In 1993, I bought what appeared to be the last Mitsumi ``single speed'' CD-ROM drive in the city of Toronto in order to do an install of FreeBSD.
At the time, Slackware provided more "nifty, readily installable stuff" than FreeBSD, and it made more sense for me to run Linux.
They nonetheless have a longstanding, mature, system that just seems to keep improving.
FreeBSD is now getting shelf space at CompUSA, which should give it at least a little bit of "mindshare." It appears that some BSDers are a bit sore at the widespread public reception of Linux as "nearly mainstream;" this at least gives a bit of publicity in their favor.
In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.
Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.
The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.
I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...
Berlin: The New Generation
A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.
I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.
In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."
My Take on Why They Haven't Progressed Quicker
After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.
I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:
They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.
This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.
This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.
The high probability of failure completely discourages commercial investment of time/effort/money.
Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.
The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.
GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.
It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)
Good News Even If The Big Project Fails
There may be components that are of value.
For instance, they may wind up producing a font rendering engine that could be useful elsewhere.
The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
There may be some useful IDL definitions.
Some of what appears valuable in Berlin is the recasting of Fresco ideas.
It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)
It is not evident that a processor array designed to run neural networks would be useful for anything other than solving what amounts to nonlinear regression problems.
For all that neural nets have been arousing excitement for a dozen years, they seem to have successfully avoided usefulness in general purpose computing environments.
When we write programs that "learn," it turns out that we do and they don't.
This goes along nicely with Douglas Hofstadter in his book ``Creative Analogies and Fluid Concepts'' where he outlines areas that are critical to language translation that happen to be real tough to even think about algorithms to process.
Hofstadter asks the question: ``What is the Chicago of Russia?'' which does not admit unambiguous results. I have parallelled this somewhat with the question What is the Moscow of New York? which has too many potentially valid answers for comfort.
I think "Star Trek Computing" is about as near as "Star Trek Economics," which is to say, no way soon.
There are certainly things to be learned; it's mostly humans that are doing the learning, not the computers...
Back a year or so ago, when Linus got hired on at Transmeta, there was much paranoia and blustering over what this "Transmeta" organization was all about.
In the interests of having some clue of what was going on, I did some research that is collected up at My Page On Transmeta.
I took a look at all the "open source" (in the sense of the term as used by the intelligence community) information that I could find via the Internet.
The author of the "Times Digital Edition" sent me email asking about how/why I collected that material...
All I have to say is that people have gotten material of vastly lower quality published in newsstand magazines...
If you look at it carefully, 2000 is not the beginning of a new millennium, but merely the last year of one.
(Ask yourself why Arthur C. Clarke named the movie "2001: A Space Odyssey" if you're not sure of this...)
People will hold "new millennium" parties, "new millennium riots," release "new millennium" models of both automobiles and soft drinks, because they were looking for an excuse to do so.
This is true whether they're religious extremists, political extremists, marketing droids, or people that just want to party.
The juxtaposition of a Whole Lot of Zeroes happens to provide a cover for there being an excuse.
Take it further than that and you'll get dumb results.
Well, for a view that is both Linux-oriented and somewhat entertaining, see My Linux Y2K Page. It actually cites some ancient legislation of hundreds of years ago...
As for the September 9th issue, this looks like it was largely an issue of incompetent journalists noticing that there are a whole lot of "9"'s together in 9/9/99.
They failed to grasp that in order for this to actually represent days and months, which can number higher than 9, the representation actually needs to be like 09/09/99.
There is a rumor that the Chinese stock exchange, running some six-year-old IBM AS/400 systems, ran into problems Sept 9 and is now down; I saw this in a news report reported on at work, which I would have hoped to be accurate. I have not found any independent verification, so this has to be considered mere rumor and not reality...
It will be real interesting to see where this takes Linux, and what impact the availability of R/3 on Linux has on sales of R/3 on NT.
There are a few entertaining factors to throw in, for good and for ill on many sides:
Note that the release of R/3 on Linux uses "SAP DB" as the database.
This used to be Adabas-D, the first "big name" RDBMS available on Linux. It was fascinating to see that SAP AG bought Adabas-D from Software AG earlier in the summer.
The net effect of this is several-fold:
SAP isn't "feeding" any sales to anyone else out of the deal, as would be the case for an NT-based system, or for an Oracle-based system.
SAP gets to keep all the money that comes in.
SAP gets to have more control over the R/3 kernel and its interaction with both RDBMS and OS, which I'd speculate has a lot to do with the decent performance that was achieved.
R/3 does a huge amount of its own cacheing and such, and doesn't make much use of the more advanced features of the RDBMS; the fact that SAP controls the sources to SAP DB means that they can tune it to their requirements, removing any "cruft" that may be K001 but not actually useful for their use of a DBMS engine.
Net result is that this moves SAP "up the food chain" relative to both Oracle and Microsoft. Good news for SAP; probably irrelevant from the perspective of Linux "community."
As you mention, Microsoft is now ``picking apart" BAAN's software, probably with particular attention to deploying it atop MTS (Microsoft Transaction Server) / MSQM (Microsoft Message Queue) / SQL Server.
This architecture differs from that of SAP's R/3 in that it makes transactions greatly more visible, and encourages the forward-thinking approach of making extensive use of asynchronous processing.
Contrast with PeopleSoft who, for large installations, make use of BEA Tuxedo, another "message queueing" system in order to improve scalability.
R/3 contains TP management software, but it is much more like CICS, with implicit management of transactions rather than visible management, which tends to result in lesser scalability.
Danger lies here for SAP; Microsoft has indeed copied their technologies from some smart folks, having a source license to Sybase as well as a MQ product that looks like it was directly "ripped off" from IBM's MQSeries architecture.
The third issue that has been largely ignored thus far is that all of these folks are pushing hard to build web-based front ends. The company I work at has half a dozen projects on the go to put web-based "front ends" onto R/3 systems for one purpose or another.
To that end, SAP's "BAPI" system, which essentially provides a Java front end to many R/3 "transactions," making them more readily mapped to transactions as others would think of them, is an "offensive" action to try to get lots of Internet apps out there.
And Microsoft is waging war with BizTalk, a scheme where transactions are represented in XML form and may be transferred around as such. This looks to be a natural way of encouraging widespread use of MSMQ...
Siemens does not produce the R/3 application. R/3 is a product of SAP AG.
Siemens does not produce Linux, the OS on which it is running. Nor did they produce the "tuned kernel;" that was done by SAP AG.
Siemens does not produce SAP DB, the relational database previously known as Adabas-D, produced originally by Software AG.
In other words, they don't sell the software that they are benchmarking.
Add to this the factor that all the other hardware vendors that try to sell systems on which to run R/3 run this same SD benchmark.
The implication that the throughput is excessive is fairly much irrelevant.
The use of the SD test is fairly normal, as is the use of really fast networks on which application servers and database servers run.
The R/3 systems that I help administer are connected together using Fibre Channel; there is a major premium on speed of connections between DB server and application servers, because they do a LOT of communications.
In contrast, it usually acceptable to run presentation servers ( e.g. what you'd probably think of as ``clients'') on much slower connections. Users find 56K connections fairly usable, albeit not as good as faster connections...
The long and short of this is that while the statistics may not be reasonably used to determine precisely how many "transactions per second" you may expect to be able to process, the results are about as useful as benchmarks get.
If you look back at the last ten years, there has been the anomaly of there being only a small amount of real progress in the development of operating systems.
Twenty years ago, there were a goodly number of derivatives of Multics as well as attempts at "truly new" stuff like Hydra on their way.
In the '90s, the only alternatives anyone has had any "faith" in have been Windows NT, and, in the last year, Linux. I would contend that this has been the result of
A concerted attempt by MSFT to buy out the OS research groups,
The failure of IBM's "WorkPlace OS" project, which is related insofar as it was based on Mach, and MSFT offered Rashid, the Mach architect, "too much to pass up," and
Related to both of the above, a conscious attempt by MSFT to convince the marketplace that the future would involve "Windows Everywhere."
Add in the factor that there used to be sizable projects that combined academic, government, and corporate funds to produce public goods, as resulted in such things as X, BSD 386, CMU Lisp, and Andrew, that don't seem to be continuing to be sponsored
And you get the situation where it looked like the world might conceivably be "Windows Anywhere."
The way we get improvements, in the long run, is by trying a diverse set of different things. Linux is not appropriate everywhere, and we may find, out of some alternative OS research, the successor that will be so much better that it can ultimately replace Linux for "general purpose" applications.
Furthermore, there are more kinds of applications out there than merely those for which the "big server" that Linux is ideal for.
For high security applications, the models provided by the UNIX security model are starting to show creakiness.
Experimentation with capability-based systems is needed to figure out how to build more secure systems.
For very small embedded systems, Linux is simply too big.
Cygnus' ECOS has a kernel that can be configured as small as a couple of kilobytes.
It may be amazing enough that you can boot Linux on a PalmPilot; that doesn't mean that it is actually useful to do so.
If I wanted to build something to fit in 2MB of RAM and some smaller amount of ROM, I'd not pick Linux.
The world will be served by allowing Linux to be replaced by a set of OSes that are better, once such systems can mature into usefulness.
Remember also that Linux may be legitimately regarded as being merely a kernel.
Is there a good wording for a "cease and desist" letter that would be readily recognized?
I've had this happen before; a Linux user group once "ripped off" the data from NTLUG, and then denied that they had done so. (The offenders linked to an essay that I wrote, and claimed I was a member of their group...)
It would be good to have something that could encourage "better behaviour" without necessarily having to go to the expense and annoyance of getting a lawyer involved...
Red Hat Software is offering this to those people that wrote code which is something that represents a contribution to the body of software that makes up the product that they sell.
That represents value returned for value contributed.
If your only "participation" is in having bought a box from them, then you received your reward in the form of that box.
If your only "participation" is in reading Slashdot, then I see no connection, no value, and no reason for them to give you anything.
Slashdot Mirror
At the time, Slackware provided more "nifty, readily installable stuff" than FreeBSD, and it made more sense for me to run Linux.
They nonetheless have a longstanding, mature, system that just seems to keep improving.
FreeBSD is now getting shelf space at CompUSA, which should give it at least a little bit of "mindshare." It appears that some BSDers are a bit sore at the widespread public reception of Linux as "nearly mainstream;" this at least gives a bit of publicity in their favor.
In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.
In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.
Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.
The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.
I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...
A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.
I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.
In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."
After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.
I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:
This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.
This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.
The high probability of failure completely discourages commercial investment of time/effort/money.
The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.
Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.
It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)
Good News Even If The Big Project Fails
For instance, they may wind up producing a font rendering engine that could be useful elsewhere.
It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)
For all that neural nets have been arousing excitement for a dozen years, they seem to have successfully avoided usefulness in general purpose computing environments.
In particular, he notes that
This goes along nicely with Douglas Hofstadter in his book ``Creative Analogies and Fluid Concepts'' where he outlines areas that are critical to language translation that happen to be real tough to even think about algorithms to process.
Hofstadter asks the question: ``What is the Chicago of Russia?'' which does not admit unambiguous results. I have parallelled this somewhat with the question What is the Moscow of New York? which has too many potentially valid answers for comfort.
I think "Star Trek Computing" is about as near as "Star Trek Economics," which is to say, no way soon.
There are certainly things to be learned; it's mostly humans that are doing the learning, not the computers...
In the interests of having some clue of what was going on, I did some research that is collected up at My Page On Transmeta.
I took a look at all the "open source" (in the sense of the term as used by the intelligence community) information that I could find via the Internet.
The author of the "Times Digital Edition" sent me email asking about how/why I collected that material...
All I have to say is that people have gotten material of vastly lower quality published in newsstand magazines...
Sorry about that...
(Ask yourself why Arthur C. Clarke named the movie "2001: A Space Odyssey" if you're not sure of this...)
People will hold "new millennium" parties, "new millennium riots," release "new millennium" models of both automobiles and soft drinks, because they were looking for an excuse to do so.
This is true whether they're religious extremists, political extremists, marketing droids, or people that just want to party.
The juxtaposition of a Whole Lot of Zeroes happens to provide a cover for there being an excuse.
Take it further than that and you'll get dumb results.
Whether you're concerned about Y2K from a technical perspective, or have religious concerns about Y2K.
As for the September 9th issue, this looks like it was largely an issue of incompetent journalists noticing that there are a whole lot of "9"'s together in 9/9/99.
They failed to grasp that in order for this to actually represent days and months, which can number higher than 9, the representation actually needs to be like 09/09/99.
There is a rumor that the Chinese stock exchange, running some six-year-old IBM AS/400 systems, ran into problems Sept 9 and is now down; I saw this in a news report reported on at work, which I would have hoped to be accurate. I have not found any independent verification, so this has to be considered mere rumor and not reality...
There are a few entertaining factors to throw in, for good and for ill on many sides:
- Note that the release of R/3 on Linux uses "SAP DB" as the database.
- As you mention, Microsoft is now ``picking apart" BAAN's software, probably with particular attention to deploying it atop MTS (Microsoft Transaction Server) / MSQM (Microsoft Message Queue) / SQL Server.
- The third issue that has been largely ignored thus far is that all of these folks are pushing hard to build web-based front ends. The company I work at has half a dozen projects on the go to put web-based "front ends" onto R/3 systems for one purpose or another.
Interesting times, to be sure...This used to be Adabas-D, the first "big name" RDBMS available on Linux. It was fascinating to see that SAP AG bought Adabas-D from Software AG earlier in the summer.
The net effect of this is several-fold:
- SAP isn't "feeding" any sales to anyone else out of the deal, as would be the case for an NT-based system, or for an Oracle-based system.
- SAP gets to keep all the money that comes in.
- SAP gets to have more control over the R/3 kernel and its interaction with both RDBMS and OS, which I'd speculate has a lot to do with the decent performance that was achieved.
Net result is that this moves SAP "up the food chain" relative to both Oracle and Microsoft. Good news for SAP; probably irrelevant from the perspective of Linux "community."R/3 does a huge amount of its own cacheing and such, and doesn't make much use of the more advanced features of the RDBMS; the fact that SAP controls the sources to SAP DB means that they can tune it to their requirements, removing any "cruft" that may be K001 but not actually useful for their use of a DBMS engine.
This architecture differs from that of SAP's R/3 in that it makes transactions greatly more visible, and encourages the forward-thinking approach of making extensive use of asynchronous processing.
Contrast with PeopleSoft who, for large installations, make use of BEA Tuxedo, another "message queueing" system in order to improve scalability.
R/3 contains TP management software, but it is much more like CICS, with implicit management of transactions rather than visible management, which tends to result in lesser scalability.
Danger lies here for SAP; Microsoft has indeed copied their technologies from some smart folks, having a source license to Sybase as well as a MQ product that looks like it was directly "ripped off" from IBM's MQSeries architecture.
To that end, SAP's "BAPI" system, which essentially provides a Java front end to many R/3 "transactions," making them more readily mapped to transactions as others would think of them, is an "offensive" action to try to get lots of Internet apps out there.
And Microsoft is waging war with BizTalk, a scheme where transactions are represented in XML form and may be transferred around as such. This looks to be a natural way of encouraging widespread use of MSMQ...
- Consider the straight facts:
- Siemens does sell the hardware.
- Siemens does not produce the R/3 application. R/3 is a product of SAP AG.
- Siemens does not produce Linux, the OS on which it is running. Nor did they produce the "tuned kernel;" that was done by SAP AG.
- Siemens does not produce SAP DB, the relational database previously known as Adabas-D, produced originally by Software AG.
- Add to this the factor that all the other hardware vendors that try to sell systems on which to run R/3 run this same SD benchmark.
- The implication that the throughput is excessive is fairly much irrelevant.
The long and short of this is that while the statistics may not be reasonably used to determine precisely how many "transactions per second" you may expect to be able to process, the results are about as useful as benchmarks get.In other words, they don't sell the software that they are benchmarking.
The use of the SD test is fairly normal, as is the use of really fast networks on which application servers and database servers run.
The R/3 systems that I help administer are connected together using Fibre Channel; there is a major premium on speed of connections between DB server and application servers, because they do a LOT of communications.
In contrast, it usually acceptable to run presentation servers ( e.g. what you'd probably think of as ``clients'') on much slower connections. Users find 56K connections fairly usable, albeit not as good as faster connections...
It's not merely ``benchmarketing.''
For where former Mach people are, see Former Mach Project Members.
Microsoft themselves publicize Rashid's arrival
Twenty years ago, there were a goodly number of derivatives of Multics as well as attempts at "truly new" stuff like Hydra on their way.
In the '90s, the only alternatives anyone has had any "faith" in have been Windows NT, and, in the last year, Linux. I would contend that this has been the result of
- A concerted attempt by MSFT to buy out the OS research groups,
- The failure of IBM's "WorkPlace OS" project, which is related insofar as it was based on Mach, and MSFT offered Rashid, the Mach architect, "too much to pass up," and
- Related to both of the above, a conscious attempt by MSFT to convince the marketplace that the future would involve "Windows Everywhere."
- Add in the factor that there used to be sizable projects that combined academic, government, and corporate funds to produce public goods, as resulted in such things as X, BSD 386, CMU Lisp, and Andrew, that don't seem to be continuing to be sponsored
And you get the situation where it looked like the world might conceivably be "Windows Anywhere."The way we get improvements, in the long run, is by trying a diverse set of different things. Linux is not appropriate everywhere, and we may find, out of some alternative OS research, the successor that will be so much better that it can ultimately replace Linux for "general purpose" applications.
Furthermore, there are more kinds of applications out there than merely those for which the "big server" that Linux is ideal for.
Experimentation with capability-based systems is needed to figure out how to build more secure systems.
Cygnus' ECOS has a kernel that can be configured as small as a couple of kilobytes.
It may be amazing enough that you can boot Linux on a PalmPilot; that doesn't mean that it is actually useful to do so.
If I wanted to build something to fit in 2MB of RAM and some smaller amount of ROM, I'd not pick Linux.
The world will be served by allowing Linux to be replaced by a set of OSes that are better, once such systems can mature into usefulness.
Remember also that Linux may be legitimately regarded as being merely a kernel.
I've had this happen before; a Linux user group once "ripped off" the data from NTLUG, and then denied that they had done so. (The offenders linked to an essay that I wrote, and claimed I was a member of their group...)
It would be good to have something that could encourage "better behaviour" without necessarily having to go to the expense and annoyance of getting a lawyer involved...
Effectively, M3 was a "one group" implementation, a Modula family language produced by DEC.
It appears to be about as portable as GCC, and the SPIN OS is written in it.
I could imagine worse ideas than trying to build a kernel in Modula 3...
Red Hat Software is offering this to those people that wrote code which is something that represents a contribution to the body of software that makes up the product that they sell.
That represents value returned for value contributed.
If your only "participation" is in having bought a box from them, then you received your reward in the form of that box.
If your only "participation" is in reading Slashdot, then I see no connection, no value, and no reason for them to give you anything.