Hacker-Typer VS linux

Hacker Typer is pure fun! It simulates typing like a Hollywood hacker. Use it to entertain your colleagues during presentations or meetings.

that - not in the same way - reminds me of a similar pair of web pages:

https://hackertyper.net - nice

https://hackertyper.com - sociopathic corruption of ad links

Because users can be extremely dumb. Ive had friends that work in tech centers open up hackertyper (after doing analysis and finding nothing) in front of their nose to "hack the hackers back" because the users kept thinking their PC was being hacked

I think this is intended as more of a proof of concept than as a useful change, but apparently this driver is going to be enabled on Fedora rawhide soon.

https://github.com/torvalds/linux/blob/master/drivers/net/ph...

MR where they are working though a build system issue: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3...

We mostly agree. My comments re: whether Drew's proposed solution is a reasonable alternative to Rust for Linux are in a sister comment.

> To someone who isn't accustomed to idiomatic Rust, it seems completely insane to have to go digging around in the type system in order to enable magic elsewhere in the call stack, when you can just tell the computer what to do.

I think this would be a fairer point if the interface was a well documented C interface which showed how to use the interface correctly but it wasn't.

See the API docs: https://www.kernel.org/doc/html/v6.0/filesystems/api-summary...

And the function itself: https://github.com/torvalds/linux/blob/d5d547aa7b51467b15d9c...

If these guys don't like types, fine. But these guys need help quick if the above is the best they can summon.

> I do not know why the JMP is not just a RET, however.

The jump seems generated by the expansion of the `ASM_CLAC` macro, which is supposed to change the EFLAGS register ([1], [2]). However in this case the expansion looks like it does nothing (maybe because of the target ?). I 'd be interested to know more about that. Call to the wild.

[1]: https://github.com/torvalds/linux/blob/master/arch/x86/inclu...

[2]: https://stackoverflow.com/a/60579385

Like I said, not anti-email. I don't see why it's git vs cvs:

> Recall that git was also designed to work over mailing lists. git format-patch, git apply, etc.

Right, and when you do web things with that same git in 2024, it looks and works like it's 2024.

You could use an old git server/file browser UI, or the built-in gitweb[0] for example, but you don't, you use something more modern & featureful, working better on mobile, looking prettier, etc. Even Linux (with its history intertwined with git) uses Github[1] as its mirror, not gitweb or anything looking like the link above for OpenBSD.

[0]: https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/

[1]: https://github.com/torvalds/linux

Losing fetch bandwidth past a taken branch is a different thing.

4. Not sure where you're going. You started by suggesting Arm has less micro-op expansion than x86, and I provided a counterexample. Now you're talking about avoiding complex instructions, which a) compilers do on both architectures, they'll avoid stuff like division, and b) humans don't in cases where complex instructions are beneficial, see Linux kernel using rep movsb (https://github.com/torvalds/linux/blob/5189dafa4cf950e675f02...), and Arm introducing similar complex instructions (https://community.arm.com/arm-community-blogs/b/architecture...)

Also "complex" x86 instructions aren't avoided in the video encoding workload. On x86 it takes ~16.5T instructions to finish the workload, and ~19.9T on Arm (and ~23.8T micro-ops on Neoverse V2). If "complex" means more work per instruction, then x86 used more complex instructions, right?

8. You can use a variable length NOP on x86, or multiple NOPs on Arm to align function calls to cacheline boundaries. What's the difference? Isn't the latter worse if you need to move by more than 4 bytes, since you have multiple NOPs (and thus multiple uops, which you think is the case but isn't always true, as some x86 and some Arm CPUs can fuse NOP pairs)

But seriously, do try gathering some data to see if cacheline alignment matters. A lot of x86/Arm cores that do micro-op caching don't seem to care if a function (or branch target) is aligned to the start of a cacheline. Golden Cove's return predictor does appear to track targets at cacheline granularity, but that's a special case. Earlier Intel and pretty much all AMD cores don't seem to care, nor do the Arm ones I've tested.

Anyway, you're making a lot of unsubstantiated guesses on "weirdness" without anything to suggest it has any effect. I don't think this is the right approach. Instead of "tail wagging the dog" or whatever, I suggest a data-based approach where you conduct experiments on some x86/Arm CPUs, and analyze some x86/Arm programs. I guess the analogy is, tell the dog to do something and see how it behaves? Then draw conclusions off that?

Linux

We're talking about the company that had to contribute arbitrary-length command lines to the Linux kernel, and whose flags library supports reading the flags from a file, in case your appetite for flags is insatiable.

https://github.com/torvalds/linux/commit/b6a2fea39318e43fee8...

Yes, but it's hard to find in the kernel:

https://github.com/torvalds/linux/tree/5437f30d3458ad36e83ab...