Re: wxWindows and GNOME

[bob cs csoft net]

Well, then how do you suggest easily creating vfs features that all
programs can use, without modifying the 4,000 + programs out there...
That is a lot of code to modify.

There are only 2 places that a file system can be implemented that all
programs can use without modifications.

1. the kernel. a kernel module would work, but since no 2 unix's can agree
on a module system, it would not work to well. One way around it would be
a vfs nfs server. All unix's can use nfs, and then all programs could take
advantage of the virtual file systems.

2. libc. filesystems are the job of the kernel, but vfs could be folded
into libc to provide vfs features to all programs linked to them. The
problem with this is getting the source for the libc. modifying glibc to
support vfs would work. Only the programs linked to glibc would gain the
vfs, but it requires much much less work to recompile a probram across
glibc then it does changing the code to work with a different library.


VFS is not really that important. If you choose not to use glibc you will
not be able to use http as a filesystem. All programs will still work
without vfs. You can't do vfs now, so whats the problem? Changing 4,000+
programs so that the closed model oses can gain some simple nonimportant
features without alittle work (adding glibc) seems to be alittle extreme.

On Mon, 30 Aug 1999 allbery@ece.cmu.edu wrote:

> On 30 Aug, bob@cs.csoft.net wrote:
> +-----
> | Um, did I say REQUIRE? (no, that want me)
> | I said that it could be added.
> +--->8
> 
> You assume that I want to have to deal with multiple *libc*s.  That
> breaks systems, sometimes even when they're designed to stay out of
> each other's way (e.g. Linux libc5 vs. libc6/glibc2.0 vs. glibc2.1).
> It's not acceptable AT ALL for non-Linux; forget about it.
> 
> I repeat:  glibc on non-Linux not an option, period.
> It's not a case of "resisting free software".
> It's a case of not breaking systems that MUST work.
> 
> And with glibc not an option, GNOME must NOT rely on or even expect
> glibc features.
> 
> # # #
> 
> I will add that the glibc folks have heard the "you ought to support
> `http://...'" thing before, and it still doesn't.  It's pretty clear
> that you can forget that idea as well.
> 
> -- 
> brandon s. allbery	[os/2][linux][solaris][japh]	 allbery@kf8nh.apk.net
> system administrator	     [WAY too many hats]	   allbery@ece.cmu.edu
> electrical and computer engineering					 KF8NH
> carnegie mellon university	  ["better check the oblivious first" -ke6sls]
>