Sure.

But “missing significant foundational and complex functionality is not really a bug”, it is a feature. I mean, I guess I could file a bug that says “won’t run ALL Windows software” and talk about how long it stays open.

As each of these dominos falls, it gets easier to add more functionality on top. I feel like they have made more progress in the past two years than they have in the 10 before that.

This is a dramatically misinformed comment. You have clearly never used Distrobox.

1. The first bullet is the worst. This is like saying that Flatpak will break your host. It will not break the host OS. Learn what a container is.

2. It is not tools on top of tools. It is tools in a container that you can optionally create entries for in your app menu. Apps in the container execute directly on the host kernel in the container. If you are in a shell, you are either in the container or out and the full environment will reflect that.

3. It is not for “new users”. That said it dramatically simplifies many intermediate ones and make some advanced things possible. Once again though, there are no “stacks on stacks”.

4. The exact opposite. Containers do not change the host. If something goes wrong in the container, you can purge it completely without impacting the host.

In fact, one of my core uses for Distrobox is to keep my host system clean. I use Distrobox to setup dev environments, to try out new software, to work around Distro constraints, and a host of other tasks. It is great.

There seems to be quite a fundamental misunderstanding of what a container is. Everything runs directly on the host kernel. Apps outside the container run on the host OS and do not interact with the container. Apps in the container run in the environment inside the container. The only interaction apps in the container have with the host is the kernel, the filesystem, and via servers like Wayland, Pipewire, and XDG portals.

The entire point of a container is to create an application environment that looks exactly like an application expects regardless of system it is running on. It is clean and consistent between deployment. This is the exact opposite of what the above comment implies.

In practice, it “feels” like apps in Distrobox are running native on the host OS but in fact everything above the kernel is running inside the container and each container is distinct from the others.

The “example” is totally wrong. GCC is either on the host or it is not (from the host). GCC is either in the container or it is not. They do not interfere with each other. They do not even share C libraries. However, the can see the same source files.

Distrobox is absolutely nothing like Homebrew. Homebrew is a package manager. If you are using a package manager in Distrobox, it will be the one intended to work with whatever distro you are running in Distrobox. This is a fantastic illustration of the confusion of ideas at work here.

If you have to compare Dostrobox to something, compare it to Flatpak.

One small downside…

This is not in FlatHub and it is not an official part of the VirtualBox KVM project from Cyberos Technology (the folks that make VirtualBox KVM).

This is a project from GitHub user tulilirockz

Well, let’s see. The UK wants mandatory ID because today you can walk in to an hospital and get $100,000 of free healthcare without even proving you are entitled to it. And you can maybe work without paying taxes. And you move freely and safely anywhere in the country.

In the US, if you do not have proof of citizenship on you at all times (and maybe even if you do), you may be snatched off the street, detained, and perhaps even sent to a foreign prison all without due process of any kind.

Wow, now that I say it out loud, you are right. The UK sounds like a hell-hole.

You cannot even decouple SystemD from Glibc, never mind separating the various components from each other. It is a bunch of processes but it is designed as a monolith.

If I understand, this is less a complaint about how UNIX works and more a story about the consequences of careless mistakes.

This is why we have KVMs I guess. Though not every server has one of those.

While I understand the sentiment, we have to understand that Open Source developers work on projects that motivate them.

So, we can have a single example of each of these but they do necessarily get any more devs. In fact, if you take economic theory ( competition for example ), it is likely they attract less attention individually than they do competing as part of an ecosystem.

It would certainly help on the user acceptance and commercial software side where choice is an impediment. But, if we are just talking resources, limiting the number of projects only works if you pay people to work on them.

Why was each of these projects started ( eg. window managers )? The answer is simple. It is because the founding developer did not like any of the existing options.

Not sure why the downvotes. The good news is that we should be very close to the end of that with GIMP 3 out very soon.

Earlier in the year they announced that it was expected in July or so. I hold out hope that they at least get it out this year. Once it is out, all will be forgieven. Let’s hope that we do not see as long of a delay next time.

I fully support this comment. Thank for attributing the FSF itself.

Historically, we owe a lot to the GNU project as well. I wish people understood what GNU was though and how GNU and the FSF differ from each other.

There is no such thing as “community-driven” and “RHEL compatible”. If they are actually going to do their own work to create an enterprise Linux distro, it is not going to be bug for bug compatible with RHEL. The only way to get that is to copy RHEL exactly in which case any actual “community” contribution is a bug ( deviates from the goal of being identical ).

I do not love what Red Hat has been doing lately but all this cheerleading for these companies acting entirely in their own commercial interest under the banner of “community” has been very hard to watch.

Red Hat wanted to make it a bit more work to make identical copies of their distro and to water down the claims from copycats that they are truly identical. In response, some of the copycats have joined forces. This both reduces the burden on them individually and provides an alternative source of credibility that they can rely on. In the end, despite all the fireworks, barely anything will have changed for most of us. The mechanics of how RHEL clone get built have been altered somewhat but otherwise things are mostly as they were.

If I am proud of my father, that is weird to you?

Are these real stats? Or just a directional commentary that Lemmy is growing? If they are real, where can we see these?

Lemmyshitpost@lemmy.world does not immediately imply credibility.