You could also use Silverlight to pitch theora video, since the upcoming moonlight 2.0 release allows dynamic codecs within the CLR (as does silverlight). Then you'd be writing in fully open source format that works in most usage scenarios while avoiding any proprietary tools.
Even Opera now has silverlight support. Someone tell me you could get theora video to more users in any other fashion...
Oh yes, and unlike the video tag, it completely works in all three platforms.
But then again, theora still uses too much bandwidth for its quality.
A technical demo on the most popular video site on the internet. A website that is using so much bandwidth it's losing ~$1 billion/year. Why wouldn't they want to switch to a higher-quality-per-kb option?
Can you recommend one? I thought they were using h.264 already...
I don't think they're going to want to re-encode everything to a weaker format that uses more bandwidth, they're bleeding enough money as is. They'll likely only do that if it will play existing h.264 files they have lying around.
Haha, oh my god. You are so clever! You're right, because I don't like the idea of having a giant apt cache on my cellphone, I must be the CEO of Microsoft!
I see why slashdotters are renowned for their wit!
I hope they included pulseaudio, too, because there wasn't enough retarded linux desktop crap on mobile phones.
The most intelligent linux platforms fit for mobile have been Android and Creative's Plaszma so far... this is just retarded overkill. Is it just built for sysadmins and freetards or something? How big can that market possibly be?
It's very important to point out that the porting task has everything to do with where you start. The PC is simply not the best development environment anymore, the Xbox 360 is-- and even Carmack would agree with me, here. You can get a game going really fast on 360, then it's a bit less difficult to go to PC. We can call this the best case scenario. Rapid time to market with superior development tools on 360 with familiar API's for cross-platform development on PC, along with similar TCR requirements between GFW and 360.
Let's say you started on the PS3, though. Maybe you took the time to learn the architecture and really take advantage of the cell architecture, so your game is basically hardcoded around the flexible pipeline and mass pararllelization, now it does things that even PC games cannot. Porting it to the 360 might not be so bad, but going to the PC is going to be a rough letdown. It feels like a dog when porting a console game.
So maybe your game started out nicely organized and clean in design, but in that last few months before release while your publisher is driving you up a wall to release, you're going to have so many hacks and messy revisions to the model to ship within your ridiculous timeframe- plus all the devs are tired and need vacations and such. Suddenly, the game is not so portable. It's the same for any platform, really- you go balls to the wall optimizing our game for the platform and you're going to spend a lot of your smooth portability.
Pay no attention to the "specs" of consoles vs. PC, it's basically meaningless. Consoles often run games almost directly, plus they have all sorts of architecture enhancements and little hardware tricks you don't find in PC's. A PC needs to have brutally more power to really match the sort of speed and power you can squeeze out of a console.
Let's say you developed on nintendo wii first... well, it's game over already, you just developed a last-gen, almost Xbox-looking game and tied it to the wiimote. Good luck porting that. That's part of why American studios don't throw big games at it, because it's too limited in power and the publishers just don't want to risk it. There are too many "hardcore" games, which need to push the envelope. The Wii is basically doomed to casual games and childrens' games because of this, because the marketing figures will always point it in that direction--and that's what really runs the game industry.
Technically speaking, you can probably see why people like the Unreal Engine or Source Engine, given the fact that all the porting work is done for you... well you still have to deal with the insane, i mean ABSOLUTELY insane requirements each console has for release... everything from trademarks to menu formats to the way control is expressed in the interface. The amount of attention to detail necessary blows away months of work. Consoles are not a free-for-all, you have to use the hardware in a very specified way.
In short.. yeah, it's rough. More difficult than most people will ever really know.
I'm sorry, but I don't know how it is where you're at, but in all the jobs I've worked, the senior engineers and programmers didn't bother with it off the clock. It's only the young fresh out of college kids who feel like working instead of spending the evening with their family. The young guys are cheaper, but they're certainly not more useful than experienced senior engineers.
Actually, the article and subsequent post had more to do with "more" amateurs using Ruby and Python, not "all" or "none". These languages are not popular in the enterprise, perhaps because they're generally low performance trendy languages with questionable professional application. But they are trendy, so I'm sure plenty of amateurs and webtrash make use of them.
People who party all weekend are more likely to have questions about Java. Better, more dedicated devlopers more likely to have an interest in Python.
Better, more dedicated? You mean developers without lives, right? Some people have families and friends and such, and that doesn't make them any worse at programming. Often they are better.
Perhaps this only indicates that Java and C# are used more by professionals and Python and Ruby are used more by amateurs. No matter where they work (whether or not they're using Java or C# or even programming at work), it merely indicates that people who use Python and Ruby are active during the weekend.
Perhaps this simply means that Python and Ruby are more popular with amateur F/OSS and web developers, something that is so obvious it doesn't even necessitate an article.
Geez, I hope nobody invents selinux and makes it a 15-second installation process on major distros. Oh wait.
Ha... oh dear. You really think you're little Mandatory Access Control profile is going to protect you from an suid-based attack by something like ALSA or your wonky networking layer? It's just security retrofitting, it won't protect you from your own shoddily written kernel.
I'm still pretty happy with using linux. I have one laptop I boot to windows maybe once a month for skype. Otherwise my 11 boxes and laptops all run linux or solaris. I've never been p0rn'ed yet. So yeah, I feel pretty good still. My friends who run windows would only dream of my level of reliability and they have no web server or email server facing the internet. Enjoy your one day. I've enjoyed my 28 years of *NIX.
What is this, an informercial? After 28 years, I can just write you off as certifiably insane and suffering from UNIX Stockholm Syndrome, aka Helsinki Syndrome.
You clearly don't understand what is meant by quick. Quick is the time it takes to patch the bug from the point it's determined that it exists.
How do you know when Microsoft plugs a bug in the Windows platform? Do you keep track of their internal repository? What matters is when the patch gets to the users of the system, not some bleeding edge repository. It's still not in the hands of Linux users. If it gets there in less of the time than Microsoft can push a patch out for their platform, then it's faster. It being in the bleeding edge repository is meaningless.
The development model in Linux is better mostly due to the level of documentation that goes into public code.
Are you saying the Linux platform is more well documented than Windows? Are you high? When I think about the disparity between platforms, documentation is a serious high point for Windows. In Linux, your documentation is the source code. You read the source code if you want to understand the functionality of a certain driver or API.
What is being illustrated is how bugs are found and resolved in a timely manner in Linux.
An 8 year old bug is located and then Linus patches the mainline kernel in the repository. How is this faster? Is this patch in Ubuntu yet? How about Red Hat? Is it in the Linux servers on Wall Street yet? When Microsoft finds an exploit, this happens fairly quickly, but then the code goes through a serious review and QA process before being pushed to the entire platform worldwide. Does it really get to the customer quicker this way? Is it really safer? The difference here is that we know when the kernel architect has finished his patch... but seeing what happened here, I won't be shocked if another one of these appears in another few months. This was a pretty amateur hole.
For example simple things like adding a firewall didn't occur to them until years after Linux distributors had made it apart of most if not all installs.
Firewalls were third party turf. I think the idea was that firewalls are a network infrastructure issue, not an OS thing. They added a firewall, though. It's a bit easier to deal with than Linux's, also.
It was fixed much faster than MS after it was announced. I guess it is 100000 times faster than your usual MS flaw. So, yeah Linux is more secure.
So Linus commits a patch to the bleeding edge repository and it's "Fixed"? Do you really think that fixes to Windows only appear when the patch comes about? No, after the patch has been implemented internally and verified by the security teams and run through QA it is rolled into a safe patch and spread out to ALL windows machines. I'd say that's much faster and less complex than the rounds this patch needs to make as it slips out to the distros and is backported into the various kernels-- and with far less testing and QA. You ride by the seat of your pants with Linux.
Also, did you bother reading what this exploit does? It is very bad because it allows user programs to gain administrator privileges. This is insecure because it puts Linux in a category that's as insecure as all pre-vista windows computers and also the UAC-enabled-because-else-it-is-useless vista and 7 computers. That's the problem here, it moves Linux to a windows state...
Limited accounts are a Windows NT feature. Are you talking about DOS-based Windows? And Linux doesn't offer the sort of security UAC does. You can't casually SUID 0 past UAC with limited access.
Finally, it is easier to find flaws in Linux, this increases the chances blackhats found bugs, but it also increases the chances someone else will find it in paralel, preventing your hypothetical situation...
Haha... you really think white hats without a profit motive are going to get to the good stuff first? Exploits are expensive, man. You simply assume that the white hats are as skilled as the black hats, which is economically improbable. Well, obviously after 8 years of wide open system, they're just not that impressive. The most prevailing force in any software project is laziness, so if security and quality are not checked and double checked in an enforced manner by those with incentive to do so, it likely won't happen. Serious security professionals are high paid fellows who can't be babysitting every code commit in the tangled mess that is the linux kernel. There's just way too much ground to cover. The NT kernel is tiny in comparison.
Ironically, it is because of some artificial obscurity that this bug was present and took so long to find. Most vulnerabilities aren't caused by obscure optimization issues, and are findable in source code, those were a non-issue thanks to the lack of obscurity. So this actually proves obscurity != security.
No, it doesn't. It proves that security is a careful process and that writing and maintaining advanced systems code should be left in the hands of professionals. Security v. obscurity is not the issue here. This was an amateur oversight.
Sorry bitches, today is Windows Day and I am wearing my NT kernel proud. I'm going to go boot up my Windows 7 box and just cackle madly for a while.
It already worked so well for us to ban them from committing a sexual offense in the first place, they'll be unable to chew through our iron red tape in order to offend again.
What if we also ban them from shopping malls and public places? Bars? Really, anywhere where people might be able to meet other people would be good. It's for the greater good.
You mean something like this? [google.com] I'm betting that the reason they created it was at least partially motivated by the need for it in Chrome OS.
It's nice, but is it really of the same scope as DirectX or Core* in Mac? I mean, this is just a 3d api for the web. Let's be fair.
Google observes that Windows is too complicated, slow and bloated. But another big bloated monolithic solution such as the Linux kernel doesn't seem an answer. Why don't they go with a microkernel architecture based on something such as Minix 3? We've known for years the potential advantages of microkernels: smaller, simpler, more robust.
You've just got yourself tied up here already. NT is probably the most popular microkernel architecture in the world. What makes it "hybrid" is pretty minimal... it's a lean mean high-performance microkernel. A lot of what still made it hybrid has gone away in NT 6.
I don't think Chrome OS has a shot in hell in outperforming Windows 7 or Mac OS X at any media application aside from the Chrome Browser itself. Google simply lacks the organization and expertise to create something like DirectX or CoreVideo, or any of the advanced mature media frameworks available in the big name desktops. If they really had that capability, it would have started peaking out in Android, which lacks all sorts of hardware acceleration features that Win CE and iPhone OS offered. It's very web-ish.
Let's be clear: we're talking about an in-development environment that will essentially be a web browser running on a framebuffer on a linux kernel with a lean non-gnu stack. It's not a general purpose OS. It's going to grab a small chunk of the super-casual market such as netbooks, probably defeat any desktop linux in existence by an order of magnitude, then fall flat on its face in front of anyone who needs to get serious work done or produce attractive documents or edit media, from housewives to students to professionals. What we're looking at isn't a juggernaut but a curiosity. I anticipate it's going to kick ass for people who only use their web browser, though. It'll really simplify things for them and offer them an extremely fast boot-to-web experience. I think it will succeed in what it's trying to accomplish, but it's just far too small in scope.
And even the potential for formal verification to prove that it really is bug free, something that Windows and Linux are far too large to ever accomplish.
What sort of verification would you be talking about? We're talking about a desktop environment built out of WebKit, so I think their potential security will be lower than what Windows offers... I think they're banking on the fact that they likely won't offer a native execution environment outside of Native Client. Of course, this is assuming Native Client isn't just a modern ActiveX waiting to be exploited upon deployment.
The main disadvantage I've heard is a perception that a microkernel architecture by necessity imposes a performance penalty. The ability to survive buggy driver code has a flip side in the supposed overhead required to jump in and out of user space whenever the microkernel calls on these drivers.
There are modern pure microkernels out there which perform blazingly fast... Green Hills INTEGRITY is an example. They've gotten around a lot of these little problems in a brilliant way. The open source community is trapped within debates from the early 80's, it's really big world outside of UNIX. Microkernels beat Monoliths on every front aside from brute simplicity. Monoliths can be "elegant," but linux is anything but. Compared to the gnu/linux ecosystem, Windows is extremely well organized and clearly architected.
Google is not looking to innovate in the operating system market, clearly. They're simply doing what so many desktop linux distributions failed at when trying to make a casual OS. They're using Linux because it'll save them time writing difficult boot and driver code and ultimately save them money. They're not writing their own kernel because they're not really going to compete with Windows. I don't think Google really has what it takes to create a serious new kernel, anyway-- or even clean up Minix enough that it performs competitively.
Linux is not Unix. It's a close approximation. For one, the base APIs are not fully POSIX compliant. Right there is a big hurdle to being Unix. If someone were to pony up the cash for certification (RedHat, Novell, Cannonical), there are issues yet to be fixed before it can be called UNIX, so it's not just a question of certifying it.
A weird thing has happened though, hasn't it? They've built linux up as its own fairly strong brand.. but I think the community does lack the attention to detail to make this jump, anyway. The linux kernel is pretty *messy* compared to even BSD. I think this small shift in functionality is probably harder to attain than they let on. At its very best, Linux is an almost-Unix.
If anyone really does need a full compliant UNIX, opensolaris is quite free.
It seems the great linux menace has finally moved out of your imaginations and into the real world. Now, over a decade after its inception, linux has become loosely competitive with Windows in the client market. Pat yourselves on the back. You've done what Microsoft did for a couple hundred thousand dollars in the 80's with a mere $1.2 billion.
Slashdot Mirror
You could also use Silverlight to pitch theora video, since the upcoming moonlight 2.0 release allows dynamic codecs within the CLR (as does silverlight). Then you'd be writing in fully open source format that works in most usage scenarios while avoiding any proprietary tools.
Even Opera now has silverlight support. Someone tell me you could get theora video to more users in any other fashion...
Oh yes, and unlike the video tag, it completely works in all three platforms.
But then again, theora still uses too much bandwidth for its quality.
It is my understanding that they transcode to FLV, but still have the h264 availiable.
Isn't FLV a container format? It's not a codec. The videos should all be in h.264 or h.263.
A technical demo on the most popular video site on the internet. A website that is using so much bandwidth it's losing ~$1 billion/year. Why wouldn't they want to switch to a higher-quality-per-kb option?
Can you recommend one? I thought they were using h.264 already...
I don't think they're going to want to re-encode everything to a weaker format that uses more bandwidth, they're bleeding enough money as is. They'll likely only do that if it will play existing h.264 files they have lying around.
Here you go [youtube.com].
A technical demo? Come on. If this is all it takes to be "catching on," then I would say JavaFX is the future.
But what's the advantage as a content provider for me to re-encode everything so it only works in Firefox and Chrome?
I don't think there's any evidence that the video tag is catching on in any meaningful way. Can anyone point me to evidence of the contrary?
Who is to say that Flash's grasp is even weakening among major content providers? Is the video tag DRM friendly?
Haha, oh my god. You are so clever! You're right, because I don't like the idea of having a giant apt cache on my cellphone, I must be the CEO of Microsoft!
I see why slashdotters are renowned for their wit!
I hope they included pulseaudio, too, because there wasn't enough retarded linux desktop crap on mobile phones.
The most intelligent linux platforms fit for mobile have been Android and Creative's Plaszma so far... this is just retarded overkill. Is it just built for sysadmins and freetards or something? How big can that market possibly be?
It's very important to point out that the porting task has everything to do with where you start. The PC is simply not the best development environment anymore, the Xbox 360 is-- and even Carmack would agree with me, here. You can get a game going really fast on 360, then it's a bit less difficult to go to PC. We can call this the best case scenario. Rapid time to market with superior development tools on 360 with familiar API's for cross-platform development on PC, along with similar TCR requirements between GFW and 360.
Let's say you started on the PS3, though. Maybe you took the time to learn the architecture and really take advantage of the cell architecture, so your game is basically hardcoded around the flexible pipeline and mass pararllelization, now it does things that even PC games cannot. Porting it to the 360 might not be so bad, but going to the PC is going to be a rough letdown. It feels like a dog when porting a console game.
So maybe your game started out nicely organized and clean in design, but in that last few months before release while your publisher is driving you up a wall to release, you're going to have so many hacks and messy revisions to the model to ship within your ridiculous timeframe- plus all the devs are tired and need vacations and such. Suddenly, the game is not so portable. It's the same for any platform, really- you go balls to the wall optimizing our game for the platform and you're going to spend a lot of your smooth portability.
Pay no attention to the "specs" of consoles vs. PC, it's basically meaningless. Consoles often run games almost directly, plus they have all sorts of architecture enhancements and little hardware tricks you don't find in PC's. A PC needs to have brutally more power to really match the sort of speed and power you can squeeze out of a console.
Let's say you developed on nintendo wii first... well, it's game over already, you just developed a last-gen, almost Xbox-looking game and tied it to the wiimote. Good luck porting that. That's part of why American studios don't throw big games at it, because it's too limited in power and the publishers just don't want to risk it. There are too many "hardcore" games, which need to push the envelope. The Wii is basically doomed to casual games and childrens' games because of this, because the marketing figures will always point it in that direction--and that's what really runs the game industry.
Technically speaking, you can probably see why people like the Unreal Engine or Source Engine, given the fact that all the porting work is done for you... well you still have to deal with the insane, i mean ABSOLUTELY insane requirements each console has for release... everything from trademarks to menu formats to the way control is expressed in the interface. The amount of attention to detail necessary blows away months of work. Consoles are not a free-for-all, you have to use the hardware in a very specified way.
In short.. yeah, it's rough. More difficult than most people will ever really know.
I'm sorry, but I don't know how it is where you're at, but in all the jobs I've worked, the senior engineers and programmers didn't bother with it off the clock. It's only the young fresh out of college kids who feel like working instead of spending the evening with their family. The young guys are cheaper, but they're certainly not more useful than experienced senior engineers.
Actually, the article and subsequent post had more to do with "more" amateurs using Ruby and Python, not "all" or "none". These languages are not popular in the enterprise, perhaps because they're generally low performance trendy languages with questionable professional application. But they are trendy, so I'm sure plenty of amateurs and webtrash make use of them.
That was almost poetic. :)
People who party all weekend are more likely to have questions about Java. Better, more dedicated devlopers more likely to have an interest in Python.
Better, more dedicated? You mean developers without lives, right? Some people have families and friends and such, and that doesn't make them any worse at programming. Often they are better.
Perhaps this only indicates that Java and C# are used more by professionals and Python and Ruby are used more by amateurs. No matter where they work (whether or not they're using Java or C# or even programming at work), it merely indicates that people who use Python and Ruby are active during the weekend.
Perhaps this simply means that Python and Ruby are more popular with amateur F/OSS and web developers, something that is so obvious it doesn't even necessitate an article.
Geez, I hope nobody invents selinux and makes it a 15-second installation process on major distros. Oh wait.
Ha... oh dear. You really think you're little Mandatory Access Control profile is going to protect you from an suid-based attack by something like ALSA or your wonky networking layer? It's just security retrofitting, it won't protect you from your own shoddily written kernel.
I'm still pretty happy with using linux. I have one laptop I boot to windows maybe once a month for skype. Otherwise my 11 boxes and laptops all run linux or solaris. I've never been p0rn'ed yet. So yeah, I feel pretty good still. My friends who run windows would only dream of my level of reliability and they have no web server or email server facing the internet. Enjoy your one day. I've enjoyed my 28 years of *NIX.
What is this, an informercial? After 28 years, I can just write you off as certifiably insane and suffering from UNIX Stockholm Syndrome, aka Helsinki Syndrome.
You clearly don't understand what is meant by quick. Quick is the time it takes to patch the bug from the point it's determined that it exists.
How do you know when Microsoft plugs a bug in the Windows platform? Do you keep track of their internal repository? What matters is when the patch gets to the users of the system, not some bleeding edge repository. It's still not in the hands of Linux users. If it gets there in less of the time than Microsoft can push a patch out for their platform, then it's faster. It being in the bleeding edge repository is meaningless.
The development model in Linux is better mostly due to the level of documentation that goes into public code.
Are you saying the Linux platform is more well documented than Windows? Are you high? When I think about the disparity between platforms, documentation is a serious high point for Windows. In Linux, your documentation is the source code. You read the source code if you want to understand the functionality of a certain driver or API.
What is being illustrated is how bugs are found and resolved in a timely manner in Linux.
An 8 year old bug is located and then Linus patches the mainline kernel in the repository. How is this faster? Is this patch in Ubuntu yet? How about Red Hat? Is it in the Linux servers on Wall Street yet? When Microsoft finds an exploit, this happens fairly quickly, but then the code goes through a serious review and QA process before being pushed to the entire platform worldwide. Does it really get to the customer quicker this way? Is it really safer? The difference here is that we know when the kernel architect has finished his patch... but seeing what happened here, I won't be shocked if another one of these appears in another few months. This was a pretty amateur hole.
For example simple things like adding a firewall didn't occur to them until years after Linux distributors had made it apart of most if not all installs.
Firewalls were third party turf. I think the idea was that firewalls are a network infrastructure issue, not an OS thing. They added a firewall, though. It's a bit easier to deal with than Linux's, also.
It was fixed much faster than MS after it was announced. I guess it is 100000 times faster than your usual MS flaw. So, yeah Linux is more secure.
So Linus commits a patch to the bleeding edge repository and it's "Fixed"? Do you really think that fixes to Windows only appear when the patch comes about? No, after the patch has been implemented internally and verified by the security teams and run through QA it is rolled into a safe patch and spread out to ALL windows machines. I'd say that's much faster and less complex than the rounds this patch needs to make as it slips out to the distros and is backported into the various kernels-- and with far less testing and QA. You ride by the seat of your pants with Linux.
Also, did you bother reading what this exploit does? It is very bad because it allows user programs to gain administrator privileges. This is insecure because it puts Linux in a category that's as insecure as all pre-vista windows computers and also the UAC-enabled-because-else-it-is-useless vista and 7 computers. That's the problem here, it moves Linux to a windows state...
Limited accounts are a Windows NT feature. Are you talking about DOS-based Windows? And Linux doesn't offer the sort of security UAC does. You can't casually SUID 0 past UAC with limited access.
Finally, it is easier to find flaws in Linux, this increases the chances blackhats found bugs, but it also increases the chances someone else will find it in paralel, preventing your hypothetical situation...
Haha... you really think white hats without a profit motive are going to get to the good stuff first? Exploits are expensive, man. You simply assume that the white hats are as skilled as the black hats, which is economically improbable. Well, obviously after 8 years of wide open system, they're just not that impressive. The most prevailing force in any software project is laziness, so if security and quality are not checked and double checked in an enforced manner by those with incentive to do so, it likely won't happen. Serious security professionals are high paid fellows who can't be babysitting every code commit in the tangled mess that is the linux kernel. There's just way too much ground to cover. The NT kernel is tiny in comparison.
Ironically, it is because of some artificial obscurity that this bug was present and took so long to find. Most vulnerabilities aren't caused by obscure optimization issues, and are findable in source code, those were a non-issue thanks to the lack of obscurity. So this actually proves obscurity != security.
No, it doesn't. It proves that security is a careful process and that writing and maintaining advanced systems code should be left in the hands of professionals. Security v. obscurity is not the issue here. This was an amateur oversight.
Sorry bitches, today is Windows Day and I am wearing my NT kernel proud. I'm going to go boot up my Windows 7 box and just cackle madly for a while.
It already worked so well for us to ban them from committing a sexual offense in the first place, they'll be unable to chew through our iron red tape in order to offend again.
What if we also ban them from shopping malls and public places? Bars? Really, anywhere where people might be able to meet other people would be good. It's for the greater good.
You mean something like this? [google.com] I'm betting that the reason they created it was at least partially motivated by the need for it in Chrome OS.
It's nice, but is it really of the same scope as DirectX or Core* in Mac? I mean, this is just a 3d api for the web. Let's be fair.
Google observes that Windows is too complicated, slow and bloated. But another big bloated monolithic solution such as the Linux kernel doesn't seem an answer. Why don't they go with a microkernel architecture based on something such as Minix 3? We've known for years the potential advantages of microkernels: smaller, simpler, more robust.
You've just got yourself tied up here already. NT is probably the most popular microkernel architecture in the world. What makes it "hybrid" is pretty minimal... it's a lean mean high-performance microkernel. A lot of what still made it hybrid has gone away in NT 6.
I don't think Chrome OS has a shot in hell in outperforming Windows 7 or Mac OS X at any media application aside from the Chrome Browser itself. Google simply lacks the organization and expertise to create something like DirectX or CoreVideo, or any of the advanced mature media frameworks available in the big name desktops. If they really had that capability, it would have started peaking out in Android, which lacks all sorts of hardware acceleration features that Win CE and iPhone OS offered. It's very web-ish.
Let's be clear: we're talking about an in-development environment that will essentially be a web browser running on a framebuffer on a linux kernel with a lean non-gnu stack. It's not a general purpose OS. It's going to grab a small chunk of the super-casual market such as netbooks, probably defeat any desktop linux in existence by an order of magnitude, then fall flat on its face in front of anyone who needs to get serious work done or produce attractive documents or edit media, from housewives to students to professionals.
What we're looking at isn't a juggernaut but a curiosity. I anticipate it's going to kick ass for people who only use their web browser, though. It'll really simplify things for them and offer them an extremely fast boot-to-web experience. I think it will succeed in what it's trying to accomplish, but it's just far too small in scope.
And even the potential for formal verification to prove that it really is bug free, something that Windows and Linux are far too large to ever accomplish.
What sort of verification would you be talking about? We're talking about a desktop environment built out of WebKit, so I think their potential security will be lower than what Windows offers... I think they're banking on the fact that they likely won't offer a native execution environment outside of Native Client. Of course, this is assuming Native Client isn't just a modern ActiveX waiting to be exploited upon deployment.
The main disadvantage I've heard is a perception that a microkernel architecture by necessity imposes a performance penalty. The ability to survive buggy driver code has a flip side in the supposed overhead required to jump in and out of user space whenever the microkernel calls on these drivers.
There are modern pure microkernels out there which perform blazingly fast... Green Hills INTEGRITY is an example. They've gotten around a lot of these little problems in a brilliant way. The open source community is trapped within debates from the early 80's, it's really big world outside of UNIX. Microkernels beat Monoliths on every front aside from brute simplicity. Monoliths can be "elegant," but linux is anything but. Compared to the gnu/linux ecosystem, Windows is extremely well organized and clearly architected.
Google is not looking to innovate in the operating system market, clearly. They're simply doing what so many desktop linux distributions failed at when trying to make a casual OS. They're using Linux because it'll save them time writing difficult boot and driver code and ultimately save them money. They're not writing their own kernel because they're not really going to compete with Windows. I don't think Google really has what it takes to create a serious new kernel, anyway-- or even clean up Minix enough that it performs competitively.
My final
Linux is not Unix. It's a close approximation. For one, the base APIs are not fully POSIX compliant. Right there is a big hurdle to being Unix. If someone were to pony up the cash for certification (RedHat, Novell, Cannonical), there are issues yet to be fixed before it can be called UNIX, so it's not just a question of certifying it.
A weird thing has happened though, hasn't it? They've built linux up as its own fairly strong brand.. but I think the community does lack the attention to detail to make this jump, anyway. The linux kernel is pretty *messy* compared to even BSD. I think this small shift in functionality is probably harder to attain than they let on. At its very best, Linux is an almost-Unix.
If anyone really does need a full compliant UNIX, opensolaris is quite free.
It seems the great linux menace has finally moved out of your imaginations and into the real world. Now, over a decade after its inception, linux has become loosely competitive with Windows in the client market. Pat yourselves on the back. You've done what Microsoft did for a couple hundred thousand dollars in the 80's with a mere $1.2 billion.