EDIT: I assumed there were also runtime configs based on the name "fallback."
My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.
EDIT: I assumed there were also runtime configs based on the name "fallback."
My question is primarily why you need compiled-in fallbacks, and secondarily why the fallback configs aren't pulled from config files.
https://www.freedesktop.org/software/systemd/man/systemd.net...
https://www.freedesktop.org/software/systemd/man/timesyncd.c...
So, in a few months to a few years, when systemd silently switches to DNS over HTTPS, what then? Maintain a (growing) blacklist of public DoH servers?
I'd much prefer my software to fail (and let me know), rather than assume some default someone, somewhere, somewhen thought a good idea.
To me this is more evidence that Systemd is really just "Poetteringd": whatever he feels like it should have, it has. Really disappointed that distros continue to use this software rather than start a community replacement that addresses its shortcomings.
If I re-did systemd, it would retain the same functionality, but not come enabled by default, and it'd be broken up into independent packages to be installed as needed. It would also use standard interfaces and do away with the binary formats, defer to existing system software rather than default to its own custom versions, de-complicate its awkward filesystem tree and simplify management of service configs, make the command-line interface more sane, and begin integrating more cloud-specific features to replace more complex cloud software (such as for service discovery, cluster management, and HA).
All these fixes would allow the "anti-systemd" crowd (of which I am a card-carrying member) to run a simple init system if they want, or extend it to the full range of systemd functionality. It would remove glaring pain points and user friction, embrace the existing system's default functionality (and backwards compatibility), and extend the software to be more useful in cluster environments. In addition, if this were maintained by the community, all distros could adopt it like they did systemd, and we don't have a half dozen different service systems like before.
Now please somebody reply and tell me why this is a terrible idea...
My theory is that the big distros are intentionally destroying forwards and backwards compatibility on the desktop as much as possible.
The more often window managers, desktop software, etc., stop working, the less their own teams have to compete with existing software. Wayland’s X11-as-a-second-class-citizen and gtk’s elimination of API stability are two other good examples of this.
Also, tearing down established standards is a great way to sabotage the various BSD’s out there.
What they don’t get is that sabotaging the rest of the community is undermining their own market share within Linux, even as it shrinks Linux’s market share.
I see this sentiment a lot and I don't get it. The developers I've talked to have been doing a lot of work to get XWayland working and to fix all the edge cases. And GTK has been API stable for years, the only thing that really seems to have broken was themes. And actually now GTK3 is feature complete and will not be receiving any more changes except bug fixes.
As far as init systems go, there seems to have never been any real standard and most distros always seem to have done their own thing. It does not seem like anything could be done there especially when a low level piece of software like this needs to use Linux- or BSD-specific APIs. It simply is not possible to have a portable standard there right now.
I have a humble request, please don't continue by promoting these unfounded theories and accusing people of sabotage. I personally would welcome a friendly fork of systemd to make some positive changes but it won't happen if people are doing it out of hostility. Many of the issues in the GP post have been brought up over the years. Upstream and the distros all have a stance on them and there is a reason why things are the way they are. It would be unwise to proceed without having substantial discussions with them to put resources where they are actually needed most. There was already a hostile fork that died because of not paying attention to this.
As Lennart says, asking your distro vendor to set defaults or just doing it on your own system is much better. This issue is just being upset on behalf of the people that don't mind or care and just want working infrastructure.