First of all, as mentioned elsewhere, you should use the public key encryption only to send the key for a symmetric (shared key) encryption algorithm, which works much faster (since it doesn't need to operate upon "bignums" in a very large prime field).
Secondly, once you share the key, you can either use a stream cipher, or you can use a block cipher. Using a stream cipher would be fairly easy in a streaming environment. If you wish to instead use a well-proven block cipher such as 3DES or Blowfish/Twofish, what you will want to do is packetize your input data, prepend it with a length byte (to tell how many bytes are in the encrypted block -- fill out the remaining empty bytes in a block with random noise to confuse attackers), and then send the result. This is similar to the way the network code itself packetizes data, by prepending data packets with a header that, amongst other things, tells how long the attached data block is.
A streaming public key encryption algorithm is possible, but of little use. The above is a fast, elegant way to handle situations that at casual glance would require streaming public key encryption, and those techniques are used by every product I'm aware of that appears to do "streaming public key encryption".
Most Linux compiles of 'ssh' have for years defaulted to the Blowfish encryption method rather than the patented IDEA encryption method that was removed from OpenSSH. If you wish to connect to a 'ssh1' server from an OpenSSH client, it will automatically adjust to use BlowFish. If you wish to connect from a 'ssh1' client that was not compiled to default to Blowfish, you MAY need to pass it an option to tell it to go to 'Blowfish' rather than IDEA.
One thing I'd like to do is remove the RSA encryption entirely from SSH and replace it with a non-patent-encumbered method of doing the public key authentication. RSA really isn't necessary anymore, there are now patent-unencumbered methods for doing public key session key exchanges and public key digest authentication without use of the RSA patented algorithm. My understanding is that RSA was kept in OpenSSH because it's necessary in order to maintain backward compatibility.
So yes, backward compatibility should be maintained by OpenSSH, unless something seriously stupid was done. I'm about to go test that theory personally:-).
I think the AES competition (www.nist.gov/aes), a competition for the replacement of DES by the U.S. government, should finally put a end to the lie that the U.S. has some kind of monopoly on encryption. A full 40% of the finalists were foreign in origin, despite a selection process that was biased for American solutions.
Similarly, while MIT/RSADI hold the U.S. patent on the RSA public key encryption method used in SSH, most modern cryptographers believe that RSA public key encrpytion is obsolete. Most of the work on its proposed replacement, elliptic curve cryptography, is being done in Britain and Canada (in fact, the biggest vendor of elliptic curve cryptography is Canadian).
Don't get me wrong, the U.S. still has many great cryptographers. Bruce Schneier, Ron Rivest, the list goes on. But I seriously doubt that the U.S. still does the majority of public cryptographic research. If you don't believe me, go browse the cryptographic links section on my home page.
As a commercial software developer I have no problem with buying a QT license for a measly 2K or so per programmer. A good programmer costs at least $60K/year in pay and benefits even in low-rent places like Houston or Phoenix, so we're talking less than 4% of a programmer's salary for the year -- and it's a one-time cost. Does it make a programmer 4% more productive? I daresay YES, if you are developing C++ applications, QT is a beautiful thing.
Ongoing royalties are what kills me as a software developer. I don't want to have to send 2% of my revenue stream to every #%%@ vendor library that's linked into my code. All those percents adds up too quickly, and they're all volume-oriented so I have to tell them "I'm going to sell 50,000 copies so you charge me the 1.5% instead of the 2% rate for 20,000 copies". The problem there of course is how the hell do I know how many copies I'm going to sell?! This is the computer business, folks! Great programs fail to sell all the time because the projected market for it dried up and moved on to other things, or because the market isn't there yet... per-copy volume based royalties are the utter PITS.
Remember, if you're an independent developer writing programs with QT, you can still develop the program with the QPL version. It's just when you actually sell it (get some money for it!) that you must send your $2k to the Trolls. If you can't make $2k off of a piece of software, you shouldn't be trying to release it as "shareware" anyhow, you should just GPL it and toss it onto the pile of Open Source code that already exists!
I find KDE 1.1 to be quite snappy even on slow computers like a Cyrix 150mhz. However, KDE 1.0 was quite sluggish when that old Cyrix had only 32 megabytes of RAM, but upgrading to 64 megabytes made it run quite well indeed, thank you.
I've come to the conclusion that all desktop environments are memory hogs, whether they're KDE, GNOME, or Windows 98:-(. If you have a low-memory machine, you're much better off sticking with something like fvwm or blackbox that doesn't use much RAM.
The legal profession standardized on WordPerfect long ago, and never bothered re-standardizing on MS Word when the rest of the world moved away from WordPerfect. Thus it is VERY unlikely that his law clerk typed up the decision using MS Word.
That must be why Microsoft Windows out-sells Linux by a factor of 10 to 1, eh? Nothing to do with bully tactics by a huge monolithic corporation with deep pockets but bug-riddled product line, eh?
Face facts: It is rarely the company with the best product who wins. Rather, it is the company that is most ruthless in destroying its competitors who wins. This is similar to the way that CocaCola Co. and Pepsico collude to buy up all the supermarket shelf space allocated for soft drinks in order to keep competing products from getting a toe-hold, or the way that General Motors bought out all the electric trolley companies so that they could discontinue service and replace the electric trollies with GM's smelly ugly smoke-belching buses. With the approval of the government. Face it, we have the best government that large multi-national corporations can buy. Too bad the only politician running for President who's willing to say so is John McCain, who stands a bat's chance in Hell of getting elected.
My predecessor at Executive Consultants implemented Y2K windowing in the PAMS educational administration system -- in *1988*!!!! (Because we designed to carry kindergarten records all the way through 12th grade, one field in the grade transcripts file header was "proposed graduation date", and, WHOOPS, Y2K oops in 1988 when you gave a proposed graduation date 12 years in the future to a 12th grader!).
Of course, our window was, "00-50 = 2000-2050", while "51-99=1951 to 1999", since hopefully our students were not born prior to 1950! (Hmm, a 50 year old 12th grader? It could happen, I guess!). And now the program will automagically convert two-digit dates "on the fly" to 4-digit dates using those windowing rules so that we can do date math and date display in a consistent manner (the database actually had 4 digits for dates, but screen displays only had 2 digits and it was pretending that we were in year 00 through 99... had to find every @#$%@ date in close to a MILLION LINES OF CODE and half the bloody dates weren't even marked as date types, they were strings that were being sliced and diced to do various funky date calculations for, e.g., attendance!). I got my subsystems Y2K ready, then left before they could press me into service fixing other people's subsystems (grin). (Well, Y2K was definitely one reason I left, but the main reason was professional advancement... please don't take flippant statements too seriously).
Anyhow, the point is: this patent is bullshit. We did it in 1988, and I'm sure we're not alone. The 20-year-mortgage people surely did it for their computerized mortgage records as early as 1979 for much the same as we did for our 12-year-matriculation problem. Heck, 30 year mortgages in 1969 probably used windowing!
Dr. Brian Gladman has already independently implemented each of the AES candidates. Their source code is available on his web site at www.seven77.demon.co.uk (yep, United Kingdom, i.e., not U.S.).
The idiocy about U.S. export restrictions is that I cannot give Dr. Gladman a copy of a program whose only cryptographic component is Dr. Gladman's own code. See the bottom of my Ocotillo page at http://www.estinc.com/~eric for more details.
The NIST appears to have opened themselves up to the possibility of having more than one algorithm under the AES umbrella. See their web site at http://www.nist.gov/aes for their current views. While still not saying that there WILL be more than one algorithm as part of the AES standard, they no longer make a blanket statement about "the" AES algorithm.
Previously the web site was pretty clear that AES was going to be a single algorithm. As Bruce notes, a family of algorithms might be more practical, though in the past NIST was not open to that suggestion.
I knew a few of the software developers who worked on AmigaOS (well, actually I work with the guy who wrote the AmigaOS SCSI driver and API for tape drives!). They say that the actual code base was actually fairly clean, as soon as they got rid of the BCPL cruft.
Remember, Commodore never had the thousands of engineers munging the code that Netscape had, and the OS was modular in the first place (with the exception of the graphics system, which would need to be totally re-written a'la' Mozilla), which made it much easier to keep things clean.
Of course, it got crufted a bit at the end, as Commodore died, but so it goes. There wasn't enough engineers left at Commodore by that time to do TOO much damage to it...
Actually, the hardest problem with AmigaOS nowdays would be compiling it. It was written in pre-ANSI-C days, and I suspect that modern compilers would choke on it:-(.
The Amiga GUI and WorkBench probably would need to be totally re-written to operate in today's environment, but the core OS itself was fairly well written (after they dumped the BCPL cruft!). Device driver writing is still easier under AmigaDOS than under Linux, despite the fact that device drivers run as separate tasks under AmigaDOS rather than being in the kernel proper, and the core multi-tasking kernel still kicks rear on task switch time and inter-process communications ability. The filesystem plugin capability was also great, though few people took advantage of it (filesystems could be "plugged in" to the system quite easily by dropping them into a particular directory). And AREXX did in 1987 what Microsoft only started trying to do in 1997 -- i.e., made all user interfaces scriptable.
A derivative of AmigaOS would be great for tiny palmtops and etc that don't have MMU's. As a general purpose OS it's not so great nowdays due to lack of VM support, but being written for a non-MMU environment is actually an advantage when you're trying to make it run on some embedded processor that doesn't HAVE an MMU. Linux can be hacked to run in such environments, but not well. AmigaOS thrives in the non-MMU environment (well, as well as can be done in such an environment!), and its low resource usage means that you could get away with crappier hardware than with, say, WinCE (wince!).
The latest version of PostGreSQL has almost all of the stuff that you mention, except for online hot backups and HSM. It even has several languages other than Java that run inside the DB backend, such as TCL, Python, and Perl.
PostGreSQL's only problem nowdays is performance on huge databases. Well, replication is still a problem too, as is hot backups, but performance is the killer here. Oracle is proven at running huge databases, PostGreSQL is not. If I were thinking 40gb of data, I'd look harder at Oracle than at PostGreSQL.
SGI Iris and Solaris are excellent choices for jobs that have outgrown Linux. That's the beauty of Linux -- once you have outgrown Linux, you can move up to bigger computers. And with 40gb per year of data, we're talking 400gb within a few years.
I have personally fsck'ed a 40gb ext2 partition. It is *NOT* fun, it takes over 20 minutes even on the latest/fastest RAID subsystems! So it is indeed appropriate to question whether Linux is the proper solution for this problem. After all, this isn't Windows NT -- we don't have to say "Linux everywhere" to win (just "Windows NT nowhere", grin).
First: MySQL isn't even in the running here. It lacks transaction support, triggers, etc., by design. MySQL was designed for speed, not features.
PostGreSQL has the features he needs, and the latest version is very stable (as stable as Oracle). Its big problem: PERFORMANCE. While its performance is acceptable on a 2gb database, you can forget it on a 40gb database.
I would say that if he can afford Oracle, to go Oracle. Oracle is proven in large-database environments. Informix, SyBase, and Adabas-D would also be good choices. If he's interested in more obscure databases, Empress has a nice 4GL. SolidTech's stuff looks pretty good too.
Doing a search for "linux database" is instructive....
By default, Mandrake installs the 'colorgcc' package. This colourizes the output of 'gcc' to make it "understandable". Unfortunately, it makes it totally INCOMPREHENSIBLE to Xemacs and other similar development tools that rely on parsing 'gcc' output in order to do things like, e.g., take you directly to the file and line of code that has the problem.
I find the default to the color 'ls' to be somewhat distracting because with the color scheme I use for "X", the yellow text on white background is virtually unreadable. I use a white background because it's easier on my eyes than the traditional white text on black background (yellow would be quite visible there). Point: color 'ls' is a Bad Idea on an "X"-oriented distro like Mandrake.
Plusses: I like some of the other choices. The 'klyx' included with Mandrake 6.1 works great. It includes 'eps' files just fine. The version of KDE is the latest, and works fairly well except for a disturbing tendency for 'kfm' to lose its configuration (and lose its mind, i.e., refuse to start at all). The 'yp' functionality is bug-free -- I updated our NIS server (running Red Hat 6.0) with the 'ypserv' and 'yppasswd' packages from Mandrake 6.1, and it fixed all the annoying glitches that I'd been working around for months. In general, it's a well-debugged and easy-to-use version of Linux, and aside from having to change my makefiles to directly call 'pgcc' rather than 'gcc' ('gcc' gets 'colorgcc'), it's been surprisingly annoyance-free.
And it includes XEmacs too, unlike RHL. I did mention that, right?
I've known (of) Evan for the past three years. He's a long-time Canadian fan of Linux, done a lot of user group work, big pusher of Linux in business, etc., as well as being a journalist (I remember seeing him with a big PRESS badge at Linux Expo a couple of years ago, back when you could fit Linux Expo into the student union at Duke).
Of course, since he's not a superior techno-geek, Slashdotters will diss him. But folks like Evan, and like MacMillan, are just as important to the success of Linux as the uber-geeks who actually produce the technology. What's the use of great technology, if you can't come out of the closet? Aren't we tired of Linux being the gay stepchild of operating systems?!
Each student in the Lincoln Parish Schools is assigned a 7-digit Student Identification Number by the district. This number is carried in their student information systems and is the only number printed on student rosters and other such reports printed by the system. The SSN is also present in the system (as the State Identification Number), but is not printed on report cards or any other reports.
Apparently the reason they used the SSN is because their lunch system (provided by a company named Bon Appetite) only had SSN's in it (the SSN is required by the Feds because the Feds match it against their food stamp rolls so they can catch people fraudulently receiving free lunches). I don't know whether the lunch ladies were just too lazy to punch in 7-digit account numbers for the students, or whether the Bon Appetite software just isn't flexible enough to accept the 7-digit numbers in addition to the SSN numbers already there. Note that the principal does not have control over the lunch ladies (their direct supervisor is the Food Services supervisor at the central office), so the SSN may have been chosen as the path of least resistence. I suspect, however, that next year the SIDNO is going to be on those cards, not the SSN!
Heheh! The only problem is that the lunch ladies generally do glance at the screen when they scan the ID, due to the fact that those bar code scanners aren't perfect. I think they'll notice that you're not Dr. Charles Scribner (grin).
The real stupidity is that they're using SSN's as the lunch account ID in the first place. The SSN has to be in the lunch system because the Feds use it to match against the food stamp database (that's how they detect fraud in the free lunch program), but I'm pretty sure that Bon Appetite (their school lunch system) has an "account number" feature that would allow you to use some other number (like the 7-digit district-assigned Student Identification Number used by their student information systems). But maybe their lunch ladies were too lazy to punch that info into the lunch computer:-( (Or maybe I'm overestimating the flexibity of Bon Appetite).
you're an idiot if you think that Columbine caused them to issue these badges. It didn't.
Ruston High School sits beside Louisiana Tech University. Half the students are very bright children of college professors. The other half are from one of the most depressed areas in Louisiana, which in turn is one of the poorest states in the US.
Ruston High has had persistent gang and drug problems in recent years, but has been reluctant to admit these problems because they're afraid of those professors and their political connections. In particular, they have had problems with former students expelled for drugs, weapons, or gang violence coming back on campus to recruit, sell drugs, or just engage in gang rumbles in the hallways.
The purpose of the ID badges is so that these hoodlums cannot as easily pose as students (since presumably their badges were yanked when they were expelled). Columbine is a generic excuse that the school is using so that they don't have to admit that they have a drug and gang problem.
All of this is my opinion, of course, but probably an informed one. (See other postings of mine in this thread for exactly why I say that).
There do exist provisions both in the administrative computer systems used by the Lincoln Parish School Board and in state and district policies for the issuing of alternative numbers for those who do not wish their SSN to be recorded. I was on the far end of many technical support calls from school secretaries asking how to do that back when I was working for a consulting company that specialized in school administration systems (I am actually the person who installed their current school administration system at Ruston High).
Somebody else posted the federal law. The federal law says that schools can ask, but if they receive federal money they have to provide services whether you provide the SSN or not. Refuse to give the SSN, and the school has to provide an alternative. They hate to do so, because they have to call the district office to get a number off the list that the state sent to the district, and also because too many "9" numbers can cause a state audit (the state thinking you're enrolling a bunch of "ghost students" to get extra money from the state and that corrupt officials are pocketing the money). But they can do it.
a,b) The ID number was for the use of the school lunch and library computers. Unfortunately, they used the WRONG ID number for that -- there is a 7-digit district-assigned number in their administrative computer that they could have used (I've explained in other postings how this number is created, it has no relationship to the SSN), but apparently the lunch system was problematic about using that so they took the path of least resistance.
c) Re: advertising for pepsi: Note that this is something that a local bottler did, i.e., donated the badges to the school as a tax write-off. It's unclear whether he gave them excess pre-printed badges that he already had in stock, or actually had some printed up with the Pepsi logo. It's also likely that he did not have the slightest idea what the school was going to do with the badges. I wouldn't hassle PepsiCo about this, they're as much a victim as the students, the poor bottler probably thought the badges were going to be used for prom night or something.
The school approached the local Pepsi bottler asking for a donation of the badge holders, and telling him he could put his logo on them. The poor guy probably never knew what the school was going to do with them, but donated the blasted things out of a sense of civic responsibility. (Yes, they still use words like "civic responsibility" up in North Lousiana!).
It's unfair to blast PepsiCo (the company) for what a local bottler did. It's probably even unfair to blast that local bottler, since he probably thought he was doing a favor for the school by giving them some of his excess badge holders.
It is not illegal. The school is allowed by federal law to ask for the SSN. You are allowed to refuse to give them the SSN, at which point they still must enroll you, but you will be assigned a "State Identification Number" starting with '9'.
It is important to note that there is a 7-digit district-assigned "Student Identification Number" for each student in their student information system that is totally unrelated to the SSN. They had to have done a special query from the system to even get a list of students with their social security numbers. I was one of the programmers who wrote the student information system used at Ruston High School (while working for a consulting firm), and we did that on purpose, at district request -- none of the standard roster reports will list social security numbers, they will only list "SIDNO" (the 7-digit student identification number).
The social security number (or 9-digit '9' number) is used for two things: 1) the state computer system uses it as the student's "State Student Identification Number", so that they can track students and detect fraud (like 'ghost students'), and 2) the federal school lunch program uses it to match the student body against the food stamp rolls in order to detect students eligible who are not receiving services, and vice-versa (i.e., to detect fraud). It most certainly does NOT need to be on a student badge -- the 7-digit district-assigned number would suffice just fine for anything except the school lunch computer (which, alas, would require a little custom programming -- there is a second 9-digit field that could be adapted, but they would probably have needed to pay Bon Appetite a few bucks to make their card scanner use that rather than the SSN field).
The purpose is to keep expelled gang members from coming back on campus and recruiting for their gangs, having gang rumbles in the hallways, and selling drugs in the bathrooms. Columbine is just a convenient excuse so that they don't have to admit that their school has a drug and gang problem.
No placard? Easy for security guard to detect! That's the point. Students weren't carrying their student ID's because nobody ever checked them, making it hard to tell the difference between a kid expelled for drugs and a kid who forgot his ID at home... but if the student ID is around their neck...
Slashdot Mirror
Secondly, once you share the key, you can either use a stream cipher, or you can use a block cipher. Using a stream cipher would be fairly easy in a streaming environment. If you wish to instead use a well-proven block cipher such as 3DES or Blowfish/Twofish, what you will want to do is packetize your input data, prepend it with a length byte (to tell how many bytes are in the encrypted block -- fill out the remaining empty bytes in a block with random noise to confuse attackers), and then send the result. This is similar to the way the network code itself packetizes data, by prepending data packets with a header that, amongst other things, tells how long the attached data block is.
A streaming public key encryption algorithm is possible, but of little use. The above is a fast, elegant way to handle situations that at casual glance would require streaming public key encryption, and those techniques are used by every product I'm aware of that appears to do "streaming public key encryption".
-E
One thing I'd like to do is remove the RSA encryption entirely from SSH and replace it with a non-patent-encumbered method of doing the public key authentication. RSA really isn't necessary anymore, there are now patent-unencumbered methods for doing public key session key exchanges and public key digest authentication without use of the RSA patented algorithm. My understanding is that RSA was kept in OpenSSH because it's necessary in order to maintain backward compatibility.
So yes, backward compatibility should be maintained by OpenSSH, unless something seriously stupid was done. I'm about to go test that theory personally :-).
-E
I think the AES competition (www.nist.gov/aes), a competition for the replacement of DES by the U.S. government, should finally put a end to the lie that the U.S. has some kind of monopoly on encryption. A full 40% of the finalists were foreign in origin, despite a selection process that was biased for American solutions.
Similarly, while MIT/RSADI hold the U.S. patent on the RSA public key encryption method used in SSH, most modern cryptographers believe that RSA public key encrpytion is obsolete. Most of the work on its proposed replacement, elliptic curve cryptography, is being done in Britain and Canada (in fact, the biggest vendor of elliptic curve cryptography is Canadian).
Don't get me wrong, the U.S. still has many great cryptographers. Bruce Schneier, Ron Rivest, the list goes on. But I seriously doubt that the U.S. still does the majority of public cryptographic research. If you don't believe me, go browse the cryptographic links section on my home page.
-E
Ongoing royalties are what kills me as a software developer. I don't want to have to send 2% of my revenue stream to every #%%@ vendor library that's linked into my code. All those percents adds up too quickly, and they're all volume-oriented so I have to tell them "I'm going to sell 50,000 copies so you charge me the 1.5% instead of the 2% rate for 20,000 copies". The problem there of course is how the hell do I know how many copies I'm going to sell?! This is the computer business, folks! Great programs fail to sell all the time because the projected market for it dried up and moved on to other things, or because the market isn't there yet... per-copy volume based royalties are the utter PITS.
Remember, if you're an independent developer writing programs with QT, you can still develop the program with the QPL version. It's just when you actually sell it (get some money for it!) that you must send your $2k to the Trolls. If you can't make $2k off of a piece of software, you shouldn't be trying to release it as "shareware" anyhow, you should just GPL it and toss it onto the pile of Open Source code that already exists!
-E
I've come to the conclusion that all desktop environments are memory hogs, whether they're KDE, GNOME, or Windows 98 :-(. If you have a low-memory machine, you're much better off sticking with something like fvwm or blackbox that doesn't use much RAM.
-E
-E
That must be why Microsoft Windows out-sells Linux by a factor of 10 to 1, eh? Nothing to do with bully tactics by a huge monolithic corporation with deep pockets but bug-riddled product line, eh?
Face facts: It is rarely the company with the best product who wins. Rather, it is the company that is most ruthless in destroying its competitors who wins. This is similar to the way that CocaCola Co. and Pepsico collude to buy up all the supermarket shelf space allocated for soft drinks in order to keep competing products from getting a toe-hold, or the way that General Motors bought out all the electric trolley companies so that they could discontinue service and replace the electric trollies with GM's smelly ugly smoke-belching buses. With the approval of the government. Face it, we have the best government that large multi-national corporations can buy. Too bad the only politician running for President who's willing to say so is John McCain, who stands a bat's chance in Hell of getting elected.
-E
My predecessor at Executive Consultants implemented Y2K windowing in the PAMS educational administration system -- in *1988*!!!! (Because we designed to carry kindergarten records all the way through 12th grade, one field in the grade transcripts file header was "proposed graduation date", and, WHOOPS, Y2K oops in 1988 when you gave a proposed graduation date 12 years in the future to a 12th grader!).
Of course, our window was, "00-50 = 2000-2050", while "51-99=1951 to 1999", since hopefully our students were not born prior to 1950! (Hmm, a 50 year old 12th grader? It could happen, I guess!). And now the program will automagically convert two-digit dates "on the fly" to 4-digit dates using those windowing rules so that we can do date math and date display in a consistent manner (the database actually had 4 digits for dates, but screen displays only had 2 digits and it was pretending that we were in year 00 through 99... had to find every @#$%@ date in close to a MILLION LINES OF CODE and half the bloody dates weren't even marked as date types, they were strings that were being sliced and diced to do various funky date calculations for, e.g., attendance!). I got my subsystems Y2K ready, then left before they could press me into service fixing other people's subsystems (grin). (Well, Y2K was definitely one reason I left, but the main reason was professional advancement... please don't take flippant statements too seriously).
Anyhow, the point is: this patent is bullshit. We did it in 1988, and I'm sure we're not alone. The 20-year-mortgage people surely did it for their computerized mortgage records as early as 1979 for much the same as we did for our 12-year-matriculation problem. Heck, 30 year mortgages in 1969 probably used windowing!
-E
The idiocy about U.S. export restrictions is that I cannot give Dr. Gladman a copy of a program whose only cryptographic component is Dr. Gladman's own code. See the bottom of my Ocotillo page at http://www.estinc.com/~eric for more details.
-E
Previously the web site was pretty clear that AES was going to be a single algorithm. As Bruce notes, a family of algorithms might be more practical, though in the past NIST was not open to that suggestion.
-E
Remember, Commodore never had the thousands of engineers munging the code that Netscape had, and the OS was modular in the first place (with the exception of the graphics system, which would need to be totally re-written a'la' Mozilla), which made it much easier to keep things clean.
Of course, it got crufted a bit at the end, as Commodore died, but so it goes. There wasn't enough engineers left at Commodore by that time to do TOO much damage to it...
Actually, the hardest problem with AmigaOS nowdays would be compiling it. It was written in pre-ANSI-C days, and I suspect that modern compilers would choke on it :-(.
A derivative of AmigaOS would be great for tiny palmtops and etc that don't have MMU's. As a general purpose OS it's not so great nowdays due to lack of VM support, but being written for a non-MMU environment is actually an advantage when you're trying to make it run on some embedded processor that doesn't HAVE an MMU. Linux can be hacked to run in such environments, but not well. AmigaOS thrives in the non-MMU environment (well, as well as can be done in such an environment!), and its low resource usage means that you could get away with crappier hardware than with, say, WinCE (wince!).
-E
PostGreSQL's only problem nowdays is performance on huge databases. Well, replication is still a problem too, as is hot backups, but performance is the killer here. Oracle is proven at running huge databases, PostGreSQL is not. If I were thinking 40gb of data, I'd look harder at Oracle than at PostGreSQL.
-E
SGI Iris and Solaris are excellent choices for jobs that have outgrown Linux. That's the beauty of Linux -- once you have outgrown Linux, you can move up to bigger computers. And with 40gb per year of data, we're talking 400gb within a few years.
I have personally fsck'ed a 40gb ext2 partition. It is *NOT* fun, it takes over 20 minutes even on the latest/fastest RAID subsystems! So it is indeed appropriate to question whether Linux is the proper solution for this problem. After all, this isn't Windows NT -- we don't have to say "Linux everywhere" to win (just "Windows NT nowhere", grin).
-E
PostGreSQL has the features he needs, and the latest version is very stable (as stable as Oracle). Its big problem: PERFORMANCE. While its performance is acceptable on a 2gb database, you can forget it on a 40gb database.
I would say that if he can afford Oracle, to go Oracle. Oracle is proven in large-database environments. Informix, SyBase, and Adabas-D would also be good choices. If he's interested in more obscure databases, Empress has a nice 4GL. SolidTech's stuff looks pretty good too.
Doing a search for "linux database" is instructive....
-E
By default, Mandrake installs the 'colorgcc' package. This colourizes the output of 'gcc' to make it "understandable". Unfortunately, it makes it totally INCOMPREHENSIBLE to Xemacs and other similar development tools that rely on parsing 'gcc' output in order to do things like, e.g., take you directly to the file and line of code that has the problem.
I find the default to the color 'ls' to be somewhat distracting because with the color scheme I use for "X", the yellow text on white background is virtually unreadable. I use a white background because it's easier on my eyes than the traditional white text on black background (yellow would be quite visible there). Point: color 'ls' is a Bad Idea on an "X"-oriented distro like Mandrake.
Plusses: I like some of the other choices. The 'klyx' included with Mandrake 6.1 works great. It includes 'eps' files just fine. The version of KDE is the latest, and works fairly well except for a disturbing tendency for 'kfm' to lose its configuration (and lose its mind, i.e., refuse to start at all). The 'yp' functionality is bug-free -- I updated our NIS server (running Red Hat 6.0) with the 'ypserv' and 'yppasswd' packages from Mandrake 6.1, and it fixed all the annoying glitches that I'd been working around for months. In general, it's a well-debugged and easy-to-use version of Linux, and aside from having to change my makefiles to directly call 'pgcc' rather than 'gcc' ('gcc' gets 'colorgcc'), it's been surprisingly annoyance-free.
And it includes XEmacs too, unlike RHL. I did mention that, right?
-Eric.
Of course, since he's not a superior techno-geek, Slashdotters will diss him. But folks like Evan, and like MacMillan, are just as important to the success of Linux as the uber-geeks who actually produce the technology. What's the use of great technology, if you can't come out of the closet? Aren't we tired of Linux being the gay stepchild of operating systems?!
-E
Apparently the reason they used the SSN is because their lunch system (provided by a company named Bon Appetite) only had SSN's in it (the SSN is required by the Feds because the Feds match it against their food stamp rolls so they can catch people fraudulently receiving free lunches). I don't know whether the lunch ladies were just too lazy to punch in 7-digit account numbers for the students, or whether the Bon Appetite software just isn't flexible enough to accept the 7-digit numbers in addition to the SSN numbers already there. Note that the principal does not have control over the lunch ladies (their direct supervisor is the Food Services supervisor at the central office), so the SSN may have been chosen as the path of least resistence. I suspect, however, that next year the SIDNO is going to be on those cards, not the SSN!
-E
The real stupidity is that they're using SSN's as the lunch account ID in the first place. The SSN has to be in the lunch system because the Feds use it to match against the food stamp database (that's how they detect fraud in the free lunch program), but I'm pretty sure that Bon Appetite (their school lunch system) has an "account number" feature that would allow you to use some other number (like the 7-digit district-assigned Student Identification Number used by their student information systems). But maybe their lunch ladies were too lazy to punch that info into the lunch computer :-( (Or maybe I'm overestimating the flexibity of Bon Appetite).
-E
Ruston High School sits beside Louisiana Tech University. Half the students are very bright children of college professors. The other half are from one of the most depressed areas in Louisiana, which in turn is one of the poorest states in the US.
Ruston High has had persistent gang and drug problems in recent years, but has been reluctant to admit these problems because they're afraid of those professors and their political connections. In particular, they have had problems with former students expelled for drugs, weapons, or gang violence coming back on campus to recruit, sell drugs, or just engage in gang rumbles in the hallways.
The purpose of the ID badges is so that these hoodlums cannot as easily pose as students (since presumably their badges were yanked when they were expelled). Columbine is a generic excuse that the school is using so that they don't have to admit that they have a drug and gang problem.
All of this is my opinion, of course, but probably an informed one. (See other postings of mine in this thread for exactly why I say that).
-E
Somebody else posted the federal law. The federal law says that schools can ask, but if they receive federal money they have to provide services whether you provide the SSN or not. Refuse to give the SSN, and the school has to provide an alternative. They hate to do so, because they have to call the district office to get a number off the list that the state sent to the district, and also because too many "9" numbers can cause a state audit (the state thinking you're enrolling a bunch of "ghost students" to get extra money from the state and that corrupt officials are pocketing the money). But they can do it.
-E
c) Re: advertising for pepsi: Note that this is something that a local bottler did, i.e., donated the badges to the school as a tax write-off. It's unclear whether he gave them excess pre-printed badges that he already had in stock, or actually had some printed up with the Pepsi logo. It's also likely that he did not have the slightest idea what the school was going to do with the badges. I wouldn't hassle PepsiCo about this, they're as much a victim as the students, the poor bottler probably thought the badges were going to be used for prom night or something.
-E
It's unfair to blast PepsiCo (the company) for what a local bottler did. It's probably even unfair to blast that local bottler, since he probably thought he was doing a favor for the school by giving them some of his excess badge holders.
-E
It is important to note that there is a 7-digit district-assigned "Student Identification Number" for each student in their student information system that is totally unrelated to the SSN. They had to have done a special query from the system to even get a list of students with their social security numbers. I was one of the programmers who wrote the student information system used at Ruston High School (while working for a consulting firm), and we did that on purpose, at district request -- none of the standard roster reports will list social security numbers, they will only list "SIDNO" (the 7-digit student identification number).
The social security number (or 9-digit '9' number) is used for two things: 1) the state computer system uses it as the student's "State Student Identification Number", so that they can track students and detect fraud (like 'ghost students'), and 2) the federal school lunch program uses it to match the student body against the food stamp rolls in order to detect students eligible who are not receiving services, and vice-versa (i.e., to detect fraud). It most certainly does NOT need to be on a student badge -- the 7-digit district-assigned number would suffice just fine for anything except the school lunch computer (which, alas, would require a little custom programming -- there is a second 9-digit field that could be adapted, but they would probably have needed to pay Bon Appetite a few bucks to make their card scanner use that rather than the SSN field).
-E
No placard? Easy for security guard to detect! That's the point. Students weren't carrying their student ID's because nobody ever checked them, making it hard to tell the difference between a kid expelled for drugs and a kid who forgot his ID at home... but if the student ID is around their neck...
-E