I dont think home directory files should handled by something named tmpfiles.
The only reason its still called tmpfiles is because of backwards compatibility
I dont think home directory files should handled by something named tmpfiles.
The only reason its still called tmpfiles is because of backwards compatibility
There were talks a few years ago about changing sd-tmpfiles name but it was decide not worth it due to the churn and bikeshedding it would cause.
sd-tmpfiles is generally used to create, modify (e.g. permissions) and remove directories on the system. The home.conf is intended for systems that only ship /usr/ (e.g. containers) to create /home/ and /srv/ as a separate subvolume on btrfs
This is a proposal by people funded by companies that would provide the services for this (https://balkaninsight.com/2023/09/25/who-benefits-inside-the-eus-fight-over-scanning-for-child-sex-content ).
A lot of actual politicians oppose this https://tbbacherle.eu/2024/06/18/open-letter/
The BSOD really isn’t something to be mad at, it actually in theory is good but there is only so much you can do when a kernel panics. What you should be mad at is shitty drivers causing BSODs
which definitely seems out of scope.
Doesn’t seem out of scope for a system and service management suite. Like, the timeperiod where systemd was “just an init” was relativly brief (like half a year).
The case is: You switched to it before it was “old-old-stable” and haven’t updated.
Causes for this are likely:
(I think that’s their goal, either ads or no watch)
They should test this much more often and frequently. Unlike Gnome, KDE do actually care about their users, not just about themselves.
It’s not like GNOME is the only outlier here (for the specific icon problem sure), someone on the linux subreddid also posted this screenshot https://imgur.com/a/1ELtsJb. It seems to really just be that KDE apps kinda struggle out side of KDE. And most of the GNOME devs do care about the users as well, just they also care that their apps look as intended.
It’s been a thing I personally have been wondering why this is how it is for a while. Personally I like most of the GNOME stuff, but this decision has always stood out as odd.
But then again I almost always use ctrl+w or alt-f4 to close apps, so I am mostly unaffected.
Sometimes (almost always) I wish that the refunded money wouldn’t come out of Steams/Valves pocket…
Fun fact: open source has a definition: https://opensource.org/osd
I don’t know much about Grayjay, but how you are describing it, it at best is “source open”
doas
is relativly simple (a few hundred LOC), especially compared to sudo
. The main benefit of run0
over doas
is that it isn’t a SUID binary, they are similary complex.
But the funny thing is that even with a larger user base, Spotify has NEVER posted a profit
I honestly doubt if you’d isolate Apple Music it’d be any different for them.
Lossless is pointless
I wouldn’t say its pointless, but it really doesn’t help much considering the quality of your average headset/earpieces.
It’s incredibly easy to fuck your partitions to hell and back, especially through Windows.
Fun fact: Windows won’t allow you to delete any EFI partition (that is the only one I know of/tried) unless its through diskpart
with a specific override/force option.
But then again, I somehow nuked my recovery partition by accident at some point as well.
bless the drive with a boot loader that doesn’t suck, like Grub
Ah yes, I need a whole separate OS just to boot my actual OS…
I would in no world call GRUB a bootloader that doesn’t suck.
Basically. systemd-run
was already able to do it, all that really changed is the interface for it. The change to run.c
in the patch itself was <400LOC, and the entire patch was <1.4k lines with most being docs, tests and utils for coloring the terminal.
I don’t understand how this is any improvement over pkexec
That has the same problem as sudo
: the SUID bit is set for it.
The fact that run0
uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status
, but systemctl reboot
needs to be in the wheel
group) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.
I dunno, I don’t have a camera feed into your life. But considering that is the first thing you respond to a clarification it most certainly wouldn’t surprise me if you did.