rule-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Rule-list] My intro, and some thoughts (long)


From: chris clark
Subject: [Rule-list] My intro, and some thoughts (long)
Date: Mon, 27 May 2002 23:42:59 +0000

Okay, I've joined the list, and a short intro was requested.
I'm Chris, and I've been using redhat since 5.0 
I'm a fan of efficient software, and distressed to see RH's 
increasing bloat. I do mechanical design work using Pro/Engineer
solid modeling software for a living, but I'm "between jobs".
I worked on the housing for the lucent phone which is now the TuxScreen.
(http://tuxscreen.net/)


I typically use unix at work, and I've experienced the HP,DEC, and SUN flavors.
I run linux exclusively at home.

I have a *little* programming experience, enough to have a feel for what's 
possible,
but I'm no developer, by any stretch of the imagination.

I've customised menus, init scripts, runlevels, etc. before.

My "good box" is a P100, since the mobo died (was k6-300)  and I'm low on cash.
I also have a 486-25 256 color NCR laptop with no CDROM.
To install linux on it, I pull out the HDD, and use an adapter from 
compgeeks.com
to temporarily place it in a better machine. When RH stopped supporting SX (no 
math)
CPU's, I upgraded(!) it to a DX chip.

Okay, intro over. 
On to some ideas for discussion.

Since it's pretty slow, I've tweaked some things.

The biggest slowdowns in boot times seem to be XFS (font server), kudzu, and 
the depmod -a .


jamie zawinski (of netscape fame) has some info on removing the font server, 
and substituting
hardcoded font paths at:

http://www.dnalounge.com/backstage/src/kiosk/laptops/

He says:
----------------------------------------------------------------------------------------
Turn off ``xfs'', the X Font Server. Once we make things read-only, it won't 
work any more and I 
didn't bother figuring out why. It doesn't matter, we don't really need it. 
Turn it off like so: 

               chkconfig xfs off

          Then edit /etc/X11/XF86Config to add real font paths: 

               FontPath "/usr/lib/X11/fonts/75dpi/" 
               FontPath "/usr/lib/X11/fonts/misc/" 
               FontPath "/usr/lib/X11/fonts/CID/" 
               FontPath "/usr/lib/X11/fonts/Speedo/" 
               FontPath "/usr/lib/X11/fonts/Type1/"

----------------------------------------------------------------------------------------
I've had reasonably good results with relatively few fonts, but I'm not picky.

Alternatively, I'm wondering why the font server gets started at boot, instead 
of as part of the 
"startx" sequence. Furthermore, might it be possible to have hard paths to some 
common fonts,
so X can start up fairly quickly, and then start up the font server later, 
perhaps with a low
priority ,and once it's running, renice it to the proper "working" priority? 
Can someone with 
a more detailed knowledge of fonts under X-Windows comment?

similarly, does the slocate database need to be built immediately and at full 
priority, or could
"sleep" and "nice" prevent locking up a shiny new install on it's first boot?




According to the lilo documentation:
http://www.tu-chemnitz.de/linux/Dokumentation/lilo/user/d4hnode26.html#SECTION00031300000000000000

-----------------------------------------------------------------------------------------------
2.1.3 Other options 

Options of the type variable=value which are neither standard options nor 
device-specific options,
 cause the respective variables to be set in the environment passed to init. 
The case of the
variable name is preserved, i.e. it isn't automatically converted to upper 
case. 

Note that environment variables passed to init are typically available in 
system initialization scripts 
(e.g. /etc/rc.local), but they're not visible from ordinary login sessions, 
because the login
program removes them from the user's environment. 

-------------------------------------------------------------------------------------------------

This implies that one could set up different options in lilo to permit 
bypassing the items that don't
actually need to be run every boot cycle, (kudzu, depmod -a "Finding module 
dependencies..."), or
items not needed in all scenarios like the X font server. 

One could even have options for specific tasks like "boot in console mode,start 
a ppp session, 
run fetchmail to grab my new mail, and then halt."




On the issue of minimal disk space:
http://www.linux.org/docs/ldp/howto/mini/Saving-Space.html#toc3
suggests that stripping binaries, compressing executables with upx 
(http://upx.sourceforge.net/), and
gzipping other files, using zlibc to transparently uncompress when needed.


Couldn't this sort of thing be implemented with the $package.post.sh 
functionality to provide more
room during installs on marginal machines?

On the problem of RAM shortage:
The small memory howto:
http://www.tldp.org/HOWTO/mini/Small-Memory/
mentions reducind the number of virtual consoles, as well as some daemons which 
might be done without.
---------------------------------------------

VCs are a great way to free up memory. Most Linux distributions run about 6 of 
them out of the box.
 On average running 6 VCs requires about 4MB of memory. Removing a couple of 
them can free up
a couple MBs of memory.
-------------------------------------------


On machines with a shortage of available colors.....
Many older machines cannot display more than 256 colors, and X fails to ration 
these in a reasonable
way. as a result of the "first come, first served" philosophy, many times a 
color shortage results,
and annoying flashing and/or black/white displays occur.I don't really 
understand this, as the 

Some apps allow the limiting of how many colors they'll consume. It would be 
helpful to have them 
launched with conservative color usage by default.

Toward this end, I use "xsetroot -bg gray20 -fg gray40 -mod 8 8" to set my root 
window background.
(This sets a graph-paper pattern, and only used up two colors) 
using the mogrify command to color-reduce other wallpaper patterns helps, and 
old sun machines 
have a collection of xbm bitmaps which look decent, although I'd guess 
re-distributing them is
forbidden.

This is only a limited workaround, though. What I think would be a better 
solution is to have
color reduction in the X-server. Perhaps creating a readonly colormap 
containing the 
216 "netscape colors", or some other (user definable?) standard set, and then 
matching the 
requested color as closely as possible to it, rather than failing the attempt 
to allocate.
Some info on this is at:
http://www.motifzone.com/tmd/articles/John_Cwikla/xcc.1.html 
although this implies that the responsibility for colors lies with each 
individual app.

It seems to me that the general case solution is for this to be done at the 
server level,
so that old, naive apps would work well without rewrite.

Is there some good reason why this isn't done already? Perhaps my grasp of this 
is just
too limited.



Software:
http://www.runlevelzero.net/greg/grab/
I'd like to nominate GRAB, as it automates some of the "rpm dependency dance". 
It
seems like it'd be a help to new users, especially.
One concern might be how it handles a request which triggers a cascade of 
packages
exceeding the available disk space.




I've also modified:
/etc/sysconfig/network-scripts/ifup-post

to include the following:
-----------------------------------------------------------------
/usr/sbin/netdate -v tick.usno.navy.mil tock.usno.navy.mil
/sbin/clock -w

IP=`/sbin/ifconfig ppp0 | grep inet | cut -d ":" -f2 | cut -d " " -f1`
echo $DEVICE up IP $IP `date +"at %H:%M:%S %Z day %j of %Y   
%s"`>>/var/log/ppplog

-----------------------------------------------------------------

netdate is only about 10k and it's nice to know my machine always has the 
correct time.

I also like having a log of when I've been online.

at some point, I may put fetchmail in there, too.


Well, that about covers my thoughts so far.
Hope this triggers some meaningful discussion.

-Chris














reply via email to

[Prev in Thread] Current Thread [Next in Thread]