From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26449 invoked by uid 1002); 6 Sep 2003 19:46:38 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28792 invoked from network); 6 Sep 2003 19:46:38 -0000 From: Brian Jackson Organization: Gentoo Linux To: gentoo-dev@gentoo.org Date: Sat, 6 Sep 2003 14:46:31 -0500 User-Agent: KMail/1.5.9 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200309061446.31195.iggy@gentoo.org> Subject: Re: [gentoo-dev] Some suggestions X-Archives-Salt: 37b1581b-9b87-4aa8-9bce-733fdafded55 X-Archives-Hash: 5d1fd69d64f2d2e6f57f2136658e9e72 On Saturday 06 September 2003 01:05 pm, David Sankel wrote: > Hello gentoo developers, > > I would like to say great job to all of you. Gentoo is an exceptional > distribution. I have been using it for about 7 months now. You all > should be very proud of yourselves for creating a very solid software > product. > > I am an independent contractor with several years experience in user > interaction with software systems. I came up with a few suggestions for > the gentoo system. It is my hope that you will find them interesting or > informative. > > 1) etc-update changes for a more automated system update > > etc-update allows you to automatically update (noted) etc files that one > never changed from their last emerge. This could save a lot of > maintenance time if it was put in a cron job to routinely do that after > an "emerge sync;emerge -u world" > The user then wouldn't have to look at all of the etc files to see > if they were changed after every "emerge sync; emerge-u world". been suggested, don't know what the status is, there's probably a bug that's tracking the progress > > 2) make.conf updates to be more automated > > Most gentoo users, I believe, modify this file. This specific file changes > quite often with updates. Since most users only modify the "USE" and "CFLAGS" > components, having an update that is automatic is plausible. This feature > is a trade off between the integrity and consistency of the system verses > end-user maintenance time. > > 3) emerge -u world "NOTICE:" output changes. > > When doing an "emerge -u world" several "NOTICE:"'s fly by on the screen. > For many users, they go unread although they contain important information > in a lot of cases. If these "NOTICE:"'s are cached and output at the end > of an "emerge -u world", their readership would have a dramatic increase. > This would allow interested gentoo users to be more informed of their > system. been suggested numerous times, I believe it's being worked on > > 4) emerge -u world progress bar option > > Most users probably care less about the compilation stages of their update > in comparison to the percentage of completion. A progress bar in this > area would be a nice aesthetic and informative addition for most users. > In order for this to happen, the output of the "emerge -u world" command > would probably have to be standardized with some flags to mark the > beginning and end of a compile. it's hard to say what progress something is at, this would require some way to measure a packages relative size, but we do have an "emerging package x/t" message > > 5) A simple graphical front end to maintenance commands such as "emerge > sync", "emerge -u world", and "etc-update". > > It would be a nice feature if users didn't have to commit these commands > to memory for regular maintenance. The maintenance menu might have an > icon on all of the default desktops. If this type of program was > implemented, it could be prominently displayed and made known for all new > users. Perhaps the install documentation could use this tool as much as > possible. kind of tough considering the sheer number of desktop environments/window managers out there, but I know there is one for kde and one for gnome > > 6) A streamlined GUI install. > > I'm sure this one has been brought up before. I consider this the "1.0" > maker of the gentoo distribution. In such an installer, I suggest that > the CFLAGS should not be modified by default. It has been shown in > several places that optimizing these does not give a significant enough > performance increase. It should stay, of course, as an option though. being worked on glis.sf.net they are doing a scripted backend, that eventually can have whatever kind of front end > > 7) Emerge -S and Emerge -s speed improvements. > > I don't know why these commands perform as slow as they do. My intuition > says that they could be an order of magnitude faster. Perhaps a > reimplementation in C/C++ or a data format change could help. also been mentioned on too many occasions to count. portage is not going to be rewritten in c/c++, even if it was it wouldn't help, most of the time is i/o. there are people working on modularizing the portage code to make it easier to change out the backend, so some day you may be able to use a db, sql, whatever backend. > > Thanks for reading my comments and taking them into consideration. Again, > I want to thank you, the gentoo developers, for doing such a great job on > the gentoo system. I welcome any thoughts or comments on my suggestions > in this newsgroup or otherwise. We always welcome new suggestions, thanks for your input. --iggy > > Sincerely, > > David J. Sankel -- Home -- http://www.brianandsara.net Gentoo -- http://gentoo.brianandsara.net -- gentoo-dev@gentoo.org mailing list