In defense of DNA fingerprinting it is often stated that the databases only store non-coding DNA, so there is no risk that someone might be able to centrally deduce possible health problems and other traits which could negatively affect the individual. How does that argument hold up now?
I'm not sure where the statement you're questioning came from, but my understanding of DNA fingerprint databases is that they don't actually store DNA base-pair sequences at all, but merely a list of the distances between certain marker sequences. Imagine taking a text document, counting the length of each paragraph, and summarising it by saying how many of each length there is. With long enough documents you're unlikely to find exact matches, but the numbers don't tell you anything actually useful about the contents of the file.
You found out what 10% of the brain does (the sensory/motor areas)? The other 90% must not be used for anything. [...] You'd have a good point... except that no serious researcher in neuroscience or genetics has ever claimed either of those things.
Yep. This should be modded up.
For example, the "unused brain" thing has never been reliably attributed to a real scientist. Basically, it was made up by the media.
OTOH, I do believe that many geneticists did originally believe that the so-called junk DNA served no useful purpose. See this article, which suggests that at least in the 1970s there was a common belief among geneticists that at least some DNA served no practical purpose other than to replicate itself. It wasn't until about 10 years ago that we started finding actual practical uses for the so-called junk DNA, so presumably that belief persisted at least until then.
It is, however, fair to say that it has never been scienctific consensus that all junk DNA is useless. But saying that no geneticist has claimed it would be foolish, as I'm sure enough digging will turn up at least some such claims: it was until relatively recently a plausible, if extreme, position.
Insulting? More like them keeping their costs down so they can run their business better and provide a better service overall. Think much?
Yes, and there's a reason this kind of behaviour is illegal here in the EU. It's called consumer protection. Here's the scenario: you buy a product from newegg. You discover that the product is badly designed and not something you actually want, but you had no way of finding this until you had the product in your hands (lets say you bought a laptop, and until you saw it were unaware that the spacing of the keys on the keyboard was too small for you to use). Now, newegg will charge you 15% to accept a return of it. Its not defective, its just a badly designed product. You don't want a replacement, because that will do you no good. This is why, here in the EU, you have an absolute right to return (almost) any goods you've bought mail order for a full refund.
Oh, and something else:
Does Newegg.com pay the return shipping cost for defective merchandise?
No, Newegg.com does not pay the return shipping cost for defective merchandise. We are not responsible for product defects, because we do not manufacture the products we carry
Uhuh. They very much *are* responsible for product defects. It's called an implied warranty of merchantability. Unless they have, in big letters, on every product page "NO WARRANTY OF MERCHANTABILITY" or some other similar warning, then there is such a warranty.
And as this is a contract term, if they are in breach of the contract, you can expect them to rectify the situation so you are no worse off than you were before you entered the contract (this is a basic tenet of common law). And if they don't, a court should order them to do so. So, basically, yes they must pay for the return. And if you decide you don't want to continue trading with them, you are probably entitled to return the goods without a restocking fee.
(deep breath)
I take a very dim view of trading with companies that try to mislead people over what their rights are. And I think other people should too, so here it is: newegg try to use their terms and conditions to browbeat consumers into thinking they have to pay to return faulty goods to them. This is immoral behaviour, and should not be tolerated. So here's my suggestion: don't deal with newegg. Don't recommend them to anyone. Don't let anyone you know purchase from them without pointing out how they mislead their customers about their legal rights.
wtf? moving tabs between windows worked even in ff 2.0..
It doesn't actually move the tab, though. What happens is the window containing the current tab sends a message to the window you dropped it in saying, "open a tab at this page with these pages in the history", and then closes its own tab.
What it *should* do is say "open a new tab for this instance of a browser object" and transfer across without needing to do any reloading, etc. This is the way chrome does it, and it is much better.
"the ability to 'drag and drop tabs between browser windows.'"
You can do that now last time I checked...
Just checked it... yep, still has the same problem its always had: it triggers a page reload. Essentially, you're not dragging the tab, you're dragging its current URL and its history. It then reinitialises in the context of the frame you've dropped it in. All the other data structures associated with the tab are destroyed & recreated.
Do it with chrome, and you'll see that the tab is dragged without reloading: all that happens is a reflow & redraw is triggered. The same data structures are used to draw the tab in its new location as were used in the old one.
Whatever the reason people are dropping support and inevitably an unmaintained file system is going to become at best a marginal legacy tool.
Who is dropping support? I haven't seen any mention of this.
Given that it isn't even a default supported Linux fs chances are it will be broken as of kernel X, and then you will be pretty much forced to migrate, so why bother with it?
In linux here's how you format a disk called/dev/sdb, mount it to/storage, and have it automatically mount itself on startup:
[complicated way of doing it snipped]
1. First, if you want to use/dev/sdb, use/dev/sdb. You don't *have* to partition it. 2. There are plenty of tools that simplify this process, if you find it too hard. Most distributions come with a tool that can partition a disk, format it and add the details to/etc/fstab for you.
ZFS-FUSE works fine. If you can build a kernel with an initrd which loads FUSE, ZFS-FUSE and mounts the root filesystem, you have absolutely no troubles whatsoever and absolutely acceptable performance for a MythTV box and a couple of servers. And if you managed to set up MythTV over ReiserFS then this isn't going to be a problem for you at all.
My experience of FUSE (admittedly not with ZFS) is that you lose about 50% of the performance of your disks.
My experience of digital video capture (admittedly not with MythTV) is that it is very demanding of the write performance of your disks (assuming you are capturing uncompressed and then compressing later, which is I believe still the most common way of doing it).
I don't see these two working out, but obviously YMMV. The machine I was running FUSE on was only clocked at 750MHz, so maybe with a modern machine the overhead will be a little less significant.
have been using Reiser 3 for the past 4 years and in practice have never experienced any problems of data corruption!
I used Reiser3 for around 6 or 7 years. Over that time I experienced data corruption twice. On the first occasion, taking the system offline and running 'reiserfsck --rebuild-tree' was able to solve the problem. On the second occasion I attempted the same solution, but it actually did more damage than good. Turns out that the tree rebuild process needs a large quantity of free space. I didn't have enough free space on my disk, so it wiped the tree and left a partially reconstructed one behind that couldn't be mounted, and which nobody had any clue how to fix. I had to wipe the FS and restore from backup.
I restored onto ext3 and have never looked back.
There. Some anecdotal evidence to counter your anecdotal evidence. Next!
You know that support for ReiserFS will disappear (unless you know for a fact that another person/group has stepped up to provide support); why wait until the last possible second, when you'll only have more work to do, to migrate your systems to a new filesystem?
Because there's absolutely no reason to believe that support will disappear. ReiserFS isn't a one-man project that nobody's ever heard of. We're talking about the default filesystem in use by at least one mainstream distribution (SuSE), who have provided significant support for its development in the past. There's no reason to believe that support will dry up, as it would be against SuSE's interests to do so (leaving their customers with difficult issues to solve).
Don't put off to tomorrow that which can be done today.
Why not?
Seriously: even if you accept that there's a 90% chance reiserfs will not be supported in some future kernel version, why change now? All other things being equal, your time now is more valuable than the same amount of time in the future (this is basic economic truth, related to the time value of money and the basic understanding that time is valuable). Your expected expenditure of time in the future is only 90% of what you would spend to change the fs now. So you actually gain by deferring the task.
The same is true in many cases; by deferring a low-value task you can spend your time on a higher-value one instead. Sometimes when you do this the low-value task becomes irrelevant and can be abandoned.
Now, if you expect this migration to become harder in the future, obviously now is the time to do it. But I see no indication that it will become harder, so why do it now?
Being swapped out happens all too often with XP Pro from what I've seen. I can stop using a program for just a couple minutes and it gets swapped out and then I go to use it (Opera) and I have to wait for 200 megs to be swapped back in. It's pathetic and a big time waster. I don't know whether to blame Opera or Windows XP for the behavior. I'd think it would be XP's fault. Anyone have any info on this issue?
Sounds to me like XP's deciding to increase your cache size at the expense of running programs. One thing to check: on My Computer's context menu, select properties / advanced / performance settings / advanced and check that "memory usage" is set to "programs" not "system cache".
Would you please point me to a citation or reference to that...
Because I understood that 32 bit windows would handle a maximum of 2GB, or 3GB if you do some registry / startup tweaking ?
The 2GB (3GB when starting up with/4GT in the kernel command line) limit a per-process limit, not a system wide limit. The same limit also applies to 32-bit processes running on 64-bit windows.
Right. Because the quality of grammar in my hastily-written comments on a web forum should really have the same standard applied as those in the first pages of a published novel.
My fear is that with all the locks needed to maintain sync and the start-stop nature of some forms of I/O, threads will go in and out of wait state so often that the overhead becomes significant
If they're waiting for I/O, then the cost would exist anyway, because the thread would have to wait for I/O to complete anyway (either blocking, giving identical results except that something else would be prevented from running, or using non-blocking I/O, which has quite a bit of overhead in terms of setting up buffers and notifying the user code that the I/O request has finished).
Spending a lot of time releasing/acquiring locks is possible and may result in inefficient execution, but unless the browser is particularly badly designed seems unlikely to me. Avoiding locking is trivial in many cases; in cases where it isn't, it's likely a lock would be necessary anyway (global data structures that may be modified in any of a number of ways), even if only a few threads were in use. In most realistic scenarios locks can usually be acquired on the first attempt. In such a scenario, you're only looking at a few processor cycles and a single memory access per lock/unlock request. On single-processor (including multi-core) systems, that memory access doesn't have to leave cache.
I don't think there's much to worry about here, unless MS have incompetently implemented the threading. Say what you like about MS, they don't hire idiots.
So it's a self-published novel then. Nothing to see here, move on. They're all like this.
If you're after more, my I recommend my dissection of the first few paragraphs of PENITENTIARY PACIFIC ("The action-novel[sic] of the year!!![sic]" - its author), a novel published by PublishAmerica (a company that claims to vet submissions for quality). The following comments are also worth reading.:)
Ok, thread pools and runnable objects might have been better style. 171 threads indicate that software engineering could not agree on a single Grand Central and every team is allowed to spawn as many threads as they want. But hey, threads are cheap - stil way better than Firefox' single process model.
Not sure it really does mean that, though. 128 would be a good limit to set on number of threads in your pool (larger than the largest number of cores you'll ever run on -- windows x86-64 has a limit of 64 cores -- but only by a small factor). Add to that one thread for each major user interface component (windows UI attaches to an owner thread, so you can't pool UI threads) and one or two for each plugin (you can't expect plugin vendors to use your thread pool) and you'll easily hit 171.
More threads to process one thing mean more context switches.
Still likely to be irrelevant in the grand scheme.
Context switching under WinXP takes around 2-3us (measurement was on a 500MHz machine, so may be less on faster machines). With 10ms time slices (accurate for WinXP with 'foreground process boost' switched off... may be longer in other situtions), that means approximately 0.03% of your CPU time is spent on unnecessary and unproductive thread switches, assuming that all your threads run until their time slice is up. If your threads *don't* use all their time slice, that means they're entering a wait state and the context switch is unavoidable.
Yes, yes, I know they have a script debugger today... if you have some form of.NET studio installed.
There's a standalone version of the script debugger available for download. Download here (you'll need a machine that passes "genuine windows" validation to download it... I dunno whether wine can do that?).
Not only that, but I'd like to point out that process isolation comes at a cost.
Agreed, and a total of 17 threads per tab doesn't seem an unreasonable cost for what it gives us: browser tabs and windows that can be managed independently, even when one is stuck in an infinite loop of javascript.
And the memory usage doesn't seem _that_ bad, either. No worse than FF2 was for similar scenarios, in my experience. We've got spoiled by the good memory usage stats of FF3.
And, no, I don't see 300-400MB of browser usage being "the long awaited "killer app" that drives customers towards 4GB+ systems and the 64-bit flavors of Windows Vista/7." First of all, all current 32-bit versions of windows are capable of handling 4GB of RAM perfectly fine. We're talking using less than 10% of that RAM, *while the browser is in heavy use*. Stop using it, and it'll be swapped out. What do you want to do that'll use the other 90% of that RAM at the same time?
And this might be a bit non-traditional, but if I find myself needing more than 4GB, I still don't see myself heading for Vista-x64: Win2K3 is a perfectly acceptable operating system which doesn't lack any features I find myself wanting, is available in OEM editions for less than $100 and supports up to 64GB of RAM in its 32-bit version.
And what's so wrong with spawning a lot of threads? "By greatly increasing the number of concurrent execution threads, and then spreading them out across multiple, discrete processes (in our case, 6 separate instances of iexplore.exe), Microsoft seems to be positioning IE 8 to take advantage of the greatly expanded core counts of future Intel and AMD CPUs - at the cost of overwhelming today's single and dual-core PCs." Not as far as I see no. The cost of a thread is a little memory and a tiny amount of overhead in switching. And neither does the test data they cite support it: IE8 is using less CPU time than firefox, so clearly those threads aren't that problematic.
"No matter how you slice the data, IE 8 represents a massive expansion of the baseline runtime requirements for Microsoft's Internet Explorer web browser. Meanwhile, the Firefox folks continue to embarrass Microsoft by "doing it better" (including delivering superior performance and overall standards compliance)"
Except, you know, the bit where firefox consumes more CPU time than IE. Or perhaps they meant someting else by "superior performance".
Entire article -- FUD. Pure & simple. Comparing beta software to release, and not even fairly summarising their own results from doing so.
Is the address "www.google.com/chrome" correct? The reason I ask is that I'm seeing this on a google search for "google chrome" right now:
Google Chrome - Download a new browser Google Chrome is a browser that combines a minimal design with sophisticated technology to make the web faster, safer, and easier. gears.google.com/chrome/?hl=en - 7k - 17 hours ago - Cached - Similar pages
Clicking on the link redirects back to google's main page, and the cached copy seems to have been purged, but they're certainly up to something with that address.
When the tab gets closed, it's memory gets returned to the OS pool by hook or by crook.
You don't even have to close the tab -- it says in the comic that they're restarting processes associated with the tabs when you navigate between domains too. This means we should be seeing a _lot_ fewer memory leak issues.
Slashdot Mirror
a lot of my code that's been around for a long time may contain as much as 30% commented out code, not to mention all the stuff in #ifdef blocks.
You know, getting rid of all that stuff is what version control systems are for.
In defense of DNA fingerprinting it is often stated that the databases only store non-coding DNA, so there is no risk that someone might be able to centrally deduce possible health problems and other traits which could negatively affect the individual. How does that argument hold up now?
I'm not sure where the statement you're questioning came from, but my understanding of DNA fingerprint databases is that they don't actually store DNA base-pair sequences at all, but merely a list of the distances between certain marker sequences. Imagine taking a text document, counting the length of each paragraph, and summarising it by saying how many of each length there is. With long enough documents you're unlikely to find exact matches, but the numbers don't tell you anything actually useful about the contents of the file.
You found out what 10% of the brain does (the sensory/motor areas)? The other 90% must not be used for anything. ... except that no serious researcher in neuroscience or genetics has ever claimed either of those things.
[...]
You'd have a good point
Yep. This should be modded up.
For example, the "unused brain" thing has never been reliably attributed to a real scientist. Basically, it was made up by the media.
OTOH, I do believe that many geneticists did originally believe that the so-called junk DNA served no useful purpose. See this article, which suggests that at least in the 1970s there was a common belief among geneticists that at least some DNA served no practical purpose other than to replicate itself. It wasn't until about 10 years ago that we started finding actual practical uses for the so-called junk DNA, so presumably that belief persisted at least until then.
It is, however, fair to say that it has never been scienctific consensus that all junk DNA is useless. But saying that no geneticist has claimed it would be foolish, as I'm sure enough digging will turn up at least some such claims: it was until relatively recently a plausible, if extreme, position.
Sounds like that is likely to change. No mainstream distribution is supporting it at this point as a first line file system AFAIK.
It's still supported (and, I believe, is the default option) for SUSE Enterprise.
None of the others have ever actively promoted it, so this looks very much like a "nothing has changed" situation to me.
Insulting? More like them keeping their costs down so they can run their business better and provide a better service overall. Think much?
Yes, and there's a reason this kind of behaviour is illegal here in the EU. It's called consumer protection. Here's the scenario: you buy a product from newegg. You discover that the product is badly designed and not something you actually want, but you had no way of finding this until you had the product in your hands (lets say you bought a laptop, and until you saw it were unaware that the spacing of the keys on the keyboard was too small for you to use). Now, newegg will charge you 15% to accept a return of it. Its not defective, its just a badly designed product. You don't want a replacement, because that will do you no good. This is why, here in the EU, you have an absolute right to return (almost) any goods you've bought mail order for a full refund.
Oh, and something else:
Does Newegg.com pay the return shipping cost for defective merchandise?
No, Newegg.com does not pay the return shipping cost for defective merchandise. We are not responsible for product defects, because we do not manufacture the products we carry
Uhuh. They very much *are* responsible for product defects. It's called an implied warranty of merchantability. Unless they have, in big letters, on every product page "NO WARRANTY OF MERCHANTABILITY" or some other similar warning, then there is such a warranty.
And as this is a contract term, if they are in breach of the contract, you can expect them to rectify the situation so you are no worse off than you were before you entered the contract (this is a basic tenet of common law). And if they don't, a court should order them to do so. So, basically, yes they must pay for the return. And if you decide you don't want to continue trading with them, you are probably entitled to return the goods without a restocking fee.
(deep breath)
I take a very dim view of trading with companies that try to mislead people over what their rights are. And I think other people should too, so here it is: newegg try to use their terms and conditions to browbeat consumers into thinking they have to pay to return faulty goods to them. This is immoral behaviour, and should not be tolerated. So here's my suggestion: don't deal with newegg. Don't recommend them to anyone. Don't let anyone you know purchase from them without pointing out how they mislead their customers about their legal rights.
wtf? moving tabs between windows worked even in ff 2.0..
It doesn't actually move the tab, though. What happens is the window containing the current tab sends a message to the window you dropped it in saying, "open a tab at this page with these pages in the history", and then closes its own tab.
What it *should* do is say "open a new tab for this instance of a browser object" and transfer across without needing to do any reloading, etc. This is the way chrome does it, and it is much better.
"the ability to 'drag and drop tabs between browser windows.'"
You can do that now last time I checked...
Just checked it... yep, still has the same problem its always had: it triggers a page reload. Essentially, you're not dragging the tab, you're dragging its current URL and its history. It then reinitialises in the context of the frame you've dropped it in. All the other data structures associated with the tab are destroyed & recreated.
Do it with chrome, and you'll see that the tab is dragged without reloading: all that happens is a reflow & redraw is triggered. The same data structures are used to draw the tab in its new location as were used in the old one.
Whatever the reason people are dropping support and inevitably an unmaintained file system is going to become at best a marginal legacy tool.
Who is dropping support? I haven't seen any mention of this.
Given that it isn't even a default supported Linux fs chances are it will be broken as of kernel X, and then you will be pretty much forced to migrate, so why bother with it?
I don't know for certain what you mean by "default supported Linux fs", but up to and including the current kernel version, reiserfs is included in the official kernel distribution.
In linux here's how you format a disk called /dev/sdb, mount it to /storage, and have it automatically mount itself on startup:
[complicated way of doing it snipped]
1. First, if you want to use /dev/sdb, use /dev/sdb. You don't *have* to partition it. /etc/fstab for you.
2. There are plenty of tools that simplify this process, if you find it too hard. Most distributions come with a tool that can partition a disk, format it and add the details to
ZFS-FUSE works fine. If you can build a kernel with an initrd which loads FUSE, ZFS-FUSE and mounts the root filesystem, you have absolutely no troubles whatsoever and absolutely acceptable performance for a MythTV box and a couple of servers. And if you managed to set up MythTV over ReiserFS then this isn't going to be a problem for you at all.
My experience of FUSE (admittedly not with ZFS) is that you lose about 50% of the performance of your disks.
My experience of digital video capture (admittedly not with MythTV) is that it is very demanding of the write performance of your disks (assuming you are capturing uncompressed and then compressing later, which is I believe still the most common way of doing it).
I don't see these two working out, but obviously YMMV. The machine I was running FUSE on was only clocked at 750MHz, so maybe with a modern machine the overhead will be a little less significant.
have been using Reiser 3 for the past 4 years and in practice have never experienced any problems of data corruption!
I used Reiser3 for around 6 or 7 years. Over that time I experienced data corruption twice. On the first occasion, taking the system offline and running 'reiserfsck --rebuild-tree' was able to solve the problem. On the second occasion I attempted the same solution, but it actually did more damage than good. Turns out that the tree rebuild process needs a large quantity of free space. I didn't have enough free space on my disk, so it wiped the tree and left a partially reconstructed one behind that couldn't be mounted, and which nobody had any clue how to fix. I had to wipe the FS and restore from backup.
I restored onto ext3 and have never looked back.
There. Some anecdotal evidence to counter your anecdotal evidence. Next!
You know that support for ReiserFS will disappear (unless you know for a fact that another person/group has stepped up to provide support); why wait until the last possible second, when you'll only have more work to do, to migrate your systems to a new filesystem?
Because there's absolutely no reason to believe that support will disappear. ReiserFS isn't a one-man project that nobody's ever heard of. We're talking about the default filesystem in use by at least one mainstream distribution (SuSE), who have provided significant support for its development in the past. There's no reason to believe that support will dry up, as it would be against SuSE's interests to do so (leaving their customers with difficult issues to solve).
Don't put off to tomorrow that which can be done today.
Why not?
Seriously: even if you accept that there's a 90% chance reiserfs will not be supported in some future kernel version, why change now? All other things being equal, your time now is more valuable than the same amount of time in the future (this is basic economic truth, related to the time value of money and the basic understanding that time is valuable). Your expected expenditure of time in the future is only 90% of what you would spend to change the fs now. So you actually gain by deferring the task.
The same is true in many cases; by deferring a low-value task you can spend your time on a higher-value one instead. Sometimes when you do this the low-value task becomes irrelevant and can be abandoned.
Now, if you expect this migration to become harder in the future, obviously now is the time to do it. But I see no indication that it will become harder, so why do it now?
Being swapped out happens all too often with XP Pro from what I've seen. I can stop using a program for just a couple minutes and it gets swapped out and then I go to use it (Opera) and I have to wait for 200 megs to be swapped back in. It's pathetic and a big time waster. I don't know whether to blame Opera or Windows XP for the behavior. I'd think it would be XP's fault. Anyone have any info on this issue?
Sounds to me like XP's deciding to increase your cache size at the expense of running programs. One thing to check: on My Computer's context menu, select properties / advanced / performance settings / advanced and check that "memory usage" is set to "programs" not "system cache".
Would you please point me to a citation or reference to that ...
Because I understood that 32 bit windows would handle a maximum of 2GB, or 3GB if you do some registry / startup tweaking ?
The 2GB (3GB when starting up with /4GT in the kernel command line) limit a per-process limit, not a system wide limit. The same limit also applies to 32-bit processes running on 64-bit windows.
See: http://msdn.microsoft.com/en-us/library/aa366778.aspx
"Loose one or the other"
Pot ... kettle.
Right. Because the quality of grammar in my hastily-written comments on a web forum should really have the same standard applied as those in the first pages of a published novel.
My fear is that with all the locks needed to maintain sync and the start-stop nature of some forms of I/O, threads will go in and out of wait state so often that the overhead becomes significant
If they're waiting for I/O, then the cost would exist anyway, because the thread would have to wait for I/O to complete anyway (either blocking, giving identical results except that something else would be prevented from running, or using non-blocking I/O, which has quite a bit of overhead in terms of setting up buffers and notifying the user code that the I/O request has finished).
Spending a lot of time releasing/acquiring locks is possible and may result in inefficient execution, but unless the browser is particularly badly designed seems unlikely to me. Avoiding locking is trivial in many cases; in cases where it isn't, it's likely a lock would be necessary anyway (global data structures that may be modified in any of a number of ways), even if only a few threads were in use. In most realistic scenarios locks can usually be acquired on the first attempt. In such a scenario, you're only looking at a few processor cycles and a single memory access per lock/unlock request. On single-processor (including multi-core) systems, that memory access doesn't have to leave cache.
I don't think there's much to worry about here, unless MS have incompetently implemented the threading. Say what you like about MS, they don't hire idiots.
Oh, look. iUniverse.
So it's a self-published novel then. Nothing to see here, move on. They're all like this.
If you're after more, my I recommend my dissection of the first few paragraphs of PENITENTIARY PACIFIC ("The action-novel[sic] of the year!!![sic]" - its author), a novel published by PublishAmerica (a company that claims to vet submissions for quality). The following comments are also worth reading. :)
Is the address "www.google.com/chrome" correct?
Yes, it is. Download's up there now...
Ok, thread pools and runnable objects might have been better style. 171 threads indicate that software engineering could not agree on a single Grand Central and every team is allowed to spawn as many threads as they want. But hey, threads are cheap - stil way better than Firefox' single process model.
Not sure it really does mean that, though. 128 would be a good limit to set on number of threads in your pool (larger than the largest number of cores you'll ever run on -- windows x86-64 has a limit of 64 cores -- but only by a small factor). Add to that one thread for each major user interface component (windows UI attaches to an owner thread, so you can't pool UI threads) and one or two for each plugin (you can't expect plugin vendors to use your thread pool) and you'll easily hit 171.
Even if they're not processing anything, they consume memory (kernel and userspace stack, primarily). The overhead is nonzero.
Yes, but that overhead's already been counted in the memory usage stats. This is like saying, "it uses more memory, and it uses more memory."
More threads to process one thing mean more context switches.
Still likely to be irrelevant in the grand scheme.
Context switching under WinXP takes around 2-3us (measurement was on a 500MHz machine, so may be less on faster machines). With 10ms time slices (accurate for WinXP with 'foreground process boost' switched off... may be longer in other situtions), that means approximately 0.03% of your CPU time is spent on unnecessary and unproductive thread switches, assuming that all your threads run until their time slice is up. If your threads *don't* use all their time slice, that means they're entering a wait state and the context switch is unavoidable.
Yes, yes, I know they have a script debugger today ... if you have some form of .NET studio installed.
There's a standalone version of the script debugger available for download. Download here (you'll need a machine that passes "genuine windows" validation to download it... I dunno whether wine can do that?).
Not only that, but I'd like to point out that process isolation comes at a cost.
Agreed, and a total of 17 threads per tab doesn't seem an unreasonable cost for what it gives us: browser tabs and windows that can be managed independently, even when one is stuck in an infinite loop of javascript.
And the memory usage doesn't seem _that_ bad, either. No worse than FF2 was for similar scenarios, in my experience. We've got spoiled by the good memory usage stats of FF3.
And, no, I don't see 300-400MB of browser usage being "the long awaited "killer app" that drives customers towards 4GB+ systems and the 64-bit flavors of Windows Vista/7." First of all, all current 32-bit versions of windows are capable of handling 4GB of RAM perfectly fine. We're talking using less than 10% of that RAM, *while the browser is in heavy use*. Stop using it, and it'll be swapped out. What do you want to do that'll use the other 90% of that RAM at the same time?
And this might be a bit non-traditional, but if I find myself needing more than 4GB, I still don't see myself heading for Vista-x64: Win2K3 is a perfectly acceptable operating system which doesn't lack any features I find myself wanting, is available in OEM editions for less than $100 and supports up to 64GB of RAM in its 32-bit version.
And what's so wrong with spawning a lot of threads? "By greatly increasing the number of concurrent execution threads, and then spreading them out across multiple, discrete processes (in our case, 6 separate instances of iexplore.exe), Microsoft seems to be positioning IE 8 to take advantage of the greatly expanded core counts of future Intel and AMD CPUs - at the cost of overwhelming today's single and dual-core PCs." Not as far as I see no. The cost of a thread is a little memory and a tiny amount of overhead in switching. And neither does the test data they cite support it: IE8 is using less CPU time than firefox, so clearly those threads aren't that problematic.
"No matter how you slice the data, IE 8 represents a massive expansion of the baseline runtime requirements for Microsoft's Internet Explorer web browser. Meanwhile, the Firefox folks continue to embarrass Microsoft by "doing it better" (including delivering superior performance and overall standards compliance)"
Except, you know, the bit where firefox consumes more CPU time than IE. Or perhaps they meant someting else by "superior performance".
Entire article -- FUD. Pure & simple. Comparing beta software to release, and not even fairly summarising their own results from doing so.
Is the address "www.google.com/chrome" correct? The reason I ask is that I'm seeing this on a google search for "google chrome" right now:
Google Chrome - Download a new browser
Google Chrome is a browser that combines a minimal design with sophisticated technology to make the web faster, safer, and easier.
gears.google.com/chrome/?hl=en - 7k - 17 hours ago - Cached - Similar pages
Clicking on the link redirects back to google's main page, and the cached copy seems to have been purged, but they're certainly up to something with that address.
When the tab gets closed, it's memory gets returned to the OS pool by hook or by crook.
You don't even have to close the tab -- it says in the comic that they're restarting processes associated with the tabs when you navigate between domains too. This means we should be seeing a _lot_ fewer memory leak issues.