The guy replying is a total dick, and for people that like to encourage change to create software that evolves with needs, they sure do refuse to change when needs evolve.
This is definitely just a dangerous cause of that one xkcd. At the very least, Debian unstable caught something before it could reach everyone else. That works, I guess.
I sometimes hear that it is a different story on servers.
Wonder what their usages are, especially in a container-focused world, where most containers simply don’t have an init, and the base system just needs, at most, to have a container runtime (+/- a few other things, see: talos linux and their 130MB bare-metal ISOs).
Why are you being inflammatory for no reason? I’m just saying I don’t think it’d be correct for an OS 3 years in the past to be neck and neck with modern stuff. Log off the computer and go outside lmao
Mfw CentOS Stream 9, using a kernel, compiler, and glibc version from 3 years ago, still manages to pull ahead of software released a few weeks ago on hardware released years after Stream 9’s original release.
I’m not sure how much I’d buy into phoronix benchmarks in this case. CentOS Strea, 9 was performing as good, if not better than, the recently released Ubuntu 24.04 and 2 week old FreeBSD 14.1 despite having a 3 year old kernel and being compiled with an equally old version of GCC. Linux is currently suffering from a pstate bug with AMD, too.
There’s a reason the BSDs are hardly used in HPC.
It’s not brave, it’s just outright wrong. As in, wrong to use in this situation, and the LLM itself is wrong.
So basically ostree deploy fails if you have an existing populated ESP (EFI System Partition), so you’ll have to partition manually atm (in my case, I just made another ESP on the same disk). Other than that, I haven’t run into any problems with Win11 + Fedora on the same disk, mostly because I don’t boot into windows.
You can read about the issue here: https://github.com/fedora-silverblue/issue-tracker/issues/284
Here’s the docs on manual partitioning: https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/#manual-partition
It’s definitely a pain. One of many papercuts you’ll find with an “emerging” desktop edition on a distro already known to push new stuff before the Linux ecosystem is ready.
Just be sure to make a backup of your windows data in a separate disk, keep boot drives for normal fedora (in case this ends up being too difficult), windows (in case you give up), and Fedora Kinoite (because duh), and ffs, don’t trust ChatGPT with your sensitive data on your main PC :)
From what I gather, it’s very similar.
They are both just wrappers for podman(/docker). Distrobox is more feature rich, and is far better documented, but is closer to a collection of bash scripts rather than a fully cohesive program. Toolbx is… definitely something. Their only real claim to fame is being less “janky”? IDK, it reeks of NIH, and in my experience, it’s a lot more fragile than distrobox (as in, I’ve had containers just become randomly inoperable in that I can’t enter them after a bit).
If you want to be pedantic, technically, distrobox is a fork of toolbx before it was rewritten.
Can’t believe he figured it out. What a shame. Guess we’ll have to go provoke another country to invade our fellow flourishing independent democracies, who play a key role in the world’s trade.
Seriously though, I hope he’s just giving himself an easy out here. There’s always too much war going on.
Also see: systemd-bsod. Generates QR codes, too. I think blue for userspace boot-time errors and black for kernel stuff might be nice.
It’s a good thing for the owners of the codebase, but often, a bad thing for the community (even if the community contributes to said codebase).
For example, FOSS maintainers sometimes will (want to) relicense to protect their income stream:
https://github.com/CaffeineMC/sodium-fabric/issues/2400
https://github.com/LizardByte/Sunshine/pull/150
While corporations might literally have maintainers sign away their rights so they can take the work from their own community:
https://lwn.net/Articles/937369/ (canonical requires a CLA, though this + the subsequent re-license might have happened anyway)
https://lwn.net/Articles/935592/ (RPM spec files are MIT licensed at the Fedora level. There are likely chnages to RPM files contributed by the community that are now source-restricted in RHEL)
https://networkbuilders.intel.com/docs/networkbuilders/accelerate-snort-performance-with-hyperscan-and-intel-xeon-processors-on-public-clouds-1680176363.pdf (See section 2.2. Previously, this work was BSD)
Mixed bag, really.
I actually do use quadlets on my server which are absolutely fantastic and hook into systemd, but I don’t see any reason why a similar init system couldn’t do similar or even contribute something like
podman generate systemdbut for a different init system.