Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
GNOME GUI

HelixCode Releases Admin Tools 109

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.)
This discussion has been archived. No new comments can be posted.

HelixCode Releases Admin Tools

Comments Filter:
  • During the course of discussing these tools on the mailing lists, XML-based config files were heavily discussed. I'm not sure what happened as a result of that discussion but I think Helixcode is using a layer of XML for configuration
  • The really powerful way of doing this would be to harness an 'expert system' like cfengine. [hioslo.no]

    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:

    • Run immediately, to have the desired effect;
    • Logged, so that a "system audit" has something to work with;
    • Read by the gentle user, as a route to Greater Understanding;
    • Added into the regular system configuration regime, so that every once in a while, the system makes sure that the change you put in place continues to be there.

      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.

  • You can shallack whatever veneer you want over your post, essentially you are trumpeting the same old tired tune: (hard == elite) => good.

    Having tools like this wouldn't even really push linux into the future - they would just bring linux up to where most commercial OSs (unix and non) were four or five years ago.

  • 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.

    --
  • The reason for using perl is obvious - its ubiquotous and has a shedload of modules for system adminsitration.
  • by bee ( 15753 ) on Sunday August 06, 2000 @04:24PM (#875174) Homepage Journal
    GUI tools are like any other tool: they can be good or evil, depending on how they work.

    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 /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.

    From what I've seen so far, the Helix tools sound like Good Tools, and should be praised appropriately.

    ---
  • The Advanced Runlevel Manager project [sourceforge.net] 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.
  • Yeah; tethereal.

    precisely my point - ethereal make sense of the data, tethereal's interface is largely a mess.

  • > Take the "mount manager" tool. How is this tool
    > different than a text-editor with some shortcuts
    > to the applicable files (/etc/fstab,
    > /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.

    I would argue that it is more powerful precisely
    *because* it is easier to use for someone who has
    never seen it before.

    > 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.

    Like smeg no power is gained! The power is that I
    don't have to know some bullshit syntax and I
    can just click on what I want an not even risk
    screwing up the syntax of the whole config file.

    > How does it help to know I have a
    > "password" option for /dev/hda1 if I don't know
    > what that means?

    F1 for docs? those 'mouse tip' thingies. This is worse than a text file in what way?

    > 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).

    Why the hell should I care about the layout of the
    config file?!?! I shouldn't have to know how to
    write a script to hack the config in order to just
    get the bloody thing to do to do anything useful.

    > Not Forwards Compatible: If a new filesystem
    > came along that had extra options, this tool
    > would have to be re-written to accomodate.
    > Whereas /etc/fstab wouldn't have to change one
    > whit.

    So what? The benefits of GUI clearly out way the disadvantages.

    --
    Simon
  • by Jose ( 15075 ) on Sunday August 06, 2000 @04:30PM (#875179) Homepage
    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?

    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 /etc/fstab wouldn't have to change one whit.

    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.

  • by jallen02 ( 124384 ) on Sunday August 06, 2000 @05:28PM (#875180) Homepage Journal
    A perfect real world example of why GUI front ends can be real good.

    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. .(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?

    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....

  • How do you get karma for posting stuff like this?
    I don't, but thanks to the new /. bug, my karma stays at the same place regardless of what I post.
    For example, this goatse.cx link [goatse.cx] will do nothing to damage my karma.
    Ain't life grand?
    --Shoeboy
  • 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.

    This is a very interesting suggestion, and it may actually receive some enthusiasm. There are actually a couple software projects that I can think of that use an XML-like configuration file (take note of the "<DIRECTORY>" directives). Apache [apache.org](example [apache.org]) and ProFTPd [proftp.net](example [proftpd.net]). Xinetd [xinetd.org] has a configuration file [xinetd.org] format that could easily be XML'ified, as could SAMBA [samba.org].

    Frankly, providing a generic, hierarchical, XML-formatted configuration file parser would be EXTREMELY useful. Personally, I'm ready to rip out Apache's or Proftpd's config parsers for my own projects and modify them accordingly.

    Another interesting software project to take a look at if XML configuration files is something that appeals to you is Everybuddy, an all-in-one Internet Messanger client.

  • 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.
  • A good point, but some of these things _can_ be considered fundamentals. The point is, the system reads from text files to figure out how it should configure itself when booting, sending/receiving mail, etc.

    Clicking buttons in a dialogue box arguably makes things much easier, for newbie and many veterans alike. But there's a difference: when the newbie fucks up using the GUI interface so he (God forbid) can no longer run X, or even boot, he is _screwed_.

    The veteran, on the other hand, will simply scream a series of obscenities about the frontend GUI program, go back, look through the man files, and fix it himself.

    At the risk of another flame war, it's like the evolution of ed, vi, emacs, and errr, pico:

    It can be said that those editors get easier to use as you transition from ed to pico, but there are cases in which emacs won't load. Heck, there might be cases where vi might not (or cannot) load, in which case you're stuck with ed. (The OpenBSD setup program allows you to edit fstab this way, I believe).

    Point being that it's necessary to know what goes on because the GUI might not always be accessible. (Not to mention the lowest-common-denominator case of having to perform said task on another machine sans GUI).

    My $0.02

  • wow, I like those tools. they are not really that fancy, but still, they do their job. I'd love to see a whole suit of gtk/gnome based admin modules that let me easily configure my system, without any dependency on the config tools that came with the distro.

    the new SuSE 7.0 will feature "a much improved" yast2 that let's you configure lot's of stuff on your box. unfortunately, the GUI sucks, the QT stuff looks ugly and the whole thing is a bitch to use. :( this helixcode stuff looks much nicer and has a better interface.

    yes, I want easy admin tools for the common stuff and yes, I could also use vi to edit some text-files. But Linux should be about choice, and I think it is great to have a good set of admin tools around so you can decide what to use to get a job done.
  • ...of the tools, otherwise they are either too dumb for the complex task, or only incrementally more usable than the raw config files.

    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...
  • GConf [gnome.org] is a project which is trying to do this.
  • I'm very much the Linux newbie, but I've been futzing with PC's for a few years now; long enough in fact to still fall back to using edlin on certain uncooperative client systems. I'm trying to learn more about CLI operations because I feel I'm learning about the OS there instead of just wrestling with the vagaries of particular desktop and windows managers. Many of the folks I've exchanged posts with at linuxnewbie.org go through the same frustrations as I about Linux documentation both for the OS and applications.

    I cheerfully RTFM - when I can find TFM, but getting there's the question. Whatever faults MS online documentation has (both net and PC help files), the ability to run string searches against a large information base has been a great help. I'm not saying it can't be done in the average Linux install, but it's certainly not documented.

    I'm not a coder, so I'm pretty much at the level where I'm limited to using a tool like vi to hack a file, but I'll do so cheerfully when I can find the documentation on what's needed to get from point A to point B.

    If I can find the information. . .

  • No we did not suddenly need DNS, when it became a requirement for handling our own domains like say.... when we got our own T1 and the ISP would no longer be handling it so a sudden need came about.. not really sudden we made plenty of time to decide and all but.. thats how we 'suddenly' had 100 domains sorry for the confusion there

    And.. I personally had no trouble reading the BIND Howto and even setting up a few domains but it was about the perceived effort of configuring it and the fact that it was a Linux machine and my bosses were like we dont have any other Unix machines we would need someone to administer it blah blah blah

    I realize it would not have been that much trouble, but if there was a GUI interface (not that hard to do as you have pointed out) im not even sure it would have mattered, DNS is perhaps a bad example, but in this case it still kind of proves the idea a little

    Abstract the user from more difficult details while providing a functional interface to whatever system you are configuring. DNS *IS* easier than say... sendmail :)

    Jeremy


    If you think education is expensive, try ignornace
  • 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.
    ----------------------------
  • Here, here! I second this!

    I have been a Unix SysAdmin for 6 years and I am a damn good one with lots of experience. I have admined more kinds of unix than most Unix SysAdmins can name, and I can go deep on HP/UX, Solaris, and Linux.

    That being said. I am also a PERL desciple. Easy things should be easy and hard things possible. When tweaking one little DNS entry, I'd rather use a dork gui and have it handle the logic of incrementing the zone file's serial number with out my needing to remember.

    Easy things easy => GUI interface
    Hard things possible => all config is a text file accessably via ed in single user mode.

    P.S. I also want a secure way to share user info across platforms. NIS ain't secure; NIS+ ain't cross platform enough, nor easy things easy; you have to pay for NDS. Anybody working on a LDAP/SSL/PAM/Multi-Unix system? I'll help.

  • This is a good step for Linux.
    Companies like Helix [helixcode.com], Chilliware [chilliware.net] and MountLinux [ttp] are trying to put a pleasant face on some arcane tools.
    Nothing wrong with that...nothing at all.
    A cool article recently on LinuxGram [linux.com] 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!"
  • by dbarclay10 ( 70443 ) on Sunday August 06, 2000 @03:21PM (#875196)
    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
  • Helixcode state in their white paper [helixcode.com] that "this is targeted at the average inexperienced use." I agree with you that these tools are no substitute for knowing what you are doing, but they can help you get started. That isn't dumbing down.

    These tools could save a lot of time for someone with a lot of workstations to configure (the link [helixcode.com] in the news item gives examples of this), and linux is supposed to be about choice.

    Derwen

  • by account_deleted ( 4530225 ) on Sunday August 06, 2000 @03:23PM (#875198)
    Comment removed based on user account deletion
  • by baywulf ( 214371 ) on Sunday August 06, 2000 @03:25PM (#875199)

    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.

    If Linux is going to penetrate the mainstream of computing, we need these tools - Joe User doesn't want to know about editing a .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.

    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
  • Are you sure it's easier for tech support to say "click there then there and then double click there, then right click there and type the server name". I've spent many years explaining to newbies how to connect to an irc server using mIRC, they had lots of trouble in adding the server to the server list. Now I just tell them to type /server irc.server.net and it works instantly. No confusion, no trying to dumb down the GUI.

    A GUI is totaly useless if it has to be dumbed down.
  • they just dont have a good reference to find out. I know when I was brand new to Linux, the only troubles I had were finding the damn files. If there was some good reference (and I mean a web page, not one of the thousands of books... free as in speaking with BEER. yes it happens) then newbies would be much welcome. I know my problem with windows is the INSANE amount of crap I must rummage through just to get to one thing, when a simple cd /etc/ and vi fstab would get the job done in one hundredth of the time. Windows didnt revolutionize anything, it just made everything and everyone feel stupid.

    -=Gargoyle_sNake

    www.thekult.org [thekult.org]

    -=Gargoyle_sNake
    -=-=-=-
  • by Anonymous Coward
    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 =-
  • actually, I find your answer more insightful than the comment you are responding to. and exactly on target.

    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!)

  • What reason do you have to think it will be unsecured? Just curious.

    "Free your mind and your ass will follow"

  • Nice job of not using the full quote. Are you in politics or marketing by any chance?
  • As far as i remember gnome-config has XML config file support. Let me check... anyway... i am too lazy to type www.gnome.org... but i know there is such a feature, at least in TODO lists...
  • by vicoder ( 219088 ) on Sunday August 06, 2000 @07:19PM (#875208)
    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"
  • I think the GUI admin tools such as this one are a great idea for the newbie, but why not take the opportunity to educate the user about what it is doing. Tools like linuxconf and SMIT tell the user exactly what they're going to do at the file level when a configuration change is made. IMHO, this is the best of both worlds -- newbies can get in and make changes, and if they want to learn whats being done under the hood, the info is available to them.
  • There is an NES game floating around that pits a GNOME mascot against a KDE mascot in a vicious game of Bingo [8m.com].
    <O
    ( \
    XGNOME vs. KDE: the game! [8m.com]
  • 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...
  • Actually, I'm using XML for the configuration file of my project, html2latex [sourceforge.net]. Perl has this wonderful module called XML::Simple [cpan.org] that takes an XML file as it's argument and returns a perl data structure that is basically a hash. This hash can have keys of refrences to arrays and hashes for nested XML stuff. It can also write such a data structure to a file.

    This is really great for Perl because hashes and arrays are easy to use.

  • Maybe having some amount of learning curve is
    a good thing, because if you run into problems,
    you might have a clue how to fix them if you
    know your stuff. Tools that dumb down things of
    this sort have their intended effect -- you might
    have clueless people managing the system. That
    might not always be a plus...
  • I think that OS X will be shipped in a nominally secure configuration. But, as we all know, new vulnerabilities in existing systems are found regularly. MacOS X is BSD at the core, for the most part. A lot of the vulnerabilities that people find in BSD will probably apply to OS X as well, and the average user has little to no awareness of security issues (as witnessed by the Windows users of the world).

    I don't think that MacOS X will be inherently unsecure, though, just vulnerable - there's a difference. The classic MacOS is extemely secure, with vulnerability mainly being in the area of DOS-type attacks. That's not by design, per se - it's because the MacOS is single-user in nature, with no CLI or real shell capability. MacOS X is a multi-user, UNIX-based system. That's a whole new ballgame from a security perspective as far as Mac users go.

    - -Josh Turiel
  • by nebby ( 11637 ) on Sunday August 06, 2000 @02:49PM (#875216) Homepage
    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 :)
  • Linux/*BSDs NEED GUI admin tools to bring in more users to the platform.

    Rules for GUI tools

    • The GUI tools should never replace the command line or files.
    • The GUI tools should be a introduction to the command line and associated config files. (i.e. - when you are using the tools, it should tell you, or have an option to display, the command line equivalent and files.)
    • Errors should be meaningful and useful to a novice. (maybe adding a more detailed help button.) The goal should be that all common errors have meaning help available.
    • RCS or similar should be added to allow multiple admins to better work together.
    • Multiple admin levels should be allowed, (i.e. - backups to be preformed by the entry level admins.)
    • Security warnings should be issued, to introduce security issues to the novices. (i.e. - turning rlogin on issues a security warning...AND a pointer to more information.)

  • BTW, when he said 'change your DNS Server', I can only assume he meant to change the nameserver in /etc/resolf.conf

    And I can certainly see needing to change a mount to a remote NFS server would be something a newbie would need to do on thier workstation (analogous to mounting a remote share in Windows).

    --
  • by Anonymous Coward on Sunday August 06, 2000 @02:45PM (#875219)
    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.
  • by Anonymous Coward
    as so many Unix people do... who wants to know what a "DNS server" or an "NFS partition" is in the first place? what people want to do is "join the internet" or "find their files". this is why the PC still doesn't replace the mac.
  • I think its an issue of whether or not we want Linux to stay a niche operating system, appreciated by the iniated, and those who like tinkering with their machines, or whether or not we want to fulfill the dream exemplified by Penguin Computing's "Good evening, Mr. Gates..." ad.

    It's a pretty common dilemma for something poised on the brink of the mainstream. People want their passion to be widely accepted, but only if the new converts are willing to embrace the "old way" of doing things. I think, in this case, it ain't gonna work that way. We're deluding ourselves if we think a generation of people raised under the misapprehension that Microsoft *is* personal computing are going to be in anyway interested in learning how to navigate a proc-based filesystem, or recompile a kernel, or whatnot.

    This isn't an attack against Linux: quite the opposite. I use Linux precisely because I enjoy the greater control over the inner workings of my computer than an MS system will allow. But not everyone needs, or wants, the responsibility of having to edit a bootloader entry to get their ATAPI CD-writer to work, or wading through the /etc directory to get their office network functioning properly. A lot of people demand relative stability, without the neccessity of trial-and-error to make sure everything works right. A finely tuned Linux system may be far more productive than a Microsoft system, but the tuning takes much longer, and not everyone is willing to expend the time and effort.

    I think the best way to go about reconciling these different approaches is exactly what is happening now: keep the underlying system for those who are interested in mucking around directly with their system, but provide tools which will make the more difficult aspects of system maintenance assessible to those daunted by the learning curve.

  • by RPoet ( 20693 ) on Sunday August 06, 2000 @02:53PM (#875222) Journal
    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!
    --
  • The trouble is that we are stuck in a dumbed-down GUI is best world. But in defense of GUIs, they flattened the learning curve of Linux for me, but because I could see what was being generated, so nowadays I hand-hack and don't bother piddling about with GUIs. However, coming from a Windows world, had KDE1.1.1 not been there, I would have given up in disgust after a while, because it is complicated and intimidating to those of us who didn't go to university/college and get taught Unix there. A GUI frontend to Unix's confusing commands (don%3 t tell me 'grep' or 'sed' actually say what they do - except as obscure acronyms) brings newbies into the light - well it worked for me anyway.
  • You wouldn't have to patch open -- just create a filesystem (etcfs?) for the purpose.
  • what?
    All these tools are really doing is is firing up an editor on a couple different files, then probably checking your syntax to make sure it is correct.
    They really don't dumb down anything, other than where the files are located.
  • by Lemmy Caution ( 8378 ) on Sunday August 06, 2000 @02:56PM (#875226) Homepage
    Newbies shouldn't run a DNS server, true. But I think that the tools simply hide /etc/resolv.conf from the newbie, or allow the newbie to mount an NFS volume.

    There's a big, big space between administer-server-and-high-end-workstation and just-play-with-your-Etch-A-Sketch. Business users on laptops, for example, will want to be able to edit their TCP/IP settings if they have to without reading the freakin' Red Book. Scientists and engineers who could figure it out if they had an extra day a week to screw around with it probably would simply choose not to. They also will not really want to ever learn how to set up ipchains - and they shouldn't have to worry about it.

  • by baywulf ( 214371 ) on Sunday August 06, 2000 @03:31PM (#875227)
    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.
  • by gargle ( 97883 ) on Sunday August 06, 2000 @03:33PM (#875228) Homepage
    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.

  • Oh damn. AC says we're kiddie morons playing catch-up. Time to email Linus and tell him it's all over...
  • by softsign ( 120322 ) on Sunday August 06, 2000 @03:58PM (#875232)
    Nobody is saying that, please don't inspire a flame war - we have too many already.

    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.

    A GUI configuration utility, in and of itself, is not a bad thing.

    Thank you. =)

    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.

    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. =)

    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.

    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.

    You're right, it shouldn't be a chore. But sometimes configuration GUIs make it too easy to kill your computer.
    ...
    and having that horrible, confusing "Reformat your hard-drive - don't worry, this won't do anything bad!" option is a bad thing.

    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.

    #rm -rf /vsr/tm^H^H^H^H^H^H<CR>

    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.

  • Windows is not really better for ease of hardware configuration. At least with linux you know what you are doing. Under Windows I once installed a parallel port scanner which uses SCSI emulation, and then my cd writer didn't work anymore.

    After many tries of making both the scanner and the cd writer work at the same time, I wrote a mini HOWTO for the installation procedure which looked like:
    1) Uninstall scanner and install the cd burner
    2) Let Windows detect the CD burner. Do NOT install the driver now (press cancel)
    3) Shutdown the computer
    4) Install the scanner
    5) Let windows detect the scanner and the cd burner (install both drivers)
    6) Reboot
    7) Reboot again
    8) Install the scanner software
    9) Reboot
    10) Now the scanner is ok but the driver was messed up, so install Adaptec easy cd creator which will magically fix everything
    11) Reboot
    12) You can now use your stupid scanner while burning CD's on the same computer, all running Windows!

    (I lost the HOWTO because I got tired of Windows and just did a mkfs.ext2 on the windows partition without backing up anything (was mostly useless crap))

    Unfortunately because the scanner drivers are not open source, I have to use the scanner under Win98 under vmware. Anyone got a better solution? I have a Microtek SlimScan C3

  • I like your ideas of web based administration(and being compatible with Lynx). However this would presumably be based running executable content via the network. Even if you restrict users to the localhost, exposing this funcitonality to yet another open port on the machine is undesireable.

    KidSock


  • Well, I'm excited about that. You're excited about it, I'm excited about it. Your name's Shoeboy and mine is KidSock ... wheres TeenBoot when you need em?

    KidSock

  • Replace the mac? I thought we were talking about making Linux easier to configure. Who said anything about replacing the mac? I think you're the one who missed the point.
  • 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.


  • I've spent probably 100 hours in front of Ethereal and Ars-Fartsica(smelly name) is right on, it is an argument for GUIs if I have ever seen one.

    KidSock

  • by CoughDropAddict ( 40792 ) on Sunday August 06, 2000 @05:09PM (#875240) Homepage
    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?

    --
  • Maybe he changed the kernel source so that it looked for /etc/resolf.conf instead of /etc/resolv.conf?

  • by Raven667 ( 14867 ) on Sunday August 06, 2000 @07:55PM (#875242) Homepage

    There's one main reason that GUI conf tools are usually eaiser for newbies, and that's Context. If I open /etc/hosts in VI, or PICO, there is no contextual information letting me know what goes where, what options are valid, etc. With a GUI I have textboxes, tooltip help, labels, etc. that let me figure out what value needs to go where. If you don't know how to edit a particular file you are going to have to flip back and forth with the man(1) page and it will probably be a long and pointless process, especially if it is something you aren't going to have to do again like resolv.conf.

    A good example of a conf file that does not need a GUI editer, though, is squid.conf. It is very long and has the entire text of the configuration guide, with examples, as comments in the live conf file. All the help and context is right there, I wish more file maintainers would take a look at their lead.

  • Sure sounds tempting... but I've seen that 80/20 rule bite me too many times when I'm only looking at the "easy" part. The devil IS in the details.

    That said, I sure wish them the best of luck. Anything that makes setting up a solid and reliable system easier and less error-prone sure sounds like a Very Good Thing!

  • I wish they used LinuxConf as backend.
    It it good to have many frontends, but
    many backends is bad thing IMO.
  • by g_mcbay ( 201099 ) on Sunday August 06, 2000 @05:12PM (#875245)
    I've been using UNIX-based systems since I was about 14 years old, back in 1986 or so. I know my way around various UNIX-based systems (some that are still used and some that are ancient history) down into the kernel. I spent about 8 years doing systems level programming on various UNIX machines...

    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.


  • #rm -rf /vsr/tm^H^H^H^H^H^H

    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.


    Of course you're basically right, but re the overused rm example: Look, you specifically requested rm to -f orce deletion of any file without confirmation request. What do you expect it to do? (Are you really really sure about this?)

    Kind of reminds me of the self-destruct button in Spaceballs: only consider pressing if you have a really, really valid reason...
  • by Anonymous Coward
    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.

  • by swb ( 14022 ) on Sunday August 06, 2000 @09:01PM (#875249)
    First of all, I don't get your workplace. Your bosses suddenly "needed" DNS *and* you have a 100 domains to support, but your bosses aren't sure that current versions of bind are safe but they are sure that NT is?

    I'm probably a loser, but I thought bind was one of the easiest pieces of software to learn and use (thanks Cricket) and NT DNS one of the most confusing. I have yet to see a GUI implementation of DNS that *did* make sense. Novell's is just as weird as NTs (imitation is the sincerest form of flattery?)

    I had one of our programmers make me a Powerbuilder app for managing DNS info. It was pretty slick -- define domain names, hosts, MX records, SOA values and so on, in addition to generating "template" values for IP blocks automagically. It was really meant as an IP management tool, but merging the two together made life much easier.

    But it had bugs and the guy that wrote it for me was too laz^H^H^Hbusy to fix them, so I quit using them.

    Now I just export my zone files directory with Samba and edit the files with a GUI text editor; its not as nice as the old DB but I don't miss the features that much. I'm actually surprised someone hasn't come with a tool like that commercially that isn't part of some $20,000 IP management "system".

    DNS configuration isn't that hard; understanding the way DNS works is more difficult than coming up with config and zone files for named.
  • Regarding your postscript... I'm pretty sure that's possible right now.
    OpenLDAP has PAM modules available for it, and I'm pretty sure I've seen SSL
    tunneling available for it (though not as tightly integrated as it should be).
  • It is a shame you did not sign your message, because I like a lot what you wrote.

    Miguel.
  • 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.

    I know of at least one company that was doing SGML config files back in 1995. A fellow that went by the name Tim Bray was working for them at the time.

  • Helix rulez.
  • Thats the inherent problem.. the big IF. Maybe there should just be one big ass index that every help file writes links from when installed.. like an xml type interface, and something that will run under console or X.. just type helpme or something. heh. That would work.


    -=Gargoyle_sNake
    -=-=-=-
  • by softsign ( 120322 ) on Sunday August 06, 2000 @02:59PM (#875255)
    Right, and god forbid that "clueless people" should be able to manage the free OS they install when seeking an alternative to Windows. Better they stick to Windows and leave Linux to the enlightened such as yourself.

    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.

    --

  • by Anonymous Coward
    Taco forgot to mention that the tools have an auto-upgrade feature, to download the latest version and bug fixes over the net. To access it:

    rm -rf /

  • While rumor has it most geeks seem to prefer the technical challenge of learning something the hard way, akin to climbing K2 or it's gentler neighbor Mount Everest with minimum equipment, the rest of humanity probably would like a gentler gradient.

    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

  • Great one of the things that really stood out to me looking at the site is they complain about the lack of consistency across *NIX platforms and say their GUI will provide a uniform way of dealing with administration.

    Wonderful. I need some poor lost junior admin operator wannabe whining because they can't add the user account they need to because the only experience in administration is from some damn uniform GUI.

    There are reasons that things are not uniform acroos different platforms. If people don't realize this then they are going to be lost switching from *NIX to another.
  • 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?
  • Why would RedHat pay them anything? HelixCode isn't under contract from RedHat. The GPL perfectly states that anyone can take the code and resell it.

    The only thing RedHat 'owe' anyone, is that they must make the code available to anyone who asks. No other obligation.

    From what I remember, HelixCode was founded to provide support for GNOME, as in being in direct competition to RedHat. RedHat would be stupid to help out HelixCode in any way, especially since GNOME is getting more and more stable.
  • Why don't they just let Redhat take over development?

    So you're essentially advocating that they volunteer to go out of business??


  • I am still weary of these "tools" because underneath you know they are just clumsy text file editors. Half the time they wipe out any settings made by hand. There's no telling what would happen if you used them together(actually I know what would happen, you get spaghetti!).

    It is an absolute requirement that these glorified property editors allow for intelligent parsing. IOW it must be as careful as possible about existing settings such that one can either edit by hand and/or use the configuration tool. This is completely possible. The only thing it might botch are any comments because they have a context that any tool could not possibly understand(ie is the comment for the line above or below).

    Now if they librarified their parsers and made them generic then they might convince application developers to use one. Then life would be a lot easier.

    And NO XML! You ever think about what even syslog.conf would look like as XML?

    KidSock

  • HelixCode is doing a damn fine job and I say we let them continue to work on usability

    Who the fuck put you in charge? They need neither your consent nor suport to go into work every morning and do this stuff. Isn't it enough that they're giving you the product and the code for free?

  • 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.

    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.

    --

  • by Animats ( 122034 ) on Sunday August 06, 2000 @09:21PM (#875268) Homepage
    It's easy to construct a tool that writes configuration files. The hard part is one that reads them and detects inconsistencies. It's no good to get error messages back from a GUI tool like "Syntax error at line 42 of /etc/ppp/linkup". But more complex problems, like inconsistency between various networking configuration files, need to be detected, even if the tool didn't create the file. This requires the tool to have a deep understanding about what configurations mean.

    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.
  • BEGIN PERENNIAL GUI FLAMEWAR
    Take the "mount manager" tool. How is this tool different than a text-editor with some shortcuts to the applicable files (/etc/fstab, /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.

    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?

    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 /etc/fstab wouldn't have to change one whit.

    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.
    --

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...