4 ms·

If it's really needed and there is no way around it, it'll be painful in almost any sane and modern init system (OpenRC isn't that much better at it than System

by zaarn 4y ago

If it's really needed and there is no way around it, it'll be painful in almost any sane and modern init system (OpenRC isn't that much better at it than Systemd, neither is svcs from Solaris which sucks the most at configs). A good init system IMO doesn't have deterministic behaviour built in but rather as emergent property. Your start order falls out of the service definition. --- The bluetooth module. Linux is highly modular and you can blacklist modules you don't want. And you can even compile modules after the fact. If you need bluetooth but your distro didn't ship it, you can in fact compile just that module and load it. Only some core options need a full recompile of the kernel but that isn't too terrible on most distros (apt source, Arch's ABS, etc.) either.

alxlaz 4y ago
> The bluetooth module. What bluetooth module? `CONFIG_BFQ_GROUP_IOSCHED=y` is a cgroup-related option. It's not pretty, and not because of a lack of tooling (apt source, ABS, whatever). The problem is that, since there's no "standard" configuration that you can depend on (unlike FreeBSD), you can't just take a "standard" system and reliably change a compile-time setting (or compile a module, or blacklist a module). There are a lot more moving parts (other compile options enabled downstream, additional patches applied downstream, especially in LTS kernels, compile-time options for userland applications and so on) which vary from one distro to another. I personally see the value of this approach. I think it's more flexible than what FreeBSD does. But it is far more time-consuming and, generally, pretty nerve wracking.
- zaarn 4y ago
  NixOS lets you do that kinda of stuff though. You specify that you want a kernel option enabled and it'll make sure that any kernel you install has it enabled or compiles one from the upstream source you set (or the default one). Even upgrading your kernel will ensure the option is enabled. And it'll ensure that any downstream modifications done by wherever you pull the kernel from has them enabled too.
  - alxlaz 4y ago
    Any distribution can do that -- at the end of the day, you can always get e.g. the linux-kernel deb-src and set the option in Kconfig. That will not solve the rest of the problem -- interaction with other kernel config flags, or side-effects vs. applications that assume a specific kernel configuration and patch set.
    - zaarn 4y ago
      No, NixOS solves that. Apps can require Kernel Config Flags to be set and the interactions between flags can be modelled in NixOS. And it'll all be side-effect free and the nixos rebuild command will tell you at build time if it's wrong.

by zaarn 4y ago

alxlaz 4y ago

> The bluetooth module. What bluetooth module? `CONFIG_BFQ_GROUP_IOSCHED=y` is a cgroup-related option. It's not pretty, and not because of a lack of tooling (apt source, ABS, whatever). The problem is that, since there's no "standard" configuration that you can depend on (unlike FreeBSD), you can't just take a "standard" system and reliably change a compile-time setting (or compile a module, or blacklist a module). There are a lot more moving parts (other compile options enabled downstream, additional patches applied downstream, especially in LTS kernels, compile-time options for userland applications and so on) which vary from one distro to another. I personally see the value of this approach. I think it's more flexible than what FreeBSD does. But it is far more time-consuming and, generally, pretty nerve wracking.

zaarn 4y ago
NixOS lets you do that kinda of stuff though. You specify that you want a kernel option enabled and it'll make sure that any kernel you install has it enabled or compiles one from the upstream source you set (or the default one). Even upgrading your kernel will ensure the option is enabled. And it'll ensure that any downstream modifications done by wherever you pull the kernel from has them enabled too.
- alxlaz 4y ago
  Any distribution can do that -- at the end of the day, you can always get e.g. the linux-kernel deb-src and set the option in Kconfig. That will not solve the rest of the problem -- interaction with other kernel config flags, or side-effects vs. applications that assume a specific kernel configuration and patch set.
  - zaarn 4y ago
    No, NixOS solves that. Apps can require Kernel Config Flags to be set and the interactions between flags can be modelled in NixOS. And it'll all be side-effect free and the nixos rebuild command will tell you at build time if it's wrong.