sylware

Is this an hoax? Because those equipement should not have been on the 'internet' anymore, or with software/hardware built around "security" (aka no bloat, no kludge, _really_ minimal and assembly written?)

Problem: they will need to have access to huge Machine Learning and inference hardware for maths specific models.

It won't be for all mathematicians, only those willing to deal with the "recipies" of ML, and those "granted" access to such hardware because a not very common resource like classic super-computers. I suspect if all that is true, maths will need bigger teams per "problem", aka will need to team up more around some math stuff.

Nope, in my "first world" country, some consumer IAPs does offer a static IPv4 with a non-filtered SMTP port and a static IPv6 prefix (usually a /64 which is very convenient to change email address/hosting IPs when compromised, well if you use an address email with an IPv6 literal). But I don't really use IPv4 anymore for my self-hosting, IPv6 has been around _here_ for a very, very long time for nearly everybody if not everybody (even mobile internet).

Yes, I know my IPv4 is the target of distributed port scans, by IPs known as compromised by the "security" community. I guess my IAP "security" team knows, and they may probably be 'in the process of doing something to deal with them'... (which would more than IP blocking and would involve authorities...).

FTTH(8GB), static IPv6, static IPv4 plus opened SMTP port, ~30 bucks a month (for millions).

Well, the combination of the maths with their implementations then... (hardware and software).

I wonder when such "AI"s will go after crypo maths...

Google blocks IP literal email addresses (which is stronger than SPF and should be part of DMARC).

I am self-hosted: minimal smtp server, no TLS, only direct and basic delivery of emails. I don't even pay the DNS mob, namely I use IP literals (mailbox@[x.x.x.x] and more mailbox@[ipv6:...], see smtp RFC, yeah the email guys were smart enough not to make their protocol hard dependent on DNS neither on any crypto).

I do not trust the CA system. If I ever crypt the content of an email, it would be because a guy I saw gave me its public key in some way (QR code?) face to face. For really serious stuff, I would not use smtp anyway and with some modified-standard-cipher pre-shared key anyways.

Where is the curl web API? Because I use noscript/basic HTML browsers, and this seems to require even a web engine from the whatwg cartel.

Yep, this is a big issue with compilers: you cannot snoop in and skim the code even to have rough understanding of what it does because you need to embrace and be proficient, nearly all the time, with their 'hardcore abstracted' model.

I did dive in LLVM a long time ago, and OMG... we have to get rid of it.

On the long term, gcc and clang are cooked, better move to binary specifications with various ISA implementations. Ofc here, we would need a bit of optimization knowledge in order to write assembly code not too much under-performant (because the goal here would not be speed, but independence from compilers!)

But it is not that much horrible: most performant micro-architectures use the same speculative concepts, then it is a matter to find the sweet spot between all of them: a good generic conditional branch machine instruction layout of a cache line with some additional care for non-conditional branch, and use branchless logic as much as you can. It is a matter to know such patterns: hopefully all those "coding AIs" can help (never tested them, cannot access them).

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'.