Laptop, kind of a must have because of University. I preferred Gnome as it was a mature DE I could’ve left untouched theoretically. Although that was not the case :D
One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.
Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.
If you really don’t want to even be encouraged to touch the command line but do everything through a graphical software store (that’ll be gnome software) while still having access to everything you need, one of these two is currently the way to go. I just came across this older article comparing them, and it seems for the new user openSUSE Aeon (micro os, formerly) wins out in minimal fiddling.
I feel sorry for those small, understaffed, enterprises that had to scramble to get off CentOS 8, and may now be in the same situation with Alma/Rocky 8. IBM/Redhat have really fucked over potential customers. What a great advert to ensure no-one buys your product.
If IBM actually cared, they could have still gone down this route. But they could have let CentOS 8 run it's initial, promised, support cycle, then switch exclusively to CentOS stream. And continue to provide the source for the entire run of RHEL 9.
To be fair, the transfer from Cebtos8 to Alma couldn't have been easier. Just ran a script to update the RPM sources and a dnf update and we were done.
Moving to a different distro with different package managers and filesystem layout is a whole other level of hurt.
That is true, however, some companies would still want weeks/months of testing the transition in non production environments first with detailed write ups and sign offs before any work can be done. The script may be easy, but the bureaucracy in some of these companies is also yet another level of hurt.
I'm in the same boot. Wrapping up my first week of dual booting (for me it's KDE via Debian 12).
With Firefox, I encountered the same issue. After adjusting the resolution scaling, it is back to normal/expected, so give that a shot if your distro allows it.
One can only hope. I think it is better if the developers that care about clean UI and workflows were to focus on Ubuntu Budgie or maybe even Budgie 11 or entirely new DE altogether. But as far as modern feeling and clean UI design I really do think Budgie 10.5.x is an overlooked gem of a DE.
It is fine to be opinionated, but I always found the.. opinions I guess by the people over at elementary to be rude, condescending and not really in the interest of its actual users. I think if that weren't the case though there'd be tons more people volunteering to make it one of the most popular and best distros around.
Neon - essentially Ubuntu with the latest KDE Plasma on top. Not only does it give you the "ready to play" base that is Ubuntu, it had "discover", a very easy to use front end for package managers that lets you do exactly what you're asking for there in that last sentence.
It is disingenuous to simply state that people think new = bad. There are definitely both advantages and disadvantages to the current containerized packaging platforms / formats at the moment. Some of which, some people may see as greater positives, negatives than others.
There are a few obvious security implications with the rise of containerized packaging. One of the first is the move away from true centralized, least trust packaging. With traditional packages, you are trusting your distro maintainer (be it Debian, Canonical, RedHat, Arch, SUSE, etc.) To provide patched versions of software from their trusted repository mirrors to your computer. This does a few things like limiting the amount of places that you need to download software binaries from, as well as having other potential benefits like checksum validation on downloaded packages.
Most containerized package platforms including Docker, Snap, Flatpak tend to have a centralized set of repository mirrors, but anyone may compile and publish their own software to it. Flatpak is kind of the exception to this. Some distros (i.e. Fedora) publish their own sets of repos with flatpak packages. This is because Flatpak allows for more than one source repo for packages. I do believe Docker, Podman allow for the same as well. Snap infamously doesn't allow any repos other than Canonical's proprietary community repo.
Most of these containerized packages solutions also offer varying levels of sandboxing, which is a good set of security features that could benefit individual hosts from potentially vulnerable software. One could argue that flatpaking Firefox or other browsers and jailing them to limited capabilities and filesystem access is a good thing given the potential for malware propagation through such applications.
In particular though, most containerized solutions aren't generally hated by online user communities except Snap, which has both been among the most restrictive as well as furthest behind in features, performance parity, and general user experience. Snap was for the longest time significantly far behind Flatpak for user land applications and still wouldn't be my first choice for server applications compared to Podman or Docker due to just not being nearly as flexible as the other two.
The performance of the platforms can vary compared to native. For the desktop-oriented platforms (Snap, Flatpak) they generally perform insignificantly different from native packages, although Snap packages that are built compressed have had horrific IO performance for the loading of package files (leading to atrociously slow startup times of applications in the past). This is supposedly better now, though I have no intention of installing Snapd to find out.
As a note for culture, people particularly also dislike Snap because of how badly Ubuntu (Canonical's Linux distro) is depending on it, including having Snap automatically reinstall after removal and dropping many packages from apt only to throw redirects in to pull the snap package when requested from apt. This is why de-snapped derivatives of Ubuntu are also popular.
As for package sizes, they tend to be a bit bigger than native, as well as the added cost of a second set of libraries. Many users online don't get the 'why' when their first package from Flatpak is nearly a 3 GiB download, despite the following packages will hardly be any different in size from native packages. In a way, these packaging solutions do remove an advantage of the singular set of libraries. If you use netbooks, SBCs, IoT devices, or other similar minimal storage devices, you might feel this impact. However most systems will only have a marginal increase of storage utilization overall from a second set of libraries being installed.
I’ll add my 2 cents to your very well written comment.
My biggest gripe with flatpaks notably, is the more difficult integration into the system. I use about a dozen flatpaks, and for every single one I had to tinker with flatseal to give them the correct access permissions, that I had to research online. One specific flatpak coulnd’t even work with those additional permissions. Half of those flatlaks also will not follow my system theme and their GUI looks broken or out of place.
Given my limited usage of system themes to one that has flatpak packages (Materia) and tendency to go through the permissions of new flatpaks and tighten them anyway, those are good points to mention. For theming, it is definitely a trouble point depending on the platform and theme used. Especially when combining Qt5/Qt6 apps, Fltk, GTK2,3+, and GTK4 applications together, things may get even more messy than consistent theming on native applications. Having comprehensive theme packages for the theme you use almost completely resolves this problem. Though I doubt predefined customization isn't something that will be popular with some users given that ricing your Linux desktop to the extreme is a huge selling point of the Linux desktop for many.
I did forget about how especially with Flatpak and Snap how there is no actual guarantee that the default sandboxing permissions will actually be any good or even usable on many applications, which is an issue that partially comes from when community maintainers end up publishing packages for developers rather than developers or dedicated platform testers publish a given package (a common practice for many applications on the Flathub repository).
Half of those flatlaks also will not follow my system theme and their GUI looks broken or out of place.
This always struck me as weird: the entire point of flatpak is to be isolated and not integrate into your system, why would you expect it to integrate with your theme?
I know they try anyway, but it just seems like a conceptual problem to me. They want to solve packaging by pretending it doesn't exist.
I don't like it when a project's website only says "here, run this Docker container" and doesn't have manual setup instructions. I don't want to just run a black box Docker container, I want to know what the knobs are and what they do.
Ha - I actually have Windows (WinToGo) dual booting with Ubuntu Budgie on the same usb stick - plus a non-encrypted ntfs partition. The OS partitions are encrypted though given that is portable. Working out the LUKS details and boot partitions was difficult however as there is a serious lack of good information on how to do it successfully.
Why should the GUI application be a system package? Why shouldn't we have the good permission system that Android has? Why is the distro packaging every piece of software out there a good thing? Why is a couple of packages using more space a big deal to you?
I never can understand those people who are just against the idea of flatpaks. On the other hand, I can see why you'd be against it for the state in which it is right now.
Annnnd we are back at square one. flatpak is just another distro, with the limitations of a distro. You are basically asking for a unique distro to rule them all.
That's not what I am asking about; fragmentation is another separate problem. What I am asking is why would you be against the idea of flatpak, if you use snaps, then you're with the idea of flatpak (to some extent).
Linux
Oldest