xxx

Saturday, 16 January 2021

Guide: A safe, clean and easy way to update LinuxMint



From all the general usage Linux desktop distribution, my favourite one is Linux Mint. In all my set-ups it seems to just work.

 

However, one of the main concerns is that it is not a rolling release, so to get to the latest version one needs to do a full upgrade.

 

This can be achieved in two ways

  1. Do an upgrade in place using the tools provided by the distribution. While this method works well most of the time. Sometimes there are big breaking changes, when moving between different Ubuntu bases but also minor annoyances for simpler releases.
  2. Do a clean installation. Some people don't like this option because they need to reconfigure their whole OS.

For many releases now, I have used a solution which gives me mostly the best of both worlds. One that gives me all the benefits of installing from scratch and at the same time allows me to keep all my settings and applications. This solution also minimizes my down time in case of I find an issue.


Here is what I do:

 

I have a partition setup that allows me to follow this method release after release, among other benefits.

  • 20 GB btrfs root partition. You may choose a larger size if you install lots of apps.
  • Separate ext4 /home large partition
  • One 20 GB spare partition for distro-hopping. You may choose a larger size if you install lots of apps.

When it's time to upgrade:

  1. Backup my list of apps (using the LinuxMint backup application).
  2. Update or disable applets and extensions that have known issues in the new version of LinuxMint .
  3. Install the new version in the spare partition reformatting it and selecting to use the existing  /home partition.
  4. Boot into the new version and verify if it works OK.
  5. Restore my applications using the backed up application list. (Using the backup app).
  6. Reinstall any flatpaks I may have installed before and "make install" anything I may have installed from source.

From beginning to end, 30 minutes, all my apps and settings exactly as the previous version.

 

If I find an issue with the new version I have two options

  • If I am pressed for time to use my computer, I restore grub to point to the previous version and I am up and running in a few minutes.
  • If I have time to troubleshoot, most of the time the easiest solution is to backup and remove some .config files which may have incompatible settings.

After I'm comfortable, I wipe-out and repurpose the "original" partition for distro-hopping until the next time I want to upgrade.


Read More

Is it fair to compare the stability of Debian vs. ArchLinux currency?


 

In other blogs and forums it is not uncommon to read arguments pro or against diverse Linux distributions.

 

Most of those arguments fail to recognize that there is more in common between Linux distributions than things that set them apart: a Linux is a Linux is a Linux.

 

The most common comparison for people who strive to have a minimalist desktop system is comparing Debian vs. ArchLinux.

 

The usual propositions are 

 

Should I choose the stability of Debian at the cost of package currency or the currency of ArchLinux at the cost of stability. 

and  

I prefer the rolling releases of ArchLinux to the standard Debian releases 

 

For me, both are false dichotomies given Debian can be current and rolling and ArchLinux can be reliable.

How so? First some clarifications: 

  • Debian has stable (Buster); but also testing and unstable (Sid). Sid -> Testing -> Buster.
  • When people talk about Debian older packages they refer, in general to Buster.
  • The word "stable" refers to how frequently packages change, not how reliable the system is.
  • Both Debian Sid and ArchLinux are rolling release. And both are reliable.
  • With that clarified:

 In Debian

  • You will only notice the older packages when there is functionality you need which is only in a newer version. So, most users don't ever notice given that, for mature applications newer features usually fall into edge cases or advanced uses.
  •  There are workarounds for having newer packages: PPAs, AppImages, Flatpaks or building from source (Note: building from source is usually trivial even if people are afraid about it). 
  • Bottom line, the "older packages" argument is a non-issue. Even if you were using Debian stable, you can use well tested applications for most things and only install the newest version for things you really need to have bleeding edge, but then you only have those few things to keep an eye on.

In Arch:

  • ArchLinux tries to keep up with the latest versions, but there is still a testing repository. Which means that packages aren't just recompiled and thrown at the users.
  • Given that it has newer packages, even with the testing, it is more likely that one may find an issue. However, there are various workarounds to solve them: One knows the system better so troubleshooting is easier. One can very easily have snapshots (if using Btrfs) and/or easily rollback packages and/or avoid certain versions. 
  • Bottom line: Instability is a non-issue. You use current applications for most things and only keep back version for things that are giving you trouble. But then you only have those packagesto keep an eye on.
  • Personally, the main difference I see is not technical but practical.

I'd advise to use Debian Buster for systems which should rarely change, like production servers or customs systems to be used by non technical people.

 

I'd advise to use Debian Sid for people who like the Debian philosophy and implementation decisions.

 

I would recommend Arch Linux for more technical people who can, and want resolve their own issues, and who have the time, and want to learn the details of how their system works.

​

Of course there are many other Linux distributions and I could do the same analysis. In the end,  Choosing the right distribution is, mostly, a matter of preference for the initial configuration as we can make them all eventually work similarly.

Read More

Thursday, 24 September 2020

"Show desktop" on one monitor only, on a Linux Desktop

I was browsing a reddit group and so a question from someone asking if it was possible to set a shortcut to minimize all the windows in a specific desktop.

I decided to investigate and couldn't find anything so I decided to write a little script to do just that using 

  • xrandr
  • wmctrl
  • xdotool
While there is some overlap on the functionality of those tools to manage the windows, I just implemented using the commands I already knew. Maybe later I will improve it.

minimizeWindowsInMonitor.sh

The usage is very simple, just call it passing an integer indicating the monitor number.

It works as a toggle: run it once and it minimizes the windows of the selected monitor specified, run it again and it restores the windows.

The script considers a window to be "in" a monitor, if the top let corner is within that monitor. 

Just make it executable and assign a keyboard shortcut to execute it:


Currently it has a few of minor bugs (that I know of)

  • When restoring windows, it restores even windows that were originally minimized.
  • There are some screens which report their offset "wrong" so they appear to be outside the window
  • It does not validate the input parameter
Note: It creates a file (.wmfm) in the home folder of the user to save the parameters of the minimized windows. I thought about putting it in /tmp but that may be a security risk. If you don't like the file there, you can edit the script and specify any other location.
Read More
© 2014 Using FOSS. Designed by Bloggertheme9
Powered by Blogger.