You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia...
The fact that there is always completely uninformed speculation is why it actually says something about Red Hat that Cox left. RH would have done a lot to keep him, but it wasn't enough.
There is no book that says more what computing is all about, from the historical perspective of appreciating how genius the founders of computer science were to the zen of how digital computers actually operate and to a different perspective on analog computing.
This book is only 110 pages and is 50 years old, but it is still worth more than any other book mentioned.
Flash on 64-bit linux has alway run in a separate process, and you can do it on any linux with nspluginwragger. When flash crashes you just get some black rectangles where before there were annoying adds.
Separating native code (flash, ActiveX, etc) into other processes is a great idea.
Separating type-safe javascript code into other processes... not so much. If at all.
Except for an independent-process, one-tab-dies-the-rest-of-it's-fine browser that doesn't suck?
It's a nice idea, but how does it help actually an average person?
Lets look at the flip side of the coin -
Crashes:
1) Chrome's GUI is natively coded as opposed to firefox's chrome which is written in javascript. So, a tab in chrome has more code that can to actually crash (from NULL exception, etc). 2) Separate process only help if you are actually using multiple tabs. Not everybody does, and if the wiki tab that you are writing your thesis in crashes you still lose work. 3) Overhead code to clean up failed tabs. Notify shared plugins that an instance died, remove GUI elements from shared spaces, etc. More code to fail or crash, more complicated for plugins, etc. 4) A crash of even one tab is never acceptable in the first place, so you have lots of extra code to handle a situation that must never happen anyway.
Performance:
1) Each tab must communicate with the container process and (for plugins) with other tabs. Although it may be infrequent, this adds latency and at least to some extent serializes many independent actions because they are 'behind' other requests in the pipeline. This can be worked around, by making the parts more complex to do out-of-order requests and such. 2) Many resources are not shared, or use expensive cross-process locking. For instance images are decompressed again in each tab they appear in.
Security:
1) It's easier to crash a Chrome tab due to it using different UI code than pages are rendered with. 2) Attacks that actually hack the the browser itself are actually pretty uncommon, so having separate memory space doesn't protect much against most malicious code. The same cross-site and leak problems are possible with chrome, they just are split between two separate parts (for instance the tab making the 'request' for an element and the container allowing/denying it).
There are plenty of advantages AND disadvantages to chrome's process-per-tab model. We'll just have to wait and see how it all shakes out. But what you can learn from Linus v. Tannenbaum is that complicated monolithic systems can sometimes end up being far, far better than 'everything is recoverable' kinds of systems.
I'm running Ubuntu 8.10 and there is no "CompizConfig Settings Manager" under System -> Preferences.
It may be a GUI that configures Compiz, but it's not included out of the box like every other Preference a user would expect. I'm not sure Configuration Editor is included for that matter, I might have specifically installed it.
If using compiz go to gnome configuration editor and change Apps -> Compiz -> Screen0 -> options -> focus_prevention_level to "2" (or whatever amount you prefer, see help text).
Unfortunately, no GUI for this afaik and it gets reset from time to time during updates.
What do you expect, the government to make/everything/ they use in-house?
Why do you misinterpret, misunderstand, and not answer the question? "Why does your government web site link to and use JavaScript hosted on a corporate site, googleapis.com?"
Why aren't FBI files hosted on google docs? Why isn't gmail used for government business?
It may be a minor matter that for instance google can correlate your IP address with your use of or posts on change.gov, but so is downloading the MIT-licensed source for the javascript and hosting it locally so there are no dependencies on other commercial sites.
I'm not sure you understand what you're trying to imply.
I'm not sure you understand what that sentence even means.
Everyone is way better off with C (for systems stuff), Java (for "enterprisy" stuff), Python (for frontends) and sh (for quick and dirty hacks) than with any C++(*).
What do these languages have in common?
* C * Java * JavaScript
They each have the same highly successful syntax. Except for small adaptations for the different levels of systems vs application vs scripting these languages are interchangeable and each has a certain C-style simpleness and elegance to it.
There are all sorts of different competitor languages... Objective C, Ruby, Smalltalk, D, Pascal, etc. The languages that have been widely successful even since before time began (1970) have been variations of the Algol/C/Java/Javascript style syntax. For whatever reasons, it is what programmers choose. Maybe it just fits better with how our brain actually works rather than how we think our brain should work. Who knows.
But in any event, I suggest that C, Java, Javascript are the trifecta. Python is a dead end, the Pascal of its generation.
Let me follow up to answer several replies. Yes, official Ruby 1.9.1 was overall moderately faster than JRuby. JRuby still is the clear winner:
1) JVM has a garbage collector known to work on multi gb sized heap and JVM has a parallel collector that can use multiple processors. So for large programs (programs that actually matter) one would expect JVM to perform better than these microbenchmarks in respect to Ruby 1.9.1.
2) JVM adapts over time to increase the performance of the most-used parts. The benchmarks probably did not run long enough to get optimized as well as they might in an actual program needing to run fast.
3) JVM version wasn't mentioned, so it was probably 1.6, but if it wasn't openjdk then it wasn't the fastest. 1.7 is coming RSN.
4) JVM is getting improvements for dynamic languages in 1.7 with bytecodes for dynamic method calls, escape analysis to use stack for objects, etc.
So in these microbenchmark tests 1.9.1 is slightly faster. The reality for actual programs is unknown but probably closer still. And JRuby should get faster automatically through improvements to JVM, even aside from improvements to JRuby itself.
I stand corrected. I blame it on the results being a png so no "highlight all" search results;-P
Also, the input sizes for many of the tests numbered in the millions. If that's not enough repetition to take advantage of hotspot optimization, then I'd say they were right to exclude it.
Hotspot tracks how much time was spent in the function among other things. With millions of iterations it may be compiled once, but not recompiled using deeper inlining or frequent-type information. In any case, a benchmark that fast is pretty meaningless for any number of reasons.
Look at how many 0.002 and similar instantaneous results there are. Tests were run 5 times and the best result used, so there probably wasn't even a single garbage collect that happened in many of the tests. You can't really say from such short benchmarks, but those tests probably did not include Java's strength of hotspot optimization over time.
There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.
we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?
Isn't it obvious? Google standardized on C++, Java, and Python. As you point out, Java is already there. This 'any x86' lets them use their other two languages, C and Python. It kills two birds with one stone, and securing x86 is a hell of a lot easier than securing C++.
Of course, if they just straight up told people they wanted to choose the wrong tool for the job just because it's what they know they would have been laughed off the web.
Microsoft Reasearch and others tested Singularity with different memory protection use on modern hardware. VM costs ~6% performance just to use on hardware optimized for VM use. The real cost is even much higher than this, since some delays are imposed by having the cache and lookups support virtual addresses in the first place and can't be 'turned off' by systems like Singularity or JavaOS that do not require it.
The CPU doesn't have the entire page table within itself, it has a cache of some kind (a TLB for instance), and it takes time to update this. So, when VM is 'turned off' essentially all address mappings are found in the TLB cache and no extra performance penalty is imposed. This is the 6% or so that Singularity team measured.
Virtual memory only starts impacting performance when pages are being swapped in and out, because all your processes need more resident memory than you actually have.
Actually, virtual memory adds quite a bit of overhead to everything the processor does. Just using virtual memory slows down the processor by ~6%, and using it in a traditional OS (separate page tables, processes isolated using virtual memory) slows it down by ~20%. These numbers are from Singularity research, fyi, and don't even count the memory cost from the page tables.
So the question I'd ask is why use virtual memory in a modern system?
Singularity, jxos, JavaOS show that it is not necessary or efficient to run programs using 1970s style protection domains. The actual answer is "because of network effects." So much code is written that requires memory protection that we have to also use virtual memory. Oh yeah, and Dvorak keyboard is better than qwerty you free market uber alles freaks!
You're right. Also Stroustrup had clearly pointed (in other argument lines) that C is not the better way to learn C++ (or OO in general):
Somebody quoting Stroustrup on the topic of computer languages... seriously? C++ is like legalese -- it's impenetrable to read, full of unintended consequences, and even though it's spelled out in excruciating detail what it says is still open to interpretation.
Not only is C the first subset of C++ that programmers should learn, it is the only subset of C++ they should learn.
And I argue that C actually teaches people more about object-oriented that most other languages, because it teaches them in no uncertain terms why you should use objects. It's harder to realize why you don't just make fields public until you've seen global variables in a C program.
Then Java teaches you how to do OO where you are not allowed to 'cheat' by replacing methods at runtime, or calling methods that don't exist, etc. And JavaScript takes all that and gives you LISP power.
Kernel driver interface - the horse [mjmwired.net] was already beaten to death many times ( see here [slashdot.org]).
I really have to fault the linux kernel developers here for being obtuse. The reality is that in Linux there is no kernel driver interface. There's 'struct module' and that's all... everything else is internal kernel interface. What module writers are asking for is basically a 'glibc for kernel' that covers say 90% of what a module might reasonable want to do. This would be a stable interface that does not depend on config options or compiler versions, etc.
Linux kernel developers say "you don't really want a stable kernel interface for reasons X, Y, Z" but those reasons apply to the kernel's internal interface, not to a driver ABI (which does not exist in linux).
Module developers say "we want a stable interface for reasons A, B, C" but the only interface is the internal kernel calls... which can't be stable for reasons X, Y, Z.
Just look at the reasons given in your link, in the kernel docs: "As a specific examples (sic) of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem." So that would be THREE whole changes to a stable ABI for USB. Instead, the reality is that the kernel will simply reject a module that wasn't compiled along with the kernel (that specific build), so every kernel build breaks every module. And most new kernel versions and some config changes will break the recompile because an extra parameter was added, or parameters were reordered, or a function name changed so now it has an "_" before it, or some other bogus reason.
The kernel developers are (seemingly) intentionally misunderstanding what module developers are asking for. Presumably from some OSS/GPL bias, so companies have to release open-source drivers. If that's the reason then they need to just own up to it instead of giving those BS reasons.
I don't like the idea behind robots fighting our wars, because that means that "acceptable risks" become a thing of the part, and we are Far more likely to "militarily intervene". Aka: "Less risk to our troops" can translate into "we go into more wars" which is something I don't support... wars benefit companies, and lead to the death of thousands.
Well get used to it. We already operate remotely piloted aircraft. Soldiers will be next. It won't be an autonomous robot per se, more like a mechanical body for the soldiers controlling it remotely. This could be clunky, but successful models will probably be humanoid with some kind of mixed virtual reality plus 'body glove' interface, so soldiers can 'walk' the robot like a person, hold a weapon, etc.
Yeah, it'll be the worst of both worlds... a mostly invulnerable disposable soldier with human failings. But it's also inevitable.
In two of the tests 'won' by chrome it was ~5% faster then the second place, but gets 10 points and second place gets 0. If you're going to use a point systems at least give first place 10 and second place 9 in that case.
There really needs to be a NoShit extension to firefox. If 4 out of 5 smart people mark the article as retarded then the extension blocks it and puts a 'steaming turd' icon in the lower right in case you really want to see the article. Sure, adblocking *foxnews* is a good 90% solution, but we can do better that than.
'devertebrated', though the Oxford English Dictionary doesn't recognise it.
If we're making up words, pretty sure 'redevertebrated' must be the longest word... you know, those vertebrates that had their spine removed in a freak command-line accident involving grep then surgically reimplanted.
Ender proves himself by posthumously baptizing all the souls of his victims, thereby justifying all the killing and giving the story a feel-good Hollywood ending.
Slashdot Mirror
Just one (likely) possible cause. If that is the case it should fix its self tomorrow.
Or it could be the Zune Rapture. This wouldn't have happened if you hadn't put Marilyn Manson on it.
You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia...
The fact that there is always completely uninformed speculation is why it actually says something about Red Hat that Cox left. RH would have done a lot to keep him, but it wasn't enough.
The Computer and the Brain.
There is no book that says more what computing is all about, from the historical perspective of appreciating how genius the founders of computer science were to the zen of how digital computers actually operate and to a different perspective on analog computing.
This book is only 110 pages and is 50 years old, but it is still worth more than any other book mentioned.
Flash on 64-bit linux has alway run in a separate process, and you can do it on any linux with nspluginwragger. When flash crashes you just get some black rectangles where before there were annoying adds.
Separating native code (flash, ActiveX, etc) into other processes is a great idea.
Separating type-safe javascript code into other processes... not so much. If at all.
Except for an independent-process, one-tab-dies-the-rest-of-it's-fine browser that doesn't suck?
It's a nice idea, but how does it help actually an average person?
Lets look at the flip side of the coin -
Crashes:
1) Chrome's GUI is natively coded as opposed to firefox's chrome which is written in javascript. So, a tab in chrome has more code that can to actually crash (from NULL exception, etc).
2) Separate process only help if you are actually using multiple tabs. Not everybody does, and if the wiki tab that you are writing your thesis in crashes you still lose work.
3) Overhead code to clean up failed tabs. Notify shared plugins that an instance died, remove GUI elements from shared spaces, etc. More code to fail or crash, more complicated for plugins, etc.
4) A crash of even one tab is never acceptable in the first place, so you have lots of extra code to handle a situation that must never happen anyway.
Performance:
1) Each tab must communicate with the container process and (for plugins) with other tabs. Although it may be infrequent, this adds latency and at least to some extent serializes many independent actions because they are 'behind' other requests in the pipeline. This can be worked around, by making the parts more complex to do out-of-order requests and such.
2) Many resources are not shared, or use expensive cross-process locking. For instance images are decompressed again in each tab they appear in.
Security:
1) It's easier to crash a Chrome tab due to it using different UI code than pages are rendered with.
2) Attacks that actually hack the the browser itself are actually pretty uncommon, so having separate memory space doesn't protect much against most malicious code. The same cross-site and leak problems are possible with chrome, they just are split between two separate parts (for instance the tab making the 'request' for an element and the container allowing/denying it).
There are plenty of advantages AND disadvantages to chrome's process-per-tab model. We'll just have to wait and see how it all shakes out. But what you can learn from Linus v. Tannenbaum is that complicated monolithic systems can sometimes end up being far, far better than 'everything is recoverable' kinds of systems.
I'm running Ubuntu 8.10 and there is no "CompizConfig Settings Manager" under System -> Preferences.
It may be a GUI that configures Compiz, but it's not included out of the box like every other Preference a user would expect. I'm not sure Configuration Editor is included for that matter, I might have specifically installed it.
If using compiz go to gnome configuration editor and change Apps -> Compiz -> Screen0 -> options -> focus_prevention_level to "2" (or whatever amount you prefer, see help text).
Unfortunately, no GUI for this afaik and it gets reset from time to time during updates.
What do you expect, the government to make /everything/ they use in-house?
Why do you misinterpret, misunderstand, and not answer the question? "Why does your government web site link to and use JavaScript hosted on a corporate site, googleapis.com?"
Why aren't FBI files hosted on google docs?
Why isn't gmail used for government business?
It may be a minor matter that for instance google can correlate your IP address with your use of or posts on change.gov, but so is downloading the MIT-licensed source for the javascript and hosting it locally so there are no dependencies on other commercial sites.
I'm not sure you understand what you're trying to imply.
I'm not sure you understand what that sentence even means.
Maybe I'll sign in so I can submit my question:
"Why does your government web site link to and use JavaScript hosted on a corporate site, googleapis.com?"
It's bad whether it's Haliburton OR Google.
Everyone is way better off with C (for systems stuff), Java (for "enterprisy" stuff), Python (for frontends) and sh (for quick and dirty hacks) than with any C++(*).
What do these languages have in common?
* C
* Java
* JavaScript
They each have the same highly successful syntax. Except for small adaptations for the different levels of systems vs application vs scripting these languages are interchangeable and each has a certain C-style simpleness and elegance to it.
There are all sorts of different competitor languages... Objective C, Ruby, Smalltalk, D, Pascal, etc. The languages that have been widely successful even since before time began (1970) have been variations of the Algol/C/Java/Javascript style syntax. For whatever reasons, it is what programmers choose. Maybe it just fits better with how our brain actually works rather than how we think our brain should work. Who knows.
But in any event, I suggest that C, Java, Javascript are the trifecta. Python is a dead end, the Pascal of its generation.
Let me follow up to answer several replies. Yes, official Ruby 1.9.1 was overall moderately faster than JRuby. JRuby still is the clear winner:
1) JVM has a garbage collector known to work on multi gb sized heap and JVM has a parallel collector that can use multiple processors. So for large programs (programs that actually matter) one would expect JVM to perform better than these microbenchmarks in respect to Ruby 1.9.1.
2) JVM adapts over time to increase the performance of the most-used parts. The benchmarks probably did not run long enough to get optimized as well as they might in an actual program needing to run fast.
3) JVM version wasn't mentioned, so it was probably 1.6, but if it wasn't openjdk then it wasn't the fastest. 1.7 is coming RSN.
4) JVM is getting improvements for dynamic languages in 1.7 with bytecodes for dynamic method calls, escape analysis to use stack for objects, etc.
So in these microbenchmark tests 1.9.1 is slightly faster. The reality for actual programs is unknown but probably closer still. And JRuby should get faster automatically through improvements to JVM, even aside from improvements to JRuby itself.
Ruby 1.9.1 failed two tests; JRuby failed three.
I stand corrected. I blame it on the results being a png so no "highlight all" search results ;-P
Also, the input sizes for many of the tests numbered in the millions. If that's not enough repetition to take advantage of hotspot optimization, then I'd say they were right to exclude it.
Hotspot tracks how much time was spent in the function among other things. With millions of iterations it may be compiled once, but not recompiled using deeper inlining or frequent-type information. In any case, a benchmark that fast is pretty meaningless for any number of reasons.
Look at how many 0.002 and similar instantaneous results there are. Tests were run 5 times and the best result used, so there probably wasn't even a single garbage collect that happened in many of the tests. You can't really say from such short benchmarks, but those tests probably did not include Java's strength of hotspot optimization over time.
There were a couple tests that were much slower in JRuby, but this is countered by the test that failed on Ruby 1.9.1; fast means nothing when you don't finish.
we already have java, which is designed for platform independence(JVM), sandboxability, etc. and has had years of development and wide support. Particularly given the increasing popularity of web on embedded(read non-x86) devices, "sorta-kinda-quasi-java-that-only-runs-on-x86s" seems like an enormous step back. Why would you do that?
Isn't it obvious? Google standardized on C++, Java, and Python. As you point out, Java is already there. This 'any x86' lets them use their other two languages, C and Python. It kills two birds with one stone, and securing x86 is a hell of a lot easier than securing C++.
Of course, if they just straight up told people they wanted to choose the wrong tool for the job just because it's what they know they would have been laughed off the web.
Microsoft Reasearch and others tested Singularity with different memory protection use on modern hardware. VM costs ~6% performance just to use on hardware optimized for VM use. The real cost is even much higher than this, since some delays are imposed by having the cache and lookups support virtual addresses in the first place and can't be 'turned off' by systems like Singularity or JavaOS that do not require it.
The CPU doesn't have the entire page table within itself, it has a cache of some kind (a TLB for instance), and it takes time to update this. So, when VM is 'turned off' essentially all address mappings are found in the TLB cache and no extra performance penalty is imposed. This is the 6% or so that Singularity team measured.
Virtual memory only starts impacting performance when pages are being swapped in and out, because all your processes need more resident memory than you actually have.
Actually, virtual memory adds quite a bit of overhead to everything the processor does. Just using virtual memory slows down the processor by ~6%, and using it in a traditional OS (separate page tables, processes isolated using virtual memory) slows it down by ~20%. These numbers are from Singularity research, fyi, and don't even count the memory cost from the page tables.
So the question I'd ask is why use virtual memory in a modern system?
Singularity, jxos, JavaOS show that it is not necessary or efficient to run programs using 1970s style protection domains. The actual answer is "because of network effects." So much code is written that requires memory protection that we have to also use virtual memory. Oh yeah, and Dvorak keyboard is better than qwerty you free market uber alles freaks!
You're right. Also Stroustrup had clearly pointed (in other argument lines) that C is not the better way to learn C++ (or OO in general):
Somebody quoting Stroustrup on the topic of computer languages... seriously? C++ is like legalese -- it's impenetrable to read, full of unintended consequences, and even though it's spelled out in excruciating detail what it says is still open to interpretation.
Not only is C the first subset of C++ that programmers should learn, it is the only subset of C++ they should learn.
And I argue that C actually teaches people more about object-oriented that most other languages, because it teaches them in no uncertain terms why you should use objects. It's harder to realize why you don't just make fields public until you've seen global variables in a C program.
Then Java teaches you how to do OO where you are not allowed to 'cheat' by replacing methods at runtime, or calling methods that don't exist, etc. And JavaScript takes all that and gives you LISP power.
Kernel driver interface - the horse [mjmwired.net] was already beaten to death many times ( see here [slashdot.org]).
I really have to fault the linux kernel developers here for being obtuse. The reality is that in Linux there is no kernel driver interface. There's 'struct module' and that's all... everything else is internal kernel interface. What module writers are asking for is basically a 'glibc for kernel' that covers say 90% of what a module might reasonable want to do. This would be a stable interface that does not depend on config options or compiler versions, etc.
Linux kernel developers say "you don't really want a stable kernel interface for reasons X, Y, Z" but those reasons apply to the kernel's internal interface, not to a driver ABI (which does not exist in linux).
Module developers say "we want a stable interface for reasons A, B, C" but the only interface is the internal kernel calls... which can't be stable for reasons X, Y, Z.
Just look at the reasons given in your link, in the kernel docs: "As a specific examples (sic) of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem." So that would be THREE whole changes to a stable ABI for USB. Instead, the reality is that the kernel will simply reject a module that wasn't compiled along with the kernel (that specific build), so every kernel build breaks every module. And most new kernel versions and some config changes will break the recompile because an extra parameter was added, or parameters were reordered, or a function name changed so now it has an "_" before it, or some other bogus reason.
The kernel developers are (seemingly) intentionally misunderstanding what module developers are asking for. Presumably from some OSS/GPL bias, so companies have to release open-source drivers. If that's the reason then they need to just own up to it instead of giving those BS reasons.
Even the robot bears find Chuck-ee Cheese boring and demeaning.
I don't like the idea behind robots fighting our wars, because that means that "acceptable risks" become a thing of the part, and we are Far more likely to "militarily intervene". Aka: "Less risk to our troops" can translate into "we go into more wars" which is something I don't support... wars benefit companies, and lead to the death of thousands.
Well get used to it. We already operate remotely piloted aircraft. Soldiers will be next. It won't be an autonomous robot per se, more like a mechanical body for the soldiers controlling it remotely. This could be clunky, but successful models will probably be humanoid with some kind of mixed virtual reality plus 'body glove' interface, so soldiers can 'walk' the robot like a person, hold a weapon, etc.
Yeah, it'll be the worst of both worlds... a mostly invulnerable disposable soldier with human failings. But it's also inevitable.
In two of the tests 'won' by chrome it was ~5% faster then the second place, but gets 10 points and second place gets 0. If you're going to use a point systems at least give first place 10 and second place 9 in that case.
There really needs to be a NoShit extension to firefox. If 4 out of 5 smart people mark the article as retarded then the extension blocks it and puts a 'steaming turd' icon in the lower right in case you really want to see the article. Sure, adblocking *foxnews* is a good 90% solution, but we can do better that than.
'devertebrated', though the Oxford English Dictionary doesn't recognise it.
If we're making up words, pretty sure 'redevertebrated' must be the longest word... you know, those vertebrates that had their spine removed in a freak command-line accident involving grep then surgically reimplanted.
The real question now is, can spiders make egg sacs in space? Also do mutant sun-irradiated vampire spiders like to feast on human blood?
We may have to nuke the space station from ground... it's the only way to be sure.
Ender proves himself by posthumously baptizing all the souls of his victims, thereby justifying all the killing and giving the story a feel-good Hollywood ending.
Nothing can beat perl script voice recognition.