On Monday, 07/14/2008 at 11:19 EDT, Erik N Johnson <[EMAIL PROTECTED]>
wrote:
> Or roll your own completely from scratch.  If you don't have a reason
> to build a kernel, don't.  But if you have a computer capable of
> amazing feats of virtualization and there's something to be gained by
> making a change IPL a whole new kernel.  Make your changes in that
> one.  It's sand-boxed, right?  Nothing is permanent here.  Nobody is
> asking you to put your entire clientele at the mercy of some
> experiment.
>
> If this kind of talk makes you wince then you're right to think "I
> should just go with the program that comes in the box that my vendor
> provides and not ask any questions or poke any holes in anything.  If
> you don't have people actually programming for a mainframe on a
> mainframe this doesn't make any sense either.  I guess my question
> would have to be:  In an environment where changes cost people money
> and people are making unnecessary changes, why are you worried about
> reining them in?  FIRE THEM.  You don't praise accountants for
> creativity.  If somebody is trying to use your very expensive
> machinery to solve a problem in a new and interesting way that is
> going to make your company money though, that's when I'm confused
> about why you would ever rein in the creative process.  Programmers DO
> create things, after all.

You're missing our point, Erik.  Making a change, whether Good or Ill,
eliminates the support that our employers have PAID FOR.  That means no
support for the rest of the kernel that remained UNchanged.

As you say, you do those experiments in a sandbox and, if successful, you
push on your distributor to include those changes so that your support
contract remains in force.  Or you work through LKML or other project to
get those changes upstream and, eventually, they will show up in your
shop, fully supported.  But that's part of your company's desire have you
participate in the long-term improvement of the platform.

The System Programmers you find here typically have neither the time, nor
mandate, to go off and be creative with the Linux kernel.  They are paid
to deploy Linux in a cost-effective manor to the benefit of the
money-making applications.  Their creativity is often exercised in the
areas of custom system automation (Linux or z/VM), managing the
performance of the entire System (not just one Linux), and in handling the
political issues that always arise when there's a New Guy In Town.

Of course, one is free to be creative on one's own time with one's own
resources.  Through the College of Hard Knocks, people have found that
using Company resources for personal projects is a good way to give the
Company an opportunity to fire you for reasons having nothing to do with
Linux kernels.

Alan Altmark
z/VM Development
IBM Endicott

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to