201984

Ugly doesn't matter as long as it works better (and I heavily disagree on all of the things you stated.)

Yeah, what's counting as "adoption" here?

> As opposed to something else, like a new shell extension or a new filesystem filter driver on Windows 11?

Ultimately, what difference does it make? The file explorer in Windows 10 is much faster than the one in Windows 11, and it's very noticeable. Turn on the old context menus, and try right clicking a file. Instant in Windows 10, visible delay in Windows 11.

But don't you get it? We're moving up the value chain to things only WE can do.

And now if I want to send a .apk to someone, they have to wipe their entire phone to install it? No thanks.

GPTZero (not sure how reliable it is) said it was 100% generated.

>Let that sink in

That's a hallmark of GPT spam, so it's not surprising there's hallucinations.

With the paywall blocker so good it got banned! You can also get it on Android.

https://gitflic.ru/project/magnolia1234/bypass-paywalls-fire...

>You have given the latencies of the instructions, not their throughput. When you use AES in such a way that you are limited by latency, that is normally wrong.

I did that because TFA is talking about encrypting 32 bit IDs, which is 1/4th of an AES block. There aren't multiple blocks to do at once in this scenario, and throughput numbers do not apply because each instruction depends on the result of the one before.

You mention doing multiple IDs at once, but the overhead of pulling multiple IDs into a single batch from something akin to URLs in web requests is likely gonna be worse than any gains.

>Instead of this, you should use as identifier an unpredictable random number. Such identifiers can be generated with AES in batches, at maximum throughput, and stored until they are needed for assignment to a record.

Now you lose the ability to sort the records in a database, and I fail to see what AES gives you here over any other random number generator.

Ascon is a stream-oriented AEAD, not a block cipher, and it requires a nonce. Because of this, it would not work for the usecases in TFA, not to mention it's also quite a bit slower than Speck.

There's nothing similar about AES and Speck, and the "microcode" for AES isn't like what you're thinking of. If you want to learn more about it, you can look up the specifications for AES and Intel's AES instruction set.

>EDIT: What I mean is you can do cypher = truncate(plain ^ AES(zero_extend(plain))).

How would you decrypt that though? You truncated 3/4ths of the AES output needed to decrypt it.

I thought you were suggesting this:

  ciphertext = truncate(AES(key) ^ plaintext)

And in this case, since AES(key) does not depend on the plaintext, it would just be XOR by a constant.

Are you certain using AES is still faster? Let's say for a 32-bit block size and 64-bit key.

From https://en.wikipedia.org/wiki/Speck_(cipher), that Speck combination would use 22 rounds, and using the instruction timings for Zen 5 from https://instlatx64.github.io/InstLatx64/AuthenticAMD/Authent..., it looks like each round would take at most 3 cycles. (Dependency chain for each round is 3 instructions long, ror+add+xor). 22*3 = ~66 cycles.

Using AES with a pshufb to take out the ShiftRows step would be 2 cycles for the pshufb and 4 cycles for each aesenc, and at 10 rounds, you have ~60 cycles.

It's quite close, and to say which one wins, we'd need to actually benchmark it. One is not clearly much faster than the other.

In the context of encrypting 32 or 64 bit IDs, where there is no nonce, that'd be equivalent to XOR encryption and much weaker than TFA's small block ciphers.

Their wiki is what sold me on Arch. I ended up there solving most of my problems on other distros, and if they can make such a fine wiki, I figured they could make a great OS (which they did).

I assume this is sarcasm, given your other comments? Even if it is, it's still quite rude.

>They totally forgot about not compiling invalid code.

Indeed. For a specific example of it not erroring out:

https://www.reddit.com/r/Compilers/comments/1qx7b12/comment/...

Professional-Managerial Class, as opposed to working class or proletariat.

What about all those Windows on ARM laptops?

I do

I played around with it, and it's very neat. This is the first time I've seen an assembly REPL and I wish I had something like this that ran native for playing with unfamiliar instructions.

I did find a couple minor issues with the simulator: MVN is supposed to be a bitwise NOT but the simulator does a two's-complement negation instead (https://github.com/rtybanana/irisc-web/blob/main/src/interpr...), and it seems negative immediate offsets aren't supported, e.g.

  ldr r0, [r1, #-4]

Sadly, schools don't have real computers any more, it's all chromebooks. Gen Alpha is going to be completely computer illiterate.

I'm sure that number is using glibc, not musl.

What does NaCl (seems to be some random crypto library?) have to do with this?

How don't they? Most x86 instructions map to just one or two uops as you can see at https://uops.info

Archive link for your CADT reference: https://archive.ph/t5m32

I wish websites weren't allowed to know what site a user is coming from.

The kernel is stable, but all the system libraries needed to make a grapical application are not. Over the last 20 years, we've gone from GTK 2 to 4, X11 to Wayland, Qt 4 to 6, with compatibility breakages with each change. Building an unmodified 20 year old application from source is very likely to not work, running a 20 year old binary even less so.

Most people can understand "bigger number better". They don't need the full theoretical derivation of the watt as a unit of power for that.

inline and register still have semantic requirements that are not just hints. Taking the address of a register variable is illegal, and inline allows a function to be defined in multiple .c files without errors.