With users in the tens of thousands, access conflicts are going to be the rule rather than the exception. With no row-level locking, that means the database is almost always locked when you want to access it. That means bad performance.
If the number of users is as high as stated (five figures), then the lack of row-level locking in MySQL is going to make it a performance nightmare for this application. Postgresql would almost certainly be a better choice.
Nonsense, Slashdot can't be broken. It's open source, and we all know that open source software is tremendously reliable and that any bugs that creep in are fixed instantly by the army of waiting eyeballs. Why, most open source projects are so reliable that they don't even have a bug database!
We started of with machine code... programming has become progressivley easier... The end result id natural language programming.... we can see the effects of the easyness of programming... there is a great reallignment happening.... sheds it's elitist image...
How about a natural language/. message before we start worrying about natural language programming?
I'm familiar with it; I believe it originated on the DEC-10 way back when (like late 1970's) and took quite a while to appear in UNIX shells. And yes, it does reduce the error potential somewhat, though not as much as showing a visual result of midstream navigation.
I have no doubt that the Eazel file manager is well designed and an improvement in the Linux user experience. However, I do have a problem with what seems to be a pervasive assumption that Linux usability can be revolutionized by a file manager.
What is needed to create a usable system is a usability culture. The primary component of a usability culture is a set of user experience standards to which a set of developers subscribe. The Mac would have gotten nowhere if it had just been the Finder on top of a bunch of command line utilities. All the software for the platform had to adopt the new standard for it to be a friendly platform. Windows 3.1 was a nightmare, even though the file browser was not too bad, until the Windows 95 release created a set of usability standards and developers began to live up to them.
In the case of Eazel, a Linux system with Nautilus installed is a command line system with a nice file browser. That does no one much good. What Eazel needs to do to revolutionize the Linux environment is not just to create some well-designed software (although that's important, just as the Finder, MacPaint and MacWrite were important), but to create a set of standards which other developers adopt to create a solid base of well-designed software for Linux.
I don't see anything to that effect mentioned on their web site, and so I can't help feeling that an opportunity is being lost. Nautilus is an island. We need a continent.
I think the reason most people fear and avoid the command line is that they have never been exposed to a real shell before.
Conversely, I think one reason some people are GUI-averse is that they have not used Macs.
Windows never caught up and has only been getting worse since Windows 95, while the Linux GUIs before Eazel have been absurdly bad. If that's the basis for judgment, no wonder the judgment is negative. But if you really want to know GUI, go back to the source, the Macintosh.
Tim
PS. And just in case you're wondering, I used csh for years before the Mac even came out. I've never looked back.
Andy Hertzfeld had nothing to do with the original Macintosh user interface. He wrote some crap OS modules in turgid 68K assembler, which still weigh down MacOS today. Later accomplishments are limited to working out a dog-slow way of switching processes (Servant) and working on the Telescript language that dragged down General Magic. People wave around the Apple banner without any understanding that not everyone at Apple is a user experience expert.
Yep. The example is rigged. He's assuming in the command line case that the shell window is already open and that he is already in the right directory, while assuming in the GUI case that the file browser is not open and that it's not in the right directory.
All other things being equal, in fact, on MacOS there are fewer keystrokes and less chance of making an error. Command-N to make a folder, then type in the folder name and hit return. No chance of mistyping the "mkdir" command, a class of error that even skilled UNIX users frequently commit, and four fewer keystrokes.
The keystroke delta and reduced error potential are even more significant in the case where you want to -- gasp! -- give the folder an English-like name, which will very likely involve two or three words. This involves the radical concept of spaces in file names, which requires quoting on UNIX, creating extra keystrokes for the quotation marks and the risk of an unbalanced quotation error.
Finally, assuming that you do need to navigate to the folder, the error potential is much higher in the command line case, since people frequently commit typographical and mnemonic errors when typing in directory names in a "cd" command. This just doesn't happen in a GUI environment. You can still type the leading part of a folder name to navigate as a shortcut if you want, but the visible results of doing so guarantee that you won't wind up in the wrong place -- or going nowhere at all, the usual consequence of an error in a "cd" command.
But that's what it takes to get an "insightful" rating here -- command line advocacy at the expense of basic honesty and of a moment's consideration about the realities of the situation. I wouldn't hold my breath waiting for your gentle correction to get a moderation point, since you're not in line with the dominant/. ideology.
Undetermined. There has been research for years into the automatic parallelization of algorithms written to the usual serial assumptions of computer languages, but so far as I know it has not looked specifically at converting them to the needs of a hypothetical quantum computer.
It's likely any real-world quantum computer would employ a hybrid architecture. Considering we are unlikely to see commercial quantum computers outside the lab for at least a decade, conventional processors at that time should be somewhere in the 50-100GHz range for a desktop system. Even if some application has been discovered that needs the extra quantum boost, most things we do now will run more than fast enough on a conventional processor, and given the availability of conventional software it's likely most of the system will still use the conventional processor, calling out to the quantum system only for specialized tasks.
I used to feel that way here, but actually things are starting to get better. This thread was remarkably intelligent about coming to grips with the usability problems of Linux, and remarkably free of the kind of knee-jerk "you're stupid if you don't like it" nonsense we often see on/. I think the tide is turning.
No, I meant the new kernel was not compatible with KDE. The new kernel came out later and its first responsibility was to avoid breaking major software that ran under the previous versions. This is what both Apple and Microsoft do; neither of them would issue a new OS that broke major software clients of the previous OS version.
You say Win2K breaks a lot of apps, but you don't list any examples. I'd be willing to bet they were minor utilities. (We'll leave schlockmeisters like Novell out of consideration.)
The commercial OS vendors are very concerned with backward compatibility, while the major open source OS (Linux) has no concern for it at all, nor do the numerous libraries, packages and languages written in that OS. This deficiency creates an ongoing version control nightmare for the end user.
As for your closing assertion, "you can't run the absolute latest revisions of everything and expect them all to play nice on any OS", it's just not true. I've never had this kind of version mismatch nightmare installing an upgrade to a commercial MacOS application.
According to stats at theCounter.com, Linux users are under 1% of all web users. So your estimate is a little high.
It's not that Linux will die, it's just that it is going to remain insignificant on the desktop as long as it it fails to address its usability problems -- many of which have nothing to do with the perennial command line vs. GUI debate! Instead they have to do with things like device capability databases and backward compatibility testing.
(I'm not disagreeing with you here, just expanding a bit on your comments.)
Software version maintenance on Linux is a daily nightmare. Everything is constantly revving, and none of the revs have any concern for either forward or backward compatibility. When the new kernel came out, it wasn't even compatible with KDE. Zope doesn't compile with the latest Python. Etc.
There are people who like this, who enjoy constantly scouring the net for the latest versions and for hints as to how to get balky versions to work together. The rest of us prefer to actually use our computers, rather than tinker with them endlessly out of the sheer joy of tinkering. (And a lot of us techno-jocks would prefer to spend our tinkering time as paid programmers rather than as recreational system administrators.)
There's room in the world for an OS for computer mechanics, just as there's room for cars designed for people who like spending their days under the hood, but niche tinkerer systems like this are never going to appeal beyond the small crowd of mechanics.
You're quite right. The rule of thumb we use in the Mac community was created by Bill Atkinson in the 1980's. He said, "I write software for people who've lost the manual." There's no reason a well-designed program can't be self-documenting enough that most needs for external documentation vanish -- and I'm not talking about relying on an online help system, either!
We have error messages that say things like "Couldn't write file X - check disc space and permissions" and we still get calls from people who haven't checked either.
Still, why should they have to do the checking? Those are both software-testable conditions. This is an example of error messages by guesswork, one of my pet peeves. Such messages are often misleading, because the problem may have occurred for none of the reasons listed; and these messages are always lazy, because it would only have taken a few minutes to write code that checked to see if the problem really was that the disk was full or that there was a permission problem.
(In fact, the error message code often ignores the actual error return from the routine that failed, and even though there was, say, an out of memory error code, it still blithely goes ahead and says to check permissions and disk space.)
the more you hide the underlying complexity the more you discourage people learning the concepts they will one day need.
Sorry, I really don't think that putting out accurate error messages hurts anyone in any way.
The error message concept itself can be an example of tunnel vision. On a server system, no one is sitting in front of the console and no one will see the error message. Instead, errors on unattended systems need to be routed into email or instant messaging, so the responsible person will see them wherever they are.
You do have a good point that data consistency algorithms like two-step commit are themselves a form of error prevention. I'm just saying that there is still a long way to go in error prevention, reporting, and correction, and that the obstacles to moving forward on those fronts are cultural and psychological rather than technical.
First, one could release the reserve storage one had allocated previously, guaranteeing that requests already in the pipeline could be serviced, while choking off new requests until the problem is resolved.
Second, one could send an automatic email notification to both the system administrator and to support, alerting the admin what the problem is and prepping support with information about the system in case a call comes in from the site.
Third, the system could trigger a purge, compress, or archive procedure which might be able to resolve the problem without operator intervention.
There are other ways to approach the problem as well, such as checking for disk full conditions before they happen and requesting preventative action. Rather than list all the possibilities, I just wanted to point out that there is a tunnel vision in traditional engineering approaches to error handling.
Part of the reason for the tunnel vision is that advanced error handling is just not a status job. No one gets as excited about doing something like this as they do about coding a new feature. But there are many more things that systems could do for the customer than they do now, and many of these things have a serious value proposition.
That's a false economy. Time spent on error prevention more than pays for itself. There are two main reasons.
(1) Development effort has benefits that are replicated on every user's system, so the most economical place to address problems is during development rather then by deferring costs onto the users.
(2) Error resolution and correction are inherently far more expensive than error prevention. Human society has known this for a very long time, hence the cliche: "An ounce of prevention is worth a pound of cure."
As for inability to deal with every possible error case, I generally agree with you, but in this case we are talking about an extremely common event, a storage device becoming full. Most complaints I hear from support staffers revolve around problems just this common, which the system could have guarded against but did not.
I think there is a psychological issue here, in that there is an actual pleasure -- or at least reward -- in blaming users for their their problems. There's a feeling of superiority in it. That (and related blame and dominance issues) are among the reasons that error prevention has not become a more widely applied principle.
Have you considered to what extent the more annoying support calls could be avoided by better system design? For instance, why should the administrator have to manually check to see if the file system is at 100% -- why shouldn't the system notify them of this common condition?
This is not meant as a rhetorical question, and even less as a flame. I've just noticed, as a longtime user experience designer, that many support people's complaints about user error never need have occurred in the first place, and could have been avoided by the well-known user experience principle of error prevention.
Open Source software is inherently non-profit making
Wow. this news is going to crush the stockholders of RedHat, VA Linux, etc. etc.
True. Are you just figuring this out? You might consider checking this link if you want to catch up with the rest of the class. Those companies are on a one-way trip to delisting.
It appears that there were earlier releases of TeX in the 1982-1984 period, although few traces of them remain. It also appears that the 1986 release obsoleted most of the earlier work.
There is a little information on the licensing in 1986, though I couldn't find anything earlier that addresses the question. This source says:
We are frequently asked if it is proper for the recipient of a Unix
TeX tape to give Unix TeX to other sites. Since Donald Knuth has
released the TeX programs as free public-domain software, it is quite
proper...
This demonstrates that TeX in 1986 was free software, but leaves open the question about earlier distributions.
Well, if you're not a UNIX youngster, why are you saying that BSD was developed as open source? It wasn't. Getting a BSD distribution before 1988 required an AT&T UNIX source code license. That is not compatible with any definition of open source or free software that I have heard of.
Allow me to quote from a widely-reprinted history of BSD:
Up through the release of 4.3BSD-Tahoe, all recipients of BSD had to first get an AT&T source license. That was because the BSD systems were never released by Berkeley in a binary-only format; the distributions always contained the complete source to every part of the system. The history of the Unix system and the BSD system in particular had shown the power of making the source available to the users. Instead of passively using the system, they actively worked to fix bugs, improve performance and functionality, and even add completely new features.
With the increasing cost of the AT&T source licenses, vendors that wanted to build standalone TCP/IP-based networking products for the PC market using the BSD code found the per-binary costs prohibitive. So, they requested that Berkeley break out the networking code and utilities and provide them under licensing terms that did not require an AT&T source license. The TCP/IP networking code clearly did not exist in 32/V and thus had been developed entirely by Berkeley and its contributors. The BSD originated networking code and supporting utilities were released in June 1989 as Networking Release 1, the first freely-redistributable code from Berkeley.
The first Berkeley distribution was in 1977. The first free distribution was eleven years later. Saying that BSD was developed as open source is just plain wrong.
I don't think that you know anything about compiler theory if you're seriously claiming that GCC is innovative.
Your statements about Timbuktu and X Window are unsupported. In particular, your statement that Timbuktu long postdates X is apparently false, since the X history links I gave earlier show that X is from the late 1980's, while Timbuktu was an early Mac product.
As for TeX, I do find one source showing a book date earlier than 1986, which is 1984 -- which, again, is after the release of the Macintosh. Apparently the actual language documentation was not released until 1986, so I don't know what an earlier "release" could have meant. I believe the 1980 date for TUG may be in error.
I have spent quite a while looking over TeX history links and they are ambiguous on the initial release date and original licensing conditions. I have found, in this thread and the previous one, that open source advocates often falsely claim that closed-source software projects originated as open source, so I am unwilling to accept an unsupported claim that TeX was developed as open source. Anyone who has actual information, as opposed to the kind of flame I'm responding to, is invited to speak up here or to write me. Thanks.
I think it is strange to say that I did not perform research in following up this thread; I've given lots of historical links, and I'm glad the subject has elicited such interest. In your case, you cited a bunch of minor programs with acronym names and not a word of text description or link, and it didn't seem like these obscure names would be worth the effort to chase down.
I wish you UNIX youngsters would listen to someone who, although he went over to the dark side of the Mac in 1984, was a UNIX kernel hacker in the early 1980's, when bsd was still fresh. I am telling you that those were not at all open source licensing conditions. I am telling you that UNIX source both in BSD and AT&T forms was closely held and closely controlled at the time. It took quite a while before anyone heard of FreeBSD. What's more, BSD is a clone of the original closed source UNIX system. UNIX was innovative and remains the standard of technical excellence of operating system architectures, but it was not from open source.
Historians of X Window treat it as the "me too" GUI that it is. As for your statement, it was the first cross platform network GUI. That's something that Macintosh still doesn't do, this seems to be an oxymoron; but in any case, one of the oldest (and still-living) Mac products is called Timbuktu, and it has long been a cross-platform network GUI.
GCC is developer-facing and it's hard to claim as an innovation due to its clone nature. It's not exactly up to the standards of compiler architecture of the time, as I think anyone who has studied compilers could attest.
Finally, closing your message with a slap at the graphical user interface shows an actual distate for innovation. This is one of the odd things about the open source movement. It declares itself revolutionary but is in fact reactionary. It has a set of tastes that was laid down twenty years ago and has not moved forward in any significant way since then. In the meantime, mainstream computing and even the popular taste have passed it by.
Tim
(Footnote on TeX history: 1986 is the earliest documented date of release I found, but Knuth says "it still took many, many years to finish TeX".)
Slashdot Mirror
Tim
Tim
Tim
Tim
How about a natural language /. message before we start worrying about natural language programming?
Tim
Tim
What is needed to create a usable system is a usability culture. The primary component of a usability culture is a set of user experience standards to which a set of developers subscribe. The Mac would have gotten nowhere if it had just been the Finder on top of a bunch of command line utilities. All the software for the platform had to adopt the new standard for it to be a friendly platform. Windows 3.1 was a nightmare, even though the file browser was not too bad, until the Windows 95 release created a set of usability standards and developers began to live up to them.
In the case of Eazel, a Linux system with Nautilus installed is a command line system with a nice file browser. That does no one much good. What Eazel needs to do to revolutionize the Linux environment is not just to create some well-designed software (although that's important, just as the Finder, MacPaint and MacWrite were important), but to create a set of standards which other developers adopt to create a solid base of well-designed software for Linux.
I don't see anything to that effect mentioned on their web site, and so I can't help feeling that an opportunity is being lost. Nautilus is an island. We need a continent.
Tim
Conversely, I think one reason some people are GUI-averse is that they have not used Macs.
Windows never caught up and has only been getting worse since Windows 95, while the Linux GUIs before Eazel have been absurdly bad. If that's the basis for judgment, no wonder the judgment is negative. But if you really want to know GUI, go back to the source, the Macintosh.
Tim
PS. And just in case you're wondering, I used csh for years before the Mac even came out. I've never looked back.
Tim
All other things being equal, in fact, on MacOS there are fewer keystrokes and less chance of making an error. Command-N to make a folder, then type in the folder name and hit return. No chance of mistyping the "mkdir" command, a class of error that even skilled UNIX users frequently commit, and four fewer keystrokes.
The keystroke delta and reduced error potential are even more significant in the case where you want to -- gasp! -- give the folder an English-like name, which will very likely involve two or three words. This involves the radical concept of spaces in file names, which requires quoting on UNIX, creating extra keystrokes for the quotation marks and the risk of an unbalanced quotation error.
Finally, assuming that you do need to navigate to the folder, the error potential is much higher in the command line case, since people frequently commit typographical and mnemonic errors when typing in directory names in a "cd" command. This just doesn't happen in a GUI environment. You can still type the leading part of a folder name to navigate as a shortcut if you want, but the visible results of doing so guarantee that you won't wind up in the wrong place -- or going nowhere at all, the usual consequence of an error in a "cd" command.
But that's what it takes to get an "insightful" rating here -- command line advocacy at the expense of basic honesty and of a moment's consideration about the realities of the situation. I wouldn't hold my breath waiting for your gentle correction to get a moderation point, since you're not in line with the dominant /. ideology.
Tim
It's likely any real-world quantum computer would employ a hybrid architecture. Considering we are unlikely to see commercial quantum computers outside the lab for at least a decade, conventional processors at that time should be somewhere in the 50-100GHz range for a desktop system. Even if some application has been discovered that needs the extra quantum boost, most things we do now will run more than fast enough on a conventional processor, and given the availability of conventional software it's likely most of the system will still use the conventional processor, calling out to the quantum system only for specialized tasks.
Tim
"Overheating" for a quantum computer would mean reaching a degree or two above absolute zero. Anything higher than that and the qubits decohere.
Tim
You say Win2K breaks a lot of apps, but you don't list any examples. I'd be willing to bet they were minor utilities. (We'll leave schlockmeisters like Novell out of consideration.)
The commercial OS vendors are very concerned with backward compatibility, while the major open source OS (Linux) has no concern for it at all, nor do the numerous libraries, packages and languages written in that OS. This deficiency creates an ongoing version control nightmare for the end user.
As for your closing assertion, "you can't run the absolute latest revisions of everything and expect them all to play nice on any OS", it's just not true. I've never had this kind of version mismatch nightmare installing an upgrade to a commercial MacOS application.
Tim
It's not that Linux will die, it's just that it is going to remain insignificant on the desktop as long as it it fails to address its usability problems -- many of which have nothing to do with the perennial command line vs. GUI debate! Instead they have to do with things like device capability databases and backward compatibility testing.
(I'm not disagreeing with you here, just expanding a bit on your comments.)
Tim
There are people who like this, who enjoy constantly scouring the net for the latest versions and for hints as to how to get balky versions to work together. The rest of us prefer to actually use our computers, rather than tinker with them endlessly out of the sheer joy of tinkering. (And a lot of us techno-jocks would prefer to spend our tinkering time as paid programmers rather than as recreational system administrators.)
There's room in the world for an OS for computer mechanics, just as there's room for cars designed for people who like spending their days under the hood, but niche tinkerer systems like this are never going to appeal beyond the small crowd of mechanics.
Tim
Tim
Still, why should they have to do the checking? Those are both software-testable conditions. This is an example of error messages by guesswork, one of my pet peeves. Such messages are often misleading, because the problem may have occurred for none of the reasons listed; and these messages are always lazy, because it would only have taken a few minutes to write code that checked to see if the problem really was that the disk was full or that there was a permission problem.
(In fact, the error message code often ignores the actual error return from the routine that failed, and even though there was, say, an out of memory error code, it still blithely goes ahead and says to check permissions and disk space.)
the more you hide the underlying complexity the more you discourage people learning the concepts they will one day need.
Sorry, I really don't think that putting out accurate error messages hurts anyone in any way.
The error message concept itself can be an example of tunnel vision. On a server system, no one is sitting in front of the console and no one will see the error message. Instead, errors on unattended systems need to be routed into email or instant messaging, so the responsible person will see them wherever they are.
You do have a good point that data consistency algorithms like two-step commit are themselves a form of error prevention. I'm just saying that there is still a long way to go in error prevention, reporting, and correction, and that the obstacles to moving forward on those fronts are cultural and psychological rather than technical.
Tim
There are more than two options.
First, one could release the reserve storage one had allocated previously, guaranteeing that requests already in the pipeline could be serviced, while choking off new requests until the problem is resolved.
Second, one could send an automatic email notification to both the system administrator and to support, alerting the admin what the problem is and prepping support with information about the system in case a call comes in from the site.
Third, the system could trigger a purge, compress, or archive procedure which might be able to resolve the problem without operator intervention.
There are other ways to approach the problem as well, such as checking for disk full conditions before they happen and requesting preventative action. Rather than list all the possibilities, I just wanted to point out that there is a tunnel vision in traditional engineering approaches to error handling.
Part of the reason for the tunnel vision is that advanced error handling is just not a status job. No one gets as excited about doing something like this as they do about coding a new feature. But there are many more things that systems could do for the customer than they do now, and many of these things have a serious value proposition.
Tim
(1) Development effort has benefits that are replicated on every user's system, so the most economical place to address problems is during development rather then by deferring costs onto the users.
(2) Error resolution and correction are inherently far more expensive than error prevention. Human society has known this for a very long time, hence the cliche: "An ounce of prevention is worth a pound of cure."
As for inability to deal with every possible error case, I generally agree with you, but in this case we are talking about an extremely common event, a storage device becoming full. Most complaints I hear from support staffers revolve around problems just this common, which the system could have guarded against but did not.
I think there is a psychological issue here, in that there is an actual pleasure -- or at least reward -- in blaming users for their their problems. There's a feeling of superiority in it. That (and related blame and dominance issues) are among the reasons that error prevention has not become a more widely applied principle.
Tim
This is not meant as a rhetorical question, and even less as a flame. I've just noticed, as a longtime user experience designer, that many support people's complaints about user error never need have occurred in the first place, and could have been avoided by the well-known user experience principle of error prevention.
Regards,
Tim
Wow. this news is going to crush the stockholders of RedHat, VA Linux, etc. etc.
True. Are you just figuring this out? You might consider checking this link if you want to catch up with the rest of the class. Those companies are on a one-way trip to delisting.
Tim
It appears that there were earlier releases of TeX in the 1982-1984 period, although few traces of them remain. It also appears that the 1986 release obsoleted most of the earlier work.
There is a little information on the licensing in 1986, though I couldn't find anything earlier that addresses the question. This source says: We are frequently asked if it is proper for the recipient of a Unix TeX tape to give Unix TeX to other sites. Since Donald Knuth has released the TeX programs as free public-domain software, it is quite proper...
This demonstrates that TeX in 1986 was free software, but leaves open the question about earlier distributions.
Tim
Allow me to quote from a widely-reprinted history of BSD:
Up through the release of 4.3BSD-Tahoe, all recipients of BSD had to first get an AT&T source license. That was because the BSD systems were never released by Berkeley in a binary-only format; the distributions always contained the complete source to every part of the system. The history of the Unix system and the BSD system in particular had shown the power of making the source available to the users. Instead of passively using the system, they actively worked to fix bugs, improve performance and functionality, and even add completely new features.
With the increasing cost of the AT&T source licenses, vendors that wanted to build standalone TCP/IP-based networking products for the PC market using the BSD code found the per-binary costs prohibitive. So, they requested that Berkeley break out the networking code and utilities and provide them under licensing terms that did not require an AT&T source license. The TCP/IP networking code clearly did not exist in 32/V and thus had been developed entirely by Berkeley and its contributors. The BSD originated networking code and supporting utilities were released in June 1989 as Networking Release 1, the first freely-redistributable code from Berkeley.
The first Berkeley distribution was in 1977. The first free distribution was eleven years later. Saying that BSD was developed as open source is just plain wrong.
I don't think that you know anything about compiler theory if you're seriously claiming that GCC is innovative.
Your statements about Timbuktu and X Window are unsupported. In particular, your statement that Timbuktu long postdates X is apparently false, since the X history links I gave earlier show that X is from the late 1980's, while Timbuktu was an early Mac product.
As for TeX, I do find one source showing a book date earlier than 1986, which is 1984 -- which, again, is after the release of the Macintosh. Apparently the actual language documentation was not released until 1986, so I don't know what an earlier "release" could have meant. I believe the 1980 date for TUG may be in error.
I have spent quite a while looking over TeX history links and they are ambiguous on the initial release date and original licensing conditions. I have found, in this thread and the previous one, that open source advocates often falsely claim that closed-source software projects originated as open source, so I am unwilling to accept an unsupported claim that TeX was developed as open source. Anyone who has actual information, as opposed to the kind of flame I'm responding to, is invited to speak up here or to write me. Thanks.
Tim
I wish you UNIX youngsters would listen to someone who, although he went over to the dark side of the Mac in 1984, was a UNIX kernel hacker in the early 1980's, when bsd was still fresh. I am telling you that those were not at all open source licensing conditions. I am telling you that UNIX source both in BSD and AT&T forms was closely held and closely controlled at the time. It took quite a while before anyone heard of FreeBSD. What's more, BSD is a clone of the original closed source UNIX system. UNIX was innovative and remains the standard of technical excellence of operating system architectures, but it was not from open source.
Historians of X Window treat it as the "me too" GUI that it is. As for your statement, it was the first cross platform network GUI. That's something that Macintosh still doesn't do, this seems to be an oxymoron; but in any case, one of the oldest (and still-living) Mac products is called Timbuktu, and it has long been a cross-platform network GUI.
GCC is developer-facing and it's hard to claim as an innovation due to its clone nature. It's not exactly up to the standards of compiler architecture of the time, as I think anyone who has studied compilers could attest.
Finally, closing your message with a slap at the graphical user interface shows an actual distate for innovation. This is one of the odd things about the open source movement. It declares itself revolutionary but is in fact reactionary. It has a set of tastes that was laid down twenty years ago and has not moved forward in any significant way since then. In the meantime, mainstream computing and even the popular taste have passed it by.
Tim
(Footnote on TeX history: 1986 is the earliest documented date of release I found, but Knuth says "it still took many, many years to finish TeX".)