ja sa stým moc netoto trochu masla sol cierne korenie a na panvicu.. bol oveľa oveľa mastnejší ako ribeye čo bol od šéfkuchára. Z Kauflandu na test druhý krát ho už nekúpim asi.

edit: skúsim na budúce tento spôsob

@MicheleDvoraku toto bolo mäso mastodon.arch-linux.cz/@Suspic… mňam do p nejaká argentína, kolega mi to tu a tam objedná ale to sa nedá porovnať

SuspiciousDuck

2025-08-07 10:32:19

uvidíme.. pekné od neho že mi ich zabalil #dobréRáno

I kind of agree, but at the same time, we aren't actually enforcing the copyright laws we already have, because OpenAI isn't actually open, and in fact, is worth so much money that lawmakers are kind of letting them do whatever they want.

It's really about corruption, and not a lack of laws or GPL version IMHO.

I don't agree. We need to train LLM on something legally and open source will benefit from it aswell. And is big difference between using code directly and thru LLM.

The main problem with LLM is that they are using unlicensed documents to train (eg books)

No, i would say its a stability problem. It might become a security problem for the using application though.

But most likely its AI slop.

For even as small as 500 bytes, I would argue that it qualifies as a potential Denial of Service issue, since this could still cause problems in a program which makes many connections, and is running on a container/microcontroller with only a small amount of memory allocated.

It probably wouldn't get a very high severity rating or anything but I'd argue that it at least qualifies for a score.

If the attacker can trigger a new curl connection from the user of the library, it becomes a security problem.

As much as I hate the CVEs, the Denial of Service is in the CVSS scoring chart, and the CVSS says: Assume vulnerable configuration.

So personally, I would treat this as security vulnerability even if there would be a single leaked byte.

By itself, not a security problem, in my opinion. If someone embeds libcurl in a server side service, then it could cause a denial of service issue or result in unexpected reboots.

So my current perspective is that it's a possible ingredient for a security issue, but not a security issue in itself.

In curl, the command? Never.

Libcurl? Such that a long running daemon could actually be impacted? I think one byte...

Security use the CIA model, Confidentiality, Integrity and Availability. This is not a threat to either C or I, but Availability may be impacted over time, leading to a Denial of Service situation. Thus the size of the memory leak is not relevant, the precense is enough to call it a security problem.

Also, will the systems overall react correctly in a situation with limited resources?

Statistically, I think that means you'll be responsible for fewer bugs as well! Though, as the project leader, you still get all the blame for the bad stuff while everyone else gets the praise for the good stuff. 😅

Very cool accomplishment and a testament to your investment in mentorship and scaling yourself. Our egos often make it difficult to achieve what you have, so I think you deserve a lot of kudos for it. 💖

But I'll still ask you to fix my Internet-connected toaster... 😜

Feels good, doesn't it ?

I remember feeling relief when somebody else finally took the "Most active FreeBSD committer" title away from me.

This is one of my favourite milestones in projects I create. Some of the others:

• Someone else wrote some documentation.
• New code for this release was mostly written by others.
• All new code in this release was written by others.
• Someone else did this release.
• Someone else did all of the code review in a patch.
• Someone else did all of the code review on all changes that went into this release.
• Someone else is co-maintainer.
• Someone else is maintainer.