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.
Yea, rain cape / poncho / "boncho" is the way to go! Combine with fenders & giant mudflaps. So fast to get on & off, & the only way to keep dry and cool at the same time.
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.
I have a specific book I've been meaning to read for awhile. I've heard that while it's a great journey, it's a dense / heavy / slow read along the way. It sounds like it'd be fun to read it together with a group of likewise interested folks.
Is there a service for pulling together reading groups around specific books, rather than the more common way of gathering a group of people and then selecting books? I'm imagining a website that has a sign-up page for ~every book and when ~10 people sign up for a book they all get an email introducing them to each other. Like if there was a bus stop for every book & when enough people had gathered, a bus appears & they depart together.
Given list of all the books, this seems like a pretty easy thing to make. Does it exist yet?
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.
X11 for xdotool. ydotool doesn't support (& can't really support with it's current architecture) retrieving information like the current mouse location, current window, window dimensions & titles. Also, normal (unprivileged) user ydotool use requires udev rules or session scripts and/or running a ydotool daemon & many distros don't yet ship with this Just Working.
X11 for Alt-F2 r to restart Gnome Shell without ending the whole session. This is a useful workaround for a variety of Gnome bugs.
Gmail prompt to provide phone number sounds like a threat
When it's hot during the day and cold at night, I sometimes find myself under-dressed for late evening riding. I can pedal harder to generate body heat, but on flat ground that creates wind chill & doesn't help. Pedaling hard while lightly holding the brakes works really well to warm up!
But the downhill-biking folks warn about the hazards of overheating brakes (mostly disc brakes but also rim brakes / V-brakes). I have V-brakes.
I imagine just pedaling into brakes transfers heat into them much slowly than controlling downhill descents, since I can go down hills much faster than I can go up hills (it takes much longer to transfer one hill's worth of energy from my muscles into having climbed the hill than to transfer the same one hill's worth of energy into the brakes/rims while descending it).
Do I need to worry about this at all?
There are so many ways do handle backups, so many tools, etc. You'll find something that works for you.
In the spirit of sharing a neat tool that works well for me, addressing many of the concerns you raised, in case it might work for you too: Maybe check out git annex. Especially if you already know git, and maybe even if you don't yet.
I have one huge git repository that in spirit holds all my stuff. All my storage devices have a check-out of this git repo. So all my storage devices know about all my files, but only contain some of them (files not present show up as dangling symlinks). git annex tracks which drives have which data and enforces policies like "all data must live on at least two drives" and "this more-important data must live on at least three drives" by refusing to delete copies unless it can verify that enough other copies exist elsewhere.
- I can always see everything I'm tracking -- the filenames and directory structure for everything are on every drive.
- I don't have to keep track of where things live. When I want to find something, I can just ask which drives it's on.
- (I also have one machine with a bunch of drives in it which I union-mount together, then NFS mount from other machines, as a way to care even less where individual files live)
- Running
git annex fsckon a drive will verify that- All the content that's supposed to live on that drive is in fact present and has the correct sha256 checksum, and
- All policies are satisfied -- all files have enough copies.
Sounds fine?
Yes: Treat the two enclosures independently and symmetrically, such that you can fully restore from either one (the only difference would be that the one in the safe is slightly stale) and the ongoing upkeep is just:
- Think: "Oh, it's been awhile since I did a swap" (or use a calendar or something)
- Unplug the drive at the computer.
- Cary it to the safe.
- Open the safe.
- Take the drive in the safe out.
- Put the other drive in the safe.
- Close the safe.
- Cary the other drive to the computer.
- Plug it in.
- (Maybe: authenticate for the drive encryption if you use normal full-disk encryption & don't cache the credential)
If I assume a normal incremental backup setup, both enclosures would have a full backup and a pile of incremental backups. For example, if swapped every three days:
Enclosure A Enclosure B
----------------- ---------------
a-full-2023-07-01
a-incr-2023-07-02
a-incr-2023-07-03
b-full-2023-07-04
b-incr-2023-07-05
b-incr-2023-07-06
a-incr-2023-07-07
a-incr-2023-07-08
a-incr-2023-07-09
b-incr-2023-07-10
b-incr-2023-07-11
b-incr-2023-07-12
a-incr-2023-07-13
....
The thing taking the backups need not even detect or care which enclosure is plugged in -- it just uses the last incremental on that enclosure to determine what's changed & needs to be included in the next incremental.
Nothing need care about the number or identity of enclosures: You could add a third if, for example, you found an offsite location you trust. Or when one of them eventually fails, you'd just start using a new one & everything would Just Work. Or, if you want to discard history (eg: to get back the storage space used by deleted files), you could just wipe one of them & let it automatically make a new full backup.
Are you asking for help with software? This could be as simple as dar and a shell script.
My personal preference is to tell the enclosure to not try any fancy RAID stuff & just present all the drives directly to the host, and then let the host do the RAID stuff (with lvm or zfs or whatever), but I understand opinions differ. I like knowing I can always use any other enclosure or just plug the drives in directly if/when the enclosure dies.
I notice you didn't mention encryption, maybe because that's obvious these days? There's an interesting choice here, though: You can do normal full-disk encryption, or you could encrypt the archives individually. Dar actually has an interesting feature here I haven't seen in any other backup tool: If you keep a small --aux file with the metadata needed for determining what will need to go in the next incremental, dar can encrypt the backup archives asymmetrically to a GPG key. This allows you to separate the capability of writing backups and the capability of reading backups. This is neat, but mostly unimportant because the backup is mostly just a copy of what's on the host. It comes into play only when accessing historical files that have been deleted on the host but are still recoverable from point-in-time restore from the incremental archives -- this becomes possible only with the private key, which is not used or needed by any of the backup automation, and so is not kept on the host. (You could also, of course, do both full-disk encryption and per-archive encryption if you want the neat separate-credential for deleted files trick and also don't want to leak metadata about when backups happen and how large the incremental archives are / how much changed.) (If you don't full-disk-encrypt the enclosure & rely only on the per-archive encryption, you'd want to keep the small --aux files on the host, not on the enclosure. The automation would need to keep one --aux file per enclosure, & for this narrow case, it would need to identify the enclosures to make sure it uses that enclosure's --aux file when generating the incremental archive.)
Check out Winston Moy's video on making a topographic map of Colorado. They mention these data sources:
- The one you already found
- The U.S. Geological Survey (USGS)
- Terrain2STL, which uses Consultative Group for International Agricultural Research - Consortium for Spatial Information (CGIAR-CSI) data
OpenSCAD's surface primitive can turn height maps into STL files.
You may have to trim the state boundaries yourself. :(
Any sane compiler will simplify this into
function cosmicRayDetector() {
while(true) {
}
}
C++ may further 'simplify' this into
function cosmicRayDetector() {
return
}