The only one of those I’ve ever heard of is Final Cut and I have Premier Pro already. I’m going to assume I can get a pretty solid alternative for any of the rest as well.
related question, although i don’t think it’s big enough for a post of its own.
if i use btrfs subvolumes, does it mean that i can have one EFI partition and one root partition, and then subdivide the root partition using subvolumes? how would that work during the installation process? or is it done after installation?
Pretty much, yeah. At some point I remember the recommendation being having a separate /boot as well due to incompatibilities with GRUB’s save default option iirc, not sure that’s a thing anymore.
Anyway, you usually set that up during the install process, although I’m not sure graphical installers let you handcraft btrfs subvolume mount points or even select them as such these days. Last I checked at least they either just used a default layout (@ and @home with Ubuntu, for instance) or treated it as a single volume with no further options.
One EFI + one ROOT partition is what I do on both my laptop and desktop for years, /home is a subvolume to my root partition. This setup suits my needs as I don’t have to worry about how big should my root or home (gaming) partition should be.
I use Arch on my desktop and Opensuse on my laptop. They both have options to set up subvolumes from their installer, Debian does not, and I’m not sure about other distros, but you can always set that up after installation, just make your home partition the last one (after the root partition) so you can easily delete it after and grow the root partition without much blocks relocation.
if i use btrfs subvolumes, does it mean that i can have one EFI partition and one root partition, and then subdivide the root partition using subvolumes?
Yes.
how would that work during the installation process? or is it done after installation?
That depends on your distro. What do you plan to achieve with the separate subvolumes?
I already have a partition layout in btrfs where I have a /home and a /root partition, since when I installed I didn’t know about btrfs subvolumes. I use Void Linux and I think it’s after installation, since I don’t remeber having a subvolumes step during the installation.
I’ll make sure to remind about btrfs subvolumes in case I reinstall. There’s a btrfs program that has a subvolume argument, so I’m guessing that’s what I could use.
Wait, isn’t a lower frame time better? Why does their screenshot show windows having the lowest and say that it scored last?
Looking at the source article, windows did have generally better 1% lows except for Starfield, so I think this article has it backwards. They also cherry picked 2 results where windows was worse lol.
I’m all for pro-linux stuff but articles like this just reek of making shit up so it looks better.
They probably didn’t label their axes properly. FPS is a clearly defined metric, and there, more is better. This indicates that the conclusion (Linux is faster) holds. Since frame times have an entry with value “100” and all other values are lower, I assume that’s in percent, i.e. Arch Linux is the fastest and picked as comparison point, and the others are shown with relative performance to Arch.
I think FPS was actually selected, not frametimes. 1% low frametimes of 89 does not make sense.
There is an issue with the image in the article, but not the one that you might think it was. The FPS should have been more clearly indicated that it was the selected tab and then it probably would have been fine.
edit: I went to the base website www.computerbase.de/2023-12/…/2/ it’s in German, but, it seems like the frametimes and frame rates are nearly the exact same values - which doesn’t even seem to make sense to me?
I hope this isn’t going to be the default. I know, the average granny might prefer to have a BSOD with a QR code, but I think a lot of the people who are more tech-savvy, like me, would prefer to see log messages when booting because then you could see which service failed and why or why it’s all of a sudden taking so long to boot. That’s also why I choose not to have a splash screen when booting.
Anyways, this BSOD thing doesn’t apply to me because I use Gentoo with OpenRC.
Using Btrfs you can do some pretty cool snapshotting: It’s basically like system restore of Windows but MUCH faster and pretty seamless. Even if you annihilate the whole operating system you can restore the snapshot and voila, have fun! It also has compression which can save some wear on SSDs and of course give you some more free™ storage space, which is cool [actual benefits depend on workload*]
There’s no GUI, but following the wiki pages on BTRFS subvolumes you should be able to make a subvolume for those with like 2 simple commands (take a look at the man page for BTRFS subvolumes as well)
I wasn’t cool enough to figure out how to “just boot into a snapshot” when I tried btrfs a while ago. I mean I did figure it out (maybe?) but somehow the read/write rights where messed up and the snapshot couldn’t actually boot/I wasn’t able to log in +___+ Just reinstalled the system eith good old ext4. It sounds really cool, though …
Well, sounds like a setup or distro issue. It should work without problems on Debian/Ubuntu/Mint. Linux Mint even really supports it as a setup-less default with TimeShift
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.
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
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.
Edit: Ok. I’ll tell the BMC-on-Arch story now.
Same company. Back before they were issuing secureboot’d machines, and before they offered the option of a Linux machine (or without special manager approval, a Mac, actually), I installed Arch on my host on a forgiveness-rather-than-permission basis.
When they started supporting Linux, they got BMC set up for Linux. (It had worked on Windows prior, of course.) And then they started sending me nagging emails about installing BMC. They knew my boss would back me up if they pressed me to switch back to Windows, so they didn’t push for that. But they wanted me to install BMC just to get the feature that it periodically phoned home to let PC Support know it was still in use and all that. (I think it also offered features like if I ever reported it stolen, they set it up so it would wipe its own hard drive next time it phoned home. To protect any trade secrets.)
I kindof ignored them for a while. Eventually they visited my desk in person. (This was before I was working remotely.) I was like “yeah, ok, tell me what to do” (I figured it was a good compromise that would let me keep Arch) and they were like “we’ll send you the installer.”
Now, the Linux distro they supported at the time wasn’t KDE Neon. It was Ubuntu. And I was on Arch. And I asked “the installer was probably was packaged for Ubuntu, right? BMC is supposed to run as a daemon and Arch doesn’t even use the same init system. I’d be surprised if it worked.” And one of the PC support guys looked me right in the eye and passed his hand over his head in a “you’re talking over my head” gesture. And then walks away.
I received the installer. Tried to run it. It immediately choked for exactly the reason I suspected. Basically it looked at my system, didn’t find the init system it expected, and aborted before extracting the files to be installed.
So, was I going to give up and switch to Ubuntu? No! I wasn’t daunted.
So I broke out strace and gdb and managed to trick the installer into extracting the files. (Basically when it checked for the init system, I altered a variable from false to true to make it not abort before extracting.)
And then I just had to stick it at the right place on the filesystem. I never made a service file for it. I just manually ran it every now and then. And killed it a little while later. No one nagged me again.
Now, I wasn’t the only one who ran Arch. I had a coworker there who also ran Arch and somehow he was never nagged to install BMC. Not sure why. But when I left the company, I left all my work with this other coworker in case he ever needed it.
And then I returned to this company. It was after that that I did the Archbunkenstein thing because they’d started using machines that enforced secureboot. The coworker who was still running Arch when I returned had lost my BMC installer reverse engineering work. And still had never been nagged by PC Support. I expected to be nagged again, but I ran Archbunkenstein for a good year or so without anyone nagging me. When I switched back to KDE Neon for the VPN, it had BMC installed, so I’ve been using BMC ever since.
You may wish to investigate Bedrock linux, it allows you to Frankenstein 2 (or more) distros together. I’m sure there’s a way you could have your KDE neon kernel plus BMC while having everything else Arch
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.