In Mozilla M14, this took 116 seconds to render - That's almost two full minutes!! In Netscape 4.72, the same page rendered in about six seconds.
Grab the source and try `./configure'ing it with the --enable-x11-shm (X-shared memory support.)
I just tested the latest CVS version (not sure how different it is from the binaries they release today) using that option (also disabled debugging) on the 500+ comment "What's Banned On Your Campus?" story, and Navigator 4.7 took 21 seconds, while Mozilla took 28 (on a K6-2 300 system.)
I am not a programmer, let alone an open-source programmer. [...]
I hear people bitching about this on both sides of the argument. Can someone please enlighten us all as to why source code takes so much work to release, especially if that code is just being given away as opposed to released for development.
I think that the main reason programmers are usually so reluctant to release their "bleeding edge" code is pride. Writing software is every bit as much a purely intellectual endeavor as writing literature, and consequently, putting it out for the public to see is in a very real sense putting your entire intellect out for display. It can be a bit nerve wracking, to say the least.
I've had my first personal experience with this recently, and even though it was only two small scripts intended for use by a very limited audience at my local ISP, I can tell you it brings out every bit of insecurity one has to know that it's inevitable that some more (or even worse -- less) experienced coder will find and point out at least a few really silly and elementary mistakes in your code.
I just wish I could help out with coding because development seems to going slower than I would think.
Yeah, which brings an obvious question to mind: why aren't more companies (or any, for that matter) taking advantage of libwine to port their products to Linux?
While it's great that the Opera folks went through all that effort to do a "real" linux port, wouldn't it have made allot more sense to just get their Windows source to compile with wine? I've had the native Windows version almost running properly under recent versions of wine, so I'd imagine that it would have been trivial for them to find the bugs in wine's Win32 emulation that cause problems, and either work around them, or even better, send bugfixes to the wine team and fix the problems properly.
However, for whatever reason, it needs a lot more RAM. It has to physically allocate however much RAM you tell it to use for the emulated OS, in my case 32MB for Win '98[...]
Well... Win98 is a monster in its own right--I'm surprised that you can get it to run at all in 32MB:(. The reason VMWare wants fixed blocks of RAM is that tricking an OS into thinking it has complete control over memory that is actually managed by another OS is a complicated process, and while they probably could do it in a more dynamic fashion (only allocate physical storage for memory the guest OS actually uses), that would probably significantly increase the complexity of the code, which of course usually means increased bugginess and performance penalties.
DOSEmu, by contrast, never uses as much RAM as I tell it it can use unless it absolutely has to. Usually I give it 8MB, but when I wanted to run Callus, I gave it 20MB. Worked great, except for lacking sound. Wine generally uses 4MB[...]
DOSemu has a much easier job than VMWare because hardware support for x86 "real" mode virtualization is built directly into all modern Intel class processors. DOS programs also rarely use more than ~1MB of memory in any case.
WINE, of course, "Is Not an Emulator";). It's basically just a library that relays Win(16|32) API calls to their corresponding xlib calls. The windows apps themselves are executed directly with the help of the loader program, so it's actually a bit surprising that it uses even that much memory.
I like the idea of Debian, but it's currently too far out of date for me to use.
You can have as up-to-date a Debian system as you want: just use "unstable". Mine's currently a hybrid between an ancient Slackware libc5 installation, Debian Slink, and Debian Potato (2.2.13 kernel and an Xserver from 3.3.5-1)--all working very well together and with very few problems.
Among other things, libapt isn't good at:-> keeping track of automatically performed selections and removals; each frontend has to do this itself
Which is as it should be. If a user want to keep logs, she can use shell redirection.
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely.
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.
What libc setup do you have to get such good results? (Although I think you've essentially conceded my point by disabling java because "it does tend to crash Netscape").
Debian's "unstable" glibc2.1+smotif linked versions of Navigator and Communicator 4.[67] are all rock solid on my system, even with Java enabled.
You can get the communicator.deb's here, which you'll probably want to convert to.rpm's for your SuSE distro. with Joey Hess's alien program.
With todays technology why can't they build the beast so that it's modular, if you want all of the bloat.. okay... just plug it in. Whatever happened to the basic Unix philosophy of making small programs that WORK and can be used as building blocks to do larger tasks. WHY MUST I BE OPPRESSED WITH BLOAT ?????
Actually, Mozilla is very modular. The loader itself (apprunner) is less than 20KB. Everything else is done with shared libraries, this biggest of which is less than 500KB.
That's not to say I disagree with everyone's main point here--that the developers should have first focused their energies on the HTML/browser component instead of the Java/email/NNTP cruft. If they had, we might not have got into this silly debate about Mozilla being a "failure" in the first place.
As for Mozilla, it's more reliable than Netscape 4.x for Linux.
Well--the latest version I've tried was M9, and it seemed to have quite a long way to go before being as stable as Naviagtor|Communicator 4.[67].
Now, though I keep hearing people complain about the quality of Netscape's latest "main-stream" offerings for Linux, in my experience both work better than any contemporary or past GUI browser on Linux or Windows. I've yet to have a single crash with the Debian smotif-linked 4.6 or 4.7 versions--and I have used them quite extensively.
Currently I mainly use KDE's "file manager" kfm (w/libkhtmlw) for browsing, mainly because it uses less RAM than Navigator, and I find it also works extremly well.
I guess I just don't see a desperate need for a new "high-quality" browser for Linux--we already have some very good options. That's not to say I don't enthusiatically support the Mozilla project--in fact it's what finally motivated me to learn C++, and I hope I can eventually make some contributions to it.
Slashdot Mirror
Just use alien to convert the rpm's to deb's.
Grab the source and try `./configure'ing it with the --enable-x11-shm (X-shared memory support.)
I just tested the latest CVS version (not sure how different it is from the binaries they release today) using that option (also disabled debugging) on the 500+ comment "What's Banned On Your Campus?" story, and Navigator 4.7 took 21 seconds, while Mozilla took 28 (on a K6-2 300 system.)
Here's a list of the build options I used:
I hear people bitching about this on both sides of the argument. Can someone please enlighten us all as to why source code takes so much work to release, especially if that code is just being given away as opposed to released for development.
I think that the main reason programmers are usually so reluctant to release their "bleeding edge" code is pride. Writing software is every bit as much a purely intellectual endeavor as writing literature, and consequently, putting it out for the public to see is in a very real sense putting your entire intellect out for display. It can be a bit nerve wracking, to say the least.
I've had my first personal experience with this recently, and even though it was only two small scripts intended for use by a very limited audience at my local ISP, I can tell you it brings out every bit of insecurity one has to know that it's inevitable that some more (or even worse -- less) experienced coder will find and point out at least a few really silly and elementary mistakes in your code.
Doing open-source really does require some guts.
Yeah, which brings an obvious question to mind: why aren't more companies (or any, for that matter) taking advantage of libwine to port their products to Linux?
While it's great that the Opera folks went through all that effort to do a "real" linux port, wouldn't it have made allot more sense to just get their Windows source to compile with wine? I've had the native Windows version almost running properly under recent versions of wine, so I'd imagine that it would have been trivial for them to find the bugs in wine's Win32 emulation that cause problems, and either work around them, or even better, send bugfixes to the wine team and fix the problems properly.
Well... Win98 is a monster in its own right--I'm surprised that you can get it to run at all in 32MB :(. The reason VMWare wants fixed blocks of RAM is that tricking an OS into thinking it has complete control over memory that is actually managed by another OS is a complicated process, and while they probably could do it in a more dynamic fashion (only allocate physical storage for memory the guest OS actually uses), that would probably significantly increase the complexity of the code, which of course usually means increased bugginess and performance penalties.
DOSemu has a much easier job than VMWare because hardware support for x86 "real" mode virtualization is built directly into all modern Intel class processors. DOS programs also rarely use more than ~1MB of memory in any case.
WINE, of course, "Is Not an Emulator" ;). It's basically just a library that relays Win(16|32) API calls to their corresponding xlib calls. The windows apps themselves are executed directly with the help of the loader program, so it's actually a bit surprising that it uses even that much memory.
I like the idea of Debian, but it's currently too far out of date for me to use.
You can have as up-to-date a Debian system as you want: just use "unstable". Mine's currently a hybrid between an ancient Slackware libc5 installation, Debian Slink, and Debian Potato (2.2.13 kernel and an Xserver from 3.3.5-1)--all working very well together and with very few problems.
Which is as it should be. If a user want to keep logs, she can use shell redirection.Among other things, libapt isn't good at: -> keeping track of automatically performed selections and removals; each frontend has to do this itself
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
Again, this is exactly the kind of thing which should be handled by a front-end. In any case, a user can always hit Ctrl-C during a download, edit the command line, and apt-get will recover quite nicely.-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
You can put packages on hold using dselect (an annoying program, IMO, but functional), though admitedly I've had apt loudly proclaim it was going to over-ride my hold on a package, and then proceed to enthusiasticly upgrade it without even prompting me. I should probably submit a bug report on this, I suppose, but at least it acknowledged the hold was there.It probably uses KDE's "libkhtmlw" widget library to do the HTML rendering, so it should be just as good as kfm in that regard.
Do a "ldd `which progyname`" to see what libraries it links to.
Debian's "unstable" glibc2.1+smotif linked versions of Navigator and Communicator 4.[67] are all rock solid on my system, even with Java enabled.
You can get the communicator .deb's here, which you'll probably want to convert to .rpm's for your SuSE distro. with Joey Hess's alien program.
Actually, Mozilla is very modular. The loader itself (apprunner) is less than 20KB. Everything else is done with shared libraries, this biggest of which is less than 500KB.
That's not to say I disagree with everyone's main point here--that the developers should have first focused their energies on the HTML/browser component instead of the Java/email/NNTP cruft. If they had, we might not have got into this silly debate about Mozilla being a "failure" in the first place.
Well--the latest version I've tried was M9, and it seemed to have quite a long way to go before being as stable as Naviagtor|Communicator 4.[67].
Now, though I keep hearing people complain about the quality of Netscape's latest "main-stream" offerings for Linux, in my experience both work better than any contemporary or past GUI browser on Linux or Windows. I've yet to have a single crash with the Debian smotif-linked 4.6 or 4.7 versions--and I have used them quite extensively.
Currently I mainly use KDE's "file manager" kfm (w/libkhtmlw) for browsing, mainly because it uses less RAM than Navigator, and I find it also works extremly well.
I guess I just don't see a desperate need for a new "high-quality" browser for Linux--we already have some very good options. That's not to say I don't enthusiatically support the Mozilla project--in fact it's what finally motivated me to learn C++, and I hope I can eventually make some contributions to it.