Right. And what about the cyclists who don't use highways and thus don't want to pay taxes to support them?
Or, a closer analogy might be childless couples: why should they have to pay taxes to fund schools?
It's the same thing, and this sort of argument just displays ignorance of the topic. Canada currently has a tax on blank media: this is a directed tax which is then forwarded on to copyright conglomerates who them redistribute the monies to artists. Taxes don't have to be universal..
And.. so when the links that Wikipedia article itself points to state that there are currently 50 conditions that can be treated by autologous cord blood transplants.. and the fact that the cord blood can be used by anyone in the family who turns out to be a match, are you just quoting out of context because you didn't read any further, or are you serious?
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss. Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans?.. so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
Commercial development shop that wants to make *more* sure that all development work happens in a place that is backed-up and supported by IT. Additionally, if a developer is using a tool that encourages him to do a pile of work offline then he is more likely to do so. Enforcing the use of a centralised VCS of some sort is a risk mitigation strategy. The corporate SAN? Backed-up administered, carefully managed. The lame little 2.5" HDD in a typical laptop? Could go at any time and all that developer's work is destroyed.
Additionally, encouraging the cooperative use of a VCS mainline or dev branch measurably decreases the amount of work that a developer has to do. The "merge late" strategy is just putting off and piling up and actually *increasing* total work that must be done. "Merge early, merge often," is an almost dogmatic mantra for a reason: codeline divergence creates unnecessary additional work. If you keep branches that are closely related, closely related by merging regularly, you are reducing divergence and merging becomes much more trivial.
I don't mean to say that all divergence is bad, nor that decentralised VCS is a bad idea. I just mean to say that I can understand why commercial enterprises are reluctant to embrace the sort of development model that git encourages in its users.
The real reason why large development shops refuse to pull git in is actually a scaleability problem. Specifically, git doesn't scale up. If it worked as well for millions of files and terabytes of information, everyone would be stampeding to use it. It doesn't and so they won't.
Tens of thousands of files and a few hundred megabytes of data is very small compared to most commercial projects.
I know parent was marked flamebait, but I think it's a perfectly valid question. It's not flamebait at all, but perhaps a bit more rhetorical than it needs to be.
IMO, svn doesn't work so well with large files. Other systems work better and faster with them. If git seriously works more slowly with large files than svn does, I am mentally shuddering. But that's a cool datapoint..! Thank you for your comment.. awesome.
The Linux kernel isn't a big project. A few tens of thousands of files and a few hundred MB? That's "big" to you?
Let's fast-forward a few more years.. development project sizes rise, amount of data rises, number of files rise. Are you trusting that git will be reprogrammed to be able to scale to such sizes? KDE tried to migrate to git, and all their sub-projects are internally dependent on one another. Therefore it wouldn't be feasible to expect them to migrate to multiple git repositories. And that attempt failed. My point is that git doesn't scale. It goes up to size X, and beyond that it simply fails.
Also incorrect, unless I'm misunderstanding what you're saying.
The BT chunks themselves can become the discrete, and known-about, units that must be transferred across the UDP channel--however they decide to do it--and the chunks of the chunks become encapsulated in packets. You still don't have to care about in-order delivery. Add in a mux'd, single, unique identifier, and it can even be reused. In fact, I challenge you to find a single instance, anywhere available to any BT user that has more than even a single GB in-transit at any one time. The endpoint socket identifiers can become the file handle as viewed by each endpoint, and you don't even need anything else beyond a single bit to identify whether the packet is a control packet or a data packet, and you can mux the two into a single socket. Or, skip that and open two UDP sockets per hosthost channel.
You don't need a file position identifier that references the file in bytes. You reference the file in discrete units which are encapsulated in the UDP packets, whatever size that might be.
Still, this is all academic. The BT people I'm sure have solved this problem themselves. All I'm pointing out is that the ability to discard some of the assumptions about a TCP stream allows you more flexibility in designing a replacement because it can be *simpler* and almost certainly *more efficient.* That's the key, and so far everything you've said I don't think applies: you seem to be suggesting that your vision of doing it is the only way, and since your way is unworkable and unwieldy, therefore there is no way. Obviously, this is a logical fallacy.
But I could simply be misunderstanding your note.:)
TCP guarantees in-order, mildly error-corrected, delivery of transmitted *DATA*. Not packets. It is a streaming protocol where the data being transmitted is of unknown and indeterminate length, or open-ended length. Since BT already doesn't care that files arrive in pieces at the beginning, middle or end (well, it does a little, but not enough to matter) then you can relax and basically eliminate one of the TCP guarantees right there: in-order delivery of data.
You can eliminate sliding windows, ACK-based retransmits, fast-retransmission, and pretty much every other mechanism that TCP uses to guarantee in-order delivery of data. You can simplify it and the application itself beautifully, and provided it correctly throttles back based on detected packet loss (it MUST be exponential back-off,) you end up with a net win for those reasons. The application can set up its own optimised data structures that don't necessarily have (but likely will end up having anyway) the overhead of an OS-backed TCP stack.
I mean who cares if you miss pieces, until the end when you can re-request them?
Heck, there are already P2P apps that use a UDP-based transfer mechanism and they are WAY less impactful on systems that a typical BitTorrent stream is. They way the hell slower, too, but that's not the point.
I do think there is a point that bears repeating: BT *MUST* have exponential back-off. If it doesn't there is logic already built-in to core routers, ISPs, and firewalls that WILL drop the connection more severely when the endpoints don't respond properly to an initial packet-drop attempt at slowing them down.
There are some really nice academic papers about it, and there are lots of algorithms and choices that companies have. They all assume TCP-like back-off on the endpoints, and they ALL uniformly punish greedy floods.
Please mod parent up. This place is so damn full of armchair wannabe network experts who've clearly no understanding of how TCP congestion avoidance works it's bordering on the physically painful.
Yes they do. ISP and core routers already do drop packets. But it's not at random. They drop it when dropped packets don't halt the incoming flood of other packets which are all part of the same connection or even connection class.
Incorrect. TCP guarantees in-order delivery of DATA. *Packet* retransmission could include additional data and thus the same packet need not be the one that is retransmitted until ACK'd at the other end. It could change, grow larger, whatever.
Incorrect. ANY BT implementation over UDP will have flow control built-in. And without an exponential back-off, the core routers WILL drop the connection right on the floor. They already have this logic built-in. BT users, you've been warned.
Actually, much of what TCP guarantees (in-order data delivery) can simply be thrown right out the window. It doesn't actually matter whether it arrives in order if you have a finite, defined chunk of data that needs to be delivered from one machine to another. Therefore, things like Windows sizes can disappear, in-order reassembly can disappear, and all this extra overhead can simply go away. (Other stuff needs to remain, but you get the idea.)
However, BT users beware: if you don't have an exponential back-off, the core routers themselves will simply QoS you. They already have these algorithms built-in. Non-responsive protocols that don't behave well in the face of dropped packets WILL BE DROPPED HARDER.
There're lots of interesting academic papers written about this.
If you thought the driver situation was bad for Linux, and worse for *BSD, it's even worser fro OpenSolaris. Yes, I said worser. It's worser enough for me to want to use a fake, worse word to describe it.:(
I mean, great idea guys, but in execution, any OS that locks up solid so you have to ssh in remotely and kill your login session so you can log in, or that makes compilation of something as simple as Quake practically impossible--installed GNU toolchain or not--is it really worth it on commodity hardware?
We have OpenSolaris desktop machines installed at work, and the amount of effort the OpenSolaris users go through.. my god, it's herculean. And I'm making this judgement call sitting atop a farm of NetBSD machines. So you fucking know--you KNOW--that when I say something's a rough ride, you better fucking listen.
Not that it's a complete dearth of utility. There's lots of stuff going for it. I'm just saying. Fair warning.
Slashdot Mirror
How amusing.
You think you are capable of determining in precise and specific amounts every benefit you receive as a result of living in a society.
.. that this guy was the author of The Crystal Empire:
http://www.amazon.com/Crystal-Empire-L-Neil-Smith/dp/031294070X
That was a horrible book.
But Poor Ballard.. oh well.
Right. And what about the cyclists who don't use highways and thus don't want to pay taxes to support them?
Or, a closer analogy might be childless couples: why should they have to pay taxes to fund schools?
It's the same thing, and this sort of argument just displays ignorance of the topic. Canada currently has a tax on blank media: this is a directed tax which is then forwarded on to copyright conglomerates who them redistribute the monies to artists. Taxes don't have to be universal..
That is incorrect. Only stupid people argue that economic reasons create a right to copy.
The ease with which it is copied doesn't make it right.
The benefit of sharing with a friend is what can make it right.
Perhaps they make this claim as outrageous as possible in order to guarantee a loss in court and still save face overall?
INSWPKUABIAISP.
Hitting them only teaches them to hit. Don't hit your kid.
-12? -15 C? wtf..?! That's not cold!
And.. so when the links that Wikipedia article itself points to state that there are currently 50 conditions that can be treated by autologous cord blood transplants.. and the fact that the cord blood can be used by anyone in the family who turns out to be a match, are you just quoting out of context because you didn't read any further, or are you serious?
You mean.. except leukemia?
Oooo.. dangerous thinking. The complete lack of administrative overhead seems like a great panacea.. until you realise that you are essentially side-stepping any corporate data retention policy, side-stepping the benefits of corporate IT support and data protection policies, and increasing risk of partial data loss. Or are you suggesting that, via forced git pulls from every single developer to every single developer you are thus creating a redundancy strategy better than the typical corporate IT backup/disaster plans? .. so how is it that you are going to force all developers to do a git pull, or at least a push to some central machine on a regular basis without actually implementing *some* sort of IT-supported machinery?
Commercial development shop that wants to make *more* sure that all development work happens in a place that is backed-up and supported by IT. Additionally, if a developer is using a tool that encourages him to do a pile of work offline then he is more likely to do so. Enforcing the use of a centralised VCS of some sort is a risk mitigation strategy. The corporate SAN? Backed-up administered, carefully managed. The lame little 2.5" HDD in a typical laptop? Could go at any time and all that developer's work is destroyed.
Additionally, encouraging the cooperative use of a VCS mainline or dev branch measurably decreases the amount of work that a developer has to do. The "merge late" strategy is just putting off and piling up and actually *increasing* total work that must be done. "Merge early, merge often," is an almost dogmatic mantra for a reason: codeline divergence creates unnecessary additional work. If you keep branches that are closely related, closely related by merging regularly, you are reducing divergence and merging becomes much more trivial.
I don't mean to say that all divergence is bad, nor that decentralised VCS is a bad idea. I just mean to say that I can understand why commercial enterprises are reluctant to embrace the sort of development model that git encourages in its users.
The real reason why large development shops refuse to pull git in is actually a scaleability problem. Specifically, git doesn't scale up. If it worked as well for millions of files and terabytes of information, everyone would be stampeding to use it. It doesn't and so they won't.
Yes, they are small projects. :)
Tens of thousands of files and a few hundred megabytes of data is very small compared to most commercial projects.
I know parent was marked flamebait, but I think it's a perfectly valid question. It's not flamebait at all, but perhaps a bit more rhetorical than it needs to be.
IMO, svn doesn't work so well with large files. Other systems work better and faster with them. If git seriously works more slowly with large files than svn does, I am mentally shuddering. But that's a cool datapoint..! Thank you for your comment.. awesome.
But yikes. :)
The Linux kernel isn't a big project. A few tens of thousands of files and a few hundred MB? That's "big" to you?
Let's fast-forward a few more years.. development project sizes rise, amount of data rises, number of files rise. Are you trusting that git will be reprogrammed to be able to scale to such sizes? KDE tried to migrate to git, and all their sub-projects are internally dependent on one another. Therefore it wouldn't be feasible to expect them to migrate to multiple git repositories. And that attempt failed. My point is that git doesn't scale. It goes up to size X, and beyond that it simply fails.
Also incorrect, unless I'm misunderstanding what you're saying.
The BT chunks themselves can become the discrete, and known-about, units that must be transferred across the UDP channel--however they decide to do it--and the chunks of the chunks become encapsulated in packets. You still don't have to care about in-order delivery. Add in a mux'd, single, unique identifier, and it can even be reused. In fact, I challenge you to find a single instance, anywhere available to any BT user that has more than even a single GB in-transit at any one time. The endpoint socket identifiers can become the file handle as viewed by each endpoint, and you don't even need anything else beyond a single bit to identify whether the packet is a control packet or a data packet, and you can mux the two into a single socket. Or, skip that and open two UDP sockets per hosthost channel.
You don't need a file position identifier that references the file in bytes. You reference the file in discrete units which are encapsulated in the UDP packets, whatever size that might be.
Still, this is all academic. The BT people I'm sure have solved this problem themselves. All I'm pointing out is that the ability to discard some of the assumptions about a TCP stream allows you more flexibility in designing a replacement because it can be *simpler* and almost certainly *more efficient.* That's the key, and so far everything you've said I don't think applies: you seem to be suggesting that your vision of doing it is the only way, and since your way is unworkable and unwieldy, therefore there is no way. Obviously, this is a logical fallacy.
But I could simply be misunderstanding your note. :)
TCP guarantees in-order, mildly error-corrected, delivery of transmitted *DATA*. Not packets. It is a streaming protocol where the data being transmitted is of unknown and indeterminate length, or open-ended length. Since BT already doesn't care that files arrive in pieces at the beginning, middle or end (well, it does a little, but not enough to matter) then you can relax and basically eliminate one of the TCP guarantees right there: in-order delivery of data.
You can eliminate sliding windows, ACK-based retransmits, fast-retransmission, and pretty much every other mechanism that TCP uses to guarantee in-order delivery of data. You can simplify it and the application itself beautifully, and provided it correctly throttles back based on detected packet loss (it MUST be exponential back-off,) you end up with a net win for those reasons. The application can set up its own optimised data structures that don't necessarily have (but likely will end up having anyway) the overhead of an OS-backed TCP stack.
I mean who cares if you miss pieces, until the end when you can re-request them?
Heck, there are already P2P apps that use a UDP-based transfer mechanism and they are WAY less impactful on systems that a typical BitTorrent stream is. They way the hell slower, too, but that's not the point.
I do think there is a point that bears repeating: BT *MUST* have exponential back-off. If it doesn't there is logic already built-in to core routers, ISPs, and firewalls that WILL drop the connection more severely when the endpoints don't respond properly to an initial packet-drop attempt at slowing them down.
There are some really nice academic papers about it, and there are lots of algorithms and choices that companies have. They all assume TCP-like back-off on the endpoints, and they ALL uniformly punish greedy floods.
Please mod parent up. This place is so damn full of armchair wannabe network experts who've clearly no understanding of how TCP congestion avoidance works it's bordering on the physically painful.
Yes they do. ISP and core routers already do drop packets. But it's not at random. They drop it when dropped packets don't halt the incoming flood of other packets which are all part of the same connection or even connection class.
Incorrect. TCP guarantees in-order delivery of DATA. *Packet* retransmission could include additional data and thus the same packet need not be the one that is retransmitted until ACK'd at the other end. It could change, grow larger, whatever.
Incorrect. ANY BT implementation over UDP will have flow control built-in. And without an exponential back-off, the core routers WILL drop the connection right on the floor. They already have this logic built-in. BT users, you've been warned.
Actually, much of what TCP guarantees (in-order data delivery) can simply be thrown right out the window. It doesn't actually matter whether it arrives in order if you have a finite, defined chunk of data that needs to be delivered from one machine to another. Therefore, things like Windows sizes can disappear, in-order reassembly can disappear, and all this extra overhead can simply go away. (Other stuff needs to remain, but you get the idea.)
However, BT users beware: if you don't have an exponential back-off, the core routers themselves will simply QoS you. They already have these algorithms built-in. Non-responsive protocols that don't behave well in the face of dropped packets WILL BE DROPPED HARDER.
There're lots of interesting academic papers written about this.
What do you mean, now? The perception of nVidia has always been the same. "Crap, it's not Open Source, but hey at least it works. Oh well."
Writing a story about yourself in the third person?
Crowing about how muted and controlled your footnote response was?
Brag much?
I miss the somewhat more.. objective and clean Groklaw postings. Oh well.
If you thought the driver situation was bad for Linux, and worse for *BSD, it's even worser fro OpenSolaris. Yes, I said worser. It's worser enough for me to want to use a fake, worse word to describe it. :(
I mean, great idea guys, but in execution, any OS that locks up solid so you have to ssh in remotely and kill your login session so you can log in, or that makes compilation of something as simple as Quake practically impossible--installed GNU toolchain or not--is it really worth it on commodity hardware?
We have OpenSolaris desktop machines installed at work, and the amount of effort the OpenSolaris users go through.. my god, it's herculean. And I'm making this judgement call sitting atop a farm of NetBSD machines. So you fucking know--you KNOW--that when I say something's a rough ride, you better fucking listen.
Not that it's a complete dearth of utility. There's lots of stuff going for it. I'm just saying. Fair warning.
(P.S. Tinkering with it? Good luck.)