My bad; yes, Hydra should be on the list, perhaps as the great-grand-daddy. I gather that the IBM AS/400 platform is based on Hydra, albeit with the advanced stuff hidden far from view so as not to frighten the accountants.
The interesting part is that Legion provides tools that resemble some parts of CORBA, whilst Spring provided tools that grew into CORBA, whilst Sprite provided journalling and cache tools that are essentially what journalling and cache servers provide today.
In a sense, what has happened is that an OS of the 1970s, Unix, has been shown sufficiently malleable that it could integrate in concepts from the research projects of the 1970s and 1980s.
Unfortunately, the 1990s were not a terribly good time for OS research; sort of like The Very Long Night of Londo Mollari of the OS world. There was this minor problem of Microsoft "buying away" whatever serious OS researchers that they could...
Yes, the money that comes in from such will suck. It is a bit more likely that the old 6.x boxes get sent back to RHAT in exchange for new 7.x boxes.
The point really is that there are mechanisms already in place for coping with returns, and a fair bit of control is in the hands of retailers, at least those that buy in bulk.
If BestBuy knows that RHAT does a release roughly every five or six months, but winds up over-ordering based on estimating sales badly, I'm not sure why this ought to be considered the fault of RHAT. The dummies are in BestBuy's purchasing department...
NeXTStep was based on an early version of Mach, back before Mach was a "seriously distributed system." It parallels Digital's OSF/1 aka "Digital Unix," which also was implemented atop "early Mach."
Both NeXTStep and Digital Unix were monolithic OSes, despite the association with Mach.
What you may be thinking of is that NeXTStep included a "distributed objects" scheme, lately being "cloned" as GDO (GNU Distributed Objects).
I certainly agree that there can be some significant irritations come out of having releases come so often.
It is nonetheless not at all obvious that this winds up causing an actual problem.
After all, if a new version comes out every 6 months, that means that CompUSA and BestBuy have the opportunity to have regular displays that say: New! Improved! Buy now!
I would certainly agree that this results in there being some obsolete RHAT boxes out there that may become virtually unsalable. That does not forcibly represent a problem; computer stores have already needed to be able to cope with "best before" dates, and dealing with products that have to head to the Bargain Bin.
Thus, for Red Hat Linux releases to exercise the "Bargain Bin" does not forcibly represent a problem for retail marketing.
Should encryption support be pervasive inside applications?
I would consider that approach less than safe; it is vulnerable to someone deciding that they need to write Yet Another Config File, or otherwise writing out a message in plain text form, thus destroying the would-be security. That's a mere fd = fopen("./tmpmsg", rw); away.
Furthermore, this does absolutely nothing about securing your AbiWord documents unless the developers thereof go through a separate process of building APIs that integrate in PGP or GPG. Ditto for Gnumeric, and GNote, and Dia, and GnuCash, and, and,...
It is quite possible that making your system secure will require doing some things to all of these applications, at some point.
But it seems to me that it is a wiser move to use encryption at the filesystem level, so that once you log out, access goes away, and where protection is pervasive.
Right now, the libraries you list are somewhat in flux. ORBit probably less so, but the others are pretty much "works in progress."
If they were "more integrated," then what you would actually have to do is not to "get the latest versions of these libs," but instead "get the latest version of MondoGNOMElib (version 2000.07.28) " which would involve compiling the same, entire set of code.
By not integrating the libraries, this allows them to "evolve" independently towards stability.
Thus, if GConf gets stable pretty quickly, then it can do so, the version numbers can stop changing, and you get at least one component that is visibly stable.
In contrast, by "integrating" them all together, the whole thing becomes a jumble of instability, and you can't tell which pieces are stable and which aren't, because all you know is that the program demanded that you install MondoGNOMElib version 2001.04.01
KDE is not terribly much cleaner; with the "not quite stable ABI" of G++, you're left with potentially needing to recompile the whole tool chain any time either:
G++ gets bumped a version level;
libg++ changes versions;
libstdc++ changes versions;
STL changes version;
Qt changes versions;
libkde changes versions.
There is potential that GCC 3.0 will resolve some of this by providing some additional promises as to the ABI interoperability, but that's not there yet.
You'd then decide on a directory in which to store the encrypted data. Let's say /home/cbbrowne/Mail/
Turn it into a CFS directory, via cmkdir/home/cbbrowne/Mail .
You'll be asked to make up a password.
Then, mount it, via cattach/home/cbbrowne/Mail Mail
Use the password you made up.
This mounts the directory on /crypt/Mail If you look in /crypt/Mail, you'll see plain text. If you look in /home/cbbrowne/Mail, you'll see gibberish.
Modify your mailer to use /crypt/Mail as the place to store data rather than/home/cbbrowne/somewhere
This methodology is not entirely flawless; /crypt/Mail is generally accessable to anyone on your host. Some time in the future, Linux may offer Plan 9 style namespaces that would allow mounts to be local to a process, so that the cattach would be local to the process and its children.
But the overall result is that by having the encryption take place in the separate layer, the mail client doesn't need to have a "security layer," you don't need to debug it, and you don't need to worry about it getting breached.
The nearest equivalent to the FBI ... is the RCMP - Royal Canadian Mounted Police. The RCMP also provides the services provided in the US by the Treasury Police, including dealing with "crimes about currency," and the protection of heads of state and diplomatic persons.
There was a scandal where RCMP "spooks" burned a barn where purportedly nefarious people were planning ill; the "public" view was that this made the RCMP look bad, and so the RCMP wanted no more to do with the "spooky" activities. When they're the "secret service," who can really be sure???. The public face on this was thus:
The establishment of the civilian Canadian Security Intelligence Service and the disbanding of the Royal Canadian Mounted Police Security Service by an Act of Parliament in 1984 recognized the differences between security intelligence activities and law enforcement work. The 120-year old interlocking of Canada's security intelligence service with the federal police force was brought to a close.
They are a mixed civilian/military group largely devoted to "signals analysis," and include pretty much the same functions associated with the NSA, notably not including having their own chip foundries. (Unless there's one hiding somewhere in Labrador!)
Notable "listening" sites include Gander (a formerly notable airport), Alert (the most northerly inhabited place in the world), Masset, and Kingston. My father used to work next door to CSE headquarters, the Sir Leonard Tilley Building.
It is certainly well and good that the "plumbing down below the GUI" looks like BSD, as that represents a well-understood and well-regarded set of "plumbing." That means that you get easy ports of "server side" stuff like Apache, PostgreSQL, Perl, Python, and such.
But with Apple having had some difficulty deciding what their GUI strategy would become, it's going to be a bit problematic to just plain choose a GUI. Do you go with:
Yellow Box?
Oops. No longer available.
OpenSTEP?
Oops. No longer available.
Aqua?
Quartz?
Carbon?
Cocoa?
The really critical thing about all of these options are that none of them, save, perhaps for OpenSTEP, via GNUstep , has any ability to run on any of the existing Unix-like systems.
In effect, in order to use existing Unix apps in GUIed manner on MacOS-X, you need to create a GUI from scratch and layer that on top somehow.
That may be nicely supportive of "web-oriented" applications; I'm sure WebObjects will work nicely on OS-X, as will the sysadmin tool WebMin, and so long as you've got a good web browser, that can provide a way of doing a bunch of useful things.
But that does not provide you with a port of the latest Sid Meier game, nor does it provide a way of running the latest SAP GUI.
The usual assumption is, in the area of cryptography, that using an obscure cipher probably means that it will be fundamentally weak, and that it is preferable to "flow with the herd" and use Blowfish, Triple DES, or whatever flows out of the AES effort.
His article Cryptography: Is Staying with the Herd Really Best? questions that; his view is that there should be a framework for there to be a rich set of ciphers in use, and that systems should readily, and dynamically, be able to shift to new ones should an older one be broken.
There are, widely stroking with the brush, two major approaches to security:
Create "heavily armoured elephants," with comprehensive, well-understood sets of defenses.
It is fairly well guaranteed that the armour will prove challenging to would-be attackers, whether we're talking about a crypto system, or a B1-certified version of Unix.
Unfortunately, since such systems are big, heavy, and complex to assemble, if they do have weaknesses, they will prove extremely vulnerable to attack at that weak point.
The other approach might be described as a "herd of gazelles."
Gazelles are not heavily armoured; they depend on moving quickly to avoid capture by those that would eat them.
More importantly, they are "physically independent." If a lion is busy chasing one gazelle, he can't catch any of the others.
The history of major Internet security breaches demonstrates that putting all the eggs in one "pot" is dangerous:
The Morris "worm" only affected systems running Ultrix and SunOS
The Melissa "virus" affected only those running Microsoft apps
Ditto for ILOVEYOU
If people are running different systems, they will have different vulnerabilities, and so long as the systems do not broadcast the evidences of vulnerabilities, there is value in obscuring the vulnerabilities.
I can't get at the KDE site, which might mean that some ticked-off "GTK advocate" may have gotten irritated and decided to DOS them, or that many, many people are interested in this development.
Realistically, I don't think that making GTK themes somewhat usable with KDE is of vast and stupendous importance. (I don't think themes are of vast and stupendous importance, which is a huge piece of cause for that...)
However, the beginnings of interoperability are reason to feel encouraged. The more GNOME and KDE can use "each others' toys," the less that the rancour will be justifiable, and there has been a lot of rancour.
If they can "play well" with toys, that can lead to more and better things. Probably not to KDE deciding to adopt GTK, and change the preferred implementation language to C, but there you go...
The genius of the PalmComputing platform is not that it is "ultimate" in any way.
The Palm machines are designed around the exact opposite, namely being designed around a set of design compromises.
There is a limited set of buttons (7 in all)
There is a screen of limited size
Limited resolution
Limited set of colours
Limited amount of memory
Limited amount of CPU horsepower
NO "secondary storage."
Thus nothing resembling "disk," or "files."
This set of design constraints mean that rather than doing the "WinCE" thing of "trying to be Windows, with a somewhat smaller screen," PalmOS is completely different.
It encourages creating embedded applications that do fairly specific things, rather than creating "generic" applications like spreadsheets to do "generic" things.
While all of the above looks like criticism, particularly in light of the usual "GNU" thing of encouraging there to be no arbitrary limits, I would take the opposite tack. PalmOS has provided a case of relishing the limitations, and working with them rather than the approach of fighting against them.
The net result has been pretty successful. You can do a number of useful things with a Palm III, which make it worth having one.
I'm not sure that the Yopi has chosen its design compromises carefully enough to be able to be successful.
If all it provides is a faster address/calendar book than PalmComputing, it loses.
PalmComputing generally doesn't suffer from being too slow.
If it needs a barrel of additional hardware, like keyboards and such, to be made useful, it loses.
It needs to be useful without the extra stuff, unless it includes a keyboard by default.
If the "cool part" is merely that it runs Linux, it loses.
A few people will run it because of that, but I'm a Linux advocate and I wouldn't spend the money just because of that.
At present, the iPAQ 3600 may run Linux, but does so only if you have a desktop "terminal" to connect to it. It may ultimately become "useful on the road," but it's not there yet.
I just don't think Yopi has yet come up with a suitable set of compromises in order to become amazingly functional.
The point is not to more strongly entrench C or C++, it is to encourage the deployment of applications that won't merely Run Best on Red Hat Linux.
If you want to use Sather-based applications on multiple distributions, then the tasks are twofold:
Make sure that there are, ubiquitously-available, Sather RPMs or DEBs or whatever that will run on the various distributions.
Make sure that the secondary libraries (stuff like a "libncurses-sather" or "libgtk-sather") has some well-thought-out location to be, that can be compatible across distributions, as well as suitable packaging.
Make sure that there's actually someone still doing development work on Sather. (Last I heard, the sponsors at Berkley weren't working on it anymore.)
Oops. That's three things.
At any rate, the "killer apps" on Linux are largely written in C, and all this standard is doing is to recognize that. It is entertaining to note that the standard somewhat discourages the use of C++ in that the libraries still haven't "settled down."
If you want to start deploying "killer apps" written in OCAML (and there are some interesting OCAML apps! ), the requirements will parallel what the "LDPS" provides, albeit by changing "C" to "OCAML."
Feel free to write the OCAML Development Platform Specification. No one will stop you, and if it's good, and is worth doing some rework of packages for, this may be a very good thing.
I did an initial interview with CSE for a job shortly after grad school; pretty entertaining levels of physical security in their buildings.
I later discovered why it was a very good thing that I didn't pursue the position; it would be reasonably likely that there would be, at some point, a six month assignment to the listening post at CFS Alert, the "most northern permanently inhabited settlement in the world." As of 26 November 1992, the Special Service Medal is awarded to personnel who have completed 180 days of honourable service at the station.
Alert is so far north that it cannot communicate with geosynchronous satellites. Way, way, way, way, north...
The "G4 Cube" will obviously sell well because it's a cube. (Which begs the question of why the NeXT Cube didn't sell as well...)
It is so sad to see Apple pushing so much of its marketing energies into hawking, as "innovations," what amount to pretty case designs, when they have gone and eliminated truly innovative things like:
I'm moving on Monday, and the slipstick already got packed for the move.
Not that it would have been any value in the reconciliation; slide rules generally are of no value in establishing anything about the order of magnitude, as that is the first thing you remove from the value before doing any multiplication.
If you're going to criticize about calculations, keep your errors straight...
Of course, the one incorrect number does nothing to establish that any of the other contentions are incorrect...
Right now, backing up using DVDs is excessively expensive. That is because the technology is brand-spanking new, and they are "spanking" you for being an early adopter.
In contrast, CD technology is a goodly dozen years old, and CD-Rs represent the "couple generations old" technology, which is now downright cheap. I can pick up 64GB of CD-R's for around $40, which makes for a price of about $0.06/GB. (Of course, that's the "premium quality!" CompUSA ones...)
Give writable DVD's another year or so, and the price is likely to drop precipitously.
I upgraded my Atari 400 to 32K of RAM, and had a hard time imagining how to use it all.
My Atari 400 had 32K of RAM, and a 120K disk drive
I now have more cache on my "obsolete" Pentium Pro CPU than that.
Anyone that suggests that X is bloated! when they're using a video card with 64MB of memory needs to be thrashed severely with a clue stick, as the wastage of 10-15MB of RAM, which is about all the bloat that is likely to be plausible with X, just disappears in the variances here...
Frankly, I'm a fair bit disappointed that there has not been much interest in GCC alternatives like TENDRA and lcc , as there is room for people to take some different approaches, learning some things from each other, thereby having better long term results than merely having one development stream.
I'm quite glad that GNOME and KDE and GNUstep are using different tools and languages to try to solve the "GUI problem," as they can find different aspects of the solutions thereof, and can be more aggressive in their experimentation as they do not risk "disaster for all" should they try something and fail.
And the above two points ignore the factor that despite their duplications of effort, they may all the same be avoiding larger multiples of duplication of effort. After all, in the MS-DOS world, there were literally dozens of spreadsheet and word processor packages, and it is really only out of quite rapacious behaviour on the part of Microsoft that package counts on Windows fell to more like a half-dozen. (MS Office, MS Works, Lotus Suite, Borland/WP Suite, with, likely, some others that few bother thinking about...)
Duplication of effort does diminish; there used to be about a dozen "Quicken Clone" projects, many of which have consolidated into working on GnuCash. There used to be two GCC projects, which have consolidated to one.
And see any of Joe Celko's books on SQL to see how weakly people tend to use what relational properties SQL has.
But as for calling SQL a "functional" language, while there may be some abtruse arguments by which some variation on it could be argued to be somewhat functional, it is certainly not recognized as such in the way that Haskell or ML are...
It appears that adding some additional hardware to Dreamcast to make it "more generally usable" may become possible. I gather that there may be USB support, which actually provides an actual "somewhat standardized" bus to work with.
Unfortunately, more hardware costs more money, so that the Dreamcast + NIC + more RAM (of some form) is liable to put the pricetag way past that of the rather similar Think NIC that already has the "more RAM" and the NIC.
Slashdot Mirror
The interesting part is that Legion provides tools that resemble some parts of CORBA, whilst Spring provided tools that grew into CORBA, whilst Sprite provided journalling and cache tools that are essentially what journalling and cache servers provide today.
In a sense, what has happened is that an OS of the 1970s, Unix, has been shown sufficiently malleable that it could integrate in concepts from the research projects of the 1970s and 1980s.
Unfortunately, the 1990s were not a terribly good time for OS research; sort of like The Very Long Night of Londo Mollari of the OS world. There was this minor problem of Microsoft "buying away" whatever serious OS researchers that they could...
The point really is that there are mechanisms already in place for coping with returns, and a fair bit of control is in the hands of retailers, at least those that buy in bulk.
If BestBuy knows that RHAT does a release roughly every five or six months, but winds up over-ordering based on estimating sales badly, I'm not sure why this ought to be considered the fault of RHAT. The dummies are in BestBuy's purchasing department...
Both NeXTStep and Digital Unix were monolithic OSes, despite the association with Mach.
What you may be thinking of is that NeXTStep included a "distributed objects" scheme, lately being "cloned" as GDO (GNU Distributed Objects).
Each has some somewhat different insights to bring to the table; there is no unambiguous way of saying "this is all vastly superior."
It is nonetheless not at all obvious that this winds up causing an actual problem.
After all, if a new version comes out every 6 months, that means that CompUSA and BestBuy have the opportunity to have regular displays that say: New! Improved! Buy now!
I would certainly agree that this results in there being some obsolete RHAT boxes out there that may become virtually unsalable. That does not forcibly represent a problem; computer stores have already needed to be able to cope with "best before" dates, and dealing with products that have to head to the Bargain Bin.
Thus, for Red Hat Linux releases to exercise the "Bargain Bin" does not forcibly represent a problem for retail marketing.
I would consider that approach less than safe; it is vulnerable to someone deciding that they need to write Yet Another Config File, or otherwise writing out a message in plain text form, thus destroying the would-be security. That's a mere fd = fopen("./tmpmsg", rw); away.
Furthermore, this does absolutely nothing about securing your AbiWord documents unless the developers thereof go through a separate process of building APIs that integrate in PGP or GPG. Ditto for Gnumeric, and GNote, and Dia, and GnuCash, and, and, ...
It is quite possible that making your system secure will require doing some things to all of these applications, at some point.
But it seems to me that it is a wiser move to use encryption at the filesystem level, so that once you log out, access goes away, and where protection is pervasive.
If they were "more integrated," then what you would actually have to do is not to "get the latest versions of these libs," but instead "get the latest version of MondoGNOMElib (version 2000.07.28) " which would involve compiling the same, entire set of code.
By not integrating the libraries, this allows them to "evolve" independently towards stability.
Thus, if GConf gets stable pretty quickly, then it can do so, the version numbers can stop changing, and you get at least one component that is visibly stable.
In contrast, by "integrating" them all together, the whole thing becomes a jumble of instability, and you can't tell which pieces are stable and which aren't, because all you know is that the program demanded that you install MondoGNOMElib version 2001.04.01
KDE is not terribly much cleaner; with the "not quite stable ABI" of G++, you're left with potentially needing to recompile the whole tool chain any time either:
- G++ gets bumped a version level;
- libg++ changes versions;
- libstdc++ changes versions;
- STL changes version;
- Qt changes versions;
- libkde changes versions.
There is potential that GCC 3.0 will resolve some of this by providing some additional promises as to the ABI interoperability, but that's not there yet.Illustrating:
- Install CFS.
- You'd then decide on a directory in which to store the encrypted data. Let's say
/home/cbbrowne/Mail/ - Turn it into a CFS directory, via cmkdir
/home/cbbrowne/Mail . - Then, mount it, via cattach
/home/cbbrowne/Mail Mail - Modify your mailer to use
/crypt/Mail as the place to store data rather than /home/cbbrowne/somewhere
This methodology is not entirely flawless;You'll be asked to make up a password.
Use the password you made up.
This mounts the directory on /crypt/Mail If you look in /crypt/Mail, you'll see plain text. If you look in /home/cbbrowne/Mail, you'll see gibberish.
But the overall result is that by having the encryption take place in the separate layer, the mail client doesn't need to have a "security layer," you don't need to debug it, and you don't need to worry about it getting breached.
There was a scandal where RCMP "spooks" burned a barn where purportedly nefarious people were planning ill; the "public" view was that this made the RCMP look bad, and so the RCMP wanted no more to do with the "spooky" activities. When they're the "secret service," who can really be sure???. The public face on this was thus:
See also the CSE Unofficial Web Page, which has a rather interesting discussion of the organization.
They are a mixed civilian/military group largely devoted to "signals analysis," and include pretty much the same functions associated with the NSA, notably not including having their own chip foundries. (Unless there's one hiding somewhere in Labrador!)
Notable "listening" sites include Gander (a formerly notable airport), Alert (the most northerly inhabited place in the world), Masset, and Kingston. My father used to work next door to CSE headquarters, the Sir Leonard Tilley Building.
It is certainly well and good that the "plumbing down below the GUI" looks like BSD, as that represents a well-understood and well-regarded set of "plumbing." That means that you get easy ports of "server side" stuff like Apache, PostgreSQL, Perl, Python, and such.
But with Apple having had some difficulty deciding what their GUI strategy would become, it's going to be a bit problematic to just plain choose a GUI. Do you go with:
Oops. No longer available.
Oops. No longer available.
The really critical thing about all of these options are that none of them, save, perhaps for OpenSTEP, via GNUstep , has any ability to run on any of the existing Unix-like systems.
In effect, in order to use existing Unix apps in GUIed manner on MacOS-X, you need to create a GUI from scratch and layer that on top somehow.
That may be nicely supportive of "web-oriented" applications; I'm sure WebObjects will work nicely on OS-X, as will the sysadmin tool WebMin, and so long as you've got a good web browser, that can provide a way of doing a bunch of useful things.
But that does not provide you with a port of the latest Sid Meier game, nor does it provide a way of running the latest SAP GUI.
That may not have been true for the MIPS release, but the Ultrix at the time was BSD 4.x, I think 4.2...
Another view is taken by Terry Ritter, of Ciphers By Ritter.
His article Cryptography: Is Staying with the Herd Really Best? questions that; his view is that there should be a framework for there to be a rich set of ciphers in use, and that systems should readily, and dynamically, be able to shift to new ones should an older one be broken.
There are, widely stroking with the brush, two major approaches to security:
It is fairly well guaranteed that the armour will prove challenging to would-be attackers, whether we're talking about a crypto system, or a B1-certified version of Unix.
Unfortunately, since such systems are big, heavy, and complex to assemble, if they do have weaknesses, they will prove extremely vulnerable to attack at that weak point.
Gazelles are not heavily armoured; they depend on moving quickly to avoid capture by those that would eat them.
More importantly, they are "physically independent." If a lion is busy chasing one gazelle, he can't catch any of the others.
The history of major Internet security breaches demonstrates that putting all the eggs in one "pot" is dangerous:
- The Morris "worm" only affected systems running Ultrix and SunOS
- The Melissa "virus" affected only those running Microsoft apps
- Ditto for ILOVEYOU
If people are running different systems, they will have different vulnerabilities, and so long as the systems do not broadcast the evidences of vulnerabilities, there is value in obscuring the vulnerabilities.Realistically, I don't think that making GTK themes somewhat usable with KDE is of vast and stupendous importance. (I don't think themes are of vast and stupendous importance, which is a huge piece of cause for that...)
However, the beginnings of interoperability are reason to feel encouraged. The more GNOME and KDE can use "each others' toys," the less that the rancour will be justifiable, and there has been a lot of rancour.
If they can "play well" with toys, that can lead to more and better things. Probably not to KDE deciding to adopt GTK, and change the preferred implementation language to C, but there you go...
The Palm machines are designed around the exact opposite, namely being designed around a set of design compromises.
Thus nothing resembling "disk," or "files."
This set of design constraints mean that rather than doing the "WinCE" thing of "trying to be Windows, with a somewhat smaller screen," PalmOS is completely different.
It encourages creating embedded applications that do fairly specific things, rather than creating "generic" applications like spreadsheets to do "generic" things.
While all of the above looks like criticism, particularly in light of the usual "GNU" thing of encouraging there to be no arbitrary limits, I would take the opposite tack. PalmOS has provided a case of relishing the limitations, and working with them rather than the approach of fighting against them.
The net result has been pretty successful. You can do a number of useful things with a Palm III, which make it worth having one.
I'm not sure that the Yopi has chosen its design compromises carefully enough to be able to be successful.
PalmComputing generally doesn't suffer from being too slow.
It needs to be useful without the extra stuff, unless it includes a keyboard by default.
A few people will run it because of that, but I'm a Linux advocate and I wouldn't spend the money just because of that.
At present, the iPAQ 3600 may run Linux, but does so only if you have a desktop "terminal" to connect to it. It may ultimately become "useful on the road," but it's not there yet.
I just don't think Yopi has yet come up with a suitable set of compromises in order to become amazingly functional.
If you want to use Sather-based applications on multiple distributions, then the tasks are twofold:
- Make sure that there are, ubiquitously-available, Sather RPMs or DEBs or whatever that will run on the various distributions.
- Make sure that the secondary libraries (stuff like a "libncurses-sather" or "libgtk-sather") has some well-thought-out location to be, that can be compatible across distributions, as well as suitable packaging.
- Make sure that there's actually someone still doing development work on Sather. (Last I heard, the sponsors at Berkley weren't working on it anymore.)
At any rate, the "killer apps" on Linux are largely written in C, and all this standard is doing is to recognize that. It is entertaining to note that the standard somewhat discourages the use of C++ in that the libraries still haven't "settled down."Oops. That's three things.
If you want to start deploying "killer apps" written in OCAML (and there are some interesting OCAML apps! ), the requirements will parallel what the "LDPS" provides, albeit by changing "C" to "OCAML."
Feel free to write the OCAML Development Platform Specification. No one will stop you, and if it's good, and is worth doing some rework of packages for, this may be a very good thing.
I later discovered why it was a very good thing that I didn't pursue the position; it would be reasonably likely that there would be, at some point, a six month assignment to the listening post at CFS Alert, the "most northern permanently inhabited settlement in the world." As of 26 November 1992, the Special Service Medal is awarded to personnel who have completed 180 days of honourable service at the station.
Alert is so far north that it cannot communicate with geosynchronous satellites. Way, way, way, way, north...
The " Doneness" listing indicates that virtually all of the commands are done, and the last date that something was updated was in June 1999.
It may well be effectively complete. I don't think PPT has taken the world by storm, though...
It is so sad to see Apple pushing so much of its marketing energies into hawking, as "innovations," what amount to pretty case designs, when they have gone and eliminated truly innovative things like:
A "kinder, gentler" version of Lisp
A really powerful PDA
Not that it would have been any value in the reconciliation; slide rules generally are of no value in establishing anything about the order of magnitude, as that is the first thing you remove from the value before doing any multiplication.
If you're going to criticize about calculations, keep your errors straight...
Of course, the one incorrect number does nothing to establish that any of the other contentions are incorrect...
In contrast, CD technology is a goodly dozen years old, and CD-Rs represent the "couple generations old" technology, which is now downright cheap. I can pick up 64GB of CD-R's for around $40, which makes for a price of about $0.06/GB. (Of course, that's the "premium quality!" CompUSA ones...)
Give writable DVD's another year or so, and the price is likely to drop precipitously.
I now have more cache on my "obsolete" Pentium Pro CPU than that.
Anyone that suggests that X is bloated! when they're using a video card with 64MB of memory needs to be thrashed severely with a clue stick, as the wastage of 10-15MB of RAM, which is about all the bloat that is likely to be plausible with X, just disappears in the variances here...
I'm quite glad that GNOME and KDE and GNUstep are using different tools and languages to try to solve the "GUI problem," as they can find different aspects of the solutions thereof, and can be more aggressive in their experimentation as they do not risk "disaster for all" should they try something and fail.
And the above two points ignore the factor that despite their duplications of effort, they may all the same be avoiding larger multiples of duplication of effort. After all, in the MS-DOS world, there were literally dozens of spreadsheet and word processor packages, and it is really only out of quite rapacious behaviour on the part of Microsoft that package counts on Windows fell to more like a half-dozen. (MS Office, MS Works, Lotus Suite, Borland/WP Suite, with, likely, some others that few bother thinking about...)
Duplication of effort does diminish; there used to be about a dozen "Quicken Clone" projects, many of which have consolidated into working on GnuCash. There used to be two GCC projects, which have consolidated to one.
SQL is not even strongly relational; see Darwen and Date's Foundation for Object/Relational Databases: The Third Manifesto.
And see any of Joe Celko's books on SQL to see how weakly people tend to use what relational properties SQL has.
But as for calling SQL a "functional" language, while there may be some abtruse arguments by which some variation on it could be argued to be somewhat functional, it is certainly not recognized as such in the way that Haskell or ML are...
Unfortunately, more hardware costs more money, so that the Dreamcast + NIC + more RAM (of some form) is liable to put the pricetag way past that of the rather similar Think NIC that already has the "more RAM" and the NIC.