[K12OSN] Greg reminds us to taste the soup

James P. Kinney III jkinney at localnetsolutions.com
Thu Jun 28 02:10:32 UTC 2007


I am going to weigh in on this with a somewhat cynical yet pragmatic
viewpoint. My apologies to anyone who feels less than stellar after my
rant.

Teachers are teachers. The cursed few who have been bit by the sys-admin
bug are doomed to a life of misery trying to juggle the tasks they are
paid for against the tasks that need to be done.

The error in this situation (science teacher turned fledgling admin) is
due entirely to the faults of the upper management of the schools system
for that teacher. They have lost the focus. Teachers are to be
supported, not used. If a teacher is given root access on a computer,
they need to also be told who their support person is for aspect of
their new job. Teachers are teachers. The vast majority need training on
how to use technology, not given god-like powers over the system that
runs half the school!

I have witnessed a very well meaning teacher get dressed down to the
point of quiting because they had root access and tried to make things
better. Mistakes happen. It is the precursor to learning. Backups are a
good thing!

The secondary mistake is the lack of a supervisor that understands that
a non-admin person is now doing admin tasks.

Now on to the software side:

In the not-to-distant past, people who actually _touched_ a computer
were highly trained and usually had a PhD. Now computers with more
capabilities than used for the creation of the first atomic bombs can be
bought by any slack-jawed yokel from WalMart.

Science teachers are probably more likely to make a decent admin than
say a history teacher. The odds are better than 50/50 they actually used
computers for more than just word processing in their college process.

Just as in general a teacher should NOT be given the ability to remove
an application from a windows machine, they should NOT be given the
ability to remove a package from a Linux machine. They should be given a
person they can contact to safely remove the package. At the same time,
that person should be collecting information as to WHY a certain package
is being removed.

Now let's assume the teacher has been granted the admin rights for good
cause. For undisclosed reasons, the button ABC has been determined to be
a problem and the only solution is to remove it for use for all
students. 

But the application name says "foo" and they see no application named
"foo" using yumex.

Who is at fault here? The teacher/grasshopper-admin who doesn't know
application "foo" is package "bar"? The package-manager application for
not telling the user that foo is found in bar? 

I would argue that the fault here is, again, the upper management that
did not inform the teacher/admin who to contact for help _WHEN_ they get
in over their head.

There will always be a disconnect between CLI and gui. I think that is a
good thing. The gui lets a junior admin "do things" with minimal
potential damage. If it can't be done using the gui and the junior admin
doesn't know how using CLI, that's fine. The teacher just found
something new to learn and the school didn't just have the box hosed in
error.

Does this mean the gui development should stop. Absolutely not! The gui
is a great way to offload simple tasks to the junior with minimal risk.
But making a gui that encompasses the knowledge of the senior admin is
not practical.

So in this instance, the teacher is over their head and those task that
require CLI MUST be run through "channels" to a senior admin with the
skills to perform the task. Anything less is just the upper management
trying to get $100+/hour work for $30+/hour.
-- 
James P. Kinney III          
CEO & Director of Engineering 
Local Net Solutions,LLC        
770-493-8244                    
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/k12osn/attachments/20070627/50cefba7/attachment.sig>


More information about the K12OSN mailing list