Not anymore because all the reason I mentioned. Has the experience change in recent years? Not likely. It is the same software as in other distros - just years out of date. That has not changed as the goals of these projects have not changed. They might be on newer versions then 10 years ago but they are still way behind more frequently updated distros - or at least will be very shortly. That is fundamentally how these enterprise distros work. Their target audience is businesses needing support, not lots of end users.

The big attraction towards these distros are the support that enterprise people will pay for - which you do not get with the free version. If you don’t mind older versions of things then it might be nice for you. If not then I would stay clear of them.

Older software is the most noticeable thing. Enterprise does not mean it is better - just that it is supported for a long time and they do that by not changing much on them. They are more designed for servers rather than workstations and generally not a great experiences unless you are running hundreds or thousands of them in an enterprise situation.

Professional just means payed for. What you are paying for is support in managing the systems, not a great user experience.

For home desktops it is far nicer to be on newer software rather than things that came out 5 to 10 years ago.

If that were the main goal why not just ban them from the extension store? Or why allow manifest v3 extensions to block requests at all? Ad blockers still work and this did not kill off any of them. Just forced them to change some of their functions. I don’t doubt the executive overlords are happy about the turmoil that this has done to ad blockers but they would be pissed if that was the only or main goal of this as there are still loads of effective adblockers about.

That is a more complex story then that. The manifest v3 changes primary give a lot of security and privacy changes that stop extensions from doing a lot of questionable things in the background on all your page you visit. But that does stop ad blockers from doing a lot of what they currently do - blocking in page elements and modifying the pages you visit. But it does not block them from blocking page requests so ad blockers like ublockorigin lite can still function in a more limited capacity to block ads.

I do think the teams outside of the chrome team are happy for this change - but I don’t think the chrome team set out to do this purely or even mainly to block ads.

Besides even if they did it does not change my argument - whom ever buys chrome will likely want to squeeze it for more money then google currently are doing and will likely do far worst things like including ads directly in the browser. Or trying to monetize it in some other way.

I would love it if chrome where maintained by some non-profit foundation. But how likely is that going to be from a court order sell off?

I would rather they split up google in other ways first.

TBH I am not sure this will end well at all. Google needs to e broken up but splitting off chrome? What will that achieve? Chrome does not directly make any money for Google really, they don’t sell it, they don’t sell ads in it, they don’t even collect much personal data though it. No where near as much as they really could if they really wanted to. Google have not been terrible at managing chrome or pushing as much profit out of it as they could.

Instead they are using it to create a good platform for all the rest of their services where they actually make money. So what will selling off this loss leader do for chrome? Most likely it will get bought up by someone else that will want to see a return on investment that wont be using it as a loss leader. Which I can very well see it getting en-shitified like everything else that is purely driven by profit.

Best case it is gets bought by a non profit foundation that can develop and take care of it - but lets be real, they wont have the money to out compete anyone wanting to buy it to make more money.

I personally don’t really trust google with my browser either - hence why I avoid chrome. But I would trust anyone seeking to buy it for profit far less and can very well see this as a overall negative if the wrong people buy it (which I see as more likely).

That being said, I don’t keep one in my car.

Now is the time to change that.

Um no. Containers are not just chroot. Chroot is a way to isolate or namespace the filesystem giving the process run inside access only to those files. Containers do this. But they also isolate the process id, network, and various other system resources.

Additionally with runtimes like docker they bring in vastly better tooling around this. Making them much easier to work with. They are like chroot on steroids, not simply marketing fluff.

When I change devices or hit file size limits, I’ll compress and send things to my NAS.

Whaaatt!?!!? That sounds like you don’t use git? You should use git. It is a requirement for basically any job and there is no reason to not use it on every project. Then you can keep your projects on a server somewhere, on your NAS if you want else something like github/gitlab/bitbucket etc. That way it does not really matter about your local projects, only what is on the remote and with decent backups of that you don’t need to constantly archive things from your local machine.

Sounds like you just need to keep the data on your server and use samba or NFS and a network mount on the other devices.

It doesn’t technically have drivers at all or go missing. All supporting kernel modules for hardware are always present at the configuration level.

This isn’t true? The Linux kernel has a lot of drivers in the kernel source tree. But not all of them. Notably NVIDIA drivers have not been included before. And even for the included drivers they may or may not be compiled into the kernel. They can and generally are compiled with the kernel but as separate libraries that are loaded at runtime. These days few drivers are compiled in and most are dynamically loaded depending on what hardware is present on the system. Distros can opt to split these drives up into different packages that you may or may not have installed - which is common for less common hardware.

Though with the way most distros ship drivers they don’t tend to spontaneously stop working. Well, with the exception of Arch Linux which deletes the old kernel and modules during an upgrade which means the current running kernel cannot find its drivers and stops dynamically loading them - which often results in hotplug devices like USB to stop working if you try to plug them in again after the drivers get unloaded (and need a reboot to fix as that boots into the latest kernel that has its drivers present).

I don’t get it? They seem to be arguing in favor of bootc over systemd because bootc supports both split /usr and /usr merge? But systemd is the same. There is really nothing in systemd that requires it one way or another even in the linked post about systemd it says:

Note that this page discusses a topic that is actually independent of systemd. systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems.

I don’t really get his points for it either. Basically boils down to they don’t like mutable root filesystem becuase the symlinks are so load bearing… but most distros before use merge had writable /bin anyway and nothing is stopping you from mounting the root fs as read-only in a usr merge distro.

And their main argument /opt and similar don’t follow /usr merge as well as things like docker. But /opt is just a dumping ground for things that don’t fir the file hierarchy and docker containers you can do what you want - like any package really nothing needs to follow the unix filesystem hierarchy. I don’t get what any of that has to do with bootc nor /usr merge at all.

TLDR; yes it does affect security. But quite likely not by any meaningful amount to be worth worrying about.

Any extra package you install is extra code on your system that has a chance to include vulnerabilities and thus could be an extra attack vector on your system. But the chances that they will affect you are minuscule at best. Unless you have some from of higher threat model then I would not worry about it. There are far more things you would want to tackle first to increase your security that have far larger effects than a second desktop environment being installed.

So, why wait for windows 10 EOL? If you are already mostly on Linux and are planning on getting rid of the last bits anyway? If you really need to you can always reinstall windows on a second disk or in a VM later on if you really need to - no real need to preemptively do that if you dont plan on using it.

If you have everything you need backed up you can reinstall on a new hard drive and restore everything you need. So you should not be completely fucked. Just an inconvenience you might have to go through. You will lose the stuff not backed up so if any of that is a pain to get again it might be more painful to restore everything.

Others have said some thing you might want to try. But having a spare disk you can swap to is never a bad idea. Disks to fail and you should plan for what to do when they do. Backing up your data is a good first step.

I would say it is not a bad idea to just get a new disk now and go through the process of restoring everything anyway - you can treat it like your disk has failed and do what you would need to do to restore. With the ability to swap back when you need to.

This is a good way to find things you might have missed in your backups.

Not if you have backed up your data. You have a backup of your data right?

Why wait? Start using Linux friendly software in your day to day workflows. Then start to dual boot Linux with your current system and start using it more and more. By the time windows 10 reaches EOL you will know if you still need a Windows install or not.

And given some recent news about Valve working on an ARM emulator and funding Arch Linux to help them start supporting ARM as well they might be working towards that. Though if that is for the deck 2 or something else further in the future is yet to be seen.

The only other major thing for repairability/upgradability would be less glue on the battery and threaded inserts, which doesn’t add size.

The glue was reduced on later versions and especially on the OLED version which also got threaded inserts. So those are already done and I doubt the next version would regress in that regard.

I no longer use git stash. I found far too many issues with it. Merge conflicts and old no longer useful stashing building up, forgetting what was on it and which branch it came from and other things. These days the only time I stash is with --autostash on a git rebase as that is very temporary.

Instead I have moved to a worktree where I just commit everything on the main branch. Then use a different worktree to create a branch and cherry pick from main and create prs from that branch.

No need to stash as my main worktree never changes off the main branch and my second worktree never has local changes that are not committed.

If I need to change focus or fix a bug I can just do that, commit those changes only and cherry pick to a new branch all without affecting my current work (assuming I have not changed the area the bug is in too much but that is not a big issue if you keep commits small and create PRs often so you don’t drift too far from master).

If I have drifted too far I can always create a new worktree from origin and not touch my local main.

This is irrelevant with Steam though. Steam offers a runtime with preconfigured versions of everything that is needed to give the devs a consistent environment for their games to run no matter how fragmented the linux install base might be. This runtime is also what proton uses for ship its different versions.