Well, it's possible to make the deduplication work with Glacier, though. Colin's right that you want to phase versions of the whole tar into slower and cheaper storage, but the technical problem of whether blocks are used in newer versions doesn't actually seem to be too much of a problem. You can compute it in a batch for extant tars, and track it for new ones. (And you can keep blocks-of-references always in S3 rather than Glacier, say.) The problem he identifies as most troublesome is what if you see a case where you would want to deduplicate, but the similar block is in Glacier, and so would be a bottleneck for the whole deduplication process. In this case, you could always treat it as a non-match, right? And optionally have some way to track it and then when it gets moved to Glacier either determine whether it was actually a match all along, or just have some duplicate data.
Of course, I don't know how tarsnap names its blocks or stores them, so I don't know how feasible it is to have two blocks with the same name because they had the same hash but there was a byte-by-byte mismatch, or if that's even a problem.
I mean, blocks that have been moved to Glacier because there are no references to them from indices on S3 can be assumed to be less likely to show up in new archives. It's a trade-off, but my experience with deduplication is that it's often not much of a trade-off to get rid of old things even though the magical thinker in me is tempted to think "but what if that chunk happens to show up again somewhere else!?"
I think that iXsystems' support of PC-BSD is something like an attempt to do that, but it seems like they're not doing much workstation stuff these days, whereas previously they were at least trying to do slightly more. PC-BSD is getting a reasonable open source ecosystem and user experience around it, though, such that someone who can handle the business development and hardware side of things would have a rather easier time than someone starting from stock FreeBSD.
The filename refers to NCFTA, which might seem in context to be http://www.ncfta.net — perhaps some bit of intel that's widely-traded in NCFTA circles for various uses? I mean, hey, pretty useful if you're tracking down pretty much anything in which an Apple device is used, right?
I'm not sure I see how this is in-keeping with any Unix philosophy I've encountered. "Everything's a file" is good, yes, but this program is needlessly-specific when what it does need not be. This is just a tool for browsing a file hierarchy in which the files happen to be GPG encrypted, right?
Which one thing is this doing and doing well? Merely being command-line and somewhat file-oriented does not make Unix orientation. The utility has numerous sub-commands, many of which are simply wrappers for other commands, like find(1) or tree(1). An encrypted file-system or some other way of encrypting the password hierarchy would seem to be exactly all the value this adds over simply using the extant set of Unix command-line tools. Most of this functionality simply duplicates the shell and cat(1).
It doesn't do one thing and well, it seems to do a small number of very general tasks in needlessly-specialized ways requiring arcane and unfamiliar incantations. The password generation stuff makes a fine stand-alone Unix utility. But git integration in the same program?
This is a front-end which brings with it a considerable number of ideas about policy, rather than simply providing a tool. Most of what it does could be handled much more simply by the filesystem and the extant tools it leverages or reimplements.
Lotta facets of unix philosophy.
It manages passwords and it does that well. "pass -c HN/ralphtinner", and then my password is on the clipboard for 45 seconds. That's nice.
From TFA, the password generation is via pwgen.
Encrypted filesystems often require root privs or SUID helpers and don't have straight-forward ways to do key management and key expiration. This tool relies on gpg's already working agent.
Seems strange to have the password generation "on the inside", though. That essentially means that `pwgen` is a strict dependency. Instead of writing something like
pass generate Email/jasondonenfeld.com 15
the user should just type something like
pwgen 15 1 | pass insert Email/jasondonenfeld.com
That way they don't need `pwgen` to install `pass`. It also means that all of the options to `pwgen` can be used without special effort or documentation.
I'd say the same thing about `xclip`, but it's probably not worth having to write something like
Well, since pass is a shell script, and thus has no compilation, you don't need pwgen, and then you can just use "some-generator-program | pass insert blah" as you mentioned. For me, though pass generate Cheese 20 is a lot easier to remember than having to think about the options to pwgen. Pwgen, by default, makes passwords that are easy to remember, and there's some flag you have to hit to make them "truely random". I can't ever remember what this flag is.
With xclip, it's actually a bit more nuanced. You want this to be internal because I have some logic for removing the password from the clipboard after 45 seconds and putting the old clipboard contents back (if nothing else has replaced it in the meanwhile).
That's not very secure. Why not send the password directly to the input manager (as keyboard events or what-have-you), so the password only is seen by the app that needs it, instead of every app the user is running?
Yea that sounds quite nice. Any suggestion on the best way to do this? I suppose there could be browser plugins that call out to pass, but what about a generic system? What would you recommend?
Now that we can see what a results page looks like, it seems like something more than a sorted list of numbers might be interesting. I mean, there's not enough data collected at the start to do something very interesting, but a chart and some statistics would be fairly simple and make it much more digestible. As it is, it's just a numberwall.
Your problem is actually with the organizers. You don't care a bit about random venues except for where organizers of events you are likely to attend decide to use them, I would guess. Therefore, if you have a problem with the venue, you should take it to the organizers, and take it up with them at the time, e.g. by leaving with your student, because wrangling the venue is what they're doing as organizers setting up an event.
Other venues are much more reasonable about this sort of thing. I have a friend who is banned from all Microsoft buildings, including non-Microsoft events hosted by Microsoft. He was informed clearly in writing, and knew the reason for his being banned. That makes Microsoft-operated venues more appealing (on at least this axis) than Yelp ones, since organizers of an event can't be sure that attendees will actually be able to enter. In the Microsoft case, at least a person seemingly knows whether they can attend.
Well, Amazon is making news because we can naively assume by looking at a summary that they're doing it the same way they make money — by working in volume. We can estimate pretty quickly how many people work in Amazon's warehouses, at something in the neighborhood of "an awful lot of people". So it sounds good at a glance. Few people will even notice the details that whittle away the eligible base down to around 0.
If they were giving a paltry reimbursement to everyone who worked in an Amazon warehouse while taking classes, that would add up to something much more significant than the big companies I've worked for that employed people who already felt set-for-life and who could've gotten an advanced degree on the company dime if they felt like it, for example.
Two hours of travel round trip to go to, what, an hour of class? And that's alongside however far one has to drive to work in a day. So maybe you can get away with doing that one day a week? Two? It's going to be a very slow, very miserable slog. Even an hour of travel total, which is probably near the average minimum, is a lot when your days are as packed as Amazon's full-time warehouse employees.
What data do you have that an hour each way is the average? I looked up a few Amazon warehouses. The Irving, TX facility is 6 miles from North Lake College. The Phoenix warehouse is 10 miles from Glendale CC, and the one in Lebanon TN is 20 miles from Volunteer State CC.
I think when you say that you pretty well reduce the vision of programmer culture in the US. How much cypherpunk influence is there in the wide swaths of programming culture that came out of Web 2.0? And how many cypherpunks have gone on to work for the NSA, DARPA, etc.? I'm not sure the landscape is so very different, and certainly one could tease out a cypherpunk influence in Russia that's much more obvious and profound than that in the United States.
There are many programmer cultures, and even cypherpunk culture is very complicated. There are some very different strains of cypherpunk thought, i.e. the divide between those whose primary mode of action as being exposing the scariest actor around and those whose effort is centered in hiding from the scariest actor around.
Of course, I don't know how tarsnap names its blocks or stores them, so I don't know how feasible it is to have two blocks with the same name because they had the same hash but there was a byte-by-byte mismatch, or if that's even a problem.
I mean, blocks that have been moved to Glacier because there are no references to them from indices on S3 can be assumed to be less likely to show up in new archives. It's a trade-off, but my experience with deduplication is that it's often not much of a trade-off to get rid of old things even though the magical thinker in me is tempted to think "but what if that chunk happens to show up again somewhere else!?"