sylware

Just look at the assembly output of significantly sized switch statements (with good random values): it's scary :)

Obvsiously engaging in pleasing as much as it can speculative/BTB hardware (to the cost of memory tables!)

AI bots using the mouse and keyboard on a browser based on those abominations of whatwg cartel web engines. I guess, using directly one of abominations should be enough in most cases.

There are also the 'click farms' with real humans going thru VPNs.

And Big Tech is still misbehaving. They are serial offenders. We need more fines and higher fines... but with hardcore technical regulation on technical interop with small tech.

If you are talking about the massive 'steam runtime' which forces you (indeed...) to compile the 'user namespace' into you kernel, it is only a shabby/not reliable (and disgusting) way to avoid to have to generate 'correct' ELF64 binaries for broad 'distro' support and long term support. Basically, they ship their own full blown distro userland (yep...), but those who did that are hypocrit and dishonnest (not even of bad faith): they still depends on the user linux kernel and system interface shared libs (for instance userland drivers) which fails to load if not sastifying all the whims of "linux" valve devs: it does happen because GNU symbol version/glibc mistmatches and kernels without the weird features and SPECIFIC/EXACT ELF/file system configuration this valve userland wants). Additionally, and probably the worst: game devs will think they have "linux" support, but actually they only have some shabby and unreliable "valve userland linux _ONLY_" support and not a real and "correct" broad "linux" support: namely they ship for something else than valve, likely their binaries won't load anymore.

This is probably one of the worst "linux" ideas from valve, and by very far. This is basically the definition of accute "enshitification", which could be tainted with abuse of dominant position.

I did show how to do all that honestly and 'correctly' in my previous post. This is basically software development 101 for ELF based platforms...

As I pointed out, the real core of the issue is ELF which we know now is completely obsolete on modern hardware architectures for CPU exes and dynamic libraries and more of a kludge/bloat and issue generator than anything else (like microsoft PE+).

In order to peak into hardware speculation/BTB, having a look atswitch lowering seems a good way. Big switches will go into serious convolution to please that hardware since by definition this is a source of a lot of branch mispredicitions.

10GHz since RISC-V archs don't have the dragging down x86_64 legacy?

:p

Yep, for their steam client (and games), they should craft 'correct' ELF64 binaries for broad "linux" distro support and long term support (which would not require the linux user namespace, like tons of "correct" games out there, for instance most, but not all, godot4 based games). Namely, _all_ the ELF64 binaries should statically load _only_ common glibc libs and that with an "old" glibc ABI version (I would target at least ~10 years, but there is no reason anymore to push forward the glibc version for this type of software, namely the next time they change something about the glibc requirement would be... no glibc is required anymore because we did manage to get rid of ELF for exe and dynamic lib finally).

Then, all their ELF64 binaries which require system interface shared libs would dynamically load them (libdl, dlopen/dlsym/dlclose). The system interface shared libs are libasound (the in-process audio software mixer + interface to external audio mixer daemons), the vulkan loader, and the legacy x11 client libs (with a properly tested wayland->x11 fallback).

All the remaining software should be statically loaded then, which probably mean symbol name customization to avoid collision (wayland/libxkbcommon, libz, libcurl, libressl/libopenssls, etc...)

All this does imply the usage of the following ubiquitous compiling/linking options (gcc and probably clang, tinycc? cproc/qbe? scc?): '-static-libgcc -static-libstdc++ -Wl,--enable-new-dtags' (libgcc_s is private to the distro, additionnaly it has been proven again and again its ABI cannot be trusted in the last decade+, and libstdc++ is private to the application as the distro could use another version of the shared c++ runtime, another vendor, or even statically link it to avoid c++ ABI hell... or none).

For linux native games, they should have a program (a bit like the 'verified' one which is limited to the steamdeck and steamos) with automated tools to statically verify some of this 'correctness' (the static loading of shared libs, the ELF dtags like DT_RUNPATH instead fo DT_RPATH, the glibc ABI version) of the ELF64 binaries and guide the game devs on how to fix them. The hard part is the runtime test, basically the dynamic loading of system interface shared libs (with a bit of fallback, for instance wayland->x11).

The really hard part for game/game engine devs is actually 3D programming, which must be super conservative, that to satisfy most 3D driver vendors [and versions...].

Ofc, valve should work with the devs of the major game engines in order to achieve the broadest distro support on the maximum amount of time following those guidelines (godot4/unity/UE/etc).

(I don't talk about the ELF64 relocations handled by the linux kernel and the glibc elf loader which should be stable for forever now).

If things ever move again, it would be first for the removal of ELF for a super simple exe and dynamic libs format which our modern hardware actitectures can handle roughly without kernel help: one log2 aligned segment, one entry point offset for exes, one 'userland' syscall number resolution function offset for dynamic libraries (guarded by hardware try-lock logic, which would guard an in-process 'loaded dynamic lib' tracker too: yep no more external ELF loader). Oh and of course the removal of x11. (I use such simple format for many of my personal projects).

I talked about mostly C/c++ but it is the same ABI requirement for any other compiled language mostly for dynamic loading of ELF system interface shared libs.

(the interface for joypads is the input event devices from the linux kernel).

If am talking about "linux" here, but this applies to any OS.

And maybe in the future we will get a simple hardware programming standard for all GPUs with a shader standard ISA , and then most of the driver complexity will be gone.

valve isn't doing the best 'linux' job to say the least...

But they are currently doing 'anti-cheat' by far the less worse way and they should teach some others...

I am browsing 'upcoming' games (only native to linux), something happened, there is now many more diarrhea games than before. I suspect AI reverse-engineered slop.

I wonder when how will performant big RISC-V micro-architecture once they can access the latest silicon node at TMSC or Intel.

You cannot trust compiler generated machine code and/or significantly sized runtimes. Some simple binary specifications with some assembly implementations (could be on several ISAs, x86_64, RISC-V, etc).

I guess this is what they are doing.

microsoft "open"AI is... open source?

really...

You meant deepseek?

The second it is blocked, they'll move to other applications/protocols able to work without DNS.

Those applications/protocols already exist to 'work around' authoritative regimes around the world. Only their usage will be re-purpose.

And many are not "kids", and even so, "kids" will also be able to use them since those alternative communication apps are packages to be used by non-tech-savvy people.

You are mixing the people demonstrating peacefully and the organized rioters.

This one is on you pal.

Real rioters will dive into no-DNS internet communication. Most internet protocols were designed with DNS independence in mind (read the email RFC, email addresses can have IP literals instead of DNS names which is of paramount importance, which I use BTW).

Namely, in the end, they will have to switch off telecommunication as a whole... well, if they are not interested in gathering intelligence about the rioters.

And then real rioters will have 'mesh communication devices', and then govs will need EM jammers too.

Sooo... govs should work on good and wide spread EM jammers instead of trying to to block DNS...

There is nothing to 'understand': the statistical models of the underlaying reality are far from our higher scale 'emergent' and classic models our brains is used to.

When the "measurement"/"interaction" has a catastrophic :) impact on what you want to understand, won't be easy to "understand" anything.

On the bright side, the universe did throw at us some nibbles through that 'catastrophic' fog which can be "useful".

I think, it is important to teach the mathematical emergence of our classic physics from quantum physics (well... not gravity ofc).

Another important thing to teach kids: the difference between models and reality. We were lucky this emergent physics was not chaotic and have had strong predictability and has been very stable... well we would not exist otherwise.