Something to think about: free vs. proprietary OSes
<flamebait> So if Dillo is about 100% free software, including the OS it runs on, does that mean we should reject any patches that help Dillo run on Solaris, IRIX, AIX, HP-UX, Mac OS X and so on? If something breaks compatibility with Cygwin, should we let it slide because Cygwin only runs on Windows? What's next, dropping support for SuSE because it's less free than Debian? Red Hat because they call it "Linux" instead of "GNU/Linux?" </flamebait> Where do we draw the line... and why? Compatibility? Ideology? If someone came up with a way to get a working prototype on Mac OS classic, without any effort on your part, would you reject their contribution because the OS is proprietary? If yes, what makes Solaris different? If no, what makes Windows different? A consensus on this issue would be useful, especially the next time someone expresses interest in using Dillo on a nonconventional platform. -- Kelson Vibber www.hyperborea.org
On 2003-09-04 at 00:11 -0700, Kelson Vibber wrote:
Where do we draw the line... and why? Compatibility? Ideology?
Suggestion: the point where conditional code compilation is being scattered throughout the code. That way lies a maintenance nightmare. The OpenSSH people have to do this, because every OS is a bit different in how the login process is managed, and even there the main development is done in a "clean" branch, for OpenSSH, and the Portable stuff is maintained separately. For a more historical example, look at wu-ftpd. If differences can be cleanly abstracted, so that people don't need to worry about the differences, then it's probably fine. But if someone's devoting their own personal time to a project, finding one OS which forces #ifdefs everywhere, in every file, just to compile suggests that it's not clean and not sufficiently in line. A grep for "ifdef" in the Dillo .c files shows remarkably little in that regard (most of the ones I see are the frames+tab patch's careful segregation. The most common ifdef is for VERBOSE and after that EXTENDED_COLOR, and those tend to be confined to small spaces. For an example of abstraction of OS differences done right, I like Exim (the Mail Transport Agent). Jorge: I've been at a conference and now am on a different desktop, so am not easily able to test the alternate fix for FreeBSD and the IO errors -- since Andreas reports that things work fine for him now, I'll take it on faith that the problem has been resolved -- thanks for the prompt response! (I got forced onto a new box and made a policy decision to go GTK2 only; I had a brief look at porting to GTK2 and got more stuff compiling, but part way through realised that I'd messed up badly so dumped that. I won't have time to look at this again for a while -- sorry) -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>
On Thu, 4 Sep 2003 13:59:51 +0000 Phil Pennock <phil.pennock@globnix.org> wrote:
(I got forced onto a new box and made a policy decision to go GTK2 only; I had a brief look at porting to GTK2 and got more stuff compiling, but part way through realised that I'd messed up badly so dumped that. I won't have time to look at this again for a while -- sorry) --
familar linux 0.7 has a gtk2 dillo. gtk1.2 is not installed by default. So there should be patches for a gtk2 dillo somewhere. Perhaps that can be used as a starting point. Greetings Andreas Kemnade
Hi, On Thu, Sep 04, 2003 at 01:59:51PM +0000, Phil Pennock wrote:
On 2003-09-04 at 00:11 -0700, Kelson Vibber wrote:
Where do we draw the line... and why? Compatibility? Ideology?
And to throw in even more flamebait (which I will not defend :-) ... ) The BSD's are not really free software in the meaning of FSF's definition ;-) ... To me, it doesn't matter, though.
Suggestion: the point where conditional code compilation is being scattered throughout the code.
On the other hand, it is truely beneficial for producing clean code (i.e. not lots of ifdefs) when trying to compile on largely different platforms. I speak from experience when I say that trying to compile with a different compiler (or on a different platform) usually reveals bugs. So far, dillo is mainly compiled with gcc - I'm not sure about the various solaris efforts, though. I personally once tried IBM's xlc compiler on AIX. It mostly worked and resulted in a few minor code cleanups, that went into dillo. Hmmm, I really should try Intel's IFC or tendra at some point .... Anyways, that alone would make a native Windows port at least interesting. Not that I have any experience with Micorsofts C-compiler, nor that I know about Windows Posix compliance (didn't some Windows version receive some sort of Unix specification ?). Still, I'm sure things will show up that may be real bugs. And these are just the purely technical and objective issues that came up when reading the recent mails on this list :-)
Jorge: I've been at a conference and now am on a different desktop, so am not easily able to test the alternate fix for FreeBSD and the IO errors -- since Andreas reports that things work fine for him now, I'll take it on faith that the problem has been resolved -- thanks for the prompt response!
It doesn't lock up any more. Sometimes, I'm not sure if there are still issues or not. It simply may be the local network like DNS servers etc. As I said, I'll report problems once I'll find them :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
participants (4)
-
Andreas Kemnade -
Andreas Schweitzer -
Kelson Vibber -
Phil Pennock