TFA's author doesn't know what he's talking about
on
Where's My 10 Ghz PC?
·
· Score: 1
Today's CPUs sport some more powerful instructions, and they perform optimizations that range from the pedestrian to the exotic, including pipelining, branch prediction, executing multiple instructions in the same clock cycle(s), and even reordering the instruction stream for out-of-order execution. Calling any of those "optimizations" is a stretch, in my opinion, unless a V8 engine (or maybe two 4-cylinder engines with a shared gas tank and transmission) is an "optimization" of an inline 4.
Note that some of what I just called "optimizations" are actually far more than optimizations, in that they can change the meaning of programs and cause visible effects that can break reasonable programmer expectations. Not on any "normal" CPU (see explanation below).
But in recent years they have been willing to pursue aggressive optimizations just to wring yet more speed out of each cycle, even knowing full well that these aggressive rearrangements could endanger the semantics of your code. They won't affect the semantics of code unless the CPU has a design problem (again, see below).
Two noteworthy examples in this respect are write reordering and read reordering: Allowing a processor to reorder write operations has consequences that are so surprising, and break so many programmer expectations, that the feature generally has to be turned off because it's too difficult for programmers to reason correctly about the meaning of their programs in the presence of arbitrary write reordering. Reordering read operations can also yield surprising visible effects, but that is more commonly left enabled anyway because it isn't quite as hard on programmers, and the demands for performance cause designers of operating systems and operating environments to compromise and choose models that place a greater burden on programmers because that is viewed as a lesser evil than giving up the optimization opportunities. Actually, you reorder them inside the processor, and then do a check to make sure your reordering did not affect the functionality before actually committing to memory (some instruction sets allow memory access reordering, and have explicit instructions to specify that certain operations must happen before others). As it is right now, your top-of-the-line x86 chip is going appear to execute a program exactly the way it would if it only did one operation at a time, and everything in order. A HUGE amount of work goes in to implementing "precise interrupts" - making sure that at any point, if you interrupt the CPU, all instructions before the current PC (program counter) have executed to completion, and no subsequent instructions have started execution).
Basically, the way instruction reordering works is that instructions are fetched from memory in order, and their dependencies are evaluated. They're given tags (unique IDs inside the CPU), and their tags are added, in order, to a queue at the end of the pipeline. Then, they flow through the actual execution units out of order. As they execute, they update a "speculative state" - results are sometimes stored in an entirely separate register file called the "future file". An instruction can only affect "architectural state" (programmer-visible state) when it is the oldest instruction in the queue at the end of the pipeline. If an instruction has an exception (divide by zero, software breakpoint, interrupt), all subsequent instructions are squashed - you can do this because the queue is added to in order, and the machine looks just like an in-order machine would.
It's worth noting that various researchers have looked into the optimal pipeline depth - basically, due to various sources of overhead (flip flops cannot store values instantaneously, there is clock skew on a chip, and other higher-level factors like data dependencies), they conclude that 6-8 gate delays
Right, but the point is, a chip rated at X GHz is *completely* stable at that speed. As far as manufacturers are concerne, there are two possibilities: a chip passes all tests, or is garbage. A Xeon is not going to be more reliable than a P4.
A quick search of the source code seems to show that the native OS LoadImage function is only used to set Mozilla icons (system tray, window icons, etc) and the splash screen (and the cck). Since none of these images come from untrusted sources*, it seems that the LoadImage hole is not exploitable via Mozilla.
*without major user intervention, like installing an XPI or messing with the JAR files that make up Mozilla
However, until some peer review mechanism is adopted for "official extensions", this is again a rather moot point.
For what it's worth, we do a little review of extensions to make sure the work and don't break things before posting them to update.mozilla.org, but as you might guess, we don't have the resources to actually look through the code for every extension submitted.
How about, uh, you know, actually loading multiple things at once instead of waiting for some service to take its time to start, therby holding everything else up along the way. That's what the problem seems to be - everything has to load in-line.
Perhaps you'd be interested in this IBM article which was on slashdot a while back.
Who said anything about locking out linux? Just because he couldn't get it to run doesn't mean it's locked out. Besides, given the target market, the machines are as locked-down as possible to minimize support cost. This doesn't appear to be aimed at geeks in developed countries (is it even available in the US?) - it's aimed at people who can't afford faster PCs and just want internet access. They probably don't want someone to look up "how to make your PIC cooler by installing linux", botch the setup, and need support.
The update.mozilla.org server has a load average that's hovering around 150 - unfortunately, right now all of the pages are dynamically generated, and it isn't behind a squid proxy.
The suite is not being ignored. Live bookmarks are in the Suite, as are all the Thunderbird features you mentioned. Tabbed-browser improvements are being added as well.
The reason you don't see this yet is development happens on trunk (currently 1.8a6), but the current release is on the 1.7 branch. Generally when a version branches, features are not backported to it - only more important and stable updates (crash fixes, rendering fixes, etc) get included. If you download a trunk nightly, you'll find all of these features.
Unfortunately, due to the Firefox hype, there are few users testing the 1.8 alphas, meaning that 1.8 will have to stay in alpha longer (it's on alpha 6 right now) before moving to beta and eventually release. A lot of the developers who work on Mozilla projects don't use, like, or care about Fireofx - the suite is not going to die any time soon.
I was wondering about that. You also have to consider the size of a transistor in a flash device, versus a hard-drive-like head. Isn't the transitor going to be significantly smaller (and orders of magnitude cheaper)?
The vast majority of security issues that exist in Firefox 0.x also exist in Mozilla 1.x and Netscape 7.x. It's not like hitting 1.0 magically improves code quality.
Many of the core developers of the code shared between Mozilla and FireFox are die-hard Mozilla fans - some of them would rather fix a trivial Mozilla bug than a critical FireFox bug. When a lot of the developers are behind a product, it will continue to exist no matter what.
I don't think Mozilla is just a technology demo. If it is, it's one that a lot of Gecko developers use as their primary browser (and, as a result, they make it very usable).
Actually, a chip does turn all the power it uses into heat. The "useful work" that's done by a CPU is just charges moving around, but eventually it all ends up as heat anyway.
From mikeswi's reply: "Interesting how you ignored 90% of the substance of my post and latched on to something that comes down to the standard full-disclosure-or-not argument."
What's your point? So he didn't reply to every point in your post. So? Maybe he agreed with that part and had nothing to say about it. That just about sums it up.
First off, if someone reports a bug, it should be ASSUMED that there is a potential security issue there, until proven otherwise. Why? Because there are generally side-effects. Even if the bug doesn't directly do anything nasty, it may very well cause something unintended which, in turn, causes something else unintended, and so on.
Do you have any idea how many bugs are filed each day? It's usually dozens to hundreds. Security bugs can only be viewed by members of the security group, and there aren't that many of them, AND the people who are in the group are only there because they've demonstrated repeatedly their ability to contribute to the project. Do you really want to waste the time of some of *the best* developers by making them look through bugs like "This page looks better in Internet Explorer" or "Product doesn't fucking work with simple html files." (an idiotic and pissed off user, bug 260136)? Triaging is often done by people who want to help, but don't have the coding skills necessary to fix a lot of the bugs.
For what it's worth, I can't think of any bugs that ended up "snowballing" that we didn't know were major from the start.
There are two classes of bugs in a computer program. Those that cause the program to crash, and those that don't. The second type are much harder to track down (because you've no real indication of where the problem started), but they are generally much worse and much more prevelent. Bugs that cause crashes can be hard to track down - for example, you may have code that caused corruption somewhere and the program won't crash until later. Bugs that don't cause crashes can also be very easy to track down - for example, various UI issues may be as simple to fix as just editing a few lines of javascript.
The "correct" way to handle bugs is to assume that (almost) any problem puts the software at risk of a non-fatal bug that could (eventually) destabilize the program or open an exploit. Unless you have infinite resources, that's not a realistic approach (see above)
Spelling errors in text messages are probably OK, but even there, if you're placing them in fixed-length buffers, it is saner to check and be sure that the risks are low than to ignore apparently trivial "appearance" stuff that could be catastrophic. Pretty much every string in Mozilla is localizable - when I write code with a string the user sees, there's no way I could put it into a static buffer. Spelling errors causing buffer overflows? PUH-LEASE!
I've seen programmers give themselves buffer overflows, I've even seen programmers rely on certain OS quirks when an overflow occurs. The code may not be portable, and it sure as hell isn't safe, but it does work. The Mozilla apps are cross platform. It works the other way around for us - we have to work *around* quirks, not take advantage of them (see bug 255120, for example)
(I've actually seen some code that won't run, unless the debug flag is present. The code will actually segfault if the extra padding the debug data creates is not there. Not from the Mozilla team, this was in a prior place of employment, but it does demonstrate that coding is not just about making something "work" it's about making it work for the right reasons.) Yes, software has bugs. So?
Now, the Mozilla team is probably simply too small to regard every bug entered in their database as a potentially critical show-stopping security hazard. This, however, reflects more on the userbase than on the Mozilla folks. Open Source works if, and only if, the "lots of eyes" out there looking for problems also translate into "lots of hands" for fixing problems. ...so what you said above is irrelevant? Every project has problems, and the team members do their best to do a good job.
Oh and in my personal experience, the best way to get a security bug fixed once you discover it is to immediatly write an exploit, clearly flag the bug as a security hole, and post it to a public forum with a sifficuently broad readership that someone in a position to fix the bug will, be that the project's BTS or bugtraq.
Great, and now while users are surfing the web between checks of [windows update | product's website], they're getting hacked. Good job.
If you file a Mozilla bug and mark it as security sensitive, it will get looked at. Often, workarounds are publicized by the Mozilla Foundation before a fix becomes available, so users can sometimes protect themselves. If the bug doesn't get fixed immediately, there are a few possibilities: 1. It's very very unlikely to be exploited, so long as the black hats don't know about it (e.g. this bug). By publicizing it, the black hats find the bug, and everyone gets hacked. As long as it stays quiet, users are most likely still safe, and developers can work on it (or even more dangerous bugs, if they happen to exist). 2. The bug is very difficult to fix. The permanent-DoS bug with SSL certs that was fixed a couple releases ago was a good example of this - developers spent a LOT of time trying to track down the problem and fix it. If you go full-disclosure on them, what happens? Everybody gets hacked, and then some time later the developers figure out the problem and fix it.
Don't take it as a personal insult that your pet bug isn't being fixed right away - there are dozens to hundreds of bugs filed every day, a limited group of people to do triaging (separating the real bugs from the duplicates / invalid bugs), and an even smaller group who know the code well enough to fix bugs.
is not very positive. If you ever dare to ask if any progress has been made, or for an ETA on a fix, you're bound to get a "well why don't you fix it yourself" indignant reply. If progress is made, you'll see patches added to the bug, or comments from developers discussing the fix. Parents get annoyed by incessant kids in the car asking "are we there yet?", and developers get annoyed by incessant users asking "is this fixed yet?". In both examples, the question's answer is obvious.
Spamming a bug with comments like "why isn't this fixed?", "this bug still annoys me", "don't wontfix this bug" and "this bug is really old and annoying, you guys suck and don't care" doesn't help fix the bug - I can't speak for other developers, but getting many useless emails about a bug only makes me more likely to remove myself from the CC list and forget about it. Having to read through 150+ "why isn't this fixed" comments to find relevant information doesn't help anything either. If someone takes the time to figure out where a fix for a bug needs to go, or contributes something, it's different.
I would be more than willing to contribute code under contract for this project. Unfortunately, my services do not come free. Mozilla is free. Many of the people who fix bugs (for example, me - you'll have to copy and paste that URL) aren't paid. Whining about volunteers not fixing a bug you care about doesn't do anything. Insulting them is even less productive. If you don't have anything constructive to say, don't bother people.
Slashdot Mirror
Today's CPUs sport some more powerful instructions, and they perform optimizations that range from the pedestrian to the exotic, including pipelining, branch prediction, executing multiple instructions in the same clock cycle(s), and even reordering the instruction stream for out-of-order execution.
Calling any of those "optimizations" is a stretch, in my opinion, unless a V8 engine (or maybe two 4-cylinder engines with a shared gas tank and transmission) is an "optimization" of an inline 4.
Note that some of what I just called "optimizations" are actually far more than optimizations, in that they can change the meaning of programs and cause visible effects that can break reasonable programmer expectations.
Not on any "normal" CPU (see explanation below).
But in recent years they have been willing to pursue aggressive optimizations just to wring yet more speed out of each cycle, even knowing full well that these aggressive rearrangements could endanger the semantics of your code.
They won't affect the semantics of code unless the CPU has a design problem (again, see below).
Two noteworthy examples in this respect are write reordering and read reordering: Allowing a processor to reorder write operations has consequences that are so surprising, and break so many programmer expectations, that the feature generally has to be turned off because it's too difficult for programmers to reason correctly about the meaning of their programs in the presence of arbitrary write reordering. Reordering read operations can also yield surprising visible effects, but that is more commonly left enabled anyway because it isn't quite as hard on programmers, and the demands for performance cause designers of operating systems and operating environments to compromise and choose models that place a greater burden on programmers because that is viewed as a lesser evil than giving up the optimization opportunities.
Actually, you reorder them inside the processor, and then do a check to make sure your reordering did not affect the functionality before actually committing to memory (some instruction sets allow memory access reordering, and have explicit instructions to specify that certain operations must happen before others). As it is right now, your top-of-the-line x86 chip is going appear to execute a program exactly the way it would if it only did one operation at a time, and everything in order. A HUGE amount of work goes in to implementing "precise interrupts" - making sure that at any point, if you interrupt the CPU, all instructions before the current PC (program counter) have executed to completion, and no subsequent instructions have started execution).
Basically, the way instruction reordering works is that instructions are fetched from memory in order, and their dependencies are evaluated. They're given tags (unique IDs inside the CPU), and their tags are added, in order, to a queue at the end of the pipeline. Then, they flow through the actual execution units out of order. As they execute, they update a "speculative state" - results are sometimes stored in an entirely separate register file called the "future file". An instruction can only affect "architectural state" (programmer-visible state) when it is the oldest instruction in the queue at the end of the pipeline. If an instruction has an exception (divide by zero, software breakpoint, interrupt), all subsequent instructions are squashed - you can do this because the queue is added to in order, and the machine looks just like an in-order machine would.
It's worth noting that various researchers have looked into the optimal pipeline depth - basically, due to various sources of overhead (flip flops cannot store values instantaneously, there is clock skew on a chip, and other higher-level factors like data dependencies), they conclude that 6-8 gate delays
Right, but the point is, a chip rated at X GHz is *completely* stable at that speed. As far as manufacturers are concerne, there are two possibilities: a chip passes all tests, or is garbage. A Xeon is not going to be more reliable than a P4.
A quick search of the source code seems to show that the native OS LoadImage function is only used to set Mozilla icons (system tray, window icons, etc) and the splash screen (and the cck). Since none of these images come from untrusted sources*, it seems that the LoadImage hole is not exploitable via Mozilla.
*without major user intervention, like installing an XPI or messing with the JAR files that make up Mozilla
However, until some peer review mechanism is adopted for "official extensions", this is again a rather moot point.
For what it's worth, we do a little review of extensions to make sure the work and don't break things before posting them to update.mozilla.org, but as you might guess, we don't have the resources to actually look through the code for every extension submitted.
How about, uh, you know, actually loading multiple things at once instead of waiting for some service to take its time to start, therby holding everything else up along the way. That's what the problem seems to be - everything has to load in-line.
Perhaps you'd be interested in this IBM article which was on slashdot a while back.
Who said anything about locking out linux? Just because he couldn't get it to run doesn't mean it's locked out. Besides, given the target market, the machines are as locked-down as possible to minimize support cost. This doesn't appear to be aimed at geeks in developed countries (is it even available in the US?) - it's aimed at people who can't afford faster PCs and just want internet access. They probably don't want someone to look up "how to make your PIC cooler by installing linux", botch the setup, and need support.
But where's the leetness if it's not "MOOX Optimized"? Then it's just another email client that millions of other people use.
That's why I use FlashBlock - it gets rid of flash, but doesn't block anything else.
How is this different from The Face Book? It seems most college students are already more than willing to provide their personal details.
Are they l33t enough to use F1r3f0x?
XPI for language pack
The update.mozilla.org server has a load average that's hovering around 150 - unfortunately, right now all of the pages are dynamically generated, and it isn't behind a squid proxy.
Firefox - l33test browser ever.
Language Pack XPI
Locale-switcher extension (updated for Firefox 1.0)
The suite is not being ignored. Live bookmarks are in the Suite, as are all the Thunderbird features you mentioned. Tabbed-browser improvements are being added as well.
The reason you don't see this yet is development happens on trunk (currently 1.8a6), but the current release is on the 1.7 branch. Generally when a version branches, features are not backported to it - only more important and stable updates (crash fixes, rendering fixes, etc) get included. If you download a trunk nightly, you'll find all of these features.
Unfortunately, due to the Firefox hype, there are few users testing the 1.8 alphas, meaning that 1.8 will have to stay in alpha longer (it's on alpha 6 right now) before moving to beta and eventually release. A lot of the developers who work on Mozilla projects don't use, like, or care about Fireofx - the suite is not going to die any time soon.
I was wondering about that. You also have to consider the size of a transistor in a flash device, versus a hard-drive-like head. Isn't the transitor going to be significantly smaller (and orders of magnitude cheaper)?
The vast majority of security issues that exist in Firefox 0.x also exist in Mozilla 1.x and Netscape 7.x. It's not like hitting 1.0 magically improves code quality.
Many of the core developers of the code shared between Mozilla and FireFox are die-hard Mozilla fans - some of them would rather fix a trivial Mozilla bug than a critical FireFox bug. When a lot of the developers are behind a product, it will continue to exist no matter what.
I don't think Mozilla is just a technology demo. If it is, it's one that a lot of Gecko developers use as their primary browser (and, as a result, they make it very usable).
Actually, a chip does turn all the power it uses into heat. The "useful work" that's done by a CPU is just charges moving around, but eventually it all ends up as heat anyway.
From TFA:
Initially, the PC will be sold in India, Russia, China, Mexico and Brazil.
It's a different target market.
There are many different lines of Geodes. The GX models are not related to Athlons. The NX models are based directly on the Thoroughbred Athlon core.
The CPU is a Geode. Geodes are x86 CPUs - they even run linux just fine.
Do you speak for the Mozilla project?
No.
From mikeswi's reply:
"Interesting how you ignored 90% of the substance of my post and latched on to something that comes down to the standard full-disclosure-or-not argument."
What's your point? So he didn't reply to every point in your post. So? Maybe he agreed with that part and had nothing to say about it.
That just about sums it up.
First off, if someone reports a bug, it should be ASSUMED that there is a potential security issue there, until proven otherwise. Why? Because there are generally side-effects. Even if the bug doesn't directly do anything nasty, it may very well cause something unintended which, in turn, causes something else unintended, and so on.
...so what you said above is irrelevant? Every project has problems, and the team members do their best to do a good job.
Do you have any idea how many bugs are filed each day? It's usually dozens to hundreds. Security bugs can only be viewed by members of the security group, and there aren't that many of them, AND the people who are in the group are only there because they've demonstrated repeatedly their ability to contribute to the project. Do you really want to waste the time of some of *the best* developers by making them look through bugs like "This page looks better in Internet Explorer" or "Product doesn't fucking work with simple html files." (an idiotic and pissed off user, bug 260136)? Triaging is often done by people who want to help, but don't have the coding skills necessary to fix a lot of the bugs.
For what it's worth, I can't think of any bugs that ended up "snowballing" that we didn't know were major from the start.
There are two classes of bugs in a computer program. Those that cause the program to crash, and those that don't. The second type are much harder to track down (because you've no real indication of where the problem started), but they are generally much worse and much more prevelent.
Bugs that cause crashes can be hard to track down - for example, you may have code that caused corruption somewhere and the program won't crash until later. Bugs that don't cause crashes can also be very easy to track down - for example, various UI issues may be as simple to fix as just editing a few lines of javascript.
The "correct" way to handle bugs is to assume that (almost) any problem puts the software at risk of a non-fatal bug that could (eventually) destabilize the program or open an exploit.
Unless you have infinite resources, that's not a realistic approach (see above)
Spelling errors in text messages are probably OK, but even there, if you're placing them in fixed-length buffers, it is saner to check and be sure that the risks are low than to ignore apparently trivial "appearance" stuff that could be catastrophic.
Pretty much every string in Mozilla is localizable - when I write code with a string the user sees, there's no way I could put it into a static buffer. Spelling errors causing buffer overflows? PUH-LEASE!
I've seen programmers give themselves buffer overflows, I've even seen programmers rely on certain OS quirks when an overflow occurs. The code may not be portable, and it sure as hell isn't safe, but it does work.
The Mozilla apps are cross platform. It works the other way around for us - we have to work *around* quirks, not take advantage of them (see bug 255120, for example)
(I've actually seen some code that won't run, unless the debug flag is present. The code will actually segfault if the extra padding the debug data creates is not there. Not from the Mozilla team, this was in a prior place of employment, but it does demonstrate that coding is not just about making something "work" it's about making it work for the right reasons.)
Yes, software has bugs. So?
Now, the Mozilla team is probably simply too small to regard every bug entered in their database as a potentially critical show-stopping security hazard. This, however, reflects more on the userbase than on the Mozilla folks. Open Source works if, and only if, the "lots of eyes" out there looking for problems also translate into "lots of hands" for fixing problems.
Sure, not everybody is goi
Oh and in my personal experience, the best way to get a security bug fixed once you discover it is to immediatly write an exploit, clearly flag the bug as a security hole, and post it to a public forum with a sifficuently broad readership that someone in a position to fix the bug will, be that the project's BTS or bugtraq.
Great, and now while users are surfing the web between checks of [windows update | product's website], they're getting hacked. Good job.
If you file a Mozilla bug and mark it as security sensitive, it will get looked at. Often, workarounds are publicized by the Mozilla Foundation before a fix becomes available, so users can sometimes protect themselves. If the bug doesn't get fixed immediately, there are a few possibilities:
1. It's very very unlikely to be exploited, so long as the black hats don't know about it (e.g. this bug). By publicizing it, the black hats find the bug, and everyone gets hacked. As long as it stays quiet, users are most likely still safe, and developers can work on it (or even more dangerous bugs, if they happen to exist).
2. The bug is very difficult to fix. The permanent-DoS bug with SSL certs that was fixed a couple releases ago was a good example of this - developers spent a LOT of time trying to track down the problem and fix it. If you go full-disclosure on them, what happens? Everybody gets hacked, and then some time later the developers figure out the problem and fix it.
Don't take it as a personal insult that your pet bug isn't being fixed right away - there are dozens to hundreds of bugs filed every day, a limited group of people to do triaging (separating the real bugs from the duplicates / invalid bugs), and an even smaller group who know the code well enough to fix bugs.
For what its worth, a bunch of the people working on Mozilla and Firefox are paid by IBM.
is not very positive. If you ever dare to ask if any progress has been made, or for an ETA on a fix, you're bound to get a "well why don't you fix it yourself" indignant reply.
If progress is made, you'll see patches added to the bug, or comments from developers discussing the fix. Parents get annoyed by incessant kids in the car asking "are we there yet?", and developers get annoyed by incessant users asking "is this fixed yet?". In both examples, the question's answer is obvious.
Spamming a bug with comments like "why isn't this fixed?", "this bug still annoys me", "don't wontfix this bug" and "this bug is really old and annoying, you guys suck and don't care" doesn't help fix the bug - I can't speak for other developers, but getting many useless emails about a bug only makes me more likely to remove myself from the CC list and forget about it. Having to read through 150+ "why isn't this fixed" comments to find relevant information doesn't help anything either. If someone takes the time to figure out where a fix for a bug needs to go, or contributes something, it's different.
I would be more than willing to contribute code under contract for this project. Unfortunately, my services do not come free.
Mozilla is free. Many of the people who fix bugs (for example, me - you'll have to copy and paste that URL) aren't paid. Whining about volunteers not fixing a bug you care about doesn't do anything. Insulting them is even less productive. If you don't have anything constructive to say, don't bother people.