Slashdot Mirror
HelixCode Releases Admin Tools
An Anonymous Coward writes: "Helix Code has just released the first preview of its admin tools. Just now there are only three utils. They are glade front-end using perl back-end." Nifty way to attack the problem. I tend to prefer handling things like this the old fashioned way, but this kinda stuff is critical for the newbies. I mean, who wants to know what file you edit in /etc to change your DNS server, or what the syntax is to mount a remote NFS partition? (Ok, I want to know, but for those just joining us, it's probably not the happiest learning curve figuring this stuff out.)
In good "MVC" manner, things would be quite clearly separated out between "front end" versus "server." (That oversimplifies MVC; so sue me...)
With cfengine, the "back end" is a configuration management engine that does things like renaming files, mounting partitions, running network config utilities, and such. The thing that is nice about it over, say, Perl, is that it directly contains abstractions made for doing "config stuff." It's not a hive of Turing-complete bits of code that could be doing anything; if you want to shut off certain services, you might use:
editfiles: /etc/inetd.conf
{
HashCommentLinesContaining "telnet"
HashCommentLinesContaining "finger"
HashCommentLinesContaining "tftp"
}
Then, when you run the GUIed tool, it doesn't simply run some Perl code that does the system configuration for you, this time; it instead generates a cfengine script, which may assortedly be:
I've used this property of cfengine to help in configuring new systems. If I have cfengine scripts set up that properly configure the local network topology, it's rather slick to drop them on a floppy, put that in the new box, run them, and suddenly have that new box linked up nicely, complete with NFS mounts and security fixes.
It's possible that cfengine isn't the perfect answer; the point is that by providing a "language for system configuration," it is a whopping lot more suited to large scale use for this task than, say, some set of Perl scripts that someone hacked up.
If you're not part of the solution, you're part of the precipitate.
Look at Ethereal - is there an equivalent useful product than can work in a terminal?
Yeah; tethereal.
GUIs make great shortcuts, but they are not the only way to design a useful interface.
--
GUI tools are like any other tool: they can be good or evil, depending on how they work.
/etc/inittab so that if you change it by hand, it quietly undoes your changes and you're left scratching your head wondering what happened and why your changes disappeared on you.
If the GUI tool provides an easy way to do things, provides all the options there in a convienent package, etc., and doesn't break when the underlying config files change because you edited them by hand when the system is in single-user mode, then it is a Good Tool. Example: veritas's vmsa, which among other things lets you create a vxfs filesystem with a few clicks, in exactly the way you want it (a process that takes many more steps when done from the command line).
If the GUI tool makes itself The Only Way This Can Be Done, and prevents editing the underlying config files by hand, or breaks the system, or other Unwanted Things, then it is a Bad Tool. Example: AIX's smit, which is good for many things but takes over
From what I've seen so far, the Helix tools sound like Good Tools, and should be praised appropriately.
---
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
The Advanced Runlevel Manager project has set out to do this. Currently, the idea is to replace rc.d, and broaden the focus to include everything else, like resolv.conf. We'd be happy to get any help, so feel free to join in.
Smit solves these problems. It is a GUI system management tool and it shows you the commands that it ran. After you use it a couple times, you know what it touched, and you can just run the command yourself.
Only Easier The First Time: The GUI looks EXACTLY the same with the exception that the options are all laid out as checkboxes. But the options aren't explained, so no power is really gained here. How does it help to know I have a "password" option for /dev/hda1 if I don't know what that means?
/etc/fstab wouldn't have to change one whit.
It will be easier everytime. All you have to do is go to your control panel, click Filesystems (or whatever) then choose what you want mounted, and here you get the added bonus of seeing all of the options you might want, as simple check boxes. where as when you are vi/emacs/pico/jed/joe/gedit/kedit/....-ing the fstab, you are not sure what options you have, so you go check the man page, flip back to your editor, wonder where to put the options, and with what syntax..etc
It will be piss easy for helix to add in a help file, or context sensitive help popups to tell you what each option will do...remember this is version 0.1.
Less Power: The tool doesn't give you any information how the file is actually laid out and there is no integrated text-processing. So the user does not advance on any path of knowledge where they can become MORE efficient (through the use of scripts, etc).
Who cares how the file is laid out? Why would Joe User give a rats ass how 30 years ago some engineer decided the syntax on the fstab? Or any other config file?
Scripting?!?! Joe User can't even remember their login name and password, much less _any_ command to type into a script file. You don't believe me? Pick at random anyone who has never written a script before, but has used computers for more than 3 years. Spend one week teaching them how to use vi/emacs and write a simple script file. Spend 8 hours per day doing that. Go back to that user 1 month later, and ask him to write the same script file.
Not Forwards Compatible: If a new filesystem came along that had extra options, this tool would have to be re-written to accomodate. Whereas
File systems do not come out very often. When they do come out, they normally spend a long time in alpha/beta. If you are someone who is going to grab the beta of some new file system, and try it out, then you can probably figure out how to add the correct info into your conf files. A short time later Helix -- or anyone else, it Free Software after all -- will make the simple change to add the options to the GUI interface.
All Helix has done here is open up a couple text editors on the files you need to edit to make changes to your system, all in one nice window. They show you what options to have for everything. I don't see how this is a bad thing at all.
The basic sleazeware produced in a drunken fury by a bunch of UCBerkeley grad students was still the core of BIND. --PV
A perfect real world example of why GUI front ends can be real good.
.(Except for those times when it came to reinstalling and I had to hand copy all 100 domains by hand.. *sigh*) Anyways it really is easier to setup so.. why do all you people insist EVERYONE needs to know how to hack a BIND configuration file instead of just learning how the name server works and writing some GUI front end that is like 10 times more functional and time saving??? Huh?
My work needed DNS but my bosses knew of BIND and its configuration files and had lingering doubts about its security just by reputation. (I pointed out it was now secure but the first impression must have been a big one...)
So they looked at the complex DNS configuration files and I showed them examples of how to do certain things and they were like I dont have time to learn that (everyone actually was really busy)
So we ended up using NT for our DNS, because it actually is more simple.. whether you guys believe it or not, I can write out DNS configuration in BIND and setup a name server.
Why did they go with NT, because it was easier to set up and easier to maintain.
I dont want to become a BIND master before it takes me 15 minutes to figure out something and change it, I *need* usability and ease of use, configuring DNS, or FTP why should that be something only a 60K / year UNIX admin can do effeciently?? When a GUI abstracts enough from the underlying system to allow for nearly anyone to do it??
Anyways.. just my two cents
Jeremy
If you think education is expensive, try ignornace
I had this idea several years ago. My take on it is that over time, all programs should move over to a configuration library, something quite simple and based on XML. In the meantime, open(2) could be patched into to create fake files any time you open a config file, and it would generate a 'legacy' file. Yes, slow, but feasible.
The idea would be to store everything in XML, but with the ability to embed LDAP queries, and Perl source, etc. Think about an admin trying to set up a 10,000-node desktop network for pick-a-big-company. They don't want to have to set up this huge system to configure systems remotely via CORBA (though for tuning single machines that's a great idea, given lots and lots and lots of security). They want to be able to create ghost machines that can be installed by your favorite high-school intern support monkey (for the record I was a high-school intern test monkey).
With a proper, and relatively simple, XML DTD that includes LDAP and scripting, you simply generate a default config file with switchouts, for instance at the top of the config file it does a simple LDAP check to see if there's anything odd about the machine. If so, later on down the config file things get more interesting with more queries. Else, it just uses the defaults.
Also, includes and local queries can be done, so if you have things like a standardized network setup (at OGI the router is always x.y.z.54), a proper config file can actually derive things. resolv.conf can include a simple translation that creates the DNS IP from the host's IP (at OGI the dns is always x.y.z.2).
The potential power of a system like this, not just for large installations, but for single systems (specifically, an admin system becomes near child's play) is immense. Unfortunately, every Unix utility/daemon/program/game has its own config file format.
Good luck moving sendmail to an XML config file....
GStreamer - The only way to stream!
assert(expired(knowledge));
What amazes me about these *NIX GUIs is that quite often they try to include so much that they end up being just as complex (if not more complex) than just editing files by hand. I mean, look at the hosts file GUI; it has 100% of everything that would go in a hosts file, but it also has lots of buttons and things surrounding it making it -- in my opinion -- more complex than just editing /etc/hosts by hand.
Don't get me wrong, when a newbie faces creating a hosts file, they'll probably learn quicker with a complex GUI than they would with a simple text editor (I can't figure that out, but it's true). I'll stick with editing files by hand, personally.
If there were either an integrated help system or a larger vision -- providing a single-user, hardened configuration assuming a compatibly configured server infrastructure -- this would be interesting. Trouble is, when the goals are too small/general people just say "edit the files yourself," but when the goals are too big, you ask "how is that different from Windows?"
Maybe the Helix tool won't suddenly grow larger than the size of my X desktop, though. That would be nice.
I can't stand using linuxconf in X on my "server" box, since it has a video card that only allows 800x600 resolution...
As for newbies running DNS servers. Sure they should. They should run local DNS servers that only listen to loopback, and use their upstream providers as forwarders. Not only does this give you faster name resolution, it cuts down on net traffic.
----------------------------
This is a good step for Linux.
Companies like Helix, Chilliware and MountLinux are trying to put a pleasant face on some arcane tools.
Nothing wrong with that...nothing at all.
A cool article recently on LinuxGram talks about that, note the title of it...this is what we need, more companies doing apps, especially if we ever want to throw Linux on our parents/grandparents/kids machines.
"Don't try to confuse the issue with half truths and gorilla dust."
Bill McNeal (Phil Hartman)
I had a quick look at the screen shot for the import/export tool. Helix has struck a balance between providing a usable interface and not concealing too many details.
All the information a power users needs to map from the GUI to what happens 'under the hood' is present, and yet a newbie could use that same tool to connect to whatever network resources he/she desires without difficulty.
--
"Where, where is the town? Now, it's nothing but flowers!"
Right, and god forbid that "clueless people" should be able to manage the free OS they install when seeking an alternative to Windows.
Nobody is saying that, please don't inspire a flame war - we have too many already.
Why is having a GUI front-end to your configuration files such a horrible thing?
A GUI configuration utility, in and of itself, is not a bad thing. The problem arises when you MUST use the GUI to configure your system. I'll use Linuxconf as an example. It does lots of non-standard things. Heck, it even starts up every time my computer does. I have to use Linuxconf in order to avoid breaking my system. What happens when the only thing I can do is get into a shell, without any graphics capabilities at all(not even text-mode, curses-based!)? Well, quite frankly, I'm screwed. Helix seems to have the right idea - their utilities are changing configuration files themselves, and only those that the service being configured reads. That way I can use a plain text editor to fix my system if I have to.
They aren't "dumbing" anything down. They're making it easier for newbies to do things that normally require navigating confusing tools or editing conf files by hand.
I firmly believe that computer users need to know more about the computer they're using. Education is never a bad thing, and the best education is hands-on education. In this case, reading manuals and editing config files.
For someone that's only looking to connect a simple box to the net so they can do their email and web-browsing, why should it be a bewildering chore to configure an IP the first time around?
You're right, it shouldn't be a chore. But sometimes configuration GUIs make it too easy to kill your computer. I know several people who have lost a lot of money(> $5000) on mis-configured computers. Users should at least know what not to do, and having that horrible, confusing "Reformat your hard-drive - don't worry, this won't do anything bad!" option is a bad thing. You wouldn't cut the brake lines in your car, would you? Sure, you're not likely to die if you kill your computer, but you could lose a lot of money, and suffer a distinct rise in blood pressure.
That said, I'd like to congratulate Helix on doing a good job on their utilities. They've got the right idea - modify configuration files that are native to the service that's using them. I'm a fan of all the work Helix has done, and I hope they continue it. Good work.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Exactly. New users need a way to get into a system without having to memorize 15 O'reily books. I know my way around a computer and spent several weeks installing a BSD System a few years back on a 486. After I got it up and running, I went back to my Macs and PCs.
Early last year, I installed a Red Hat system...it was a world of difference from having to compile everything from scratch and hoping ya had drivers for every piece of hardware ya had (didn't have CD Drivers for my drive at that point...). I was up and running in an hour. For about 6 months I used Linux Config for just about everything. Its easy enough to use even in straight telnetable text.
If it wasn't for Linux Config, I wouldn't have been running the system and I would have given up on it and gone back to the NT network I administer. Now, I can't even use Linix config because it kills most of the changes I've made to the sendmail config files and otherwise.
Users need a way to get use to a system first and then figure out all the geeky things that we all love. The more GUI based admin tools the better (and let hope these new ones don't kill config files just because they don't understand what yer working on...)
blah
clif
What really irks me about editing text configuration files is that they can have a steep learning curve where you have to read quite a few pieces of documentation. Take the filesystem mounting tool. I have a good idea of how the configuration file is arranged but don't know every option by heart. If I want to use a feature I never used before, I have to read the man page again on what order to enter the parameters, what valid values there are, etc. And heaven forbid you make a typo, add an extra space, etc and can't reboot the system anymore. A good gui based configuration tool presents the much easier to use interface which can list all valid values and parameters and prevent you from making a gross blunder. Take an example from real life... I was setting up NFS exports on a Linux machine and ended up putting a space between a hostname and its permission in /etc/exports. This totally changed the meaning of the NFS export and made it read only instead of read/write. I spent a week troubleshooting what was wrong. Sure I learned a bit or two from this experience but I also lost a lot of time for more productive things.
I can see both sides here. When I was just starting out many moons ago, I could have used a tool to make editing config files and managing the system easier. It would have saved me a lot of time and agony. Today, I can run a system just fine, but it can be a pain having to remember all the details. Easy-to-use GUI config tools definitely have a place, since not everybody can or necessarily should be hand-tweaking everything - opening up the system to misconfigurations. Not in a world filled with script kiddies, in particular.
.conf file - not now, not ever. Who are we to say that's wrong? But more importantly, we need to start issuing distributions that are optimized for single-user use. Why load wu-ftpd if it's not needed by a user? Make it easy for the user to add services as they master the system, but disable them by default in the interest of security and flattening the learning curve. That'll help user acceptance a lot. Nice admin tools like HelixCode's will help, too.
If Linux is going to penetrate the mainstream of computing, we need these tools - Joe User doesn't want to know about editing a
In the power/ease future, I'm really looking forward to MacOS X. It'll offer me a lot that the MacOS doesn't. On the other hand, I'm terrified of what happens when the typical Mac user meets the waves of script kiddies out there with what will be essentially an unsecured BSD system. Ouch.
- -Josh Turiel
-- Josh Turiel
"2. Do not eat iPod Shuffle."
As a relative new comer to Linux I think it very helpful to have GUI front-end for the more hard to understand tasks. It makes the OS more friendly to long time users from other OS (What? No control panel? I am outa here.)
However I run into problem once I feel comfortable with the system and to want to know more. For example I have always use the GUI to add new user/group to the system, and now I want to do it by myself. But how? The GUI program certainly didn't tell me what it is actually doing when I hit that "add user" button.
I think developers should provide detailed helps for their GUI front-end programs, for those who are willing to learn. eg "This program is a front end for X which modify Y so that you can do Z".
There is no reason why GUI can only "dumb down" something, it can be an excellent way for people to learn too.
-= AC: Anti-Cookies =-
there are tools that make it easier to work with the system. but you should know what is going on, unless you want to classify your machine as the equivalent of a toaster. In which case it better be disposable, along with your data.
There are also tools that would not make things easier. I, for one, would not look forward to Edlin for Windows 2000! (or Edlin for Linux either!)
"It is a greater offense to steal men's labor, than their clothes"
Isn't Linux/Unix/GNU all about Choice. Sure you may not want to play with files to tweak your systems and it is your choice to use GUI front-ends. No one should be forced or looked down upon because of what they prefer to use. Some people will never feel confortable in CLI's and it is their preference. They should be shot down by the Unix Militants who are anti-newbie extremist. Sure maybe it would be nice if they did open up the hood and explored their system a little but not everyone is up for that. The people from Helix code and KDE are giving these people the choice (grep this comment for the world choice hehehe) and I believe that it is a smart move. No one should have to accept windows if they want another alternative. I started out on Red Hat and I am still kind of a newbie ::gasp:: but I do use vi...etc to hand config my system when I feel the need to. We should not condone people for their preferences and because what they want to use is not what you would use. Let people figure out for themselves what they want to use. No one is stuck in KDE/GNOME the shell is there and always will be.
::RANT MODE OFF::
-"The Good Humor Man can only be pushed so far"
-The good humor man can be pushed only so far
Ok, as only partially-initiated, I must ask, in spite of the simplicity of the philosophy of Unix, why oh why are there so many damn interdependencies in applications? Example: I install RedHat (yeah, shut up, it was the only thing that would install over DHCP on this old ThinkPad, after trying FreeBSD, Slackware, NetBSD, and TurboLinux), and choose the most minimal of configurations, and also choosing some small tools like cvs, etc. Well all of a sudden it is prompting me for all sorts of other dependent packages. I could not believe it when it told me I needed the entirety of KDE, and *then* also GNOME to satisfy dependencies! That is bullshit. Tk, Tcl, Python, Perl, Expect (!)...how the hell many things do I need to install? Am I the only one who thinks that backending GUI or administrative applications by Perl is just a god-awful abuse?
Sure this is just one experience, but I've found the same general thing when installing other distributions. Is this just a commercial flaw? Or do other "non-commercial" distributions like Slackware and Debian not require this? I just boggle at the horrendous amount of crap that even the most trivial of applications is dependent upon.
Ok, I'm putting on my asbestos trousers...
It's 10 PM. Do you know if you're un-American?
Look ^^^ up ^^^ a few comments to #73.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
Just glancing over these tools reminded me of something that I've heard is being done for MacOS X that I bet would be a good (albeit large) project for the OSS community to undertake.
:)
Basically for OS X it sounds like all their configuration stuff is done using XML conf files. I'm betting that they're not really making all NEW UNIX conf files, but are adding a layer of XML above stuff (ie, your resolv.conf file is generated off of an XML file)
I think a project whose job would be to take many modern day UNIX configuration files (/etc/*) and translate them into XML formatted files would be quite useful. The logical progression of such a project would be to allow a "univeral" configure tool which would interpret the XML files to create an on screen configuration tool for whatever conf files are needed. This would eliminate the need for specific tools hardcoded for certain files (like the one seen on the Helix code site for configuring your nic's) and would become essential to setting up a Linux box for newbies.
Just a hunch
--
I think there is your problem. Newbies shouldn't HAVE to mess with that stuff. Someone new to Linux definitely shouldn't be running a DNS server or an FTP server! These are the kinds of people that stick their boxes up unprotected on the net and wonder why they get hacked, then blame it on Linux! Newbies (we were all a newbie at one time) generally don't bother keeping stuff upgraded until they become more advanced and that poses a very big security risk. Newbies to Linux should probably start off with something akin to a simple WebTV interface that handles all the hard details and doesn't make them worry about handling any of that administrative mumbo-jumbo. They just need to know to turn on their box and start their apps. When (and if) they want to advance and learn more they can get to a shell and start working with that.
While there's plenty of other front-ends for configuration things, it's always a plus to have them integrated into the desktop environment. Having a consistent GUI design to relate to is not just something newbies appreciate!
It's also cool to see how GNOME and KDE borrows from each other. Not code, but ideas, like the new KDE panel or the splash screen for KDE2. Of course GNOME borrows a lot from KDE as well. This is competition not to succeed commercially, but to get the happiest users -- competition the way it *should* be!
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
I happen to use a browser based administration tool called Webmin (www.webmin.com) which is written in Perl/CGI and thus it happens to run of a great many platforms. It certainly doesn't do every possible configuration task but it does make lot of the common tasks easy. It is also very modular and you can customize it to the small portion that interests you. You can also delegate certain capabilities to other users.
Part of this really is missing fundamentals
While learning fundamentals is good, is there really anything fundamental about hand tweaking configuration files? I don't think so.
It's too easy to confuse matters of fundamental importance with matters that are merely pointlessly difficult - sort of like the old adage: if the medicine isn't bitter, it can't be good for you.
Linuxconf and other tools like Webmin already do a good job of simplifiying linux configuration. Why bother starting over from scratch when we already have good tools to start from? In my opinion Web based administation is defenately the way to go since you can provide a universal tool that will work in X, at the console(via lynx), and remotely that is easy and faminiliar to new users.
You point is well-taken. I have a concern, though. Can the GUI tool abstract ALL of the settings in those config files? If not, we've got a potential problem in the making.
This is similar to what happens when using a code-generation tool. It works up to a point, and then I go and hand-craft some enhancements in the generated source. Unfortunately, since the generator didn't do it, and it's not in ITS files, it won't be in the code the next time I use the generator to regenerate that source.
Replace "generator" with "GUI-front end". Either the GUI tool has to know ALL the possibilities of ALL the various flavors of the config files, or it'll run into a case where it's going to cream hand-corrected settings. Which would happen in a heartbeat when the "newbie" asks a "nerd" to help him tweak his system, and the "nerd" is unaware of the helpful.
The long and the short of it is that the GUI tool presents a "language" that is an abstraction/simplification of the desired config files. It gets interpreted/compiled into the "native" language of the config files. You need a complete forward and backward translation or you're going to lose something in the translation.
With all due respect, I think that's exactly what's being implied in the original post. But you're right, it's not worth the flames. On to the real discussion.
Thank you. =)
Using Linuxconf as an example of GUI config helpers is, quite frankly, just plain wrong. You're right, it does non-standard things, it locks you in and it's basically a very poor way of doing things. That doesn't invalidate all GUI config tools, just Linuxconf. =)
You're missing the point. Not everybody is an academic. You and I may feel the need to understand how every tool works and how it is configured. I, personally, like to tweak every single tool on my system. I'm just anal that way. But that's just me. And I'm quite convinced that I, and others like me, are becoming the minority in the computer using world.
A computer is a tool to most people. You should not, EVER, be forced to learn how the computer works in order to accomplish what it is you want to do.
Should you know what an IP address is? Yes. Should you be concerned with how your OS interprets configuration files to determine its IP address? Hell no.
Keep in mind, I'm not talking about sysadmins here - sysadmins are professionals who should understand the systems in their care - I'm talking about Joan Q. Public who just wants to use her computer for simple, everyday tasks.
Come on now, have you EVER seen an option that says "here, go ahead, format your HD, it'll be fine"? That's ridiculous. With that kind of logic, we should outlaw root access and any kind of CLI. It is far, FAR easier to really mess up your system with a CLI.
A slip of the pinky there is much less forgiving than a GUI config tool that only allows you to do a specific task and clearly spells out the dangers associated with it.
The problem you're describing is poor software design, not uninformed users. Well, maybe a mix of both. I say the onus should be on the developer to make sure the consequences of every click are clear to the user - not on the user to anticipate what the software wants you to do.
--
one step at a time, my anonymous friend.
These tools are to help everyone using GNOME. It is up to your ISP to write installation scripts for you in order to have what you desire. Each ISP, and internal network will have different settings for DNS, NFS (if at all), dhcp, et al. so it would be impossible for Helix to write software to solve that problem.
Not to mention that these sort of things are only going to have to be editted once for everytime you switch networks, so it isn't that hard anyway.
The basic sleazeware produced in a drunken fury by a bunch of UCBerkeley grad students was still the core of BIND. --PV
SMIT for AIX has this functionality. If it runs a command you can see the exact command line, with all the options in place. If it runs a script you can see the contents of the script. SMIT does not appear to rely on any internal, hard coded programming, for every configuration activity it runs an external command or script.
Since I have only done a little AIX admin work I could be somewhat wrong, if so please correct me.
-- Remember: Wherever you go, there you are!
I hope it has the capability to, upon making changes, show you exactly what it did. What files were changed, what was added or removed, and a quick little explanation of each change.
What better way to learn the fundamentals of system configuration?
--
When I was a teenager, I too would scoff at the clueless newbies running their MSDOS and Windows 3.x. Then I actually grew up and realized that the vast majority of the population DOESN'T need to know every detail of the operating system they are using. If you think they do, or think the average user SHOULD know what's going on 'under the hood' take off your geek blinders. Suggesting such is about akin to suggesting everyone who flies in a plane should know advanced aerodynamics, or anyone who drives a car should be able to rebuild the engine.
If Linux doesn't start getting a lot more support for 'clueness newbies' ala Helix Code's apps, you can forget about it ever becoming a serious mainstream desktop OS. Even with this support, its rather a big question whether it will all be too late.
I, for one, love the ability to use a good gui to config a system. I am jumping between Linux, Irix and Solaris and I sometime have a mental lapse as to where things are... like... um... what config file has the services in it? ;)
Not all of them are that easy.
I use linuxconf to do a quick config of my system.
NIS info changed? Click, click... type type... restart... all better
I know what I want done. I know the theory behind it. I don't want to have to wory about a little file.
Also... mentioning NIS and DNS and all of that... it is so hard remembering about SGI's new all in one daemon. Going between that and Linux daily is enough to drive a person crazy...
I HUP'ED the ypbind... why is it not taking it...
Oh... yeah... that other daemon... nsd... yeah... HUP that mug.
-I just work here... how am I supposed to know?
Ok time for another of my rants on the false sense of elitism among unix fiddlers and how that is totally unrelated to real competence in engineering or anything else.
Folks, the details of networking protocols and config files are of little interest to anyone except the type of person who enjoys picking up grains of sand with tweezers. Frankly, these things are BORING especially to really talented programmers. Some familiarity with these things is taken for granted with anyone who has used unix for very long and who has had some administrative experience, which includes most home users, eventually, as well as sysadmins who fiddle with configs for a living. But an extensive knowledge of such trivia is a heavy penalty to pay for the priviledge of using unix and having to administer it.
We have autoconfigs in the development process for a reason. Fiddling with the mechanics of makefiles is BORING and although some understanding of what is going on helps, one does not have the time to delve into these things at length when doing development work. One must focus on the project at hand. The same applies to using a computer generally, which necessarily involves sysadmin ESPECIALLY for home users, because they do not have a specialist on hand to do it for them like users of corporate networks. They have better things to do than to fiddle with config files. Knowledge of these things has NOTHING whatsoever to do with intellectual capacity or creativity.
What IS interesting is the many creative things one can do with a computer which includes programming and all kinds of development but also many other applications for non-technical folks who use computers - artists, musicians, writers, etc. Not to mention business apps.
Computer science has little to do with making a living in sysadmin or knowledge of all the little arcane details of sysadmin passed on in stupid rites of initiation among the boys club that unix sysadmin characterizes like nothing else in the universe. Reading the manual is not good enough. Many things, if not most of the key things, one needs to know CANNOT be learned by reading manuals because the whole purpose of unix sysadmin is to insure job security for those in the field. The obfuscation is intentional. Why, for example, do man pages have no examples? It's by design.
Nevertheless sysadmin is necessary, and really creative sysadmin is a GOOD THING. But it is not sysadmin as we know it today. What is really creative sysadmin? Trying to find and implement coherent, well-organized systems for adminstering systems. Unix currently doesn't have that. What it does have is hundreds of config files scattered from here to kingdom come and essential utilities with widely varying syntax and paramaters. This is not a good thing. Unix has excellent systems, but not systems for administering them. In the place of these systems, what we have is the arcanery of sysadmin work - a self-serving and self-perpertrating profession which retards progress in technology to justify itself.
Thank God for the efforts of Helix to help remedy this situation. There have been similar efforts in the past, but nobody has got it right yet. Let's give Helix a chance here.
Helix rulez.
PCXL Forever!!!!
Why is having a GUI front-end to your configuration files such a horrible thing? They aren't "dumbing" anything down. They're making it easier for newbies to do things that normally require navigating confusing tools or editing conf files by hand. For someone that's only looking to connect a simple box to the net so they can do their email and web-browsing, why should it be a bewildering chore to configure an IP the first time around?
Not everybody likes to get their hands dirty working with the innards of their OS. A lot of the computing public is genuinely frightened of changing anything on their computer.
I say kudos to anyone that wants to make it that much easier to install and keep a Linux/BSD/nix box running.
--
The outrage at this sidesteps you into the traps of wanting more people in the community, but at the same time playing a game of hide and seek with the goal posts. Ultimately, I do not see that game as being terribly practical.
I prefer to push people to be more competent, more expert, and to use the knowledge they have. This is more of a coaching style where you are gentle on the person, but death on the missing skill sets. Personally, I prefer some sort of learning curve vs the infamous learning cliffs, especially if you can get hurt when you fall off.
Part of this really is missing fundamentals. All those things that you know due to your expertise and experience. Someone whose knowledge of computers is limited to the most recent MS horrors might have to spread a day or two learning the basics for, and the reason why, of this thing called a command line. This is really worth doing, and doing well. but now it is skipped over as not very relevant, when instead it is merely vital.
I'll avoid the Mac comments on this for the time being .... :P
"It is a greater offense to steal men's labor, than their clothes"
First off, this isn't a distro, it's just a packaged version of GNOME, and second my guess is one of their goals is to get RedHat to pick it up as their default UI and start getting cash from them for their work. I mean, come on, has RH *ever* put those finishing touches that really make the configurability of X stand out?
First we had TWM, then FVWM95 and lately Enlightement with GNOME 1.0 -- all of them with unusable defaults..
HelixCode is doing a damn fine job and I say we let them continue to work on usability and not declare them an unnecessary addition to the community just yet..
Look at Ethereal - is there an equivalent useful product than can work in a terminal?
Is this necessarily true? I mean, with good programming, the GUI could be smart enough to recognize changes it hasn't made itself and then ask for input on how to proceed (ie, should I incorporate these changes into my own record?)
That's the key, with good programming and maintenance, it doesn't have to be a nuisance to the casual tinkerer.
--
So how good are these new tools at this?
A learning curve is good, for people that would actually fix their computers if something serious goes wrong. For grandma or grandpa that just wants to send e-mail and surf the 'net, "dumbing down" is defintely called for. They might need to change a few settings (following instructions provided by their ISP for instance), and they'll be much more comfortable if they can use a GUI to do it and be told to "Click on the ___ button," instead of "Add the line XYZ to file /etc/ABC and then find and edit the line LMN to read MNO." Linux really can be an OS for everyone, if we can just make it simple for people to manage the settings that they want and NEED to in order to maintain their system. Personally, I'd like for my grandparents to have a Linux PC to do e-mail and surf. Stability is important, and we all know that Linux is much more stable than Windows could ever dream of being. If we can overcome the learning curve for those that don't care about how things actually work, we can increase the user base. However, it is important that things aren't set up so that a GUI is required to do the config. Those of us that know what is going on need to be able to get in and fix things if the GUI won't load, etc., so we need access to the config files, but only if you want to do things that way.
"You will only be remembered for two things: the problems you solve or the ones you create." Mike Murdock
BEGIN PERENNIAL GUI FLAMEWAR /etc/smb.conf, etc)? Answer: It is only easier to use to someone who has never seen it before but it is less powerful AND not forwards compatible.
/dev/hda1 if I don't know what that means?
/etc/fstab wouldn't have to change one whit.
Take the "mount manager" tool. How is this tool different than a text-editor with some shortcuts to the applicable files (/etc/fstab,
Only Easier The First Time: The GUI looks EXACTLY the same with the exception that the options are all laid out as checkboxes. But the options aren't explained, so no power is really gained here. How does it help to know I have a "password" option for
Less Power: The tool doesn't give you any information how the file is actually laid out and there is no integrated text-processing. So the user does not advance on any path of knowledge where they can become MORE efficient (through the use of scripts, etc).
Not Forwards Compatible: If a new filesystem came along that had extra options, this tool would have to be re-written to accomodate. Whereas
I am not saying GUIs are bad. I am saying that porting a text environment to GUI is not helpful and may be the reverse. Porting another GUI to Linux isn't even all that great.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)