notriddle

> Part of me thinks (perhaps naively) if I had the ability to speak with a real person over the phone, we could sort this out instead of constant emails or creating tickets that go into a black hole.

Honestly, yes, I do think you’re being naive.

Ask me about the time I tried to switch from a rented modem to one we own on COX phone support. They bounced me around through separate departments which gave contradicting information about how their own stuff worked, and when I finally gave up and just dumped them for a different ISP, tried to talk us into keeping them by offering a limited time offer for a cheaper price at half the speed (as if).

Or about trying to get payment stuff worked out with my bank. The most pleasant experience I’ve ever had with them on the phone is debit card activation and the occasional fraud prevention notice. Neither of which involve humans.

In short, if they need forced to offer phone support, it will suck. It’ll just be a poor sap sending the email for you anyway.

> There's also plenty of apps which the developer has barred from installing on macOS where this is the only real solution.

You can bypass that with iMazing. It’ll export the raw iPad app, which you can then install on your Mac, and it’ll probably run fine.

Kagi is probably a lot more usable, right now. Nobody’s trying to game it.

As long as it remains niche, it might actually stay that way indefinitely. I’m just worried about Google taking inspiration from them. I bet whatever “tricks” they use now would get a lot less effective if they did.

I get why you want this, but I'm not sure how it actually work in practice without also sacrificing interoperability.

There are a number of reasons why we can basically expect everything to converge on all computers behaving exactly the same, even if the interop standard notionally says they don't have to:

* Any observable behavior will eventually be relied upon. You know, Hyrum's Law.

* Extending a protocol means that someone, somewhere is behaving differently in response to that protocol extension. This means extending a protocol changes its semantics, and that people will either rely on the extension being supported [1], or they will (accidentally or maliciously) create crap data in the extended namespace and penalize anyone who actually tries to use it [2].

* In other words, there is no such thing as optional features in standards. Either the feature works, and implementations that do not support it get fucked*, or it doesn't work, because the implementations that do not support it had enough clout to make it unusable.

* If vendor-locked-in solutions provide a better UX, a lot of people will just use that [3]. Especially if the locked-in version is a superset of the standard, and everyone gradually just moves to the version with proprietary extensions because fixing the interop hazards is more important than whatever feature ties them to a niche implementation. Consider how Linux EEE'ed POSIX. Was there a conspiracy, like with ActiveDirectory and LDAP? Or did it just sort of happen?

[1]: https://acko.net/blog/on-variance-and-extensibility/

[2]: https://web.archive.org/web/20070508200721/http://www.well.c...

[3]: https://signal.org/blog/the-ecosystem-is-moving/

* By "get fucked", I mean "not interoperable." It might still be usable in a limited context, but that means network effects are working against it instead of for it. I need very, very good reason to use two different web browsers.

Also, Wikipedia is able to make so much money from just donations because their target audience is "literally everyone."

MDN has a smaller set of users, and the thing with running websites with user-generated content is that it scales up pretty well. MDN probably only costs about a tenth as much as Wikipedia to run, but has much, must less than a tenth as many users.

Unfortunately, we live in the present, not hundreds of years in the future. The fact that it took so long for literacy to take hold seems like an argument against trying to use education as you go-to solution to a problem, since it’s not only slow, but also spreads unevenly and unpredictably.

Also, I resent the comparison between advocating a defensive design, and being opposed to literacy. It’s not as if I’m advocating for locked bootloaders, or anything else that would prevent a determined user from doing whatever they want. I’m arguing that manual password management should not be the obvious default.

Education has been the plan for the past twenty years. Has it worked?

What’s your plan to reduce the number of successful phishing attacks?

Password managers are a perfectly reasonable answer, but they need to hide the text entry field, to make sure everybody actually uses the password manager instead of entering a password by hand.

Standard Time approximates a fixed noon. DST is a poorly-done jury-rig to make it track dawn instead.

Letting Pocock keep the domain is not a fact. It is a choice. The choice is based on law, and the rendering of the judgement was based on facts, but it is ultimately turning out this way because some people once upon a time decided that domain names should:

* be first-come first serve

* be rented for an ongoing, nominal subscription

* to the maximum extent allowed by law

Giving up any one of these properties, and the Internet would be a totally different place. And none of these are fundamental human rights, or necessary for free speech. They’re just designed to work this way because someone thought it was the best way to avoid various stupid, useless outcomes, like domain names being permanently lost because the owner dies, or some teenagers squatting all the domain names because they think it’s funny, or having an important organization get hijacked because someone manages to fill out a form before the group that really can lay a legitimate claim to that name does it.

None of these are facts. They’re values. You cannot factually prove these things. The only thing you might be able to prove is that, out of all the things we might want from a namespace system, you have to make trade-offs.

Of course not, but that's what DST is intended to approximate. It just does a bad job of it due to insufficient granularity. If we did a twelve minute clock shift, with ten evenly-spaced switch days, the jet lag would be a lot less bad.

Since that would also require a lot more work, it doesn't happen, but it's also more obvious what DST is actually doing when you think of it like that.

While the timezone system is really designed with noon as the fixed point at 12PM, what some folks actually want is a fixed dawn at 7AM. A timezone system with fixed 7AM dawn, combined with a work schedule that uses a fixed amount of time, would guarantee these two nice properties:

* You don't have to commute in darkness (assuming it takes you less than 2 hours to get to work, and work starts at 9AM).

* You have as much daylight as possible when you actually get off from work at about 5. Assuming your day never gets shorter than about ten hours. If you're far enough north or south, this whole exercise gets futile very quickly.

There are cultures that actually did this, but DST is a gross hack on top of a civil time system that isn't designed to work this way, and causes more problems than it solves. I support just getting rid of it.

I know a few people who would choose options 3 and 4...

3. Switching > Permanent Standard Time > Permanent DST

4. Switching > Permanent DST > Permanent Standard Time

It's the ones where Switching is in the middle that are basically unheard-of.

They're handling it better than Samoa did, anyway [1].

[1]: https://mm.icann.org/pipermail/tz/2021-September/030397.html

Especially the "people in power are even less rational" part. The 99% might seem more predictable than the 1% only because the law of large numbers smooths out the random, unpredictable irrational acts.

Is it really a Minimum Viable Product if it needs to have every single feature that the incumbents already have?

This is almost exactly RiffTrax.

> These builds have no FF branding and they've disabled auto-update in them but they have the major advantage of actually allowing you to edit your extensions/add-ons without having to play security theater with Mozilla's automated signing portal every time you make a change.

“Security” isn’t even the word I’d use for what extension signing seems to do. After all, full-out malware — the illegal stuff — can replace firefox.exe with their own.

What it really seems to be intended to protect against is legal-but-scummy applications like Oracle Java that installed random toolbars and add-ons that almost nobody wants. They can legally install an add-on, but patching Firefox itself would be a clear-cut trademark violation, so they won’t do that. Since the Java installer ran with the same permissions that a regular user runs as, they can’t really stop that thing without stopping you.

The phrase I’d use to describe this is brand protection, not security.

Wine does that thing where it traps errors to a log instead of killing the program. Great for compatibility.

Probably not so great for security. I’d expect most cases where Windows switched from being lenient to being strict are exploit mitigations.

Global warming was less of a problem during the golden age of piracy.

Blackhole 8.8.8.8, 8.4.4.8, 1.1.1.1, and 1.0.0.1.

Technically, the provider could use something else, but are they so worried about ad blocking that they’ll run BGP anycast themselves?

They’re called all-in-ones. They’re very popular. The Apple version is called the iMac.

Of course, if you're an adult of average intelligence, then 50% of parents will be dumber than you. Parents who are dumber than you are would not be rare at all.

But I'm not comparing adults with other adults. I'm comparing adults with children. I would be surprised to find a child that was smarter than their parents; it happens, but it's rare.

Older people knowing better than younger people is one of those heuristics that's almost always right [1]. It's hard to tell the difference between a stupid kid and a stupid parent, because stupid parents are rare. Yet people keep searching for stupid parents, because it's really important to find them when they exist. There's a constant rate of kids pulling false alarms on their parents, but you don't want to ignore them, because if one of them is for real, you don't want to be the asshole that ignored all the warning signs.

[1]: https://astralcodexten.substack.com/p/heuristics-that-almost...

As if automakers haven't found plenty of ways to make human-piloted cars less safe in exchange for profit.

Running a program with fixed-rate 60hz (a lot of games) would cause judder. It's the same sort of reason they don't do 150% scaling; you want integer multiples of the "low-fi" version so that you can upscale without artifacting.

They cornered the market on TSMC's highest node, also. This means AMD still gets to benefit from the process improvements, offset by one gen.

The problem isn't creating the XML file. The problem is querying it later, after you've dumped it from RAM to disk, you have to load the entire thing off disk back into RAM in order to rebuild the DOM.

A database like SQLite allows you to perform structured queries at faster-than-O(n) speed straight off the disk.

Sure. All it would take is razing LA to the ground and rebuilding it from scratch.

I don't think I'm exaggerating, either. In a city plan like that one, any public transit route is going to, even at optimal configuration, have simultaneously too many stops and too little:

* Too many stops, because the train or bus spends more time stopped than it spends moving, so rides across the city take forever.

* Too few stops, because you still have to walk a mile to actually get where you're going.

Fixing this requires a walkable city, which can be summarized as "don't spend half the land area on parking and stroads."

A SQL database, with indexing configured correctly, allows you to look up a row in O(log(n)).

A bag of XML bytes doesn't give you that. It takes, at best, a SAX parser to do an O(n) scan through the whole document to find stuff. Most DOM implementations give you O(1) indexing by ID, but they require you to parse it first, and that's going to take O(n).