@lka1988 why systemd needs some extra compatibility? If it designed to work, it must just work, not requiring changing evertyhing around
mittorn
@Gork @nutbutter just look at /proc/1/maps on systemd-powered system :)
I do not see any reason keeping all of this in init. It might be implemented in optional lightweight services, not in single monster-binary
@MonkderVierte new ntfs driver sometimes might be unstable (usually chkufsd helps fix some errors)
Also there is fuse Paragon UFSD version (you may use ufsd binaries from paragon mounter on x86)
But ntfs-3g utilities sometimes cannot fix even trivial journal errors
@MonkderVierte @bluesheep ntfs? just use chkufsd binary from paragon mounter apk (there is static x86 binary in assets). And do not use ntfs-3g, it is slow and almost abadonned.
@gamer @DesertDwellingWeirdo
>discord
>desktop apps
/0
Also, packaging electron to flatpak sounds most stupid idea ever...
@InnerScientist This might be good behaviour (especially on shared multiuser system)
But how often you using shared multiuser systems in 2025? In 2015? In 2010 this might be useful, but now we are using containers instead.
When you have single root user, single unpriveleged user and few service users, such behaviour is just useless. If interactive user left some services running, it's usually intentional. And systemd requires notify about this intention every time. Why? It's just useless complexity.