sylware

If we manage to keep the dev tantrums/planned obsolescence at bay, all you will need, if the game devs or game engine devs are competent, is a lean elf(glibc)/linux distro: a set of glibc libs (interwined with the system ELF loader), the vulkan loader, libasound, a wayland compositor, and related linux userland interfaces.

In the future, we can expect a much simpler file format to replace ELF for CPU executables and dynamic libraries (ELF is beyond obsolete and overkill on modern hardware achitectures and its complexity is source of many issues), and maybe pure and standard GPU hardware command instanciable ring buffers, but that's much further away in the future, as we "don't know yet" (but we do for CPUs), and we still could get GPU vendor specific hardware command instanciable ring buffers (it seems this how the PS5 works).

If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.

If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).

Are AI scrappers using the web engines from the whatwg cartel already?

Aren't the IP ranges they operate on properly known?

Yeah... cartel stuff again.

c++ is sorta private to the application.

If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.

You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).

To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).

(BTW, is the c++ intel compiler still shipping??)

If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).

This is required for broad distro support [and long term support].

Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.

I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.

The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.

If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.

Nope, very different words :)

Ivory -> Ivoire

Silver -> argent

Often, I don't know or do the wrong translation of culture/language specific idioms.

Isn't that the "silver tower" syndrom?

The gogol agenda of blocking and excluding all web engines not part of their whatwg cartel is moving forward, at a slow pace, steathly.

gogol search was blocked to all noscript/basic HTML browsers last year. I recall people that a few years before, they removed their gmail basic HTML interface not long after that their account creation (then login) would require one the abominations of the whatwg cartel.

I have been working around the gogol search engine since then and my email is now self hosted without DNS (IPv6 literals, see RFC). Yeah, most DNS registrars are now gated by the whatwg cartel web engines in some way, this is the net effect of big corpos toxic behavior.

Pure evil.

Hopefully for RAM and RISC-V ultra-performant µarchitectures.

Yeah, I am advocating for I would like to happen (hopefully INTEL and AMD will put a RISC-V decodecs on their µarchitecture out of good will... yeah since they hold the x86 and x86_64 IP then excluding all alternatives de-facto... the incentive is.. negative.

If I am not mistaken, EU is currently pouring money in defence. For defence needs, one state-of-art chip build line is enough... the EU armies could even share it.

Got phished...

I would like AMD to put a RISC-V decoder front-end in its micro-architectures.

TT is politely and gently trying to deal with the ego of many mathematicians, namely to teach them humility, which they will need to design their specialized maths AI models(agents?). Well, dunno if it will work out anything interesting, but he is giving a try.

I wonder if the current maths models, if any, are able to use formal solvers in their 'reasoning'. I wonder if a natural language interface is really that efficient, maybe a pure formal language hinted with intuitive "tokens". I remember the time I was learning real maths: "elegant", "brutal", "strong", etc were somewhat meaningfull.

Something does not add up there: inference on interesting models is already very slow by itself on consumer systems. "Sending to a GPU" is literaly "zero time".

No other workloads? Really?

Because, if I am not too mistaken, inference hardware would do all that and directly on the silicon, namely much faster and using much less energy.

Or is this to run quantized models on consumer CPUs??? Weird, because, if I do run models on my consumer system, I will want the full weights of the frontier open weight models.

What heavy CPU workloads AVX10 V2 AUX could help accelerate significantly?

It has a smells of 'we need to push back our IP deadlines' thingy.

Nope, I am blocked by anubis: javascript of recent whatwg cartel web engines (the worst of the worst).

I am looking for a noscript/basic HTML alternative front.

Any reddit noscript/basic HTML frontend alternative?

Well, with all the enshitified complex file formats out there, I bet this is a "piece of cake" (for the people of the field with good tooling) to find exploits in the state management of code dealing with them. And very high computer languages/specialized script languages won't protect anything as those are "logic errors". I think "closing" state machines on such complex file formats is just pointless, better design new file formats from the ground up, but this time with a much stronger focus on robustness (keep that state machine as small and simple as possible and super rigorously well defined, and I mean like maths maniacs). And it is hard: because the purpose of the file format must come AFTER the robustness, namely tough compromise on the purpose itself may have to be done.

Here, "regulation" is more about a "minimal platform for interop" than anti-trust.

That "minimal platform for interop" would be made of simple but able to do a good job enough and stable in time file formats and protocols. This minimal platform must be reasonably implemented with "Small Tech" (excluding de facto the whatwg cartel web engine and computer languages with ultra-complex languages or heavy runtime this is common sense).

That "minimal platform" should probably be made with subsets of current file formats and protocols. As I said, for instance a subset of PDF (with validation tools), mandatory handling of basic UTF-8 text files, no script/basic HTML for the web, brutally simple SMTP support (aka self-hosted, not paying for DNS, or email addresses with IPs literals, only the commands to send actually emails without fideling around), IRC bridge for chat, etc.

BTW, on the "assembly to save us", I was talking about very high level languages with interpreters/JITs coded directly in assembly (aka binary specifications), then Mr. Bellard quickjs, but also obviously python (but it seems its syntax is going amok which is bad omens)/lua/etc.

This "platform" should slow down a lot the endless enshitification cycle we are into.

If AI coding is that powerfull (cannot test it as its access is gated by the whatwg cartel web engines), it can probably help: like I said, since we are not alone, look at what the others like me did: they are using it to write transpilers from ultra-complex computer language syntaxes, I saw on HN this norvegian guy who is using AI coding to help write directly in 'human readable' assembly (here x86_64) the binary specifications of its own everyday software.

This plaform must be very rigid, but not completely, namely rational removal/restructuring could happen. Basically, implementation "from scratch" by "Small Tech" must always be reasonable.

Aside of all that, there is the ultimate hard truth: for much software developement, but not all, it is extremely hard to justify a permanent income and that honestly. Making all that very complicated to fit in any economy.

Here, only regulation can help, there is no going against corpos with billions of $ and backed by funds of thousands of billions of $. Much of Big Tech abuses non pertinent complexity and size, not to mention their manic usage of planned obsolescence. There, the regulation should secure and set in ice a basic subset of file formats and protocols for interoperability which are known to be reasonable to implement again from scratch with "Small Tech". And by subset, I meant for instance noscript/basic HTML for the web; UTF-8 text files for text; I guess JSON should be favored over XML; a subset of PDF (certainly not all of it...);etc. If an online service have a 'chat', a basic IRC bridge should be there with a properly display access URL, etc, etc. That does not block "new" and "innovative" things to happen in any way.

Some of Big Tech hates "small is beautiful" and stability in time then will fight hard with their $ for that not to happen (administration "corruption"). Complexity and size (including the SDK then the computer language syntax complexity) is their bread and butter to keep "control" and keep alternatives away.

For the "bootstrappable", it is the starting point of building from 'small and simple' toward big and complex, aka the SDK 'binary seed'. At the time anybody would expect a 'simple C compiler' with a simple linker and assembler buildable with that simple C compiler... but people at the gcc steering commitee and the usage of many C extensions without maintaining proper fallback to assembler source files (in kernels, hence linux) broke the chain of 'sanity' for good. Now you must have an ultra complex c++ compiler to "bootstrap" (~LFS), not to mention the required zillions of complex tools required by the "build systems". Lately, it seems AI coding may be the salvation here... How? AI seems to assist writting c++(insert you computer language with a complex syntax here) to simple C "transpilers" (somebody pretended to have done the same with a rust->simple C transpiler, was published here on HN). I have to say I have never used AI, since they are gated with the web engines of the whatwg cartel (I cannot even get a token to use some web API), I have never tested.

The conclusion: fixing the software stack to let sane small alternatives to 'exist' and be 'real life' is probably not going to be calm and quiet.

I did not get everything you said, sorry.

But where I do agree: I presented the "assembly saving the world from big tech toxicity" would come with very high level scripting languages (probably a mess... but less toxic than what we have today), but with their interpreters/JIT "compilers" written is such assembly without abuse of any macro pre-processor.

I gave some thoughts about porting Bellard quickjs to pure hand written/tool assisted RISC-V assembly.

In the SDK, I do include the "compiler": the computer language syntax complexity is critical here since it is a barrier of entry of any new "real-life" alternative compiler. NetBSD won't protect you here.

For this major reason, computer languages with a "simple" syntax and "alternative" real-life compilers should be favored (or you know it is reasonable to build one from scratch). The current _LESS WORSE_ alternative is C and similar. But this is far from a silver bullet. I think our only way out, namely getting rid of all this toxicity is assembly without abuse of any macro-preprocessor, that's why worldwide non-IP locked ISA standard like RISC-V are so much important.

Ohohoh! The complexity and cost of the various "open source SDKs" is on stellar scale. I build my own distro, and I usually remove SDKs to switch to linear orthogonal brutal build shell scripts... and I am going to warn you, you are going to see a lot of ugly close to insane.

You'll see also a good amount of more than questionable code generators. And when you will have a look at some _GNU_ makefiles of big corner-stone projects, you will question the sanity of their authors (the "makefile" itself is often, but not all the time, very questionable too nowdays). Everything was with a good intent, turned sour and painful on the long run.

On our modern computers, we should have "one-compilation-units" for most, if not all binary products (exes or shared libs) anyways. "Same language" binary static linking in the open source world should not be a thing anymore (have a look at those 'header-only' projects).

The invisible backdoor injectors (namely compilers) are a problem, for many reasons that most know here (barrier to implementation of real-life alternatives, [open source] developer lock-in, etc). The more complex is the syntax of a computer language, the worst it is (on c++ syntax complexity scale, or with a heavy/intrusive required runtime like many "new" languages do shove down your throat).

If you don't see any issue, get cproc/qbe C compiler (and the binutils gas assembler), then you compile linux (with a brutal and linear shell script, let's say for a real life x86_64 desktop) and we'll talk again after, ok? And once you succeed, we'll see how it holds in 7-10 years (the time ISO takes to break in a non pertinent way many things).

Well, in this very case, it is more complicated than that: they have to protect their software against planned obsolescence and developer tantrum (it would be the same for any "in production software").

Modifications and changes must be weighted very carefully. For instance "removing" (including in the SDK) is usually a less worse modifications than the others and it decreases the global technical size and complexity/number of layers of the stack/SDK (which is top priority in "security"), namely most of the time but not everytime a good thing.

Because, on most complex software (open source or not), a "believed" benign modification can be disastrous. It is even worse if close to bare metal involving complex hardware (even with massive QA[testing]).

The step by step is the right approach... but you'll discover that many 'components' are _INSANE_ and that includes their SDK.

Bare LFS is not enough (I run my own): you need a kind of userland (above glibc) multi-version system which some kind of "atomic-ish" switching (always have a stable SSH running in case something goes wrong, better than unplugging the system disk and fix it on another computer).

For linux, same thing, with a kind of flip-flop-ing for updates/fix/etc.

The insight that gives you will probably scare you: the current "open source" stack is an abomination (the worst is the SDKs I think).

That's why we need _LEAN_ open source, and that includes the SDKs.

I know (like selling software without official technical support), I was asking if actual and real hacking did occure.

In this case, they are probably big tech brain washed and lack a lot of experience/perspective.

I remember the time when I was warned again corpos: nice in the first decade, then nasty afterwards.

What's they were hacked and their current work in progress 'stolen'?

On my open source projects, there is always a big "WIP" messy phase which I don't "really" publish... because it is messy.

A elite dev is not someone who is "not doing any mistakes" (if that has a meaning in the first place)

A dev is much more likely to be qualified as elite when you look at how he/she handles his/her own 'real' mistakes.

Huh?

Re-using advances done by others is necessary in maths.

This is how hard sciences do progress.

Then if those BOTS are using whatwg web engines, what are your options?

Not to mention, they could be click farms with real humans behind, then what can you do?