Has anyone ever heard of a phono jack connection detection that works in windows with headphones and a sound system, but only works in linux in the headphones?

This issue breaks my understanding of how phono detection works. How the operating system would have any way to distinguish between the two. And it sounds like some physical weirdness.

Anyone else seen anything like this? Please boost.

#Fedora #Linux #Foss #Audio #Sound

All human-authored art, regardless of quality, is vastly superior to soulless AI remixes.

Using AI art just sends a message that filling a space with *anything* is all that matters. How can you expect people to care about anything else you have to offer once they know that?

[RSS] BGGP6: REVIVING RDOFF PART 1

https://n0.lol/bggp6-rdoff/

Hello from Düsseldorf. I am at German OWASP day and you can follow along too. There’s a live stream on https://media.ccc.de/.
Full program at https://god.owasp.de/2025/

Talks are about all sorts of appsec things, from langsec over pdf to passkeys and so on. All talks will be recorded :)

Came across this striking art piece in Bourke St Mall, #melbourne called Paid Attention by Huei Yin Wong. It’s designed to comment on the way the advertising industry profits from constantly taking our attention at no benefit to us. If you sit making unbroken eye contact with the messages about our attention choices on the screen, it pays out the equivalent of minimum wage for the time watched. Sitting there conspicuously staring at something silly in public for even less than 2 minutes was weirdly unsettling even though we’re constantly looking at silly stuff on screens

We made a new tool, QuicDraw(H3), because HTTP/3 race condition testing is currently trash. https://www.cyberark.com/resources/threat-research-blog/racing-and-fuzzing-http-3-open-sourcing-quicdraw

@caspicat yeah that too - google even has a special "wont tell you why we dont index this" code on search console. But I'm also talking about docs where you get like 3 examples but no API docs.

@pancake umm, that's weird, seems to have disappeared from the blog too?

You can now pull Ghidra databases straight into your workflow in Binary Ninja 5.2! Open a .gbf on its own, import Ghidra data into an existing session, or bring parts of a full project into a Binary Ninja project on Commercial and above. Mixed tool workflows get a lot easier and this update sets the stage for future export support. https://binary.ninja/2025/11/13/binary-ninja-5.2-io.html#ghidra-import

Re: "AI chat is a better search experience than traditional search engines"
https://come-from.mad-scientist.club/@algernon/statuses/01KAYE52M0RCVN6G3TWCYVS1SG

Lately I have the impression that not only are search engines worse and websites contaminated with slop, but significant amount of content - technical docs, mostly for modern SW - *is simply not there, because no one ever wrote it*!

Am I alone with this?

AI chat is a better search experience than traditional search engines

Weeelll.... only because traditional search engines are full of ads and scam, and the slop machines filled the internet with garbage, which these search engines keep pumping up.

Traditional search engines became crap the moment advertisement found its way there, and the moment they became generic and all-encompassing.

I've been using my own search engine (a YaCy instance) for the past few years, and it continues to work remarkably well, thank you very much. Better than any slop machine, better than any traditional search engine.

If you look past the shitstained windows of BigTech's walled garden, there's a whole world of beautiful, working internet out there. Free of advertisement, free of dark patterns, free of the slop machines.

The trick is to not believe their lies.

[RSS] Why does XAML break down when I have an element that is half a billion pixels tall?

https://devblogs.microsoft.com/oldnewthing/20251124-00/?p=111811

[RSS] The apocryphal origins of the Hot Dog Stand color scheme

https://devblogs.microsoft.com/oldnewthing/20251125-00/?p=111813

woo-hoo! @mwl is writing "OpenZFS Mastery" ​

More filesystems! More disks! More Zthings!

You too can sponsor his madness at https://sponsor.mwl.io/

(This was not paid by @mwl, I just happen to sponsor his books because I'm addicted to books).

[RSS] Constant-time support lands in LLVM: Protecting cryptographic code at the compiler level

https://blog.trailofbits.com/2025/11/25/constant-time-support-lands-in-llvm-protecting-cryptographic-code-at-the-compiler-level/

@tess

Some helpful advice for all you software devs:

- you can cause social problems with code
- you can degrade the system if you don't understand how or why it works
- you can produce obstructions for someone else without understanding how they work or what they are doing.

Sometimes I think it’s going to be the librarians who will save us all.

I just went to request a feature in #KDE on #Linux and saw that the feature had been requested 10 years ago. I added a comment to bump it and see if it was still under consideration when I got a ding on my phone.

Turns out I had commented on the same bug, under an old email address, seven years ago.

If you only enable scripts on soundcloud[.]com the site doesn't load but no blocked scripts show up either.

Back in the day people were burned at the stake for shit like this.

I've seen a number of people (including some well-respected people in the infosec sphere) promoting a particular blog post/writeup recently about the macOS secure boot chain. As someone who has done a fair bit of research and reverse engineering of iBoot and Apple's secure boot chain over the years, this naturally piqued my interest so I decided to take a look, at minimum to see how much it lined up with my RE of iBoot over the years.

Unfortunately after reading the blog post thoroughly, I can pretty confidently say this: the writeup is almost certainly a pile of AI slop. Let's dive into it and discover some major red flags that I found.

Let's talk about something that I think a lot of the people reposting this post haven't realized yet: this post was *very* factually wrong when it was first posted. (Here (https://web.archive.org/web/20251122220347/https://stack.int.mov/a-reverse-engineers-anatomy-of-the-macos-boot-chain-security-architecture/) is a link to the earliest version on the Wayback Machine, very good resource btw ) Shoutouts to @nicolas17 btw for making archives once he noticed the article rapidly changing, he puts in a lot of work in the archival side of things that imo goes very unnoticed, but his work helps Apple security research in the long run.

This original version of the post has several factual errors (there are too many to list but some of the VERY obvious ones include Apple silicon chips starting at EL3 when no M-series *Mac* chip has implemented EL3 (which is optional per ARM spec) In addition there is contradictory info about the ECID, incorrect info on security fuses, etc, there's a LOT of slop to digest here along with tons and tons of jargon that makes no sense.)

The fact the post gets stuff wrong in and of itself is not the issue (a mistake here and there is completely understandable and in fact quite human), the issue is with the *magnitude* of *how many factual errors* were posted publicly, seemingly without any fact checking or sourcing, it really is quite egregious just how wrong this post is (even the current version of the post still has *many* of these errors), especially to any person who has even took a cursory glance at iBoot or the secure boot chain.

The syntax, per people I discussed this with, screams that it was based on prompting Claude (an LLM that seems to have more natural writing style than some of the others.)

However, what *really* is super insidious is the *history* behind this post. This (https://gist.github.com/nicolas17/81d082c93599c8bc70492caabb97289d/revisions) is a link to diffs of the post over time, and it's pretty damning. The post had very very large chunks changed in very short amounts of time across multiple parts of the very long post, and with how long the post is, this is probably outright infeasible for a human to do in that short time frame (especially when incorporating time to fact-check the updated parts, which any writeup worth their salt imo *should be doing.*)

Per these two comments (https://news.ycombinator.com/item?id=46020891) (https://news.ycombinator.com/item?id=46020395) on HackerNews, along with the drastic changes mentioned before (especially considering that the post changed quite drastically between revisions, saved versions of which you can find here (https://web.archive.org/web/20250000000000*/https://stack.int.mov/a-reverse-engineers-anatomy-of-the-macos-boot-chain-security-architecture/)), it's pretty clear that what's been happening here is the person used AI to churn out this "writeup", then used the fact it was blatantly wrong to get people who knew how these systems actually worked to correct the post, and then told the AI to incorporate said corrections into the original post.

Let's be clear what's happening: the person is outright baiting people using this AI slop into correcting the post, incorporating said corrections *without attribution to the people who corrected the post* and then took the credit for said corrections silently. This isn't okay, this is a blatant abuse of community goodwill and the benefit of the doubt to fraudulently boost your own credibility and platform, without even a legitimate effort or attempt at doing proper research or fact-checking. (Not even diving into how LLMs are plagiarism laundering machines that yoink real human work and mash it together without any attribution.)

This "writeup" is nothing but of AI slop, and I strongly advise avoiding giving it attention. I'm very disappointed that people, even people I respect quite a bit, are promoting this like it's legitimate without reading it deeper and realizing this is AI slop.

Here are some writeups I *strongly* recommend reading, that have real, human, legitimate research placed into them:

- This fantastic writeup/thesis (https://arxiv.org/abs/2510.09272) by Mortiz Steffin and Dr. Jiska Classen on the GXF-protected portions of iOS (SPTM, TXM, Exclaves/SecureKernel) and how it all makes XNU closer to a true microkernel architecture.
- JJTech's writeup (https://jjtech.dev/reverse-engineering/imessage-explained/) on iMessage and how it worked as of 2023 (yes, 2023 was two years ago, but this writeup is still worth reading regardless)
- Snoolie's writeup on an Apple Archive vulnerability (https://snoolie.gay/blog/CVE-2024-27876), this is a great writeup that goes further in depth on CVE-2024-27876.