11 ms·
Systemd 250 Released
- sigmonsays 5y agominor issue, but anyone know how breaking changes are managed? between ubuntu16 and ubuntu20 some unit file parameters have changed. I find it rather troubling that we can't maintain consistency.
- p_l 5y agoThe approach was always "fuck you" and it's bigger part of "lennart hate" than people like to admit...
- rurban 5y ago> The static lease DHCP server logic in systemd-networkd may now serve IP addresses outside of the configured IP pool range for the server. See, see, taking lessons from C++. So someone requested a bug, and they got it. How could that be useful?
- electric_mayhem 5y agoSystemd is a matryoshka doll of bugs. How could that be useful?
- JoshTriplett 5y agoSuppose you have a network 192.168.0.0/24, with the router at 192.168.0.1, and you want the DHCP server to hand out dynamic addresses from 192.168.0.50 to 192.168.0.240 to clients, and hand out static IPs from 192.168.0.2 to 192.168.0.49 to specific identified devices via static leases. Those static IPs are outside the configured IP range for the DHCP server, intentionally.
- kuhsaft 5y agoI think there’s a misunderstanding. The [DHCPServer] section is tied to a [Network] unit. The [Network] unit has an address range. The [DHCPServer] section has options to reserve a range for dynamic leases. There is also [DHCPServerStaticLease] sections to assign static leases. However, previous versions of networkd did not allow the static lease to be outside of the [DHCPServer] dynamic range. Now, the static lease can be outside the dynamic range but within the network range. So, pretty much what any other standard DHCP server can do.
- iam-TJ 5y agoDHCP protocol actively avoids specifying a policy - that is for the system administrator. It defines three 'mechanisms' for allocation [0]: * automatic == permanent address * dynamic == finite (time-limited) and possibly re-assignable to a different client * manual == assigned by system administrator (and simply conveyed by DHCP) Static leases outside any 'pool' are "manual" allocations. [0] https://datatracker.ietf.org/doc/html/rfc2131#section-1 https://datatracker.ietf.org/doc/html/rfc2131#section-1
- davydm 5y agowait, hang on - the init process now incorporates a dhcp server? why? when there are existing solutions to that problem?
- sgaduuw 5y agono, it's not the init process, it's one of the tools in the systemd suite
- ChuckMcM 5y agoAt this point any system that is running this should not be called "UNIX derived" or "UNIX like" as systemd has subsumed all of the pre-existing architecture around system startup and management. Not arguing if that is a good or bad thing just saying we should stop putting systemd managed systems in the 'UNIX' column just like we don't put Windows NT systems in the UNIX column.
- tssva 5y agoShould macOS and Solaris also not be considered "UNIX derived" or "UNIX like" because of their use of launched and SMF?
- ddingus 5y agoAgreed, also no judgement here as well. I propose: "UNIX-ish" or Sysd type Linux. Shit, what am I thinking! GNU LINUX was the older discussion and development. SYSTEMD LINUX is likely most applicable nomenclature, given current development.
- traverseda 5y agoWell UNIX is "a pun on multics", so how about EUNICS? The S can stand for systemd.
- ddingus 5y agoLol I used to care a lot more. Frankly, what I do now is make sure I can use an OS and that I am depending on more portable software where I can. I find myself in Windows, OSX, and Linux land, maybe now I should just say Systemd Linux land and pretty much have something other than the OS to worry about. Ideally, the OS gives me few worries.
- deleted 5y ago[deleted]
- nightfly 5y agoSolaris's init/service/network management is/was just as complicated and it was definitely still UNIX.
- starklevnertz 5y agoI just want to pre-empt the inevitable bitching about systemd to say I think it’s awesome and incredibly useful and consistent and powerful and I’d take it any day over the mess of stuff that filled systemd’s duties before. Sure it isn’t perfect, but what software is? And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative?
- lmm 5y ago> And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative? Because it's tightly coupled to everything (particularly to the few profitable parts of linux - most open-source is maintained on a shoestring, so it's pretty cheap to take control over development of even vital low-level infrastructure). This is how systemd bypassed the bikeshedding problem of there being half a dozen replacement inits but no clear consensus, with the result that everything relied on a lowest common denominator. But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.
- 3np 5y ago> But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components. You can, though? And many distros do by default. Don’t like systemd-boot? You can replace it with grub. Don’t like systemd-networkd? You can replace it with networkctl. Want to use it but prefer to handle Wireguard tunnels with wg-quick? Fine! Don’t like systemd-resolved? You can replace it with dnsmasq. Don’t like systemd-cryptsetup? systemd won’t care if some other system takes care of your LUKS partitions. Etc, etc.
- fsflover 5y agohttps://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
- teleforce 5y agoThis week I have just learned that systemd has an alternative scheduler in addition to cron. At this rate systemd will probably become another new OS on top of Linux similar to Android.
- pmontra 5y agoYesterday I learned that it has its own alternative to NTP: systemd-timesyncd. Quite a big dose of NIH.
- cturner 5y agoSolving integration problems well is often harder than implementing functionality.
- pmontra 5y agoI second that but unfortunately they implemented only the basic functionality. I quote https://unix.stackexchange.com/a/464729 https://unix.stackexchange.com/a/464729 > systemd-timesyncd does no clock discipline: the clock is not trained or compensated, and internal clock drift over time is not reduced. It has rudimentary logic to adjust poll interval but without disciplining the host will end up with uneven time forever as systemd-timesyncd pushes or pulls at whatever interval it thinks the near-term drift requires. It also can't assess the quality of the remote time source. You're unlikely to get accuracy much greater than 100ms. This is sufficient for simple end user devices like laptops, but it could definitely cause problems for distributed systems that want greater time precision.
- 5e92cb50239222b 5y agoYou mean systemd timers? https://wiki.archlinux.org/title/Systemd/Timers https://wiki.archlinux.org/title/Systemd/Timers They were always there, and they work much better than cron in my experience (you're not forced to use cron expressions because it supports things like human-readable time formats; they can randomize startup times, which is useful for backups; they can put additional constraints (like "start only if network is available"); and they can actually be controlled from a single place (systemctl list-timers) instead of cron files that can be spread across multiple configs and directories in /etc/cron*, and pretty much every single user profile). It's a tiny slice of functionality and it makes a lot of sense to keep it in the service manager. Try harder next time.
- trabant00 5y agoWork hard and solve a big, complex set of problems. Solve them well. Offer the solution as free open source. Work some more to offer extra functionality and fix the bugs. Become the internet's villain. Come up with a commercial solution to a simple problem. Ex: file sharing or password management. Make it slow, insecure, privacy violating, lose people's data. Make millions, become a hero.
- aww_dang 5y agoYou make a valid observation. However I doubt that most Systemd haters are champions of commercial bloat. If I had to generalize, I'd assume that they dislike both.
- xpressvideoz 5y agoYeah, it's about whom to target. Open source overlords are hard to satisfy, to be honest.
- 0x0nyandesu 5y agoPersonally I use Gentoo with OpenRC. It's basically the opposite of bloat.
- bayindirh 5y agoHalf of systemd's problems are coming from human aspects rather than technical. I'm too tired to write them all over again, but here's a rundown, from me. - https://news.ycombinator.com/item?id=25611149 https://news.ycombinator.com/item?id=25611149 - https://news.ycombinator.com/item?id=27651567 https://news.ycombinator.com/item?id=27651567
- theteapot 5y agosystemd is a cuckoo bird that found the perfect nest, init. Not-a-hero.
- bayindirh 5y ago> Become the internet's villain. This is not about the problems systemd solves, but how they solve them and how they act while solving them.
- nyanpasu64 5y ago> systemd-homed now makes use of UID mapped mounts for the home areas. If the kernel and used file system support it, files are now internally owned by the "nobody" user (i.e. the user typically used for indicating "this ownership is not mapped"), and dynamically mapped to the UID used locally on the system via the UID mapping mount logic of recent kernels. This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary. I wish it was possible to pull a hard drive from one Linux system, and plug it into another, and mount the ext4/etc. partitions in a "removable" mode which ignores permissions and mismatched UIDs, and grants full access to the files without needing to be root.
- LeoPanthera 5y agoYou can set an ACL on the appropriate mount point to grant all users in an arbitrary group rwX permissions.
- dschuetz 5y agoIf homed makes it into the major distributions I'm done with mainstream Linux.
- Mikhail_K 5y agoI use Devuan, systemd-free fork of Debian, no complaints so far.
- sgaduuw 5y agogenuine question: what's so bad about homed to jump ship? can't you just disable it and not look back?
- dschuetz 5y agoWhat do you mean "jump ship"? There are plenty of Linux distributions that still let you choose. Genuine question though: why didn't Lennart and his gang just fork some Linux distribution for their ideas? Why invade everywhere else instead? Anybody ask them that?
- arianvanp 5y agoBeing able to seal credentials for services like TLS keys to your TPM is extremely dope. I welcome this feature a lot.
- 3np 5y agosystemd-networkd will now automatically configure routes to addresses specified in AllowedIPs=. This feature can be controlled via RouteTable= and RouteMetric= settings in [WireGuard] or [WireGuardPeer] sections. Wow, that’s a pretty significant breaking change that I’m surprised to see (and one I don’t really agree with; there was reasoning behind not doing that in the first place). This is going to bite most users already using the WG functionality if they don’t realize when upgrading. I really hope apt will notify users about this when upgrading. sd-boot gained the ability to change screen resolution during boot-time, by hitting the "r" key. This will cycle through available resolutions and save the last selection. Neat! Overall I learned to stop worrying and love the systemd, especially systemd-networkd. The maintainers can be impressively responsive in acknowledging and fixing reported issues.
- dschuetz 5y agoReading this the following comes to mind: Wow systemd breaks important things and solves non-problems, awesome, I love systemd!
- 3np 5y agoHonestly, moving my VPN management from wg-quick+ip-route+iptables to systemd-networkd was a great experience and made things so much easier and predictable. Wish I had done it way sooner. Similarly, after having spent way too much time fiddling with IP and routing in other ways (OpenWRT comes to mind), systemd-networkd made it so much more predictable and straight-forward. Similar story with other components. Having to read the release notes before upgrading to a new major version is a price I’m willing to pay.
- p_l 5y agoNow if only there was a way to reliably test networkd setups... Sincerely, someone who lost a week or two trying to get anywhere with a bit more complex setup and ended up going back to /etc/interfaces because it had a "show what commands will be run" option
- asymmetric 5y ago
- gorgoiler 5y agoSystemD has something of a reputation for being a bunch of arrogant young engineers making fundamental changes to the long established status quo in order to solve clever problems that range from tiny-minority-edge-case to non-existent. It’s an absolute classic anti-pattern any industry veteran would recognise. Your new-grad engineer, top of their class and incredibly smart, spends two weeks rewriting a core system in Idris without telling anyone. So accordingly, I was delighted to see the following: > [files in] systemd-homed home areas are now internally owned by the "nobody" user and dynamically mapped to the UID used locally. > This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary. All that to save a chown -R if I screw my drive into a new PC (or rebuild the current PC around it)? If I move it to a non systemD system, you’ve just added the need to chown -R all my files because the new OS says they are all owned by nobody. I don’t even believe for one moment that a recursive chown of 100k files takes any appreciable amount of time. Certainly not when it’s a one off. (5s for 66k files on my crappy VPS just now.) In any case, the nobody user is a blunt but useful instrument for running daemons as a user that does not own any files. I don’t really want some janky daemon to run as a user which has write access to /home/gorgoiler. [I have some guacamole prepared, to spread on my inedible but soon to be eaten hat, the moment someone links me to a diff showing the author of this change as Alan Cox.] [Update: The hat and condiment survive, author is one L Poettering: https://github.com/systemd/systemd/commit/cf5115f6e531c65bbb5b78c8 https://github.com/systemd/systemd/commit/cf5115f6e531c65bbb...
- fsh 5y agosystemd-homed is not intended for your single-user desktop. Don't use it.
- traverseda 5y agoWhat is it intended for? Certainly not large scale user groups backed by an LDAP server, as those would have consistent uid/gid so setting everything to be owned by nobody wouldn't make sense technically... What is the use case?
- 5y ago
- gigel82 5y agoI'm curious if it's still falling back to Google DNS / NTP if not otherwise configured. That was a very bad choice even though I understand it'll only kick in under unusual circumstances.
- bitwize 5y agoCongratulations to the systemd team. I still won't use systemd, and to the extent of my ability I will fight the trend of the Linux ecosystem hard-depending on it. But it's a bit silly to be anything but grateful for open source and choice.
- esarbe 5y agoI applaud your ability to simultaneously dislike systemd and acknowledge the achievements of it's developers without the need to vilify them.
- sgaduuw 5y agoI recently switched from Ubuntu to FreeBSD, and systemd-networkd is what I miss the most. Network settings in /etc/rc.conf totally feel like a bandaid on a bandaid on a bandaid.
- scottlamb 5y agoThis release should have my small fix for a pet peeve: if any local filesystem failed to fsck, the system used to go into emergency mode even if the fsck entry was marked "nofail" or "noauto". It contradicted intuition and documentation. It came up rarely but was frustrating to have the system broken until you were physically there, even if you tried to avoid this exact behavior. Now the system boots anyway, just as it would if the filesystem was entirely missing.
- oliwarner 5y agoI'm a Log4Shell survivor and I'm finding it hard to see them packing more and more features into this monolith. It'll probably be fine, but I'll be Jack's complete lack of surprise when I'm taping servers back together after a DNS exploit gives some kids root access.
- revanx_ 5y agoI wish Systemd-networkd had native PPPoE support. https://github.com/systemd/systemd/issues/481 https://github.com/systemd/systemd/issues/481 Still, systemd is just great and it has made my life a lot easier.
- egberts1 5y agoStill no default-deny option in systemd.
- unixsheikh 5y agoI cannot believe how big of a monstrosity systemd has become. It started out as an init system and was promoted as such and I started out liking it. Then the wording suddenly changed to "a suite of basic building blocks for a Linux system", then came the hardcoded DNS servers, then the shitload of bugs that has been ignored since about 2015. Now instead of fixing what's broken and making things more secure, more and more cruft keeps getting added. > We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option. (Doug McIlroy). Sigh!