It's not that hard to install, but one of the major hurdles I found when using Woody's boot CDs, was the completely obsolete kernels you have a choice of using.
There is some talk recently on debian-devel about letting newer kernel versions into the point releases, so in the future this may not be much of an issue. The idea has been shelved until after Sarge is released since Sarge will have a new kernel anyway. On the flip side though, the default 2.4 and 2.2 kernels can generally get Debian installed on almost any hardware. After that, compiling a kernel from scratch with make-kpkg is fairly simple.
All of these new products have brought something new to the field. They would have crashed and burned otherwise. I fail to see what this new standard can bring to the masses, and it's really nothing unique that existing software can't do.
I will come bundled with every copy of Frontpage/Office/Windows...the same way that IE beat Netscape.
This is the second time this has happened to a big open-source project (the first being the GNU servers a while ago).
Don't forget the hack on the Kernel CVS. More accurately though, this is the third time you have been told about. Would the commercial vendors tell you about a compromise like this? I can imagine a slew of reasons why they would keep an attack like this quiet. Debian make a big issue out of full disclosure of problems.
How many smaller projects have been hacked and still haven't noticed? If Debian, GNU, and the Linux kernel team are vunerable it's a good bet that FooProject.org is vunerable.
Huh? 32V never lost it's copyright, Caldera Int., opened up Version 7 and 32V with a old-style BSD license.
If you read the Judge's ruling in the BSDI case he stated that AT&T might have lost their copyright on the 32V source code because they failed to adequately mention a copyright in the code. At the time, publishing something without mentioning a copyright meant you weren't asserting any. The laws have changed since then, but at the time there was a good chance that AT&T would have lost UNIX to the public domain if the case went on.
Caldera releasing the "ancient UNIX" code under a BSD style license is a seperate issue.
There is one factor that helps SCO now. Copyright laws have changed so the argument that 32V Unix had lost its copyright is shakey at best.
OTOH, the fact that SCO wants to challenge the agreement so long after the fact makes it difficult to imagine they have any chance of winning. It also sounds like ATT/Novel/SCO never bothered to correct the problems that got them into trouble in the first place. Did they ever document which code was borrowed from Berkeley? I really doubt it.
AT&T tried. They lost their case: it turned out that AT&T had copied a lot of BSD code.
Hmmm. Presents an interesting "what if" scenario. If the BSD agreement is declared invalid, doesn't that make SCO liable for years and years of copyright infringement? The whole Berkeley Packet Filter debacle seems to suggest that SCO still hasn't bothered to properly document the code that was taken from Berkeley.
1 Kasparov = 4 2.8GHZ Xeons
Imagine what a beowulf cluster of Kasparovs could do.
Seriously though. Kasparov ties with a four processor system? The fact that he was even playing against such a modest machine seems to be an admission of defeat. In two or three years he'll be playing competitively with an imac.
debian includes non-free in the default distro does it not?
No.. Debian asks if you want apt to pull in software from the non-free archive. The funny thing is that non-free in Debian is filled with things that most other distros call free software. Qmail, malestrom, mpg123, povray, etc. RMS made the mistake before of assuming GNU/LinEx was applying the same standards of freeness as Debian and had eliminated the non-free section. In reality they moved some non-free software into the main archive.
Considering that RMS seems to think even Debian isn't really a Free Software(tm) distro, I find it difficult to image that Mandrake qualifies.
On the 9.2 comparison chart you can clearly see that every version of Mandrake other than the Download edition includes plenty of proprietary software.
Don't get me wrong. Most of what I know about GNU/Linux I learned on Mandrake. Implying that it's the last of the free software distros is comical though.
They don't look like copies to me. Close relatives, yes. Accomplish the same task, yes. Comments identical? No.
Although I tend to agree that the similarities are not interesting enough to get in a huff, I'd be interested in hearing whether or not Scott Deboy wrote the comment "Convert an integer passed as argument to a level. If the conversion fails, then this method returns the specified default."
If he didn't write it, where did he get it? Perhaps both groups were borrowing from another source.
It doesn't make any sense that someone would get source from CVS, then do a diff against BitKeeper. You'd do a diff against the file in CVS. If it was done as you suggest, the diff might back out other unrelated patches to the same file.
The intent was probably that a CVS user get the bad version, work on other stuff, and send the diff (including the bad lines) to a maintainer in an otherwise good patch.
I don't see how this would work. If I update against a CVS server, work on a file, then submit a diff of the changes I've made, the trojan wouldn't be included in the diff unless I edited the line the trojan was on, and even then it shouldn't apply properly to the clean upstream source. Am I missing something here?
Netscape? A failed company who tried to create their own monopoly, but failed when Microsoft gave away their browser for free -- something that every single other browser manufacturer before Netscape was doing already?
I always found the arguments that IE was not free rather compelling. If they start bundling Office with Windows, and the cost of a Windows upgrade climbs to $400, is Office now free or did you get forced into buying it?
Surely Internet Explorer, Windows Media Player, and Outlook Express add SOME cost to Windows. If they really aren't being charged for in the cost of Windows, why do you need a Windows license to use them?
There's an article refering to SGI's stuff (The Linux in Hollywood one) this morning and now McBride starts pointing a finger at them too. I wonder how many SCO FUD Spinners read/. waiting to see who to go after next.
In this case, it seems pretty obvious SCO is digging through slashdot looking for anything that tends to back up their arguments. They prune away any mitigating factors or uncertainty and hold out the argument as a proven fact. A couple of assert() statements in ate_utils.c may be from SysV, but the overwhelming majority of this code was released for BSD style use in 2002. SCO refuses to acknowledge ANY mitigating curcumstances.
I would strongly suggest that if anyone finds anything new that tends to support SCO's claims, take it off Slashdot. SCO is not going to pay you for making their case. They don't care about helping the Linux kernel team move beyond these IP issues. They seem hell bent on obscuring the truth.
If you have some interesting counterpoint to something Bruce Perens, ESR, or Linus says, email them. They all seem eager to discuss arguments for or against SCO. If you find questionable code in the Kernel, contact one of the Kernel maintainers in private.
I strongly believe in the Debian philosophy of being open about problems, but this whole sad saga leading into a lawsuit against SGI shows that you have to remember, sometimes there really are selfish bastards hiding in the background plotting against you.
SCO could have easily taken the high moral ground by letting these trivial code snips slide. Instead they want to sue over code that has been freely and widely distributed for 20+ years. XFS is a non-issue. It will end up just like the BSD trial with the judge narrowing the scope of claims down to the six questionable functions that SGI has found.
I was under the, possibly mistaken, impression that IBM had assigned all their copyrights in the Linux kernel to the FSF. If that is the case, how can IBM claim SCO violated their copyright. Wouldn't the FSF have to make this claim?
From FSF Statement on SCO v. IBM The Foundation notes that despite the alarmist statements SCO's employees have made, the Foundation has not been sued, nor has SCO, despite our requests, identified any work whose copyright the Foundation holds-including all of IBM's modifications to the kernel for use with IBM's S/390 mainframe computers, assigned to the Foundation by IBM--that SCO asserts infringes its rights in any way.
The most serious change to BTX versus ATX is switching the side of the expansion slots. What possible advantage could this have, aside from making it incompatible with existing ATX cases?
If this little change is so important, why don't we see anyone manufacturing ATX tower cases where the motherboard mounts on the left side rather than the right. You'd get the same effect (CPU in line with the case fan) without designing a completely new style of motherboards. This sounds more like an excuse to eliminate PS2, serial and parallel ports. My keyboard and mouse are plugged into PS2 ports, my printer is plugged into the parallel port, and I use the serial port to log in to headless servers. You only need a single USB port to plug in a hub, so why do they want to eliminate all the older ports?
I can't tell if you think that the OpenSSH people were sitting on this patch for a while and then told us and the distros simultaneously, or if you think that they should have sat on the patch but only after telling the distros about it. There has to be some way to generate the time between the creation of the patch and when you'd like for them to officially release the patch.
Well, if it's an issue where the patch reveals all the information needed to create an exploit, and no known exploit exists, the the distros should be informed prior to releasing the patch. Wasn't the GNU ftp server compromised for this reason?
I'm not saying that these problems should be hidden, but when the patch itself provides the information needed to create an exploit, it shouldn't be revealed until the distros have been given a chance to prepare fixes. If there is already a confirmed exploit, all bets are off.
If all security bugs are announced the second they are found then we'll have a real problem. Someone interested in cracking your site just needs to wait for a long enough delay between the upstream patch and the distro fix. If upstream is dropping security fixes in CVS and waiting 6 months for the next release, that could be a disasterous problem.
I'm not saying that is what happened here. I honestly don't know the exact details. In fact, Sendmail's release notes state that they were planning on a later release and someone disclosed the bug early. It does sound like Sendmail was trying to coordinate a proper release.
Either way it comes up to "announce to distros first, then everyone else", which I have problems with. Everyone needed the patch, they needed it soon, and they needed it whether or not they happened to be using a particular distro!
In a perfect world, I completely agree with you. Given the limitations of the human beings sitting between my servers and OpenSSH's CVS, I'd rather see some allowances made. Taken to absurd levels, would you rather see security bugs posted to slashdot before the upstream authors are even informed about them? Obviously there has to be a certain amount of secrecy, the question is where do you draw the line.
I'm using Debian, and this is why I'm upset. The Debian developers are great people but they aren't magic. They need time to get a package ready and test it. For something as important as Sendmail I'd expect they do some serious testing before pushing a patch down on everyone. Announcements like this mean that no real testing will be done before a new verison is pushed down. If you look at the OpenSSH bug released yesterday you can see the problem with this system. Debian sent out a fixed version right after the vunerability was released. Today they pushed down a second fixed version after they discovered more problems with the first fix. If the Debian developers had proper notice they could have worked out these issues without wasting everyone's time and bandwidth fixing the same problem twice. Give the system the time it needs to fix things properly... That's all I'm saying.
When did everyone decide the standard way of fixing security bugs was no longer worth the effort. You don't release a new version with a security bug fixed until all the distros have been contacted and the fix has been backported. Why have Sendmail and OpenSSH decided this no longer applies to them? Is Apache next? Are they going to force an upgrade to Apache 2 by rolling security fixes into beta versions and not bothering to tell anyone before they are released?
Kevlar covered laptops?? Increased focus on redundant, mobile systems??
It's certainly possible things have changed dramatically in the last three years, but when I left in 2000 the average grocery store had a more robust and better designed IT setup.
Our bradley company had four laptops. The Company Commander and First Sergent each had top of the line Dells with Windows NT. The Supply Sergeant and Arms Room NCO each had an old crufty Win95 laptop to run their DOS based supply/arms-room tracking software.
We had another 5 desktop systems that ranged from mediocre to copletely obsolete, all running Win95 and Office 97. These were divided up among platoon leaders (3), training room (1), and the executive officer (1).
EVERYTHING was printed. The XO had an old LaserJet III that printed but made grey pages. The training room had a nice new 9000TN. Things that needed printing was brought on a floppy to the training room for printing then walked up to Battalion headquarters for photocopying. (And Battalion loved to change the codes on the Xerox and demand that everyone go to Brigade headquarters two miles away...and, of course, Brigade wouldn't let anyone use their photocopier...but that's a different story.)
Other computers being used for various training tasks included: four Commodore Vic-20's that ran really old rifle training simulators and one Vax system that ran our Bradley simulator. Then, of course, you had all the specially designed equipment GPS, radios, geiger counters, etc. The one thing that can uniformely be said about all the custom gear is that it's terribly bulky and heavy. Our GPS units weighed at least 1&1/2 pounds, and were less accurate than civilian models weighing a few ounces. The radios were top notch but weighed a ton, took two different types of batteries to work properly, and were difficult to set up correctly. If you've ever worked with a frequency hopping military radio you'd know the immense joy of running between a dozen vehicles with a watch at 3:00am trying to get the clocks synced. It's hardly suprising that personal cellphones were used so widely as a backup. Most of this equipment is unreliable. Sheer numbers makes up for that fact.
Of course, I was in a combat unit. Even our support staff (the como platoon) had absoloutely NO training on computers. Typing ability was a curse and everyone tried to pretend they had never seen a computer before. Being what amounts to an extermely underpaid secretary in a military enviornment sucks bigtime. At least a quarter of the enlisted men in the military have trouble writing complete sentences, and they're trying to submit paperwork to officers who have all graduated college. It's a nightmare.
All of the sexy jobs that required real knowledge and thinking outside the box were done by contractors. The internet may have been created for the military but it wasn't created by military personel. Anyone who's looking for one of those sexy high-tech jobs descrambling chinese radio transmissions would do best to stay out of the military, finish college and work as a contractor.
If you want to blow shit up...that's a different story.
This bug is only public knowledge because the OpenSSH people have already fixed it.
And it's only a problem because they didn't tell anyone else. There are too many people looking at SSH for holes to try and slip a security fix into a new version without mentioning it and backporting the fix. Maybee they didn't appreciate that it was an exploitable bug. Maybee this whole topic is hype and there is no exploit. Assuming they new it was an exploitable bug, they should have coordinated a fix before releasing a patched version. A local root exploit in Galeon, Grip, etc...upsetting but no use losing sleep over it. A remote root exploit in SSH, Apache, xinetd, etc...get is fixed ASAP and don't hide the problem.
No, BLAST won't work. ESR's SHRED won't work. These are, at heart, text matching algorithms, which are easily defeated and of little relevance.
Except that "Shred" is basicly the same thing as what I did to find the malloc.c/ate_utils.c similarity several months before SCO claimed it. You could certainly extend the shread idea further to, for instace, rename everything that's not a reserved word before hashing and bumping the line count up to 10 or so. That should catch anything where the author did a simple find/replace on variable names.
You think the mythical team of MIT experts had a better method? If you manipulate the code too far before comparing it you'll eventually get to the point where copyright law doesn't even apply and two seperate implimentations of a standard will nearly always match.
SCO has already made it clear that any literal copying is secondary to their grander claims to own all things that touch Unix.
Slashdot Mirror
It's not that hard to install, but one of the major hurdles I found when using Woody's boot CDs, was the completely obsolete kernels you have a choice of using.
There is some talk recently on debian-devel about letting newer kernel versions into the point releases, so in the future this may not be much of an issue. The idea has been shelved until after Sarge is released since Sarge will have a new kernel anyway. On the flip side though, the default 2.4 and 2.2 kernels can generally get Debian installed on almost any hardware. After that, compiling a kernel from scratch with make-kpkg is fairly simple.
All of these new products have brought something new to the field. They would have crashed and burned otherwise. I fail to see what this new standard can bring to the masses, and it's really nothing unique that existing software can't do.
I will come bundled with every copy of Frontpage/Office/Windows...the same way that IE beat Netscape.
Your technological and biological OS'nes will be adapted to profit us
We are SCO, prepare to be litigated.
This is the second time this has happened to a big open-source project (the first being the GNU servers a while ago).
Don't forget the hack on the Kernel CVS. More accurately though, this is the third time you have been told about. Would the commercial vendors tell you about a compromise like this? I can imagine a slew of reasons why they would keep an attack like this quiet. Debian make a big issue out of full disclosure of problems.
How many smaller projects have been hacked and still haven't noticed? If Debian, GNU, and the Linux kernel team are vunerable it's a good bet that FooProject.org is vunerable.
Huh? 32V never lost it's copyright, Caldera Int., opened up Version 7 and 32V with a old-style BSD license.
If you read the Judge's ruling in the BSDI case he stated that AT&T might have lost their copyright on the 32V source code because they failed to adequately mention a copyright in the code. At the time, publishing something without mentioning a copyright meant you weren't asserting any. The laws have changed since then, but at the time there was a good chance that AT&T would have lost UNIX to the public domain if the case went on.
Caldera releasing the "ancient UNIX" code under a BSD style license is a seperate issue.
AT&T had a MUCH better table to stand on.
There is one factor that helps SCO now. Copyright laws have changed so the argument that 32V Unix had lost its copyright is shakey at best.
OTOH, the fact that SCO wants to challenge the agreement so long after the fact makes it difficult to imagine they have any chance of winning. It also sounds like ATT/Novel/SCO never bothered to correct the problems that got them into trouble in the first place. Did they ever document which code was borrowed from Berkeley? I really doubt it.
AT&T tried. They lost their case: it turned out that AT&T had copied a lot of BSD code.
Hmmm. Presents an interesting "what if" scenario. If the BSD agreement is declared invalid, doesn't that make SCO liable for years and years of copyright infringement? The whole Berkeley Packet Filter debacle seems to suggest that SCO still hasn't bothered to properly document the code that was taken from Berkeley.
1 Kasparov = 4 2.8GHZ Xeons Imagine what a beowulf cluster of Kasparovs could do. Seriously though. Kasparov ties with a four processor system? The fact that he was even playing against such a modest machine seems to be an admission of defeat. In two or three years he'll be playing competitively with an imac.
debian includes non-free in the default distro does it not?
No.. Debian asks if you want apt to pull in software from the non-free archive. The funny thing is that non-free in Debian is filled with things that most other distros call free software. Qmail, malestrom, mpg123, povray, etc. RMS made the mistake before of assuming GNU/LinEx was applying the same standards of freeness as Debian and had eliminated the non-free section. In reality they moved some non-free software into the main archive.
Considering that RMS seems to think even Debian isn't really a Free Software(tm) distro, I find it difficult to image that Mandrake qualifies.
On the 9.2 comparison chart you can clearly see that every version of Mandrake other than the Download edition includes plenty of proprietary software.
Take a look at the M's in Debian's non-free section and compare it to Mandrake's package list.
Don't get me wrong. Most of what I know about GNU/Linux I learned on Mandrake. Implying that it's the last of the free software distros is comical though.
They don't look like copies to me. Close relatives, yes. Accomplish the same task, yes. Comments identical? No.
Although I tend to agree that the similarities are not interesting enough to get in a huff, I'd be interested in hearing whether or not Scott Deboy wrote the comment "Convert an integer passed as argument to a level. If the conversion fails, then this method returns the specified default."
If he didn't write it, where did he get it? Perhaps both groups were borrowing from another source.
Has a php-nuke/post-nuke/thataware site ever withstood a slashdotting?
It doesn't make any sense that someone would get source from CVS, then do a diff against BitKeeper. You'd do a diff against the file in CVS. If it was done as you suggest, the diff might back out other unrelated patches to the same file.
The intent was probably that a CVS user get the bad version, work on other stuff, and send the diff (including the bad lines) to a maintainer in an otherwise good patch.
I don't see how this would work. If I update against a CVS server, work on a file, then submit a diff of the changes I've made, the trojan wouldn't be included in the diff unless I edited the line the trojan was on, and even then it shouldn't apply properly to the clean upstream source. Am I missing something here?
Netscape? A failed company who tried to create their own monopoly, but failed when Microsoft gave away their browser for free -- something that every single other browser manufacturer before Netscape was doing already?
I always found the arguments that IE was not free rather compelling. If they start bundling Office with Windows, and the cost of a Windows upgrade climbs to $400, is Office now free or did you get forced into buying it?
Surely Internet Explorer, Windows Media Player, and Outlook Express add SOME cost to Windows. If they really aren't being charged for in the cost of Windows, why do you need a Windows license to use them?
Exactly what patent is Linux threatened by?
It's easier to point out which software patents are actively avoided.
GIF, MP3, and S3 Texture Compression immediately spring to mind.
There's an article refering to SGI's stuff (The Linux in Hollywood one) this morning and now McBride starts pointing a finger at them too. I wonder how many SCO FUD Spinners read /. waiting to see who to go after next.
In this case, it seems pretty obvious SCO is digging through slashdot looking for anything that tends to back up their arguments. They prune away any mitigating factors or uncertainty and hold out the argument as a proven fact. A couple of assert() statements in ate_utils.c may be from SysV, but the overwhelming majority of this code was released for BSD style use in 2002. SCO refuses to acknowledge ANY mitigating curcumstances.
I would strongly suggest that if anyone finds anything new that tends to support SCO's claims, take it off Slashdot. SCO is not going to pay you for making their case. They don't care about helping the Linux kernel team move beyond these IP issues. They seem hell bent on obscuring the truth.
If you have some interesting counterpoint to something Bruce Perens, ESR, or Linus says, email them. They all seem eager to discuss arguments for or against SCO. If you find questionable code in the Kernel, contact one of the Kernel maintainers in private.
I strongly believe in the Debian philosophy of being open about problems, but this whole sad saga leading into a lawsuit against SGI shows that you have to remember, sometimes there really are selfish bastards hiding in the background plotting against you.
SCO could have easily taken the high moral ground by letting these trivial code snips slide. Instead they want to sue over code that has been freely and widely distributed for 20+ years. XFS is a non-issue. It will end up just like the BSD trial with the judge narrowing the scope of claims down to the six questionable functions that SGI has found.
I was under the, possibly mistaken, impression that IBM had assigned all their copyrights in the Linux kernel to the FSF. If that is the case, how can IBM claim SCO violated their copyright. Wouldn't the FSF have to make this claim?
From FSF Statement on SCO v. IBM
The Foundation notes that despite the alarmist statements SCO's employees have made, the Foundation has not been sued, nor has SCO, despite our requests, identified any work whose copyright the Foundation holds-including all of IBM's modifications to the kernel for use with IBM's S/390 mainframe computers, assigned to the Foundation by IBM--that SCO asserts infringes its rights in any way.
The most serious change to BTX versus ATX is switching the side of the expansion slots. What possible advantage could this have, aside from making it incompatible with existing ATX cases?
If this little change is so important, why don't we see anyone manufacturing ATX tower cases where the motherboard mounts on the left side rather than the right. You'd get the same effect (CPU in line with the case fan) without designing a completely new style of motherboards. This sounds more like an excuse to eliminate PS2, serial and parallel ports. My keyboard and mouse are plugged into PS2 ports, my printer is plugged into the parallel port, and I use the serial port to log in to headless servers. You only need a single USB port to plug in a hub, so why do they want to eliminate all the older ports?
I can't tell if you think that the OpenSSH people were sitting on this patch for a while and then told us and the distros simultaneously, or if you think that they should have sat on the patch but only after telling the distros about it. There has to be some way to generate the time between the creation of the patch and when you'd like for them to officially release the patch.
Well, if it's an issue where the patch reveals all the information needed to create an exploit, and no known exploit exists, the the distros should be informed prior to releasing the patch. Wasn't the GNU ftp server compromised for this reason?
I'm not saying that these problems should be hidden, but when the patch itself provides the information needed to create an exploit, it shouldn't be revealed until the distros have been given a chance to prepare fixes. If there is already a confirmed exploit, all bets are off.
If all security bugs are announced the second they are found then we'll have a real problem. Someone interested in cracking your site just needs to wait for a long enough delay between the upstream patch and the distro fix. If upstream is dropping security fixes in CVS and waiting 6 months for the next release, that could be a disasterous problem.
I'm not saying that is what happened here. I honestly don't know the exact details. In fact, Sendmail's release notes state that they were planning on a later release and someone disclosed the bug early. It does sound like Sendmail was trying to coordinate a proper release.
Either way it comes up to "announce to distros first, then everyone else", which I have problems with. Everyone needed the patch, they needed it soon, and they needed it whether or not they happened to be using a particular distro!
In a perfect world, I completely agree with you. Given the limitations of the human beings sitting between my servers and OpenSSH's CVS, I'd rather see some allowances made. Taken to absurd levels, would you rather see security bugs posted to slashdot before the upstream authors are even informed about them? Obviously there has to be a certain amount of secrecy, the question is where do you draw the line.
I'm using Debian, and this is why I'm upset. The Debian developers are great people but they aren't magic. They need time to get a package ready and test it. For something as important as Sendmail I'd expect they do some serious testing before pushing a patch down on everyone. Announcements like this mean that no real testing will be done before a new verison is pushed down. If you look at the OpenSSH bug released yesterday you can see the problem with this system. Debian sent out a fixed version right after the vunerability was released. Today they pushed down a second fixed version after they discovered more problems with the first fix. If the Debian developers had proper notice they could have worked out these issues without wasting everyone's time and bandwidth fixing the same problem twice. Give the system the time it needs to fix things properly... That's all I'm saying.
When did everyone decide the standard way of fixing security bugs was no longer worth the effort. You don't release a new version with a security bug fixed until all the distros have been contacted and the fix has been backported. Why have Sendmail and OpenSSH decided this no longer applies to them? Is Apache next? Are they going to force an upgrade to Apache 2 by rolling security fixes into beta versions and not bothering to tell anyone before they are released?
Kevlar covered laptops?? Increased focus on redundant, mobile systems??
It's certainly possible things have changed dramatically in the last three years, but when I left in 2000 the average grocery store had a more robust and better designed IT setup.
Our bradley company had four laptops. The Company Commander and First Sergent each had top of the line Dells with Windows NT. The Supply Sergeant and Arms Room NCO each had an old crufty Win95 laptop to run their DOS based supply/arms-room tracking software.
We had another 5 desktop systems that ranged from mediocre to copletely obsolete, all running Win95 and Office 97. These were divided up among platoon leaders (3), training room (1), and the executive officer (1).
EVERYTHING was printed. The XO had an old LaserJet III that printed but made grey pages. The training room had a nice new 9000TN. Things that needed printing was brought on a floppy to the training room for printing then walked up to Battalion headquarters for photocopying. (And Battalion loved to change the codes on the Xerox and demand that everyone go to Brigade headquarters two miles away...and, of course, Brigade wouldn't let anyone use their photocopier...but that's a different story.)
Other computers being used for various training tasks included: four Commodore Vic-20's that ran really old rifle training simulators and one Vax system that ran our Bradley simulator. Then, of course, you had all the specially designed equipment GPS, radios, geiger counters, etc. The one thing that can uniformely be said about all the custom gear is that it's terribly bulky and heavy. Our GPS units weighed at least 1&1/2 pounds, and were less accurate than civilian models weighing a few ounces. The radios were top notch but weighed a ton, took two different types of batteries to work properly, and were difficult to set up correctly. If you've ever worked with a frequency hopping military radio you'd know the immense joy of running between a dozen vehicles with a watch at 3:00am trying to get the clocks synced. It's hardly suprising that personal cellphones were used so widely as a backup. Most of this equipment is unreliable. Sheer numbers makes up for that fact.
Of course, I was in a combat unit. Even our support staff (the como platoon) had absoloutely NO training on computers. Typing ability was a curse and everyone tried to pretend they had never seen a computer before. Being what amounts to an extermely underpaid secretary in a military enviornment sucks bigtime. At least a quarter of the enlisted men in the military have trouble writing complete sentences, and they're trying to submit paperwork to officers who have all graduated college. It's a nightmare.
All of the sexy jobs that required real knowledge and thinking outside the box were done by contractors. The internet may have been created for the military but it wasn't created by military personel. Anyone who's looking for one of those sexy high-tech jobs descrambling chinese radio transmissions would do best to stay out of the military, finish college and work as a contractor.
If you want to blow shit up...that's a different story.
This bug is only public knowledge because the OpenSSH people have already fixed it.
And it's only a problem because they didn't tell anyone else. There are too many people looking at SSH for holes to try and slip a security fix into a new version without mentioning it and backporting the fix. Maybee they didn't appreciate that it was an exploitable bug. Maybee this whole topic is hype and there is no exploit. Assuming they new it was an exploitable bug, they should have coordinated a fix before releasing a patched version. A local root exploit in Galeon, Grip, etc...upsetting but no use losing sleep over it. A remote root exploit in SSH, Apache, xinetd, etc...get is fixed ASAP and don't hide the problem.
No, BLAST won't work. ESR's SHRED won't work. These are, at heart, text matching algorithms, which are easily defeated and of little relevance.
Except that "Shred" is basicly the same thing as what I did to find the malloc.c/ate_utils.c similarity several months before SCO claimed it. You could certainly extend the shread idea further to, for instace, rename everything that's not a reserved word before hashing and bumping the line count up to 10 or so. That should catch anything where the author did a simple find/replace on variable names.
You think the mythical team of MIT experts had a better method? If you manipulate the code too far before comparing it you'll eventually get to the point where copyright law doesn't even apply and two seperate implimentations of a standard will nearly always match.
SCO has already made it clear that any literal copying is secondary to their grander claims to own all things that touch Unix.