New Firefox Project Could Mean Multi-Processor Support 300
suraj.sun writes with this excerpt from Mozilla Links "Mozilla has started a new project to make Firefox split in several processes at a time: one running the main user interface (chrome), and another or several others running the web content in each tab. Like Chrome or Internet Explorer 8 which have implemented this behavior to some degree, the main benefit would be the increase of stability: a single tab crash would not take down the whole session with it, as well as performance improvements in multiprocessor systems that are progressively becoming the norm. The project, which lacks a catchy name like other Mozilla projects (like TaskFox, Ubiquity, or Chocolate Factory) is coordinated by long time Mozillian, Benjamin Smedberg; and also integrated by Joe Drew, Jason Duell, Ben Turner, and Boris Zbarsky in the core team. According to the loose roadmap published, a simple implementation that works with a single tab (not sessions support, no secure connections, either on Linux or Windows, probably not even based on Firefox) should be reached around mid-July."
As a Developer the Question I Have Is ... (Score:5, Insightful)
As chipmakers demo 64 or 128 [gizmodo.com] core chips, why aren't we coding and being trained in Erlang [wikipedia.org]? Why aren't schools teaching this as a mandatory class? Why aren't old applications being broken down and analyzed to multithread components that don't interact? Why isn't the compiler theory concentrating on how to automate this (if possible)?
It's becoming obvious the number of cores is going to far outweigh the number of applications we'll be running five years from now (so you can't leave it up to the OS) so why isn't this a bigger concentration now in application development?
I understand a lot of server side stuff can take advantage of this (in the nature of serving many clients at once) but it's only a matter of time before it's typical on the desktop.
Re:As a Developer the Question I Have Is ... (Score:5, Funny)
Re: (Score:3, Interesting)
I wish Opera will catch up soon to this aswell. Its a great browser, but when it does crash on some page whole browser goes down. They have to soon, seeing all other major browsers have implemented it.
Re: (Score:2)
On the serverside you just fire up a few more processes.
On the clientside you rarely need the juice that multiple cores provide. Processor speed still keeps improving _per core_. In most cases it is simply not worth the effort yet.
Re:As a Developer the Question I Have Is ... (Score:4, Informative)
No, your post and the one you replied to are off base, because firefox is already multithreaded:
# ps -eLF | grep firefox /bin/sh -c firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox /usr/lib/firefox-3.0.7/firefox
user 23146 20837 23146 0 1 468 496 1 15:26 ? 00:00:00
user 23147 23146 23147 4 6 43763 59000 0 15:26 ? 00:00:12
user 23147 23146 23149 0 6 43763 59000 0 15:26 ? 00:00:00
user 23147 23146 23150 0 6 43763 59000 0 15:26 ? 00:00:00
user 23147 23146 23154 0 6 43763 59000 1 15:26 ? 00:00:00
user 23147 23146 23155 0 6 43763 59000 1 15:26 ? 00:00:00
user 23147 23146 23156 0 6 43763 59000 0 15:26 ? 00:00:02
And when I tried it just now, opening a new tab spawned a new thread (maybe more than one).
The question for this article is, why separate processes instead of threads? If you have processes sharing memory (especially read/write memory) this distinction between threading vs. multiple processes becomes rather small.
I do hope they can firefox survive a plugin crash, because youtube always locks up firefox eventually.
Re:As a Developer the Question I Have Is ... (Score:5, Informative)
Well, at least in the Unix/Linux model, processes are mostly independent, memory-wise. Shared memory is an explicit thing, under the category of Interprocess Communications (IPC). Under no condition does a fandango-on-core in one user process trash non-shared core in another process, and shared memory is generally restricted to shared-context communications, so both a smaller victim space and functionally more resilient. (Code using IPC shmem expects it to be volatile, and well-written code that uses IPC shmem vets its contents carefully before using it, so catastrophic oopses should be rare.)
Compare that to the more modern thread model, which, in almost every architecture I'm aware of, mostly runs in exactly the same user space. If a thread eats atomic hot buffalo wings, all its brother threads in the same process get the same heartburn. The upside, barring badness, is that thread management is lightweight: no need to copy the parent memory image to a separate allocation and set up full process "OS bureaucracy" data structures. In contrast, it's practically "wave your magic wand et voila you have created a new thread". Very responsive. Very fragile.
I think this responsiveness is a lot of the reason to love threads. And that "crashing" stuff? That never happens to me. So I don't need to worry about how fragile threads are.
ObDisclaimer: it's been a few years since I've done any hardcore coding, so I may have missed some important details. If I did, I'm sure someone vastly smarter than me will be happy to point it out.
Re:As a Developer the Question I Have Is ... (Score:4, Insightful)
There's a much more important reason to use threads instead of processes + IPC, and that's that inter-thread communication is a sub-microsecond matter. Even the context switch between multiple threads (in the same process) is so cheap you can have way too many threads and still not see the overhead if you're also doing real work. In Linux much of inter-thread communication happens entirely in userland, so you don't even suffer the cost of a system call. You can go even further and use atomic operations to make data structures and algorithms that never need system calls to begin with, and that's about as fast as you can get with threading.
Re:As a Developer the Question I Have Is ... (Score:5, Informative)
I think you are a bit confused.
With linux, the only difference between context-switching between threads and between processes is the update of the page tables and the flushing of the TLB. Not normally a big deal.
Also, I'm not sure where you get the idea that interthread communication happens in userland--threads share memory, file descriptors, signal handlers, etc., but things like sockets/pipes need to go through the kernel. Processes can be made to share memory too, it's just a bit more work to set up, and you need to be explicit as to exactly what is being shared. (Which can be an advantage.)
Perhaps you're thinking about synchronization primitives which do not require a syscall in the uncontended case--if so, those are valid to use between processes as well.
Multithreaded apps have the potential to be faster than multi-process ones due to the lack of TLB flush, but they're more fragile due to the shared memory. For something like a browser which is often prone to crashing on crappy plugins, it makes sense to aim for reliability.
Re: (Score:2)
It's a very strange trend to me.
Tab processes must have some way to access global data and state. A shared memory approach is quite likely. So now, instead of a tab crash directly bringing down others, you just hope that nothing scary happens to the shared memory area. You also hope that your "crash" isn't some other failure like a deadlock - suddenly everything else hangs trying to get the mutex for the global bits? What if a plugin gets exploited in just one tab? Then the exploit code can use its unsandbo
Re:As a Developer the Question I Have Is ... (Score:5, Informative)
Re: (Score:3, Informative)
Re:As a Developer the Question I Have Is ... (Score:5, Insightful)
As a recent college grad, I had one course in which threads came into play; it was in the course that introduced GUI work, so our GUI wouldn't freeze while a worker thread was running, but that is the area where single-threading is most apparent to the user, after all.
There isn't all that much room for undergrads to take courses on threading though; the course I took it in was the highest-level course that's required of all CS majors, and even still, that was only one semester after taking our "Intro to C and Assembly" course.
Realistically, an in-depth course on good threading implementation is at the graduate level, but there isn't a large percentage of CS majors that go on to graduate work.
Re: (Score:2)
I agree it's not that advanced, but there's not much room for it, with all of the other topics that need to be covered.
Here's an overview of the courses I took that were required for my degree:
-Intro to CS (C++, covered basic concepts, not even really getting into OO basics)
-Intro to CS, Pt 2 (C++, covered OO, classes, basics of pointers)
-Data Structures (Java, nothing but hashes, lists, trees, etc)
-Software Design (Java, mostly about how to structure OO designs well)
-Intro to C and Assembly (covered pointe
Re: (Score:3, Informative)
-Operating Systems (C, covered things like memory allocation, caching policies)
This is the class that should have covered multiprogramming issues.
Re: (Score:2, Insightful)
Any bloke can use a thread and a few locks, or toss in some OpenMP pragmas on a for-loop. But what about: priority inversion, memory barriers, atomic operations, lock-free data structures, concurrency under deadline scheduling, deterministic concurrency, automated task-graph analysis. Not advanced concepts?
Re:As a Developer the Question I Have Is ... (Score:5, Funny)
It's becoming obvious the number of cores is going to far outweigh the number of applications we'll be running five years from now
The number of cores (at least some chips) already outweighs the applications you can run if you run Winows 7.
Re: (Score:2)
Thank you for the clarification.
Re: (Score:2)
It may have been a joke, but it certainly wasn't funny.
Re: (Score:2)
Re: (Score:3, Interesting)
Really? Not that I noticed. I was tought Pascal, Ada, 68000 machine code, and they let us play with a little C off the record. Oh and Cobol, of course. No threading at all. That was around 1990.
Having talked to programmers who qualified more recently, it hasn't got any better except they now get to learn C 'officially'. It takes around 6-9 months for a new programmer to pick up how things are done in the real world after being through the education system.
Re: (Score:3, Interesting)
I'm pretty sure that was plain textbook stuff (from the first chapter of Tanenbaum's Operating Systems), as you would fail the grade if you didn't get it to work.
Re:As a Developer the Question I Have Is ... (Score:5, Insightful)
Why isn't everyone doing this?
Because multi-threaded programming is really really hard to get right, and because most programs either are not CPU bound, or else have so much inherently non-parallel logic that the benefit would be marginal. Serving multiple independent tabs in a web browser is extremely amenable to parallelization, but almost everything else isn't.
Re: (Score:3)
It is not hard to to get right, when you leave side-effects out of the language. Because of the determinism and independence from other parts of the program, you can easily split the code processing, and even cache results wherever it helps. Automatically. (Of course you can still manually control it.)
Re: (Score:3, Insightful)
In "why isn't everybody doing this?" the "this" refers to not doing multi-threaded programming; it means forking a process and talking over a pipe (or some other much-high-level-than-shared-memory IPC), which is actually pretty easy to do and hard to fuck up.
The catch is, it tends to be harder to think up ways to split your program into multiple processes that can really be useful with such relatively limited IPC (relatively limited, as
Re: (Score:2, Informative)
As chipmakers demo 64 or 128 core chips, why aren't we coding and being trained in Erlang?
Every mainstream programming language has facilities for multithread programming and there's no need to learn a new one just to do it.
Why aren't schools teaching this as a mandatory class?
Multiprocessing is a key theme of operating systems courses, which are in the core curriculum of all CS programs. Many other courses also cover synchronization primitives, IPC, and other topics useful for multithreaded programming.
Why aren't old applications being broken down and analyzed to multithread components that don't interact?
It's usually difficult to retroactively add such features to applications that weren't originally designed with them in mind.
Why isn't the compiler theory concentrating on how to automate this (if possible)?
Compilers do paralle
Re: (Score:2)
Multiprocessing is a key theme of operating systems courses, which are in the core curriculum of all CS programs. Many other courses also cover synchronization primitives, IPC, and other topics useful for multithreaded programming.
If only it was.. life would be so much simpler.
In truth 'operating systems' often means little more than learning machine code. Schools teach the bare minimum the pass - it's not worth their while to start on non-core subjects. The average graduate I see can't even *spell* IPC l
Re: (Score:2)
Why isn't the compiler theory concentrating on how to automate this (if possible)?
Compilers do parallelize when possible. It's usually not possible without intervention by the programmer.
I think he's wondering why more effort isn't being spent on getting the compiler to do it more intelligently. I don't know whether or not that is happening, I'm not in the industry.
A funny answer, but it's also the serious one (Score:3, Insightful)
Because it's hard?
Re:As a Developer the Question I Have Is ... (Score:5, Insightful)
Erlang is a very poor choice for true multi-threaded programming. It does "lightweight" threads very nicely but real multi-CPU stuff is very slow. To the point that it negates using multiple processors in the first place.
While I like programming in Erlang, its performance sucks donkey balls. Even the HIPE stuff is pretty damn slow.
Plus the learning curve for functional languages is pretty high. Most programmers take a good bit of training to "get it", if they ever do. I have been programming in Erlang for about 5 years and even though I get it, I still prefer the "normal" programming languages like C/C++, Lua, Perl, whatever. I use functional tricks and I wish some of those imperative languages had more functional features but I think they work more like the human mind does and that helps me program better.
We do need something to make multiple-CPU programming easier though. Threaded programming in C/C++ or similar can turn into a nightmare real quick, it's error prone and complicated.
Re: (Score:2)
Wouldn't the point of the course be to teach them about threading (perhaps using erlang), they can then use those skills to thread in other languages.
Re: (Score:2)
Because it is a niche language.
Many programs already use multiple threads and were threaded before multi-core systems were common. The modern Windows shell (explorer.exe) has been multithreaded since it was introduced in Windows 95.
In general, anything obvious and easy to parallelize has probably been already.
Re:As a Developer the Question I Have Is ... (Score:4, Informative)
Erlang's great until the share-nothing approach leads to so much overhead in pushing bytes back and forth between processes that you are spending more time copying bytes than actually doing work. Not saying that normal thread models are always better, but there is no "perfect" multiprocessing model and Erlang has its own pitfalls. As for Firefox, you are basically running a series of stovepipes where it makes sense for each tab to have a separate process... why it has taken so freakin' long for this I don't know, but it's not a new idea (hell I posted it right here on Slashdot back when FF3 was just coming out... lemme check.... here [slashdot.org].
Re:As a Developer the Question I Have Is ... (Score:5, Funny)
)
Sorry, I can't sleep if I know there is a bracket left open.
Re:As a Developer the Question I Have Is ... (Score:4, Funny)
Re: (Score:3, Funny)
His Lisp had a compile error.
Re: (Score:2)
Why do you think this isn't the case? There's plenty of research in exactly the areas you describe going on right now. It's all over the programming blogs and research papers, everywhere I look (when searching for programming-related topics) there is a tutorial on functional programming. Are you living under a rock or something?
Re: (Score:2)
As this article has pointed out, we don't need to switch to Erlang to take advantage of multicore chips. All we need to do is make better use of multithreaded programming, which has been around for ages. One of the tags on this article said "abouttime": this is exactly right. Why wouldn't a tabbed browser put each tab into a separate thread. I already have 25 open tabs on my current Firefox session, and it seems a little silly that those aren't in different threads or processes in this day and age.
Right
Re:As a Developer the Question I Have Is ... (Score:4, Informative)
That doesn't mean that the application doesn't have a ton of threads or processes, utilizing processor resources. It's just easier and more efficient for a single dispatcher to communicate with a bunch of threads than it is to communicate with a bunch of processes. It also means that when one thread catches the hiccup, the whole application has to deal with the collateral damages.
Now, to make a GUI application multi-processes, you need to have a dedicated process to handle drawing and events. Add one or more processes to handle the tasks, and IPC to tie them together. In another word, you ends up reimplementing X
Add a deadline to that and you can see why you end up with just multi-threaded applications.
Re: (Score:3, Insightful)
For the most part we are not doing it because it is a totally useless activity. The vast majority of programs out there gets along fine with a single thread (or just a few threads for specific purposes). Adding more threads will not make them faster or better in any appreciable way.
And thread creation / communication / synchronisation also has an overhead, and that overhead might very well add up to slower overal programs. Besides, if you are working and your computer just seems to stop for a second... That
Re: (Score:2)
Once upon a time, the core(s) were the bottleneck.
Once the storage bogeyman is taken care of (as I'm sure it will eventually) what will be the new bottleneck?
This is the nature of the beast. Kill one, and more take it's place.
Re: (Score:2)
In some applications, memory bandwidth is already the bottleneck.
Re: (Score:2)
Sure, it'd be nice if my browser's UI is a tad faster, and doesn't miss a beat even if I load a horribly javascript heavy page; but the really nice thing is having my 35 tabs not be taken out by a single flash instance, or that one tab with deviousmalwarehackz.ru open.
responsiveness (Score:5, Insightful)
I think the main benefit of such a system would be responsiveness. It is very unpleasant when one tab temporarily causes the entire browser window to become completely unresponsive--including the STOP button or the button to CLOSE the misbehaving tab. The UI should never freeze for any reason.
Re: (Score:2)
The UI should never freeze for any reason.
Sadly, IE8 still has this problem. Anyone know for Chrome?
Re: (Score:2)
The UI should never freeze for any reason.
Sadly, IE8 still has this problem. Anyone know for Chrome?
Chrome is designed so that no blocking operations whatsoever are allowed on the UI thread. In theory, therefore, the interface should never freeze up. Since Linux builds still tend to crash a lot, though, I haven't been able to give it a good workout personally.
Re: (Score:2, Informative)
Um, IE8 does the exact same thing. It uses child processes to control groups of tabs by domain.
Of course, IE8 was doing it since the first public beta, over 5 months before anyone knew about Chrome. The implementation in Chrome is a near carbon copy. Who is copying whom?
Re: (Score:2)
Re: (Score:2)
Um, IE8 does the exact same thing. It uses child processes to control groups of tabs by domain.
That doesn't mean it makes sure to avoid blocking on the interface tab. So in principle, the interface might still freeze up. (Since I use Firefox on Linux, I don't know, personally.)
Of course, IE8 was doing it since the first public beta, over 5 months before anyone knew about Chrome. The implementation in Chrome is a near carbon copy. Who is copying whom?
Neither is copying anything. You think Chrome wasn't already a working internal alpha with most of its design fixed (obviously including major structural issues like use of threads) by five months before its release?
Re: (Score:2)
Whoah. Somebody hasn't used a Windows OS in a while, I see...
Re: (Score:2)
The existence of MS Windows does not detract anything from his point. It only serves to demonstrate that Microsoft has not learned the lesson.
Re: (Score:3, Funny)
sive--including the STOP button or the button to CLO...
SE the mi...
sbehaving tab. The UI should never freeze for any reason.
Hear! Hear! I don't recall any problems of this nature back on version 2.x of Firefox. And why does my bank's website think I'm running from a different computer every time there's a minor update to Firefox?
Re: (Score:2)
Probably because your user agent has changed, and they detect that.
Re:responsiveness (Score:5, Insightful)
Re:responsiveness (Score:4, Insightful)
Sure, it would be useful as an option, but I think this is more add-on territory because of how little it would benefit most people.
Re: (Score:3, Interesting)
If I look at a page like The Drudge Report, I can ctrl-click on 10 links, creating 10 background tabs. Then, I click on the first article tab, read a bit, close the tab. That shows me the 2nd article. Close it, and I get the 3rd. etc.
This way, I don't have to wait more than 50ms to go from article to article. They are already loaded in the background for me.
Very handy!
Doesn't everyone do this?
Re: (Score:2)
This can be achieved in threads, i really hate the idea of jumping to a one process per tab model when it doesn't offer the advantages being promised. If this is going to be done, it needs to be done for the security benefits and that requires OS/distro cooperation!
Responsiveness / multicore use / tab crashing can all be done using threading
Security is the only reason to use separate processes and IMO i don't want to take a per-tab performance hit when browsing slashdot/youtube/gay^H^H^Hporn/etc, per tab st
Finally! (Score:5, Interesting)
Otherwise, I'd probably switch to google chrome eventually, which doesn't have the add-on support I enjoy from firefox.
Re: (Score:2)
The web is changing ...
This is about hardware changing, not the web. If the CPU manufacturers were still concentrating on X Ghz chips instead of Y core chips, Mozilla wouldn't be doing this. Intel and AMD have spoken and the software world better pay attention.
Mozilla is interested in providing a better user experience and they're correct in taking full advantage of your hardware. As multicore chips become cheaper and cheaper to fabricate and they show up in netbooks with low frequencies, this is going to pay off big time.
Re: (Score:2)
This is about hardware changing, not the web. If the CPU manufacturers were still concentrating on X Ghz chips instead of Y core chips, Mozilla wouldn't be doing this. Intel and AMD have spoken and the software world better pay attention.
Not quite correct.
The laws of physics have spoken, and caused Intel and AMD to change their focus from clockspeed/GHz to multicore. The software world better either pay attention, or figure out a way on their own to get single-core CPUs to run at 20 GHz without needing liqu
Re: (Score:2, Flamebait)
The web is changing - full of in-browser videos, web apps, and other resource intensive content, and firefox has had trouble catching up.
Of course, with add-ons to Firefox like Adblock Plus, FlashBlock and NoScript, all that crap becomes Opt-In. Aside from occasional problems with the Java plugin (which I need for a specific site), I've never felt that Firefox was slowing me down. Chrome felt slower despite handling JavaScript faster, because it had to run the JavaScript, period.
Re: (Score:2)
And it doesn't crash like it used to back in the early 1.x days. Sure, it's a little bloated, but I'll happily compare my FF uptime stats with at least Windows Server.
Re: (Score:2)
Try out minefield, its pretty fast and rarely crashes on me (literally twice in ~6 months of running it), rendering is fast, startup time is pretty good and generally firefox 3.5 is the fasted browser I've seen (granted im on Linux but it compares favorably to chrome on my friends windows box, and the Linux version does even have PGO yet)
Changing to a multiprocessor system is going to mean a performance hit and only provides a marginal security benefit, Firefox's main security hazard are its extensions, ofc
Relief (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Don't forget us poor bastards that are forced to use Windoze at work. We're not lemmings, just not in a position to force our companies to switch. Thanks to stupid Outlook and Office, even at past jobs where I used Linux, I still had to use Windoze for my email and office crap (and also web browsing), and only used Linux through VNC.
Re: (Score:2)
You can set Firefox to open PDFs externally instead of using the plugin. Options -> Applications.
That's what I did until last week, when I switched to Sumatra.
Re: (Score:3, Informative)
Tools->Options->Applications. Search for 'pdf' and disable it from using the plugin to auto downloading and opening the file.
I also recommend using Foxit Reader instead of Acrobat for viewing PDFs, it too has a in browser plugin, but downloading and opening the application is quicker at least for me; the actual application usually opens in less than a second.
But back on topic, I have been using chrome more and more lately due to the fact that no tab can crash the entire browser. I still use Firefox th
So here's the $10,000 question... (Score:3, Insightful)
Re: (Score:2)
it depends how its done, but the performance hit in the past has been pretty bad. This is how nspluginwrapper works and apparently running 32bit flash on a 32bit system still took a noticeable performance hit. IMO it's better to just do this in threads but keep a close eye on the plugin threads.
How about threads? (Score:2, Interesting)
Processes vs Threads...
I'm pretty certain that the usual 40-60 pages I have open are going to blow the memory if each runs in its own process.
Re: (Score:2, Informative)
or am I wrong about it being multithreaded?
Re:How about threads? (Score:4, Interesting)
On any modern system, there is very little memory overhead to having multiple copies of the same process. They will share read-only or copy-on-write versions of the executable code and resources loaded from shared libraries and the the program binary, as well as any resource files opened with mmap() or the Windows equivalent. The only real overhead is relocation symbols, which are a tiny fraction of most processes. In exchange for this small overhead, you have the huge benefit of having completely isolated instances which only communicate with each other through well-defined interfaces.
Threads are an implementation trick. They should not be exposed as a programmer abstraction unless you want people to write terrible code. Go and learn Erlang for how parallel code should be written.
Re: (Score:3, Informative)
Do mods know nothing abuot modern operating systems?
A properly implemented application using a multi-process model should use only slightly more memory, thanks to shared memory [wikipedia.org], a feature of any modern operating system.
Re: (Score:3, Informative)
If it is threads, then the common parts are sharing literally the same memory, although you do pay for some locks.
If processes, which would be more robust, then the common parts should be in .so/.dll to share the code (common data could be in library-allocated memory, but cleanup is tricky on M$-Windows), and per-instance data is part of the process, which, when a window (tab, too, I suppose, but I don't use them) is closed, would free the memory. Reducing the amount of common storage to simplify its manag
Re:How about threads? (Score:4, Interesting)
I tried explaining this on DIGG, but to not have the title understand it on Slashdot is depressing!
I think there is an advantage to processes pre tab against a code injection attack
Also if you had Firefox-gui, Firefox-net, Firefox-Gecko, Firefox-Profile, Firefox-file you could give each one a different SElinux/apparmor/UAC profile.
Im not sure what the performance trade off would be like so i sincerely hope that there is a single binary compiler option. I also think that a good balance to prevent the security hit on per-tab processes is to only put https tabs in separate processes (additionally it would be smart to prevent extensions running on these pages (GUI extensions would still work, but nothing that touched the page).
Are processes even needed for security though? can threads be locked down to achieve this without the performance hit? (and additionally, lock down extensions?)
Re: (Score:2)
You think that's bad? A friend of mine routinely runs 400+ tabs. (She is forced to use Firefox 1.x as nothing newer is capable of handling this kind of number.) Can you imagine the resource hit that would take by using processes?
Re: (Score:2)
I'm the same way. This usually happens for me when I am reading some long text with a lot of links in it. I see a link, open it in a background tab and continue reading...
Also, I usually keep a lot of tabs open to the sites I frequently visit, so I just select the tab and refresh the page to see if the site (a forum or /. main page) changed. On some sites I do not need to refresh, since they refresh automatically.
Yes, I know, I should use bookmarks, but maybe it's just a bad habit, but a lot of tabs is easi
I guess it can be useful in... (Score:4, Interesting)
I guess it can be useful in determining which site I visit tends to create the memory leaks I still experience (even with ff3).
(as I type, this current browser session has ballooned to over 600MB...which is still better than my typical with ff2...which was 700-800MB)
maybe they can dedicate a process just for "garbage collection".
Catchy Name (Score:5, Funny)
Re:Catchy Name (Score:5, Funny)
I'd mod this up if I had the points. Flames behind a fork would look really stylish... although now you've got me thinking of Fondue...
Re: (Score:3, Funny)
Re: (Score:2)
How about Miles Prower [wikia.com]?
Re: (Score:3, Insightful)
Following the link on that page Kitsune [wikipedia.org] the Japanese word for fox, particularly in folklore. "The more tails a kitsune hasâ"they may have as many as nineâ"the older, wiser, and more powerful it is"
The problem is not threads vs processes... (Score:4, Insightful)
Current multithreaded Firefox is able to use multiple CPUs, being the reason of splitting the tabs into independent processes is to surrender to mediocrity. How about increasing Q&A, do proper synchronization between components, and don't allow untested components to be used without showing a big warning at installation?
Re:The problem is not threads vs processes... (Score:5, Insightful)
Until Mozilla has control over Flash, most internet uses will have to put up with buggy plugins. This is about being defensive instead of just getting shot.
Re:The problem is not threads vs processes... (Score:4, Insightful)
Re: (Score:2, Insightful)
What, you mean like ActiveX and code signing? Anything goes, as long as the user knows it's dangerous?
The era of "trust the user to make intelligent decisions" is long gone. I would argue that it never really existed in the first place. Computers are for people who don't want to know how the computer works. They don't want to see Big Scary Dialog Boxes where they have to make the Right Choice or else their system could be compromised.
The onus is on application developers to minimize the frequency of sca
the real question is... (Score:4, Interesting)
Will Chrome mature to have a nice system of plugins to match the advantages of Firefox before Firefox rearchitects this very low level code?
I sometimes wonder about the FF devs - I've been wondering about the lack of a multi-threaded (at least) UI for a few years now. That project kept getting put off and put off until there was too much code to change easily. Only now that a real competitor comes along do they bother with the obvious thing that should've been put in from the start. Do FF devs not actually USE FF? Or do they not browse sites with Flash apps that go out of control and make the browser completely unresponsive? I find that hard to believe.
Whatever. At least it'll finally happen. One wonders how many people will have switched over to Chrome by the time they get this out the door, though.
Re: (Score:2)
> "Will Chrome mature to have a nice system of plugins to match the advantages of Firefox before Firefox rearchitects this very low level code?"
Chrome already has plugin support well along in development.
And your wondering if a complete top to bottom rewrite of the stinking pile of shit codebase that is Firefox is going to arrive sooner?
Yes, it's got plugin _support_, but notice I said 'a nice system of plugins' - that is quite different. Having the capability to use plugins with very few plugins (and no
Interest dynamic between Firefox and Chrome: (Score:4, Insightful)
I kind of like single-processor apps. (Score:5, Insightful)
Re: (Score:2)
multi-threading is all they need to lock up your system, but ofc more than one thread/process needs to be chomping at the same time!
Re:I kind of like single-processor apps. (Score:5, Insightful)
If a process using 100% of your cpu "cripples" your machine your OS is broken,
Makes Firefox/browser platform of the future (Score:2, Insightful)
Making Firefox act more like a real operating system, each "application" runs in its own process is another step in that direction. It means that my gmail browser window won't crash if I surf to some buggy website. And it means that I can run a lot of browser based application faster and more stably.
This is the next logical st
Re: (Score:2)
Also, separate processes provides more isolation, so the malware site I'm visiting has no avenue to get at the banking application in the next tab.
However, web based apps require all browsers to render basic html properly. When is firefox going to fix Bug 33654? It was reported just over 9 years ago. This is the bug that prevents you from using TEXTAREA html elements in forms and getting them to be a consistent size. So far its been reported and marked as a duplicate of this bug at least 25 times.
Re: (Score:2)
Since QT 4.5 is not LGPL...how about re-creating its interface using QT like folks at VideoLan did. This would go a great way in improving the user experience.
Welcome to last year. http://arstechnica.com/open-source/news/2008/08/nokia-helps-port-firefox-to-qt.ars [arstechnica.com]
Re: (Score:2)
Any news since then, I've not played around much with my system because of exams but, last time i looked the QT port had once again died! This isn't the first time this has been tried/failed either :(
Re: (Score:2)
QT *IS* LGPL: http://www.qtsoftware.com/about/licensing [qtsoftware.com]
Sorry! (Score:2)
I meant to say: "...QT is now LGPL..."
My mistake.
Re: (Score:2)
The last time I viewed a page with Flash in it.