this looks interesting, possibly very much in line with what I'd like for the 0G Project. <https://www.fsfla.org/0G>
a couple of questions that I couldn't answer just by looking at your slides: you mention no blobs, does that mean GNU Linux-libre or an otherwise cleaned-up kernel like Debian's, or no added blobs on top of those carried by the kernel Linux?
you mention several GNU/Linux distros under alternate approaches, but it wasn't clear whether your approach involved GNU userland, is that the case?
thanks,

this looks interesting, possibly very much in line with what I'd like for the 0G Project. <https://www.fsfla.org/0G>
a couple of questions that I couldn't answer just by looking at your slides: you mention no blobs, does that mean GNU Linux-libre or an otherwise cleaned-up kernel like Debian's, or no added blobs on top of those carried by the kernel Linux?
you mention several GNU/Linux distros under alternate approaches, but it wasn't clear whether your approach involved GNU userland, is that the case?
thanks,

(apologies if this post is a dupe; I'm still getting errors after long delays after trying to post it)
this looks interesting, possibly very much in line with what I'd like for the 0G Project. <https://www.fsfla.org/0G>
a couple of questions that I couldn't answer just by looking at your slides: you mention no blobs, does that mean GNU Linux-libre or an otherwise cleaned-up kernel like Debian's, or no added blobs on top of those carried by the kernel Linux?
you mention several GNU/Linux distros under alternate approaches, but it wasn't clear whether your approach involved GNU userland, is that the case?
thanks,

@lxo no blobs as in "no binary blobs/drivers that run on the CPU/GPU". So basically mainline Linux plus non-free firmware (where it can't be avoided atm (e.g. wifi)) plus a "GNU like" userland. When running #debian it's a GNU userland. pmOS uses musl libc instead of glibc).

thanks, I've downloaded your speech, will watch it soon

@agx @FrOSCon

Great talk!

@agx @FrOSCon Great talk! Out of curiosity, do you know what the state of the art is for mobile governors (dynamic frequency scaling) on mainline linux. One of my students has been playing around with Android's governors, and it's looking increasingly like even the defaults (one of which originates from mainline) are over-engineered for the phones we''ve tested on. I don't know what the frequency scaling options look like on the imx8, but there might be some low hanging power savings there.

@okennedy @FrOSCon We're using frequency scaling for both cpu and busses (devfreq) on the imx8 (#librem5). We intend to improve some bits regarding bw limit calculation but I think we have the low hanging stuff there covered (but would be happy to be proven wrong).

@agx @FrOSCon What we've been seeing on the snapdragons we've been testing with is that governor policies that adaptively scale CPU frequency are "butting heads" with the idle thread policy. That is, when running the idle thread, it seems like the kernel cuts all power to the core already, so there's not a huge benefit to scaling based on CPU load, which Android's defaults (at least one of which is inherited from linux) are configured to do...

@agx thank you! @FrOSCon