Andrew Hecox wrote:
John Summerfield wrote:


Every sysadmin is a beginner at some time. If you want a new email
account set up, would you prefer your beginner sysadmin to spend five
minutes filling in a form on the screen, one that prompts for the full
set of information, one that ensures he does a complete job all in five
minutes, or do you think his time's better spent reading manuals and
howtos for an hour or so, coming up with an different answer from last
time?

Okay, so you've spend big bucks and she's trained, so it only takes 15
minutes. Probably she'd take three minutes with the form.


I would rather that she read the 10 line shell script so that she
understood unambiguously what it means to our site to "add" a user, even
if it took an hour. If we're going to have an admin for 3-5 years, I'm
happy to take 3 full months of training so that they can understand the
breadth of what we do and how we do it.

To further illustrate my point, I've spent most of the time between my earlier reply and now trying to install sudo and gpm on my freshly-installed Debian Etch system.

I'm competent in Debian, I've used it for some years. Installing stuff in Debian is usually easier than on Fedora.

Debian's asked me for the install disk. Okay, I have the ISO I installed from right on the same physical system.

The problem is that this is a virtual system, I created it with virt-install (after quite some reading and trying of different incantations).

Some problems.
1. virt-manager allows one a list of computers, and from there I can open a viewer. There are two viewers, and of the two, this is the worse. The other has the ability to select keystrokes to send to the guest. Keystrokes such as ctrl-alt-F1 to switch consoles. The one virt-manager doesn't have that ability. Both capture the mouse cursor so one can't move it outside the window, and KDE captured my ALT-F1 and popped up a menu I couldn't use, and the viewer couldn't receive keystrokes. Since the mouse was captured, I couldn't mouse out of there to kill it. Fortunately, all this was inside VNC, so I was able to get away to a separate ssh session and kill it.

Okay, that's a bug and not directly relevant, but it contributed to the sense of frustration when if found out

2. virsh, which is supposed to attach a new block device and which should do (I think) what I want doesn't work. Again, it took quite some reading to find how it do it.
2. xm has the ability too. However,
2.a The example in the manual is wrong
2.b It won't attach a file to an existing virtual drive, as far as I can see
2.c It will create a new block device with the file, but Etch doesn't recognise it. 3. xm has the ability to remove a block device. According to the manual. AFAICT it doesn't actually do anything.

I don't have a high opinion of the Linux virtualisation tools just now, and I've wasted hours trying to make it work.

With a well-designed GUI, I should be able to do this in a couple of minutes, without the need to read through various man pages, the point in 2.a would not arise, whether 2b is possible will be immediately. 2.c would arise, but at least it would be pretty quick.

I _have_ used the free version Microsoft's Virtual PC. It's fairly basic, but it really is easy to use, and importantly, it doesn't require the hardware virtualisation I need to run fully virtualised computers in xen.

script very quickly and easily.
Assuming it's properly documented and easily found. The best
documentation is on-screen forms, part of an integrated administration
tool.


I'm not sure I follow how that is the case, or even what you mean.

I use KDE.

I open "control center," it's in the Application menu.

It's left pane is a list of things I can change.

I choose KDE Components and there's sublist of things to change.

I select "Component Chooser" and a similar (to control=center) window opens inside the right pane. Again, it has a left pane listing things to change, and in its right panel is a description of what this does, and some things to change regarding my email client. Its left pane has selections for text editor, instant messenger, terminal emulator and web browser.

All the information most users would need on how to use it's on the screen, and there are fields to supply all the relevant information. Where it wants a file name, I can type it or use a "file open" kind of dialogue.

It's easy to use, I don't need three months' training.

Gnome has a similar idea, it's the System/Preferences menu structure.


I think the interesting question is not if there's value in a general
system management tool but at what point does it's value v. cost exceed
simple homegrown solutions. And at that point, where your scale or
problem is large enough that you've exceeded homegrown solutions, is
there all much value in which one RHAT happened to include in the distro?
Home-grown solutions are always expensive, more so in small shops. In
small shops they tend to be basic, undocumented and hard for the next
sysadmin to find.


I don't quite understand how they are always expensive. Certainly, home
grown solutions /can/ be awful, awful stuff but so can third-party
solutions. Rather than be definitively awful or awesome, I'd submit both
have different characteristics and are appropriate under different
circumstances.


Commercial systems tend to me more comprehensive, but its development costs are spread over many users.

Don't take this as referring to you personally, Andrew, this is just illustrative, some kind of average.

What's your salary? Let's say 100,000 currency units.
How many weeks a year do you work? Depends on employment conditions, but allowing for annual leave, sick leave, public hols, long service leave, let's say 44 weeks. The number's not that important.

What are the overheads of employing you/ You need a desk, phone, office space, a computer, you use electricity and your office space needs a share of the building's management. Then there's the time managing you, preparing your share of the payroll, processing applications for annual leave, sick leave, special payments (super? I'm sure it varies widely). Let's say it amounts to about your annual salary, give or take a bit. It's a number I've seen for Australia. Again, the number's not that important.

Okay, for your 44 week's work your employer pays 200000/44=4545 currency units. Let's say +-50%.

One week's work costs 2272-6817 currency units. If you spend a week writing scripts for some management tasks, that's the sort of cost you incur,


Another rule of thumb I read is that a competent programmer produces 100 lines of documented, debugged code a day. Now obviously, that varies enormously with the technical difficulty of the task, and writing a few management scripts would be at the easy end of programming.

If someone claims to be significantly better than that, look to what problems they're solving, how they're testing and what documentation they're producing.



There also is clearly an issue of scale, maturity, complexity, and
interface. For example, our script for adding users calls useradd even
though we could easily have modified the relevant files ourselves.
However useradd presents a stable, well-documented, and easily scripted
interface. Each new major version of EL we verify that things like
useradd continue to do what we expect and if they don't, we wrap those
changes into our code. Verifying that useradd's -m, -G, -u, and -p and
options still do the same thing is a very quick process.


I often wrap command with my own scripts, commonly for downloads I want to do repeatedly - Linux update, podcasts, homes for sale, securities prices, but that's a vastly different scale of task from those addressed by linuxconf and yast. It would be far cheaper to buy something like those (ignoring that those are FOSS) than to write one's own.


--

Cheers
John

-- spambait
[EMAIL PROTECTED]  [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

Please do not reply off-list

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to