qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
MichaelRaskin has quit [Ping timeout: 245 seconds]
MichaelRaskin has joined #spectrum
<lejonet> adisbladis: \o/
<qyliss> NICE
<samueldr> how many hidden proprietary blobs are respecting your freedom this time?
<samueldr> the "secondary processor" paragraphs here https://ryf.fsf.org/about/criteria
<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 looks at the docs
<samueldr> it might just be like the pine64 one
<samueldr> where it runs its own linux system
<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
<samueldr> sure
<samueldr> it's always going to be non-trivial
adisbladis has quit [Quit: WeeChat 2.4]
<lejonet> samueldr: wow, wtf
<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.
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined #spectrum