It's been more focused on being lightweight than targeting "old hardware" directly for a while now: "The project’s goal is to provide a lightweight yet functional Linux distribution based on a rock-solid Ubuntu base.". Snap has been included by default since 18.10 which was also when they dropped 32 bit x86 builds.
I'm not a fan of containerization of base OS apps at all (planning on using it for for Chrome, Skype, Slack, and other Electron-based cross-platform apps only) but I'm pretty sure Ubuntu is mainstream enough at this point that Canonical pretty much dictates the shape of the Linux desktop for third-party apps while "everyone else" includes "just" RH (who still do/finance a large part of kernel development, of course).
But maybe I'm overlooking something, so if somebody with a distro maintainance or third party appdev background could share why settling on snaps causes trouble or undue extra work or is less-than-optimal I'd appreciate it.
"Note, due to the extensive changes required for the shift in desktop environments, the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install."
Is quite a surprising note for an official Ubuntu flavor.
Honestly the only Linux distros worth trying are Gentoo, Arch, Fedora and RHEL/Oracle/CentOS. With anything else you are just wasting your time with amateur hour attempts to cobble together a Windows/Mac OS competitor without a good understanding of how all the components fit together.
Sure, Ubuntu and Debian change the source code/setup of upstream packages, and generally add very little value compared to just using Gentoo/Arch/Red Hat based distros which actually use upstream components with much less touches and provide a more sane way to install your own packages, run docker container etc. In addition, Ubuntu does not do any real work pushing desktop linux forward.
Ubuntu focuses its efforts on ill-advised efforts like writing its own compositor (Mir) and Desktop environment (Unity).
Currently, most work to advance the Linux desktop is focused on a new project called Wayland (Used by Fedora for last few releases), yet Ubuntu has decided to double down on X11, a legacy project that clearly has no future and has issues like screen tearing that are basically impossible to fix.
Another tangible example related to developers: On Fedora/Arch you can run docker containers without requiring root due to Red Hat's work pushing podman forward, however you cannot do this on Ubuntu/debian because they lag behind upstream
Honestly it seems like a clone of docker selling the slight advantage of root less.
Which docker already does.
I don't understand why I should care that it's a Daemon. In fact that blog post says that they won't go into why it's bad. Just that they do things different.
In fact it seems like it's a "Not invented here" implementation from Red Hat.
Searching Hacker news there's not many posts on it. Seems like it'd be as silly as using Mir to run this in production.
Also on my doubling down, I misquoted you saying they're doubling down on X11.
There doesn't seem to be any evidence of this. I wasted time googling it and it looks like they decided not to use Wayland by default in 20.04 because of certain bugs they didn't deep acceptable.
But it comes with Wayland out of the box, and you select it on the login screen.
I think having a MacOS/Windows competitor is a good start, a lot of people try a Linux distro and choose a flavor that's familiar (Linux Mint is very similar to windows for example).
Or, we've been using Linux for a long long time and have no time for compiling from scratch, and like it or not, Ubuntu is the best tested out there for the desktop/laptop. Fedora isn't bad either, mind you.
I'd never run Ubuntu on the server by choice, mind you, but servers are constrained by other considerations.
Since we're talking about compiling from scratch, I spend about a third of the time compiling since I've got Arch on my machine (albeit a fairly powerful Ryzen). The vast breadth of the AUR saves me a lot of time having to figure out how to compile version z of software x.
Agreed, but also: it's important to know that some of the "hardcore/tunable" distros don't provide a good understanding of how components fit together either.
I don't know how it is now, but many years ago it was a running joke that most Gentoo users hadn't the faintest idea of how anything worked, but felt "hardcore" because they could pass many command line flags to the build and felt they were "optimizing" their system -- actual gains were not demonstrably noticeable, but they "felt fast" -- and they had no understanding whatsoever of gcc flags for example. Experienced users had to patiently explain that no, you shouldn't pass that experimental flag to gcc or everything would break.
"Hardcore" Gentoo users believed that by "installing from source" they somehow magically ended up with a faster system. No empirical evidence, of course, just a heartfelt belief compiling source code was magical.
This kind of "hardcore" Gentoo users was very, very, very annoying. Users of Ubuntu were better off: they understood what they worked with regularly and didn't pretend to understand what they didn't need to understand.
I see similar issues from a lot of Arch users tbh. There seems to be a lot of posturing of being a more advanced user, when thats not always the case. I once saw someone confidently explain that their drive device was /dev/nvme instead of /dev/sda because its an arch thing.
I've tried one such "hardcore" distro once (Crux to be exact) and while it was fun for a while, I also wasted a lot of time. Nowadays, I just stick Ubuntu Flavor (am actually running Lubuntu right now) because everything works mostly out of the box. Yes, I know it has its own set of problems, but I have different priorities. I dont particularly care if I get labeled a noob for it.
I just (last 2 weeks) switched from Gentoo to Ubuntu for my personal/home VMs (Linode!). The risk of crap breaking on a emerge world ... was just too high. I think the final straw wsa something related to python2/3 issues breaking emerge it's self. I rebooted it into safe mode, spun up a new Ubuntu image, and rsync'ed to /old_linode/ and then reinstalled bind9 and apache2 and etc. The thing I liked about having local compiles for everything is you could gdb any system binary. As a C programmer for many years, I like seeing real code.
I also do know a bit of super linux knowledgeable people who dont need to tweak their system and use ubuntu. Sure they used to run super tweaked systems but by now they use lts ubuntu, manually tweaking g their desktop gets old fast. (That said, they do tune the embedded file system they build on that distro and that they are responsible of.) Or developers that work on their interesting problem which is not tweaking a linux desktop.
Under no circumstance should anyone listen to this user nor should they run Gentoo or Arch on a production machine. I use Arch on my personal computer but for work I find Debian testing to be the perfect distro. Stability is a trait which matters.
Do you find debian testing to be stable enough compared to debian stable, for servers?
For similar reasons (stability), I always go for the current stable (although I've a couple machines on oldoldstable, because it takes a while to upgrade...).
I've been super happy with Gentoo in production for at least a decade. I don't see the issue? I have Gentoo on my desktop+laptop too. But, I also run loads of Debian server systems too. My worst upgrade experience has been Ubuntu systems
I run Arch Linux for work even though we're a Debian shop, and it has a great many efficiency advantages. I think in hours they are more than worth the three hours of productivity loss it would take me to repair my machine in case something bad happens. Indeed, AUR and the extreme adaptability of Arch probably saves me 2-3 hours a week.
(Many) years ago I knew someone who was very happy running their business off Gentoo. "It took two weeks to "make world" with the ultimate optimization settings. "But it runs great!"
I never could bring myself to ask if they were ok with being down for 2 weeks if they needed to re-install. Say, in a case where they had an intrusion and didn't trust their backups...
There's no reason they'd have to be down for two weeks in that case. They could use a binary distribution to immediately get back into shape, and then switch over after compilation's finished, or they could compile without -OX and it'd take almost nothing, and then they'd be good to go.
Really, though, nowadays compiling everything, even compiling things for optimal performance, doesn't take that long. Your production machines shouldn't have web browsers, and without the C++ garbage behemoths on it, compilation takes like half an hour on most machines.
I'm not a Gentoo user, but it's kind of silly to act like it makes recovering substantially harder than any other distribution.
This was at a time when compiling just the kernel took 30 minutes, so YMMV. But obviously, I don't know. Just didn't seem to me like the choice is want to make for running a business. Again, ymmv...
I imagine anyone doing this seriously would have a spearate system for building binaries. Obviously if that system was compromised, you would not be in a great situation, but it should be much easire to lock that down.
It has a long tradition. It happened to me many years ago: I've upgraded from one version of Ubuntu to another doing the "upgrade" but I had more and more problems. Then I've reached for help over the internet. The answer was "oh you upgrade to the new version? We never try this, we backup our home and install from scratch."
Another interesting point from these times: it was even then often written that the Linux and Ubuntu are better for the use of older computers compared to Windows. That wasn't true either. With every new version less of my hardware worked as expected. The memory demands only for the GUI installer were bigger than the demands of Windows, forcing me to attempt to install from the text mode, and still having the issues later. Windows just worked on the same machine (with the existing drivers).
I've also lived through my (other) old hardware breaking on Windows too: my notebook on which all the hardware worked as expected on Windows 7 was declared by the Windows 10 as "totally would work" and it totally didn't -- the Intel devices on it never got the drivers that worked on Windows 10, neither by Microsoft nor by Intel who simply stopped supporting them.
No OS is immune from the scenario (or even the company claims) "it will work" which than turns out not to be true with a new version.
Long story short, in this case, backup your /home, install from scratch. Backups are good anyway. Any other attempt will probably give more pain. Also don't expect the newest OS to always work with the old hardware. Be prepared for these kinds of events too.
Hopefully people realize it's an Ubuntu problem, and not a general Linux problem.
I pin my Debian machines to the "Testing" branch and "apt-get dist-upgrade" once a month, and I've never had a problem, except once or twice when NVIDIA drivers needed to be re-installed. It's worked great for me for 15 years, but YMMV.
The CPU/memory usage almost certainly has more to do with the software being used than with the distro. The Linux kernel and GNU system utilities can run on very low resource machines, but most "desktop environments," like GNOME, KDE, and even XFCE, are targeting up to date systems. IME, using old hardware usually means putting in some effort to find and configure software that will run well on it - I'm pretty sure it's the same on any OS.
Nah, it's not Ubuntu problem, it just happens because software is complex. It depends on so many factors and things like Debian break just as often.
I've personally had the same install across six Ubuntu installs in total and I know other people like that as well. Anecdotal experience but so is claiming Ubuntu's breakage ratio is higher.
It is surely not anecdotal and telling about "people I know" but the top comment of this thread for Lubuntu 20.04 LTS:
"the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install."
Note that 18.04 was also LTS, so whoever tries to upgrade from one LTS to another, will probably be able to start the process (like before) but at the end will with huge probability be better off just biting the bullet... and fresh install.
If the "people you know" upgrade faster then LTS to LTS they won't see a problem this time.
But being able to upgrade from one LTS to the next LTS is completely reasonable user expectation. I don't even want to try to prove that it will be broken this time.
No, Debian releases do not "break just as often". If you really couldn't got from release n to n+1 via apt(-get|itude) due to new packages migrating into testing, this would be a release-critical bug, and have to be corrected before the n+1 release were to be marked stable.
There are certain situations where a Debian upgrade will break a specific package - maybe due to upstream messing up really badly, or maybe due to some unusual way of configuring it. But in that case, the release notes that Debian publishes for each release would cover that particular problem for sure. Mistakes happen, and noone's perfect - but Debian tries to be, and they're very near that ideal in terms of ensuring your ability to upgrade your installation.
Fir me Debian releases are broken to start with. Fresh install of 10.3 resulted in gnome desktop that could not use gui sudo and some package with broken dependencies.
Replaced with xubuntu that just worked.
This was not the first time I tried Debian with similar results. The "stable" part just means that they distribute an old version of some software and not that it all works.
I thought Debian also moved to a fixed schedule release policy? Doesn't it make it harder to stick to a "release when ready"?
Personally, I don't think that Ubuntu is less perfect that Debian wrt. upgrade quality, it's just that (it seems to me that) the workforce is not as large, and that they also have other projects on their plate (not to say it should be that way or not, I'm merely trying to state the facts).
No, it makes "release when ready" easier, since the entire distribution doesn't have to wait for that single software release becau the next distro release is not that far away. At least that's how it works for Java. (I'm not that deep into Linux distros.)
How is that supposed to work? I understand that it possible to pull the plug on packages which are not ready at time T, but it also means pulling the plug on all the packages that depend on it.
So if libreoffice depends on package P, and that one is not ready, is Debian going to simply drop libreoffice until next release?
New versions of stuff go into Unstable. When they've been tested a while they get pushed to Testing. Periodically Testing is frozen and branched into a new Stable release. If a package doesn't make it into Testing before the freeze then it's out of luck and has to wait for the next release.
For example, assume libreoffice 1.0 and libfoo 1.0 are in Unstable, Testing and Stable. If libreoffice 1.1 comes out and depends on libfoo 1.1, but libfoo 1.1 is broken in Unstable, then libfoo 1.1 and libreoffice 1.1 won't be pushed to Testing until the issue is fixed. If they don't make it into Testing before the release freeze then the next stable will ship with libreoffice 1.0.
After the freeze, when the libfoo 1.1 is fixed in Unstable, then libreoffice 1.1 and libfoo 1.1 will go into Testing and wait for the next Stable to get branched.
The things I change are all over the place. From say /var/lib/mysql to /usr/local/bin and of course various /etc things ... it's not enough to say "backup /home and wipe the rest".
and sometimes it's, unfortunately, unavoidable for us when we are in the user's role to have to "just change as root that x y somewhere."
Long term, the goal should be to raise the awareness that there is a real need for most of the configuration to be easily transferable from the installation to the installation. But what we get instead is "just change as root wherever" and the containers for containers being run in the containers -- more bloat, but still not less demanding to maintain.
I really think Red Hat is not appreciated enough for their work on maintaining stability. The optimal solution will be when we have really stable platforms on which we will be able to easily and cheaply have recent languages, but also stable. Knowing how unstable practically a lot of programming platforms are, I am aware we're still not there. But... raise the awareness!
I take this approach on all operating systems now; I think I learned it from my dad when upgrading windows 95 to 98. A fresh install has less variability. Sure it takes a little more time to reinstall, but it’s an up front investment in not having complex research tasks later when things are weird.
This is the reason I switched over to Arch Linux. I have never been able to upgrade an Ubuntu system without some kind of obscure breakage without a documented fix. I've never encountered this problem with Arch, and archlinux.org both has great documentation and does a great job of alerting users when package upgrades require manual intervention.
Arch is like the CI/CD analogue of operating systems. Small upgrades makes breakages much less common, and much easier to repair. This comes as a trade-off of less battle-tested stability than e.g. Debian, but if you're able to make small repairs proficiently then Arch is the way to go. I'd strongly recommend Arch on a personal computer - it makes a good OS for a pet (although Debian, because versioned releases are much more thoroughly tested, makes for much better cattle OS).
Debian unstable follows more or less that "CI/CD" approach you're describing, but it is called unstable for a reason: sometimes, a significant change is necessary, which may lead to significant breakage as well, but most of the time, you get small breaks here and there, which are usually easy to fix (and hopefully report, so that break can be handled by the package upgrade process directly).
I wonder how's Arch in that regard. You speak about breakage less common, but there has to be some significant breakage from time to time: for instance, for a shift as important as moving from traditional sys-v init scripts to systemd, it must be expected that a lot of OS configuration related packages would break, unless every package maintainer is made aware that this change would happen, and that he/she has to prepare its package (if necessary) to that shift, AND that the shift only happens when everyone's ready. But Debian (and I suspect Arch as well) do not follow such a rigid scheme, and so there has to be breakages and fixes to follow.
> my arch installations tend to be quite lightweight.
That may explain why you don't get that many problems.
If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish.
I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that.
The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems.
The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation?
Or maybe there's too much friction between distros and upstream developers?
> If you start pulling in many different components
But if you've made that choice, you will likely be more aware of what you're dealing with.
There are definitely valid reasons to go with big-upgrade-every-year-or-two kinds of distributions. It can make developing software that depends on other software easier, especially if you need binary compatibility. A book or article about that system won't be out-of-date immediately.
Personally I wouldn't mind a few spread-out glitches throughout the year compared to frantically trying to repair a broken system after a dist-upgrade and losing a weekend.
I have had a few glitches with arch, but I think they were mostly some manual intervention for signing keys and didn't harm the system.
Arch looks like it's got a lot going for it, and I sometimes find myself looking at their documentation when I'm trying to shoehorn a package into ubuntu. Even though I used Gentoo linux for a long time, very similar to Arch in lots of ways, I haven't been able to install and configure Arch successfully on my computers. I'm sure if I spend a lot more time on it, I'll be able to do it, but I just don't have that much time to spare, so I stick to ubuntu and variants. But I really do like what I see on Arch.
Personally I'd hold up until the .1 release for servers, they iron out number of bugs that could impact stability. 20.04, despite being an LTS release, is quite "bleeding edge".
I always like to note that in Ubuntu upgrades to the next LTS are not offered until after it has gone through the first point release[1] (e.g., if you run 18.04LTS, you won't be told about 20.04 until 20.04.1 is out).
They started removing features for the sake of branding and their "desktop vision". They cut down on customization options that a lot of people were used to when they moved from gnome2 to gnome3.
To me, it felt like they started believing themselves to be great innovators in an Apple model of "we know what's best for you, this is revolutionary. You'll take it and you'll like it. Witness our works and tremble." [1]
I may be slightly hyperbolic there, but I worked on minor bits of the gtk code base and the way some of lead devs were talking I found frankly alienating.
To be fair there were also practical reasons to limit customization for greater testing coverage and I think some of the changes were driven by RedHat's move towards being an enterprise vendor. But those changes in addition to the change in tone I was hearing was jarring.
In any case several efforts attempted to move forward with the earlier code base or at least with the earlier philosophy. And I found one that was near enough to ok.
I gave up on Linux desktop when Lubuntu file manager removed its tree view. A few months ago I read somewhere that it was restored. These news sound promising so I've taken a look and... it turns out that lxde is gone. Out of luck.
The thing I liked was the file manager tree view. PCMan had Windows 95 style tree. That's my favourite file manager arrangement, the one that suits my workflow.
Even in Windows 10 it's possible to more or less have the original behaviour after some tweaking.
In Linux, tree support comes and go in file managers. For me that's really infuriating. Programmers in charge of desktop environments wake up some day and decide that I shouldn't be working the way I've been working last 25 years and deprecate it. Not cool.
Edit: it seems PCMan got a qt version. It seems I'll take a look after all.
Swapped Lubuntu 18.10 on an old dell book w xp and was really impressed by everything. Well, everything except the boot time ( and bootloader ) for that matter.
I have been using Linux for for almost 15 years now. Mint, RHEL, CentOS and most recently Ubuntu. For some reason, though, I can't understand all these variations in Ubuntu flavors. For example, other than the Desktop Environment, what else does Lubuntu offer that vanilla Ubuntu doesn't? Can't one just install the desktop environment on Ubuntu? Isn't this stuff modular, take in what you want take out what you don't?
So what exactly is Lubuntu's value proposition over Ubuntu?
Lubuntu isn't really a "different distribution". The different "flavors" of Ubuntu are all the same distribution, they just differ in their default install and settings.
If you remove lxqt from lubuntu, install kde you can morph it into kubuntu.
I've been using Xubuntu for over 10 years. Besides a lighter Desktop environment, I don't know if it offers something else. The advantage over Ubuntu+Gnome+XFCE is that there are fewer packages installed on the system, which means there are fewer compatibility issues and fewer packages to update.
Yes, it's modular and the difference in names is mainly marketing. At the end the packages are hosted by the same infrastructure and switching from one DE to another is just a single apt install lubuntu away, and a single selection in the login screen.
I opted for Lubuntu when I switched back to Linux after a ~15 year hiatus and I'm very pleased. It's really aimed at older/slower computers, but I think it offers the convenience of Ubuntu (easy installation, good online resources for help, large and well-maintained package repositories, fast security updates) without much of what old neckbeards like me dislike about Ubuntu proper. Lubuntu has saner defaults (IMHO), no massive desktop environment or office suites in the default install, is less dependent on Gnome apps, etc.
(Edit: I see now that Lubuntu 20.04 LTS comes with Libreoffice, whereas 18.04 did not.)
I've been using Ubuntu and variants for a long time now. I find lubuntu is ok and small in terms of size. As for older computers, I must have some really slow ass hardware, because even lubuntu is kind of slow on some of my hardware. I stick to standard ubuntu on my desktop just to see what it's like, but prefer xubuntu because I prefer the DE over the gnome crap. I'm used to the more standard keystrokes and shortcuts that you see on windows and the IBM standard which gnome wants to ignore. It's also tough to customize gnome to how I like to do things.
It's nice to have more effort put into making sure the DE and default apps work well together. Sure it's possible to start with the normal or minimal Ubuntu install and put something together yourself, but little incompatible things can easily cause "death by a thousand cuts" and make someone decide that e.g. KDE just doesn't work well with Ubuntu. Default configuration counts for a lot.
> Can't one just install the desktop environment on Ubuntu? Isn't this stuff modular, take in what you want take out what you don't?
Yes to both. I run Window Maker on Ubuntu to the exclusion of any other desktop environment, and it works. It's in the package repositories, and there's no barrier to making it your GUI.
The big difference is the libraries installed in the initial OS install: Ubuntu has the libraries required to support Gnome, Kubuntu has the libraries to support KDE, and I don't know what libraries Lubuntu has by default. But since we have dependency-tracking package management, if you install Ubuntu and then install a KDE-based application, the packaging system will install all of the libraries required for it to work.
The thing is also in the default pack of apps. Say you want a light text editor. Which one do you use? If you select a gnome based one on a kde desktop, you might pull all of kde libs ! So the pack of light image viewer, notepad, calculator form a mini coherent set (a "distribution") that fits well together, but does not justify a full on packaging of kernel, glibc ... hence flavours, not packages or distros.
One problem with just installing the packages for different desktop environments is that various config files in /etc may be optimal for Ubuntu Gnome but a poor experience for Kubuntu or Lubuntu. Installing a different DE doesn’t necessarily change all the other pieces that work best when configured a certain way. For example, I tried i3 briefly on my Kubuntu install once. It changed some configuration and made all my desktop notifications styled completely differently, even when I was using KDE plasma and not i3. Uninstalling i3 didn’t remove the change to my system notifications. I’m sure there’s something I could have done (apt purge? Maybe there was another package i3 installed that I needed to remove?) but I ended up just reinstalling Kubuntu.
Not official Ubuntu, but there is Regolith-linux[0], which is a i3 based system built on Ubuntu. I use it regularly. It is good, but I'm not a power user.
If only LXQt had built-in (not a 3-rd party dock) support for modern Win7/Unity-style taskbar that lets you pin taskbar buttons and use the same to launch and to switch I would certainly give it a try.
I dont know how LXDE was, but I've been running "new" Lubutbu with LXQt for a bit now and I find the various components that make up the desktop a bit odd.
I accidentally deleted my desktop background once while I don't remember exactly which component failed, I remember my desktop wouldnt properly start. I think it was something about pcmanfm-qt (which would no longer start) being so coupled the desktop environment.
I used LXDE in a lot of older machines. It is not very glamorous because the selection of themes icons is not that vast but it uses GTK unlike LXQt.
I have never experienced any odd behaviour or faults. It certainly is not the most beautiful desktop environment but it is stable and very very performant.
It's quite understandable given that they're completely changing the distribution from one with software built from GTK libraries (LXDE) to one based on Qt libraries (LXQt). Such a dramatic change is pretty much a once-off event.
I recently tried reinstalling Lubuntu on a netbook with a very small EMMC (4GB if I’m not mistaken) and couldn’t find a way to slim down the install to the bare essentials.
(It was running 14.04, and that, I think, had a CLI installer with package selection)
Anyone know if 20.04 lets you install without LibreOffice and the like or have some tips on how to get to the old installer?
122 comments
[ 2.4 ms ] story [ 189 ms ] threadBut maybe I'm overlooking something, so if somebody with a distro maintainance or third party appdev background could share why settling on snaps causes trouble or undue extra work or is less-than-optimal I'd appreciate it.
Can you please write who "everyone else" is?
Is quite a surprising note for an official Ubuntu flavor.
Ubuntu focuses its efforts on ill-advised efforts like writing its own compositor (Mir) and Desktop environment (Unity).
Currently, most work to advance the Linux desktop is focused on a new project called Wayland (Used by Fedora for last few releases), yet Ubuntu has decided to double down on X11, a legacy project that clearly has no future and has issues like screen tearing that are basically impossible to fix.
Another tangible example related to developers: On Fedora/Arch you can run docker containers without requiring root due to Red Hat's work pushing podman forward, however you cannot do this on Ubuntu/debian because they lag behind upstream
What was wrong with unity? Plenty of people preferred it.
Also Mir was ill-advised back in 2013 and was dropped in like 2017.
Wayland has been around as long and is only just becoming usable.
Or are you saying that Ubuntu should have funded Wayland development?
Any proof they're "doubling down" on Wayland?
If Ubuntu isn't pushing desktop Linux forward. Gentoo, Arch or Fedora sure ain't.
Also lol. Podman seems to be an alternative to docker. Why should I use that? Why isn't that ill-advised? Is it because Red Hat made it?
What's wrong with this?
https://docs.docker.com/engine/security/rootless/
See details here: https://developers.redhat.com/blog/2019/02/21/podman-and-bui...
I'm not sure what you mean by Ubuntu doubling down on Wayland. They have no plans to migrate to Wayland.
Honestly it seems like a clone of docker selling the slight advantage of root less.
Which docker already does.
I don't understand why I should care that it's a Daemon. In fact that blog post says that they won't go into why it's bad. Just that they do things different.
In fact it seems like it's a "Not invented here" implementation from Red Hat.
Searching Hacker news there's not many posts on it. Seems like it'd be as silly as using Mir to run this in production.
Also on my doubling down, I misquoted you saying they're doubling down on X11.
There doesn't seem to be any evidence of this. I wasted time googling it and it looks like they decided not to use Wayland by default in 20.04 because of certain bugs they didn't deep acceptable.
But it comes with Wayland out of the box, and you select it on the login screen.
I'd never run Ubuntu on the server by choice, mind you, but servers are constrained by other considerations.
I see a lot of people in IT who don't directly do systems-related work (think of QA people for example).
Without Ubuntu they'd be either running mac os or windows.
Ubuntu lowers the bar of linux-on-desktop accessibilty by a lot.
For a lot of people it's okay not to have a good understaning og how all the components fit together.
I don't know how it is now, but many years ago it was a running joke that most Gentoo users hadn't the faintest idea of how anything worked, but felt "hardcore" because they could pass many command line flags to the build and felt they were "optimizing" their system -- actual gains were not demonstrably noticeable, but they "felt fast" -- and they had no understanding whatsoever of gcc flags for example. Experienced users had to patiently explain that no, you shouldn't pass that experimental flag to gcc or everything would break.
"Hardcore" Gentoo users believed that by "installing from source" they somehow magically ended up with a faster system. No empirical evidence, of course, just a heartfelt belief compiling source code was magical.
This kind of "hardcore" Gentoo users was very, very, very annoying. Users of Ubuntu were better off: they understood what they worked with regularly and didn't pretend to understand what they didn't need to understand.
I've tried one such "hardcore" distro once (Crux to be exact) and while it was fun for a while, I also wasted a lot of time. Nowadays, I just stick Ubuntu Flavor (am actually running Lubuntu right now) because everything works mostly out of the box. Yes, I know it has its own set of problems, but I have different priorities. I dont particularly care if I get labeled a noob for it.
I'm not saying everyone should run Gentoo, I'm just saying that there is a much more of a justification for Gentoo existing than Ubuntu.
Ubuntu just re-invents the wheel with a bunch of nonstandard stuff so Canonical can sell support see AppArmor, Snaps, Mir, Unity etc...
For similar reasons (stability), I always go for the current stable (although I've a couple machines on oldoldstable, because it takes a while to upgrade...).
i would assume that testing should be rock solid.
I never could bring myself to ask if they were ok with being down for 2 weeks if they needed to re-install. Say, in a case where they had an intrusion and didn't trust their backups...
Really, though, nowadays compiling everything, even compiling things for optimal performance, doesn't take that long. Your production machines shouldn't have web browsers, and without the C++ garbage behemoths on it, compilation takes like half an hour on most machines.
I'm not a Gentoo user, but it's kind of silly to act like it makes recovering substantially harder than any other distribution.
Another interesting point from these times: it was even then often written that the Linux and Ubuntu are better for the use of older computers compared to Windows. That wasn't true either. With every new version less of my hardware worked as expected. The memory demands only for the GUI installer were bigger than the demands of Windows, forcing me to attempt to install from the text mode, and still having the issues later. Windows just worked on the same machine (with the existing drivers).
I've also lived through my (other) old hardware breaking on Windows too: my notebook on which all the hardware worked as expected on Windows 7 was declared by the Windows 10 as "totally would work" and it totally didn't -- the Intel devices on it never got the drivers that worked on Windows 10, neither by Microsoft nor by Intel who simply stopped supporting them.
No OS is immune from the scenario (or even the company claims) "it will work" which than turns out not to be true with a new version.
Long story short, in this case, backup your /home, install from scratch. Backups are good anyway. Any other attempt will probably give more pain. Also don't expect the newest OS to always work with the old hardware. Be prepared for these kinds of events too.
For a real long term, there's Red Hat.
I pin my Debian machines to the "Testing" branch and "apt-get dist-upgrade" once a month, and I've never had a problem, except once or twice when NVIDIA drivers needed to be re-installed. It's worked great for me for 15 years, but YMMV.
The CPU/memory usage almost certainly has more to do with the software being used than with the distro. The Linux kernel and GNU system utilities can run on very low resource machines, but most "desktop environments," like GNOME, KDE, and even XFCE, are targeting up to date systems. IME, using old hardware usually means putting in some effort to find and configure software that will run well on it - I'm pretty sure it's the same on any OS.
I've personally had the same install across six Ubuntu installs in total and I know other people like that as well. Anecdotal experience but so is claiming Ubuntu's breakage ratio is higher.
"the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install."
Note that 18.04 was also LTS, so whoever tries to upgrade from one LTS to another, will probably be able to start the process (like before) but at the end will with huge probability be better off just biting the bullet... and fresh install.
If the "people you know" upgrade faster then LTS to LTS they won't see a problem this time.
But being able to upgrade from one LTS to the next LTS is completely reasonable user expectation. I don't even want to try to prove that it will be broken this time.
The one I replied to said Ubuntu not Lubuntu. Big difference.
There are certain situations where a Debian upgrade will break a specific package - maybe due to upstream messing up really badly, or maybe due to some unusual way of configuring it. But in that case, the release notes that Debian publishes for each release would cover that particular problem for sure. Mistakes happen, and noone's perfect - but Debian tries to be, and they're very near that ideal in terms of ensuring your ability to upgrade your installation.
Personally, I don't think that Ubuntu is less perfect that Debian wrt. upgrade quality, it's just that (it seems to me that) the workforce is not as large, and that they also have other projects on their plate (not to say it should be that way or not, I'm merely trying to state the facts).
So if libreoffice depends on package P, and that one is not ready, is Debian going to simply drop libreoffice until next release?
At a very high level, it works like this:
New versions of stuff go into Unstable. When they've been tested a while they get pushed to Testing. Periodically Testing is frozen and branched into a new Stable release. If a package doesn't make it into Testing before the freeze then it's out of luck and has to wait for the next release.
For example, assume libreoffice 1.0 and libfoo 1.0 are in Unstable, Testing and Stable. If libreoffice 1.1 comes out and depends on libfoo 1.1, but libfoo 1.1 is broken in Unstable, then libfoo 1.1 and libreoffice 1.1 won't be pushed to Testing until the issue is fixed. If they don't make it into Testing before the release freeze then the next stable will ship with libreoffice 1.0.
After the freeze, when the libfoo 1.1 is fixed in Unstable, then libreoffice 1.1 and libfoo 1.1 will go into Testing and wait for the next Stable to get branched.
In order of stability from most to least.
LTS -> Bleeding Edge -> 6 month release cycle distros
Stuff like Ubuntu non LTS seems to break as much as bleeding edge but take longer to fix it. It's the worst of both worlds.
This is not tenable, really.
The things I change are all over the place. From say /var/lib/mysql to /usr/local/bin and of course various /etc things ... it's not enough to say "backup /home and wipe the rest".
A dose of a "normal-user"-hostility is kind of a given in Linux platforms, the best reflected by:
https://xkcd.com/619/
and sometimes it's, unfortunately, unavoidable for us when we are in the user's role to have to "just change as root that x y somewhere."
Long term, the goal should be to raise the awareness that there is a real need for most of the configuration to be easily transferable from the installation to the installation. But what we get instead is "just change as root wherever" and the containers for containers being run in the containers -- more bloat, but still not less demanding to maintain.
I really think Red Hat is not appreciated enough for their work on maintaining stability. The optimal solution will be when we have really stable platforms on which we will be able to easily and cheaply have recent languages, but also stable. Knowing how unstable practically a lot of programming platforms are, I am aware we're still not there. But... raise the awareness!
Arch is like the CI/CD analogue of operating systems. Small upgrades makes breakages much less common, and much easier to repair. This comes as a trade-off of less battle-tested stability than e.g. Debian, but if you're able to make small repairs proficiently then Arch is the way to go. I'd strongly recommend Arch on a personal computer - it makes a good OS for a pet (although Debian, because versioned releases are much more thoroughly tested, makes for much better cattle OS).
I wonder how's Arch in that regard. You speak about breakage less common, but there has to be some significant breakage from time to time: for instance, for a shift as important as moving from traditional sys-v init scripts to systemd, it must be expected that a lot of OS configuration related packages would break, unless every package maintainer is made aware that this change would happen, and that he/she has to prepare its package (if necessary) to that shift, AND that the shift only happens when everyone's ready. But Debian (and I suspect Arch as well) do not follow such a rigid scheme, and so there has to be breakages and fixes to follow.
When you install arch, you install each piece on-demand. So only the pieces you have chosen are dragged through updates.
my arch installations tend to be quite lightweight.
That may explain why you don't get that many problems.
If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish.
I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that. The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems.
The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation?
Or maybe there's too much friction between distros and upstream developers?
But if you've made that choice, you will likely be more aware of what you're dealing with.
There are definitely valid reasons to go with big-upgrade-every-year-or-two kinds of distributions. It can make developing software that depends on other software easier, especially if you need binary compatibility. A book or article about that system won't be out-of-date immediately.
Personally I wouldn't mind a few spread-out glitches throughout the year compared to frantically trying to repair a broken system after a dist-upgrade and losing a weekend.
I have had a few glitches with arch, but I think they were mostly some manual intervention for signing keys and didn't harm the system.
But sadly I also really can not recommend it, to anyone who does not know english, nor the command line (or have someone close, who knows).
If you're not on LTS, then you should upgrade every 6 months when the OS tells you a new distribution is ready, and you'll be fine.
[1] https://wiki.ubuntu.com/PointReleaseProcess
To me, it felt like they started believing themselves to be great innovators in an Apple model of "we know what's best for you, this is revolutionary. You'll take it and you'll like it. Witness our works and tremble." [1]
I may be slightly hyperbolic there, but I worked on minor bits of the gtk code base and the way some of lead devs were talking I found frankly alienating.
To be fair there were also practical reasons to limit customization for greater testing coverage and I think some of the changes were driven by RedHat's move towards being an enterprise vendor. But those changes in addition to the change in tone I was hearing was jarring.
In any case several efforts attempted to move forward with the earlier code base or at least with the earlier philosophy. And I found one that was near enough to ok.
[1] and eventually stuff like https://www.omgubuntu.co.uk/2019/05/open-letter-stop-gtk-the...
Whereas apple stuff generally just works on the desktop, is super polished and generally fast, gnome3 is cumulatively an amass of crap.
Which is very bad because gnome2 used to be very functional.
They tried to become Apple, but they are not.
They literally dumbed down the whole thing.
Even in Windows 10 it's possible to more or less have the original behaviour after some tweaking.
In Linux, tree support comes and go in file managers. For me that's really infuriating. Programmers in charge of desktop environments wake up some day and decide that I shouldn't be working the way I've been working last 25 years and deprecate it. Not cool.
Edit: it seems PCMan got a qt version. It seems I'll take a look after all.
I have been using Linux for for almost 15 years now. Mint, RHEL, CentOS and most recently Ubuntu. For some reason, though, I can't understand all these variations in Ubuntu flavors. For example, other than the Desktop Environment, what else does Lubuntu offer that vanilla Ubuntu doesn't? Can't one just install the desktop environment on Ubuntu? Isn't this stuff modular, take in what you want take out what you don't?
So what exactly is Lubuntu's value proposition over Ubuntu?
It also has zram configured by default, if I remember right.
I've never used it, but unlike most spins of distributions, it seems to have some interesting changes to the base.
Lubuntu isn't really a "different distribution". The different "flavors" of Ubuntu are all the same distribution, they just differ in their default install and settings.
If you remove lxqt from lubuntu, install kde you can morph it into kubuntu.
Now, it's been forked and resurrected as LXQt, which uses the Qt framework (KDE faction) as opposed to GTK (GNOME et al faction).
It was a DE for when your 2003 laptop is so weak or when your neurotic minimalism is so hellbent that even Xfce feels too heavy.
Now, I guess it can also be a Qt-flavored Xfce.
(Edit: I see now that Lubuntu 20.04 LTS comes with Libreoffice, whereas 18.04 did not.)
Yes to both. I run Window Maker on Ubuntu to the exclusion of any other desktop environment, and it works. It's in the package repositories, and there's no barrier to making it your GUI.
The big difference is the libraries installed in the initial OS install: Ubuntu has the libraries required to support Gnome, Kubuntu has the libraries to support KDE, and I don't know what libraries Lubuntu has by default. But since we have dependency-tracking package management, if you install Ubuntu and then install a KDE-based application, the packaging system will install all of the libraries required for it to work.
Maybe they don't want to confuse the new users with choices they don't understand, and give them the most reasonable defaults they can.
And I did give Xubuntu, Lubuntu and Unity an sincere chance.
For hardcore work sessions nothing beats i3wm productivity tho.
[0] https://regolith-linux.org/
I accidentally deleted my desktop background once while I don't remember exactly which component failed, I remember my desktop wouldnt properly start. I think it was something about pcmanfm-qt (which would no longer start) being so coupled the desktop environment.
I have never experienced any odd behaviour or faults. It certainly is not the most beautiful desktop environment but it is stable and very very performant.
(This was using Debian + LXDE)
(It was running 14.04, and that, I think, had a CLI installer with package selection)
Anyone know if 20.04 lets you install without LibreOffice and the like or have some tips on how to get to the old installer?
This is an old Xubuntu article, but describes the general approach for a minimal install: https://xubuntu.org/news/introducing-xubuntu-core/