After what the USAians achieved with a net positive output, hopefully they can match and surpass that. Fusion is one of the few technologies that can get us to 1 on Kardashev scale.
Not a surprise for those with containerised workloads. Mac is a nightmare for that. Every single dev team with mac that I've been on has struggled with it. Heard all these things and more:
We can't use Docker Desktop due to licensing!
podman doesn't work, but colima does
npm install takes forever!
Why can't it find the docker socket?
This only works on x86
The port-forwarding didn't work
XYZ works in the dev-container but not when deployed
Recreating a problem you encountered with your container in a x86 linux VM in the cloud on a mac with apple silicon is no fun either.
And good luck with custom hardware on a mac. Working from home with stuff that was plug and play on linux simply refused to work on mac. Ergonomic mice, keyboards, USB-C docks, high-quality webcams, USB headsets... Either you're in the Apple ecosystem or you're gonna have a bad time.
If an employer doesn't allow me to install linux on my dev machine, then I move on.
You can forward the VNC port with a local port forward e.g ssh -L $yourPort:localhost:$vncPort $grandmasMachine. Then open Remmina (or KRDC, or some other VNC client).
I do hope your grandma has good upload speeds though.
Bless you for spreading the word of the penguin and being the support of your family. Props to you.
Still makes you bound to github. Can't publish to crates.io without github.
just leaning on the security guarantees of github
What security guarantee does github have? I can create a new account right now with a random email, sign up for crates.io and type-squat a package.
If you want, you can use git links when declaring dependencies in Cargo.toml. So alternative to crates.io is basically any git host already!
Sure, but how do you discover the package? That's the other function of a registry. Also, I could easily just add another package as a submodule, but that's not the point.
That's easier said than done. I find that there's no clear vision of what "idiomatic" Rust is. With functional programming, it feels like there's a strong theoretical basis of how to structure and write code: pure functions everywhere, anything unpure (file access, network access, input conversion, parsing, etc.) goes into a monad. TBF, the only functional code I write is in JS or nix and nix-lang is... not really made for programming, nor is there any clear idea of what "good" nix code looks like.
Rust however... are Arc, Box, Rc, async, etc. fine? match or if/else? How should errors be handled? Are macros OK? Yes, the clippy linter exists, but it can't/won't answer those questions for you. Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> ... | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper). I haven't found good examples of solutions or guidance on these things.
My rust code still feel kludgy, yet safe after a year of using it.
flake? The experimental feature that hasn't been stabilised for multiple years, isn't officially part of the main package repository (nixpkgs), requires external tutorials and documentation because it doesn't have an official tutorial and the most official documentation on it is in a man page about nix flakes, and has split the community in flakes vs no flakes, is better than a well documented (from the beginning mind you) file which is used throughout most of the industry?
Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you're using a hammer on everything.
There is no silver bullet in life and most undeniably not in programming.
Also, electron has a reason for existing. If it didn't have a use, it wouldn't have the number of users it has. You can't tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.
It's just another instance