Hey guys! Trying to understand what developers actually do to create a yet another distro, or what are the differences between existing distros. Lets say we have ubuntu and fedora. What are the differences? Excluding DE, Installer, theme, installed packages/libs and package manager. They both are FHS compliant, both running systemd what else?

Just wondering if there could be a way to “simulate”, lets say ubuntu on fedora. For example providing every program that should be present on ubuntu in fedora. Would it be enough to be able to run .deb packages on fedora? Im not gonna do that though, just curious about this question.

Thank you!

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    27
    ·
    11 months ago

    This is a great question!

    It’s hard to really wrap your head around it without doing a ton of low-level taking things apart and putting them together differently.

    But to answer, it’s pretty impressive the extent to which a full Linux install of any distro tends to just be like a bunch of legos put together in one particular way.

    Theoretically, there’s no reason why you couldn’t ship-of-Thesius one distro into another. You’d have to have a good idea of what the differences between the two are, but it can certainly be done.

    There’s a thing called a “chroot.” It’s basically a whole OS installed in a subdirectory on another whole OS. And there’s a command (also called “chroot”) that can be used to tell the parent OS to “give me a shell in the chroot OS – as in run the /path/to/chroot/bin/bash (or whatever) executable in ‘The Matrix’ such that that process thinks that the chroot is the root OS.”) That lets you do some pretty cool stuff like building an OS to be installed on another box. But when you run in the chroot, it doesn’t load the guest OS’s kernel or (typically) init system or anything. The processes run on the host system’s kernel.

    And it’s entirely possible to have the guest chroot system be a whole different distro than the host. (Though some distros will have tools that make it easier to chroot into a guest chroot of the same distro.) Which implies that you can just kindof substitute one distro’s kernel for another distro’s, right?

    Turns out the answer to that question is “at least mostly yes.” Quick funny personal story. I started working somewhere recently where they allowed new hires a choice between Windows, Mac, or Linux on their work laptop. I chose Linux, but didn’t like the distro they pre-installed on it. (KDE Neon. I preferred Arch. Insert hate here.) But the laptop had secure boot enabled and the PC support department wasn’t willing to let me disable that. The laptop would only allow certain kernels to boot. Windows and some kernels from some unknown set of Linux distros.

    Just as a quick aside, the way it knew how to deny a specific kernel from running or allow another to run was with signatures. Canonical which makes Ubuntu includes cryptographic signatures in the kernel file identifying that kernel image as made and certified by Canonical. (Microsoft does roughly the same thing for Windows kernels.) The secure boot system on the laptop has a list of trusted certificates. If the kernel that the bootloader (which is also signed, by the way) asks the secure boot system to boot is signed by one of those certificates, it boots. If not, secure boot denies the request. Theoretically more certificates can probably be configured/trusted, but that wasn’t an option in my case.

    But I still wanted to run Arch! Now, KDE Neon uses the Ubuntu kernel, so I knew that was one I could boot without access to the secure boot config. So I grabbed the .deb for the Ubuntu kernel, wrote a script to convert the .deb for the Ubuntu kernel into an Arch package. (Arch doesn’t use .debs or .rpms. It uses “pacman packages”.) I installed that arch package, configured the bootloader to point to the arch install including that Ubuntu kernel, and booted it. Viola! Arch (mostly) without secure boot access!

    What I was running was really kindof 95% Arch and 5% Ubuntu kernel. Kindof a Frankenstein’s monster of OS’s. But it worked perfectly.

    And theoretically, just about any part of a distro can be replaced with the equivalent from another distro. (Or from the upstream/source version.) You could technically take a Fedora system and replace the package manager with apt (I’m guessing there isn’t an rpm package that would install apt on your Fedora, so you might have to make it yourself or just build it from source and install it manually) pointed at Ubuntu repositories and transform Fedora piece-by-piece into Ubuntu. It’d be a pretty wild and messy process. And it would probably be easier to just reformat and install Ubuntu. But it could be done.

    Similarly, you could replace the init system. Artix is a fork of Arch that gives a choice of init systems whereas Arch only supports Systemd. And it’s kindof another Frankenstein’s monster of an OS because it still relies heavily on the Arch repos. But it works.

    • Crazazy [hey hi! :D]@feddit.nl
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      This Arch story reminds me a lot of a r/talesfromtechsupport story that went remarkably similar but had a less happy ending for the Linux enthusiast, where he basically disabled the TPM and couldn’t access the company network because the network seemed to only allow trusted machines.

      Can’t find it right now but maybe I can do some digging once I’m on a computer

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        11 months ago

        Funny you should mention the company network.

        To tell the next part of my story, when I did all of what I described, I first backed up the KDE neon install onto a tiny little partiton. So I still had it to go back to if I needed to.

        And after I’d been using Arch for a good while, the VPN folks decided to retire OpenVPN and switch to something called “GlobalProtect”.

        They run BMC, a remote machine management program, on all freshly-imaged machines. That lets them (un)install shit without the user’s knowledge and stuff. Windows users had lots of horror stories about “the great Java uninstall of 2018” where the PC Support folks just randomly decided one day to uninstall OpenJDK from every Windows user’s machine. While we were trying to write/maintain Java software written in-house. (This happened multiple times within a few years.)

        One of the biggest benefits to running Linux (even if it was KDE Neon) was that the PC Support folks were scared of Linux and stayed very hands-off. They never (un)installed stuff remotely for KDE Neon users.

        …until they switched to GlobalProtect. They wouldn’t give out the .deb for GlobalProtect to let folks install it themselves. They’d only install it for you via BMC.

        But since I was running Arch and had never installed BMC, (actually I have another story about BMC on Arch, but I’ll save it for when I have more time), my machine was passed over when they installed GlobalProtect on all the KDE Neon machines.

        So I rebooted into KDE Neon, asked pretty please that they install GlobalProtect, and have been using KDE Neon ever since.

        Now, I’ve done nothing to disable the TPM or anything on Arch. I don’t think even if GlobalProtect uses the TPM that there’s any reason it couldn’t do so while on Arch. But I tried just copying the install from KDE Neon to Arch file-for-file and running it. It didn’t work. I had to strace it to get more info and… don’t remember what the error was about now. Some inter-process communication thing I had never heard of before wasn’t able to talk to the daemon process.

        I keep telling myself I’m going to get GlobalProtect running on Arch again so I don’t have to keep using KDE Neon, but it’s been a while since I’ve worked on that any.

        Also, one of my coworkers had been working for years by connecting to the company VPN from a personal machine. And I told him he needed to figure out his VPN situation months before they actually turned off OpenVPN. But he didn’t heed my warnings and when they shut off OpenVPN, he was screwed. He took the Mac they’d sent him when he was first hired off of mothballs and tried to get it running. They ended up just telling him they needed to send him a new machine. So he basically couldn’t work for almost two weeks while he waited for the new KDE Neon machine he ordered to get set up/imaged/etc and then shipped halfway across the country. He uses KDE Neon on a company laptop now.

        There are some great stories about how we’ve messed with PC Support at this company. Lol.

  • MajorHavoc@lemmy.world
    link
    fedilink
    arrow-up
    22
    ·
    11 months ago

    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.

  • Joker@discuss.tchncs.de
    link
    fedilink
    arrow-up
    17
    ·
    11 months ago

    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.

  • Vilian@lemmy.ca
    link
    fedilink
    arrow-up
    13
    ·
    edit-2
    11 months ago

    what else?

    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.

    distrobox

  • DannyBoy@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    11 months ago

    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.

    https://linuxreviews.org/Hannah_Montana_Linux

    • majestic@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      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?

      • Dotdev@programming.dev
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        11 months ago

        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.

        • majestic@sh.itjust.worksOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          11 months ago

          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?

          Looks like the answer is “Yes”, but im not sure.

          • Dotdev@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            11 months ago

            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.

  • Pantherina@feddit.de
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    11 months ago

    Distros

    • are putting together a set of packages in repos.
    • the repos are either close to upstream, or they backport security fixes. Everything else is not secure
    • make working, secure, sometimes branded bundles including Desktop, some apps, some specific software
    • the bundles get updated and if it is a point release, upgraded to a new set of packages. That is called a “Distro version”
    • This ensures new features and security fixes
    • the Distros care about bug reports, work with upstream, getting new contributors, packaging (bundling the packages, presets, libraries into a set with a name, handling dependencies etc.)
    • Distros also often package and build their own Kernel or multiple ones. These kernels are general purpose most often, even though there is the kernel-hardened or Oracles “unbreakable kernel” (whatever that is). Also there is a lts Kernel that has backported security fixes, as well as other releases of the kernel like git (latest of everything)
    • Distros take care of the versioning, so not every package is always the latest but tested to work with other packages.
    • Distros also implement security systems like SELinux and Apparmor with matching configurations

    So you see that is highly complex. So stay as close to upstream as possible to get the best experience. I think of the main distros as

    • Debian + Ubuntu
    • Fedora + the RHEL stuff or clones (Oracle, Alma, Rocky etc)
    • Opensuse, SEL
    • Arch
    • Gentoo
    • Alpine (busybox and musl, not real Gnu+Linux)
    • NixOS
    • GUIX
    • ClearLinux
    • Coreboot (yes that is a Linux distro)
    • Slackware and other probably outdated projects
    • small ones with different focus

    All the others are either downstream modifications of these, or less known. Some Line ublue, EndeavorOS etc. also just take an upstream distro and change very little.

  • nyan@lemmy.cafe
    link
    fedilink
    English
    arrow-up
    4
    ·
    11 months ago

    The main difference between Ubuntu and Fedora is the package manager. Most of the rest is just selected default values for configuration and cosmetics, and what helper scripts are or aren’t present on the system. They’re both mainstream distributions aimed at the general user, and they’re shaped by their goals.

    To see how different distributions can be, you need to compare the mainstream distributions to stuff that’s decidedly not mainstream, like Gentoo, Alpine, and Nix.

    Just as a trivia note: Gentoo does package a couple of other distros’ package managers (app-arch/rpm and app-arch/dpkg), for use in installing otherwise-unavailable commercial binaries, although I suspect app-arch/rpm2targz sees more use than either of them.

    • majestic@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      11 months ago

      NixOS, Alpine and Gentoo are also pretty popular, but yeah, Fedora and Ubuntu it is the distros the regular person is associating linux with. Or doesnt know what is linux at all :)

      Btw i use NixOS

  • juli@programming.dev
    link
    fedilink
    arrow-up
    4
    arrow-down
    2
    ·
    11 months ago

    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.

  • Radioactive Radio@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    11 months ago

    How much snap you have/need. Or the stability I guess, but in my experience that hasn’t been a problem yet.

  • Auli@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    3
    ·
    11 months ago

    Really nothing. Want to distribute hop without the hassle change your theme.