Wait until they hear how much source code is thrown away to make software! I guess that's a bit ephemeral, but still probably similar in a lot of industries.
Clothes are weird shaped, weaves are rectilinear, it's a pretty tricky problem to solve. Unless someone manages to invent a non-rectilinear robot loom or something?
We're terrible at company and brand naming here in Europe. Just look at the "Wero" payment solution (formerly/currently iDeal). Like, who the hell came up with that stupid name?
The list of stupid European company names and product names are endless.
I agree, the Dutch iDeal was probably the better name. However I'm not sure if this is an uniquely European problem. Wero's counterpart 'Zelle' doesn't seem to be that much better of a name.
I find it okay'ish. At least it's unique. Say, as much as I like Mario Zechner (who doesn't like HNers anymore for whatever reason), naming your product "Pi" is just terribly bad.
Facebook was a good name (hate the company but the name was good). But "Meta" is just dumbfucktarded.
Wait... I've got an idea: I'm going to make a product and name it "Alt". Or "Control".
Really: there are a lot of totally unhelpful name that just confuses everybody, including search engines, humans, and LLMs but I don't think "Solvinity" is that bad.
I've always found Whatsapp a terrible name, but its so established now that 'apping' is understood. If you're big enough it seems that a bad name hardly hold you back.
The rustcrypto crates seem a lot better maintained and will probably supplant ring in future. Ring maintenance seems hostile to use outside of expected use cases.
If they're already running a custom Linux kernel build, why did they have AF_ALG enabled? Seems the perfect situation to limit features to only those actually being used.
And also as part of this, they have learned the lesson parent comment is trying to make: they called out that they are going to review their deployments and make sure there's no unused modules being deployed
The simplified answer is, larger keys that demand a far larger effort to break, in a way similar to RSA-4096 vs RSA-2048.
The predicted timelines for quantum computer advances (and the requirements for practical applications) have shrunk dramatically in the past 15 years. What used to be a no-later-than-2035 recommendation for getting off e.g. RSA-2048 in good time, is today no-later-than-2030. The admission of 256-bit curves for ECDSA/ECDH has been supplanted by 384-bit curves already years ago.
In the absolutely ground shaking event that a future application of quantum computation somehow manages to cut Ed448's equivalent security of ~224 bits in half, exploring even a small portion of a 112-bit space will still cost more electrical energy than we can possibly provide.
The whole point is that RSA and ECDH can't be made safe against quantum computers by making the keys bigger. The speedup is exponential and so breaking a 4096-bit key is only twice as hard as a 2048-bit key. The 'cutting in keysize in half' is true in principle in general (but not in practice, as the article points out), but for some algorithms it's much worse.
Just to be clear, I'm not advocating for Ed448 for the KEX - we already have ML-KEM and SNTRUP in OpenSSH and everyone should start using those. I'm advocating for Ed448 DSA ("SSH pubkey").
Looking at the PR discussed, it's 34 commits! I'd probably ignore that too as a maintainer. The PR description isn't particularly motivating, "Cleans up the implementation", "see #6735 for the actual motivation".
Fair call-out, although couple things to point out, I am used to a Squash Merge workflow which I think makes reviews easier based on comments as the reviewer gets to see what changed after their comment easier. Many of the commits are merge commits. If you actually look at the timeline of the original PR, you will see that it also started with a smaller scope but as time passed I also went through the cycle of "while at it, let me also fix this" loop that I mentioned in the article.
The point of the article is: there is a feature that people would like, there is someone who wants to add it, the appropriate time and a lot more for this feature to be merged has been spent yet the feature is nowhere to be found. That's the two way street I am trying to get across. I wish I wasn't even able to open the PR, I wish the maintainer would utilize more automation tools to groom feature requests and potential contributors with agreed upon plans and agreed upon timelines so that both sides time could be used much more effectively.
As far as PR descriptions etc goes, I asked multiple times what the best route to merging would be. If that went through better descriptions, I was happy to do that, as you can see, I wasn't aware of the "no conventional commits" rule, so in my next PRs I used the correct approach, but that should be completely automatable. Yes, I should have spent more time studying Jellyfin's conventions, but I shouldn't have to, not because its unfair for me, simply because there are more contributors than maintainers, so maintainers should not rely on desired behavior from contributors, they should force that behavior as much as possible.
Many of those are "Merge branch 'master' into armanc/subtitle-sync-refactor". Rebasing the PR on top of master would bring that down to like 15 or something.
Clothes are weird shaped, weaves are rectilinear, it's a pretty tricky problem to solve. Unless someone manages to invent a non-rectilinear robot loom or something?
reply