purelynonfunctional

The Nix daemon itself still uses root at build/install time for now. NixOS doesn't have any built-in sandboxing for running applications à la Docker, though it does have AppArmor support. But then, NixOS doesn't generally have applications run as root (containerized or otherwise), unlike Docker.

Depends on to whom. If you're explaining to your grandma, a small child, a co-worker, or a student under your tutelage, you probably don't want an explanation that relies on reference to a porn site.

And if you're explaining to a novice developer or to an IT person who sometimes might have to work with Git, they deserve an explanation that leaves them with a basic understanding (or at least the names) of the kinds of things Git and GitHub are (VCSes and SCM forges, respectively), not just an inkling that GitHub is not unique in being 'a place to host (some?) Git, whatever that is'.

So... if you don't mind that it suggests 'GitHub is for uploading Git(s)', that line is an okay way to teach 'the difference between Git and GitHub' to non-technical, non-elderly adults who don't really need to know what Git is (and don't work with you or study under you).

That's an explanation of pretty damn narrow usefulness, to put it generously.

It is pithy and memorable, though.

It's not, though. Git is a means of distributing content, not the content itself. The thing analogous to PornHub's porn on GitHub is the source code in the repos hosted there, not Git itself.

Previously, I've avoided keeping old switches around whenever I've swapped them in my boards. I'm realizing now that this puts me at a disadvantage when it comes to possibilities like this.

What do you use for switch storage to make this manageable?

I'll give the U4Ts a chance, too! They could be a nice fit here. Since I only need the lighter switches in a few keys, the spring swap doesn't even feel like much trouble.

I think we don't want the silents here since the person I'm gifting this to prefers a longer travel distance, and dampeners shorten the throw. Thanks for alerting me to that detail!

Should I look for springs on Amazon or are specialized keyboard shops a better bet for those?

I did order some Box Jades! The person I'm building this keyboard for did like a board I have with Box Whites, which afaik have the same spring. Given their preference for extreme tactility, the Box Jade might be perfect for them as a lighter complement to the Zeal Clickiez. :D

Box Royals have previously felt too mushy for me on a full board, but they might not be bad for extra light pinky keys.

Silent browns will I think not provide any discernable feedback to the typist I'm building this for, hehe.

Truthfully, I've not tried many MX-compatible switches in a full board. Just Box Whites and Box Royals, besides the Box Navies. My daily driver is a Model M.

I haven't tried the U4Ts! They're on my list of candidates. Do you find them to be pretty good as a relatively light switch that still gives good feedback?

I do have some Emogogo Silver Grays which I think might be comparable, but I need only a handful of these switches so I wouldn't mind ordering some U4Ts if they're good.

Spring swapping is a good idea, especially since I don't need a ton here. I wonder how light I can go with the Clickiez before they have return issues... maybe I could lighten those a bit.

The metadata you want is called a Software Bill of Materials, and there are a range of tools for generating them. Some generic ones include Trivy and Grype, but you may also find some for your language ecosystem by Googling ' + SBOM'.

One tool you can use to view these versions with a web UI is OWASP Dependency-Track.

All of the tools mentioned and linked above are F/OSS.

For general Unix skills, get him a laptop and help him install a Linux distro on it. Show him a few different desktop environments, buy him a Linux magazine with a DVD and articles or projects. Then just let him try whatever he wants and promise to be there to help him fix whatever he breaks (by pointing him to docs, belong him write good forum questions, helping him revise search queries, etc.). These skills are perhaps a bit simpler to pick up but can eventually grow into scripting and programming skills.

For programming, start with simple programming exercises or koans, and maybe give him prizes (like a quarter or a piece of candy or something) when he solves them. Let him solve lots of similar problems/puzzles over and over as he builds his confidence; rather than pushing him to harder material, just offer harder material with higher rewards. You'll probably have to write your own exercises at first, like just translating arithmetic expressions from a notation he's learning in school to one used by whatever programming language you're working in together. Eventually, you can start to do online exercises together.

Once he has been messing with this stuff for a year or two, revisit fundamentals by working through a carefully selected introductory textbook together. You can include shell scripts at this point to tie the Unix stuff and programming stuff together, and maybe use a good Linux magazine or Learn Enough Developer Tools to Be Dangerous as the 'textbook' for that side. Then he'll at least know basic version control and surrounding tools.

After you've gone through a chunk of those basics together— full mastery is not required— sign up for an introductory programming class together at the local community college. Taking it together, you can make sure he's keeping up with the material, encourage him to ask questions, and help him with homework if necessary. If you want, you can also do this with networking or systems administration.

This is based on some things that my dad did with me, including a couple of community college classes we took together. (Idr exactly how old I was during those classes, but I think it was before I started high school.)