HN user
https://stuartpb.com/
[ my public key: https://keybase.io/stuartpb; my proof: https://keybase.io/stuartpb/sigs/5uPpTu8U1RHc0QOZSnGyFYL4q8ol8keXdCdulvMGSus ]
This looks excellent - I outlined wanting something like a cross between Lua and Bash back in 2016, and at first glance, it would seem that this project by and large fits the bill: https://github.com/stuartpb/lash
Recent versions of Lua use this trick as well.
I tried to prototype my own implementation of `vidir` in Node.JS a while back (not realizing that it existed under this name in moreutils), and I ended up getting derailed after realizing how incomplete Node.JS's support was for getting the group / username corresponding to a G/UID: https://github.com/stuartpb/whomst
This is what the Cluetrain Manifesto was saying... in 1999.
That's what `vipe` is for: https://joeyh.name/code/moreutils/
No. See http://www.cluetrain.com/ - paid advertising is inherently unethical on a network where genuine mass interaction is free.
Other than DNA sequences I can't think of a good person key.
In theory, one could use 3D geoposition at time of birth, time of birth, and sibling order (for twins / triplets / etc delivered surgically), where said order is dictated by the parent(s) or ob/gyn present. Of course, the main problem with this in practice is that not everybody has this information.
I would have said you could do something via retinal imagery, but not everybody has eyes. If we had non-invasive neural imagery, would it maybe be possible to derive a key from a simplification of a person's physical brain topology?
But pretty much no one thought CMOS features could be made arbitrarily small.
Pretty much no one qualified, maybe. There are lots of laymen (including many True Believers in The Singularity) who operate under the impression that it's a fixed law of nature.
While I first wrote an article about the absurdities of information security [in 2011][1], this specific extension is an idea I've had since [June 2015][2] - due to the absurd nature of the idea, I wanted to launch it on April Fools' Day, but that ended up causing it to be [dismissed as a joke out of hand altogether][3], so I figured I'd wait a day before posting it to Hacker News.
While the premise of the extension sounds like a joke, it's legitimately a good idea, and [one others have had independent of this][4]. I explain some of the thoughts and motivations behind NilPass's design here: https://nilpass.com/seriously/
[1] http://www.cracked.com/article_18962_5-things-we-all-do-that...
[2] https://github.com/nilpass/nilpass-branding/commit/6090b5cc9...
[3] https://www.reddit.com/r/netsec/comments/62sgrp/presenting_n...
I spent all of yesterday making an extension for this, and now HN won't let me post it as an article: https://nilpass.com/
Though, of course, this still means trusting the compiler: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
I made a similar app to this for Pebble at a hackathon in 2015: https://github.com/phoneyscape
We got an offer from Madrona Ventures for it that I never ended up following up on.
He seems to have changed his tune now that he can't behind the "that's only an imaginary possibility" cover: http://marc.info/?l=git&m=148787047422954
Do we want to migrate to another hash? Yes.
Holy crap, really? I've been drawing up [profiles for the user account systems of a bunch of websites for the past few years][1], and I think I've only seen that once before (on a Washington State website, no less).
Precisely - calling it an "encoding" here is more of a tongue-in-cheek nod to how simple the steganographic rule is than an intention to imply that it be used as a straightforward representation.
Also, "steganography" tends to imply that the intent is to hide the underlying message, and that's not necessarily the case here, such as when employing alphabi for mnemonic purposes ("Baywatch hologram lemonade asteroid" being easier to remember than "52.84.24.108").
Furthermore, the purpose of the "encoding" being so flexible (and, consequently, low-density) is that it can be used, then, as a medium of expression - it's not that the "message" is hidden, it's that, well, [the medium is the message][], and per Article 19 of the Universal Declaration of Human Rights linked there (emphasis mine):
Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
[the medium is the message]: https://en.wikipedia.org/wiki/The_medium_is_the_message
So, this is an idea I had a while back, inspired by how ideas like [illegal primes][] are fundamentally irrepressible as free speech, due to the intrinsically fluid nature of abstract data.
It's not just useful on a free-speech axis, though: in terms of just bare usability, it opens the door for a simple way to represent arbitrary numbers (like IP addresses) mnemonically, without having to lug around huge arbitrary dictionaries that might have proprietary restrictions to them, like the one what3words uses to encode geo coordinates.
I'm interested in hearing what uses Hacker News readers could come up with for this, and other thoughts around these kinds of concepts.
[illegal primes]: https://en.wikipedia.org/wiki/Illegal_prime
Last time I checked, Google's tools (like the Android SDK) require python2.
This is why I designed the similarly-updating glyphs in surpass (https://stuartpb.github.io/surpass/demo.html) to only update after a half-second delay when masked.
Yeah, I posted an edit within an hour after posting the original article - I hadn't read the further takes mentioning that the lookups were A records. I'd only read the comments in a Reddit thread, where people were saying they couldn't understand what the article was describing.
EDIT: I've withdrawn the article. When it comes to the facts presented therein, to borrow a phrase, what was good wasn't new, and what was new wasn't good.
There's no reason to sealion this, but here's a recent article that talks about exactly this topic: https://aeon.co/essays/you-don-t-have-to-be-stupid-to-work-h...
This is a phone screen - the test they make you answer before they take the time to schedule actual interviews.
More than half the assertions in that article are predicated on the false premise that self-driving cars would be owned by the riders for personal use, rather than commissioned per-ride from a fleet (the way ride-"sharing" services like Uber and Lyft work today).
Once you take that part out of the equation, the arguments, one by one, become a lot weaker, if not collapsing entirely:
- Electric cars being impractical: when you're managing an automated fleet, taking them off the grid to be fueled electrically is actually more practical, since it's easier to deploy recharging nodes without manual intervention than it is to transfer liquid. Also, longer on-base recharging times (which aren't necessarily a given) can be combined with any routine maintenance which may need to be done (including scanning the cabin for lost items / cleaning it).
- Ownership costs: this one falls apart almost completely. There is the looming problem that this would give massive corporations even more leverage than they already have, but the solutions there are political in nature, calling for an approach similar to the existing approach to state-run mass transit (akin to how Seattle runs the Pronto bike service).
- No big increase in productivity: "One of the many benefits is smaller than claimed" is hardly an argument against autonomous vehicles - not to mention that that study only looks at the immediate behaviors of current self-driving-car passengers. It's quite likely that, after even just a few months of self-driving fleets being normalized, we'd see workflows start to adapt, with more voice-driven productivity adopted (to avoid motion sickness), possibly combined with translucent displays in the vehicles themselves.
- People like driving themselves: I'm not sure I buy this as a real obstacle for the majority of the population. People liked feeding horses, chatting with travel agents, and browsing bookstores, too- it wasn't enough to keep most people from abandoning them once a significantly more convenient alternative came along. (And if you're only making the decision per-ride, instead of for an up-front bulk purchase like a self-driven car, this decision becomes a lot easier.)
I had the same reaction: why isn't there a "rebase now" button, with a separate "merge" button you can click after CI etc. runs?
Sounds like a more detailed version of Mini Metro: http://dinopoloclub.com/minimetro/
Yeah, don't take it personally. Most of what I wrote there was just pent-up generalized frustration with a lot of published material out there. I regret not sufficiently framing my post within that context.
The authors I really want to hit with this kind of critique are the ones who aren't embracing what you describe here:
Ultimately, doing some writing over the past few months has taught me that I shouldn't necessarily underestimate people's ability to understand scientific concepts if only I take the time to explain them properly.
There's a troublingly large contingent out there that, as XKCD put it, [communicates badly and then acts smug when it's misunderstood][1], [confused about how communication works][2]. These are the ones I really take issue with: the ones who are pleased when the audience who can absorb their material is small, interpreting it as validation of their own abilities (thinking "I'm one of a few people who can understand this"), instead of a refutation of them.
[2] https://xkcd.com/1028/ "Anyone who says that they're great at communicating but 'people are bad at listening' is confused about how communication works."
I particularly apologize for the part about it being pretentious to mention the Cartesian Theatre. While I would cut that in later drafts for being irrelevant (which, like all irrelevant material, confuses the subject), it really doesn't come across as anything more than that, and I was especially projecting my frustrations from other stuff I've read when I characterized it like that.
That wording is no less syntactically ambiguous.
The worst trait I see when domain experts try to write "introductory" material is a depressingly-common amnesia toward what it was like to not already know their subject matter. This article is so badly written, so overly and needlessly wordy, that I'm honestly considering deconstructing it line-by-line as a case study in how not to write articles for the layman.
Here's a brief example, using the most jarring line I've been derailed by so far (I still haven't finished reading this article, getting hung up on runs like this):
So what is the purpose of lateral inhibition in the retina? Let’s consider what kind of stimuli are optimal for activating this bipolar cell.
"What is the purpose of lateral inhibition in the retina?" Uh, hi - I just got here. We are zero lines from the place where we were first introduced to any of these terms (the last two words of the preceding illustration's detail are literally the first place the phrase "lateral inhibition" even appears).
We've just been shown this concept, at all, for the first time - in a literally microscopic illustration, with some concepts so unexplained they were just left for us to hunt for ("Notice that a single neuron pools information" - notice what? Notice how?) - and now we're supposed to be considering the ultimate purpose for this obliquely-introduced phenomenon? Not only that - we're supposed to be pondering this now using a neurologist's lexicon?
If we were actually supposed to be following what the author is saying here, we'd be given some time to reiterate this concept we were just presented from one angle, to consider it in different approaches, with descriptions we don't immediately understand reinforcing a model we could build with other descriptions we could better understand.
Instead of reinforcing its subject, the article spends time on aside paragraphs mocking what a non-neurological model of human vision might be (talking about Dennett's Cartesian Theatre), despite the way that nobody reading this would have that misconception, and introducing it only adds a concept so unrelated that it actively impedes understanding of the material. Passages like this are just thrown in, like the author wants to say "I know more than you, and I want you to know that I don't just know neurology, I also took a philosophy course."
The line I excerpted doesn't even have to spend more time describing the concept. Indeed - it's actually more effective if you make it less wordy, because a high-level general description tells us which things we don't strictly have to understand to follow the next part. Here's how I'd write that whole paragraph - note how much less I hang meaning on unexplained jargon:
So, when a wide area of photoreceptors see the same signal, they actually reduce the signal seen by the tight cluster in the center. Why reduce the signal like this? Because this way, when we see a small detail - one that isn't surrounded by a big area of the same kind of light - that wider group of photoreceptors (connected to the horizontal cell) doesn't inhibit the signal. Getting stronger signals for just the smaller details is what makes stuff like dots and edges visually obvious to our human eyes.
It's not perfectly clear - it still needs a round or two of editing to be truly smooth to read - but, even as a rough draft, that's smoother than anything in the linked publication, which reads like didactic sandpaper.
I think you're missing the part where a non-upgraded connection will be treated by the client as insecure and untrustable.
It sounds like you're confusing what the author is describing with GNU "Change Logs" (https://www.gnu.org/prep/standards/html_node/Change-Logs.htm...), which track every source file change and are indeed redundant with `git log` (or any other version control system record).
This is calling for more use of what GNU calls a "NEWS file" (https://www.gnu.org/prep/standards/html_node/NEWS-File.html), which is what virtually everybody else means when they say "changelog". Per the page itself:
Why can’t people just use a git log diff?
Because log diffs are full of noise — by nature. They could not make a suitable change log even in a hypothetical project run by perfect humans who never make typos, never forget to commit new files, never miss any part of a refactoring. The purpose of a commit is to document one atomic step in the process by which the code evolves from one state to another. The purpose of a change log is to document the noteworthy differences between these states.
As is the difference between good comments and the code itself, so is the difference between a change log and the commit log: one describes the why, the other the how.