kmontrose

This rebuttal is... poor, I guess? Not disingenuous or anything, but lots of wishful thinking and (for lack of a better term) "inside baseball"-objections.

Like sure H3 might be a byproduct of other mining on the Moon, but the hard part is the mining at all yes? It's wishful thinking to handwave away another hard problem and then say "this rebuts the other hard problem". Or "we'll get the metal for a Venus cloud city by moving asteroids into orbit" - yeah... if we can move and mine asteroids, building on Venus would be a lot easier but we can't do those things? Or an assumption of high enough immigration rates to offset genetic diversity concerns - space travel is hard, expensive, and all of this is at (or beyond) the limits of current engineering why assume a certain scale?

There's a fair amount of "only Musk and/or Bezos say X, but there are others in the community you say not-X" - which I'm sure is true but seems irrelevant? Like it or not, a handful of rich folks (and Hollywood and other popular media collectively) set the bounds of discussion here. Most telling in the rebuttal around Moon and Mars settlement, where the argument seems to be "A City on Mars is right, but we should also be talking about Venus and Titan (etc.)" - if I grab a random non-expert off the street, they're gonna list Mars, Moon, and maybe "space stations". Heck, didn't the current NASA admin announce plans for a nuclear reactor on the Moon? Presumably that's to power something (not that I expect it to ever be built) base-or-settlement-y?

A City on Mars is a pop-sci book so I'm sure there are plenty of issues, but (at least as a non-expert) the critiques I've seen (and this one in particular) are really poor.

YoY sales are down while other automakers are up, Q3 might be an artifact of EV incentives expiring. Iirc other manufactures also saw an increase in EV sales in Q3.

The Stack Exchange TOS ( https://stackoverflow.com/legal/terms-of-service/public ) doesn't assign ownership - posters retain copyright, SO gets a non-exclusive license to it, and everybody else gets it under various CC wiki terms.

I don't know that I've ever heard such a violent "woosh" as the goalposts were moved. Going from "obviously happened, consistent with evidence" to "the problem is the way it was discussed in private" is just... wow.

I wonder how this would play out if we transposed it to any other field. If I was interviewed and asked if So-And-So had proved P=NP, I'd just say "almost certainly not" knowing that any other response would require an amount of nuance that wasn't going to be conveyed - despite having plenty of private conversations that "yeah, P=NP is total possible and it'd be interesting because...". And that's a pretty theoretical problem with immediate real world impact, and relatively little new being discovered day-to-day.

I'd be shocked if there was any non-trivial topic discussed in any field where the internal debate _isn't_ broader and more nuanced in private than what is conveyed in public interviews. That's a natural consequence of communicating to a population with less expertise than the speaker, IMO.

> This, is damning evidence regardless of any of that. Nothing remotely like this was being presented by mainstream newsmedia, perhaps because nothing remotely like it was being presented to them by the scientists they talked to. There was no version of a lab origin theory that was being presented as worthy of consideration.

You have to acknowledge this is incredibly weak logic. “A thing is possible, therefore it happened.” Is this molecular evidence the Furin Cleavage Site? Cause that was peddled basically as a lie - they occur in nature just fine, it’s also used in research.

I’m unaware of any compelling evidence for the lab leak theory, but I will acknowledge it’s basically impossible to disprove. We don’t know where most diseases arose (or where they came from) - it’s just we mostly don’t care, unlike with COVID.

The Old New Thing: https://devblogs.microsoft.com/oldnewthing/

Been reading it for years, lots of little interesting insights into current and historical quirks in Windows and related systems.

Only became a problem in combination with other missteps (or constraints, like dev needing to be routable).

Which is what makes this kind of stuff so insidious.

It's this.

Discovery, immediate mitigation, deeper mitigation, general notice, notifying effected users - all these can happen pretty quickly once the ball is rolling. Once you're dealing with "the law" in any capacity you are constrained in what you details you can share broadly, and when.

I'm happy we were finally able to share this level of detail.

The breach itself was announced shortly after it was discovered: https://stackoverflow.blog/2019/05/16/security-update/

And affected users were notified once identified, which was shortly after the announcement: https://stackoverflow.blog/2019/05/17/update-to-security-inc...

This is an update with more details, which was held back for legal reasons.

The House has already passed a couple bills funding the government, in whole or in part[1]. They haven't been taken up in the Senate.

One of the bills passed this week: https://www.congress.gov/bill/116th-congress/house-bill/21?s...

[1]: https://www.cnbc.com/2019/01/04/house-passes-bill-to-end-gov...

There's a pretty strong connection between the numbers the tool has and market rates - it's not like the numbers are pushed top down, they come from actually participating in the hiring market.

The calculator normally gets a few revisions a year, one of the things that prompts that is market rates changing (others are things like hiring for new skills, or new roles being created).

What's nice about the calculator is, if the market rates change, everyone gets a raise (and knows they should). It's not just the new hire (who's mostly recently on the market), it's everybody in the same skill track.

The calculator also keeps us honesty about what matters for compensation. When the yearly salary review comes around, you can point at things you've done in the last year _and_ at where it says they should matter. It means fewer surprises, less frustration, and less fear that you're being too aggressive or too passive in salary discussions.

You also install runtimes once for other languages.

GOPATH isn't awful, but it's something more than "just source" as claimed in the article; which is my point. Go is simple, but not as simple as claimed.

My point is that `go generate` requires more than just source, and thus isn't "simpler" in the manner claimed in the article.

I'm not judging the existence of `go generate` or it's merits relative to some other environments. Except makefiles. Makefiles are worse.

And? Presumably some of these packages get updated, handed off, or are collaborative in the first place. Re-generating is part of continuing development.

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit.

---

> Go programs are built from just their source, which includes all the information needed to fully build the program.

Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source.

> C# is joined at the hip with Windows. Objective-C and Swift are for Apple. Java and Scala and Groovy might benefit from JVM bytecode and its independence… until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware.

C# has Mono, you can use Objective-C with gcc, the JVM has a bajillion implementations. I suppose Swift is more or less unportable at the moment. 1 out of 4 ain't great.

> Go is helping pioneer a command-line renaissance that reintroduces a generation of programmers to the idea of writing tools that fit together like segments in a pipe (the original Unix philosophy).

This never went away. Heck we were going over this in college, which for me was in Scheme, Java, C, and C#.

Something of an in joke I suppose, but design thought it was funny enough to leave as is.

Localization probably kills that, since this is displayed to users a not-insignificant amount of the time.

"9" is pretty well universal (I know, not strictly, but for software Arabic numerals are kind of assumed knowledge); "Nine" on the other hand isn't something you know without being able to read English.

(Having been through a pretty big localization project recently... this stuff sucks. So much. All your assumptions start breaking.)

Such as?

App compat's out (ie. "Run this program in compatibility mode for"), too many libraries. They'd never get an accurate enough list of affected programs.

They can't change the reported OS name, too many apps display it; and it'd be crazy weird (a bug for all practical purposes) to have programs claim they're on "Windows 10" while the box says "Windows 9".

Probably can't change the format of the name either, ie. "Windows(tm) 9" or "Microsoft Windows 9" or whatever; I bet tons of apps just check for "Windows " as well.

It's an unfortunate choice, but I don't really see an alternative if they wanted a numeric version number.

It doesn't even cover C#, just C++ and Java. C# has it's flaws certainly, but it's a baffling omission.

After thinking on this for a while, I personally doubt the license applies.

Most importantly, it applies to the software (ie. the Perl script; or a compiled version of it) not the "name" or "invention" of Markdown. To own the name, he needs a trademark; to own the invention, a patent. Since Standard/Common Markdown isn't a derivative of the Perl script, the license itself probably doesn't apply.

If he does claim a trademark (registered or otherwise) he hasn't defended it at all for going on ten years now. It's really hard to imagine a court not finding it to be a generic trademark as with Kleenex or Aspirin.

I doubt very much he claims a patent, he's way past any grace period in which to apply for one subsequent to his initial disclosure.

This is one of those "ultimately, up to the courts"-things though. Gruber certainly has standing to bring suit if he wants to.

Disclaimer: I am a Stack Exchange employee. I have not been involved in any of the (now Common) Markdown standardization proceedings. I was aware that they were underway, having read Jeff's earlier blog posts.

There's a real difference between consumer and enterprise grade SSDs.

For comparison, for a while we nearly had a 1 to 1 dev to killed (consumer) SSD in work machines (see: http://blog.codinghorror.com/the-hot-crazy-solid-state-drive...). Granted, we did adopt them (see: http://blog.codinghorror.com/the-state-of-solid-state-hard-d...) for local dev use much earlier than we started putting them in servers.

I've killed 2 in my time here, though I do horrible big-ish data things that are either not SSD friendly or actively hostile.

That's a straight copy/paste from the Stack Overflow codebase (Helpers\SqlMapper.cs:332 at time of writing, if you care). Now the typos and snark are out there for everyone to see.

New DNS records propagating.

You could go grab the copy we put on internet archive a few weeks ago.

https://archive.org/details/stackexchange

Pretty sure we'll have this worked out with our provider before you can finish downloading though.

David means a single primary, there's a read-only replica for in DC failover and a read-only replica in our other DC for "New York is getting hit by another hurricane"-failover.

A few services hit the read replicas instead of the primary (our API, for example, moves what it can when it can), but the code for stackoverflow.com is almost entirely querying a single (quite beefy) box.

We can and do sometimes run without either replica in the AG, though we prefer not to except for scheduled maintenance.

The most common reason for someone going remote (that I'm aware of) is starting a family. New York's great, but spacious it is not.

I can think of 3 devs who have gone remote, and 2 devs (including myself) who have moved to NYC since I've been here. Most people stay wherever they were hired. The only location-specific policy I'm aware of is a cost-of-living adjustment in NYC (though that may also apply to London/SF/etc., I don't honestly know).

Technically we use Newtonsoft and Jil, Jil replacing Newtonsoft as we become increasingly confident in it.

I wouldn't suggest anyone use Jil in a production role unless you're at Stack Overflow. It's too untested at the moment, and the typical person can't get me on the horn to fix whatever just broke.

Stack Exchange has one database per-site, so Stack Overflow gets on, Super User gets one, Server Fault gets one, and so on. The schema for these is the same.

There are a few wrinkles. There is one "network wide" database which has things like login credentials, and aggregated data (mostly exposed through stackexchange.com user profiles, or APIs). Careers Stack Overflow, stackexchange.com, and Area 51 all have their own unique database schema.

All databases are MS SQL Server.

The Stack Overflow Q&A dev team has 2 people in New York, out of a team of 10 team. The Careers dev team is more New York heavy, 3 remote and 5 in New York. The sysadmin team is also quite remote, though I don't know the breakdown offhand.

I believe at this point most new technical hires are remote.

Our offices are mostly sales, Denver and London exclusively so.

That's an accurate read.

- Stack Exchange employee