Don't mix use cases. Privacy is different from uniquely identifying senders.

The reason for random email addresses is YOU finally can identify each vendor uniquely by the email they send you stuff.

It isn't about anonymizing, it's about identifying them.

I've been doing it for 30+ years on my own domains.

This is exactly what I use it for.

The point being it works without temp problems in Sonoma. Not Tahoe.

This discrepancy indicates they've changed the software so it works worse.

> This discrepancy indicates they've changed the software so it works worse.

This is what I just said. Apple is switching to devicetree power management in libdispatch, which Intel chips do not support. Processes will eventually stop being efficient on Intel hardware and focus on ARM efficiency, and it's quite possible that this is already happening in Tahoe.

I'm confident it isn't purposeful. But no hardware errors can be found.

Virgin install Tahoe: grinds from 74-C up to 100-C within a minute and then throttles. Virgin install Sonoma: runs fine. No temperature change of note.

This isn't indicative of a hardware problem.

Nothing in dmesg? Maybe try to put some dtrace probes into the sys calls and see if anything is suspicious. Let spotlight index for a day or so first.

Because my account isn't signed into iCloud, that's the whole problem. To sign into my mac with iCloud requires it letting me sign in...

... right, it isn't signed in, so why won't this work?

> "Use another Apple device to reset your password."

> Reset your password while signing in on a new device

I've found the BBB to be a joke, TBH.

Without leverage, your sticks and stones mean pretty much nothing to Apple. I left the Apple ecosystem because complaining about poor cross-platform support and dwindling API coverage fell on deaf ears. Nobody here can wave a magic wand and fix the problem, ultimately we're just yelling at companies that value us for dogfooding their shit UX.

I wish you luck, but I've seldom seen the "Google/Microsoft/Facebook/Apple wronged me!" threads get a happy ending on HN.

calling out versions: no, that's what kindof tipped me over the edge, as trying that and it wouldn't revert.

These package managers are much older. YUM came out in 2002 with yellowdog linux. APT as dpkg came out in 1998.

To start: VSC is made by Microsoft and not the community. That's all that needs to be said.

But to continue on your logic path...

You are right in that the original devs couldn't keep it alive because of VSC, but your correlating that this is because of a lack of community interest, which I think is far from the truth.

The reality is Microsoft owns Github, and they own VSC. Why pay to support two editors? Between the two VSC is more clearly "their" product, so they try to kill Atom to further help their product.

But VSC is dangerous, imho. Not only does it watch all sorts of things you are doing, it's just locking you into the same hegemony that brought you the frightening CoPilot AI that is scanning everybody's code on Github, creating all sorts of problems. https://thenextweb.com/news/github-copilot-works-so-well-bec...

Whereas one of the first things the Pulsar group did was remove "telemetry" from the code base, making it more of a free "no strings attached" community editor.

However, to each their own, as I suggested :) Not everybody likes Atom, but MANY people do. It certainly is not a minor editor by ANY count.

Just because it's #2 or #3 compared to VSC? That's a pretty lofty position.

And if you enjoy suckling from teat of Microsoft on VSC, by all means continue to do so. I am not a fan of their sins of the past and present, so I avoid them when possible.

And personally, I like the configurability of Atom far more than VSC, which I've tried it from time to time—but it's just a different experience, not to my liking.

You took my comment the wrong way.

I don't trust Microsoft and I don't really like VSC.

VSC is made by Microsoft but they have the community who make plugins, report bugs, contribute, spread the word, etc. They have the critical mass to make something like this work while Atom doesn't.

Atom did not die because Microsoft killed it. They didn't have to. They only had to push VSC. Now the original Atom devs are working on another editor (zed.dev) because even they know Atom is done.

This is what I too have wondered.

I'm curious if there are more devs in elixir or erlang.

I'm also curious if it'd be easy enough to have elixir->erlang transpiling, so those wanting from elixir could pull it.

+100 — the heart of the problem

Imagine it's an important lib you can't just replace and there's a bug you need fixed and can't just wait for the maintainer to do it for you. Now you suddenly need to understand that language enough to do that. To some extent this happens very often, I've had it in Clojure+Java and PHP+C libraries.

Exactly the problem I've run into on more than one occasion. And the erlang libs I'm referencing have almost zero documentation, so it really means "RTFC" which then is painful :D