<samueldr>
(and this matters in the way they seem to require the system to not be able at all to interact with the proprietary bits; like how the librem 5 is using this exclusion for the DDR training, and doing gymnastics to hide the blob away)
<lejonet>
So basically, as long as the proprietary "secondary processor" doesn't interact with any part they want to claim is 100% free software, its okay?
<samueldr>
that's what RYF seems to indicate in the 2-3 paragraphs, and supportd by Purism using the clause that way
<samueldr>
and it's bonkers, since if/when an OSS component can be used on the component in the future, you cannot (through the system) upgrade to it
<samueldr>
you cannot either, in some situations, use the system to interact with it to study its workings, thus helping reverse engineering work, or better documenting its abilities
<samueldr>
I would rather that such blobs be put front and center, with some warning tape around "future improvement work required"
<samueldr>
than hide it under the floor tiles
<lejonet>
Interesting, I wonder how the hell librem 5 gets around gsm modems being more or less always proprietary then?
<samueldr>
hmmm, didn't think about that in respect of RYF
<MichaelRaskin>
By making the modem just react to a very limited and pretty standard interface, I think
<MichaelRaskin>
(and giving it its own RAM instead of the default modem)
<MichaelRaskin>
modem's expectation to access entire RAM as a privileged device
<samueldr>
USB and RNDIS seems to point towards something similar
<lejonet>
Because iirc that is the main reason why a 100% FOSS phone isn't practically doable yet, because there aren't any FOSS alternatives for a GSM modem
<samueldr>
yeah
<MichaelRaskin>
I think there are functionl alternatives but they are too useful to be certifiable…
<samueldr>
still, RYF, in my opinion, is not too good :(
<lejonet>
Yeah, with the whole "Oh, you're allowed proprietary blobs, but scope them off and you're fine" makes the point of the certification a bit moot
<samueldr>
I would have liked to see "ARYF" (almost respects your freedom) with points deduced, so ARYF(-2) for two things that are described
<lejonet>
Mhm
<lejonet>
Because known badness is always preferably to unknown badness
<samueldr>
yeah, imo
<samueldr>
like, you'd know that ARYF(-10) is worse in the Freedom respect than ARYF(-1)
<lejonet>
its in the same way that even a known bad product can be useful in comparison to an unknown bad product
<samueldr>
that there are 10 discrete components requiring work
<lejonet>
Mhm
<samueldr>
though -10 might be 10 easy to fix, while -1 is one major blob
<samueldr>
so it would need to always be attached to a description
<samueldr>
like a nutritional label
<lejonet>
Yeah, I would certainly prefer that
<samueldr>
like, the pine64 phone, as it is, would have ARYF(-2) at the very minimum, SoC initialization (in silicon) and the modem... might also have a firmware for wifi/bluetooth, don't remember off the top of my head
<MichaelRaskin>
Kind of funny that if Librem5 shipped a no-GSM fully-open PDA with a slot for an (optional, available at the same store, horrible-inside but with well-documented FOSS interface specification) extra GSM modem card, it would be promotion of proprietary offers in the same store and non-RYF
<samueldr>
for real? that's an amazingly contorted thought
<lejonet>
Oh boy, the whole GPL "taint" thing put in a completely different light lol
<MichaelRaskin>
Hm, or maybe one could say it is promoting nonfree hardware, not nonfree software
<MichaelRaskin>
Counting nonfree in-silicon stuff is another kind of worms in any case
<samueldr>
definitely is
<samueldr>
but I rather have a (provable) source dump of the SOC init stuff than nothing
<samueldr>
or rather, somewhat provable
<samueldr>
e.g. without such a thing you can't see if the silicon has weird boot modes, like booting from an HDMI dongle
<MichaelRaskin>
For it to make any sense, you need a clearly versionable dump of the SoC itself, though
<lejonet>
It would be amazing to be a fly on the wall during the discussion that lead to adding that lol
<samueldr>
the amlogic chip is designed for set-top boxes (tv boxes) mainly
<samueldr>
this allows a firmware-less "opt out" of their default boot chain for recovery
<samueldr>
it's an inelegant, but workable solution to their problem
<MichaelRaskin>
Also, even without making a decision, there is a high probability that a highest-throughput connection of a device has a direct access to the internal bus where a clever device could impersonate another kind of device.
<lejonet>
Yeah, just take a look at firewire
<MichaelRaskin>
PCMCIA firewire thunderbolt
<lejonet>
yeah
<lejonet>
External peripheals + DMA is a messy combo
<lejonet>
(not saying internal buses are better, but at least they usually take some effort to access)
<MichaelRaskin>
Apparently RDMA is currently being considered as an efficient thing to base the entire VM deployment infrastructure upon
<lejonet>
Remote DMA?
<MichaelRaskin>
Yes
<lejonet>
Riiiight
<lejonet>
That sounds like an awesome idea...
<lejonet>
You probably get helluva performance buuuut :P
<MichaelRaskin>
Not so much performance as power efficiency
<lejonet>
True
<MichaelRaskin>
Apparently this would not be such a great idea if there would be cost-effective mass-produced servers with higher RAM:CPU ratio, but with the current supply it might be efficient to produce just the small bits you need for RDMA on a deep-sleep server
<lejonet>
Yeah, was just going to write that in a cluster- setting, i.e. the compute density being very important, I can more understand RDMA, but those are usually also very closed systems, in the sense that not even the users really get real access to the hardware and such
<MichaelRaskin>
No-no, I hav eheard this discussed foir RDMA for deploying VMs, just because you usually have the RAM as bottleneck and want to send CPUs to sleep
<lejonet>
so basically, they want to cut away all the bus overhead by moving stuff through RAM directly, thus meaning that the CPU doesn't have to be active for transfers?
<MichaelRaskin>
Apparently the network is throughput-competitive with DDR RAM bus…
<MichaelRaskin>
And apparently right now people basically buy the cheapest set of servers having the desired amount of RAM
<MichaelRaskin>
So the idea is to use another server's RAM as local RAM (or a crazy-fast swap), and sending the remote CPU to sleep
<MichaelRaskin>
I have seen it discussed as research, not deployment-ready something yet.
<MichaelRaskin>
Although…
<lejonet>
So basically, host-based "NUMA" instead of inter-socket NUMA :P
<MichaelRaskin>
Pretty much
<lejonet>
I've seen those discussions coming up in various contexts, sounds like an interesting idea to have like a 4U server with a tiny CPU and tonnes of DIMM slots, and then make like SBC-like nodes that are basically just a CPU package and some VRM for density and powr efficiency
<MichaelRaskin>
If you have a 4U full of DIMM, just put there a slightly better CPU and now that's the VM runner you actually want
<lejonet>
if its "only" an insane RAM to CPU ratio you're looking for, yeah
<MichaelRaskin>
With modern software you kind of do
<lejonet>
For calculations, definitively
<MichaelRaskin>
If you want it to be a RAM carrier, then skip the CPU, just put enough of a vestigial motherboard and a CPU lookalike to run RDMA
<lejonet>
Yeah, that is what I meant with a "tiny CPU"
<MichaelRaskin>
Calculations might differ (but if you want more CPU per unit of RAM, there are reasonably priced solutions)
<lejonet>
More alike a microcontroller perhaps than a CPU
<lejonet>
Yeah
<qyliss>
I like RYF, but the name is bad
<qyliss>
The fundamential principle, which again isn't what they say, is that vendors shouldn't be able to have power over my hardware that I don't.
<qyliss>
(after they've sold it to me)
<qyliss>
Once you look at it through that lens, it makes a lot more sense.
<samueldr>
sure, but I think it would be better served like a facts label, rather than a single certification name
<samueldr>
the single label worked well for accessories, e.g. wireless adapters
<samueldr>
more complex systems, e.g. a computer, are inherently more... complex :)
<qyliss>
Yeah
<qyliss>
It would make more sense to individually certify (or not) each component.
<qyliss>
Some interesting news for us, btw, is that Raptor have started selling the new POWER CPUs (with ultravisor)
<qyliss>
And apparently a bit of a performance gain
<qyliss>
But they only do 4 and 8-core models so far
<MichaelRaskin>
Too bad it's unrealistic to verify that the secondary proprietary processors do have fixed behaviour (especially with network communication chips, but also in general with planned-obsolescence lifetime tracker etc., which could not even be disclosed to the full-device manufacturer)
<MichaelRaskin>
I think in some version of RYF rationale they did mention the attempt to define a fixed IC-like behaviour that happens to be implemented with a generic secondary CPU and static firmware, but the current version doesn't seem clear about all that.