That makes sense on the very surface, but eventually someone's going to lose their config, and all their orphaned storage is just occupied forever in the rest of the group.
I'm pondering an "anti-challenge" primitive, whereby storing nodes can ask the original writer to confirm that it still has the stub file. (Because if that's lost, the data can't be decrypted anyway, there's no point to still saving it.) And if that fails for X months in a row, sorry, time to go. Or maybe raise it for manual review so the node operator can check in with the others before pushing the "reclaim storage" button.
> storing nodes can ask the original writer to confirm
As law enforcement, I would love to know that the existence of encrypted data on your hard drive implies an active, ongoing contact with the online node that bears the key.
An unsung benefit of core memory's non-volatility is that, decades later, forgotten core stacks discovered in storage might still retain whatever data they held when they were powered off.
You just only get one chance to read it.
I'm not aware of any good writeups of such discoveries, though.
Sometimes. Coatings on drums and platters are subject to flaking off and other deterioration, particularly if they weren't stored in completely perfect conditions. Tiny bits of coating cause head crashes which destroy much bigger parts of the surface. Also, over time, the backer for the rust can deform, which also leads to head crashes. Core memories are fragile in their own way (tiny, brittle wires...), but my gut is they're a bit more resilient that iron oxide coating.
Yeah, I saw that via another forum. You should check out his G-15 restore; it's epic. That LGP-21 looks almost pristine, and based on the back story, they guy who originally had it sounds like the kind of guy who knows how to store vintage kit. That thing didn't come out of a barn someplace, so not surprising the coatings survived. :-)
There are many operating models. Some are attached to another organization (a library, a university), some are commercial (RIP Techshop), some are completely DIY and member-run. Any given city might have a handful of different ones, but you'll have to dig around and visit a few to see what you vibe with.
Caveat, it's very easy to get focused on the ooh-shiny tools, and forget to pay attention to the community energy and expectations. Some of the more professional spaces, you just pay for what you want, and staff takes care of the rest. At the other end of the scale, the fully-DIY places are very much a case of "you get out of it what you put into it", and may offer cheaper memberships but expect a lot more involvement.
> forget to pay attention to the community energy and expectations
My problem is that I just...don't care about the community that much, and ended up just buying the tools I needed/outsourcing as needed. Though travel time/cost made it really uncompetitive (I don't drive, and neither of the large makerspaces in my city bothered to take transit accessibility into account...sigh). Even if I did drive, to me the commute time is just time better spent actually working on project du jour. All of that, plus the rise of sites like JLC(PCB|3DP) and sendcutsend where I can just get the part I want without any hassle really killed the value proposition for me.
I still like the idea of makerspaces, but it feels to me that the community has become the product. Which is all well and good, but if you don't particularly value that part, cheap tools + online fabrication services are already a tough comparison, and that's before burning a couple of hours on transit, before I've even touched a tool, well, the practical case completely falls apart for me.
Exactly. The sane ones just ask you what year it is at startup, and use that to determine the initial epoch. Then they handle rollover automatically since then.
It's been widely opined that 1024 weeks (~20 years) is the worst possible interval. Either rollovers should've happened VERY frequently (say, 128 weeks) so receivers would be FORCED to deal with it, or extremely infrequently (16384 weeks?), so it's simply never an issue.
The unhappy medium is long enough that developers feel justified in saying "naaaah, our receiver won't still be in use then, we can ignore that!", but in practice it's very likely to happen.
That makes sense on the very surface, but eventually someone's going to lose their config, and all their orphaned storage is just occupied forever in the rest of the group.
I'm pondering an "anti-challenge" primitive, whereby storing nodes can ask the original writer to confirm that it still has the stub file. (Because if that's lost, the data can't be decrypted anyway, there's no point to still saving it.) And if that fails for X months in a row, sorry, time to go. Or maybe raise it for manual review so the node operator can check in with the others before pushing the "reclaim storage" button.
reply