(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)
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)
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)
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?
JJ, Gerrit, codebutler, and I think a couple of others have all basically agreed upon a syntax for change IDs and they are converging their prior ad-hoc formats into one; but last time I checked, the request to the upstream git team of "please don't silently drop the change-id header during rebase or amend" was met with bike-shedding about all the other hypothetical benefits that alternative formats could hypothetically provide, so universal support for the header as used in practice today is still missing D:
(I would love to be proven wrong if there's been some progress that I didn't get the memo about ^^)
Funnily enough the two features that I've missed from phabricator are Stacked Diffs and the per-user opt-in whimsy mode, maybe GitHub can copy the latter next? :D
A couple of days ago I split a single class which did 5 barely-connected things, where each of the 5 entry points had another 5-10 private helper methods (none of which were shared between entry points), into 5 separate classes which each do one thing - total number of lines went up (because they all have the same boilerplate import statements at the top), but being able to focus on one entry point and it's helpers at a time has made things much easier to work with
I'm am curious how you used satisfactory trains - I always found the satisfactory stations to be so overwhelmingly huge that they basically didn't fit anywhere (unless I build a layer of foundations a couple of hundred feet in the sky, which feels like cheating)
Followed the app's instructions to go to gate 15, sat there waiting for the gate to open, until eventually getting a notification that I'd missed the flight from gate 30. Went to the help desk, was told that since I was the only person who made that mistake it was clearly my fault rather than the app (which was still displaying the wrong gate, even while I was at the help desk). Got booked on a $400 replacement flight for a journey which was originally $50. In the queue to board the replacement flight, I meet around 20 other people who missed the same flight for the same reason, all being told "it's clearly your own fault, ryanair has no responsibility here"...
People within Meta have been campaigning for this for _years_; even people as high up as John Carmack were pushing for open bootloaders on deprecated hardware (and he achieved that on the Go headset, but not as a general policy)
> It is sad that it takes a Meta developer having some fun to realize they should open up ADB.
I'm not even sure if the motivation is as positive as that - the video, blog, and dev docs read more like a sales pitch for meta's AI tools...
(I'm glad they did it, the portal is great hardware; but I don't expect that this will be a pattern of opening up old hardware unless it provides tangible benefits to the AI department)
javascript uses floats as its own default numeric data type; but other languages do have integers, and might want to convert those integers into a JSON (string) representation
FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)
Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend.
FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3
In the circles where I hang out I think community opinion is that go is _fine_, but python has faster iteration speed for experiments, and rust has better correctness and performance for production, so there's less excitement around it
Facebook started out PHP; but they ship-of-theseus'ed it into Hack by replacing the standard library, the language, and the runtime engine, so now it's a totally different thing with only a few superficial similarities (FWIW IMO Hack is much better than PHP, I'm sad that it never gained traction...)