Replied in thread
Administered by:
#systemd
7 posts6 participants2 posts today
Replied in thread
Learn how 
systemd-lsp is designed to simplify the editing of #systemd Unit files by providing validation, autocompletion, and formatting features commonly available for modern languages and file formats.
GitHubGitHub - JFryy/systemd-lsp: a language server implementation for systemd unit files made in rust 🦀a language server implementation for systemd unit files made in rust 🦀 - JFryy/systemd-lsp
Replied in thread
the #wayland vs X drama is like living the whole #systemd shenanigans again.
#opensource has changed a lot over the years, in so many ways. yet in others, it never did, and never does. 
Replied in thread
@CursedSilicon @gettie mostly because #systemD (and it's competitiors) took all the right lessions:
- Start less
- Start more in parallel
- Resolve dependencies to avoid waiting times
And basically everyone (#OpenRC, #Upstart, etc. Even #LaunchD [the #init for #macOS that is literally the SystemD but before SystemD and by Apple] and #SMF [#Sun's SystemD for #Solaris] did that to allow for boot times in secinds, not minutes…
Replied in thread
@CursedSilicon @gettie Eeyupp!
Same as with #SystemD: Shit's more dynamic and we can't sell people systems with #SysVinit startup speeds in the minutes like in 2007.
https://www.youtube.com/watch?v=o_AIw9bGogo
Noone would've started either project if the preceding solutions were "fine". Cuz they weren't!
Replied in thread
@CursedSilicon @tilton and whilst at it, get gnomewithoutsystemd.org and forward it to that post subheading saying "Consider using #systemD"...
https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/
#UnpopularOpinion / #HotTake: I think it's the right call for @gnome to "Stop being a mad scientist" and simply offload a lot of [quite security-critical] stuff onto #SystemD.
- After all both are being bankrolled mostly by the big 3 #Linux distros and neither #RedHat nor #Suse nor #Canonical are willing to spend money on essentially redundant work if they can avoid it...
Tho @BrodieOnLinux is wrong re: "Linux is #Unix" because technically #macOS (if we take in any #POSIX-esque system into account)!
Actually don't give a flying fuck about #X11 vs. #Wayland. I guess I'll be sad if I install Linux on a machine and the software I want to use doesn't work. But, I suppose other people will want to continue to use software, so maybe that will get worked out. Also don't fucking care about #Systemd. It's convenient for managing services for me, a very uneducated, reluctant, amateur sysadmin. But I get that people are upset and I see you.
Every time I see someone express dismay about systemd eating the world of system management, I keep thinking to myself "I have three Raspberry Pis in my house, and they each have their own way to set DNS servers." #systemd #unix #standards
Replied in thread
Also shoutout to this entiled POS that decided to vomit his unwanted hatemail into the mentions before being the biggest coward I've seen since Ro!
- DO YOU THINK I'M A COMPLETE IDIOT, DIPSHIT?
Your cowardice is a disgrace for the fediverse and yet another piece of evidence that all the clichees of #SystemDhaters & #WaylandHaters are not exaggerated but true!
- What an asshole...
Replied in thread
@mrmasterkeyboard @cesarpose I mean, #Xorg - like #SysVinit - both have severe issues that just ain't gonna be addressable under reasonable expectations re: hardware support, compatibility and software support.
- But there's a reason "Big Distros" and the community in general came to the conclusion that #Wayland and #SystemD are at worst 'necessary evils' and for the most part deliver a lot of quality-of-life features.
https://www.youtube.com/watch?v=o_AIw9bGogo
There is no "#conspiracy" of #BigTech wanting to kill #X11 or even sabotage #Xlibre for that matter. It's just that some folks have trouble letting go and acknowledge that #Xserver is kept on "life support" as #Xwayland so people can run their 25+ year old #Windows games in #Wine without going apeshit.
- I mean, ask @fuchsiii about that effort, where she's basically "workarounding" wine devs by literally pulling a "#Steam compatibility layer" kind of trick and swapping "good known working" Wine versions in just before launching a game because that works for setups where you have one user playing one game at a time on one machine and where shuffling around files/symlinks is possible.
Replied in thread
@mrmasterkeyboard sounds like some folks who don't want to admit #Xorg is dead and #Wayland is the way to move forward.
- Kinda like folks stubbornly opposing #SystemD for no good reason.
Insecure defaults can lead to surprises. When creating FIFO sockets with systemd, be sure to note that SocketMode defaults to 0666 - that is world readable and writable. That is: any local user can communicate with the FIFO. If your FIFO is used to perform privileged operations you must ensure that either the FIFO file itself is located in secured location or set SocketMode to stricter value.
I spotted one such insecure use in cloud-init: the hotplug FIFO was world writable. This is CVE-2024-11584 and fixed in cloud-init 25.1.3.
The commit fixing this is in https://github.com/canonical/cloud-init/pull/6265
GitHubSync security by blackboxsw · Pull Request #6265 · canonical/cloud-init
Replied in thread
@BoydStephenSmithJr @dvandal @david_chisnall @strlcat
This reasoning is based upon a fallacious dichotomy. In the real history, Upstart existed and had a strong competing maintainership, to the level that the #Debian TC itself was nearly split down the middle on #RedHat/#Canonical lines, and the choice was *never* between van Smoorenburg init+rc and systemd.
It was between #Upstart and #systemd, the latter indeed being a reaction to the former, with #OpenRC as a late entrant.
Continued thread
2/2
offizielle Version übernehmen will...
Die beiden Wege die ich gefunden habe um den #dnsmasq Aufruf durch #NetworkManager zu übernehmen sind auch Mist, weil sie beide keine Distro-Updates überleben wenn dnsmasq ein Update erfährt...
Jetzt habe ich aber doch noch ne Idee die "vollautomatisch" (reboot überleben) laufen sollte... dann wäre ich aber von #systemd abhängig...
Und das ist mir jetzt egal...
Das schlimmste von meinem Wechsel von Artix auf Devuan ist, dass ich jeden Tag mehrfach mein System updaten will und es einfach keine Aktualisierungen gibt.
For those who specialize in DHCPv6 and systemd: Is there a way to tell the DHCPv6 server "If this IP is available, just give me it, don't give me anything else", or at least get systemd to do that? I'm trying to make an oracle cloud instance running Arch+systemd-networkd that uses DHCPv6 for IP configuration only use one of two IPs assigned to the oracle instance, but leave the other one unused so I can do NDP proxying and route it to my laptop over wireguard, giving my laptop a public IPv6 address as a result, but it appears that oracle is forcing my VPS to use both IPv6 addresses, which is not what I want.
Redacted logs, for context:
Jun 18 06:08:27 somewhere systemd-networkd[-1]: eth0: DHCPv6 address 2000::4201/128 (valid for 1d 5
9min 59s, preferred for 23h 59min 59s)
Jun 18 06:08:27 somewhere systemd-networkd[-1]: eth0: DHCPv6 address 2000::1337/128 (valid for 1d 5
9min 59s, preferred for 23h 59min 59s)
Feel free to boost this for increased visibility if you wish, and if you know of any mailing lists or IRC channels I should ask on, please let me know.
Relevant tags to try to help people who might know something see this:
#dhcp #ipv6 #systemd #oracle #dhcpv6 #networking #systemdnetworkd #systemd-networkd