Plans from Red Hat [LWN.net]

Several articles were published this week looking at Red Hat's plans. The Register starts off with this article about the recently announced end-of-life schedule. (See Red Hat's errata policy announcement). We understand the need to set an end-of-life to products, but announcing a December 31, 2003 end-of-life for 8.0 seems a bit extreme. After all, 8.1 isn't even due out until April.

Next, Linux Journal takes a look at Red Hat's plans for a corporate desktop. The idea here is to get people familiar with Red Hat desktop at work. Then in a year or two they'll be ready to trade in their Windows systems for a Red Hat desktop at home. This seems like a good strategy. If the corporate sales are good, Red Hat should gain some users this way.

Finally, vnunet looks at Phoebe and a new Samba configuration tool included with Phoebe. Phoebe is, of course the beta version of 8.1. "Without the new tool, most system administrators would configure Samba by editing text files on each system running the Samba software. Many administrators prefer this method of configuration because it makes it straightforward to back up and redistribute server configurations simply by copying one text file. However, other administrators who are used to working with Windows may be put off by the text-based interface." As long as 'vi filename' still works....

(Log in to post comments)

RedHat's Beta is Phoebe, not Phobe.

Posted Jan 30, 2003 3:54 UTC (Thu) by corbet (editor, #1) [Link]

Gee...we used to know how to spell that...I'm not sure what happened, but it's fixed now.

Plans from Red Hat

Posted Jan 30, 2003 4:20 UTC (Thu) by npj (guest, #4267) [Link]

Kudos to Red Hat for publishing a list of end-of-life dates; For systems administrators, knowing in advance when the security updates for a distro are going to stop is extremely useful information. To the best of my knowledge other distros like Mandrake and Debian don't do this, and IMHO it would be helpful if they did.

Having said that, one year is definitely too short; That's enough time to deploy a server system, slowly become satisfied that it's going to work OK (and document/fix/workaround whatever errors/bugs/foibles exist). At that point the ideal is to be able to leave it and only update as and when security issues dictate; Under the Red Hat timeline though, you have to upgrade to the latest and greatest to still get updates, just when the old setup had proved its stability.

Of course supporting older versions cost money and there has to be a limit to how long something (especially a cheap/free something) is supported for. One year just simply isn't long enough though to make deploying a production server running Red Hat's standard distro a sensible proposition for the person who has to test/update/maintain it, so it seems pragmatic to look elsewhere when selecting distro for this kind of configuration. (Of course Red Hat's advanced server is supported for longer, but it's significantly more expensive at US$799.00 to US$2499.00 per year, according to their web site.)

Plans from Red Hat

Posted Jan 30, 2003 10:38 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Yes, 1 year sounds short. But we at least usually update within the series (7.1 --> 7.2 --> 7.3) well before that. As long as the changes aren't too large... and x.0 on a server isn't in my plans, at least.

Samba Config Tool not needed

Posted Jan 31, 2003 23:33 UTC (Fri) by taro (guest, #6163) [Link]

By now badly OT, but i can't use swat as it wipes comment from the files: -- outrageous.
Tom

GUI config editors and "cooked" comments, txt file paths

Posted Feb 2, 2003 4:17 UTC (Sun) by Duncan (guest, #6647) [Link]

Mandrake here, and I don't use SAMBA, but the last time I used DiskDrake, with
it's pretty interface, to layout and mkfs a new partition, and allowed it to write the
changes to fstab, the next time I booted, I had a bunch of new dirs mounted in
root with names like /the, /default /value /is, because it hashed all the comments
and spit them out as mount-points when it saved the file.

Now, I use the GUI to create the partition and mkfs it, but don't allow it to write
the changes to fstab, which I update manually, keeping my comments intact. I
also keep a backup version of this and some of my other basic config files
around, in case they get "cooked" somehow.

Thus, I definitely sympathize with having comments "cooked"! GUI configurators
need to learn how to leave comments as is, AND leave the current layout as is,
so the comments stay with what they are commenting about. Any mods should
be done in place, and new settings should normally be appended without
changing existing format. (Perhaps DiskDrake does that now, I haven't tried it
lately, and don't intend to.)

..

I'm with the guy who suggested that GUI configurators list the files they actually
modify, as well. There's nothing like knowing it's in a text config file somewhere,
and not being able to find it. As I've gotten more familar with Linux, and my
favorite windowing environment (KDE) and tools, I'm usually able to figure it out
without to much trouble, but it DEFINITELY would have been helpful to have this
info a few months into switching to Linux, when I'd progressed past learning what
was there, to attempting to mold the environment to my liking.

--
Duncan

Text config files

Posted Jan 30, 2003 12:21 UTC (Thu) by rknop (guest, #66) [Link]

One of the problems with the spread of GUIs for config programs (including web based interfaces) is the lack of documentation as to what the text based config files *are*.

I think it important that Linux config files always allow you to edit the text by hand; eliminate that and you eliminate one of the big potential benefits of Linux, and one of the reasons a knowledgeable Linux admin can keep track of so many more sysstems than a knowledgeable Windows admin. I also see that, yes, it can help to have the GUI; that's especially good for people new to the program, but it's inherently limiting. If the GUI aces out the ability to reasonably use the text base config file, that's a problem. Even on the user level, the complexity of the Gnome configuration directories, and the poor documentation of how you'd edit the config without the GUI, disturbs me.

Even when you use the GUI, or even if you *have to* use the GUI, I'd like it if programs would include documentation as to which text files get modified-- i.e. which text files you have to back up so that if you reinstall or want to clone the configuration elsewhere, you know which files to copy. (That way you don't have to run the GUI everywhere.) That documentation often isn't there; I certainly haven't found it for GConf yet. (GConf occasionally gives me huge headaches, I have to admit, e.g. when I try to log into the same account with an NSF shared home directory on two machines at once.) I do like the CUPS web based GUI, but don't want to run it on every machine that's going to share printers, and don't want to have to rerun it every time I reinstall the OS. Which files do I need to back up? There I'm pretty sure I've figured out it. I'm less sure for MailMan (where the system admin documentation is limited to telling you which scripts you can run).

Text-based anything (be it config scripts, or mail clients, or whatever) may be "archaic and old", but for those who know what they're doing, they can be far more efficient than a easy-to-learn GUI. (I had a colleague, in response to my claim that I preferred things like mutt and pine, incredulously say that text-based mail clients were terribly archaic in this day and age of graphical mail clients. It was extremely ironic, because as he was saying that, he was waiting for his Netscape 6 to *slowly* display over a long-distance ssh-tunnelled X connection, so that he could read his mail back at his home system. Of course, a text-based client would have been *much* more responsive in that situation. I guess if you think text based clients are "too archaic" even when you're looking at the one situation where the advantage of the text based client is most glaringly obvious, you're beyond any possibility of appreciating them.)

-Rob

Designing configuration tools

Posted Jan 30, 2003 14:08 UTC (Thu) by brugolsky (subscriber, #28) [Link]

I am disappointed by the redhat-config-* tools. While I appreciate a clean GUI interface that minimizes what I need to remember, the new Red Hat tools are a step backwards from previous attempts (linuxconf, etc.).

A configuration tool should have:

- a clean separation between the GUI/TUI/cmdline frontend and the backend configurator.

- a well-defined command structure for the backend.

- a precise, command-oriented log that can be transformed into input to a cmdline tool with at most light editing.

- a mechanism for making persistent changes "by hand" -- i.e. misc config changes that are perhaps not modelled by the configurator, but won't be undone the next reconfiguration. ["By hand" doesn't necessarily mean vi.]

Previous systems on Linux (such as Linuxconf) and other systems (e.g., AIX's smit) incorporate most of these concepts.

Since the tools are written in Python, perhaps they will evolve in that direction; packaging Python "cmd" objects is relatively straightforward.

redhat-conf-* tools

Posted Jan 30, 2003 16:50 UTC (Thu) by scripter (subscriber, #2654) [Link]

Actually, I find them a step in the right direction. I like the tools. They feel good to me. And they are easy to find because they all start with "redhat".

With previous distributions, it was "printconf", "netconf", etc. I could never remember what all the different configuration tools were. Now, bash completion takes care of it for me.

Go back to linuxconf & webmin!

Posted Feb 5, 2003 16:05 UTC (Wed) by mwilck (guest, #1966) [Link]

You are absolutely right. Mandrake makes the same mistake. Instead of grabbing a well-working, well-designed package like linuxconf or webmin and integrating it smoothly into their distribution, they design their own configuration tools that are usually slick for standard administration tasks but fail miserably when it comes to real system administration.

linuxconf and webmin are particularly good at cooperating with text-file editing.

Weirdly, RedHat used to be linuxconf-based but deliberately moved away from that in favor of their home-made tools.

SuSE's YaST is more capable, but it's not free, and it comes nowhere close to webmin/linuxconf.

What the Linux world needs most desperately is a standardized set of well-designed, interoperable configuration tools that can coexist with old-style text file editing and graphics tools at the same time.

IMO, all that'd be needed is a "wizard" style frontend for linuxconf that
allows the user to perform easy configuration steps easily. Both linuxconf and webmin tend to scare apprentice users with tons of complex options.

Go back to linuxconf & webmin!

Posted Feb 5, 2003 16:10 UTC (Wed) by mwilck (guest, #1966) [Link]

> You are absolutely right.

Oops: I meant brugolsky was right, not scripter.

It is normal that users/admins "like" such simple tools initially, but learn to hate them (and ask themselves how to disable them) when more complex tasks need to be perfomed. I quit using SuSE years ago exactly because I was tired of YaST/SuSEconfig overwriting my manual settings. A good configuration suite needs to be able to configure something up to the tinyest detail, and yet make simple things easy to set up.

(That said: I didn't test RedHat's samba tool yet. I am just assuming it feels like the other RedHat tools I know).

Plans from Red Hat

Posted Feb 7, 2003 16:01 UTC (Fri) by Laney (guest, #9063) [Link]

I appreciate what Red Hat are trying to do here, with their redhat-config-* packages. Obviously there is room for improvement, as detailed in previous comments.

I dislike, however, this coming at the expense of the ncurses based packages such as ntsysv, netconf etc. Now, its either run X windows or edit the files by hand. Fine, I can edit them by hand, but these tools were useful, particularly ntsysv, for quickly achieving trivial changes to the system.

But, clearly, this product is not aimed at the small server market any more, rather focusing on the desktop workstation.