Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
> Requiring C (compressed) is necessary to avoid splitting the Linux ecosystem. Chips lacking C would never be able to run binaries compiled with C.
Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.
> Also the excuse given by Qualcomm - that it would make all instructions fixed length and so much easier to decode - is just wrong. RISC-V supports variable length instructions, even much longer than 32 bits, and you've just got to deal with it.
It's not wrong. RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined. All existing instructions are 16 or 32 bits. Without C all instructions are 32 bits. You don't have to deal with 48 bit instructions because there aren't any.
It's possible that they will add some in future, but I'm doubtful of that because a) it would be a huge pain, and b) they didn't for Vector which is where it would have been most useful.
> Just because Qualcomm acquired a company with a microarchitecture that could only deal with fixed length instructions is no reason to break the ecosystem.
Yeah it was too late to change but that doesn't mean it wasn't a mistake.
I like RISC-V (it's been my job for the last 7 years) but this is nonsense. Not everything RISC-V is good. CLIC was awful (thankfully it has been abandoned). The spec is not especially well written - the style is inconsistent due to being written by many authors, and it is waaaay too much of a textbook rather than a proper spec. (There is some ongoing work to improve this tbf.)
There's a practically unending list of undefined/implementation defined behaviours, which is great if you want to implement an ultra minimal microcontroller with 100 flops, but pretty awful otherwise.
Requiring the C (compressed) extension in the RVA profiles was definitely a mistake. The lack of true 16/64kB pages and conditional moves are probably a mistake (though fixable).
I don't know how any of these make it more robust and mature.
(But to be clear, I still think it's pretty good overall.)
> Default lock screen experience still has a needless delay of 5 seconds when entering a wrong (even blank wrong) password, even on the first attempt.
I suspect that is not KDE's fault (or Wayland's) - it's probably PAM, which by default has a 2 second delay (+/- 50%). That default is extremely difficult to change, but you can configure it. See my instructions here: https://github.com/linux-pam/linux-pam/issues/778#issuecomme...
Also if you follow that issue you can see I've been trying to convince the PAM developers to fix it (by changing it to a 0.5 second delay, which is much more tolerable and no less secure). Unfortunately they have this weird idea that users want the delay, because it lets them recompose their thoughts after getting the password wrong or something like that.
Note the shunting yard algorithm is an iterative (as opposed to recursive) version of Pratt parsing (and also precedence climbing which is virtually identical). However as normally stated it does not do proper error checking - it will accept totally invalid input.
It is. Only the default changed. Also you can press tab if someone happens to be looking over your shoulder (and your password is so obvious they can guess it from the length).
It's really really not. By default PAM has a difficult-to-disable 2ish second minimum delay for all authentication methods. However this is completely pointless for local password authentication because PAM checks password using unix_chkpwd, which has no delay. The comment I linked to is explaining that unix_chkpwd has a silly security theatre delay if you try to run it in a tty, but that's trivial to avoid.
If you want to brute force local password authentication you can just run unix_chkpwd as fast as you like. You don't need to involve PAM at all, so its 2 seconds delay achieves nothing.
It maybe does more for remote connections but I'm not sure about that either - if you want to check 10k ssh passwords per second what stops you making 10k separate connections every second? I don't think the 2 second delay helps there at all.
> Change both the config files and you can remove the delay if you want.
This is extremely complicated. See the comments in the issue for details.
You make it sound like there was a discussion where they looked at these two alternatives and chose improving sudo over using run0. Actually I just submitted a patch for this and they accepted it. I don't work for Ubuntu and I didn't even know run0 existed until now (it does sound good though; I hope they switch to that).
Yeah I would like to fix those too but sudo is the one I encounter most. Also the existence of sudo-rs meant there was less push-back. I seriously doubt the maintainers of openssh or passwd would accept this change.
I didn't actually know that Mint had enabled this by default. That would have been a useful counterpoint to the naysayers.
If you want the original behaviour you don't actually need to change the configuration - they added a patch afterwards so you can press tab and it will hide the password just for that time.
> The catalyst for Ubuntu’s change is sudo-rs
Actually it was me getting sufficiently pissed off at the 2 second delay for invalid passwords in sudo (actually PAM's fault). There's no reason for it (if you think there is look up unix_chkpwd). I tried to fix it but the PAM people have this strange idea that people like the delay. So I gave up on that and thought I may as well try fixing this other UX facepalm too. I doubt it would have happened with the original sudo (and they said as much) so it did require sudo-rs to exist.
I think this is one of the benefits of rewriting coreutils and so on in Rust - people are way more open to fixing long-standing issues. You don't get the whole "why are you overturning 46 years of tradition??" nonsense.
> i.e. this doesn't require age verification at all, just a user profile age property
This is usually how they do it though. First make a dumb law with poor enforcement. People don't push back about it because it obviously won't be enforced. Wait a bit, then say "people are flagrantly violating this law, we need better enforcement". At that point it's a lot harder to say "it shouldn't be a law at all!" because nobody complained when it was brought into law.
lol what? They've caught and successfully reflown the super heavy booster, and they've mostly successfully done a soft landing of Starship in the sea. How is that remotely "just talk"?
It's going to be optional - the hooks will always fix the code if they can, but then you can supply a `--no-fix` flag (or config) if you want to tell it to not actually apply those changes to the real filesystem.
It doesn't need Landlock because WASI already provides a VFS.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).