https://www.serverwatch.com/server-news ... years.html
Wonder how long before Debian will do the same?
My guess is Ubuntu is trying to match Redhat's 10 years of support.
Canonical Extends Ubuntu Support
Re: Canonical Extends Ubuntu Support
I think it's more relevant for server, people won't use a desktop installation for 10 years...
Re: Canonical Extends Ubuntu Support
Why not, Adrian? If it's awesome, safe, and up-to-date, I wouldn't change anything for 10 years, maybe longer.
Re: Canonical Extends Ubuntu Support
It would be hard for me.
The new releases are more awesome, safer, and more up-to-date.
I guess I also just like to change --that's why I used to distro hop-- from boredom.
I have started testing distros in the past because there was no challenge to maintain the active.
Crazy, but true.
Experience has reduced that craziness.
Using MX since a few days after the initial release of MX-14 because it fits my idea of what I want.
The new releases are more awesome, safer, and more up-to-date.
I guess I also just like to change --that's why I used to distro hop-- from boredom.
I have started testing distros in the past because there was no challenge to maintain the active.
Crazy, but true.
Experience has reduced that craziness.
Using MX since a few days after the initial release of MX-14 because it fits my idea of what I want.
Thinkpad T430 & Dell Latitude E7450, both with MX-21.3.1
kernal 5.10.0-26-amd64 x86_64; Xfce-4.18.0; 8 GB RAM
Intel Core i5-3380M, Graphics, Audio, Video; & SSDs.
kernal 5.10.0-26-amd64 x86_64; Xfce-4.18.0; 8 GB RAM
Intel Core i5-3380M, Graphics, Audio, Video; & SSDs.
Re: Canonical Extends Ubuntu Support
Because users care about newer software, especially browsers, and in general things that change a lot, a "supported" release for 10 years means that you get the security updates but not much more (otherwise it would be a rolling release a la Arch) Think about it, there would be no need for Ubuntu to release twice a year if a 10 year old release would mean upgrading all the software. But that's not possible technology changes, you probably want better solutions not just security updates.
Re: Canonical Extends Ubuntu Support
Yup. Servers don't need the bells and whistles, they just need to be safe.
But personal/desktop users may want to enjoy the latest features on software and that may not be able to be run on the older OS base. Or maybe the latest games won't run because it needs the latest Steam or whatever (just plucking a hypothetical from thin air because I don't play games!) which might not be able to run on the older base.
The alternative to a long-running system (that is not rolling) will be what Endless OS or Fedora's Silverblue ( https://fedoramagazine.org/give-fedora- ... est-drive/ ) offer with containerization.
You have a bare OS base plus Flatpak infrastructure as your system. Applications are installed as flatpaks, so that you can upgrade them and their respective runtime (e.g. toolkits like gtk+ or Qt) even if your base OS is on an older version of that toolkit/runtime.
However, the same caveats Dolphin_Oracle set out in his Blog entry and video on flatpaks still apply:
1. large size of applications and their runtimes
2. some apps running as flatpaks in that containerized environment may or may not work or integrate perfectly with your base system. It might also depend on the developer or flatpak maintainer/packager of the application.
But it's good that there are different choices as to how to want to run and maintain your system. You just need to assess for yourself the pros and cons and what fits your use case best.
But personal/desktop users may want to enjoy the latest features on software and that may not be able to be run on the older OS base. Or maybe the latest games won't run because it needs the latest Steam or whatever (just plucking a hypothetical from thin air because I don't play games!) which might not be able to run on the older base.
The alternative to a long-running system (that is not rolling) will be what Endless OS or Fedora's Silverblue ( https://fedoramagazine.org/give-fedora- ... est-drive/ ) offer with containerization.
You have a bare OS base plus Flatpak infrastructure as your system. Applications are installed as flatpaks, so that you can upgrade them and their respective runtime (e.g. toolkits like gtk+ or Qt) even if your base OS is on an older version of that toolkit/runtime.
However, the same caveats Dolphin_Oracle set out in his Blog entry and video on flatpaks still apply:
1. large size of applications and their runtimes
2. some apps running as flatpaks in that containerized environment may or may not work or integrate perfectly with your base system. It might also depend on the developer or flatpak maintainer/packager of the application.
But it's good that there are different choices as to how to want to run and maintain your system. You just need to assess for yourself the pros and cons and what fits your use case best.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Re: Canonical Extends Ubuntu Support
Nitrux OS is trying to do the same thing - base OS (Ubuntu) + portable apps (Appimages).
But based on this recent review by Jesse of Distrowatch: https://distrowatch.com/weekly.php?issu ... 015#nitrux
there are still some issues with it. And integration with the base system is also something that affects Appimages.
From my own experience, I've also found that that Appimages, once you upgrade beyond certain versions - might no longer work on your base system, so I believe it's not 100% containerized. My example was Krita. Version 3+ Appimages work on MX. I tried running a version 4+ Appimage and it gave me some error messages.
But based on this recent review by Jesse of Distrowatch: https://distrowatch.com/weekly.php?issu ... 015#nitrux
there are still some issues with it. And integration with the base system is also something that affects Appimages.
From my own experience, I've also found that that Appimages, once you upgrade beyond certain versions - might no longer work on your base system, so I believe it's not 100% containerized. My example was Krita. Version 3+ Appimages work on MX. I tried running a version 4+ Appimage and it gave me some error messages.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400
Re: Canonical Extends Ubuntu Support
Really, the words container and AppImage don't belong together in a one-sentence description.https://www.appimagehub.com/
AppImages are self-contained apps which can simply be downloaded & run on any Linux distribution. For easy integration, download AppImageLauncher
We can accurately say an appimage file is an archive, an archivefile. The construct is derived from RoxDesktop AppDir distribution files.
Security-wise, an AppImage -packaged application is not "containerized".
The author of firejail is striving to provide a mechanism for auto-sandboxing launched AppImages, but (IMO) that mechanism is not ready for primetime.
Watch 'em like a hawk I am. Rechecked the various docs tonight to verify they are not making any representations regarding security.
I really wish the docs would convey a disclaimer, but oh well.
https://github.com/TheAssassin/AppImageLauncher
https://github.com/AppImage/AppImageKit
https://appimage.org/
https://en.wikipedia.org/wiki/AppImage "...a portable, self-contained, distro-agnostic [package]"
Re: Canonical Extends Ubuntu Support
Flatpacks and Snap packages should allow updates of the main applications like Firefox, Libreoffice, etc. I could see certain machines, especially older ones and servers that I would not want to fix if they aren't broken. Ubuntu gets more bloated with every release. I compare older Ubuntu/Mint releases and the newer ones use more ram, slower to start up and shutdown, gtk3 may be much of it, but whatever the reason, Ubuntu gets more bloated with each new release. So sticking to a lighter, dependable base will have an audience. Remember that using a Windows release for a decade is expected, so Ubuntu would be more appealing to some people because of it.
Now back to reality :) Ubuntu is only doing this because Shuttleworth is going to do an IPO next year, according to his words, and I'm sure he is hoping for a buyer with big pockets. He is trying to make Ubuntu Server, the profitable arm of Ubuntu, more like Redhat with 10 years support. As for practical experience, I've never got Main Ubuntu to last more than a couple of years, usually not that long, before they break it with an update, so I take 10 years with a grain of salt, knowing anyone who even get 5 years of a working Ubuntu desktop should thank their lucky stars :)
Now back to reality :) Ubuntu is only doing this because Shuttleworth is going to do an IPO next year, according to his words, and I'm sure he is hoping for a buyer with big pockets. He is trying to make Ubuntu Server, the profitable arm of Ubuntu, more like Redhat with 10 years support. As for practical experience, I've never got Main Ubuntu to last more than a couple of years, usually not that long, before they break it with an update, so I take 10 years with a grain of salt, knowing anyone who even get 5 years of a working Ubuntu desktop should thank their lucky stars :)
Re: Canonical Extends Ubuntu Support
+1, I agree, I like the LongTime Support too, and with the solutions like appimage, flatpak, snaps, etc , only security updates are required.
Pour les nouveaux utilisateurs: Alt+F1 pour le manuel, ou FAQS, MX MANUEL, et Conseils Debian - Info. système “quick-system-info-mx” (QSI) ... Ici: System: MX-19_x64 & antiX19_x32