C++ is hardly "off the OO deep end". Not in the sense that Smalltalk, or even Java, is. In the words of it's creator:
C++ is a multi-paradigm programming language that supports Object-Oriented and other useful styles of programming. If what you are looking for is something that forces you to do things in exactly one way, C++ isn't it. There is no one right way to write every program - and even if there were there would be no way of forcing programmers to use it.
As a longtime C++ user, I can attest to this fact from personal experience. In fact, there have been times when I've wished C++ was more OO than it is.
Isn't that an awfully low standard? Kind of like saying a rule of thumb for picking a book on baking bread is to put it back if it doesn't mention flour. Well of course; but that leaves room for plenty of bad books to make the cut. A C book would have to be trully awful not to mention malloc. In fact, I have a hard time believing such a book exists. A more accurate rule would be "If the book doesn't mention malloc, put it back - you picked up a C++ book by mistake, idiot".
Debian's got a lot of (nifty) quirks, few of which are well-documented. Many tasks are automated by Debian-specific tools; but good luck discovering those tools on your own. Many configuration files have been modularized or otherwise tweaked as compared to their Red Hat counterparts. It would be nice to have a system admin book that focused on the Debian Way of doing things.
I have no opinion about this news; but I hope it prompts a few more people to make the effort to read through Hans Resiser's brilliant whitepaper. The first time I read that article I was blown away by the amount of thought the guy has put into the design of file systems. The first OS to thoroughly exploits his ideas will revolutionize computing.
A number of projects have worked on making "persistent" operating systems which could save their entire state across powerdowns. The TUNES project is one that comes to mind. There are other projects that are more concrete and farther along. A quick google search turns up this page, among many others.
Actually, if you want to play with a persistent programming environment, download a Smalltalk environment. Smalltalk environments are able to serialize themselves to image files. When subsequently re-serialized, the state of all the objects in the system at the time of serialization is restored.
To the question "Can OO programming solve engineering problems", I would answer an emphatic yes. However, the engineering that I do at my place of work has to do with coordinating RADAR tracks in an air traffic control system, among other things. OO principles are applied to this domain with excellent, elegent results. The problems you are talking about (though I don't pretend to understand them) sound like very specific mathematical ones which are probably best solved in a procedural fashion, perhaps packaged up neatly into a class. However, just because it's the only engineering problem you are faced with, don't make the mistake that OO design principles cannot be applied to any engineering problem domain.
I don't let my kids have any toys that involve guns. Not because I'm a gun-hating peacenik; not because I'm a reactionary religious drone. I'm (emphaticaly) neither of the above. What I/am/ is someone who expects someday to own, and to teach my children to use those firearms safely and responsibly. I don't want them *ever* to think of a gun as something one plays with, even in pretend. I want them to always remember guns are deadly tools that should be taken very, very seriously.
I think this response says a lot about RMS's personal character. Some salient quotes:
In our community I often encounter personal insults, sometimes simply reflecting personal enmity, sometimes used as a tactic. You know what I mean. Could you face such hostility for years and respond as dispassionately as this?
and:
People have given me have a reputation for being uncompromising.
and especially:
By nature, I am not diplomatic at all.
Whatever people say about his being "out of touch", I think this shows that he is well aware of the criticisms levelled at him. He is also admirably aware of his own stubborn nature, and of the ideals he stands for. This guy knows what he's fighting for, knows his personal limits, and has no illusions about how he comes across to others.
By virtue of the
FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.
By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.
In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.
Lately I've found that using SWIG makes this pattern very easy to apply in real life.
XFree86 supports the SHAPE extension. Have you never tried the round clock, or XEyes? Or any of the fancy-ass skinnable MP3 players? X has had support for that for many years. It has nothing to do with KDE.
Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.
One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.
I took a look at your page, and what you described were all common techniques used in C++ coding. Instead of BetterC, why not just recommend people code in C++, after first reading a little Stroustrup, Meyers, and Meyer to learn how to do it _right_?
For example, in your memory allocation examples: that's what std::auto_ptr is for. Use auto_ptrs to point to your memory; if something fails, and you wind up throwing an exception, any allocated memory will automaticly be freed as the stack unwinds. Better yet, encapsulate *all* resource allocation inside classes, and make sure their destructors take care of freeing allocated resources. Shazam, resources will always be freed up when you a) exit the enclosing scope, or b) throw an exception.
Pre- and postconditions, as well as invarients, are equally easy to implement in C++. So my question is, if you have an aversion to coding in Eiffel, why not just use C++ instead of reinventing it?
The amazing feature is that mp3 files don't have to be stored locally on the device but can be streamed via AirPort from any Mac that has an AirPort-card and iTunes 2 installed which is going to be released on Tuesday as well.
Typical Mac users, getting all googly-eyed over age-old technology.
Konq is the *only* file manager I've ever used that made changing file associations easy - just right-click on any file and hit "Edit File Associations" (or something like that). Konq then takes you straight to the File Associations editor, with the filetype of the file you clicked already selected and ready to edit. And if you want to change a different file type, you can do searches with globbing to find the FileType(s) corresponding to any given extension.
Still, extensions are a fundamentally broken and archaic way of handling associations. Bring resource forks to Linux!
Now, don't get me wrong, I'm not a mindless Emacs zealot. I
happen to think that Vi and Emacs are both (gasp) pretty neat. I
was introduced to Emacs a year or so ago, and decided that it
would be in my best interests as a hacker to make myself learn it.
I'm still in that process, but so far it's paid off tremendously.
The power of Emacs is in the amazing integration of it's
various extensions. As an example. Right now, I'm editing a perl
script. At the bottom my screen, the "modeline" says this
(abbreviated):
XEmacs: PasswdFile.pm 'set_up' S0 (CPerl ARev DCln Avoid
Font Fill Abbrev)----L11--C0ll
Let's go through those codes one at a time:
'set_up': this is an indicator provided by
an extension called function-menu that tells me which function
I'm editing. The same extension also creates a menu of
functions in the current file. It's completely seperate from
any language-specific editing mode; and apparently uses a
generic library to determine what functions exist in the
current file. This means the extension itself doesn't have to
change to be able to recognize functions in a new language.
S0: This tells me I'm on screen
zero. It's provided by an Emacs screen-management extension
that works independently from (but seamlessly with) all other
loaded extensions.
CPerl: This says I'm in CPerl-mode, a
sooper-dooper Perl code editing mode. It provides all sorts
of handy keyboard shortcuts and auto-formatting, as well as
the logic that other extensions use to customize themselves to
Perl code (like how to tell a comment, so font-lock-mode can
colorize comments, etc. properly).
ARev: This means that the buffer is in
auto-revert mode. Whenever another program modifies the file,
it updates appropriately. This is completely seperate from all
other extensions.
DCln: This indicates dryclean-mode. The
buffer will be stripped of extraneous tabs and spaces whenever it
is saved. Again, this is independent from other extensions,
and could be used on any type of file.
Avoid: This mode moves the mouse pointer
away from the text I'm editing, so it won't be in the way.
Once again, completely independent of other extensions.
Font: This means my code is being
colorized, according to the patterns provided by CPerl mode.
Fill: This means my comments will
automatically be formatted to stay within the column limit I've
set, and will be properly indented and have '#' characters
prepended whenever a new line is started. This mode adapts
itself to whatever language is being edited, and adds the
appropriate markers to comments.
Abbrev: This mode interactively expands
abbreviations I've defined as I type them.
All of these extensions are independant from each
other; they can be mixed and matched at will; and many can be
used equally well in dozens of other types of files. Yet they
all coexist happily in this one buffer, and even help each
other. This is the kind of integration of little tools
that the modern desktop needs; and so far, no one has attempted
it since Emacs. All the many incompatible component
technologies are based on the "fear and loathing" model -
components are closed little black boxes, with their own little
piece of the screen, and a few methods that they grudgingly make
available to the outside world. This model, while very clean
and attractive to OO programmers such as myself, doesn't lend
itself to the kind of friendly, trusting, pervasive integration
that Emacs features. Yes, all these extensions daringly allow
other pieces of code view and even (gasp) change their
"private members". The downside of this? Horrifyingly complex
dependencies. The advantage? an amazingly well-integrated piece
of software.
Until programmers can figure out how to provide this kind of
pervasive integration within a modern GUI environment, the
XPCOMs, Bonobos, KParts, etc. of the Linux world will simply
remain programmer's tools, rather than timesavers for users. I
believe that this article espouses a noble goal, but any hackers
trying to implement it should look first to the past. They
should remember this proverb, which I just made up:
Every good idea you have has probably already been coded,
in Emacs Lisp
There's nothing "recent" about that idea. Stallman, and thus the FSF, have been pushing the idea that "all software should be free" since the GNU project's inception in the 70s. That's his whole point. You and I may disagree with his beliefs; but the FSF is not "shooting itself in the foot" by continuing to promote the same philosophy they always have.
The less-defined "Open Source Movement" on the other hand, might possibly be construed as being hurt (by association) by the FSF's dogma. But that's no concern of the FSF; they aren't Open Source advocates, and they aren't beholden to anyone's ideals but their own.
...Isreal and palestine should lay down their arms and live in peace; the oil companies should all band together to clean up the environment; all the children in the Third World should be fed; science should invent a cure for AIDS; and Palm should open-source BeOS.
In the meantime, the author of this article ought to turn his attention to explaining to managers *why* they should care about beautiful software design. Until management gives us the time and budget to do otherwise, we engineers are just going to keep on writing code as well as we can within the contraints we're given. It's not like we *enjoy* writing crappy software.
> I would suggest you actually use Python before you start guessing about what it is like.
Likewise, I would suggest you actually *use* Perl and Smalltalk before you start comparing Python to them. While I'll admit I don't know a lot about Smalltalk, I *do* know that it is based on a much more strictly Object-Oriented concept than Python. Like anothor poster said, even Java is more like Smalltalk than Python. Not that this is (IMHO) necessarily a good thing. But sheesh... just because something has OO features doesn't mean it's "like Smalltalk". Python's OO-ness is more like C++ than it is like Smalltalk.
> You can't use Python like Perl even though it has
> a strong, Perl-compatible regular expression
> library
So, Perl's sole feature is strong RegEx support? Wow, thanks for enlightening me. All along I thought it was a unique computer language, and it turns out it's just glorified grep. That's awfully dissapointing. Well, I guess I'll get back to my Python book...
Saying something is "like Perl" because it has good RegEx support is like saying a Gazelle is like a Studebaker because they both have horns.
The power of Perl is (to me) the ability to craft unreadable, unmaintainable little tools *incredibly quickly*. Ruby gives me the shortcuts to do the same, and then later clean them up into code that's just as structured and clean as Python. The attitude of all the python documentation I've read is that you should never, *ever* write quick&dirty tools, and that's why Python doesn't have the (admittedly ugly) shortcuts Perl offers.
I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.
Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.
So just give it time. I think it's well on it's way to world domination.
Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.
Companies have been providing this type of service for awhile. Flyswat has a browser plugin that recognizes names of companies, sports teams, famous people, books, etc. on web pages and puts special hyperlinks to more information under them. I understand the latest version of the Alexa ("What's Related") plugin does something similar. GuruNet doesn't actually change the look of the page, but it allows you to alt-click on any word in a page to pop up a window of related information. ThirdVoice got into trouble with a lot of companies because their plugin let users annotate any site's page with their own comments, which could only be seen if you had the 3V plugin.
In all these cases, the actual web pages are never touched; they are simply annotated on the client side. I don't recall there being any law against a user agent modifying an HTML page when it is displayed. I'm sure if corporations had their way, they wouldn't allow me to use my own stylesheet to view their pages (an option in both IE and Netscape); but I still can, because HTML was never intended to strictly control how content is displayed. If a user agent wants to intersperse every page with links to it's producer's web, well, why not? It may be annoying, but there's nothing illegal or even immoral about it.
Slashdot Mirror
C++ is hardly "off the OO deep end". Not in the sense that Smalltalk, or even Java, is. In the words of it's creator:
As a longtime C++ user, I can attest to this fact from personal experience. In fact, there have been times when I've wished C++ was more OO than it is.
Isn't that an awfully low standard? Kind of like saying a rule of thumb for picking a book on baking bread is to put it back if it doesn't mention flour. Well of course; but that leaves room for plenty of bad books to make the cut. A C book would have to be trully awful not to mention malloc. In fact, I have a hard time believing such a book exists. A more accurate rule would be "If the book doesn't mention malloc, put it back - you picked up a C++ book by mistake, idiot".
...that despite being glad someone is finally lobbying for open-source software, I felt vaguely dirty after reading this article?
ick... I need to wash my hands...
Debian's got a lot of (nifty) quirks, few of which are well-documented. Many tasks are automated by Debian-specific tools; but good luck discovering those tools on your own. Many configuration files have been modularized or otherwise tweaked as compared to their Red Hat counterparts. It would be nice to have a system admin book that focused on the Debian Way of doing things.
It's called More Than A Gigabuck
I have no opinion about this news; but I hope it prompts a few more people to make the effort to read through Hans Resiser's brilliant whitepaper. The first time I read that article I was blown away by the amount of thought the guy has put into the design of file systems. The first OS to thoroughly exploits his ideas will revolutionize computing.
Actually, if you want to play with a persistent programming environment, download a Smalltalk environment. Smalltalk environments are able to serialize themselves to image files. When subsequently re-serialized, the state of all the objects in the system at the time of serialization is restored.
To the question "Can OO programming solve engineering problems", I would answer an emphatic yes. However, the engineering that I do at my place of work has to do with coordinating RADAR tracks in an air traffic control system, among other things. OO principles are applied to this domain with excellent, elegent results. The problems you are talking about (though I don't pretend to understand them) sound like very specific mathematical ones which are probably best solved in a procedural fashion, perhaps packaged up neatly into a class. However, just because it's the only engineering problem you are faced with, don't make the mistake that OO design principles cannot be applied to any engineering problem domain.
I don't let my kids have any toys that involve guns. Not because I'm a gun-hating peacenik; not because I'm a reactionary religious drone. I'm (emphaticaly) neither of the above. What I /am/ is someone who expects someday to own, and to teach my children to use those firearms safely and responsibly. I don't want them *ever* to think of a gun as something one plays with, even in pretend. I want them to always remember guns are deadly tools that should be taken very, very seriously.
"Sadly, few people seemed to have heard much about Ruby, something they
will probably come to regret in time."
I think this response says a lot about RMS's personal character. Some salient quotes:
and:
and especially:
Whatever people say about his being "out of touch", I think this shows that he is well aware of the criticisms levelled at him. He is also admirably aware of his own stubborn nature, and of the ideals he stands for. This guy knows what he's fighting for, knows his personal limits, and has no illusions about how he comes across to others.
This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:
In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.
Lately I've found that using SWIG makes this pattern very easy to apply in real life.
XFree86 supports the SHAPE extension. Have you never tried the round clock, or XEyes? Or any of the fancy-ass skinnable MP3 players? X has had support for that for many years. It has nothing to do with KDE.
Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.
One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.
The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.
No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.
I took a look at your page, and what you described were all common techniques used in C++ coding. Instead of BetterC, why not just recommend people code in C++, after first reading a little Stroustrup, Meyers, and Meyer to learn how to do it _right_?
For example, in your memory allocation examples: that's what std::auto_ptr is for. Use auto_ptrs to point to your memory; if something fails, and you wind up throwing an exception, any allocated memory will automaticly be freed as the stack unwinds. Better yet, encapsulate *all* resource allocation inside classes, and make sure their destructors take care of freeing allocated resources. Shazam, resources will always be freed up when you a) exit the enclosing scope, or b) throw an exception.
Pre- and postconditions, as well as invarients, are equally easy to implement in C++. So my question is, if you have an aversion to coding in Eiffel, why not just use C++ instead of reinventing it?
Konq is the *only* file manager I've ever used that made changing file associations easy - just right-click on any file and hit "Edit File Associations" (or something like that). Konq then takes you straight to the File Associations editor, with the filetype of the file you clicked already selected and ready to edit. And if you want to change a different file type, you can do searches with globbing to find the FileType(s) corresponding to any given extension.
Still, extensions are a fundamentally broken and archaic way of handling associations. Bring resource forks to Linux!
And the name of it? Emacs/XEmacs.
Now, don't get me wrong, I'm not a mindless Emacs zealot. I happen to think that Vi and Emacs are both (gasp) pretty neat. I was introduced to Emacs a year or so ago, and decided that it would be in my best interests as a hacker to make myself learn it. I'm still in that process, but so far it's paid off tremendously.
The power of Emacs is in the amazing integration of it's various extensions. As an example. Right now, I'm editing a perl script. At the bottom my screen, the "modeline" says this (abbreviated):
XEmacs: PasswdFile.pm 'set_up' S0 (CPerl ARev DCln Avoid Font Fill Abbrev)----L11--C0ll
Let's go through those codes one at a time:
All of these extensions are independant from each other; they can be mixed and matched at will; and many can be used equally well in dozens of other types of files. Yet they all coexist happily in this one buffer, and even help each other. This is the kind of integration of little tools that the modern desktop needs; and so far, no one has attempted it since Emacs. All the many incompatible component technologies are based on the "fear and loathing" model - components are closed little black boxes, with their own little piece of the screen, and a few methods that they grudgingly make available to the outside world. This model, while very clean and attractive to OO programmers such as myself, doesn't lend itself to the kind of friendly, trusting, pervasive integration that Emacs features. Yes, all these extensions daringly allow other pieces of code view and even (gasp) change their "private members". The downside of this? Horrifyingly complex dependencies. The advantage? an amazingly well-integrated piece of software.
Until programmers can figure out how to provide this kind of pervasive integration within a modern GUI environment, the XPCOMs, Bonobos, KParts, etc. of the Linux world will simply remain programmer's tools, rather than timesavers for users. I believe that this article espouses a noble goal, but any hackers trying to implement it should look first to the past. They should remember this proverb, which I just made up:
There's nothing "recent" about that idea. Stallman, and thus the FSF, have been pushing the idea that "all software should be free" since the GNU project's inception in the 70s. That's his whole point. You and I may disagree with his beliefs; but the FSF is not "shooting itself in the foot" by continuing to promote the same philosophy they always have.
The less-defined "Open Source Movement" on the other hand, might possibly be construed as being hurt (by association) by the FSF's dogma. But that's no concern of the FSF; they aren't Open Source advocates, and they aren't beholden to anyone's ideals but their own.
...Isreal and palestine should lay down their arms and live in peace; the oil companies should all band together to clean up the environment; all the children in the Third World should be fed; science should invent a cure for AIDS; and Palm should open-source BeOS.
In the meantime, the author of this article ought to turn his attention to explaining to managers *why* they should care about beautiful software design. Until management gives us the time and budget to do otherwise, we engineers are just going to keep on writing code as well as we can within the contraints we're given. It's not like we *enjoy* writing crappy software.
> I would suggest you actually use Python before you start guessing about what it is like.
Likewise, I would suggest you actually *use* Perl and Smalltalk before you start comparing Python to them. While I'll admit I don't know a lot about Smalltalk, I *do* know that it is based on a much more strictly Object-Oriented concept than Python. Like anothor poster said, even Java is more like Smalltalk than Python. Not that this is (IMHO) necessarily a good thing. But sheesh... just because something has OO features doesn't mean it's "like Smalltalk". Python's OO-ness is more like C++ than it is like Smalltalk.
> You can't use Python like Perl even though it has
> a strong, Perl-compatible regular expression
> library
So, Perl's sole feature is strong RegEx support? Wow, thanks for enlightening me. All along I thought it was a unique computer language, and it turns out it's just glorified grep. That's awfully dissapointing. Well, I guess I'll get back to my Python book...
Saying something is "like Perl" because it has good RegEx support is like saying a Gazelle is like a Studebaker because they both have horns.
The power of Perl is (to me) the ability to craft unreadable, unmaintainable little tools *incredibly quickly*. Ruby gives me the shortcuts to do the same, and then later clean them up into code that's just as structured and clean as Python. The attitude of all the python documentation I've read is that you should never, *ever* write quick&dirty tools, and that's why Python doesn't have the (admittedly ugly) shortcuts Perl offers.
--
I think as long as it's use is based on it's usefullness (which has been the case with most scripting languages), it's only a matter of time.
Ruby has been as much of a pleasent surprise to me as Perl was back when I first learned it. No, it's not "Perl with Objects"; Perl itself does that quite well. It's more like Smalltalk, only readable, pragmatic rather than idealistic, and as expressive and concise as Perl when you want it to be. Personally, i think Ruby is a much greater threat to Perl than Python is, in the long run. Rather than forcing you to do it Guido's Way, you can do it the Perl Way, or the Smalltalk Way, or the Functional Way... or any combination of the above. No wonder the Pragmatic Programmers wrote a book on it. It does TMTOWTDI better than Perl does TMTOWTDI; while remaining relatively simple and clean.
So just give it time. I think it's well on it's way to world domination.
Oh, and as for a CPAN-like code archive for Ruby, there's a somewhat embrionic one here. There is discussion currently going on at the RubyWiki on how to implement a CPAN-like system for Ruby only avoiding the problems that CPAN has.
--
In all these cases, the actual web pages are never touched; they are simply annotated on the client side. I don't recall there being any law against a user agent modifying an HTML page when it is displayed. I'm sure if corporations had their way, they wouldn't allow me to use my own stylesheet to view their pages (an option in both IE and Netscape); but I still can, because HTML was never intended to strictly control how content is displayed. If a user agent wants to intersperse every page with links to it's producer's web, well, why not? It may be annoying, but there's nothing illegal or even immoral about it.
--
Thank you very much for these URLS. I'm happily playing with OO-Browser right now :-)
--
It was just a badly chosen name.
--