Great, by "remain ahead" this implicitly means "put everybody else behind". These are the same people that are pushing for "think of the children" internet and VPN KYC.
Let me translate this for you:
> - Secure-by-design and secure-by-default must become standard practice – not an aspiration.
This means we will enforce censorship of many many topics, often broadly, even egregiously, and at the whims of whichever policy wig is trying to climb the ladder.
> - Resilience cannot depend on a single solution or technology. Defence in depth remains essential.
This means it will be wide sweeping policy applied to anything tangentially related to "AI" - pushing the compliance burden down onto everybody, luckily a small number of firms will profit massively from this due to regulatory capture.
> - As AI systems evolve, new and previously unknown vulnerabilities will emerge, including zero‑day vulnerabilities.
This means we're realizing that so much software is utter shite, instead of letting people fix it we will bury our heads in the sands and only allow approved government contractors access to models which can fix vulnerabilities (fixing them requires finding them too)
> The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years. We must act before and be prepared to adapt and withstand evolving threats.
This means "We're fucked, and we know it, this will be rushed through parliament and congress, basically the "AI Patriot Act" on steroids as a "temporary measure", to try and keep ahead of the curve.
Amazon Nitro Enclave does pretty much this, the guest has one method of communication, via vsock, and it's up to you to build the pipes on either side.
It's a huge PITA in practice because whatever you want to run inside some enclave usually ends up being a 'normal program' that needs to talk TCP/IP over sockets... so your vsock I/O becomes a weird mix between a TUN proxy or a SOCKS5 local listener inside the VM that tunnels through vsock.
For example, I have the Windows NT 3.50 kernel compiling from scratch with virtio-net drivers, it's fairly straightforward for me to add a bus driver that runs over vsock inside Nitro Enclave that exposes itself (o,o) as a NIC then handle the tunneling logic in a usermode process in the host - but I don't uderstand the point of why you would do that when you already have sufficient attestation methods that don't require you to do vsock isolation.
Yes, you can do this on real metal, EFI is EFI and as such you can make it do essentially whatever you want. For example recently I had to make a stage0[1] HTTP EFI bootloader, it pulls the URL and hash or pubkey from the cloud metadata service, downloads the EFI binary and chainloads it after verification.
On metal you would simply embed the URL and pubkey into the EFI loader binary (or a file on disk), put it into your ESP partition and reboot the machine. Typically the certificate DB of the machine would be reset with a single certificate that signed stage0 then switched into 'Deployed mode' so no new certificates can be added.
This separates the 'provision machine' phase from the 'machine boots and runs your latest release' phase. Although at this point we're booting UKIs so a Linux kernel + uefi stub + initramfs all in a single file.
One of the best flights I've ever taken was Spirit and had 8 passengers on it, 5 of which were transferring staff/pilots. The second worst flight I've ever had the pleasure of enduring was also Spirit - the worst was Easyjet (simply because their seat dimensions are somehow smaller than the average human and generally incompatible with human physiology), and third worst was Ryanair because a mass of orange colored Brits are with near a unlimited supply of duty free gin is... amusing enough to move it up a few notches.
Some people get so precious about code bases and want everything to be 100 line digestable units that working with them is becomes near impossible when they dig their heels in.
It's like dealing an angry grandpa throwing mud over your newly cleaned car, "You gotta start at the wheels lad, not the windows, do it again".
Great, now you've broken the flow, I have to re-do everything, figure out which tests to introduce in which order and unravel them all, ironically this is where I've found more bugs creeping in, because you're no longer diligent - you're appeasing performatively.
The subscription craze is getting worse where often the features I need are locked behind a recurring fee costing hundreds to thousands of dollars over its useful lifetime, or are only available in 'enterprise' versions where the sales people laugh me off for not having $30k to spend and won't even let me trial the software (because inevitably I'll just RE it and make a crack)
The most recent example is I wanted a simple home security system with presence detection and a private control panel, none of the free ones hit my requirements, or require custom hardware, or lock you into a cloud, or assume you can spin-up some containers - or are super enterprise grade stuff.
Within about 2 days I had an android app for my tablet, Google FMDN integration, fingerprinting of my other devices, all controllable via Telegram from any of my phones with alerts that "just work" wherever I am and include an inline gif snapshot.
What I wanted didn't really exist as any individual product, so I absolutely see the appeal of DIY vibe-coded stuff, and a day of the build time was optimizing the OpenGL motion-detection pipeline with shaders & DMA which in itself was good to learn about.
Finally somebody built this, the problem is that the people who don't know won't think of using this tool.
A friend recently came across a project with no RLS and described it as "a once in a lifetime fuckup, a career defining moment, you could shitcan them but they wont learn how to fix it, either way they need adult oversight".
And once you find some dumb low-hanging fruit like that, you usually discover that the vibe-coded ignorance is fractal, especially with TypeScript projects where people assume that you define something in an interface with a given type that the user will always supply that - and your user will always be the app you wrote - and duck-typing doesn't exist.
Maybe worth scanning the various Android app stores? It's incredibly depressing.
Try walking into an small diaspora place during slow hours, paying cash and not being fussy about what you eat, do that 3 days in a row and say "yesterday I was still hungry" (or something to that effect).
The key for me really was eating once a day, I got stuck in a bad routine with the shops and alcohol too.
Whereas now I almost exclusively eat set menus, thalis, nasi kandar etc. at small family run places and ask for extra rice, pickles and veg at little to no cost, and the staff end up getting to know me.
So most days it's "Oh... it's 8pm, I should eat now" and I'm done in half an hour without really thinking about it and somebody else handles the cooking, shopping & cleaning - sometimes I just sit down and look at my phone and food turns up.
As a weird benefit - I don't really drink alcohol any more. The craving and even desire is gone.
---
Re: food noise, it's irrational craving to fill the time, it's sugar, fats, salt. It is an addiction, a little devil on your shoulder going "IM HUNGRY!!! GO TO SHOP AND CONSUME" even when you're not. It's a choice I've had to make to regain more control, and I understand not everybody has the same relationship or brain so may not experience it the same.
Sure, any kind of non-veg protein adds up quickly, especially if you're doing 3 meals a day.
Most local Indian places will do you a solid 1500 calorie meal for £10 if you know what to look for.
Versus, go to supermarket... get stuck in a routine every day of "buying stuff", wanting snacks, meat, and so on adds up quickly to the point where sticking below £10 a day becomes a constant battle. It's the routine and constant food noise that really got to me, and when even a chocolate bar can be 10% of your budget for a day the decision fatigue is real.
So by breaking the routine, sticking to OMAD, I lost weight, had much less decision fatigue, and no constant food noise - that was the major change that saved me a load of money, time & effort.
For example yesterday I found a tiny cantonese place, got wonton soup and some duck, vegetables and watermelon for about £8
Not GLP-1, but moved onto an OMAD diet which is essentially a 23hr daily fast with nothing but neat espresso, cigarettes and water in between - although occasionally I have a small treat or sugary drink.
But now I eat almost exclusively at restaurants and enjoy it, and overall it's cheaper than cooking at home given wastage with many ingredients and desire for variety.
I do eat very simply though, usually south & east asian food.
I've had no end of problems with accountants regardless of their certifications, they operate in a domain with an incoherent body of contradictory and highly subjective rules yet make it out to be a science.
My conclusion as a whole is that accountancy as a profession rarely delivers any actual value to their customers, where much of the job is compliance theater at best.
All the 'Small' language models and the 'TinyML' scene in general tend to bottom out at a million parameters, hence I though 'micro' is more apt at ~150k params.
Yup, Amazon supports the 6.11? kernel on aarch64. Most toolchains if you target linux aarch64 static they, they will produce executables that will run on Amazon Linux aarch64 and Android, set-top boxes with 64-bit chips and Linux 3+ it's surprising how many devices a static aarch64 ELF will run on.
Graviton with Nitro 4 has been quite pleasant to use, with the rust aarch64 musl static target and rust-lld I can build monolith ELFs that work not just on my android via `adb push` and `adb shell` but also on AWS.
AWS with Nitro v3+ iirc supports TPM, meaning I can attest my VM state via an Amazon CA. I know ARM has been working a lot with Rust, and it shows - binfmt with qemu-user mean I often forget which architecture I'm building/running/testing as the binaries seem to work the same everywhere.
Let me translate this for you:
> - Secure-by-design and secure-by-default must become standard practice – not an aspiration.
This means we will enforce censorship of many many topics, often broadly, even egregiously, and at the whims of whichever policy wig is trying to climb the ladder.
> - Resilience cannot depend on a single solution or technology. Defence in depth remains essential.
This means it will be wide sweeping policy applied to anything tangentially related to "AI" - pushing the compliance burden down onto everybody, luckily a small number of firms will profit massively from this due to regulatory capture.
> - As AI systems evolve, new and previously unknown vulnerabilities will emerge, including zero‑day vulnerabilities.
This means we're realizing that so much software is utter shite, instead of letting people fix it we will bury our heads in the sands and only allow approved government contractors access to models which can fix vulnerabilities (fixing them requires finding them too)
> The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years. We must act before and be prepared to adapt and withstand evolving threats.
This means "We're fucked, and we know it, this will be rushed through parliament and congress, basically the "AI Patriot Act" on steroids as a "temporary measure", to try and keep ahead of the curve.