Their idea was Javascript without strong typing will never be as fast or close to C.
When WebGL was added to the browser, they added some strong types for storing all the graphics data.
So the developers at Mozilla figured out they can leverage those strong types when doing CPU-intense operations and optimize the Javascript engine to take advantage of that. Then they figured out you can use a compiler to target those strong types and recompile existing C-code that way.
oVirt or vSphere (I've never used them myself, so I could be wrong) are usually centrally managed systems.
CloudStack or OpenStack are meant for building multi-tenant environments like Amazon, which means people get a tenant-account and an API. The API can be used to do auto-scaling, to automatically deploy more or shutdown VMs as needed. Elastic they call it. VMs are deployed in seperate per tenant/project networks. They also keep statistics on a per tenant basis.
Let's see I looked at the one patent filed in my country. Patent filed at 2001, granted in 2011, valid to 2021.
What I hate the most is these hidden patents which are first filed, but they delay it for as long as possible (so they also remain hidden) and 10 years (!) later they get granted and are valid an other 10 years.
VP7 is from 2005, VP6 is from 2003, VP5 is from 2002. All based on TrueMotion S created in 1995 or so.
1. one of the reasons OpenID failed is because people did not associate website/webpage with identity, BrowserID uses an email address, which is already very directly associated with an identity by many people
2. email addresses are already used on many, many websites, because of password recovery. Even with Facebook Connect/oAuth people will take the email address from the identity provider and record it (yes, it is already provided in most situations !).
3. with current free email providers, you can create as many identies as you like. So your privacy problems could be handled that way.
The biggest problem with all this is something else of course, within big companies people get assigned to different tasks all the time.
Sometimes that means that simple task but very important task gets handed over to some one else who doesn't fully understand the implications when it doesn't get done.
The technical bits of 1.1 are availaible in the NSS-library (the library created by Netscape at the time I believe and now developed by the people who develop Firefox).
The technical bits for 1.2 exists too, but I don't know if they still need more core, I believe they are under review.
The problem is really with all the webservers which still don't properly work with it.
Which forces a new TCP-connection with 1.0 (which means adding the 1.1 or 1.2 is probably useless if an active attacker can mess with your traffic and force fallback to an older protocol).
The IETF working group has not yet choosen the video-codec. VP8 is just what Firefox and Chrome are using to talk to each other. Even if VP8 is mandatory and H.264 was not. That does not mean that both parties talking to each other can't negotiate H.264 when they both support and prefer it.
Slashdot Mirror
It's code, code is programs people use. And the goal of RMS is for people to be able to have control over the programs they use.
HTTP/2.0 will be mostly based on SPDY. That is what the 'wait' is all about. There will be no SPDY RFC, there are just drafts.
Basically SPDY is the testing ground for HTTP/2.0.
HTTP/2.0 will most likely only use TLS.
I believe the comment you refered to from a Firefox developer was from one of the developers that helped solve the problems.
AKA it has already been solved.
Actually the CPU-performance of Javscript is about twice as slow as a C-program. So "only" 18 months behind according to moore's law.
The GPU-performance might be even better then twice because they use WebGL to tell the GPU what to do.
Their idea was Javascript without strong typing will never be as fast or close to C.
When WebGL was added to the browser, they added some strong types for storing all the graphics data.
So the developers at Mozilla figured out they can leverage those strong types when doing CPU-intense operations and optimize the Javascript engine to take advantage of that. Then they figured out you can use a compiler to target those strong types and recompile existing C-code that way.
So that is what is going on.
I'm sure they can supply you a list of some examples if you ask them nicely.
And so does btrfs.
Suggestion: collect a list of all the IP-addresses that send queries for a few months and then enable the ACL.
When the next DNS amplification DDoS attack comes in a few months you won't be part of it and you don't need to handle that traffic.
Maybe in your country, not mine.
An analogy of this law is: You will be punishable by law if you open a unlocked door when unauthorized.
Anyway, you could also take a look at the recent presentation from Mozilla:
http://pyvideo.org/video/1764/beyond-passwords-secure-authentication-with-mozi-0
Well, that is not completely true.
oVirt or vSphere (I've never used them myself, so I could be wrong) are usually centrally managed systems.
CloudStack or OpenStack are meant for building multi-tenant environments like Amazon, which means people get a tenant-account and an API. The API can be used to do auto-scaling, to automatically deploy more or shutdown VMs as needed. Elastic they call it. VMs are deployed in seperate per tenant/project networks. They also keep statistics on a per tenant basis.
Yep, nothing new, it's called a container, other implementations are FreeBSD jail, OpenVZ, Linux-Vserver or LXC.
Let's see I looked at the one patent filed in my country. Patent filed at 2001, granted in 2011, valid to 2021.
What I hate the most is these hidden patents which are first filed, but they delay it for as long as possible (so they also remain hidden) and 10 years (!) later they get granted and are valid an other 10 years.
VP7 is from 2005, VP6 is from 2003, VP5 is from 2002. All based on TrueMotion S created in 1995 or so.
I think this is their reasoning:
1. one of the reasons OpenID failed is because people did not associate website/webpage with identity, BrowserID uses an email address, which is already very directly associated with an identity by many people
2. email addresses are already used on many, many websites, because of password recovery. Even with Facebook Connect/oAuth people will take the email address from the identity provider and record it (yes, it is already provided in most situations !).
3. with current free email providers, you can create as many identies as you like. So your privacy problems could be handled that way.
I don't know if he is a shill, but can you tell me what you don't like about BrowserID, that could be a lot more interresting discussion.
Try using the SSL/TLS subsystem in Windows without sending information to Microsoft.
Let's not kid ourselfs, this is probably all about cheap nuclear power production:
http://www.nytimes.com/2009/11/10/business/energy-environment/10nukes.html?_r=0
So what do you call pulseaudio and systemd and everything else Lennart will come up with ?
Let's just say Lennart doesn't work for Canonical.
Yeah, we can see how well that worked this time.
The biggest problem with all this is something else of course, within big companies people get assigned to different tasks all the time.
Sometimes that means that simple task but very important task gets handed over to some one else who doesn't fully understand the implications when it doesn't get done.
Or whatever they are called, they have these large side pocket.
My prediction is they are going to be the next trend ;-)
And so Dijkstra still did it.
The technical bits of 1.1 are availaible in the NSS-library (the library created by Netscape at the time I believe and now developed by the people who develop Firefox).
The technical bits for 1.2 exists too, but I don't know if they still need more core, I believe they are under review.
The Firefox parts are almost there:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=733647&hide_resolved=1
The problem is really with all the webservers which still don't properly work with it.
Which forces a new TCP-connection with 1.0 (which means adding the 1.1 or 1.2 is probably useless if an active attacker can mess with your traffic and force fallback to an older protocol).
The merge for 3.8 isn't just over, it has already been released.
And still CORS headers work just fine in Firefox :-)
The IETF working group has not yet choosen the video-codec. VP8 is just what Firefox and Chrome are using to talk to each other. Even if VP8 is mandatory and H.264 was not. That does not mean that both parties talking to each other can't negotiate H.264 when they both support and prefer it.