Shish2k

Yes - difficulty in shipping security updates to a hundred different container images, each of which is vulnerable in their own slightly-different way because they all decided to ship an OS alongside their app - is one of the top criticisms of the docker way of doing things

Working for a few years at Facebook, and then returning to the normal world, it was like stepping back in time -- I really think that the mainstream git culture (by which I mostly mean "github") achieved a local maxima around 2012, and has been holding the industry back since :(

(Like GH finally has some support for stacks, 15 years late, with an implementation which is somehow more complicated and less powerful than the prior art...)

That's not the compliment that you think it is...

(I say this as somebody who deeply loves the concepts in most functional languages, and loves the concepts in nix, but recognises that the developer-experience of both is about as pleasant as reading somebody else's code-golfed perl)

What if you're an artist who enjoys creating your own art, but also, you need to pay rent?

Says who?

(Of my 200+ published repos, I'd say about 175 contain code I wrote purely to scratch my own itches - if other people find it useful, great! If they don't find it useful, that's also fine with me - I'm not sure why I should be obliged to go out of my way to help though?)

Why is it any of your business how I do or don't describe my repos? (Genuine question, it seems like a really weird demand to impose on other people for no particular reason)

> many developers have not learned git in depth

TBH learning git in depth was a hindrance for me learning jj - for my first few weeks I kept instinctively looking for complex solutions to simple problems and being confused, when the answer was always "use the tools you already know"

As a concrete example - git has one set of commands for managing commits, a different set of commands for managing the index, a third set of commands for managing stashes, a fourth set of commands for managing the working directory, and a fifth set of commands for managing conflicts -- in jj all of those things are a single concept with a single set of commands, equally (if not more) powerful, but also simpler

Unfortunately time and time again, the overwhelming majority of people show that they would rather deal with an unreliable scummy company for "free" than pay $1/mo for a reliable service which treats them with respect :(

"sophistication" seems like a strange way to describe GitHub to me - I've found in every individual aspect (code browsing, issue tracking, code review, package management, etc), it's the worst out of all the systems I use regularly... But it's good _enough_ for most people, and it has all those features in one place, which is more convenient than wrangling 10-15 high quality but disconnected systems

The Direct Rendering Manager is useful for any Linux user who wants to display things on a monitor (unless you're happy with like 640x480 VESA, in which case maybe you don't need it)

Some people like to have choices other than "all" and "nothing"

I would imagine RSS solves this pretty nicely? (Though personally I subscribe to project blogs for major updates; the GitHub news feed is overwhelming with information I don't care about)

None of that is anything to do with collections

Other platforms have been doing it this way for over a decade, and I've found stacked diffs (with Phabricator and Gerrit at least, not tried the GH version yet) to massively simplify my workflow o_O

I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same "each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased" workflow to GitHub has been a nightmare, how does JJ help?