You get power dissipation in each gate or buffer that changes state because of some signal, irregardless of the direction in which the information is flowing. You can not recycle this power. This comes directly from the basic principle behind CMOS technology (used by almost all digital chips today) - you are charging and discharging a capacitor.
You're half right. You're right that what's going on is a charging and discharging of a cap, but you're wrong that the charge can't be recycled. A conventional clock works by connecting the gates of a bunch of devices (i.e. capacitance) to Vdd, then after a little time connecting it to ground instead. Wait a little bit, then repeat. What effectively happens is that you dump some amount of charge from Vdd to ground each switch, and it's gone (i.e. it's heat now). A water analogy would be a tub of water above you (Vdd), a bucket in your hand (the capacitance), and the ground (gnd). You pour some water from the tub into your bucket (charge the cap), then dump it on the ground.
It doesn't have to be this way. There are actually ways to charge a capacitor, and then pull the charge back out again (without dumping it to ground)! I'm going to assume you're familiar with LRC circuts, and how they can resonant when an impulse is applied. What's going on during the oscilattions? Charge is moving into the capacitor, and then being pulled back out to the inductor. The same charge goes back and forth, ideally forever (of course, in practice, the resistance isn't 0 so you put out some heat and the oscillations dies down). I'm not sure what exactly the water analogy would be - maybe a wave sloshing back and forth in a trough.
I recently attended a seminar where the presenter talked about clocking based on LRC oscillations and he had actually fabbed chips that worked. The basic idea was to put an inductor on the die, and set up oscillations between the inductor and the clock load capacitance, which results in a ticking clock. Of course, you get a sinusoidal clock instead of a nice almost-square-wave, so your circuits have to be designed a little bit differently, but the point is, it works and is doable.
Now, the technology described in this article, as best as I can tell, uses another idea - transmission lines. In a normal design, your clock grid basically looks like a bunch of capacitors with resistors in between (i.e. distributed RC). It takes time for a signal to propagate - signals propagate much slower than the speed of light, becuase you actually have to charge up the capacitance along the line through the resistance of the line itself. Imagine a long trough that's empty. You start pouring water in, and although water reaches the far side pretty quickly, you don't actually observe it until the water level at the far end is half way up. Signals propagate differently when wires are set up as transmission lines - they propagate at much closer to the speed of light, because you're actually sending a wave down the line (imagine creating a ripple on a trough of water, instead of actually filling and emptying the trough).
Now, I don't understand how they combined charge recycling and transmission lines, I don't understand transmission lines all that well, but your arguments aren't good reasons to disregard the claims made by the company.
If you're interested, here is a little bit of info about the talk I went to.
Typical example, that running signals in a circuit does not save power: take a ring oscillator (a number of negators wired in a loop). This circuit will oscillate (send changing signals through its loop) and consume an considerable amount of power. If you created an oscillator between an inductor and a capacitor, on the other hand, once you started it going, it would continue for a long time with minimal energy injected in the future.
Maybe because the Mozilla Foundation is smart enough not to take big risks with security releases? They got a lot of heat with 1.0.x from distributors, since they included more fixes than just the security fixes and major stability fixes, so now the 0.0.0.1 increments will only fix very very low risk (or very high-impact) issues in security releases.
It might seem like a fix is simple, but when you have a really large codebase and millions of web pages doing strange things, it's very easy for a "simple fix" to significantly change rendering results. Sure, in this case you personally would like the change, but imagine if you had a corporate intranet which for some reason depended on that specific alignment being unsupported. You distribute the security update, and suddenly it looks wrong. You'd be flaming the Mozilla Foundation for changing non-critical things in a minor point release.
That's why old branches are supported (i.e. Firefox 1.0.x) long after a new release is available - people don't want to have to worry about non-critical changes breaking things for point releases.
The Inquirer is generally regarded as a somewhat-reliable rumor mill that publishes a lot of tech secrets from leaked documents, plus general industry news.
The people who attempt to argue against evolution never use the scientific method, and produce untestable hypotheses (e.g. "the flying spaghetti monster created the universe"). Why should other scientists NOT ostracize people who claim to be scientists but have demonstrated that, for issues that are important to them, they won't actually use science?
I actually put together this earlier this month to show someone that even in a simulation environment, with every node starting at the same voltage (which should be a "stable" state, as long as it's not disturbed by outside influences), the floating point inaccuracies in the simulator are sufficient for oscillation to start spontaneously.
It's already easy to embed things into a single file with Gecko-based browsers (e.g. SeaMonkey, Firefox, etc) - all you'd have to do is grab the data that makes up the various files in the page (images, swfs, etc) and use "data:" URLs. For an example of a page that already embeds some images directly into the HTML, view this page with a Gecko-based browser. If you look at the source, you'll see some images inlined right into the HTML. I'd imagine it would not be difficult to make an extension that does what Unipage is currently doing. If all the content is hosted on the same domain, you could probably do it almost trivially in the page itself with some XMLHttpRequests to fetch the contents of images and other objects and inline them into document.innerHTML before saving it to a file.
While some Mozilla developers may suggest otherwise, I doubt there is much that can be done to deal with such issues. The general architecture and code quality of Mozilla is so bad that fixing such issues would be a massive undertaking.
I've seen you repeatedly make this claim. Can you back it up with some examples? Perhaps a link to LXR showing some bad code?
It's definitely worth reminding people that if you *flawlessly* rendered valid CSS, but also were forgiving and did a "best guess" for broken CSS, you'd fail the Acid2 test.
Are you suggesting we shouldn't bother implementing features just because somebody else came up with it? That's a pretty stupid idea. We find a feature we like, we implement it, even if we're not the first.
Note that the release announcement mentions features added since Mozilla 1.7, since that's what we figured many users would be coming from, so we've actually had a lot of these features in the nightlies for quite a while.
There are a lot of other features too - these are just ones we happened to think were interesting.
Re:For those of us not in the know...
on
SeaMonkey 1.0 Released
·
· Score: 5, Informative
Is the "Mozilla Suite" project dead? Is Seamonkey the replacement for the old Mozilla Suite? Will the next version of Netscape be based on Seamonkey 1.0?
"Mozilla Suite" will only get security updates. No more new development. SeaMonkey is a good replacement for the old suite - it's effectively Mozilla 1.8 (SeaMonkey 1.0 alpha was what would have been Mozilla 1.8 beta 5). If Netscape decides to ship annother "Communicator" (rather than just a browser), they would be wise to use SeaMonkey as a base for it.
If you like an integrated suite, be sure to give SeaMonkey a try. It's got pretty much the same features as Thunderbird 1.5, but also includes a browser and more.
He also complains about a hard drive problem related to 130GB. If he's going to compare to a new linux distro, shouldn't he at least have obtained an XP CD with SP1 already on it? My school only provides XP with SP1 (maybe SP2 now?) already on it.
cmd is a lot more powerful than he makes it out to be.
He says Windows gamers need to disable services for performance. He's mistaken - someone on the Anandtech Forums did a comprehensive test of game performance with and without many services and found no actual benefits. The people shutting off services are misinformed tweakers. It already performs great, with the services on.
Re:No words will fix the problem.
on
Firefox Secrets
·
· Score: 1
On the off chance you really would like to help, get on IRC (irc.mozilla.org, read the MOTD for channels), DON'T speculate on things you know nothing about, DON'T think you have more of a clue than the people there, and ask for help tracking down one of the problems you experience. Make sure you're using a nightly build for reasons I've already explained. You might start by giving a specific site or action that reliably crashes you 100% of the time. Be patient too, not all channels are active all the time, and you might even have to come back on a few separate occasions. Keep in mind that some people are in different time zones, and many people may be on vacation.
Re:No words will fix the problem.
on
Firefox Secrets
·
· Score: 1
An educated guess: Probably developers would find that fixing the CPU and memory hogging bug would solve many, many other small issues, and make working with the code much more fun. Educated? Yeah, right.
No other program in Windows or Linux has this problem, apparently. The problem is entirely caused by something in the Mozilla programs. The fact that the problem is largely unchanged for more than 2 years indicates that it was in the code base more than 2 years ago. That's a clue. No, it more likely means that the rate leaks are added is similar to the rate leaks are fixed. I don't think this is good either, but that's not the point.
Use the history file to program the browser to load web pages automatically. If I were trying that, I would write a program to arrange the history file so that it could be used as input to a keyboard imitation program written in AutoIt or AutoHotkey (Windows). Run the test program on a test computer. We have many of them here; Mozilla developers probably do too. Feel free to contribute a program to do that.
Maybe I could head the Mozilla Foundation, at least temporarily. I have the necessary programming and top management experience. I certainly have clear ideas about things that need to be done, and how to do them. I say this, not because I need work, but because I am demonstrating a solution. My guess is that the Mozilla Foundation needs more fund-raising, and some structure that allows resolving big issues like the CPU and memory hogging bug. Thanks for the laugh.
Ok, I read the bug you filed. (I had looked earlier, but it didn't look particularly unique to me so I didn't bother to note who filed it).
In the bug you said: 1. Firefox crashes soon after you open it. No details provided, no sites that cause crashes, no nothing of any use. This part of the comment is about as good as bugs that say, "you suck". 2. Every instance should be separate. You were making a suggestion that was not accepted.... =>WONTFIX or INVALID. Your suggestion shows you don't understand why things are the way they are. 3. You make a comment about stack space, without demonstrating that a maximum stack size is in fact the problem. That sounds like a very uninformed remark - I've never heard of any limits due to stack sizes.
4. You lost all windows, each window with 5 tabs while downloading "a" file. You didn't bother to say what file from where, but did mention that you were doing very important work (I'm sure humanity is worse off as a result). 5. You also complain about large memory usage. Are you not aware that you're supposed to address ONE issue per bug? Bugs with multiple problems in them make tracking very difficult and they get closed. Comment 9 points out that you're talking about a lot of separate things, and later comments from people who understand how to help developers also mention the one-problem-per-bug rule. 6. You said memory usage, when large, grows when tabs are closed. To me, that implies you're looking at the wrong column in Task Manager.
I'd like to point out that you made your complaints a long time ago - a lot of code has changed since then. Maybe some of your issues are fixed now. I personally use dozens+ tabs in multiple windows. Some of the SeaMonkey project leads don't use tabs at all and do not experience trouble with lots of windows, while another uses up to hundreds of tabs at once, and doens't experience your problems.
7. You go on to speculate about things you know nothing about (e.g. event handling). Your speculation (which is sometimes obviously way off, and in other cases I don't know enough to tell) is useless to everybody. 8. You mention OS instability following Firefox crashes. That's an indicator you have other problems - bad drivers, bad hardware, etc. If you do have other problems, debugging your Firefox would be a hopeless task. You tried different machines - maybe you also install some other program or driver on those machines and
Slashdot Mirror
You get power dissipation in each gate or buffer that changes state because of some signal, irregardless of the direction in which the information is flowing. You can not recycle this power. This comes directly from the basic principle behind CMOS technology (used by almost all digital chips today) - you are charging and discharging a capacitor.
You're half right. You're right that what's going on is a charging and discharging of a cap, but you're wrong that the charge can't be recycled. A conventional clock works by connecting the gates of a bunch of devices (i.e. capacitance) to Vdd, then after a little time connecting it to ground instead. Wait a little bit, then repeat. What effectively happens is that you dump some amount of charge from Vdd to ground each switch, and it's gone (i.e. it's heat now). A water analogy would be a tub of water above you (Vdd), a bucket in your hand (the capacitance), and the ground (gnd). You pour some water from the tub into your bucket (charge the cap), then dump it on the ground.
It doesn't have to be this way. There are actually ways to charge a capacitor, and then pull the charge back out again (without dumping it to ground)! I'm going to assume you're familiar with LRC circuts, and how they can resonant when an impulse is applied. What's going on during the oscilattions? Charge is moving into the capacitor, and then being pulled back out to the inductor. The same charge goes back and forth, ideally forever (of course, in practice, the resistance isn't 0 so you put out some heat and the oscillations dies down). I'm not sure what exactly the water analogy would be - maybe a wave sloshing back and forth in a trough.
I recently attended a seminar where the presenter talked about clocking based on LRC oscillations and he had actually fabbed chips that worked. The basic idea was to put an inductor on the die, and set up oscillations between the inductor and the clock load capacitance, which results in a ticking clock. Of course, you get a sinusoidal clock instead of a nice almost-square-wave, so your circuits have to be designed a little bit differently, but the point is, it works and is doable.
Now, the technology described in this article, as best as I can tell, uses another idea - transmission lines. In a normal design, your clock grid basically looks like a bunch of capacitors with resistors in between (i.e. distributed RC). It takes time for a signal to propagate - signals propagate much slower than the speed of light, becuase you actually have to charge up the capacitance along the line through the resistance of the line itself. Imagine a long trough that's empty. You start pouring water in, and although water reaches the far side pretty quickly, you don't actually observe it until the water level at the far end is half way up. Signals propagate differently when wires are set up as transmission lines - they propagate at much closer to the speed of light, because you're actually sending a wave down the line (imagine creating a ripple on a trough of water, instead of actually filling and emptying the trough).
Now, I don't understand how they combined charge recycling and transmission lines, I don't understand transmission lines all that well, but your arguments aren't good reasons to disregard the claims made by the company.
If you're interested, here is a little bit of info about the talk I went to.
Typical example, that running signals in a circuit does not save power: take a ring oscillator (a number of negators wired in a loop). This circuit will oscillate (send changing signals through its loop) and consume an considerable amount of power.
If you created an oscillator between an inductor and a capacitor, on the other hand, once you started it going, it would continue for a long time with minimal energy injected in the future.
Maybe because the Mozilla Foundation is smart enough not to take big risks with security releases? They got a lot of heat with 1.0.x from distributors, since they included more fixes than just the security fixes and major stability fixes, so now the 0.0.0.1 increments will only fix very very low risk (or very high-impact) issues in security releases.
It might seem like a fix is simple, but when you have a really large codebase and millions of web pages doing strange things, it's very easy for a "simple fix" to significantly change rendering results. Sure, in this case you personally would like the change, but imagine if you had a corporate intranet which for some reason depended on that specific alignment being unsupported. You distribute the security update, and suddenly it looks wrong. You'd be flaming the Mozilla Foundation for changing non-critical things in a minor point release.
That's why old branches are supported (i.e. Firefox 1.0.x) long after a new release is available - people don't want to have to worry about non-critical changes breaking things for point releases.
Actually, MFSA issues 09-19 were fixed before this release - the only new ones for the 1.5.x branch are 20-29.
How is this better than AMD's 50x15 program and the PIC?
The Inquirer is generally regarded as a somewhat-reliable rumor mill that publishes a lot of tech secrets from leaked documents, plus general industry news.
The people who attempt to argue against evolution never use the scientific method, and produce untestable hypotheses (e.g. "the flying spaghetti monster created the universe"). Why should other scientists NOT ostracize people who claim to be scientists but have demonstrated that, for issues that are important to them, they won't actually use science?
I actually put together this earlier this month to show someone that even in a simulation environment, with every node starting at the same voltage (which should be a "stable" state, as long as it's not disturbed by outside influences), the floating point inaccuracies in the simulator are sufficient for oscillation to start spontaneously.
They should make the API details public, so that you can replace the mshtml code with an html rendering engine of your choice, such as gecko or khtml
It is, and you can (with Gecko, at least).
It's already easy to embed things into a single file with Gecko-based browsers (e.g. SeaMonkey, Firefox, etc) - all you'd have to do is grab the data that makes up the various files in the page (images, swfs, etc) and use "data:" URLs. For an example of a page that already embeds some images directly into the HTML, view this page with a Gecko-based browser. If you look at the source, you'll see some images inlined right into the HTML. I'd imagine it would not be difficult to make an extension that does what Unipage is currently doing. If all the content is hosted on the same domain, you could probably do it almost trivially in the page itself with some XMLHttpRequests to fetch the contents of images and other objects and inline them into document.innerHTML before saving it to a file.
While some Mozilla developers may suggest otherwise, I doubt there is much that can be done to deal with such issues. The general architecture and code quality of Mozilla is so bad that fixing such issues would be a massive undertaking.
I've seen you repeatedly make this claim. Can you back it up with some examples? Perhaps a link to LXR showing some bad code?
It's definitely worth reminding people that if you *flawlessly* rendered valid CSS, but also were forgiving and did a "best guess" for broken CSS, you'd fail the Acid2 test.
I'm this guy (copy the URL if /. referrer is blocked).
Are you suggesting we shouldn't bother implementing features just because somebody else came up with it? That's a pretty stupid idea. We find a feature we like, we implement it, even if we're not the first.
Note that the release announcement mentions features added since Mozilla 1.7, since that's what we figured many users would be coming from, so we've actually had a lot of these features in the nightlies for quite a while.
There are a lot of other features too - these are just ones we happened to think were interesting.
Is the "Mozilla Suite" project dead? Is Seamonkey the replacement for the old Mozilla Suite? Will the next version of Netscape be based on Seamonkey 1.0?
"Mozilla Suite" will only get security updates. No more new development. SeaMonkey is a good replacement for the old suite - it's effectively Mozilla 1.8 (SeaMonkey 1.0 alpha was what would have been Mozilla 1.8 beta 5). If Netscape decides to ship annother "Communicator" (rather than just a browser), they would be wise to use SeaMonkey as a base for it.
You don't have to download the whole suite - grab the stub installer (a bit over 200KB), and just the parts you want.
SeaMonkey (don't download the beta just yet - 1.0 is shipping in a matter of hours!)
I love SeaMonkey.
I've got SeaMonkey set to allow persistent cookies from sites on my whitelist, and session cookies only for other sites.
If you add this to your userContent.css, links that have a ping attribute will be green:
a[ping] {
color: green !important;
}
You could also do something like this:
a[ping] {
-moz-opacity: 0.5 !important;
}
a[ping]:hover {
-moz-opacity: 1 !important;
}
so that the links would be transparent until you hover over them
There is no data. There is only XUL.
If you like an integrated suite, be sure to give SeaMonkey a try. It's got pretty much the same features as Thunderbird 1.5, but also includes a browser and more.
He also complains about a hard drive problem related to 130GB. If he's going to compare to a new linux distro, shouldn't he at least have obtained an XP CD with SP1 already on it? My school only provides XP with SP1 (maybe SP2 now?) already on it.
cmd is a lot more powerful than he makes it out to be.
He says Windows gamers need to disable services for performance. He's mistaken - someone on the Anandtech Forums did a comprehensive test of game performance with and without many services and found no actual benefits. The people shutting off services are misinformed tweakers. It already performs great, with the services on.
I suggest you read this paper.
I can't find the English version of http://www.de.tomshardware.com/motherboard/2000022 5/agp-analyse-08.html which compares AGP to 2x and 4x. It's old, but it was interesting.
On the off chance you really would like to help, get on IRC (irc.mozilla.org, read the MOTD for channels), DON'T speculate on things you know nothing about, DON'T think you have more of a clue than the people there, and ask for help tracking down one of the problems you experience. Make sure you're using a nightly build for reasons I've already explained. You might start by giving a specific site or action that reliably crashes you 100% of the time. Be patient too, not all channels are active all the time, and you might even have to come back on a few separate occasions. Keep in mind that some people are in different time zones, and many people may be on vacation.
An educated guess: Probably developers would find that fixing the CPU and memory hogging bug would solve many, many other small issues, and make working with the code much more fun.
Educated? Yeah, right.
No other program in Windows or Linux has this problem, apparently. The problem is entirely caused by something in the Mozilla programs. The fact that the problem is largely unchanged for more than 2 years indicates that it was in the code base more than 2 years ago. That's a clue.
No, it more likely means that the rate leaks are added is similar to the rate leaks are fixed. I don't think this is good either, but that's not the point.
Use the history file to program the browser to load web pages automatically. If I were trying that, I would write a program to arrange the history file so that it could be used as input to a keyboard imitation program written in AutoIt or AutoHotkey (Windows). Run the test program on a test computer. We have many of them here; Mozilla developers probably do too.
Feel free to contribute a program to do that.
Maybe I could head the Mozilla Foundation, at least temporarily. I have the necessary programming and top management experience. I certainly have clear ideas about things that need to be done, and how to do them. I say this, not because I need work, but because I am demonstrating a solution. My guess is that the Mozilla Foundation needs more fund-raising, and some structure that allows resolving big issues like the CPU and memory hogging bug.
Thanks for the laugh.
Ok, I read the bug you filed. (I had looked earlier, but it didn't look particularly unique to me so I didn't bother to note who filed it).
In the bug you said:
1. Firefox crashes soon after you open it. No details provided, no sites that cause crashes, no nothing of any use. This part of the comment is about as good as bugs that say, "you suck".
2. Every instance should be separate. You were making a suggestion that was not accepted.... =>WONTFIX or INVALID. Your suggestion shows you don't understand why things are the way they are.
3. You make a comment about stack space, without demonstrating that a maximum stack size is in fact the problem. That sounds like a very uninformed remark - I've never heard of any limits due to stack sizes.
4. You lost all windows, each window with 5 tabs while downloading "a" file. You didn't bother to say what file from where, but did mention that you were doing very important work (I'm sure humanity is worse off as a result).
5. You also complain about large memory usage. Are you not aware that you're supposed to address ONE issue per bug? Bugs with multiple problems in them make tracking very difficult and they get closed. Comment 9 points out that you're talking about a lot of separate things, and later comments from people who understand how to help developers also mention the one-problem-per-bug rule.
6. You said memory usage, when large, grows when tabs are closed. To me, that implies you're looking at the wrong column in Task Manager.
I'd like to point out that you made your complaints a long time ago - a lot of code has changed since then. Maybe some of your issues are fixed now. I personally use dozens+ tabs in multiple windows. Some of the SeaMonkey project leads don't use tabs at all and do not experience trouble with lots of windows, while another uses up to hundreds of tabs at once, and doens't experience your problems.
7. You go on to speculate about things you know nothing about (e.g. event handling). Your speculation (which is sometimes obviously way off, and in other cases I don't know enough to tell) is useless to everybody.
8. You mention OS instability following Firefox crashes. That's an indicator you have other problems - bad drivers, bad hardware, etc. If you do have other problems, debugging your Firefox would be a hopeless task. You tried different machines - maybe you also install some other program or driver on those machines and