Try the nightly build:

https://github.com/yt-dlp/yt-dlp-nightly-builds/releases

Yes, that worked. Thanks!

Is there a VOD link instead of the livestream link?

This video isn’t available anymore

Is it a permissions issue? If you’re running software through flatpak, do you need to enable access to the optical drive device through flatseal?

I would look at the tools that the preservation groups use for doing this. The optical media layouts are funky and IIRC using dd on the block device is not enough to archive a bit-for-bit copy. There are details about the track layout and so on that need to be recorded separately. This is why formats like BIN/CUE exist.

eg. https://wiki.redump.info/Redump#Technical_Questions

Oh I see. If the URL puts the sensitive information after the anchor, like https://example.com/bsod#sensitive-info-goes-here then the browser would never send that part to the server. Everything after the anchor is just used locally by the browser to scroll the page to a specific place (or in this case for the javascript to read and process).

You’d need to check every time you scan a QR code though that the # is in the URL and it’s not malformed. Trivially replacing the # with a ? would turn the private URL into one that sends all the data in the GET request. It’s training users to do something risky.

Oh and it also assumes that the javascript hasn’t been tampered with to upload the data somewhere.

I don’t like it.

So it’s leaking information about your system to an external site?

That’s just what we need.

every month PayPal charges a little fee for having money on the card.

PayPal or PaySafe?

It’s worth learning nftables, it’s actually pretty cool.

IIRC Tor Browser makes its own connections to Tor within the application, it doesn’t use the Tor daemon even if one is running.

VirusTotal also tells you a load of stuff about file read/writes and network access etc. What did it say? And what was the positive result for?

An article about a tweet.

Denuvo has done some homework, though. The filing lists a Discord user ID, a Reddit account and seven Steam profiles that it believes are linked to the cracker.

Denuvo hopes the information linked to these accounts will eventually unmask the cracker. Games have to be bought before they can be cracked, for example, and Steam purchases come with payment details.

I hope this person has good OPSEC.

Stallman was right.

Nice try Linus, but I wouldn’t watch your review even if it was the last one on earth.

Why even mention the nazi distro at all?

sloppers can just keep burning new accounts (as long as they have access to new IP addresses) while real developers deserving of praise and reputation thrive.

Becoming a Debian developer requires you to meet an existing Debian developer in person and have your public key signed by them. It’s not possible to keep burning new accounts unless you go and meet a different Debian developer each time and there’s a limited number of them in each region and they usually meet together, so more than one person will see your face.

This vote was not about upstream projects included in the Debian distro, it was about the Debian project itself.

I disagree with your reading of the proposals. My interpretation was that only proposals (1) and (7) have severe limits on LLM use. Each of the other proposals allows LLM use with some very minor concessions or no concessions at all. It felt to me as though they were all worded very sneakily to try to attract votes from anti-AI developers while actually being very permissive, by waffling about the harms of AI in the preface before completely dropping the ball in the requirements section.

Removing all of the waffle, the proposals can be boiled down to:

1. Completely outlaws all use of LLMs in Debian contributions, whether code or documentation or communication etc.
2. Allows any and all LLM use provided that:

• the tools are not legally problematic
• the LLM output does not violate another copyright
• the contributor assumes full responsibility
• they’re not used for bulk operations without prior discussion
• private data is not sent to cloud services

3. Allows LLM use for everything except for human-to-human communication. Also permits individual maintainers to ban LLM contributions to the project that they maintain (implying that maintainers may also permit LLM contributions to the project they maintain).

• This one is particularly pernicious since it also “requests” (as in, a non-binding encouragement) that nobody uses LLMs, whilst acknowledging that for decision makers this “will involve uncomfortable compromises.”

4. Allows any and all LLM use provided that the contributor takes full responsibility, tags the contribution as LLM-assisted, and doesn’t use cloud services for private data.
5. Says absolutely nothing of substance. 8 paragraphs of waffle to place no restrictions on anything but to say that contributors are already bound by the Debian Social Contract and existing rules, and that they should be held responsible for their contributions accordingly.
6. Exactly as (5), but this time 9 paragraphs of waffle to say nothing of substance.
7. “In order to safeguard the project’s mutual understanding, trust and respect, we disallow the output of generative AI as direct contributions to Debian.”
8. 12 paragraphs of hand wringing about the climate boils down to: “this text is just a position statement. This said however, we appreciate the disclosure of LLM usage.”

So by my reading, that makes:

• Bans AI: (1), (7)
• Allows AI: (2), (4), (5), (6), (8)
• Allows AI with a restriction: (3)

Now read the titles of these proposals and their introductory preamble and ask yourself whether they are representative of the actual rules they will put into effect.

https://lists.debian.org/debian-vote/2026/08/msg00352.html