No, RMS claims to speak for the Free Software Foundation, an organization he started and still leads. That sounds pretty fair to me.
ESR persistently claims to speak for all hackers or "our tribe" or "our community". Such a thing has such fuzzy boundaries that it has no single opinion, and even if it did ESR wouldn't represent it.
Being pedantic about terminology may or may not be a good tactic, but I think it's understandable for RMS to resist the FSF being written out of history by clueless journalists.
"SYN flood" is obviously wrong... Unless they are running a system old enough to be called grossly negligent, they aren't susceptible to TCB starvation.
I mean, SYN cookies are only 7 years old now. You can't expect a world-class technology innovator like SCO to have implemented them quite that quickly, can you?
Linux having SYN cookies just proves that Linux is a bicycle. Or something like that.
First, both projects go on to be successful. In this case, the number of developers on each project will effectively be halved
You say that like it's a bad thing, but it ain't necessarily so: see The Mythical Man Month, etc. In some cases, having a smaller number of developers with a more concentrated idea of where they're going can be more effective.
Often when projects fork they don't directly compete, but rather one of them is going to be more adventurous (e.g. samba-tng) or have different priorities (e.g. OpenBSD). Doing that can produce much better outcomes than trying to hold everything under one umbrella.
Now, I'm not saying that forking is a bad idea, rather it's not a win-win situation.
You seem to be assuming that forking is something that unruly hackers do, but it's generally not. Forks happen when there are unreconcilable (not necessarily hostile) differences about how the project ought to proceed.
The only way to avoid having differences is serious groupthink by the developers, therefore probably ignoring opportunities.
In cases where the fork happened for silly reasons (typically with younger hackers), then it's no great loss, because they might not have achieved much anyhow. Probably they would have wasted a lot of time arguing if they'd stayed in.
...absolute progess
Progress is not an absolute. It is a vector; it has direction and magnitude. Having more progress in a direction which doesn't suit some of the users or developers is not a good thing.
CVS does not do *deltas* of binary files. It stores and transmits the whole thing every time. Therefore you lose the main advantage of rsync, which is that the network transfer is roughly proportional to the edit distance between the old and new files.
On Ethernet it makes little difference. On ADSL or modem or between continents rsync is enormously faster than CVS.
When I'm fetching a big CVS tree, it can be faster to do the initial checkout on a well-connected machine in the US and then move it by rsync back to my machine in Australia. In this case there is no delta of course but the pipelined and compressed network protocol is a big win by itself.
They have NOT been found guilty of commercial espionage.
Actually, it has been established in court that Microsoft bugged their victim/competitor's hotel room to gather commercial intelligence. This was some time ago, perhaps in the early 90s. I don't know if they were found guilty or even if this was a crime in the relevant jurisdiction. It certainly indicates a willingness to descend to unethical tricks.
And SCO may be acting unethically, but I've yet to see them found guilty of anything except stupidity.
Well, they haven't even literally "been found guilt of stupidity", and it's not a crime. But they probably will be found guilty of market manipulation and commercial libel.
But I have been running rsync v.2.5.7 since BEFORE the gentoo rsync server was compromised.
Don't be ridiculous. There was no 2.5.7 release before the Gentoo compromise. I know because I was one of the team that responded to the intrusion and produced the patch. The machine was crashed on Tuesday and the patch came out on Thursday, about 36 hours later.
The network protocol it just something to get the (significantly reduced) data from point to point. There isn't too much a network protocol can do to speed up the process.
There are several things that a new network protocol can do to make a transfer faster. For example, rsync is heavily pipelined in both directions, and removes common information from headers of consecutive files. Neither of those optimizations would be possible in FTP or HTTP.
rsync was for years the only major application that aggressively utilized full duplex TCP sockets, and found several bugs in Linux, BSD, and Solaris kernels by doing so. Again this is a protocol design decision that gets more mileage out of the connection than is possible in other ways.
Have you ever even looked at an HTTP dump? The hundreds of bytes it takes to send the headers can accomodate several whole rsync-compressed files. A recursive update of a changed tree is typically several times quicker with rsync than with either CVS or FTP. Nothing against those protocols; they were just designed with different purposes in mind.
Now you can reasonably question whether the space saving really justifies having a new protocol. If you're not convinced, don't run it. Many people do find it worthwhile. If you are super security-conscious then you probably shouldn't be offering anonymous or unencrypted service at all.
I was going to post it here, but the moronic lameness filter won't let me. So you'll need to look at rsync.samba.org.
The rsync team has received evidence that a vulnerability in rsync was recently used in combination with a Linux kernel vulnerability to compromise the security of a public rsync server. While the forensic evidence we have is incomplete, we have pieced together the most likely way that this attack was conducted and we are releasing this advisory as a result of our investigations to date.[....]
OK, those machines will see more requests. Some of the requests are going to miss. On the other hand, if a new Linux release has just come out and many people are trying to get it, they'd be likely to get many hits on the DNS records, and that's a good thing.
It's probably easier on the ISP to get a little more DNS traffic than it is for everyone to download ISOs over plain HTTP.
As I said above, it's unlikely to be statistically significant because the.torrent file is so small compared to the actual download.
It's also likely to be absolutely dwarfed by the pointless queries generated by misconfigured clients: Windows machines looking up Netbios names in DNS and similar shit. I seem to remember a survey showing that fully half the queries to root nameservers were unnecessary.
DNS is pretty good at serving cachable small chunks of information used for service location. Putting Bittorrent service location into isn't necessarily a terrible idea, though the implementation could use a lot of work.
Are you stupid, trolling, or just not paying attention?
The 256kB block is transferred over TCP by the usual means. The DNS query/response is just a short packet of perhaps 200 bytes telling it (in essence) where to get the block from. It's just like the way SMTP uses DNS: we use MX and A records to find out what host to talk to, and then actually send the message over TCP.
It's a little indirect and inefficient in this proof-of-concept implementation, but the DNS traffic is still much less than 0.5% of the whole. You could shrink it even more by putting it directly into the bt client, so that it fetched records as and when it needed them.
It's more likely they'd patch their DNS servers to filter out only the suspect non-text TXT records
Why would administrators care? The same data is going to come down over either HTTP or DNS. There's nothing inherently more expensive about passing it through bind rather than squid. The point of ISPs is, after all, to provide internet service.
a lot more memory required to cache thousands upon thousands of torrents.
You only need to cache them if your users are actively downloading thousands upon thousands of files. If you're really doing terrabytes (3000 x 660MB) of traffic per day, I think you can afford a big DNS server or two.
Unless the point is to stop people using BitTorrent altogether -- I suppose you might want to do that in a business environment, but in that case you've probably blocked the ports already.
It's just another irresponsibility specifically designed to slink through a firewall, and subvert security. It's just like Microsoft SOAP that's nothing more than RPC via port 80, and also designed to evade firewalls.
That's a fairly silly statement, given that the existing method for downloading tracker files is HTTP. I think HTTP is right up there with DNS in terms of ease of getting through firewalls. And, you know, if I was really desparate, I could just get someone to email me the tracker file, or I could bring it in on my USB key. Trying to prevent transfers of a few-kB file is fairly impossible without military-style disconnected networks.
If an administrator wants to block BitTorrent, they can easily block the high numbered ports (6880?) that it uses for the actual transfer.
And unless your DNS server got some godly amounts of memory, your in-memory DNS cache is pretty useless. Bye, bye caching-only name server.
If your DNS server can't handle an extra couple of queries per megabyte of traffic it's severely underprovisioned.
The people who think their DNS forwarder will be swamped must have a 100Mbps connection saturated with BitTorrent downloads, and a 486 as DNS server. Is that really likely?
Anyhow, even if the DNS server drops some records, is that really the end of the world? No. All it means is that you'll need to do more lookups upstream, and your users will find it slightly slower. But any user complaints are far more likely to be about their link being saturated with BT tentacle porn downloads.
I can't imagine what some TIER I DNS server might look like if this becomes prevalent.
If by "TIER I DNS server" you mean root name server, then the answer is that it would have little effect. The records are stored under names like 0_197_56633ab0d90f43c68ed1b47358eccfe7.domain.com. All the root and.com nameservers have to do is provide the cachable referral to domain.com, which they're doing already. It makes no difference to them how many queries the domain.com nameserver receives.
And as for your caching forwarder: this is going to generate roughly one request for every BT block somebody downloads, typically 256kB. A couple of extra UDP packets are negligible compared to the traffic to actually download the block.
Indeed since most web resources are smaller than 256kB, and many client machines have only a small DNS cache in the browser, it's likely that random web browsing is likely to generate requests at a higher rate. (Admittedly they're more likely to be cache hits.)
Doing this may give you more DNS misses but if you're downloading gigabytes of data the cost of the misses will be negligible.
Assume a DNS RR takes (generously) 1kB of disk or traffic. The queries to do this are still less than 0.5% of the traffic generated by the downloads themselves. If you allocated another 1GB of disk (about $1 at today's rates) then you could cache the tracker information for 256GB of BitTorrent downloads, which ought to keep your users supplied with Japanese tentacle porn for at least a few days.
I'm curious what kind of sound card, amp and speakers/headphones you're using to listen to it?
I can believe there's a difference, but I find it much easier to hear noise/distortion introduced by the poor analog hardware people typically use for MP3 playback.
Anyhow, now that they can take a PCM feed it's moot. There'll be some quantization loss, but no worse than the source CDs.
If the $300 slimp3 compares adequately to a $300 CD player and $1000 amp then I'd be reasonably satisfied.
Actually, that particular case can be handled using SMART testing in the disk drive firmware: one of the drive self-tests (IIRC) tells it to stop the platter, and measure how long it takes to spin up again. This is a good indicator of impending death through stiction. This can be done with the machine online and just a minor performance degradation that will be absorbed by the OS.
Of course you could have other hardware problems that might make the machine fail to boot. Possibly the current surge at startup would be too much for the machine.
But I think all of these things are arguments for avoiding reboots and power cycles unless you need them. They wear out the machine and are spikes of failure risk. Once a year is probably an OK tradeoff.
A more serious problem is an admin making a change that lets the machine keep working, but fail to boot. Doing the reboot earlier rather than later might give you more chance of working out what you changed that broke it. On the other hand Linux is generally more transparent to Windows and it's easier to work out what the real problem is, rather than blindly backing out changes.
Slashdot Mirror
I can't help but read that as symante.cx. Damn, I really miss seeing Bob on slashdot.
That sounds delicious!
No, RMS claims to speak for the Free Software Foundation, an organization he started and still leads. That sounds pretty fair to me.
ESR persistently claims to speak for all hackers or "our tribe" or "our community". Such a thing has such fuzzy boundaries that it has no single opinion, and even if it did ESR wouldn't represent it.
Being pedantic about terminology may or may not be a good tactic, but I think it's understandable for RMS to resist the FSF being written out of history by clueless journalists.
"SYN flood" is obviously wrong... Unless they are running a system old enough to be called grossly negligent, they aren't susceptible to TCB starvation.
Well, there are no SYN cookies on SCO UnixWare/OpenServer systems. I say that based not only on the google search, but also reports from friends who used to run a large site on UnixWare until a few years ago.
I mean, SYN cookies are only 7 years old now. You can't expect a world-class technology innovator like SCO to have implemented them quite that quickly, can you?
Linux having SYN cookies just proves that Linux is a bicycle. Or something like that.
You say that like it's a bad thing, but it ain't necessarily so: see The Mythical Man Month, etc. In some cases, having a smaller number of developers with a more concentrated idea of where they're going can be more effective.
Often when projects fork they don't directly compete, but rather one of them is going to be more adventurous (e.g. samba-tng) or have different priorities (e.g. OpenBSD). Doing that can produce much better outcomes than trying to hold everything under one umbrella.
Now, I'm not saying that forking is a bad idea, rather it's not a win-win situation.
You seem to be assuming that forking is something that unruly hackers do, but it's generally not. Forks happen when there are unreconcilable (not necessarily hostile) differences about how the project ought to proceed.
The only way to avoid having differences is serious groupthink by the developers, therefore probably ignoring opportunities.
In cases where the fork happened for silly reasons (typically with younger hackers), then it's no great loss, because they might not have achieved much anyhow. Probably they would have wasted a lot of time arguing if they'd stayed in.
Progress is not an absolute. It is a vector; it has direction and magnitude. Having more progress in a direction which doesn't suit some of the users or developers is not a good thing.
CVS does not do *deltas* of binary files. It stores and transmits the whole thing every time. Therefore you lose the main advantage of rsync, which is that the network transfer is roughly proportional to the edit distance between the old and new files.
On Ethernet it makes little difference. On ADSL or modem or between continents rsync is enormously faster than CVS.
When I'm fetching a big CVS tree, it can be faster to do the initial checkout on a well-connected machine in the US and then move it by rsync back to my machine in Australia. In this case there is no delta of course but the pipelined and compressed network protocol is a big win by itself.
They have NOT been found guilty of commercial espionage.
Actually, it has been established in court that Microsoft bugged their victim/competitor's hotel room to gather commercial intelligence. This was some time ago, perhaps in the early 90s. I don't know if they were found guilty or even if this was a crime in the relevant jurisdiction. It certainly indicates a willingness to descend to unethical tricks.
And SCO may be acting unethically, but I've yet to see them found guilty of anything except stupidity.
Well, they haven't even literally "been found guilt of stupidity", and it's not a crime. But they probably will be found guilty of market manipulation and commercial libel.
But I have been running rsync v.2.5.7 since BEFORE the gentoo rsync server was compromised.
Don't be ridiculous. There was no 2.5.7 release before the Gentoo compromise. I know because I was one of the team that responded to the intrusion and produced the patch. The machine was crashed on Tuesday and the patch came out on Thursday, about 36 hours later.
I suppose you're running kernel 2.7 as well?
I realize you're trolling, but BSD is equally vulnerable.
The network protocol it just something to get the (significantly reduced) data from point to point. There isn't too much a network protocol can do to speed up the process.
RTFM, idiot.
There are several things that a new network protocol can do to make a transfer faster. For example, rsync is heavily pipelined in both directions, and removes common information from headers of consecutive files. Neither of those optimizations would be possible in FTP or HTTP.
rsync was for years the only major application that aggressively utilized full duplex TCP sockets, and found several bugs in Linux, BSD, and Solaris kernels by doing so. Again this is a protocol design decision that gets more mileage out of the connection than is possible in other ways.
Have you ever even looked at an HTTP dump? The hundreds of bytes it takes to send the headers can accomodate several whole rsync-compressed files.
A recursive update of a changed tree is typically several times quicker with rsync than with either CVS or FTP. Nothing against those protocols; they were just designed with different purposes in mind.
Now you can reasonably question whether the space saving really justifies having a new protocol. If you're not convinced, don't run it. Many people do find it worthwhile. If you are super security-conscious then you probably shouldn't be offering anonymous or unencrypted service at all.
"I'm glad I don't put much basis on yammerings on slashdot"... "In fact, I'm real glad." --Theo de Raadt
I was going to post it here, but the moronic lameness filter won't let me. So you'll need to look at rsync.samba.org.
OK, those machines will see more requests. Some of the requests are going to miss. On the other hand, if a new Linux release has just come out and many people are trying to get it, they'd be likely to get many hits on the DNS records, and that's a good thing.
.torrent file is so small compared to the actual download.
It's probably easier on the ISP to get a little more DNS traffic than it is for everyone to download ISOs over plain HTTP.
As I said above, it's unlikely to be statistically significant because the
It's also likely to be absolutely dwarfed by the pointless queries generated by misconfigured clients: Windows machines looking up Netbios names in DNS and similar shit. I seem to remember a survey showing that fully half the queries to root nameservers were unnecessary.
DNS is pretty good at serving cachable small chunks of information used for service location. Putting Bittorrent service location into isn't necessarily a terrible idea, though the implementation could use a lot of work.
Are you stupid, trolling, or just not paying attention?
The 256kB block is transferred over TCP by the usual means. The DNS query/response is just a short packet of perhaps 200 bytes telling it (in essence) where to get the block from. It's just like the way SMTP uses DNS: we use MX and A records to find out what host to talk to, and then actually send the message over TCP.
It's a little indirect and inefficient in this proof-of-concept implementation, but the DNS traffic is still much less than 0.5% of the whole. You could shrink it even more by putting it directly into the bt client, so that it fetched records as and when it needed them.
It's more likely they'd patch their DNS servers to filter out only the suspect non-text TXT records
Why would administrators care? The same data is going to come down over either HTTP or DNS. There's nothing inherently more expensive about passing it through bind rather than squid. The point of ISPs is, after all, to provide internet service.
a lot more memory required to cache thousands upon thousands of torrents.
You only need to cache them if your users are actively downloading thousands upon thousands of files. If you're really doing terrabytes (3000 x 660MB) of traffic per day, I think you can afford a big DNS server or two.
Unless the point is to stop people using BitTorrent altogether -- I suppose you might want to do that in a business environment, but in that case you've probably blocked the ports already.
It's just another irresponsibility specifically designed to slink through a firewall, and subvert security. It's just like Microsoft SOAP that's nothing more than RPC via port 80, and also designed to evade firewalls.
That's a fairly silly statement, given that the existing method for downloading tracker files is HTTP. I think HTTP is right up there with DNS in terms of ease of getting through firewalls. And, you know, if I was really desparate, I could just get someone to email me the tracker file, or I could bring it in on my USB key. Trying to prevent transfers of a few-kB file is fairly impossible without military-style disconnected networks.
If an administrator wants to block BitTorrent, they can easily block the high numbered ports (6880?) that it uses for the actual transfer.
And unless your DNS server got some godly amounts of memory, your in-memory DNS cache is pretty useless. Bye, bye caching-only name server.
If your DNS server can't handle an extra couple of queries per megabyte of traffic it's severely underprovisioned.
The people who think their DNS forwarder will be swamped must have a 100Mbps connection saturated with BitTorrent downloads, and a 486 as DNS server. Is that really likely?
Anyhow, even if the DNS server drops some records, is that really the end of the world? No. All it means is that you'll need to do more lookups upstream, and your users will find it slightly slower. But any user complaints are far more likely to be about their link being saturated with BT tentacle porn downloads.
I can't imagine what some TIER I DNS server might look like if this becomes prevalent.
. All the root and .com nameservers have to do is provide the cachable referral to domain.com, which they're doing already. It makes no difference to them how many queries the domain.com nameserver receives.
If by "TIER I DNS server" you mean root name server, then the answer is that it would have little effect. The records are stored under names like 0_197_56633ab0d90f43c68ed1b47358eccfe7.domain.com
And as for your caching forwarder: this is going to generate roughly one request for every BT block somebody downloads, typically 256kB. A couple of extra UDP packets are negligible compared to the traffic to actually download the block.
Indeed since most web resources are smaller than 256kB, and many client machines have only a small DNS cache in the browser, it's likely that random web browsing is likely to generate requests at a higher rate. (Admittedly they're more likely to be cache hits.)
Doing this may give you more DNS misses but if you're downloading gigabytes of data the cost of the misses will be negligible.
Assume a DNS RR takes (generously) 1kB of disk or traffic. The queries to do this are still less than 0.5% of the traffic generated by the downloads themselves. If you allocated another 1GB of disk (about $1 at today's rates) then you could cache the tracker information for 256GB of BitTorrent downloads, which ought to keep your users supplied with Japanese tentacle porn for at least a few days.
I'm using the generic term "NT" for the NT family of OSs, which includes W2003. Just as non-marketdroid people from Microsoft do.
The NT machines we had to patch included 2000 and 2003.
I'm got a blanket solution for cold mornings.
If you like devfs so much, why don't you maintain it yourself?
It at least gives you a defence (although not a good one).
It raises reasonable doubt that you downloaded the files.
Of course if they get to search your PC, and then find them there...
Seeing as it has a 5VDC 1A input you could easily put a little battery pack on it. I don't know if it's really designed to go on picnics though.
I'm curious what kind of sound card, amp and speakers/headphones you're using to listen to it?
I can believe there's a difference, but I find it much easier to hear noise/distortion introduced by the poor analog hardware people typically use for MP3 playback.
Anyhow, now that they can take a PCM feed it's moot. There'll be some quantization loss, but no worse than the source CDs.
If the $300 slimp3 compares adequately to a $300 CD player and $1000 amp then I'd be reasonably satisfied.
TVs, even LCD or plasma displays, produce HF noise. I don't want them on when I'm trying to listen to music.
I should put my money where my mouth is and buy one...
Actually, that particular case can be handled using SMART testing in the disk drive firmware: one of the drive self-tests (IIRC) tells it to stop the platter, and measure how long it takes to spin up again. This is a good indicator of impending death through stiction. This can be done with the machine online and just a minor performance degradation that will be absorbed by the OS.
Of course you could have other hardware problems that might make the machine fail to boot. Possibly the current surge at startup would be too much for the machine.
But I think all of these things are arguments for avoiding reboots and power cycles unless you need them. They wear out the machine and are spikes of failure risk. Once a year is probably an OK tradeoff.
A more serious problem is an admin making a change that lets the machine keep working, but fail to boot. Doing the reboot earlier rather than later might give you more chance of working out what you changed that broke it. On the other hand Linux is generally more transparent to Windows and it's easier to work out what the real problem is, rather than blindly backing out changes.