> there are billions of souls on this planet. They're not a rare thing
> like say, gold. They're very easily produced, by two people getting it
> on. That leads to a harsh conclusion: human beings aren't that valuable
> as individuals. We are in fact very disposable and replaceable.
I appreciate the perspective you're offering here, and I don't entirely disagree, especially from an economic angle. But I do want to offer a counterpoint:
Lumps of gold are largely interchangeable. It's just a mass of gold atoms that we don't differentiate between, so one lump of gold is as good as another. But people are not like that. If you were to painstakingly transform a lump of gold into a beautiful sculpture, it would be worth more than its face value. And if a person transforms from the lump of flesh they are born as into a unique individual, they are worth something more, too. Two gold sculptures would not be interchangeable, to an art aficionado, and two people are not interchangeable in that way, either.
On the gross large scale, yes, we're all lumps of flesh squidging around on the planet; a uniform slimy patina on a tiny ball of dirt. And our various large-scale systems and policies (economic, political, etc) treat people in this way, too, in varying degrees.
But you are living your one and possibly only life (just like everyone else). And you have taken a unique path through that life (just like everyone else), and I'd just encourage you and/or others reading to cherish that, both in yourself and others, even if (or especially if) the systems in which we live don't seem to. It is something that can't be taken from you, because it is intrinsic to you, and that is a value beyond "what someone will pay for."
My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops.
Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema.
I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:
> you are back to the same problems that certificates have.
Some of the same problems. One nice thing about verifying content rather than using an SSL connection is that plain-old HTTP caching works again.
That aside, another benefit of less-centralized and more-fine-grained trust mechanisms would be that a person can decide, on a case-by-case basis what entities should be trusted/revoked/etc rather than these root CAs that entail huge swaths of the internet. Admittedly, most people would just use "whatever's the default," which would not behave that differently from what we have now. But it would open the door to more ergonomic fine-grained decision-making for those who wish to use it.
I recently learned about the fact that Sichuan peppercorns are actually related to citrus, so was looking for where the connection is... As it turns out[1], there is a "citrus family" (Rutaceae[2]) and a citrus genus (Citrus[3], in that family). The Sichuan plant is a member of the family, but not the genus (that would be Zanthoxylum[4]). Confusing!
MetaPost is written in literate programming language WEB, then generating
Pascal code from it. Hence the tooling and developer experience around
it is quite suboptimal. Extending it is also almost impossible.
It's unfortunate (and a little funny to me) that a literate programming language, the whole purpose of which is to remain highly maintainable for future generations, is a stumbling block to development. Maybe we need literate build systems, so people can even begin to do development in the language proper? Or maybe the whole "literate" concept harkens from an increasingly-bygone era where it was assumed that a maintainer would spend a long time getting to know the existing system in detail, basically reading a book's-worth of material on the subject as they do their work.
Does anyone know a google-able term for split keyboards that have doubled keys down the middle column (B/N, G/H, T/Y, 6/7)?
I see one instance on this page of a keyboard with double "B" key ("Alice layout"), but not the others.
I've been interested in trying a split keyboard, but I like to type those middle keys with either left or right hand depending on the moment, so all the split keyboards I've tried have ended up somewhat annoying, for that reason.
I don't think there is an actual name for that. I actually don't think I have ever seen a keyboard with a layout like the one you describe. I'm not really sure if it was really intentional on the Alice layout. The extra B might just be for extra symmetry between the two halves.
I didn't see it on the feature list, but it might be nice to allow it to run as a cron job and send email for reminders. These days, most mobile phones have an associated email like your-phone-number@vztext.com (depending on carrier), so you can send yourself text messages about chores and whatnot.
Or, perhaps just as good, have a way for it to dump out data as json, and could be consumed by some other send-the-email tool. There is the "-json" sqlite option, of course, but I'm not sure if your schema is meant to be stable.
I have a perl script for reminders like this that has been super handy over the 10+ years I've been using it. Never bit the bullet to put it in a nice UI or have a backing DB like this project, though.
There's definitely some scope and appetite for some notifications/reminders here. I haven't thought about the UX here, but the ingest pipeline + automatic reminders seems like a killer combo!
I went down this rabbit hole a while back — there's a fascinating history of various scientists' investigations into the blue sky, across many decades, with some back-and-forth between Russia and Europe. Einstein eventually made a connection between it and the seemingly-unrelated issue of "critical opalescence," by showing that the fluctuations of densities is responsible for the scattering, not just a simple "individual molecules floating in space" analysis that Rayleigh originally performed. But funnily, for an ideal gas (such as our atmosphere), the formula works out to be the same.
So, "Rayleigh scattering" is the common term still used today, but there is a deeper reason for the formula being correct — it remains correct even when molecules are relatively close together, such as in the lower layers of our atmosphere.
The one in the article is the same essential technique (structurally speaking), but with a lot more decorative flourish.
reply