Good. Public money is paying for your university links to be used for academic purposes, not sharing music and movies. If you want a Linux distro, ask your administrators to mirror the appropriate distro locally (so everyone only has to get it once), or better still - offer to run a student server for this kind of purpose. Then the file sharing done from that server will at least be accountable. It's very easy to set up a local mirror - most distros provide rsync servers somewhere, and you can rsync it daily using very little bandwidth. All legitimate file sharing can easily be done that way.
Toyota don't dispose of the batteries, they recycle them. They aren't throwing the heavy metals in a hole somewhere. (Another poster mentioned they pay a $200 bounty for bringing the battery for recycling as an incentive).
The size of the US has little to do with it. It's more the structure of cities. I used to live in Houston - with its sprawl-by-design public transport is almost impractical. Compare the structure of Houston with the structure of the Bay Area in California and the difference is like night and day (the Bay Area has a workable public transport system).
Re:Sensationalist Journalism?
on
A Flu Pandemic?
·
· Score: 1
And flu is fairly dangerous anyway (at least to the more vulnerable). I heard on the radio the other day that 10,000 people a year die of flu in Britain - three times as many as die in car accidents.
Well SOMETHING must have improved then (the sugar content of our typical diet has not). Most the people of my Dad's generation had a mouthful of fillings by the time they were 30. Most the people in my generation are still filling-free at the age of 30. If it hasn't been flouride toothpaste, then what was it? The same dental advice (brush, floss etc.) was given out when my dad was a kid too.
Well, not quite. If you don't brush at all (especially with the typical sugary diet) you'll get cavities in no time.
One of the important things about toothpaste in general is the flouride. The flouride helps calcium present in your saliva precipitate out, and prevent incipient cavities from worsening. My Dad by the time he was 20 had many fillings. Thanks to the better toothpaste formulations, I'm 33 and still don't have a single filling - no tooth pain - no gum bleeding. I don't religiously floss my teeth every day either. Just brush my teeth with flouride toothpaste after each meal.
Beauty is in the eye of the beholder. A lot of people complain about the Windows default theme (Fisher Price and Teletubbies combined). I rather like the earthy theme of Ubuntu. It's only a couple of mouse clicks to change it - just as it's only a couple of mouse clicks to change from the much disliked Windows teletubbies theme.
Of course that means you are paying twice for Windows - once for the OEM pre-install, and once for your corporate rental agreement. So Microsoft probably doesn't care - you'll get to pay for Vista even if you just blow it away with your corporate WinXP image.
The interesting thing is that MS Research does do a lot of truly interesting pieces of research - but the funny thing is, despite this, MS itself uses few to none of the fruits of this research, preferring instead to just buy up other companies and copy other technologies.
Fortunately, we don't have the RIP act here in the Isle of Man.
I wonder if the RIP Act essentially criminalizes automatically keyed systems such as SSH and IPsec? You can't reveal the key on traffic they might have sniffed because you don't actually know it.
Based on this, the Police can essentially arrest and imprison most system administrators in the land.
Look at the top (usually, it either has an X or K on top - this is actually to allow the capacitor to deform rather than explode). If the top of the capacitor is flat, it's probably good. If the top of the capacitor is showing any bulge at all, it's probably bad. Definitely if brown goo is coming out.
We hae 75 or so HP (Compaq design, hence Hewlett-Paqard) d530 USDT desktops (the ultra slim desktop). These have had two problems which have required the replacement of every single motherboard under warranty and about 30% of the hard disks.
Firstly, the design for cooling is terrible - the hard drive bay has a fan by it, but it is blocked by the structure of the bay, so the hard disk essentially is uncooled. The Maxtor low profile drives seemed to be very susceptible to heat - we had a failure rate on hard disks of around 20% of our installed base. (The d530 USDT generally runs very hot).
After 9 months of having the machines in use, then the capacitors began to fail - either just bulging (and then one day, the machine wouldn't boot) or actually bursting (not explosively, just seeping electrolyte). Our HP agent ended up replacing every single motherboard under warranty after the failure rate reached 30% in less than a year of use.
I have to wonder if it was lowest-bidder parts. So much for getting reliability when buying a name-brand.
Unfortunately, you're probably too late to get pre-iTunes 6 (jHymn is broken now in iTunes 6). I buy from iTMS and immediately strip off the DRM with jHymn. I won't upgrade iTunes until JHymn can remove DRM from the files. I don't do this to pirate the music, but so I can play it on any of my computers (unencrypted AAC is a standard format - Xine plays it very nicely on Linux). You get to keep all the metadata with iTunes+JHymn.
Hopefully the encryption in iTunes 6 will be broken soon so I can upgrade. If at any time I'm forced to upgrade to a version of iTunes where I can no longer remove the DRM, this is the point at which I stop using iTMS.
Unfortunately, the record companies seem to believe they are giving us a 'privilege' to play music on non-Windows systems. This is not so. It is actually us who are giving them the privilege of receiving our money. As soon as record companies break things such that I can't store and play the music I paid for how I want to, I will revoke their privilege of receiving my money.
The thing is *it doesn't work*. Nvidia provide a closed source driver by having a wrapper. Not having a stable kernel interface does not stop binary only drivers. If that's its goal, the phrase "cutting off your nose to spite your face" springs to mind.
The only group that the lack of a stable ABI hurts is end users. I use some open source drivers that are not in the 2.6.9.x kernel that CentOS uses. Guess what - each new kernel that CentOS pushes out, I get to have to rebuild and re-install all these drivers. It's a pain in the arse I could do without, especially as it is totally ineffective at achieving its desired goals (preventing closed source drivers) as nvidia has proved. If you hurt end users this way, you guarantee that Linux adoption won't happen.
And what happens to VMware when your distribution packages up a new kernel with a minor version number change? They have to re-install the driver. I use an open source kernel module (FUSE) and since the distro I use is 2.6.9.x (and FUSE is not in that kernel), every time they push out a bug fix kernel update, I get to re-install the driver. It's an additional manual step I could do without.
The whole thing about forcing all drivers to be open source is a red herring; nvidia provide a closed source driver by adding an open source abstraction layer (which you have to re-install each time you get a new kernel).
The only group that not having a stable kernel ABI hurts is the user. It doesn't stop people writing closed source drivers with wrappers.
I use some open source drivers that are not in my kernel yet (the CentOS kernels), and won't be in this release. However, each time I get a kernel update, I have to rebuild the open source FUSE drivers and reinstall them. It's a pain in the ass.
If there is one thing I would fix about Linux is the development model. A 'stable' kernel series (say, 2.6) would have a stable API for kernel modules. So if you build a module for 2.6.0, it still works with 2.6.9. 2.6 would be bug fixes only - no new features in the kernel. You wouldn't need to put new features in a stable kernel series if it was done this way, because distros and end users can build modules and have a reasonable chance of them working for the entire kernel series without needing a rebuild.
Alternately, a method to automatically rebuild all 3rd party or add-on kernel modules as part of an upgrade could be made by a distribution maker, so you install the module as source, and distribution tools build them, then rebuild them for each kernel.
Manufacturers can _already_ use binary drivers, (nVidia already does) by providing their own abstraction layer, so this argument is a complete red herring. A stable kernel ABI helps _end users_ the most.
Gah. If you think this is 'testing for memorization of language details', you cannot ever claim to be an experienced C programmer (i.e. the people the original poster is interviewing). The answer is blindingly and instantly obvious to any (genuinely) experienced C programmer who should be able to point out two fatal flaws with that code snippet without even having to think about it, and what's more, explain cogently why those flaws are indeed fatal.
I wouldn't hire a C programmer who passed themselves off as 'experienced' if they couldn't instantly spot what was wrong with that code.
No. Chmodding wget will stop wget working. Although this will frustrate automated scripts and probably worms, it won't stop your own users from writing a CGI script that does what wget does. Or even a more advanced cracker from doing just the same.
However, you can use SElinux to limit what programs can create and use sockets. If you create a SElinux policy that forbids sockets and apply it to anything that Apache is going to load, and probably Apache itself, you can close off that vulnerability. Alternately (or in addition) you can use iptables rules to prevent outbound access (i.e. egress filtering).
I think another article recently pointed this out - but enumerating badness often doesn't work. The stance you really need to take is everything is bad unless I specifically say it is good - i.e. take a position of 'default deny'. How strong your default deny position is depends on what kind of service you are running. However, strong egress filtering is possible for virtually every web server without breaking the stuff that should legitimately be running.
With this exploit, it doesn't matter what the user's shell is set to (the exploit will most likely run as user 'nobody').
If you give people CGI access, you have essentially given them shell access (doubly so if you use mod_suexec so the CGI programs run as their username), and changing the user's shell to/usr/bin/false is entirely ineffective. You need to be using SElinux, not have tools like 'wget' installed, and have strict egress filtering on your web server if you want to neutralise the shell accounts that your users can gain themselves.
Slashdot Mirror
Good. Public money is paying for your university links to be used for academic purposes, not sharing music and movies. If you want a Linux distro, ask your administrators to mirror the appropriate distro locally (so everyone only has to get it once), or better still - offer to run a student server for this kind of purpose. Then the file sharing done from that server will at least be accountable. It's very easy to set up a local mirror - most distros provide rsync servers somewhere, and you can rsync it daily using very little bandwidth. All legitimate file sharing can easily be done that way.
Only 1 to 2MByte/sec from kernel.org? I've seen 4MByte/sec to my regular, commercial Internet server from kernel.org.
Toyota don't dispose of the batteries, they recycle them. They aren't throwing the heavy metals in a hole somewhere. (Another poster mentioned they pay a $200 bounty for bringing the battery for recycling as an incentive).
You can ride a motorbike instead. Many small motorcycles weigh not that much more than the human riding them.
The size of the US has little to do with it. It's more the structure of cities. I used to live in Houston - with its sprawl-by-design public transport is almost impractical. Compare the structure of Houston with the structure of the Bay Area in California and the difference is like night and day (the Bay Area has a workable public transport system).
And flu is fairly dangerous anyway (at least to the more vulnerable). I heard on the radio the other day that 10,000 people a year die of flu in Britain - three times as many as die in car accidents.
Well SOMETHING must have improved then (the sugar content of our typical diet has not). Most the people of my Dad's generation had a mouthful of fillings by the time they were 30. Most the people in my generation are still filling-free at the age of 30. If it hasn't been flouride toothpaste, then what was it? The same dental advice (brush, floss etc.) was given out when my dad was a kid too.
Well, not quite. If you don't brush at all (especially with the typical sugary diet) you'll get cavities in no time.
One of the important things about toothpaste in general is the flouride. The flouride helps calcium present in your saliva precipitate out, and prevent incipient cavities from worsening. My Dad by the time he was 20 had many fillings. Thanks to the better toothpaste formulations, I'm 33 and still don't have a single filling - no tooth pain - no gum bleeding. I don't religiously floss my teeth every day either. Just brush my teeth with flouride toothpaste after each meal.
Beauty is in the eye of the beholder. A lot of people complain about the Windows default theme (Fisher Price and Teletubbies combined). I rather like the earthy theme of Ubuntu. It's only a couple of mouse clicks to change it - just as it's only a couple of mouse clicks to change from the much disliked Windows teletubbies theme.
The Ubuntu installer is actually easier than the RedHat one. Why does it need to be running in graphics mode?
Of course that means you are paying twice for Windows - once for the OEM pre-install, and once for your corporate rental agreement. So Microsoft probably doesn't care - you'll get to pay for Vista even if you just blow it away with your corporate WinXP image.
The interesting thing is that MS Research does do a lot of truly interesting pieces of research - but the funny thing is, despite this, MS itself uses few to none of the fruits of this research, preferring instead to just buy up other companies and copy other technologies.
Fortunately, we don't have the RIP act here in the Isle of Man.
I wonder if the RIP Act essentially criminalizes automatically keyed systems such as SSH and IPsec? You can't reveal the key on traffic they might have sniffed because you don't actually know it.
Based on this, the Police can essentially arrest and imprison most system administrators in the land.
Look at the top (usually, it either has an X or K on top - this is actually to allow the capacitor to deform rather than explode). If the top of the capacitor is flat, it's probably good. If the top of the capacitor is showing any bulge at all, it's probably bad. Definitely if brown goo is coming out.
We hae 75 or so HP (Compaq design, hence Hewlett-Paqard) d530 USDT desktops (the ultra slim desktop). These have had two problems which have required the replacement of every single motherboard under warranty and about 30% of the hard disks.
Firstly, the design for cooling is terrible - the hard drive bay has a fan by it, but it is blocked by the structure of the bay, so the hard disk essentially is uncooled. The Maxtor low profile drives seemed to be very susceptible to heat - we had a failure rate on hard disks of around 20% of our installed base. (The d530 USDT generally runs very hot).
After 9 months of having the machines in use, then the capacitors began to fail - either just bulging (and then one day, the machine wouldn't boot) or actually bursting (not explosively, just seeping electrolyte). Our HP agent ended up replacing every single motherboard under warranty after the failure rate reached 30% in less than a year of use.
I have to wonder if it was lowest-bidder parts. So much for getting reliability when buying a name-brand.
Unfortunately, you're probably too late to get pre-iTunes 6 (jHymn is broken now in iTunes 6).
I buy from iTMS and immediately strip off the DRM with jHymn. I won't upgrade iTunes until JHymn can remove DRM from the files. I don't do this to pirate the music, but so I can play it on any of my computers (unencrypted AAC is a standard format - Xine plays it very nicely on Linux). You get to keep all the metadata with iTunes+JHymn.
Hopefully the encryption in iTunes 6 will be broken soon so I can upgrade. If at any time I'm forced to upgrade to a version of iTunes where I can no longer remove the DRM, this is the point at which I stop using iTMS.
Unfortunately, the record companies seem to believe they are giving us a 'privilege' to play music on non-Windows systems. This is not so. It is actually us who are giving them the privilege of receiving our money. As soon as record companies break things such that I can't store and play the music I paid for how I want to, I will revoke their privilege of receiving my money.
The thing is *it doesn't work*. Nvidia provide a closed source driver by having a wrapper. Not having a stable kernel interface does not stop binary only drivers. If that's its goal, the phrase "cutting off your nose to spite your face" springs to mind.
The only group that the lack of a stable ABI hurts is end users. I use some open source drivers that are not in the 2.6.9.x kernel that CentOS uses. Guess what - each new kernel that CentOS pushes out, I get to have to rebuild and re-install all these drivers. It's a pain in the arse I could do without, especially as it is totally ineffective at achieving its desired goals (preventing closed source drivers) as nvidia has proved. If you hurt end users this way, you guarantee that Linux adoption won't happen.
And what happens to VMware when your distribution packages up a new kernel with a minor version number change? They have to re-install the driver. I use an open source kernel module (FUSE) and since the distro I use is 2.6.9.x (and FUSE is not in that kernel), every time they push out a bug fix kernel update, I get to re-install the driver. It's an additional manual step I could do without.
The whole thing about forcing all drivers to be open source is a red herring; nvidia provide a closed source driver by adding an open source abstraction layer (which you have to re-install each time you get a new kernel).
The only group that not having a stable kernel ABI hurts is the user. It doesn't stop people writing closed source drivers with wrappers.
It's not just binary drivers.
I use some open source drivers that are not in my kernel yet (the CentOS kernels), and won't be in this release. However, each time I get a kernel update, I have to rebuild the open source FUSE drivers and reinstall them. It's a pain in the ass.
If there is one thing I would fix about Linux is the development model. A 'stable' kernel series (say, 2.6) would have a stable API for kernel modules. So if you build a module for 2.6.0, it still works with 2.6.9. 2.6 would be bug fixes only - no new features in the kernel. You wouldn't need to put new features in a stable kernel series if it was done this way, because distros and end users can build modules and have a reasonable chance of them working for the entire kernel series without needing a rebuild.
Alternately, a method to automatically rebuild all 3rd party or add-on kernel modules as part of an upgrade could be made by a distribution maker, so you install the module as source, and distribution tools build them, then rebuild them for each kernel.
Manufacturers can _already_ use binary drivers, (nVidia already does) by providing their own abstraction layer, so this argument is a complete red herring. A stable kernel ABI helps _end users_ the most.
I couldn't find such a page on the website - can you put a link to 'Common creationist mistakes?'
How does a Kiwi find his sheep in six foot tall grass?
Very nice, thank you.
If the human race innately took your attitude, we'd still be living in caves.
Gah. If you think this is 'testing for memorization of language details', you cannot ever claim to be an experienced C programmer (i.e. the people the original poster is interviewing). The answer is blindingly and instantly obvious to any (genuinely) experienced C programmer who should be able to point out two fatal flaws with that code snippet without even having to think about it, and what's more, explain cogently why those flaws are indeed fatal.
I wouldn't hire a C programmer who passed themselves off as 'experienced' if they couldn't instantly spot what was wrong with that code.
No. Chmodding wget will stop wget working. Although this will frustrate automated scripts and probably worms, it won't stop your own users from writing a CGI script that does what wget does. Or even a more advanced cracker from doing just the same.
However, you can use SElinux to limit what programs can create and use sockets. If you create a SElinux policy that forbids sockets and apply it to anything that Apache is going to load, and probably Apache itself, you can close off that vulnerability. Alternately (or in addition) you can use iptables rules to prevent outbound access (i.e. egress filtering).
I think another article recently pointed this out - but enumerating badness often doesn't work. The stance you really need to take is everything is bad unless I specifically say it is good - i.e. take a position of 'default deny'. How strong your default deny position is depends on what kind of service you are running. However, strong egress filtering is possible for virtually every web server without breaking the stuff that should legitimately be running.
With this exploit, it doesn't matter what the user's shell is set to (the exploit will most likely run as user 'nobody').
/usr/bin/false is entirely ineffective. You need to be using SElinux, not have tools like 'wget' installed, and have strict egress filtering on your web server if you want to neutralise the shell accounts that your users can gain themselves.
If you give people CGI access, you have essentially given them shell access (doubly so if you use mod_suexec so the CGI programs run as their username), and changing the user's shell to