guides VS text

i agree with this piece, as someone who likes man pages to the extent of having ported significant amounts of the s6-ecosystem docs to mdoc(7), and as someone who has also written a number of guides.

And the -bin kernel can be used to easily get many of the settings you'll need when you build your own kernel.

Gah, didn't even consider that the OP might have meant the cover image! Probably at least partly because i know that EPUBs don't necessarily need a cover image - i learnt this as a result of learning how to create a minimal EPUB. (And i actually have many EPUBs without a cover image.)

The point is to be able to customise where you want/need to, and to not have to when you don't. The -bin packages for FireFox, LibreOffice and Zig meet my needs, so i use them. i used the -bin package for the kernel to help me create a minimal kernel for my hardware, because messing around with kernel configuration is not my idea of a good time. But more generally, compiling allows me to specify things like: "i want packages compiled with USB and PCRE support where available, but i don't want them compiled with GNOME support."

Even though D-Bus is probably most often encountered by people in the context of GUI sessions, it's not specific to that; it can be (and is) used outside of such contexts. The widespread misunderstandings i've encountered about D-Bus over the years led me to write a short guide, "D-Bus: the essentials".

(Some related background you might find helpful: a guide i wrote about D-Bus and X sessions).

But more generally, you might find it helpful to refer to this guide i wrote on creating a minimal Gentoo-patched kernel via gentoo-kernel-bin (which can then be regularly updated just like any other Gentoo package).

Take advantage of savedconfig where appropriate, e.g. for kernel builds. In particular, this can be used to easily create a minimal kernel for your hardware.

(Further to this, you might be interested in my guide to creating a minimal kernel for your hardware.)

[a] i've actually written a quickstart guide to writing man pages with mdoc(7), to try to encourage others to use the semantics-oriented mdoc(7) macros for man pages, rather than the presentation-oriented man(7) macros.

As for the editor, I hope it will not reformat the text, see the Nextcloud debacle: https://github.com/nextcloud/text/issues/593

Yes, but some 'central' agencies push for specific Markdown formats/use. E.g. Nextcloud [1] wants to use Markdown as a format, to save the output of their wysiwyg text editor. Everytime you open a Markdown file in nextcloud-text, it is 'formatted' correctly, according to the Commonmark specs, and _written_ back, without asking the user.

[1]: https://github.com/nextcloud/text/issues/593

With the text app you can open to edit them. I believe its this one https://github.com/nextcloud/text

But since you do have concrete PHP experience, you might find it easier to try to work on some of the open issues in one of the Nextcloud repositories. So for example, if you go to the 'Issues' section for the Text app, there are various tags on the issues, and you might be able to start out by helping out with those tagged "Need triage". (i used to triage bug reports for Emacs itself, which is what led me to write this guide to reporting bugs in GNU Emacs.)

It may very well be expected behaviour. See for instance this on Github.