Cloudef

I disagree. Webgpu is completely useleless middleware that is already outdated, and it bugs me it killed compute shaders for WebGL proposal. In addition webgpu still does not work on browsers out of box.

Interacting with webgpu from wasm is also often slower than webgl because the api is lower level and causes more gc overhead on js side.

I think it's because of the webgl demo at top stealing focus

They are, but nobodys making kids

Relying on cloud services is a big liability. I'd think twice before feeding data to these LLM cloud products. If you make them a fundamental part of your product / development / workflow, be ready for the eventual moment the pricing and terms change.

Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).

On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.

Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor.

> Unfortunately implementing an Apple style architecture on Linux would be very difficult.

The apple apps kind of thing already exists and its called flatpak.

I chuckled, but isnt godzilla product of the nuclear aftermatch?

The way simd speeds up "compute" is indeed mainly the reason that you operate on multiple pieces of data at once.

Apple does not allow running code from internet either (even if interpreted iirc)

That said shipping JIT / interpreter with your program to recompile updates / parts of it sounds silly to me.

Try reading zig code. For me its much more readable than the other languages, and does not suffer the fact go doesnt have language level errors. Local allocators are very useful and if you dont think so, perhaps you havent dwelved too deeply into systems programming or the language isnt targeted for you.

> Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.

By trusting another chain of trust and firmware binary blobs involved in booting your PC.

Secure boot exists only as one of the puzzle pieces for remote attestation for MS and trusted OEMs, nothing to do with your security.

Symbian was really awful OS. Nokia's mistake was ignoring Maemo.

Rust unsafe is less safe than writing C code. Rust is not good language for writing "unsafe code". C++ smart pointers are really bad compared to arena allocators, and not allocating at all. It's very easy to end up with dangling references in C++, or double frees with smart pointers. Also the fact that C++ initialization itself is a huge foot gun.