Hi all!

Yes, I know, why re-invent the wheel? Well, because it's fun :)

https://lab.abiscuola.org/gmnxd

It's a gemini server that works with inetd and requires a reverse proxy in front of it for TLS
acceleration. I've built it for my personal use case: an OpenBSD server already using relayd(8)
for the web.

There is also a gemtext -> html5 compiler/converter in the same repository as I use it to serve
the same content of my gemini capsules on the World Wide Web.

Cheers.

Andrea

Hi.

Sorry for the horrible delay. I was on vacation.

On Sun, 12 Mar 2023 19:43:35 +0100
Mika Feiler <m@mikf.pl> wrote:

> Andrea Biscuola wrote:
> > When I started to work on it, having a portable branch was a "nice to have" that I put at the bottom
> > of the requirements list.
> >
> > However, the code itself is really basic and a port probably require some just some hours of work.
> > Mind that, _I_ don't plan to use gmnxd on linux anytime soon, but if somebody would like to have
> > it work on some linux distributions, I wouldn't mind doing the work (or accepting patches for it).
> >
> > That's said, there are two ways, that I see, to make gmnxd portable:
> >
> > 1 - Doing it quick: things like pledge and unveil becomes no-ops and things like strlcpy are added
> > to the codebase.
> > 2 - Doing it right: find a proper way to sandbox gmnxd on linux (landlock?). However I'm no expert
> > on how to do something like that on linux, so I may need some help with it.
> >
> > I may give it a shot in the next days and see, first, what a "quick" port would look like.
>
> I think a good idea in case of not trying to keep it
> portable-even-but-untested would be to introduce a TODO-like keyword for
> code comments, that would be added every time a change would be
> suspected to be non-portable; or a document where all the things to do
> for such a port would be summarized and kept up to date.

I agree. Right now I'm busy with another project, but just adding a specific document to the
repository wiki would make sense to understand the work required for portability.

I'm not a huge fan of using code comments for such purpose.

> That way a port wouldn't have to start with a thorough reading to
> summarize what has to be done, and would have better chances at
> estimating effort.
>
> Such summarizing/annotating could be performed while the code stuff is
> still relatively fresh in the memory, and while the codebase is still
> fresh and transparent enough.

Well, the code in itself is quite small. It would take more work to make the makefiles portable
than anything else.

--
Andrea