Live data from Hacker News

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

undeadly.org

61–70 of 79 posts

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

#61

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??

It's not encroaching on fstab, it's using it as input during boot, because mounting is intimately coupled with service ordering. Think about services that reside on a network filesystem: the network has to be up to mount the filesystem, but the network in turn can require arbitrary services to run, which can require other local filesystems to be mounted. You can't get configurations like these to work without coupling mounting and service ordering.

It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.

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

#62

Earlier quoted context omitted.

> 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.

No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity.

It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the dependencies using the new interfaces. Gentoo tries still with OpenRC, more or less successfully.

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

#63

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…

If you want your system to boot if a filesystem can't be mounted, use the longstanding nofail option on the noint point.

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

#64

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…

> What can I possibly gain by switching which DHCP client Yesterday I switched to systemd-networkd on debian to gain the feature of having the hostname be set via DHCP and not have to write a script myself. In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here. But for this feature I had to switch DHCP server and client. TBF it…

The Debian policykit packages have (frustratingly) diverted from upstream here. They do not pull in mozjs, sanding users with the older and far less flexible rules files.

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

#65
post #10

Earlier quoted context omitted.

But in the case of Linux distributions do they let the older solution remain available.

Sure they do, I run a few systems which use systemd with older dhcp daemons. And for example Raspbian uses systemd for process management, but completely disables its network parts, using their own solutions instead. One of the best parts of the systemd is how easy it is to disable/replace any part of it. The resolved and timesyncd are easy, but even things like journald have a mode when it keeps no files on disk, an…

TBH you still take the performance hit for journald doing all the lookups for each received message that populate all the fields of each message. In most cases you won't notice but I have seen some people complain that this extra processing can't be disabled.

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

#66

Earlier quoted context omitted.

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

No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity. It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the depend…

I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built for enterprise use cases, worked on people whose it's their full time job. It's because of the wider support that the majority of distros decided to go with them.

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

#67

Earlier quoted context omitted.

No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity. It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the depend…

I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built…

That is incorrect. https://news.ycombinator.com/item?id=23067431

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

#68
post #22

Earlier quoted context omitted.

> Yes, there's some code sharing between different components, but it's not a monolith. So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?

What part of “not a monolith” requires portability to other operating systems?

The use of stable, documented, orthogonal interfaces. That part.

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

#69
post #67

Earlier quoted context omitted.

I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built…

That is incorrect. https://news.ycombinator.com/item?id=23067431

Your own comment that you've linked here, which mentions Russ Allbery, has him quoted saying, "Most of those [systemd] components are clearly superior to anything we have available now on Linux platforms and will be used in the distribution going forward".

Then there's Fedora, which is upstream of Red Hat, who has many of it's contributors as Red Hat employees, so I don't see how it's odd that they would adopt software that Red Hat are invested in.

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

#70

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…

> What can I possibly gain by switching which DHCP client Yesterday I switched to systemd-networkd on debian to gain the feature of having the hostname be set via DHCP and not have to write a script myself. In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here. But for this feature I had to switch DHCP server and client. TBF it…

If you don't like it, try dhcpcd I which can set the hostname via DHCP by default.

On Linux there are no hard dependencies although your distro may enforce a udev dependency.

Post reply on HN