* Patrick Mauritz oxygene@studentenbude.ath.cx [2004-02-18 21:25:32 +0100]:
<snip>
kgi-wip.sf.net, #kgi on irc.freenode.org
also take a look for mentions of kgi on the linux-kernel mailing list. the situation is similar to UDI (you'll get _roasted_ from all sides)
Well, I know such things, i.e. when I was recently talking on the mplayer-dev-eng about moving out codecs to a general-purpose codec-lib. (there's now such a project, called media-api, where matroska people and some mplayer folks live peacefully ;-))
You shouldn't really care about this.
At least you've got a killfile ;-)
Why not a new kernel branche / inofficial patches ? If the code is good, they'll someday take it into the official distro.
where "someday" might be when epoch equals infinity, depending on who's toes you step on. (see kgi on lkml)
Well, for me it doesnt matter. I've no trouble with patching the kernel. On many larger projects it is quite normal (i.e. the MUA mutt has many "inofficial" patches, which are good but not yet included in the main distributions). Often it is because the maintainers feel the patches are not "good enought" for getting into main branch. Thats no problem for me - and no real reason for starting completely from scratch :)
<snip>
Many good kernel projects were developed outside of the main tree for a very long time, i.e. isdn4linux, capi4linux, alsa, ...
in which way is that different to writing your own kernel, if you have to redesign or improve most of it, anyway - except for bootstrapping a working
What's wrong with the memory management and the vm subsystem ? What's wrong with the filesystem ? What's wrong with the socket interface and the networking stuff ?
I can understand, if you dont like Xwindow - for just local applications its perhaps a little bit bloated, but if you gonna use remote displays, you dont really want RDP ...
<snip>
personalities ?
like on WinNT: Posix+, Win32, OS/2, DOS - all of them are different personalities of the OS in the way that they represent a different interface to client applications, yet building on the same foundation.
Ah, several different vm subsystems. There was something for some other unices, but I dont know if its still in the kernel.
On Linux those things are normally done in userland, but this doesn't necessarily have to be optimal ... that's what I meant with kernel support for wine.
cu