Never? Never is a long time.

That said, by the time you can actually run a significant software company without any programmers it seems likely that you could also run most white collar firms with vastly fewer employees and then we're going to have bigger problems.

in the react-server package used by React Server Components (RSC).

Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).

By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).

However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.

I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.

Config should be pretty flat.

Why? I don't see any reason for that.

TOML rocks precisely because it nudges you into making simpler configs.

This is just "you're holding it wrong".

In most cases you don’t, and when you do, it’s possible and not unreasonable.

Really. Here's the first Gitlab CI example I could find:

lintDebug:
  interruptible: true
  stage: build
  script:
    - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
  artifacts:
    paths:
      - app/lint/reports/lint-results-debug.html
    expose_as: "lint-report"
    when: always

Let's see the TOML:

[lintDebug]
interruptible = true
stage = "build"
script = [
  "./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint"
]

  [lintDebug.artifacts]
  paths = [ "app/lint/reports/lint-results-debug.html" ]
  expose_as = "lint-report"
  when = "always"

Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.

IMO JSON5 is the best:

{
  lintDebug: {
    interruptible: true,
    stage: 'build',
    script: [
      './gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint',
    ],
    artifacts: {
      paths: [
        'app/lint/reports/lint-results-debug.html',
      ],
      expose_as: 'lint-report',
      when: 'always',
    },
  },
}

This is much clearer than TOML and less ambiguous than YAML. It could do without the outer {}, but overall it's still better.

After Dorsey sold Twitter to Elon Musk, selling the platform out to the far right for a crisp billion-with-a-“B” dollar payout, the FOSS community shouldered the burden – both with our labor and our wallets – of a massive exodus onto our volunteer-operated servers, especially from victims fleeing the hate speech and harassment left in the wake of the sale.

That is a very weird way of putting it. Like Mastadon et al didn't want more users? That's not at all the response I remember.

Yeah I didn't mean to imply systemd wasn't suitable for professional use, rather that shepherd is only going to be used by people who want to set this up themselves programmatically.

Like how the average computer user is never going to use Nix to install Firefox or whatever.

It's cloud based though... Not ideal. I get why they had to do that (they didn't want to expose people to the Python infra shit show) but it's still kind of a shame.

Would be better if they added Typescript support IMO.

Does it work properly on Mac yet? Or does that depend on GTK4?

Very cool but I hope they give it proper GUI integration, not just a webview or VNC, which is how the alternatives work.

The camera is used for visual odometry. They're usually black and white and very low resolution though.

Microphone, I have no idea. Could be useful for floor type detection or something? Voice control?

I just looked up Deno and it’s part of an NPM stack.

It's not. It supports NPM modules for backwards compatibility, but the whole point is that it doesn't inherit the NPM tooling mess. You can go from a new Linux install to a running Fresh project in 3 commands.

Neat hack, but IMO this just loses waaay too many features and UX that Github et al. have. Only masochists will use this. Here are a few I can think of:

1. From a user perspective it's "simpler" in that it saves maybe 1 command... git push (I've still going to want to make a branch), and clicking on the "create a PR" link. But you've also made updating a PR way more of a pain - it was git push, now it's... I dunno some long command I don't remember and looking up a PR number in the web interface?
2. Can't request reviews from people.
3. Can't enforce review requirements.
4. Can't require review comments to be resolved (I bet it's easy to miss review comments!)
5. Can't easily tell who wrote review comments. Are you really supposed to have a conversation by adding // Dave: I agree under comments?
6. Can't add comments to code that doesn't support comments (e.g. packages.json)
7. No CI integration.

I guess some of those are fixable, but overall this seems like a clever hack but very clunky.

I guess it's better than a mailing list at least.