had an option to disable the activity BS on startup and go straight to the desktop.
But oh well, the GNOME team is more occupied with censoring comments on their blog and trying to re-invent the desktop environment experience with animations and whatnot instead of focusing on what really delivers productivity.
you’re using it wrong. ™
activity should be treated as the “default” mode of gnome (also you need to go to it do launch anything anyway)
also desktop icons suck
Desktop icons have no benefit for me and would look ugly. Opening in the desktop would mean that I would have to press super before launching all my apps, which would be annoying.
Because it takes manpower to develop and maintain these features?
Especially desktop icons are difficult to get right (see workarounds like “ReIcon” on Windows). E. g. keeping icon positions across multiple monitors and varying resolutions and displays (which can be unplugged at any time). They can also be a privacy-issue, e. g. when doing a presentation.
But most importantly: GNOME doesn’t want to be a traditional (Windows-like) desktop, so why would they implement features that don’t align with their ideas for a desktop experience?
There are lots of other desktops, like Cinnamon, that offer a traditional desktop experience within the GTK ecosystem. There is also plenty of room for desktops, like GNOME, that have a different philosophy and feature set.
In my opinion it would be boring, if every desktop tried to do the same thing. And there wouldn’t be any innovation, if no one tried to do things differently.
Innovation or regression? Gnome used to have optional desktop icons. They removed them. Let’s settle on gnome is progressing, while keeping in mind, that progress is neither necessarily nor inherently good.
Innovation doesn’t necessarily mean that all past functionality needs to be carried over. Actually innovation often means that past technology becomes obsolete and gets replaced with something new.
Gnome used to have optional desktop icons. They removed them.
They removed them because with GNOME Shell those icons no longer made sense. There was no longer a concept of dragging apps from a panel menu to a desktop, instead apps were now pinned from the fullscreen app overview to the dash.
Since the code was no longer used by the default GNOME experience, it became unmaintained and eventually got removed.
Especially desktop icons are difficult to get right
This doesn’t just affect desktop icons, icons in general suck under Linux. Things have strange behaviors when selected, long names don’t work properly etc.
But most importantly: GNOME doesn’t want to be a traditional (Windows-like) desktop, so why would they implement features that don’t align with their ideas for a desktop experience?
Because GNOME is the only DE with some potential and by not having 2 or 3 simple optional features aren’t getting more traction. I bet half of the KDE users would be glad to use GNOME only if it had desktop icons. Using other DE doesn’t make much sense as you’ll inevitable run in GTK and parts of GNOME and having to mix and match to get a working desktop experience.
Again, GNOME had icons, v3.28 discontinued them for no other purpose than trying to re-inveting something that worked for a ton of people.
Because GNOME is the only DE with some potential and by not having 2 or 3 simple optional features aren’t getting more traction.
But everyone has different requirements and my “2 or 3 simple optional features” that are missing are completely different than what you think is missing. I couldn’t care less about desktop icons or system trays. I even prefer not having a system tray, as this functionality should be provided via notifications and regular application shortcuts in my opinion.
But in the end, a software project only has a limited amount of resources available and developers have to decide where they want to focus on. GNOME chose not to focus on desktop icons:
GNOME had icons, v3.28 discontinued them
Because the code was “old and unmaintained” and probably no one was willing to modernise and maintain it. Desktop icons were already disabled by default before 3.28, so they didn’t “re-invent” this feature with the removal of the code in Nautilus.
Using other DE doesn’t make much sense as you’ll inevitable run in GTK and parts of GNOME and having to mix and match to get a working desktop experience.
I use GNOME and KDE and use the same applications (as Flatpaks) on both desktops: I use GNOME Calculator on KDE, because I dislike both KDE calculators, and I use Ark on GNOME with a Nautilus script, as File Roller doesn’t allow me to set the compression ratio (I need to create zip files with 0 compression for modding games). So for me it has become the norm to mix applications created with different toolkits. Thanks to Flatpak I still have a “clean” base system though.
Btw. I am getting tired of these re-occurring complaints that GNOME works differently than other desktops. I am not constantly complaining about what features KDE is, in my opinion, missing all the time either (e. g. dynamic workspaces, same wallpaper and desktop configuration across all existing and new monitors, online account integration, command line config tool, etc.), instead I accept that this is how it is at the moment and either use KDE the way it is (like I do on my desktop PC) or use something that better suits my needs (like I do on all my laptops).
Since GNOME disabled desktop icons years ago, I liked it so much that I disable them in every OS I use, even on Windows.
They are just ugly and make the whole system feel messy. I do t need that. I can use the search or a favourites thing in a hidden drawer like the start menu or the gnome dock.
I get understand wanting desktop icons even though I don’t like them personally, but what’s the advantage of starting at the desktop instead of the overview? It seems like you would probably want to open an application when you log in so it seems more convenient to already be in the overview
Indian here. There are a lot of Indians that love tech experimentation and “jugaad”, and just the mere act of dailying Linux allows us to step up our IT industry game for zero cost.
In general, consider setting up any kind of rollback functionality; this will enable you to get right back to action without any downtime when you’re time-restricted. This can be achieved by configuring your system with (GRUB-)Btrfs+TImeshift/Snapper. Please bear in mind that it’s likely that you have to come back to solve it eventually, though*. (Perhaps it’s worth thinking about what can be done to ensure that you don’t end up with a broken system in the first place. cough‘immutable’distrocough)
If you feel absolutely overwhelmed by the amount of choice, then you should probably consider the bold ones; not because I think they’re necessarily better but:
openSUSE’s offerings are generally speaking very polished, therefore being highly suitable to replace Linux Mint or Ubuntu. It’s its own thing though, therefore you might not be able to access packages that are exclusively found in Debian’s/Ubuntu’s repos (though Distrobox solves that trivially). Tumbleweed if you like rolling release, Slowroll if you prefer updates only once every 1-2 months and finally Leap if you lean more towards Stable/LTS releases.
siduction for being based on Debian; but it’s strictly on the Unstable(/Sid) branch.
SpiralLinux for being based on Debian; this one -however- has proper support for switching branches.
Vanilla OS for being based on Debian; this one is very ambitious. But, because it’s an ‘immutable’ distro, it might require the biggest changes to your workflow.
nvidia drivers are absent
While any of the aforementioned distros do a decent job at ‘supporting’ Nvidia, perhaps you might be best off with uBlue’s Nvidia images. As these are images relying on the same technology that Fedora’s immutable distros do, rollback functionality and all the other good stuff we’ve come to love -like automatic upgrades in the background- are present as well. In case you’re interested to know how these actually provide improved Nvidia support:
“We’ve slipstreamed the Nvidia drivers right onto the operating system image. Steps that once took place on your local laptop are now done in a continuous integration system in GitHub. Once they are complete, the system stamps out an image which then makes its way to your PC.
No more building drivers on your laptop, dealing with signing, akmods, third party repo conflicts, or any of that. We’ve fully automated it so that if there’s an issue, we fix it in GitHub, for everyone.
But it’s not just installation and configuration: We provide Nvidia driver versions 525, 520, and 470 for each of these. You can atomically switch between any of these, so if your driver worked perfectly on a certain day and you find a regression you just rebase to that image.
Or switch to another desktop entirely.
No other desktop Linux does this, and we’re just getting started.”
It’s often used to describe a distro in which (at least some) parts of the system are read-only on runtime. Furthermore, features like atomicity (i.e. an upgrade either happens or doesn’t; no in-between state), reproducibility^[1]^ and improved security against certain types of attacks are its associated benefits that can (mostly) only exist due to said ‘immutability’. This allows higher degree of stability and (finally) rollback-functionality, which are functionalities that are often associated with ‘immutability’ but aren’t inherently/necessarily tied to it; as other means to gain these do exist.
The reason why I’ve been careful with the term “immutable” (which literally is a fancy word for “unchanging”), is because the term doesn’t quite apply to what the distros offer (most of these aren’t actually unchanging in absolute sense) and because people tend to import associations that come from other ecosystems that have their own rules regarding immutability (like Android, SteamOS etc). A more fitting term would be atomic (which has been used to some degree by distros in the past). The name actually applies to all distros that are currently referred to as ‘immutable’, it’s descriptive and is the actual differentiator between these and the so-called ‘mutable’ distros. Further differentiation can be had with descriptions like declarative, image-based, reproducible etc.
That is, two machines that have the exact same software installed should be identical even if one has been installed a few years ago, while the other has been freshly installed (besides content of home folder etc). So stuff like cruft, bitrot and (to a lesser degree) state are absent on so-called ‘immutable’ distros.
Initially I was typing out a very long answer, but it quickly got unwieldy 😅. So instead, this one will be oversimplified 😜.
Currently:
Package management on native system just takes considerably longer on most atomic^[1]^ distros. The exceptions would be Guix and NixOS, but unfortunately their associated learning curves are (very) steep compared to the other atomic distros.
The learning curve in general is steeper.
Documentation is lacking.
Big shifts occur more frequently^[2]^.
Some things simply don’t work (yet).
One might (perhaps correctly) point out that most of these are actually more related to the technology lacking maturity. And that atomic distros would actually (already) net positively otherwise. Therefore, I’d argue, the transition to atomic distros is perhaps more akin to a natural evolution. I believe (at least) Fedora has already mentioned the possibility to sunset the non-atomic variant in favor of the atomic one when the time is there (or at least switch focus). Which is why I believe that atomicity will probably leave a lasting impact to the Linux landscape, similarly to what systemd has done in years prior.
Besides that it’s probably a challenge to maintain…
If your use-case is supported and you’ve acquired the associated knowledge for setup/configuration and maintenance, then I’d argue it’s probably even easier than a non-atomic distro; simply by virtue of atomicity, increased stability and rollback-functionality. But, as has already been established previously, the learning curve is steeper in general, so getting there is probably harder. With the exception being those whose needs are satisfied easily by the accessible software found in the main package-‘storefront’. Which makes distros like Endless OS very suitable for people whose primary interaction with ‘computers’ has been mobile phones and tablets, as the transition is -perhaps surprising to some- near flawless.
Yes, that’s how I’ll be referring to them.
Fedora Silverblue switching to OCI container images for delivery of installations and upgrades. openSUSE’s offerings switching to image-based. Vanilla OS switching from Ubuntu to Debian and to a model that’s a lot more similar to where Silverblue is headed towards. NixOS switching to flakes. etc
NixOS has been around since 2003, thus making it older than Ubuntu (2004). Even Silverblue has been out since more than 5 years (October 2018). Finally, we can’t forget about Guix that had its first release over 10 years ago (January 2013).
Great post. However, I will add my opinion about Debian Sid and its lineage: just don’t use them for production. Sid is an unstable distribution that looks like a rolling release distribution and most of the time it’s fine, but it is fundamentally different since it’s okay if it gets broken.
I’m guessing the idea behind Siduction is to use this rollback functionality to counter its innate instability, but with solid alternatives like openSUSE or the already installed Linux Mint + Timeshift, I wouldn’t recommend Siduction. Also, Manjaro is unstable by design, wouldn’t recommend that one either.
I personally agree with your assessments regarding Debian Sid and Manjaro. However, I didn’t want to force my (potential) ‘bias’ in a comment that tries to be otherwise neutral. Thank you for bringing up the ‘asterisks’ associated with both of these!
Great piece of information. I personally don’t see the benefits with immutable distribution, or at least it (without any experience) feels like that I’ll spend more time setting it up and tinkering with it than actually recovering from a rare cases where things just break. Or at least that’s the way it’s used to be for a very long time and even if something would break it atleast used to be pretty much as fast as reverting a snapshot to fix the problem. Sure, you need to be able to work on a bare console and browse trough log files, but I’m old enough that it was the only option back in the day if you wanted to get X running.
However the case today was something that I just couldn’t easily fix as the boot partition just didn’t have enough space (since when 700MB isn’t enough…) even a rollback wouldn’t have helped to actually fix the installation. Potentially I might had an option to move LVM partition on the disk to grow boot partition, but that would’ve required shrinking filesystem first (which isn’t trivial on a LVM PV) and the experience ubuntu has lately provided I just took the longer route and installed mint with zfs. It should be pretty stable as there’s no snap packages which update at random intervals and it’s a familiar environment for me (dpkg > rpm).
Even if immutable distros might not be for my use case, your comment has spawned a good thread of discussion and that’s absolutely a good thing.
at least it (without any experience) feels like that I’ll spend more time setting it up and tinkering with it than actually recovering from a rare cases where things just break
That might be the case depending on your proficiency and to what degree the ‘immutable’ distro allows you to configure your distro declarative. On e.g. NixOS you can define (most of) your system declarative. As such, reinstalling your entire setup is done through some config files. You can even push this further with the (in)famous Impermanence module that has been popularized by the popular Erase your darlings blog-post, in which your system is wiped every time you shut off the machine and rebuild (basically from scratch) every time you boot into it.
Potentially I might had an option to move LVM partition on the disk to grow boot partition, but that would’ve required shrinking filesystem first (which isn’t trivial on a LVM PV)
I haven’t worked with LVM yet. Defaulting to Btrfs (as Fedora -amongst others- does) has so far provided me a reliable experience, even though I’m aware that I’m missing out on performance. Hopefully, Bcachefs will prove to be a vast improvement over Btrfs in a relatively short time-span. You’ve pointed out to have installed Linux Mint with ZFS. Would I be correct to assume that you’ve been hurt by Btrfs in its infancy and choose to not rely on it since? Or is it related to lacking proper support for RAID 5/6? Or perhaps something else? Please feel free to inform me as I don’t feel confident on this topic!
and the experience ubuntu has lately provided I just took the longer route and installed mint with zfs.
Understandable. Though, I can’t stop myself from being very interested in their upcoming Ubuntu Core Desktop. But I imagine you couldn’t care less 😜.
Would I be correct to assume that you’ve been hurt by Btrfs in its infancy and choose to not rely on it since?
I have absolutely zero experience with btrfs. Mint doesn’t offer it by default and I’m just starting to learn bits’n’bobs of zfs (and I like it so far) so I just chose it with an idea that I can learn it on a real world situation. I already have zfs pool on my proxmox host, but for that I hope I’d gone with something else as it’s pretty hungry for memory and my server doesn’t have a ton to spare. But reinstalling that with something else is a whole another can of worms as I’d need to dump couple terabytes worth of data to somewhere else in order to make a clean install. I suppose it might be an option to move data around on the disks and convert the whole stack to LVM one drive at the time, but it’s something for the future.
But I imagine you couldn’t care less 😜.
I was a debian only user for a long time but when woody/sarge (back in 2005-2006) had pretty old binaries compared to upstream and ubuntu started to gain popularity I switched over. Specially the PPA support was really nice back then (and has been pretty good for several years), so specially for a desktop it was pretty good and if I’m not mistaken you could even switch from debian to ubuntu only by editing sources list and running dist-upgrade with some manual fixes.
So, coming from a mindset that everything just works and switching from a release to another is just a bit longer and more complex update the current trend rubs me in a very much wrong way.
So, basically the tl;dr is that life is much more complex today than it was back in the day where I could just tinker with things for hours without any responsibilities (and there’s a ton more to tinker with, my home automation setup really needs some TLC to optimize electricity consumption) so I just want an OS which gets out of my way and allows me to do whatever I need to whenever I need it. Immutable distro might be an answer, but currently I don’t have spare hours to actually learn how they work. I just want my sysVinit back with distributions which can go on for a decade without any major hiccups.
Ah, I had misunderstood your /boot situation previously. There’s an easy way to fix it by backing up current content of boot, unmounting it, creating some dir somewhere where there’s space (/tempboot was my choice last time), bind mounting it to /boot and going through the apt process. Then unmount the bind, mount the real boot, delete everything except currently booted kernel stuff, copy all the things from /tempboot update the initrd and grub. Et voila!
Why I didn’t think of that. It whould have fixed the immediate problem pretty fast. I would still have the issue with too small boot partition, but it would’ve been faster to fix the issue at hand. But in either case, I’m pretty happy I got new distro installed and hopefully that’ll fulfil my needs better for years to come.
Broken computers aren’t really stressful to me anymore, but it sure plays a part that I kinda-sorta had waited for reason to wipe the whole thing anyways and as I could still access all the files on the system, so in the end it was somewhat convenient excuse to take the time to switch the distribution. Apparently I didn’t have backup for ~/.ssh/config even if I thoguht I did, but those dozen lines of configuration isn’t a big deal.
Thanks anyway, a good reminder that with linux there’s always options to work around the problem.
Can’t do a lot wrong with Linux mint I suppose. Stable software so support should be good, cinnamon doesn’t have too much fancy stuff that would use up ressources iirc.
It’s my top recommendation for beginners, might switch back to it some time.
In that case, Pop!_OS might be a good option to try. It’s built on Ubuntu and doesn’t have snapd garbage on it. I’ve been using it as a daily driver for 2 years now and I’ve had zero problems.
Mint is an awesome option too. For me it came down to the UI as the primary decision factor. I prefer MacOS aesthetics to Windows.
There are a host of other issues I have with how Microsoft (and Apple!!) do things, and really, the GUI is the least of those problems. But it is also the most obvious problem because I’m looking at it all day at work.
How old is your PC? Do you game via Steam?
If it is younger than 10 years, any desktop oriented distro will work equally well.
In that case, I’d recommend Mint, just because it is the best beginner distro overall.
If you have less than 4GB of RAM, Debian with Xfce would run faster.
If it’s older, then there’s a (small, but getting larger with age) chance it is limited to 32bit architecture or 32bit UEFI.
Then your choice of distros becomes slim, but MX Linux would be a good choice.
Absolutely, this thing has been sitting around for ages because it was barely powerful enough for WindowsXP when it first came out. Now has a new purpose!
Sure, as our European businesses - under management of big IT groups - are using indian’s sweatshop - that we have to train moreover!!! - for implementation and operational projects. I don’t say there’s not skilled indian, of course not, but they got a “shortcut”.
To manage temporary files in Linux, a Bash script can move files untouched for 10 days to a timestamped subfolder, return modified files to the root, and delete files not modified for 90 days. Alternatively, a folder with symlinks to recently accessed files can be created using mkdir, find with -atime -7 to locate recently accessed files, and a while loop with ln -s to symlink each file into the folder. Both approaches help organize files based on access time to avoid clutter and remove stale temporary files. The Bash script offers more automation while the symlink folder provides a manual way to access recent files.
The verified feature on flathub is a double edged sword, it makes me lean towards verified apps, even if the alternative is better and made by the original Dev ( but they just didn’t verify themselves )
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.