ddevault

ISO standards are not standards. Closed standards are not standards. Implementations are not a standard. This is a bad joke.

> If that's the intention you can update your original comment to say the "open" standard, because your definition of standard is not universal. And then I would have instantly agreed because I've experienced this firsthand.

No. A closed standard is not a standard.

> Besides from that technicality though, do you really think that publicly available standards would have changed the situation? I don't think so---Chrome (and to be clear, most other browsers) has supported tons of closed standards anyway.

I think it might have helped, yes.

I'm going to say this as politely as I am able: closed standards can eat a big, steaming plate of shit. If it's not open, it doesn't exist. Period.

Have you actually tried to read them? They don't exist.

https://jpeg.org/jpegxl/

https://jpeg.org/jpegxl/documentation.html

All we have is a whitepaper.

JXL had this coming. They should have written specifications. The implementation can never be the standard. I hope everyone watching this learns from their mistake.

No?

We are incredibly far away from objects like this, so the apparent movement is negligible.

Squashing isn't the problem. What you should be doing is trying to make each commit the smallest possible atomic unit of change. Rebase is a useful tool for achieving this -- squashing, splitting, whatever. git add/commit -p also good for this.

It draws from the (growing in popularity) approach of tagged unions/result types among many languages, but generalizes it a bit and makes it easier to use in an ad-hoc manner.

Hare is available in nixpkgs to the best of my knowledge.

You probably want to use another language. Hare does not aim to support every use-case, but instead seeks to thrive in its niche. But I would also recommend giving Hare a shot and not writing it off because it lacks generics -- you can do a lot with it regardless.

There might be a need for these ideas, sure. They're worth exploring. But it's a bet, or a gamble: they're exploring novel territory. Hare aims to distill proven ideas into a simple package which represents the best approach as of $CURRENTYEAR, then use it to build a platform which will be stable for as long as possible. It might not be perfect -- the next language can improve on it, or maybe one of Hare's contemporaries will succeed -- but it will be dependable, and that's a trait worth optimizing for in at least one language.

git bisect imo relies on having good commit discipline to be as useful as possible, so many novice git users will not find it useful (identifying the bad commit among "fix thing" "add stuff" "aasdfasdfljser", all of which are +1000/-1000, is not going to help with much).

git has a lot of stuff, even the experienced can find something new. Have you heard of git bisect yet?

The simplest system uses the fewest moving parts to accomplish the goal. Some of Arch's ideas, like PKGBUILDs, are pretty simple. But ultimately Arch is just another typical mainstream Linux distribution with glibc, GNU coreutils, systemd, PAM, etc. These tools are all severely bloated and over-complex, and many simpler alternatives exist which solve the same problems with much less.

As for "small", well, it varies, but Arch systems tend to bloat more with time as the system does not provide much for auditing and cleaning up your system, so the older an arch install gets, the more garbage it accumulates. Arch also tends to turn on as many options as possible for each of the things it packages, so many packages have a lot of optional dependencies made mandatory. This is not a unique problem to Arch; only Gentoo (and maybe Nix and friends) solve this one, and they have many other problems to contend with.

All of this is not to say that Arch is necessarily a poor choice. It's just not simple, nor small.

Well, great documentation with the caveat that good upstream documentation is always preferable to the Arch wiki.

Small? No. Simple? No. Great documentation? Yes.

It's much easier if your first step is to write a grammar for your DSL.

Transferring money from suckers to LO.

Man, fuck this.

No one was upset that he donated from his own money. It was never portrayed as a breach of fiduciary duty. What upset people is that he's a homophobe. No one wanted to work for him, have the fruits of their labor used to undermine theirs or their friends' human rights, or use software stewarded by a homophobic leader.

Here's a few large/largeish projects I find interesting, in no particular order:

https://sr.ht/~mil/sxmo/

https://sr.ht/~thestr4ng3r/chiaki/

https://sr.ht/~alextee/zrythm/

https://sr.ht/~eliasnaur/gio/

https://sr.ht/~mil/mepo/

https://sr.ht/~etalab/code.gouv.fr/

Feel free to browse more here:

https://sr.ht/projects

Colocated on owned hardware.

>Those probably eliminate this problem for logged-in users—but I’m not one of them, so(?) I don’t see any!

These were intentionally removed for logged-out users because they can be a bit confusing -- many users would look at, say, a git repo, and think that the lists link would take them to that project's mailing lists. This is a long-understood problem that we expect to be able to solve within several weeks -- briefly mentioned in the OP.

> A somewhat related complaint is that the git.sr.ht page for a project (that I’m most likely to remember, because they’re in my git remotes) don’t link back to the sr.ht page for it with the ML and CI and perhaps sibling repos (that I can in the common case reach by simply editing the domain of the URL—once I remember it exists). I wouldn’t be surprised if most people unfamilliar with Sourcehut, when visiting a git.sr.ht link, thought the repo on it was all there was (especially given it would be true on GitHub).

Same basic problem, same planned solution, same priority.

Thanks :)

Non-commercial OSS projects is a contradiction in terms.

Plan 9 is mostly useful for research interest, not as production infrastructure.

No, there are authentication pieces in place that I did not go into in this article.

Yeah, you could do that, but it's a bit magic innit?

The ctl file also lets you control other connection settings, such as keep alive. It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal.