As you can see there's lots of excellent choices. Check out distrosea.com if you want to get a feel for different ones without installing. FWIW I prefer Fedora and RPM based distros as I've found their hardware support to be a bit better than Debian based. This is just personal experience though so your's may differ. Please report back on what you ultimately choose.
You'll hear it in every company: Sales produces revenue. Everything else is a cost center. If a business could have only Sales and nothing else, they would.
I would not be using CentOS in your use case as it is a rolling release and as such not considered stable for production environments. In recent times Ubuntu server has taken over where CentOS was once used.
In regards to a framework for HPC, I would be looking at grid computing and using one of the scientific workflow management solutions which is compatible with your requirements and a Linux environment.
The lack of stability is actually quite attractive to me. In a scientific environment we're normally running fairly new, often unstable code, and we often hit problems because of using older versions of libraries / packages / compilers, so somthing which stays a bit more current would be good and we can deal with breakage if it happens. The trouble is the management systems around HPC assume you're working on enterprise systems, which isn't really true in our case.
I've looked at things like OpenHPC but they're still on RHEL8 (RHEL9 is in testing but not released yet), and even lower level tools like warewulf is still only supporting RHEL8 at the moment which is getting too old for me to want to build a new system from it.
I've looked at more generic tools like Ansible and Chef / Puppet but before I go down that rabbit hole I'd like a sanity check that there isn't something more suited that I'm missing.
It's a misconception that Centos Stream is a rolling release. It comes in versioned releases that tracks ahead of Red Hat by a few months and have 5-year support cycles.
It literally states in the CentOS site that it is a, and I quote;
"Continuously delivered disto that tracks just ahead of Redhat Enterprise Linux (RHEL) development..."
I don't see how that quote means anything. It factually just isn't a rolling release model. Rolling releases are like Arch, which don't have versions and are instead continuously updated. Point releases have a versioning system in place. Centos (as the quote says) tracks ahead of Red Hat, so Centos Stream 9 released a few months before RHEL 9. In the future there will be a 10 and an 11. That makes it a point release schedule, not a rolling release schedule.
Centos is 100%, factually not a rolling release. Rolling releases don't deploy based on version, they do it based on snapshot. That is quite literally the only defining characteristic of a rolling release and Centos does not share it. Centos deploys by version AKA a point release schedule. Centos 9. Centos 10. Centos 11. Actual rolling releases don't have this characteristic. There isn't an Arch 5, or an OpenSUSE Tumbleweed 23.1, or a Void Linux 4.8. There is just Arch, OpenSUSE Tumbleweed, and Void Linux. Maybe you have Arch 2023.29.6 snapshot but that is not the same thing.
"This is in contrast to a standard or point release development model which uses software versions that must be reinstalled over the previous version."
This is exactly how Centos works. It's also how Red Hat, Ubuntu and Debian work. Are Red Hat, Ubuntu and Debian rolling releases?
It looks like the downstream rebuilders are already working on this and are able to extract (with a bit more work) the information they need from the stream repo. How much Redhat tries to block these approaches remains to be seen, but if they can work around this so quickly then it seems a pretty petty stunt to pull.
I'm not clear what this means for distros like Alma or Rocky which used to rebuild the SRPMs that RedHat made available. Are they now dead in the water, or is there a more indirect way for them to get to the code. It looks like the CentOS Stream repository will have all of the code released by RHEL but it's going to take a lot of work to find and extract those packages from the ongoing development, so that's likely going to difficult if not unfeasible.
This is going to be a huge pain to anyone using these distros - it's fine to say we should all move to Debian based distributions, but that sort of migration takes time and planning. If this is implemented immediately then you're going to see a ton of unpatched systems around as existing distros lose support.
For this in particular, look into setting up NetworkManager to do the openvpn configuration, it has that functionality built in. Otherwise, systemd unit file
I don’t use open VPN so I don’t know for sure, but I think you’re right as the best way to go. Pretty sure I recall Network Manager having an option to set a vpn to be always on when a network connection is made and an option to save credentials.
You can make sudo password-less for a single command (including using specific arguments) though, so even if using sudo were the only solution, it wouldn't be that bad. For example, I have a sudoers entry that allows my user to decrypt my ZFS pool by executing a root-owned script (with permissions 700), but everything else requires a password.
That looks pretty straightforward. I'll look into doing that. And if I can;t make it work I'll go with the cron job option suggested by @Andromeda above
Actually OP, for the easiest, safest option to your system I would say @Supermariofan67 hit the nail on the head. Use your network manager settings: forum.manjaro.org/t/…/46298
If you’re using NetworkManager, I’d recommend you to use it to create a VPN profile instead and connect to that on startup through the unprivileged nmcli.
If you want to do a proper color calibration, lookup “color management” for your distro or desktop environment. You can load an ICC color profile, but you will need a colorimeter or spectrometer to create one.
linux
Popular
Esta revista es de un servidor federado y podría estar incompleta. Explorar más contenido en la instancia original.