Re: bloatware

> Anyone who claims X is bloatware simply has no idea what they are 
> talking about.  People who scream the loudest also tend to be 
> those who have never used oprofile and similar tools to actually 
> *measure* real runtime metrics.  They also are the ones who tend 
> to complain that X doesn't have more features such as 
> translucency, etc.

There is room for disagreement about this (if not always for X itself), but I
do have some idea what I'm talking about.  I've run releases of XFree86 for 9
years, downloaded several source releases, built from source, wrestled with
installation and configuration issues, various apps, etc.

I was also the guy who figured out what the problem was with the Mach VM in
BSD, that was causing it to thrash swap to death when large requests were
being used by X clients.  To do this I ran not only user-level measurment
tools, but also BSD's ddb in-kernel debugger.

[If you're curious about that problem:  The X server calls realloc() on each
request buffer after use to reduce it to 8K.  But the Mach VM was keeping all 
of the pages from each original allocation in the object cache, where they 
were never used again.  Causing the VM to drop the deleted pages from
the object cache fixed the problem.]

And I do NOT complain about X needing more features.  However, I and many
others have pointed out that X tends to suffer in terms of size-per-feature. 
I've always been amazed how big the server is, when at bottom about all it
does, rendering-wise, is draw lines and fill rectangles.  Sure there's more
to it than that, but as a driver person you must know.

Now don't launch into an elaborate explanation of what else is in the server.
That might just possibly be part of the point. ;)


> Adding more features while also making the runtime memory usage 
> of the X server smaller are rather mutually exclusive goals.  For 
> those who require a minimalist X server, there is kdrive.

Well, certainly those are mutually exclusive goals.  That's why it's an issue
that needs to be considered.

I'm looking into kdrive.  Unfortunately, there's not much information (I did 
find a 3rd party howto somewhere).  Also, it seems crazy to download the 
whole source tree just to build kdrive (I did anyway, because I'm curious).

But why is "require" a condition for kdrive?  You might turn it around the 
other way.  Earlier mainstream X servers were much smaller, including 
accelerated ones.  Who "required" that anything be added?  I once ran an S3 
server that already seemed outrageous at ~1.3M; by 3.3.x I couldn't build 
anything smaller than nearly twice that; and in 4.x, the "backbone" that just 
starts up and can't even run without loading a slew of modules is about the 
same size as that first S3 server -- and none of these servers does anything 
that any of the others doesn't.

And it's not just about binary size, it's also about source tree size.  And
it's not just about the server, it's about the whole installation.  And it's
not just about XFree86, it's about what you have to pile on top of it to get
a useful system going....

It just doesn't seem to have been a goal or priority for X, from the 
beginning.  If anything, the opposite.  (Memory pricing was important in the
profit profile for workstation vendors, you know.  The incentive was in the
other direction.)

But I also think where people want bloatware, they should have bloatware.  So 
for me it's a problem worth pondering (if not getting ponderous with).


> I wont bother going into details about the X server *not* 
> actually using much memory at all, and the fact that most people 
> claim X is huge and bloated by basing their assessment on the 
> broken and misleading output of programs like top and ps though.

Alright then, I will.  The text segment (program code) is demand-paged, i.e., 
only pages (4K on x86) that are actually executed in a program are actually 
read from disk into RAM.  So a program's code can look larger on disk than 
the memory that actually gets occupied by it when run.

And measurement tools don't give a realistic picture of shared library
usage, which also definitely makes things look more alarming.

You do have a good point about that, but I wouldn't go so far as to say "not 
much memory at all".... ;)

Anyway, I don't expect to win on this issue, I haven't yet.  I tried in BSD
land, and kernel builds that were once under 500K with stuff you didn't need 
are now 2 to 3 times larger without stuff you do need.  And kernels are not
demand-paged, either.  Projects just can't seem to resist those last few 
kitchen sinks in every room.

I wonder if you noticed my point about harm to the advantage of open source 
over proprietary systems, though.  Windows has evolved into bloatware as 
well, but if the only other advantage people find in open source is source 
code that is so sprawling as to be useless to them, then the cost advantage 
may also seem less compelling.


> -- 
> Mike A. Harris


-- Jim Howard  <[email protected]>