Cross-platform (was NTFS Stream Fun)

While I agree with you at the academic / theoretical level, this just doesn't make commercial sense in many cases. Make no mistake, I am a *big* fan of cross-platform tools, but remember that these tools are designed to make things easier for the *developer* not the end user. One only needs look at the reception of Java by developers vs users to see that cross-platform is almost irrelevant to the end-user (Not trying to start a Java debate here folks ;) ). If one product has a perceptible benefit (greater feature set, faster, better integration) than another then it is unlikely that, "but ours is cross-platform" is going to make up for lost sales. The product I am currently developing was recently presented at a medical trade show and even though it clearly said "Available Windows, Linux, OS/X", out of 100's of enquires / expressions of interest we got precisely ONE non-windows expression of interest from a Mac OS/X guy who ended up telling us he would "knock up something similar himself" anyway. It is my firm belief that non-Windows users are generally more technically competent than their Windows counterparts (who MS keeps dumbed down). The implications of this are that it is far easier to sell into the Windows market. While I might not like this from a technical, social or moral viewpoint; it is the commercial reality that we live with. I suppose I see two REBOL worlds. One where small useful cross-platform utilities and tools are distributed and used across the internet by anyone with access; and another where larger applications integrate seemlessly with a customers existing applications. In this later case REBOL must not only play nice, it must play well.

Yes, but Frodo had to "accept" it (and its corrupting effects) for the short term so as it could be destroyed in the long run. ;) Regards, Ashley

I understand your point, but disagree with the conclusion in the following way: there are differences in technical issues which only developers may "understand", but which ultimately surface as visible characteristics to the user. For example, I recall a situation from my past in which an application had been in use on a small, increasingly antiquated box until such time that the increasing workload (and decreasing reliability) forced the team to move the application to a new platform. As usual, the term "forced" is appropriate, because the conversion wasn't done until the situation had become a near-emergency. The application had some characteristics/technology which were specific to the old platform, and therefore extra time was required to convert those aspects to the new environment. The user wailed and moaned mightily at the fact that developer time and effort was going into a system upgrade that offered no new, desired features. (I started to say "squealed like a scalded pig", but that didn't sound sufficiently respectful! ;-) The developers felt it was important to minimize the number of "moving parts" and get the previous functionality up and stable on the new platform before making any changes to provide different functions that the previous version. My point is that we live in an increasingly networked computing world, where scaling, access to resources, improving performance, deploying with "thin clients", etc. are all significantly degraded when we allow proprietary features to get in the way of ease of mobility of our code. I certainly understand that (currently!) the majority of end-user desk boxen are running some form of Windows, but even the option of moving cycles back and forth between clients and servers is often a useful tool in tuning system behavior, scaling (or degrading!) gracefully, etc. It is also the case that economic conditions, the commoditization of computer hardware, and the rate of progress in computing technology (Moore's Law is alive and well) all give weight to the idea that I should be able to run today's code on tomorrow's box with as few assumptions and constraints as possible. Ironically, one can argue that the very success of Microsoft was due to its determination to provide a uniform, consistent layer of functionality that was independent of the underlying hardware. This is consistent with the overall pattern of the development of the computing field, where a melange of ad hoc hardware, O/Ss, assembly languages, and custom variations of "standard" languages has slowly given rise to a layered model in which variations at one level (which may be perfectly legitimate *AT*THAT*LEVEL* for a variety of reasons, including performance, cost, etc.) are hidden beneath an abstracted interface that lets the next layer up deal with only the concerns that are relevant at that next layer. Because Microsoft made PC hardware a commodity and attempted to establish Visual CP/M (called "Windows" in their literature ;-) as the universal platform, the user could stop worrying about the insides of his/her box (assuming there were enough memory, the hard drive were big enough, etc...) Along comes the 'Net. Now the next stage of evolution is to make the details of the client-vs-server distinction, the operating system, etc. irrelevant in the face of open protocols (TCP/IP, FTP, HTTP, etc.) This is, of course, resisted mightily by monopolists who are loathe to cede their place of privelege which they hope would allow them to be the gatekeepers for all of computing. I suggest that it is in our users' best interests for us to look out for those interests even in areas where the user has no direct expertise. That's how we add value, after all. I don't know enough biochemistry to know precisely how the medicine operates in my body, but I *DO* expect my doctor to know enough about it to prescribe the best medication for me, to avoid simultaneously prescribing drugs with harmful interactions, etc. My other point is that using loss of platform-neutrality as argument against open source is invalid IMHO, for two reasons: 1) The opportunities for breaking neutrality are already all around us, and it is our professionalism/attitude/commitment that keeps us from breaking neutrality, not the properties of our tools. 2) Availability of open source tends IMHO to make a tool available on even *MORE* platforms, thereby further promoting widespread use and enhancing the recognition that neutrality is in the best interest of users and geeks alike.

Yes, but it almost killed him in the process (and *DID* kill others). The odds aren't good. ;-) And, of course, there's the fact that they really didn't have the option to "just say no" as do we. -jn-