Re: GSoC ideas

[Manolis Ragkousis]

Hey

On 03/02/16 23:31, Ludovic Courtès wrote:
> Do you have examples of GNU/Linux uses that would make no sense?
> 

After a quick look in mount's man page I think that maybe Roland was
referring to some flags (like relatime for example) that when passed to
mount, expect the Linux kernel to handle the filesystem in a specific way.

> Other options include calling out to the ‘settrans’ command (inelegant
> IMO), writing Guile bindings for some of the Hurd libraries, and/or some
> sort of a MiG in Scheme (neat but takes some time!).

We could have a guile wrapper for the ‘settrans’ command that could
cover our needs. Isn't this feasible? WDYT?

Manolis

Re: GSoC ideas

[Samuel Thibault]

Ludovic Courtès, on Wed 02 Mar 2016 22:31:41 +0100, wrote:
> Samuel Thibault  skribis:
> > It can both help and hurt. Roland's concern is that we will probably not
> > want to provide a mount() that behaves like Linux, because in some cases
> > it may just not even make sense. So the "ported" software that would try
> > to use it would just fail.
> 
> Do you have examples of GNU/Linux uses that would make no sense?

I haven't investigated, I just report what kind of fear Roland was
having.

Samuel

Re: GSoC ideas

[Ludovic Courtès]

Samuel Thibault  skribis:

> Ludovic Courtès, on Wed 02 Mar 2016 11:09:28 +0100, wrote:
>> Manolis Ragkousis  skribis:
>> > 1) Merge wip-hurd branch.
>> > 2) Make the daemon handle chroot builds on the Hurd.
>> > Note here that on the Hurd, one does not need to be root to achieve
>> > isolation, so I should change the daemon to use this capability.
>> 
>> I think an ideal situation would be if libc provides ‘mount’ and
>> ‘umount’, with MS_BIND implemented in terms of firmlinks.
>> 
>> I remember Roland was not thrilled with the idea of adding ‘mount’ and
>> ‘umount’, but it would clearly help porting.
>
> It can both help and hurt. Roland's concern is that we will probably not
> want to provide a mount() that behaves like Linux, because in some cases
> it may just not even make sense. So the "ported" software that would try
> to use it would just fail.

Do you have examples of GNU/Linux uses that would make no sense?

Other options include calling out to the ‘settrans’ command (inelegant
IMO), writing Guile bindings for some of the Hurd libraries, and/or some
sort of a MiG in Scheme (neat but takes some time!).

Ludo’.

Re: GSoC ideas

[Samuel Thibault]

Ludovic Courtès, on Wed 02 Mar 2016 11:09:28 +0100, wrote:
> Manolis Ragkousis  skribis:
> > 1) Merge wip-hurd branch.
> > 2) Make the daemon handle chroot builds on the Hurd.
> > Note here that on the Hurd, one does not need to be root to achieve
> > isolation, so I should change the daemon to use this capability.
> 
> I think an ideal situation would be if libc provides ‘mount’ and
> ‘umount’, with MS_BIND implemented in terms of firmlinks.
> 
> I remember Roland was not thrilled with the idea of adding ‘mount’ and
> ‘umount’, but it would clearly help porting.

It can both help and hurt. Roland's concern is that we will probably not
want to provide a mount() that behaves like Linux, because in some cases
it may just not even make sense. So the "ported" software that would try
to use it would just fail.

Samuel

Re: GSoC ideas

[Ludovic Courtès]

Hi!

I realize I hadn’t responded to Manolis.  Another +1 from me!

Some random comments:

Manolis Ragkousis  skribis:

> Before May:
>
> 1) Merge wip-hurd branch.
> 2) Make the daemon handle chroot builds on the Hurd.
> Note here that on the Hurd, one does not need to be root to achieve
> isolation, so I should change the daemon to use this capability.

I think an ideal situation would be if libc provides ‘mount’ and
‘umount’, with MS_BIND implemented in terms of firmlinks.

I remember Roland was not thrilled with the idea of adding ‘mount’ and
‘umount’, but it would clearly help porting.  I don’t know if this task
should be part of the GSoC project though, and you may need guidance
from the Hurd folks.  What do people think?

> 3) Instead of using the Linux syscall guile wrappers, I should modify
> Guix to use a more Hurdish way (i.e settrans) so later on we can handle
> translators and bootstrap a GNU/Hurd system.

Possibly, depending on whether libc provides ‘mount’ and ‘umount’, which
would make things simpler.

> End of GSoC:
> Have a working GuixSD with Hurd as the kernel.

\o/

Cheers,
Ludo’.

Re: GSoC ideas

[Richard Braun]

On Sun, Feb 28, 2016 at 11:12:25PM +0100, Samuel Thibault wrote:
> Just sending my big +1 on this project :)

Same here.

I'd like to note that I'm personally pushing so that we have less
students but with better projects. This one definitely fits.

-- 
Richard Braun

Re: GSoC ideas

[Samuel Thibault]

Hello,

Just sending my big +1 on this project :)

Samuel

Re: GSoC ideas

[Alex Sassmannshausen]

Andreas Enge writes:

> On Thu, Feb 11, 2016 at 01:46:30PM +0200, Manolis Ragkousis wrote:
>> As I am still a student I would like to suggest continuing the project
>> of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
>> having a working GuixSD/Hurd by the end of the summer.
>
> Sounds great, I hope it will go through!
>
> Andreas

+1 :-)

Re: GSoC ideas

[Christopher Allan Webber]

Manolis Ragkousis writes:

> Hello everyone,
>
> As I am still a student I would like to suggest continuing the project
> of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
> having a working GuixSD/Hurd by the end of the summer.
>
> After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd
> port I am starting to have a good idea on what is left to be done and
> the solution needed for the problems we have.
>
> So here's a preliminary timeline as well as a list of things to be done:
>
> Before May:
>
> 1) Merge wip-hurd branch.
> 2) Make the daemon handle chroot builds on the Hurd.
> Note here that on the Hurd, one does not need to be root to achieve
> isolation, so I should change the daemon to use this capability.
> 3) Instead of using the Linux syscall guile wrappers, I should modify
> Guix to use a more Hurdish way (i.e settrans) so later on we can handle
> translators and bootstrap a GNU/Hurd system.
> 4) Better understand how GuixSD startup works.
>
> May-August:
> 1) Implement the mechanisms for creating and mounting the initial
> filesystem and starting the system.
> 2) Implement the mechanisms to handle the Hurd servers in /hurd. I
> remember I was told that there may be an issue when the servers are not
> actually there (i.e all the binaries are in the /gnu/store). Would love
> if somebody could tell us more on that.
> 3) Isolate Linuxisms around Guix.
> 4) David Michael has made an excelent work on getting Shepherd working
> with Hurd so I don't think we will have any serious issues with the init
> daemon.
> 5) Others that will come up.. In the following weeks I will work closely
> with the Hurd guys to make sure we get a better understanding of
> everything and a detailed timeline.
>
> End of GSoC:
> Have a working GuixSD with Hurd as the kernel.
>
> Currently Justus (and others soon :-)) are testing Guix on their
> machines. We have some issues but we are working on them.
>
> Please feel free to add/correct anything from the above. Your
> comment/opinion may help to get things up and running faster :-)
>
> Finally I want to say that I will continue my work on this, regardless
> of GSoC or not, but I would like it if it was. :-)
>
> Thank you,
> Manolis

I can't speak for everyone else but it feels like this would be a great
project for you to contininue.  The guile-emacs project ran for a few
years, so I don't see any blocker on continuing, right?

Re: GSoC ideas

[Manolis Ragkousis]

Hello everyone,

As I am still a student I would like to suggest continuing the project
of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
having a working GuixSD/Hurd by the end of the summer.

After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd
port I am starting to have a good idea on what is left to be done and
the solution needed for the problems we have.

So here's a preliminary timeline as well as a list of things to be done:

Before May:

1) Merge wip-hurd branch.
2) Make the daemon handle chroot builds on the Hurd.
Note here that on the Hurd, one does not need to be root to achieve
isolation, so I should change the daemon to use this capability.
3) Instead of using the Linux syscall guile wrappers, I should modify
Guix to use a more Hurdish way (i.e settrans) so later on we can handle
translators and bootstrap a GNU/Hurd system.
4) Better understand how GuixSD startup works.

May-August:
1) Implement the mechanisms for creating and mounting the initial
filesystem and starting the system.
2) Implement the mechanisms to handle the Hurd servers in /hurd. I
remember I was told that there may be an issue when the servers are not
actually there (i.e all the binaries are in the /gnu/store). Would love
if somebody could tell us more on that.
3) Isolate Linuxisms around Guix.
4) David Michael has made an excelent work on getting Shepherd working
with Hurd so I don't think we will have any serious issues with the init
daemon.
5) Others that will come up.. In the following weeks I will work closely
with the Hurd guys to make sure we get a better understanding of
everything and a detailed timeline.

End of GSoC:
Have a working GuixSD with Hurd as the kernel.

Currently Justus (and others soon :-)) are testing Guix on their
machines. We have some issues but we are working on them.

Please feel free to add/correct anything from the above. Your
comment/opinion may help to get things up and running faster :-)

Finally I want to say that I will continue my work on this, regardless
of GSoC or not, but I would like it if it was. :-)

Thank you,
Manolis

Re: GSoC ideas

[Andreas Enge]

On Thu, Feb 11, 2016 at 01:46:30PM +0200, Manolis Ragkousis wrote:
> As I am still a student I would like to suggest continuing the project
> of porting Guix to GNU/Hurd in this GSoC as well, with the objective of
> having a working GuixSD/Hurd by the end of the summer.

Sounds great, I hope it will go through!

Andreas