eslaught

How many people here are commenting based on their kids' experiences and not based on their own? Nothing in a 4 year-old trend (or whatever it is at this point) is going to be anticipated by people who were that age 10, 20, 30 years ago. (Sorry folks.)

My kids are just short of this age, so this article is very topical for me. I'm trying to encourage them to read, and they do, but it's also been difficult (in my experience) to make the transition to "big" books (i.e., anything other than a graphic novel). Books that I am 99% sure I read by their age, they don't seem to be responding to---and not just those books specifically, but anything in that class. And my kids have very low screen time.

The entire point is that crash recovery fails because you rarely test it. By making it the one and only code path, by definition, you will be testing it all the time, so it is much more likely to work in the first place.

(The obvious counterargument being that if there are different ways in which the software can crash, this is still not an adequate defense.)

Answering my own question....

I grew up in Davis, CA and then spent 4 years in San Diego as an adult before moving to the Bay Area. The biggest shock was how unhappy everyone seems to be here. I don't think Davis and San Diego residents are especially happy, but there was a very noticeable difference even just walking around on the streets in the Bay Area; there are a lot of people who seem to be down or depressed or upset a lot of the time.

The other thing that shocked me was the disparity in housing here. In Davis, some houses are bigger and some are smaller but the quality is (usually) relatively uniform. In a lot of Bay Area cities like Palo Alto and Menlo Park, you'll have neighborhoods with these obviously built-up, luxury single family homes, right next to houses that are literally falling apart to the point of probably being unsafe to live in. That was a shock by itself, but then the average quality is probably worse... I guess people here can't pay to repair their homes. Meanwhile, you can walk a couple blocks in some directions and be in the middle of gigantic mansions with gates and big hedges and the works. It's surreal.

The driving culture in the Bay Area is also unique (and not in a good way), but I'm guessing most people know that already.

On the positive side, the food here is unparalleled, especially in contrast to small-town Davis, where literally all of my favorite restaurants have closed. That town seems to struggle to keep its food scene alive, unfortunately.

All of this to say: I wonder how much people who get an impression of "California" are really responding to the particulars of the Bay Area culture specifically, and probably don't ever experience anything else.

As a Californian I'd be curious what culture shock you experience coming here.

I wish I had gotten to the comment section earlier because the top-level summary of this article is simply incorrect.

The majority of the revenue of the Big 5 publishers may come from celebrities and repeat best-sellers. But the majority of the profit comes from the un-anticipated best sellers: books that the publishers offer low advances but end up going on to vastly out-sell expectations. While some of those books may have ended up in the "anticipated top selling books" category identified in the trial, the point is that their eventual sales are vastly greater than anticipated, for whatever level was offered.

This means that the rest of their publishing business is absolutely not a "vanity project": it is the business of publishing itself. The reason why these publishers have a backlist (older books that earn a profit long after release) is because of the unanticipated best-sellers. The trial data makes it very clear that publishers (and authors) are actually better at pricing the very high-end books and therefore the profits are typically less (because authors have more leverage to get a fair price in their initial negotiations).

So TL;DR: publishers hope to find promising, but under-rated, authors who may potentially go on to become best-sellers. They continue to fund the books of such authors (despite generally not making a profit) because the few that do fund the rest of the business. But (ironically) once such authors are actually established as best-selling franchise authors, those very same authors' ability to negotiate drives profit margins down, which drives the endless search for fresh talent in the publishing industry.

I feel like I finally need to complete my own analysis of the trial results, because I don't think this is well understood.

> value prop of a BMW made between 1975 and 2005

I'd be curious for someone to explain what this is, and what happened in 2005 that changed this.

> books not recouping their advances

This is in fact a feature, not a bug.

Traditional publishers consider a book to be a "success" when it has recouped about 70% of its advance. Publishers prefer this situation because advances are a fixed cost and by holding down royalties (which they essentially refuse to negotiate on except with the most successful authors), they earn big money on the few books with low advances that do really, really well.

This means that authors have an incentive to negotiate as large an advance as possible; so from an author's perspective, if you have earned out your advance, it means you have failed to capture as much value from your book as you could have (and/or, you are a runaway best-seller, so you will presumably negotiate better the next time).

Source: CEO testimony from the trial transcripts in the antitrust case against the merger of Peguin Random House and Simon & Schuster. Available here if you're interested (disclosure: I have no interest in Publisher's Lunch, and the transcripts may also be available publically): https://shop.publishersmarketplace.com/

Edit: it is funny to see in the trial that some authors and agents clearly do not understand this, even with having it being explained by the CEOs of publishing companies earlier in the very same trial.

Has anyone done anything like this for historical time periods? I realize the data is inherently sparse, but I'd be curious to see what the results would look like in 1900, 1800, 1700, 1600, etc.

My impression of the data is that, actually, we're doing pretty well with social mobility. Not perfectly by any means, and there is lots of room to improve. But as compared to (I think) just about any historical period, I think the graphs would be even more skewed. I'm fairly certain that as a medieval peasant, there were basically no viable routes to improving your lot (and even the word "lot" betrays the assumptions of the time), and so acceptance was the only viable route (violent rebellions excepted).

Looks like no one answered this question from the last time around:

https://news.ycombinator.com/item?id=24492646

I had my own "oh shit" moment in my PhD, which I wrote about among other things, here:

https://elliottslaughter.com/2024/02/legion-paper-history

I'll just add one more comment: it's entirely possible to feel like everything you're doing is worthless, when in fact you are on the brink of accomplishing something worthwhile. That's not to say that every research project is worthwhile, but "how I feel right now" is maybe not the best indicator of how you are actually doing.

I believe I got my original GitHub invite from another HN user, back in the days when it was still invite-only. I confess at the time I didn't really "get it", despite having played with Darcs and the like prior to this.

But (in retrospect), I don't think it's really that complicated. SourceForge, back in the day, had a really atrocious UI. As a highschooler navigating CVS and SVN repos for the first time, it was really difficult to figure out how to even download source code (this was especially horrific with CVS on Windows), let alone contribute in any meaningful way. Discussion on these sites required you to sign up for a mailing list. I think Gmail was just barely a thing, but prior to that as a student I would have been stuck with some awful Hotmail account or similar. Anyway, the hurdles were high and therefore this selected for "serious" contributions (or people willing to put up with a lot of obstacles). SourceForge may have supported some sort of bug tracker, but I don't remember ever interacting with a project that used it, so in practice people were splitting their various components (code, mailing lists, bug tracker) between several different sites.

Ignore Git for a minute. GitHub, if nothing else, had a really slick UI. That UI put code front and center, so it was (finally!) obvious what sort of project you were actually looking at. I think it can't be underestimated how much this uniformity makes code easier to browse, as compared to the vast gulf in difference in quality between the best and worse homepages of open source projects prior to this.

For fun, here's one that I authored back in the day. The home page here is actually kind of informative, but you can see how if this is all you get, the results are going to be all over the place:

https://ip-interfaces.common-lisp.dev/

Beyond this, GitHub offered a permissionless collaboration. In the bad old days of open source, I could clone a repository, and I could write patches, but the cost of setting up forks was prohibitive. This is one of the things I didn't "get" at the time, but GitHub made it practically (and socially) acceptable to just fork whatever you needed, change something, and submit it. Or not, it didn't matter. Whether you intended for your experiments to be useful to anyone else or not, it dramatically lowered the cost of starting and maintaining those experiments. And that I think dramatically changed the face of open source software (for the better).

I've been writing a profiler in egui, and so far have been very happy with it. Comes with the nice bonus that I get both native and web UIs:

https://legion.stanford.edu/prof-viewer/?url=https://sapling...

I work on a distributed runtime system for heterogeneous supercomputers [1].

As an example of the sort of bug we regularly deal with, I am at this exact moment tracking down a freeze that occurs on 8,192 nodes of a supercomputer [2]. That means I'm using about 64,000 GPUs and about half a million CPU cores. The smallest node count I've seen my issue is 2,048 nodes and at that scale it only happens about 10% of the time.

We've been debating internally whether Antithesis could help us or not. On the one hand, the fuzzing to explore the state space, and deterministic reproduction, are exactly what we want. On the other hand, we believe our state space is much larger than what you see in a typical distributed database. (And not just because of the sheer scale of things, but even on a single node we have state machines with order hundreds to thousands of states in them.) Based on the post here and the "scenario" count explored in CouchDB, I'm not convinced you'd be able to handle us. :-)

I'd be curious what you think. Happy to discuss here, or contact info in profile.

[1]: https://legion.stanford.edu/

[2]: https://www.olcf.ornl.gov/frontier/

What you've identified is known as Gustafson's Law. If you can keep solving larger and larger problems, your solution time doesn't necessarily go down, but "speedup" is potentially uncapped.

Of course there may be some practical limit to Gustafson's Law, but I don't think we've found it yet, at least in many scientific domains.

The Wiki article has a brief summary of the history, but basically the original author wanted to transfer responsibility for the user-facing maintenance to someone else, who started seeking donations and (I believe) taking payment for "acceptable ads" and the like.

https://en.wikipedia.org/wiki/UBlock_Origin#uBlock

There's more going on here. They are adding a notion of "places" (what I would call "field paths") and an explicit syntax for "modes" (what I would call "privileges"). So you can now say:

    shared(x.a.b.c)

or:

    mut(y.d.e.f)

That makes it possible to pass around a reference with the promise that the callee will only access a subset of the fields of whatever referenced type you're talking about, as well as other things.

Superficially it looks very much like what I did in Regent [1] though I am sure the details differ widely.

[1]: https://regent-lang.org/tutorial/06_privileges/

On the contrary, I thought it was quite apt. If you follow the article's link to this Stack Overflow answer:

https://stackoverflow.com/a/15140227/1614219

Which summarizes a discussion by the C++ standards committee to reject the C++ version of Rc, and one of the main arguments is the risk of Rc code being accidentally included in threaded code.

I would point out that this code can include: code you wrote years ago that you forgot includes Rc, code in libraries that was modified internally to use Rc and the authors forgot to mention it, code written by colleagues who aren't familiar with the pitfalls, etc. That's why this isn't a trivial problem to solve.

Music is the perfect counterexample to what you're saying. It's the only remaining digital platform where it's still possible to buy legal, DRM-free copies of digital files, which you can download to your own machine and thus ensure you retain access.

Ebooks, audiobooks, movies, games all work like you say. (Less so with games, at least there are alternatives like GOG. But mainstream games are by and large not available without DRM.) Even podcasts are going that direction. But music, somehow, inexplicably, remains DRM-free even with all the mainstream labels.

I thought the point was that they would intentionally seed the audience with one or a couple of people who would storm out in (apparent) anger (if none of the actual audience members got to it first), and thus the music is the experience of the audience reaction to the piece.

> How is that different from cars that project information on the windshield?

Are there any cars like that?

At any rate, for such cars to receive regulatory approval, they would need to be vetted to ensure that the UI elements don't exacerbate blind spots or hide critical pieces of the road, etc. The Apple UI is not designed with that in mind and may not give any such guarantees, and even if it were, it's still possible to abuse. There is also a formal process for removing such cars from the road if it turns out that they don't function as expected; whereas chasing down Apple Pro Vision users is left to the relevant highway patrol units.

Even if, in theory, the Apple device could be used safely, what happens in practice is far more important than theoretical use cases.

I'd just use Pandoc Markdown.

For simple things, you can easily write Markdown that is compatible with all dialects. Mainly, remember to indent your lists 4 spaces if you soft wrap.

But Pandoc Markdown has the most extensive support for other extensions, like footnotes, figures, etc. That's useful because it minimizes how much HTML or Latex you need to write, which in turn makes your documents more portable.

There are other formats that support more features, but in my experience the communities are smaller and the syntax is not as pretty. Ultimately you're betting on that format continuing to exist longer than Pandoc, which I think is not a great bet in most cases. The only format which I think might have better long-term support and compatibility is CommonMark, but it comes at the tradeoff of substantially fewer features. Which again means sacrificing portability because everything you can't do in the base language you need to do in HTML or Latex.

Ok, but you have to view this through the lens of what was on the market at the time and what kind of expectations Intel likely would have had. I can't imagine that Apple told Intel what they were planning. Therefore, it would have been reasonable to look around at the state of what existed at the time (basically, iPods, flip phones, and the various struggling efforts that were trying to become smartphones at the time) and conclude that none of that was going to amount to anything big.

I'm pretty sure most people here panned the iPhone after it came out, so it's not as if anyone would have predicted it prior to even being told it existed.

I agree mobile was a miss but the linked article actually quotes Intel's former COE making a pretty good argument why they missed:

> "The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do... At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn't see it. It wasn't one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought."

In that circumstance, I think most people would have made the same decision.

It depends. As an intern, working an extra hour to get free dinner and a bus ride home was absolutely worth it. But it's not as if they were forcing people to stay (for either the work or the food). My experience was that people with families generally didn't stay, which absolutely makes sense given their different priorities and life situation.

> ... as it didn't kill off the fashion industry.

Clothes are inherently consumable goods. If you use them, they will wear out. If you do not use them, they still age over time. You cannot "copy" a piece of clothing without a truly astonishing amount of effort. Both the processes, and the materials, may be difficult or impossible to imitate without a very large investment of effort.

Compare this to digital art: You can copy it literally for free. Before AI, at least you had to copy it mostly verbatim (modulo some relatively boring transforms, like up/down-scaling, etc.). That limited artist's incomes, but not their future works. But in a post-AI world, you can suck in an artist's life's work, and generate an unlimited number of copycats. Right now, the quality of those might be insufficient to be true replacements, but it's not hard to imagine we'll be in a world not so far off when it will be sufficient, and then artists will be truly screwed.

Isn't PyPy up to 3.10 by now? At least that's what Homebrew reports to me.

PyPy seems pretty alive, all things considered, and for my code bases I've seen pretty dramatic speedups on the order of 2-5x. That's basically a no brainer unless I'm doing something with incompatible C extensions, which I think is the real Achilles heel of all of these alternative implementations.

I totally get that.

I'm just one person, but for me, this was the feature that made me switch to a minimalist text editor for writing.

Otherwise, why not stick with Emacs? Plain text with light syntax highlighting is something Emacs already does fine, it's relatively distraction free, it has keyboard shortcuts I've already memorized forward and backwards.... The biggest downside is that I have to pop over to another window to get proper syntax rendering and to be 100% sure it's parsing the way I expect.

Anyway, just my two cents. I could totally understand it not being worth the effort to implement, but when it works, it's really nice.

Fair enough. Thanks for the response!

Since the author seems to be in the comments, have you ever considered implementing a Typora-style live preview? (Typora, for those who don't know, hides the Markdown formatting as you type, and shows it again when you move the cursor back onto the text.)

Paper appears to have a more traditional split between text mode and preview mode, and you can't properly edit the formatting in preview mode (e.g., you cannot turn a heading back into normal text from preview mode).

I'm sure it's a pain to implement, but it's the one really killer feature of Typora that I can't live without.