Maybe my needs just aren't that exotic? I'm currently using daemontools at work and so far I have a slightly unfortunate handful of bash scripts that repeat in different projects with minor variations.
I've also used launchd (OSX) for Serious Things That I Don't Want to Fail, and it was easy. One config file with a few details. Completely watertight abstraction, as far as I could tell.
Pretty much all of the new school init systems, loosely starting from 2004 onwards (Upstart, launchd, Solaris SMF, systemd) have glaring structural deficiencies in one way or another, from my observations.
I'd argue that the DJB ecosystem has an almost-zero learning curve if you have a decent grasp on your systems fundamentals. As long as you understand how process handling works, the administrivia of DJB's tools is dirt simple.
It also has the odd benefit of already being cross-platform, so even if you move whole systems distributions (e.g., from Debian GNU/Linux to FreeBSD), you can still use that same knowledge there too.
Edit: Note that simple does not imply easy. Daemontools, for example, does not provide a means for doing dependency handling, so you'll actually have to engineer around that by writing a script to handle it. Same goes for bouncing things that go off the rails. Same goes for pretty much anything that does not fall strictly under the purview of starting a process and restarting it if it crashes.
I understand it is impossible to make these things fit in a proper relational model. For instance, modeling dates when artworks are made circa a date, between 2 dates, started by someone and finished by someone else, is very complex. That said, they should at least try. Being able to sort artworks by date seems pretty fundamental to me!
Look at the data released by the Cooper-Hewitt that someone posted below. They actually have some kind of structure!
There are some academics who study functional fixedness in literature under the name "Thing Theory". In particular, Raymond Malewitz has a book of examples of "creative misuse" in recent American lit. Some of his examples (Fight Club, No Country for Old Men) are noted for their anti-capitalist or anti-consumerist slant, while others (Apollo 13, McGuyver) have more of a quasi-military aspect to them.
I'm also reminded of British architecture critic Reyner Banham's essay "The Great Gizmo" about examples of American technology that are meant for retrofitting and composition more than entirely new things. The outboard motor, for example, as opposed to designing a new boat.
And also Olia Lialina has an essay "Turing-Complete User" about very similar themes in today's software.
The thing that GitHub has right now is the userbase - the network effect keeps people interested in their service. The technical value they provide is pretty trivially replicable (see: GitLab, BitBucket), but you can't code up a (real) community.
It's worth noting that 10 years ago, this same statement was true of Sourceforge.
gitlab and bitbucket aren't as good, I've tried them and more.
GitHub isn't a commodity that excels only because of it happening to be popular. People choose GitHub because it's both popular and good. It has competition, some of which are better for specific circumstances, but as a whole they don't execute as well.
Let me contrast with Facebook – it was only good, in my opinion, for a brief period starting in 2005 which happened to coincide with my freshman year of university. As it grew and changed, I found myself and very many of my peers hating each significant change. The only reason I've kept an account is because it's popular – it stores some weak social connections which would be otherwise lost.
And bitbucket has unlimited private repos for free compared to github's limited number for a fee. I moved my lab repos to bitbucket when we outgrew 10 private repos. It was going to be quite expensive to add more at GitHub.
(Most of out repos are public but some things you want to keep private at first.)
Bitbucket is not as good? Feature-wise they're almost identical.... I use github for my FOSS projects and bitbucket for stuff that shouldn't be public, like for-profit soft and side-projects. If you don't see added value in free unlimited private repos that's not the case for many of us.
I like Github best, but will readily admit it's mostly just because I'm most used to it. Like you I use both, with Bitbucket for my private stuff and Github for the public stuff. The latter mostly because that's where people are.
The point is the nature of git means I don't really need any of them. They're convenient as a public dumping ground (Github) or "backup" (Bitbucket) with a decent web ui, but if they disappeared it'd make very little practical difference for me (other than recruiters having to find me via another site).
GitHub's enterprise grade services and their integration with 3rd party and on-site solutions is currently above what anyone else provides.
It's way above being a simple repository storage which isn't a trivial think to setup to begin with just watch the various talks from BitBucket's core team.
As long as everyone else has to play catch up they will be fine. And i don't see sourceforge as being comparable unless you just look at a project hosting in it's most basic form in which Google Drive or Dropbox can also fit in that category.
a diff I see missing from bitbucket is the visualization - heat graphs/maps of my activity on a project or across projects. I know it wasn't there early on, but I've known more than a few people that keep committing to a project on a daily basis because they can keep their streak going on the visual chart (on github).
It's not really one particular feature, but a whole mess of little things that, collectively, will keep github 'default choice' for a lot of folks for a long time coming - it's inherently a bit more 'social'.
That said, I'm in agreement with your view that most other services have most of the main same features anyway - I prefer bitbucket for my projects, but... I'm in a minority. This sort of feels like MS Office vs OpenOffice 15 years ago. Yeah, technically there's a lot of the same stuff, but there's enough 'missing' features from multiple users' perspectives that the larger player still 'wins'.
From the linked PDF report: "Nominal orbit: Halo orbit about the Sun-Earth L2 point."
The linked report also answers the "why there" question I immediately had.
> The HDST spacecraft and its operations will likely share many commonalities with the JWST architecture and operations. For HDST, as for JWST, an L2 halo orbit is preferable to a geosynchronous orbit (and most others, including low-earth orbit), because it is thermally stable and has lower fuel requirements for station-keeping