**** BEGIN LOGGING AT Thu Feb 04 02:59:59 2016 **** BEGIN LOGGING AT Thu Feb 04 04:10:39 2016 Feb 04 23:01:24 (([2016-02-02 Tue 11:39:40] PaulFertser: the critical issue is whether the firmware is upgradable)) critical for what or whom? The point is you can't prove that there's *no* sekrit path to upgrade blobs, even when stored on a flash in the peripheral system. Ever Feb 04 23:05:14 and while we're at it: let's define a UYL to obsolete RYF :-)) http://talk.maemo.org/showthread.php?p=1497467#post1497467 Feb 04 23:06:30 topmost criterion to actually replace the basically useless RYF by something better: make it a rating rather than a "all or nothing" cert Feb 04 23:08:18 RMS only needs to "draw a line somewhere" because of his goal is all-or-nothing. If you don't focus on a finish line to cross, you can have a very useful distance in meters since start or til finish Feb 04 23:10:04 we're doing that all the time, see "GTA04 is more|less open than GTA02". Just when it comes to FSF and RYF approval, it's a "sorry, doesn't qualify for a badge" Feb 04 23:12:20 it's easy to evidence that no mobile phone ever can be RYF compliant. If RYF is ever granted to a mobile phone, then by mistake, ignoring the fact that you can't prove the non-update-ability of the radio firmware Feb 04 23:13:34 there is a legal requirement that user cannot update the modem with his own modified firmware Feb 04 23:15:04 however there's a technical need that manufacturer at least one time provides a firmware to the silicon, and unless this was a mask programmed ROM, you can't ever prove that it's not updatable Feb 04 23:16:31 conclusion: modems are always updateable, it's just a question how. And modems must not comply with RYF, according to law Feb 04 23:22:56 FSF clearly failed to define the borders of their domain of responsibility. To me it seems they tried to use the outer case of a device as border. They rather should have defined it on a logical system level, where buses and interfaces are the natural borders of a (software/OS eco)system Feb 04 23:24:49 when I connect a peripheral to a computer system via a bus, it's really irrelevant if the peripheral sits on a PCB in a USB dongle, or it's on the same PCB like the main CPU but still connected via USB only Feb 04 23:25:45 it's also irrelevant if there's a common case around both, and if there's a USB connector anywhere on the USB bus between the peripheral and the system Feb 04 23:30:09 as long as the 'GNU/linux CPU' can completely control the peripheral and even shut it down, and the linux system still works when the peripheral is down, when furthermore the peripheral can't change the program text the GNU/linux CPU is running, then I would define the peripheral irrelevant for any certification like RYF Feb 04 23:47:45 RMS shouldn't draw a east-west line and tell "you're too far south" or "you're ok, still on this side" - he should draw a line from all way north down to where the DUT is and then tell how long this line is Feb 04 23:51:41 this would *really* help customers who ask "how libre can it possibly get when I need a XY device?" and want to compare their options Feb 04 23:53:04 it would also yield much higher motivation for hw builders to try and get a good rating, rather than making them shrug away a RYF cert that's simply not realistic at all Feb 04 23:54:48 thus: let's do UYL :-D Feb 05 00:07:53 would be fun to evaluate a RYF-certified PC and find all the ignored assumptions about "chip X is a blackbox" where actually you can't prove it can't get firmware-updated Feb 05 00:09:38 eMMC, display controller and keyboard are only a few that come to mind instantly Feb 05 00:12:16 battery management, smb, let's not even start about any XY-drives Feb 05 00:13:38 show me a optical or HD Drive or even a SSD that does _not_ have a firmware, and of course that firmware is updatable Feb 05 00:15:07 however _all_ those have one thing: a properly defined interface to separate them from the GNU/linux CPU domain Feb 05 00:19:07 none has any embedded code that is supposed to run on the GNU/linux CPU without the user (by proxy of a FOSS program) actively pulling data and then converting that data into program text Feb 05 00:24:22 technically your disk holds the program data :° Feb 05 00:37:56 emphasis on data Feb 05 00:38:36 it becomes program text by CPU actively converting it from data into executable Feb 05 00:39:42 the only program text per definitionem, which you can't help but let the CPU execute is the very first bootloader code Feb 05 00:40:30 on a PC that's called BIOS Feb 05 00:46:26 and before that gets loaded, you basically always have some "hardwired" code to read that bootloader code from wherever it's stored. This hardwired code is often inside CPU and hardly ever documented or FOSS or user modifiable. So if you want to go to that extreme, there's no computer-alike device at all that could really 100% comply a pure RYF Feb 05 00:50:57 the question is if you trust this hardwired code to always work the way it's specified to do. At least when you're concerned about your freedom and not about extorting hardware manufacturers rsp chip makes to comply with some political requirements you stated Feb 05 00:52:51 when you don't trust, then you also need to evaluate the chip design and even the physical basics about how semiconductors work Feb 05 00:55:10 likewise you have to trust the HDD firmware to not modify your data between writing and reading Feb 05 00:58:57 but now we're deep into the question what "Freedom" actually means, in RYF Feb 05 00:59:34 or in FSF Feb 05 01:01:13 it's difficult when we have a GPL and only look at software. It gets unmanageable when it comes to hardware Feb 05 01:05:38 even software GPL implies there's a limit where it simply ends. It's for example the microcode that defines how a single cpu operation actually gets executed and implemented Feb 05 01:08:09 you always have axiomatic elementary buolding blocks you take as given. in software those are for example opcodes. in hardware I'd suggest we should take chips and their interfaces as such "atomic" building blocks, no matter if they have a firmware or not Feb 05 01:11:06 in software / opcodes you have a increment and a arcsin() function. In hardware you have a I2C-LED-controller and a modem. As examples of simple and complex building blocks **** ENDING LOGGING AT Fri Feb 05 02:59:59 2016