Re: [gentoo-dev] Vanilla behaviour in Gentoo Linux (long email)

[Troy Dack <troy@tkdack.com>]

On Mon, 2003-11-03 at 12:29, Dhruba Bandopadhyay wrote:
> --------------------------------
> Scenario 1: slocate and updatedb
> --------------------------------
> Out of the blue my hard drive starts roaring flat out.  This happens 
> generally after the first reboot after installation or every day on a 
> working system.  Given that this happens without any prior warning or any 
> explicit consent or instruction during any part of install or configuration 
> it can become extremely unpleasant especially if doing something rather 
> important and resource intensive.  The culprit here is slocate and the 
> makewhatis and updatedb cron scripts added to the daily cron duties!  One of 
> the reasons I use Linux is because it only does things when I tell it to. 
> Problems like this one sadly resemble Windows which when idle begins to 
> grind away at hidden activities.  updatedb also requires root access to kill 
> which can be an added hassle.  My requests:
> 
> 1) Remove slocate from base system
> 2) Remove makewhatis from daily cron duties
> 3) Remove updatedb from daily cron duties
> 
> I'm probably not alone in the fact that I never use slocate and given fixed 
> location of package files and other files in gentoo finding things is easier 
> than other distros especially given qpkg -l and etcat -f.

qpkg and etcat do not handle any files in /home/$USER

locate does.

If you don't like having slocate as part of the default install then
create your own profile (instead of default-x86-1.4) and remove slocate
from the profile.  Maximum flexibility is available here.

> -------------------------------------
> Scenario 2: baselayout and /etc/issue
> -------------------------------------
> With every emerge or update of baselayout or invocation of emerge -e a file 
> called /etc/issue is placed on my system.  It serves no purpose other than 
> to tell me what I already know such as what kernel, architecture and machine 
> name I am using.  And on server machines with no monitor it does not even do 
> that much.  Every time I have to delete this file and it gets added back in 
> later.  Is this an example of developer preference deviating from vanilla 
> behaviour?  There have been bugs filed about the removal of graphical 
> /etc/issue which was later removed.  Why not give the user the choice and 
> put control in his or her hands?  Customisation is a preference.  My requests:
> 
> 1) Eliminate /etc/issue and rename it if it must be added to the system

http://www.pathname.com/fhs/2.2/fhs-3.7.html section 3.7.3

Yes, it is optional.

Since you state that on server machines with no monitor it really
doesn't serve a purpose, I'd have to assume that you never (rarely) see
it.  However you seem to be overly concerned about a 30 byte file (or a
4K file if you count the block size).


<el snippo>
 ... others have commented better than I could possibly hope to
</el snippo>

> -------------------------
> Scenario 5: Ebuild speech
> -------------------------
> On completion of merging the portage ebuild sleeps for ~15 seconds, the 
> baselayout ebuild for ~10 seconds and even dev-sources sleeps for ~5 seconds 
> whilst all these packages display messages.  In my opinion, this is 
> downright pointless.  On a source distribution like this one especially 
> where claims about speed are made not only of portage but also the packages 
> themselves what is the point in gaining ~10 seconds load time when you lose 
> ~15 seconds compile time?  What is the net gain?

Sheesh! 15 seconds compile time is not such a big deal, really.  Load
time and compile time are not comparable either.  And if you are
building on low end hardware, 15 seconds is hardly going to make a huge
difference to a 20 hour compile

>   To make matters worse, 
> ebuilds beep out loud through pc speaker on important sys-apps merges whilst 
> sleeping in between which can make one very uncomfortable in office or quiet 
> environments.

Remove the speaker :) or with a 2.6 kernel don't build support for the
speaker into the kernel.

>   I understand it is important to get messages to the user but 
> this is not the way.  There should be other means whereby all messages are 
> accumulated and logged and displayed at the end of all merges (bugs are 
> open).  I currently this as follows.
> 
> $ emerge -Du world | tee updates.log
> $ grep '01m' updates.log  ( <-- this gives all messages in log file without 
> use of sleep)
> 
> My requests:
> 
> 1) Eliminate all use of sleep in ebuilds
> 2) Eliminate all use of beeps via echo -ne "\a"
> 3) Write eclasses or modifications to portage which control logging and 
> display - I have even written a bash wrapper (unfinished) around emerge 
> which does log all output and displays all messages at end of every emerge 
> separated according to package names.
> 4) If there absolutely has to be sound it must be done through 
> FEATURES="sound".  FEATURES="notify" can be used for message waits if 
> absolutely necessary.

I believe that there are a few bugs on this, hopefully your comments
will encourage the portage devs to implement a better
logging/notification facility.

>   It's a shame that finally EULA's have made ebuilds 
> interactive and sound and message waits are further increasing merge time

Unfortunately not all the software that people want to use on their
Gentoo system is free/OSS, there has to be a compromise somehow.

> Overall, I would say vanilla behaviour should always be exhibited by default 
> in all aspects of the operating system in favour of user preference or dev 
> preference.  Focus should be on instructing the user on how to make a change 
> rather than making the change and expecting the user to reverse it. 

After using several different Linux distributions I'd have to say that
Gentoo, by and large, does things more "vanilla" than most. 
Additionally I've found Gentoo to be the easiest distribution to
customise to *my* liking, and those changes stick and are not wiped out
by a package upgrade.

> Exceptions are where the change is vanilla in itself like providing stock 
> kernel configs to newbie users as genkernel does.

OK, now you are taking _some_ control away from the user by supplying a
default config, couldn't /etc/issue be considered a default *Gentoo*
configuration (heck it is on many other distributions)?

When I first started using Gentoo I had to compile my kernel from
scratch, it taught me a good deal about my system and what it needed. 
Personally I don't think that genkernel is a good idea, but others do
and I'm all for making Gentoo more accessible to new users, so each to
their own.

> Please discuss as you wish.  I would be grateful if these issues were paid 
> some attention and I look forward to receiving feedback whether you share 
> the same experience or have opposing views.  If any of them should be filed 
> as bugs
> 
> with sincere regards
> Dhruba Bandopadhyay

-- 
Troy Dack					http://linux.tkdack.com
<troy@tkdack.com>				http://webportage.sf.net

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C


--
gentoo-dev@gentoo.org mailing list