Post AuSopXb2dBanNGhtL6 by lanodan@queer.hacktivis.me
 (DIR) More posts by lanodan@queer.hacktivis.me
 (DIR) Post #AuSmK0CqWdXKvmDuLI by mjg59@nondeterministic.computer
       2025-05-25T20:12:02Z
       
       1 likes, 1 repeats
       
       Them: code stored in an immutable physical form is hardwareMe: an Ubuntu live CD is hardware
       
 (DIR) Post #AuSopXb2dBanNGhtL6 by lanodan@queer.hacktivis.me
       2025-05-25T20:41:47.748666Z
       
       1 likes, 0 repeats
       
       @mjg59 *points at old stash of CD-RW*EEPROM
       
 (DIR) Post #AuSub867EnTVxhkkk4 by ignaloidas@not.acu.lt
       2025-05-25T21:46:28.904Z
       
       0 likes, 0 repeats
       
       @mjg59@nondeterministic.computer I think that what FSF is arguing for is essentially, licensing cooties. Proprietary code can exist and do whatever, as long as they don't need to touch it.
       
 (DIR) Post #AuTGLftc0T4X8ywMEK by developing_agent@mastodon.social
       2025-05-26T01:45:06Z
       
       0 likes, 0 repeats
       
       @ignaloidas @mjg59 Long as it's not on the filesystem where users might see it and start asking some very inconvenient questions.Side note: Hey, uh, there wasn't anything in those four software freedoms about studying software, was there?
       
 (DIR) Post #AuTGLgvm9uOgLyxbF2 by ignaloidas@not.acu.lt
       2025-05-26T01:50:12.113Z
       
       0 likes, 0 repeats
       
       @developing_agent@mastodon.social @mjg59@nondeterministic.computer funny question - when does it start being wrong?If there's a flash chip that is accessible by the ""main OS"" of the system but isn't writable, and to set up some peripheral, it has to set up a DMA transfer from that flash chip to the peripheral to upload the firmware, is that fine? What if there's no DMA hardware and the OS has to first read it out to main memory and then upload it? What if the flash is writable?You can try to be pure and do a religious type push about the values and the like to get more people involved with free softwareOr you can try to make stuff actually useful so that people want to use it because it's better, and get more people involved with open source software that way
       
 (DIR) Post #AuTUgwrrV2vNDj9yeu by developing_agent@mastodon.social
       2025-05-26T03:56:49Z
       
       0 likes, 0 repeats
       
       @ignaloidas @mjg59 I don't think much of that matters, if any at all.If it's available to the OS why *not* make it available to userspace? If it can be read, and especially if it can be written, why *not* make this available to an appropriately privileged process?It's not about trying to draw some arbitrary line between what should and should not be hidden. Why should anything ever be hidden or made inaccessible at all?
       
 (DIR) Post #AuTUgyG0KlpXWtSlvc by developing_agent@mastodon.social
       2025-05-26T04:16:50Z
       
       0 likes, 0 repeats
       
       @ignaloidas @mjg59 So many people apply the FSF's RYF guidance to say that firmware of various kinds should be *made* impossible to update, or should be *made* invisible/inaccessible, (proprietary firmware is given a passing mark if it's "rom" or if it's handled on cores isolated from the main CPU, etc) when it could be otherwise.But I don't think they'd be ok with any of this obfuscation or obstruction from a device maker shipping "FOSS" firmware. ("What good is this github repo if its ROM?")
       
 (DIR) Post #AuTUgzEGii2IXnetrU by ignaloidas@not.acu.lt
       2025-05-26T04:30:55.502Z
       
       0 likes, 0 repeats
       
       @developing_agent@mastodon.social @mjg59@nondeterministic.computer It might not literally say that, but some people did that stuff purely to make a useful device while still complying by the RYF by the letter (though not by spirit). And because of FSF's/GNU's ignorance on hardware projects, they draw the line that's convenient to do from a purely software perspective (can our software touch it? must be free software), without considering the broader implications around this decision (namely that it encourages hiding software).
       
 (DIR) Post #AuTUh3HbeF5B7JFccS by developing_agent@mastodon.social
       2025-05-26T04:17:00Z
       
       0 likes, 0 repeats
       
       @ignaloidas @mjg59 Makes me wonder if one could derive a contradiction between RYF and GPLv3, in some situation where you couldn't both satisfy anti-tivoization provisions AND RYF's requirement that proprietary firmware be in ROM. Perhaps a proprietary firmware kernel running a GPLv3 firmware userspace.
       
 (DIR) Post #AuTWHuFkHgL3mOWB8a by developing_agent@mastodon.social
       2025-05-26T04:46:03Z
       
       0 likes, 0 repeats
       
       @ignaloidas @mjg59 What I mean to say is that if you built an RYF device pretending that FOSS firmware was proprietary and took the measures outlined in the text of the RYF guidelines, if quickly looks ridiculous.But I guess if you asked an RYF drafter it's all worth it for defence against real proprietary code. :/
       
 (DIR) Post #AuTWHvkciMdGQRyLuC by ignaloidas@not.acu.lt
       2025-05-26T04:48:49.452Z
       
       0 likes, 0 repeats
       
       @developing_agent@mastodon.social @mjg59@nondeterministic.computer ah, I see your point now