At least in macos the key you’re thinking of is called command, not meta. The history of the key names is that originally the space cadet keyboard had 4 modifier keys, control, meta, super, and hyper. When emacs was originally written it was aimed at this keyboard with those modifers. When using a PC keyboard emacs often mapped meta to alt and nothing for super until the windows key was introduced by Microsoft which made it a natural option for super and so the hyper key is the only one that totally died off.

Man, it sure is confusing that apparently some software calls the super key meta. Historically that’s alt and a lot of software calls alt meta instead. My brain was bending over backwards reading this article, confused as to why alt and meta were being used simultaneously as though separate until I figured it out.

EDIT: lol, I just noticed apparently the KDE key remapper used meta in place of alt so we’ve got both uses of meta in the same article and the author went with the keyd definition…

As others have said I wouldn’t recommend testing as it doesn’t get security updates, however I personally run sid (unstable) and have for a long time now. At least since 2020 if I recall, it does occasionally break, albeit anecdotally less than my friends arch system, can’t comment on if that’s the distro or just our individual setups. The main reason I run it is because I like debian, I’m very familiar with apt, with its initramfs tools, with all of the debianisms but I wanted something rolling. I tried arch but it just wasn’t as comfy for me personally. That being said it is a bit like hard mode, there is no arch wiki, if you don’t do heavy customization that might be ok, sometimes I’ve wanted to tweak my initramfs and while I know the debian generator better than arch, there’s far less easily accessible documentation on it. In general it’s been such a good experience that I basically stopped distro hopping, it’s been my home now for a long time but I know I’m in the minority with that so take it as you will.

Glad you got it working. It’s not exactly the most straight forward setup unless you use virt manager a lot.

Virt manager does but only during creation. You have to check the option for “customize VM before creation” or whatever that option is on the last screen. Then there’s a firmware drop down where you can select OVMF

I don’t believe pika supports booting from a BIOS as almost no real systems have a BIOS anymore, especially not the target systems pika is designed for. You likely need to switch to UEFI firmware in qemu, possibly installing the ovmf package if you don’t already have it and then switching to that firmware in whatever VM manager you’re running

Wonder if you use kpartx to read the partition table instead of having the kernel do it if you’d have more luck?

but really we need to stop these laws from happening in the first place. I will grant that the poster does not attribute foot nor bad to the situation.

What I think everyone is trying to tell you is that nobody is disagreeing with this sentiment. These laws are bad, I doubt the poster of the article would disagree. What is trying to be said here is if these laws go into affect (which is bad), and they exempt Linux (which seems good), they will quite possibly condemn Linux to an even smaller niche of tech nerds than it already belongs to and that is bad for Linux being a desktop platform, and it may be better for Linux to comply for its survival as a desktop platform. That is all that’s being said here, nobody is arguing the merits of the laws.

Command line browsers do exist but are usually worse than the others mentioned in terms of site support.

Yes, you CAN stop there, the other qualifiers I added were specifically because C sort of assumes those to be present and while there are C to bf compilers they emulate that functionality on top of the more restrictive, but turing complete, architecture. I was listing the things C assumes/requires the hardware to be able to do for reasonable performance and compilers not emulating features.

These are not language features but features of the C standard library and are only required if you wish to use said library, they have little to do with hardware requirements or the language itself

You aren’t wrong but classically a high level language is one that is abstracted from the hardware which is precisely why C is considered high level. You don’t have to think about registers, instructions, stacks, etc, you just call functions with arguments and write “high level” code. It’s on the lower end compared to modern very high level languages but it’s still considered high level. Classically most non-assembly languages are.

Yeah, I get both sides too, I also want Linux to be successful but I’m just disappointed this is what we’re resorting to. Although I guess as long as I don’t have to use it it’s probably for the greater good?

I already don’t compile it in…I’m just stating my opinion. I don’t think that should be something in the kernel. I complain, but I also do something about it.

It’s not a scheduler issue, it’s a windows apps do thread synchronization differently to linux apps. Additionally fsync in the vast majority of use cases works just fine, the article notes most performance comparisons are against vanilla wine synchronization, i.e. without fsync or even esync. Regardless I still don’t think the kernel should be emulating windows scheduling behavior.

I’ve honestly not heard that particular argument for why C isn’t low level. I’m not even sure I see what design choices they made which are PDP specific. C seems to fit pretty well on top of computer architecture as a whole. As long as you’re turing complete, have RAM, and the ability to issue function calls you basically have everything you need for C. The main reason I’m familiar with for why it’s high level is because it’s ISA independent. C comes from a time where most software was written in assembly and so highly CPU specific. C isn’t that, you write C for one platform and it works everywhere, just need a recompile (provided all the APIs you use are available)

No, that’s not quite the same thing, I fundamentally don’t think it should be Linux’s goal to be a good windows emulator. It’s fine if wine exists and people use wine for that, but I don’t think that should be a goal for the kernel, this starts pushing into that territory. Hardware support very much is the Kernel’s job and modules which benefit it should be there if it’s meaningful

A lot of people like to call C low level, maybe in modern times that’s fair? It misses the historical context of why it’s not usually considered one though and it’s ultimately sort of relative.

But if you read the article even valve said fsync was basically good enough, why go this far if the improvements compared to fsync aren’t amazing?

XD, I do, I already build my own kernel and turn it off…just saying I don’t like it

I mean…the code isn’t copied but the design is and it honestly frustrates me. Like yes Linux performance is improving…but I personally don’t like adding kernel functionality specifically for the benefit of wine

Even if it was built in it probably wouldn’t get full root, SELinux borks a lot of root exploits even if they privesc correctly.