bhauer

Social media is a scapegoat, hiding a more important issue that doesn't receive enough attention: increasing polarization is the inevitable product of our two-party system.

As someone who doesn't fit within either major party's ideology, I observe the increasing strife between the two majors with amusement and terror. Social media can indeed accelerate the polarization, but as the article concedes, polarization preexisted social media and I believe it would endure and continue to fester even if social media were undermined. Social media is a sideshow obscuring the root problem.

In a modern instant-communication "infotainment" economy, a two-party system establishes a political game where ideological territory is nearly always split. What do I mean by that? Imagine all political ideology as a two-dimensional plane, or a map. In a two-party system, a position on Issue X taken by Party A will inevitably see the space of opposition on Issue X occupied by Party B, even if that position isn't precisely consistent with the rest of Party B's platform. By occupying the opposite position's territory, Party B can capture any single-issue voters who hold that position on Issue X. Meanwhile, thanks to the stickiness of a two-party system and the totality of their other positions, they won't lose members who disagree on X.

The result is increasingly reduced ideological overlap between the major parties, whittling away opportunities for sympathy and reconciliation. On virtually all issues, the parties are at odds with one another, even if that doesn't seem consistent with their ideological roots or founding principles.

Third parties are where you find overlap, like overlapping layers on the ideological map. But because of our voting system (called "plurality voting"), where citizens may select one and only one candidate for each election, third-party candidates are squeezed out by strategic voting that avoids "splitting the vote." (If you support a third-party candidate, you are strongly incentivized to vote for the major candidate you can tolerate, because otherwise you risk "throwing your vote away" and ultimately supporting your opposition.)

It's for this reason that I believe voting system reform is the principal cause to support today. It is foundational: until we can reduce polarization, we won't have the capacity to address other issues.

If we adopted approval voting (select all the candidates you approve of) or score voting (score each candidate from 0 to N), we would invigorate third parties by eliminating the risk of vote splitting. Following adoption, I anticipate we'd see a gradual migration of citizens to more diversified ideologies; a recognition and empowerment of their innate, personal, nuanced ideology; and a weakening of the one-size-fits-all ideologies currently peddled by the two majors, Republican and Democrat. There would no longer be an incentive for parties to always capture opposing views on all issues because other ideological maps could better fit the populace's actual preferences and therefore get more votes.

From the article:

> It is better to focus simply on the e. Yet even that is not precise enough. The environment is an all-encompassing term, including biodiversity, water scarcity and so on. By far the most significant danger is from emissions, particularly those generated by carbon-belching industries. Put simply, the e should stand not for environmental factors, but for emissions alone.

As I wrote elsewhere in this thread (though I was downvoted), I suspect the reason is that this benchmark is measuring the total execution time of a single run of an executable. This would include any time spent by the executable to bootstrap its runtime environment, initiate a virtual machine, and whatever else it needs to do in addition to the relevant code at hand to process the string.

Such a test will favor implementations that have extremely svelte boostrapping, allowing them to immediately begin executing the relevant code and return a result.

I feel a more useful test would be for the relevant string processing code to be run tens to thousands of times within the process itself, so as to diminish the relative importance of boostrap/warmup code and/or runtime optimization performed by VMs. Unless, of course, part of the intent was specifically to measure the impact of the bootstrapping.

I only skimmed the article, but I suspect they are including the time necessary to spin up the executable and any runtime environment prior to executing the relevant code.

"Lightning fast" can mean a lot of things, and it might not mean "executables start quickly."

About a 2013 vehicle. You need to be better than this to be convincing, especially with a green account.

Bjørn Nyland's review of the 2022 Model 3 Performance [1] confirms your view that the Model 3 is absolutely not dated. He tests scores of EVs and still considers the Model 3 the best balance of comfort, features, technology, performance, etc. If anybody here is seriously concerned that the Model 3 may be "dated," I suggest watching the video below.

[1] https://www.youtube.com/watch?v=QdMwGJBFUd4

> The screens melt in Arizona heat.

That's a very old talking point about the original Model S screens from ~2012. Do you have any recent justification for this claim?

He was the director of AI at the company, an important position. Notably, however, the AI director position is distinct from the director of the Autopilot team. That position is held by Ashok Elluswamy.

It was exaggeration as a figure of speech to suggest that if self-driving is solved, it will make the EV business look incredibly small.

What's shocking is how many people interpreted it literally--that the value is literally zero without self-driving--as if the successful EV business is in fact unsuccessful.

This monitor would be perfect as left and right side displays. It needs a matching center display that is twice the width and the same height, yielding a three-monitor configuration with a nice large central display.

While I partially agree with the premise, I perceive the situation a bit differently. By not adequately prioritizing performance at the early technology-selection phase of a development project, teams often find themselves forced to prematurely adopt highly-complex deployment systems and other approaches to scale their low-performance system.

In my experience, a well-functioning new team will include performance in their selection process. Doing so allows a project to defer optimizations such as higher-complexity deployment (e.g., cluster orchestration, highly sophisticated caching, and so on) for much longer than those who build on low-performance platforms and frameworks.

Choosing a low-performance platform and framework sets an artificially low performance ceiling. Developers dealing with a low performance ceiling will either instinctively (through received or learned patterns) or reactively (through user complaints, issue reports, troubleshooting, and tuning) deal with performance challenges they should not need to deal with so early in a product's lifespan.

Ironically, some would say that including performance in your technology selection criteria is "premature optimization," but I argue the opposite: considering performance a feature early allows you to defer costly optimizations (such as the matter at hand, Kubernetes deployment), perhaps even indefinitely.

I laughed when I saw the high score awarded to Los Angeles.

Precisely. Which is why he wants to acquire it and move it in the direction he has in mind.

Precisely. Because it's about Tesla, this gets reported and generates clicks. But anyone who pays attention to cars knows horror stories about service, from any manufacturer you name.

Dealerships aren't just awful for the buying experience. They're also awful for the service experience. If anything, Tesla's model of providing at-home service for small or routine work is an exception from the norm that, in my experience, raises it above other premium brands.

> Is performance inversely proportional to dev experience?

No. I feel there is great developer experience in many high performance languages: Java, C#, Rust, Go, etc.

In fact, for my personal tastes, I find these languages more ergonomic than many popular dynamic languages. Though I will admit that one thing that I find ergonomic is a language that lifts the performance headroom above my head so that I'm not constantly bumping my head on the ceiling.

> In some areas, US administrative capacity remains world-beating, most obviously the military, which enjoys bipartisan and popular support, and vast investments of resources.

I think this claim requires support. Yes, military spending is high and has bipartisan support, but I don't particularly agree that it is a hallmark of highly capable administration. Funding does not equal capacity.

Agreed. I'm not familiar with PDP or VAX Basic, but I did grow up on GFA Basic with its PROCEDURE and FUNCTION. Both could be called by just using their name without a GOSUB.

    PROCEDURE printfoo(bar%)
      PRINT "foo: " + bar%
    RETURN
    
    FUNCTION double(number%)
      RETURN number% * 2
    ENDFUNC
    
    ' Prints "foo: 8"
    printfoo(double(4))

I'll quote myself:

> How is it not easy to check a reputation database for domains when evaluating a mail server?

The point I'm making in this thread is that they have the ability to maintain a database of domains that have been proven to be trustworthy. I am not talking about a database of IP addresses, and I am not sure why that is being raised here.

I'm sorry, but I don't buy that argument.

Google--a technology giant with algorithms and heuristics running most operations--is not up to the task of improving algorithms for email server reputation? No, they are definitely capable of improvement. It's simply not of interest to them.

I can hardly blame them because the cost-benefit analysis clearly says, "why bother?"

Of course anything can be gamed, but magnitude matters. I've had the same domain for 24 years, with many hundreds or thousands of email conversations between users of my server and those of the major email players over the years. I had to switch my mail server's IP address two years ago. Immediate zero reputation from many big players.

> The problem of identifying if a new IP is used for spam is not easy to solve.

How is it not easy to check a reputation database for domains when evaluating a mail server?

Using DKIM records, Google could cross-reference the reputation for the sending domain and, where applicable, recognize that the domain in question has never been malicious or negligent. And in that case, extend a probationary reputation sufficient to allow the IP to establish its own new reputation.

> The real story is nobody cares.

Exactly. Why should the major players care about those too small to matter?

> Sure you would have to catch people buying a "good" domain that expired

Adding to my earlier point, Google and Microsoft are well-enough connected to the domain registrars to know when that scenario has happened as well. If they put any effort into it, they could reliably determine whether a new IP address for an established domain is legitimate or a fraud. But as we've said, why put any effort into it when the only people complaining are not important?

> The hobbyist/small mail server is historically more likely to go unpatched and pwnage is more likely to go unnoticed, so it’s unfortunately a good defensive move to penalize them reputationally by default.

But to reiterate my earlier point: Google and Microsoft have the computational and storage capacity to have a detailed history of all domains' authoritative mail servers behavior. They will know whether a domain has a history of patch negligence.

No, I think the far simpler explanation is that they just don't bother tracking reputation by domain. Or if they do, it's largely overshadowed by the weight given to IP-based reputation.

The annoying thing about the major email services (Gmail, Outlook, et al) using reputation as a key input in their spam prevention algorithms is that they don't handle reputation in a way sympathetic to small and hobbyist mail server operators at all.

Google and Microsoft have the computation and data storage resources to forever record how much spam they've received from the mail servers operated by any given small company or hobbyist. If a domain's authoritative mail servers have a history of never sending spam, when that company or hobbyist (for any reason) has to switch hosting providers and gets a new IP address, Google/Microsoft should recognize that the domain, and its referenced mail servers, has never been malicious.

But instead, the majors treat a new IP address for a long-established domain as entirely new to the internet and assign it zero, or even negative, reputation. And they don't care to address this because, well, why care about hobbyists and the rare small company insolent enough to try to self-host email?

The clarification email Musk sent to all staff had this to say:

> Tesla will be reducing salaried headcount by 10%, as we have become overstaffed in many areas. Note, this does not apply to anyone actually building cars, battery packs or installing solar. Hourly headcount will increase.

This addresses any confusion about how two new factories could ramp if overall headcount was going to take a 10% hit. But to be fair to CNBC, they probably didn't have this context when they wrote the article and headline.

Source: https://twitter.com/WholeMarsBlog/status/1532728341865943040

> Not one of them had any QC issues.

Same in my experience, though it's not as extensive as yours.

It's surprising how often you see negative anecdotes about quality control amplified as representative of a larger trend. It often seems there is an agenda compelling many to work so hard circulating negative opinions.

My unconventional take: The early death of Home Server before the concept could really take hold is the most disappointing loss here. I often think modern computing could be superior today had more consumers become comfortable with home servers rather than relying on public clouds.

This reminds me of my rant about televisions versus monitors on my 2014 blog entry "4K is for Programmers."

https://tiamat.tsotech.com/4k-is-for-programmers

I am in favor of permanent standard time, but failing that, I am super happy with permanent daylight-saving time.

Far more important to me is ridding ourselves of the twice-annual insanity of changing clocks. I'd be okay with adopting UTC if that meant our clocks never changed again.

Furthermore, although it's for use on the autobahn, it's limited to 37 MPH, further narrowing its use case.

I think in the short-term the strategy is this from the article:

> Or ... block all the IP addresses of Google App Engine, at the risk of blocking many applications. having nothing to do with tracking.

Anyone hosting legitimate apps in the Google ecosystsm is indirectly complicit in this and at least for my personal network, I have no concern with blocking Google App Engine holistically.

Additionally, I think it's important to hurt Google as much as possible for escalating in this way. Widespread blocking of GAE may seem extreme but it's also arguably warranted.