In a message dated: Wed, 21 Jun 2000 15:37:09 EDT
"Jerry Feldman" said:

>Ken,
>While this may be true to some extent, I do disagree. In my current role 
>of porting, I do not require root privs, but I do need to install some beta 
>software required for my system. However, in my previous contracts both 
>at Raytheon as well as at Digital, I could not do my job without having 
>root access. At raytheon I needed root priviledge to develop a device 
>driver for a fibre channel board. At least under HP-UX, it had to be 
>compiled in a specific subdirectory, and installed in another. At Digital, I 
>was responsible for the floating point code in the Digital Unix kernel. I 
>could build without root access, but certainly could not test.

Nothing you mention here can not be accomodated with a combination of changing 
permissions of the directory structures or via use of sudo.  Need a debugger?  
Sure, use it via sudo.  Need to install software, I use sudo almost daily to 
both build and install software.  Need to edit a file, sudo can do that too.

>Secondly, testing is not a lab function. Today, most software 
>development is performed at the desktop, and at least unit tested at the 
>desktop. In general, the developer should never, ever give untested code 
>to the test/QA people. More advanced testing, such as integration, 
>regression, is certainly a lab function. 

Well, this whole time the concept of a "lab" has been bandied about as if it's 
a totally different physical location.  But there's no reason why the system 
at the developers desk can't be punched down to a separate "lab" subnet.  
Additionally, you should *NO* under any circumstances be testing software on a 
live production network.  Period!  Why?  Because if something goes wrong with 
that software, you risk taking the entire network off line, then you've got X 
number of other engineers sitting around twiddling their thumbs.  Yeah, that's 
a productivity enhancement.  Too often I've seen entire subnets taken down 
because someone was testing software.  "Hmmm, that's funny, it's not 
*supposed* to do that."  The fact that Windows allows anyone to do anything 
without any concept of access control has been the bain of my sysadmin 
existence more than once.  I can't even count the number of times I've had 
people set up PDCs, DHCP servers, boot test devices with the same IP addresses 
as production servers, etc.  No, IMO, there is no room for testing on a 
production network, especially if one feels it requires root access.  *Maybe* 
if the product you're developing has nothing to do with network access, and 
*maybe* if it's a user space application that can only affect your machine, 
would I consider it okay to test in the open.

>The bottom line is that in the past 9 years or so I could not have done my 
>job without root privs. In my previous Digital contract, I had 3 systems in 
>my office. My personal Unix workstation, where I probably did not have a 
>requirement for root. I had another Unix system where I tested my kernel 
>mods, and a third system (alpha NT) where I tested the assemblers. 

And none of that needed to be on a production network, did it?  I doubt it.  I 
would agree that there may have been some inconvenience or changes to the way 
you did things, but given a decent environment, an adequately skilled sysadmin 
team, and a little cooperation from everyone involved, I'm sure you could not 
only have done your job with little or no impact on you productivity, but it 
could have also been done securely.
-- 
Seeya,
Paul
----
        "I always explain our company via interpretive dance.
             I meet lots of interesting people that way."
                                          Niall Kavanagh, 10 April, 2000

         If you're not having fun, you're not doing it right!



**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************

Reply via email to