No, the implied solution is to reevaluate the standard rather than hacking around it. The two humans should communicate that the standard works for neither side and design a better way to do things.
patatahooligan
This is really funny to me. If you keep optimizing this process you'll eventually completely remove the AI parts. Really shows how some of the pains AI claims to solve are self-inflicted. A good UI would have allowed the user to make this transaction in the same time it took to give the AI its initial instructions.
On this topic, here's another common anti-pattern that I'm waiting for people to realize is insane and do something about it:
- person A needs to convey an idea/proposal
- they write a short but complete technical specification for it
- it doesn't comply with some arbitrary standard/expectation so they tell an AI to expand the text
- the AI can't add any real information, it just spreads the same information over more text
- person B receives the text and is annoyed at how verbose it is
- they tell an AI to summarize it
- they get something that basically aims to be the original text, but it's been passed through an unreliable hallucinating energy-inefficient channel
Based on true stories.
The above is not to say that every AI use case is made up or that the demo in the video isn't cool. It's also not a problem exclusive to AI. This is a more general observation that people don't question the sanity of interfaces enough, even when it costs them a lot of extra work to comply with it.
It's much more complicated than this. Given that models have been shown to spit out verbatim copies of some training material, it can be argued that the weights do in fact encode the material, just in some obfuscated way. Additionally, it can be argued that the output of the model is a derivative copy of the original work regardless of whether the original work can be "found inside" the model weights, just by the nature of the process. As of now, there is no precedent that I know of on whether this constitutes redistribution of copyrighted material.
How many months should he have waited for an authoritative response?
Well, Marcan should wait as long as feels right to him. As I said previously, I'm pretty sure he was already pissed off about previous R4L issues and he didn't quit because of this alone. I want to be clear that I'm commenting solely on the expectation of a swifter response from leadership in the original email thread and not on Marcan's decision to step down, which I can't be the judge of.
So, I expect people in places of power to take their time when they respond publicly to issues like this, for various reasons. Eg:
- they might try to resolve things in private first (seems to be the case)
- they might want to discuss with their peers to double check their decision making and to take collective action, this is especially true if the CoC committee gets involved
- they might want to chime in when people have calmed down and they expect to be able to have meaningful conversations with them
At the very least, I would have waited to see what happens with the patches if I were in his position. The review process, which kept going in the meantime, essentially sets a timer for a decision to be made. In the end, Hellwig's objections would either be acknowledged as blocking or they would be ignored. In any case there would have been a clear stance from the project's leadership. It makes sense to me to wait for this inevitable outcome before making a committal decision such as stepping down.
Cristoph Hellwig's initial message was on 2025-01-08. Marcan's stepping down was on 2025-02-07. So no, it's not several months; it's barely one month. Getting in fights in mailing lists and making social media posts is not everyone's first reaction and it is arguably not the best reaction, especially for people in places of power. It is silly for Marcan to demand everybody's reaction to be as loud and as quick as his own.
It was very clear that the reaction was going to be no reaction.
Well, it turns out that the reaction was pretty clear not "no reaction". That's the reason this thread we're talking in exists. Marcan was objectively wrong if he assumed Hellwig's comments and nack would be accepted. Instead, Hellwig was explicitly called out for having no say on the matter and for producing "garbage arguments".
Marcan is not the submitter. Unless I've missed something, the submitter is still working on the patch.
Arch doesn't require you to "read through all changelogs". It only requires that you check the news. News posts are rare, their text is short, and not all news posts are about you needing to do something to upgrade the system. Additionally, pacman wrappers like paru
check the news automatically and print them to the terminal before upgrading the system. So it's not like you have to even remember it and open a browser to do it.
Arch is entirely about “move fast and break stuff”.
No, it's not. None of the things that make Arch hard for newbies have to do anything with the bleeding edge aspect of Arch. Arch does not assume your use case and will leave it up to you to do stuff like edit the default configuration and enable a service. In case of errors or potential breakage you get an error or a warning and you deal with it as you see fit. These design choices have nothing to do with "moving fast". It's all about simplicity and a diy approach to setting up a system.
Agreed. A few year back the devs looking for quick fixes would go over to StackOverflow and just copy answers without reading explanations. This caused the same type of problems that OP is talking about. That said, the ease of AI might be making things even worse.
Getting the entire world to switch to something better would be quite the undertaking.
But that's probably not necessary. You could install something on your phone that does phone number lookup and then just dials the number as normal. The service doesn't need to be built into the old phone networks this way.
The latter is I think aiming for Linux ABI compatibility.
I had never hard of Asterinas, but this sounds like a the best approach to me. I believe alternative OS's need to act as (near) drop-in replacements if they want to be used as daily drivers. ABI-incompatible alternatives might be fine for narrower use cases, but most people wouldn't even try out a desktop OS that doesn't support most of the hardware and software they already use.
No, not all encryption. First of all there's two main categories of encryption:
The most widely used algorithms of asymmetrical encryption rely on the prime factorization problem or similar problems that are weak to quantum computers. So these ones will break. Symmetrical encryption will not break. I'm not saying all this to be a pedant; it's actually significant for the safety of our current communications. Well-designed schemes like TLS and the Signal protocol use a combination of both types because they have complementary strengths and weaknesses. In very broad strokes:
This is crucial because it means that even if someone is storing your messages today to decrypt them in the future with a quantum computer they are unlikely to succeed if a sufficiently strong symmetric key is used. They will decrypt the initial messages of the handshake, see the messages used to negotiate the symmetric key, but they won't be able to derive the key because as we said, it's safe against eavesdropping.
So a lot of today's encrypted messages are safe. But in the future a quantum computer will be able to get the private key for the asymmetric encryption and perform a MitM attack or straight-up impersonate another entity. So we have to migrate to post-quantum algorithms before we get to that point.
For storage, only symmetric algorithms are used generally I believe, so that's already safe as is, assuming as always the choice of a strong algorithm and sufficiently long key.