From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80 invoked by uid 1002); 6 Sep 2003 19:22:57 -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 26732 invoked from network); 6 Sep 2003 19:22:50 -0000 From: Douglas Russell Organization: University Of Reading To: gentoo-dev@gentoo.org Date: Sat, 6 Sep 2003 20:21:20 +0100 User-Agent: KMail/1.5.2 References: In-Reply-To: MIME-Version: 1.0 Content-Description: clearsigned data Content-Disposition: inline X-UID: 29 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200309062021.26817.puggy@bobspants.com> Subject: Re: [gentoo-dev] Some suggestions X-Archives-Salt: 7b6eaf8e-42cb-40d1-bba3-b3ba382c71e6 X-Archives-Hash: f63275e955a644d9e210fbc9b3b959fa -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 06 September 2003 7: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". You can't be serious!? If you don't examine those etc-update changes you could seriously screw up your system. > 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. What about those of use with a load of other stuff in there. I just use the interactive merge function of etc-update. Takes about 30 seconds to do make.conf. > > 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. I believe their is a patch to do this somewhere around. Sorry I can't remember where. > 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. A progress bar would be difficult as its difficult to estimate how much code is left to compile and/or how long that is going to take. It would probably end up just saying 20 our of 24, 21 out of 24 etc. I personally prefer to see the compilation so when it breaks I can see exactly where it was before it broke. > 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. Well, there are programs whcih do some of the stuff you might be referring to like kportage. They don't work on all desktops though, and they don't do all of that. > 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. Your right, GUI discussion is all over the place. It would be useful to some users certainly. What places? Not modifying the CFLAGS? What do you suggest they should be left at. I can assure you, your Athlon XP 2800+ or whatever will comparitivly crawl with mcpu=i686. > 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. Their are faster versions. http://bugs.gentoo.org/show_bug.cgi?id=24756 for example. > 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. > > Sincerely, > > David J. Sankel > > camio@yahoo.com > > > -- > gentoo-dev@gentoo.org mailing list Puggy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/WjO1XYnvgFdTojMRAn/uAKCbyE9q3OSY2E6Ckqgr+XTt81hcMwCgrN4C VbMZGO4LLKRHVCGcNHr+5WY= =bZ0l -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list