Adam Williamson is a Linux distribution developer who writes about UEFI boot, packaging, and security details of the Linux desktop.
HN recommends his UEFI boot article as the go-to explanation of how UEFI works, and links his posts on Snappy and Flatpak.
That's sort of my point. I'm also an old fogey in Linux hipster-land, who started off with RH5, then moved to Mandrake, then Gentoo somewhere around the kernel 2.2->2.4 transition.
It was really important then to know how to identify hardware so you could actually have it supported in your kernel (I don't remember if `genkernel` didn't exist yet or whether I was just trying to squeeze out as much performance as I could -- probably the latter). But it was also the era of winmodems, winprinters, risk of actual damage to your monitor if you screwed up the modes in X11R5/6.conf, we had to use `lilo` and remember to update it every time, etc, etc.
A lot of the people I talk to know who end up in the same positions as me still use those skills -- but we use them at distro vendors to make sure that 'normal' users never need to worry about it. Honestly, with the way Linux has been adopted, my expectation would be that by the time I exit the industry, people with the skillsets you and I have will be rare, and mostly unnecessary. Linux "just works" on the vast majority of hardware these days, and we old fogeys put a lot of blood, sweat, and tears into making that so.
It's not that I think that it's useless, it's that it's not _required_ knowledge anymore, and anyone who is convincing themselves that it's giving them deeper knowledge considering the vast increase in complexity is kidding themselves. In a pre-EFI world where all you needed was a binary (any binary) located at `/init`…
Snap is horrible.
The software required for running a Snap Store instance is proprietary [0], and there are no free software implementations as far as I know. Also, the default client code hardcodes [1] Canonical snap store, so you have to patch and maintain your own version of snapd if you want to self-host.
Snapd also hardcodes auto-updates that are also impossible to turn off without patching and maintaining your own version of snapd / blocking the outgoing connections to Canonical servers, so snapd is also horrible for server environments. To top that, the developers have this "I know what's good for you, you don't" attitude [2] that so much reminds me of You Know Who.
[0] https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/
[1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
[2] https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707
In theory, I agree. In practice, there doesn't seem to be any other snap store out there?
This is a years old quote from [0], but it doesn't feel like anything changed since.
> If you want to distribute your snaps, your choices are 1) publish it through the Canonical store, entirely under Canonical's control, 2) upload it as a file and tell people to use the CLI to install it, or 3) try to figure out how to reconfigure the snap client to use a different server by reading the source code, then write your own server end from scratch, and tell your users to do that.
[0] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/
such an interesting thread, thanks for bringing this up!
At Packet, we've been working to support CoreOS and their Distributed Trusted Computing (https://tectonic.com/trusted-computing/) for our on-demand bare metal product. This relies on UEFI vs traditional BIOS. Reading up on this I've certainly learned a ton! A good background article I read was https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
Alternate source, though may be dated to around the time of v2.2 of the UEFI spec.
https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/
I find it funny that almost all the real gripes with user freedom infringement actually tend to come as a result of Microsoft or other big players getting their fingers into a hardware platform.
Completely understood by me, hopefully I said this in a way that was productive. :) Per-app passwords have their use cases and I think techs have been banging on it in open source for awhile, example: https://www.happyassassin.net/posts/2014/08/26/adding-application-specific-passwords-to-dovecot-when-using-system-user-accounts/