On Fri, 2020-11-27 at 20:57 +0100, Syds Bearda wrote:

Hi Dario,

Hi!

Really good point.

Well, thanks. Ah, FTR, when I said in my email "someone on telegram suggested Chromium", that was Syds here. :-)

I see 5 options: 1) installing extensions from within Gnome Software 2) adding a browser for extensions 3) adding a striped down browser for extensions, that is called 'gnome extension browser' 4) firefox flatpak gets the ability to install extensions 5) not including a browser

My preferred solution would be an add-in for Gnome Software, but as that's not possible at the moment i think adding a browser is pretty useful. Only problem i have with that is that the browser is not really useful for codec related browsing, that's for both Firefox and Chromium.

I install chromium in my setup as that's a browser i don't use and i can abuse it for just installing gnome extensions. But I'm sure most users would actually keep using it.

So if option 3 or 4 would work, that's okay as well.

Yes, so, basically, if we ship with Chromium pre-installed, users can use it for installing GNOME extensions, without having to modify the system with `transactiona-update`. This makes our base image bigger, and results in some duplication (i.e., 2 browsers) if afterwards the user also install the Flatpak Firefox. But I think the benefit of _not_having_to_ start fiddling with `transactional-update` *immediately* after finishing installing the system may make it worth paying such a price. After that, the user can of course stick to Chromium if she wants. And maybe add Packman and install codecs in a `trasactional-update shell` and stay on it (Chromium) indefinitely, if she so desires. Or she can just install Flatpak Firefox and forget about Chromium, and go back to it only for installing extensions (as you're doing yourself, IIUC).

For option 3 we need a maintainer for creating a stripped down version of for example chromium or firefox for just extensions.

And for option 4 we need to add flathub as a repo (if we want to use flathub as the preferred flatpak repo), add the firefox browser and hack the flatpak version to get out of its sandbox. And if we add firefox as a flatpak, we could also just install some other flatpaks for office, email, music, photos and videos for example.

Everyone can do whatever pleases him the most, of course. However, installing *all* apps as Flatpak (and, for now, that means via Flathub) is what we recommend, what we tell people to do in talks and what we (will?) document. So, sure, it makes sense to pick the browser from there as well. That's why we're extremely lucky that a Flatpak for a browser, with all the needed codec there already (or being automatically downloaded, for what matters) is available these days. And that's Firefox... In fact, I've tested quite a few other browsers available on Flathub, and not surprisingly, none of them except Firefox does that. In fact this, as I was saying to Neal in my other email, means that a good chunk of our users may never have to fiddle with Packamn in a `transactional-update shell`. There will probably be Flatpacks for Chromium/Chrome soon (Frederic one showed me the link of where they're working on that... I'll post it here if I find it again), but it's not there yet. Therefore, Flatpak Firefox is something I cherish truly and deeply, these days, and I don't want to give up on that. :-) That being said, any effort toward implementing any other --and probably even more suitable-- long term solution is certainly not wasted and, of course, absolutely welcome! Thanks and Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere)

Am 28.11.20 um 20:02 Uhr schrieb Syds Bearda:

Hi all,

I just typed 'sudo transactional-update' without a dup, pkg or shell option and it calls automatically for a zypper up, while i was expecting an error that says please add an option.

Also a zypper dup would make more sense then as my MicroOS desktop is based on TW and not Leap.

Is there a reason it calls for zypper up or is it something that could be changed?

Yes, that should be changed, but we haven't found the best way to do it yet: https://bugzilla.opensuse.org/show_bug.cgi?id=1171473 Options include: * Taking the value from https://kubic.opensuse.org/documentation/man-pages/transactional-update.conf... * Taking the value from the release package (https://bugzilla.opensuse.org/show_bug.cgi?id=1171463), i.e. trusting the distribution on how it wants to be updated. * Hardcode something different or introduce a custom logic as suggested in the original ticket. The value in transactional-update.conf is currently only used for the systemd timer and is set at installation time in the packages' %post script. I'd personally lean to just throwing that config value away and trust what the distribution says, but I haven't implemented that yet. In any case this would require a new command (such as `updatewithautomaticallydetectedupdatemethod`) as it still has to be possible to chain the commands (e.g. `transactional-update shell cleanup reboot `). Cheers, Ignaz

On Fri, 2020-11-27 at 14:49 -0500, Neal Gompa wrote:

On Fri, Nov 27, 2020 at 2:11 PM Dario Faggioli wrote:

...

So now the user is happy, because he/she can install GNOME extensions right away, but is also mad, because he/she needs two Firefox-es installed, if wanting to watch Netflix. :-(

I personally am all but sure about what we should do about all this.

So, again, thoughts? :-)

My perspective would be to ship Firefox as an RPM. Unfortunately, the pitfall we have right now is that we don't have a good mechanism for someone to add codecs to the system. This is a general problem we have to solve at some point, but the particularly nasty issue with Firefox is that we only have one option: Packman.

Yes, that is true. In the specific case of MicroOS Desktop though, adding codecs to the system may very well not be necessary. For instance, it has not been for me, and it's now quite a while that I use it as my daily driver. Now, of course it's not like every user is/will be me and is/will be doing the same things I do, but thanks to the fact that the Firefox flatpak has codecs already, a good chunk of them may very well be in this situation that they will never need to add Packamn for anything. And considering that one of the main selling point of this thing (at least one of my main selling points :-)) is that you don't need external repositories that, once added, makes the base OS different from what is developed and tested with OpenQA and hence less reliable, etc, etc, I'm super reluctant to give up on this! Sure, if there would be a package in the main repos that I should include in the GNOME Desktop pattern and, with it, h264 & friends would work out of the box on RPM Firefox, that would be a no-brainer. But that, 1) is not the case, and 2) is not something I can work on trying to make it the case right now. :-(

I think this might have been easier to solve if we had a similar arrangement with Cisco[0] to ship OpenH264 codecs to openSUSE users and preload the repo configuration for that on openSUSE systems. 

Eheh, indeed!

We could then have YaST pull it in at install-time. That would fix Firefox for H.264. And combined with fdk-aac-free[1], that would be sufficient to solve this dilemma. Firefox can use both of these to support WebRTC and other web video playback.

[0]: https://fedoraproject.org/wiki/OpenH264 [1]: https://src.fedoraproject.org/rpms/fdk-aac-free

Yes, in fact, I have now checked and confirmed, in my VM, that the RPM Firefox that come preinstalled with Silverblue can indeed play Netflix. :-) Thanks for the feedback and for the links. I knew that the situation was kind of like that on Fedora, but this gave me the excuse for going and actually trying it first hand. :-D So, they can install GNOME extensions and watch video streaming out of the box. Us, currently, we need to: flatpak install org.mozilla.Firefox to watch videos and: transactional-update pkg install && \ systemctl reboot to instal extensions. I'm fine with users having to do the former (until we manage to add flatpaks during install, but that's another story). I'm not fine with the user having to do both. Therefore, I'm leaning toward preventing them to have to do the latter, by doing it ourself... At least for now, as a short term solution. Of course, that does not mean that seeking a better solution is not important! Quite the opposite. But I believe we need a step-gap. Thanks and Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere)