Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

undeadly.org

Post reply on HN
Print view View original

51–60 of 79 posts

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#51

Post by j0057 »

rkangel wrote: post #13
Denvercoder9 wrote: post #12

Earlier quoted context omitted.

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…

systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.

Because it all lives in one repo, some distros make the choice of packaging all of systemd into one package, so that you can't choose to not install timesyncd or networkd.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#52

Post by gigatexal »

donmcronald wrote: post #36
IgorPartola wrote: post #14

Earlier quoted context omitted.

What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that. However, when you try to bo…

Ok that’s a bit much. Why is SystemD encroaching on the fstab??

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#53

Post by jcelerier »

gigatexal wrote: post #52
donmcronald wrote: post #36

Earlier quoted context omitted.

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that. However, when you try to bo…

Ok that’s a bit much. Why is SystemD encroaching on the fstab??

Because systemd services can depend on mount points or cause mountpoints to come up dynamically, in a way that pure fstab does not support, e.g. for containers. So (as far as I understand) fstab is now simply an input to the actual mount system.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#54

Post by pwdisswordfish8 »

Denvercoder9 wrote: post #12
throw0101a wrote: post #9

Earlier quoted context omitted.

> An old and somewhat crusty cross-platform daemon replaced by an OS-specific set of daemons, that takes care of managing /etc files that have been there forever. The older solution remains available, but may bitrot or otherwise become harder to maintain in the future. > Wait, isn't this what systemd is "accused" of doing all the time? Each of these do one thing and one thing only. The code is loosely coupled between…

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…

> On my Debian system it ships 50+ different binaries split across 8 different packages.

Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long as that's true, it's completely fair to call systemd a monolith, 50+ binaries or not.

In other words, this is a ‘only Microsoft employees may use the secret 7 on the dice’ situation.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#55

Post by bonzini »

j0057 wrote: post #51
rkangel wrote: post #13

Earlier quoted context omitted.

systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.

Because it all lives in one repo, some distros make the choice of packaging all of systemd into one package, so that you can't choose to not install timesyncd or networkd.

You can choose not to use them though. RHEL uses neither of those two, for example.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#57

Post by dfhsfgsdfhh »

pwdisswordfish8 wrote: post #54
Denvercoder9 wrote: post #12

Earlier quoted context omitted.

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled. > [..] > The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc. This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sha…

> On my Debian system it ships 50+ different binaries split across 8 different packages. Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long…

What's really relevant is market share. Guess what? Systemd is winning because it massively sucks less than what existed before it.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#58

Post by kasabali »

op00to wrote: post #23
tinus_hn wrote: post #6

Earlier quoted context omitted.

I didn’t see the part where it’s a take it or leave it proposition and there’s politics to force people into accepting one part which is then used to force them to accept an ever growing list of unrelated parts.

I didn’t see this with systemd either, so that’s good.

Which part of "gently pushing" didn't you see?

https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#59

Post by dale_glass »

cesarb wrote: post #46
thristian wrote: post #44

Earlier quoted context omitted.

I've heard a rumour that POSIX mandates that Perl be installed, although I haven't been able to substantiate it. POSIX-described Turing-complete interpreters include at leat the Bourne shell, awk, and sed, none of which you probably want to use for implementing a security policy. Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4), but that won't pacify anyone with an axe to grind about applications makin…

> Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4) Wow, that didn't age well. That document actually says Python "2.4.2 or greater" and Perl "5.8.8 or greater", which doesn't help if the installed interpreters are Python 3.10 and Perl 6.c (2018.06), since both are greater than the specified versions but incompatible with them. Even if it had specified the major release (that is, Python 2.x greater than…

Perl 6 isn't really a thing anymore.

Python3 requires some code changes, but on the whole is the same language.

Perl 6 was intended to be an upgrade from 5, but over time developed into a completely new language that shared stylistic similarities to Perl 5. Perl 6 can't be compatible with Perl 5 to any large extent because XS isn't a thing anymore, so any modules that had binary parts to them can't be easily ported.

These days Perl 6 got renamed to "Raku", to signify that it's its own, independent language.

The Perl 5 line continues to exist and apparently plans for the next major version to be Perl 7.

Re: dhcpleased(8) and resolvd(8) enabled in base, replacing dhclient(8)

#60

Post by Denvercoder9 »

donmcronald wrote: post #36
IgorPartola wrote: post #14

Earlier quoted context omitted.

What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switchin…

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that. However, when you try to bo…

> Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed.

That's indeed an unfortunate situation. systemd allows you to set the SYSTEMD_SULOGIN_FORCE environment variable for the rescue.service to override this behaviour and always give you a rootshell. It's an open bug for the Debian installer to set that variable by default if installing without a root password (#952450).

Post reply on HN