HN user

colonwqbang

2,261 karma

HackerSmacker profile: https://www.hackersmacker.org/user/colonwqbang?hs=Qv7V6ExW035thvyjNI

Posts1
Comments599
View on HN
XML is a cheap DSL 4 months ago

I didn't say that json can represent all rational numbers. I said that all json numbers have an obvious interpretation as a rational number.

So far you haven't really shown an example of a json number which has an ambiguous or ill defined interpretation.

Maybe you mean that json numbers may not fit into 32 bit integers or double floats. That's certainly true but I don't see it as a deficiency in the standard. There is no limit on the size of strings in json, so why have a limit on numbers?

XML is a cheap DSL 4 months ago

How do you feel numbers are ill defined in json? The syntactical definition is clear and seems to yield a unique and obvious interpretation of json numbers as mathematical rational numbers.

A given programming language may not have a built in representation for rational numbers in general. That isn't the fault of json.

Has nothing to do with go. You added a dependency which is not portable. It is well known that systemd project only targets Linux.

Vendorise systemd and compile only the journal parts, if they are portable and can be isolated from the rest. Otherwise just shell out to journalctl.

Your post could be (uncharitably) paraphrased as: "once you have written correct C++ code, the drawbacks of C++ are not relevant". That is true, and the same is true of C. But it's not really a counterargument to Rust. It doesn't much help those us who have to deliver that correct code in the first place.

Relicensing isn't necessary. If you violate the GPL with respect to a work you automatically lose your license to that work.

It's enough if one or two main contributors assert their copyrights. Their contributions are so tangled with everything else after years of development that it can't meaningfully be separated away.

That is true! But AVIF is based on AV1. As a video codec, AV1 often does need to be implemented in dedicated hardware for cost and power efficiency reasons. I think the article is misleading in this regard: "This limitation comes from early digital video systems". No, it is very much a limitation for video systems in the current age too.

So they "ignore" bit depth by using 32 bits for each sample. This may be a good solution but it's not really magic. They just allocated many more bits than other codecs were willing to.

It also seems like a very CPU-centric design choice. If you implement a hardware en/decoder, you will see a stark difference in cost between one which works on 8/10 vs 32 bits. Maybe this is motivated by the intended use cases for JPEG XL? Or maybe I've missed the point of what JPEG XL is?

Author is posting honest and respectful critique of Zig features on their blog. That is a valid way of collaborating in the community discussion. The project github isn't the only place where discussion is allowed to take place.

When it looked like Microsoft might close off Windows, Valve built their own SteamOS Linux distro. It now runs many AAA and indie titles, making Linux-based gaming very practical. This is something which was at one time considered impossible.

Valve also have an extremely loyal customer base. If they have to open an account at the Bank of Gaben to get their fix of smutty games, they just might.