Package Config Diffs
For system administration... In order to reconstruct a system... It is easy/rivial to get a list of all the instaned packages on a machine. But, getting a list of the modified configuration files (presuming any modified file is a config file of some type) and the differences is a little harder. I am thinging of extracting all files from a package into a scratch directory and then comparing against what is actually installed, looping over all installed packages. This seems a bit excessive, any suggestions?
How to display to a television?
Has anyone done RGB output to a televion. How is it done? -- Fredrick Paul Eisele Netarx, Inc. Phone (248)647-9800 Fax (248)647-9840 30910 Telegraph Road Bingham Farms, MI 48025 [EMAIL PROTECTED] www.netarx.com
Re: SEUL packaging, etc.
I would like to make it almost trivial for a user to install a package, i.e. click in a hypertext help/wizard window and it will install what is required for functionality set X. Some time ago I made a suggestion that was only slightly commented on (as I have been rather busy I have not followed up) that I believe addresses this issue. Problem #0: Installation is too hard. I have to type in all kinds of installation parameters. Solution #1: Make a graphical interface, everybody knows picking is much better than typing. [Is this the essence of what Erik is proposing?] Problem #1: (Problem with Solution #1) Installation is hard, I have to enter in all kinds of installation parameters and I can't just enter them and let the installation proceed on its own, I have to shepherd it all the way. Solution #2: Make better use of the multi-stage select/install/configure. Cause all the information required to install to be obtained during the select phase. Separate the configure into two phases one to collect the configuration information and the second to actually perform the configure (Could this information be obtained during the select as well). Problem #2: Installation requires me to have a significant amount of insight into the workings of each package that I have to install. I want this ability for the packages that I am particularly interested in but for the bulk of the packages I really don't care. In fact what I really want is to have an installation like (for example) Bud (basic user/developer). Solution #3: Add in a second level install program which provides a GUI and has all the standard selections already entered. If I want something different then I can simply pick different options. [Is this the essence of dselect, diety et al?] Problem #4: But, what if there are multiple standard selections that cross multiple packages, then I have to hard code them into the second level install program. This will make for the baulkanization of install packages. [Is this the cause for SEUL project?] What I really want is to make it possible for me to manage MY configuration and to be able to share MY configuration with other like minded people, i.e. people acting in the same role. This is the arguement against the Debian distribution, debian is for bit-heads, hackers, nerds, ... and not for normal, typical,... people like ME. Solution #4: Extend the first level install programs to comprehend package recursion. Extend the current package to allow the inclusion of other packages. These new collection packages have options which override the default parameters of constituent packages. Ultimately, the specific system administator should have the ability to generate a collection package consisting of their own selected set of packages. This would allow for the sharing of system configurations. Problem #5: This could/would lead to a explosion of packages which add no real functionality to the distribution. People would start arguing over what was the best way to organize the package hierarchy. Also, the atomic packages (those that do not include other packages) would be more prone to failure? Solution #5: Is this a problem? Finally, it is possible that all this discussion has already gone on in the development of Deity and others. If so, sorry for consuming valuable band width, if not, I would like to see some discussion on this thread. In particular I would like to see some discussion of the the different roles which typical linux users may play. Fred There are two kinds of people; those who divide people into two groups, and those who don't. -- unknown -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect via ftp probs
Needed perl, which I have, but didn't install with dselect. Naughty me. So, I tried to grab the deb perl, and install it, but it needs libdl1. Where is libdl1? I think there is an error in the dependancy. I think what is meant is libdb1. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Free space on Linux Drive
John wrote: I think this a simple enough question, but even my Unix teacher can't answer it. I just installed Debian on my 586 Windoze machine, with a 200mb partition. The first time I installed it on 100 megs but I ran out of room. My question is how can I check how much space is left on my Linux partition. I DOS, I can use chkdsk, is there a similiar function in Linux? Yes, this does sound to simple. Try the df command. (summarize free disk space) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Discussion Role Based Packages (was Re: Fax programs! help please. (fwd)
Orn E. Hansen wrote: What Im driving at is... for a writer, make an environment suitable for writers... and for an office worker set up an environment for an office worker... each can be based on a common os... but to try and create a one setup to serve all... will only fail (unless you're going for a guaranteed ten years service part :-) Proposal: While watching the discussion concerning dselect that went on a while back it occured to me the deselect may not be the best place to implement role based system configuration (a setup based on what the intended user will be doing). It seems to me that dpkg should (already) support recursive packages. That is, the install(remove) script for a package would invoke dpkg to install(remove) other packages as well as modify config(and .*rc) files. And, rather than just making suggestions about how to improve dselect it would be easy enough to constuct a role based package and say 'see like this'. My current configuration is nothing to brag about, but I would like to see what the experts have done. The main benefit would be to allow an installer to invoke dpkg once(few) times on a(some) role based package(s). 1) is this possible? 2) if so, how would it be done? 3) does anyone out there feel that their setup is exemplary? (given a particular role) 4) assuming positive answers on the previous; I think such packages would be best suited for admin. 5) would it be possible to generate a role package automagically from the dpkg status files? Thanks, from a gnubie -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Improvements -- Canning
Richard G. Roberto wrote: 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. What if a set of packages were developed, one package for each specialized type of installation? This would place the burden on those who want such a specialized installation (of which there are many types (per this thread)). Some package types that come to mind: newbie: a package that installs basic stuff (no X) babushka: a package that installs much like Red Hat's initial setup appl-dev: a package that installs stuff used by application developers 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. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: cron problem
Lawrence Chim wrote: I don't know why cron always send mail to root with the following body. Any idea? I think what you are asking to related to the MAILTO variable. If you set MAILTO='' in your crontab for root the cron stuff will not be sent. An exerpt from the cron man page: When executing commands, any out put is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Oleo - Any docs?
Ed Down wrote: I've used a few spreadsheets in my time, but the Oleo docs do not give me enough info to use the program. Anyone know of any user-friendly Oleo docs, or maybe an easier to use X spreadsheet program? I made a shot at installing SIAG but have not really put much effort into it. Has anyone tried it? How does it compare to the likes of NExS? SIAG: http://linus.asogy.stockholm.se/~ulric/siag/siag.html NExS: http://www.xess.com/NExS/nexs.html Incidentally, SIAG is GPL; NExS is commercial. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
