Shog9

This is where Python's GIL bit me: I was more than familiar with how to shoot myself in the foot using threads in other languages, and careful to avoid those traps. Threads spun up only in situations where they had their own work to do and well-defined conditions for how both failure and success would be reported back to the thread that requested it, along with a pool that wouldn't exceed available resources.

Like every other language I've used this approach with, nothing bad happened - the program ran as expected and produced correct results. Unlike every other language, spreading calculations across multiple cores didn't appreciably improve performance. In some cases, it got slower.

Eventually scrapped it all, and went with an approach closer to what I'd have done with C and fork() decades ago... Which, to Python's credit, was fairly painless and worked well. But it caught me off-guard, because with asyncio for IO-bound stuff, it didn't seem like threads really have much of a purpose in Python, other than to be a tripwire for unwary and overconfident folks like myself!

I think atoav was crediting Bauhaus with the modern kitchen, with the Frankfurt Kitchen as an early success story.

Which is both fair and faintly damning, as what has been lost along the way (functional design that makes good use of limited space) was perhaps more important than the clean lines and shiny veneer which was retained.

Or maybe I'm just projecting. Been cooking on glass-topped stoves for the past few months and that tends to make me irritable.

Yes, that's why I used C++ as an example. It's very easy to create a scenario where the memory layout your logic (and your type-checker) assume exists just... doesn't. Core dumps from the field with "impossible" values, vtables missing entries, etc.

TBF, this can also be true in C++, C#, probably most languages that can interoperate with other systems not written 100% in the same language + same runtime. After a while, you just get used to not trusting anything at the boundary - types are for your convenience and your internal logic, nothing more.

Yep. If you drive around through any of these towns, upon leaving in any direction you'll encounter a mobile home park down the road just a ways, tucked into a valley or next to a railroad, somewhere the views aren't as valuable and the roads aren't as good. Inexpensive manufactured housing or RVs on tiny lots (that still cost too much to rent for what you get).

That's where you'll live if you work most jobs in the town, if you're lucky; otherwise, you'll commute a lot further - potentially over dangerous mountain roads in icy conditions. Better hope I70 stays open...

This. It didn't start with the pandemic or WFH - in the two decades I spent in Colorado, I heard similar stories from just about everyone I met who lived (or more often, used to live) in the various ski towns.

I loved living in Colorado, but during the pandemic took the opportunity to sell and move out - it was clear to me that things weren't going to get better any time soon. And for folks talking about a "crash" or "correction" - that happened to some extent after 2008; it mostly just resulted in big investors snapping up a lot of property at a discount and holding onto it until they could sell at a profit - didn't really help at all for the most housing-constrained areas.

The other advantages of buying a recipe book:

- you can take notes in the margins

- you can find your favorite recipes quickly because the pages are all stained and wrinkled

- you can reward the author for all the time they spent testing and honing those recipes

The real depressing thing here is the amount of whining about "wasted time" from folks looking for free cooking instructions on the 'Net. It's almost as bad as the "gimme teh codez" jerks on forums.

FWIW, I like this brownie recipe (and have purchased the book it comes from, twice): https://www.seriouseats.com/bravetart-glossy-fudge-brownies WARNING: contains even more words than the "love and lemons" page.

I'd argue not just outsourcing, but ensuring that nobody gets to benefit from past labor or collective effort. By constantly varying prices and tailoring prices to the time, location and even the individual, efforts to shop around to find the best price for a given item are defeated, or enough confusion is introduced to lead to exhaustion.

For the benefit of others who don't want to click an opaque video link:

> Ryan Tubridy grills Ryanair mogul, Michael O' Leary, on the multiple rumours, observations and comments surrounding the low fare airline and he certainly has some interesting things to say!

You may be misunderstanding the concern expressed on that page. A button communicates action when activated; a link communicates navigation (not necessarily "load new page", perhaps just "show new information on current screen"). Using a button for navigation or a link styled like a button for action has potential to thwart these expectations in various ways.

I'll admit, sometimes this makes some sense; you may be building an interaction that doesn't map cleanly onto either "trigger action" or "show information", and you wish to pick and choose the semantics that best fit your needs.

...But then there's the situation you allude to, where you have a button (action) and a link (navigation) and are just trying to make them look the same for consistency. Even if you pull it off visually, the chance that an end-user's client software will misinterpret what you're doing in some way and cause confusion is high.

Could be, but mostly isn't. This thread and others like it are always full of folks lamenting that some other markup language isn't as popular or well-supported or both, even though said language has more features, a better spec, and got there first.

Maybe Markdown just hit the sweet spot. But I actually suspect it's something else: as soon as it's very convenient to have machines ingesting and producing a language, it becomes tempting to create tooling that is unnecessarily strict in what it will accept while at the same time spitting out markup that is unusually difficult for humans to read. A sort of specialized violation of the Robustness Principle.

The most famous example of this was probably XHTML, but even HTML5 suffers from it. And so we end up with stuff like Markdown because HTML tooling is too hostile to work with directly, and AsciiDoc because DocBook XML is similarly awful. They don't have to be, but...

It's trivial to imagine, if you've ever worked on a car, had a "car guy" neighbor, lived near a service shop, etc. Many cars are neither quiet nor do they confine their emissions to property boundaries.

IIRC, the danger with storing lithium batteries at a low SoC is that they do have some small amount of self-discharge and can eventually drop to levels that cause severe degradation - and potentially catastrophic failure when next charged.

There is no "fix", IMHO - just as in physical societies, maintaining infrastructure takes a lot of boring work that never ends as long as people still use it.

That said... There were and are a lot of things that could make it less frustrating. Once again, we can look at physical societies: if 99% of people litter and .001% of people sweep up after them, the latter are gonna have a rough time. If we can increase the size of the latter group that'll help somewhat - but so will reducing the size of the former, and if there's less of a crushing workload then increasing the number of workers may get easier too.

Stack Overflow is entirely moderated by volunteers, and their numbers haven't exactly scaled with the volume of casual users. I find it interesting to look at how moderation changes around major holidays - especially Christmas and New Years Day: suddenly there is much less work to do, and more of it gets done - but not only done, done well! Folks are happier, more relaxed, more... Friendly and helpful.

For years, Stack Overflow's management has looked at discussions like this one and said to themselves, "those damned volunteers are making us look bad, we've gotta make their work harder so they stop screwing this up". And... It has had precisely the opposite effect: more litter, fewer sweepers == increasingly hostile interactions with those who remain to push the brooms.

I strongly suspect a campaign to encourage a bit more... Civic pride... "This site belongs to all of us, pick up after yourself", etc. Might've done more good.

The core of the problem there is that for Gregg, "this site might be helpful" is an understatement; he knows there is a good chance that it will be helpful, that there is direct relevance...

...and then there are the legions of folks who've been posting links to the first Google result with that same text for years. Those are over-selling it: sure, the link might be helpful, buuuut... Probably not. These have been the bane of many a forum, clogging up the first page or so of responses, sometimes discouraging folks with actual knowledge of the topic from even bothering to respond.

There needs to be some way of distinguishing between the two.

Yeah, this doesn't surprise me. The login system at SO is unnecessarily complex - by which I mean that the complexity of the interface does not match the complexity of the underlying system, because while both have been redesigned several times they've never been completely redesigned together.

So you end up with weird situations like this, where both the interface and the underlying system support multiple associated email addresses, but not in the same ways or with the same functionality exposed.

It is... A legacy system, with all that that entails.

Gonna clarify here, because that description is a bit misleading: this wasn't a route that allowed viewing sent emails, it was a route that allowed viewing what would be sent if a password reset was requested.

The story behind that route might be interesting... See, originally Stack Overflow didn't have passwords - all logins were done via OpenID, so any credential management you'd need to do was done through your provider (Google, LiveJournal, myOpenID, etc) This made account recovery assistance pretty simple: given a verified email address, the system would just send that address an email that reminded the owner of any and all OpenID providers that they'd associated with their account. From there, it was up to the account owner to work with a provider to do things like reset passwords.

Skip forward a few years, and Stack Overflow had its own OpenID provider - now you could sign up with an email and password just like a normal site, except really you were creating an account on https://openid.stackexchange.com/ - so the recovery process remained pretty much the same, just with a new provider that happened to be run by the same company.

So far so good... Except, this was awkward to explain to folks. Really, that was what ended up killing OpenID: folks wanted a "Google" or "Facebook" button, not a whitepaper on fancy new authentication systems.

At this point Stack Overflow decided to try to streamline the login process, making signing up and logging in with their own provider seamless: no need to know anything about OpenID. Now recovery emails started including password reset links, and also reduced or removed information on other OpenID providers that were associated with the account in an effort to reduce confusion. The decision tree for generating those emails got complex.

And the decision tree for supporting users got complex as well. Support staff got frustrated; they'd been used to knowing what would and wouldn't be in a recovery email, and had a pile of templates ready to help folks navigate login issues based on that. But now they were getting replies back from folks who were confused and upset because their recovery email didn't contain information that the support person had asserted it would!

This was the genesis of the vulnerable route: a way for support staff to ensure that they were providing accurate information to users about how they could recover their accounts. By the time of this attack, it was already obsolete; the login system had been redesigned twice since the confusing and complex system that first required it. It was vestigial and forgotten... The ideal breeding ground for vulnerabilities.

(source: I worked at Stack Overflow through the time period described in this post, and was involved in support during the period when the relevant route was useful)

One possible hitch: if you lose ALL your coolant, you might have a hard time monitoring your engine temperature, as the usual temp gauge monitors coolant temp.

Might still be fine, but... By the time you know it ain't, could easily be too late.

The choice is an illusion. Both strategies require understanding the requirements implicit in the current system. The first just assumes many of them are low-priority; this is frequently a dodgy assumption.

So, regardless of which path you take, most of your journey will be extracting requirements, writing tests, discussing priority with stakeholders. At the point where you're finally writing new code vs modifying existing, most of the journey is already behind you.

The example you picked - NYC - has by far the highest population density in the country.

This was one of the major factors cited by the article here; it would seem to lend credence to the "why".

This is where the "dying metaphor" thing comes into play: AOL was a walled garden in the sense that I outlined - like so many other early online services (and BBSs), it had walls to protect its members. That was the original sense of the metaphor.

But... That sense is dying; it is a poor metaphor because few people actually build real-world walled gardens[0][1] for that purpose; the metaphor has no currency, and thus the meaning shifts. Now it is just as frequently used to describe any sort of system which restricts the flow of people OR of information, in or out. So while Instagram might be considered a "walled garden" in the original sense (no outbound links on posts), it may ALSO be considered a "walled garden" in the sense that it restricts inbound access for non-members, or even in the sense that it forces certain onerous licensing terms on contributors. In this manner, the metaphor becomes problematic, as what one intends to convey is not necessarily the meaning which is understood by others. If/when the metaphor dies entirely, becoming an idiomatic way of saying "not completely open", this problem disappears - no one will attempt to relate people to plants, or content to flowers.

With this in mind, I suspect your original intent was focused on the "garden" aspect: that the value MO provides comes from imposing a structure and certain expectations which facilitate productive interactions like this, with the "sweet spot" being that it remains open enough for the rest of us to benefit from the outcome of those interactions.

[0]: https://solar.lowtechmagazine.com/2015/12/fruit-walls-urban-...

[1]: https://news.ycombinator.com/item?id=22395292

This is yet another one of those situations where the use of a dying metaphor[0] hurts communication; you wall up a garden to protect what is inside from the harsh conditions outside: wind, cold, vermin... The implication is that the people in the garden are delicate flowers who would be destroyed by the conditions on The Greater Internet if they were to be exposed.

The antonym to the walled garden is the open garden or field, with hardy plants able to withstand and even thrive in the local atmosphere. They're still cultivated - weeded, fertilized - but there's no need to create a microclimate to just to accommodate them.

In this context, Facebook does make some effort toward walling off their gardens, but... As you note, Facebook's primary goal isn't protecting it's dominating - Facebook is just as happy to own major portions of the 'Net in pursuit of this goal, and more than a little reluctant to provide any real protection beyond what is absolutely necessary.

Beyond that... We all garden. From little personal websites and blogs, to big community gardens[1] like Wikipedia, Reddit, Stack Overflow, and even Hacker News. We plant, we harvest, we tend these plots, alone or together, but make little effort to isolate them from the larger world - indeed, we generally recognize that the strength of the Web is based on its interconnections, its inherent ability to draw together different sources of information.

[0]: https://www.orwell.ru/library/essays/politics/english/e_poli...

[1]: https://meta.stackexchange.com/questions/349513/feedback-for...

Good cautionary note, thanks. Yes, please, anyone looking to go this route should do their research first - I'm not kidding about the tiny doses required, they sell very dilute solutions for use in very large animals; a little dog potentially needs less than a drop!

A couple relevant bits of info about MathOverflow:

- The site is operated by Stack Overflow/Exchange, but is owned by MathOverflow, Inc a non-profit corporation[0]. As such, it retains the right to exist independently of the Stack Overflow company - to my knowledge, it is the only public Stack Exchange site for which this is true.

- Like all public Stack Exchange sites, authors retain ownership of their work, which is published under a CC-BY-SA license. Regular archives are uploaded to Archive.org and can be obtained there or via Bittorrent[1]

In short, not a walled garden, and not Stack Overflow's garden.

[0]: https://meta.mathoverflow.net/questions/969/who-owns-mathove...

[1]: https://archive.org/details/stackexchange

Dog heartworm pills are a MASSIVE rip-off. The active ingredient - ivermectin - can be purchased without prescription at any farm supply shop in sufficient quantity to last several dogs' lifetimes with plenty to spare. The maintenance dosage is miniscule.

Pet prescription meds are only slightly less of a scam than human prescription meds.

Unfortunately, the exchange rate for converting slivers of dev time into hardware is... Unfavorable. And up until two days ago[0], Stack Overflow was running on fumes - shedding staff, perks, equipment to keep the ship afloat. I know of folks who spent months scrambling to get new servers before the old ones died, and... Didn't quite make it.

Given the situation, investing time into making do probably seemed like a much better bet than hoping for a windfall with which to buy equipment.

[0]: https://news.ycombinator.com/item?id=23976881

I'm sure there are better options. OTOH... I was at SO for about 9 years, and the system described existed for all of it - predating GraphQL, predating even ElasticSearch. There's stuff built on top of it that was never envisioned when it was created, and stuff that wouldn't have been possible without it.

At this point, moving to something else would likely be a far more costly investment just in terms of requirements analysis than the migration described in the blog post. Would it pay off? Maybe! But for a critical bit of infrastructure, that's something you put an awful lot of careful thought and research into before you venture to do anything... And meanwhile, that infrastructure has to be kept running.

> unless, of course it's a bug that ... is similarly rare...

I'll give an example: a bug in the revision ordering logic that could be triggered by two edits being submitted almost simultaneously where one of the editors had made another edit within the past few minutes. The bug resulted in rows being interleaved between the two revisions and the post being rendered as a combination of two unrelated edits.

Almost impossible to reproduce. Affected a low double-digit number of posts out of millions edited over the course of several years.

Was able to finally nail down the scenario by pulling logs for all editors involved in each of the events over the years and identifying the common factor.

(You can argue this is a crazy way of storing revisions, but that's beside the point; at this scale even very unlikely bugs do show up with some frequency and it is nice to be able to investigate them)

Curious what use-cases you're envisioning here.

Having worked with the system described in the past, it's quite flexible: data can be easily pulled out into more specialized systems for aggregation or trend analysis, while the raw logs remain quickly accessible over long enough periods of time to allow for digging into everything from support cases involving a single person to monitoring distributed attacks. Access can be controlled and monitored with reasonable granularity, and training new folks to use it is as easy as teaching some basic Select queries.

Not gonna suggest it's the most efficient system (if nothing else, SQLServer wastes a TON of disk space), but it minimizes complexity while deftly avoiding the choice between throwing away information when it's still needed and keeping everything in flat files which are too unwieldy to be used.

Maybe, but... Twitter actually has a mobile website. You can argue - and I would agree - that "request desktop site" should give you what you asked for, but there's still a difference between "here is the mobile web UI" and "here is a link to download an app": namely, one still allows you to use the site if you can't or won't install a native app.

Slack is actively locking folks out of their site here, a service that folks have paid for even... That is a significant departure from what folks might've seen in the recent past with mobile device detection.