haskellshill

Right, they probably already mitigated this bug in their own usage. Which is exactly why reporting the bug is a FAVOR to ffmpeg. Would you rather they just quietly fix it on their own and not report it to the maintainers?

you have 90 days to fix it

Or else what? They release the report? That's standard and ffmpeg is open source anyway, anybody can find the bug on their own. There's no threat here.

If you're mad about companies using your software, then don't release it with a license allowing them to use it. Simple as that. I don't understand how people can complain about companies doing exactly what you allowed them to do.

What does it matter if it's AI generated if it's a real bug? The problem with AI reports is usually that they're invalid; in this case it was an actual bug.

currently have zero real-world impact

So better we not talk about them until someone bothers to write an exploit for it?

the "researchers" didn't even bother to write a patch/fix

If it has no real-world impact and thus shouldn't even be reported, then why does it need to be fixed?

There's no law that you have to fix all bug reports. Isn't it better for users and developers alike that they can see the problems of the project. If they don't have resources that's fine, it's not like they are charging money for their product. But why not be honest and not request people sweep bugs under the rug for fear of looking bad?

Google found a vulnerability and reported it for free. Why do they need to do anything more? Give and inch and ffmpeg's twitter guy requests a mile. If you don't want people to use your software to make money, release it with a license that prohibits that.

rarely anyone ever uses

It's enabled by default so all that's required to exploit it would be to construct a payload file and name it movie.mp4

Yeah, it's actually a great bug report. Reproducible and guaranteed to be an actual problem (regardless of how small the problem is considered by the devs). Just seems irresponsible to encourage people not to file bug reports if it's "insignificant". Why even accept reports then?

VLC is pretty popular on windows, but ffmpeg? Is there any commonly used windows app that relies on it? I doubt it'd be worth one's time to write exploits for desktop linux

Yeah, I mean if it's an actual vulnerability what are they complaining for?

No :)

Again, you're focusing on a pointless detail. Sure, I made a mistake in offhandedly using li as an example. Why do you choose to ignore the actually valid p example though? Seems like you're more interested in demonstrating your knowledge of HTML parsing (great job, proud of ya) than anything else. Either way, you've given zero examples of benefits of not doing things the sensible way that most people would expect.

That's exactly my point, people are clueless about the basics of nuclear power. Why would they know it? I mean, why would the average person know what a linear equation is or what year the first world war started?

If there's a bit of water in your lungs, a surprisingly small amount, it causes massive inflammation and your lungs start to fill with fluid. It's called "secondary drowning", and it happens a couple of hours after.

Allow me to quote an article from Cleveland Clinic Journal of Medicine https://www.ccjm.org/content/85/7/529 (AI generated nonsense of course)

Secondary drowning, sometimes called delayed drowning, is another term that is not medically accepted. The historical use of this term reflects the reality that some patients may worsen due to pulmonary edema after aspirating small amounts of water.

Drowning starts with aspiration, and few or only mild symptoms may be present as soon as the person is removed from the water. Either the small amount of water in the lungs is absorbed and causes no complications or, rarely, the patient’s condition becomes progressively worse over the next few hours as the alveoli become inflamed and the alveolar-capillary membrane is disrupted. But people do not unexpectedly die of drowning days or weeks later with no preceding symptoms. The lungs and heart do not “fill up with water,” and water does not need to be pumped out of the lungs.

There has never been a case published in the medical literature of a patient who underwent clinical evaluation, was initially without symptoms, and later deteriorated and died more than 8 hours after the incident. People who have drowned and have minimal symptoms get better (usually) or worse (rarely) within 4 to 8 hours. In a study of more than 41,000 lifeguard rescues, only 0.5% of symptomatic patients died.

Maybe don't set too much store by what some random "water rescue course" instructor tells you, especially if it sounds like complete bovine excrement.

Well, just because something is allowed by the syntax does not mean it's a good idea, that's why pretty much every language has linters.

And I do think there's an evenly applied rule, namely: always explicitly close all non-void elements. There are only 14 void elements anyway, so it's not too much to expect readers to know them. In your own words "there's no substitute for actually knowing the real rules".

I mean, your approach requires memorizing for which 15 elements the closing tag can be omitted anyway (otherwise you'll mentally parse the document wrong (i.e. thinking a br tag needs to be closed is equally likely as thinking p tags can be nested)).

The risk that somebody might be expecting a closing tag for an hr element seems minuscule and is a small price to pay for conveniences such as (as I explained above) being able to find and replace a p tag or a li tag to a div tag.

Are you misunderstanding on purpose? I am aware they are optional. I am arguing that there is no reason to omit them from your HTML. Whitespace is (mostly) optional in C, does that mean it's a good idea to omit it from your programs? Of course a br tag needs no closing tag because there is no content inside it. How exactly is that an argument for omitting the closing p tag? The XML standard has no relevance to the current discussion because I'm not arguing for "starting to treat it like XML".

The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it.

And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.

Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of my comment, or perhaps you replied to the wrong guy?

As the saying goes, "a little bit of knowledge is a dangerous thing". Your "water rescue course" taught you something that's clearly wrong, as we see with the sibling comment, while my common sense and just everyday life experience led me to the correct conclusion.

It's an analogy, there's no need to analyze it literally. And no, I've worked with some devs who don't understand git (thankfully I don't anymore) and it was quite a bit more than "five times" they got stuck or messed up the repo on the remote in an annoying way. Sure, if you regularly write code using a bunch of evals or gotos "nothing bad will happen" but it's a very suboptimal way of doing things.

"Intimately understand the VM" is not the same as knowing what data structure you're using. It'd be comparable to not knowing the difference between an array and a linked list. Sure you may call it gatekeeping but likewise I may call your style willful ignorance of the basics of the tools you're using. Have you never used rebase or cherry-pick?

I didn't expect this level of unfounded ignorant hysteria here. Have you really never gone swimming and inhaled some water? Did you go to the hospital?

In the past, these terms were used to try to explain that some fatal drowning victims had very little water in their lungs at autopsy. Now it is understood that little water enters the lungs during drowning. Moreover, when water enters the lungs, it is rapidly absorbed when breathing starts again. The amount of water that enters the lung does not determine the amount of injury or determine the treatment of drowning. The amount of injury from drowning is due to how long the victim is without oxygen.

Source: Red Cross

It had too much unnecessary metadata yes, but case insensitivity is always the wrong way to do stuff in programming (e.g. case insensitive file system paths). The only reason you'd want it is for real-world stuff like person names and addresses etc. There's no reason you'd mix the case of your CSS classes anyway, and if you want that, why not also automatically match camelCase with snake_case with kebab-case?

They introduce zero ambiguity to the language

Well, to parsing it for machines yes, but for humans writing and reading it they are helpful. For example, if you have

    <p> foo
    <p> bar

    <div> foo
    <div> bar

The "redundancy" of closing the tags acts basically like a checksum protecting against the "background radiation" of human editing. And if you're writing raw HTML without an editor that can autocomplete the closing tags then you're doing it wrong anyway. Yes that used to be common before and yes it's a useful backwards compatibility / newbie friendly feature for the language, but that doesn't mean you should use it if you know what you're doing.

Reall? Libreoffice at least has a File > Open menu that allows you to specify the separator and other CSV stuff, like the quote character

People can drown on dry land from about a tablespoon of water getting into their lungs.

Well, I don't think there's such a big risk of that. Falling into a pool is something most of us have probably done. Being pushed by a friend as a kid for example. The risk of drowning is probably pretty comparable to the risk from the radiation (negligible).

I mean, if you actually think there's a pool of "lava" that's dangerously radioactive at the surface, while people are walking right next to it, you might be a bit "stoopid". The whole reason water is used is that it shields from radioactivity pretty well

"Expert level knowledge" implies something more to me than simply few people knowing about it. It's ridiculous to say that knowing how to change gears makes you an expert driver, even if a minority know how to do it (such as in the US e.g.)

all the experts you know use it in slightly different ways

What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.

Wow, people are really clueless about how nuclear power plants really work. It's really not that dangerous to fall into the water.

You're arguing in circles. They don't "try to figure out reasons" because there is no concept of "trying", "figuring out" or "reasons".

If that's not thinking, then I don't know what is.

How about actual thinking, you know, what humans and to a lesser extent animals do?

This is a silly definition of learning, and any way, LLMs can't even do what you describe.