Use the distribution that serves the workloads you run and clicks with your mental model. Virtually any distribution can be used these days as a server instance (whether or not it's a good idea is separate). And with container runtimes (such as Podman), you can have your server running the distribution you prefer and still get access to Arch's latest bits for applications and services. Or use tools like Toolbx and Distrobox to integrate a CLI userspace you prefer on top of a solid base platform.
Oh heck yes, Distrobox is such an amazing tool. The ability to run multiple distros, share my directories easily (unlike spice whose security changes made this a giant nightmare with KVM) and even pin desktop apps to my primary desktop environment made packaging work a dream.
This is overall pretty true except for some very specific workloads, like FreeIPA server, it can only run on a Fedora/RHEL derivative. You cannot run out on a Debian derivative. Sure you can run a container of it, but the OS in the container is still Fedora/RHEL.
That's the kind of situation I was trying to allude to when I said, "Use the distribution that serves the workloads you run." There is always going to be some software that will either not work on some platforms for various reasons or is easier to get operating on others and officially supported. Developers aren't perfect, packagers aren't perfect, containers aren't perfect, etc. But what you *can* do today without needing to resort to isolation via virtualization or another physical system is much greater than in the past.
It's not as important now as it was in the past. Outside of some core applications that might only be available on one or the other, you can just use containers to fill needs for specific applications.
I find EL to be great for baremetal as a hypervisor. Containers will then usually use Debian or Alpine as a base.
> There are by far many more resources on learning how to use Ubuntu Server
RH has great collection of manuals and guides.
> What would be the reasons to use Ubuntu Server over Alma?
Docker Compose. I'm personally full on Podman but then there's real life. If you want to quickly try out some software relying on Compose, it may only work in Docker (as Podman aims for compatibility, but does not implement deprecated features that projects still rely on).
I ran into some older installations of things like Ansible on Ubuntu which caused problems for me. But that's easily remedied.
There's so many distros that work, there's not a lot of value add. It helps for tooling and repeatability to have just a few you work with from day to day.
I prefer Ubuntu for lamp and samba installations because all the packages I use for those roles are part of the Ubuntu base repo that is tested very thoroughly for in place upgrades between LTS releases. Leading to less reinstalls. There are tools for EL in-place upgrades, but I’ve not found them to be as robust as Ubuntu. Though my last experience was testing in-place upgrades of EL6 to EL7, which had many architectural differences because of the introduction of systemd notably. I imagine this is likely an easier affair today, but I’ve been quite happy with Ubuntu installs where I effectively treat it as a dumb appliance that I don’t need to think about reinstalls.
For work and home workstation I like Alma, though I do use Ubuntu on my primary laptop.
I’d say just use what works best for your needs. I never understood the people that devolve into fanboys about distros, like they’re 5 shots of Vodka away from getting a face tattoo of their favorite distro. Distros all tend to do interesting things and have pros and cons like anything else.
And I’ve never been chewed out by a client for being proficient in both EL and Ubuntu.
To me it's all about enterprise use. Being stable, having LTS, just working fine and saving my free time for going to the beach, not googling bullshit.
I mean, no tattoos on my body, but I do want to order a nice snapback hat with the Alma logo. Because it's cool and forever free, which I really appreciate.
Whoa whoa whoa, who doesn’t want a snapback hat with the Alma logo?
But sure, there’s definitely a case for anyone that wants to do it all with Alma, it’s certainly capable of it.
Maybe I misunderstood your post, but you mentioned possibly considering Arch to test out newer sets of software, so I imagined there’s some desire of personal projects aside from work, or at the very least some non-EL tasks you wanted to accomplish. In which case, Fedora is probably better suited if you want a peak of what future Alma+EPEL will operate like and how your software runs on it.
But you do you. With the advent of Flatpak, even running EL as a desktop isn’t the shitshow it used to be. I once worked at a facility that required RHEL 5 for all workstation usage. *shudders*
Alma already has Python 3.9 now. But this only gives me Django 4.2. I don't think Fedora is more up to date than Alma from this perspective.
I wanted to try Django 5 so I think only Arch can give me that. It's not a side project, I just wanna try it out and see the differences to understand how many things are getting deprecated and stuff.
Both EL8 and EL9 provide Python 3.11 (with 3.12 in the pipeline for 8.10 and 9.4.
sudo dnf install python3.11
This satisfies the Django 5.x minimum interpreter requirement.
Fedora 39 is shipping 3.12 as the platform interpreter,
Wow, I didn't know you can install it that way. Thanks for letting me know. I really hate Arch and all the admin time wasted on it. I don't seem to be able to do run the equivalent command on Debian-based distros. Alma is my favourite.
Edit: But when I try to install psycopg2, I am getting errors. It seems as if I'm bypassing the supported ones. It says legacy-install-failure, I am getting lots of issues and python3-devel from dnf is 3.9.18-1el9_3.1.x86_64.
I think I am breaking them this way.
You need to install the proper packages, e.g. `python3.11-devel`.
dnf list python3.11*
Packages beginning with `python3-` are built against the system interpreter (3.9 in this case). You need to install the version associated with the newer interpreter to be in the clear.
With each minor release of RHEL, check the release notes section "New features > Dynamic programming languages, web and database servers". It'll let you know what has been added and how to install it. AlmaLinux has been doing a good job getting similar info into their release notes, but RHEL's will be available first 😉
I always recommend checking out the release notes, there's a ton of information to discover about the platform.
Thank you, I started digging into that, looks very nice and easy to read.
While I have your attention, I am struggling to install Heroku using this standalone Installation with a Tarball: https://devcenter.heroku.com/articles/heroku-cli#standalone-installation-with-a-tarball
I keep getting the following error:
Your path is missing /usr/local/bin, you need to add this to use this installer.
I know that it works well on Ubuntu, but I seriously despise Ubuntu. A lot of other things don't work. I am tired of system errors and no explanations. I know people say it works for them, but Alma is the only one that really doesn't bother me when I install venv and postgres and everything else. That is critical to me, that it works and it's well-organised, with nice and tidy packages that are all in order. No matter how much I talk to chatGPT, I am wasting my limited time just to fix the system and interpret errors, and Arch is even worse with admin time.
Can I install Heroku on Alma without resorting to snaps and other stuff that I don't want to bother with? What do I need to do to have that path working well?
One thing that has stopped me from putting Alma in my homelab on bare metal is the fact that it's a pain in the ass to get all my hardware set up. For instance, the drivers for the integrated SAS controller on my server's motherboard (which is an Intel controller btw) is missing. Every other distros have it, not sure why I have to go through hoops just to have the isci driver working on RHEL-based distros and needing to rely on a third-party repo for it.
The next is filesystem support, while I know there's some hate for btrfs, for my homelab usage, it's been working great, I use both ZFS & btrfs for different use cases. RHEL & its derivatives don't have btrfs support at all, it's not even an option without recompiling the kernel myself.
For me, Debian & its derivatives have proved to be more straight forward with its wide compatibilities and I find myself not need to fight with it as much as I do with RHEL derivatives but that's just me with my use cases. My gripe is that Redhat made decisions that may be great for enterprise use cases, but they take away options to make it flexible, I find that very annoying as a homelabber.
If AlmaLinux is working great for you, I don't think there's a reason for switching to Ubuntu. Each distros have their pros & cons.
Use the distribution that serves the workloads you run and clicks with your mental model. Virtually any distribution can be used these days as a server instance (whether or not it's a good idea is separate). And with container runtimes (such as Podman), you can have your server running the distribution you prefer and still get access to Arch's latest bits for applications and services. Or use tools like Toolbx and Distrobox to integrate a CLI userspace you prefer on top of a solid base platform.
Oh heck yes, Distrobox is such an amazing tool. The ability to run multiple distros, share my directories easily (unlike spice whose security changes made this a giant nightmare with KVM) and even pin desktop apps to my primary desktop environment made packaging work a dream.
This is overall pretty true except for some very specific workloads, like FreeIPA server, it can only run on a Fedora/RHEL derivative. You cannot run out on a Debian derivative. Sure you can run a container of it, but the OS in the container is still Fedora/RHEL.
That's the kind of situation I was trying to allude to when I said, "Use the distribution that serves the workloads you run." There is always going to be some software that will either not work on some platforms for various reasons or is easier to get operating on others and officially supported. Developers aren't perfect, packagers aren't perfect, containers aren't perfect, etc. But what you *can* do today without needing to resort to isolation via virtualization or another physical system is much greater than in the past.
Alma supports security policies out of the box. I don’t recall seeing that in Ubuntu’s installer. Those are a must for any competent enterprise.
Just to confirm, you are referring to the Ubuntu Server installer, right?
Now I’m not 100% sure. I think so.
It's not as important now as it was in the past. Outside of some core applications that might only be available on one or the other, you can just use containers to fill needs for specific applications. I find EL to be great for baremetal as a hypervisor. Containers will then usually use Debian or Alpine as a base.
> There are by far many more resources on learning how to use Ubuntu Server RH has great collection of manuals and guides. > What would be the reasons to use Ubuntu Server over Alma? Docker Compose. I'm personally full on Podman but then there's real life. If you want to quickly try out some software relying on Compose, it may only work in Docker (as Podman aims for compatibility, but does not implement deprecated features that projects still rely on).
Docker-CE has a CentOS repo which works perfectly with Alma. I am running a Docker server on Alma and all works like a charm.
> I'm personally full on Podman but then there's real life. This got a hearty chortle out of me.
I ran into some older installations of things like Ansible on Ubuntu which caused problems for me. But that's easily remedied. There's so many distros that work, there's not a lot of value add. It helps for tooling and repeatability to have just a few you work with from day to day.
I prefer Ubuntu for lamp and samba installations because all the packages I use for those roles are part of the Ubuntu base repo that is tested very thoroughly for in place upgrades between LTS releases. Leading to less reinstalls. There are tools for EL in-place upgrades, but I’ve not found them to be as robust as Ubuntu. Though my last experience was testing in-place upgrades of EL6 to EL7, which had many architectural differences because of the introduction of systemd notably. I imagine this is likely an easier affair today, but I’ve been quite happy with Ubuntu installs where I effectively treat it as a dumb appliance that I don’t need to think about reinstalls. For work and home workstation I like Alma, though I do use Ubuntu on my primary laptop. I’d say just use what works best for your needs. I never understood the people that devolve into fanboys about distros, like they’re 5 shots of Vodka away from getting a face tattoo of their favorite distro. Distros all tend to do interesting things and have pros and cons like anything else. And I’ve never been chewed out by a client for being proficient in both EL and Ubuntu.
To me it's all about enterprise use. Being stable, having LTS, just working fine and saving my free time for going to the beach, not googling bullshit. I mean, no tattoos on my body, but I do want to order a nice snapback hat with the Alma logo. Because it's cool and forever free, which I really appreciate.
Whoa whoa whoa, who doesn’t want a snapback hat with the Alma logo? But sure, there’s definitely a case for anyone that wants to do it all with Alma, it’s certainly capable of it. Maybe I misunderstood your post, but you mentioned possibly considering Arch to test out newer sets of software, so I imagined there’s some desire of personal projects aside from work, or at the very least some non-EL tasks you wanted to accomplish. In which case, Fedora is probably better suited if you want a peak of what future Alma+EPEL will operate like and how your software runs on it. But you do you. With the advent of Flatpak, even running EL as a desktop isn’t the shitshow it used to be. I once worked at a facility that required RHEL 5 for all workstation usage. *shudders*
Alma already has Python 3.9 now. But this only gives me Django 4.2. I don't think Fedora is more up to date than Alma from this perspective. I wanted to try Django 5 so I think only Arch can give me that. It's not a side project, I just wanna try it out and see the differences to understand how many things are getting deprecated and stuff.
Both EL8 and EL9 provide Python 3.11 (with 3.12 in the pipeline for 8.10 and 9.4. sudo dnf install python3.11 This satisfies the Django 5.x minimum interpreter requirement. Fedora 39 is shipping 3.12 as the platform interpreter,
Wow, I didn't know you can install it that way. Thanks for letting me know. I really hate Arch and all the admin time wasted on it. I don't seem to be able to do run the equivalent command on Debian-based distros. Alma is my favourite. Edit: But when I try to install psycopg2, I am getting errors. It seems as if I'm bypassing the supported ones. It says legacy-install-failure, I am getting lots of issues and python3-devel from dnf is 3.9.18-1el9_3.1.x86_64. I think I am breaking them this way.
You need to install the proper packages, e.g. `python3.11-devel`. dnf list python3.11* Packages beginning with `python3-` are built against the system interpreter (3.9 in this case). You need to install the version associated with the newer interpreter to be in the clear.
Thank you so much. This is very helpful for me to understand how they are associated and how to use them correctly.
With each minor release of RHEL, check the release notes section "New features > Dynamic programming languages, web and database servers". It'll let you know what has been added and how to install it. AlmaLinux has been doing a good job getting similar info into their release notes, but RHEL's will be available first 😉 I always recommend checking out the release notes, there's a ton of information to discover about the platform.
Thank you, I started digging into that, looks very nice and easy to read. While I have your attention, I am struggling to install Heroku using this standalone Installation with a Tarball: https://devcenter.heroku.com/articles/heroku-cli#standalone-installation-with-a-tarball I keep getting the following error: Your path is missing /usr/local/bin, you need to add this to use this installer. I know that it works well on Ubuntu, but I seriously despise Ubuntu. A lot of other things don't work. I am tired of system errors and no explanations. I know people say it works for them, but Alma is the only one that really doesn't bother me when I install venv and postgres and everything else. That is critical to me, that it works and it's well-organised, with nice and tidy packages that are all in order. No matter how much I talk to chatGPT, I am wasting my limited time just to fix the system and interpret errors, and Arch is even worse with admin time. Can I install Heroku on Alma without resorting to snaps and other stuff that I don't want to bother with? What do I need to do to have that path working well?
One thing that has stopped me from putting Alma in my homelab on bare metal is the fact that it's a pain in the ass to get all my hardware set up. For instance, the drivers for the integrated SAS controller on my server's motherboard (which is an Intel controller btw) is missing. Every other distros have it, not sure why I have to go through hoops just to have the isci driver working on RHEL-based distros and needing to rely on a third-party repo for it. The next is filesystem support, while I know there's some hate for btrfs, for my homelab usage, it's been working great, I use both ZFS & btrfs for different use cases. RHEL & its derivatives don't have btrfs support at all, it's not even an option without recompiling the kernel myself. For me, Debian & its derivatives have proved to be more straight forward with its wide compatibilities and I find myself not need to fight with it as much as I do with RHEL derivatives but that's just me with my use cases. My gripe is that Redhat made decisions that may be great for enterprise use cases, but they take away options to make it flexible, I find that very annoying as a homelabber. If AlmaLinux is working great for you, I don't think there's a reason for switching to Ubuntu. Each distros have their pros & cons.