Jia Tan liked your comment
Without the traditional distribution workflow […]
You are aware that the xz exploit made it into Debian Testing and Fedora 40 despite the traditional distribution workflows? Distro maintainers are not a silver bullet when it comes to security. They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.
As someone who owns a PinePhone I can tell you that a lot more work needs to be done first. postmarketOS is ok but being Alpine based means you have to forever deal with all the issues that come with it including its primitive package manager. And mobian also kept breaking ever other half a year or so requiring manual config changes etc.
What we need IMO, is a more reliable spin like Fedora, maybe even something immutable like Silverblue to ensure the stability required for a daily driver device while also being quick to deploy the latest versions of releases.
There’s also the whole app ecosystem aspect but between advances in Waydroid and convergent GTK apps, I’m more concerned about the underlying base OS than the app ecosystem ^^
I wish something like .config would be a thing for storing configuration files in repositories. Instead we have a .vscode, .github, .gitlab, .idea, .vs, etc
Not to be that person but I’m curious what made you go with AppImage over Flatpak, given that you already mentioned using the Flatpak as an alternative ^^"
They already use GitHub for a bunch of other projects. See https://github.com/mozilla/ and https://github.com/mozilla-mobile/
The linked message is from 2019, i.e. per-M1 Apple laptops and at a time when arm in datacenter was just starting out.
Tbh, I feel like it’s kinda pointless to discuss a comment made by someone over 4-years ago. Both the environment and the person itself can change a lot in that time.
Or just use long-forms like
tar --create --file pics.tar ./pics
instead of
tar -cf pics.tar ./pics
or
tar --extract --file pics.tar```
instead of
tar -xf pics.tar
which is honestly way easier to remember... \^\^
So basically it’s just another GNOME release gotcha.
AFAIK, the extension developer needs to explicitly set each version of Gnome they support. Even when the Gnome version doesn’t have any breaking changes, the extension developer still needs to update their extension to enable their extension for the new Gnome version.
On that note, screen sharing worked just fine for me on Wayland Fedora 38 with Zoom Flatpak.
So far, Fedora has been rock solid for me ^^
I just really dislike the whole left/right tribalism. Politics is a lot more complex than left/right and just marking someone as either just increases polarisation…
As someone running a Framework 13 with Fedora 38 with 1.5 fractional scaling using Wayland I cannot say I experienced the same issue. Everything kinda just worked out of the box.
Personally I couldn’t go back from HiDPI screens. The lower resolution just makes stuff look blurry IMO.
Yup, this. Started update via Gnome Software, walked away from my laptop to make some coffee, restarted when I came back and it was done. ^^
Fedora has a KDE spin and gets some updates faster than even Arch (e.g. new Gnome releases) while also being considered stable. Heck even the the Asahi Linux project switched from Arch to Fedora as a base recently.
If you really need something from the AUR you can just use distrobox to generate an arch container and install the AUR package in there. You can then export it from distrobox to your application list with a single comment so that the fact that it’s running inside distrobox becomes completely transparent.
That way you have a stable but up-to-date base while also still having access to AUR.
That being said, in my 7 years on Linux I never needed something that was only accessible in AUR but maybe that’s just me ¯\_(ツ)_/¯
Been using the PoC extension for a few days now and I’m absolutely in love with it <3
Note that the people behind the Asahi don’t yet recommend getting a MacBook for the sole reason of running Asahi on it.
ngl, I’m annoyed whenever someone creates an application but doesn’t want to publish their code cause it looks bad. Like no one cares that your code is bad and by publishing it, you can get others to help you improve it.
This. And even then there should be procedures in place to essentially make it impossible to send the wrong inputs.
It’s like when an intern accidentally drops the production database. It’s not the interns fault for sending the wrong command. It’s the managements fault for not restricting access in the first place.
Also, you can just download an older version of the toolchain and use that to compile the project. If the project is properly setup it’ll tell you the toolchain version it used. If not you can probably guess by the time of the last commit ^^
Aren’t AppImages still limited to Xorg?
Also there’s no centralised update mechanism or dependency deduplication, no?