Re: improvements
Ralph Winslow writes: When Kendrick Myatt, et. al. wrote, I replied: Somebody wrote: communications non-networking communications documentation all documentation development as is currently games all games graphicsanything which creates, massages, transforms graphics misccatch all- math, electronics, hamradio, misc, etc. networking any networking functions- mail, news, utilities, etc. printinganything dealing with printing- TEX, lout, etc. system admin, base, shells, X windows, etc. IMHO X deserves a heading of its own. Perhaps TEX/Ghost*/(the package that handles MIME)/etc. need an area as they cut across printer/X. I proposed the above catagories, and I said that it wasn't set in concrete 8-) The key here is the catagory (what ever it is) must be application oriented. IMHO, X windows are not an application, rather X windows are an extension to the OS and as such, you run X windows applications in that extension. Keep in mind that I am only referring to Xbase, Xlib, Xfonts, Xserver as Xwindows - not XQuake, or XV, or any other application which would require the basic Xwindows. Try to think in terms of the DOS user who installs DOS and then adds his/her favorite application(s) (be it word processing, or anti-virus utility, or printing program for making labels, etc. etc.) -- -= Sent by Debian 1.2 Linux =- Thomas Kocourek KD4CIK [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
When Kendrick Myatt, et. al. wrote, I replied: Somebody wrote: communications non-networking communications documentation all documentation development as is currently games all games graphicsanything which creates, massages, transforms graphics misccatch all- math, electronics, hamradio, misc, etc. networking any networking functions- mail, news, utilities, etc. printinganything dealing with printing- TEX, lout, etc. system admin, base, shells, X windows, etc. IMHO X deserves a heading of its own. Perhaps TEX/Ghost*/(the package that handles MIME)/etc. need an area as they cut across printer/X. # I am really in favor of this as well, if it would be possible. The way it is laid out now is more than a little muddy. Right now I seem to be getting the emacs package, which I do not want. I was thinking the interface of the packages would be more like above. It is an *awful* lot to scroll through once you get the list of packages, IMHO, and it was easy for me to get lost. Mainly breaking it up a little more into categories would have let me build the system I want better. Like, I could go into a Utilities menu and choose editors and then choose vi and pico, but not emacs. Then go back and under networking go to mail and get pine, then back up and go to news There needs to be an automated way to find specific packages which are at leaf positions without knowing the path from the top. I often try to surmise what the purpose of a package whose name i've overheard by looking at the source modules names (or by grepping the source, itself). I might not have a clue as to what its top-level entry is. and get tin, but not INN since I just want to read from another server, not host news. I know, it's easy for me to suggest all this when someone else would have to do the work :) But, it's just some ideas from a first-time Debian I'd build a perl DB to do this and other keen things, but I lack experience with the internals of dselect and organisation of the current dependancy info (and probably some other things I haven't anticipated) and I don't know anything about dpkg (I think dpkg is the what dselect uses as prinitives???). user. Mainly I expected the interface to make things LESS confusing instead of MORE. I really like the way Slackware does their install ( that's about it) and I like being able to manipulate packages like I can in Solaris. I think that Debian is almost a best of both worlds system, but can still use some work, especially in the initial setup area. Example, why do I seem to be getting the British ispell dictonary!!! *sigh* Little things like that :) I still think it's way cool all in all :) I may re-do it from scratch just for the experience :) Regards, Kendrick I just wish my selections were stickier. And a mode that simply includes required packages, rather than getting user confirmation on a per-package basis would be appreciated. The What you need to dselect using ftp should be the minimum and included automatically (if you want a more minimalist package, strip it yourself. It all begins to sound like a more formal DB may be desirable. I remain, Ralph [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
Dear ml users, Please do NOT use html mail. This format is not standard and cannor be interpreted by most mail readers. Thank you, -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler [EMAIL PROTECTED] -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
Somebody wrote: communications non-networking communications documentation all documentation development as is currently games all games graphicsanything which creates, massages, transforms graphics misccatch all- math, electronics, hamradio, misc, etc. networking any networking functions- mail, news, utilities, etc. printinganything dealing with printing- TEX, lout, etc. system admin, base, shells, X windows, etc. # I am really in favor of this as well, if it would be possible. The way it is laid out now is more than a little muddy. Right now I seem to be getting the emacs package, which I do not want. I was thinking the interface of the packages would be more like above. It is an *awful* lot to scroll through once you get the list of packages, IMHO, and it was easy for me to get lost. Mainly breaking it up a little more into categories would have let me build the system I want better. Like, I could go into a Utilities menu and choose editors and then choose vi and pico, but not emacs. Then go back and under networking go to mail and get pine, then back up and go to news and get tin, but not INN since I just want to read from another server, not host news. I know, it's easy for me to suggest all this when someone else would have to do the work :) But, it's just some ideas from a first-time Debian user. Mainly I expected the interface to make things LESS confusing instead of MORE. I really like the way Slackware does their install ( that's about it) and I like being able to manipulate packages like I can in Solaris. I think that Debian is almost a best of both worlds system, but can still use some work, especially in the initial setup area. Example, why do I seem to be getting the British ispell dictonary!!! *sigh* Little things like that :) I still think it's way cool all in all :) I may re-do it from scratch just for the experience :) Regards, Kendrick -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
Indeed, it might be worth considering doing away with the classification of required, recommended, extra, important, etc., because every person's needs and desires are different. Obviously, if the system won't run without it, it is required de facto. This might reduce the dselect confusion. -- Nathan L. Cutler Linux Enthusiast http://www.cise.ufl.edu/~nlc -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
On Thu, 9 Jan 1997, Nathan L. Cutler wrote: Indeed, it might be worth considering doing away with the classification of required, recommended, extra, important, etc., because every person's needs and desires are different. Obviously, if the system won't run without it, it is required de facto. This might reduce the dselect confusion. This can be done without changing package dependency data. We really just need to have a different interface for installing. The current installer only takes you as far as getting base installed and then throws us into dselect. There needs to be an intermediate step that allows for simplified installation of a choice of several install profiles. This is non-trivial however. All packages of a given section cannot be installed and someone needs to decide on which packages go in the canned profile and which don't. This needs to be a dynamic list that requires active management much like the existing release and it would not replace any part of the existing release process, so it means more work. This really should be done by oem types, but that isn't how debian is getting distributed (yet?). Just my $.02 Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
On Fri, 10 Jan 1997, Richard G. Roberto wrote: On Thu, 9 Jan 1997, Nathan L. Cutler wrote: Indeed, it might be worth considering doing away with the classification of required, recommended, extra, important, etc., because every person's needs and desires are different. Obviously, if the system won't run without it, it is required de facto. This might reduce the dselect confusion. This can be done without changing package dependency data. We really just need to have a different interface for installing. The current installer only takes you as far as getting base installed and then throws us into dselect. There needs to be an intermediate step that allows for simplified installation of a choice of several install profiles. This is non-trivial however. All packages of a given section cannot be installed and someone needs to decide on which packages go in the canned profile and which don't. This needs to be a dynamic list that requires active management much like the existing release and it would not replace any part of the existing release process, so it means more work. This really should be done by oem types, but that isn't how debian is getting distributed (yet?). Give me some time ( I'm working currently of totally new release of 3-5 new packages ) and I will send you (and to debian) a concretisation of my idea of virtual packages who can greatly ease the installation process. Mostly, you can do it by yourself (I send previous posting about it some months ago about local-deps - just the same thing but with little more configuration.). Ciao! Fab -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: improvements
[EMAIL PROTECTED] wrote: (2 cents worth) 8-) I perceive 2 separate issues going on this list pertaining to improving Debian. Issue 1 - Easier installation; Issue 2 - friendlier dselect. On installation issue, I'd like to see a return to the installation of release 0.93 - A custom mode for the experienced Debian user and a newby mode (with uncluttered DOS-like screens) for the raw newcomer to Debian. On the dselect issue, a lot of information is crammed into the presentation making the upgrade process more difficult than it needs to be. I refer to dselect as an upgrade process because at the point that dselect is called, the base OS is already in place/installed. You are then upgrading the base into a fuller, more usable system. I would like to see a dselect organized by applications rather than the current packages/sub-catagory presentation. Example: I start this new program and have a screen oriented by application: (these are merely suggestions and are not set in concrete) communications non-networking communications documentation all documentation development as is currently games all games graphics anything which creates, massages, transforms graphics misc catch all- math, electronics, hamradio, misc, etc. networking any networking functions- mail, news, utilities, etc. printing anything dealing with printing- TEX, lout, etc. system admin, base, shells, X windows, etc. I need communications; I move the cursor to the communications folder and open it. Now I see a new screen with efax, minicom, and uucp (applications!) Now I move the cursor to minicom and select it. At this point, dselect would select minicom _and_ all other package(s) needed by minicom. If a conflict exist, then a popup box would appear stating that there was a conflict and offer to either take care of it immediately, or wait until later. I suggest a new dselect called aselect. (keep the current dselect!) aselect would be for the newby or applications oriented person to upgrade his base installed Debian. When the installation is finished and the person reboots, does the admin stuff, they have the opportunity to either use the applications oriented dselect or the packages oriented dselect with the default going to applications. I like this idea and I'm a newbie...:-)) There should be of course always a help screen available, describing (not just with one phrase) what the selected application is used for, because it is not always so obvious, only by just looking at the name. The current dselect description is not not that informative about all applications, and when U never used Unix/Linux before it's more confusing and U are not sure if the application is needed or not?? Greetings Jacek
