In reply to @jade_:matrix.org
subsystem seems like the absolute cleanest way of doing this tbqh, but putting PATH stuff in a drop in for sshd_config somewhere would also work

Of course it is: https://manpages.debian.org/unstable/openssh-server/sshd_config.5.en.html

Note that the Debian openssh-server package sets several options as standard in /etc/ssh/sshd_config which are not the default in sshd(8):

Include /etc/ssh/sshd_config.d/*.conf

so re: https://discourse.nixos.org/t/2024-03-07-documentation-team-meeting-notes-112/40963

@danielsidhion: Evaluating frameworks that could do multi-page renders for the Nixpkgs/NixOS manuals, making sure all necessary extensions and more are supported

is this about presentation frameworks for rendered outputs, or for actual splitting? because actual splitting has been there from day one (html:into-file), which we feel is being forgotten on a weekly basis

I understand the frustration you're experiencing, especially considering the significant effort you've invested into the project.

However, Danielsidhion and I are currently exploring alternative options because we're trying to providing the best possible experience for our users.

This sometimes entails re-thinking our current approach. Adopting an off-the-shelf rendering framework that offers customization options could significantly enhance user-friendliness while reducing complexity and maintenance work. Daniel has a list of needed features like page search, intuitive navigation, handling cross references, md plugins, live editing etc, ultimately improving the overall user experience.

I think we might need an RFC if we really want to migrate anyways. This would also allow potential epub users to show up.

In reply to @jade_:matrix.org
It seems borderline absurd to assume that there exists an off the shelf solution that actually has proper interactions with nix and consideration of anything that is not a web browser. Have you considered taking the nrd output and using it in your pipeline instead of trying to reinvent it, so we actually own the markup parser and such?

In reply to @pennae:matrix.eno.space
like, the root problem with our docs isn't tooling support. switching out tooling again will only bind resources that could've been used for something that actually improves that status quo?

In reply to @infinisil:matrix.org
I'd say it's a problem that we use different tooling for different projects. I guess it would make sense to try and see if nixos-render-docs could be used throughout though (such as for Nix and nix.dev).

In reply to @pennae:matrix.eno.space
not nix-specific, but nixpkgs/nixos-specific very much so. like manpage export, integration with the option system, crossreferencing, even performance optimizations needed to generate such huge documents as the nixos manual