Unless by "not behave differently" you mean "become horribly buggy and less functional", then sure.
YouTube's HTML5 player has made great strides, and it's been interesting watching the progress from "completely unusable" to merely "annoyingly buggy". But it's not ready as a full replacement quite yet.
The fact that, using Chrome, the last time I tried to view a youtube video in HTML5 (a few days ago) the pause button was unclickable, kind of underscored that point for me.
That's the idea. "post-webkit" would mean "after everybody moved to webkit". There are still exceptions, but it seems like pretty much everybody who needs a third party web rendering engine these days uses webkit, relegating Gecko to being used only in Mozilla products. As an example: pretty much all smartphones use webkit. Windows Phone is the exception, but it has virtually no marketshare at this point (which is too bad, it's nice to code for).
Google is already doing VoIP in the browser; see GMail's VoIP (still free calling to US&Canada) as an example. It's implemented as a one-off plugin.
Two-way audio and video seems a common enough use case that there will probably eventually be an HTML5 API for doing it. Probably not over WebSockets; that's TCP and is ill-suited for VoIP. WebSockets would need to be extended to support UDP.
Google's Swiffy (release notes: http://www.google.com/doubleclick/studio/swiffy/releasenotes.html) is the answer to that. I'm sure it's not the most efficient, and it's by no means complete (sound support is the big thing missing at this point, line thickness is still not right), but it's fast enough to, for example, watch a Homestar Runner cartoon at a normal level of performance. Of course, Homestar Runner isn't all that interesting without sound.
Except Flash is only bundled with Chrome (not Chromium), and they're getting rid of direct downloads of flash, potentially making it impossible to legally get it for Chromium.
This statement is what warranted the "mom's basement" comment, because it's laughable to have anyone who's brave enough to install Apache (through experience or as a newbie) who would have 512 MB of RAM (about what the IPhone 4 will have) and not the ubiquitous 2Gigs+. People have to question you after a statement like that, because it shows a basic failure to understand the consumer PC market, much less "the big iron" you compare it to.
Where did I ever say anything about the amount of RAM in the consumer PC market? 512MB is a typical size for many VPS providers, and for those who offer that size as their entry-level offering, it's normally their most popular service level by a huge margin because it's good enough for a significant amount of load if properly tweaked. Dedicated servers now tend to feature more RAM than this, but 10GB+ is rare; only a handful of SoftLayer's offerings come with that much RAM, and they're some of their most expensive packages. 2GB+ is pretty ubiquitous for dedicated servers these days (1GB is not uncommon), but that's not the case for the virtual hosting market, which tends to have far higher density.
I don't know why you're bringing smartphones into this; apparently you think a VPS provider runs their infrastructure on iPhones?
That's nice, if you're colocating. If you're buying a dedicated server, from, say, SoftLayer, going from 2GB to 24GB will cost you an extra $6600 per year.
If you're hosting with Linode, who are an excellent top-of-the-market VPS host, they'll charge you roughly the same.
If you could handle the same load with a tenth the RAM, then the cost of the 24GB boxes becomes wasteful.
No, I'm saying that handling 150 *concurrent* clients on Apache requires an excessive amount of RAM. Because mpm_worker will spawn 150 different processes to do that, and in reality, you rarely need to handle 150 concurrent sessions, even if you've got 1000 simultaneous users. Why? Well, if 1000 people are browsing a forum, they're not all constantly hitting the server, and even when a good number of them do, there's nothing to be gained from trying to serve too many of them at the same time; better to handle them sequentially.
Personally, I use Lighttpd with fastcgi. I switched from Apache to Lighttpd when nginx was still largely unknown, and while I've been impressed with nginx, I haven't seen any reason to switch, since it seems to accomplish many of the same things.
Win7 *requires* that to run, but that doesn't mean it will run well. Using modern websites and web apps on that sort of machine will be painful. Besides that, Windows counts on there being a certain amount of hardware acceleration for graphics, even if it's just GDI (2D) acceleration. But few smartphone GPUs have 2D components, so there's no accelerated 2D drawing. You end up basically drawing and compositing everything entirely in software, which puts a huge burden on your already underpowered CPU.
A few things are going to improve this going forward:
1) More apps are getting support for OpenGL ES, enabling 3D hardware acceleration. Ubuntu's desktop composition now supports this. 2) Newer mobile GPUs are starting to get 2D GPUs; the OMAP4470 and onwards has one, but the OMAP4430 and OMAP4460 don't. But the 4460 is the newest available at the moment; the 4470 hasn't shipped yet. 3) Mobile CPUs are getting faster fast, tackling this from the other end. The Cortex A15 is a huge improvement clock-for-clock over the A9, and will be clocked at higher speeds to boot.
On top of all of this, many desktop apps are designed with assumptions about the sort of resources they'll have available and run on, and not all of those assumptions are true when you're running on a low-power SoC. For example, RAM. I've got 6 tabs open in Chrome right now, and that's using 768MB of RAM. That's not a problem on my desktop, which as 12GB of RAM, but that kind of memory usage wouldn't fly on a smartphone platform with 512MB of 1024MB of RAM. There are things they could do to mitigate that (cache less things, keep less rendered bitmaps in RAM, etc). A desktop app will probably trade RAM for performance by a different standard than a smartphone app can afford to.
I expect Apache to ship with defaults appropriate for the typical user. In my case, I configured my way to a different web server half a decade ago, due to Apache's various shortcomings.
It's the right idea, but Ubuntu on ARM is nowhere near ready. It's crazy buggy, and you're going to miss out on hardware accelerated graphics for the vast majority of applications, because most apps still expect OpenGL, and can't take advantage of OpenGL ES.
The other problem is that devices like the Atrix, while an interesting concept, aren't really ready to host desktop Linux yet. The performance just isn't there yet. I suspect that the next crop of smartphones, with dual core A15s or quad-core A9s, those will probably do a decent job at it.
Disclaimer: my experience with playing around with this is limited to various versions of Ubuntu on a pandaboard, which is a TI OMAP dev board with similar specs to the Atrix.
Basically. I'm generalizing a lot, and a lot of this stuff matters much less if you've decoupled PHP (or similar) from your webserver and are running apache with something other than mpm_worker, where it takes one process per request, but that's the idea. There are workloads that legitimately do need massive concurrency.
The point isn't maximizing your Apache configuration to take advantage of available RAM, it's having extra RAM in the first place when it's not needed to handle the load. I've seen way too many people throw a server with 8GB of RAM at a workload that could have been handled easily by a server with a gig of RAM, and they're paying a heck of a lot more for that 8GB server. Of course, it makes the server host happy...
If you need 1500 concurrent users connected to a server to handle your traffic, and you don't have persistent connections for AJAX or large file downloads, I assume you're handling one or two billion pageviews per day?
The rules do change a bit when you start scaling horizontally and your bottlenecks aren't in the same place, but if you need to handle that many concurrent connections on a single server, you've probably got a nasty bottleneck somewhere else that's causing your requests to take way too long to service. Because if your bottleneck is on your application server, why are you taking 5 seconds to process 1500 requests when you take half a second to process 150, and get the same amount of work done in the same time with far less resources?
I wasn't aware that the world's largest server providers were "my mom's basement". If so, perhaps I should move back home, because that sounds like a fucking awesome basement.
For every enterprise customer like you with big iron, there are many more smaller servers. It's like the graphics card industry. Enthusiasts drive the high-end cards, but the vast majority of the market (and profit) is made off the average customer and their iGPU or other low-end part.
Yes, I do actually. Most Apache installations are going to be at dedicated and VPS server hosts, due to the sheer number of customers in that market, and they're typically going to have tens of thousands of servers with far far less than 10GB of RAM.
150 max clients is enormously too high for a LAMP stack, or serving static content (unless you're dealing mostly in very large files). Most cases where I see people running that sort of concurrency with enough RAM to back it up are caused by people misconfiguring their server and throwing more RAM at the problem. They see that they're running out of RAM because Apache is sucking it all up, so they throw more RAM and concurrency at the problem. Meanwhile, for dynamic load, you probably don't want more than 8 to 12 concurrent users on a quad-core server for a typical PHP web application, since beyond that and you're just throwing RAM at the problem without improving performance.
There are a handful of workloads that can justify that sort of concurrency, but they're few and far between. Web applications with persistent connections (which you're obviously not doing with that amount of RAM), or serving up large files for download, that sort of thing. The typical case of a LAMP stack almost never requires it, and enormous loads can be handled with levels of concurrency orders of magnitude smaller than what you've got.
People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.
I won't say that your workload doesn't justify that sort of concurrency, because I don't know what your workload is, but 150 is not a reasonable default for the vast majority of applications. Certainly not for most LAMP installations, where 512MB of RAM is typical, and more than a gig or two is rare.
Unless I'm way off the mark, the vast majority of Apache out there (particularly in the environments I mentioned earlier) are running some sort of dynamic module like mod_php.
Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.
Slashdot Mirror
And since PPAPI is an open API with a BSD-licensed reference implementation, whose fault is that?
Chrome is the only browser to support PPAPI because Mozilla doesn't want to implement it, not because Google is preventing them from doing so.
Unless by "not behave differently" you mean "become horribly buggy and less functional", then sure.
YouTube's HTML5 player has made great strides, and it's been interesting watching the progress from "completely unusable" to merely "annoyingly buggy". But it's not ready as a full replacement quite yet.
The fact that, using Chrome, the last time I tried to view a youtube video in HTML5 (a few days ago) the pause button was unclickable, kind of underscored that point for me.
That's the idea. "post-webkit" would mean "after everybody moved to webkit". There are still exceptions, but it seems like pretty much everybody who needs a third party web rendering engine these days uses webkit, relegating Gecko to being used only in Mozilla products. As an example: pretty much all smartphones use webkit. Windows Phone is the exception, but it has virtually no marketshare at this point (which is too bad, it's nice to code for).
Google is already doing VoIP in the browser; see GMail's VoIP (still free calling to US&Canada) as an example. It's implemented as a one-off plugin.
Two-way audio and video seems a common enough use case that there will probably eventually be an HTML5 API for doing it. Probably not over WebSockets; that's TCP and is ill-suited for VoIP. WebSockets would need to be extended to support UDP.
Google's Swiffy (release notes: http://www.google.com/doubleclick/studio/swiffy/releasenotes.html) is the answer to that. I'm sure it's not the most efficient, and it's by no means complete (sound support is the big thing missing at this point, line thickness is still not right), but it's fast enough to, for example, watch a Homestar Runner cartoon at a normal level of performance. Of course, Homestar Runner isn't all that interesting without sound.
Except Flash is only bundled with Chrome (not Chromium), and they're getting rid of direct downloads of flash, potentially making it impossible to legally get it for Chromium.
This statement is what warranted the "mom's basement" comment, because it's laughable to have anyone who's brave enough to install Apache (through experience or as a newbie) who would have 512 MB of RAM (about what the IPhone 4 will have) and not the ubiquitous 2Gigs+. People have to question you after a statement like that, because it shows a basic failure to understand the consumer PC market, much less "the big iron" you compare it to.
Where did I ever say anything about the amount of RAM in the consumer PC market? 512MB is a typical size for many VPS providers, and for those who offer that size as their entry-level offering, it's normally their most popular service level by a huge margin because it's good enough for a significant amount of load if properly tweaked. Dedicated servers now tend to feature more RAM than this, but 10GB+ is rare; only a handful of SoftLayer's offerings come with that much RAM, and they're some of their most expensive packages. 2GB+ is pretty ubiquitous for dedicated servers these days (1GB is not uncommon), but that's not the case for the virtual hosting market, which tends to have far higher density.
I don't know why you're bringing smartphones into this; apparently you think a VPS provider runs their infrastructure on iPhones?
What you find in a desktop computer or laptop is not the same as what you find in a mass-market dedicated server or VPS.
That's nice, if you're colocating. If you're buying a dedicated server, from, say, SoftLayer, going from 2GB to 24GB will cost you an extra $6600 per year.
If you're hosting with Linode, who are an excellent top-of-the-market VPS host, they'll charge you roughly the same.
If you could handle the same load with a tenth the RAM, then the cost of the 24GB boxes becomes wasteful.
No, I'm saying that handling 150 *concurrent* clients on Apache requires an excessive amount of RAM. Because mpm_worker will spawn 150 different processes to do that, and in reality, you rarely need to handle 150 concurrent sessions, even if you've got 1000 simultaneous users. Why? Well, if 1000 people are browsing a forum, they're not all constantly hitting the server, and even when a good number of them do, there's nothing to be gained from trying to serve too many of them at the same time; better to handle them sequentially.
Personally, I use Lighttpd with fastcgi. I switched from Apache to Lighttpd when nginx was still largely unknown, and while I've been impressed with nginx, I haven't seen any reason to switch, since it seems to accomplish many of the same things.
Win7 *requires* that to run, but that doesn't mean it will run well. Using modern websites and web apps on that sort of machine will be painful. Besides that, Windows counts on there being a certain amount of hardware acceleration for graphics, even if it's just GDI (2D) acceleration. But few smartphone GPUs have 2D components, so there's no accelerated 2D drawing. You end up basically drawing and compositing everything entirely in software, which puts a huge burden on your already underpowered CPU.
A few things are going to improve this going forward:
1) More apps are getting support for OpenGL ES, enabling 3D hardware acceleration. Ubuntu's desktop composition now supports this.
2) Newer mobile GPUs are starting to get 2D GPUs; the OMAP4470 and onwards has one, but the OMAP4430 and OMAP4460 don't. But the 4460 is the newest available at the moment; the 4470 hasn't shipped yet.
3) Mobile CPUs are getting faster fast, tackling this from the other end. The Cortex A15 is a huge improvement clock-for-clock over the A9, and will be clocked at higher speeds to boot.
On top of all of this, many desktop apps are designed with assumptions about the sort of resources they'll have available and run on, and not all of those assumptions are true when you're running on a low-power SoC. For example, RAM. I've got 6 tabs open in Chrome right now, and that's using 768MB of RAM. That's not a problem on my desktop, which as 12GB of RAM, but that kind of memory usage wouldn't fly on a smartphone platform with 512MB of 1024MB of RAM. There are things they could do to mitigate that (cache less things, keep less rendered bitmaps in RAM, etc). A desktop app will probably trade RAM for performance by a different standard than a smartphone app can afford to.
I expect Apache to ship with defaults appropriate for the typical user. In my case, I configured my way to a different web server half a decade ago, due to Apache's various shortcomings.
It's the right idea, but Ubuntu on ARM is nowhere near ready. It's crazy buggy, and you're going to miss out on hardware accelerated graphics for the vast majority of applications, because most apps still expect OpenGL, and can't take advantage of OpenGL ES.
The other problem is that devices like the Atrix, while an interesting concept, aren't really ready to host desktop Linux yet. The performance just isn't there yet. I suspect that the next crop of smartphones, with dual core A15s or quad-core A9s, those will probably do a decent job at it.
Disclaimer: my experience with playing around with this is limited to various versions of Ubuntu on a pandaboard, which is a TI OMAP dev board with similar specs to the Atrix.
Basically. I'm generalizing a lot, and a lot of this stuff matters much less if you've decoupled PHP (or similar) from your webserver and are running apache with something other than mpm_worker, where it takes one process per request, but that's the idea. There are workloads that legitimately do need massive concurrency.
The point isn't maximizing your Apache configuration to take advantage of available RAM, it's having extra RAM in the first place when it's not needed to handle the load. I've seen way too many people throw a server with 8GB of RAM at a workload that could have been handled easily by a server with a gig of RAM, and they're paying a heck of a lot more for that 8GB server. Of course, it makes the server host happy...
Actually, you might argue also that it's the distro's fault, since they typically determine the defaults deployed applications will use.
If you need 1500 concurrent users connected to a server to handle your traffic, and you don't have persistent connections for AJAX or large file downloads, I assume you're handling one or two billion pageviews per day?
The rules do change a bit when you start scaling horizontally and your bottlenecks aren't in the same place, but if you need to handle that many concurrent connections on a single server, you've probably got a nasty bottleneck somewhere else that's causing your requests to take way too long to service. Because if your bottleneck is on your application server, why are you taking 5 seconds to process 1500 requests when you take half a second to process 150, and get the same amount of work done in the same time with far less resources?
That's not entirely uncommon, no.
It could; server admins might not like it, but "reduce maxclients" sounds like a better failure scenario to me than "trigger kernel OOM killer"
My point is that those "bunch of tiny servers" vastly outnumber the "real enterprise applications".
I wasn't aware that the world's largest server providers were "my mom's basement". If so, perhaps I should move back home, because that sounds like a fucking awesome basement.
For every enterprise customer like you with big iron, there are many more smaller servers. It's like the graphics card industry. Enthusiasts drive the high-end cards, but the vast majority of the market (and profit) is made off the average customer and their iGPU or other low-end part.
It's their responsibility because it's a (the?) typical deployment scenario for their software.
Yes, I do actually. Most Apache installations are going to be at dedicated and VPS server hosts, due to the sheer number of customers in that market, and they're typically going to have tens of thousands of servers with far far less than 10GB of RAM.
150 max clients is enormously too high for a LAMP stack, or serving static content (unless you're dealing mostly in very large files). Most cases where I see people running that sort of concurrency with enough RAM to back it up are caused by people misconfiguring their server and throwing more RAM at the problem. They see that they're running out of RAM because Apache is sucking it all up, so they throw more RAM and concurrency at the problem. Meanwhile, for dynamic load, you probably don't want more than 8 to 12 concurrent users on a quad-core server for a typical PHP web application, since beyond that and you're just throwing RAM at the problem without improving performance.
There are a handful of workloads that can justify that sort of concurrency, but they're few and far between. Web applications with persistent connections (which you're obviously not doing with that amount of RAM), or serving up large files for download, that sort of thing. The typical case of a LAMP stack almost never requires it, and enormous loads can be handled with levels of concurrency orders of magnitude smaller than what you've got.
People normally thing they want to handle tons of people at the same time, but handling 10x more client requests simultaneously typically means each one takes 10x longer to process; there's no performance advantage, and all you've managed to do is burn RAM.
I won't say that your workload doesn't justify that sort of concurrency, because I don't know what your workload is, but 150 is not a reasonable default for the vast majority of applications. Certainly not for most LAMP installations, where 512MB of RAM is typical, and more than a gig or two is rare.
Unless I'm way off the mark, the vast majority of Apache out there (particularly in the environments I mentioned earlier) are running some sort of dynamic module like mod_php.
Does this release fix one of Apache's biggest problems, that the default Apache config file assumes that you've got 10 gigabytes of RAM in your server? Stuff like setting maxclients to a default of 150 has got to be the single biggest cause of Apache servers blowing up at dedicated and virtual private server hosts.