If you think about it, EFI is basically a bootloader already (and not too far removed from "a whole OS"), so having it boot another bootloader (GRUB, systemd-boot or whatever) should be superfluous, at least in principle. That is, on an EFI system, the most minimalistic thing would be to skip the extra bootloader altogether.
It seems some of the Linux devs thought so, too, because EFISTUB exists, which lets you register the kernel image as an EFI executable and then it can boot itself:
https://wiki.archlinux.org/title/EFISTUB
https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html
How well this might work for you is, however, going to depend on the EFI firmware you've got. On one of my laptops, I just couldn't make it work and I still have no idea why. If it does work, though, it's as minimalistic as you're going to get.
There's nothing stopping you from trying it before you switch to Artix, too: register a boot entry with efibootmgr
like the wiki says, interrupt the next boot to choose what to boot (it's usually F12 or Enter), pick the entry you created and see if it boots. If it doesn't, you can just boot the bootloader instead, so it's not like you have to you'll have to fix your boot process or anything scary like that.
Having said all that, GRUB lets you do some pretty fancy stuff if you know what you're doing. If you're messing around with custom kernels or weird kernel parameters, it might not be the worst thing to have installed, even if you normally bypass it with EFISTUB.
So I think a good question to ask yourself is why you want to switch. Artix is a bit more DIY than your normal systemd distros. A lot of software these days ships with systemd unit files, and systemd will look under /usr/lib/systemd to find those files which allows you to easily start a daemon. More likely, you'll have to put in a little more work with Artix to setup your environment the way you like. And that is the reason I switched to Artix. I think systemd is a huge mistake and I didnt want it making my system decisions for me.
That said, if you would like to come to Artix (and I think you should), it will run pretty much the same as Arch in performance and other respects. You will still have to learn an init/service management system, and you may have to write a daemon or two if the daemon script is not included in Artix repos.
Worst case scenario a piece of software was written specifically for systemd, and youll have to fork or find someone who has patched that software to work outside of systemd. At the end of the day available programs should be a binary that one can execute and any good piece of software should not make a systemd assumption.
If NordVPN is a client program, you can easily have your service manager start this program for you. Bluetooth was not in my base install so I had to install it and start it at system startup.
I use s6 and it had a bit of a learning curve while taking a look at it, but I honestly think it is the best I've used out of 14 years of Linux.
It might be a good idea to run Artix in a VM before making the switch to see if it suits you. And I hope it does.
Creating a finish
file with ExecStop
's contents should do the trick.
Simple question: does running the run
script on the terminal (by itself, ./run
) give you back control immediately? Then that's what's called a forking daemon, and it requires differently handling on runit (if you have to type Ctrl+C to get your terminal back, though, the service runs on the foreground and your script will work, most likely).
Personally I feel the AUR (Arch User Repository) is the best part.
You can find virtually every utility you can think of in there.
There is no official tool to install packages from the AUR, however, which is kind of a pain point in my opinion.
I personally use yay: https://github.com/Jguer/yay
That foxboron's not even a developer, he's just a trusted user. Generally, the Arch devs refrain from making unsubstantiated remarks like his, he sounds like a bigot.
you would need to extract the kernel out of the *.deb package and install it accordingly to your setup but I honestly don't see any reason why you would want to do that
the Ubuntu kernels are close to a mainline kernel with only minimal patches on top which typically won't bring you much
you are pretty much always better off downloading one of the mainline kernels from here: https://www.kernel.org/ or use the ABS to build a proper package for Artix for it (i.e. linux-mainline
in the AUR)
uptime
and /proc/uptime
start counting from the when the kernel is initialized (i.e., just after the bootloader). If you make a service which depends on whichever service you consider sufficient for your system to have booted (e.g., a getty or a display manager or whatever) and tell it to cat /proc/uptime
and log it somewhere, then you'll know. I'm guessing logging uptime
would just tell you the system's been running for 0 minutes, but /proc/uptime
should be accurate to 10 ms or something. The procedure for creating something like this seems fairly straightforward:
Problem is solved here [Troubleshooting
](https://wiki.archlinux.org/index.php/pacman#:~:text=%22Failed%20to%20commit%20transaction%20(conflicting%20files)%22%20error,-If%20you%20see&text=This%20is%20happening%20because%20pacman,is%20usually%20trivial%20to%20solve.) Short answer is this command that will remove corrupted file "pacman -S --overwrite glob package".