[opensuse-kubic] MicroOS Desktop & GNOME Extensions
Hello, So, I was giving some thoughts at the matter in the subject of this email, and here's what I came up with. Personally, I do use a few extensions; not that many, but a few. I also don't think I have spoken with any GNOME user that has not needed and/or installed at least one. Therefore, I'd say it's quite important to have a way to install them, ideally one that is available right after install, without having to fiddle with and tweak the system. Right now we're not shipping any browser. we were shipping Firefox, but got rid of it, since there is a Flatpak. But the flatpak can't handle the extensions. The issue is known, is being debated and maybe will even be fixed at some point. But that may take a while. Some links: https://bugzilla.mozilla.org/show_bug.cgi?id=1633206 https://bugzilla.mozilla.org/show_bug.cgi?id=1621763 https://www.reddit.com/r/gnome/comments/g2emg7/extensionsgnomeorg_firefox_fl... https://discussion.fedoraproject.org/t/firefox-flatpak-on-flathub-beta/17878... The last one contains a workaround, but I don't see it as something that we can easily (at some point) put in place like by default, or document and expect users to understand and follow it, TBH. As an alternative, there's this app, available as Flatpak, but it does not handle the installing part of the extension workflow, so it's kind of useless for the purposes of this discussion: https://flathub.org/apps/details/org.gnome.Extensions The only solution I currently see, is to do it from a browser installed in the system, with RPMs. And on that ground, I think we should go back and add one, by default. This of course would apply to the GNOME flavor only. I mean, if we want it in KDE too, for whatever other reason, I don't personally object or anything, I just don't think it'd be necessary there. Thoughts so far? Well, it gets trickier. In fact, if you're tempted to say "Ok, let's go back to including Firefox as an RPM by default", then think about this: what happens if an user then try to use this version of Firefox that we provide, for access multimedia content that requires the coded that we don't ship and that (typically) are in packman? Something like <<oh, there's a browser there already, let's watch Netflix in it!>>. Yeah, well, it does not work. OTOH, on the Firefox from Flathub, of course, it works like a charm. :-/ 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? :-) Thanks and Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On Fri, 2020-11-27 at 20:11 +0100, Dario Faggioli wrote:
And I forgot to add that it would be wonderful if Epiphany could handle GNOME extensions. In that case, we could include it, and then users will install the Firefox Flatpak (if they want, of course) without having two of them. But I just tried that, and it does not. Someone on Telegram suggested that we can ship Chromium instead. So far, this would be, I think, the best way forward... Regards again -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Hi Dario, Really good point. 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. 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. BR, Syds On Fri, Nov 27, 2020, at 20:43, Dario Faggioli wrote:
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. :-)
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).
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/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
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? BR, Syds
Am 28.11.20 um 20:02 Uhr schrieb Syds Bearda:
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 <autodetect_command_here>`). Cheers, Ignaz
On Fri, Nov 27, 2020 at 2:11 PM Dario Faggioli <dfaggioli@suse.com> wrote:
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. 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. 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 -- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, 2020-11-27 at 14:49 -0500, Neal Gompa wrote:
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. :-(
Eheh, indeed!
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 <browser_of_choice_but_beware_that_if_its_Firefox_you_will_have_two_instances_of_them> && \ 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/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On Fri, 2020-11-27 at 20:11 +0100, Dario Faggioli wrote:
And I forgot to add that it would be wonderful if Epiphany could handle GNOME extensions. In that case, we could include it, and then users will install the Firefox Flatpak (if they want, of course) without having two of them. But I just tried that, and it does not. Someone on Telegram suggested that we can ship Chromium instead. So far, this would be, I think, the best way forward... Regards again -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Hi Dario, Really good point. 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. 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. BR, Syds On Fri, Nov 27, 2020, at 20:43, Dario Faggioli wrote:
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. :-)
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).
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/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
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? BR, Syds
Am 28.11.20 um 20:02 Uhr schrieb Syds Bearda:
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 <autodetect_command_here>`). Cheers, Ignaz
On Fri, Nov 27, 2020 at 2:11 PM Dario Faggioli <dfaggioli@suse.com> wrote:
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. 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. 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 -- 真実はいつも一つ！/ Always, there's only one truth!
participants (4)
-
Dario Faggioli -
Ignaz Forster -
Neal Gompa -
Syds Bearda