I hate to keep bringing this up, but iCab doesn't support a lot of the standards that the WSP and a lot of other people demand. In particular, it doesn't support the particularly hard ones (DOM, CSS2).
You're partly right --- MS have already released "Pocket Explorer".
There are two main advantages for Mozilla: -- It's portable. Already runs on lots of different platforms with lots of different UI toolkits. This makes it much easier to make another port. -- It's free. If you adopt it for your device, you don't have to worry that you're putting Microsoft's (or anyone else's) noose around your neck.
The idea that Netscape/AOL "isn't really trying" with Mozilla is ludicrous, and insulting to all the developers and contributors. You don't have to look very hard at www.mozilla.org and bugzilla.mozilla.org to see that the developers are busting their guts over this.
Most IE-specific code is easily tweaked to become standards-compliant, and hence usable in Mozilla.
If Mozilla goes down the road of emulating IE's quirks (e.g. document.all), no-one will bother fixing their code and you've basically ceded control of standards to Microsoft. That's a world that no-one wants to live in, whether you like Mozilla or not.
iCab doesn't even support Javascript properly yet.
Building an HTML4 renderer is one thing. Building a Web browser that supports Javascript, CSS (1 and 2), XML and DOM (*especially* DOM 1 and 2) is a totally different ball game. You may not want those things, but the WSP does and that is what Mozilla is signed up to provide. iCab, Konqueror, Opera and other browsers are fine at what they do, but they solve a much easier problem.
Much like the WSP's letter, this sounds like you think Netscape deliberately held Mozilla back from being released. Nothing could be further from the truth; Netscape and other Mozilla contributors are desperately trying to get Mozilla out the door, and whining from the WSP and other quarters IS NOT HELPING.
A Web browser that supports modern Web standards (DOM) is just as complex as an OS kernel. Probably a lot more so, because of the need to be backward compatible with hundreds of different kinds of incorrect Web page coding.
> In my opinion the display engine should be a > removable plug-in (And thereby be replacable) > which can be used by Navigator, whatever the > mail/news client is called, and Composer.
> I am not aware of any I/O completion port
> architecture on Linux.
It exists. See Ingo Molnar's comment in this article.
Why not use user threads to solve your inside-out problems?
Anyway, I didn't say this was a *nice* or easy way to write the system. It's just the best performing way. The interesting point is that the easiest (and slowest) and the hardest (and fastest) way to build the system uses a minimal number of shared-everything threads.
Cache coherency has nothing to do with it, really, as long as every CPU can access every part of memory equally fast in the cache miss case. The cost of cache coherency is taken by any and every inter-CPU communication. Keeping the inter-CPU communication down is easier to do with separate address spaces, because you're less likely to share something accidentally, but a well-written shared-everything thread model will do just as well.
For NUMA machines, it may be advantageous to make copies of shared structures rather than sharing the same memory across CPUs, especially if the structures are read-only. (Each CPU can have its own copy of the data "close to" that CPU.) But again, you can make these copies even in a shared-everything thread model, if you're clever.
Two processes can share memory using mmap(), no copying required.
TLB flush can be expensive, and that is why shared-everything threads are useful in some situations. However, if you are frequently scheduling different threads onto the same CPU, your system is probably poorly designed. In an optimally designed and configured system, you have exactly one thread (or process) pinned to each CPU, each one using non-blocking/asynchronous system calls and callbacks (e.g. signals or NT's IO completion ports) to service many different requests simultaneously.
Mentioning "threads" and "simplicity in design" in the same sentence? Hahahaha. In my experience, threads must be handled with extreme care, and require extremely careful and clever design.
The problem is that reasoning about asynchronous computation is inherently hard, and to minimize the amount of reasoning you have to do, you need to carefully limit the communication between your asynchronous components. A shared-everything thread model actively discourages and obstructs this goal.
> NT's threads, though, best Linux's.
Perhaps. I've heard a Linux kernel hacker claim that Linux switches processes faster than NT switches threads. He could have been lying, but it should be easy enough to check. If NT has an advantage, it's in the IO completion ports and other thread-related tricks.
Adam Lock is doing exactly this. His code is in the Mozilla tree.
It's amazing how on these Slashdot forums, everyone comes up with these great ideas that MOZILLA IS ALREADY DOING. People should take some time to actually look at the project before they comment.
Self didn't scale. Their lovely optimization technology was great at optimizing programs consisting of a few pages of code. Point it at something even a fraction of the size of a Web browser, and it would sink into the dust.
That's why the minds behind Self went on to other things, such as Chambers' Vortex compiler.
I browse with Mozilla all the time and I see very few "obvious" HTML rendering errors. Could you give some specific examples?
One difference might be that I carefully pick the builds I use. Some of the nightly builds are unstable or have serious layout problems; this is inevitable because people sometimes check in buggy code. There is an enormous difference between a "good" nightly build and a "bad" one.
Any truly standards-compliant browser lets you code old arcade games into webpages, because the W3C standards let you do exactly that.
If you want a small, simple, fast browser, you'll have to give up on complete standards support (especially the DOM). That's your choice, and there are browsers like Konqueror and Opera that fill this need.
Mozilla, on the other hand, aims for complete standards support, while still being fast (if not simple and small). It tackles a different, and harder, problem.
Mozilla does this. Have you ever used it? Right click on an image, select "Block image from loading". Be careful though, it blocks all images from that image's domain. I use this feature a lot and it's great!
The intelligent wrapping you desire would break many sites. If you don't mind that, you could create a user style sheet for Mozilla setting the max-width of BODY to some desired width (e.g. 500px). Not an ideal solution I suppose, but an easy hack.
BTW, HTML4 and CSS1 compliance issues are being tracked in Bugzilla, e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=7954 There are test suites already in place, too.
If you think there's anything missing from there, input would be appreciated.
Slashdot Mirror
> Where's the modularity?
It's there. That's why numerous projects are building their own Web browers on top of Mozilla's rendering engine.
It's also dead simple to build a "browser only" Mozilla package. I don't know why no-one's done it yet.
I hate to keep bringing this up, but iCab doesn't support a lot of the standards that the WSP and a lot of other people demand. In particular, it doesn't support the particularly hard ones (DOM, CSS2).
iCab doesn't fully support Javascript, doesn't support CSS, doesn't support DOM (this is the really hard part), doesn't support XML.
This may not matter to you, but it matters to the WSP and a lot of other people.
You're partly right --- MS have already released "Pocket Explorer".
There are two main advantages for Mozilla:
-- It's portable. Already runs on lots of different platforms with lots of different UI toolkits. This makes it much easier to make another port.
-- It's free. If you adopt it for your device, you don't have to worry that you're putting Microsoft's (or anyone else's) noose around your neck.
The idea that Netscape/AOL "isn't really trying" with Mozilla is ludicrous, and insulting to all the developers and contributors. You don't have to look very hard at www.mozilla.org and bugzilla.mozilla.org to see that the developers are busting their guts over this.
It's much more easily done than you think.
It's easier said "it's easier said than done" than done.
Most IE-specific code is easily tweaked to become standards-compliant, and hence usable in Mozilla.
If Mozilla goes down the road of emulating IE's quirks (e.g. document.all), no-one will bother fixing their code and you've basically ceded control of standards to Microsoft. That's a world that no-one wants to live in, whether you like Mozilla or not.
iCab doesn't even support Javascript properly yet.
Building an HTML4 renderer is one thing. Building a Web browser that supports Javascript, CSS (1 and 2), XML and DOM (*especially* DOM 1 and 2) is a totally different ball game. You may not want those things, but the WSP does and that is what Mozilla is signed up to provide. iCab, Konqueror, Opera and other browsers are fine at what they do, but they solve a much easier problem.
> By delaying the browser release
Much like the WSP's letter, this sounds like you think Netscape deliberately held Mozilla back from being released. Nothing could be further from the truth; Netscape and other Mozilla contributors are desperately trying to get Mozilla out the door, and whining from the WSP and other quarters IS NOT HELPING.
A Web browser that supports modern Web standards (DOM) is just as complex as an OS kernel. Probably a lot more so, because of the need to be backward compatible with hundreds of different kinds of incorrect Web page coding.
> In my opinion the display engine should be a
> removable plug-in (And thereby be replacable)
> which can be used by Navigator, whatever the
> mail/news client is called, and Composer.
It is.
> I am not aware of any I/O completion port
> architecture on Linux.
It exists. See Ingo Molnar's comment in this article.
Why not use user threads to solve your inside-out problems?
Anyway, I didn't say this was a *nice* or easy way to write the system. It's just the best performing way. The interesting point is that the easiest (and slowest) and the hardest (and fastest) way to build the system uses a minimal number of shared-everything threads.
Cache coherency has nothing to do with it, really, as long as every CPU can access every part of memory equally fast in the cache miss case. The cost of cache coherency is taken by any and every inter-CPU communication. Keeping the inter-CPU communication down is easier to do with separate address spaces, because you're less likely to share something accidentally, but a well-written shared-everything thread model will do just as well.
For NUMA machines, it may be advantageous to make copies of shared structures rather than sharing the same memory across CPUs, especially if the structures are read-only. (Each CPU can have its own copy of the data "close to" that CPU.) But again, you can make these copies even in a shared-everything thread model, if you're clever.
Two processes can share memory using mmap(), no copying required.
TLB flush can be expensive, and that is why shared-everything threads are useful in some situations. However, if you are frequently scheduling different threads onto the same CPU, your system is probably poorly designed. In an optimally designed and configured system, you have exactly one thread (or process) pinned to each CPU, each one using non-blocking/asynchronous system calls and callbacks (e.g. signals or NT's IO completion ports) to service many different requests simultaneously.
Mentioning "threads" and "simplicity in design" in the same sentence? Hahahaha. In my experience, threads must be handled with extreme care, and require extremely careful and clever design.
The problem is that reasoning about asynchronous computation is inherently hard, and to minimize the amount of reasoning you have to do, you need to carefully limit the communication between your asynchronous components. A shared-everything thread model actively discourages and obstructs this goal.
> NT's threads, though, best Linux's.
Perhaps. I've heard a Linux kernel hacker claim that Linux switches processes faster than NT switches threads. He could have been lying, but it should be easy enough to check. If NT has an advantage, it's in the IO completion ports and other thread-related tricks.
1) is coming, with the JAR-ification of the chrome tree.
2) is coming, a Mac-alike skin is already checked in, it's being fixed and polished before it's turned on.
3) and 4) will improve over the coming "performance work" milestones.
> Mozilla will probably never match the feature
> set and polish of IE Mac
It will exceed it in some areas, e.g. MathML, XML namespaces, MNG.
> "wipe out" option
Exists: in Mozilla, right click and select "Block image from loading" (blocks all images from the domain).
> cookies
Exists: Mozilla can block cookies per-site.
> fonts
Partially exists: Mozilla lets you increase or decrease text size of a page. User style sheets could help too, if you know how to use them.
I guess it would take a little work in Galeon to expose these in its interface, but Gecko does support them.
Adam Lock is doing exactly this. His code is in the Mozilla tree.
It's amazing how on these Slashdot forums, everyone comes up with these great ideas that MOZILLA IS ALREADY DOING. People should take some time to actually look at the project before they comment.
Self didn't scale. Their lovely optimization technology was great at optimizing programs consisting of a few pages of code. Point it at something even a fraction of the size of a Web browser, and it would sink into the dust.
That's why the minds behind Self went on to other things, such as Chambers' Vortex compiler.
I browse with Mozilla all the time and I see very few "obvious" HTML rendering errors. Could you give some specific examples?
One difference might be that I carefully pick the builds I use. Some of the nightly builds are unstable or have serious layout problems; this is inevitable because people sometimes check in buggy code. There is an enormous difference between a "good" nightly build and a "bad" one.
Any truly standards-compliant browser lets you code old arcade games into webpages, because the W3C standards let you do exactly that.
If you want a small, simple, fast browser, you'll have to give up on complete standards support (especially the DOM). That's your choice, and there are browsers like Konqueror and Opera that fill this need.
Mozilla, on the other hand, aims for complete standards support, while still being fast (if not simple and small). It tackles a different, and harder, problem.
> Speaking of images
Mozilla does this. Have you ever used it? Right click on an image, select "Block image from loading". Be careful though, it blocks all images from that image's domain. I use this feature a lot and it's great!
The intelligent wrapping you desire would break many sites. If you don't mind that, you could create a user style sheet for Mozilla setting the max-width of BODY to some desired width (e.g. 500px). Not an ideal solution I suppose, but an easy hack.
www.alphanumerica.com
Their "Total Recall" package works cross-platform IIRC.
There is an effort porting DirectX to Linux. It's called WINE.
BTW, HTML4 and CSS1 compliance issues are being tracked in Bugzilla, e.g.4
http://bugzilla.mozilla.org/show_bug.cgi?id=795
There are test suites already in place, too.
If you think there's anything missing from there, input would be appreciated.