Simple Comprehensive Config Tools? 358
"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."
SuSE? Corel? (Score:1)
And isn't that something Corel must have put into their distribution?
KDE 2.0 (Score:2)
I guess for what you want there are at least two. (Score:2)
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.
graphical admin tool (Score:1)
You want good software don't you? (Score:2)
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.
Corel is based upon Debian silly. (Score:2)
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.
Re:graphical admin tool (Score:1)
This sounds good, do you have a name for the product so we'll know what to look for??
If you can't figure out how to mail me, don't.
Monitor (Score:1)
Re:stop whining and start coding!! (Score:1)
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.
What about... (Score:1)
Not all of windows is idiot proof. (Score:2)
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.
How about a collection of applets? (Score:2)
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 (Score:3)
http://www.webmin.com
Re:Not all of windows is idiot proof. (Score:2)
I'm not saying to make it "idiot-proof". I like linux precisely because it gives me such fine control over the OS. I"m just saying that there's no reason not to give the idiots the tools to stay away from that kinda control if they don't want it. Maybe like two layers - one idiot-proof, but you can drop into the more detailed version if you want it...
I see nothing wrong with making it appealing to the "idiots". We don't have to sacrifice anything but our elitism.
If you can't figure out how to mail me, don't.
As long as regular configuration files still work (Score:2)
RedHat skirts around this issue, a little. The regular
Re:You want good software don't you? (Score:1)
Yes and look at their market share as compared to Windows. It's paltry. True, they have lots of commercially viable SERVER software, but the average end user isn't interested in that. They'll be content to let someone else do that, I could almost hear the shouts of glee when I set up an IRC server for a friend. But when it comes to end-user software, I stand by my statement.
And I don't particularly like babysitting idiots either, but at the same time I don't like the elitism that a lot of the Linux community shows when faced with this problem. Give them what they want. Give us what we want. Everyone's happy and the world benefits.
If you can't figure out how to mail me, don't.
Re:graphical admin tool (Score:2)
here's a few more teasers on the software: its 100% modular, can admin more than one machine at once, and works w/Linux now and will be ported (which is trivial) to *BSD, AIX, Solaris, etc... the front end will also be ported to windows...
if you are interested in finding out more or getting involved in the development of what is the next generation in Linux/Unix config/admin tools, drop me a line at aseigo@mountlinux.com
Re:Webmin (Score:2)
I've used webmin. It works but I found it very lacking in a lot of respects. It's not easily configurable and it's not under the GPL, you're not permitted to redistribute your changes.
I gave it to the support staff where I used to work... they didn't like it and I came to realize it was a mistake.
If you can't figure out how to mail me, don't.
You can still use ed/vi/or cat >conffile.ext too. (Score:2)
Re:Why bother wasting time? (Score:2)
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.
Tools or Docs? (Score:4)
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
Re:stop whining and start coding!! (Score:1)
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.
Re:As long as regular configuration files still wo (Score:2)
please, please be careful! (Score:3)
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!
How much do we want it? (Score:4)
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?lack of GUI a plus (Score:1)
IMHO, I like the lack of GUI config tools, and, with the exception of kernel config, I hardly ever use them.
Re:KDE 2.0 (Score:1)
Re:How about a collection of applets? (Score:1)
our software will be out (GPL'd of course!) first week of march... company: Mount Linux... software is currently code named olympus (because we developers can't come up with a better one at the moment.. too busy having fun coding the damn thing)
GUI Tools versus config files (Score:3)
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).
Re:You want good software don't you? (Score:1)
I have no commercial interest whatsoever in Linux, and seeing the latest hype with the RedHat and VALinux IPO has done nothing but sicken me, seeing how we spend more time making things 'pretty' instead of fixing them, just so that some company can then go out there and make a wad of cash selling shares when they really never turned in any profit, nor actually have a 'real' product.
I do not agree with windows users moving to Linux, because the learning curve is HUGE. I do not agree with people devoting a large amount of time making things as simple as 'point-and-click' because it takes away the need for a clue on the user's side.
Look at the amount of packet kiddies out there, and the number of 'hackers' popping up allover the place simply because distributions like redhat make it easy for a clueless person to put a server online on their cable modem which will then become a happy spam relay box, a smurf amplifier, a shellbox for kidz, etc etc.
Now tell me... is it really worth it ?
Re:As long as regular configuration files still wo (Score:1)
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.
Re:You want good software don't you? (Score:2)
itachi, former phone monkey who knows the difference between lusers and clients...
Re:You want good software don't you? (Score:2)
Well, you know, I'm an idiot too, before I've had my first cup of coffee and any time I'm not paying close attention
When creating these new tools let's never forget that they're not just for newbies - they're going to be used by professionals as well, so let's design them according.
Simpler installation open doors, but (Score:2)
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.
Config tool should not require X (Score:1)
Re:Why bother wasting time? (Score:2)
Methinks we very nearly have a convert
Take another look at linuxconf (Score:2)
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!
Hiding complexity doesn't mean that it disapears (Score:1)
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
Hiding complexity doesn't mean that it disapears (Score:2)
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
Re:How much do we want it? (Score:1)
graphical config tools (Score:5)
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.
Not Geek enough for Linux? (Score:5)
- 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.
--
Re:Simple brings the stupid (Score:3)
Re:Hiding complexity doesn't mean that it disapear (Score:2)
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,
cfengine, anyone? (Score:5)
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.
Yes! (Score:2)
I guess that's what you said. But I completely agree.
----
standard GUI wrapper (Score:2)
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.
Check out "gecco" (Score:3)
----
Re:please, please be careful! (Score:3)
GUIs are good. Humans primarily rely on visual information, not a buncha #s and
Stop the madness! 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? not only it will help admins, it will make the creation of a GUI layer on top, much, much easier. As things are now, every utility needs a parser to make sense out of its config file...
Better stop ranting now... I am going back to my POS 98 laptop, fondly remembering the days when a reliable, pretty, configurable Unix still existed: it was called NeXTStep
engineers never lie; we just approximate the truth.
Re:graphical config tools (Score:4)
engineers never lie; we just approximate the truth.
Open-source Community and the Desktop PC (Score:3)
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.
Mandrake 7.0 (Score:2)
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.
My take. (Score:3)
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.
Re:KDE 2.0 (Score:2)
I definitely think that Linux could only benefit from something like that. I have had (and still do have, on occasion) similar troubles. It isn't using the config files that is the problem, it is finding them. It only makes sense to provide some method of centrilization for configuration. Coincidental cohesion.
Re:How much do we want it? (Score:2)
If you look at it this way, Windows has the same problem the Unices, but it has a way around it. (The difference is that Unix started with the problem, and MS retrofitted it in. :)
Documentation, as you imply, is important. Unix documentation, although not centrally organized, is all over the place; OTOH, there are many things about MS products you don't learn unless you take their courses or buy their resource kits. (Or someone who has shows you.)
If I were Bill or Steve, I would trade the dollars for the knowledgeable user base. No, wait. On second thought, if I were either of those two guys, I'd quit my job tomorrow, buy a bunch of secluded land, and build a palatial high-tech hermitage. Hey, wait....
phil
linuxconf does this (Score:3)
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.
Re:Config tool should not require X (Score:4)
You can have your cake and eat it too. The existence of easy to use graphical tools does not necessarily mean that text-based tools are going out the window (no pun intended).
Face it, some things are just a nightmare in linux. For example, making it so that you can have decent good-looking fonts in X requires a brilliantly written 20+ page how-to. Things just HAVE TO get better than this. Very few people have the time to read dozens of pages of information to change each little aspect of their computing experience.
Graphical front-ends are a good idea, epecially for administrative tasks that are done once per installation or that are changed infrequently or on machines that are administered by someone that is not a professional administrator. It is very hard to remember the details of commands like mount, for example. The man page is very long and complex for this command and it creates a feeling of dread in someone that just wants to get some work done.
Easy to use vs. easy to learn (Score:2)
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
The whole area needs a rethink (Score:4)
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.
DEVFS! (Score:2)
--
Deepak Saxena
The demon of backwards compatability; more (Score:3)
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.
Re:The demon of backwards compatability; more (Score:3)
My $0.002: forget
As for the format; yeah, it will be tough to iron out, but so was POSIX. I ain't that level of hacker, but I do think that XML should be able to handle everything that a program would need. After all, XML is more of a syntax than a language, right? The added benefits:
As I said before, a GUI layer on top will be almost trivial, and expandable to no end.
There could be a standard configuration-reading library, that any utils developer can use to parse his or her config file, saving that stupid work... (I've always hated writing parsers, don't you? ;-)
engineers never lie; we just approximate the truth.
Re:Webmin (Score:2)
Of course, it's pretty easy to just make a cgi or php application to do similar administration.
Besides webmin, I also have almost everything on my system automated. From splitting logfiles and creating reports, to easy additions to config files, to little crontabbed scripts that ensure a daemon is working, to *cough* automated logging of user commands upon executing commands or connecting to ports they shouldn't be, to adding new ip's to an interface as well as the rc, to simple changes to the adduser script to meet my requirements for new users...
These are things anyone can do with a bit of practice.
Re:Why bother wasting time? (Score:3)
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.
Once I found /etc/inittab... (Score:3)
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.
Config tools. (Score:2)
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
---
Re:Hiding complexity doesn't mean that it disapear (Score:2)
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 [hotnutz.com]
Not really... (Score:2)
----
Anything but XML! (Score:3)
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.
Re:i have to agree...somewhat (Score:2)
Re:The whole area needs a rethink (Score:2)
I don't like that last part: a single way. What I would prefer to see is this db exported to something akin to /proc - a virtual filesystem containing textual representations of the db contents, and editable with a text editor or a GUI tool. The text editor would use the standard read/write interface; the GUI tool could do that, or there could be, as in AIX, some standard API for accessing and modifying the configuration that it would use directly.
The centralized repository for system configuration is a good idea, but only if its implementation doesn't force the use of a single tool. Can we do this better? Certainly not me - I'm too busy hacking Linux audio+MIDI apps.
Re:Anything but XML! (Score:2)
E.g.: Apache's
We can do XML-based config files now, with existing tools, without departing too much from the "Unix way". I think it's time we should. Think about it: before Bill Joy, unix admins probably thought one line of text at a time was all _they_ needed
engineers never lie; we just approximate the truth.
Tangential but related (Score:2)
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 [io.com] 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
In the Meantime... (Score:2)
It seems we are missing the point here. (Score:2)
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
One of the things I'd like to see.... (Score:2)
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!!!
Mutually Exclusive? (Score:2)
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.
Re:Why live in the past? (Score:2)
dufke
-
Re:The whole area needs a rethink (Score:2)
This works very well because it's infinitely extendable. You just add text files in whatever format seems appropriate for the application. There would be no benefit whatsoever in making this more complicated than it is. To use a virtual file system like
I'm sick and tired of hearing this same tired argument. Unix doesn't need a registry.
Individual hand-edited ASCII config files do what we need and they are robust and independent; a more tightly-bound repository kept in memory and managed by a large program would expose the configuration data to programming screwups like the Windows registry suffers from.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Linuxconf should be like AIX SMIT (Score:2)
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.
Re:How about a collection of applets? (Score:2)
Re:Tools or Docs? (Score:2)
I disagree. I think that is a great solution for you or me. I like good technical documentation. Unfortunately that's not a good solution for the average user. I want to see Linux grow, and that means attracting the average user. Take my girlfriend for example: she loathes computers and no matter how hard I try, I make little headway. She doesn't understand very much about computers and so the Microsoft setup solutions work quite well for her. They generally try and configure the machine for the lowest common denominator (which is probably one reason why we find them so frustrating). They judiciously use wizards with very simple questions and instructions. The last thing that she wants is to wade through pages of documentation that goes in to detail that she doesn't care about.
Re:How much do we want it? (Score:2)
But under UNIX I can add it to my MANPATH and use man -k. Etc. There is no way under Windows for searching all of the help on the machine.
Re:The demon of backwards compatability; more (Score:2)
So you tweak the logic of your config options, the template file would reflect the change.
Essentially what you'd have, I guess, is a programming language for the configuration system.
But i do also agree that linuxconf is running full-steam in the wrong direction, and needs to be completely re-thought. In many instances it does things in entirely the wrong way. See the samba module for insight.
Re:Anything but XML! (Score:3)
Re:How much do we want it? (Score:2)
Re:graphical config tools (Score:3)
I dunno. Isn't hiding operations rather the point of a "user-friendly" tool? One of the reasons that the Macintosh was heralded by the computer press was that it hides the underlying details from the user.
This is a timeless debate that has gone on forever, but really the hiding of the nuts and bolts is really what has one in the hearts and minds of the users. This is why Micros~1 Windoze is so popular.
Remember that many Windows users, especially newbies, are confused even by the presence of multiple windows. In my line of work, when a modal dialog box would pop up (one that doesn't let you do anything until you dismiss it), users would instantly get confused (why can't I click this?), or even just other instances of multiple windows (when I click this pulldown menu, this other window that was on top goes away, why?)
Having complicated details on the screen confuse most casual users. They'll be completely intimated by it. Even the stupid "Device Manager" in Windows 9x confuses many clueless users. Forget that, even the CONTROL PANEL confuses them.
I know what you'll say next: well, casual users shouldn't use admin tools. But even seemingly simple things like installing or configuring a printer are really system administration tasks. Mounting network shares, adding devices, installing software, etc. are all system administration tasks that casual users often find doing for themselves, despite having adequate IT staffing. And technical details are intimidating and confusing to these users. They just want to point and click and get their work done. They don't care about technical details and don't want to know what is going on under the hood.
Just my $0.02
Re:please, please be careful! (Score:2)
Let's get the tools right this time (Score:2)
Re:Anything but XML! (Score:2)
Then you really should study it more closely.
Yes, indeed, XML is an extraordinarily complex syntax for writing what are essentially SEXPRs; however, it's a single, common, generic, internationally and openly agreed syntax, for writing files which are both human readable and machine parseable.
If you are going to start again from scratch and define new syntax for UN*X configuration files, and you choose to use anything other than XML, you really are going to need to have a very good reason for doing so.
And remember, if you really find XML syntax so ugly, it's trivial to convert XML SEXPR syntax into LISP SEXPR syntax and back again.
Re:The demon of backwards compatability; more (Score:2)
But as someone else suggested in this thread,
With careful engineering and everybody pulling together (which, with the added benefits of a standard format to users and developers alike won't be too hard, IMHO), we could have a clean, standardized system in 2-3 years easily...
engineers never lie; we just approximate the truth.
Re:Anything but XML! (Score:3)
I really think UNIX should evolve to XML. Plain text encourages Yet Another Configuration Format. GUI tools would also benefit from the XML format. Dragging and dropping tags from one file to another.
The arguments for editing everything by hand usually stem from shoddy tools. Quite frankly, the common text editors seem to be the few stable applications used with GNU/Linux. I have tried LinuxConf but it's interface is terrible and its stability is lacking. I much prefer editing by hand compared to using LinuxConf.
I think it would be far nicer for the newbie to double click on resolve.conf.xml and get an XML editor window allowing the user to change the DNS numbers just by double-clicking on the entry. I don't think it would be wise to put all the configurations in One Be-All Tool. Keep the config files where they are but just put the files in a friendlier format -- XML. Have a nice SysEdit application that lists all the configuration files on the system and a short description of them -- the user double clicks on the file they want to edit and the XML editor comes up with that file ready to edit by double clicking. This is both user-friendly and The Unix Way.
Unix is a very old OS. It needs to evolve towards modern interfaces and file formats. The best way to do things then isn't necessarily the best way to do things now.
You're right (Score:2)
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.)
Re:The demon of backwards compatability; more (Score:2)
Great idea. I would love to use a system that implemented this.
Re:graphical config tools (Score:2)
I love SMIT. When I have more free time (in a year or two
I wouldn't mind writing one up, but I only know the configuration formats of some tools. Not all, so this would definitly be a group effort!
Steven Rostedt
Re:XML is a poor choice (Score:2)
The more important thing here, is that: a) the community (not necessarily us, this thread, or
engineers never lie; we just approximate the truth.
Re:The whole area needs a rethink (Score:2)
I rest my case.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
Tenets of the Unix Philosophy (Score:2)
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 [camalott.com]):
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
Re:graphical config tools (Score:2)
You seem to be contradicting yourself. The first part of your sentence states that computers are "extremely complex tools," and then you say that people should "learn the little bit it takes to operate [one]".
Which is it? Are they complicated or do they take "a little bit" to learn?
I don't think you know what you're talking about.
Re:The whole area needs a rethink (Score:2)