The Isreali Army is one of the best in the world at defending itself...but it's never pro-active
They're highly proactive. They conquered the entire nation of Israel in 1948. And then in 1967 they captured more land and headed off any possible retailation by destroying not only the armies of all surrounding Arab nations, but also killing 34 US servicement who witnessed the pre-emptive attack.
Look at how they deal with terrorists. I'd sure say that launching missiles from a helicopter to explode a suspected organizer is pro-active!
a technologically superior military if you arm 2 billion people with steak knives and send them against 100 million with guns
In the second world war, US Marines killed attackers with knives at a 600:1 ratio. And with better equipment, US pilots killed lightly armed people at a ratio of 14000:1.
The American lives sacrificed were lives that other European nations didn't have to sacrifice.
It wasn't the US lives that made a difference, but the equipment (and the economic/financial power that bought those things)
For each US soldier killed, more than 50 Russian warriors gave their lives. That's not counting the many British, Polish, and yes, even French. (Contrary to recent jokes, the French army didn't surrender- they were killed)
Plus, for those other nations, it wasn't just their soldiers dying- civilians were also decimated by Axis assault.
Internet traffic, if I remember correctly, is bursty
Part of what the FAST TPC project tries to do is make it less bursty, by inserting a timer mechanism on the sender to spread out the transmission of packets. It's mentioned on page 5 of the FAST pdf.
(Willingly throttling your send rate will reduce the speed you can send small files, but when sending large files it'll reduce the chances of overloading the network, which could lead to an overall improvement)
Perhaps this could finally lead to the possibility of having a FPS (First Person Shooter) use TCP instead of UDP.
No, it couldn't. In a comment above I described how this new system is inappropriate for streaming media applications, and took some flak because for many uses of streaming, enormous amounts of prebuffering (amounting to 10+ seconds of latency for the viewer) are acceptable. Which makes TCP/IP OK.
Listening to a radio station, you may not care that the sounds you hear are 2 minutes old. But if you're talking to another person, 2 seconds of delay will press the limits of tolerance. And for shooting animated monsters, 200 ms is as high as you'd want to go. (I played an internet FPS recently and had a stellar ping of 26 ms. The opposition was devastated, despite my inability to navigate the maze-like passages)
Another reason to avoid TCP for gaming: TCP is a stream protocol (called "SOCK_STREAM" in the Unix header files), meaning that logically it is providing a linear sequence of data. This maps perfectly to audio, which is just amplitude over time. For audio+visual work, you may need 2 separate streams, if the picture and sound have different delivery constraints (for example, sound needs less bandwith overall, but any skipping in the audio stream will be more obvious to the audience than a dropped frame of video).
In a videogame, there aren't just one or two logical streams of data- there's the player himself, his enemies, flying missiles, powerups on the ground... all of those may have different minimum acceptable update rates.
The FAST website points to "FAST vs Linux TCP" performance comparisons as a demonstration of their success. Linux's TCP/IP code is completely different from BSD's, right? (In the past, the Linux stack was reported to be "dead-slow" in some conditions, hopefully this has been fixed)
Do you think they'd have achieved less impressive results if comparing against FreeBSD TCP speeds? Or would you happen to have data comparing FreeBSD (using inflight_enable) to typical Linux performance?
The mention of "156 seconds" was an oversimplified example of the kind of problem. It does happen in real streaming applications, however, especially if playing from a live source where latency constraints don't permit lengthy buffers (most important in bidirectional VoIP apps)
Of course a streaming protocol uses a buffer. That's one reason why you don't want to run it over TCP. TCP provides its own buffer, which would be redundant with the one the higher-level protocol is also creating. Optimally, one fully-informed piece of software can manage all buffers.
Streaming music over TCP (even HTTP) is fine, because the bandwidth needs are so low that suboptimal solutions work. Streaming video is different- not only is the total bandwidth more than 10x higher, but you've got two separate streams of data whose buffer sizes need to be correlated.
Essentially, if the network is stressed enough so that framedrops (underflows of the application-level buffer) ever happen, then TCP will waste time retransmitting old data, while a hand-rolled UDP solution will recover quicker . Today's popular audio-only streaming doesn't usually push enough data to cause framedrop events.
You can experimentally check that UDP is better for streaming video with applications like RealPlayer. Watch some videos with it. Then adjust your firewall to block it's UDP ports (6970+) and try again (or use the HTTP setting from inside realplayer).
You're using an odd naming system for units of measurement. If you want the capitalization of letters to have meaning, be consistent with it.
"640k" vs "64Kbytes"- why change capitalization on the K? That doesn't mean anything, unless k=1024 and K=1000. But "10mb" vs "1MB" does mean millibits in the first case and megabytes in the second- not likely what you intended.
Aside from that, what you're saying is that you seem to need 10 bits of connection to transmit 8 bits of data. That's a 25% overhead, well in line with the the 10% suggested by joshuac, but completely different from the 600000% increase claimed in the article.
The last sentence of both news articles suggests that this broadband-optimized TCP system could be used by corporations like Disney to provide video-on-demand. (If they're talking to Microsoft, on the other hand, the result will just be a modification to the TCP/IP stack in Windows(r), which doesn't care at all what kind of data it's transmitting)
That's just wrong, at least according to the ways media companies have traditionally desired their materials to be broadcast over the internet. They typically use streaming protocols, which not only gives the user one-click startup, but also makes it non-trivial to keep a local copy of the file (enhancing the corporation's feeling of control).
However, a well-designed streaming protocol won't use TCP at all. TCP hides many characteristics of the network from the application software, and to stream properly it needs to know as much as possible. One example of why TCP is bad for streaming: in streaming, you try to keep advancing time at a constant rate. Once 156 seconds of playing have elapsed, you want to be showing video from exactly 156 seconds into the source file. If at 155 seconds some packets were dropped, you should just skip over them and continue onward. TCP, however, will always try to retransmit any lost packets, even if that means they'll arrive too late to do any good. TCP has no knowledge that packets may expire after a fixed time, but a custom-built UDP protocol can be aware of that constraint. (Here's a reference on preferring UDP in video streaming)
On the other hand, maybe a corporation will realize that properly controlled non-streaming playback can provide a better end-user experience (guaranteeing, for example, that once playing starts, network failures will never interrupt it). In that case, they might either try to push Microsoft to integrate this faster TCP/IP into Windows(r), or more interestingly, implement it themselves in customized player software.
It's possible to implement a protocol equivalent to TCP on top of UDP, with only a tiny constant amount of overhead. So a programmer for realplayer, quicktime, or mplayer might be able to add the techniques from this research to his own code, even without support in the operating system.
Rsync shouldn't be compared to TCP or this variant TCP. That's like asking if a Pentium is faster than a Compaq.
Rsync is an application-level protocol, as are HTTP and FTP. TCP is a transport-level protocol. Rsync, HTTP, and FTP all run on top of TCP. If the modified TCP described in the article works correctly, then they can all run on top of it as well, without those programs being aware that anything is different (only the TCP/IP stack in your OS will change, nothing else).
(Technically, rsync runs on top of rsh or ssh, which are both themselves application-level protocols. But those two run on TCP. Some application-level protocols don't use TCP at all, but instead prefer UDP. For example, games like Quake3)
The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.)
That's the usual acceleration provided by this planet's gravitational field. It's equivalent to 32 feet/second/second, converted into the metric system.
As I see it (hard to say because the article wasn't exactly technical), here is how it's going to work:
That's wrong. You were possibly misled by a bad article. Your diagram of "Slow TCP" isn't describing TCP at all, but a more primitive protocol that can be called "Stop and Wait". Stop-and-Wait provides some of the same advantages of TCP (reliability and consistency), but obviously takes a painfully long time to transmit a file, so it's little used in real life.
The idea that you can send many data packets before getting an ACK is already part of normal TCP. It's called the "sending window", and it measures the number of packets that can be sent before waiting for an ACK. The sending window is basically an estimate of the bandwidth of the link, which TCP maintains as it runs. The estimate starts out low, and then is continually increased as the transmission goes on. As soon as ACKs fail to arrive, the assumption is that the bandwidth was exceeded, and the estimate is cut in half. It's a linear-increase, exponential falloff procedure- which is meant to prevent from impairing the TCP performance of other users (you increase your transmission speed slowly, but decrease it quickly if there's an overload). The lineary increase of the window size is called "slow start".
Apparently, this research uses a different technique to obtain the starting estimate of the bandwidth available. Instead of sequentially increasing the window size up to gigabit levels as the connection goes, they start out with a large estimate, because they already know the link is fast.
it won't benefit "big corporations", it shouldn't threaten them either
It'll threaten them a little bit. This proposal will increase the public domain, which is in competition with corporations that sell entertainment. (More free sources of amusement -> less dollars for Disney)
Megacorps don't only want lengthy copyrights so they can continue to market their old works- they also want to keep other peoples' old works from being freely distributed.
Imagine what would happen if the public domain extended into the 1930s or 40s, so that cartoons and TV shows began expiring... Napster-like services could have a legal use!
The Steamboat Willy copyright will soon expire. Do you want to pay a few dollars every few years, or do you pay hundreds of thousands of dollars to get all copyrights (not just yours) extended?
This proposal won't help Disney there. It doesn't alter the maximum length of copyrights. Disney will still have to pay $100,000 to get all copyrights extended in 2013.
At any rate, in the specific case of QT, just a couple of comments - I can't see why the DoD wouldn't just go ahead and buy a commercial license anyway.
They are allegeric to paying license fees for software. Even though it's just a per-seat developer license, they're unwilling to spend a few thousand dollars for every developer who might have to edit the program in the future. Nevermind that 2 weeks of programmer labour nearly exceeds the cost of a license. Partly, this is due to capital expenditures coming from a different part of the budget than payroll. (If a manager has a programmer under him, he can't stop paying him without finding a reason to fire, or admitting that his department is overstaffed. But dollars to equip that guy can be easily diverted to other needs.)
(Obviously, the choice to buy Microsoft Windows comes from an entirely different part of the DoD than I am referring to. Paying $20 million for a giant site license doesn't feel as expensive as $1000/head, because the payment is temporaly disjoint from the installation)
The third parties reference is to a situation where you have distributed the program publically, and it's gone on from there to third parties.
Margins are much too far over to type very much more. But there's no reference to public distribution in the section on the third-party offer, or in the GPL at all. The GPL doesn't make any distinction between sending the program to a member of the public and simply making a copy. Section 3 says you can only make a copy if it is accompanied by an offer. Section 4 mentions that you "may not copy" except as described in section 3. Section 5 reminds us that section 4 is redundant, as copyright law already forbids copying software.
Obviously this can't come up if you don't do external distribution
It comes up if you make a "copy". It's the 3rd word of section 3. The GPL makes no mention of internal vs external use, or public vs private copying.
If there were such a distinction, and "external distribution" had some special meaning, then the GPL should've had some guidelines on exactly what qualifies as "external". If the Army writes a program and gives it to the Navy, is that external? Or are they both just part of the DoD organization? What about the IRS writing something to prepare your taxes, and giving it out to all payers of income tax? The "Citizens of the United States" are an organization too. (Once again, parts of the GPL FAQ resemble guidelines on this area. But they're not part of the license, and unless somehow demonstrated to be implied by the license text, they mean nothing)
I'm sure the DoD has plenty of experience with protecting secret data.
They do. It involves the Security officer removing your hard drive and locking it in his safe at night, and is far too cumbersome to apply to a mere software program. And anyway, if a GPLed program were classified as secret, GPL section 7 comes into play: "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."
Meaning that if any piece of GPL code were accidently infected with top secret data, the entire program would have to be destroyed. (The hard-drives run through shredders, or thereabouts)
but I don't think it's within his power to forbid either.
GPL section 6: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein".
Obviously for some reason you don't want to believe this, but I can't for the life of me see why.
Because this is the interpretation of DoD lawyers. The example of the Qt library wasn't a fabrication of mine- it really happened. I suspect that the Trolltech lawyers felt the same way.
I'm saying in such a situation the DoD would be, legally, distributing it only to itself.
If you take that interpretation, which I don't grant, it still doesn't work. The GPL requires that redistribution rights are given not only to the direct recipient, but to "any third party" who gets ahold of the binaries, by whatever means.
Maybe you can view the employees of the DoD as parts of an aggregate entity- but they never stop being individuals. When 11:59 rolls around and lunch hour starts, suppose a DoD employee takes a break from surfing nascar.com and pokes around on his hard drive.
"Hmm,/usr/war/robotank/doc/COPYING. Seems like an interesting file, I'll take a look at it. Why, it says here, in section 3, that I can copy and distribute the Program! Hey, the kids would love to see a copy of this! I'll just email it over to them!"
Prehaps you think that the person who prepared the installation package for that software would've stripped the GPL license from it, leaving no way for the employee end-user to learn of her rights. I suppose that would be tempting. But removing the GPL text from a modified version (or even an unmodified one) is a serious license violation. Remove that license, and you have no right to install the binaries on more than one machine at a time.
Once more, from the top: copyright law forbids you from copying works without the author's permission. The GPL gives some permission. In section 3, it says
"3. You may copy and distribute the Program () in object code or executable form provided that you also do one of the following... Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code"
See where that says "copy"? You don't even have permission to make a copy of the software on a different computer (no need to argue about what "distribution" means) unless each copy is accompanied by an offer for the source code, valid for anybody who has the offer.
The existence of that offer, alongside every copy of the program, makes it almost inevitable that one of the employees will get his hands on it, and decide to invoke his right to the code- not as an employee, but in a role as "any third party".
It's concievable that an organization might try to work around this by structuring file permissions in such a way that although the offer exists on the computers, users never have the chance to view or print it. That would require extreme measures, and I don't believe they'd be legally binding, but won't get into the details.
It's the publically stated opinion of the lawyers that wrote the license,
I've never seen this stated. The oft-cited GPL FAQ entry is too terse to count as a statement on much of anything. (And this published PDF journal article merely references the FAQ) The only thing that FAQ says clearly is that the organization has no obligation to publish externally, which we already knew. It makes the assumption that the members of the organization won't wish to spread it to outsiders, but says nothing about the organization's ability to forbid them that right.
That forbiddance, however, is obviously counter to the intent of the GPL, which was to empower the users of software with the ability to modify and redistribute it. 300,000 soldiers who run modified GPL software but aren't allowed to take copies cannot possibly be what Stallman intended.
Who's talking about 'passing out a program to 10,000 people?' I'm talking about installing it on company computers to be used by company employees on company time. You appear to be talking now about passing out CDs to take home and use. Very different situations.
I'm talking about sending out files to install on government computers to be used by government employees on government time. (There happen to be 10,000 of them, and spread around the world). Entirely similar situations, from a copyright perspective. Making copies of a program cannot be done without the author's permission, which means obeying her license terms.
No, I wasn't. I was explicitly forbidden from distributing it in fact. This was made very clear.
Get a dictionary. Walking around with a CD-Rom and installing a program on 100s of computers is distribution. You seem not to understand what that word means. To make a copy of something and leave it in a different position than the original copy- that's distribution.
This seems to be the key point where one of us isn't understanding. Why the hell would the DoD need to 'pass out' copies of Qt to anyone if they want to use it internally?
Because all of their employees can't sit in the same cubicle at once. If you spread something out to different geographical locations, you "pass it out"- you distribute it!
This doesn't entail 'passing out copies' to everyone and their dog
No, that would be "publication". A special case of "distribution". The GPL covers not only publication, but also distribution in general.
They simply receive the use of the binary while they are at that station.
As a side note, the GPL requires anyone allowed to run a heavily interactive program to take a copy of it with him. This isn't well known, and never seems to be enforced. But if you check the GPL, in section 2c, it states that any program with a splash-screen must state that "users may redistribute the program".
ok, if the author is dead, how exactly is he punished???
Very simple. Lets suppose a copyright term equals Life + 10 years.
If you're 20, and you sell a publisher perpetual rights to a book, you can negotiate for an expected 66 years of profitable sales. If a 90 year old writes a book of equalivalent quality, the publisher won't be willing to pay him as much, because his expected lifespan is already used up- the copyright will only last about 11 more years.
Equivalently good authors, but one of them gets a smaller check from the publishing house because of government age discrimination.
(Additionally, there's the whole matter of children to think of. Many people want their kids to be well provided for, even after their deaths. It's somewhat Darwininan. What if two 26-year old authors write successful books, but one is eaten by a cougar just after publication? Her kids will be out not only a parent, but a million dollars of royalty)
Your argument is like saying that because I didn't get off my arse and get a job until I was 85 the ones who hired me are punishing me for being old, after all, if I won't have as long to live and get paychecks.
No. If you work from 85-90, that's much less total productivity than having a job from 20-90. Less work, so less pay. That's fine. But if two authors do equal work- they both spend 6 months writing excellent books- it's not fair for one to be paid less, just because he's older.
For this reason Security through Latency isn't a much better solution either.
There's no such thing as Security Through Latency, except as a bad idea that the US government forced upon some private citizens by its export restrictions (defining powerful encryption as illegal weapons).
Moore's Observation of increasing computer speeds is well known. "CPU speeds double every 18 months". Lets assume for a minute that there's a techological advance, and they start doubling every 3 months. That's a 16x improvement per year- to keep up with that, you just need to increase the size of the crypto key by 4 bits per year. Easy. Some people today already use 2048 bit keys, which will take centuries to brute-force, even if Moore's Observation speeds up drastically.
Increasing CPU speeds will always take enormous technical effort. Increasing the resiliency of encryption only takes doubling the size of an integer in the software.
I wish it did. In a strict reading of the Constition, the word "useful" means all copyright on works of fiction or entertainment is beyond the scope of Congressional powers. Of course, the courts will never agree- such a position would be far too disruptive to the world economy.
A book, once published, adds something to society and ceases to belong solely to its creator.
More importantly: A book, prior to being written, comes from something bigger than its sole creator. The whole of society contributes to it.
There's no truely original work- all ideas are derived from others. The expiration of copyright is partly an acknowledgement of the intractability of determining a single point of authorship.
Corporations will automate the process of offering $100 for the rights to every item about to go off-copyright,
They'll go bankrupt, because there is a huge, huge number of copyrighted materials. With today's computers and hard drives, amateurs are stamping out works (which are incidentally copyrighted) at an enormous and increasing rate. And obviously, few of those works will have much sale value.
It's more important to preserved those as historical artifacts, which is one benefit of the proposal.
How about a law that limits copyrights to life of the author and leave it at that. Why should anyone inherit something they didn't create?
Using the author's lifespan as any part of the calculation of a copyright term is financial discrimination by the government. It punishes authors who are old or sick and rewards the young.
Overall, Life+X copyrights reduce the incentive for sucessful authors to write more stuff, because their newer works will have shorter terms of sale then their earlier publications. (And "incentive to create" is the whole US Constitutional justification for copyright law)
Allowing prepayment would undermine the goal of the proposal.
The point of the law is not to impose a financial burden on copyright holders by making it significantly expensive to extend the duration. It's to create an bookkeeping burden, so that the corporation will have to keep a record of it's copyrights for at least as long as it expects the law to protect them.
The idea is to liberate works that have been forgotten by their authors. Allowing prepayment would transfer the bookkeeping task from the corporations to the government, which is precisely what we want to avoid (the total cost of remembering to renew in 50 years will be much greater than the nominal fee)
Maybe you don't realize how common copyrights are. Since the Berne convention, just lifting pen from paper is enough to create a new "copyrighted work". You can possess copyrights without even noticing it.
Every email you send and every Slashdot comment you post is a separate copyright belonging to you. (Check the bottom of this page: "Comments are owned by the Poster")
The fact that you probably own too many copyrights to keep track of them all is a benefit of the proposed law. It means that corporations can only afford to keep long-lasting copyrights on material that they're actually aware of, that has actually been published, and that have some hope of earning money.
This is so totally wrong, I can hardly bear to respond anymore. One overall point is that the GPL isn't about companies- it's about people.
But even though a company is the copyright owner of those modifications, it doesn't imply that its employees are automatically given a personal license.
Not automatically. Only as soon as you perform an action which is in violation of the original author's copyright privileges. Which means copying the software for another employee.
When one member of the company gives the modified software to another, he either gives that person unlimited permission to redistribute copies, or he violates the GPL.
If a company wishes to give its employees copies of GPLed software, it must either give them personal licenses.
If one of the developers takes that software and posts it on the web, he has stolen company property.
No, he has not. Unless he were the one and only guy who had written those modifications.
If boss Bob instructs coder Carl to edit Gimp for their own purposes, then Carl's changes are company restricted... until he gives the program to either Bob or Sally (in sales). Then, because a violation of the Gimp author's copyright has occured, the GPL must be invoked, so Bob & Sally have been given unlimited permission to redistribute.
If you don't understand that, then just read the GPL. Section 2 states that any modified work you distribute must be licensed under the GPL. (And yes, giving copies to co-workers meets any sane interpretation of "distributed") Thus GPL section 3 will apply to the modified work. And section 3 states that whoever has a copy can give further copies to anybody he likes.
If the boss instructs his employees to never give out copies, then he has essentially scratched out section 3 of the GPL. Meaning that he doesn't intend for the GPL to apply to those derived works, meaning the company has no right to possess the modified copies.
What logic? The CD-Rom of MS Office doesn't contain a license agreement stating "You may copy and distribute the Program". But, the distribution media of any GPL software says exactly that. (It's on line 134)
Slashdot Mirror
The Isreali Army is one of the best in the world at defending itself...but it's never pro-active
They're highly proactive. They conquered the entire nation of Israel in 1948. And then in 1967 they captured more land and headed off any possible retailation by destroying not only the armies of all surrounding Arab nations, but also killing 34 US servicement who witnessed the pre-emptive attack.
Look at how they deal with terrorists. I'd sure say that launching missiles from a helicopter to explode a suspected organizer is pro-active!
a technologically superior military if you arm 2 billion people with steak knives and send them against 100 million with guns
In the second world war, US Marines killed attackers with knives at a 600:1 ratio. And with better equipment, US pilots killed lightly armed people at a ratio of 14000:1.
The American lives sacrificed were lives that other European nations didn't have to sacrifice.
It wasn't the US lives that made a difference, but the equipment (and the economic/financial power that bought those things)
For each US soldier killed, more than 50 Russian warriors gave their lives. That's not counting the many British, Polish, and yes, even French. (Contrary to recent jokes, the French army didn't surrender- they were killed)
Plus, for those other nations, it wasn't just their soldiers dying- civilians were also decimated by Axis assault.
Internet traffic, if I remember correctly, is bursty
Part of what the FAST TPC project tries to do is make it less bursty, by inserting a timer mechanism on the sender to spread out the transmission of packets. It's mentioned on page 5 of the FAST pdf.
(Willingly throttling your send rate will reduce the speed you can send small files, but when sending large files it'll reduce the chances of overloading the network, which could lead to an overall improvement)
Perhaps this could finally lead to the possibility of having a FPS (First Person Shooter) use TCP instead of UDP.
No, it couldn't. In a comment above I described how this new system is inappropriate for streaming media applications, and took some flak because for many uses of streaming, enormous amounts of prebuffering (amounting to 10+ seconds of latency for the viewer) are acceptable. Which makes TCP/IP OK.
Listening to a radio station, you may not care that the sounds you hear are 2 minutes old. But if you're talking to another person, 2 seconds of delay will press the limits of tolerance. And for shooting animated monsters, 200 ms is as high as you'd want to go. (I played an internet FPS recently and had a stellar ping of 26 ms. The opposition was devastated, despite my inability to navigate the maze-like passages)
Another reason to avoid TCP for gaming: TCP is a stream protocol (called "SOCK_STREAM" in the Unix header files), meaning that logically it is providing a linear sequence of data. This maps perfectly to audio, which is just amplitude over time. For audio+visual work, you may need 2 separate streams, if the picture and sound have different delivery constraints (for example, sound needs less bandwith overall, but any skipping in the audio stream will be more obvious to the audience than a dropped frame of video).
In a videogame, there aren't just one or two logical streams of data- there's the player himself, his enemies, flying missiles, powerups on the ground... all of those may have different minimum acceptable update rates.
The FAST website points to "FAST vs Linux TCP" performance comparisons as a demonstration of their success. Linux's TCP/IP code is completely different from BSD's, right? (In the past, the Linux stack was reported to be "dead-slow" in some conditions, hopefully this has been fixed)
Do you think they'd have achieved less impressive results if comparing against FreeBSD TCP speeds? Or would you happen to have data comparing FreeBSD (using inflight_enable) to typical Linux performance?
The mention of "156 seconds" was an oversimplified example of the kind of problem. It does happen in real streaming applications, however, especially if playing from a live source where latency constraints don't permit lengthy buffers (most important in bidirectional VoIP apps)
.
Of course a streaming protocol uses a buffer. That's one reason why you don't want to run it over TCP. TCP provides its own buffer, which would be redundant with the one the higher-level protocol is also creating. Optimally, one fully-informed piece of software can manage all buffers.
Streaming music over TCP (even HTTP) is fine, because the bandwidth needs are so low that suboptimal solutions work. Streaming video is different- not only is the total bandwidth more than 10x higher, but you've got two separate streams of data whose buffer sizes need to be correlated.
Essentially, if the network is stressed enough so that framedrops (underflows of the application-level buffer) ever happen, then TCP will waste time retransmitting old data, while a hand-rolled UDP solution will recover quicker . Today's popular audio-only streaming doesn't usually push enough data to cause framedrop events
You can experimentally check that UDP is better for streaming video with applications like RealPlayer. Watch some videos with it. Then adjust your firewall to block it's UDP ports (6970+) and try again (or use the HTTP setting from inside realplayer).
You're using an odd naming system for units of measurement. If you want the capitalization of letters to have meaning, be consistent with it.
"640k" vs "64Kbytes"- why change capitalization on the K? That doesn't mean anything, unless k=1024 and K=1000. But "10mb" vs "1MB" does mean millibits in the first case and megabytes in the second- not likely what you intended.
Aside from that, what you're saying is that you seem to need 10 bits of connection to transmit 8 bits of data. That's a 25% overhead, well in line with the the 10% suggested by joshuac, but completely different from the 600000% increase claimed in the article.
The last sentence of both news articles suggests that this broadband-optimized TCP system could be used by corporations like Disney to provide video-on-demand. (If they're talking to Microsoft, on the other hand, the result will just be a modification to the TCP/IP stack in Windows(r), which doesn't care at all what kind of data it's transmitting)
That's just wrong, at least according to the ways media companies have traditionally desired their materials to be broadcast over the internet. They typically use streaming protocols, which not only gives the user one-click startup, but also makes it non-trivial to keep a local copy of the file (enhancing the corporation's feeling of control).
However, a well-designed streaming protocol won't use TCP at all. TCP hides many characteristics of the network from the application software, and to stream properly it needs to know as much as possible. One example of why TCP is bad for streaming: in streaming, you try to keep advancing time at a constant rate. Once 156 seconds of playing have elapsed, you want to be showing video from exactly 156 seconds into the source file. If at 155 seconds some packets were dropped, you should just skip over them and continue onward. TCP, however, will always try to retransmit any lost packets, even if that means they'll arrive too late to do any good. TCP has no knowledge that packets may expire after a fixed time, but a custom-built UDP protocol can be aware of that constraint.
(Here's a reference on preferring UDP in video streaming)
On the other hand, maybe a corporation will realize that properly controlled non-streaming playback can provide a better end-user experience (guaranteeing, for example, that once playing starts, network failures will never interrupt it). In that case, they might either try to push Microsoft to integrate this faster TCP/IP into Windows(r), or more interestingly, implement it themselves in customized player software.
It's possible to implement a protocol equivalent to TCP on top of UDP, with only a tiny constant amount of overhead. So a programmer for realplayer, quicktime, or mplayer might be able to add the techniques from this research to his own code, even without support in the operating system.
Rsync shouldn't be compared to TCP or this variant TCP. That's like asking if a Pentium is faster than a Compaq.
Rsync is an application-level protocol, as are HTTP and FTP. TCP is a transport-level protocol. Rsync, HTTP, and FTP all run on top of TCP. If the modified TCP described in the article works correctly, then they can all run on top of it as well, without those programs being aware that anything is different (only the TCP/IP stack in your OS will change, nothing else).
(Technically, rsync runs on top of rsh or ssh, which are both themselves application-level protocols. But those two run on TCP. Some application-level protocols don't use TCP at all, but instead prefer UDP. For example, games like Quake3)
The latter is harder. 9.8 is a constant (I don't know where it comes from, but that value is often quoted, and seems to work out in my experience.)
That's the usual acceleration provided by this planet's gravitational field. It's equivalent to 32 feet/second/second, converted into the metric system.
It comes from work by Isaac Newton.
As I see it (hard to say because the article wasn't exactly technical), here is how it's going to work:
That's wrong. You were possibly misled by a bad article. Your diagram of "Slow TCP" isn't describing TCP at all, but a more primitive protocol that can be called "Stop and Wait". Stop-and-Wait provides some of the same advantages of TCP (reliability and consistency), but obviously takes a painfully long time to transmit a file, so it's little used in real life.
The idea that you can send many data packets before getting an ACK is already part of normal TCP. It's called the "sending window", and it measures the number of packets that can be sent before waiting for an ACK. The sending window is basically an estimate of the bandwidth of the link, which TCP maintains as it runs. The estimate starts out low, and then is continually increased as the transmission goes on. As soon as ACKs fail to arrive, the assumption is that the bandwidth was exceeded, and the estimate is cut in half. It's a linear-increase, exponential falloff procedure- which is meant to prevent from impairing the TCP performance of other users (you increase your transmission speed slowly, but decrease it quickly if there's an overload). The lineary increase of the window size is called "slow start".
Apparently, this research uses a different technique to obtain the starting estimate of the bandwidth available. Instead of sequentially increasing the window size up to gigabit levels as the connection goes, they start out with a large estimate, because they already know the link is fast.
And that rambling post is related to copyright expiring at death how?
(Please don't bother trying to answer. It's a rhetorical question.)
it won't benefit "big corporations", it shouldn't threaten them either
It'll threaten them a little bit. This proposal will increase the public domain, which is in competition with corporations that sell entertainment. (More free sources of amusement -> less dollars for Disney)
Megacorps don't only want lengthy copyrights so they can continue to market their old works- they also want to keep other peoples' old works from being freely distributed.
Imagine what would happen if the public domain extended into the 1930s or 40s, so that cartoons and TV shows began expiring... Napster-like services could have a legal use!
The Steamboat Willy copyright will soon expire. Do you want to pay a few dollars every few years, or do you pay hundreds of thousands of dollars to get all copyrights (not just yours) extended?
This proposal won't help Disney there. It doesn't alter the maximum length of copyrights. Disney will still have to pay $100,000 to get all copyrights extended in 2013.
At any rate, in the specific case of QT, just a couple of comments - I can't see why the DoD wouldn't just go ahead and buy a commercial license anyway.
They are allegeric to paying license fees for software. Even though it's just a per-seat developer license, they're unwilling to spend a few thousand dollars for every developer who might have to edit the program in the future. Nevermind that 2 weeks of programmer labour nearly exceeds the cost of a license. Partly, this is due to capital expenditures coming from a different part of the budget than payroll. (If a manager has a programmer under him, he can't stop paying him without finding a reason to fire, or admitting that his department is overstaffed. But dollars to equip that guy can be easily diverted to other needs.)
(Obviously, the choice to buy Microsoft Windows comes from an entirely different part of the DoD than I am referring to. Paying $20 million for a giant site license doesn't feel as expensive as $1000/head, because the payment is temporaly disjoint from the installation)
The third parties reference is to a situation where you have distributed the program publically, and it's gone on from there to third parties.
Margins are much too far over to type very much more. But there's no reference to public distribution in the section on the third-party offer, or in the GPL at all. The GPL doesn't make any distinction between sending the program to a member of the public and simply making a copy. Section 3 says you can only make a copy if it is accompanied by an offer. Section 4 mentions that you "may not copy" except as described in section 3. Section 5 reminds us that section 4 is redundant, as copyright law already forbids copying software.
Obviously this can't come up if you don't do external distribution
It comes up if you make a "copy". It's the 3rd word of section 3. The GPL makes no mention of internal vs external use, or public vs private copying.
If there were such a distinction, and "external distribution" had some special meaning, then the GPL should've had some guidelines on exactly what qualifies as "external". If the Army writes a program and gives it to the Navy, is that external? Or are they both just part of the DoD organization? What about the IRS writing something to prepare your taxes, and giving it out to all payers of income tax? The "Citizens of the United States" are an organization too. (Once again, parts of the GPL FAQ resemble guidelines on this area. But they're not part of the license, and unless somehow demonstrated to be implied by the license text, they mean nothing)
I'm sure the DoD has plenty of experience with protecting secret data.
They do. It involves the Security officer removing your hard drive and locking it in his safe at night, and is far too cumbersome to apply to a mere software program. And anyway, if a GPLed program were classified as secret, GPL section 7 comes into play: "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."
Meaning that if any piece of GPL code were accidently infected with top secret data, the entire program would have to be destroyed. (The hard-drives run through shredders, or thereabouts)
but I don't think it's within his power to forbid either.
GPL section 6: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein".
Because this is the interpretation of DoD lawyers. The example of the Qt library wasn't a fabrication of mine- it really happened. I suspect that the Trolltech lawyers felt the same way.
I'm saying in such a situation the DoD would be, legally, distributing it only to itself.
If you take that interpretation, which I don't grant, it still doesn't work. The GPL requires that redistribution rights are given not only to the direct recipient, but to "any third party" who gets ahold of the binaries, by whatever means.
Maybe you can view the employees of the DoD as parts of an aggregate entity- but they never stop being individuals. When 11:59 rolls around and lunch hour starts, suppose a DoD employee takes a break from surfing nascar.com and pokes around on his hard drive.
Prehaps you think that the person who prepared the installation package for that software would've stripped the GPL license from it, leaving no way for the employee end-user to learn of her rights. I suppose that would be tempting. But removing the GPL text from a modified version (or even an unmodified one) is a serious license violation. Remove that license, and you have no right to install the binaries on more than one machine at a time.
Once more, from the top: copyright law forbids you from copying works without the author's permission. The GPL gives some permission. In section 3, it says
See where that says "copy"? You don't even have permission to make a copy of the software on a different computer (no need to argue about what "distribution" means) unless each copy is accompanied by an offer for the source code, valid for anybody who has the offer.
The existence of that offer, alongside every copy of the program, makes it almost inevitable that one of the employees will get his hands on it, and decide to invoke his right to the code- not as an employee, but in a role as "any third party".
It's concievable that an organization might try to work around this by structuring file permissions in such a way that although the offer exists on the computers, users never have the chance to view or print it. That would require extreme measures, and I don't believe they'd be legally binding, but won't get into the details.
It's the publically stated opinion of the lawyers that wrote the license,
I've never seen this stated. The oft-cited GPL FAQ entry is too terse to count as a statement on much of anything. (And this published PDF journal article merely references the FAQ) The only thing that FAQ says clearly is that the organization has no obligation to publish externally, which we already knew. It makes the assumption that the members of the organization won't wish to spread it to outsiders, but says nothing about the organization's ability to forbid them that right.
That forbiddance, however, is obviously counter to the intent of the GPL, which was to empower the users of software with the ability to modify and redistribute it. 300,000 soldiers who run modified GPL software but aren't allowed to take copies cannot possibly be what Stallman intended.
Who's talking about 'passing out a program to 10,000 people?' I'm talking about installing it on company computers to be used by company employees on company time. You appear to be talking now about passing out CDs to take home and use. Very different situations.
I'm talking about sending out files to install on government computers to be used by government employees on government time. (There happen to be 10,000 of them, and spread around the world). Entirely similar situations, from a copyright perspective. Making copies of a program cannot be done without the author's permission, which means obeying her license terms.
No, I wasn't. I was explicitly forbidden from distributing it in fact. This was made very clear.
Get a dictionary. Walking around with a CD-Rom and installing a program on 100s of computers is distribution. You seem not to understand what that word means. To make a copy of something and leave it in a different position than the original copy- that's distribution.
This seems to be the key point where one of us isn't understanding. Why the hell would the DoD need to 'pass out' copies of Qt to anyone if they want to use it internally?
Because all of their employees can't sit in the same cubicle at once. If you spread something out to different geographical locations, you "pass it out"- you distribute it!
This doesn't entail 'passing out copies' to everyone and their dog
No, that would be "publication". A special case of "distribution". The GPL covers not only publication, but also distribution in general.
They simply receive the use of the binary while they are at that station.
As a side note, the GPL requires anyone allowed to run a heavily interactive program to take a copy of it with him. This isn't well known, and never seems to be enforced. But if you check the GPL, in section 2c, it states that any program with a splash-screen must state that "users may redistribute the program".
ok, if the author is dead, how exactly is he punished???
Very simple. Lets suppose a copyright term equals Life + 10 years.
If you're 20, and you sell a publisher perpetual rights to a book, you can negotiate for an expected 66 years of profitable sales. If a 90 year old writes a book of equalivalent quality, the publisher won't be willing to pay him as much, because his expected lifespan is already used up- the copyright will only last about 11 more years.
Equivalently good authors, but one of them gets a smaller check from the publishing house because of government age discrimination.
(Additionally, there's the whole matter of children to think of. Many people want their kids to be well provided for, even after their deaths. It's somewhat Darwininan. What if two 26-year old authors write successful books, but one is eaten by a cougar just after publication? Her kids will be out not only a parent, but a million dollars of royalty)
Your argument is like saying that because I didn't get off my arse and get a job until I was 85 the ones who hired me are punishing me for being old, after all, if I won't have as long to live and get paychecks.
No. If you work from 85-90, that's much less total productivity than having a job from 20-90. Less work, so less pay. That's fine. But if two authors do equal work- they both spend 6 months writing excellent books- it's not fair for one to be paid less, just because he's older.
For this reason Security through Latency isn't a much better solution either.
There's no such thing as Security Through Latency, except as a bad idea that the US government forced upon some private citizens by its export restrictions (defining powerful encryption as illegal weapons).
Moore's Observation of increasing computer speeds is well known. "CPU speeds double every 18 months". Lets assume for a minute that there's a techological advance, and they start doubling every 3 months. That's a 16x improvement per year- to keep up with that, you just need to increase the size of the crypto key by 4 bits per year. Easy. Some people today already use 2048 bit keys, which will take centuries to brute-force, even if Moore's Observation speeds up drastically.
Increasing CPU speeds will always take enormous technical effort. Increasing the resiliency of encryption only takes doubling the size of an integer in the software.
I wish it did. In a strict reading of the Constition, the word "useful" means all copyright on works of fiction or entertainment is beyond the scope of Congressional powers. Of course, the courts will never agree- such a position would be far too disruptive to the world economy.
A book, once published, adds something to society and ceases to belong solely to its creator.
More importantly: A book, prior to being written, comes from something bigger than its sole creator. The whole of society contributes to it.
There's no truely original work- all ideas are derived from others. The expiration of copyright is partly an acknowledgement of the intractability of determining a single point of authorship.
Corporations will automate the process of offering $100 for the rights to every item about to go off-copyright,
They'll go bankrupt, because there is a huge, huge number of copyrighted materials. With today's computers and hard drives, amateurs are stamping out works (which are incidentally copyrighted) at an enormous and increasing rate. And obviously, few of those works will have much sale value.
It's more important to preserved those as historical artifacts, which is one benefit of the proposal.
How about a law that limits copyrights to life of the author and leave it at that. Why should anyone inherit something they didn't create?
Using the author's lifespan as any part of the calculation of a copyright term is financial discrimination by the government. It punishes authors who are old or sick and rewards the young.
Overall, Life+X copyrights reduce the incentive for sucessful authors to write more stuff, because their newer works will have shorter terms of sale then their earlier publications. (And "incentive to create" is the whole US Constitutional justification for copyright law)
Allowing prepayment would undermine the goal of the proposal.
The point of the law is not to impose a financial burden on copyright holders by making it significantly expensive to extend the duration. It's to create an bookkeeping burden, so that the corporation will have to keep a record of it's copyrights for at least as long as it expects the law to protect them.
The idea is to liberate works that have been forgotten by their authors. Allowing prepayment would transfer the bookkeeping task from the corporations to the government, which is precisely what we want to avoid (the total cost of remembering to renew in 50 years will be much greater than the nominal fee)
Maybe you don't realize how common copyrights are. Since the Berne convention, just lifting pen from paper is enough to create a new "copyrighted work". You can possess copyrights without even noticing it.
Every email you send and every Slashdot comment you post is a separate copyright belonging to you. (Check the bottom of this page: "Comments are owned by the Poster")
The fact that you probably own too many copyrights to keep track of them all is a benefit of the proposed law. It means that corporations can only afford to keep long-lasting copyrights on material that they're actually aware of, that has actually been published, and that have some hope of earning money.
This is so totally wrong, I can hardly bear to respond anymore. One overall point is that the GPL isn't about companies- it's about people.
But even though a company is the copyright owner of those modifications, it doesn't imply that its employees are automatically given a personal license.
Not automatically. Only as soon as you perform an action which is in violation of the original author's copyright privileges. Which means copying the software for another employee.
When one member of the company gives the modified software to another, he either gives that person unlimited permission to redistribute copies, or he violates the GPL.
If a company wishes to give its employees copies of GPLed software, it must either give them personal licenses.
If one of the developers takes that software and posts it on the web, he has stolen company property.
No, he has not. Unless he were the one and only guy who had written those modifications.
If boss Bob instructs coder Carl to edit Gimp for their own purposes, then Carl's changes are company restricted... until he gives the program to either Bob or Sally (in sales). Then, because a violation of the Gimp author's copyright has occured, the GPL must be invoked, so Bob & Sally have been given unlimited permission to redistribute.
If you don't understand that, then just read the GPL. Section 2 states that any modified work you distribute must be licensed under the GPL. (And yes, giving copies to co-workers meets any sane interpretation of "distributed") Thus GPL section 3 will apply to the modified work. And section 3 states that whoever has a copy can give further copies to anybody he likes.
If the boss instructs his employees to never give out copies, then he has essentially scratched out section 3 of the GPL. Meaning that he doesn't intend for the GPL to apply to those derived works, meaning the company has no right to possess the modified copies.
What logic? The CD-Rom of MS Office doesn't contain a license agreement stating "You may copy and distribute the Program". But, the distribution media of any GPL software says exactly that. (It's on line 134)