Re: bloatware

On Sunday 30 March 2003 06:03, Jim Howard wrote:
|  > 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.
|
[...]
|
|  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.

Have you tried KDrive (TinyX) server?
It is amaazing light, and have most of the features you would expect for 
typical SysAdmin-like XFree86 install (management console, one browser window 
to configure some devices, couple of X-terms)

Another way to reduce memory usage and increase effectiveness of the code is 
to develop features inside extensions (like X-RENDER)
My point about Xr/Xc support in *default branch* of XFree86 CVS was exactly 
about this.
In addition to drawing lines and polygons, you can have extensive set of 
drawing primitives (beziers, dashed lines, etc.) at very low overhead.
IIRC, Xr/Xc sources combined is just 50K in size.  So, this is really *small 
portion* from the 57MB traball.

|
|  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).

Yes, it's indeed crazy.
I can advise to you to get RawHide (or RedHat 9) SRPM and built it on your 
install.
I did it on Mnadrake 8.2, and tomy surprise - KDrive has been built, so I even 
have binary RPM with it.
I don't rememeber though wether I needed to modify specfile for this.

You may want to ask about KDrive experience on RULE mailing list
<[email protected]>, archives at  <http://mail.gnu.org/pipermail/rule-list>
Project page: http://www.rule-project.org

I have tried KDrive  on my ATI Rage Mobility and could not get it running. 
But it can be that I passed wrong parameters to KDrive and that was the 
reason.

|
|  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....

AFAIK, just a few people were working on KDrive.
You may want to check http://www.handhelds.org, people there use KDrive with 
Compaq/HP iPAQ.
May be, they can help with less exotic install, too.

|
|  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]>
|  _______________________________________________
|  Forum mailing list
|  [email protected]
|  http://XFree86.Org/mailman/listinfo/forum

-- 
Best Regards,

Vadim Plessky
SVG Icons * BlueSphere Icons 0.3.0 released
http://svgicons.sourceforge.net