Dhruba Bandopadhyay <[EMAIL PROTECTED]> writes: > Hello > > I'm writing about the enforcement of default/expected 'vanilla' > behaviour of various attributes of the operating system. These issues > have been an annoyance for some time and are only being ventilated now > that I have some time so please forgive me if I seem a little edgy. > My intention is to make suggestions and reach discussed optimal > solutions. When reading bear in mind the philosophy of putting > control into the user's hand and providing choice to the user. > > -------------------------------- > 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. > > ------------------------------------- > 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 > > --------------------------------------------------- > Scenario 3: vanilla kernels and development sources > --------------------------------------------------- > Usually, I get the latest bk snapshot from kernel.org, unpack and > compile manually. However, recently, on a new install I emerged > development-sources to fulfill virtual/linux-sources and was later > puzzled to find its contents in > /usr/src/linux/linux-2.6.x-test-y-patchset-a.b and many other > involuntary steps being taken by the ebuild. This confounded many > users and bugs were filed about install locations, alsa actions and > also about adding gentoo patchsets to dev-sources. On forums, I heard > something about a 'vanilla' use flag to prevent the gentoo patchset > although now I only see it in IUSE and not in emerge -vp oddly. Why > can't it be as simple as download > unpack > merge rather than > download > unpack > play with permissions > run genpatches to patch > sources > merge into different location? What is the 2.6-test gentoo > patchset and why is it necessary and applied by default on an > unfinished release? My requests: > > 1) Provide the kernel in vanilla fashion without customisations > 2) Reconsider using the alsa and vanilla use flags here as they > violates the rule of using use flags only for compile time > switches. > > ------------------------------------- > scenario 4: kernel sources on portage > ------------------------------------- > $ emerg -qs sources > <snip> > $ emerge -qs sources | grep -c '^*' > 38 > > Currently, there are 38 kernel sources on portage. A few weeks back > there were 36. Then gentoo-test-sources was added as a branch to > gentoo-sources and also recently gentoo-dev-sources has been added as > a branch to development-sources. Now, does this only strike me as > being a very large number resulting from liberal means? Are there any > rules that govern creating new kernel sources and justifying their > need? Providing choice is good but having this many kernel sources > not only confuses the user and makes him indecisive but it also makes > dev maintenance and administration more difficult. Also, problems > such as the description for gentoo-dev-sources being exactly the same > as development-sources will only serve to increase confusion. Is it > necessary to provide gentoo patchsets for every possible kernel > variant? Even if you go by the rule that stable kernels will have > patchsets the current dev-sources violates it. My requests: > > 1) Create gentoo patchsets only for finished releases and separate > into different sources > 2) Provide vanilla kernels as unaltered, unpatched and uncustomised > sources just as they would be if done manually > 3) Agree on prerequisites that must be fulfilled prior to adding new > kernels-sources or in fact any new packages onto portage. > > ------------------------- > 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? 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. 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. It's a shame that finally EULA's have > made ebuilds interactive and sound and message waits are further > increasing merge time > > 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. Exceptions are where the change is vanilla in > itself like providing stock kernel configs to newbie users as > genkernel does. > > 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 > > -- > [EMAIL PROTECTED] mailing list > >
-- Matthew Kennedy Gentoo Linux Developer -- [EMAIL PROTECTED] mailing list
