bug-hurd
[Top][All Lists]
Advanced

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

Re: upstream GNU Hurd vs Debian GNU Hurd?


From: Thomas Schwinge
Subject: Re: upstream GNU Hurd vs Debian GNU Hurd?
Date: Tue, 10 Sep 2013 20:36:42 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)

Hi!

On Mon, 09 Sep 2013 12:13:42 +0200, Justus Winter <address@hidden> wrote:
> Quoting Samuel Thibault (2013-09-09 10:04:55)
> > Putting a proper subject and explicitly Cc-ing maintainers, otherwise
> > people will not notice the question under technical details :)
> 
> Noted >,<

I always continue to plan to catch up on list email (or also "direct"
email, for that matter) -- but it just doesn't seem to be happening.  :-/

> > Justus Winter, le Thu 05 Sep 2013 13:04:35 +0200, a écrit :
> > > Turns out it was only because my /hurd/init contained the
> > > proc_set_init_task patches while the /hurd/proc I built on top of hurd
> > > upstream did not :/ and this was even though I wrote those patches.
> > > 
> > > So I'd like to restate these questions:
> > > 
> > > 1. Who is "upstream GNU"?
> > 
> > Well, it's actually us too :)

And, let's be clear: given your current involvement and great work, there
is no reason not to hand more power to you, too.  (Whatever that means in
an open project.)  :-D

> Cool! Let's upstream all those debian/patches then.

If they're in a form suitable for upstream (GNU upstream generally do
strive for high quality standards on design and implementation, the Hurd
being no difference), and there is consensus about them: yes, please.

> > > 2. If I shall continue working on the Hurd, how suspectible is
> > >    "upstream GNU" to my patches?
> > 
> > It depends on the patches.
> > 
> > AIUI, the difference between upstream GNU Hurd and Debian GNU Hurd is
> > whether we want to build a GNU system or a Debian system.

I consider the GNU Hurd project a different project from the complete GNU
system; the GNU Hurd "just" providing one component of it.  Discussion
and implementation of the GNU system happens (or would happen) elsewhere,
for example on
<http://lists.gnu.org/mailman/listinfo/gnu-system-discuss/>.

> > The GNU
> > system will probably want to have its own startup system, while on
> > Debian, we prefer to use the Debian startup system, to avoid maintenance
> > burden on the Debian side.  As another example, in Debian GNU Hurd we
> > have abandoned the idea of keeping /usr a symlink to /, because it was
> > posing too many problems, that we don't have time to fix (and they are
> > not interesting).  This also brings a divergence.

The /usr thing I too consider purely a policy decision; not to be
enforced by mere selection of your operating system kernel, but instead
just how your software distribution has been configured and built.

> > > I ask this because I see the difference between "Hurd with Debian
> > > patches" and "upstream Hurd" as a burden not only for the Debian
> > > maintainers but also for any potential developer.
> > 
> > Yes, this poses problems indeed.

I do agree.

> > I'd tend to think that upstream Hurd
> > should integrate what is useful for downstreams like Debian to adapt the
> > Hurd to its own purpose.  The problem comes when this would make the
> > upstream Hurd have to work a downstream way, and not be able to choose
> > its own GNU way.
> 
> At the cost of someone compiling a upstream Hurd component that does
> not work on Debian? Afaiui I can take any version (well, almost, if I
> don't pick an *too* oldish one) of an unmodified Linux kernel and boot
> my Debian system with it.
> 
> > > Also, according to [0] Debian/Hurd is the only "working" Hurd
> > > distribution (whatever that means, let's say not in "early stages of
> > > development" and not "defunct" as used on that page).

Always happy to see patches updating the web pages, too.

> > > In particular,
> > > the "GNU" distribution is marked as "defunct" and according to [1]
> > > there has not been a release for seven years. So from my point of view
> > > they are *not* using /hurd/init as reaper, so they might as well *not*
> > > use sysvinit (or any other established init system) as reaper.
> > 
> > Actually Guix is on its way to become a GNU distribution, and some
> > preliminary work has already been done on the Nix side, it does work a
> > bit.  AIUI, there are people motivated on working on that distribution,
> > which would become a GNU system using the Hurd.
> 
> I don't buy it ;)
> 
> /hurd/init is not an init system, it barely does anything any other
> init system does. From my point of view its name is the only thing
> that it has in common with other init systems, and it should really be
> named /hurd/startup or /hurd/bootstrap or something as it really
> mostly bootstraps a couple of processes running atop of mach into
> something resembling a POSIX system. If GNU wants a sysvinit
> replacement, they will have to write one.

I'm certainly not disagreeing with you.  What you're seeing there, as I
understand it (I have not been around myself back then), in principle is
some infrastructure to cobble the whole system together, so that one can
indeed boot a GNU Hurd system.  From my point of view, this stuff
(perhaps aside from the Hurd server startup/bootstrap) is not part of the
the GNU Hurd project, but instead some separate package(s): an
init/daemon management system, startup scripts, and whatnot.  Clearly an
init system may be doing some things differently on the Hurd than it does
on a "regular" Unix system, but it doesn't have to; its the init system
implementor's choice.  The stuff shipped with the GNU Hurd for me is not
meant to provide all that, but instead I consider the GNU Hurd to just be
the Hurd interfaces (RPC definition files), and their implementation in
the Hurd libraries and Hurd servers, and the integration work (such as
init system, or package management) to be done externally.

So if you say /hurd/init is confusing and should be renamed/reworked
(including removing functionality it currently provides) to, say,
/hurd/bootstrap, then that is a valid proposal to be considered.  (I have
not yet been able to look at this discussion myself.)

> Out of curiousity I browsed the GUIX package list, and I couldn't find
> an init system in there. How do they even boot the system? I did find
> the linux-libre kernel though, so if GUIX wants to run ontop of both
> Linux and Hurd, they will have to find/write an init replacement that
> runs on both. Even if /hurd/init was an init system, it surely does
> not and never will run on Linux.

I'd be happy to see a Guix system using the Hurd, but I don't know about
the efforts with that.


Sorry, have to leave.

Grüße,
 Thomas

Attachment: pgp3Uz2EmzlTx.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]