Intel decided that multimedia stuff was the Future, so they made the P4 an overgrown DSP. Turns out that here in the Future, we still have conditionals, and AMD can usually keep up with the multimedia stuff.
As for not having the on die memory controller... I'm lost on that one. It's like they want to be left behind.
If it's a project that you're really into, you can do it. Even if you go home your mind is still working on the problem.
That's why startups can (sometimes) do it. The people are personally involved in a project they created. That's why companies like Google can do things nobody else can. Even with a 40 hour week everyone's having a ball.
Unfortunately, most programming is arbitrary, tedious shit.
Yes, but it's apparent that EA expects people to work these 80 hour weeks for months at a time.
Also, with those 80 hour weeks you need time off afterwards for people to recover from burnout, otherwise you get a protracted period of reduced productivity even back at 40 hours.
I'm all set for real OSes, thanks. I'm just pointing out that Windows constitutes such a vast majority of the desktop OS market that any p2p software that doesn't support it is unlikely to get far.
"Right, so how is this different when the firewall vendors start distributing their personal firewall products with default off for the UDP case."
I doubt they will. That would break things, more than just p2p software.
I'm guessing you'd think something along the lines of "good", but such firewall software would not be popular.
"Fine, as an arms race I can sort of see where the feature "implement TCP over UDP/HTTP/DNS/whatever" comes from. But you don't "design" your protocol with stupid TCP over UDP hacks in mind. You design for a reliable stream protocol, like say TCP."
In most cases, I would agree. However, there are sufficiently compelling reasons for somebody to try it in this case. I don't understand why you're getting so worked up about it.
"It's only important if you run BitTorrent on the firewall as a trusted user. I run BitTorrent behind the firewall, on my workstation, as a regular user. There's no need for doing anything with different users, unless you're running BT on the firewall."
No... you're missing the point. The torrent user isn't trusted (except for the ability to listen for connections), he's de-trusted. He's stuck in his home directory, he doesn't own anything else. If I ran the bittorrent client as me, an attacker would have access to all my files. Right now, he can only access the files in/home/torrent.
"Prioritizing interactive traffic with one tool is a nice PF feature, though Linux's tc can make up the functionality."
This is the advantage of prioritizing by user. Probably 10% of bittorrent clients out there use non-standard ports, and they're fairly evenly distributed across the whole range. Also, other services will occasionally find themselves on the bittorrent ports and these are hurt by port-based prioritization,
With a seperate user, exactly the right connections are throttled. No more, no less.
Yes. In my case, I have a laptop that's sometimes not home, a desktop that's sometimes turned off, and a firewall/server that's always on. It made sense to run bittorrent on server. It may not make sense if your situation is different.
The assumption should be that things are compromised. In my case, I don't care because I put my name on the stuff I print. You just shouldn't assume that things are anonymous.
"a) Modern TCP implementations (with window scaling) support a maximum window size of approximately 1 GB.
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well."
AFAIK, RFC1323 is not enabled by default in Windows 98, 98SE or XP. Using UDP lets people benefit without messing with their settings. sack is supported, but with a small window it doesn't do as much good.
"c) Yeah, until the firewall vendors start looking for this and the whole thing becomes a even more insanely unreliable hackjob than it already is. Why not just cut to the chase and implement RFC 3093?"
There's the home firewalls, and there's the enterprise firewalls. In the case of home firewalls, the people probably want to accept incoming connections but don't know it's not set up.
"d) I suppose, though this'll be pretty unreliable if/as egress filtering becomes more common."
It's not trivial to do sufficiently tight filtering to keep this from protecting people from being sued. And at the end of the day, p2p will always be an arms race. This is par for the course.
p2p traffic is large static files almost 100% of the time. A UDP protocol optimized for large files can be a good thing, better than TCP.
a) Instead of a relative small window like TCP, we can make the window as big as we want. This would let us cut down a LOT on ACKs (or pseudo-ACKS in the case of UDP). We can ACK a range, or a range with exceptions, or whatever. For a protocol specializing in bulk transfers, it can really cut down on overhead.
b) TCP guarantees that data arrives to the application in order. This is expensive when we don't care. A custom UDP protocol lets us pick up missing chunks at our leisure, we simply need to maintain a list of missing chunks as the transfer goes along so we can request them later.
c) Since UDP is connectionless, firewalls must create pseudo-connections for UDP. When a UDP packet is sent, the firewall will allow incoming UDP packets from that host/port to the originating port. This gives us a way of signaling to the firewall that we wish to accept UDP packets from that host on that port, even though the client on the other end will never recieve that packet due to their own firewall. Once they've both done it, they have a mutual "connection". This is a brilliant hack, whoever thought of it.
d) We can hide the sender of the data. If we request a file in some mutually accessible place, along with the host/port we're going expect packets from, anyone anywhere can start spewing packets at us with falsified sender information. It's nearly impossible to determine where they came from with UDP.
"However, one must wonder why not just use TCP, which is guaranteed to be reliable. IMHO, What you'd end up with using UDP is a LOT of "did you get it? yes/no"-type network traffic between peers."
TCP does that a lot too (a LOT), it's simply handled by the network stack rather than the application. TCP ACKs cause 1/15th or 1/20th as much upstream traffic as the downstream portion of the connection causes. That adds up when you have a {dsl,cable} modem that's 1/10th as fast with upstream traffic.
I have bittorrent behind my firewall. Rather than statically allowing ports, I set up a "torrent" user, and told the firewall to let it listen for connections. This also has two beneficial side effects. First, if there's an arbitrary code vulnerability, an attacker can be somewhat contained. Second, bittorrent doesn't always use the common range of ports, so prioritizing by port is problematic. Having a seperate user lets me throttle the bittorrent connections so that interactive traffic has priority.
While I imagine this is possible with Linux, I have no specific knowledge of how to do it. I did it with PF on OpenBSD.
"But I guess ultimately, if you are going to do something illegal these days there is enough technology around that can 'eventually' track you down."
I don't know about that.
I'd dumpster dive for it. People turf those cheap printers without a second thought, and it's probably possible to restore many of them to working order with a bit of care. You can probably get paper and ink that way too.
Assuming "they" can trace the paper, ink, and printer to the people that bought them, "they"'d still be unable to connect it to you if you don't leave clues on the dumpster or on the paper.
If I were doing something that I wouldn't want traced back to me, I would assume that any printer would leave unique markings on the paper, on purpose or not. Bullets have rifling marks, tires have unique markings, etc. Those aren't intentional. Also, the paper might be traceable in the same way.
You can bet there's tricks they don't advertise on the discovery channel, particularly the intelligence agencies.
"I'll grant everything before the "and." We don't know what Sun's OSS model will look like. It certainly won't be the GPL, and I'll be amazingly surprised if it's even as liberal as the BSD licence. People aren't fond of giving away their code so that a corporation can make money off of it, so if Sun's model is anything like Microsoft's Shared Source initiative, it will stifle development by the community, not encourage it."
I think something GPL-like is more likely. The GPL is much less liberal than the BSD L, and many companies prefer it for that reason. They can release their code in a contaminated way. Other companies won't benefit without releasing their code under a similar license. The only people that might benefit are the open source people, and they're going to win (eventually) if Sun does nothing, so that's irrelevant.
I dunno if it will be the GPL. I suspect they'll want to keep Solaris code from finding its way into Linux, so it'll need to be GPL-incompatible even if only slightly.
As for using Solaris over Linux... non-zealots have many OSes to choose from. FreeBSD is almost as big as Linux in webserving for a reason, nobody can match OpenBSD in terms of security, there might even be a good reason to use Windows (I'm not aware of one, but that proves nothing.:) ). Solaris will have a number of key features that aren't available with any other OS that runs on commodity hardware.
For example, I don't think anyone has a filesystem to match ZFS on commodity hardware. It's more flexible and more reliable than anything any of the other commodity-hardware OSes have.
The BSDs will all run Linux binaries too, as well as SCO UNIX and soon Solaris.
The important thing is stability (in the doesn't crash sense, in the no new major bugs in the main branch sense, and the changes slowly enough for people to maintain software for it sense (this applies to kernelspace stuff, not userspace stuff)), and Linux is currently bad at that because of the poor decisions made my the development team.
The distros are not up to the task of stabalizing the kernels they use.
"Im not sure if i like the idea. Developers have have lives, that's why the developement is moving at the pace it is. And i like the pace the developement is at. Forking another kernel tree will split the developers apart and slow down the developement of the 2.6 kernel."
The stability of the 2.6 kernel has thus far been terrible. I mean, really just horrible. Major bugs are introduced on a regular basis because the maintainers made the decision to leave testing up to the distros. Except for Debian, none of them are good at testing kernels, and as a result major bugs get shipped.
2.4 is obsolete, but 2.6 is unstable.
What do you expect people to think if they have a distro that's supposed to be easy to use, and you tell them "Oh, that version of the kernel has a bug, you can't burn CD's. Just download and compile the new one, it's easy.". It's been almost as bad as Windows.
Slashdot Mirror
Intel decided that multimedia stuff was the Future, so they made the P4 an overgrown DSP. Turns out that here in the Future, we still have conditionals, and AMD can usually keep up with the multimedia stuff.
As for not having the on die memory controller... I'm lost on that one. It's like they want to be left behind.
If it's a project that you're really into, you can do it. Even if you go home your mind is still working on the problem.
That's why startups can (sometimes) do it. The people are personally involved in a project they created. That's why companies like Google can do things nobody else can. Even with a 40 hour week everyone's having a ball.
Unfortunately, most programming is arbitrary, tedious shit.
Yes, but it's apparent that EA expects people to work these 80 hour weeks for months at a time.
Also, with those 80 hour weeks you need time off afterwards for people to recover from burnout, otherwise you get a protracted period of reduced productivity even back at 40 hours.
Using SSL or SSH to encrypt the communications is trivial.
Intel performs better with media encoding stuff, AMD performs better on other things.
Like code with branches, and code that accesses memory.
"Here's 2 cents kid, go buy yourself a real OS."
I'm all set for real OSes, thanks. I'm just pointing out that Windows constitutes such a vast majority of the desktop OS market that any p2p software that doesn't support it is unlikely to get far.
"Right, so how is this different when the firewall vendors start distributing their personal firewall products with default off for the UDP case."
I doubt they will. That would break things, more than just p2p software.
I'm guessing you'd think something along the lines of "good", but such firewall software would not be popular.
"Fine, as an arms race I can sort of see where the feature "implement TCP over UDP/HTTP/DNS/whatever" comes from. But you don't "design" your protocol with stupid TCP over UDP hacks in mind. You design for a reliable stream protocol, like say TCP."
In most cases, I would agree. However, there are sufficiently compelling reasons for somebody to try it in this case. I don't understand why you're getting so worked up about it.
Where in Canada?
"It's only important if you run BitTorrent on the firewall as a trusted user. I run BitTorrent behind the firewall, on my workstation, as a regular user. There's no need for doing anything with different users, unless you're running BT on the firewall."
/home/torrent.
No... you're missing the point. The torrent user isn't trusted (except for the ability to listen for connections), he's de-trusted. He's stuck in his home directory, he doesn't own anything else. If I ran the bittorrent client as me, an attacker would have access to all my files. Right now, he can only access the files in
"Prioritizing interactive traffic with one tool is a nice PF feature, though Linux's tc can make up the functionality."
This is the advantage of prioritizing by user. Probably 10% of bittorrent clients out there use non-standard ports, and they're fairly evenly distributed across the whole range. Also, other services will occasionally find themselves on the bittorrent ports and these are hurt by port-based prioritization,
With a seperate user, exactly the right connections are throttled. No more, no less.
Yes. In my case, I have a laptop that's sometimes not home, a desktop that's sometimes turned off, and a firewall/server that's always on. It made sense to run bittorrent on server. It may not make sense if your situation is different.
The assumption should be that things are compromised. In my case, I don't care because I put my name on the stuff I print. You just shouldn't assume that things are anonymous.
"a) Modern TCP implementations (with window scaling) support a maximum window size of approximately 1 GB.
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well."
AFAIK, RFC1323 is not enabled by default in Windows 98, 98SE or XP. Using UDP lets people benefit without messing with their settings. sack is supported, but with a small window it doesn't do as much good.
"c) Yeah, until the firewall vendors start looking for this and the whole thing becomes a even more insanely unreliable hackjob than it already is. Why not just cut to the chase and implement RFC 3093?"
There's the home firewalls, and there's the enterprise firewalls. In the case of home firewalls, the people probably want to accept incoming connections but don't know it's not set up.
"d) I suppose, though this'll be pretty unreliable if/as egress filtering becomes more common."
It's not trivial to do sufficiently tight filtering to keep this from protecting people from being sued. And at the end of the day, p2p will always be an arms race. This is par for the course.
Yup. I got the idea from ftp-proxy. :) Also, you want to throttle any outgoing connections by that user as well.
p2p traffic is large static files almost 100% of the time. A UDP protocol optimized for large files can be a good thing, better than TCP.
a) Instead of a relative small window like TCP, we can make the window as big as we want. This would let us cut down a LOT on ACKs (or pseudo-ACKS in the case of UDP). We can ACK a range, or a range with exceptions, or whatever. For a protocol specializing in bulk transfers, it can really cut down on overhead.
b) TCP guarantees that data arrives to the application in order. This is expensive when we don't care. A custom UDP protocol lets us pick up missing chunks at our leisure, we simply need to maintain a list of missing chunks as the transfer goes along so we can request them later.
c) Since UDP is connectionless, firewalls must create pseudo-connections for UDP. When a UDP packet is sent, the firewall will allow incoming UDP packets from that host/port to the originating port. This gives us a way of signaling to the firewall that we wish to accept UDP packets from that host on that port, even though the client on the other end will never recieve that packet due to their own firewall. Once they've both done it, they have a mutual "connection". This is a brilliant hack, whoever thought of it.
d) We can hide the sender of the data. If we request a file in some mutually accessible place, along with the host/port we're going expect packets from, anyone anywhere can start spewing packets at us with falsified sender information. It's nearly impossible to determine where they came from with UDP.
"However, one must wonder why not just use TCP, which is guaranteed to be reliable. IMHO, What you'd end up with using UDP is a LOT of "did you get it? yes/no"-type network traffic between peers."
TCP does that a lot too (a LOT), it's simply handled by the network stack rather than the application. TCP ACKs cause 1/15th or 1/20th as much upstream traffic as the downstream portion of the connection causes. That adds up when you have a {dsl,cable} modem that's 1/10th as fast with upstream traffic.
UDP isn't made reliable by the network stack, but we can make it reliable in our application by using the same techniques that TCP uses.
I have bittorrent behind my firewall. Rather than statically allowing ports, I set up a "torrent" user, and told the firewall to let it listen for connections. This also has two beneficial side effects. First, if there's an arbitrary code vulnerability, an attacker can be somewhat contained. Second, bittorrent doesn't always use the common range of ports, so prioritizing by port is problematic. Having a seperate user lets me throttle the bittorrent connections so that interactive traffic has priority.
While I imagine this is possible with Linux, I have no specific knowledge of how to do it. I did it with PF on OpenBSD.
Of course... it's the smart ones you have to worry about.
"But I guess ultimately, if you are going to do something illegal these days there is enough technology around that can 'eventually' track you down."
I don't know about that.
I'd dumpster dive for it. People turf those cheap printers without a second thought, and it's probably possible to restore many of them to working order with a bit of care. You can probably get paper and ink that way too.
Assuming "they" can trace the paper, ink, and printer to the people that bought them, "they"'d still be unable to connect it to you if you don't leave clues on the dumpster or on the paper.
That assumes the photocopier won't leave artifacts or watermarks.
"Most Linux-only users use NFS, which does not have these security holes."
RPC (NFS runs over RPC) vulnerabilities have been among the most numerous over the years, and NFS security sucks even apart from that.
If I were doing something that I wouldn't want traced back to me, I would assume that any printer would leave unique markings on the paper, on purpose or not. Bullets have rifling marks, tires have unique markings, etc. Those aren't intentional. Also, the paper might be traceable in the same way.
:)
You can bet there's tricks they don't advertise on the discovery channel, particularly the intelligence agencies.
You can't be paranoid enough.
"I'll grant everything before the "and." We don't know what Sun's OSS model will look like. It certainly won't be the GPL, and I'll be amazingly surprised if it's even as liberal as the BSD licence. People aren't fond of giving away their code so that a corporation can make money off of it, so if Sun's model is anything like Microsoft's Shared Source initiative, it will stifle development by the community, not encourage it."
:) ). Solaris will have a number of key features that aren't available with any other OS that runs on commodity hardware.
I think something GPL-like is more likely. The GPL is much less liberal than the BSD L, and many companies prefer it for that reason. They can release their code in a contaminated way. Other companies won't benefit without releasing their code under a similar license. The only people that might benefit are the open source people, and they're going to win (eventually) if Sun does nothing, so that's irrelevant.
I dunno if it will be the GPL. I suspect they'll want to keep Solaris code from finding its way into Linux, so it'll need to be GPL-incompatible even if only slightly.
As for using Solaris over Linux... non-zealots have many OSes to choose from. FreeBSD is almost as big as Linux in webserving for a reason, nobody can match OpenBSD in terms of security, there might even be a good reason to use Windows (I'm not aware of one, but that proves nothing.
For example, I don't think anyone has a filesystem to match ZFS on commodity hardware. It's more flexible and more reliable than anything any of the other commodity-hardware OSes have.
I'm sorry, but I mistrust anyone that uses that many exclamation points.
The BSDs will all run Linux binaries too, as well as SCO UNIX and soon Solaris.
The important thing is stability (in the doesn't crash sense, in the no new major bugs in the main branch sense, and the changes slowly enough for people to maintain software for it sense (this applies to kernelspace stuff, not userspace stuff)), and Linux is currently bad at that because of the poor decisions made my the development team.
The distros are not up to the task of stabalizing the kernels they use.
"... The development process is going so smoothly that there may not need to be a 2.7 at all"
what. the. fuck.
It's not. Major bugs get shipped, and the distros aren't up to the task of testing kernels properly.
"Im not sure if i like the idea. Developers have have lives, that's why the developement is moving at the pace it is. And i like the pace the developement is at. Forking another kernel tree will split the developers apart and slow down the developement of the 2.6 kernel."
The stability of the 2.6 kernel has thus far been terrible. I mean, really just horrible. Major bugs are introduced on a regular basis because the maintainers made the decision to leave testing up to the distros. Except for Debian, none of them are good at testing kernels, and as a result major bugs get shipped.
2.4 is obsolete, but 2.6 is unstable.
What do you expect people to think if they have a distro that's supposed to be easy to use, and you tell them "Oh, that version of the kernel has a bug, you can't burn CD's. Just download and compile the new one, it's easy.". It's been almost as bad as Windows.