Ich think you need to turn the blocker off. It seems to block anything not going through the VPN, even if the VPN allows to configure exceptions.

I’m not a criminal! I mean, I kinda am, but not because I use Linux!

Can’t reproduce.

No, seriously, please date me 🥺

I just noticed how that Arch is in quotes and “64 bit” was added. Does anyone use 32 Bit Arch for gaming? Is it even possible to run Steam on that?

And why not go with:

Arch Linux (rolling-release) 64 bit

Have you ever heard of datacenters, portable devices or climate change?

At it’s heart, numpy is C tho. That’s exactly what I’m talking about. Python is amazing glue code. It makes this fast code more useful by wrapping it in simple® scripts and classes.

I’m mainly talking efficiency in terms of energy use. I won’t deny that some ugly decisions have been made with Java :D

Java is still significantly faster and more efficient than Python tho - because it has ahead-of-time optimizations and is not executing plain text.

To add to the other answers: Yes, it is a known bug and I think it is being fixed in Plasma 6.1.2 or 6.2

I have to, for work - which is why I am happy whenever they do stuff right. That said, there is also a lot of schadenfreude whenever they think something along the lines of “let’s tell people we will screenshot everything”.

Whatever MS does, I win.

I think TOML found a pleasant compromise there

I have yet to draw the comparison in person (only have a 165Hz), but I mean, every time you double the FPS, the benefit of doubling them again halves. Going from 120 to 240 to 480 Hz is going from 8 to 4 to 2 ms in terms of frametime.

A 4 ms difference in delay might be somewhat noticeable, if you have a very well running game and amazing reflexes. Anything beyond 240 is marketing bs / e-sport ‘I need every ms I can get’.

Remember that blind test on LTT where no one, including an esporty player, could reliably differentiate between 120 und 240 Hz?

I know it’s not exactly the most thorough experiment ever, but it’s all I needed to know.

That are 40 TOPS, no? I mean, why use standard nomenclature when you can have a big number I guess.

Any yeah, that’s a lot of OPS for a ‘+’.

I mean, there is OpenCL and AMD is actually compatible with lots of frameworks these days. It’s not impossible, people just don’t want to

Sorry for the late reply btw, responses were broken for me

In the case of Dracut, I’m not sure what it does exactly, but the kernels will almost definitely not be identical. In the “EFI kernel”, uneeded modules (meaning most of them) are usually omitted.

You could probably also have different kernels in terms of version number, although it might complicate things. Kinda depends on whether they recycle data structures from the first kernel and whether those remain compatible. I don’t really know whether this is actually done tho.

The reason why multiple kernels (or bootloaders for that matter) are used is that there are different levels of “readiness” in your system. Say you have LVM and a LUKS encrypted partition (in whatever order). Systemctl-boot will load the kernel and it’s initramfs, but can’t be bothered to deal with complicated file system shenanigans. That would complicate the whole program significantly.

So it just loads a Linux kernel which has these capabilities. That kernel can deal with LVM, decrypt the LUKS partition (or ask for a password), mount whatever btrfs nonsense is inside and then hand it over to the proper kernel. The proper kernel can in turn rely on having all its stuff mounted and ready, instead of having to worry about all this.

You could do with just one kernel, but Dracut allows you to rapidly create bootable kernel + initramfs pairs of which you might need multiple (e.g. for dual booting, backup). Moreover, you probably wouldn’t really want it to fiddle with your kernel all the time, especially when it’s customised already.

The kernel in the EFI partition is used as a tool to bootstrap hardware and memory for your proper kernel, which is chainloaded.

There is a simple reason for that: The Linux kernel can do anything a bootloader needs to do, especially for itself, so why not use it as one?

That said, in most setups there is another bootloader before that, which loads the kernel itself and the initramfs for that kernel. That can be for example systemd-boot, formerly known gummiboot, a minimal bootloader meant to (auto-)discover EFI compatible stuff it can load.

Dracut creates a setup / boot chain like that.

They work.

OpenSUSE exists as a testbed for SLE, I don’t think there’s anything confusing about that. It’s also much easier to get to a sensible setup for new users. If it weren’t for the AUR and the Arch Wiki, I would probably still be using it.