Ubuntu 21.10 Systemd To Finally Ship With Cgroup v2 By Default

[phoronix]

Phoronix: Ubuntu 21.10 Systemd To Finally Ship With Cgroup v2 By Default

Ubuntu developers acknowledge "delaying this for a long time" but for Ubuntu 21.10 they are planning to ship its systemd package with the unified cgroup hierarchy (Cgroups v2) by default...

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-21.10-systemd-cgroup

[Hibiki Kanzaki]

cgroup v2 is a vast improvement regardless of anything to do with systemd.

[evil_core]

So now technology is held back by this 'fantastic' containerizing technologies like Snaps, Appimage, Flatpak, Docker, etc, they are trying to push deep trough our throats ;-)

I'm glad I'm not using using Ubuntu, that become slave of their previous 'innovations', like pushing bloated containers, that takes space at HDD at least 10* more than packaged as .deb, with shared libraries(and other components). This madness should be stopped long ago. It's "Microsoft Windows" way of deploying apps.

[RahulSundaram]

So now technology is held back by this 'fantastic' containerizing technologies like Snaps, Appimage, Flatpak, Docker, etc, they are trying to push deep trough our throats ;-)

You are confusing multiple things which aren't really similar to each other. Appimage for example is just a compressed image. Flatpak isn't affected here since Fedora moved to using cgroups v2 several releases back.

[evil_core]

You are confusing multiple things which aren't really similar to each other. Appimage for example is just a compressed image. Flatpak isn't affected here since Fedora moved to using cgroups v2 several releases back.

I haven't said they are also affected, but think that some technologies designed to solve some problems, are subpar and flawed.
"Dependency hell" wasn't problem for distributions that managed them right.
They are bundling now whole linux distro with every app. It takes HDD space, uses much more RAM (because libraries aren't shared. But who cares in times, when apps aren't optimized at all)
I hate everything that uses more space, than it should and makes things more complicated and complicated. Instead of three common package formats (RPM, DEB, Arch's PKG), people invented at least 3 different container formats.

Look at old DOS/SNES/NES/Sega games distribution at GOG or Steam. Things that originally took 6-30MB takes 500MB-2GB, because all this containerization and wrappers.

[RahulSundaram]

I haven't said they are also affected, but think that some technologies designed to solve some problems, are subpar and flawed..

You said "So now technology is held back by this 'fantastic' containerizing technologies" which implies that they are affected. I am just pointing out some of these are neither container technologies nor are they affected. Whether you like them or not is a different topic.

[evil_core]

You said "So now technology is held back by this 'fantastic' containerizing technologies" which implies that they are affected. I am just pointing out some of these are neither container technologies nor are they affected. Whether you like them or not is a different topic.

As you know early libpulse implementation in pipewire had to be scraped, because non-compatible with containers. There are more and more problems, because containers becomes often unmaintained and incompatible with new technolgies. There ere more and more problems with them over the years. I would love if they would be scraped, but new software is more and more often distributed this way.

[oiaohm]

I haven't said they are also affected, but think that some technologies designed to solve some problems, are subpar and flawed.
"Dependency hell" wasn't problem for distributions that managed them right.

What distribution was that. Only one I know of is like NixOS that did end up costing more storage and ram as well.

They are bundling now whole linux distro with every app. It takes HDD space, uses much more RAM (because libraries aren't shared. But who cares in times, when apps aren't optimized at all)

This is not all the same. Flatpak does not install a whole Linux distro with every application. So the idea that applications are not being shared in the flatpak cases is not 100 percent true because they are being shared with other flatpak applications.

I hate everything that uses more space, than it should and makes things more complicated and complicated. Instead of three common package formats (RPM, DEB, Arch's PKG), people invented at least 3 different container formats.

True over 3 different formats of containerisation but they are not created equal.

Look at old DOS/SNES/NES/Sega games distribution at GOG or Steam. Things that originally took 6-30MB takes 500MB-2GB, because all this containerization and wrappers.

Steam with its containerisation is using a form of shared containerisation like flatpak as well. So the first application costs a lot with steam the next application not as much because the runtime is being shared in most cases.

Both Steam and flatpak are more distribution or a handful or distributions for all the application installed from there sources. This does not result in distribution per application. ostree is naturally de-duplicating behind flatpak. This is important 2 flatpak applications install the same library in there applicaiton directory in the same flatpak path interesting point ostree in background de-duplicate that. Yes a de-duplicated library by ostree or the filesystem does result in the Linux kernel using basically the same amount of ram as if they were the same file in a single path just the file is appearing in two places on filesystem. There is more than 1 way to share libraries.

Docker and snap are still quite a mess. Snap said there starting a duplication solution in 2015 and have still not solved it. Docker there was a few attempts in 2020 still not a good fix.

[jacob]

So now technology is held back by this 'fantastic' containerizing technologies like Snaps, Appimage, Flatpak, Docker, etc, they are trying to push deep trough our throats ;-)

I'm glad I'm not using using Ubuntu, that become slave of their previous 'innovations', like pushing bloated containers, that takes space at HDD at least 10* more than packaged as .deb, with shared libraries(and other components). This madness should be stopped long ago. It's "Microsoft Windows" way of deploying apps.

Well why don't you look some things up before starting another whinefest? Fedora (with Flatpak) has supported cgroupsv2 for a while and Ubuntu is actually getting it, so no, you are not being "held back". Flatpak doesn't inherently take more space than traditional packages when you account for their dependencies, snap does to some extent but it's not nearly as dramatic as some would want you to believe. You know, just because something is the "Microsoft Windows way of deploying apps" doesn't necessarily mean it's a bad way.

[arQon]

You know, just because something is the "Microsoft Windows way of $thing" doesn't necessarily mean it's a bad way.

Although in fairness, it USUALLY is. :P

He's wrong on multiple fronts though: first off, what he's describing is the OLD Windows model; and secondly, the current Windows model - SxS - is, as you say, vastly superior to anything other than the "ideal" of "just" having everything in the distro rebuilt at the same time and working the exact same set of libs. And in practical terms, SxS is still better than that as it allows you to add packages that potentially have conflicts because of bugs. (e.g. P1 requires libxyz3, but xyz3.0 is missing a function that P2 requires from libxyz3.1, but 3.1 also includes the fix for a bug that P1 happens to depend on, etc).

Not saying SxS isn't a pain in the ass :P - but it does solve this problem better than anything else so far, so any "new" packaging system that doesn't implement something at least that good is implicitly being held back by either incompetence or for "religious" reasons, neither of which is a good sign.