navi-desu

it does do bounds checks if you -fsanitize=bounds, in gcc at least

(and msvc is stuck on partial c11 support to this day, so imo, i don't quite think it's a fair target when comparing things to new features anyway)

and how is that any different from system services doing `ExecStartPre=/usr/libexec/my_setup_script.sh`? or worse, 20 different `ExecStartPre` lines that basically build a shell script in the ini file, one line at a time

services are not simply a set of knobs to start a single process, often they don't even have processes (e.g. wg-quick)

and even when they do, it often involves setup, and sometimes cleanup.

systemd has to provide the exact same functionality, even if they put a .ini-paint of coat in it -- the difference is that openrc doesn't make services install N helpers scripts for that. Really, "Not being turing complete" is a useless metric for "stopping complexity in init setups"

the way you stop complexity is by giving pre-configured functionality that is easy to use. systemd did that very well, openrc does do that for a lot of things already, and we're adding more as we see the common need of init scripts for said features

> OpenRC still requires you to manually enable support for service auto-restart ( https://wiki.gentoo.org/wiki/OpenRC/supervise-daemon#General... ), a feature that comes built-in in systemd and without extra complexity or components, and with predictable outcomes given the unit file

fwiw it's being worked on to have supervision as the default in openrc as well

what is... actually wrong with that?

it works, it's extensible, and a simple service is just as declarative as systemd, but when you need to do something more complex (e.g. checking conditions before starting), you don't need to create a separate script to do so or pile up 10 ExecStartPre lines, just `start_pre() { ... }` away

i've seen people again and again complain of "but shell scripts", while the default functions provide an interface with declarative variables right there, what is the actual issue with it?

> 1. Define a new cross-terminal-emulator OSC sequence that instructs the terminal emulator to echo back THE WHOLE TERMINFO CAPABILITY STRING, in-band. No "user agent sniffing" with TERM. We detect features directly from now on.

XTGETTCAP does that (kindof), it's implemented by xterm, kitty, and foot.

xterm allows querying keyboard caps, plus a few others

kitty adds to that querying all integer and string caps

foot adds to that bools caps, meaning in foot you can query all of terminfo via it.

what we need to do is bring other terminal emulators up to par with foot's XTGETTCAP, and then we can finally ditch libterminfo for good.

meson actually solves this problem on the build system, their wrap subsystem allows you to use the system provided lib if found, or fetch from a database during the build process if not.

best of both worlds, imo.

gnome hard depends on systemd, so much that for it, *bsd (and any non-systemd unix-like) had to write a systemd-shim to emulate some functions of it, and/or gut some of systemd's components such as logind in to elogind

> It's also not a complete alternative, because it doesn't have anything for user session services like `systemd --user`.

i am working on a implementation of that for openrc for a while now, it's been working nicely so far: https://github.com/OpenRC/openrc/pull/573