Hacker News - Best

https://www.eff.org/deeplinks/2025/11/patent-office-about-make-bad-patents-untouchable

By iamnothere ⬆️ 397 💬 44 [comments]

Top comment by kregasaurusrex:

Before I discovered HN (of which I'm on daily), I was a frequent reader of Groklaw[0]- a site primarily devoted to covering the fragile intersection of the technology sector and legal system; where the two are often at odds with one another. We're more than a decade beyond it's voluntary closure after the Snowden revelations and it's left a large void on substantive coverage of these issues. The site was the blog of an anonymous tech reporter named Pamela Jones that did detailed deep-dives into the parties & issues involved in high-profile lawsuits between tech companies, like Apple vs. Samsung on the issue of design patents for rounded corners, over what have often been patents containing broad language that resulted in hindrances to innovation ranging from being unwilling to license to extortion of revenue streams for entire product lines. Part of why I find the technology industry to be continually interesting is its desire to innovate instead of litigate- there needs to be a check on bad faith actors whose goal is capture of a niche through regulatory means instead of fair competition; else we get these cases relegated to the infamous eastern district of Texas which has historically played favor towards non-practicing patent trolls. I'll be submitting my comment and suggest others do the same.

[0] https://en.wikipedia.org/wiki/Groklaw

https://www.theverge.com/tech/823337/switching-linux-gaming-desktop-cachyos

By throwaway270925 ⬆️ 356 💬 251 [comments]

Top comment by vinkelhake:

I recently had my Framework Desktop delivered. I didn't plan on using it for gaming, but I figured I should at least try. My experience thus far:

    * I installed Fedora 43 and it (totally unsurprisingly) worked great.
    * I installed Steam from Fedora's software app, and that worked great as well.
    * I installed Cyberpunk 2077 from Steam, and it just... worked.

Big thanks to Valve for making this as smooth as it was. I was able to go from no operating system to Cyberpunk running with zero terminals open or configs tweaked.

I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn't really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.

https://www.ntsb.gov:443/news/press-releases/Pages/NR20251118.aspx

By DamnInteresting ⬆️ 322 💬 123 [comments]

Top comment by crote:

I strongly recommend watching/reading the entire report, or the summary by Sal Mercogliano of What's Going On In Shipping [0].

Yes, the loose wire was the immediate cause, but there was far more going wrong here. For example:

- The transformer switchover was set to manual rather than automatic, so it didn't automatically fail over to the backup transformer.

- The crew did not routinely train transformer switchover procedures.

- The two generators were both using a single non-redundant fuel pump (which was never intended to supply fuel to the generators!), which did not automatically restart after power was restored.

- The main engine automatically shut down when the primary coolant pump lost power, rather than using an emergency water supply or letting it overheat.

- The backup generator did not come online in time.

It's a classic Swiss Cheese model. A lot of things had to go wrong for this accident to happen. Focusing on that one wire isn't going to solve all the other issues. Wires, just like all other parts, will occasionally fail. One wire failure should never have caused an incident of this magnitude. Sure, there should probably be slightly better procedures for checking the wiring, but next time it'll be a failed sensor, actuator, or controller board.

If we don't focus on providing and ensuring a defense-in-depth, we will sooner or later see another incident like this.

[0]: https://www.youtube.com/watch?v=znWl_TuUPp0

https://www.linkedin.com/posts/adafruit_opensource-privacy-techpolicy-activity-7396903362237054976-r14H

By ChuckMcM ⬆️ 405 💬 197 [comments]

Top comment by ahepp:

> users are now explicitly forbidden from reverse-engineering or even attempting to understand how the platform works unless Arduino gives permission.

I briefly looked at their IDE and CLI repos and GitHub claims they're AGPL and GPL 3 respectively. I didn't see a CLA when I looked at their contribution guide.

Am I missing something here? What basis do they have to restrict users' rights to reverse engineer the software?

https://www.chrbutler.com/what-ai-is-really-for

By delaugust ⬆️ 266 💬 190 [comments]

Top comment by highfrequency:

The universal theme with general purpose technologies is 1) they start out lagging behind current practices in every context 2) they improve rapidly, but 3) they break through and surpass current practices in different contexts at different times.

What that means is that if you work in a certain context, for a while you keep seeing AI get a 0 because it is worse than the current process. Behind the scenes the underlying technology is improving rapidly, but because it hasn’t cusped the viability threshold you don’t feel it at all. From this vantage point, it is easy to dismiss the whole thing and forget about the slope, because the whole line is under the surface of usefulness in your context. The author has identified two cases where current AI is below the cusp of viability: design and large scale changes to a codebase (though Codex is cracking the second one quickly).

The hard and useful thing is not to find contexts where the general purpose technology gets a 0, but to surf the cusp of viability by finding incrementally harder problems that are newly solvable as the underlying technology improves. A very clear example of this is early Tesla surfing the reduction in Li-ion battery prices by starting with expensive sports cars, then luxury sedans, then normal cars. You can be sure that throughout the first two phases, everyone at GM and Toyota was saying: Li-ion batteries are totally infeasible for the consumers we prioritize who want affordable cars. By the time the technology is ready for sedans, Tesla has a 5 year lead.

https://openai.com/index/gpt-5-1-codex-max/

By hansonw ⬆️ 397 💬 230 [comments]

Top comment by johnfn:

I've been using a lot of Claude and Codex recently.

One huge difference I notice between Codex and Claude code is that, while Claude basically disregards your instructions (CLAUDE.md) entirely, Codex is extremely, painfully, doggedly persistent in following every last character of them - to the point that i've seen it work for 30 minutes to convolute some solution that was only convoluted because of some sentence I threw in the instructions I had completely forgotten about.

I imagine Codex as the "literal genie" - it'll give you exactly what you asked for. EXACTLY. If you ask Claude to fix a test that accidentally says assert(1 + 1 === 3), it'll say "this is clearly a typo" and just rewrite the test. Codex will rewrite the entire V8 engine to break arithmetic.

Both these tools have their uses, and I don't think one approach is universally better. Because Claude just hacks its way to a solution, it is really fast, so I like using it for iterate web work, where I need to tweak some styles and I need a fast iterative loop. Codex is much worse at that because it takes like 5 minutes to validate everything is correct. Codex is much better for longer, harder tasks that have to be correct -- I can just write some script to verify that what it did work, and let it spin for 30-40 minutes.