The Linux administrators faced some out of the ordinary challenges, not faced by most Linux admins, while the Windows admins faced none.
For example, most of the time difference between Windows and Linux was spent upgrading gLibC, something that you're really not supposed to do. It's comparable to trying to manually upgrade parts of a Windows 98 system to run a program that required XP, rather than actually upgrading to XP.
Then, you had the Linux admins getting updates from 4 different sources, rather than just from SuSE's repositories, which is also out of the ordinary, while the Windows admins only visited Windows Update, which only supplies patches to the base operating system, when in reality they'll have to get updates from many other sources if they wanted to keep their apps up to date.
Let customers download the MP3s via a server side script which quietly puts their customer number for tracking and a hash for non-repudiation into the ID3 tags, which'll survive most transcoding. Then if it appears on a P2P network (not likely, unless it's not already there), they'll know who did it.
I'll pay more for some songs than I would for others. There are a lot of old, good songs that I wouldn't buy for 99 cents, but which I might buy for a bit less. Consumers get fairer prices, and record companies see more profits due to the increased sales. Too bad for the musicians though. They'll still see an average of 2-3% of revenue.
Music stores don't sell all their CDs at the same price. And you wouldn't run an online software store where every program was $99. It's simple economics. You charge what people will pay, attempting to maximize profit.
I suppose they could try to force this by raising the price of ad-free Windows, if Microsoft were evil. OEMs will get ad supported Windows for free, or even be paid to install it. If they are paid to install it, I'd happily buy a new Windows PC and install Linux over it, if they don't lock me out.
1) Fast prototype the system. Get a version out as quick as I can that will meet all the basic requirements. 2) It works! Client likes it, wonders why they should pay you to write it a second time, without adding any features.
If the system can do page remapping (is that the right term?), then dynamic allocation is acceptable for the most part. Non-contiguous free pages can be grouped together to satisfy requests for large contiguous chunks of ram. malloc() is pretty fast in some implementations. A very, very fast alternative you can try in some cases is alloca(), which in gcc is an intrinsic function that produces only around 2-3 instructions that allocate a variable amount of ram from the stack, which is freed when the function exits.
Something else of interest is Java. It'll be slow, but its garbage collection compacts, so that you can allocate chunks of memory up to your total free, not limited to the largest contiguous block, and without any waste caused by fragmentation. Allocation is also very fast, since free memory is kept in one contiguous chunk, which it pulls from linearly until it needs to do another garbage collection. I'm not saying to use Java, but a garbage collector in that style overcomes the severe fragmentation problem that comes with having a system that doesn't support page remapping.
The ones where I just replaced all the hard disks are now running 2.6. They were 2.4 just a week ago. Also, our backup server is running 2.6 without trouble, but we've had it only a couple months. Red Hat has been sticking with 2.6.9 for about the past year, avoiding newer releases. Unfortunately SMART monitoring of SATA drives isn't supported yet, though experimental kernel patches are available. I probably should have noticed that before choosing SATA drives over IDE. Someone thought it'd be cool to make Linux think SATA drives were SCSI. Aside from that, all is going well.
Do they have to? How often are there kernel vulnerabilities that can be exploited remotely? How many of the other bug fixes apply to them if they haven't encountered any serious bugs in the past year? When a server gets old enough, the thought of shutting it down gets a little scary. Maybe it won't come back up, or some intervention will be necessary.
I think my XP Home desktop has been up longer than your Windows servers. But my experience is pretty much the same. Our Windows 2003 server wants to reboot any time updates are installed. Our Linux machines generally boot up the day they're born and shut down when their hardware fails. Services can be patched with less than a second of downtime. An exception is that we just upgraded all the hard drives in our file servers, reinstalling the latest CentOS on each, but I managed to do it with zero downtime.
$1 million for this semi-supercomputer running the tried and tested server operating system Linux, under an open source license. Or $2 million for the same supercomputer running a server variant of the popular desktop operating system Windows, same performance, assuming advertisements don't lie, and under a license which limits the possibility of tweaking. Which will the client choose?
Will they replace the infected CD's? Compensate users? I suppose a class action suit will someday decide the latter, but most of it will go to the lawyers.
Slashdot Mirror
I haven't heard good things about NFS security, or NFS performance on Linux.
The Linux administrators faced some out of the ordinary challenges, not faced by most Linux admins, while the Windows admins faced none.
For example, most of the time difference between Windows and Linux was spent upgrading gLibC, something that you're really not supposed to do. It's comparable to trying to manually upgrade parts of a Windows 98 system to run a program that required XP, rather than actually upgrading to XP.
Then, you had the Linux admins getting updates from 4 different sources, rather than just from SuSE's repositories, which is also out of the ordinary, while the Windows admins only visited Windows Update, which only supplies patches to the base operating system, when in reality they'll have to get updates from many other sources if they wanted to keep their apps up to date.
Do you think this was a fair study?
Ironically, circumventing the rootkit is illegal, according to the DMCA, one of those few laws that was passed with a unanimous vote in Congress.
They call that RAD.
How many people hack into users' systems to steal MP3's?
Get a pin. Stab the RFID tag.
But it's just an ID badge, so what's the fuss? They didn't implant it in his skin or anything.
Let customers download the MP3s via a server side script which quietly puts their customer number for tracking and a hash for non-repudiation into the ID3 tags, which'll survive most transcoding. Then if it appears on a P2P network (not likely, unless it's not already there), they'll know who did it.
I'll pay more for some songs than I would for others. There are a lot of old, good songs that I wouldn't buy for 99 cents, but which I might buy for a bit less. Consumers get fairer prices, and record companies see more profits due to the increased sales. Too bad for the musicians though. They'll still see an average of 2-3% of revenue.
Music stores don't sell all their CDs at the same price. And you wouldn't run an online software store where every program was $99. It's simple economics. You charge what people will pay, attempting to maximize profit.
I suppose they could try to force this by raising the price of ad-free Windows, if Microsoft were evil. OEMs will get ad supported Windows for free, or even be paid to install it. If they are paid to install it, I'd happily buy a new Windows PC and install Linux over it, if they don't lock me out.
Also tell them how many bosses you have.
They're just pirating up a storm aren't they?
Use a needle silly.
Hence the real world model:
1) Fast prototype the system. Get a version out as quick as I can that will meet all the basic requirements.
2) It works! Client likes it, wonders why they should pay you to write it a second time, without adding any features.
If the system can do page remapping (is that the right term?), then dynamic allocation is acceptable for the most part. Non-contiguous free pages can be grouped together to satisfy requests for large contiguous chunks of ram. malloc() is pretty fast in some implementations. A very, very fast alternative you can try in some cases is alloca(), which in gcc is an intrinsic function that produces only around 2-3 instructions that allocate a variable amount of ram from the stack, which is freed when the function exits.
Something else of interest is Java. It'll be slow, but its garbage collection compacts, so that you can allocate chunks of memory up to your total free, not limited to the largest contiguous block, and without any waste caused by fragmentation. Allocation is also very fast, since free memory is kept in one contiguous chunk, which it pulls from linearly until it needs to do another garbage collection. I'm not saying to use Java, but a garbage collector in that style overcomes the severe fragmentation problem that comes with having a system that doesn't support page remapping.
Luckily I don't use our 2003 server as my personal desktop for browsing possibly malicious websites.
The ones where I just replaced all the hard disks are now running 2.6. They were 2.4 just a week ago. Also, our backup server is running 2.6 without trouble, but we've had it only a couple months. Red Hat has been sticking with 2.6.9 for about the past year, avoiding newer releases. Unfortunately SMART monitoring of SATA drives isn't supported yet, though experimental kernel patches are available. I probably should have noticed that before choosing SATA drives over IDE. Someone thought it'd be cool to make Linux think SATA drives were SCSI. Aside from that, all is going well.
Do they have to? How often are there kernel vulnerabilities that can be exploited remotely? How many of the other bug fixes apply to them if they haven't encountered any serious bugs in the past year? When a server gets old enough, the thought of shutting it down gets a little scary. Maybe it won't come back up, or some intervention will be necessary.
I think my XP Home desktop has been up longer than your Windows servers. But my experience is pretty much the same. Our Windows 2003 server wants to reboot any time updates are installed. Our Linux machines generally boot up the day they're born and shut down when their hardware fails. Services can be patched with less than a second of downtime. An exception is that we just upgraded all the hard drives in our file servers, reinstalling the latest CentOS on each, but I managed to do it with zero downtime.
I'm not sure if sending them written letters will do much good. How about phone calls?
I really don't see how being able to find MD5 collisions can allow someone to exploit an MD5 password hashing scheme.
$1 million for this semi-supercomputer running the tried and tested server operating system Linux, under an open source license. Or $2 million for the same supercomputer running a server variant of the popular desktop operating system Windows, same performance, assuming advertisements don't lie, and under a license which limits the possibility of tweaking. Which will the client choose?
I'm pretty sure supercomputers are about performance.
I too often read the message body and forget to glance at the subject.
Remember to vote.
Will they replace the infected CD's? Compensate users? I suppose a class action suit will someday decide the latter, but most of it will go to the lawyers.