Netscape 6 Vs. 4.7x
rafa writes "Linuxworld has an informal comparison between Netscape 6, Mozilla, Opera and Netscape 4.7 with focus on resource usage. It reflects what I've been experiencing with Mozilla." A lot of this is well known, but the article does a good job of bringing it all together.
Years ago the WordPerfect for Windows 5.1 was released. A WYSIWYG word processer that ran with 8 mb ram, and about 40 meg hard drive space. The fact is: there is no reason that WinME should take 550 Meg alone on my hard drive.
I'll grant you that features creep in, and users demand more and more and more features. But, newer programming classes fail to teach students some very basic important things. And what I speak of, is the often repeated line, that I've heard spoken in the classroom, and by a great many professional programmers, "RAM is cheap."
Coding is taking less and less effort, not more. Any fool with a copy of Visual Basic or Visual C++, can create a passible text editor. Compare this to the days of hand optimized assembly, where one must stretch the processor beyond its current capabilies, getting every ounce of RAM out as possible. Intelligent, well thought out designs, were the only way you could create a solution that would run well.
Now, Linux is one of the few enviroments where talented programmers have joined together to create something nice. In terms of requirements, the Linux world is moving at a much slower pace than most other industries. It is actually possible to runt the latest version of slack on a 486DX4-100 with 24 mb of ram, use an older version of netscape(or mozilla), and have things feel a bit slow, but the system be usable. This was the configuration of my Compaq laptop, which I used until I sold a week ago. :P
But their is much software where, the often repeated statement, "RAM is cheap", pops up. Even in Linux. I find the whole situation disgusting myself. One should not justify not thinking fully through a program with this qualification. Clever algorithems, thoughtfull code, and interesting tricks are no longer allowed. Coding has begun to become something for the braindead. And the sad thing is, that many corporations will hire these pimple faced teen VB programmers that have no knowledge of algorithem analysis, and have little to know experience writing anything else than yet another Visual Basic Calculator.
------ 24.5% slashdot pure
I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:
This was back in my bad old days of being a college dropout, hungry with no idea what I was going to do for a career. I told him I thought that would be a terrible place to work, the boss would always be bugging you to work harder.But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.
And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)
I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.
I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?
I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.
Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.
My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.
While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.
A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?
I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.
The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.
At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.
I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.
Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.
My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks
Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
Uh, doesn't adding memory totals from top give an inaccurate picture of real memory usage because it counts shared pages multiple times?
E.g., if I fork() (which is pretty much the same as making a new thread in the Linux world), all the text pages that are shared will be listed under the memory total for both the parent and child process in top. If I sum the memory usages, then, I'm counting the shared pages twice.
Which can give an unfair appraisal of the memory hunger of a multithreaded program.
Quite honestly, I've recently decided that NCSA Mosaic is still the best browser out there. I've got an x86 box at work, so I downloaded the (statically linked, thank goodness) binary and messed around with it.
Whoa. Nostalgia trip.
Thing is, though, it's got so many things that newer browsers don't even bother with. Like making clicked links dashed instead of solid underlined. (Kinda relevant for those color-blind users mentioned a while back.) And allowing you to select fonts for each heading level (don't think it's in that version, but I remember doing that in Mosaic on Solaris). And letting you quickly flip between a fontset for the whole document.
Oh yeah, and Mosaic is fast. Maybe that's because it focuses all its resources toward actually displaying HTML, and not trying to turn itself into some kind of sick Turing machine/security hole.
A few updates would be nice... Cookies, SSL, maybe style sheets. But overall, I just wish people would bother to consider all the "accessability features" and "performance enhancements" that always existed, but were simply forgotten.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
I'm typing this from my workstation at my client's office, a web application company (I've clocked out). I'm using whatever Netscape came from the Debian site when I updated my software on Monday when I started.
Read about my laptop which was my main development machine for most of the last year. It boots NT, Slackware and BeOS.
You can read my resume - note the long list of products I've shipped, and keep in mind I haven't been keeping that list up to date. See the long list of projects I've done in the two and a half years I've been a consultant.
Note that among the jobs I've held was Senior Engineer at A Big Fruit Company where I held the role of "Debug Meister" - I did low-level debugging and in fact performance tuning of the Mac operating system.
When a tester found that an application would crash under a new system build and they didn't understand what component was at fault, it came to my team (Traditional OS Integration, formerly known as the Blue Meanies). We would track down the bug and assign it to the right engineer or fix it ourselves.
Note that sometimes, probably half the time, the bug was due to a third-party app bug, and we determined this purely by running MacsBug, an assembly level debugger, inside the app and system software. We had the entire Mac OS source code at our disposal but this wasn't usually readily available when you were visiting a crashed Mac at a tester's cube so you just had to know your MacBug.
I use and contribute to open source. My latest effort was aiding the author of the ZooLib cross-platform application framework in releasing his library under the MIT License; I worked with Andy Green for a year to test his code by developing a product with it and led a beta test of developers who also developed products with it.
I found ZooLib to be an incredibly enlightening example of well-architected, efficient and compact code for what it does. Just using it and reading the source code increased my own abilities as a programmer and architect tremendously.
You can read some of my thoughts on the business and technique of programming at GoingWare's Bag of Programming Tips
Linux is better than most as far as efficiency is concerned, but don't get me started about reliability and ease of use.
As for what I think is a well engineered OS, try the BeOS but you don't want to get involved with the company.
Read why I think developers need to take back control of their lives from operating systems vendors and how I think they ought to do it. If you really want the full-bore opinion, read The Cross-Platform Manifesto
So yes, I am in fact a developer, thank you. It's just that I maintain high standards and I like to encourage others to do so as well.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
Unfortunately, a number of design decisions were errrr less than optimal. The XUL user interface language seems to have a big impact on performance. And leaving aside whether one likes the UI or not, the fact that it behaves different than other apps on any given platform also leaves a lot to be desired (to Mozilla's defense, both Microsoft and Apple have gone down the tubes in this area as well, for example, I'm abhorred by Windows 2000's "browser like" clicking, where a single click will open a file rather than selecting it, and it isn't particularly obvious when it behaves the old way or the new).
Anyway, to be able to fix something in Mozilla requires a significant investment of time on the part of the contributor. In the first Mozilla releases, which were based on the 4.x user interface, I could usually locate something I want to fix in an acceptable amount of time. Now, with the overhaul and the complete switch to C++, I spend hours grovelling through the thing, usually without coming up with an answer.
So, open source or not, Mozilla's improvement still hinges in great part on the full time developers, who live and breath that code base. For me, and I think for a lot of other contributors, it has just become too complex.
I have high hopes for its evolution over time, but it won't be soon that it will be as fast as 4.x. It will be interesting to see how spinoffs like Galeon will handle leveraging functionality from Mozilla. Time will tell whether XUL will become a boon to browser extension development, or remain a drag on the UI performance...
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Netscape dropped LiveConnect, which is the way Netscape plugins comminicated with Javascript. They say that old plugins that require LiveConnect will "fail silently". They are correct, assumming that your definition of "fail silently" under Windows NT is "attempt to access a NULL pointer and crash the application".
They have a replacement for LiveConnect. It is almost completely undocumented. There is no SDK.
Geez, if I were a plugin developer, I'd be way pissed, and would hesitate to bother supporting Netscape 6.
Oh wait, I am a plugin developer.
The cake is a pie