whizzter

I think part of the entire design is that it's quite hard to detect.

1: Reads/Writes are just routed to a COTS SD-card. 2: Unless the (correct?) password is detected in the write-data that starts the disconnect procedure.

The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay, only works if the CPU cost is large enough to overtake the SD-card measurably and some constant-time optimizations should make it more or less undetectable.

It's a clever design and I think it should be possible to optimize to become more or less unrecognizable.

Ah sorry for being coy, the G was meant to be a shorthand for gyr or am I misremembering?

Can't remember the exact featureset of the popular D one (because boy, was there many languages called D and E and so on over the years in the 80s/90s), I'd say to be a car it needs both temporal and bounds safety at the least but faintly I remember D being a bit of a kitchen sink? Wasn't there 2 standard libraries for a while? Were they even coherent in style/used language features?

You went by that g nickname back then right? Remedy 2003 in that cramped student apartment.

Ice skates with a rocket engine on your back?

For those that weren't around (or didn't do programming back in those days).

The GUS soundcard just filled a niche perfectly at point in time with a reasonable pricepoint.

It came out at the same time as the Sound Blaster 16, but while the SB16 required "expensive" software mixing for anything but prerecorded audio the GUS handled that in hardware meaning that users either traded for CPU performance or audio quality in games.

In the 486 era it was really a differentiator and also caught on in the demoscene, by the time Pentium processors rolled in the software mixing cost became far less pronounced.

Finally when Windows became the go-to for games (and CPU's got even faster, esp when MMX processors came into play) the API's made cheap hardware equally good since most developers just targetted the plain streaming API's (with software mixing) for broader compatibility.

The final holdout for GUS cards afaik was the demoscene, since the card had a built in mixer with frequency control it could play modules (.MOD, .XM,etc) with simple players that just uploaded the samples to ram and then just changed registers realtime (kinda like an Amiga but more powerful) instead of including a mixer, in the end however it was more about code-size than cpu performance, doing a 64kb intro you could shave off something like 3-10kb's compared to supporting a SoundBlaster card (depending on other tools) and those extra KB's was well suited for effects/art.

In the end though, people realized that the dosextender+GUS combo was as heavy in terms of code as just a mixer on Windows (since you didn't need a dosextender) and when better compressors arrived for Windows even the demoscene moved on.

It's the old craftsmen vs industry issue, Andrew comes from the craftsman tradition that prefers all other people developing to also be proud craftsmen.

What Java, JS, Python and C# all did to conquer the industry from a C++ dominance was to provide safety harnesses for less "perfectionist" workers to fumble around without causing a mess, to write C and C++ in an increasingly hostile world we realized you needed a lot of craftsmanship, the performance benefits outdid and kept the latter languages relevant for a long while.

Still, the performance/predictability penalty didn't give way so Rust (and Swift) came into play. They don't have as many unpredictable performance characteristics as the previously "safe" GC languages but still provided more or less the same guarantees (in some ways perhaps even better for Rust).

The brilliance of the Rust ideas did start a bit of a cambrian explosion of languages in that niche, most of them however targeting a bit more of a craftsman position than Rust (that came out of distinct industry needs).

The problem as the article illustrates, in car terms.

If Java,JS,etc are mostly "regular safe cars" and C/C++ a two wheel motorcycle.

Rust is perhaps a rally car (fast but still a car so occupants inside are well protected) whilst Zig really is a quadbike or open wheel cart, not as unsafe as a two wheel bike since you won't slide for the smallest oil/ice patch but flipping over is still dangerous as hell.

And that takes us to the crux, so many developers who love the craft and perfection (and don't live under- or perhaps care of- financial constraints) think that "good careful" developers is all that's needed and don't see dangerous language designs as a problem.

I'm an older developer, and given that I can write "good careful code", but 90% of the time it's also a matter of time and financial constraints so I wouldn't trust mine (or anyone elses for that matter) code written under those "industry" conditions.

I think Zig has a lot of nice perks, but it was obvious from day 1 that it's very much for people that love their hacking freedom over writing code for todays hostile world.

I think that's the issue in some cases though, while being totally absent is a major negative, the perception the kid has of the parent _while_ present is more improtant than when being absent if the absence is understandable, a kid in daycare will observe other parents leaving and picking up and normalize it.

RenderWare was quite a special case that made trust in third party engines go down significantly since EA closed it to external customers just as the PS3 hit (Renderware kind-of saved the PS2 since it was "complicated" in the same ways as the PS3 but having a middleware enabled many smaller developers to focus on their games).

Engines has been (And is to a large extent) bad business because unless you really do something _really special_ it's way expensive for little gains (especially if you're targeting realistic games since there is so much to focus on before even considering portability).

And I say this as someone who started out working on custom engines (but am out of the business outside of hobby stuff).

The pandemic and scalpers really destroyed peoples apetite for the "new thing" when this generation came out, and with that boost missing studios saw little point in going exclusive perpetuating the vicious cycle, it's just in the past few years that there's really been exclusives for this generation that didn't also support older consoles.

And even then, already the PS4/XbOne generation added stratification making it more "PC-like" with the XbOne-X having heftier hardware (not to mention it being PC-like compared to PS1/PS2/PS3/Xbox360), that then continued with the Xbox-series-X and Xbox-series-S.

Consoles aren't specialized hardware for "magic experiences" and everyone knows this, it's just another "device" that happens to be connected to a TV with a controller where people are gatekeeping software availability.

You mean in the sense that async methods return "awaitable" (Value)Task objects that contains the actual activation machinery that can be queried for liveness status?

It's funny that they're actually revamping the entire machinery for .NET 11 to defer allocations by default for non-waiting codepaths (Not sure, but iirc that machinery might require JIT compilation so would've perhaps not been possible to use for C++).

Iirc often the frameworks don't have worker affinity, anyhow environments like .NET has "AsyncLocal" to provide an aware alternative.

You're thinking of older early coroutines or in singlethreaded runtimes (JS).

It's M:N threading, most logical threads/tasks are more lightweight than full OS threads, the logical ones should preferably behave cooperatively but they can be scheduled onto any number of real worker threads (usually these systems picks something like 2x worker threads compared to real CPU/Core count to manage some codepaths not being as well behaved).

Erlang and .NET(with Task/async) uses this model, iirc modern Java does this also (but hides it) and I'd be surprised if the modern async Rust or C++ variations didn't do this as well.

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).

The main benefit is not having the cost of threads, f.ex. a default thread on Windows has something like 500k of stack iirc, scale that to 10000 concurrent requests and you're looking at 5gb of memory _just for stacks_, compared to a couroutine,etc that has perhaps a few kb's of usage (even if in deep stack-traces).

This is why we have stuff like io_uring these days, the bottleneck moved to the kernel calls (especially with Spectre style attacks) when concurrent costs in the applications went down.

The United States might be 85 times larger than Switzerland but it still has a higher population density than Sweden, and even in rural Sweden (similar population density to Wyoming) where my father lives he has a similar ability to pick providers at will as the Swiss.

Again, it's all still tied to that one device, the phone, if it's hacked it's really game over and with a big enough hole in the Android or iOS ecosystem that could be wormable a lot of people could be exploited en-masse.

Sure a 24h delay or SMS code are 2 way but they fully fall into the bandaid category.

In the past we used to have disconnected dongles for banking, the bank issued a one-time challange and you entered the response along with your username. Now there are disadvantages with those also but at least it was fully airgapped.

Well that is the point of this entire digital wallet thingy, there's going to be a transition period since everything here is more or less hardcoded to bankid not to mention tons of code with presumptions about Swedish identity semantics (that do differ from other countries).

But on the plus-side the Swedish state-eID solutions is planned to be delivered by end of year and hopefully most organizations will start migrating or at least dual-supporting them and in doing so also fix their services to support foreign eID's in the process.

Iirc he was kind-of funded by AMD for a while to break the CUDA LLM moat (the mention of change of direction at the bottom of the article), no idea if it was legal issues with him being paid by them or why it changed, but..

1: Much initial research and early OSS was CUDA focused due to libaries and momentum, but with more Mac users,etc kernels/frameworks are more portable so with stuff like Unsloth so the CUDA moat is falling there (If it's Vulkan or more propietary backends doesn't matter, Vulkan or OpenCL are probably fairly equal in usefulness since Vulkan support would probably require custom extensions for full performance).

2: As alluded above, ZLuda seems to have focused a bit on ROCm API's for AMD (I think I've seen mentions of other library supports but it's been up and down iirc since he was employed by AMD). The main benefit compared to Vulkan iirc is that ROCm allows for some CUDA-like feature that makes kernel emulation so much less troublesome (or even feasible at all?).

Honestly, as long as the architectures is fatally flawed (Even if convenient) it's just bandaids over a larger issue.

These mobile id's are too powerful, signing contracts, transfering all your funds or taking loans, regulation is also papering it over a bit by requiring high-stakes lenders,etc to do additional checks.

Germany was going in the right direction imho, they NFC enabled their ID cards (Sweden has info on them but no enablement procedures) that is then paired with the app, so the card acts as a 2nd factor that makes the app itself less of a security issue since a user will be required to physically enable it (sadly the NFC pairings are kinda fiddly.. but I'd take that as a security option for all non-trivial transfers).

I'm not entirely disagreeing, right now however there is so much fraud that when it intersects with things of interest causes millions(billions?) to be spent on chasing the wrong leads (see findings on that 2006 Amyloid Plaque paper regarding Alzheimers research).

I'm mostly saying that being reproducible should become a higher badge of quality, right now reviewers in cartels can boost a researchers credibility by accepting each others articles to papers to let them become "influential" and money is then redirected even more to bullshit research (ie pure waste).

If up to 50% of research grants is spent on bullshit research based on fraud, spending 10% by earmarking it for reproduction to weed out irreproducible fraud is money well spent.

I think I was more referring to academia than commercial research even if there is a large intersection.

I wouldn't say so, more that lawyers and capitalistic interests goes before scientific advancements, that doesn't preclude independant (or guided) re-discovery and eventual replication of findings.

Researcher/academics pay/promotoins should be contingent on reviewing,challenging and reproducing papers rather than publishing quantity, because publishing cartels and AI has already degraded most research fields.

Whoa, Antrophic,etc are really running afraid that their IPO's are gonna crash when people realize that the open models are Good Enough(TM).

So I'd put it at 30% that this is a ruse, say that Qwen 3.5,etc is tainted by training by them and start issuing DMCA takedowns to protect the IPO valuation (Or they'll hold off on that, getting a DMCA takedown could backfire spectacularly if others do that to them).

We would end up with some other (probably worse) JS frameworks instead, JQuery(shudder) was still big, Angular 1 was a glimpse of something but they went for Angular 2+ that changed everything, backbone js, ember js,etc.

Vue is probably the only outsider of that age that stayed even somewhat relevant (really by just doing what Angular 1 did but correctly), Angular seems to have kinda survived in some niches but other than that I haven't heard of the other similarly aged frameworks in a long while.

Right, but bad UI's was not uncommon before webviews, if anything the spartan-ness of the web often simpified patterns whilst reliance on weird hotkeys in desktop apps isn't uncommon.

This is a library in similar vein to "Dear imgui", minimal requirements for integration (rectangle and text rendering) so that it's easy to embed into game-engines,etc for debug UI's and similar things.

And that's the unserious part, they really don't want anything to do with consumers despite making consumer products (gmail, Android, etc.) so you're always at the mercy of their automatic systems.

It's in the first paragraph of the article:

"Strikingly, this concern is being openly voiced by the very people who have the strongest incentives to project confidence rather than alarm: the founders of the largest AI laboratories."

It's amazing how a writer can write something like that and not even question the premise of someone with the "strongest incentive" to be "critical" as not being a marketing ploy.

1: Something like Figma could probably offload some of the memory pressure to GPU textures. (But they'd probably run into safety browser limits before that).

2: Most runtimes are 64bit already, A runtime detecting a wasm32 binary will just continue to generate code with the current JIT compiler whilst WASM64 will require another JIT (and perhaps memory system since WASM32 runtimes are often based on "hacks" where 4gb of address space is reserved but not given real memory so that the JIT compiler gets an easier job without security implications).