Recently posted comments
blob or not to blob
Posted Oct 15, 2025 8:09 UTC (Wed) by joib (subscriber, #8541)In reply to: blob or not to blob by decorum
Parent article: The FSF's Librephone project
The x86 ecosystem being relatively open seems to be a historical anomaly. Manufacturers seem determined to not make that mistake again.
blob or not to blob
Posted Oct 15, 2025 6:23 UTC (Wed) by decorum (subscriber, #178110)Parent article: The FSF's Librephone project
Perfection is the enemy of good
Posted Oct 15, 2025 5:35 UTC (Wed) by marcH (subscriber, #57642)In reply to: Perfection is the enemy of good by Trelane
Parent article: The FSF's Librephone project
How so? I really fail to imagine the legal conspiracy here...
Firmware is just software and exists for the very same reasons. Why do people use software ? Hardware is faster after all!
Libre AI?
Posted Oct 15, 2025 4:42 UTC (Wed) by pabs (subscriber, #43278)Parent article: The FSF considers large language models
Personally I like Debian's document about that:
https://salsa.debian.org/deeplearning-team/ml-policy/
It would be very useful to have at least some of the former, for things like human language translation, noise removal from audio, text to speech, speech to text and so on.
Reusing firmware across kernel versions to save disk space?
Posted Oct 15, 2025 4:33 UTC (Wed) by raven667 (subscriber, #5198)In reply to: Reusing firmware across kernel versions to save disk space? by Cyberax
Parent article: Last-minute /boot boost for Fedora 43
We can rethink the mechanism around initrd instead of providing a filesystem image, just providing a filesystem, and see if that makes some of these other problems go away, by eg de-duplicating using hardlinks. The init has to be a minimal but full featured system to be able to accommodate whatever hardware setup is required before booting the main system and starting services, eg you could have iSCSI over WiFi with LUKS and graphical boot, which needs a bunch of software and firmware infrastructure to work. ISTM that most of that wouldn't change between instances or between the recovery system, so all boots could have access to the full recovery toolset without extra disk usage on the firmware-accessible filesystem.
I will say that having 3 kernels plus recovery seems extravagant, would not 2+recovery make more sense, the system you last successfully booted and the system you are trying to boot into seems like the amount of redundancy you need, what is the 3rd version for? What might be interesting as well is if the recovery tools can be layered on to one of the regular initrd, just loopback mounting it into /opt or /usr/local or something, so you can skip all the stuff which exists in the normal initrd and only have it contain files which are unique to recovery.
This is going in a different direction than UKI though as this is a more complex system to create and maintain with greater possibility that a flubbed upgrade corrupts it in some way that annoyingly half-works, UKI is about making it so simple that the EFI firmware can load it directly, it's just one file with one signature that either works or it doesn't.
Define “prompt”
Posted Oct 15, 2025 4:21 UTC (Wed) by mussell (subscriber, #170320)In reply to: Define “prompt” by Baughn
Parent article: The FSF considers large language models
Why was this a policy debate at all?
Posted Oct 15, 2025 4:01 UTC (Wed) by mjg59 (subscriber, #23239)In reply to: Why was this a policy debate at all? by raven667
Parent article: Debian Technical Committee overrides systemd change
Why was this a policy debate at all?
Posted Oct 15, 2025 3:49 UTC (Wed) by raven667 (subscriber, #5198)Parent article: Debian Technical Committee overrides systemd change
Why not a separate tmpfs?
Posted Oct 15, 2025 3:19 UTC (Wed) by lutchann (subscriber, #8872)In reply to: Why not a separate tmpfs? by fw
Parent article: Debian Technical Committee overrides systemd change
Progress with a Plan
Posted Oct 15, 2025 3:12 UTC (Wed) by josh (subscriber, #17465)In reply to: Progress with a Plan by Hello71
Parent article: Debian Technical Committee overrides systemd change
1) Modern flock, modern traditional lock, legacy traditional lock: The modern program has the lock, the legacy program waits until the modern program is done.
2) Modern flock, legacy traditional lock, modern traditional lock: the legacy program has the lock, the modern program is waiting on the traditional lock before it can run.
3) Legacy traditional lock, modern flock, modern traditional lock: The legacy program has the lock, the modern program is waiting on the traditional lock before it can run.
Perfection is the enemy of good
Posted Oct 15, 2025 3:03 UTC (Wed) by raven667 (subscriber, #5198)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 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.