51–60 of 60 posts
Earlier quoted context omitted.
I believe it's the opposite. Compliment : positive quality. Complement : making a whole. ps: not native english speaker.
While your definitions are technically correct - GP is right. Complimentary means "free", complementary means "goes well with"
Earlier quoted context omitted.
I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.
Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
Ok, this has to have been one of the more interesting reads on what the complaints against systemd are. Ridiculously entertaining, to boot.
Because systemd was entirely too consistent across environments, so it needed some inconsistency introduced. The documentation reminds me a lot of Emacs's "ANTINEWS", listing all the functionality you lose by downgrading to the previous version of Emacs. Except in this case, it's actually a "NEWS" file, showing all the functionality you lose by downgrading from systemd to uselessd. > Certain superfluous unit types re…
ANTINEWS is the best kind of NEWS. And you don't just lose things, come on. Our recent support for running a system instance of systemd/uselessd without taking over init (as early and rudimentary as it still may be) is a good thing. Cross-libc is another. A couple of things from main.c were refactored into independent tools. This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wi…
Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality.
At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for example is a perfect example of a process monitor is easy to make lose track of the services it's supposed to monitor (I'm not trusting it again). Systemd's use of cgroups for this is for good reason: it's a hard problem to sort out.
You may end up with something usable, but a lot of the Systemd decisions are the ways they are because the alternatives were severely broken. And yes, that includes supervisord and monit.
E.g. here's an example from the Monit website:
check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
I've lost count of the number of times the Apache init scripts fails to bring Apache reliably up or down, for a variety of reasons, and the assumption that the pid-file will actually contain the pid of Apache or an invalid pid is fundamentally broken (the number of times I've found the pid-space has rolled over quickly enough to cause problems? Not huge, but far from zero), as is the assumption that there won't be other Apache processes in various unpleasant states whose pid is not in the pid file, but which will prevent a restart.
The problem is that Monit is fairly representative for process managers in this respect, most of which makes the (broken) assumption that the init scripts start, stop and restart actions will work reliably, and/or that the pid file contains sane content, and/or that you have a reliable way to kill a process based on holding onto a pid. I've yet to encounter a system where any of those assumptions are true, though you may need to scale up a bit before you start seeing enough of those failures to care.
So the suggestion of using something like monit or supervisord without addressing the amount of functionality you lose if you do makes me question if you understand the purpose of the pieces you are tearing out and/or whether you have put any thought into how users can regain that functionality without ending up making the same tradeoffs systemd does after all.
I'm all for getting something more modular than systemd, but ultimately I think few people will be well served by giving up on the substantial improvements systemd is bringing.
Earlier quoted context omitted.
ANTINEWS is the best kind of NEWS. And you don't just lose things, come on. Our recent support for running a system instance of systemd/uselessd without taking over init (as early and rudimentary as it still may be) is a good thing. Cross-libc is another. A couple of things from main.c were refactored into independent tools. This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wi…
> If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality. At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for ex…
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.
Earlier quoted context omitted.
The name is perfect and I do not see myself changing it. The fact that so many people misunderstand makes it better. The Linux Action Show thought we were calling systemd "useless" and went on a hilarious rant, there's people on LinuxQuestions.org who really insist that it's pronounced "use less dee" (I call it "uselessdee", as in it's of no use, personally).
So basically you're doing all this for the lulz of confusing and pissing off people and don't really want anyone to actually use the software?
And you're worried about somebody calling their own project "uselessd"?
Ok, this has to have been one of the more interesting reads on what the complaints against systemd are. Ridiculously entertaining, to boot.
Honestly, I feel the opposite -- I feel like this project acts as a far better rebuttal to some common misconceptions about systemd than Lennart's blog post about systemd myths. Why isn't systemd portable? You could read Lennart's explanation, or you could just look at all the things these guys had to rip out in order to get systemd to compile (and then not work) on non-Linux kernels.
Now, in my case, I happen to have furthered my distrust of systemd in the process. But that is secondary to just having learned more about what exactly is involved by looking at this.
Earlier quoted context omitted.
A truncated text log can still be informative, and I've never had a corrupted text log hang or crash my text editor.
That's because your text editor has had thousands of hours of work going into catching all of the edge cases. Things which have caused editors to hang or crash: 1. Binary data outside of the US-ASCII visible range 2. Malformed or creative Unicode combinations 3. Very long lines 4. Very many lines 5. Inconsistent line termination 6. Lines with patterns which trigger syntax highlighting, URL underlining, etc. 7. Embedd…
Earlier quoted context omitted.
That's because your text editor has had thousands of hours of work going into catching all of the edge cases. Things which have caused editors to hang or crash: 1. Binary data outside of the US-ASCII visible range 2. Malformed or creative Unicode combinations 3. Very long lines 4. Very many lines 5. Inconsistent line termination 6. Lines with patterns which trigger syntax highlighting, URL underlining, etc. 7. Embedd…
Yeah so let's just redo all those thousands of hours of work... for one specific format that has literally one use.