Gordon Tetlow wrote:

> As a preface to this whole thing, I find it higly amusing that you are
> sending this mail from a Linux box. Of course, for that matter, so am I.
> (I'm planning on changing that soon.)

Excuse me?

FreeBSD wahoo.kc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Fri Aug 10 16:51:25 CDT 
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/WAHOO  i386

When Netscape comes out with support for FreeBSD again, I'll run native, until then, 
I, like everyone else using freebsd am stuck 
using netscape in the COMPATLINUX construct.

Please don't make assumptions about an operating environment without understanding the 
problems of living within that environment.

> On Sun, 12 Aug 2001, Jim Bryant wrote:
>>I said I'd drop it, but apparently there are people that don't
>>understand the dinosaur mentality of certain organizations such as
>>If it's not in the base setup, on a production box, you can't use it.
>>Everything must be kept in it's ORIGINAL install location, otherwise
>>you MUST justify it and ask DISA/DECC for a waiver, which in itself,
>>is a pain in the ass, and in many cases, not likely to happen due to
>>dinosaur mentality.
> You said it yourself. They are a dinosaur. Why should be drag ourselves
> back to the paleolithic and cater to a very specific problem in our base
> tree? bash is a nice shell. I use it as my normal shell, but when I drop
> to single user mode, I *always* end up using /bin/sh. I'm not a fan of csh
> (tcsh isn't bad though) and I only write shell scripts in /bin/sh.
> Besides, how often do you need to drop to single user mode and *really*
> need bash?

I'm not arguing for bash.  I despise bash in fact.

When I drop to single-user, I want to be in and out.  That means I want the tools to 
do the job most efficiently so I can be in and 
out.  I'm personally a tcsh fan, but shells are a matter of preference and 
proficiency.  What can take ten minutes in the bourne 
shell may only take me five using the shell of my choice.

IMHO, the real dinosaur mentality I see at this moment is opposition to a very trivial 
request, that even the real dinosaurs int he 
unix industry [the Suns, HPs, IBMs, SGIs, etc] are seeing must be done because of 
end-user complaints and requests.

Also, dinosaurs or not, DOD is now an INVESTOR in the FreeBSD system.  Name any other 
group besides maybe BSDI that has provided 
$1.4 million [USD] to the project.

We should look towards making FreeBSD the open-source OS of choice in the DOD 
environment, in which Linux has already made major 
inroads where FreeBSD isn't even allowed to tread yet.

>>I now refer you to the recent news concerning the TrustedBSD project.
>>FreeBSD is getting military contracts now.  We need to think ahead to
>>the needs of a whole new class of admin and user, and they are in
>>highly restrictive environments that preclude `mv /usr/local/bin/*sh
> And those people that are working there are probably programming in COBOL
> and Fortran.

More likely C, C++, and Java.  Maybe a bit of stuff ported to GNAT.

>>I'm sure there are equally restrictive environments for computers and
>>operating systems in *EVERY* country, but I speak from my personal
>>experience with the dinosaurs at DOD.  At DOD, *EVERY* copy of FreeBSD
>>will be subject to what I am saying.  In the Sun environment in which
>>I did my last DOD contract at, if tcsh wasn't in /bin, I wouldn't have
>>been able to use it.  That's how backwards they are.
>>In answer to your statement, some admins can be fired, even arrested
>>and brought up on charges for doing what you suggest.  I'm certain
>>that this happens in countries other than America as well.
> Again, this is a problem for you and the DOD to sort out. It should be of
> no concern to the project.

Actually, it is up to us to resolve this.  I don't think you understand how DOD 
operates.  The vendor makes the changes, not DOD. 
Not the admin.

Another priority item should be making sure we are compatible with such things as the 
latest versions of Oracle, etc...  This is an 
area in which we can compete head-to-head with the high-dollar stuff.

Also, I havn't worked for DOD in a long time, but I have done recent contracts with 
them, and understand firsthand the BS involved 
in having to do without tools all unix people, including myself, consider standard, 
that are not allowed because it's not part of 
the base install.

Moving the non-GPL shells to /bin is a trivial request that can solve problems that 
you obviously don't understand.

DOD will is a vast new market for FreeBSD, and if we don't think ahead now and 
consider what will make admins recommend FreeBSD over 
Linux, Solaris, or HP-UX, then we'll never reach the kind of market penetration that 
Linux, Solaris, and HP-UX have in the DOD 
market.  Key to this is an admin-friendly environment designed to get around the 
pre-cambrian attitudes that prevent DOD admins from 
using standard tools just because it's in the wrong place on the disk array or because 
it's considered a third-party option, or even 
worse: freeware [ooooh!  step away from the keyboard, son.  you going to prison, boy!].

DOD is only an example of an organization that can benefit from such a trivial change. 
 They can already get this with Sun, and 
probably HP as well [I haven't seen the latest minor release to 11.x, but I bet they 
are following Sun's lead].

Try thinking outside the box sometime.  If you want a "traditional" unix, I think 
there is still a PDP-11 emulator and DL01 image of 
V7 at gatekeeper.dec.com.

I'm more for an evolutionary unix where the idea of what's standard changes to reflect 
the needs of it's admins and users in diverse 

I may not be one of the big movers, but I think this is why I do what I can to help 
out with -CURRENT, to move forwards meeting the 
needs, instead of going nowhere due to outdated beliefs "oh, but that belongs in 
/usr/local/bin".  If something after years of use 
becomes a standard tool, it needs to be moved into the base distribution.  I give perl 
as a prime example of one time that this 
actually happened, despite the arguments for or against perl, it *IS* a standard tool, 
and it *IS* expected to be available.

My argument for the trivial move of the non-GPL shells to /bin, so long as they are 
statically linked, is based on experience in a 
market in which FreeBSD just got it's foot inside of the door.  We have already done 
this with tcsh.  I don't see what the problem 
is getting the rest of the non-GPL shells into /bin is.

Of course, if my argument is somehow bad, then we do have a real dilemma here.  Better 
remove tcsh from /bin at once to clear up 
this dilemma!  As I recall the Carnagie-Mellon University tcsh wasn't in the original 
BSD or USG implementation of Unix!  Can't be 
cluttering up the tree now, get it outta there!  [see how many admins, including 
myself, like that suggestion, after they fought so 
hard to get it in].  I recall posting a similar message to this list or -hackers back 
in '94 or '95 to get tcsh into /bin, I also 
remember people making the same argument as you back then.  I may be wrong, but I 
think I even recall Terry saying it'd be a bad idea.

How about an instant poll:

1). Since tcsh was included as a "standard" tool in /bin, do you use it in a 
standalone scenario?
a). Yes
b). No

2). Since tcsh was included as a "standard" tool in /bin, is it root's default shell?

a). Yes
b). No

ET has one helluva sense of humor!
He's always anal-probing right-wing schizos!

Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to