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.

Technical debt will suffocate them after a while. Often, but not all the time, technical debt happens fast, very fast.

riots from the 17th of october: 0 deaths. heavy rain a few days later: 3 deaths. one KKK terrorist (ex drug dealer): 1 death.

This is 101 "optimization":

First the algorithms and the models. Then machine code on some micro-architecture.

The real problem with classic computer languages: dependency on vendor-locked (open source or not) compilers and runtimes happens super fast.

If it is formal, you don't need LLM.

If you need LLM, it is not formal.

Formal software are not LLMs.

LLMs/agents can use formal software.

The limit of formal software is the formal model itself, roughly speaking the binary specification is designed by humans. If the formal model is "wrong", bravo, you have formally proven a "wrong" model...

For that abomination, like gcc, I hope nobody.

gov and hype...

Personnaly, I think this is completely broken and even dangerous as it induce in normal people some kind of third-party trust which is worth nothing in reality.

In the end people are tricked in believing that information system security is really a thing and very strong/solid, which is, as we all know here, a fantasy, it does not exist. It is even worse when you have some 'people' pretending to sell 'deliverable security'.

For low bandwidth and personal web sites, aka small and not hacker juicy targets, probabably depends on the user tech tastes more than anything else.

The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.

Unless the money of the investors is going somewhere else...

whatwg javascript gated.

Any other links?

What? Stick to simple PNG. It is simple, runtime and SDK, beyond good enough and has 16bits per color component support (which webp does not have).

RAM price?

Issue: valve announced the beta steam client was finally 64bits clean and nope it cannot start games if you remove 32bits support since their "reaper" command is still 32bits....

Unless I missed something? Yeah? Anyone to enlighten me?

Hopefully, this will end up in its foundation or even the linux one, with most motherboard manufacturers behind it.

But... it should be binary specifications with "human-like" assembly implementations since you have to remove the "compiler" issue from the SDK.

DUDE!

VULKAN!

(and shaders written with a SPIR-V assembler, no glslang!)