No, Fedora is semi-rolling with less random freezes. Regular Ubuntu is similar but just not Ubuntu please.
Fedora also had 13 months of support so staying on the older version gives an extra stability.
And then there is OpenSUSE slowroll, which is CI/CD with more testing
Fedora Atomic has no liveUSB
Yes I think you mentioned the relevant points here. Ubuntu tests their preinstalled software, while there is tons more in the repos that is not as tested. Same with Mint.
And they backport only stuff they think is necessary. For example Plasma 5 is based on the EOL Qt5 and backporting things to Plasma 5 is nearly impossible as you need real Plasma devs and nobody really wants to do that.
Plasma 6 is really stable, 6.1 not so much, but the timing was not perfect. Simply because they do their release schedule as fixed as that.
It is a total pain if you simply want working software, as they may backport some stuff, but all the stuff not preinstalled, or that is very complex, will not get fixes.
This is the same with all stable distros, if the maintainers dont literally maintain all the software there is.
And way more reliability, even though it is pretty modified.
It is randomly frozen as not all developers follow Ubuntus release schedule. They just release when it is ready.
Stability means backporting tons of bugfixes to tons of small packages and libraries. I dont think Ubuntu does that for enough packages, best example Plasma 5.27 on Kubuntu. I have reported over 200 bugs I guess and most of the newer ones are just fixed in Plasma 6.
Flatpak for sure is a good way, and if a distro is stable, they should only install Flatpaks.
Plasma 6?
Well maybe dont use buggy firmware then?
#coreboot #heads #dasharo
Stable is not equivalent to “works well”. It is randomly frozen at some point, mostly not in contact with upstream devs, so you just have outdated packages.
OpenSUSE slowroll sounds like a way better model. Or maybe CentOS stream.
Plasma 6?
Interesting on what distro and when did you try that?
I didnt know that it relied on XWayland but that seems outdated anyways
Very nice, thanks for the links.
Where do the sandboxing profiles come from? I suppose from the aisap repo?
Laughing in kwin-wayland
Very interesting project. Cage is a wayland kiosk, right?
But what about doing system updates and stuff like shutting down? KOReader doesnt have such an interface
I share the exact same experience with you.
I use the ublue kinoite-main base image, not one of their very opinionated variants. It is best as a base, better than Fedoras (even though you need to trust Github 100%)
config creep is solved only partly. I am currently overhauling the kind-of guide here
Local stuff in your home is persistent, and /etc is also persistent.
But we are working on that.
Bazzite has a ton of WINE stuff on the system, not really the “immutable small core” principle. At the same time they uninstall Firefox, while Flatpak Firefox does not support all things.
So I recommend to install Fedora Kinoite from the official website and follow the rebase guideline here at the bottom
~/Applications
is no a random place, it comes from macos.
Hahaha I would call that VERY random. It is problematic that the default xdg directories are hidden.
And I just learned that you can just source scripts into bash and thus being executable or not doesnt matter. What an incredible design flaw… at least this just works with some binaries, I guess?
You mean appimagetool
No the Flatpak Appimage Pool. But a solution to easily package a bunch of files sounds really awesome. I miss that for RPMs, sddm2rpm did this kind of.
appman
Very interesting tool. So this is for appimages but also binaries?
I am a bit confused, especially as they state to prefer official releases, which for me means tarballs.
But a very good concept.
Interesting set of apps you have there. And ironically I have to agree they are small. Flatpak libraries are too huge and the deduplication doesnt work if it us not used for downloads and if there are dozens of runtimes.
A modular approach would be very much needed, instead of a damn KDE runtime that is nearly the entire desktop.
But I have some questions.
Yes that’s aisap sandbox
Thats not a sandbox, its a nice wrapper for firejail, at least what they write. I only knew some Github issue where they discussed this, and because Appimages require fuse they couldnt be sandboxed with bubblewrap.
Then they say “bubblewrap is used in Flatpak” but no comment if THEY also use it.
Firejail is the setuid binary I talked about, they likely have fixed their security issues but bubblewrap/bubblejail are probably better as they dont need setuid binaries.
If Appimages are possible to sandbox with bubblewrap, that would for sure be cool.
I also found rustysnakes crabjail, dont know the state it is in, but that is a possible candidate for replacing bubblejail.
right now its biggest limitation is that a sandboxed appimage can’t launch another sandboxed appimage.
No idea if Flatpaks can do that. But I would say the biggest issue is that the big vendors just put their appimage on some file server without any data on the sandbox.
Flatpak is way better here, where the sandbox is checked BEFORE apps are successfully submitted. And there are warnings etc.
And, of course, every app is sandboxed, not just a few.
those menus rely on desktop entries in
$XDG_DATA_HOME/Applications
.
Not the “create new” to my knowledge. That is in $XDG_TEMPLATES_DIR
but I am currently struggling to make Flatpaks use that.
AppImage is just a format, same as a deb or rpm
Yes, so is Flatpak. But Appimages were introduced to be Windows-like. Sure there are companies that dont care and publish random rpms on their website too.
But with Appimages that is the only way as there is no real repo. AppMan is a cludge here, bundling together tons of different sources, kind of like Obtainium.
That tool is either completely finished or kind of abandoned.
Interesting, didnt know they have a signature builtin. That would also be useful.
That zsync2 thing explained in AppMan was just like delta updates. If a malicious actor has access to the old appimage and the fileserver, they can produce the correct zsync2 thing and the updates work, until signature verification is enforced.
I like to keep all the software that I need in my home, because that way I don’t depend on what my distro provides.
As I said, as long as bash script.sh
works with nonexecutable stuff, noexec home is pretty worthless. Just another layer of defence.
You mean the APK itself does the signature verification or what?
No, android APKs are like Distro packages, they can be sideloaded however you want and then are forwarded to the “session installer” (on modern android), which is the “package manager” of android.
That installer saves the signature somewhere, and from then on you can only update the APK if the signature was made with the same private key.
Found out you can also not sign APKs, which happened here. I honestly dont know if more developers dont sign their APKs.
I will update my repo text to get to the current state of facts.
Ubuntu is not following mainstream anymore, which is a bad thing. They are the only ones pushing snaps, while every other distro prefers Flatpaks. Their store is closed off and problematic, and the sandboxing only works on distros using AppArmor.
So they are pushing basically new Ubuntu repos, and just dont stop.
Also they theme GNOME apps like hell, have a strange appstore nobody needs (GNOME Software can handle packagekit, flatpak and snaps).
They ALSO now highly push Flutter instead of GTK for whatever reason, which brings inconsistencies, and flutter is nearly abandoned by Google.
get around the 3-5 people
What people?
Nonexecutable home directories I mean. /tmp too. This only makes sense as normally programs are in different areas. I will experiment with that.
Really nice that he used Victorias graphic
It is semi-rolling. They ship different point releases and kernels within a release