[kwlug-disc] Xubuntu 22.04 to 24.04 Upgrade

Fri Oct 11 13:00:29 EDT 2024

I've been running Linux Mint 20.3 for a couple years on my Thinkpad T14 and on a desktop PC. I use Cinnamon. There have been problems.

The desktop PC has some flakiness: the volume control for audio keeps disappearing, requiring a reboot or logout/login.

On both systems, I have Desktop Zoom enabled, from the Accessibility settings. I've configured it to zoom the full screen in and out using the mouse wheel when the Super key is held down. The bug I keep encountering is that if the mouse cursor is over a window that uses the Xinput2 library for mouse input, then that window scrolls while I am zooming.

Yesterday I upgraded the laptop to Linux Mint 21.3 using the mintupgrade program (instead of a clean install where the disk is wiped). As a result, Desktop Zoom is now broken (the mousewheel technique doesn't work at all). I have a workaround, in that AltSuper+ and AltSuper- can still be used for zooming.

Mint isn't unique in breaking on upgrade. I stopped using Fedora because I was on a forced upgrade cycle every 6 months, and spending a week to debug and repair my broken desktop environment twice a year was too much of a burden. With Mint, I decided to take this hit once every two years.

I am also disappointed that Mint 22 has dropped support for ZFS.

I was hoping that Mint would be more reliable, but I guess that's just how it is for desktop Linux.

Doug.

On Fri, Oct 11, 2024, at 9:38 AM, Charles M wrote:
> We've been comparing Xubuntu 24.04.1 to Linux Mint (21.3 and 22) as
> part of our exploration of Xubuntu 24.04.1 and here are some minor
> differences we noticed:
>
> Xubuntu has better integration with Xscreensaver "out of the box."
> Linux Mint XFCE uses light locker (Xubuntu may as well, but it seems
> to start the
> xscreensaver daemon on load). I know screensavers are not much of a
> thing these days, but we used to use them to draw people's eyes away
> from the Windows machines...
>
> Handbrake, which isn't installed by default, behaves a bit differently
> when first installed. Xubuntu, when you click Open Source, remembers
> the
> path you last added a file from. This comes in really handy if you
> have a directory of 100 files, open source, opens to that last
> directory. Clicking
> Open Source in Linux Mint XFCE opens the /dev directory each time.
> There's probably a setting somewhere to change this behaviour, but not
> everyone's going to realize this is a difference between the two. It's
> just going to be a bit more annoying in Mint.
>
> Xubuntu uses Atril for it's default PDF reader. Atril seems to open a
> bit quicker on low-resource machines than Xreader (Linux Mint XFCE).
>
> Linux Mint XFCE uses Xed for its text editor. Xubuntu uses mousepad
> for its text editor. While I like both Xed has bracket completion,
> which is
> nice for people who don't need a full fledged code editor, but
> appreciate some of the functionality.
>
> Mint has Timeshift and mintbackup, handy tools for making restore
> points, and backing up files. We've been adding Timeshift to our
> installs
> for awhile, it comes in handy because sometimes we have issues with
> nvidia drivers, and it's nice to timeshift back to the floss driver.
>
> Linux Mint 21.3 uses an old kernel. This can be a problem with new
> hardware, but we have a sort of niche case where it's useful. One of
> the issues
> we ran into with Xubuntu 22.04 was adding NVidia drivers for certain
> old cards. Those cards advertised a driver, but when attempting to
> install that
> driver (390 I think) Xubuntu would simply fail to install the driver.
> It was after installing Linux Mint 21.3 with it's older kernel that we
> realized the issue
> had to do with Xubuntu's newer kernel, the driver just couldn't
> compile against that newer kernel, but it could against the old Linux
> Mint 21.3 kernel.
> So a few of our machines perform better with lower end Nvidia cards
> because of this kernel difference. With Linux Mint 22 it's a moot
> point as
> it uses a newer kernel, so those cards won't see proprietary drivers
> in the future.
>
> The snap store in Xubuntu 24.04.1 is fast, and while they've added
> support for Debian packages back to the snap store (My Apps), it still
> doesn't have
> support for flatpaks (for obvious reasons). The old (GNOME) Software
> Centre can still be installed in Xubuntu 24.04.1, and support for
> Flatpaks can
> be added to its UI. The speed of the "My Apps" snap store is something
> that Xubuntu/*buntu has needed for several versions, it's been my
> biggest
> gripe with Xubuntu over the years. While I mostly use cli to install
> anything, I heard the frustration of some who used GNOME software
> centre - slow.
> Linux Mint XFCE's software manager seems a bit slow when first
> started, but nothing like the slowness of GNOME software centre. I
> think it's also a
> bit more intuitive in the sense that search has a decent sized search
> bar, as opposed to just a search icon (until you click it).
>
> We've been doing a fair amount of installs of both Xubuntu 24.04.1 and
> Linux Mint XFCE, and we found we had a lot of crash report prompts
> with
> Xubuntu 24.04.1 (xwrapper). Linux Mint XFCE also had some applications
> crash, but things happened more silently (which could be a good or bad
> thing depending on your perspective). In Mint System > System Reports
>> Crash Reports lets you look at any crashes and report them. I like
> this a
> bit better than the intrusive, always reporting that Xubuntu does.
> Again, probably a setting to turn this off, but just detailing out of
> box experience.
>
> Lastly, I've always thought Linux Mint had the edge when it came to
> appearance, but I think I actually like the work the Xubuntu team has
> done
> for 24.04.1 better. The new icon theme is a bit brighter, and though
> they only added 1 new wallpaper for this release, I prefer the look of
> it to the
> somber look of Linux Mint 21.3/22.
>
> Cheers,
>
> Charles
>
> On Wed, 9 Oct 2024 at 15:29, Chris Frey <cdfrey at foursquare.net> wrote:
>>
>> On Wed, Oct 09, 2024 at 02:41:07PM +0000, Doug Moen wrote:
>> > I would argue that the doctrines that packagers of binary-based Linux
>> > distros have built up around shared libraries are very specific to the C
>> > language. When these doctrines were formed, all binary executables were
>> > compiled from C or early stage C++ code.
>>
>> That's fair enough, and perhaps there are new technologies yet to be
>> created in the shared library world (and software licensing world)
>> when it comes to these new generic languages.  I understand if C-shared
>> must look different than C++-shared or Python-shared or Rust-shared or
>> Julia-shared, as long as they actually share.
>>
>> My objection is that for some languages, they don't seem to be trying,
>> or more accurately, it is not a priority for them.  Saying
>> "it's impossible" doesn't convince me either.  Sure, there's
>> a lot of template/generic code out there, but that's not all of it.
>>
>> I looked up your example of Julia, assuming it would be a super generic
>> example of something impossible to build into shared libraries.  Yet
>> they document app building that allows for including all the Julia
>> standard libraries or not, implying that you can assume certain stdlibs
>> already exist on the target machine.  Looks like they support C-level
>> .so files for interoperability purposes.  I couldn't find whether they
>> have a stable ABI yet, but they do document their calling conventions.
>>
>> It also looks like there are some folks on the Rust side working on a
>> stable ABI:
>>
>>         https://slightknack.github.io/rust-abi-wiki/intro/intro.html
>>
>> So, it's basically what I said originally... it's just what happens
>> when people start something from scratch, and eventually they will catch
>> up to the rest of the world on the old techniques, while having invented
>> a lot of new techniques in the process.
>>
>> - Chris
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>> with the subject "unsubscribe", or email
>> kwlug-disc-owner at kwlug.org to contact a human being.
>
>
>
> -- 
> Charles
> Mastodon: @chaslinux at techhub.social
>
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.