Yes, I see your point. While both involve system administration, managing a server is fundamentally different from managing a laptop. The requirements, usage patterns, and priorities vary considerably. Since my perspective is shaped by laptop use, I will respectfully step back from the conversation. I'll leave you with an aside.
Note: This is a tangential aside and not essential to the main argument. Feel free to skip it. Changing the service model would necessarily require adjustments elsewhere in the system. One area that would demand particular attention is the init framework. This, it must be made clear. What was not stated explicitly is that revamping bsdrc would almost certainly be necessary in order to support and reinforce the proposed layered service model. At present, the FreeBSD init system depends on a loosely ordered sequence of shell scripts. It provides limited support for formal dependency tracking. There are no enforced boundaries separating system-level, administrator-managed, and user-defined services. To support a layered startup structure with well-defined privilege separation and reliable ordering, the init system itself would need to be restructured. A strict hierarchy, it would be required. Vendors too might welcome such a model, since it offers cleaner integration points and more predictable behaviour during system bring-up. In the revised model, each service is assigned to a specific layer according to its role and scope. The base layer includes services delivered with the FreeBSD base system and resides in /etc/rc.d. These services are maintained by the operating system and form the foundation on which everything else depends. The local layer includes services installed by the system administrator or vendor, usually from the ports collection or package repository, and are located in /usr/local/etc/rc.d. The user layer consists of session-specific services, owned and configured by the individual user, and stored in writable locations such as ~/.config/rc.d or ~/.rc.d. The init system, under this model, brings up each layer in sequence. The base services are initialised first, then local services, and finally user services. This order, it enforces trust boundaries. It ensures that core functionality is established before anything optional or user-scoped is allowed to execute. It makes the startup process not only more predictable, but also more defensible. To support this structure, each service would include a corresponding metadata file. This file, conventionally named service.rcmeta, is not a replacement for the shell script itself but a declarative descriptor of the service’s role, requirements, and constraints. It specifies the layer the service belongs to. It defines which user or group the service should run under. It indicates whether the service is one-shot or supervised, and under what conditions it should be started, such as on boot, on login, or in response to a network event. It includes startup and shutdown timeouts. It may require the service to run inside a jail, a chroot environment, or a sandbox. It declares whether the service is restartable or idempotent. It defines where logs should be written. It can also specify environment variables or dependency values to be injected at runtime. The purpose of this metadata is to allow the system to construct and validate a complete service graph before execution begins. It gives administrators the ability to verify dependencies and detect misconfigurations early. For package maintainers, it offers a portable and self-documenting way to describe service behaviour. For users, it provides safety and control without compromising the rest of the system. This structure also introduces meaningful improvements to system security. By clearly separating layers and responsibilities, the system can define and enforce trust boundaries. User services are unable to interfere with administrator-managed services. Local services cannot override or disrupt base system components. Each layer is constrained to its scope, which makes the system more resilient against misconfiguration and harder to compromise through privilege escalation. Metadata enforcement further strengthens this boundary. If a user-level service attempts to launch before its dependencies are met—for example, before the network stack is ready—it is deferred. If a local service depends on a daemon in the base layer, that dependency must be explicitly declared. Cyclical dependencies are detected and rejected at compile time. The service tree, it becomes deterministic. For desktop users, this structure enables a long-requested feature: reliable and supervised per-user services. Background processes such as encryption agents, file sync daemons, and session services can be declared and managed by the user without any need for elevated privileges. If a service crashes, it can be restarted. If it misbehaves, it can be isolated, killed, and logged. The configuration lives entirely in the user’s home directory. There is no need to modify global paths like /usr/local/etc to install or manage something that only one user needs. Support for graphical environments becomes smoother and more robust. Wayland compositors, notification daemons, user message buses, and related components can be started automatically, in correct order, with clean boundaries. It reduces friction during login, and it opens the door to more complete desktop session management. Administrators benefit as well. Services are consistent in structure and purpose. Startup semantics become understandable and predictable. Logs can be tied directly to service state. For vendors, the environment becomes safer to extend and easier to debug. For users, the system becomes more usable, more resilient, and more responsive to their needs. In this model, FreeBSD remains true to itself. It does not sacrifice its clarity or simplicity. Instead, it evolves with intention, refining the architecture where necessary while preserving the principles that define it. The system becomes structured rather than ad hoc, layered rather than flat, and secure without becoming restrictive. This direction builds on what FreeBSD has always done well, though it may reflect the priorities of someone approaching it from a laptop user's point of view. - Vic On Thu, Jul 31, 2025, at 10:24, Roger Marquis wrote: > On Thu, 31 Jul 2025, vimanuelt wrote: >> ... the current architectural assumptions underpinning FreeBSD?s package >> management model. The practice of overloading a single tool, namely pkg, to >> manage both the base system and third-party software introduces semantic >> ambiguity, violates long-standing UNIX separation-of-concerns principles, > > A single pkg command for both base and third-party packages would not be > a problem so much as a feature for 3 reasons: 1) it has a long track > record of working in Linux, 2) it facilitates 'distroless' and 'minimal' > base and jails which, like Linux containers, are much desired as they > reduce the attack surface and minimize pkg update overhead, and 3) yet > another package command would be confusing and create unnecessary > maintenance overhead. > > For those worried about recursive deletes, removing essential base > packages with a '-F' flag (force base too) and/or '-RR' (recurse base > too) could potentially limit unintentional dangerous actions. Either > way it would IMO be simpler and more intuitive if all pkg flags were > base-aware rather than requiring a different command with a slightly > different set of flags. > > Bottom line: FreeBSD's current inability to create a minimal base, much > less minimal jails, is a HUGE USABILITY GAP that makes the OS > problematic to spec in appliances and IoT much less jails. Facilitating > security updates and enabling minimal distributions are critical to > FreeBSD staying viable as an OS. I say this as a security analyst who > spends a large portion of every working day trying to help engineering > and operations patch tens of thousands of unnecessarily > vulnerability-ridden systems. > > Roger Marquis
