So, when things get tough, privation measures are recommended.
Didn't the Soviet Union try this for a few decades? ("Do without, until 'we'
work out the issues.")
> -----Original Message-----
> From: Adam Rifkin [mailto:Adam@KnowNow.Com]
> Sent: Sunday, March 25, 2001 12:24 AM
> To: FoRK@XeNT.CoM
> Subject: [Jeff Covey @ Freshmeat] We Are Losing the Browser War
> It's 2001, and people are advocating taking Flash,
> out of the Web. Didn't those languages arise because Web developers
> needed them?
> To see commentary on this article go to where I found it...
> We are losing the browser war
> by jeff covey, in Editorials - Saturday, January 27th 2001 23:59 EST
> Anonymous has had his eye on his Web server logs lately, and
> is worried at
> the shift in the ratio of Netscape to IE browsers hitting his
> pages. He
> worries that, if we're not careful, this trend on the desktop
> could undo all
> the progress Linux has made in the server room, and he offers
> some ideas on
> how we could fix things.
> I have been watching netcraft.co.uk. It is pleasing to see
> that Apache is
> increasing its slice of the pie with almost every new report.
> Unfortunately, I have also been looking at Web server access
> logs, and I
> have been seeing a decline in the use of Netscape with a corresponding
> increase in Internet explorer. That is a problem.
> Without a decent browser, it will be difficult for
> alternative operating
> systems to remain viable. We owe the old Netscape a great
> debt of gratitude
> for releasing a Linux version of Netscape so early on; it
> quickly made Linux
> a viable desktop, and later did the same for the other free
> Unices. Only a
> few wise men seem to realize this.
> To paraphrase Linus: "It's the desktop, stupid." Backend
> infrastructure can
> be replaced quickly; user desktops cannot, so we are
> vulnerable to being
> leveraged out of the server space. Microsoft could use its increasing
> dominance at the client side as a wedge to lift Linux out of
> the server
> room. FreeBSD's motto "The power to serve" means nothing if
> it can't serve
> up the proprietary or patented protocols spoken by the clients.
> We need some nontrivial presence on the client side to prevent the
> bastardization of protocols and file formats. Don't think
> that just because
> a file contains the pixy dust of XML it can't be made
> proprietary. I am
> convinced that there are people patenting DTDs as I write this.
> In the newer Linux distributions, we have an operating system
> capable of
> holding its own on the desktop; now we need a viable browser.
> Netscape and Mozilla have lost their way. Netscape had its
> air supply cut
> off by a better-funded opponent. Mozilla... well, I am unsure
> what to make
> of it. I am guessing that when it was released it was a mess
> understood by a
> few. Now a couple of valiant individuals have undertaken the
> thankless task
> of cleaning it up. They might even be succeeding.
> Unfortunately, it appears that Mozilla still carries the
> legacy of some poor
> management decisions. I think (and I might be wrong) that the
> plan was to
> turn Netscape into an operating system of its own. In a
> horrible way, they
> have succeeded; Mozilla is about as bloated as some of the
> largest operating
> The problem is not only that Mozilla is big and slow,
> removing it as the
> browser of choice for older and embedded systems (exactly the
> place where
> Linux is a viable contender), but also that it is difficult
> to understand.
> Heck, simply compiling it can be tricky. Getting up to speed
> on Mozilla
> appears to be difficult, so contributing is difficult.
> I believe that the strength of the Open Source movement is that its
> components are highly modular. Forget the big projects such
> as gcc or the
> Linux kernel which need to be run by experienced wizards.
> Most Open Source
> projects are small; a talented programmer can understand the
> entire system.
> If contributers get in on the ground level, they too can keep
> track of their
> own part. The modularity is much stronger than the (IMHO rubbish) OO
> methodology advocated by dubious software engineering
> textbooks. An Open
> Source system breaks into objects at the executable level --
> a level which
> both the developer and system administrator understand -- not at lower
> levels where it slows down development and execution.
> An FTP server is an object. An FTP client is an object. The
> interface is
> well-defined in a couple of RFCs. Don't like a particular
> server? Plug in
> your own! It doesn't matter if the client is written in C,
> Python, Perl, or
> Intercal. It doesn't matter how the internals of the FTP server are
> structured. It's an object. No need to rely on inconsistent
> mangling of C++
> classes in obscure libraries with undocumented interfaces and
> side effects.
> No need to worry if the object fails; if the FTP client
> crashes, the server
> keeps running. No esoteric marshaling or transport mechanism tied to a
> particular language; objects communicate via vanilla Unix
> pipes or TCP/IP.
> This point is really important. As long as the maintainers
> understand the
> internals of their object/package and there are not too many
> Open Source works beautifully. Don't like sysvinit? replace it with
> simpleinit or minit. Think you can do better than syslogd?
> Replace it with
> syslog-ng or idsa. Think inetd is vulnerable to DoS attacks?
> Try xinetd or
> tcpserver. Don't like bash? Try zsh or tcsh. Think wu.ftp is
> an exploit
> waiting to happen? Install oftpd or troll ftpd. We have an
> amazing amount of
> biodiversity (or should that be cyberdiversity?.
> Open Source objects seem to do best when a replacement can be
> written by a
> smart teenager during summer vacation or as an after hours
> project of an
> experienced sysadmin. The replacement need not do all the
> original does and
> won't be bug free, but it should be enough to show promise.
> Later, it will
> become large and nastier, but the skeleton will be the same. This is
> probably the core of the Open Source world, even if it means
> that there are
> too many half-finished IRC clients.
> Back to Mozilla. Mozilla is much larger than most Open Source
> Becoming a contributer is hard. Writing a replacement is
> harder. The people
> at the W3C appear to have fallen into the same trap as the
> people who design
> C++, and have added more and more baggage. No doubt they were
> under pressure
> to formalize the extensions added by Netscape, Sun, and Microsoft, but
> A browser is no longer something that speaks HTTP and renders
> plain HTML. It
> frames, cascading
> style sheets, and XML disasters. Building a replacement
> browser is no longer
> a vacation project for a couple of smart teenagers. Oh, sure,
> none of the
> extensions are essential to a browser, but only a minority of
> sites don't
> make use of at least one of the features.
> So, we have a problem. Mozilla is too large to attract casual
> programmers in
> the numbers it needs, and the Web itself consists of too much
> cruft. The
> entry cost of the Web browser business is considerable. Large
> companies like
> large entry costs since it keeps out the smaller players,
> including the
> volunteers. Microsoft can throw programmers at Internet explorer.
> Programmers at large corporations have to wade through spaghetti code
> whether they like it or not, and paid programmers can spend
> their days doing
> regression tests. Volunteers like doing neither of these things.
> The free software community desperately needs a decent Open
> Web browser to
> stave off the .net effort. It is probably the biggest
> software gap we have.
> Solving it won't be easy, and losing it might be fatal.
> I have thought about a number of approaches to the problem.
> One is to have
> more people working on Mozilla. Mozilla is being cleaned up -- some
> subsystems are probably quite solid by now -- but it is still
> large and
> slow. If you think you are a hotshot programmer, consider helping out
> Mozilla. If Mozilla makes a comeback, you'll be a hero.
> Another method is to simplify the Web. We need to lower the
> entry costs for
> the people writing alternative browsers. Web sites need to
> lose the Flash,
> work. If you have
> a Web page, resist the temptation to add clever stuff to it. Disable
> sites which rely
> on these things. If you visit pages which do, drop the author
> a line and
> tell him about it. Email is best. If you can't be bothered
> with email, try
> the approach I use: I request links such as
> r/ or
> http://www.someidiot.com/lose/the/flash/or/lose/this/viewer in the
> hope that somebody reads the error logs.
> Making the Web simpler is difficult, but we have a window of
> opportunity --
> cell phones and other wireless browsers are still too small
> to run a large
> browser, and WML is (rightly so) falling from favour. A
> restricted subset of
> HTML might just work. Maybe the cHTML used in Japan might be a good
> candidate (do we have a Linux cHTML browser?). We could kick
> up a stink
> about accessibility -- put pressure on sites to keep it
> simple so that blind
> and partially sighted people have a chance at viewing them.
> Emphasize the
> Point out the
> risks to ecommerce sites. Point out the savings of turfing
> the Web design
> division to the CEOs of failing dotcoms, letting them spend
> more funds on
> the backend and order fulfillment. Inform people that fancy
> Flash pages and
> Java applets won't be viewable in 20 years. Lead by example.
> Full marks for
> freshmeat using HTTP authentication and not cookies. Use the
> "best viewed
> with any browser" button. Focus on content, not looks.
> And then there are the alternative Web browsers. Konqueror is showing
> promise. Zen has the right approach. Express might be worth
> taking up again.
> Maybe we could learn from the NCSA/Apache experience. When
> NCSA httpd was no
> longer viable, some smart people put together Apache. Apache
> has something
> important going for it -- it can be easily extended. It might be worth
> trying the same for a new Web browser. Make it simple. Use
> wget to fetch the
> pages. Pipe it to a simple caching program. Have the caching
> program pipe
> the output to a simple renderer -- the GTK HTML render or maybe a diet
> gecko. Control the pipeline from a simple X interface, and we
> have a Web
> browser. X has a neat feature which lets a window of one
> application swallow
> the window of another. One of the people who designed X
> wondered why it
> wasn't used more often. Think about it -- for an HTML form input box,
> instead of using a crummy text widget, we could spawn an
> xterm the exact
> size of the text box, and use vim or any editor to fill out
> the form. It
> would be nice. It would be easy to maintain. Crashing the
> editor would leave
> the browser running.
> In the last few years, the Open Source community has made
> good progress. We
> now have several impressive operating systems. Apache is the
> most popular
> Web server, but we need to have a viable Web browser, be it a working
> Mozilla or a lighter alternative. Without it, we don't stand a chance
> against .net.
> Let's be serious. The web is getting more complicated.
> Designers like myself
> are demanding more control over presentation. Consumers are
> demanding more
> rich, interactive, and immersive experiences. And as complete
> as CSS, DOM,
> Macromedia's Flash technology - an inferior, binary, and
> proprietary format
> (everything the web was never supposed to be) - because it
> offers consumers
> and designers exactly what they want.
> But complication is not necessarily a bad thing. Space exploration is
> complicated. Microprocessors are complicated. Hell, my car is
> complicated -
> a beautiful, efficient, yet terribly complicated synergy of a hundred
> different technologies.
> The point is that the web, which is essentially a completely
> free market,
> will not be held back because progress isn't "fair" to open-source
> development. Consumers will continue demanding better
> displays. Designers
> will have to create them. Technologies which deliver will
> survive, and those
> that don't will die.
> I work with designers who will do anything to get the right
> effect. We've
> created kluges so thick they'd make you sick to your stomach.
> We've actually
> animated individual Flash objects around the screen with
> layers to get a particular effect. To suggest that such a
> breed would give
> up even an ounce of control to subsidize open-source
> development is just
> plain dumb.
> In place of emailing webmasters and thinking up snappy things
> to write in
> bogus HTTP requests, I'd like to see the open-source
> community rally around
> and support Gecko. I'd like to see an improvement in DHTML
> performance, and
> a plugin to support XSLT. Fixing those weird scrollbar
> problems would be
> nice too...
> There is a war for the web, but it's not against who you
> think. No matter
> what you think of it, Flash is gaining ground. Web authors
> are using it for
> more and more things that are difficult or impossible to do with
> cross-browser DHTML. And in contrast to the elegant and open
> nature of HTML,
> Flash is very proprietary, very binary, and very
> presentation-friendly. So
> if you want to fight the real enemy, upgrade to a decent browser and
> "demand" the efficient use of standards. Then, check out some
> of the best
> Flash implementations and learn how to match them with
> standards-based HTML,
> In the end only consumers - and the designers and engineers
> who give them
> what they want - can win. If developers want a
> standards-based web, then
> they must expand and improve the standards. Lowering consumer
> is impossible, and a complete waste of time.
> -- Aaron at http://youngpup.net/writings/i_want_my_DOM/
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:14:55 PDT