I know I’m not making a helpful contribution here, but I’ve been wondering about this stuff for a while myself and this thread has some great answers. Thanks for asking this OP.
fedora is usually more updated(newer packages and newer kernel) and it uses zram, ubuntu use swap from default, and ubuntu push snap, fedora, like others, come with flatpak pre-installed
Just wondering if there could be a way to “simulate”, lets say ubuntu on fedora.
ZFS is a crazy beast that’s best for high end server systems with tiered storage and lots of RAM.
ext4 is really just a basic file system. Its superior to NTFS and fat as it does have extra features to try to prevent corruption but it doesn’t have a large feature set.
Btrfs is kind of the new kid on the block. It has strong protection against corruption and has better real world performance than ext4. It also has more advanced features like sub volumes and snapshots. subvolumes are basically virtual drives.
Another few older options include things like XFS but I won’t go into those.
Yes, but most filesystems are already optimized for flash storage. Arch wiki says f2fs is prone to corruption on power loss. Based on that and the lack of information on its anti-corruption measures I’m inclined to think it doesn’t have one and that’s why it’s faster. I wouldn’t use it in a non-battery operated device.
Catastrophic battery failure isn’t really any less likely than catastrophic power supply failure (conceptually. If you use a brandless grey power supply, results may vary).
That link is for kernel 5.14, so I’d say those results are pretty much invalid for most users (unless you’re actually on it, or the 5.15 LTS kernel). There have been a ton of improvements in every filesystem since then, with pretty much every single kernel release.
A more relevant test would be this one - although it talks about bcachefs, other filesystems are also included in it. As you can see, F2FS is no longer the fastest - bcachefs and XFS beat it in several tests, and even btrfs beats it in some tests. F2FS only wins in the Dbench and CockroachDB benchmarks.
Not quite. Bcachefs can be used on any drive, but it shines the best when you have a fast + slow drive in your PC (eg NVMe + HDD), so the faster drive can be used as a cache drive to store frequently accessed data.
The differences between distros are the things you mentioned. They all use the Linux kernel, so the differences are in the DE, installer, theme, default packages, and package manager. These changes come about from design choices: rolling vs versioned releases, stability goals, FOSS vs proprietary packages/repositories, things like systemd vs alternatives, and overall goals/use cases (lightweight, server, etc).
A distro can be as little as a theme change. The famous Hannah Montana Linux is KUbuntu with a custom theme, icon pack, and Hannah Montana as the background.
So basically if i have all Voidlinux’s programs installed on NixOS, i can have some decent amount of packages (that are not heavily depending on init systems or some other non trivial stuff) from Void repos running on NixOS?
I wouldn’t compare void and nix since both of them follow very different approaches. Void is more like a traditional distro while nixos on the other hand uses configurations for setup.
And no you can’t use void on nix os as said above. Hannah Montana linux and kubuntu uses Ubuntu as the base that’s what he meant.
Im not talking about comparing these distros, nor using void on NixOS. Im asking if i had all packages that are preinstalled on void, present on NixOS as well. Would i be able to run some packages from void linux repos on NixOS? If i make nix derivation with package from void repo and install it, would it work?
If the same void package exists in the nix os repo then sure. You can’t use a void package in nix os is the thing I would like to point out other than using distrobox.
Who made Red Hat the arbiter of when xorg should end?
I mean, sure they’re a major Linux vendor but their market is servers with hardly any foothold in the desktop market. It would be more interesting to see how long Debian, Ubuntu or Arch will keep xorg alive.
Redhat does a lot of testing/patching with Xorg Server.
most of the people who was working on Xorg Server moved to Wayland a few years ago, Ubuntu and Debian have been Defaulting to Wayland, on the main Desktops, and Desktops are dropping Xorg Server support in Development, this is not just Redhat.
No Patches and No $$$,$$$,$$$ = Xorg server dead. if you want to pay 15 to 20+ Software Engineers/Testers to work on Xorg Server got for it.
FreeBSD has Wayland support to.
Even the Xorg mailing list is mostly dead, many of the Xorg Server Dev’s moved on, XWayland will be long lived.
and last i was there for all the Crying about XFree86 to I’m old.
People are completely missing the point here. “Who made Red Hat the arbiter of when Xorg should end?”
I would say nobody but perhaps a better answer is all of us that have left the work of maintaining Xorg to Red Hat. All that Red Hat is deciding is when they are going to stop contributing. So little is done by others that, if Red Hat stops, Xorg is effectively done.
Others are of course free to step up. In fact, it may not be much work. Red Hat will still be doing most of the work as they will still be supporting Xwayland ( mostly the same code as Xorg ), libdrm, libinput, KMS, and other stuff that both Xorg and Wayland share. They just won’t be bundling it up, testing it, and releasing it as Xorg anymore.
So little is done by others that, if Red Hat stops, Xorg is effectively done.
Source?
As far as I know the X.org foundation is an independent non-profit organization, and while Red Hat is a sponsor and they have 1 member in the board of directors (out of 8), they don’t appear to be the main contributor.
As the video points out, a lot of the work in xorg (and Linux in general, fwiw) is done by red hat engineers. So red hat cutting on that investment bears direct consequences for everyone else. Unless of course someone steps up and takes their place in maintenance, but it’s not gonna happen, which is literally why Wayland (and not some revamped xorg) is the future of Linux desktop.
Also, red hat’s decisions often trickle down on most other distros. E.g.: systemd, pulseaudio, pipewire, gnome, not including proprietary codecs, etc.
So, they technically don’t arbiter, but they definitely set the pace.
By whom? Red Hat is pretty much the only one supporting X.Org so that’s why. Development will not really continue because there will be nobody to do the development.
Would it be enough to be able to run .deb packages on fedora?
Unpacking a .deb on Fedora, or unpacking an .rpm on Ubuntu isn’t a big deal. The files inside are often actually identical.
But would not be useful because the files inside usually rely on shared libraries, which may or may not already be installed. Those shared libraries are installed in different places on each Linux distro. Figuring out which ones to ask for (and making sure the program can find them) is the real work that the .Deb or .RPM installers do.
A fun way to try this out is with Portable Apps. Anything called a “portable app” either doesn’t use additional libraries, or carries the libraries it needs with it.
If you find a portable app for Ubunutu, there’s a good chance the Fedora version is an identical file, and works fine on Ubuntu. There’s lots of reasons it might not work, but it can be fun to try.
For the most part, the only reason any Linux program is unavailable on a different version of Linux is that no one has bothered to build the necessary installer for that combination of program and OS.
.RPM was supposed to solve this by being universal, since any other OS can implement it to match .Deb was supposed to solve this by being universal, since any other OS can implement it to match (about 60% actually do). I think Flatpacks and Snaps might solve this by being universal, at some point…
Source: I’ve built installer packages for various operating systems.
You can use distrobox to run ubuntu on fedora and fedora on ubuntu.
Imo the difference isn’t too big. If you know what you do, your system will look roughly the same on ubuntu and fedora. Same packages, same workflow etc.
If you keep the base packages constant, i.e. with a immutable distro, you can compare it much better, imo. The experience on Fedora silverblue and opensuse microos will be almost the same for the usual end user. Both are immutable systems, you install packages via flatpack, command line tools via distrobox. System keeps itself up to date. One is standard release, one is rolling.
Flatpak and distrobox offer sandboxing and reproducibility. Imo you want both on a regular install as well which almost make a traditional install like an immutable system, yet you are not as discouraged from installing packages onto the base layer.
If I’d be asked what the difference between fedora and ubuntu is, then I’d say the company behind it from which you get tech support. That’s mostly it.
ext4 certainly has its place, it’s a fine default file system, there’s really no problems with it.
But others, like ZFS and BTRFS, have features that you may want to use, but ext4 doesn’t do: fs snapshots, data compression, built in encryption (to a degree, usually only happening for data and some of the metadata, so LUKS is often better IMHO), checking for bitrot and restoring it when possible (whether it is depends on your config), quotas per user group or project, spanning multiple disks like with RAID but safer (to a degree), and others.
On the surface, the biggest difference between distros will be the package manager and the update cadence. Most package managers are generally comparable so I won’t get into that. The cadence has to do with release type - rolling or fixed - and the speed with which updates are released. Do you want the newest packages, LTS or somewhere in the middle? This is probably the first big decision to make when choosing a distro. The only real must-have here is you want a distro that provides timely security updates. Even a highly stable LTS should be pushing out security updates asap.
Then you have default package choices, which are often superficial like DE or default apps. This can all be changed so it’s not much of a concern. But there could also be more impactful choices like whether a distro uses systemd or glibc vs musl. The mainstream distros tend to use systemd and glibc, which is generally good, but know that you have other options if your specific use case requires it. There’s also package availability, meaning the number of packages available in the repository, although this is less important than it used to be because you have options like Flatpak or Nix for getting packages that aren’t in your distro’s repository.
There are also some distros created with a specific use case in mind, such as Alpine for containers or Kali for testing network security.
Finally, you have structure and governance. Some distros have corporate backing, others are community supported and still others aren’t much more than a hobby. The ones with corporate backing typically have options for paid support. In general, you want something with stable and competent governance where it will continue to thrive even as team members change. You can find examples of this in corporate-backed distros as well as community distros.
So your biggest choices are going to be cadence, structure/governance, and whether you may need paid support now or in the future.
As for what distro developers actually do… First, they build the tooling and infrastructure to make their distro work - package manager, packaging tools, repository, etc. Then, they are responsible for packaging everything available in the distro. They are pulling in source code for all these apps, compiling it and putting binaries in the repository. They rebuild packages as required when there are updates to the source code. Some distros like Arch will build vanilla packages, meaning they don’t make changes to upstream code. Others may apply their own patches for various reasons. Some like Red Hat will provide patches to upstream apps requested by customers as part of their paid support services. So let’s say something isn’t working the way you need it for some random FOSS app included with the distro. You can put in a request and they will change it for you.
As for your specific question about simulating Ubuntu on Fedora, that is not possible. They each use their own distinct package manager and repository. They generally have similar packages, but they are not interchangeable. However, there are tools like distrobox and distros like VanillaOS that have mechanisms for using another distro’s packages. These use containers under the hood so it’s not quite the same as just installing .deb on Fedora or .rpm on Ubuntu.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.