00:29 <clover[m]> You don't like flatpak?

00:30 <clover[m]> I think everything I need is a flatpak with aarch64

00:30 <clover[m]> Vs code, dbeaver, brave browser, geary

00:44 <steev> i don't know why i'd run those and not their pre-built packages

00:44 <steev> but then, i use a distro that makes sense :P

00:52 <clover[m]> Touche

03:16 <robclark> steev: tbf more sandboxing is never a bad thing.. the flatpak approach seems solid but I wish we'd progress faster towards all flatpaks being fully sandboxed

03:17 <steev> but then i can't have as much fun :(

03:20 <robclark> there isn't a shortage of fun.. I was a bit tempted to try silverblue (but then again at this stage getting things working at all is an accomplishment and we don't have secure boot working)

03:21 <robclark> but in big picture, from reducing attack surface, flatpak is the the sorta direction we should be looking

03:22 <robclark> ie. keep core os small and immutable, and keep apps sandboxed

03:22 <clover[m]> Can you do terminal work in silverblue?

03:23 <HdkR> Is flatpak the one that thinks it is a good idea to ship video drivers inside the application binary?

03:23 <clover[m]> So you can't have it without secure boot?

03:23 <robclark> clover[m]: toybox

03:24 <robclark> HdkR: that isn't quite the right way to do it.. but otoh apps are already shipping drivers

03:24 <HdkR> Think that was the one where I tried running an application and the driver it shipped couldn't support my 6900XT. So I had to unpack it regardless

03:24 <HdkR> ew

03:24 <HdkR> I hate this future

03:25 <robclark> I mean, you could just solve all problems by unplugging your computer from the interwebs

03:25 <robclark> but putting head in sand doesn't make things better

03:25 <HdkR> Viable strategy if I was more security paranoid :D

03:26 <HdkR> My concern is these containers thinking shipping the drivers are a good idea, and then initialization time

03:27 <HdkR> Snap is notoriously bad at initialization time, and if Flatpak thinks shipping some decrepit mesa package is the solution then that's just a nightmare

03:27 <robclark> containers are for sure a good thing.. but there is room for discussion about how to implement

03:27 <robclark> tbh I'm toying with ideas about mesa completely isolated from kernel (yeah).. since webgpu is a thing that terrifies me

03:28 <robclark> (who thought it was a good idea to expose interwebs to gpu gl/vk drivers?)

03:29 <HdkR> I feel like browsers need to have these things default disabled just like the old flash blockers

03:29 <HdkR> Maybe with a canvas overlay which allows you to quickly enable that canvas to run your shadertoy canvas or HTML game

03:30 <HdkR> At that point it just becomes a paradigm for good experiences rather than bombarded with garbage trying to hack your machine

03:31 <robclark> maybe.. but I kinda doubt that is enough

03:31 <robclark> turns out bad guys are creative

03:32 <HdkR> It's very true

03:33 <HdkR> and human potatoes are very bad at determining nefarious plots

03:33 <robclark> I'm kinda thinking about virtgpu native ctx approach without vm.. where you just split access to kernel to a trusted proxy (possibly rust, but at least small/auditable/fuzzable).. ie. just plan on UMD getting owned and make it so that doesn't matter

03:34 <robclark> obv not the thing to use for trusted things.. but for browser context it makes tons of sense because you'd be crazy to trust the interwebs

03:36 <HdkR> I think that sounds reasonable for security reasons

03:37 <robclark> the only alternative I see is teaching my parents to use lynx.. and that seems harder ;-)

03:40 <HdkR> Might be a bit hard for them to navigate facebook

03:42 <robclark> or, like.. anything these days

03:57 <clover[m]> <robclark> "clover: toybox" <- Interesting

08:38 <jhovold> steev: thanks for the heads up, it does not seem like this was ever reported on the lists

08:40 <jhovold> all i see is this related thread were robclark explains why these registers differ from the vendor kernel:

08:40 <jhovold> https://lore.kernel.org/lkml/CAF6AEGva3ecxTOx3Yb+Wh-1K=jYA3tDo_aXg09jS9pzJupYExQ@mail.gmail.com/

08:40 <jhovold> but no on-list report to bamse regarding the a690 series

08:41 <jhovold> which also used the values from downstream

08:42 <jhovold> robclark: does it just affect those debug tools you mentioned in the thread above, or is there any other impact?

08:57 <steev> iirc HdkR needed it for something fex related

09:08 <HdkR> Was necessary for crashdec and fdperf I think

09:09 <HdkR> and probably useful for the people that use perfetto as well

11:24 <HdkR> `VmPTE: 7024 kB` Spicy, I wonder how that relates to native execution

14:28 <robclark> jhovold: needed for fdperf and perfetto... maybe it was on IRC that I mentioned it

15:06 <HdkR> VmPTE Native versus emulated. 2828 KB versus 16312 KB respectively. That's spicy