Whats with X

[Liberty Young]

On Fri, 2003-05-02 at 14:43, Rob Wultsch wrote:
> What is with it? Why is it that x is larger than a very minimal install 
> of 98 (windows lite)?
> 
> Could x not be implented in the kernnel with a very basic vesa driver 
> (so that it will automaticly kinda work) and have the process of 
> changing drivers be nontrivial?
> 
> Could a distro not package two versions of the kernel one with x and one 
> without?
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss


Of course, if we're talking about kernels here, then you don't need any
"X" or VESA drivers...just CONFIG_VGA_CONSOLE=y....You won't get
graphics out of this, but you'll be able to play nethack all day long on
your VGA console. 
---------------------------------------------------
I'd imagine that they don't offer two versions because it's not worth
the effort. There are plenty of minimalistic Distros out there, and
that's their goal...hit a specific audience, whose main objective is
tight, small, and light. 

Then you have Redhat, Debian, Suse, whose main goal is to hit a wider
audience, with a wider array of needs, whose main objective is to have a
Desktop suite of applications that "Work Out Of The Box". 

While Redhat could try to have a "light" version, the Return Over
Investment just isn't there. Let's look at OS stuff before we look at
the kernel. 

On my Mandrake 9.0 machine: 
[liberty@minime liberty]$ ldd $(which ftp)
	libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x4001f000)
	libkrb4.so.2 => /usr/lib/libkrb4.so.2 (0x40032000)
	libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40047000)
	libdes425.so.3 => /usr/lib/libdes425.so.3 (0x400a9000)
	libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x400ad000)
	libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x400be000)
	libutil.so.1 => /lib/libutil.so.1 (0x400c1000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0x400c4000)
	libresolv.so.2 => /lib/libresolv.so.2 (0x400f2000)
	libc.so.6 => /lib/i686/libc.so.6 (0x40103000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[liberty@minime liberty]$ 

On TSLinux, a small Embedded Distribution we built for our SMALL,
EMBEDDED computers, ftp has these dependencies: 

[liberty@minime TS-3.04]$ ldd usr/bin/ftp
	libc.so.6 => /lib/i686/libc.so.6 (0x4001f000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[liberty@minime TS-3.04]$ 

--------------------------------------
So what's the point? 

You'd have to have TWO SEPERATE Operating Systems, one "light" and one
"fully functional out of the box so you don't have to figure out (and
also compile) everything"...Otherwise, when the first customer who uses
ftp, hoping to use Kerberos5 or  GSSAPI, they can't. Then they'll
complain, and believe you me, they don't want to compile their own
stuff. They'd rather pay you to do it for them, so they don't have to. 

Same with the kernel. I initially built the default kernel for our
embedded board to be tight...i mean, only the things that _needed_ to be
there were there. Stuff like PPP, IPTables, drivers for Ethernet
chipsets that weren't on the board, were not compiled in. 

So now i'm in this bind where all of my customers are breathing down my
neck to compile for them a new version of the kernel that supports their
need: IPTables, or an Ethernet Chipset for a Daughter Board that plugs
into our Board, it's a nightmare. 

I made the kernel too specific for my audience, and now i'm busy
compiling kernels rather than do development. 

The ROI just isn't there.