[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd does NOT need /hurd

On Wed, 2002-05-22 at 14:37, John H. Robinson, IV wrote:
> On Wed, May 22, 2002 at 01:42:31PM -0500, Jeff Licquia wrote:
> > Sample scenario:
> > 
> > Suppose init and su are both borked, and you don't have sudo.  You're
> > logged in as a regular user on the console, but you need root.  If you
> > log out, you'll lose your tty, and init won't respawn (remember, it's
> > borked).  When init went down, it took all the running gettys with it. 
> > How do you get to root to fix the problem?
> reboot, init=/bin/sash passed to the kernel.

Less useful, as it requires a reboot with a borked init.  (Safe reboots
are handled by init, remember.)  So, you're talking about adding borked
filesystems to the borkage of init and su.  "exec login" has none of
these disadvantages.

> i'm not averse to the idea of translators living in /hurd, since it is a
> hurd specific thing. i'm averse to saying ``they -have- to be there,
> because <insert falsehood here>.'' the ``user convienece'' and
> ``tradition'' arguments are actually both valid, and sufficient for my
> purposes. (they also anser -should-, not -must-) the ``they cannot be
> run by hand, so should stay out of $PATH'' is a false one, as
> demonstrated by some of the hurd developers themselves. mind you, i am
> not too hip on the intracacies of passive translators
> 	on two counts: 1) it is possible to have a translator that is a
> 	normal proggy as run by a user, and 2) there exist things in a
> 	user's $PATH that probably should not be there

Technically, there are very few "musts" in computers.  You can change
nearly anything you want, given enough time and resources.  So, it's all
about tradeoffs.

I suppose I'm just prepared to give the Hurd team the benefit of the
doubt for now.

> i coulda sworn, though that my /bin/login is non-suid . . .
> i'll verify _that_ when i get home

That is, assuming you can log in when you get home. :-)

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: