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
2001
[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
>>DOD, DISA/DECC, OSD, DARPA, USA, USN, USAF, and USMC.
>>
>>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
>>/bin`.
>>
>
> 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
environments.
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
jim
--
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
