OpenBSD is as big a pile of crap as any other OS, if not admin'ed by a relatively clueful person. Just because the BSD people have numbers on their side that they can use to say they're "secure", OpenBSD boxen still do get r00ted (8 in the month of October alone, according to alldas.de).
The big "security bonus" seen when comparing the *BSDs to Linux is rooted in the fact that the intellectual cost of entry is higher for the BSDs (due to an even more profound lack of point-and-drool installers than are available for Linux), and thus, admins are more likely to be semi-qualified to be running a box in the first place.
b) LEAVE FTP disabled
Once again, if you've got the intelligence to even run a *NIX-ish OS, then you should be able to run even wu-ftpd if you keep track of bugtraq, vuln-dev, and other mailing lists.
c) LEAVE Telnet disabled
Agreed.
d) ENABLE SFTP if you need an FTPish connection.
I didn't even know of the existence of an SFTP *client* on my box (which I've been using for 14 months) until I checked for the manpage. All those running SFTP servers, raise your hands...
Just a reminder that you can't be truely secure with any operating system, service footprint, or ftp daemon...:)
Mainly because there is nobody there to issue them... I agree that Slackware is a very fine distro, but last time I checked, they didn't have a team of zillions trolling vulnerability boards for potential problems.:)
Definitely not your average script kiddie's reading material (it includes an indepth breakdown of malloc() and its ilk), but worth a read if you're interested.
Can someone give a joe-user guide to helping test new kernels?
/me stretches, getting ready for some extended typing...
"Don't."
You shouldn't really be testing new kernels unless you know what you're doing and you eat kernel compiles for breakfast (they go great with strawberries and low-fat milk). If you've mastered ksymoops, gdb (and its brother, kdb), and recovering a borken kernel, then have at it... just don't come complaining to me when your kernel panics.:)
FS corruption is FS corruption, you can't justify it at all, especially since this is supposed to be a stable kernel.
You shouldn't expect stability from the latest version of *anything* if it hasn't been out a day yet.
There is a difference, too; the iTunes bug resulted from bad shell script written for the installer on an in-house program written for their own flagship OS by a large, trusted company. This is a bug in a part of the kernel maintained by a small group of people working without pay for the project.
It can't be all that obscure if it's changed enough since the last revision to do damage now could it?
Uh... the changes were to fix a long-standing filesystem bug (albeit, one that didn't cause FS corruption). Granted, Linus should have tested the kernel first, but he was in a hurry to get 2.4.15/2.5.0 out.
Come on guys, nobody is going to take linux seriously as long as problems like this -- or the VM saga -- keep popping up in supposedly stable kernels.
Read my earlier post on the subject. This is not a stable kernel, as there is no development tree to iron out all the bugs. If you ask me, anyone who upgraded to something as bleeding-edge and untested as this (myself included) deserves to get burned a little bit as a warning that you don't really need the newest kernel.;)
The iTunes bug was a broken shell script; this is a bug in some obscure, not-very-often-modified C code in the core of the Linux kernel... there's a big difference.
Just like so many things with Linux, you'd think that this would be true, but it isn't.;) There are two trees that are in development at all times:
The "stable" tree (which has an even minor version number), and the "development" tree (which has an odd minor).
When kernel 2.2n.0 (n being a non-negative integer, in this case, 2) is released, development stops on 2.2n-1.x, and all newly-submitted-and-approved-by-Linus patches are applied to the 2.2n.x tree (because 2.2n-1.x is out of date). While 2.2n.x is still called the stable tree, it becomes the development tree (because some of the newly-patched stuff is untested, and there's no "development" tree to put it in). The "stable" role falls back to 2.2(n-1).0, in this case, the 2.2.x tree.
As far as this goes, it was a stroke of bad luck and hurried timing that this bug wasn't ironed out in 2.4.15-pre9 before it went final (and somewhat of a stroke of stupidity on the parts of the early adopters, myself included).
When 2.2n+1.0 is released, 2.2n continues development, making it the stable tree. Any fixes to bugs found in the 2.2n+1.x tree are back-merged to the current stable tree so that end-users can enjoy a stable, debugged kernel without riding the bleeding edge.
The problem with the Linux kernel numbering system is that the "stable" tree is only stable when there's a "development" tree to test the uncharted waters for it... if there isn't one, it's best to stay back a few revisions unless you like running fsck.;)
This bug was introduced when the kernel coders were trying to fix a bug that existed earlier (but, AFAIK, didn't cause fs corruption). It was introduced in pre9, but the final kernel was released within a few hours, so I guess nobody caught it in time.
It afflicts every filesystem. However, rebooting with the file/forcefsck extant forces it to run an fsck (and fix the corruption) on boot.
Also of help might be the Alt+SysRq keys; if you sync the drives and unmount them in single user mode before reboot, you should reduce or eliminate the corruption.
The Soviet Union was a powerful military country, and built 9 space stations. (Salyut 1-7, Mir, and now the ISS).
IIRC (which I might not, and I'm not going to check, because I'm a lazy, lazy man), Salyut 1-7 were just missions to a single space station (brought up with the first of the flights). Can someone confirm or deny this?
If memory serves (as it often doesn't), Star Division (the German(?) company that originally produced StarOffice), went belly-up, but gave the rights to Sun to redistribute as they wished... not sure though.:P
My guess is that GameCubes with differently-colored casings may have been made on separate production lines, and thus, if one line is bad, it will only affect specifically-colored GameCubes.
Actually, there was a thread or seven on the linux-kernel mailing list about this a couple months ago. However, it didn't go much of anywhere, as to upgrade a kernel on the fly would take some major code-fu (chucking variables into reserved spots in memory and hoping that you could keep track of them while you're running without a kernel)...
Well, if that is what the schools want to buy, who are we to tell them otherwise?
I'm not saying that the schools will want it, but they'll get it anyway. Microsoft will send marketroids to any dissenting school districts by the dozen preaching about the perceived advantages of Microsoft software. Since these are, by and large, school districts that are severely lacking in technology (and qualified professionals to run it, by the same logic), they will fall for it hook, line, and sinker. In addition, Microsoft has a lot of "wiggle room" (for lack of a better phrase) with which to offer, shall we say, special incentives (free software). As long as they're not doing this to large numbers of school districts, the "donation" goes off as planned, and they gain valuable mindshare, PR fodder, etc.
There are some problems with your argument, albeit ones that are easy to make.
Red Hat is going to support 1 million PC's for free. How much would that cost?
All of which will be on standardized software and in groups of 70 or so per school. To support 70 identical PCs is no different from supporting 1 PC; the additional cost is only 69 more records in the database.
Do they realize the beating these machines take? Do they think that school teachers and librarians (who usually do the first line support) have any computer knowledge?
(Keep in mind, I don't work for RedHat, and don't even live in the same state as their offices)
I personally happen to be using RedHat now (7.1; I haven't taken the time to get 7.2 yet), and RedHat Network is a very high-class support scheme, possibly falling second only to Microsoft's omnipotent and ubiquitous Windows Update (which is only good because you're talking about a homogenized, monolithic OS, with an update program you can't escape). I prolly have about 100-150 non-standard packages installed on my computer (many being very, very alpha) and RHN keeps track of what's there well enough so that I can keep my system up to date.
Any school district worth its salt will have at least one technology professional. Even if they have to admin 700 boxen, all of the boxen are identical, so it can be made largely a "set-and-forget" affair with RHN.
This is insane. It's just a PR stunt.
IMHO, it isn't necessarily suicide. Consider the following:
1) This counterproposal most likely caught Microsoft off guard, and with the holiday season here, they may not have an official statement for a while.
2) This offer hasn't gotten much press (not even on the local news; I live near Seattle, btw) due to the events in Afghanistan.
3) If M$ accepts the counteroffer, they lose approximately 5 kids per computer per year that the computer is in operation... that's 5 kids who won't use Microsoft software times 1,000,000 boxen times maybe 3 or 4 years (at the least) that the boxen will be up.
All M$ will win back is the runoff, so to speak; the kids who grew up with Linux, hated it, and have now become Luddites. These children will require extensive hand-holding and support in the future when they are forced to use M$ products, which means their boxen will cost *far* more to maintain than those in a closed school environment.
4) If M$ declines the counteroffer, this whole mess is revealed to be nothing but some shady back-room dealing by Microsoft in an effort to escape monetary losses. This will leave them holding the bag for:
- 1 million personal computers
- Software to outfit these computers
- and, likely, the same case as before, as public outrage would prompt massive backlash at M$ *and* the DoJ
This will offend all school administrators offered these computers, not to mention pretty much every technology-informed person on Earth, or at least those who can put 1 and 1 together.
5) If their official statement comes after the Afghanistan situation cools down somewhat, then M$ will also lose every non-informed consumer who has access to a media outlet.
In summary:
- If M$ accepts the counteroffer, they lose 20 million prospective customers. RedHat gains every OS manufacturer's dream: a million boxen, running on standardized configurations, and all in the hands of children. *Big* PR boost; Linux cause furthered; pays back big dividends, even if they have to take loans out.
- If M$ declines, they lose a damn sight more than 20 million customers, not to mention lost revenues from *giving away* their own software. They'll prolly still be stuck with the case, and the DoJ won't take it easy on them this time.
Once again, RH gains a big PR boost (amongst those who can read between the lines, at least), doubts are planted in the minds of loyal Microdrones as to the actual practices of Microsoft, but this is a lesser victory, as any gained customers will be in non-controlled environments, meaning total maintenance cost is through the roof. OTOH, they are the same customers who don't know how to do anything but click buttons and look at pretty colors, so they sell big volumes of boxed sets, and all the How-To guides sell off store shelves.
> The MS money could be used for any computer/OS. I don't see that in the RedHat proposal.
Oh, come on... we all *know* what the M$ money would purchase software-wise; either Macs (with the absurdly expensive OfficeXP for Mac) or PCs (with the almost-equally expensive WindowsXP in addition to the absurdly expensive office software).
RedHat can't *afford* to give out any product but its own; Microsoft has billions of dollars in the bank and this would be a drop in the bucket.
Slashdot Mirror
a) install a secure by default OS such as OpenBSD
:)
OpenBSD is as big a pile of crap as any other OS, if not admin'ed by a relatively clueful person. Just because the BSD people have numbers on their side that they can use to say they're "secure", OpenBSD boxen still do get r00ted (8 in the month of October alone, according to alldas.de).
The big "security bonus" seen when comparing the *BSDs to Linux is rooted in the fact that the intellectual cost of entry is higher for the BSDs (due to an even more profound lack of point-and-drool installers than are available for Linux), and thus, admins are more likely to be semi-qualified to be running a box in the first place.
b) LEAVE FTP disabled
Once again, if you've got the intelligence to even run a *NIX-ish OS, then you should be able to run even wu-ftpd if you keep track of bugtraq, vuln-dev, and other mailing lists.
c) LEAVE Telnet disabled
Agreed.
d) ENABLE SFTP if you need an FTPish connection.
I didn't even know of the existence of an SFTP *client* on my box (which I've been using for 14 months) until I checked for the manpage. All those running SFTP servers, raise your hands...
Just a reminder that you can't be truely secure with any operating system, service footprint, or ftp daemon...
> And there are very few security advisories.
:)
Mainly because there is nobody there to issue them... I agree that Slackware is a very fine distro, but last time I checked, they didn't have a team of zillions trolling vulnerability boards for potential problems.
This sort of thing was alluded to in Phrack #57, Phile #8 (on the now-infamous "this doesn't seem to be exploitable" Sudo exploit)...
here.
Definitely not your average script kiddie's reading material (it includes an indepth breakdown of malloc() and its ilk), but worth a read if you're interested.
@this-space-for-rent.com
How about "BottomlessMoneyPit"?
Can someone give a joe-user guide to helping test new kernels?
:)
/me stretches, getting ready for some extended typing...
"Don't."
You shouldn't really be testing new kernels unless you know what you're doing and you eat kernel compiles for breakfast (they go great with strawberries and low-fat milk). If you've mastered ksymoops, gdb (and its brother, kdb), and recovering a borken kernel, then have at it... just don't come complaining to me when your kernel panics.
FS corruption is FS corruption, you can't justify it at all, especially since this is supposed to be a stable kernel.
You shouldn't expect stability from the latest version of *anything* if it hasn't been out a day yet.
There is a difference, too; the iTunes bug resulted from bad shell script written for the installer on an in-house program written for their own flagship OS by a large, trusted company. This is a bug in a part of the kernel maintained by a small group of people working without pay for the project.
It can't be all that obscure if it's changed enough since the last revision to do damage now could it?
Uh... the changes were to fix a long-standing filesystem bug (albeit, one that didn't cause FS corruption). Granted, Linus should have tested the kernel first, but he was in a hurry to get 2.4.15/2.5.0 out.
Hopefilly, in the future, the development tree will open as soon as the next major stable release is made and we can avoid things like this.
;)
Same hope here, but don't keep your fingers crossed.
Eep... didn't mean to give myself +1. D'oh!
Come on guys, nobody is going to take linux seriously as long as problems like this -- or the VM saga -- keep popping up in supposedly stable kernels.
;)
Read my earlier post on the subject. This is not a stable kernel, as there is no development tree to iron out all the bugs. If you ask me, anyone who upgraded to something as bleeding-edge and untested as this (myself included) deserves to get burned a little bit as a warning that you don't really need the newest kernel.
The iTunes bug was a broken shell script; this is a bug in some obscure, not-very-often-modified C code in the core of the Linux kernel... there's a big difference.
Does this error occur on every architecture?
;)
Yep... since the affected files are in fs/, not arch/*, it's an architecture-independent problem. Good thing I have the Magic SysRq enabled.
Just like so many things with Linux, you'd think that this would be true, but it isn't. ;) There are two trees that are in development at all times:
;)
The "stable" tree (which has an even minor version number), and the "development" tree (which has an odd minor).
When kernel 2.2n.0 (n being a non-negative integer, in this case, 2) is released, development stops on 2.2n-1.x, and all newly-submitted-and-approved-by-Linus patches are applied to the 2.2n.x tree (because 2.2n-1.x is out of date). While 2.2n.x is still called the stable tree, it becomes the development tree (because some of the newly-patched stuff is untested, and there's no "development" tree to put it in). The "stable" role falls back to 2.2(n-1).0, in this case, the 2.2.x tree.
As far as this goes, it was a stroke of bad luck and hurried timing that this bug wasn't ironed out in 2.4.15-pre9 before it went final (and somewhat of a stroke of stupidity on the parts of the early adopters, myself included).
When 2.2n+1.0 is released, 2.2n continues development, making it the stable tree. Any fixes to bugs found in the 2.2n+1.x tree are back-merged to the current stable tree so that end-users can enjoy a stable, debugged kernel without riding the bleeding edge.
The problem with the Linux kernel numbering system is that the "stable" tree is only stable when there's a "development" tree to test the uncharted waters for it... if there isn't one, it's best to stay back a few revisions unless you like running fsck.
This bug was introduced when the kernel coders were trying to fix a bug that existed earlier (but, AFAIK, didn't cause fs corruption). It was introduced in pre9, but the final kernel was released within a few hours, so I guess nobody caught it in time.
It afflicts every filesystem. However, rebooting with the file /forcefsck extant forces it to run an fsck (and fix the corruption) on boot.
Also of help might be the Alt+SysRq keys; if you sync the drives and unmount them in single user mode before reboot, you should reduce or eliminate the corruption.
The Soviet Union was a powerful military country, and built 9 space stations. (Salyut 1-7, Mir, and now the ISS).
IIRC (which I might not, and I'm not going to check, because I'm a lazy, lazy man), Salyut 1-7 were just missions to a single space station (brought up with the first of the flights). Can someone confirm or deny this?
They're still pretty damn distant on an Earthly distance scale... :)
What do you get when you cross a rugby ball with a web-cam?
The lamest pr0n in the Universe?
If memory serves (as it often doesn't), Star Division (the German(?) company that originally produced StarOffice), went belly-up, but gave the rights to Sun to redistribute as they wished... not sure though. :P
My guess is that GameCubes with differently-colored casings may have been made on separate production lines, and thus, if one line is bad, it will only affect specifically-colored GameCubes.
Just my $0.02.
My guess is that the Slashdot editors do this to answer the eternal philosophical question:
"How many people who can't read 'use the mirrors' can fit over a 100MB pipe?"
:)
Actually, there was a thread or seven on the linux-kernel mailing list about this a couple months ago. However, it didn't go much of anywhere, as to upgrade a kernel on the fly would take some major code-fu (chucking variables into reserved spots in memory and hoping that you could keep track of them while you're running without a kernel)...
Well, if that is what the schools want to buy, who are we to tell them otherwise?
I'm not saying that the schools will want it, but they'll get it anyway. Microsoft will send marketroids to any dissenting school districts by the dozen preaching about the perceived advantages of Microsoft software. Since these are, by and large, school districts that are severely lacking in technology (and qualified professionals to run it, by the same logic), they will fall for it hook, line, and sinker. In addition, Microsoft has a lot of "wiggle room" (for lack of a better phrase) with which to offer, shall we say, special incentives (free software). As long as they're not doing this to large numbers of school districts, the "donation" goes off as planned, and they gain valuable mindshare, PR fodder, etc.
There are some problems with your argument, albeit ones that are easy to make.
;)
Red Hat is going to support 1 million PC's for free. How much would that cost?
All of which will be on standardized software and in groups of 70 or so per school. To support 70 identical PCs is no different from supporting 1 PC; the additional cost is only 69 more records in the database.
Do they realize the beating these machines take? Do they think that school teachers and librarians (who usually do the first line support) have any computer knowledge?
(Keep in mind, I don't work for RedHat, and don't even live in the same state as their offices)
I personally happen to be using RedHat now (7.1; I haven't taken the time to get 7.2 yet), and RedHat Network is a very high-class support scheme, possibly falling second only to Microsoft's omnipotent and ubiquitous Windows Update (which is only good because you're talking about a homogenized, monolithic OS, with an update program you can't escape). I prolly have about 100-150 non-standard packages installed on my computer (many being very, very alpha) and RHN keeps track of what's there well enough so that I can keep my system up to date.
Any school district worth its salt will have at least one technology professional. Even if they have to admin 700 boxen, all of the boxen are identical, so it can be made largely a "set-and-forget" affair with RHN.
This is insane. It's just a PR stunt.
IMHO, it isn't necessarily suicide. Consider the following:
1) This counterproposal most likely caught Microsoft off guard, and with the holiday season here, they may not have an official statement for a while.
2) This offer hasn't gotten much press (not even on the local news; I live near Seattle, btw) due to the events in Afghanistan.
3) If M$ accepts the counteroffer, they lose approximately 5 kids per computer per year that the computer is in operation... that's 5 kids who won't use Microsoft software times 1,000,000 boxen times maybe 3 or 4 years (at the least) that the boxen will be up.
All M$ will win back is the runoff, so to speak; the kids who grew up with Linux, hated it, and have now become Luddites. These children will require extensive hand-holding and support in the future when they are forced to use M$ products, which means their boxen will cost *far* more to maintain than those in a closed school environment.
4) If M$ declines the counteroffer, this whole mess is revealed to be nothing but some shady back-room dealing by Microsoft in an effort to escape monetary losses. This will leave them holding the bag for:
- 1 million personal computers
- Software to outfit these computers
- and, likely, the same case as before, as public outrage would prompt massive backlash at M$ *and* the DoJ
This will offend all school administrators offered these computers, not to mention pretty much every technology-informed person on Earth, or at least those who can put 1 and 1 together.
5) If their official statement comes after the Afghanistan situation cools down somewhat, then M$ will also lose every non-informed consumer who has access to a media outlet.
In summary:
- If M$ accepts the counteroffer, they lose 20 million prospective customers. RedHat gains every OS manufacturer's dream: a million boxen, running on standardized configurations, and all in the hands of children. *Big* PR boost; Linux cause furthered; pays back big dividends, even if they have to take loans out.
- If M$ declines, they lose a damn sight more than 20 million customers, not to mention lost revenues from *giving away* their own software. They'll prolly still be stuck with the case, and the DoJ won't take it easy on them this time.
Once again, RH gains a big PR boost (amongst those who can read between the lines, at least), doubts are planted in the minds of loyal Microdrones as to the actual practices of Microsoft, but this is a lesser victory, as any gained customers will be in non-controlled environments, meaning total maintenance cost is through the roof. OTOH, they are the same customers who don't know how to do anything but click buttons and look at pretty colors, so they sell big volumes of boxed sets, and all the How-To guides sell off store shelves.
Hope this post provides useful info.
-- Colin
> The MS money could be used for any computer/OS. I don't see that in the RedHat proposal.
Oh, come on... we all *know* what the M$ money would purchase software-wise; either Macs (with the absurdly expensive OfficeXP for Mac) or PCs (with the almost-equally expensive WindowsXP in addition to the absurdly expensive office software).
RedHat can't *afford* to give out any product but its own; Microsoft has billions of dollars in the bank and this would be a drop in the bucket.