srevenant

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.

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

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

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.

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...

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

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.

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

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.

Yep :) Anybody familiar with the roots of OO will understand how wildly Java/C++ and their ilk went off the rails. It wasn't intended as a code organizational system. It's about encapsulation of needs, actors, and sending messages back and forth.

+100 — the heart of the problem

Although I also have issue w/the Elixir docs, they tend to have more explanations in them than the Erlang ones. Marginally :)

I am one who came not from Ruby, btw. My roots come from a variety of things including Smalltalk, C, C++, Perl (dare I admit), Java, Javascript and Python, among those most influential on my life (and in that order).

I'm really happy w/Elixir, finally getting back to a better true object oriented system (for those who know the roots of such).

Then there are those bosses who do it on purpose, to just screw with you. I had one boss who was upset because we both submitted to present at a conference (VMworld) and I was selected, but he wasn't. He then declined the business paying for the trip, so I paid my own way, then he arrived at the conference, slipped past the guard the day I was presenting (I was first panel of the day and did a dry-run) and stepped up to a group of us talking after I had just finished and said, casually, "whew, what a long call I just got off, we were talking about your replacement."

I remember looking at the VMware guys I was with and their eyes were bugging out like WTF, did he really just say that. By this point I was used to his crap and kindof let it roll off me. After we got away one of them asked if I was okay and said screw the presentation--he'd go introduce me to some people :D I talked him through it and did the presentation anyway.

This boss was definitely toxic--he relished psych games, and at one point handed out copies of "The art of War" so we could all "brush up"--and as much fun as I was having working there (not because of this stuff), I finally did leave within a few months on my own terms. Never have I worked with anybody as toxic as that.

(After I returned I asked the CTO about the call the boss was on where they "talked about my replacement." The CTO scoffed at it, and said that call had no such conversation. In followups my boss backpedalled and said he just meant because I was going away for a few weeks and who would cover me during that time--of course that's what he meant).

Sorry, but your testing methodology needs some help. Were you testing OSes? Postgres? Storage configuration? I suggest investigating FIO first, use it to isolate the best performing disk configuration (Storage+Kernel+Filesystem+whatever), then do some pgbench tests with different postgres tuned parameters, to show the best way to tune postgres.

A few thoughts:

* You weren't testing OSes which the subject implied, you were testing Linux kernel variants and their stock OS configurations/kernel scheduler setups, and FreeBSD was tossed into the mix. Whether you are running Ubuntu, CentOS, Debian or whatever you should have the Linux kernel tuned to perform well, so adding the distribution as a variable is just a red herring. I'd be more interested in removing that variable and comparing different storage configurations (such as XFS, and LVM).

* Clients connecting over the network adds a huge variable at play (the network) -- ideally you would want to remove this.

* I may have missed it, but it wasn't clear if you had a warmup period to your benchmarks. Especially with a system like ZFS which has COW, you need to do a few benchmarks on the same blocks first, to break past the cache.

playing devil's advocate: it is easy to claim discrimination doesn't happen when you aren't affected by it--the claim that it is the cause of the individual, no the system, is the usual go-to argument. Try revisiting similar arguments above, but changing them to be about women or black people, and see how they play out.

And for a little flavor, mix in neurodiversity differences. In tech you have people who literally think and act differently. They could be brilliant, but if you expect them to behave and schmooze like your sales team, they are going to wash out. https://hbr.org/2017/05/neurodiversity-as-a-competitive-adva...

Then add to the mix privilege. People who start a few steps ahead, maybe they had better schooling and networks. Somebody who spent 20 years learning the job but starting further behind might be just as good, but just not beginning at the same starting point.

Or, it could just be the fault of the person being old and they should have already succeeded by this point in their life? Don't ask questions, just notice the age and move onto the younger candidate.

Bias and prejudice exists in everybody, we cannot avoid it.

General "wisdom" is to only show the last 10 years of experience on your resume. This is for a variety of reasons, but it largely is because there is an age bias. It makes it harder when you have things older than 10 years you want to show, but the X-Y year doesn't matter more than "spent 3 years working on OSS project doing ..."

There are certainly things that try to weed out inexperienced as well, but there are also people who simply would rather hire a younger person because they have a perception that somebody older would be harder to train (right or wrong).

I had somebody tell me they like to see if anybody had any gaps in their employment. But this is probably a false indicator either way and not worth the problem of encouraging Ageism bias.