1,264 karma · joined September 21, 2011
So in general I agree that using "full access" should require, say, closer review. But in this case, they've been closely reviewed & approved over the same issue in the past, and FlickType says the keyboard continues to work when full access is off, as it should. Pretty much no matter how you cut it, in the absolute best-for-Apple interpretation here, Apple is still doing a pretty awful job of explaining their review criteria or enforcing them consistently.
Feedbin does this, FWIW. You mentioned you had used Feedbin before, maybe they introduced the feature after you left? It's super useful, and justifies the cost of the subscription all by itself for me. All my newsletter subscriptions go into my Feedbin feed, and my email inbox stays nice and clean (and my real email address stays nice and private).
Every year they post a summary of what models they're working with and how they perform, which is usually good reading. This is last year's: https://www.backblaze.com/blog/backblaze-hard-drive-stats-fo....
The Google policy on PII linked from YouTube's response quoted in the article is intentionally a bit broad and vague and considers "full name" PII, but lots of people say their full name on YouTube videos. Showing ID cards isn't mentioned in the policy - those could violate the rules about addresses, but the ID documentation being shown certainly isn't accurate anymore: the people in the videos escaped the camps and I presume aren't in China anymore.
Maybe it's the documenting of the relatives still in the camps YouTube objects to. If this is a violation, would a news clip about a missing child that includes the child's name and photo also be a violation? Seems like it should be. If YouTube takes that down, are they trying to help the missing child?
I'm not, to be clear, expressing an opinion that the business will be successful with that strategy or that I think it's a good trend. On the contrary, this overall trend of feature-x-as-a-service products depresses me a bit. We've gone from the old days when you had to write pretty much everything yourself (which sucked), to the days when there were a ton of feature-x-as-library choices (which was way better but led to complaints of web programming becoming a chore of just bolting libraries together), to the current trend of feature-x-as-service products.
It's a logical evolution in some ways - similar to libraries over roll-your-own, it reduces your own set of responsibilities. But it also reduces your ability to learn (e.g. from reading source) or grow beyond the provided service (much harder to swap out providers or roll-your-own when the current solution is a third party black box). It also feels depressing in that we've gone from a thriving ecosystem of software based on open source to a much more capitalism-first ecosystem of "this could be a library but then how would I make money off of it". (I realize open source funding & maintainer compensation/sanity is its own set of problems. I just wish we could work on those issues without turning everything into a product.)
For a tool I install & use, my happy path is "install it with my package manager, and then stop thinking about it". Upgrades will happen whenever I decide to ask my package manager to upgrade everything. (I use Arch Linux, so that's usually once or twice a week.)
Needing to hand-setup an installation or deal with multiple package managers like that for a program makes me cranky. I've certainly done it when there wasn't a good alternative (and also occasionally wrap programs in docker containers as well if it's easier - https://github.com/wfleming/dockerfiles), but it's the kind of thing that makes me pause and reconsider whether I really care enough to use whatever the program is.
There's also Mates [1]. Less mature, very simple, but it's what I personally use.
I try to steer away from relying on CLI tools implemented in python or ruby: at the system level they always seem to cause dependency hell problems eventually. Mates is implemented in Rust, so it's compiled, which is primarily why I chose it.
An important related project is vdirsyncer [2]. Ppl, khard, and mates all store data in vcard format but don't talk to APIs or sync anything. Vdirsyncer can sync your vcard collection with your email provider or what have you.
[0] https://github.com/scheibler/khard
From a philosophical perspective, though, I agree that Jefferson and others saw those rights as fundamental human truths. They were saying "people already have these rights, we promise the government won't infringe on them", not "the government grants people these privileges". (Of course, who qualified as "people" continued to be a matter of debate. And some of the "fundamental" rights later enumerated in the bill of rights, specifically the third, seem like pretty localized of-their-place-and-time concerns in retrospect.)
I think what prompted my comment and some of the other replies to pc86 was that the beginning of this comment thread was discussing some fairly specific applied legal concepts (e.g. "parallel construction") from a practical perspective of applied law. So replying to that thread with a point about political philosophy from an entirely different country is a bit of an odd tangent. Re-reading the comment, I do think that's how it was intended, but I think the context made it easy to misinterpret it as suggesting that Americans believe everyone in the world should abide by our political philosophy. Which is certainly regrettably true of some Americans, but I hope it doesn't describe anywhere close to most of us.
As an American I find this a very surprising interpretation, and I doubt anybody in my close social circle would agree with it either.
It's an interesting trade-off. It seems like batch keys for device attestation was designed to help protect individual privacy (good), but if you can't ban a key without potentially a lot of splash damage when you detect a bad actor, that seems like a very limiting choice.
In 1906 it was just firing duelling pistols at dummies, which... c'mon, that's just target shooting with a twist.
Even today, comic books are effectively serialized narrative stories that are pretty reliably published on schedule and have writers who have to keep up for months at a time.
> Authors tend to have phases of inspiration, and lulls in between.
Different writers have different approaches to work. Some writers work in highly productive sprints with long fallow periods, and you're right this model probably wouldn't work well for them. But some novelists do work steadily (Stephen King I believe still tries to write for a couple hours every single day and only takes relatively short breaks between novels), and the fact that this model used to work for a number of books that are now considered classics seems to indicate it can still work in at least some cases.
I'd actually be more worried about the consumer side - the death of magazines makes this model tougher. A given author can reliably produce a novel over the course of a year or two, perhaps, but probably not indefinitely (comic books solve this problem by having writing teams do arcs and then swap out the writer). Magazines used to bundle multiple authors, so subscribers weren't affected by the break period of a single author. In a world where people subscribe to individual authors on Substack and there's no bundling of many authors writing, yeah, it's a tougher sell.
I used a Model M when I was younger and loved it, I'd probably get a used one or buy a Unicomp one if they weren't so dang big.
Likes: It's the best, most reliable 60% keyboard I've found, and that's the size I strongly prefer. It's very compact, it's comfortable, and the layout of keys that are often weird on 60% layouts (e.g. arrows, tilde) are sensible.
I've tried a number of other 60% models and they all either had lousy layout decisions or just weren't very reliable (I had two KBParadise V60s have certain keys start to fail in < 1 yr). Both my HHKBs are going strong after several years.
Dislikes: Topre switches are... fine. Way better than most membrane keyboards, but I would prefer proper mechanical Cherry or Gateron switches. (If you like the mechanical feel but not noise, you may very well like Topres, FWIW.)
You probably saw the other recent thread about mechanical keyboards at https://news.ycombinator.com/item?id=26989563 - a lot of the comments there match my experience. There's cool stuff in the mechanical keyboard community, but there's also a lot of unreasonable pricing and small-batch manufacturing with less-than-reliable quality/consistency. I sort of pigeonholed myself by developing a strong preference for a 60% layout - there are a lot more options out there for larger keyboards. But once I decided that it was 60% or bust, HHKB became the natural choice. It's the only keyboard of this general form factor I've found that is basically a commodity, meaning 1) I'm confident of what I'm getting when I buy it, 2) the price is reasonable and 3) I'm also confident the company will still be around and making a similar product in 5-10 years if I need to buy another one.
FF's extension interface allows more sophisticated rules & blocking behavior, and uBO takes advantage of that. You may be fortunate that you don't happen to spend time on sites where it makes a difference, but I'll say from experience that I do see ads and annoyances on some sites on my iPad that I do not see on my laptop or Android phone (both running FF with uBO). It's not a huge difference - as was said above, Safari with content blockers is certainly usable, but uBO is still better.
I am speculating a bit here because I haven't dug too deeply to confirm this, but I think one technique sites use to work around ad blockers that Apple-platform content blockers don't handle well but uBO does is serving ad content from the same origin as real content (and even with similar paths as real assets). Last I looked, Safari content blockers were mostly limited to old-style rules of "block assets matching this URL" and "block this css selector on this site", so when sites do the work to make ad assets look the same as real content assets, that can't be blocked as effectively with content blockers. uBO can inspect the DOM and other aspects of the page content blockers can't, so it can do more to detect those techniques and block them.
More broadly, I question how effectively "endogenous interest" can be accurately measured without risking a lot of confounding factors from the broader society. I didn't read the original paper, maybe they tried to account for that, but I can't really see how you reliably could. People's interests don't exist in a vacuum, they're tangled up in their upbringing and society. If they'd done a similar study a century ago they might have found women having a high endogenous interest in being homemakers.
If a demographic's involvement decreases as the subject becomes more rewarding, it seems more likely to be because external forces are discouraging them rather than any inherent lack of interest.
And Unicorn is pretty old. It wouldn't surprise me if this object reuse dates back to mongrel's code base, back when doing anything with threads in Ruby would have been unusual.
It's still bad code on unicorn's part (when I got to that part of the post I said "Unicorn does WHAT?" out loud), and GH should have been more careful introducing threads to an environment that didn't have concurrency before, but every step of the chain is pretty understandable IMHO.
It's interesting that lumber kind of looks like shrinkflation (what the comment I was originally responding to suggested), but it's more that technical improvements have allowed producing the same finished product with less input material. But we still label the stuff by the amount of input material it used to take for historical reasons, which at a glance looks like shrinkflation.
For comparison, sheet goods aren't priced this way. A 3/4" sheet of plywood really is 3/4", because the plywood was manufactured that way and as a manufactured product there is no seasoning.
You're not being ripped off because a 2x4 is actually smaller. A sawmill had a tree, and they cut off a hunk of that tree, and they charge by how much wood they cut off. The dimensions of that piece of wood changed after they cut it (which in and of itself is a service they provide - it would be a hassle if you had to buy green lumber and dry it yourself).