AI is the complete opposite. It takes away the thinking part. When people use AI, they tend to offload a lot of thinking part to it as well. I use it because company policy. But if you care about every single if case and every single variable name, writing by hand is faster unlike CAD.

When you have limited time to learn as a student, you either have the smarts to learn in the limited time or you cheat.

With a capability-based microkernel you get to assign ownership and resources to a very granular level that increases robustness against crashes and protection against attacks to the core system policy. A unikernel can give all of that but I feel like then it will be worse to program against rather than a microkernel.

So overall I don't see any advantage of unikernels. They don't help you write more correct programs IMO and the performance gains are limited.

We tested this in the office with equal laptops. CPU workloads have almost no VM overhead and the C++ / Rust compilation workloads on purely WSL2 virtual disk image is only 2% slower.

Yes WSL1 was more ambitious but the fundamental differences in the NT and POSIX makes it quite hard and CPU workloads suffered.

Soon images taken without this signature will be unpresentable to the court.

If your GPU is older than 5 years, then you're in danger zone and you should have completely replaced your hardware 3 years ago and bought new Nvidia equipment now 10x more expensive!

I say this as a person who strongly dislikes many many aspects of Unix and Linux due to bad design and terrible UX. Git has a better design than any Unix program you get.

Submodules work okay. It is just Git LFS but for Git repos. Get over it.

And once you go into FFI for interpreted or JIT compiled languages it turns into hell. Both Python and Java creates huge headaches when you have multiple versions of the same libraries in various /usr subdirs.

I often helped lab students who read a simple `make; make install` tutorial for OpenCV and permanently messed up their Python installs.

Windows (10 LTSC or 11 with dTPM) actually works better for old Nvidia systems with WSL. You even get CUDA libraries within WSL and security updates for the next 5 years.

The origins of Chromium come from KHTML which was designed to be embeddable and quite modular. Both Webkit and Blink forks retained that feature and improved it.

Chromium has V8 which is the faster JS engine (so it accommodates crappy bloated webpages better). It achieved HW acceleration early on, it is quite important for video decode. Many webdevs only optimize for Chrome for viewing.

> After spending years doing those FFI dances in both directions, I’ve reached the conclusion that the only good boundary with Go is a network boundary.

It looks like this extends into the package manager too. The only good boundary with Go programs is a socket. The only good boundary with the Go package manager (? if we can say it is one) is a domain and a DNS server (your own or somebody else's in the case of gopkg.in).

[^1]: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-k...

If your goal is "delivering applications to only well-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features (with a lot of bugs and horrible API because Qt).

The only foolproof way of having truly professional software is still the same: have N different, very-well integrated UI implementations (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron.

With Rust you can use Win32 or WinUI3. Both are provided by Microsoft-developed crate windows-rs.