Thread

Systemd is a suite of basic building blocks

37 points · 65 comments · Bluestein

Loading the complete thread in the background. This saved snapshot is available now. Refresh

jauntywundrkind · 1789754952 · focus · HN ↗
This is just the homepage. Bah. I was hopeful this might be more! I would genuinely love for some posting on systemd that can actually talk to this.
There's posts on using systemd for this or that, which are fine, but it feels like the pro-systemd camp doesn't find or make opportunities to rally, to express ths vision, where-as the anti-vision (as ever) sells itself, is a magnet that makes common party out of all dissent.
1. graemep · 1789755241 · focus · HN ↗
  The vision is controversial so a lot of advocates find it easier to promote as an init system.
  It tends to be the anti-systemd people who keep saying its not just an init system.
  1. xyzzy_plugh · 1789755962 · focus · HN ↗
    It's not really controversial at this point, there's just a loud contingent of continuous complainers.
    Everyone I've ever worked with professionally is totally content with it.
2. McGlockenshire · 1789755338 · focus · HN ↗
  Yeah this is just a link to the branding page. I do appreciate the discussion of "system 500" at the bottom.
  But if you yank out the "brand" from the URL you'll get the actual site.
  1. jauntywundrkind · 1789756584 · focus · HN ↗
    Sure. These sites are fine rallying points, absolutely.
    But they are also very old, and there's very few efforts I've seen to pitch and promote systemd. It's found and enjoyed by a lot of people (particularly those who had to deal with the tangled haphazard sprawl of cobbled together systems from the before times), it makes nicely visible what is happening on the system, integrates cgroups and good least capabilities practices.
    But it feels to me like there ought be more ongoing and vocal celebration of this, enjoyment of this. More rallying points that trumpet the wins, that page people in to how nicely this helps. I want to see more positive tech advocacy, is what I'm saying. This is a fine site, yes, with lots of discussion. I've enjoyed decades of Lennart blog posts too. But I wish there was more. I wish this submission was a blog post of the same title. A fresh take, a fresh spin, on such a worthy-of-treatment topic.
3. mxuribe · 1789755438 · focus · HN ↗
  @jauntywundrkind I was about reply...but then @McGlockenshire said it best! Cut off the subdomain, and you'll get more info. ;-)
4. Bluestein · 1789756100 · focus · HN ↗
  - <a href="https://systemd.io/" rel="nofollow">https://systemd.io/ is full of documentation.-
  1. cyberax · 1789759122 · focus · HN ↗
    And it's crap. It still lists blog posts from 2012.
    There is NO good overall diagram of all the moving pieces in systemd.
    dTal · 1789828932 · focus · HN ↗
    Well, yes. Why would there be? It's a piece of software designed to turn all distros into Red Hat, and then sell consulting services to manage the untameable complexity. Legibility, composability, these would defeat the purpose.
5. wmf · 1789756771 · focus · HN ↗
  Every now and then there's a blog post or presentation that combines several systemd features to show how the result is a better overall system. The All Systems Go conference <a href="https://all-systems-go.io/" rel="nofollow">https://all-systems-go.io/ is a good place to learn about systemd.
6. nomel · 1789757206 · focus · HN ↗
  > pro-systemd camp doesn't find or make opportunities to rally
  I've never really seen this sort of parading in open source software. Do you have an example? I see it as competent people using things that they want to use, with the "better" being preferred, for whatever reasons (including momentum).
  1. jauntywundrkind · 1789759410 · focus · HN ↗
    Having everyone have to discover the pro/con's of every system themselves, in the dark, with no social media / blogging around it, seems like a very strange position to me.
    nomel · 1789768389 · focus · HN ↗
    You're arguing a point I never made. Experience can be shared without the intent to manipulate/persuade. A blog post/social media about experience of use is NOT a rally, and a rally is NOT required, and in fact makes a post suspect, because that's means the person is probably hiding negative aspects with their intent to promote, rather than technical "here's my experience".
    jauntywundrkind · 1789769693 · focus · HN ↗
    You're taking a slant on the rally, to turn a possible downside into something greviously fatal. That's not intrinsic in what I was talking about. We can have clear identifying gathering points, touchstones, blog posts, etc that call the cause without having to hide and conceal. This argument you are making is extremely uncharitable, and assumes bad motives from the start.
    nomel · 1790033507 · focus · HN ↗
    There's no shortage of information though. Have you actually looked at all? There are books, lectures [2], documentation [3], and countless personal pages.
    [1] <a href="https://www.youtube.com/watch?v=yxhJA2uRr_g" rel="nofollow">https://www.youtube.com/watch?v=yxhJA2uRr_g
    [2] <a href="https://opensource.com/downloads/pragmatic-guide-systemd-linux" rel="nofollow">https://opensource.com/downloads/pragmatic-guide-systemd-lin...
    [3] <a href="https://systemd.io" rel="nofollow">https://systemd.io
    [4] <a href="https://medium.com/@sebastiancarlos/systemds-nuts-and-bolts-0ae7995e45d3?sk=6ea38e345558472c76f0b6fd2366c9e5" rel="nofollow">https://medium.com/@sebastiancarlos/systemds-nuts-and-bolts-...
7. akerl_ · 1789757843 · focus · HN ↗
  Given that the overwhelming majority of Linux distros have moved to systemd, it's not clear why the pro-systemd camp would need to be finding or making opportunities to rally.
  They're spending their time build and improving systemd's set of building blocks.
  1. jauntywundrkind · 1789759660 · focus · HN ↗
    The drift, the gap between the advanced guard of seasoned enjoyers and the rest of the world that doesn't know what their missing feels like material that deserves coverage to me?
    Just stay heads down and keep doing the world, don't share, dont socialize has been the plan so far in a lot of open source. And I think the outcomes would be better if we tried methodologies other than this. Freaking weird that this is just accepted.
8. ares623 · 1789757870 · focus · HN ↗
  Do they need to? As an outsider, my view is that they already "won".
  1. jauntywundrkind · 1789761201 · focus · HN ↗
    Is your Civilization victory a Science, Military or Cultural one? I think that depends on how and if the technology is socialized and spoken of.
    If people feel like it's an oppressor, something they don't understand that has rolled in, and now defacto is (is shipped in every distribution of note): it feels like a Military victory. Over them. It sparks no joy.
    Appealing to the nerds can be a strong science victory. Preach all your amazingness. I personally can go on and on and on about how awesome it is that systemd offers workload isolation, least privileges, cgroups for juggling priorities. I love that mdns kind of just works for me, and integrates well with my resolver. There's little science-y reasons.
    But there lurk Two Cultures problems everywhere. And figuring out how to bridge the technical to the world, how to sing praises, how to get the world to be interested in relating to, engaging in, giving it the ability to share in some of your wonder and awe: that is what turns Science Victory into a Cultural Victory. And it's what good worthy interesting projects deserve. And it should be an act we do, and help build. We should make appeals to the world, try to get them interested in relating to the upsides, and the downsides to, to give them something worth engaging. I feel like the negative creeps have absolutely slammed their way to Two Cultures wins, to appealing to the world with negativity, and I think some more deliberate, caring, thoughtful work and blogging would make a huge difference in building cultural momentum, in sealing in what ought be a Cultural Victory. That those who know systemd reasonably well largley agree with already, but that many people do not see or understand.
    (Am I missing other victory types?)
    dTal · 1789830227 · focus · HN ↗
    > I personally can go on and on and on about how awesome it is that systemd offers workload isolation, least privileges, cgroups for juggling priorities. I love that mdns kind of just works for me, and integrates well with my resolver.
    So.... mDNS works out of the box on any glibc system with libnss-mdns and a running avahi-daemon - not "kind of" works, just Works. cgroups are a kernel feature that is quite straightforward to use without systemd. "Workload isolation" and "least privileges" are vague but seem to me to just be describing cgroups again, or just general permissions. I realize that this was an off the cuff remark, not a blog post in defense of systemd, but you must know that every time a systemd skeptic reads a list like this, full of "features" that work fine without it, the impression is only further reinforced that what systemd really provides is marketing.
    jauntywundrkind · 1789848932 · focus · HN ↗
    That you don't know what I'm talking about when I say least least privileges isn't stunning. Because almost no one took any precautions with how processes ran and only some people realize you should! Even though systemd makes it so so easy, and integrates many many different mechanisms and systems for locking down what procesess can do and what they have access to. SuSe has an ok page, but this is barely the tip of the iceberg they are covering. There are temporary users, sandboxed filesystems, all sorts of stuff more! <a href="https://documentation.suse.com/smart/security/html/systemd-securing/index.html" rel="nofollow">https://documentation.suse.com/smart/security/html/systemd-s...
    "cgroups are a kernel feature that is quite straightforward to use without systemd". Oh, you've used cgconfigparser? You run your services via cgexec? You found cgrulesengd to be pleasant and productionally operizationable? Or did you have a bash /etc/init.d/set-my-cgroups with 30 hardcoded lines of things twiddling /sys/fs/cgroups files? C'mon my man. No one did either of these! Or at least very very few! Today Cgroups work incredibly well, out of the box, with no thought, and have a very sensible coherent pattern of use, that benefit all Linux users. And which is incredibly tweakable. Since systemd. Because of systemd. You're not being remotely intellectually honest & your suggestion that this was "straightforward" maybe comes from you being a master sysop with decades of experience for who this came second nature, and if that's so I think you have no idea how most code ran. But I think you are just blowing smoke, making up nonsense.
    I too ran years of libnss-mdns and avahi-daemon (another Lennart project btw). It worked for a decade, was fine. I'm glad systemd-networkd (advertising) and systemd-resolved (finding) just integrate these concerns for me, alongside everything else they just integrate amazingly, a drop-in file like everything else if I want. It's easier to scope & keep on top of which networks I do what mdns on. This is the weakest win of these three but it's still to me a sigificant win.
    To reframe: I realize that this was an off the cuff take-down, not a blog post in aggression of systemd, but you must know that every time a systemd hater tries to throw salt like this, full of "do we really win" that no one ever did before, the impression is only further reinforced that what the haters really got is nothing.
    awss1i · 1789854852 · focus · HN ↗
    systemd makes it so so easy, and integrates many many different mechanisms and systems for locking down what procesess can do and what they have access to.
  2. nomel · 1789768817 · focus · HN ↗
    As someone that tried systemd init early on, without bias (I have no emotional attachment to how things start on my computer), it was incredibly clear that they would win.
9. egorfine · 1789760187 · focus · HN ↗
  > the pro-systemd camp doesn't find or make opportunities to rally
  Why would they? Their leader was always "I know better than you, now f off". This kind of approach doesn't need any rallying or evangelism at all.
mxuribe · 1789755373 · focus · HN ↗
This should be renamed to "Branding about..."...Because that seems to be the focus on this destination webpage...and not content specific to the underlying tech of systemd.
1. kyleee · 1789758926 · focus · HN ↗
  Yes a more accurate headline - systemd would like to be perceived as a suite of basic building blocks
0xbadcafebee · 1789756409 · focus · HN ↗
[delayed]
0xbadcafebee · 1789756915 · focus · HN ↗
"Building blocks" makes it sound like things you can use to build other things. In reality it's more of an octopus, or a fungus.
1. 9dev · 1789758787 · focus · HN ↗
  But that’s precisely what it allows you to do: plug a socket unit into a service unit, connect a timer unit, then another service as a dependency… and that’s just for the init management. Systemd might not fit your personal stylistic preferences, but most of all it’s consistent.
  1. Joker_vD · 1789760090 · focus · HN ↗
    Yeah, like what Upstart did! Why did we switch away from that, again?
    c-hendricks · 1789763445 · focus · HN ↗
    Didn't have timers for one, or the same level of support around sockets.
    the_why_of_y · 1789809364 · focus · HN ↗
    Because firstly, it had a broken architecture.
    <a href="https://bugs.launchpad.net/upstart/+bug/406397/comments/21" rel="nofollow">https://bugs.launchpad.net/upstart/+bug/406397/comments/21
    <a href="https://bugs.launchpad.net/upstart/+bug/447654/comments/6" rel="nofollow">https://bugs.launchpad.net/upstart/+bug/447654/comments/6
    Secondly, Canonical required a copyright assignment for any contribution to Upstart, and Lennart/Kay decided that if they basically have to substantially rewrite it to fix the broken architecture, they better do it in a new project with no copyright assignment barriers.
    See the comments in this thread by Upstart author and former Canonical employee Scott James Remnant:
    <a href="https://web.archive.org/web/20140928104327/https://plus.google.com/+KaySievers/posts/C3chC26khpq" rel="nofollow">https://web.archive.org/web/20140928104327/https://plus.goog...
    Had the CLA not been in place, the result of the LF Collab discussions would have almost certainly been contributions of patches from +Kay Sievers and Lennart (after all, we'd all worked together on things like udev, and got along) that would have fixed all those design issues, etc.
    But the CLA prevented them from doing that (I won't sign the CLA myself, which is one reason I don't contribute since leaving Canonical - so I hold no grudges here), so history happened differently. After our April 2010 meeting, Lennart went away and wrote systemd, which was released in July 2010 if memory serves.
  2. throw0101a · 1789774657 · focus · HN ↗
    > But that’s precisely what it allows you to do
    And if I don't want a building block like logind or journald, can I not use them? Can I take those blocks elsewhere, like over to FreeBSD and use them there?
    SystemD is not "building blocks" — which implies modularity — it is a monolith: components cannot be added or taken away or replaced. The best you can do is maybe run disable --now.
seany · 1789757209 · focus · HN ↗
We had reasonable building blocks before systemd...
1. IshKebab · 1789758572 · focus · HN ↗
  A bunch of barely working duck-taped Bash scripts? Hardly reasonable.
  1. hnlmorg · 1789759456 · focus · HN ↗
    You’d be surprised just how often systemd calls bash scripts.
  2. kjs3 · 1789761674 · focus · HN ↗
    You might have done barely working duck-taped Bash scripts; not eveyone who calls themself a 'system admin' is competent. But actual professionals who ran these systems since the 1970s had carefully written, fully functional scripts and we were quite capable of keeping hundreds and thousands of servers running just fine. Being bad at your job isn't the tools fault.
    IshKebab · 1789763415 · focus · HN ↗
    All Bash scripts are duck-taped by definition. It's a shitty duck-tape language.
    > thousands of servers running just fine
    Err yeah well you might have noticed these things called "laptops" and "desktops". SysVinit was... fine.. on servers. It worked badly on desktops and not really at all on laptops. I'm pretty sure the post introducing SystemD explained it all in detail if you want to learn something.
    hnlmorg · 1789816948 · focus · HN ↗
    Bash doesn’t just stop working because the x86 CPU is inside a different form factor. And actually Linux (and BSD too) did used to run on commodity desktop for local ISPs, newsgroups and so on and so forth. That was part of the reason for their success story: Linux and FreeBSD meant smaller Internet-facing business in the late 90s didn’t have to buy expensive mainframe hardware to run Unix software.
    The issue with Linux on the desktop, and especially the laptop, in the pre-systemd days wasn’t the init system. It was the lack of quality drivers.
    Now I’m not saying that systemd hasn’t brought improvements over sysv. But to say bash worked badly on laptops but fine on servers is just silly. That’s simply not how the technology works at all.
    And I don’t need to read some promotional piece from Redhat to know this. I’ve been running Linux on desktops and laptops longer than many adults have been alive. So I’ve lived through these massive ecosystem changes and have a first hand account of life before systemd.
    pocksuppet · 1790043924 · focus · HN ↗
    Actually yes, that's why they did stop working. Laptops regularly change hardware configuration. Desktops less so. Back when "local ISPs, newsgroups and so on and so forth" had desktops, they never changed hardware configuration while running.
  3. Woodi · 1789794867 · focus · HN ↗
    Total lack of understanding what is happening.
    There is difference between mandatory one implementation and set of funcionalities. Systemd is monolit with visible parts that provide somewhat modern funcionalities in nix world.
    And there is no serious developers in 'distro' space, except RedHat. And, really, there is no such thing RedHat we have in old Linux days - it was devoured and we just have a label doing corporate propaganda.
    So when few modern init systems were hatching RH dropped systemd and, as RH is main force in distros development, it gained dominance.
    And since then thing are getting worse.
    Eg. cgroups ? systemd first used them and so much hype happened. But is it deserved hype ? No! They implemented cgroups v1 when cgroups v2 was available. And cgroups v2 usage was blocked for years*. In systemd too.
    Do not make mistake of not seeing difference between good and modern functionalities and one codebase with funding that block real development.
2. rezonant · 1789759150 · focus · HN ↗
  I think we just have different ideas of what the word "reasonable" means.
  1. Joker_vD · 1789759997 · focus · HN ↗
    Upstart was reasonable. So is OpenRC.
  2. egorfine · 1789760226 · focus · HN ↗
    I don't think anyone seriously defends sysvinit.
    However upstart was totally reasonable.
    pocksuppet · 1790033250 · focus · HN ↗
    Nobody even uses sysvinit. When people say they use sysvinit, they actually mean a pile of ad-hoc shell scripts that have no relationship to sysvinit.
    egorfine · 1790197131 · focus · HN ↗
    Fair point.
  3. throw0101a · 1789773651 · focus · HN ↗
    > I think we just have different ideas of what the word "reasonable" means.
    I think we just have different ideas of what the term "building blocks" means.
    You cannot add (or remove) part of systemD as you wish somewhere else: on a Linux system I cannot replace journald with something, and I cannot bring journald over to FreeBSD.
    SystemD is tightly-coupled. Building blocks in my mind are like Legos: you can put together the thing you see on the box, but the individual (literal) blocks can be used however you wish.
    mkeedlinger · 1789783150 · focus · HN ↗
    This is the best point I’ve heard for this perspective.
    I guess I just never cared to actually LEGO much with Linux.
  4. seany · 1790020365 · focus · HN ↗
    an init system that is just an init system. _That's it_. Any other option is unreasonable.
tosti · 1789758236 · focus · HN ↗
I can recommend the book "Savaged by Systemd"
It's on AA
1. blipvert · 1789760954 · focus · HN ↗
  > It’s on AA
  Administrators Anonymous?
  Is that where the alt.sysadmin.recovery crowd go now?
  1. tosti · 1789763312 · focus · HN ↗
    <a href="https://annas-archive.gd/" rel="nofollow">https://annas-archive.gd/
2. cyberpunk · 1789761657 · focus · HN ↗
  I keep meaning to leave a copy of this around the office somewhere however i suspect it would trigger HR
badatnames · 1789758242 · focus · HN ↗
Where "basic" follows a highly nuanced alternate definition, where if you step out of line without realising it, you lose 3 days debugging a complex undocumented interaction between 4 enterprise crapware daemons only to find out the answer is "you're wrong and won't fix" buried in a 6 year old bug report, when all you did was plug in a USB mouse or try to set the default audio output device, or something else.
Total and utter propaganda, it's underdeveloped steaming garbage
1. ux266478 · 1789758313 · focus · HN ↗
  I think the problem is that it's overdeveloped rather than underdeveloped.
  1. badatnames · 1789758386 · focus · HN ↗
    You know it's underdeveloped because everything is described as "basic" or "simple". There's no such thing in any complex design, yet somehow for all his purported seniority, he keeps pumping out designs using the same description.
  2. 9dev · 1789758683 · focus · HN ↗
    The reason for seeing overcomplexity in systemd components is usually that you never considered the use cases of other people or proper server management - mostly because in the days of olde, everyone cobbled together their shell script Jenga towers in seclusion.
    kqgnkqgn · 1789759273 · focus · HN ↗
    If they don't have the problems that other people are having...maybe they don't need that complexity. Different use cases can use different solutions.
    An Army unit crossing rocky and muddy terrain might want tracked vehicles and tanks. I don't need that in a vehicle I drive 10 minutes to the office in the city.
    fragmede · 1789760349 · focus · HN ↗
    Analogies only go so far. Driving an actual tank with a cannon to the grocery store 10 minutes away is ludicrous, but my smartphone has gigabytes of both ram and storage and a CPU that runs at gigahertz frequency, but weighs about the same as a dumb phone that does far less. It's not the 1970's anymore. We can be inefficient and stop counting every single little bit where it doesn't count. Yes, where it counts, we still want to be efficient and mean and lean, like in transcoding, but for starting up services on a laptop with gobs of ram and CPU cycles to spare, the added expense of the tracked vehicle to the grocery store is what, an extra 100 milliseconds of loading data from nvme storage to RAM? Yeah, don't port kubernetes to a microcontroller. Focus on the interface you have with it and let the complexity just sit there, being harmless.
    zdragnar · 1789760646 · focus · HN ↗
    > Driving an actual tank with a cannon to the grocery store 10 minutes away is ludicrous
    And here's me thinking it would be a lot of fun...
    doubled112 · 1789762217 · focus · HN ↗
    I think it’d really help on the highway with traffic.
    I don’t need it all the time, but that doesn’t stop it from being useful.
    kjs3 · 1789760962 · focus · HN ↗
    This. I can see the utility of systemd and probably would have liked to have it when my team was riding herd on a DC full of Sun E15Ks and HP Superdomes. But for basically everything else that I use Linux for, every time someone says "systemd does this", at least 50% of the time I don't need that, and most of the rest I could do with with other tools with vastly less complexity.
    112233 · 1789762418 · focus · HN ↗
    Not "this". By that logic most people do not need backups too. Rebuilding working service state after config change is non-trivial, requires using admin-only kernel interfaces, and said kernel does not care about these types of problems. Meaning average user ends up simply rebooting rather than trying to figure why enabling wifi makes printer stop working (and such). We cannot have network stuff controlled by multiple programs, because linux kernel is broken like that. This thing is the userspace part of the monolith.
    kjs3 · 1789939653 · focus · HN ↗
    By that logic most people do not need backups too.
    You need to go back for remedial logic.
    jauntywundrkind · 1789766602 · focus · HN ↗
    Those jenga towers were terrible, many didn't work very well. Very few had good monitoring, ops, reliability, least-privleges.
    It's unbelievable to me to hear people advocating for not having good broadly usable systems, to advocate that sysadmins really should spent their time and energy building bespoke custom cut weird poorly invested in little things to suit their own fancies. It's not helping the company to do this. And to me it's such a weird antisocial vibe, that is radically vocal, that shows up all the time to proclaim everyone everyone else is doing the wrong thing by working together and making tools that fit together, have cohesion. Theres never any suggestions for how or what that looks like either, just the image of not working with others is the only thing presented to sell itself. This is din. This is havoc. This is hell. Don't do it people. And alas, we have to endure this attitude every single time. The forces against cooperation are doggedly persistent and vocal. The forces for just build your own thing, this unreasonableness, is radically overrepresented.
    This is why I was so hopeful this submission was going to be a nice new post kind of re-selling where we are today with systemd. Because the pro-social forces are weirdly not bothering to get the social / cultural victory. And those driving us apart telling us to each do our own thing, figure it all out yourself: they are endemic, dime a dozen on social media.
    ux266478 · 1789760656 · focus · HN ↗
    Actually I didn't say anything about overcomplexity and I wasn't thinking about systemd as an init system at all. I think that wild misinterpretation, which you knew to hedge with that "usually", is more or less the proof in the pudding frankly.
    throw0101a · 1789774218 · focus · HN ↗
    > The reason for seeing overcomplexity in systemd components is usually that you never considered the use cases of other people or proper server management
    What use cases of "proper server management" does fucking with my resolv.conf(5) solve?
    If I have a laptop I can perhaps consider updating value per DHCP or IPv6 RAs, but once I set up a server up why the hell is it a link to /run? (I once had to use chattr +i because of brain dead "cleverness".)
    In over thirty years of running Unix-y systems I never needed my resolv.conf "managed", so I have no idea why Ubuntu (for one) defaults to fiddling with it.
    9dev · 1789777360 · focus · HN ↗
    > What use cases of "proper server management" does fucking with my resolv.conf(5) solve?
    For one, it avoids telling all processes and their mothers the IP of the DNS resolvers they should query, but hands them 127.53 instead. If you then update your resolvers using systemd-resolved, for example because the network changes to a failover line, or because puppet pushes an updated catalog, or you want split DNS for a VPN (like, send *.corp.local to the internal DNS server or something), that is all pretty easy. There are more use cases on servers, but of course you most obviously benefit from this on laptops that roam between WIFIs with different upstream DNS server config.
    Woodi · 1789792831 · focus · HN ↗
    Just one thing: why that resolver work *need to be" in systemd package ? Why we can't have few implementations, as it always have been, that do different jobs, with overlapping funcionalities ? Why we ever need some gigantic codebase guarded by corporations that we can't easily replace ? Codebase that is uncooperative with other implemantations. And developers.
    And moust importantly: why they make everything more stupid and windows-like trash ?
    And I assure you: what you described as "easy" is not true. I is just few basic usecases they baked in. And when you neeed something a bit more specific in some direction you are not allowed to have that.
    Systemd is a trash, atm.
    throw0101a · 1789829173 · focus · HN ↗
    > For one, it avoids telling all processes and their mothers the IP of the DNS resolvers they should query, but hands them 127.53 instead.
    What "all process" are you referring to? What kind of software on Unix-y systems is not using gethostbyname(3) (or similiar)?
    (And the context of this sub-thread is "server management", which I'm not sure how often has VPN running on it and doing things like split (horizon) DNS.)
    pocksuppet · 1790043988 · focus · HN ↗
    You should install an actual local resolver for this, not systemd.
cyberax · 1789759666 · focus · HN ↗
Yeah, and these LEGO blocks are strewn around the room by a 3-year-old just waiting for you to step on them. It's the worst thing, there is no organization in systemd. No rhyme or reason to it.
The basic core service supervision in systemd is great. And nearly everything else around it is bad as a result: command-line utilities, filesystem mount handling, virtualization integration, network configuration, etc.
Just look at systemctl's `--help` if you don't believe me. Why does it have `service-log-level` to set the log level for the target, but not a way to actually _view_ the logs? Or why does it have a top-level `--firmware-setup` flag?
k310 · 1789836338 · focus · HN ↗
> systemd is a suite of basic building blocks
So was linux before systemd.
Choice is good.
<a href="https://linuxstans.com/best-linux-distros-without-systemd/" rel="nofollow">https://linuxstans.com/best-linux-distros-without-systemd/
<a href="https://www.without-systemd.org/wiki/index_php/Main_Page/" rel="nofollow">https://www.without-systemd.org/wiki/index_php/Main_Page/
<a href="https://without-systemd.org/wiki/index_php/Linux_distributions_without_systemd/" rel="nofollow">https://without-systemd.org/wiki/index_php/Linux_distributio...

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.