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
> 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
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 firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com