Star Citizen: 23 million in funding and going up roughly ~100k/ day.
Crowd funding looks to be working these days. Who cares if the AAA titles and studios die when we have made it easy for creative people with good ideas to get funded!
G-sync (i.e. sync originated by the graphics card) seems like a good idea. It:
allows for the ability of single or multiple graphics cards within a computer to emulate genlock for multiple monitors, so that the refresh rates and refresh times of those monitors interact properly
allows for the synchronization of frame rendering and output, i.e. reducing display lag which is important for gamers and realtime applications.
allows for a graphics card to select the highest possible framerate (possibly under 60hz) when displaying higher resolutions (e.g. 4k or 8k) on cables/interfaces that don't allow for a full 60hz bitrate.
I think you mean the other way around. You don't add standards to patents, you use patents over parts of standards. Either that or you mean something about adding patents to patent protection pools?
In any case it isn't true that their patents are worthless when they don't put them in. Look at Microsoft with the FAT patents. What the current ruling does is encourage companies with patents to NOT disclose them, or to keep them as patent applications as long as possible (and thus they can be kept secret for longer) only to pull the patent out of the proverbial hat after the technology is established.
Again, the only way to fix this is to provide an ability to remove these patents from the patent holders.
You are being short-sighted then... because as a natural consequence, companies will not license their IPR for use in standards, and, if that isn't sufficient, they'll not make standards anymore.
The better solution is fixing the damn patent system. A mandated eminent-domain purchase of any patent deemed essential and then allowed for public use, for instance, would be an interesting way out, though fraught with its own problems (who determines the fair price? This is always the problem with any eminent-domain issue). I'd prefer those problems to what we have today, though.
The easy solution for this is for companies to stop releasing whatever people are calling 'standards', and instead let people reverse engineer it (and then sue with their patents), or to provide no FRAND terms when licensing the IPR, or not licensing the IPR.
What they're doing here is not going to incent the proper behaviors out of the actors-- it is pretty short-sighted. It would be better to abolish these patents for some one-time-fee when they become essential to the economy/public benefit in some way.
Ensuring that men have and *must take* as much leave when a child is born ends up improving equality *for women*, as now employers have no productivity basis for discriminating against women w.r.t. having kids.
Actually, it is possible to set up a circle of ownership, and lose the share that was owned by someone. At that point, there is no longer any owner who is a real person.
Firstly: their property is on our (the public's) right of way.
Secondly: Clearly I should apply your reasoning to other utility companies. Lets assume you're a libertarian, and out of touch with reality. As a result, your utility company, which is run by a greedy bastard, has decided to cut you off from water and electricity because:
a) He doesn't like you
b) You didn't buy his brother's product when it was offered to you
In any case, according to your argument, that is perfectly fine.
Wait, it gets better!
Lets assume you have a river running through your property... Is it ok to drop some poison into the stream? It is on your property at the time, right?
Mapping back to today: The bits flowing over Verizon's wires are NOT (for the mostpart) Verizon's. Why do they get to touch them?
Shooting a man in the leg doesn't stop him from speaking directly. By your definition, this would not be eroding someone's freedom of speech.
"The public venue" is no longer the public street corner. It is no longer newspapers.
It is the internet. If we wish to be able to converse freely and in a public venue today, it is done online.
Net Neutrality says that you cannot choose to censor or delay messages that you don't like on the network. This kind of thing is essential to free speech, now that the gov't has given away the public resources to make the public venue to private corporations.
Yes. Pipelining support was optional in HTTP/1.1 effectively. Multiplexing in SPDY is so essential that if you mess it up, Google (and probably all other sites that use SPDY) won't work at all. People are thus strongly motivated to get it right, which wasn't true of many of HTTP/1.1's effectively optional features.
We definitely looked at SCTP. It wasn't, and unfortunately isn't deployable.
I'm not sure I buy the argument that improving HTTP means we can't eventually improve the transport, btw. I think we can, but that it will take longer (e.g. ~10 years or more).
It all depends on the nature of the loss on the path the packets traverse. Correlated (i.e. simultaneous) loss will be *worse* to the many-connection case. When a network is congested this is the likely loss-type. Actual random loss (e.g. when using wifi and someone turns on the microwave) can cause a single connection to perform worse than many. In most cases, the single connection can outperform multiple connections after a bit of startup time.
In all cases many connections adds to buffer bloat and decreases the ability of the TCP stack to react to real congestion.
As for server push... in that case, the server determines what the browser may need. The browser can cancel streams if it finds it already has the resource being pushed. The server must announce what resources it will push before they're referenced in another resource (to avoid data races). This assumes some smarts in the servers that doesn't exist in typical HTTP servers (unless they're doing inlining).
Ask Patrick McManus, who implemented it:) There was a spec, which has been public since day one (no reverse engineering required), along with open-source implementations of both client and server. The SSL patch has been available as well and is hopefully going into the next OpenSSL release (but... those take a while).
Unfortunately, the spec was wrong in a couple of places, which Patrick pointed out as he went along (and so we fixed the spec). That is why it is good (and imho I wish it was still necessary) that the IETF wants to see multiple implementations by different implementors of specs.
SCTP is cool in a lot of ways. It just has some (substantial) deployment issues. Sadly, this is true of any non-tcp protocol. I hope that we continue to play with such, but I think that replacing TCP as a transport for reliable communication is probably farther down the line.
Slashdot Mirror
'nuff said
ok maybe not.
Star Citizen: 23 million in funding and going up roughly ~100k/ day.
Crowd funding looks to be working these days. Who cares if the AAA titles and studios die when we have made it easy for creative people with good ideas to get funded!
G-sync (i.e. sync originated by the graphics card) seems like a good idea.
It:
allows for the ability of single or multiple graphics cards within a computer to emulate genlock for multiple monitors, so that the refresh rates and refresh times of those monitors interact properly
allows for the synchronization of frame rendering and output, i.e. reducing display lag which is important for gamers and realtime applications.
allows for a graphics card to select the highest possible framerate (possibly under 60hz) when displaying higher resolutions (e.g. 4k or 8k) on cables/interfaces that don't allow for a full 60hz bitrate.
Good stuff.
I think you mean the other way around. You don't add standards to patents, you use patents over parts of standards. Either that or you mean something about adding patents to patent protection pools?
In any case it isn't true that their patents are worthless when they don't put them in.
Look at Microsoft with the FAT patents.
What the current ruling does is encourage companies with patents to NOT disclose them, or to keep them as patent applications as long as possible (and thus they can be kept secret for longer) only to pull the patent out of the proverbial hat after the technology is established.
Again, the only way to fix this is to provide an ability to remove these patents from the patent holders.
You are being short-sighted then... because as a natural consequence, companies will not license their IPR for use in standards, and, if that isn't sufficient, they'll not make standards anymore.
The better solution is fixing the damn patent system. A mandated eminent-domain purchase of any patent deemed essential and then allowed for public use, for instance, would be an interesting way out, though fraught with its own problems (who determines the fair price? This is always the problem with any eminent-domain issue). I'd prefer those problems to what we have today, though.
In both cases you're decoding media. Just point it out :)
What the AC says here seems spot on.
The easy solution for this is for companies to stop releasing whatever people are calling 'standards', and instead let people reverse engineer it (and then sue with their patents), or to provide no FRAND terms when licensing the IPR, or not licensing the IPR.
What they're doing here is not going to incent the proper behaviors out of the actors-- it is pretty short-sighted.
It would be better to abolish these patents for some one-time-fee when they become essential to the economy/public benefit in some way.
Thusfar, as far as I know, the speed of light has remained about the same...
So, you're saying that programmers read the SSL bytes directly and can interpret them? :)
That is impressive
Mod parent up, please!
Lol, and sadly, it does. But it isn't true for many other sites. :)
You should open up the perf tab of your browser and look at this page to see if it supports your conclusions.
Ensuring that men have and *must take* as much leave when a child is born ends up improving equality *for women*, as now employers have no productivity basis for discriminating against women w.r.t. having kids.
Actually, it is possible to set up a circle of ownership, and lose the share that was owned by someone.
At that point, there is no longer any owner who is a real person.
Firstly: their property is on our (the public's) right of way.
Secondly: Clearly I should apply your reasoning to other utility companies.
Lets assume you're a libertarian, and out of touch with reality.
As a result, your utility company, which is run by a greedy bastard, has decided to cut you off from water and electricity because:
a) He doesn't like you
b) You didn't buy his brother's product when it was offered to you
In any case, according to your argument, that is perfectly fine.
Wait, it gets better!
Lets assume you have a river running through your property...
Is it ok to drop some poison into the stream? It is on your property at the time, right?
Mapping back to today:
The bits flowing over Verizon's wires are NOT (for the mostpart) Verizon's. Why do they get to touch them?
Too late. :)
Shooting a man in the leg doesn't stop him from speaking directly.
By your definition, this would not be eroding someone's freedom of speech.
"The public venue" is no longer the public street corner. It is no longer newspapers.
It is the internet.
If we wish to be able to converse freely and in a public venue today, it is done online.
Net Neutrality says that you cannot choose to censor or delay messages that you don't like on the network.
This kind of thing is essential to free speech, now that the gov't has given away the public resources to make the public venue to private corporations.
Yes. Pipelining support was optional in HTTP/1.1 effectively.
Multiplexing in SPDY is so essential that if you mess it up, Google (and probably all other sites that use SPDY) won't work at all.
People are thus strongly motivated to get it right, which wasn't true of many of HTTP/1.1's effectively optional features.
As one of the creators of SPDY I can say: SPDY as specified today requires TLS and is only deployed using TLS.
yesh. :)
We definitely looked at SCTP.
It wasn't, and unfortunately isn't deployable.
I'm not sure I buy the argument that improving HTTP means we can't eventually improve the transport, btw. I think we can, but that it will take longer (e.g. ~10 years or more).
It all depends on the nature of the loss on the path the packets traverse.
Correlated (i.e. simultaneous) loss will be *worse* to the many-connection case. When a network is congested this is the likely loss-type.
Actual random loss (e.g. when using wifi and someone turns on the microwave) can cause a single connection to perform worse than many.
In most cases, the single connection can outperform multiple connections after a bit of startup time.
In all cases many connections adds to buffer bloat and decreases the ability of the TCP stack to react to real congestion.
As for server push... in that case, the server determines what the browser may need. The browser can cancel streams if it finds it already has the resource being pushed.
The server must announce what resources it will push before they're referenced in another resource (to avoid data races).
This assumes some smarts in the servers that doesn't exist in typical HTTP servers (unless they're doing inlining).
The browser signals the priority. The server does its best to respond to it.
The protocol allows this to occur.
Ask Patrick McManus, who implemented it :)
There was a spec, which has been public since day one (no reverse engineering required), along with open-source implementations of both client and server.
The SSL patch has been available as well and is hopefully going into the next OpenSSL release (but... those take a while).
Unfortunately, the spec was wrong in a couple of places, which Patrick pointed out as he went along (and so we fixed the spec). That is why it is good (and imho I wish it was still necessary) that the IETF wants to see multiple implementations by different implementors of specs.
SCTP is cool in a lot of ways. It just has some (substantial) deployment issues.
Sadly, this is true of any non-tcp protocol. I hope that we continue to play with such, but I think that replacing TCP as a transport for reliable communication is probably farther down the line.