I wish Systemd-networkd had native PPPoE support.
https://github.com/systemd/systemd/issues/481
Still, systemd is just great and it has made my life a lot easier.
Systemd 250 Released
101–110 of 204 posts
Re: Systemd 250 Released
#102Earlier quoted context omitted.
As someone who has learned Linux/Unix just the past few months using a systemd based distro, I find it a breeze to use. Great documentation, FOSS, and really easy to pick up. I just don’t understand why there is so much dislike thrown around when that energy can be focused elsewhere on truly bad behavior/software. And from my understanding, there are distros out there that don’t use systemd for those who dislike it t…
Disclaimer: I _still_ like systemd. My only real big pet peeve with Systemd is the documentation is somewhat lacking..., like it's all there in the manual, but its laid out poorly and makes it hard to understand. The interaction between unit files and dependencies is also quite convoluted when you start digging into how things are ordered. There's a ton of unit file options that enable weird conditional behavior. The…
> The moment you need to start comprehending the difference between Wants vs. Requires and not hooking into running when multi-user.target is reached (the most common situation) you are in for a world of trial-by-error testing.
And the worst is that the tooling to test is very limited ( non-existent). I had a problem with conflicting/circular ndependencies ( my service had to be launched before networking but after dbus, which is just impossible because dbus needs networking itself), which worked 9 times out of 10. It was nearly impossible to debug, i had to use the graph tool that shows you visually how much time each service took to start, and completely by chance i noticed that dbus started after networking, which led me to look into it.
Re: Systemd 250 Released
#103Earlier quoted context omitted.
More like replace a working system with a more unreliable one with stability problems (and prioritize more features instead of fixing it) and more resource usage, then push for its adoption, then complain when you get hate. Now yes, it gives you more functionality, but it was a pain until it got there. Systemd was just Pulseaudio all over again (except now in init, so if it breaks your whole system can't boot). Now,…
There is no reason to be so dramatic. In the end you are free to use any init system you want.
> In the end you are free to use any init system you want.
Not really
Re: Systemd 250 Released
#104Earlier quoted context omitted.
You mean 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…
Cron has all these features: - single place control: crontab -e - additional constraints: systemctl status && scirpt.sh - randomize startup times: sleep ${RANDOM:0:MAX} && script.sh The nice thing is that it integrates with the existing infrastructure (shell scripts). This means you don't have to add code to cron to add features. I agree with the 10s of files in /etc/cron.daily, etc. But those are there for convenien…
There are some cool features in systemd that are not easy to do in cron.
Example: I use restic backup. One timer runs every 24h or on the next boot if there where more than 24h since the last backup as this is a laptop. Also it waits some random amount so that not all script run at the same time after boot. If a backup fails (eg remote server down) it retires every 15min, but no more than one hour before I get an Mail with a detailed report.
All really easy in systemd. No scripting required.
Re: Systemd 250 Released
#105SystemD 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 i…
I guess the use case is for when you want to migrate home to a different install. At the same time assuming you can't just adjust passwd to make uids work.
So I guess there is none.
Re: Systemd 250 Released
#106At 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.
Well the name System D implies a manifest destiny to conquer System V (i.e. UNIX) because D=500 and V=5 in Roman numerals. Why else would they choose the name? Also you should call it GNU/Systemd.
Or you could avoid silly conspiracy theories and think about a lot of different daemons that have "d" at the end, like httpd, crond, etc.
Re: Systemd 250 Released
#107Work 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.
As someone who has learned Linux/Unix just the past few months using a systemd based distro, I find it a breeze to use. Great documentation, FOSS, and really easy to pick up. I just don’t understand why there is so much dislike thrown around when that energy can be focused elsewhere on truly bad behavior/software. And from my understanding, there are distros out there that don’t use systemd for those who dislike it t…
Systemd by itself is alright, the problem for me is the larger movement from "Linux is about choice" to tightly integrated, opinionated tools. Examples:
- Gnome started to depend on systemd features. Now non-systemd systems become second class citizens.
- You used to be able to freely swap out window managers, taskbars, and so on, because everything was working with common standards. In the modern world, everything is integrated in your wayland compositor, and if you want to change the way window decorations look, you will also have to change everything else. Systemd is similar, it wants to take over so many responsibilities (task scheduling, DNS, session management), and if you want to swap out one part it is going to be difficult.
- Pulseaudio, NetworkManager, Polkit: Written in the same spirit, in part from the same people. Work great if everything works as expected, if they break it is a nightmare to figure out why. But code depends on them, so they become de facto standard on desktop linux.
Re: Systemd 250 Released
#108This 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.
You mean 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…
My favorite feature of systemd timers is that they get triggered when the time is set by NTP on boot. Combine that with a system without an rtc and a timer to reboot the system every week.
It just works.
Re: Systemd 250 Released
#109Earlier quoted context omitted.
It used to be process 1 was init, and it forked/exec'd everything else typically from /etc/rc (this elides over a lot) -its the first binary the kernel runs. Everything else stems from the birth of user process number 1. Fork/exec is the lightweight process inheriting of open i/o and memory state with copy-on-write which made Unix a joy to work with. It's a delightful mapping of kernel and userspace into complex inhe…
consistency ftw: https://news.ycombinator.com/item?id=29670751 gimme open-rc or gimme death actually, sysv was fine too open-rc solves the parallel-startup desire for people who want a faster boot and doesn't hide logs in binary formats which can only be interrogated with specialised tools - my primary reason for leaving Debian-based systems that I'd used for 16 years was having systemd forced on me and trying to dea…
My Debian came with rsyslog enabled by default which writes the journald logs to disk as plain text.