Slashdot Mirror
Simple Comprehensive Config Tools?
"I admit it, I'm a Linux newbie. As I write this, it is Day Two. I've been both impressed and unimpressed with the out-of-box experience. The variety of Linux I've picked up was RedHat 6.1 for my Intel machine. I hate lowlevel hardware tweaking like determining IRQs, and have hated it for 19 years, but I figured I could go through a little more of it.
Impressed:
I was pleased to find that there were gui or text-mode-gui things to help me get many items configured. There were a series of tools on most of the basics like mouse, monitor, graphics card, sound, net card, modem, ppp, and so on. If I knew the name of the tool or could find it (by using the Win32 laptop still attached to the Web), I was able to get my subsystems all working with a little effort. I'm not afraid of vi or bash or emacs, but the gui setup was well-adapted to letting me run around and choose options without having to remember or learn keystrokes like C-x C-s at the same time.
Unimpressed:
Very few things seemed to be organized, either in the online help, or the tools available. Most of the things I found were by searching the support requests on the RedHat page, not in any prepared documentation. Once I found *mention* of setserial(8), I could use it or get the manpage. Once I found the /etc/inittab(5), I could tweak it to get that graphical login that rh6.1 install didn't make. And so on, for problems I faced in an unsupported PnP Sony 17" monitor stuck in 640x480 SVGA, and other problems I've yet to figure out.
If I had a *comprehensive* one-stop-shopping place to go, it would help a lot. It doesn't have to know all the esoteric PnP techniques, it just has to know how to execute the tools that have already been written.
Perhaps it would let you browse all /dev/* entries, click on each one, and it would start the configurator tool that is responsible. Or at least point the user at what /etc/*.conf file was useful. I would hope to see loopback tests and more importantly, what to do or where to look if something's not working resources, even if they're just URLs back to the distro or author of the uberconfig tool."
As far as I know, KDE 2.0 is supposed to have such a tool. I've only seen screenshots of it, though; can anyone else elaborate on that tool's quality?
I use debian and am a little partial to debconf which does a great deal of the important setup information for many packages. This was reventle (about a month ago) given its own package and can have various levels of importance with regard to prompts.
However your best bet is linuconf or maybe a gnome app (sorry can't think of the name because I only used it once)
which allowed for editing system files and such.
Slashdot social engineering at it's finest
Because the "idiots", as you put it, are the ones who buy the software, and Linux isn't going to be very commercially viable unless the "idiots" can set it up and use it. And Linux will have to be commercially viable to get the same attention from large developers that Windows does...
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
Since Corel is based upon Debian I think that the various config methods (notibly debconf and things related to apt) are the norm.
Corel I believe has added some of their stuff for the install and probably improved the apt front end greatly with some form of gui or something.
Slashdot social engineering at it's finest
If you think this is the case look at all win32 api documentation then tell me about it. Generally the user interface in windows is more idiot proof than most (except the mac). However it does not mean that any idiot could do anything they want from the OS in an idiot proof manner.
What must be stated is that if all you want is to play games then you can easily do this in liunx in an idiot proof manner. However if you want to do something complex in a simple manner you may be stretching it. Any OS that tried to do something complex in an idiot proof wawy usually fails because of the complexity or because of lacking flexibility.
Slashdot social engineering at it's finest
I've played around with Linuxconf and the Gnome configuration tools, and have been generally unimpressed with the "embed everything into one tabbed panel" approach of the two. I use simple console-based tools or vi to edit the config files, but would welcome a set of *loosely integrated* tools, each specialized to work with modems, mice, etc. under X.
One approach, although windows-like, would be to make each applet a dynamically-linked library. A central "control-panel" applet could enumerate the shared libraries in a directory, calling some function like 'struct cp_ops init_panel(void);" to get a list of the functions to call for opening the applet, closing the applet, or assigning the applet an "owner window" (if such a thing exists). Among the "struct cp_ops" members could be a name, description, etc. This would be highly extensible, and wouldn't be limited to any one "master" application: other client programs could easily link in the "official" control panel operations, or simply reimplement them by calling into the applets directly.
I'm sure there's some really good argument for the ORBit/COM-like OO approach to configuration tools, but in practice I just haven't seen it work. If the embedded applets wouldn't do funny things like disappear when I press OK (GNOME), I would probably be singing their praises right now.
Is the aforementioned (and simple ) approach adequate? Is there some use or situation for which it would fail?
Webmin is an excellent configuration tool that everyone should check out once. It's particularly good at configuring server processes such as sendmail and DNS.
http://www.webmin.com
Automation and GUIs are great, as long as the "traditional methods" don't get broken. SMIT on AIX can be great, but some of the /etc stuff doesn't work, any more. Even worse, some of that is still there. So I would say that any GUI config tool should work through existing /etc stuff rather than around it.
/etc stuff is there and works, but it was typically machine generated. The original data is often back in /etc/sysconfig, and if you use linuxconf again later, your changes are ignored and wiped over.
RedHat skirts around this issue, a little. The regular
The living have better things to do than to continue hating the dead.
here's a few more teasers on the software: its 100% modular, can admin more than one machine at once, and works w/Linux now and will be ported (which is trivial) to *BSD, AIX, Solaris, etc... the front end will also be ported to windows...
if you are interested in finding out more or getting involved in the development of what is the next generation in Linux/Unix config/admin tools, drop me a line at aseigo@mountlinux.com
All these add are gui *front ends*. Meaning that nothing changes. Thank you.
Slashdot social engineering at it's finest
As for myself, I've tried Linux several times on different occasions and concluded that it was a neat OS to run but my Win NT box is doing everything I need it to at the moment and it hasn't crashed once since I rebuilt my computer. If Linux offered better performance over NT on most of the things I use it for, then I'd have cause to switch but as it stands Win NT suffices.
Make it user friendly for the masses but first make sure it's what they need.
I don't really have an answer here, more of an expansion to the question, I guess. Since tools like linuxconf can be so dangerous (big gaping security hole waiting to be exploited in the machine isn't properly configed, and who is going to be most likely to not know what config is dangerous? First time users. Not to mention breaking things that you don't understand...), is that really the best answer? I think that a better solution to this would be a very detailed set of installation and/or config documents. For some things, this isn't that big a deal - if you can't get quake3 running in the first 20 minutes the machine was booted into *nix/BSD, you'll live. But if you don't know how to deal with basic config and setup, you can leave yourself open to being rooted, and that is a danger not only to yourself, but to everyone who has a computer that is network accessible from yours. Not a problem for the home box with nothing but loopback, but a serious problem for someone installing linux in their office, or on a college campus, or attaching to a DSL or cable modem. Personally, the way I first did this was by looking for man pages associated with everything in /etc. But that's time consuming, and there's plenty of stuff you don't learn that way. I suppose that for a given item you want to setup, that might not be that bad a method, for the moment. Still, I like the notion of a big pile of documentation. IIRC, red hat used to sell a package where you got these two immense reference manuals along with the distro cd and some other cds of software. Something like that would be good for a first time install, I think. Although it would have to be done just right - easily cross referenced, available in text or digital form, and up to date. Having meandered about this notion, I think it'll never happen, because it is that most feared and hated part of the programming project - documentation. Bummer, dude.
Now, in an attempt at answering, I would say that YaST is a really good tool for this, although I don't know if it can be shoehorned onto anything other that suse. YaST is fun and fabulous, although it doesn't do everything. But what it does, it does nice.
itachi
There are always ways to get around GUIs but they are usually not easy. All it takes is some knowledge about what the config file looks like and then you can edit it.
Slashdot social engineering at it's finest
The impression that everything is not organized comes from someone who knows nothing about Unix; I mean, "once I found
I understand the need the GUI generation (and most of non-geeks) have for easy to use tools, especially if Linux wants to take over the desktops (which I'm not sure is a good idea anyway), but I really worry about it turning Linux into something it's not, which is difficult to use for the experienced user.
Please be careful with automated tools. To try to put all the Unix miriad configuration files under ONE tool has a huge potential for chaos. It's almost inevitable the thing is going to get out of sync as already happens with linuxconf, unless you refrain from doing any kind of configuration by hand.
My feeling is that half the problems of the Windows family are caused just by that - the GUI and the need to make everything easy.
Maybe if Linux would split into 2 things, one of them being what already exists and the other some distribution for the masses. If something like this does happen, I'll bet anyone the version for the masses will not be nearly as stable and flexible as the original design.
Please, guys, make your install/config tools, but be careful!
I think we can start of with a sem-apropriate quote from Brian Behlendorf:
The point I'm trying to make here is that traditionaly under unix configuration has been quite a complex thing. Practicly everything under wintel has been designed with a cutsie little 'properties' dialogue in mind. Most of the time under unix the system and tools are vastly more configurable. Just look at the network thingy in a windows control panel, it's unwealdy, obease and not entirely effective at getting the job done, now imagine what it might look like under linux with the 10 fold greater flexibility the architechture lends to configuration. It may well be possible to design simple dialogues to hland the simple stuff like ip address, dialup and the like (effectively just the definitions at the top of all the config scripts and a few enable dissables). What you are unlikely to see however is an 'apply' button that asks you to 'please wait while I recompile the kernal', it's just plain silly. A certain degree of configuration can be hidden from the user by dialogues but until some big changes under the hood are implemented sooner or latter your going to have to roll your sleaves up. The question you then need to ask is how much flexibility are we willing to sacrifice for user friendliness?Although I can appreciate many people's desire to
have GUI config tools to help with configuration
in linux (devices, xwindows, daemons, startup, etc), I'd like to point out the following:
most GUI tools of this ilk are linux-specific.
One thing I always tell friends (esp. when configuring apache, bind, sendmail, etc) is that
they should go straight to the config files. One
of the strengths of linux is that configuring it
gives you an introduction to other unices as well.
If you can configure apache's httpd.conf on linux,
then you can also configure it on freebsd, solaris, aix, and just about any other UNIX it will port to. That's a valuable skill to learn --
and one that the GUI tool won't help you with.
By all means, play around with GUI configurators,
but learn what they actually configure and where.
Look at the config files. Learn to configure these
things with vi and you'll go a long way towards a
wider world.
(one thing I did like about AIX Smit is that it
displayed the CLI syntax once it kicked off a
configuration task -- not bad).
Simpler installation attracts people like the "newbie" who want to try things, but it frustrates more experience users. There cannot be a one size fit all distribution, Corel tries to address the naive user market, RedHat tries to address moderate to experience user, etc. If he has installed Corel instead, he don't even have to deal with /dev stuff.
- Etam
If Linux offered better performance over NT on most of the things I use it for, then I'd have cause to switch but as it stands Win NT suffices.
:-)
Methinks we very nearly have a convert
Life's a bitch but somebody's gotta do it.
Linuxconf has gotten a lot better over the past 6 months, and I find it adequate for 90% of my configuration needs. You can add users, edit mounted disks, modify the network setup, config Apache and Samba, and even edit the default init level (one of the problems mentioned in the post.) It seems to play fairly nice with existing text config files, and the web interface is a really neat idea.
Now when it comes to configuring hardware, I think Red Hat's simply the best, with Kudzu and Xconfigurator. Kudzu runs at bootup and, if new hardware is detected, will install and auto-configure the needed drivers. Xconfigurator, the well-known X config tool, is adequate, but this is one area that could use a make-over. I anticipate better tools after the release of XFree86 4.0.
I've never had a problem getting supported hardware to work with RH 6.1. Didn't even need to edit any text files!
The dream of one unified tool to manage your system is but a dream.
/etc.
Todays computer systems are complex things, just tcp/ip reqiures a 600 pages book to cover the basics, and people think that thinks that it could be melted down to one single "network control panel" are dreaming.
The traditional unix way of handling complexity is to break things down into smaller packages which could be managed on their own, imho a sensible aproach, top-down. But the drawback is obvious, you get the 2367 config files
I hope not for one tool to manage my system but rather a set of tools, perhaps integrated by a "front-end", the best aproach I have on this so far is made by http://www.linux-mandrake.com/ , things like http://www.linux-mandrake.com/lothar/ , the lothar project seems to be heading in the right direction. But as with all software theese things take time to mature and become really usable.
/N
Disclaimer: this is not a bashing of admintools .. please bare with me :)
I've been kicking around unix systems for some years now, and I've developed a love/hate relationship with admin tools (both GUI and text-based). I tend to lean towards the hate category and edit config files by hand as much as possible.
"Why", you ask? Because if I don't figure out how to do it by hand, when things go south, you either wind up learning to do it by hand, or you often are out of luck. It seems to me that it is better to know all the nasty bits up front, rather than wait for Bad Things to happen later and have to figure things out then (often under pressure from time constraints).
Now, this is not an admintool-bashing argument; I'd love to see the end-all-be-all suite of admin tools. However, what I would *most* like to see in an admin tool is more feedback. Specifically, if I'm going to be using linuxconf (for example), when I hit the apply button, I want it to *tell* me what it's doing, and preferably log all the changes it's making. That way, I have a clue where to look if linuxconf isn't doing the Right Thing. That would go along way towards helping newcomers to linux: they'd have a central place to go for configuration *and* learn what was going on behind the scenes for those times when it really matters.
As a second example, consider the debate about the ease of installing windows vs installing linux. Windows installation is usually described as easier, right? In many ways, I'd say this is true (altho it's the delta is narrowing all the time). However, you've probably had those times when installing windows didn't go so well. And when it goes badly, what happens? You are in a world of hurt. Why is that? Because it doesn't tell you what it's trying to do behind the seens; you can't fix things because you can't even figure out what is supposed to be fixed (at least not without an enormous amount of effort or prior knowledge of windows).
So, in summary, I think anyone developing configuration tools should really consider keeping the tool's users informed about what is going on under the hood, rather than hiding the operations completely. That would help both the user, and the tool's maintainer.
- You're an idiot if you don't already know all the magic incantations to configure a Linux system;
- Write your own config tool;
- WINDOZE SUX
It seems that there are quite a few people who think that Linux should not be used by people who don't program; or that Linux is a club for nerds who can rhyme off everything inIf, on the other hand, Linux is supposed to be an OS that can actually be useful as an OS, shouldn't it be possible to install it properly without having another PC handy for Web queries? Fun's fun, but you shouldn't have to take a "Linux for Geeks" course before you can even boot it up.
I don't think the issue is so much GUI vs. CLI configuration, but rather having some tool available "to execute the tools that have already been written", as the article said.
Or maybe I'm wrong, and I'm just not ready to join the Holy Order of Linux Initiates.
--
To an extent, yes. A bimodal tool (addressing needs of the expert user and the new to the system) would be of value to the WHOLE Linux market. I realize that many folks have a bias that makes them feel that Linux would be best served by keeping it highly complex, but you restrict the usability of the OS by doing so. Consider something like Jakob Nielsen's usability heuristics, one of which states that you should support the new user with comprehensive assistance and an obvious interface, but also provide shortcuts to the advanced user. I beieve that there is room for both in the Linux community. Perhaps the resource for the new user could be an agent that could be a module to be compiled if selected, so that the new user has the help, and the experienced user could merely not install it. Just my 2 cents (Canadian, so that's about 1.6 cents US). Cadfael
-- The Hollow Man
Non illegitimati carborundum
This is both a blessing and a curse. I hated Windows because it insisted on holding my hand when I didn't want my hand held, so, what was the first thing I did when I installed Linux, I ran Linuxconf.
Linuxconf is a phenomenally capable tool. Sure it is rough in spots and annoying in spots and it writes hideous smb.conf files, but it does at least give someone a place to start. The curse part, however, is that I started relying on the tool instead of educating myself as to what was going on underneath the Linuxconf interface. So, I quit using Linuxconf and started doing everything by hand. Now I know what goes on on my systems (the last Linuxconf module I regularly used was the Sendmail module, I recently started using the M4s, and then ran into the arms of Postfix, but that's a different story).
Now, I sometimes use Linuxconf again to do quick and dirty network stuff, but at least I know what Linuxconf is doing!
If we are ever going to reach the "average" users, tools like Linuxconf must succeed and we shouldn't look down on the tools or those who use those tools (and I've seen some of that invective on this thread). Just be glad that as with most things Linux we have a choice!
Stand Fast,
Stand Fast,
tjg.
cfengine is a sort of generic "configuration control" languge. You define things like lines that should be in /etc/hosts , or things that should be mounted, or files that ought to be kept up to date with central repositories, rotating system logs, fixing file permissions, and other similar sorts of things.
A daily/hourly run will go through and "clean up" whatever isn't set according to the instructions.
There's a client/server variation called cfd that allows you to push configuration across a network on demand.
The big point to this is that it treats system set up more like "immunology" than anything else. From a security perspective, this is very good. You get some security rules set up, run them regularly, and fix/prevent holes.
Perhaps more useful, once you set up some common rules for a site, installing a new system becomes real easy: you just need to get as far as installing cfengine, get some config files over, whether via floppy, CD, or NFS mount, and then type # cd /etc/cfengine; cfengine and depending on the sophistication of the rules, you may never need to log on as root again.
For instance, you might set up a location where machines mount a filesystem containing package upgrades or configuration file upgrads, and automagically install them.
The regrettable thing is that cfengine doesn't have the "barneyfication" that naive users may want/need.
On the other hand, it has the major virtue over things like Linuxconf that it is a tool for building configuration systems rather than being a front end that is tightly connected to the back end.
I could see:
Thus, rather than merely doing a "cp foo /etc/foo; chmod 774 /etc/foo", the configuration process might include asking the user for input of critical bits of configuration, and constructing a cfengine script that might even be usable to "clean up" if you've done something icky and want to fix the package.
This would also make it natural to create a little script for a given package that might do security checks, perhaps automagically turning off dangerous options or the like.
If you're not part of the solution, you're part of the precipitate.
That's my biggest beef with Linuxconf - when I resort to using it because I don't know how to do it by hand, I would *really* like to have it tell me which file it's editing, at the very least - this would make it a good learning tool, as well as a good config tool.
:)
I guess that's what you said. But I completely agree.
----
It could be nice if as many config files as possible were in some standardised markup language, such as some XML-family language. That way, a GUI tool could parse them, or you could edit them directly.
Actually, it would be nice if all the cli tools output a standard command template that could have a gui wrapper autmatically put around it. The amiga almost had this - every compliant command produced a template when called with ? as a command line option, whcih could be fed into a tool such as Gui4Cli (on aminet) to build a GUI automatically. The template wasn't quite general enough for everything, but if each command output a GUI code in XML when called with foo --gui, then very newbie-friendly distros could be built.
Choice of masters is not freedom.
gecco, on sourceforge, looks interesting. It has a way to go, but it has a cool plugin architecture that should make it easy for various people to contribute to it, and make it a good all-around tool...
----
The viewpoints are extreme oversimplifications, but the point is made. What we're seeing is a split both over how Linux should be used, and I think, how it will be used. And it says a lot about what Linux needs. Linux's install base is diversifying so much that one solution is not going to fit everyone. On the one hand I say, "Yes, a comprehensive graphical system manager would be fantastic!" On the other, "But you're not learning system administration, which is what Linux is all about."
Linux is too complex for the newbie. It's just a fact, and it's going to have to be accepted. Steps have already been taken to change that, but in large part, these efforts have been controlled by people who aren't newbies and don't understand all of the troubles. Microsoft does this sort of testing, and the Linux community does not. When we need something like this, something that targets an audience that's "not us", we copy Microsoft, and since our systems weren't designed like Microsoft's, it's a kludge. It works, but not necessarily very well, and it's certainly not cohesive, and probably never will be, simply because it's being done by many separate people, not one overarching company. It's one of the downfalls of open-source software, a minor one for anyone who doesn't use corporate software.
Someone can very easily develop a fully comprehensive system manager. Parts have already been started. The end result is something that really bastardizes the idea of what Linux is, a server OS that is very complex and very loosely organized, but it does work for the newbie, because it hides all that. The end result is really two different versions of Linux, which is really what Microsoft has with its Windows line. The Windows schism isn't necessarily a bad thing, except that they are two different implementations. With Linux, the community has a chance to produce that seeming "schism" in one implementation. If done right, security, which config files can of course break, can be set at install time, and the system manager will never touch it. A more advanced user, of course, would take care of all that on his own, and probably never need the manager. It's the same OS. The implementation is even the same. On one hand, though, you are setting the security at install time, and in the other, the user's taking care of it.
I don't want one of these 'system managers'. My Linux doesn't need one of these 'system managers'. But Linux as a community does, if it's ever going to be viewed as having its act together. Webmind and Linuxconf don't cut it. Newbies need a manager that can act just like we do when we manage our systems. Can a community that produces so many things separately do that as one? Who knows.
I have installed just about every variety of Linux that I have heard about. Mostly out of curiousity.
From my experience, Mandrake 7.0 seems to be what every newbie is looking for. The installation is GUI based and very straightforward. It also lets you tweak the X configuration and test it before committing to it in the installation. That way any one can test their resolutions and color depths.
After that, such things mentioned earlier such as DrakConf and Lothar make matters much easier for setting up thigns such as the sound card.
On the other hand, it might make things a little too simple and cause someone to get lazy and never learn any aspects of the CLI. But, nothings perfect.
On a side note, and off topic:
Everyone seems to be pro linux, screw microsoft, but in the same sense, everyone also seems to have the "Why should we make things any easier" attitude. Either you want more linux advocates, or you don't. Pick a direction.
Graphical all-in-1 configuration tool is a great idea - but it is ahead of its time. Here's why:
First, configuration file formats changes from one version of the same software to the next. It is unlikely that the team who writes the config utilities catch up soon enough with the team who makes the programs to be configured.
Second, different programs have different configuration files. It makes it hard for a single configuration utility to recognize them all.
Third, the existing tools seem to be too tree-structured, taking away the simplicity advantage they first try to provide. (anyone besides me who hates linuxconf?)
INI files is one of the few things about Windows that I like. I'd love to know if anyone has started to unify the format of all the configuration files into, say, XML?
Another possibility is to have the author of each program write its own configuration cgi script,
Then some project can be started to make a configuration server to gobble them all up at an HTTP port (ala SWAT)
As of now, the closest thing I can get is to have a text editor that support projects. Put a bunch of config files into a project....I prefer this to linuxconf. You get the idea.
That's my biggest beef with Linuxconf - when I resort to using it because I don't know how to do it by hand, I would *really* like to have it tell me which file it's editing...
linuxconf offers you the option of previewing your changes before it applies them. When you quit the program, choose "Preview what has to be done".
This is on Red Hat 6.1, linuxconf 1.16r3.2-2, but I'm pretty sure it has done this for a long time.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
You can have your cake and eat it too. The existence of easy to use graphical tools does not necessarily mean that text-based tools are going out the window (no pun intended).
Face it, some things are just a nightmare in linux. For example, making it so that you can have decent good-looking fonts in X requires a brilliantly written 20+ page how-to. Things just HAVE TO get better than this. Very few people have the time to read dozens of pages of information to change each little aspect of their computing experience.
Graphical front-ends are a good idea, epecially for administrative tasks that are done once per installation or that are changed infrequently or on machines that are administered by someone that is not a professional administrator. It is very hard to remember the details of commands like mount, for example. The man page is very long and complex for this command and it creates a feeling of dread in someone that just wants to get some work done.
Disregarding for the moment my own opinion on the GUI config vs. CLI debate, I see a lot of people getting confused in this thread about the idea of easy to use compared to easy to learn.
Example: vim makes text editing easy for me. It makes programming easy. Was it easy to learn? No, not really. Is it worth it, though? I think so.
Example: Debian makes maintaining my box incredibly easy. Easy to learn? Hah! But the payoff, once again, is there.
I could go on and on, but I think I've made my point. Please keep this idea in mind as you think about how to improve the GNU/Linux system. There's nothing wrong with making things easier to learn, as long as you don't trade away ease of use.
--
Ian Peters
What's needed is a declarative, as opposed to procedural, way to specify what "installed" means for a device or a software package. The problem with procedural representations is that it's hard to do much with them except run them. Given the specification of something in this form, along with specification of previously installed things, it should be possible to perform all the following operations:
The key idea here is to get away from procedural scripts and to move toward a declarative representation that can be used for multiple purposes.
This is kind of abstract. To be more concrete, you want a description of a component that contains lots of information like:
Package XXX requires file YYY with checksum ZZZ installed in directory DDD.
This provides information that an installer or an uninstaller needs, but more important, it allows you to find conflicts between components. That's the part of configuration and installation that usually gives trouble.
"cfengine" is a step in the right direction, but they don't quite have it right. A popular package that got this right, one that let you do all four operations listed from the same description, would be a major advance.
Ok, devfs won't solve all the problems, but devfs support is one major step that needs to be taken by the kernel to make whole device management easier. The device namespace in Linux is so incredible polluted it's just too much for new and experienced users to deal with. There are 5103 entries in /dev under RH 6.1. With the 2.4 kernel, this will increase even more with the new devices (I2O, Firewire, USB, etc.) It's completely ridiculous. If /dev only showed the devices that were actually on the system instead of every possible one, it would be much easier for people to tell what's what. Imagine if /dev/modem only appeared if a modem device was detected?
--
Deepak Saxena
Deepak Saxena
"Computers are useless, they can only give you answers" - Picasso
You can/should/have to standardize... even win16 had a consistent *.ini file syntax that made sense even if you had never seen the application before. Why can't Unix standardize? why not Linux?
/etc/* and their siblings. Not only the original software which gets fed said files, but other software as well. Changing things would break huge amounts of software. Ironically, some of these programs are automation tools design to make admins' jobs easier.
.INI files; others will want XML; others still will want something based on their favorite scripting syntax. Who gets to be king of the world and decide the standard?
Mainly because of that beast that causes engineers to shudder and admins to dive for cover: Backwards compatibility.
There is a huge installed base of software that reads and/or writes the countless configuration files that live in
There are other problems as well. For one, what format do you pick? Some will want Windows style
There is also the legitimate technical complaint that no one format fits all possible uses. The sendmail configuration file format is a programming language all its own; it would be tough to reduce it to a universal format that would work for all software.
In short, changing things around to use a single standard format would be akin to getting all the people of world to settle on one language: Really nice idea, but impossible to execute.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
The biggest problem with all these configureing programs is that you the user are limited to what the programmers have built in. Also these programs make a mess of the files. I gave mandrake a try a while back and for me it was the hardest thing to use because the config program didn't have anything in it for configureing ip_masq and more that one nic. The rc files are a mess and imposible to trace.
I started out using slackware and I found most of the config files were easy to edit manualy and any special setups wasn't that hard to configure.
One of the biggest problems I have when I sit down at a windows 9x machine to fix something for a friend is that I have no way of knowing what the box is trying to do or what has been done. And then theres the rebooting *shudder*.
What we need is a stadard layout for config files. That are both easy to read by humans and programs alike.
God, root, what is the difference?
Here's another little story.
I owned a Toyota MR2 a few years back, which is a mid-engine car. That is to say, the engine is not in front of the front axle, it's in front of the back axle, behind the driver.
I drove a long highway trip, visiting relatives in a small town, just when it was due for oil. I didn't have the option of going to a Toyota dealership to get the service done. I went to a professional looking establishment a relative recommended. I drove up, and girl waived me into the garage stall. She must have been the mechanic's girlfriend, just killing time and helping him on a slow Wednesday. She made a hand gesture for me to "open the front hood."
I smiled, and shook my head no. When she came to the window, I explained, the oil's behind me. Her boyfriend assured her that I wasn't pulling her leg... the engine compartment really wasn't up in the front of the car. She couldn't get over that... a car with the engine in the back!
Sure, if you *know* the architecture of MSDOS and Windows starts with a kernel that reads AutoExec.bat, while the architecture of Unix starts with a kernel that reads /etc/inittab, you should be able to find your way around.
The last time I used Unix, there was no X login shell. Why would I look into something that was named /etc (as in, miscellaneous afterthoughts) for the core, key, central file that controlled all run levels? It's all a matter of context.
There's a difference between being stupid, and being ignorant. One can be cured.
[
VGA-16 colour support in 640x480 (ie: an video card and monitor that can handle this is likely to be on the target machine), so GUI config tools are quite possible from the earliest get go.
Here's an idealised setup routine:
* Setup Wizard is a version of netconfig and the lilo conf with the "click for help and examples" and related documentation all in one interface, allowing easier first time setup.
For an idealised setup like this to happen, there need to be a few more tools that don't (AFAIK) yet exist, as well as a few modifications to existing tools. X, for example, should default back to the VGA16 colour server if it suddenly finds the video card is different (ie: the 3Dlabs server is run on a non-3DLabs card). A simple program that is set to run in the default system-wide xinitrc can detect the fallback, and open up a helpful wizard for newbies. For non-newbies, it can allow skipping of the dialog so they can get to fixing the problem themselves.
Another thing would be a good program for setting up your XF86Config for the first time. xf86config is kinda complex and lengthy for a newbie. Since the kernel knows about the hardware, how hard would it be for a program to check the
Finally, a nice program I'll call "Control Panel" needs to be created. Yes, it'll be a blatant rip-off of the Windows control panel concept (which, IMO, is actually implemented semi-decently). A "Container" window is shown, listing the various configuration backends it understands. IE: for networking, it'd probably want an xml file describing how to obtain its settings, how to committ its settings, and how to format its GUI dialog. This could be implemented in GTK+ with libxml and included in the system menus of the various window managers and desktop environments that ship with the system. What would absolutely have to be shipped would be the basic complement of backends: X display settings, networking,
** Package Manager: To my taste, there are no "good" package managers. Something that could keep track of how often certain packages are used, could handle the installation of autoconf, RPM, deb, and Slackware tgz through support programs, and could finally centralise all of these disparate ideas would be what I'm thinking of. NT 5 has something like this, and it suprised me when I was playing with it. It's butt ugly, but it really does track how often something is used -- a big plus.
The problem is, of course, the fact that there are hundreds of window managers, and a few desktop evironments to boot. Under Win32, the installation and removal of programs has been simplified because of the add/remove control panel applet. True, it did little but point the appropriate uninstall program at the appropriate install created setup file, but the Linux world does not have something like it. Remember, their add/remove applet handles all kinds of setup programs from different companies (install shield, MS, Norton setup programs, etc). Second, the "control panel" is reinvented poorly by desktop environments like Gnome and KDE. Their internal config programs are great for modification of their own startup, look & feel, and window manager, but they do not address things like network config, kernel reconfiguration and compiliation, etc. The things they do allow you to look at are limited. KDE's "SMB status" tab is interesting, but you can hardly reconfigure smb.conf from there, or do something like launch Swat and connect to it in a browser.
If you've not noticed, all my ideas for "new" programs, or modifications to existing programs, involve ways for these many disparate ideas and design philosophies play nicely together. An "over" package manager that allows the user to point it at a package (or various types), and letting it handle the implementation (calling rpm, installpkg, or configure --prefix=/usr; make; make install; recording the changes and monitoring usage) would do much to make life easier for both the newbie and the guru alike (in my "over" package manager, the guru would be able to easily modify the default config "template" args, supply their own args, etc). For things like X, there would be a way to figure out problems, and help the user cope with them (rather than "vi
Just my opinion
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I honestly think that these sorts of beliefs hold back the acceptance of computing into the areas where it could be used in the most interesting ways, i.e. by people who may not understand computers.
Sure TCP/IP is complicated. So is a Pentium chip, I don't know how superpipelining works and I use the thing just fine. There are a zillion examples of this in technology - compexity made usable. Unfortunately we haven't mastered it in computing yet.
When we do, and giving up the idea that our area of specialization is just too complex for anyone to simplify is the first step, then I think we'll really be making some progress.
Hotnutz.com
"preview what has to be done" just tells you which services it's going to restart (i.e. inetd) but it doesn't tell you which files it's editing (i.e. /etc/hosts)
----
I have a rabid hatred of XML. It's just such a hideously ugly language that I could never stand to use it. Markup languages seem more or less acceptable for text formatting, though they aren't much fun to write by hand, but they are just about my last choice for configuration (or for general data description, or programming). They're also hideously verbose, wasting keystrokes and network bandwidth alike.
I still don't see any advantage to XML. Standardizing on a completely general language is about as useful as standardizing on "an ordered list of bits." If you're going to extend it you still need code somewhere that actually understands the data. Parsing a configuration language is trivial compared to actually deciding what the content and structure should be.
Yes, I know, you can make a GUI editor that understands the format of your XML-based language, and gives the user options, but I really don't think this is more than a superficial benefit. People should get used to editing plain text; it's the basic skill of running Unix systems, and a damn good thing to standardize on. Text editors have been tuned for a long time, and they can be used very efficiently with a little practice - much more so than a configuration GUI.
A more useful thing might be to start having a standard script for each plain text configuration file, which interleaves it with a man file, putting all the relevant entries right beside where they'd be used, allows the user to edit the file in this way, then removes the man comments (for efficiency in reading the config file) when he is done. This way you could get what is IMHO the main benefit of GUIs: having configuration options laid out in front of the user to select, with all of the traditional benefits of plain text (or rather, unique syntax) config files.
ah, that is your problem, you are not trying to be "elite" but you are trying to prevent other people from doing things to help others. No one forces you to use any tool. heck you dont even have to use a fricking distro! you have the kernel, build your own! heck, or just keep running what you are running and never upgrade. why is that so difficult? why must we always have social groups that try to keep others out? are you so much better than the other man that you refuse to be next to him?
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
The aesthetics / ergonomics (loosely speaking) of software is a big interest of mine. That's not because I'm a software expert, but rather for the opposite reason: I can figure out a way to misinterpret or fail to comprehend directions from practically any source, and I'm sure you can think of examples where you laughed at the guy going through the door labeled "Enter other side" ass-first or whatever. Yes, that was me, and it still hurts. I've hurled a fair number of CDs across the room because of frsutration at installing the software they contained onto my standard-issue, plain-vanilla PCs.
;)
The arguments that easy-to-use GUI tools make true, deep learning harder by eliminating the need for it have merit. But there is a threshold beneath which learning isn't even an issue, because the software (whatever software -- let's keep this agnostic!) never gets installed at all.
Remember, whatever we already know can seem pretty obvious. But the things we don't know yet can lurk tantalizingly close and remain unknown. My father, for instance, is an electrical engineer with a moderate but lengthy exposure to computers: no way could he figure out a GNU/linux install without plenty of handholding.
I offer here a small example of some documentation I've created with the intent of making the "... for Dummies" books seem positively erudite and obfuscatory, all for the purpose of getting software installed in the first place. After that we can worry about deeper learning. (Which goes for me, too.)It's specific to my present ISP. Illuminati Online (io.com), but I imagine would be easily modifiable for many others.
Hope someone finds it useful -- I like to find an excuse to post it once in a while so I can make sure the counter on my Web site works
Regards,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
I think that posts like this advocating a central, unified configuration language are the way things need to go eventually. But, for the mean time, and in the case of extremely complex configs that won't mess readily with such a standard, maybe the solution is to create a number of pluggable GUI tools that will work with the existing configs. For common tasks that everyone needs to perform, there will be the option of editing the configs by hand, or using the GUI. For more complex tasks, let new users select from a few options that will handle basic things, but leave the text files in place, so that if they (or anyone else) needs to change the configs by hand, they can. Let people who know the most about a specific tool work on a GUI configurator for it, and then create central configuration util that can call on those other, device specific units. You keep the flexibility of hand configuring a device in its own origonal config language for advanced users and sysadmins, but you add the ability for newbies to get basic tasks up and running safely until they get a chance to learn more. It's a little stopgap; the real solution is still probably to go to a more standard format; while it would still leave some problems with GUI implementation, it would still allow hand-editing of configs. If a GUI is written responsably and so as to not break the hand configs, than there is no reason why slapping a different interface on a configuration should cripple anyonthe device's flexibility, or your ability to debug config problems.
A centralized repository of pointers to all the configuration tools/files that exist somewhere under linux.
He is correct, merely finding out what needs to be changed can be a huge waste of time. Learning how to use Linux, no matter how innately valuable the process of discovery might be, does not mean we all have dozens of hours to spend finding out where inittab is.
Perhaps a listing of all the common hardware devices and software, with a paragraph describing the config tools or files, and their common locations. A link to the appropriate HOW-TO, or any other documentation that may already be on the system, and links to useful URL's would be a great time-saver. Maybe this could be added to linuxconf for the bits it doesn't currently handle, and as a fallback for the stuff it does.
I imagine a tool like this would be a source of encouragement for the many people who are willing to experiment with Linux, but may actually have a life outside of computers vying for their time. Certainly many people that would benefit from the stability and versatility of Linux, but who might otherwise give up after too many disappointments trying to get thing X working.
Now the issue of standardizing on the format of config files seems like another great idea, XML might be well suited to the task, but merely making a common syntax would be a step in the right direction. Windows ini files were a model of simplicity, no matter which other faults they may have. Are there any XML parsers already written that can easily be embedded into an app to add this functionality?
Thought provoking question,
Alekzandr
Would be a kernel configurator that notes to you what hardware modules are actively used by the system (like SCSI modules). Though you would still need to know your hardware fairly well, the kernel configurator would give you little heads up before you exclude modules you REALLY need to keep active.
Chas - The one, the only.
THANK GOD!!!
Chas - The one, the only.
THANK GOD!!!
Almost all of the arguments against GUIs that I've read here rest on the fact that GUIs and flexibility are somehow mutually exclusive. I don't think that's necessarily true. It's easy to point at Windows and say that GUIs are inflexible, but that's overlooking the underlying truth: Windows is inflexible; why should the GUI be any different?
Why not make a GUI that's a tutorial as well? Why not make a scalable GUI? Instead of assuming that the current UI metaphors are the alpha and omega, why not investigate new and alien UIs?
Why not have a configuration tool that uses plugins? That way the poor config authors wouldn't have to be responsible for keeping up to date with all the config file changes.
Why not have each plugin include a paragraph for each option explaining how to set that in the raw config files?
Giving something a GUI frontend is not the same thing as making it Windows. Let's get some ideas out here instead of the same old cantankerous crap.
-- I can't think of anything witty to put here. Sorry.
This is why it's great to have multiple distributions. I would never put mandrake or corel on a server or similar non-desktop machine. But on my main workstation, I would like to live happily without text-mode screens. There will allways be distributions that cater to the server environment - because, as you say - it is one of the primary (and best) uses of linux.
dufke
-
__
Comment submitted. There will be a delay before you understand what you posted.
Just imagine if linuxconf was like it:
* It would be dismembered in a number of system commands; like, if you would change a device, you would use chdev; if you change network parameters, you would use a command called chinet; if you would delete a filesystem definition along with its partition, you would use rmfs; if you would list devices on your system (with parameters that specify things like: devices actually working of just device definitions), you would use lsdev, and so on. Mnemomic enough.
* You could get to where you want by a shortcut, not having to navigate through awkward menu options every time. Example: linuxconf user would take you to the "user accounts" section.
* You would have a less irritating text interface. Ever seen smit? Its interface is VERY simple. A title on the top, some options, each one in one line, the one that is selected is highlighted, that is, written in reverse. In the bottom, a small keys chart. And that's it. No fancy ascii art and text contours. Fast and visible. Straightforward.
* You could see the command, script, or linuxconf "subsystem command" it would execute if you selected the option. For example, if you fill the form to create a user and press F6 to see what it would do if you pressed enter, you could see something like: adduser -c 'New user' -d '/home/user' -G 'users' -s '/bin/ksh' 'foouser'. Or, if you are just about to reconfigure the serial line, you could get some chdev -l ttyS0 -a baud_rate=9600 -a parity=none -a stop_bits=1.
* EVERY option or entry would have a dedicated context-sensitive help if you pressed F1 (and not a general screen with boring explanations. Let's get to the point!)
* There's still more, like types of input (choices from certain lists, which are also activated by scripts or commands; numerical values; string arrays; pathnames), logging everything (even the menu entries selected) to a text file, but I almost lose my hopes... Something that born to be linuxconf will NEVER get to the feet of SMIT.
Really, linuxconf designers and programmers should get a grip on the better designed UNICES. Alas, they make a good work, they make it for free, yadda yadda yadda, I know that, but there IS good-designed stuff on the market for them to take their ideas from!
Patola.
Patola (Claudio Sampaio)
Unix System Administrator
I think a lot of people are missing the point here. It's not that us folk who have been using Linux for years are being OS bigots and don't want to let everyone else play with "our" OS - it boils down to the fact that we know, from experience, that when a user becomes dependant on a config tool, they cannot solve the simplest (to us anyway) problems manually when the config tool doesn't provide the funcionality. The solution to this is simple - Create config tools which teach the user as they go along in configurating their system. Tell them *why* they need to create user accounts, and exactly *how* it is doing it etc. Don't just do it all for them, although you might get through the config a few seconds quicker, you'll be worse off in the long run. That way the user will be better prepared to be able to do the same thing on a system where the tool might not be available, or if the config tool is missing the functionality you are looking for, and will also give them clues as how to approach other problems. It's the same as in every other aspect of day-to-day life. There will never be a config tool which can do *everything* on every single specific system, and do it all properly. So the aim is to provide as much functionality as possible, and enough resources and clues to make sure they can intelligently think for themselves when the tool is lacking. Hopefully this will reduce the increasing number of I-wanna-be-spoon-fed idiots on IRC these days (some of whom have been using Linux for quite a while, but because they become dependant on linuxconf etc, they simply don't understand basic concepts), so that we can all work more productively. "Give a man a fish and he'll feed himself for a day. Give him the means to fish for himself and he'll curse you for the rest of his life"
"preview what has to be done" just tells you which services it's going to restart (i.e. inetd) but it doesn't tell you which files it's editing (i.e. /etc/hosts)
Um, I just double-checked, and you're right. I stand corrected. Somebody moderate my original post down with "-1, Incorrect".
(I could have sworn it told you the configuration files it was about to modify, but I must have been thinking of something else.)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
OK, fine; really, the format here is almost beside the point. I am sure that whatever group gets to decide on the format will be knowledgable enough to decide on something practical and readable for both machines and humans.
/. for that matter) agree that it is about time to move to a standardized format, and b) that this migration is as painless as possible. Let's agree on that, and get a momentum behind this. The engineering details warrant a larger audience and a much longer discussion...
The more important thing here, is that: a) the community (not necessarily us, this thread, or
engineers never lie; we just approximate the truth.
Forget to tab in syslog.conf? : comments got you down in inittab, typo in passwd locked you out? Guessing at possible values for
I fail to see how moving the data to a different location - or putting it into a tree structure - would make any difference at all.
Without dumbing it down, or removing flexibility, I believe a better way to manage the bits of configuration required by each program would be a centrally managed, accessed, API driven repository for config.
As I've pointed out, front-ending the whole thing with a database manager which keeps everything in memory exposes the whole damn thing to corruption. Obviously you haven't suffered under Windows as much as I have.
I don't pretend to know the right way to begin to code this up, but I'm tired of explaining to new admins that are looking to change X in unix, that the only way to know how to find the config file -- is to already know where to find the config file.
Ha ha. I sympathize with your newbies, but your answer is not strictly true. You only need to know what the file is called - and you can get that from the man page for the utility/program concerned. Once you do know what it's called you just do a 'find
No doubt some will complain "but that's too complicated". They may be right but it won't be solved just by putting the X config files into a central repository. If you want to master X configuration, you have to learn how it works. There are, unfortunately, not shortcuts to mastering a system with so many configurable options. Even if there was a nice GUI on it, you'd still have to learn what all the parameters mean.
Sorry Mr.Bell, but I'm fundamentally opposed to any scheme to take Unix away from the philosophy which makes it what it is: the most flexible operating system, the most robust application platform and the most feature-rich development platform in the world.
For those of you who have forgotten, or who are simply too young to know, here is that philosophy spelt out (you can find the original here):
Tenets of the UNIX Philosophy
from The Unix Philosophy by Mike Gancarz
ISBN:1-555558-123-4. Copyright 1995 Butterworth-Heinemann.
Reprinted with Permission of Digital Press
The main tenets of the Unix Philosophy are as follows:
1. Small is beautiful.Small programs are easy to understand.
Small programs are easy to maintain.
Small programs consume fewer system resources.
Small programs are easier to combine with other tools. 2. Make each program do one thing well.
"The best program...does but one task in its life and does it well."
"The program is loaded into memory, accomplishes its function, and then gets out of the way to allow the next single-minded program to begin." 3. Build a prototype as soon as possible.
Prototyping is a learning process.
Early prototyping reduces risk. 4. Choose portability over efficiency.
Next ---'s hardware will run faster.
Don't spend too much time making a program run faster.
The most efficient way is rarely portable.
Good programs never die--they are ported to new hardware platforms. 5. Store numerical data in flat ASCII files.
ASCII text is a common interchange format.
ASCII text is easily read and edited.
ASCII data files simplify the use of Unix text tools.
Increased portability overcomes the lack of speed (of flat ASCII text files...)
The lack of speed is overcome by next year's machine. 6. Use software leverage to your advantage.
Good programmers write good code; great programmers "borrow" good code.
Avoid the not-invented-here syndrome.
Allow other people to use your code to leverage their own work.
Automate everything. 7. Use shell scripts to increase leverage and portability.
Shell scripts give you awesome leverage
Shell scripts leverage your time, too.
Shell scripts are more portable than C.
Resist the desire to rewrite shell scripts in C. 8. Avoid captive user interfaces.
CUIs assume that the user is human.
CUI command parsers are often big and ugly to write.
CUIs tend to adopt a "big is beautiful" approach.
Programs having CUIs are hard to combine with other programs.
CUIs do not scale well.
CUIs do not take advantage of software leverage. 9. Make every program a filter.
Every program written since the dawn of computing is a filter.
Programs do not create data--people do.
Computers convert data from one form to another.
Use stdin for data input;
Use stdout for data output;
Use stderr for out-of-band information.
Ten Lesser Tenets
- Allow the User to tailor the environment.
- Make operating system kernels small and lightweight.
- Use lower case and keep it short.
- Save Trees.
- Silence is golden.
- Think parallel.
- The sum of the parts is greater than the whole.
- Look for the 90 percent solution.
- Worse is better. (I won't try to explain this one...)
- Think hierarchically.
Forgive me for reproducing the whole page here but I feel it's something everyone should see at least once, even the "click-through challenged".Consciousness is not what it thinks it is
Thought exists only as an abstraction