CodesInChaos
CodesInChaos on Hacker News
> These are schema and app concerns
Discriminators are one of the fundamental building blocks of composition (sum types in ADT parlance). The workarounds for expressing them are verbose, ugly, and complicate schemas.
Consider `shape: circle: { radius : 1}` vs the workarounds like `shape: { type: circle, radius: 1}` or `shape: { circle: { radius: 1 }`.
It's about using a
certified cryptography implementation. Presumably RHEL has such a certification, while Debian has a compliant but uncertified implementation.
This isn't relevant to the CVE, but counters the claim that Debian is always a suitable choice of distribution.
Not really. INI has a fixed structure (section>key>value) and its values are untyped.
What I'm missing:
1. The readme doesn't make it clear what its "float" type is. A double, a decimal, implementation defined. I'm generally not a fan of restricting numbers to what a double can represent, like toml does.
2. It doesn't have a good way to model key-value pair like types such as tagged unions, polymorphic types, or function invocations. Simply allowing a key-value pair as a value (right associative) where the key is a string matching the keys of an object would fix this. Alternatively a function call syntax would fix this, which would also enable tuples as a concept distinct from arrays.
So far Opus hasn't complained about doing security reviews of my code. Though I never asked it to exploit the vulnerabilities or to produce a PoC.
I am rather receptive to the argument that SQL is a fractal of bad design. But complaining that SQL engines implement well known SQL semantics according to spec is silly.
Since the library claims to be postgres compatible, I wonder if its developers ran the existing postgres jepsen suite against it (possibly with some adjustments). Or why not.
Especially now, where you could probably just ask AI to adapt the existing suites to the cosnistency claims this database makes, and get something useful out of it. While certainly not as good as a professional test, I'd expect it to at least find some low hanging fruits before going for the expensive and public official Jepsen test.
Just like the old userfriendly.org comic where marketing promises nine fives instead of five nines.
Claude "team" plans are limited to 150 seats per company. So big companies have no choice.
Why do you use commas to separate multiple targets, instead of multiple arguments?
Claude is surprisingly bad at killing processes. Had several "Whoops, my process killer matched itself and died before its victims" notifications already.
Get the "One Tab" extension. It closes all tabs, but saves a list, so it gets over the psychological hurdle of losing the open tabs.
> I always found it weird that people flocked to github.
Same reason we ended up with git. Their predecessors were significantly worse, and then they had enough momentum to keep going.
Downtime aside, what do prefer about GitLab?
> one of the main performance tricks for CGI was to get processes to stay alive
How does that work? Exec(ve) without fork? That should still clean up the PHP state.
> zstd has high quality rust implementations
On the decompression side yes, on the compression side the first good zstd rust port was announced yesterday. Until then, brotli was better supported in Rust than zstd.
But I agree, decompression libraries should be (mostly) memory safe nowadays, since that side is both easier to implement and more likely to be vulnerable.
It's just as likely it would end up as an overengineered mess. And that's without considering backwards compatibility constraints, which are one of the biggest maintenance burdens.
So we now have evidence that AI absorbs the souls of dead people.
There is little difference between a tag and a branch in git. There is just the convention that tags reference the same commit forever, while branches move.
On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository.
I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
Matches my subjective experience where Opus Extra likes starting sub-agents that burn tokens for little benefit. While High just does the work itself.
I think the original SubSync was the useless linear tool I tried last time. Though the Sefzz15 fork added some kind of "piecewise" feature which might work.
Though they do have the money to generate terrible TTS audio for many videos. And since google can't fathom a person knowing a foreign language, use those automatically without warning.
Considering the progress on speech recognition, why do YouTube subtitles have little in common with what's spoken in the video? Shouldn't Google be able to do a good job at auch a task?
Slightly off-topic, but can anybody recommend a local model/tool that fixes timestamps of existing srt subtitles? That should be easier than generating them from scratch.
When I last looked for this a few years ago, I only found a really primitive one that did a linear transformation of all timestamps in the video, and none to correct each line individually.
edit: Claude recommended alass. Any experiences with that one, or better options?
That was the idea behind namecoin. But they screwed up their pricing and died.
The AI of today is just a tool, albeit a very powerful one. But I don't think it's a big step for it to reach a level where the majority of humans will be unable to to meaningfully contribute to the economy ten years from now.
But why does missing JXL support make the AVIF too small? It ends one pixel before the gray background.
Lepton guarantees that JPEG->Lepton->JPEG produces an identical file, not just identical pixels. Does JPEG XL achieve the same thing?