chrisfinazzo

No argument here.

For some reason, people feel like this should be a replacement for traditional luggage tags.

I do not understand this mindset.

I’d prefer to have a dedicated loop for my bag and the inside attachment points just aren’t big enough. I’d feel more secure if it wasn’t loose in a pocket and could easily fall out or be removed by an unscrupulous (or inattentive) airline or TSA employee.

This might also explain why the first party luggage loop accessory seems to have been (unfortunately) memory-holed. I think third parties still sell them out of excess inventory, but they've been harder to come by in recent times.

My current carry-on doesn't have large enough attachment points to easily accommodate the Apple leather case's keyring, so an updated loop would have been welcome.

As the platform owner, they explicitly reserve the right to do this - see also Meta, Google, Amazon, etc.

Apple collects data, but they usually keep it for their own use, that's the difference.

Third parties trying to do the same level of collection and also share it with partners is the issue. As such, the platform owner putting constraints on them by applying rules related to privacy shouldn't surprise anyone.

If it does, you're not paying enough attention.

I've had the preferences "close windows when quitting an application" and "ask to keep changes when closing documents" checked since the day they appeared in System Preferences.

With these two, most applications behave as they did in the pre-Lion document model.

I see the appeal of using Gmail to manage all of your mail, including the fact that you can still send through external SMTP servers, but it's just not for me.

Native clients continue to improve, and the mismatch between how I handle Gmail on iOS vs (for example) Fastmail shows that they're so wedded to this particular mindset that it's unlikely to ever be fully solved.

I look at people like my Dad -- early 70's, who spent most of his career as the "desktop infrastructure" manager at a midsize insurer -- who still wants to have Outlook available because he likes how Outlook does mail. It's just how his mind works. IMAP exists, but it's an implementation detail that's separate from the specific client features they add.

    Wouldn't mind exploring something akin to a web-based, self-hosted Thunderbird mail client giving a server hosted web UI for multiple email and nntp services.

Self hosting your own mailserver is almost always a bad idea unless you're really a dyed-in-the-wool mail nerd - I worked for one at a small startup one summer during college, but they're a rare breed.

Why are people surprised by this? (No, really)

IMAP "defeated" POP long ago if you wanted to use a third-party client but still access mail from anywhere.

By definition, this doesn't work in a POP environment, but that's increasingly an outdated mindset.

For historical reasons (intertia, and being early enough that I was able to acquire a "firstname.lastname" address), I don't plan to leave Gmail unless things really go south. My personal domain (Fastmail) is used for other things and I've never anything other than Mail.app and their own web interface.

Sourcing .zshrc works reasonably well. I have the following at the end of setup.sh -- which creates symlinks and sets up other configurations.

makeLinks does most of the work, then sets Homebrew's zsh as the default shell -- this currently runs in bash, so it probably will need to be updated at some point -- and everything gets reloaded.

    makeLinks && chsh -s /usr/local/bin/zsh
  
    exec $SHELL && brew doctor

English is a stupid language ¯\_(ツ)_/¯

Not sure...

Someone smarter than me can answer that.

As @rollcat said, I suspect this means that people can contribute modifications, but that they cannot be distributed outside of the official sources.

So, while you can send a patch to add a feature, you couldn't release that modified version on its own.

Related: The installer for iTunes 12.2.1 included a bug which might recursively delete a volume if the path given as input included incorrectly escaped spaces.

How can you be sure that a targeted attack can't exfiltrate all available fields?

For the record, I don't have a great answer to this either -- genuinely curious.

I presume this reversal happened during NT's main support window?