Does the macoOS login keychain get backed up by Time Machine backups in a way that could restore the keychain if the original machine's Secure Enclave is lost or destroyed?
Small self-driving busses would do exactly what you want. The cost of increasing bus service is overwhelmingly the cost of bus drivers. If the busses could drive themselves, cities could afford to deploy a lot more busses, especially smaller busses, running much more often.
As for light rail, in the US, light rail projects can typically cost hundreds of millions of dollars per mile. The NYC 2nd Avenue subway expansion cost billions of dollars per mile.
And, if you want people to stop wasting city space on parking, self-driving taxis are exactly the right solution.
If buses are autonomous, it no longer makes sense to have arbitrary routes that people need to wait at a bus stop for. They can wait in parking lots, charging their batteries, until they are summoned, and give people door-to-door transportation.
It sounds like an autonomous taxi, but not necessarily. A taxi usually has only one rider, whereas a bus would have more seats, and potentially pick up and drop off other riders that are more-or-less on the way. This is Via's Microtransit[1] model, but without the cost of a human driver, it becomes much more cost-effective to deploy at large scale.
That model doesn't really work with high demand I wouldn't think. The thing with the fixed route case is you no longer have to serve the many edge cases, you force people to solve it themselves and maximize the service you can offer over a more collectively beneficial routing.
In principle, but there are hard physical challenges such as the lack of space efficiency between a typical four occupant sized vehicle and a bus that holds some 10 or 20 fold more people on maybe only double the road footprint. Time to seek out your paired ridemates is something to consider, it melts away as you pack more people into the same vehicle and increases both in time as well as space as you start introducing more lower capacity vehicles.
You're not comparing against real-world fixed-route bus routes.
In the real world, most bus routes run nearly empty if not completely empty most of the time, belching diesel smoke and paying a driver, in order to ensure that service is provided to remote locations and that service is made available on a regular schedule. In cities, utilization is usually higher, although you see the same pattern off-peak.
In suburban and rural environments, the footprint is nearly irrelevant, but the lack of riders means that early attempts would start with designs that prioritize battery capacity and range over the sheer number of seats. In urban environments, the final mix of buses will look closer to a combination of mid-size buses for door-to-door and full-size buses for trips that are door-to-door but in practice are no different from fixed-routes due to the sheer number of people who take the current routes at rush hour.
> And, if you want people to stop wasting city space on parking, self-driving taxis are exactly the right solution.
Self driving taxis have to be parked (or cruise around continuously), I guess, and that parking better be close cause ain't no one waiting for a self driving car parked 30 minutes away to get moving.
1. Dating apps/sites are a rich-get-richer market. Most people go where everyone else goes, because everyone else is there.
2. The more work you ask your users to do up front, (e.g. answering a bunch of survey questions, taking high quality photos, paying up front) the fewer highly desirable people you'll have, because they can easily find people wherever they go without doing all that work.
3. Swiping is more fun (more addictive) than answering survey questions. OKCupid switched to swiping when A/B testing showed that swiping retained people better than survey questions.
1. Dating apps/sites are a rich-get-richer market. Most people go where everyone else goes, because everyone else is there.
I get that this is true for social networks in general, like messaging platforms, there's a first mover and network effect.
However for dating apps specifically, there is not truly a network effect, all you need to find is one person, and for monogamous relationships (which incidentally are more common among heterosexual couples, whereas Tinder and its descendants, coming from grindr heritage, tend against) it's even more true, as in the ideal scenario each user finds one other user, there's not a huge amount of network interaction.
I also think that both in the general and specific course, there's a lot of incentives for niches, subcultures, alternative cultures, often times part of a culture is to avoid the monotonizing mainstream tropes and memes.
You also have a self-selection effect: users willing to fill out more involved surveys may pair with each other at a higher rate than the overall background.
> for monogamous relationships (which incidentally are more common among heterosexual couples, whereas Tinder and its descendants, coming from grindr heritage, tend against)
Describing everyone who isn't straight as "tending against monogamy" is bigotry. I'm aware that there's a 0.1% PP difference or whatever -- still absurd.
Not sure if it helps, but I mean male homosexuals. Lesbians are more monogamous, so it's not a matter of being homosexual that makes one less monogamous, it's more that men are more hypergamous.
This is true in almost all species, as there is an evolutionary benefit for males to mate in excess of one partner, as each subsequent mate increases the chance and amount of offspring. Whereas females have little benefit to mating in excess of 1 partner, as she cannot have more than 1 child in that period.
So if anything I would be sexist against males (of any species)? Or sexist against women? It depends on whether you consider monogamy virtuous or not. Or maybe pointing out any difference, even if morally neutral, between two group of people is enough to be a bigot, in which case I would avoid speaking about protected classes of people, which doesn't sound great.
I don't know what the rules for bigotry are, (but I know it when I see it). But I'd dare say that even pointing out negatives of a protected class can be fine. If we are talking about basketball and I point out that the Japanese team is too short, that's not bigotry. That a comment is tangential instead of central to an argument is probably also relevant.
As for the accuracy of the claim, I won't cite a study, some truths are accessible by simpler, perhaps more social means. If you know gay people, talk to them, ask them directly if they feel comfortable and you care about it. Also take a look into the history of dating apps, is it a coincidence that Grindr was originally gay only? Is there an equivalent Lesbian hookup app?
Also, I'm sorry if you are gay and found this offensive, I just assumed you were straight and were just being offended in the name of someone else. I don't think many gay people would question that men are less monogamous, but I may be wrong..
There's no suggestion of that in the quotation. The author is suggesting that Tinder was designed as a straight hookup app inspired by grindr, the gay hookup app. This is not really true in the specific but certainly isn't implying non-straights are "tending against monogamy".
There isn't an offensive imputation contained in being called non-monogamous anyway, unless you in turn have a prejudice against polyamory etc.
There's a hack: if the platform appeals to some of the most sought-after women, it can win, since the most sought-after men will follow, and the marjority women/men will follow chasing the first two groups. (same dynamic is used to fill empty nightclubs).
Bumble did this to Tinder. Coffee Meets Bagel is currently trying to do it to Bumble.
Bitwarden lets you extract and import passkeys. Apple, Google, Microsoft, and 1Password don't support that directly, but they do support a finicky app-to-app transfer system, where you install two password-manager apps on the same device, and you directly export your passkeys from one app to another. It's called the "Credential Exchange Protocol" (CXP).
Bitwarden's app can receive CXP passkeys, so you can install a passkey in Apple's password manager, CXP it to Bitwarden, and then export it to a file that you control.
Putting the file under your control does make it possible for someone to trick you into sending you that file, undermining some of the phishing protections of passkeys. It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
People just assume that, but it's not true. If you have access to your Microsoft account, then you'll have access to your Microsoft passkeys in the cloud.
Passkeys are just passwords that require a password manager. You can login to Microsoft with a Microsoft passkey, but that's not the only way to login to your Microsoft account. You can still login to Microsoft with a password.
All password managers require just one last password outside the password manager to access your account. That's how Microsoft's password manager works, too, and that's why you'll always be able to use a password to login to your Microsoft account.
(If you're afraid of Microsoft banning you from your Microsoft account, then don't use Microsoft's password manager. Bitwarden is pretty good.)
Passkeys aren't tied to physical hardware. They're tied to your password manager. Passkeys are just passwords that require a password manager.
On Windows, macOS, iOS, and Android, there's a cloud-based password manager built into the operating system, so you can use your passkey anywhere you use that password manager.
Microsoft, Apple, Google, 1Password, and Bitwarden all have password-manager apps for Windows, macOS, iOS, and Android.
Pick a password manager and use the same one everywhere, and your passkeys will be available wherever you go.
Well, unless you have a device-bound or FIDO2 key, according to the post.
And I think for FIDO2 keys, this is fine. If I can register a key (plus a backup) the usage doesn't seem so different from a regular key.
For the rest, I think what irks me is the feeling of "you have free choice which corporation you want to entrust all your login credentials with, but you will have to choose one". Previously, password managers were a convenience (that incidentally also increased security, because they made keeping a separate, hard password for each domain practically feasible) - but nothing stopped me from keeping passwords at several different places at once or memorizing some of them, in case I lose access to the password manager.
Now suddenly, they become the arbiters of my logins everywhere. What happens if they ban me, or go out of business or get bought up? (Or in Apple or Google's case, make arbitrary business decisions that can now affect the way I login to completely unrelated services?)
You say "they're packing lots of signals into fewer words," and sometimes they do, but often they do the opposite of that.
I think the deeper problem is that the models (not just Claude) have a very poor understanding of what their readers already do/don't know.
They belabor obvious points and underexplain jargon, because they don't know what's obvious to you.
The best writing is surprising but inevitable in hindsight. The models don't know what's surprising or what's inevitable in hindsight, making it very difficult to write well.
+1. Most games, once shipped, completely disband their development team.
If you require game developers to even so much as recompile their game, they simply cannot do it. If you want the game to keep working, you have to guarantee ABI compatibility in perpetuity.
Now seems a good time to mention that you can beautify your XML RSS/Atom feeds without XSLT using CSS and JS.
You can add a stylesheet to an Atom feed by adding a <link> tag with an xmlns attribute, like this:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="stylesheet" href="style.css" xmlns="http://www.w3.org/1999/xhtml" />
<!-- ... the rest of the feed goes here ... -->
Or add styles directly with a <style> tag:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<style xmlns="http://www.w3.org/1999/xhtml"><![CDATA[
* { color: red; }
]]></style>
<!-- ... the rest of the feed goes here ... -->
You can even run JavaScript when users browse to your feed like this:
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<script src="script.js" xmlns="http://www.w3.org/1999/xhtml" />
<!-- ... the rest of the feed goes here ... -->
You can use JS to transform your XML, just like you can (could) with XSLT.
