awj

So, your answer now is to argue that you don't know whether or not the working conditions are bad, after arguing that they aren't bad enough to entitle people to complain?

Which is it? Why are you now equivocating over this instead of being able to answer for your own conclusions?

Clearly you think the working conditions of Twitter aren't that bad, that was literally the thesis of your first post. Clearly you think that there exists a set of working conditions that are deeply immoral and deserving of at least complaint. That was also the thesis of your first post.

So where does that line exist? When do working conditions go from "not deserving of complaint" to "complaints are fully justified"?

So ... what's the wage cutoff where you're no longer entitled to sane working conditions?

The real "deeply depressing" bit here is how many of us would rather focus on pulling down the top crab than question why we're all in this bucket to begin with.

I never even got to meet one of my grandparents. All I have is stories, and honestly not a lot of those.

I don't think you should feel narcissistic at all. Family is one of the prime places where we share our wisdom and values. Where we pass on the results of our mistakes in the hopes that the next generation avoids them. Don't feel bad for trying to do that, it's one of the fundamental elements of human progress.

By "your own politics" are we still referring to things like "hey it's not okay that you're making fun of people and their different-sounding names"?

Yeah, that's gotta be one of my biggest complaints after years of working with Rails. Eventually you sort-of memorize the conventions and can relatively accurately guess where a file lives, until someone decides to get clever and put things in a weird place.

It also implicitly discourages you from asking yourself if you should be accessing the thing you are. IMO a lot of the tight coupling in Rails codebases begins with being able to grab literally anything and use it with no one the wiser unless the read that specific line of code.

Right, and on the flipside significant effort has been invested in Clang performance when compiling for Intel CPUs. Much of that is likely to the benefit of all backends, but some of it surely is specific to Intel.

IMO this bit right here is worthy of highlighting again:

> Especially when you consider that during the build the workstation is belching hot air and screaming like an airplane about to take off while M1 is whisper-quiet with barely warm air coming from its exhaust.

I have never run a significant amount of compilation on any machine that didn't hit heat issues. So either the M1 is doing very well at managing heat, or Clang is doing incredibly poorly at exploiting the full system. In either case this makes the M1 look like something special.

That's only one part of the problem here.

"Competing" in this sense is delivering similar user experience (battery life, performance, seamless hardware interactions) that Apple is achieving through their top-to-bottom control of the hardware and software.

It's not enough to show off Intel/AMD SoCs and call that good when the other components and software force subpar UX.

> The Ansible vault is a bad example of this. They have a little command `ansible-vault` that lets you manage encrypted files and strings. If you run `ansible-vault edit ./nonexistent_file` it tells you that you meant `ansible-vault create` and vice versa but doesn't just do it despite the user intent being clear. This ultimately lead me to just patching it to do the right thing.

IMO it's a bit much to decide what "the right thing" is there. Blindly assuming that someone attempting to edit credentials didn't mistype a file name isn't exactly safe and sounds like a great way to cause problems based on believing you updated something you did not in fact update.

Do most generic statements start with "This matches my experience"?

Kinda seems like you are, mate.

> or (2) the user to install a certificate generated by the person doing the MITM

You mean like that "setup software" Comcast spent ages trying to pretend I had to install just to get things running?

I ran Linux in those days, which always meant a little extra support time but I never had to install jack.

All of the license-encumbered code lives in a separate directory, with a clear warning that it's licensed, and builds result in license-encumbered code being an entirely separate artifact from the purely Apache 2 licensed code. Besides that, anything that goes into package managers is also fully clean Apache 2 licensed code.

Literally the only way to "mix this up" is to not read anything, ignore package managers and build from source, then somehow decide to use 'x-pack' over 'elasticsearch'.

Based on me augmenting my memory with searches of release notes at the time:

- Phone apps from the jump - Easy ability to upload files - Search includes the content of those files - Editing

> ircd with logging enabled + elastic search/sphinx/lucene + web frontend

Slack is way more than that, though.

My recollection is that even the initial version of Slack was more than that.

At this point, it's enough that "let's extend ircd" isn't exactly a practical answer. Either they maintain their own incompatible fork of ircd or they try to force their business desires into the irc protocol.

There's plenty of things that are "just X plus some paint" if you don't look at them deeply. That usually does an extreme disservice to the difficulty of the "plus some paint" part, and often represents a failure to understand the features involved.

So, what you're saying is there's tons of technologies lying around that are a solid UI and some extra features away from being valuable to normal people. But somehow doing those things and making lots of money is bad?

Indeed.

Unless I find a big chunk of time today, I'm 0/4 on a resolution to write a post a month this year.

Expecting people to build content in their spare time builds in some hefty assumptions on how much spare time and energy they have.

People accuse me of playing Baseball, Football, and Guitar for the band TOOL.

Yep.

I took a deep dive at one point into understanding concurrent transaction behavior in MySQL and its ramifications. Probably go back and reference that post about once a month...

That statement assumes no transmission latency on your current setup. Kinda doubt that's the case.

We see that every once in a while with email, where someone decided to sign up for an email list but also wants to charge $1-2 for "unsolicited" delivery.

Just set your phone on permanent DND w/ exceptions. It's literally the same thing, except you're not going through annoying contortions to "stick it to" someone that is probably a robot...

PageRank is predicated on an assumption that most pages (and thus, most links) are created/curated by humans. This was true when it was invented, but appears to be less likely now.

What gives me pause here is all the anecdotes in this thread about other engines getting results right. If the real answer is "PageRank has been successfully flooded by bots", then everyone would have bad results.

What I suspect, off nearly no evidence, is that Google is using ad tracking to inform a notion of search relevancy. My nearly unjustified belief is that that system is the one being flooded by bots.

> Any thoughts on how a company should balance good service to users (and false positives) with the need to fight black hats?

Charge money.

A big part of why MailChimp responded this way is that they have a very generous free plan. With that they can't afford to dig deep on free plans that violate ToS. You'll get buried under the weight of support/vetting for that.

Once you start charging even a little bit, the amount of spam/fraud BS you have to deal with plummets.

Every hurdle your free plan introduces to blasting out emails adds friction for spammers. Give them enough friction and they'll move on somewhere else. Forcing them to provide a valid credit card before they can send emails is a great way to add that friction.

Except it's not a pure cost thing. Delivering blockchain/ICO emails impacts the deliverability scores of everyone else routed through those same domains and IPs. It's incredibly difficult to pin that to a number, because it's hard to quantify in advance how much of an impact one customer's blockchain emails will have on your IP/domain reputation.

The only way to make it a pure n% cost is to isolate the individual customer or all blockchain-email customers to a dedicated set of IPs/domains that can have their own (probably: really shitty) reputations. At that point, it's highly likely you'll go through all that effort just to take money from people and still not be able to deliver their email due to catastrophically low reputation infrastructure.

Refusing to accept the impact to your other customers of a hot spam topic is not "censorship". People really need to stop misusing this word. Mailchimp is a business, and has every right to take reasonable steps to protect their customers. It's already pretty common for porn and get-rich-quick businesses to be refused by these services, largely for the exact same reasons.

"accountability", as in a golden parachute and maybe an uncomfortable congressional hearing or two?

Yeah, huge responsibility there...

That might be part of it. Plenty of other restaurants need (at the least) experienced cooks who probably would have gotten bounced out if they couldn't keep food safety more or less in order.

A lot of it, I would guess, is simple scale. There's like 800 more Chipotle restaurants than Chili's, and I'd be damn sure the volume of meals coming out of each one is skewed far towards Chipotle as well.

> Except that, uh, "header" and "footer" themselves are layout terms.

Doesn't that give them semantic meaning? When I see a "header" tag, that tells me something about its intended use. When I see a "div" tag ... I start reading ids and class names and hope for the best.

I would assume that the Lambda team is more likely to fill in gaps in support for things that already have official SDKs before starting to officially support something that the rest of AWS isn't yet working on.

OpenLayers vs. Leaflet is a bit like Rails vs. Sinatra: one is a lot bigger and heavier, but you'll probably end up reimplementing 1/4 to 3/4 of its features if you go with the other.

Plenty of cases where either choice is the right one, IMO.

You're the one saying we should effectively stick with the current mechanism, despite its flaws. The onus isn't on me to provide an alternative, it's on you to defend a problematic solution.

He's arguably already had legitimate and impactful successes. Building a business even remotely capable of commercial spaceflight is a huge deal. What Tesla has done, both in batteries and in getting the major auto makers to put focus on EVs is a huge deal.

Musk arguably does significantly more talking than doing, but his goals are lofty enough that even failing to make it halfway still means significant advancement.