I wish... Linux supported a base system for ten years.
Linux isn't a person or organization and thus can't support anything.
The best organization I know of (in terms of length of support for a given Linux configuration) is Red Hat, which supports RHEL for seven years. Still not as good as Microsoft's ten year policy.
Microsoft will support you even longer, if you pay for a custom support agreement. I'm told prices start around $40K.
I suppose, for that price, you could pay someone to maintain your Linux configuration for you. You do have the source code. But you'd have to start doing it sooner.
$1.20 says they'll continue releasing critical updates as they've done for a while for "retired" service packs in the past.
Can you cite specific examples? In my experience, support for Microsoft products starts to be curtailed near end-of-life, not extended past it. NT4, 2000, XP have all had security vulnerabilities discovered which Microsoft did not fix, but which were fixed for later releases of Windows. MS09-048 for 2000/XP. Another I can't recall right now for NT4. Yah, they had their reasons, but the fact remains that once the successor products arrive, support starts to degrade for the old releases.
For example, our standard apps maintain state persistence by simply writing out one or more C structures to a temp file on disk.
Of course, the C standard explicitly states that the layout in memory of structures is implementation-dependent, so doing things like that sets yourself up for serious pain when you do things like change compiler versions, optimization options, or run on different platforms.
In my experience, a lot of programs run without crashing only through sheer luck.
"I was under the impression that that these process-per-page browser implementations keep such related pages in the same process space, for the same reason (breaks JavaScript/DHTML/etc)."
Nope. The code for the browser is under the control of the browser team, so they can adapt/rewrite things as needed for a multi-process model. They have no control over plugin code, so they can't do that.
FWIW, the commonly-cited reason for Mozilla Firefox still using a single process for all pages is that it's a lot of work to adapt all the existing code for a multi-process model. They're not there yet.
(Process == heavyweight or lightweight (thread) in the above.)
When I first read the article title, my first reaction was to echo a Jon Stewart/Daily Show quote: "This study was published this month in The American Journal of Shit We Already Knew."
"Is it within the realm of possibility that some nobody might be allowed to die so that his organs can be harvested for a prominent somebody?"
Why stop with prominent somebodies? In "The Jigsaw Man" (spoiler warning on the link), Larry Niven has an interesting take on the potential for unexpected side-effects in a system where organ transplant is perfected but organ supply remains scarce.
Ah.... at last, light dawns in the forest. I'm not sure why I couldn't get my head wrapped around the idea of multiple, opposing, angled vents yielding a net lateral force of zero, but it took your explanation to get it through to me. Thanks for taking the time to explain all that!
But you said "...parts of the SRBs on STS-51-L (the one that killed Challenger) survived the initial explosion...".
Okay, yes, I did write that. I should have written "deflagration and break-up". I'll apologize to the Pedantic Semantics Council.;-)
And robustness of solid rockets is probably slightly deceiving - yes, as a functional block they are tough (they need to be)
You've remarked twice now that solid rockets are robust because they need to be robust to work at all. I fail to see how that's a bad thing by itself. Yes, it's an inherent requirement of the design, but it still means a tougher vehicle. Now, you could argue that the need for a more robust vehicle increases weight/cost/etc., but I don't get why you seem to be implying robustness doesn't count just because it's inherent.
... not a lot of commercial launchers rely on solids to such a large degree as the advantages would suggest...
Again, I was never arguing that SRBs are an overall design win. I think I made it quite clear in my initial post that both technologies have advantages and disadvantages, and that liquids are prolly the overall design win.
DragonHawk: "I haven't been able to find any information on just how practical thrust venting really is."
DerekLyons: "You time your separation..."
DragonHawk: "If the rocket is already in the air and we can afford to jettison the booster, why would we care about equalizing thrust? If we can do a separation, we do it, and now the booster can do whatever the heck it wants to -- splash down into the ocean, explode into a million tiny pieces, etc. No?"
DerekLyons: "Sometimes. But the question was again, was it possible, not was it desirable.
Um, no, my question was whether it was practical. Not as a theoretical possibility, but, would this be useful in the real world?
DerekLyons: "... in a 'normal' (for lack of a better term) thrust venting situation the plume is being sent up and to the side, so your departing module catches only the very edges of that half the thrust."
(Emphasis added.)
As it's been explained to me, thrust venting works by opening both ends of the rocket. Since the thrust is now exiting equally from top and bottom, they cancel each other out. Given that, I would think that if you instead tried to direct the vented thrust to the side, that would not cancel out the "normal" exhaust. The rocket would instead veer sharply to one side. In the case of an outrigger (like STS), that would be directly into the main vehicle. In the case of a single rocket stack, it would still leave the normal exhaust pushing the solid rocket into the next stage. Am I missing something here?
I might buy the idea that venting an outrigger straight out the top would be a practical way to abort a launch. For example, suppose for the sake of discussion one of the STS SRBs ignites accidentally. In that hypothetical situation, you blow the top of that SRB, the thrust equalizes, net impulse zero. The LV sits on the pad in a cloud of smoke and flame for a minute or so, but otherwise is okay.
But in the case of a solid rocket in-line with another stage (such as the Ares design), you can't do that, because there are more stages and/or payload and/or crew above the solid rocket. No?
And once the vehicle is in flight, if you can afford to jettison the solid rocket, I don't see the point in bothering with thrust venting. You don't need the solid so you don't care what happens to it. If you did care what happens to it, thrust venting would prolly be a bad idea anyway, because once you cancel thrust, gravity takes over, and that generally ends badly for a rocket.
The one hypothetical situation I can think of for in-flight thrust venting being useful would be if you want to both recovery the spent solid and you *also* want to limit how far down range you have to go to retrieve it. But that seems like a big stretch. Even the STS SRBs end up within a hundred miles or so of Florida.
Most of your points are irrelevant if I happen to be using two browsers. Things aren't broken if I do that today, so what's special about working with one browser?
The key point you're missing is that some websites open multiple pages, instantiating multiple Flash objects. This is commonly done with popup windows, for example. Flash also has mechanisms for allowing different servers/sites/pages to share data and communicate with each other. Those things all work together, as a group. Such things will always be opened in the same browser, because they're opened by Flash, not by you clicking the Internet Explorer icon. Since historically, all plugins ran in the same process, the design of Flash assumes all the objects instantiated across all those pages will be able to communication within the same process. If you isolated each page's Flash objects in its own process, then all of that would break.
There's a very good chance you use web systems like this now, but just don't realize the systems would stop working if every Flash object within your browser was isolated.
"My apologies... I thought you were arguing for processes over threads."
Yah, I can see where you got that from, now. No need to apologize; my fault for being confusing.
"parent was comparing threads vs processes (saying threads were better because processes are more heavyweight)"
At this point, I'm not sure *what* BhaKi was saying in #32661562. My original take was "tabs don't and shouldn't run in separate processes" meant any attempt at multi-tasking browser stuff should be avoided. But I see what you mean; they might have been arguing in favor of threads over more heavyweight processes. The whole tab=thread/window=process assertion threw me.
"What makes you think that threads aren't exposed to the OS?
Um. I don't think that at all.
"letting the OS know" is most definitely not an argument to not use threads."
I wasn't trying to argue that. Indeed, I think it would be great if Firefox used a different process/thread for each page. I'm arguing *for* that.:)
We may be confused over terminology. When I say "multi-tasking", I am including both heavyweight processes and lightweight processes (threads). Also, I was looking at this from a somewhat Linux-centric point of view. On Linux, heavyweight processes and lightweight processes are very similar. They both use the same structures and system calls; it's just a question of what context they share. So the thread/process distinction is less critical than it is on OSes where a "thread" and a "process" are very different entities.
FF violates what I said above and actually is using userland threads in a pretty dumb way (unlikely)
On Linux, at least, Firefox uses multiple OS threads, but the bulk of the work appears to be done in a single thread. If multiple pages are busy, you don't see other threads picking up the load; you just see that one thread doing more work. I presume the other threads are helper/utility things, such as network I/O or name lookup.
"In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance."
"While reading Slashdot, it doesn't make one bit of difference. While one story tab loads, the rest of Firefox FREEZES while slashdot struggles to get rendered. I can't even scroll up or down."
That's because Firefox uses a single thread for just about everything. If a page is slow to render because of complex HTML/CSS, or has bad JavaScript which eats up CPU time, that drags everything to a stand-still.
Browsers that use a separate process/thread per page, on other hand, will keep everything else running. That one page will be slow/non-responsive, but everything else keeps humming along nicely (as long as the hardware can keep up). Google Chrome works this way. Firefox does not (yet).
(Firefox does spawn multiple threads, but the bulk of the work appears to be done in one thread. I presume the others are support/helper threads.)
I usually break into multiple Firefox windows when I start having multiple disparate browsing sessions take place
I used to do that, before I got TST. And I still do it sometimes -- especially if I've got different things happening on different virtual desktops. But I find the ability to expand and collapse tab branches is more flexible and more useful than static windows.
I actually suspect the tree-style-tab concept would be a good idea for a general purpose window manager, i.e., for all windows on a system, not just the browser. Might be tricky to figure out a general solution, though.
The other thing I've really liked using is Session Manager
I use and like Session Manager as well. TreeStyleTab and Session Manager play nice together; the TST tab structure is properly restored by SM.
For performance reasons, tabs don't and shouldn't run in separate processes.
I find that statement dubious. Please explain.
In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance. I believe there are multiple reasons for this. For starters, the OS already has a perfectly good scheduler, and it makes sense to use that to handle multi-tasking. Indeed, OS people prolly know more about how to design a scheduler than browser people. By exposing the this to the OS, it also means the OS can do whatever tricks it has to make I/O, memory allocation, etc., more efficient on a per-page basis, rather than treating the whole browser as an opaque object.
Finally, lot of modern hardware has 2, 3, 4 or more processor cores. Firefox generally only uses one of them. A browser like Chrome can have each page render on its own processor core, which is a *huge* performance gain. Without that, any multitasking is going to be limited to slicing up a single core between multiple tasks. The system can still only do one thing at a time. By using multiple cores, the system actually gets multiple things done literally simultaneously. On good hardware, the performance difference is astounding.
"You know, the original motivation for the tabs feature was that each tab could be run in a separate thread whereas each window needs a separate process."
That's just plain wrong. Each window does not need a separate process. Each tab does not get a separate thread. In Firefox 3.6, multiple threads are used, but it's not a one-thread-per-tab thing. Most of the work is still done in a single monolithic thread.
The motivation for tabs in Firefox was to copy Opera. The motivation for tabs in Opera was as an alternative to one-page-per-window or MDI.
I routinely open that many tabs. But then, I work in a dynamic environment where I'm often being asked to do a dozen things at once, including several open-ended research projects, plus a handful of web-based apps, plus casual browsing, reading news, etc. And Slashdot, of course.
I'll put in a plug for my favorite extension here: TreeStyleTab. Rather than limiting tabs to a linear strip, this gives it a 2D structure. When I surf, inevitably one thing leads to another thing, which leads to a site which leads to six more things. So I middle-click almost every link, and it all gets organized into a hierarchical history. It helps me organize my thinking when I'm researching something, especially when I don't know exactly what I'm looking for.
It's got a million options. You can configure it for all sorts of things. You can even have it put a 2D tab strip across the top of the window, if you like that.
The lack of a working TreeStyleTab clone on Chrome meant I went back to Firefox. Everything else was great, but I can no longer do serious web browsing without TST, and so that killed Chrome for me. Yes, it's that important.
TreeStyleTab: Don't leave your home page without it.
"It looks like there is a single process plugin-container.exe to run all flash files. Killing this exe will stop playing all the flash files."
FWIW, Google Chrome works the same way.
I'm not sure, but I suspect this *may* be due to design of the whole plugin concept. I would guess that the plugin concept assumes a single monolithic process for everything. There would be no need for an IPC facility. So I would guess Flash doesn't expect to find different windows running in a different process space. I know I've seen Flash objects communicate between each other; I presume that's done inside the plugin. If I'm right with my guess, using a different processes for each plugin object instance would be a giant compatibility problem.
I'll take this opportunity to post some non-inflammatory info on planned Firefox development.
Firefox 4.0, which may go into beta as early as next month, is supposed to do a lot in this direction. Overhauled JavaScript engine, overhauled HTML rendering, etc.
I thought I had heard that 4.0 was supposed to deliver one-process-per-page functionality, but I'm having trouble finding recent status info. (One drawback to high-speed FOSS development is it's hard to keep track of things like that.) But anyway, the project is named "Electrolysis" ("E10S" in Firefox-developer-speak).
"Contrary to popular belief, Challenger was actually mostly broken up by aerodynamic forces..."
I never stated otherwise. What does that have to do with what I was talking about? As I stated, the point was the robustness of solid rockets, not the STS as a whole.
And, no offense, but the third sentence (with parenthetical) in your first paragraph is so incoherent I can't figure out what point you might be trying to make.
"(liquid rocket is in comparison virtualy inert most of the time)."
Hmmm, that's a good point. I wonder if the gentleman I was talking to was considering that.
Certainly the PEPCON disaster showed that while solid rocket fuel might be relatively safe compared to liquid fuels, it's not inert by any stretch of the imagination.
"Plus it's certainly not a coincidence that our orbital rockets rely mostly on liquid propellants... higher specific impulse is good to have after all, for starters."
Well, for starters, using a conventional solid rocket for orbital insertion and maneuvering would be close to impossible, since you don't have the control needed. So I'm not sure what you hope to prove with that.:)
Beyond that, I'm told that during the boost phase, when you're trying to climb out of the gravity well, you want a higher thrust-to-weight ratio, which solids are good at. During the second phase, when you're trying to accelerate downrange to orbital velocity, efficiency matters more, and liquids are a win there.
"failure of the seal as on Challenger is one of the more common modes of failure for solid rockets"
And is normally not a huge concern, since the rocket is robust enough to survive it. The problems happen when you put something vulnerable next to the solids. When it's vulnerable and explosive, it's a recipe for disaster. Again, not arguing the overall design of STS.
I'm also not arguing solid rockets are an overall design win. All I'm saying is that they are a simple, robust technology.
"Hybrid rocket engines seem to be interesting..."
Yah, new concept to me, which I'm just reading up on now. Interesting, indeed.
You time your separation to avoid the plume and recontact between the booster and the separating module.
If the rocket is already in the air and we can afford to jettison the booster, why would we care about equalizing thrust? If we can do a separation, we do it, and now the booster can do whatever the heck it wants to -- splash down into the ocean, explode into a million tiny pieces, etc. No?
And really the plume is less than you might think, when the pressure in the booster drops, so does the combustion rate.
I imagine that would take a few seconds, though. Challenger's ET blew apart quickly enough from contact with a relatively tiny plume. I imagine half the total trust from an SRB would be pretty dangerous, even if it's nominally directed up and not sideways.
And if the crew capsule is directly on top the solid rocket...
"From a safety POV, they amount to the same thing."
Me, I see a big safety difference between a giant geyser of flame spewing out of each end, and a full shutdown (like Gemini 6).
Also, I haven't been able to find any information on just how practical thrust venting really is. (Which is not to say such information doesn't exist, just that I don't have it.) There's going to be a payload/crew module -- either on top of the rocket, or right next to it, in the case of an outrigger booster. I imagine the thrust being vented would be quite hazardous. So how does that work?
Last time I got in a discussion on this subject on Slashdot, nobody had any references, it was all just supposition. Your links, especially the second, are much more solid (pun unintended).
This issue gets more and more complicated the more I look at it.
"I already did! Read the link. The SRBs are more expensive per flight."
Ah, sorry. I ass-umed that since your statement on solid fuel costs came after the link, it was an independent point. Thanks for the correction.
"They never got anywhere near $160/lb. - not at over $10,000/kg."
Like I said, I wasn't defending the cost efficiency of STS, or even just the SRBs. The shuttle program is notorious for its high costs and budget overruns. I had just been lead to believe that solid rockets were cheaper in general. Your reference obviously contradicts that.
I wish your reference got into more detail as to why the solid booster option was expected to be more expensive to operate (post-development). I'm working on very meager information already, and this just complicates things.:-(
DragonHawk: "...once lit they will consume their entire fuel supply. No stop-and-restart."
DerekLyons: "Actually, while you can't restart 'em - you can shut them down."
Interesting. Mind explaining how, or at least giving me a term to Google?
(If you're talking about thrust venting, I'm aware. But they still consume their entire fuel supply. Thrust venting simply cancels out the thrust; the fuel still burns to completion.)
Slashdot Mirror
I wish ... Linux supported a base system for ten years.
Linux isn't a person or organization and thus can't support anything.
The best organization I know of (in terms of length of support for a given Linux configuration) is Red Hat, which supports RHEL for seven years. Still not as good as Microsoft's ten year policy.
Microsoft will support you even longer, if you pay for a custom support agreement. I'm told prices start around $40K.
I suppose, for that price, you could pay someone to maintain your Linux configuration for you. You do have the source code. But you'd have to start doing it sooner.
$1.20 says they'll continue releasing critical updates as they've done for a while for "retired" service packs in the past.
Can you cite specific examples? In my experience, support for Microsoft products starts to be curtailed near end-of-life, not extended past it. NT4, 2000, XP have all had security vulnerabilities discovered which Microsoft did not fix, but which were fixed for later releases of Windows. MS09-048 for 2000/XP. Another I can't recall right now for NT4. Yah, they had their reasons, but the fact remains that once the successor products arrive, support starts to degrade for the old releases.
My thoughts on the SCO fuster cluck at this point:
"If they blew him up, put his head in a blender, and mailed the rest of the pieces to Norway, he'd still return from the grave."
References
Sugar for pointers.
And C is sugar for assembler, which is sugar for writing machine code directly using a hex editor.
The whole point of any language feature is to make it easier to use machine features. Calling them "sugar" doesn't negate that.
For example, our standard apps maintain state persistence by simply writing out one or more C structures to a temp file on disk.
Of course, the C standard explicitly states that the layout in memory of structures is implementation-dependent, so doing things like that sets yourself up for serious pain when you do things like change compiler versions, optimization options, or run on different platforms.
In my experience, a lot of programs run without crashing only through sheer luck.
"I was under the impression that that these process-per-page browser implementations keep such related pages in the same process space, for the same reason (breaks JavaScript/DHTML/etc)."
Nope. The code for the browser is under the control of the browser team, so they can adapt/rewrite things as needed for a multi-process model. They have no control over plugin code, so they can't do that.
FWIW, the commonly-cited reason for Mozilla Firefox still using a single process for all pages is that it's a lot of work to adapt all the existing code for a multi-process model. They're not there yet.
(Process == heavyweight or lightweight (thread) in the above.)
When I first read the article title, my first reaction was to echo a Jon Stewart/Daily Show quote: "This study was published this month in The American Journal of Shit We Already Knew."
"Is it within the realm of possibility that some nobody might be allowed to die so that his organs can be harvested for a prominent somebody?"
Why stop with prominent somebodies? In "The Jigsaw Man" (spoiler warning on the link), Larry Niven has an interesting take on the potential for unexpected side-effects in a system where organ transplant is perfected but organ supply remains scarce.
Ah.... at last, light dawns in the forest. I'm not sure why I couldn't get my head wrapped around the idea of multiple, opposing, angled vents yielding a net lateral force of zero, but it took your explanation to get it through to me. Thanks for taking the time to explain all that!
But you said "...parts of the SRBs on STS-51-L (the one that killed Challenger) survived the initial explosion...".
Okay, yes, I did write that. I should have written "deflagration and break-up". I'll apologize to the Pedantic Semantics Council. ;-)
And robustness of solid rockets is probably slightly deceiving - yes, as a functional block they are tough (they need to be)
You've remarked twice now that solid rockets are robust because they need to be robust to work at all. I fail to see how that's a bad thing by itself. Yes, it's an inherent requirement of the design, but it still means a tougher vehicle. Now, you could argue that the need for a more robust vehicle increases weight/cost/etc., but I don't get why you seem to be implying robustness doesn't count just because it's inherent.
... not a lot of commercial launchers rely on solids to such a large degree as the advantages would suggest...
Again, I was never arguing that SRBs are an overall design win. I think I made it quite clear in my initial post that both technologies have advantages and disadvantages, and that liquids are prolly the overall design win.
DragonHawk: "I haven't been able to find any information on just how practical thrust venting really is."
DerekLyons: "You time your separation ..."
DragonHawk: "If the rocket is already in the air and we can afford to jettison the booster, why would we care about equalizing thrust? If we can do a separation, we do it, and now the booster can do whatever the heck it wants to -- splash down into the ocean, explode into a million tiny pieces, etc. No?"
DerekLyons: "Sometimes. But the question was again, was it possible, not was it desirable.
Um, no, my question was whether it was practical. Not as a theoretical possibility, but, would this be useful in the real world?
DerekLyons: "... in a 'normal' (for lack of a better term) thrust venting situation the plume is being sent up and to the side , so your departing module catches only the very edges of that half the thrust."
(Emphasis added.)
As it's been explained to me, thrust venting works by opening both ends of the rocket. Since the thrust is now exiting equally from top and bottom, they cancel each other out. Given that, I would think that if you instead tried to direct the vented thrust to the side, that would not cancel out the "normal" exhaust. The rocket would instead veer sharply to one side. In the case of an outrigger (like STS), that would be directly into the main vehicle. In the case of a single rocket stack, it would still leave the normal exhaust pushing the solid rocket into the next stage. Am I missing something here?
I might buy the idea that venting an outrigger straight out the top would be a practical way to abort a launch. For example, suppose for the sake of discussion one of the STS SRBs ignites accidentally. In that hypothetical situation, you blow the top of that SRB, the thrust equalizes, net impulse zero. The LV sits on the pad in a cloud of smoke and flame for a minute or so, but otherwise is okay.
But in the case of a solid rocket in-line with another stage (such as the Ares design), you can't do that, because there are more stages and/or payload and/or crew above the solid rocket. No?
And once the vehicle is in flight, if you can afford to jettison the solid rocket, I don't see the point in bothering with thrust venting. You don't need the solid so you don't care what happens to it. If you did care what happens to it, thrust venting would prolly be a bad idea anyway, because once you cancel thrust, gravity takes over, and that generally ends badly for a rocket.
The one hypothetical situation I can think of for in-flight thrust venting being useful would be if you want to both recovery the spent solid and you *also* want to limit how far down range you have to go to retrieve it. But that seems like a big stretch. Even the STS SRBs end up within a hundred miles or so of Florida.
Most of your points are irrelevant if I happen to be using two browsers. Things aren't broken if I do that today, so what's special about working with one browser?
The key point you're missing is that some websites open multiple pages, instantiating multiple Flash objects. This is commonly done with popup windows, for example. Flash also has mechanisms for allowing different servers/sites/pages to share data and communicate with each other. Those things all work together, as a group. Such things will always be opened in the same browser, because they're opened by Flash, not by you clicking the Internet Explorer icon. Since historically, all plugins ran in the same process, the design of Flash assumes all the objects instantiated across all those pages will be able to communication within the same process. If you isolated each page's Flash objects in its own process, then all of that would break.
There's a very good chance you use web systems like this now, but just don't realize the systems would stop working if every Flash object within your browser was isolated.
"My apologies ... I thought you were arguing for processes over threads."
Yah, I can see where you got that from, now. No need to apologize; my fault for being confusing.
"parent was comparing threads vs processes (saying threads were better because processes are more heavyweight)"
At this point, I'm not sure *what* BhaKi was saying in #32661562. My original take was "tabs don't and shouldn't run in separate processes" meant any attempt at multi-tasking browser stuff should be avoided. But I see what you mean; they might have been arguing in favor of threads over more heavyweight processes. The whole tab=thread/window=process assertion threw me.
"What makes you think that threads aren't exposed to the OS?
Um. I don't think that at all.
"letting the OS know" is most definitely not an argument to not use threads."
I wasn't trying to argue that. Indeed, I think it would be great if Firefox used a different process/thread for each page. I'm arguing *for* that. :)
We may be confused over terminology. When I say "multi-tasking", I am including both heavyweight processes and lightweight processes (threads). Also, I was looking at this from a somewhat Linux-centric point of view. On Linux, heavyweight processes and lightweight processes are very similar. They both use the same structures and system calls; it's just a question of what context they share. So the thread/process distinction is less critical than it is on OSes where a "thread" and a "process" are very different entities.
FF violates what I said above and actually is using userland threads in a pretty dumb way (unlikely)
On Linux, at least, Firefox uses multiple OS threads, but the bulk of the work appears to be done in a single thread. If multiple pages are busy, you don't see other threads picking up the load; you just see that one thread doing more work. I presume the other threads are helper/utility things, such as network I/O or name lookup.
"In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance."
"While reading Slashdot, it doesn't make one bit of difference. While one story tab loads, the rest of Firefox FREEZES while slashdot struggles to get rendered. I can't even scroll up or down."
That's because Firefox uses a single thread for just about everything. If a page is slow to render because of complex HTML/CSS, or has bad JavaScript which eats up CPU time, that drags everything to a stand-still.
Browsers that use a separate process/thread per page, on other hand, will keep everything else running. That one page will be slow/non-responsive, but everything else keeps humming along nicely (as long as the hardware can keep up). Google Chrome works this way. Firefox does not (yet).
(Firefox does spawn multiple threads, but the bulk of the work appears to be done in one thread. I presume the others are support/helper threads.)
I usually break into multiple Firefox windows when I start having multiple disparate browsing sessions take place
I used to do that, before I got TST. And I still do it sometimes -- especially if I've got different things happening on different virtual desktops. But I find the ability to expand and collapse tab branches is more flexible and more useful than static windows.
I actually suspect the tree-style-tab concept would be a good idea for a general purpose window manager, i.e., for all windows on a system, not just the browser. Might be tricky to figure out a general solution, though.
The other thing I've really liked using is Session Manager
I use and like Session Manager as well. TreeStyleTab and Session Manager play nice together; the TST tab structure is properly restored by SM.
For performance reasons, tabs don't and shouldn't run in separate processes.
I find that statement dubious. Please explain.
In my experience, the process-per-page (be they tab, window, or whatever) yields much better performance. I believe there are multiple reasons for this. For starters, the OS already has a perfectly good scheduler, and it makes sense to use that to handle multi-tasking. Indeed, OS people prolly know more about how to design a scheduler than browser people. By exposing the this to the OS, it also means the OS can do whatever tricks it has to make I/O, memory allocation, etc., more efficient on a per-page basis, rather than treating the whole browser as an opaque object.
Finally, lot of modern hardware has 2, 3, 4 or more processor cores. Firefox generally only uses one of them. A browser like Chrome can have each page render on its own processor core, which is a *huge* performance gain. Without that, any multitasking is going to be limited to slicing up a single core between multiple tasks. The system can still only do one thing at a time. By using multiple cores, the system actually gets multiple things done literally simultaneously. On good hardware, the performance difference is astounding.
"You know, the original motivation for the tabs feature was that each tab could be run in a separate thread whereas each window needs a separate process."
That's just plain wrong. Each window does not need a separate process. Each tab does not get a separate thread. In Firefox 3.6, multiple threads are used, but it's not a one-thread-per-tab thing. Most of the work is still done in a single monolithic thread.
The motivation for tabs in Firefox was to copy Opera. The motivation for tabs in Opera was as an alternative to one-page-per-window or MDI.
With 128-150 tabs open
No offense, but I think you're doing it wrong.
I routinely open that many tabs. But then, I work in a dynamic environment where I'm often being asked to do a dozen things at once, including several open-ended research projects, plus a handful of web-based apps, plus casual browsing, reading news, etc. And Slashdot, of course.
I'll put in a plug for my favorite extension here: TreeStyleTab. Rather than limiting tabs to a linear strip, this gives it a 2D structure. When I surf, inevitably one thing leads to another thing, which leads to a site which leads to six more things. So I middle-click almost every link, and it all gets organized into a hierarchical history. It helps me organize my thinking when I'm researching something, especially when I don't know exactly what I'm looking for.
TreeStyleTab demo shot
It's got a million options. You can configure it for all sorts of things. You can even have it put a 2D tab strip across the top of the window, if you like that.
The lack of a working TreeStyleTab clone on Chrome meant I went back to Firefox. Everything else was great, but I can no longer do serious web browsing without TST, and so that killed Chrome for me. Yes, it's that important.
TreeStyleTab: Don't leave your home page without it.
"It looks like there is a single process plugin-container.exe to run all flash files. Killing this exe will stop playing all the flash files."
FWIW, Google Chrome works the same way.
I'm not sure, but I suspect this *may* be due to design of the whole plugin concept. I would guess that the plugin concept assumes a single monolithic process for everything. There would be no need for an IPC facility. So I would guess Flash doesn't expect to find different windows running in a different process space. I know I've seen Flash objects communicate between each other; I presume that's done inside the plugin. If I'm right with my guess, using a different processes for each plugin object instance would be a giant compatibility problem.
I'll take this opportunity to post some non-inflammatory info on planned Firefox development.
Firefox 4.0, which may go into beta as early as next month, is supposed to do a lot in this direction. Overhauled JavaScript engine, overhauled HTML rendering, etc.
http://wiki.mozilla.org/Firefox/4/Beta
http://developer.mozilla.org/en/Firefox_4_for_developers
I thought I had heard that 4.0 was supposed to deliver one-process-per-page functionality, but I'm having trouble finding recent status info. (One drawback to high-speed FOSS development is it's hard to keep track of things like that.) But anyway, the project is named "Electrolysis" ("E10S" in Firefox-developer-speak).
http://wiki.mozilla.org/Electrolysis
http://wiki.mozilla.org/Talk:Firefox/Roadmap
"Contrary to popular belief, Challenger was actually mostly broken up by aerodynamic forces..."
I never stated otherwise. What does that have to do with what I was talking about? As I stated, the point was the robustness of solid rockets, not the STS as a whole.
And, no offense, but the third sentence (with parenthetical) in your first paragraph is so incoherent I can't figure out what point you might be trying to make.
"(liquid rocket is in comparison virtualy inert most of the time)."
Hmmm, that's a good point. I wonder if the gentleman I was talking to was considering that.
Certainly the PEPCON disaster showed that while solid rocket fuel might be relatively safe compared to liquid fuels, it's not inert by any stretch of the imagination.
"Plus it's certainly not a coincidence that our orbital rockets rely mostly on liquid propellants ... higher specific impulse is good to have after all, for starters."
Well, for starters, using a conventional solid rocket for orbital insertion and maneuvering would be close to impossible, since you don't have the control needed. So I'm not sure what you hope to prove with that. :)
Beyond that, I'm told that during the boost phase, when you're trying to climb out of the gravity well, you want a higher thrust-to-weight ratio, which solids are good at. During the second phase, when you're trying to accelerate downrange to orbital velocity, efficiency matters more, and liquids are a win there.
"failure of the seal as on Challenger is one of the more common modes of failure for solid rockets"
And is normally not a huge concern, since the rocket is robust enough to survive it. The problems happen when you put something vulnerable next to the solids. When it's vulnerable and explosive, it's a recipe for disaster. Again, not arguing the overall design of STS.
I'm also not arguing solid rockets are an overall design win. All I'm saying is that they are a simple, robust technology.
"Hybrid rocket engines seem to be interesting..."
Yah, new concept to me, which I'm just reading up on now. Interesting, indeed.
You time your separation to avoid the plume and recontact between the booster and the separating module.
If the rocket is already in the air and we can afford to jettison the booster, why would we care about equalizing thrust? If we can do a separation, we do it, and now the booster can do whatever the heck it wants to -- splash down into the ocean, explode into a million tiny pieces, etc. No?
And really the plume is less than you might think, when the pressure in the booster drops, so does the combustion rate.
I imagine that would take a few seconds, though. Challenger's ET blew apart quickly enough from contact with a relatively tiny plume. I imagine half the total trust from an SRB would be pretty dangerous, even if it's nominally directed up and not sideways. And if the crew capsule is directly on top the solid rocket...
"From a safety POV, they amount to the same thing."
Me, I see a big safety difference between a giant geyser of flame spewing out of each end, and a full shutdown (like Gemini 6). Also, I haven't been able to find any information on just how practical thrust venting really is. (Which is not to say such information doesn't exist, just that I don't have it.) There's going to be a payload/crew module -- either on top of the rocket, or right next to it, in the case of an outrigger booster. I imagine the thrust being vented would be quite hazardous. So how does that work?
Thanks for the info.
Last time I got in a discussion on this subject on Slashdot, nobody had any references, it was all just supposition. Your links, especially the second, are much more solid (pun unintended).
This issue gets more and more complicated the more I look at it.
"I already did! Read the link. The SRBs are more expensive per flight."
Ah, sorry. I ass-umed that since your statement on solid fuel costs came after the link, it was an independent point. Thanks for the correction.
"They never got anywhere near $160/lb. - not at over $10,000/kg."
Like I said, I wasn't defending the cost efficiency of STS, or even just the SRBs. The shuttle program is notorious for its high costs and budget overruns. I had just been lead to believe that solid rockets were cheaper in general. Your reference obviously contradicts that.
I wish your reference got into more detail as to why the solid booster option was expected to be more expensive to operate (post-development). I'm working on very meager information already, and this just complicates things. :-(
DragonHawk: "...once lit they will consume their entire fuel supply. No stop-and-restart."
DerekLyons: "Actually, while you can't restart 'em - you can shut them down."
Interesting. Mind explaining how, or at least giving me a term to Google?
(If you're talking about thrust venting, I'm aware. But they still consume their entire fuel supply. Thrust venting simply cancels out the thrust; the fuel still burns to completion.)