sylware
RISC-V is IP UNlocked. I bought RISC-V mini-boards (so cheap) years ago because I was planning to build my keyboard... but I am still on other projects... and there are even better RISC-V miniboard nowdays (better USB, more GPIOs... for a full fledge BFO-9000 keyboard!).
What I am waiting for are RISC-V high performance micro-architectures which will use the best silicon node (desktop, mobile, and for servers it seems there are a few attempts). One of the main issue seems... the compressed instructions which should be removed as it increases implementation complexity significantly in order to apply some of the known high-performance optimizations (it is not anectodale if ARM removed thumb machine instructions).
I like the idea, I code as much as possible things in RISC-V assembly now, and re-use a ton of code paths (at the assembly level!). I have even written a small RISC-V interpreter for x86_64 for static exes.
Giving a IPv4 and IPv6 prefix is what an ISP do...
Hoax?
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.
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).
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.
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).
Obvsiously engaging in pleasing as much as it can speculative/BTB hardware (to the cost of memory tables!)
There are also the 'click farms' with real humans going thru VPNs.
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+).
:p
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.
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 guess this is what they are doing.
really...
You meant deepseek?
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.
This one is on you pal.
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...
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.