🚀 go-pugleaf

In <stephenkDp4z92.3An@netcom.com> stephenk@netcom.com (Stephen Knilans) writes:

>In article <danpop.828243225@rscernix> danpop@mail.cern.ch (Dan Pop) writes:
>>In <stephenkDp17xt.Boo@netcom.com> stephenk@netcom.com (Stephen Knilans) writes:
>>
>>>In article <danpop.828050308@rscernix> danpop@mail.cern.ch (Dan Pop) writes:
>>>>In <stephenkDowqB9.F4E@netcom.com> stephenk@netcom.com (Stephen Knilans) writes:
>>>>
>>>>>In article <danpop.827809042@rscernix> danpop@mail.cern.ch (Dan Pop) writes:
>>>>>>In <4j6lv1$k3r@news.mpd.tandem.com> Joseph Crowe <jcrowe> writes:
>>>>>>
>>>>>>>danpop@mail.cern.ch (Dan Pop) wrote:
>>>>>
>>>>>You have NO idea what you are talking about!
>>>>
>>>>If this is true, then remove /bin/sh and try to reboot your Unix system.
>>>>It's as simple as this.  You'll see who is the guy who has NO idea what
>>>>he is talking about.
>>>
>>>I DID!
>>
>>And what happened?
>
>It worked just fine, because I ALSO set things up to handle it in /etc.  You
>remember....the place you said we shouldn't do anything with!

In other words, you substituted /bin/sh by another shell in the first
line of some scripts.  I find it hard to believe that you reimplemented
in C all the startup scripts.  So, your setup was still relying on a shell.
>
>>>If you delete lotus 1-2-3, you can't use that program!  ERGO, if you delete the
>>>shell, you can't use the shell.  SIMPLE!
>>
>>If you delete /bin/sh you can't use the system at all, because this
>>program is a critical OS component.  SIMPLE, indeed.
>
>NOPE!  That is OVERsimplification.  It is a command line processor, nothing
>more.  You can replace it with another, or use programs.  HECK, you COULD
>put your own program there, and make things VERY secure!

And, as I repeated a zillion times, all the programs using system() and
popen() will stop working.  So will do cron.  Yes, one can replace all
these, but the result won't be Unix any longer.  What is so difficult to
understand?

>>>>>NOW HOW do you send a command to a shell without having the shell, HUH?
>>>>
>>>>This was precisely my point, which shows that I knew perfectly well what
>>>>I was talking about.  system(), popen() and cron are parts of the Unix
>>>>operating system.  Remove them and you have something which isn't Unix
>>>>any longer.
>>>
>>>WRONG!  
>>
>>Shouting is not a good substitute for a proof.
>
>You state that a program, whos purpose is to send a command to a routine, 
>SHOULDN'T need the routine!  That is like saying that a bank shouldn't have 
>money!  What a silly idea.

I do admit that your ideas are silly :-)

>>>ACTUALLY, unix itself is a KERNEL.
>>
>>By whose definition???
>
>By the industry, and by AT&T(the writers of same).

Care to provide some quotes?  The kernel is exactly what it's name suggests:
the nucleus of the operating system, not THE operating system.  The kernel
alone is not enough to make a computer usable, the other components of the
operating system are needed, as well.

BTW, the first "Unix" systems I've used and administrated were Apollo's.
Their kernel had nothing to do with Unix, yet they behaved like any
other Unix system, even at the level of system programming and system
administration.  The Unix system calls were implemented in terms of
Domain/OS (the OS used by the Apollo's) system calls in a library, and
this was completely transparent to the Unix system programmer.  TCP/IP
was completely out of the kernel, implemented as a daemon.  The networking
protocol which was implemented in the kernel was DDS.

Voila, Unix systems without a Unix kernel.
>>
>>Plain bullshit.  Without multiuser support in the kernel, your "auxiliary
>>programs" would never make Unix a multiuser system.
>
>Look at inittab sometime!  UNIX starts init, which is told by inittab to start
>several programs.  Among these are programs LIKE getty(but not necessarily getty
>) 
>that are directed to various terminals.  Things like user are on a task basis,
>so making a multitasking system with accessible tty possibilities multiuser is 
>EASY.
>
>BTW one user on one terminal could be logged in as HUNDREDS of users.  Try login
>sometime!

Multiuser support means more than multiple terminal or multiple session
support.  The kernel itself keeps track of the (effective and real)
user id and group id of a process.  Without these, you'll have a 
multisession or multitasking system, but not a multiuser system.

>>So what?  There are plenty of Unix applications that rely on those
>>components to work as advertized and which would break themselves if 
>>those basic Unix components stop working.  What's so difficult to
>>understand?  Who cares that my "hello, world" program will continue to
>>work?
>
>And there are macintosh programs that rely on Lotus 1-2-3!  What's your point?

My point is that if you remove /bin/sh, lots of applications (including
standard Unix utilities, bundled with the system) which worked fine,
will instantly stop working.  The system will stop complying to ALL the
Unix standards in existence (POSIX, SVID, XPG) and calling it Unix would
be an abuse.

>>>>We were talking about "applications, pure and simple", not about system
>>>>files.  I didn't ask you to remove any of the Unix configuration files,
>>>>only "applications, pure and simple", like /bin/sh, right?
>
>These applications ARE system files!

Could you, please, make up your mind?  Are they "applications, pure and 
simple" as you claimed previously, or are they "system files", as you
claim now???

>>>It is those unix configuration files that dictate what applications it will 
>>>need,  and you KNOW it.  I HAVE had to run without nearly everything.  I
>>>made a minimal boot disk(which incidently had NO sh shell!), 
>>
>>Sorry, the idea was to have "no shell", not "no sh shell".  Can you spot
>>the difference?
>
>As I said, you don't need ANY shell!

Remove all the shells and see how much of "The Unix Programming Environment"
by Kernighan and Pike has still any relevance to your "Unix" system.  It
looks like those (clueless) guys used a definition of Unix which is
slightly different from yours.

By the way, your claim is plain stupid.  A program which can start other
programs IS a shell, no matter how much different it is from the usual Unix
shells.  emacs, COMMAND.COM and the MacOS Finder are all shells.  Without 
any shell you won't be able to use the system at all, simply because you
won't be able to run _any_ program.  Once you have a program that can do
a fork+exec on user's behalf, you have a shell.
>>
>>>and HAVE done
>>>what you requested.  It actually runs BETTER!  
>>
>>You must be using a very personal definition of "BETTER" :-)
>
>By better, I meant faster and in less memory!

Nonsense.  How does a missing /bin/sh make the system faster or requiring
less memory?  All the other shells are either larger or slower (or both)
than /bin/sh. 

>HECK, do you REALLY think I can
>fit over 300Meg of code onto a 1.44MB floppy?

You don't have to.  Nobody asked a boot floppy to contain a complete Unix
system.

>The shell I generally use is 
>over 250K, so I even have to forego THAT! 

This is precisely why the shells used by boot floppies are smaller (typically
between 50-100K) and offering the functionality of the Bourne shell and
nothing (or very few) else.

>BTW I originally had NO ifconfig, and STILL have no cron, on those disks!

So what?  The system booted from such a disk is far from being a complete
Unix system.  It won't comply to any Unix standard and a significant part
of its kernel will be unused, because the applications needed are missing.
>
>>>Of course, I want to have more 
>>>flexibility generally.
>>
>>And you want to have something that could be called Unix and used as such,
>>not something that after booting doesn't give you the full functionality
>>of the OS, because lots of standard components don't work any longer.
>
>Try running every program for the mac on your computer.

If my computer were a Mac, your suggestion would have made sense.  It isn't
so your suggestion is nonsensical.  It is perfectly capable of running
Unix applications which were compiled for it.  If I remove /bin/sh, many
apps will stop running on my computer and I'll have to fix it (read
restore /bin/sh) ASAP.

>I GUARANTEE that many won't run! 

I can guarantee that NONE will run.  So what?

>UNIX has been around for a LONG time!  Some apps are now STANDARD.  It has a 
>program to print banners, one to do calenders, one to copy to another system
>over a normal serial port, several to use a serial port as a network.  Several
>to use ethernet, etc......   NONE of these are "NEEDED" to use the system, but
>some programs ASSUME they are there.  

Because the definition of Unix includes them.  Have a look at POSIX,
SVID or XPG sometime (or even at the historical UNIX Version 7
Programmer's Reference Manual -- Section 1) and you'll understand why
some applications assume and rely on the presence of certain "pure and
simple applications" which actually are components of the operating
system generically called Unix.

>Some of these programs have counterparts for the mac.  

So what?  

>What happens when you want to run one of these on the MAC?  HMMM?
>they have to ALSO add the needed programs that are generally on UNIX systems!

So what?  There is no need to try to convince me that MacOS is not Unix.
I already knew that :-)

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland