Recently posted comments
Perfection is the enemy of good
Posted Oct 15, 2025 2:51 UTC (Wed) by dskoll (subscriber, #1630)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
It depends on the hardware and on the blob. In some cases, it's for regulatory reasons... a provider of radio hardware might not want you to be able to use it at frequencies or power levels that are illegal in your jurisdiction and might choose to keep the firmware closed to make it harder for you to do those things.
In other cases, it's just way simpler to perform a function in software rather than hardware, and if you're going to need software anyway, you might as well make it field-replaceable so if bugs are found, they can be fixed on the fly. It's unlikely that said software contains intellectual property of any value and far more likely that it's embarrassingly badly-written and tied so tightly to a very specific piece of hardware that it would be almost useless for an end-user to try to tinker with it.
I don't know where the line should be drawn between "this restricts freedom" and "it's pointless to let users change this". It's definitely at a higher level than the hardware and a lower level than the operating system, but in between is fuzzy.
Progress with a Plan
Posted Oct 15, 2025 2:38 UTC (Wed) by Hello71 (subscriber, #103412)In reply to: Progress with a Plan by josh
Parent article: Debian Technical Committee overrides systemd change
Perfection is the enemy of good
Posted Oct 15, 2025 2:29 UTC (Wed) by Trelane (subscriber, #56877)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
I would always prefer to not have my hardware held captive by a corporation if I can reasonably prevent it.
Perfection is the enemy of good
Posted Oct 15, 2025 2:15 UTC (Wed) by mikebenden (guest, #74702)In reply to: Perfection is the enemy of good by dskoll
Parent article: The FSF's Librephone project
I happen to fully agree with this perspective (hardware is a program compiled into a graph of gates, then either carved into silicon or configured into an fpga).
Working on that premise, where *should* the line rightfully be drawn between "give the users source so as to respect their freedom" vs. "it's obtuse of <insert activist / organization name here> to insist that source at/below this level of abstraction be provided so as to respect users' freedom" ?
Define “prompt”
Posted Oct 15, 2025 2:13 UTC (Wed) by Baughn (subscriber, #124425)Parent article: The FSF considers large language models
- Discuss a problem with the LLM. The LLM autonomously reads large parts of the repository you’re working in, during the discussion.
- Ask it to write a plan. Edit the plan. Ask it about the edited plan. Edit it some more.
- Repeatedly restart the LLM, asking it to code different parts of the plan. Debug the results. Write some code yourself. Create, rebase, or otherwise play around with the repository; keep multiple branches of potential code.
- Go back and edit the original plan, now that you know what might work. Port some unit tests back in time, sometimes.
- Repeat until done.
There is a prompt. Actually, there are many prompts, all conveniently stored in verbose JSONL that also requires point in time snapshots of the repository you’re working in to make sense of.
If someone were to ask me for that, I wouldn’t know where to start. It’s like asking for a recording of my desktop so they can be sure I’m not doing something they disapprove of.
Perfection is the enemy of good
Posted Oct 15, 2025 1:34 UTC (Wed) by dskoll (subscriber, #1630)In reply to: Perfection is the enemy of good by rsidd
Parent article: The FSF's Librephone project
The FSF is ok with hardware that implements a function, no matter how complicated or buggy, but not with blobs that implement the same function and can be upgraded.
With modern hardware, this distinction is even less meaningful because the hardware is likely synthesized from VHDL or Verilog, which you could look at as being software written for a very weird machine architecture. So even the hardware itself is really just "frozen" software.
Perfection is the enemy of good
Posted Oct 15, 2025 1:09 UTC (Wed) by rsidd (subscriber, #2582)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
Not only that, those blobs are actually better (for the user) than if they were hard-coded into the chips. A blob can be upgraded (proprietary or not), plus it's a lot cheaper. The FSF is ok with hardware that implements a function, no matter how complicated or buggy, but not with blobs that implement the same function and can be upgraded.
In the context of CPU microcode the FSF's attitude is even worse, as well laid out here.
In the context of mobile phones, are they planning to develop the hardware as well as the software? Because commercial manufacturers will have zero interest in doing so.
Perfection is the enemy of good
Posted Oct 15, 2025 1:01 UTC (Wed) by ttuttle (subscriber, #51118)In reply to: Perfection is the enemy of good by hailfinger
Parent article: The FSF's Librephone project
Perfection is the enemy of good
Posted Oct 15, 2025 0:42 UTC (Wed) by hailfinger (subscriber, #76962)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
I love my postmarketOS phone and it is the most mobile Linux "desktop" I ever had, but it fills a different niche (Linux+mobile feeling) compared to the Android feeling. For me, right now the answer for "postmarketOS vs. LineageOS" is "both", each on its own device.
That said, I mostly agree with the previous poster on the unfortunate requirement of proprietary firmware blobs as those are not likely to go away soon. Having a free Android-style kernel+userland combined with firmware blobs is probably a realistic 2-year goal on a very limited set of phones. If blob-free implementations are a hard requirement, the easiest way to go forward is to remove/outsource the mobile radio functionality to a dedicated device and use VoWiFi on a blob-free handset. That way you could even get a RYF certification for the handset because the blobs live in a different device. The usuability would be severely limited, though.
Perfection is the enemy of good
Posted Oct 15, 2025 0:37 UTC (Wed) by ttuttle (subscriber, #51118)In reply to: Perfection is the enemy of good by pizza
Parent article: The FSF's Librephone project
The RISC-V distribution that nobody can use (except in qemu)
Posted Oct 14, 2025 22:39 UTC (Tue) by jmalcolm (subscriber, #8876)In reply to: The RISC-V distribution that nobody can use (except in qemu) by jmalcolm
Parent article: Ubuntu 25.10 released
https://www.eetimes.com/tenstorrent-productizes-risc-v-cp...
Same for Akeana unfortunately:
https://www.akeana.com/introducing-the-akeana-5000-series...
The Zhihe A210 is "released" but I am not sure where you buy one. We may be able to buy RVA23 silicon in 2025 but 2026 is more likely.
Perfection is the enemy of good
Posted Oct 14, 2025 22:29 UTC (Tue) by pizza (subscriber, #46)Parent article: The FSF's Librephone project
Nearly all modern hardware requires some sort of proprietary firmware blob to function... But those blobs barely register as a rounding error on the grand scheme of things (eg mandatory DRM and always-on ties to a datamining mothership)
The odd behavior of /dev/zero
Posted Oct 14, 2025 21:07 UTC (Tue) by roblucid (guest, #48964)In reply to: The odd behavior of /dev/zero by iabervon
Parent article: The phaseout of the mmap() file operation
would rely on sparse memory structures not actually using much memory that they had allocated. so there was no going back to the older way where
actual physical swap space was allocated to back what was asked for, because that broke stuff.
The big change came with shared libraries, prior to that it wasn't uncommon to link applications commonly used together and have the command name select functionality, thus saving page faults and sharing memory better; even later GNU fileutils was doing the same sharing common code.
On floppies ...
Posted Oct 14, 2025 20:49 UTC (Tue) by roblucid (guest, #48964)In reply to: Best news is ... by geert
Parent article: Jumping into openSUSE Leap 16
Floppies were more popular with Linux using PC, they'd improved a lot on the old true 5 1/4" floppies, having a plastic shell.
Later I did have them bundled with the Solaris sun4m arch workstations and I did find a use for them on desktop, as I'd store tripwire
instrusion detection software storing the data read-only on the bundled floppies,
I'd actually use that mainly to figure out the configuration changes and the files that GUI installers would put on machines as using
a GUI meant missing the good ole documentation and is in practice error prone and tought to replicate at scale.
The floppies were generally used for sharing (small) files with documentation people, translators and so on.
There was at one time requirement to use a DOS emulator and floppy drive, which the PC support installed with DOS
and had to be called back when their install caught a virus and stopped functioning. After that it had a virus scanner active too.
There were some FOSS tools around to write to floppy disks and convert files, but mostly networking was used,
the PCs becoming clients to a network of remote office servers, so UNIX was doing the distribution of data, with
PC clients using NFS taking over from an awkward DECnet system, which wasn't manageable at the scale we were
operating at, at least with a small team.
Why not a separate tmpfs?
Posted Oct 14, 2025 20:46 UTC (Tue) by fw (subscriber, #26023)In reply to: Why not a separate tmpfs? by gray_-_wolf
Parent article: Debian Technical Committee overrides systemd change
The revert did not bring back the separate mount point, though: https://salsa.debian.org/systemd-team/systemd/-/commit/92...
I don't know why things are done this way.
AI Garbage
Posted Oct 14, 2025 20:46 UTC (Tue) by bins (guest, #49492)In reply to: AI Garbage by mathstuf
Parent article: Firefox 144.0 released
no thank you.
(I'll keep my IronFox/LibreWolf as far as I still can)
[1] https://drewdevault.com/2025/09/24/2025-09-24-Cloudflare-...
confusing claim
Posted Oct 14, 2025 20:24 UTC (Tue) by NightMonkey (subscriber, #23051)In reply to: confusing claim by mattdm
Parent article: Firefox 144.0 released
confusing claim
Posted Oct 14, 2025 20:18 UTC (Tue) by mattdm (subscriber, #18)Parent article: Firefox 144.0 released
Which... is good news, really. I want my web browser to be a web browser. I assume the feature is paid product-placement, so of course it's made to sound more impactful and dramatic than it is.
rustc_codegen_gcc
Posted Oct 14, 2025 20:00 UTC (Tue) by josh (subscriber, #17465)In reply to: rustc_codegen_gcc by rywang014
Parent article: Gccrs after libcore
The RISC-V distribution that nobody can use (except in qemu)
Posted Oct 14, 2025 19:38 UTC (Tue) by riking (subscriber, #95706)In reply to: The RISC-V distribution that nobody can use (except in qemu) by jmalcolm
Parent article: Ubuntu 25.10 released