Reminds me of a proof-of-concept I took years ago : https://github.com/alex14fr/wgsig

The main difference with wpex is that the central server does not have to forward packets exchanged between peers, I guess.

wpex also does not need custom client software.

Just use Linux bro.

This feels way slower than https://bellard.org/jslinux/

I tried compiling mandelbrot.c (single threaded one) from the benchmarks game and execution on jslinux took 12 seconds, while webvm completed it in 1.2 sec. The host takes 0.03 sec with the same gcc flags.

It may be faster for this particular benchmark, yet it feels slow and sluggish for interactive use.

Hard to compete with Bellard :)

Yay ! More AI-generated sheet !!

The irony.

Just use yt-dlp bro.

I have trouble understanding this part:

> Beware, messing out with your clocks via sysfs without knowing what you are doing may permanently damage your device at the hardware level, so if you're clueless, don't mess around.

Anyway, very nice and informative article, thanks !

Thanks, it means what it means, it asserts a #define on clk.c whereby root will be able to do very stupid things with clocks...

Ok, but to me it seems to mean that the hardware may be permanently damaged (= a power cycle does not fix the issue) by a wrong clock setting, and I wonder why.

Well the simplest example I can give you is overclocking your CPU or GPU. If you do that past a certain limit, it would be damaging to the hardware don't you agree?

The correct implementation of the power-up script for Rock Pi N10 NPU should be as a kernel module, this way we don't have to enable any dangerous #defines in clk.c

And on the same day, what a coincidence, a Syrian illegal "migrant" stabs 8 children in a park...

What exactly are you trying to imply with this comment?

not OP, but maybe he implies the attack was instrumented to make the bill pass.

I guess one answer could be to add a physical switch to disconnect microphone, or use a removable microphone.

Glad to have sticked with the good old iptables and left CONFIG_NF_TABLES unset in kernel configuration.

Aren't iptables just an emulation layer on top of netfilter?

For modern distros, the nft package includes an alternative binary that takes the place of /sbin/iptables and translates the input to an nft compatible format. As far as the kernel is concerned, iptables is still iptables. Old iptables can be accessed by calling the iptables-legacy binary which will auto load the old iptables ko.

Yes, AFAIU (not an expert), iptables and nftables are two command line tools and abstractions (chains vs. tables) for interacting with the same underlying netfilter API.

I believe at one time they were two separate subsystems, but they got merged in 4.x or 5.x

I run 6.3 and the incriminated files were not compiled in my kernel thanks to CONFIG_NF_TABLES=n during make config.

Probably depends on the distro. Iptables is a wrapper around nftables in most distros, but probably not all.

You can check with: iptables -V

If it says (nf_tables), you are using the compatibility layer from the iptables-nft package.

It works quite well. Apps like Docker that inserts rules using the legacy iptables syntax are oblivious to the fact that they are actually inserting nftables rules.

It also provides an easy migration path. Insert your old rules using your iptables script then list them in the new syntax using nft list ruleset.

The problem is that it works so well that it seems most users just stayed with the iptables syntax and did not bother migrating at all.

IMO, the problem is that the people who created nftables (and the "ip" tool) couldn't create a user interface that anyone but themselves would like to use. Linux traffic shaping functionality suffers from the same "obscure word soup" interface.

I agree for the "ip" tool (from iproute2).. I got used to it but I still prefer the ifconfig output. It is somehow consistant and you can get used to it.

I somehow got accustomed to the nftables rules format. It is in fact objectively much better than the iptables format in many ways. The native JSON, easy bulk submit to the kernel, built-in sets and maps (the source of the currently discussed CVE though). It really does fix a lot of what was wrong with iptables.

But iptables was probably not broken enough for most users to warrant re-learning everything.

Now, the traffic shaping tool, oof.. I still cannot grok any of it. I've been happy with the fireqos script so far to abstract everything out of the tc syntax.