- mtndew4brkfstGitHub has never allowed public repos to disable PRs in particular. There's no setting for that.
- One foundational misunderstanding in your very first bullet - Universal Blue distros are installable operating systems that happen to use container image formats as a file representation for network distribution and update mechanisms, but you're expected to be running it on actual hardware or as a traditional VM. The outermost "container" part is largely an incidental implementation detail. You don't run these as a workload on like, a Kube cluster, or anything like that.
The underlying project in question for the next conceptual layer down is rpm-ostree:
- Here's one from 2002: https://meyerweb.com/eric/comment/chech.html
- It's literally impossible for open source development to be an asocial or apolitical endeavor.
- "LWN.net is a reader-supported news site dedicated to producing the best coverage from within the Linux and free software development communities."
FOSS beyond Linux itself is still explicitly on-topic by the site's own self-description.
But we all know what this was about anyway. Good luck to you out there.
- Why does her hair color matter to you? Why is open source longevity and viability not on-topic for LWN discussion?
Dr Foster holds a PhD, did her dissertation about the Linux kernel, and has had a respectably long career in technology with a focus on open source and governance. The topic is literally straight in her professional wheelhouse.
- In an ideal world, yes, my belief is that that produces the best results.
- Very very much so. The project also includes separate binary releases with this feature compiled out altogether, but I'd much rather this sort of feature was never ideated or acted upon in this first place.
Generally speaking I don't want a terminal multiplexer to be doing network IO of any sort, so I also didn't love it when they shipped "load WASM plugins from a non-checksummed arbitrary URL via your config file" in a previous release.
- As with my comment in another tree, no, none of the Elixir core team or Dashbit employees are directly involved with this effort, though they may be advising informally and will likely submit a PR here and there.
https://dashbit.co/#team https://elixir-lang.org/development.html#team https://github.com/elixir-lang/expert/graphs/contributors
- I would say there's an ocean of software with better UX than those two, so it all comes down to what axis you measure on.
- Nit: there has never been an official LSP implementation until now, only community-authored. Even now no Dashbit employees or language core members are directly involved in this project in an ongoing basis.
IMO that contributes powerfully to the quality of the experiences of using any of the options.
- It has both a justfile and a makefile at the root, even. Most of us seem to want to use it to throw make away entirely.
That said, I consider `just` very language-agnostic and useful because of that, and I consider mix pretty bad at any workflow needs that isn't directly concerned with BEAM.
- It's unkind to publicly speculate on this in this particular way, IMO.
- API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.
- IMO in the 12 months or so I've been aware of the BABLR work and observed the author's comment contributions, they've never really substantiated why BABLR would be preferable to tree-sitter, or how a JS-based implementation of parser tech can fulfill any of the same niches. Most consumers of tree-sitter leverage it via FFI or native code, not an embedded or external JS runtime.
It's not clear to me how you could substantially replace the capabilities/benefits of what LSP provides with BABLR either.
- Nothing since then really recaptured what I personally liked about GWave or let me use their tool in similar ways to how I used it. YMMV, of course, more so than most of my comments.
- It is, however, a commit object per change because of how jj tracks the evolution of commits. Those intermediate/ephemeral commits will not be able to be GC'd from git object storage until they are either abandoned in jj or are removed from the jj op log. The latter of which AFAIK does not happen automatically, not even on a time/age basis.
I am an extremely fervent believer in jj and use it exclusively since December '24, but I think it's useful to be accurate as possible for these kinds of trade offs. I don't use watchman snapshots specifically because of this downside.
- This is my impression - if you explicitly don't want to use toolbox or devcontainers I don't think you're on Bluefin's happy path at all, and the maintainers don't seem concerned enough by that to improve other experiences.
- With the limited sample set of previous writing about this tooling - my impression is that it seems impossible to offer a succinct but still compelling description of this particular dialect of Rust.
There are thousands of words of prose to describe it between this and the shell-scripting post, and a lot of code-level seams and abstractions introduced in the snippets. Yet I still can't tell you why I should want to do the new things that this code style would make possible for me to do.
I also probably wouldn't enjoy trying to onboard a new contributor to a hypothetical project using this style, no matter how experienced with Rust they might be. DSLs, which I would consider CGP to be one, have a pretty high friction rate if they haven't become dominant/widespread.