What is to prevent the OSS community from making a more restrictive DRM standard based on ogg vorbis with some DRM-ish layer?
Does this mean that the only legal streaming format will then be ogg-DRM-vorbis?
The RIAA and the other middlemen must really be worried that they are going to be cut out of the equation when the artists realise that they don't need
to give up 99% of the revenues and could just as easily hire an online
company to distribute their works for them at a much lower cost.
Legislating a certain format for the online distribution of music would turn the tables again and force the artists to deal with another middleman, in this case the company that owns the rights to that DRM format. The RIAA could simply buy those rights to that particular DRM and they would be guarenteed a revenue stream for quite a few years into the future.
It isn't any worse than the folks that use the same passwords on all the machines anyway. Break one and you have them all (or at least most of them).
Secondly, and this is the real clincher, the breaking of that first machine can't be done by guessing passwords either. One either needs to be sitting at the console to break that password or have some other sloppy program that allows remote login (or at least file-theft) exploits.
One then needs to break the password of the targeted user. This still doesnt' leave one any worse off than the case where one can break passwords remotely via password-guessing attacks.
Many of the places that plaintext passwords are used, one needn't
allow a password login at all. The strongest security is to disable
all other login services (like telnet, rsh etc) and require remote
users to log in via ssh using rsa or dsa keys. The whole beauty of
this rsa/dsa-only method is the users could choose easily guessed
passwords and the protected computer still wouldn't be at risk from
external attackers because the user's password is only used to access
their local computer. To break in the remote attacker would still
have to guess the RSA or DSA key which is computer-chosen and very
long (1024 - 2048 bits). If all computers are configured such that
unix passwords are only acceptable for local
(console or perhaps hardwired rs-232 terminal) logins, then a remote
attacker gains little by discovering the unix plaintext password.
Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePam no
(The last line may fail on computers that have PAM turned off at
compile time. Leaving PAM logins on for machines that have PAM
globally enabled negates the whole rsa/dsa-only requirement.)
I'm surprised phk is screwing around writing long-winded letters. Much faster would have been to just add a dns A-record entry by the name of private-ntp.dix.dk for the legit users and have them use that server. The old gps.dix.dk entry should be made into a CNAME for www.dlink.com. That would put the crushing levels of ntp traffic back where it belonged -- right on Dlink's doorstep.
NTP does include support for leap seconds - there are bits that can be set by the primary time source to indicate that a leap second will occur soon.
This is a bit disingenuous. NTP uses a very specific timescale to transfer the time information. (Essentially seconds since the epoch, with retro-active redefinitions of when the epoch occured every time a leap second event happens.) Just to keep things simple, the timescale the BSD kernel uses to keep time and to timestamp file mod-times etc is the same one. While there may be leapsecond bits present within the NTP protocol on the wire, these bits are stripped and forgotten as soon as the time information hits the kernel. The way things work now kernel time is discontionous whenever a leap second occurs and subtracting two time values that straddle the leap second event won't get you the correct number of elapsed seconds.
According to the article, the 250GB bursts hit 171 MB/s, so actually it would be hindered by SATA1.
Seeing how the overall data-rate off of the heads is only in the 60MByte/sec to 90MByte/sec range, all this talk of 300MByte channels is
bordering on dishonesty with numbers. The burst rate sounds like it is simply the speed at which the on-board cache can be read at. That isn't going to a number that influences much other than artificial benchmarks.
This article is just another article from an ever growing number of "fan-boy" review sites that read like ad-copy. A real review
would test the disk throughput with something
similar to:
dd if=/dev/wd0c of=/dev/null bs=1m
and then note the true MBytes/sec that the disk achieved. This is the best-case number
that essentially allows the disk to stream
with very little track-to-track stepping.
Good disks will be able to do 60MBytes/sec on the outer tracks, but will usually slow to
2/3rd's that speed on inner tracks.
I just buy CD's and encode all the music myself with grip. Grip is
pretty good about adding in the track names and other vitals
automatically. If it can't find them it prompts you.
One large advantage of encoding it yourself and using a non-DRM
player is that you can play the same file from
{Linux,{Free,Net,Open}BSD} and from the portable player. They player
I have is a Digital Minds DMC
500. It isn't the smallest player in the world, but it plays
mp3's and oggs and takes a normal laptop 2/5" drive. That means you
can easily slap a 100G drive in there and carry a few weeks of music
on you.
After a 3 years of recording 9 hours of radio shows a week I've
finally managed to fill the disk. Unfortunately the disk drive
capacities haven't really gone up as much as I'd hoped.
If you really think ghosts and all are fake, then how about this: put up, say $1000 of your own money to the first person to scientifically prove they exist. You wouldn't do it right? Because you know you'd be out $1000.
James Randy aka "The Amazing Randy" (a retired stage magician) has put up 1000x that -- a cool 1 million to the first person that can demonstrate any of these paranormal claims. If someone could get a ghost to strut around for the test, I'm sure they could pick up a bit of spare change.
There are few things more addictive and difficult to argue with than religion
One needs to treat these people the same way as one treats little kids that have imaginary freinds.
Unfortunately there isn't a test for mental age that one needs to pass in order to be eligable to vote.
Under linux the laptop was drawing 50-100watts (which is very
high for a laptop), under windows it was drawing from 30-50 watts.
There are several aspects to power managment that many of the OSS
kernels fail to take advantage of. 1) they don't turn down they CPU
voltage and clock rate, even when the CPU is idle. 2) they don't turn
the power off to unused chips and peripherals. 3) sometimes they
don't even turn off some devices when the laptop is turned off.
Anyone with a Compac Evo laptop has probably seen this. Shutdown your
computer while running linux on mains, unplug it so you can take it home and look at
the battery charge a few days later and it is down to half charge.
Some of the internal devices (like ethernet transcivers) are never
even turned off. While wake-on-lan etc. might make sense on
desktops, one has to wonder what the folks were thinking when they
decided to keep a laptop's ethernet powered even when the laptop might
later be needlessly draining the battery.
Now some of this isn't the the fault of the OSS authors. In many
cases the chip companies simply never release the information needed
to correctly manage the power. That's got to change. Other times, it is simply that nobody
cares enough about power usage to get off their butt and write the
code. Certainly the amd64 CPU voltage/frequency settings fall into
that category for the various BSD's. How many amd64 computers are out
there running OSS, idling at 140watts when they could easily be idling
at 90watts, a savings of ~30%.
I know one guy that says they don't ever see problems until the temperature is above 80F, so businesses can save a lot by not being so freaking cold.
Many electrolytic capacitors have very reduced lifetimes at
even a few degrees above room temp. Ditto for for some lubrication used in disk drives. In the end it comes out to a trade off beteen
the cost of power and the cost of replacing failed equipment.
Slashdot Mirror
What is to prevent the OSS community from making a more restrictive DRM standard based on ogg vorbis with some DRM-ish layer? Does this mean that the only legal streaming format will then be ogg-DRM-vorbis?
The RIAA and the other middlemen must really be worried that they are going to be cut out of the equation when the artists realise that they don't need to give up 99% of the revenues and could just as easily hire an online company to distribute their works for them at a much lower cost. Legislating a certain format for the online distribution of music would turn the tables again and force the artists to deal with another middleman, in this case the company that owns the rights to that DRM format. The RIAA could simply buy those rights to that particular DRM and they would be guarenteed a revenue stream for quite a few years into the future.
It isn't any worse than the folks that use the same passwords on all the machines anyway. Break one and you have them all (or at least most of them).
Secondly, and this is the real clincher, the breaking of that first machine can't be done by guessing passwords either. One either needs to be sitting at the console to break that password or have some other sloppy program that allows remote login (or at least file-theft) exploits. One then needs to break the password of the targeted user. This still doesnt' leave one any worse off than the case where one can break passwords remotely via password-guessing attacks.
Many of the places that plaintext passwords are used, one needn't allow a password login at all. The strongest security is to disable all other login services (like telnet, rsh etc) and require remote users to log in via ssh using rsa or dsa keys. The whole beauty of this rsa/dsa-only method is the users could choose easily guessed passwords and the protected computer still wouldn't be at risk from external attackers because the user's password is only used to access their local computer. To break in the remote attacker would still have to guess the RSA or DSA key which is computer-chosen and very long (1024 - 2048 bits). If all computers are configured such that unix passwords are only acceptable for local (console or perhaps hardwired rs-232 terminal) logins, then a remote attacker gains little by discovering the unix plaintext password.
(The last line may fail on computers that have PAM turned off at compile time. Leaving PAM logins on for machines that have PAM globally enabled negates the whole rsa/dsa-only requirement.)
I'm surprised phk is screwing around writing long-winded letters. Much faster would have been to just add a dns A-record entry by the name of private-ntp.dix.dk for the legit users and have them use that server. The old gps.dix.dk entry should be made into a CNAME for www.dlink.com. That would put the crushing levels of ntp traffic back where it belonged -- right on Dlink's doorstep.
NTP does include support for leap seconds - there are bits that can be set by the primary time source to indicate that a leap second will occur soon.
This is a bit disingenuous. NTP uses a very specific timescale to transfer the time information. (Essentially seconds since the epoch, with retro-active redefinitions of when the epoch occured every time a leap second event happens.) Just to keep things simple, the timescale the BSD kernel uses to keep time and to timestamp file mod-times etc is the same one. While there may be leapsecond bits present within the NTP protocol on the wire, these bits are stripped and forgotten as soon as the time information hits the kernel. The way things work now kernel time is discontionous whenever a leap second occurs and subtracting two time values that straddle the leap second event won't get you the correct number of elapsed seconds.
Microsoft is against ISPs doing anything that would restrict customers' choice of software.
That is a right they want to reserve for themselves (via their "Trusted Computing" DRM and similar).
According to the article, the 250GB bursts hit 171 MB/s, so actually it would be hindered by SATA1.
Seeing how the overall data-rate off of the heads is only in the 60MByte/sec to 90MByte/sec range, all this talk of 300MByte channels is bordering on dishonesty with numbers. The burst rate sounds like it is simply the speed at which the on-board cache can be read at. That isn't going to a number that influences much other than artificial benchmarks.
This article is just another article from an ever growing number of "fan-boy" review sites that read like ad-copy. A real review would test the disk throughput with something similar to:
and then note the true MBytes/sec that the disk achieved. This is the best-case number that essentially allows the disk to stream with very little track-to-track stepping. Good disks will be able to do 60MBytes/sec on the outer tracks, but will usually slow to 2/3rd's that speed on inner tracks.
Three words:
Embrace, Extend, Extinguish
I just buy CD's and encode all the music myself with grip. Grip is pretty good about adding in the track names and other vitals automatically. If it can't find them it prompts you.
One large advantage of encoding it yourself and using a non-DRM player is that you can play the same file from {Linux,{Free,Net,Open}BSD} and from the portable player. They player I have is a Digital Minds DMC 500. It isn't the smallest player in the world, but it plays mp3's and oggs and takes a normal laptop 2/5" drive. That means you can easily slap a 100G drive in there and carry a few weeks of music on you.
After a 3 years of recording 9 hours of radio shows a week I've finally managed to fill the disk. Unfortunately the disk drive capacities haven't really gone up as much as I'd hoped.
If you really think ghosts and all are fake, then how about this: put up, say $1000 of your own money to the first person to scientifically prove they exist. You wouldn't do it right? Because you know you'd be out $1000.
James Randy aka "The Amazing Randy" (a retired stage magician) has put up 1000x that -- a cool 1 million to the first person that can demonstrate any of these paranormal claims. If someone could get a ghost to strut around for the test, I'm sure they could pick up a bit of spare change.
There are few things more addictive and difficult to argue with than religion
One needs to treat these people the same way as one treats little kids that have imaginary freinds. Unfortunately there isn't a test for mental age that one needs to pass in order to be eligable to vote.
Under linux the laptop was drawing 50-100watts (which is very high for a laptop), under windows it was drawing from 30-50 watts.
There are several aspects to power managment that many of the OSS kernels fail to take advantage of. 1) they don't turn down they CPU voltage and clock rate, even when the CPU is idle. 2) they don't turn the power off to unused chips and peripherals. 3) sometimes they don't even turn off some devices when the laptop is turned off. Anyone with a Compac Evo laptop has probably seen this. Shutdown your computer while running linux on mains, unplug it so you can take it home and look at the battery charge a few days later and it is down to half charge. Some of the internal devices (like ethernet transcivers) are never even turned off. While wake-on-lan etc. might make sense on desktops, one has to wonder what the folks were thinking when they decided to keep a laptop's ethernet powered even when the laptop might later be needlessly draining the battery.
Now some of this isn't the the fault of the OSS authors. In many cases the chip companies simply never release the information needed to correctly manage the power. That's got to change. Other times, it is simply that nobody cares enough about power usage to get off their butt and write the code. Certainly the amd64 CPU voltage/frequency settings fall into that category for the various BSD's. How many amd64 computers are out there running OSS, idling at 140watts when they could easily be idling at 90watts, a savings of ~30%.
I know one guy that says they don't ever see problems until the temperature is above 80F, so businesses can save a lot by not being so freaking cold.
Many electrolytic capacitors have very reduced lifetimes at even a few degrees above room temp. Ditto for for some lubrication used in disk drives. In the end it comes out to a trade off beteen the cost of power and the cost of replacing failed equipment.