* A paper about Plan 9 and Guix
@ 2024-04-04 20:20 Edouard Klein
2024-04-08 5:44 ` Pjotr Prins
2024-04-10 15:08 ` Ludovic Courtès
0 siblings, 2 replies; 7+ messages in thread
From: Edouard Klein @ 2024-04-04 20:20 UTC (permalink / raw)
To: guix-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A paper about Plan 9 and Guix
2024-04-04 20:20 A paper about Plan 9 and Guix Edouard Klein
@ 2024-04-08 5:44 ` Pjotr Prins
2024-04-10 15:08 ` Ludovic Courtès
1 sibling, 0 replies; 7+ messages in thread
From: Pjotr Prins @ 2024-04-08 5:44 UTC (permalink / raw)
To: Edouard Klein; +Cc: guix-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A paper about Plan 9 and Guix
2024-04-04 20:20 A paper about Plan 9 and Guix Edouard Klein
2024-04-08 5:44 ` Pjotr Prins
@ 2024-04-10 15:08 ` Ludovic Courtès
2024-06-02 13:14 ` Edouard Klein
1 sibling, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2024-04-10 15:08 UTC (permalink / raw)
To: Edouard Klein; +Cc: guix-devel
Hi,
Edouard Klein <edou@rdklein.fr> 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’.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A paper about Plan 9 and Guix
2024-04-10 15:08 ` Ludovic Courtès
@ 2024-06-02 13:14 ` Edouard Klein
2024-06-06 14:20 ` Ludovic Courtès
0 siblings, 1 reply; 7+ messages in thread
From: Edouard Klein @ 2024-06-02 13:14 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> Edouard Klein <edou@rdklein.fr> 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’.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A paper about Plan 9 and Guix
2024-06-02 13:14 ` Edouard Klein
@ 2024-06-06 14:20 ` Ludovic Courtès
2024-08-27 15:50 ` Edouard Klein
0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2024-06-06 14:20 UTC (permalink / raw)
To: Edouard Klein; +Cc: guix-devel
Hi Edouard,
Edouard Klein <edou@rdklein.fr> 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
<https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/>.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A paper about Plan 9 and Guix
2024-06-06 14:20 ` Ludovic Courtès
@ 2024-08-27 15:50 ` Edouard Klein
0 siblings, 0 replies; 7+ messages in thread
From: Edouard Klein @ 2024-08-27 15:50 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> Hi Edouard,
>
> Edouard Klein <edou@rdklein.fr> 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?
>
First, I made a typo, it's /srv/listen/ that needs monitoring,
/run/listen is where the services can put sockets to communicate with
the rest of the systme.
Then, one of the point of listen is to allow access control on a a
per-user, per-port basis: the permission of e.g. /srv/listen/tcp79 will
decide who can fiddle with the finger server.
It is the reason why one need something to monitor the directory and
start/stop services based on its content
> Ludo’.
>
> ¹ The first implementation of this idea was
> <https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/>.
^ permalink raw reply [flat|nested] 7+ messages in thread
* A paper about Plan 9 and Guix
@ 2024-04-09 8:06 Nathan Dehnel
0 siblings, 0 replies; 7+ messages in thread
From: Nathan Dehnel @ 2024-04-09 8:06 UTC (permalink / raw)
To: edou, guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-08-27 15:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-04 20:20 A paper about Plan 9 and Guix Edouard Klein
2024-04-08 5:44 ` Pjotr Prins
2024-04-10 15:08 ` Ludovic Courtès
2024-06-02 13:14 ` Edouard Klein
2024-06-06 14:20 ` Ludovic Courtès
2024-08-27 15:50 ` Edouard Klein
-- strict thread matches above, loose matches on Subject: below --
2024-04-09 8:06 Nathan Dehnel
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).