Re: A paper about Plan 9 and Guix

2024-06-06 Thread Ludovic Courtès
Hi Edouard,

Edouard Klein  skribis:

>> I wonder to what extent the combination of ‘make-inetd-constructor’ and
>> ‘least-authority-wrapper’ would fit the bill for you?  (This is currently
>> used for the bitlbee, dicod, and rsync services.)  It seems to address
>> the main shortcomings listed in Section 1.

[...]

> It sure would be nice if shepherd could be used to manage those daemons,
> just to avoid having two concurrent systems doing the same kind of work,
> but I'd still need a way to monitor the /run/listen directory, and start
> and stop shepherd services on the fly. It is probably doable, but it
> is a huge refactor.

To be clear, ‘least-authority-wrapper’ is already used for a handful of
services¹.  I’m curious whether /run/listen is still necessary in that
context?

Ludo’.

¹ The first implementation of this idea was
  .



Re: A paper about Plan 9 and Guix

2024-06-02 Thread Edouard Klein


Ludovic Courtès  writes:

> Hi,
>
> Edouard Klein  skribis:
>
>> I'll be presenting it not next week end, but the one after (12-14 April
>> 2024).
>
> Yay, congrats!
>

Thanks :)

>> I'd be happy if some of you would be so kind as to read it with their
>> extensive knowledge of Guix, in case I've made a mistake somewhere.
>>
>> https://the-dam.org/docs/explanations/Plan9ListenOnLinux.html
>
> Interesting read!
>
> I wonder to what extent the combination of ‘make-inetd-constructor’ and
> ‘least-authority-wrapper’ would fit the bill for you?  (This is currently
> used for the bitlbee, dicod, and rsync services.)  It seems to address
> the main shortcomings listed in Section 1.
>


I simply was not aware of the existence of least-authority-wrapper. It
does look nicer that passing a slew of options to guix shell
--container.


It sure would be nice if shepherd could be used to manage those daemons,
just to avoid having two concurrent systems doing the same kind of work,
but I'd still need a way to monitor the /run/listen directory, and start
and stop shepherd services on the fly. It is probably doable, but it
is a huge refactor.


> Thanks,
> Ludo’.




Re: A paper about Plan 9 and Guix

2024-04-10 Thread Ludovic Courtès
Hi,

Edouard Klein  skribis:

> I'll be presenting it not next week end, but the one after (12-14 April
> 2024).

Yay, congrats!

> I'd be happy if some of you would be so kind as to read it with their
> extensive knowledge of Guix, in case I've made a mistake somewhere.
>
> https://the-dam.org/docs/explanations/Plan9ListenOnLinux.html

Interesting read!

I wonder to what extent the combination of ‘make-inetd-constructor’ and
‘least-authority-wrapper’ would fit the bill for you?  (This is currently
used for the bitlbee, dicod, and rsync services.)  It seems to address
the main shortcomings listed in Section 1.

Thanks,
Ludo’.




A paper about Plan 9 and Guix

2024-04-09 Thread Nathan Dehnel
Wow, that's incredible.

>Port number themselves stem from TCP emerging from earlier protocols (see the 
>early RFCs 322, 349, 433 and those that obsolete them), and a clean design 
>would probably elect to eschew them, leveraging a \(2^{128}\) address space to 
>allow process-to-process communication, instead of the route-to-host, then 
>route-to-process dance we do know.
>
>The host to process frontier should be an implementation detail on the 
>receiving end, not baked so deeply in the stack.
>This barrier may even change from request to request as new hosts come up or 
>down depending on load.
>This already happens anyway with e.g. kubernetes, but we would have less cruft 
>if it was baked into the protocol.

That sounds like some of the problems RINA was trying to solve.
https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture



Re: A paper about Plan 9 and Guix

2024-04-07 Thread Pjotr Prins
On Thu, Apr 04, 2024 at 10:20:04PM +0200, Edouard Klein wrote:
> Dear Guix developers,
> 
> A paper of mine has been accepted as a Work in Progress at the next
> International Workshop on Plan 9 (http://iwp9.org/).
> 
> I'll be presenting it not next week end, but the one after (12-14 April
> 2024).
> 
> I'd be happy if some of you would be so kind as to read it with their
> extensive knowledge of Guix, in case I've made a mistake somewhere.
> 
> https://the-dam.org/docs/explanations/Plan9ListenOnLinux.html

All I can say is WOW. 

Pj.




A paper about Plan 9 and Guix

2024-04-04 Thread Edouard Klein
Dear Guix developers,

A paper of mine has been accepted as a Work in Progress at the next
International Workshop on Plan 9 (http://iwp9.org/).

I'll be presenting it not next week end, but the one after (12-14 April
2024).

I'd be happy if some of you would be so kind as to read it with their
extensive knowledge of Guix, in case I've made a mistake somewhere.

https://the-dam.org/docs/explanations/Plan9ListenOnLinux.html

Thanks in advance,

Cheers,

Edouard.