Fedora 42 Beta • Hacker News Board

Re: Fedora 42 Beta

#121

Post by PhilippGille » Wed, Mar 19, 2025, 10:49 PM UTC

paride5745 wrote: post #118

PhilippGille wrote: post #115

Earlier quoted context omitted.

- `brew list` doesn't include apps you install from 3rd party taps, or casks, so `brew list --full-name` + `brew list --full-name --cask` is better - Many apps store their config and user data outside of the home dir. I always find it dishonest when people say backing up home is enough on Linux. You did say " mostly ready to go", but that's exactly the tricky and important part that most people pretend doesn't exist…

Ideally you shouldn't have to backup /var/lib/docker, as your docker configs should live in your docker-compose.yaml or whatever you use to start your docker containers. Also I have included backing up /etc confs in my original post. I agree on the brew list being incomplete, totally forgot about casks. Not even sure if they work correctly under Linux to be honest. I literally just use brew for golang and awscli :P

Re Docker I said volumes, not config. Some volumes you might have mapped to the host and maybe picked a home subdirectory, but others maybe not. For example the Ollama 3rd party UI `open-web-ui` suggests to run it like this in their documentation:

`docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main`

Then "open-webui" will be in `/var/lib/docker/volumes/open-webui/`.

Sure you can change it, but what I mean is that a lot of software by itself, or by you following documentation, puts data that you usually want to back up outside of your home.

Re: Fedora 42 Beta

#122

Post by kasabali » Thu, Mar 20, 2025, 7:39 AM UTC

> RPM copy on write uses reflinking capabilities in btrfs

Why not in XFS?

Re: Fedora 42 Beta

#123

Post by 2OEH8eoCRo0 » Thu, Mar 20, 2025, 4:39 PM UTC

xd1936 wrote: post #53

nasir wrote: post #31

Using Fedora 3 as my first linux distro makes seeing this nostalgic.

Fedora Core 6 here!

Pre-EL Red Hat here!

Re: Fedora 42 Beta

#124

Post by quicksilver03 » Fri, Mar 21, 2025, 5:23 PM UTC

ezekiel68 wrote: post #89

threePointFive wrote: post #70

I've been super happy with Fedora since switching to it on desktop. Unfortunately I'm still biased to Debian for the server usecase. Fedora moves too quickly but RHEL (and derivatives) not supporting major version upgrades is pretty much a deal breaker. Would love a RedHat-themed distro with a ~5year support cycle with the option to do major version upgrades.

In our environments, we use Fedora. We run the package upgrades weekly in a test env and make sure the functional/integration tests pass successfully, then roll those forward to stage and prod envs. Very seldom (twice in 5 years) have we caught a problem in the lower environment that prohibited the upgrade from moving on towards prod. And in both of those instances, newer package upgrades in the test env fixed the pr…

That's an excellent example of what I like to call "good IT hygiene". I too would like to know what kind of tools you have to perform the functional and integration tests, and to execute the various rollouts.

Re: Fedora 42 Beta

#125

Post by ezekiel68 » Sat, Mar 22, 2025, 7:41 AM UTC

quicksilver03 wrote: post #124

ezekiel68 wrote: post #89

Earlier quoted context omitted.

In our environments, we use Fedora. We run the package upgrades weekly in a test env and make sure the functional/integration tests pass successfully, then roll those forward to stage and prod envs. Very seldom (twice in 5 years) have we caught a problem in the lower environment that prohibited the upgrade from moving on towards prod. And in both of those instances, newer package upgrades in the test env fixed the pr…

That's an excellent example of what I like to call "good IT hygiene". I too would like to know what kind of tools you have to perform the functional and integration tests, and to execute the various rollouts.

Without going too deeply into details, we use common non-cloud-native platforms such as Jenkins to configure and schedule the tests. Unit tests are often baked into Makefiles while functional / integration tests are usually written as shell scripts, python scripts, or (depending on what needs to happen) even Ansible playbooks. This allows us to avoid cloud vendor lock-in, while using the cloud to host this infra and the deployment envs themselves.

Edit: we use Makefiles, not because we are writing code in C (we are not) but because our tech culture is very familiar with using 'make' to orchestrate polyglot language builds and deployments.

Re: Fedora 42 Beta

#126

Post by ezekiel68 » Sat, Mar 22, 2025, 7:47 AM UTC

threePointFive wrote: post #120

ezekiel68 wrote: post #89

Earlier quoted context omitted.

In our environments, we use Fedora. We run the package upgrades weekly in a test env and make sure the functional/integration tests pass successfully, then roll those forward to stage and prod envs. Very seldom (twice in 5 years) have we caught a problem in the lower environment that prohibited the upgrade from moving on towards prod. And in both of those instances, newer package upgrades in the test env fixed the pr…

That's quite impressive by the standards I'm used to. Do you mind if I ask what scale you're operating at and what tools you use to manage the staged rollout?

re: tools, see my reply to a peer comment.

Our scale isn't ginormous. Fewer than two dozen microservices and we sometimes fudge the 'microservice' definition somewhat to allow some of those services (such as pure lookups) to host their isolated tables in the same database schemas/instances. We always mock external web service calls in the test env since a Fedora update either will or will not screw up the ability to hit an endpoint via HTTP (has never happened) -- in other words, hitting a real, live service would add nothing to the results of the dev test outcomes.