Otherwise it is available for download here:
bsod.c. The really great part about this version is, that you can have bluescreen exactly when you want, I for one use it when it is about time to go to bed.
And to be honest, I would never pay for a 64kbit/s Ogg or 128kbit/s
mp3.
I can understand that though personally I'm not able to tell the difference between 48kbit/s Ogg Vorbis and the original uncompressed sound.
If I were paying, it would have to be the max bitrate for either
Why exactly would you want that? If you want a high bitrate why not the uncompressed version?
but let's say 320kbit/s constant for mp3
I don't know about MP3, but for Ogg Vorbis requiring a constant bitrate is going to reduce quality. With variable bitrate, you get a lot better quality at the same average bitrate. Besides IIRC variable bitrate requires less CPU time as well.
no lowpass filter
Why? Are you sure that is a good idea? Usually lowpass filters are used to avoid artifacts.
While pirate copies of Windows might not be the best thing that could happen to Microsoft, it is surely not good to the free software movement either. Getting a lot of pirate copies of Windows replaced with free software will be an advantage to the free software movement. You know the major problem in the computer industry right now is, that there are way too many Windows systems. There are so many Windows systems, that you more or less have to make something compatible with those. Microsoft knows that, and they make it as hard as possible to interoperate with Windows. Getting rid of copies of Windows will decrease the amount of power Microsoft has even if it doesn't immediately give Microsoft less money.
I think that forcing computer vendors to ship only open source products is not the way to go.
While in principle I agree with you, and you do have a good point, I must point out, that today many computer vendors are practically forced to ship computers with Windows. Having some vendors forced to ship something else might be a good way to change that, does sound like more fair competition. Of course the problem is, how do we know when Microsofts position have been weakened enough to let go again?
watch kernel contributors with deep pockets sue SCO for copyright infringement.
That would be IBM, in fact isn't that more or less what IBM is already doing? OK, the exact words of that lawsuit might be, that SCO is violating the GPL. But it can quickly be turned around or just add another lawsuit to the heap with the argument that without the rights from the GPL SCO is in fact commiting copyright infrigement. It doesn't really matter for that argument if the GPL is valid or not, what is important is, that SCO clearly not accepted the GPL and thus have no right to copy, modify, or redistribute the software. My first question to SCO would be: "Did you or did you not accept the GPL before distributing GPL software". And then take one of two paths depending on the answer. (Of course from time to time SCO is going to give different answers to that particular question). I hope it will turn out, that the GPL is still legal, but SCO did not accept it.
Those are stuff that cannot be seen in the resulting executable, the watermark is claimed to be found even in the resulting executable. (Yes I know in some cases variable names can be visible in the executable, but you can easilly prevent it from being there.) I somehow doubt this watermarking is at all possible. With optimizing compilers it is hard to find resemblance between source and executable. Finally knowing how the watermarks are made on the code, it is probably easy to write another but slightly similar algorithm that will remove the watermark.
That is not what I wrote/. messed it up. Probably it is impossible to write it correctly on slashdot as it will always insert spaces in places where it shouldn't be. Since I am already writing another comment I might as well add, another command you could use. You can of course also query installed packages rather than querying the.rpm files. To query about license on all installed packages you could use:
rpm -qa --qf '%{LICENSE}\n' | sort | uniq -c
For yet another example of how to use rpm query formats see/etc/cron.daily/rpm and/usr/share/doc/rpm-4.2/queryformat on any recent RHL distribution.
yeah, but the GPL doesn't permit companies to make any profit on GPL'd software
That is not true. You are allowed to sell GPL software at whatever price you want. It only says, that if you make a profit on selling binaries without source, you must also sell sources without making any profit on the sources. For the exact words read section 3 part 3 of the GNU GPL.
FAT uses linked lists, which mean any implementation have to suck. Seeking in large files cannot be done efficiently on FAT. Directories with many files cannot be done efficiently either. Of course it is still possible that the Mac implementation suck more than other FAT implementations, I don't know about that.
Why isn't his test, done with real world data, not a 'real world'
test?
If the speed difference is really caused by differences between the drives/protocols, it is an interesting result. The smaller seek time on the SCSI drive could be part of the reason, but certainly not the entire reason for such a large difference. The larger buffer on the SCSI drive is also an advantage, but I don't know how much difference that does. It would have been interesting to throw in an IDE drive with 8MB buffer in the test. However there are a few details he completely omits from his description, and I'm afraid he have forgotten about those. The filesystem used, and the fragmentation of the drive is important. Using a different filesystem on the two drives could cause such a large difference. Besides the old drive probably being fragmented, and the new drive possibly not being fragmented could also cause the difference. Making a raw copy of a partition from one drive to the other would have ensured those factors were also the same.
I've actually wondered about this before and if it was possible
In general it is not possible to use drivers under any other OS than the one it was developed for. And any kernel developer will tell you it is not a good idea. A driver needs to interface not only with the device, but also the OS. No matter how well it works with the device, it doesn't help making it work with another OS. Expecting a Windows driver to work with Linux is like expecting an SCSI driver to work with an IDE harddisk (maybe not the best anology, but it was the best I could come up with, and they have certainly been seen worse). In some cases you might be able to provide a wrapper, that makes it work, but it requires good knowledge about the interface in both directions, and the end result certainly isn't going to be as good as a native driver. If hardware vendors want a wide range of compatibility, they can easilly achieve it, it just takes a few steps.
And then there was this 500 Internal Server Error and my wit and wisdom were lost forever to the bit bucket in the sky.
That is a simple one to recover from. Just use the back button. What would be worse would be a power failure. How long before Mozilla get autosave for forms to avoid this kind of data loss? Slashdot is not the only place, where you type in potentially large messages in a text field on a web page. Of course you might have to dig out the text from some obscure place, but at least you wouldn't have to write it all over again.
Just in case somebody want a litle history lesson about
Harald Blaatand. And considering when Blaatand was born I guess he must have been dead for about a thousand years.
Slashdot Mirror
did they implement the bluescreen feature?
Otherwise it is available for download here: bsod.c. The really great part about this version is, that you can have bluescreen exactly when you want, I for one use it when it is about time to go to bed.
And to be honest, I would never pay for a 64kbit/s Ogg or 128kbit/s mp3.
I can understand that though personally I'm not able to tell the difference between 48kbit/s Ogg Vorbis and the original uncompressed sound.
If I were paying, it would have to be the max bitrate for either
Why exactly would you want that? If you want a high bitrate why not the uncompressed version?
but let's say 320kbit/s constant for mp3
I don't know about MP3, but for Ogg Vorbis requiring a constant bitrate is going to reduce quality. With variable bitrate, you get a lot better quality at the same average bitrate. Besides IIRC variable bitrate requires less CPU time as well.
no lowpass filter
Why? Are you sure that is a good idea? Usually lowpass filters are used to avoid artifacts.
the quality of the streaming songs is...aka kbps...
No, quality is more than just the bitrate. A 64kb/s Ogg Vorbis stream has better quality than a 128kb/s MP3 stream.
I'm not exactly sure which side wins here.
While pirate copies of Windows might not be the best thing that could happen to Microsoft, it is surely not good to the free software movement either. Getting a lot of pirate copies of Windows replaced with free software will be an advantage to the free software movement. You know the major problem in the computer industry right now is, that there are way too many Windows systems. There are so many Windows systems, that you more or less have to make something compatible with those. Microsoft knows that, and they make it as hard as possible to interoperate with Windows. Getting rid of copies of Windows will decrease the amount of power Microsoft has even if it doesn't immediately give Microsoft less money.
I think that forcing computer vendors to ship only open source products is not the way to go.
While in principle I agree with you, and you do have a good point, I must point out, that today many computer vendors are practically forced to ship computers with Windows. Having some vendors forced to ship something else might be a good way to change that, does sound like more fair competition. Of course the problem is, how do we know when Microsofts position have been weakened enough to let go again?
Ignore the ipaddr, I'm an idiot.
Which ipaddr?
watch kernel contributors with deep pockets sue SCO for copyright infringement.
That would be IBM, in fact isn't that more or less what IBM is already doing? OK, the exact words of that lawsuit might be, that SCO is violating the GPL. But it can quickly be turned around or just add another lawsuit to the heap with the argument that without the rights from the GPL SCO is in fact commiting copyright infrigement. It doesn't really matter for that argument if the GPL is valid or not, what is important is, that SCO clearly not accepted the GPL and thus have no right to copy, modify, or redistribute the software. My first question to SCO would be: "Did you or did you not accept the GPL before distributing GPL software". And then take one of two paths depending on the answer. (Of course from time to time SCO is going to give different answers to that particular question). I hope it will turn out, that the GPL is still legal, but SCO did not accept it.
randomising white space, replacing variable names
Those are stuff that cannot be seen in the resulting executable, the watermark is claimed to be found even in the resulting executable. (Yes I know in some cases variable names can be visible in the executable, but you can easilly prevent it from being there.) I somehow doubt this watermarking is at all possible. With optimizing compilers it is hard to find resemblance between source and executable. Finally knowing how the watermarks are made on the code, it is probably easy to write another but slightly similar algorithm that will remove the watermark.
Ain't that something you eat?
Det kan du bande paa, det ikke er!
With apropriate defines it will work. Example 1:Example 2:Example 3:Example 4:
That is not what I wrote
I don't know. But it should be easy to find out by anyone with access to the
yeah, but the GPL doesn't permit companies to make any profit on GPL'd software
That is not true. You are allowed to sell GPL software at whatever price you want. It only says, that if you make a profit on selling binaries without source, you must also sell sources without making any profit on the sources. For the exact words read section 3 part 3 of the GNU GPL.
and that the mac implementation of FAT sucks
FAT uses linked lists, which mean any implementation have to suck. Seeking in large files cannot be done efficiently on FAT. Directories with many files cannot be done efficiently either. Of course it is still possible that the Mac implementation suck more than other FAT implementations, I don't know about that.
Why isn't his test, done with real world data, not a 'real world' test?
If the speed difference is really caused by differences between the drives/protocols, it is an interesting result. The smaller seek time on the SCSI drive could be part of the reason, but certainly not the entire reason for such a large difference. The larger buffer on the SCSI drive is also an advantage, but I don't know how much difference that does. It would have been interesting to throw in an IDE drive with 8MB buffer in the test. However there are a few details he completely omits from his description, and I'm afraid he have forgotten about those. The filesystem used, and the fragmentation of the drive is important. Using a different filesystem on the two drives could cause such a large difference. Besides the old drive probably being fragmented, and the new drive possibly not being fragmented could also cause the difference. Making a raw copy of a partition from one drive to the other would have ensured those factors were also the same.
Apache/1.3.27 (Unix) (Red-Hat/Linux) on Linux
That doesn't answer the question, but at least it tells us, that it must be running a kernel at least 184 days old.
i think poeple should choose a more friendly domain name if they want to provide an alternative.
If you read the page, you would know, they already have a more friendly name.
In general it is not possible to use drivers under any other OS than the one it was developed for. And any kernel developer will tell you it is not a good idea. A driver needs to interface not only with the device, but also the OS. No matter how well it works with the device, it doesn't help making it work with another OS. Expecting a Windows driver to work with Linux is like expecting an SCSI driver to work with an IDE harddisk (maybe not the best anology, but it was the best I could come up with, and they have certainly been seen worse). In some cases you might be able to provide a wrapper, that makes it work, but it requires good knowledge about the interface in both directions, and the end result certainly isn't going to be as good as a native driver. If hardware vendors want a wide range of compatibility, they can easilly achieve it, it just takes a few steps.
Bill Gates should get stoned.
That one of you who never made a bug shall throw the first stone.
If I was in McBride,
I hope nobody here was actually in McBride.
Does the GPL make it impossible to personally claim infringement of your ownership/copyright of contributed code?
Certainly not. In fact it is probably the only way to defend the GPL.
Yeah, any company in any lawsuit always spends 100% of the cash on hand to fight it. (And has no other revenue or expenses except the suit.)
Probably true in the case of SCO.
And then there was this 500 Internal Server Error and my wit and wisdom were lost forever to the bit bucket in the sky.
That is a simple one to recover from. Just use the back button. What would be worse would be a power failure. How long before Mozilla get autosave for forms to avoid this kind of data loss? Slashdot is not the only place, where you type in potentially large messages in a text field on a web page. Of course you might have to dig out the text from some obscure place, but at least you wouldn't have to write it all over again.
Anyone remember Happy Meal Ethernet and Big Mac Ethernet?
I remember the driver sauce, hme is surely worth reading. sunhme.c sunbmac.c
Just in case somebody want a litle history lesson about Harald Blaatand. And considering when Blaatand was born I guess he must have been dead for about a thousand years.