The same is true of most Unices I've used, though. My AIX box defaults to everyone being in the same group and the defualt umask being 022. I'm not sure why users would immediately expect other people not to be able to read their files, especially when the same is true of Windows 9x by default:)
And if you're brining over existing ssh keys from another server? One that you're decomissioning or migrating from? Not everyone uses ssh-keygen...
Ok, that's clearer. The first time you run ssh on a Debian system the.ssh directory created isn't world readable, so if you're copying them across the network then the.ssh directory will already be unreadable to the attacker.
Now, cp will attempt to preserve the permissions of an original file within the constraints of your umask. With a umask of 022, a file with permissions of 600 will keep those permissions if you cp it somewhere. scp behaves in the same way. Unless you're doing something stupid like using cat to copy your keys around, it doesn't seem like a problem.
Say goodbye to working ssh under that arrangement, unless you've got the foresight to manually set your directories up properly. And what happens when you try to set your ssh keys up, expecting things to be secure? You've got a window of oppurtunity where another user on the system can get _all_ of your RSA information. Your personal and private keys are right there, ripe for the taking with just a simple "cp../joeuser/.ssh/* ~", and you'd never be the wiser.
From the source code to the ssh-keygen shipped with Debian 2.2, we have:
if (mkdir(dotsshdir, 0700)
error("Could not create directory '%s'.", dotsshdir);
Brief investigation reveals that the private RSA key is saved with permissions of 600
Question: do you have to check the Debian changelog for every package you install to make sure they're all secure? Isn't there an easier way?
Sure there is - you assume that your OS vendor knows what they're doing. Debian 2.2 was frozen for several months, during which they've had ample time to fix things. Unless you have reason to believe that they're incompetent, and in the absence of any security advisories telling you to upgrade a package, it's probably safe to assume that the problems have been fixed unless you have evidence to the contrary.
Now, in the case of somebody writing an article about a product, the onus is upon them to check their facts. The changelog is the obvious place to check them. What would you prefer Debian do?
Corel's package management tool was linked against both libqt (version 1, not 2) and libapt (Debian's package management library, and GPLed). This was construed as a breach of the GPL, but was sorted out after the maintainer of libapt gave permission for it to be used. As well as this, the beta agreement stated that further redistribution of the software (pretty much all GPLed, remember) was forbidden.
I don't know, though. They sound like mistakes made by people who haven't really checked the GPL properly on one hand and an overzealous legal department on the other. Both were resolved fairly amicably, so I wouldn't call it "screwing" Debian.
Having the source to the driver means that if I'm sufficiently clued, I can make the driver work with my Linux 7.2 system. If I'm not sufficiently clued, then I can learn. Not having the source means that I'll have to figure out how the entire card works, which is going to became sufficiently close to impossible in the near future that it's not worth it as cards become more complicated.
The Linux driver API is never going to be stable. Linus has said this. Even when the external API remains stable, the internal kernel structures may change. A module that compiles on both 2.2.12 and 2.2.16 may not work if I try to install one compiled under 2.2.12 on a 2.2.16 system. At the end of the day, the Linux kernel is open source. Anything that interfaces with the kernel and is not open source is going to increase the difficulty for users and is significantly more likely to cause problems.
For SGI, the incentive is pretty obvious. At the moment they produce machines with massive numbers of processors (we've a 256 node SGI here) and need an operating system to run on them. IRIX is massively better than Linux for this sort of thing at the moment, but using IRIX means that they have to deal with everything else associated with programming an OS rather than just the bits they're good at. By improving Linux sufficiently so that it has the same sort of level of performance as IRIX on massively parallel machines they can drop IRIX development and let someone else deal with most Linux bugs, saving themselves rather a lot of time and money in the process.
DOSEmu uses the host processor rather than providing x86 emulation, and so is pretty fast (GP2 is only slightly slower under DOSEmu than it was under plain DOS on the same machine). Are you thinking of Bochs?
In any case, Plex86 will again use the host processor rather than emulate it. Speed should be pretty good.
It's "emulation" of a virtual machine inside your own machine, not an emulation of DOS. Theoretically, you should be able to run anything that will run on your own machine on this without having to modify it. If you merely want DOS emulation, try Dosemu which has been around for ages and works wonderfully.
That's NetBSD. Linux PPC requires Open Firmware and PCI, but works fine on the 7200 which has Open Firmware and a 601. Note that the 7200 doesn't have a video driver in firmware, though, and as a result you need another machine connected via a serial cable to twiddle things.
Mozilla only includes a very primative program that uses the GTK widget. Galeon is a significantly more advanced program with the similar function of wrapping around the GTK widget and providing a user interface and other features.
Again, Linux is much more than a kernel. Qt is just as much a system library as Motif was for older versions of unix if and when distributions ship with Qt. That decision is entirely up to the distributions, not to GNU zealots and license police.
If you make the assumption that QT is a system library, you still fall foul of unless that component itself accompanies the executable. Sure, shipping KDE would be fine then, but you wouldn't be able to ship it with your distribution.
No, serious. I would have expected more hard core Linux users to install their system themselves. Is there something that is too hard to do yourself that prevents LFS from becoming as popular as e.g. Slackware?
I'd guess it's primarily because even hardcore Linux users want to utilise their time more efficiently. I know how to build a system from scratch, but have absolutely no desire whatsoever to do so. The same applies to packages - sure, I could spend ages downloading and compiling source, or I could just install the package. This is why I use Debian, which has a packaging system that works without randomly conflicting (or, at least, tells me it will before installing anything) and has packages containing most of the software I want to use.
This is X we're talking about - the server is the thing running on the local machine, while the clients are the things that are displayed on the server. Server-side anti-aliasing would allow the hardware to be used, whereas clients should know nothing about the underlying hardware as much as possible.
The main distribution of Debian is entirely free, but the Debian non-free section (not part of the distribution itself, but hosted on the mirrors and usable from the standard Debian tools) contains about as much non-free software as they can legally distribute. There's also a Debian package called "The virtual RMS" that will mail you every month telling you which non-free packages you have installed.
The ESS Maestro, Aureal Vortex and Trident 4DWave can all do this to varying degrees. The AudioPCI chips can play back 2 channels at once, although the second doesn't have as many capabilities as the first (it's meant for midi playback, since there's no hardware midi on them). It's not that rare an ability any more.
2) XMMS works fine with WindowMaker. You may need to switch off save unders in ~/GNUstep/Library/WindowMaker/Defaults/WindowMaker - this is in the FAQ, so you'll know this already.
3) XMMS runs fine here with 2.3.99pre2
4) If you can play MP3s, pretty much any other digital audio format should also work.
5) Those errors sound more like driver issues rather than anything else. What sort of card do you have?
If it was a webserver, then why the hell was it running sendmail? Do you really think a spammer, upon discovering this machine running an old version of sendmail, will think "Oh, that's a web server. I shouldn't abuse it"? The fact that it was running an insecure version of sendmail means that a spammer could have used it to blast thousands of messages to innocent people, using your bandwidth to do so. It's this sort of situation (people running mail daemons on machines that shouldn't be running them, and then not updating them because "oh, it's not the mail server. We don't have to worry about patching it") that's responsible for a good chunk of the spam problem.
The machines blocked are the rly-ip*.mx.aol.com ones, not the rest of the mx servers. Outgoing SMTP connections are transparantly proxied through the rly-ip servers - most legitimate traffic should be going through the other mx machines, so just blocking the rly-ip ones shouldn't cause a problem.
AOL recently implemented a scheme whereby any of their customers trying to deliver mail directly (as opposed to sending it through AOL's designated SMTP servers) is transparantly routed through another AOL mail server. Generally speaking, there's no legitimate reason for an AOL customer using any mail servers other than AOL's own - as a result, the mail going through these new servers is almost entirely spam (either being sent directly to the recipients mailboxes, or originally destined to go through some poor sap's open relay). It's these servers that AOL have requested be added to ORBS, not their normal mail servers. Even if you use ORBS, you should still get all legitimate AOL mail sent through AOL's main mail servers.
In terms of integer performance, a 133MHz 6x86 is approximately as fast as a Pentium at 166MHz. The FPU performance is distinctly worse, though (along with pretty much every Intel clone up until the Athlon). I don't have any problem with what Cyrix did - they never tried to pretend that the chip wasn't really a 133, but if they'd simply marketed it as a 133MHz Cyrix then nobody would have bought the things. If the Fry's person tried to sell it to you as a 166MHz processor, though, you probably have the right to his first born son. Or something like that.
Slashdot Mirror
The same is true of most Unices I've used, though. My AIX box defaults to everyone being in the same group and the defualt umask being 022. I'm not sure why users would immediately expect other people not to be able to read their files, especially when the same is true of Windows 9x by default :)
And if you're brining over existing ssh keys from another server? One that you're decomissioning or migrating from? Not everyone uses ssh-keygen...
.ssh directory created isn't world readable, so if you're copying them across the network then the .ssh directory will already be unreadable to the attacker.
Ok, that's clearer. The first time you run ssh on a Debian system the
Now, cp will attempt to preserve the permissions of an original file within the constraints of your umask. With a umask of 022, a file with permissions of 600 will keep those permissions if you cp it somewhere. scp behaves in the same way. Unless you're doing something stupid like using cat to copy your keys around, it doesn't seem like a problem.
From the source code to the ssh-keygen shipped with Debian 2.2, we have:
if (mkdir(dotsshdir, 0700)
error("Could not create directory '%s'.", dotsshdir);
Brief investigation reveals that the private RSA key is saved with permissions of 600
fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0600);
Now, could you possibly elaborate on the security issues with SSH that exist here?
Sure there is - you assume that your OS vendor knows what they're doing. Debian 2.2 was frozen for several months, during which they've had ample time to fix things. Unless you have reason to believe that they're incompetent, and in the absence of any security advisories telling you to upgrade a package, it's probably safe to assume that the problems have been fixed unless you have evidence to the contrary.
Now, in the case of somebody writing an article about a product, the onus is upon them to check their facts. The changelog is the obvious place to check them. What would you prefer Debian do?
Corel's package management tool was linked against both libqt (version 1, not 2) and libapt (Debian's package management library, and GPLed). This was construed as a breach of the GPL, but was sorted out after the maintainer of libapt gave permission for it to be used. As well as this, the beta agreement stated that further redistribution of the software (pretty much all GPLed, remember) was forbidden.
I don't know, though. They sound like mistakes made by people who haven't really checked the GPL properly on one hand and an overzealous legal department on the other. Both were resolved fairly amicably, so I wouldn't call it "screwing" Debian.
Having the source to the driver means that if I'm sufficiently clued, I can make the driver work with my Linux 7.2 system. If I'm not sufficiently clued, then I can learn. Not having the source means that I'll have to figure out how the entire card works, which is going to became sufficiently close to impossible in the near future that it's not worth it as cards become more complicated.
The Linux driver API is never going to be stable. Linus has said this. Even when the external API remains stable, the internal kernel structures may change. A module that compiles on both 2.2.12 and 2.2.16 may not work if I try to install one compiled under 2.2.12 on a 2.2.16 system. At the end of the day, the Linux kernel is open source. Anything that interfaces with the kernel and is not open source is going to increase the difficulty for users and is significantly more likely to cause problems.
For SGI, the incentive is pretty obvious. At the moment they produce machines with massive numbers of processors (we've a 256 node SGI here) and need an operating system to run on them. IRIX is massively better than Linux for this sort of thing at the moment, but using IRIX means that they have to deal with everything else associated with programming an OS rather than just the bits they're good at. By improving Linux sufficiently so that it has the same sort of level of performance as IRIX on massively parallel machines they can drop IRIX development and let someone else deal with most Linux bugs, saving themselves rather a lot of time and money in the process.
DOSEmu uses the host processor rather than providing x86 emulation, and so is pretty fast (GP2 is only slightly slower under DOSEmu than it was under plain DOS on the same machine). Are you thinking of Bochs?
In any case, Plex86 will again use the host processor rather than emulate it. Speed should be pretty good.
It's "emulation" of a virtual machine inside your own machine, not an emulation of DOS. Theoretically, you should be able to run anything that will run on your own machine on this without having to modify it. If you merely want DOS emulation, try Dosemu which has been around for ages and works wonderfully.
That's NetBSD. Linux PPC requires Open Firmware and PCI, but works fine on the 7200 which has Open Firmware and a 601. Note that the 7200 doesn't have a video driver in firmware, though, and as a result you need another machine connected via a serial cable to twiddle things.
Mozilla only includes a very primative program that uses the GTK widget. Galeon is a significantly more advanced program with the similar function of wrapping around the GTK widget and providing a user interface and other features.
You've missed off a zero there. Try $750,000 and things look more sensible.
Again, Linux is much more than a kernel. Qt is just as much a system library as Motif was for older versions of unix if and when distributions ship with Qt. That decision is entirely up to the distributions, not to GNU zealots and license police.
If you make the assumption that QT is a system library, you still fall foul of unless that component itself accompanies the executable. Sure, shipping KDE would be fine then, but you wouldn't be able to ship it with your distribution.
No, serious. I would have expected more hard core Linux users to install their system themselves. Is there something that is too hard to do yourself that prevents LFS from becoming as popular as e.g. Slackware?
I'd guess it's primarily because even hardcore Linux users want to utilise their time more efficiently. I know how to build a system from scratch, but have absolutely no desire whatsoever to do so. The same applies to packages - sure, I could spend ages downloading and compiling source, or I could just install the package. This is why I use Debian, which has a packaging system that works without randomly conflicting (or, at least, tells me it will before installing anything) and has packages containing most of the software I want to use.
This is X we're talking about - the server is the thing running on the local machine, while the clients are the things that are displayed on the server. Server-side anti-aliasing would allow the hardware to be used, whereas clients should know nothing about the underlying hardware as much as possible.
The main distribution of Debian is entirely free, but the Debian non-free section (not part of the distribution itself, but hosted on the mirrors and usable from the standard Debian tools) contains about as much non-free software as they can legally distribute. There's also a Debian package called "The virtual RMS" that will mail you every month telling you which non-free packages you have installed.
The ESS Maestro, Aureal Vortex and Trident 4DWave can all do this to varying degrees. The AudioPCI chips can play back 2 channels at once, although the second doesn't have as many capabilities as the first (it's meant for midi playback, since there's no hardware midi on them). It's not that rare an ability any more.
The HFSS partition isn't necessary - we use yaboot over TFTP without any problems.
1) GNOME isn't a window manager.
r - this is in the FAQ, so you'll know this already.
2) XMMS works fine with WindowMaker. You may need to switch off save unders in ~/GNUstep/Library/WindowMaker/Defaults/WindowMake
3) XMMS runs fine here with 2.3.99pre2
4) If you can play MP3s, pretty much any other digital audio format should also work.
5) Those errors sound more like driver issues rather than anything else. What sort of card do you have?
The proxies that port 25 is redirected to are called rly-ip* and aren't used for anything else. They're the only ones listed.
If it was a webserver, then why the hell was it running sendmail? Do you really think a spammer, upon discovering this machine running an old version of sendmail, will think "Oh, that's a web server. I shouldn't abuse it"? The fact that it was running an insecure version of sendmail means that a spammer could have used it to blast thousands of messages to innocent people, using your bandwidth to do so. It's this sort of situation (people running mail daemons on machines that shouldn't be running them, and then not updating them because "oh, it's not the mail server. We don't have to worry about patching it") that's responsible for a good chunk of the spam problem.
The machines blocked are the rly-ip*.mx.aol.com ones, not the rest of the mx servers. Outgoing SMTP connections are transparantly proxied through the rly-ip servers - most legitimate traffic should be going through the other mx machines, so just blocking the rly-ip ones shouldn't cause a problem.
The servers being discussed here are in MAPS as well.
AOL recently implemented a scheme whereby any of their customers trying to deliver mail directly (as opposed to sending it through AOL's designated SMTP servers) is transparantly routed through another AOL mail server. Generally speaking, there's no legitimate reason for an AOL customer using any mail servers other than AOL's own - as a result, the mail going through these new servers is almost entirely spam (either being sent directly to the recipients mailboxes, or originally destined to go through some poor sap's open relay). It's these servers that AOL have requested be added to ORBS, not their normal mail servers. Even if you use ORBS, you should still get all legitimate AOL mail sent through AOL's main mail servers.
In terms of integer performance, a 133MHz 6x86 is approximately as fast as a Pentium at 166MHz. The FPU performance is distinctly worse, though (along with pretty much every Intel clone up until the Athlon). I don't have any problem with what Cyrix did - they never tried to pretend that the chip wasn't really a 133, but if they'd simply marketed it as a 133MHz Cyrix then nobody would have bought the things. If the Fry's person tried to sell it to you as a 166MHz processor, though, you probably have the right to his first born son. Or something like that.