111–120 of 132 posts
Earlier quoted context omitted.
To what?
RunIt, say.
I'm not sure it's necessarily a better solution as it requires more manual interaction out of the box (namely creating symlinks by hand among other duties), but that might be argued as a feature. There appears to be a wrapper or two out there to automate away some of the tedium.
Earlier quoted context omitted.
> as a developer I just want something that works, has decent interfaces and abstracts away so I can care a lot less about it. As a sysadmin, I want something to be debuggable because I'm the one who gets paged when the failure rates increase.
On to microservices with you and give the developer the pager! Embrace the change :)
As a nice counterexample, OpenBSD doesn't have stuff like udev or dbus usage during boot. The rc.d system they use is literally just a bunch of scripts and is dead simple and reliable.
Ah, systemd. It's one of those things where I'm glad it exists, but I hate it. I'm glad it exists because more open source is good, and diversity of implementations is good. I hate it because it complicates my machine's startup process, and my life, unnecessarily, and puts a lot of shit in pid 1 that shouldn't be there. I don't want it to become a hard dependency of my entire software stack. (Same with PulseAudio, he…
I assume given context that Safari and IE are right out. Chromium and variants are probably out? If Firefox and variants are out (not sure if all of them have the pulse dependency, because honestly your comment was the first time I learned about it - probably because I'm using Arch), what's left? Qutebrowser? Konqueror?
I guess implicit in the above is an assumption of certain (non-basic) functionality that many people would consider table stakes in a web browser. Given that choosing to use any software involves making certain compromises (like "if you don't use Chrome, some Google applications will likely not perform as well") I guess my underlying desire is to know which compromises you are willing to make, given that you aren't willing to compromise your desire to keep pulseaudio off your machine in order to be able to use Firefox.
On a scale I'm having trouble naming but that goes from about 1 ("my son bought me this iPad so I can see my grandchildren on Facebook") to 10 ("I wget webpages to my server then email them to my Trisquel laptop") your pulse/firefox constraint seems to me to be solidly in the upper half, which I respect, but which also makes me expect you are willing to accept compromises that I'm not (yet) in choosing a browser. Maybe I'm wrong, though, because there's a lot of browsers on this chart: https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Ti...
Earlier quoted context omitted.
I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.
Sigh, this argument just has to come up in every discussion on Systemd. Anyone who dare to be critical about Systemd is apparently just a Luddite afraid of change. You know what, I have no problems with change at all, only when the change is to something worse.
I use systemd across distros, and am now confused when I run into an old SysV system.
When I'm sufficiently advanced to bump into one of these corner cases, it will be a Good Problem To Have.
The market penetration of systemd is about as good an empirical validation as can be had. How soon until it's codified in Posix?
Earlier quoted context omitted.
The problem is the Java generaton that never learned how to do it.
Somehow members of the JavaScript and Ruby generations pick up Rust rather easily, while those who pride themselves on having learned to write robust C (or C++) are flummoxed by it. Hypothesis: C is so pathologically bad that it breaks brains.
Earlier quoted context omitted.
I'd like something like systemd, but with all high-level internals written in a embedded scripting language.
init.d was nice, using shell scripts. readable, editable, clean, extendable. I liked that
Earlier quoted context omitted.
Poettering used alloca() as a poor man's garbage collector. Proper manual memory management is just "too hard". Other lingering code quality issues surely remain when the primary author is taking these sort of shortcuts and not considering how to write robust C.
As long as the allocation size is bounded (due to alloca/VLAs lacking any mechanism to signal allocation failure), what's the problem with that?
Earlier quoted context omitted.
I think ultimately a lot of the systemd hate is just fear of change and not wanting to give up an init system they are famiiliar with.
Sigh, this argument just has to come up in every discussion on Systemd. Anyone who dare to be critical about Systemd is apparently just a Luddite afraid of change. You know what, I have no problems with change at all, only when the change is to something worse.
I'll readily admit that systemd isn't perfect, but my overall experience is that it is better in many ways to its predecessors, and did solve real problems.
And when I referred to "systemd hate" I was not referring to healthy criticism, but to those who take very chance to claim that systemd never should have been invented and their init system of choice is clearly superior. Rather than, say trying to make systemd better, or make their init system fix the problems that systemd was designed to remedy.
