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."
And isn't that something Corel must have put into their distribution?
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
The organization i work with/for/own a slice of is actually in the process of creating such a tool that will do all that speare is asking for and then a whole lot more. its simple, secure, graphical, network aware and... well... there is so much to say about it that you may as well just wait till its out... it will be GPLed and the release is slated for the first week of march (we have 5 full time developers working on it). watch yer freshmeat =)
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
Try using Xconfigurator for you video problem. Make sure you know the type of video card and how much memory is on it first though... It will then ask you what type of monitor you have. 17" Sony is one of the options
This is a person that was brand new to Linux. You can hardly expect someone like that to just dive in and write it. You were new to Linux once, right?
I swear, it's attitudes like these that make me wonder how Linux ever got anywhere.
If you can't figure out how to mail me, don't.
For linux tips: http://www.linuxtipsblog.com
the new 7.x release of Mandrake w/ Cooker (beta), DrakX, linuxconf and Econf as defaults?
Remember guys, this is Amerika. Just because you have the most votes, doesn't mean you get to win.--Fox Mulder
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.
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
That's really a fairly lame thing to say. The simple fact is that there is a lot of stuff out there in relation to Linux that even keeping track of it all sometimes blows my mind.
Then you have to know how to code. I think it's asinine at best to assume that every Linux user needs to be a programmer. Not everyone who wants to use a robust quality OS like Linux has the time or inclination or knowledge to write code.
-K www.wackyboy.com
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?When I first installed Linux, I knew very little about the nuts and bolts of an operating system. Having been a Mac user for years, I had no idea as to the workings of an OS, how an OS did the things it did. Using Linux (LinuxPPC) forced me to quickly develop an understanding of the things that make an OS tick.
IMHO, I like the lack of GUI config tools, and, with the exception of kernel config, I hardly ever use them.
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).
any gui tool in unix (imho) should always allow the user to hand edit the file in question if they want to... there is not reason not to, really...
also, conventions must be kept to and prior modifcations/changes should be respected and held to.
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
Any linux config tool should not require X *cough*redhat*cough*mandrake*cough*. Some of are trying to set up Linux on 486s or 386s with 4MB or 8MB of RAM with small 135MB hard drives. I ain'ts gots no steenkin' room for X.
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 basic, 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
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
Unix Console was released yesterday. It is not exactly what you're looking for, but if you're a Mac user setting up a Linux box it may help. Basically it allows you to use most of the monitoring/configing tools on a unix box graphically, in a nice little app. It logs you in via telnet and then sends the command line commands when you perform certain tasks. Granted, it's optimized for Solaris, but it seems to do most of the things Webmin does.
(Runs on MacOS)
"In individuals, insanity is rare, but in groups, parties, nations, and epochs it is the rule." -Nietzsche
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.
--
What about building a text-gui index to the HOWTO files (HTMLed, I suppose) and putting it in the installer as a sort of online-help system? I have nothing against linuxconf, of course, but an easily accessable HOWTO database should cover a wider array of possibilities, IMHO.
Quantum mechanics: the dreams that stuff is made of.
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
Yes, I'm still a junky. Are you still a bitch?
This has more than once provided me all I ever needed to know about the configuration file in question. That's not so difficult. Just poke around /etc/ until you find a file that looks likely, then check the manpage.
Quantum mechanics: the dreams that stuff is made of.
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.
Chris has posted this information about himself, just to draw attention.
You want to know what? It will work because you and I are contributing to it right now.
Job well done, Chris. You are such a genious.
EverCode
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.
I have been a Slackware linux user for about 3 1/2 years now, and I decided that I would try Redhat due to it's new *advanced easy to use GUI setup* that I have heard from many people make it really easy to set up linux quickly. Well, after trying it out, I didn't like it. My main gripe was that I was limited in the length of characters I could type in the lilo header when setting it up in the GUI ( something like 15 or so letters ). I have an ABit BE6 mobo, and I was going to install linux to boot off of my Highpoint UDMA/66 controller.... I couldn't do it because I couldn't type the hard drive parms for ide1 and ide2. If you were a newbie or had a generic system, I guess the X setup would work ok... but if you want to do an even remotely non cloned setup you're screwed. After all this, I decided to go back to Slack because even though it doesn't have full RPM support IMHO it's easier to setup and manage. Plus, I'm sorry, but you can already do the IRQ checking and et.al. .... It's called pico /proc/whatever.
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.
I know of Lothar, it comes with Mandrake 7.0. The web page is at http://www.linux-mandrake.com/lothar/
From the web site:
"It is a fully GUI based tool which ties together many of the tools already included in a Linux distribution to automate and simplify the process of installing new hardware. Some items will be detected, others can be selected from a drop down list. The various IO, IRQ and such X86 annoyance settings can be adjusted from within this interface."
Opus: the Swiss army knife of audio codec
On a side note, those HOWTOs helped me out back when I started out (Slackware). They were text also, but html are available at the many mirrors for the HOWTOs. Of course, if you are trying to fix your internet connection, or don't have one, this isn't very helpful. The html's are distributed from, for example, linuxdoc.org or metalab.unc.edu. They come complete with a general index and then table of contents for each HOWTO. The people that I have converted to GNU/Linux have found these very easy to understand.
--
steve
C-x i ~/.sig
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.
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
It is better (in the 2.2.* kernels it is almost necessary) to use /dev/ttyS3 instead of /dev/cua3.
At least part of the problem is that there are hundreds of different configuration formats.
Basically everyone who writes a tool, utility or application has re-invented the wheel and written their own special configuration file format. This is partly due to the creators of the first Unix systems not creating a little configuration API/library to save developers some coding time.
Well. There is no longer any excuse. There are now a number of configuration libraries with differing properties and licenses.
Don't create "Yet Another File Format" when you code. Use one of the existing configuration management libraries. Check out freshmeat.
These include:
Name License Primary use
---- ------- -----------
GConf LGPL Gnome
parsecfg GPL unknown
libconfig GPL unknown
libproplist LGPL GnuStep
libcfg BSD unknown
One think to note is that the license of a library might well affect it's usefulness to commercial applications. A library which can be used for free software, but not realisticaly for a commercial application is, well, only half useful.
Deleted
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.
"We need software which is not just user-friendly, but also hacker-friendly"
"We need both."
looks a little friggin redundant to me
did you just happen to miss the word "ALSO" in the original post or what?
-dk
-dk
Dream with the feathers of angels stuffed beneath your head.
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.
What matters is an API. The fact that a configuration is stored in a file of format X or Y on disk or on an LDAP server, or SQL server, or web site becomes irrelevant.
Deleted
I've put mandrake 7.0 on my girls new box thrice just to try out the different configurations. "Lothar", Mandrake's config tool is the first linux config tool that rivels M$'s win98 control panel. Mandrake 7.0 found all of her hardware while it was installing, but I shuffled IRQ's on her PCI soundcard just for kicks. Smooth.
Lucky for you, Mandrake 7.0 is a drop in upgrade from Redhat 4.x and above, which goes back a couple years, ya dig?
The Corel linux 1.0 tools are damn nice, too. I wouldn't hesitate to recommend either distribution to anyone's gramma, but I tend to like Mandrake more. Ok?
-=nft1999=-
"We must be the change we wish to see in the world." -Gandhi
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.
[
i have been running linux for about as long as it
has been around, and i really happen to like the
fact that it did not used to have GUI's for
everything under the sun. UNIX has never been
ground for newbies and those weak at heart, and
i honestly dont think that linux should be any
different. i am NOT trying to be elite here
either--i spent very long hours with my nose in
books (and i still do, since i admin UNIX for a
living now) to learn what makes *nix tick.
"if you make a tool that any moron can use, only
morons will want to use it"
i for one will depart from the linux world if it
keeps progressing towards the Mac world.
A year spent in artificial intelligence is enough to make one believe in God.
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.
Basically, what is essential here is that we all agree on what kind of slot to use between the screwdriver and the screws. Then we can use a hand turned screwdriver or a motor driven screwdriver. And we can use self-tapping screws, or machine screws, or whatever we like.
... pluggable tools.
If the configuration state is stored in a file with a document that makes the file format open, then you can use fancy GUI tools, or vi, or a script, to manage the configuration. This is what we need to require
now we need to go OSS in diesel cars
Whatever utility results from this thread, its needs are pretty fundamental to BOTH hacker and avg user. Both groups need an operational machine, which relies on proper configuration of HARDWARE PLATFORM SPECIFIC things. In Intel land, there are devices that are present, each of which has configuration parameters. SGI,Sparc have their own subleties, etc... It is quite logical to organize a Device Manager to follow the structure of the hardware. Makes less sense to have a RedHat specific or a Debian specific approach IMHO. We (collectively) can only benefit from commonality that serves a purpose. If it looks like windows, so what! Does it present the information needed to verify and adjustments needed to configure these devices? Cool! We all win! In order for Linux to gain mass acceptance in our society, it needs to bring technology to the average user. Dont we all need hardware that is configured properly and be aware of this fact? If there are settings beyond what we need to establish basic functionality, then make extensions and call it the 'Extra Credit Extensions (TM)' If something is found to be misconfigured, maybe we could trap the error codes, and crank up ppp, dial up to a web site and automagically search for cures? (Ok, lets call that the next step.. :^) No one wins if Linux is difficult. The casual one loses the moment, the hacker loses the future. Replication is the sincerest for of competition! John Westerdale
Instead of:
<device>
<name>eth0</name>
<address>192.168.1.2</address>
<netmask>255.255.255.0</netmask>
<onboot>yes</onboot>
</device>
I'd rather have:
device = (
name = eth0
address = 192.168.1.2
netmask = 255.255.255.0
onboot = yes
)
XML may have some cool features, and be useful for embedding information descriptors and tags in documents, but for building config files, it's hard to read and basically sucks.
now we need to go OSS in diesel cars
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
Seems to me the issue really isn't whether there is a GUI or not. A new user might be perfectly happy with a form he fills out with what he wants. The form could then generate a script that changes all the config files, etc. The problem is that the setup is spread all over the place and is not consistent. Throw in a few arcane terms and uninformative abbreviations, and the new user (or moderatley old user) must perforce resort to HowTo's and other resources to try to figure out what needs to be done.
I love the /stand/sysinstall config tool that comes with FreeBSD. With that I can run fdisk or disklabel, setup networking and ppp interfaces, install software from the ports collection and parts of xfree86. Other than having to recompile your kernel for things like sound its great.
Only the State obtains its revenue by coercion. - Murray Rothbard
just like the hot grits I poured down my pants.
Only the State obtains its revenue by coercion. - Murray Rothbard
Am I the only one who finds his request impossible? The unified tool sounds nice, but I don't see anything more powerful than yast or linuxconf in the near future. The reason? It's really simple. Have you ever in your history with linux seen any configuration file that have similiar syntax? .vimrc's use " as comments! There are just too many different software packages written by too many different people to enforce any kind of a standard. And without a standard any package that claims to be a universal configuration file tool would need some sort of macro for each config file (like linuxconf).
And how would you write the GUI? What a mess, and I though linuxconf was ugly.
Maybe it's just me being pessimistic or maybe it's just that man or bitchx seem good enough to me (I've been a linux user for about 9 months)
Different Strokes for Different Folks. 486's can still perform certain tasks - like audio. I'm still trying to figure out why a 133MHz 486 can't decode MP3's when they have a thousand clockticks to get a single point decoded.. I'd have to lay it at the feet of the operating systems (Win95 and Linux). A 486 should be able to be a jukebox for ones stereo.
Think about this. If Linux doesn't become easier to use, we will still be using Windows @ Work b/c nobody will want to put up with it. Think of the hours some of you must dread at work dealing with Windows crashes and stuff, the nightmare which is life now. You could be living a better life if Linux and Unix for that matter were easier to use and more generally accepted. Just think about it. :)
And rememebr...
X=X+0
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.
I needed a network print server after the old Axis box dies. These things aren't cheap to replace, however, we had an old 386 doing nothing out back and put Linux on it and a couple more parallel ports and presto! A practically free print server. It performs beautifully.
It's funny, you remind me of a guy used to I know when I was a phone monkey. Really great with computers, but my boss and I wouldn't let him near the phones. I think the problem here is that we're talking about two seperate things here. Neither of us wants to deal with the lusers and jerks. It's a bad time for everyone involved. But haven't you ever had a conversation with a technically competent person who had a gap in knowledge that you helped fill in? Or the other way round? I think that filling in those gaps can mean as much to the linux community as helping to code software - after all, it means more people who know what they're doing.
In my own linux migration, I started out by researching what was involved and what sort of hardware changes I'd need to make. One of the ways I did this, other than reading through distro docs, was by asking friends of mine who were already running some sort of *nix/BSD what their experiences had been. Aren't newbies allowed at least that? Without meaning to sound to much like a Junior Flowerchild here, mellow and cooperative can be good, dude.
itachi
This is not always true.
Sometimes, the front-end ends up being the only way to configure whatever it's supposed to configure, or the front-end is the only one with the documentation.
For example, look at OS X Server. Yes, it's a real unix, but everything is handled by gui-front ends, or by some java application that you access through netscaping to some port. The problem is that you can't really do something non-trivial (like add a user) without a java-capable browser (which OSX doesn't have), or by actually sitting down at the machine (so you need at least two machines handy to do any work). When things go bad, you have to go to the machine to change something (you can't just ssh in and mess with some config file). The man pages that came with it were a joke, and you couldn't change anything about the appletalk sharing or the Macintosh Manager authenticator through the console. I had a list of about 30 users I wanted to add -- I couldn't do any sed/awk magic with /etc/passwd and be done with it, I had to type in each name/passwd individually (and mess with the mouse in between adding each name to change groups, etc.). Sure, it was easy to add a user if you'd never done it before, but if you wanted to do any maintenance/configuration, you had to sit at the computer (no X server), with another machine nearby (no java browser). Altogether, it was a big mess.
Fortunately, this happens only rarely in Linux -- I can just copy my config files over to a new machine when I set it up and I can change whatever I want about the system with an ssh session from anywhere in the world. The point is that if new tools start being developed with gui configuration in mind rather then textfile configuration, people need to make sure that instead of just saying "to change xyz, click here," also saying "to change xyz, edit /etc/foo.conf; see foo.conf(5) for details." OSX didn't provide the textfile configuration I needed (and as a result, I haven't touched our OSX server in months).
This is already starting to happen to Linux. For example, I use WindowMaker for my windowmanager, and to configure it, you can use WPrefs, which just writes some config files. Unfortunately, I couldn't find the documentation for those config files (and they didn't have any comments at the top to help me), so I was stuck using WPrefs to change things. At one point, I wanted to get rid of all icons entirely, but there was no way of doing this with the front-end. I needed to edit the files, and the only way I could work was by changing something, restarting windowmaker, and seeing if it did anything (and config files would be overwritten at points so I would lose all my work). I finally did it, but it was a slow and tedious process, whereas if I had a manpage for the config file, I could have had it done much more quickly. This was a simple task, but imagine if there were no manpage for /etc/sshd_config or /etc/smb.conf. The only way I was able to get X initially working on my machine was to edit XF86Config, and I wouldn't have been able to do that without a manpage.
My point is that gui front-ends (like xf86configurator or WPrefs) are replacing my emacs, and I don't like it. People are starting to put more thought into writing front-ends for editing a file rather than documenting the file's format.
it seems to me that the problem isn't that the admintools don't give enough feedback, but that the programs (and the system itself, let me finish) are doing things the wrong way.
anyone who has ever put a production machine up knows that linux's killer apps need configuration that consists of more than key=value pairs. bind, exim, gnome, apache, even the password system. they all use a different variations on a theme. a tree-like structure with branches that have properties, a heirarchical database.
perhaps what we need is a standard, powerfull way for programs and applications to store their configuration. an extensible database, perhaps something like LDAP. i'm not saying ldap is the solution, but maybe it is.
once we get all of that in place, we can begin to write more comprehensive admin tools. you could throw a command-shell like one on an emergency disk, or a GTK based one on the distro install cd. i don't need to tell you how nice it would be to have some sort of network-wide configuration system for labs and server clusters alike.
the original author makes a good point. the user has to be able to use it, but then so do we. i know from experience that if you make a tool too easy to use, only the inept will want to use it. make it look sexy AND functional, and we get a tool that everyone can use.
get this framework in place, throw in x11r6.4 and a few more months work on Gnome, and the linux community will qualify for a seat at UN Headquarters.
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
I would like to see some hard numbers on how many linux systems are used as routers, mailservers, webservers, and in embeded systems. Compare that number to the number of desktop linux systems. I would think they are quite close. I have 32 no-user (servers, routers, etc) linux systems in my company's network, but we have maybe 15 linux and solaris workstations. The rest of the desktops are for users trapped in Gatesland. At my home I have 14 computers (9 are linux, 2 solaris, 1 HP-UX, 1 OpenVMS and 1 True64.) and 4 users (family). Only 3 of the computers have monitors and keyboards (excluding the TRS-80 I have setup as a terminal). Of the systems without monitors/keyboards only 1 has X installed.
I would like to destroy microsoft by stealing all of their desktop users, but not at the expense of making linux (or at least the major distro's) bad for server use.
The current Slashdot moderation system is made by gay communists!
A package manager. Specifically, the Debian apt-get does all that you describe. It has a "status" for each package; since each one is configured as it is installed, instead of the files being tossed onto the drive, and good luck configuring, try starting in /etc...
:)
If you attempt to install a package with apt-get, it will inform you of any additional packages needed in order for this package to be installed, and also if any packages currently installed conflict, and would have to be removed. If you think this is OK and opt to continue, it will do all of this for you.
Every time you run apt-get, it checks the packages installed. If there are some that were not configured (including, of course, the newly installed ones, should they need configuration), it will prompt you to configure these.
Debian is perfect; why don't people listen to me?
WMBC freeform/independent online radio.
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!!!
It seems that what you want is best served by going for SuSE Linux. Most of the set up is covered by YAST. You can go straight to SAX if you just want to setup the GUI stuff.
/var/run thrown in for when you start running scripts and want to shut down processes.
You also get that useful
SuSE is so far ahead of the others for both beginners and the more advanced that it is the only one I recommend. The people that hate it are the fundamentalists that are not worth listening to anyway.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
I've used most of the admin tools, linuxconf, smit, sam, etc. They're tolerable for letting an inexperianced sysadmin change something on one box. However, I've never seen one that scaled well to a cluster of machines. When you have 50, 100, or 1000 machines to admin, each with it's own requirements, those tools break down. You have to start scripting.
You also learn it's better to parallel-rdist a config file out, than to try to rsh the same cli admin tool on all boxes. At that point you're back to needing intimate knowledge of the config files. Once you have that knowledge, it's almost always faster to just hack the file than to use the tool.
As for graphical administration and installation tools, please remember many (perhaps most) professionally run unix boxes do not have graphical consoles. They have serial consoles wired into telnet-able terminal servers. The admin may be dialed in from home, or in an office 1000 miles away. Even if the machine is in the same room, a serial console has huge advantages. Cut and paste between the consoles of seperate systems is incredibly useful.
If you ctrl-alt-f2 out of the graphical install to the bash prompt, run fdisk, and go back in, the graphical install doesn't notice you've changed the partition table. There's no refresh button. Even if you go back a few steps and forward again, it doesn't reread the table. It's annoying.
My only complaint with Disk Druid is I have trouble getting it to create the partitions in the correct order. I like to put swap, tmp, and var near the begining of the disk. Rotational delay is smaller there, so you get slightly higher performance. Disk druid seems to like reordering my partitions.
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.
Personally, I prefer text-file configuration for most things, and having tried LinuxConf I find it more confusing than poking around in /etc. /etc/inetd"
::sigh::
But I'm sure that for new users, something like wharf (or redhat's control panel) with an easy API to add your own dock-config-apps would help quite a bit.
It would allow a centralised config centre, but without being tied to a particular distro/desktop/windowmanager.
Even if an app author could easily add a button which just opened up a text editor with the config file for thier app, without having to go through a linuxconf/redhat/yast/kde/gnome config tool, I'm sure it would help a lot.
/etc/dock-config
...
Inetd
{
"Setup Inetd network services"
"/usr/local/icons/inetd.xpm"
"xedit
}
Gnome-Control-Centre
{
"Configure GNOME"
"/usr/local/icons/gnomecc.xpm"
"gnome-cc" # or whatever it is...
}
SUSE-Config
{
"Configure SuSE"
"/usr/local/icons/yast.xpm"
"xterm -e yast"
}
...
To add a button for your app/helper just becomes a matter of appeneding a little text to the file.
If only I was better at coding in linux.....
Billysara.
Just because it hasn't been done before, doesn't mean it can't be done at all. Making things on the surface more simple can't do any harm, as long as there is still access for the 'power users' to create/edit things as they see fit. I'd be much happier to see easy configuration via a GUI, so long as the config files were still easliy accessable incase I'm not happy.
Why are we competing with Window's Control Panel again?
In my experience the more graphical config tools are used in a distribution, the more they are shoved down your throat and the more hidden the real information in your OS.. MacOS anyone?
But I couldn't find answers because I didn't know the questions.
I would love to know what every file was used in concert for, including where to go when I needed to know subsystems in detail. If I knew, I would draw a map. A map is what I call a "graphical" install. GUI installs are just a quicker way to hell (let me do what I don't know I'm doing faster).
Instead, I want a wholistic, fine grained, system encompassing map (an actual drawing) that can guide you wherever you want to go.
Well, I also managed to teach myself how to use and play around with the workings of Windows, but it's one hell of a lot easier to do that than with Linux. Windows has nearly everything in nice and easy GUI, which any reasonably intelligent person could work their way around to find out how perform configurations and such, whereas in Linux everything is far from obvious.
Yes, I do it is... http://pegasus.rutgers.edu/~elflord/font_howto/htm l1file/
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
Webmins license is perfectly fine since they got aquired by caldera. And its an excellent config tool. Easy to use, very powerful and secure (as far as I can tell...). It does require knowledge of the packages you are configuring, but as far as Im concerned hiding all power and configurability from a user just so he can generally use things without reading or even thinking about them is fine for maybe a desktop, but not for server configurations.
I'm not a newbie, and I'm not a Guru. I'm not a sysadmin, but I would'nt mind learning.
.configs have different syntax, but to 'standardise' is to not evolve.
One of the beauties of open source OS is that every component is accessible. It can be configured exquisitely (if you know how, which I don't). Now imagine having ten different ways to configure a batch of stuff, none of which work quite right. Well, now you're thinking like an MS engineer.
Something should only need to be said ONCE, and right now the config files are the ultimate authority. It's like when you want to complain about something; you ask to see the Manager, not the teaboy. GUIs are like the teaboy... friendly but only do simple things. They have no power.
Yes the config files are idiosyncratic. But hell, Windows is idiosincraptic. Over time perhaps, syntax could be pruned, but ooonly by the respective authors, contributors etc. Let people tend their own garden. If they want to simplify, fine, but don't exclude people just because they invent clever ways of saying things!
So that's two issues: that config tools are never the real authority, and can (and will) get out of synch, and that the
The third and _separate_ issue is The User. We often talk as if there are only two kinds of users, like the novice and the expert. But really there's a whole spectrum of semi to skilled user 'levels' in between. Our documentation doesn't reflect that. You're either a Dummy (insert hot poker in security hole here) or an expert. And with today's documentation, the leap from newbie to sysadmin is like a great chasm.
I think that's a big problem against adoption.
People at home have to be their own sysadmins, to some degree. The GUI install may get your system up, but it won't teach you anything. Nor should it. You know from your own experience, that you learn best when you _need_ to learn. Say you want to buy a printer for your system. Where do you start? If all you see before you is fog, you drive slowly. If the road is clear, you race ahead. Starting with Linux documentation is very very foggy.
This problem comes from the exclusive use of text based description (how long does it take to read _every_ man page, or even books ?).
I am appalled at the lack of _diagrams_. Sequential statements are fine for programmers but when a person arrives in any foreign city the first thing they do is purchase a MAP. This is why the mac _tends_ to work; because the map is fairly clean and accurate. This is why Windows doesn't; because what the GUI is trying to map is fucked up anyway.
With a MAP of systems, that point to maps of subsystems, which hilight general behaviours, and ultimately (for those in need when fsck suddenly starts complaining) individual executables, configs, scripts and the data formats being dealt with, willing users can educate themselves as needed. Our docs need to show the big picture, quickly and clearly, and where to find the detail when needed.
After having used Linux for several years now, I much prefer vi on the command line over linuxconf et al. You know exactly what file you're changing so you can make a backup in case your changes don't work and it's easy to do the configuration from a remote host.
What the new user lacks is a comprehensive view of what services need to be configured on their system and what files and options are generally used to cofigure those services. Linuxconf provides the view, but it hides the actions actions it takes and the files it modifies.
I propose that we make a simple HTML and/or text based document that provies a reasonably comprehensive list of all services and options that one typically wants to configure on a Linux system. The document would have a section for each service and the sections would be no more detailed than necessary to provide the new user with the knowledge to minimally configure that service, (bascially allow them to configure as much as GUI tools typically allow.) This kind of document is good for many reasons: 1) I means GUI tools don't have to be written. 2) It builds user's knowledge of their system. 3) It reduces dependency on those magic GUI configuration tools that limit the user's control of thier own system.
The HTML/text configuration files I'm talking about already exist in my company, and I'm sure in many other companies too. We have lots of HTML documentation on getting Linux running in our environment. This information could be easily adopted for more general use
Hey, maybe this is another project for me!
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"
name = eth0
address = 192.168.1.2
netmask = 255.255.255.0
onboot = yes
>
I believe this is valid XML.
Got HTML? Want LaTeX? Try html2latex
so, does anybody know if the distros out there that are _aggressively_ trying to increase the number of linux Users (ppl who spend ~5% of the time as su or root) are using or hiring Usability and Interface professionals, or firms to perform usability and experience testing and user research?
it seems that much of the experience of linux is the result of decisions by The Community who are, of course among the most literate users out there, but are not necessarily the best at creating good user experiences and usable products.
what has been done to date is in fact amazing, but now that linux is getting more attention and companies based on linux are public and worth millions or billions perhaps a great deal of attention can now be placed on the usability of linux by the growing usability/information design/interface design professions.
linux to date has been almost entirely an active group of Root Users, and Super Users. but now there is a growing need and demand for linux by users who spend 95% of their time as Users. (and many of these would-be-Users are reading slashdot and trying to install the current crop of distros.)
the friction between the elite and the plebes has been ever present-- from the western european monks who did not want people to learn to read, and after just reading Steven Levy's Hackers i would say this friction sounds similar to the MIT hackers of the 50s and 60s who did not want deal with the Real World and remain in an esoteric utopia, and similar to the big hardware manufactures of the 70s who _laughed_ at Wozniak's idea of a home computer for the masses... ha!
so does a 'Community Group on Linux User Experience and Usability' sound way to idealistic? how about a weblog about the human side of computer interface? how about a Open Source Usability Group which is funded by various for profit groups? (Do groups like this exist already?)
just my 2 pesos, and some ideas...
-neotint
This is kinda what I keep saying about Linux as a whole. I love it, I enjoy using it. I'm also someone who enjoys playing with computer hardware and software, etc. Many computer users don't have so much fun doing these things however.
GUI tools to configure your Linux install would be a good start. Strong configuration docs would be great as well. If Linux could overcome a user's inherent belief that it's a 'geek OS' that they won't understand or be able to learn, it could make much greater headway into both the consumer and business desktop markets.
One comment I've seen a few times in this list is that a GUI would somehow be 'dangerous' by allowing security holes to be created in your OS. I fail to understand how a GUI would create more holes than a complete and utter lack of understanding of how to properly configure your daemons and drivers.
We need to listen to our mildly less computer literate friends when they describe why they wouldn't like to use Linux. They are the strong majority and will be the ones using the OS when/if it becomes mass market popular.
"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.
I'm surprised nobody ever mentions WebMin in these discussions. I use it on a few machines I am responsible for. I think of it like the Linux Control Panel. You can configure most services that Linux machines use, manage processes, users, groups, etc.. All via a standard web browser interface. I've put it on a few machines and trained NT admins to use it. Most of them think it's eaiser than NT. It's free for use, and IIRC presently can be considered "open source". Although the author does mention that some modules in the future may be payware. And the interface is MUCH nicer than LinuxConf, IMO.
Actually, they are specifying a namespaces standard for XML which will allow you to mix different DTD's without confusing what tag belongs to who.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Agreed with most ... Unix/Linix is the better way to go.
... as "?knowledge and experience?" in the office with money; ask, advice on what to buy? BUY MICROSOFT!
Reality >> (sometimes) I observe
Reality >> The lower the knowledge and experience, the lower the requirement to be an expert/professional, and the greater the reliance on MS Gates products which leave the lazy professional with a target to blame (software is not available yet, the lie) for a problem resolution, then the more MS Gates products will control some parts of the market.
The lazy professional (some [not all] MS Gates products supporters) screams buy MS Gates products and think's "I have an easy target to blaim for problems" that only MS can fix. They best of Reality: (1) high paid easy job, (2) always MS to blaim for problems.
Linux/Unix needs two flavors: one, for the very bright, experienced, creative, and knowledgable user/administrator/developer, and another Linux/unix for folks who just want to use and minimully configure their software for everything.
I'm not sure I stated what I believe very well this time.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
The problem for Linux is that it is available for so many different types of hardware!
That's why (eg) Sun's adminf.. er, admintool works as well as it does. They don't have a squillion different types of video cards/audio thingys/disk drives to worry about.
DEVFS will go a long way to improving the clutter in /dev , at least if it gets supported by the major distributions AND hardware manufacturers.
Where other os's admintools shine is where they have limited hardware choice.
- JR
Ideal Solution to Unix Config Trouble(TM)(IMHO!):
If I was a real programmer I would extract it from BIND source and generalize enough to make it eligible for always busy FreeRadius folks - right now they need a new config-parsing engine, nobody wants those old ugly "users" files...
And we need much better config repository than /etc !
The idea of the registry is not so bad after all if we do some virtual file system of it
we have procfs and devfs - why not conffs?
Brain is my second favorite organ.
Enjoy!
-------------------------------------------------
It's life Jim, but not as w
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
So what about HSI (Hierarchical Structured Information I think was the acronym)?
It's hierarchical, can do comments (my implemetation uses # comments), is simple to read, lightweight to parse, and doesn't use redundancy.
The implementation I am working on also supports binary data in various handy notations. You can enter binary bytes into strings using ^ notation, \ notation, or % hexadecimal notation. The corresponding output functions will generate various notations with preference for the ^ then \ (other than octal) then %.
now we need to go OSS in diesel cars