It's worth watching.
chkno
Say more?
NixOS supports headless LUKS, which was an improvement for me in my last distro-hop. The NixOS wiki even has an example of running a TOR Onion service from initrd to accept a LUKS unlock credential.
Nice.
Here's another worked example of a less adventurous pi pico (W) project I did recently. It's C, built with Nix, and doesn't require setting up all the hardware-debugger stuff (it uses the much simpler hold-bootsel-while-plugging-in and copy-the-.uf2-file mechanism to load code). The 5th commit is the simple blink example from the SDK with all the build mechanisms figured out.
Bumping package versions usually isn't hard. Here, I'll do this one out loud here, & maybe you can do it next time you need to:
- Search https://github.com/NixOS/nixpkgs/pulls to see if someone else already has a PR open for a version bump for this package.
- Clone the nixpkgs repo if you haven't already:
git clone https://github.com/NixOS/nixpkgs.git ~/devel/nixpkgs
(orgit pull
if you have). - Create a branch for this bump:
git checkout -b stremio
- Find stremio:
find pkgs -name stremio
- Edit it:
$EDITOR pkgs/applications/video/stremio/default.nix
Looks like nixpkgs has version 4.4.142. If I go to https://www.stremio.com/ (link inmeta.homepage
in this file) and click 'Download', it all says 4.4, which is not helpful. The 'source code' link goes to github, and the 'tags' link there lists versionv4.4.164
, which is what we're looking for. - In my editor, I change the version:
4.4.142
→4.4.164
. - In my editor, I mess up both the hashes: I just add a block of zeros somewhere in the middle:
sha256-OyuTFmEIC8PH4PDzTMn8ibLUAzJoPA/fTILee0xpgQI=
→sha256-OyuTFmEIC80000000000000000000A/fTILee0xpgQI=
. - Leaving my editor, I build the updated package:
nix-build . -A stremio
- It fails, because the hashes are wrong, obviously. But it tells me what hash it got, which I copy/paste back in, in the spirit of collective TOFU. I do this twice, once for each hash.
- It builds successfully. I test the result:
./result/bin/stremio
. Looks like it works enough to prompt me to log in, at least. I don't know what stremio is or have an account, but it's probably fine. - I commit my change:
git commit -a -m 'stremio: 4.4.142 -> 4.4.164'
- I push my commit:
git push github
(If this is your first time, create a fork of nixpkgs in the github web UI &git remote add
a remote for it first) - I create PR in the github web UI: https://github.com/NixOS/nixpkgs/pull/263387
I use Nix (not yet NixOS) on a Librem 5. Debian stable is so old, so it's nice to have Nix as an alternative.
Thanks for the lead!
It looks like the Buddy Read feature does in fact start with a specific book and organize a group around it, but it invites me to specify all the people that will ever be in the group right away, at group creation time. I get three ways to invite people:
- "Machine-learning powered reading buddy recommendations" - Unspecified voodoo. Three users are shown.
- "Community members who have this book on their radar" - Probably folks that have this on their public 'to read' list. Three users are shown.
- Specifying users directly by username
This doesn't quite fit the "I'm up for this, let me know when it starts" mechanic.
I could create a new group & invite all three of the users with this book in their public 'to read' list, but I think folks treat the the 'to read' list very, very casually -- not at the "I'm ready to commit to a reading group" level. These three users have 723, 2749, and 3771 books on their 'to read' lists respectively. I see that I somehow have have 46 books on mine, & haven't been thinking of it as a 'ready to commit to reading group' list.
Thank you for sharing updates about your progress. Good luck rummaging around in found.000. :(
Regulation is slow, full of drama, scales poorly, & can result in a legal thicket that teams of lawyers can navigate better than the individuals it's intended to advocate for. Decriminalizing interoperability is faster & can handle most of the small/simple cases, freeing up our community/legislative resources to focus on the most important regulatory needs.
Yeah, that's normal. That's the seam -- where each layer starts/stops. Yours don't look any worse than mine.
Sometimes you can tweak settings to reduce them a bit, but the only way to avoid them completely is to print in spiral/vase mode (which is very limiting: 1 contiguous perimeter, no infill).
More importantly: You can control where they appear on the part! Your slicer may have settings like 'nearest' , 'random', 'aligned', 'rear', or may have a way to paint on the part in the UI where the seams should be. Seams are clearly visible when they're in the middle of an otherwise-smooth expanse like the side of your boat there, but are barely noticeable if you put them on a corner.
Vanilla JS