>Not in the systemd sense of putting its fingers into everything.
It is unclear what this "putting its fingers" actually means besides "implementing features that other projects then want to use". Is openssl "putting its fingers" into everything because everyone uses it to implement TLS?
>In other words, your claim that I cannot make an init that doesn't take over the machine is false.
No I don't think so. I cannot really see what you are gaining from this. I have also made simple inits like this back when I was a student. Usually a project is successful because of its features, not because of its absence of them. How is this any different from using the supervision system as the init? It sounds like you are making a PID1 that spawns one other process as PID2 and then that process takes over the system. So really, from the point of view of a sysadmin running this system, both PID1 and PID2 are the same and they both assume control of the system, because killing either one of them will take down the system.
>They may be separate processes, but if something refuses to run without systemd as init, then it is part of systemd, and systemd has subsumed those daemons.
No it has not. As I said before you can just implement backwards compatibility with systemd in your init, and then those daemons can run again. It is not like this is even hard to do this, you can see exactly what APIs it depends on. Those other daemons may not require much more than one or two API calls. You are confusing "subsuming" with "having a dependency", and of course looking at it that way makes it seem a lot less dramatic because nearly all open source packages have dependencies.
>Actually, you're wrong. As I implied above, init should be something close to Rich Felker's minimal init, and the supervision system should be separate.
No, I'm not wrong. As I suggested above, separating it provides no benefit.
>That's not to say that they can't share code, but sharing code can be done through libraries, including the fork()/exec() dance.
I don't see any benefit there either, the libraries are not so useful to any other code. All this code must be able to run as root inside the service manager. Usually you will not have any other code that runs at this privilege level. That's what I mean by "take over the machine", by necessity the service manager must have the highest privilege level and this is part of the design of the OS. You can't change it without changing the kernel.
>Also, I've written an async-signal-safe fork()/exec() dance. It's not hard. It just requires reading the manpages.
I'd say it's more like that it's tedious. The more things you want to set up in there, the more you have to be very careful about how you do it.
>Yes, he did. He used politics to get distros, not users, to adopt systemd by fiat, the same way someone might use politics to get a state legislature to pass a law by fiat.
No he did not, this is incredibly rude to those distros and it suggests that those distros did not have any agency to make this choice. They chose themselves to adopt it because it was good and it made their lives easier. There was no "politics" to push them into it. The reason users cannot make this choice is because the init system and service manager is primarily something that needs to get set up by the distro. The distro is the one who ships all the services and writes the service files, users are not expected to do that. The distro maintainer is actually the primary user of this type of software so what they say goes, it is pointless to ask the users for an opinion on this. Maybe looking at it from that point of view will help you with your own init.
>Sure, you can move to a different state, and you can move to a different distro, which is what I had to do! That's not really a lot of choice.
That is plenty of choice. The users don't decide anything anyway and they never did. That's why they choose the distro, because they trust the distro to make the correct decision for them. Users that don't will do like you and leave for another distro, or create their own, which has been done countless times in the history of Linux distros. If no one did this there would only one Linux distro, but there are currently hundreds for you to choose from and a lot of them don't use systemd. I don't know how much more "friction" you need here or why this is not adequate, everything that you need has been given to you but you're still saying it's not enough. You have even starting making your own init system! If what you say about "choice" was true, you would not even be able to do that.
>What I am going to do instead is to present my init/supervision system and let users adopt it as they may. As users adopt it, distros might be willing to add it as an option.
This is exactly what Lennart did, and also what Scott Remnant did when he created upstart, and what DJB did when he created daemon tools...
>They should only be promoted insofar as they solve problems that people have
Systemd did actually solve a lot of problems the distros had.
>but it is a better thing to make a judgment about whether Ur is a good solution for each individual I come across
This does not scale beyond a very small number of users. I hope you can see that it would be impossible to develop something like the Linux kernel this way.
>comments from users, who you so disdainfully call "the peanut gallery."
I don't mean all users. By "peanut gallery" I am actually referring to people who don't use your software and who decided they don't like it. They are not your target audience, don't worry about them. You will not win over every potential user and that's to be expected.
>You're the one giving me "hate" right now.
Actually no, I have been trying to give you tips on how to promote your work and succeed, based on my own experience. Sorry if it came across poorly, that's on me. Maybe my tips are useful and maybe they are not.
>Yes, systemd can run sysvinit scripts, but that's because sysvinit scripts are not run by systemd, they are run by the sysvinit interpreter.
In the same way, you can just make a systemd interpreter. I think some other service managers do actually have that.
>systemd's declarative format is completely broken and hobbled. Its various types of dependencies are confusing. Implementation concerns are exposed to the user in various places.
After learning how to use it, I cannot say I share the same opinion, but you do you.
>No, I want a clean break from systemd, and I'm willing to have few users of Ur to have it.
But this is the tradeoff you have made personally. You can decide to support systemd, it's more work but you get more users. You can decide not to do that, it's less work and gives you some flexibility but it's risky. That is a choice you have made yourself to not be compatible with systemd, based on your own intelligence, it is not systemd somehow manipulating "politics" to make you do that or not do that.
>However, I do not know who you are, an account created 2-3 days ago, just as these stories about Poettering started coming out. This is slightly suspicious, so could you tell me who you are to lay that to rest?
No, I am sorry. I don't use my real name on here because I have been harassed online before, and this account is new because I lost my old one. I am even more cautious when discussing systemd because I have seen a lot of hateful messages about it, and the systemd developers have actually received death threats before just because someone was mad at them for developing systemd. In case you're getting any ideas: I am not Lennart, I have never worked with Lennart, I am not a systemd developer, I am not a Red Hat employee or a Microsoft employee.