It makes this variable usable only when set to true, which is not how environment variables should be used.
All command-line software which outputs text with ANSI color added should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color.
So it’s not “true”, it’s any value. As far as I understand empty string would do too.
One can easily remove variable from environment, and check for existence is simple and unambiguous.
How environment variables should be used for boolean data instead of this? Or you mean that environment variables are not designed for boolean data?
It’s interesting how the HTTP protocol specifications are ignored by nearly everyone. I’ve never seen any 451, just 404.
Try browsing a US newspaper site from the EU. Many use 451 to passive-aggressively protest against GDPR requirements.
It was approved by the IESG on December 18, 2015. It was published as RFC 7725 in February 2016.
It’s pretty recent so I’m not surprised it’s not widely picked up yet.
Also, 404 isn’t wrong in these cases, 451 is just more specific. Usually telling “this thing is not there” is easier than also figuring out the reason why.
What about the case when the resource is publically available, but not for the requester for legal reasons (e.g. being in a European country)? In that case, does the 404 status still make sense?
No, but I wasn’t thinking about that case, as parent mentioned 404 (I actually did, but quite a bit later after I wrote that comment). In absence of 451, 403 would be suitable in situation you mentioned, but 451 is much less ambiguous for these cases.
I’ve been running Yggdrasil on seven boxen for the past two months, and it’s been running flawlessly from what I can tell.
Yggdrasil is way easier to build than cjdns, and to peer with other nodes all you need is an IP address and a port number. You can literally have Yggdrasil up and running in less than half an hour. And Yggradrasil nodes on a LAN will auto-discover each other (like cjdns with the beacon activated).
I’ve been using it for a while, and I have to say, for alpha it’s really good at just working consistently well without any crashes and similar issues. At least for me, I’ve heard someone had crashes, though that was fixed, apparently.
Tunneling over tor, and even i2p works without problems (other than slowing things down, especially in case of i2p).
Totally unlike my experience with cjdns, which, when I tested it, consistently kept dying at least few times a day, and had other issues, like weird 2 process model and when I sigterm master it leaves child running (so not good for daemontools), no support for tcp (so any kind of tunneling required ugly hacks which didn’t work well), requirement of nodejs just to build it… Maybe my experience is outdated, as it’s been more than year now, but all of it just left bad taste. Oh yeah, this isn’t about cjdns.
Community is okay, developers are friendly and reasonable people, I’ve contributed some improvements for things I cared about, and they’ve been accepted.
Overall, my experience is largely positive.
ive been running Yggdrasil from the start, its freakishly stable for something only in alpha.
Developers are very organized and helpful and listen to users, documentation is also amazing.
They keep adding well thought out features.
There is a good community developing around with lots of little projects to boot.
If you have not tried it, i highly recommend and you can find the devs in irc, more info on their website.
This is what the network currently looks like as of this post:
It’s a royalty-free format with an open-source reference implementation, surprisingly.
Now the question is how it compares with other royalty-free formats that have been around longer (namely AVIF).
On lossless side, it looks better than other stuff for the most part, at least looking at https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/ which isn’t very surprising considering that that part of JXL came from FLIF/FUIF research.
On lossy side, if given enough bitrate, it’s more accurate than AVIF, though filtering AVIF does really helps it in low bitrate scenarios. I wouldn’t say that comparision with that is entirely fair considering AVIF encoding time though. Also features aren’t the same (AVIF can only encode in YUV colorspace, no progressive decoding).