ALP WG Meeting minutes - July 5th 2022
Hi everyone, we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop. tl;dr; Fear not, you will not be forced to download random flatpaks or containers from dockerhub/flathub. We (probably) just change the deliver method, but the packaging workflow will stay the same. long version: Desktop in ALP (topic for next official ALP update at news-o-o) How can we dispell fears of users that we will shove containers & flatpacks down their throats: - we will use flatpak/containers as a distribution format, the packaging model will not change, only the format - the fear is not necessarily flatpaks (probably), but the fear that you'll have to pull everything from flathub/docker hub => stress out that you won't have to pull $randomStuff from the internet, you'll get audited software as you were before Questions that lkocman would ask Yi Fan on the meeting would be: * Some users are concerned that everything on their desktop will run in a container. Can you address these fears? - flatpak/containers just a distribution mechanism, packaging not going to change - ALP is still in flux, nothing set in stone - aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak) - possible solution for display manager & lower level things: https://github.com/fcrozat/gdm-container - will allow seamless updates with flatpaks installed on the host * Desktop not being part of PoC, but can we "tentatively" expect it in any snapshot after (Dec, May)? - gdm container makes good progress - good progress with Wayland issues like remote desktop (also upstream involvement) - maybe even have rough prototype in the PoC, will have more info this or next week * I'd really love to see desktop image that you simply dump to disk e.g. with self-install and first-boot wizzard that lets user to configure system. What's YiFan opinion about this? (SUSE IT wants this approach). - no concrete plans here yet - PoC will not have an installer, just a disk image will be the deliverable -> need to figure out how to run an installer or what to use here - Ancor is driving a workgroup to look into the traditional installation -> https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/Installation * Any tips, best practices for how to start with Desktop app development (Including things like Desktop Managers like XFce, Elightenment etc) in "openSUSE ALP" (Current reference for community part of ALP based distro, based on top of "base install image of ALP"). - for info, message Yifan directly (yfjiang@suse.com) or the ALP matrix room https://matrix.to/#/#alp:opensuse.org - currently focusing on upstream contributions (-> GNOME upstream) - downstream contributions go into Tumbleweed - for container specific stuff, maybe later, currently too much in flux - look into building flatpaks on OBS, this will become important very soon, so get started beforehands -> help OBS handling flatpaks & container images * Preferred way to distribute apps we know there will be ALP flathub repo in OBS, I think we could have something like "Community version of it". But we should be really smart about this, as the same app could work on top of (Community) ALP as well as Tumblweed. - would be possible to create * How many desktop environments will there be for ALP? Just GNOME like with SLED? - first focus on GNOME, might consider alternatives afterwards - will learn from going with GNOME first and apply this to others later on Maybe publish the Desktop WG results to the openSUSE Wiki as well And that's it for this week, see you again next week with Luboš back in the driver seat! Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
On 05.07.22 at 18:19 Michael Pujos wrote:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Just my 2 cents (not intending to start a flame war or bikeshedding): Basically I do not care which command I run to fully update my system. If "zypper dup" or "flatpak something" take care of that without breaking things, I am fine with it. ;-) I do not install things via rubygems or pip in addition to RPM packages, because then I would need to take care of two or more different things and would need to understand two or more distribution mechanism (and be able to debug them and answer funny questions on conflicts or similar). If it makes life easier for packagers and lets me (and the distribution) use "packages" from other distros more easily, then it sounds like a step in the right direction. I think many people are frustrated by examples like Canonical and their stunt with Firefox as a snap (which apparently broke some functions with KeepassXC). I have too little knowledge of flatpak to judge if it suffers from the same limitations as snaps. I have not followed the discussion closely enough, but my first thought was to build both rpm and flatpak out of the same source package in OBS. Not sure if that is possible. Have a nice day everyone! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi,
I have not followed the discussion closely enough, but my first thought was to build both rpm and flatpak out of the same source package in OBS. Not sure if that is possible.
It is absolutely fine, and it may be possible to fetch from rpm binary to compose a flatpak based on a properly maintained flatpak runtime. For the latter, we may rely on the current compile power and the current tool chain we have in place. Best wishes, Yifan
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
To jump in here, I'd like to highlight one stress point, that I simply don't understand yet: Disk space and it's associated performance impact. Here's what I get then I install the Firefox flatpak: (cropped for 80 characters line) ID Download 1. org.freedesktop.Platform.GL.default < 131.3 MB 2. org.freedesktop.Platform.Locale < 325.8 MB (partial) 3. org.freedesktop.Platform.VAAPI.Intel < 11.8 MB 4. org.freedesktop.Platform.ffmpeg-full < 4.2 MB 5. org.gtk.Gtk3theme.Breeze < 190.4 kB 6. org.freedesktop.Platform < 200.3 MB 7. org.mozilla.firefox.Locale < 45.5 MB (partial) 8. org.mozilla.firefox < 87.3 MB Now, the same for Gimp 1. org.gnome.Platform.Locale < 336.0 MB (partial) 2. org.gnome.Platform < 276.2 MB 3. org.gimp.GIMP < 126.9 MB I'm aware that flatpak re-uses shared libraries/packages, but having a large set of Desktop applications as flatpaks means unevitably, that you will have to install a desktop appliance twice. I e.g. need gnome as underlying desktop on my real machine, and then again as runtime for all applications that follow. In my understanding this means unevitably, in the best case I still have to duplicate packages that are in the range of several hundred MB if not GBs in size. This makes the task of performing system hygiene rather hopeless. What happens if packages rely on outdated or older versions of the platform? Will then e.g. org.gnome.Platform exist twice on that system? So while it from a maintainers perspective "there should not be that much of a difference", it means for the system users immediately two things: 1. it increases the maintenance load for every system because I need to check two package managers for updates 2. I have to accept that the Desktop system will be much heavier, both in terms of hard disk space and in terms of necessary RAM space required for efficient caching of the applications that I use Are my above mentioned statements true or do they arise from a (at least partial) misunderstanding of how flatpaks work? Best, Felix On Wed, 2022-07-06 at 09:15 +0200, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
Cheers,
Dan
Felix Niederwanger <felix.niederwanger@suse.de> writes:
To jump in here, I'd like to highlight one stress point, that I simply don't understand yet: Disk space and it's associated performance impact.
Here's what I get then I install the Firefox flatpak:
(cropped for 80 characters line)
ID Download 1. org.freedesktop.Platform.GL.default < 131.3 MB 2. org.freedesktop.Platform.Locale < 325.8 MB (partial) 3. org.freedesktop.Platform.VAAPI.Intel < 11.8 MB 4. org.freedesktop.Platform.ffmpeg-full < 4.2 MB 5. org.gtk.Gtk3theme.Breeze < 190.4 kB 6. org.freedesktop.Platform < 200.3 MB 7. org.mozilla.firefox.Locale < 45.5 MB (partial) 8. org.mozilla.firefox < 87.3 MB
Now, the same for Gimp
1. org.gnome.Platform.Locale < 336.0 MB (partial) 2. org.gnome.Platform < 276.2 MB 3. org.gimp.GIMP < 126.9 MB
I'm aware that flatpak re-uses shared libraries/packages, but having a large set of Desktop applications as flatpaks means unevitably, that you will have to install a desktop appliance twice. I e.g. need gnome as underlying desktop on my real machine, and then again as runtime for all applications that follow. In my understanding this means unevitably, in the best case I still have to duplicate packages that are in the range of several hundred MB if not GBs in size. This makes the task of performing system hygiene rather hopeless.
Not necessarily. If two flatpaks use the same version of the runtime, then you'll get it only once. If they depend on different versions, then you'll obviously have duplicates, but we should set policies in place to prevent this from happening.
What happens if packages rely on outdated or older versions of the platform? Will then e.g. org.gnome.Platform exist twice on that system?
Yes it will.
So while it from a maintainers perspective "there should not be that much of a difference", it means for the system users immediately two things:
1. it increases the maintenance load for every system because I need to check two package managers for updates
It would be great if this wasn't needed and zypper could update flatpaks as well. Michael and Benjamin mentioned in this thread that this would be possible to add.
2. I have to accept that the Desktop system will be much heavier, both in terms of hard disk space and in terms of necessary RAM space required for efficient caching of the applications that I use
The hard disk space requirement shouldn't be that much of a burden, as we do not want to have 50 different versions of gnome flying around. When it comes to RAM usage, I am actually not that sure. We'd have to check how flatpaks perform in this regard and whether any deduplication can be applied here. Cheers, Dan
On Wed, 2022-07-06 at 09:15 +0200, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
Cheers,
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hello On 2022-07-15 15:33, Dan Čermák wrote:
If two flatpaks use the same version of the runtime, then you'll get it only once. If they depend on different versions, then you'll obviously have duplicates, but we should set policies in place to prevent this from happening.
Huh? Perhaps I misunderstand what is meant with "runtime" here but isn't it the whole idea behind something like Flatpak that applications come with all their needed libraries and so on to make it possible that applications can run within a different runtime environment compared to what is installed on the host system? If openSUSE would have policies in place to prevent this (i.e. that applications depend on different versions of needed libraries and so on) from happening, then Flatpak would no longer make sense for openSUSE. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)
On 15.07.2022 17:01, Johannes Meixner wrote:
Hello
On 2022-07-15 15:33, Dan Čermák wrote:
If two flatpaks use the same version of the runtime, then you'll get it only once. If they depend on different versions, then you'll obviously have duplicates, but we should set policies in place to prevent this from happening.
Huh?
Perhaps I misunderstand what is meant with "runtime" here but isn't it the whole idea behind something like Flatpak that applications come with all their needed libraries and so on to make it possible that applications can run within a different runtime environment compared to what is installed on the host system?
If openSUSE would have policies in place to prevent this (i.e. that applications depend on different versions of needed libraries and so on) from happening, then Flatpak would no longer make sense for openSUSE.
AFAIU the idea is to build (open)SUSE flatpaks using some common run-time(s), not to block installation of other flatpaks not following it. There is no difference with RPM. Packages are built against some common baseline; when this baseline changes, packages must be rebuilt. Sometimes it is possible to have multiple baselines (Python, ...), but this requires a lot of RPM black magic and explicit support from the software in question. Flatpaks extend this to arbitrary software which does not have native ways to use multiple versions in parallel.
On 7/15/2022 8:01, Johannes Meixner wrote:
On 2022-07-15 15:33, Dan Čermák wrote:
If two flatpaks use the same version of the runtime, then you'll get it only once. If they depend on different versions, then you'll obviously have duplicates, but we should set policies in place to prevent this from happening.
Huh?
Perhaps I misunderstand what is meant with "runtime" here but isn't it the whole idea behind something like Flatpak that applications come with all their needed libraries and so on to make it possible that applications can run within a different runtime environment compared to what is installed on the host system?
Yes, "runtime" in terms of flatpak means a packaged set of some dependencies that can be shared between flatpaks. So a flatpak "can" come with all the needed libraries, but in that case every library would be duplicated for every app. So instead they can depend on a flatpak "runtime" which has a set of the base dependencies and only a few libraries in the app's flatpak. The idea then is to have policies which allow a "proper" mix of runtimes to allow for needed flexibility, but not so many that everything is getting duplicated over and over again. And I think finding that balance is much easier said than done. Especially when we are talking about these flatpaks being used on everything from SLES to ALP to Tumbleweed. -- Jason Craig
Hello, On 2022-07-16 20:45, Jason Craig wrote:
On 7/15/2022 8:01, Johannes Meixner wrote:
On 2022-07-15 15:33, Dan Čermák wrote:
If two flatpaks use the same version of the runtime, then you'll get it only once. If they depend on different versions, then you'll obviously have duplicates, but we should set policies in place to prevent this from happening.
Huh?
Perhaps I misunderstand what is meant with "runtime" here but isn't it the whole idea behind something like Flatpak that applications come with all their needed libraries and so on to make it possible that applications can run within a different runtime environment compared to what is installed on the host system?
Yes, "runtime" in terms of flatpak means a packaged set of some dependencies that can be shared between flatpaks. So a flatpak "can" come with all the needed libraries, but in that case every library would be duplicated for every app. So instead they can depend on a flatpak "runtime" which has a set of the base dependencies and only a few libraries in the app's flatpak.
The idea then is to have policies which allow a "proper" mix of runtimes to allow for needed flexibility, but not so many that everything is getting duplicated over and over again. And I think finding that balance is much easier said than done. Especially when we are talking about these flatpaks being used on everything from SLES to ALP to Tumbleweed.
Thank you for your clear and explicit explanation. Now I think I understand and things make sense: So I assume several openSUSE Flatpak runtimes are needed for each one of openSUSE's standard code streams e.g. basic system ones for SLE15/Leap15, ALP, Tumbleweed plus e.g. Gnome ones for SLE15/Leap15, ALP, Tumbleweed. Then openSUSE Flatpaks for some applications A and B could be based on openSUSE's Gnome Flatpak runtime for Tumbleweed because the applications A and B need some latest things and an openSUSE Flatpak for some application C could be based on openSUSE's basic system Flatpak runtime for SLE15/Leap15 because the application C needs some older things. In contrast a third-party Flatpak for some application X (possibly even a proprietary non-free application X) may contain all what it needs to run in its Flatpak so the third party can ensure its application can run (almost) everywhere and it runs in their tested environment. An ALP user who installs application A and B Flatpaks also gets the Gnome Flatpak runtime for Tumbleweed installed. An ALP user who installs application A and C Flatpaks also gets the Gnome Flatpak runtime for Tumbleweed and the basic system Flatpak runtime for SLE15/Leap15 installed. There might be a few duplicates of basic system things in the Gnome Flatpak runtime for Tumbleweed that are also in the system Flatpak runtime for SLE15/Leap15. An ALP user who installs application A, C and X Flatpaks also gets the Gnome Flatpak runtime for Tumbleweed and the basic system Flatpak runtime for SLE15/Leap15 installed. There could be some more duplicates via the X Flatpak that are also in the Gnome Flatpak runtime for Tumbleweed or in the basic system Flatpak runtime for SLE15/Leap15. I think this is the best possible way how ALP users can use applications which are not available for ALP. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)
On 7/6/22 09:15, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it. Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
Cheers,
Dan
I've been using Linux since forever. As time goes by, I try to simplify my computing experience with less software, not more. Especially, less hugely complex software. For example I'm not using KDE Plasma nor GNOME, but instead I use i3 (window manager) + a few simple helper programs. Or SDDM that I replaced with startx. Disabling Plymouth. That kind of stuff. Flatpak as you guessed, go against that philosophy, adding another layer of complexity and overhead. It also goes a bit against the concept of a coherent whole as we have now. What I am aiming at has nothing to do with misplaced minimalism for the sake of minimalism. For example, I do not care much that the distro pulls a ton of recommended packages (by default) that I never use. To get back to Flatpak, I do not deny it may solve real problems. But I absolutely do not need it on my PC, for my usage. I don't need to run Firefox, Thunderbird or some other desktop program containerized. I suppose I could get over it and forget it, but I really dislike that trend and added complexity. For the same reason, I do not use any Electron program. There will always be plenty of distros never making use of Flatpak and containerizing all the things, so there is choice, and that's good.
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/6/22 09:15, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it. Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
Cheers,
Dan
I've been using Linux since forever. As time goes by, I try to simplify my computing experience with less software, not more. Especially, less hugely complex software.
For example I'm not using KDE Plasma nor GNOME, but instead I use i3 (window manager) + a few simple helper programs. Or SDDM that I replaced with startx. Disabling Plymouth. That kind of stuff.
Flatpak as you guessed, go against that philosophy, adding another layer of complexity and overhead.
I would agree with complexity to a certain degree: yes, you have to use another binary to launch your applications. But then again, rpm is also adding complexity to your system. You could also just compile everything from source and you would not have to have rpm installed at all. Flatpaks are at the end of the day really just a different distribution method for packages.
It also goes a bit against the concept of a coherent whole as we have now. What I am aiming at has nothing to do with misplaced minimalism for the sake of minimalism. For example, I do not care much that the distro pulls a ton of recommended packages (by default) that I never use.
I fail to understand your point then. If you don't care about bloat by getting a ton of RPMs, what is the issue of getting your applications via flatpaks (which are according to you bloated as well)? I'd also like to add that the whole story is imho very coherent: the base OS will be RPM based and most of the applications will be added on top via containers and flatpaks (at least that's the current-very-in-flux-state-of-the-art). It's just a different story than it was before.
To get back to Flatpak, I do not deny it may solve real problems. But I absolutely do not need it on my PC, for my usage. I don't need to run Firefox, Thunderbird or some other desktop program containerized.
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I suppose I could get over it and forget it, but I really dislike that trend and added complexity. For the same reason, I do not use any Electron program.
There will always be plenty of distros never making use of Flatpak and containerizing all the things, so there is choice, and that's good.
Sure and Tumbleweed will stay as it is for the foreseeable future. It will probably get even more attention than it currently gets, because we will (probably) base a lot of our containers and flatpaks on Tumbleweed. So your use case will not be threatened by ALP. In contrast, I believe you'll benefit indirectly from ALP. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hello, Am 06.07.22 um 12:11 schrieb Dan Čermák:
I would agree with complexity to a certain degree: yes, you have to use another binary to launch your applications. But then again, rpm is also adding complexity to your system. You could also just compile everything from source and you would not have to have rpm installed at all.
yes, but after installation of software rpm is not involved in running the application, so it's not exactly the same.
Flatpaks are at the end of the day really just a different distribution method for packages.
to be honest, no, it's not. it's also running and isolating the application (and that's a good and important thing!). BUT: What i like about flatpak (and containers) is that we have a separation of system base and user land. system base can have a small set of rpm packages and applications/services can be separated from system base. Even if in the flatpak there are also rpms, but they cannot conflict with the rpms in the basesystem. it decouples userland-software-lifecycle and basesystem-software-lifecycle! This is good, guys! FreeBSD has that for ages and it helped them well. and Linux also does need that from my POV.
I'd also like to add that the whole story is imho very coherent: the base OS will be RPM based and most of the applications will be added on top via containers and flatpaks (at least that's the current-very-in-flux-state-of-the-art). It's just a different story than it was before.
i think there's fear that people will stop creating rpm packages and only deploy with flatpak/containers in the long term. if we could appease that sorrow more people would accept that we ALSO have flatpak/containers and that some people run their stuff mainly/only with that.
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
i totally agree, especially browsers are a popular attack surface. I do not want that my Firefox has file access by default to ~/.ssh or ~/.config/osc Also, let's be honest: for some reason we (as the whole linux ecosystem community) never built a secure desktop with Apparmor or SELinux. And if we have to tie system isolation methods to distribution methods, which also seems to work a little bit better with containers and infrastructure services, isn't that something we should try?
Sure and Tumbleweed will stay as it is for the foreseeable future. It will probably get even more attention than it currently gets, because we will (probably) base a lot of our containers and flatpaks on Tumbleweed. So your use case will not be threatened by ALP. In contrast, I believe you'll benefit indirectly from ALP.
i do not understand that last sentence though. i mean, normally we would secure applications with SElinux or Apparmor. how would classic systems/user benefit from new isolation/distribution methods in ALP? jm2c, kind regards, Dennis -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
On Wed 2022-07-06, Dennis Knorr wrote:
BUT: What i like about flatpak (and containers) is that we have a separation of system base and user land. : it decouples userland-software-lifecycle and basesystem-software-lifecycle! This is good, guys!
FreeBSD has that for ages and it helped them well. and Linux also does need that from my POV.
It's not that straightforward for FreeBSD even: over time more and more things have moved from src (= the core) to ports such that the former has become more barebones. That can be a good thing. It also means that even base tools can have essentially move to a rolling release model - which some consider a good thing, some are concerned about. It also means that various major release streams differ in their base and use the same set of ports (version, etc.) though built separately. Gerald
I've been using Linux since forever. As time goes by, I try to simplify my computing experience with less software, not more. Especially, less hugely complex software.
For example I'm not using KDE Plasma nor GNOME, but instead I use i3 (window manager) + a few simple helper programs. Or SDDM that I replaced with startx. Disabling Plymouth. That kind of stuff.
Flatpak as you guessed, go against that philosophy, adding another layer of complexity and overhead. I would agree with complexity to a certain degree: yes, you have to use another binary to launch your applications. But then again, rpm is also adding complexity to your system. You could also just compile everything from source and you would not have to have rpm installed at all.
rpm just has a packaging complexity. Once a rpm package installed, the program runs just as if you compiled it from source. Flatpak adds a runtime complexity, with its filesystem layering, permission system, integration with the base system and more...
It also goes a bit against the concept of a coherent whole as we have now. What I am aiming at has nothing to do with misplaced minimalism for the sake of minimalism. For example, I do not care much that the distro pulls a ton of recommended packages (by default) that I never use. I fail to understand your point then. If you don't care about bloat by getting a ton of RPMs, what is the issue of getting your applications via flatpaks (which are according to you bloated as well)?
I don't care about disk bloat. That is, packages installed on disk that get never used. I care about runtime bloat, or "added complexity" as I prefer to call it, which I would file Flatpak in that category.
I'd also like to add that the whole story is imho very coherent: the base OS will be RPM based and most of the applications will be added on top via containers and flatpaks (at least that's the current-very-in-flux-state-of-the-art). It's just a different story than it was before.
I hope that Flatpak will be limited to a few huge desktop programs. And not something like kcalc or gedit...
To get back to Flatpak, I do not deny it may solve real problems. But I absolutely do not need it on my PC, for my usage. I don't need to run Firefox, Thunderbird or some other desktop program containerized. You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
Firefox already has its own sandbox model already and has an AppArmor profile. How many layers of sandboxes does it need and where does it stop putting boxes into boxes to run software ?
Hello, Am 06.07.22 um 12:45 schrieb Michael Pujos:
rpm just has a packaging complexity. Once a rpm package installed, the program runs just as if you compiled it from source. Flatpak adds a runtime complexity, with its filesystem layering, permission system, integration with the base system and more...
well, yeah, that is the package manager. But on the other side, Flatpak does not change stuff all over the place like rpm (e.g. /etc) which makes it a little bit easier trusting 3rd party packages.
It also goes a bit against the concept of a coherent whole as we have now. What I am aiming at has nothing to do with misplaced minimalism for the sake of minimalism. For example, I do not care much that the distro pulls a ton of recommended packages (by default) that I never use. I fail to understand your point then. If you don't care about bloat by getting a ton of RPMs, what is the issue of getting your applications via flatpaks (which are according to you bloated as well)?
I don't care about disk bloat. That is, packages installed on disk that get never used. I care about runtime bloat, or "added complexity" as I prefer to call it, which I would file Flatpak in that category.
Wait, if you secure with AppArmor you also have added complexity. What's the difference in complexity between AppArmor and Bubblewrap? Or do you just not want to have ALL your applications secured, only a selected few?
I'd also like to add that the whole story is imho very coherent: the base OS will be RPM based and most of the applications will be added on top via containers and flatpaks (at least that's the current-very-in-flux-state-of-the-art). It's just a different story than it was before.
I hope that Flatpak will be limited to a few huge desktop programs. And not something like kcalc or gedit...
I also do not want kcalc or gedit or khelpcenter have access to ~/.ssh or ~/.config/osc. and it's surprisingly often that such niche applications are used for lateral movement/exploitation.
Firefox already has its own sandbox model already and has an AppArmor profile. How many layers of sandboxes does it need and where does it stop putting boxes into boxes to run software ?
Or.. we replace as default method AppArmor with Bubblewrap/Flatpak as this secures the application by default. For examples there are now numerous forks of Firefox and Chrome.. Nobody will write an AppArmor profile for them. But when they are distributed with Flatpak and their access to the system is already regulated. To be honest, i also have my gripes with all these new technologies and i am also not totally convinced, but they DO have some really good advantages. The future is certainly exciting, at least in that regard. :) Kind regards, Dennis -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
On 7/6/22 13:22, Dennis Knorr wrote:
I also do not want kcalc or gedit or khelpcenter have access to ~/.ssh or ~/.config/osc. and it's surprisingly often that such niche applications are used for lateral movement/exploitation.
I have a real hard time understanding this line of thinking. Do you trust /bin/ls ? vim ? should they also be sandboxed ? At some point you have to trust your system, whether it is about the closed source BIOS and firmware blobs, kernel, packagers, OBS, ...
Am 06.07.22 um 13:52 schrieb Michael Pujos:
On 7/6/22 13:22, Dennis Knorr wrote:
I also do not want kcalc or gedit or khelpcenter have access to ~/.ssh or ~/.config/osc. and it's surprisingly often that such niche applications are used for lateral movement/exploitation.
I have a real hard time understanding this line of thinking.
first: i admit, there's a fine line between sensibility and nonsense, but this line actually moves from attackers POV, sadly.
Do you trust /bin/ls ? vim ? should they also be sandboxed ?
yes and no. ls and vim work in a terminal on files. but should ls actually be open network connections? I think that should not be the case. BUT: in that case i would argue, that we do not need to sandbox ls as it does not have that many attack vectors, like khelpcenter, also ls is only called by programs (shell scripts) which need that functionality and ls also does not have the whole QT-library-shebang compiled in. The thing is: GUI Applications (like khelpcenter) have a much broader attack surface. For example, they have libraries and/or permissions to open network connections or write files. But why should khelpcenter write files? it shall only show html files from somewhere in /usr. but it can curl your ~/.ssh/privatekey to $attackerservice without you noticing because it can be loaded semiautomatically after an exploit calls it, because kmail is secured, but khelpcenter is not, but is called from there. also, even your terminal might be a problem, do you know https://github.com/Nudin/copy-paste-and-the-terminal ? Sadly we do not have a mechanism like pledge (from openbsd) where an application could state "after that stage, i just need read privileges on THAT directories" and the OS drops privileges for the rest. Therefore we need indeed mechanisms which enforce security policies for almost all bigger applications. And stuff like helper applications are a popular attack vector, if available. In practicality In the end, this is tradeoff between quite a few issues, but in the end, with some sense it is worth i in my opinion and experience.
At some point you have to trust your system, whether it is about the closed source BIOS and firmware blobs, kernel, packagers, OBS, ...
Yes, of course, but still, there's much unneeded attack surface, which can be avoided, relatively easily. also systems like qubes and android showed, it is possible to achieve a higher level of security here :) We just have to be sure that we do not brick classical systems and applications, if we can ensure that i am quite positive that we all will benefit from that :) Kind regards, Dennis -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Hi,
Do you trust /bin/ls ? vim ? should they also be sandboxed ?
yes and no. ls and vim work in a terminal on files. but should ls actually be open network connections? I think that should not be the case. BUT: in that case i would argue, that we do not need to sandbox ls as it does not have that many attack vectors, like khelpcenter, also ls is only called by programs (shell scripts) which need that functionality and ls also does not have the whole QT-library-shebang compiled in.
Well, vim at least actually had a quite big security hole with its modeline feature. IIRC, it's removed now, but sandboxing vim is still not a bad idea.
Sadly we do not have a mechanism like pledge (from openbsd) where an application could state "after that stage, i just need read privileges on THAT directories" and the OS drops privileges for the rest.
The Linux kernel offers seccomp (~pledge, but per-syscall) and landlock (~unveil, but subtractive and taking access mode into account). Sadly, not many applications make use of them. Alois
Am 06.07.22 um 15:18 schrieb Alois Wohlschlager:
Well, vim at least actually had a quite big security hole with its modeline feature. IIRC, it's removed now, but sandboxing vim is still not a bad idea.
Well, like, i do not disagree, but i wanted to make the difference a little bit more apparent. But yeah, sometimes vim also could be a problem. but not that serious as most GUI-with-Network-programs-which-only-calculates-dates.
Sadly we do not have a mechanism like pledge (from openbsd) where an application could state "after that stage, i just need read privileges on THAT directories" and the OS drops privileges for the rest.
The Linux kernel offers seccomp (~pledge, but per-syscall) and landlock (~unveil, but subtractive and taking access mode into account). Sadly, not many applications make use of them.
Exactly. we need landlock in every basesystem for that. AND: people have to accept seccomp. Many do not like containers, why should they accept seccomp? Kind regards, Dennis Knorr -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Hi,
Well, like, i do not disagree, but i wanted to make the difference a little bit more apparent. But yeah, sometimes vim also could be a problem. but not that serious as most GUI-with-Network-programs-which-only-calculates-dates.
Not sure I agree here. Complexity only translates into attack surface if it's actually exposed. The probability that an exploitable vulnerability in the GUI calculator is found is basically zero, because almost none of the complexity is exposed. Meanwhile, vim is arguably less complex, but exposed a lot of its complexity, so arbitrary code execution managed to slip through as a documented feature (!).
Exactly. we need landlock in every basesystem for that. AND: people have to accept seccomp. Many do not like containers, why should they accept seccomp?
Landlock and seccomp can be used by the applications themselves, without the need for a third-party container solution, same as with unveil and pledge on OpenBSD. For example, I know for a fact that all major browsers and the file tool use seccomp for sandboxing, and I think systemd and qemu do as well. Still, not many applications do this. I should probably start adding seccomp and landlock support to my simple toy applications as a positive example ;) Alois
Hi,
Well, like, i do not disagree, but i wanted to make the difference a little bit more apparent. But yeah, sometimes vim also could be a problem. but not that serious as most GUI-with-Network-programs-which-only-calculates-dates.
Not sure I agree here. Complexity only translates into attack surface if it's actually exposed. The probability that an exploitable vulnerability in the GUI calculator is found is basically zero, because almost none of the complexity is exposed. Meanwhile, vim is arguably less complex, but exposed a lot of its complexity, so arbitrary code execution managed to slip through as a documented feature (!).
Exactly. we need landlock in every basesystem for that. AND: people have to accept seccomp. Many do not like containers, why should they accept seccomp?
Landlock and seccomp can be used by the applications themselves, without the need for a third-party container solution, same as with unveil and pledge on OpenBSD. For example, I know for a fact that all major browsers and the file tool use seccomp for sandboxing, and I think systemd and qemu do as well. Still, not many applications do this. I should probably start adding seccomp and landlock support to my simple toy applications as a positive example ;) Alois
Dne 06. 07. 22 v 15:04 Dennis Knorr napsal(a):
Do you trust /bin/ls ? vim ? should they also be sandboxed ?
I do trust /bin/ls (more or less)? I absolutely do not trust vim with its various plugins which can do whatever. It is hard to do it for the universal text editor, but I think we are in a desperate need for some kind of protection against it (probably SELinux would be better tool here than docker/flatpak, though).
Sadly we do not have a mechanism like pledge (from openbsd) where an application could state "after that stage, i just need read privileges on THAT directories" and the OS drops privileges for the rest.
We have SELinux. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Somewhere at the edge of the Bell curve was the girl for me. -- Based on http://xkcd.com/314/
Hello, Am 09.07.22 um 13:32 schrieb Matěj Cepl:
Sadly we do not have a mechanism like pledge (from openbsd) where an application could state "after that stage, i just need read privileges on THAT directories" and the OS drops privileges for the rest.
We have SELinux.
SELinux does not have the same capabilities as pledge/unveil/landlock as SELinux does not know anything about the internal working structures, but the application knows when it can drop capabilities or privileges. But on the other side, it needs upstream developer support. Which is not necessary with SELinux. Kind regards, Dennis -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
On Wed, Jul 06, Michael Pujos wrote:
I've been using Linux since forever. As time goes by, I try to simplify my computing experience with less software, not more. Especially, less hugely complex software.
For example I'm not using KDE Plasma nor GNOME, but instead I use i3 (window manager) + a few simple helper programs. Or SDDM that I replaced with startx. Disabling Plymouth. That kind of stuff.
Flatpak as you guessed, go against that philosophy, adding another layer of complexity and overhead. I would agree with complexity to a certain degree: yes, you have to use another binary to launch your applications. But then again, rpm is also adding complexity to your system. You could also just compile everything from source and you would not have to have rpm installed at all.
rpm just has a packaging complexity. Once a rpm package installed, the program runs just as if you compiled it from source.
Which is not correct. Packagers tend to be lazy and only care about the packaging complexity...
Flatpak adds a runtime complexity, with its filesystem layering, permission system, integration with the base system and more...
... the same is true for packages, including how to migrate old configuation files and databases to a newer format. Looking at our bug reports for SLES (and thinking back at the decade where I was responsible for it): the biggest problem of our RPMs are that either packages make migration overcomplex or ignore it at all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key). If its not, then how is "put this into a fancy chroot with all deps" (that's how I understand containers ;)) "as isolated fromthe rest of your system as possible", because the Browser (for example) certainly then will still have access to outside of the chroot, or how would it save the downloads? Is there a architecture document describing how this is supposed to work (and why it is supposed to be better)= -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key).
That is the idea, if the flatpak has no permissions to read & write your home directory and has no access to the GNUPG sockets, then it cannot interact with GPG at all.
If its not, then how is "put this into a fancy chroot with all deps" (that's how I understand containers ;)) "as isolated fromthe rest of your system as possible", because the Browser (for example) certainly then will still have access to outside of the chroot, or how would it save the downloads?
This is achieved via so-called freedesktop portals. This is essentially an interface where an application requests to perform a certain action, like saving a file to the file system. The user then gets presented their usual file selection dialog and the file is saved where they want. However, the requesting application does *not* get access to the full filesystem, the actual saving is handled via the portal. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi Dan, On 06.07.22 17:41, Dan Čermák wrote:
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key).
That is the idea, if the flatpak has no permissions to read & write your home directory and has no access to the GNUPG sockets, then it cannot interact with GPG at all.
Good,
If its not, then how is "put this into a fancy chroot with all deps" (that's how I understand containers ;)) "as isolated fromthe rest of your system as possible", because the Browser (for example) certainly then will still have access to outside of the chroot, or how would it save the downloads?
This is achieved via so-called freedesktop portals. This is essentially an interface where an application requests to perform a certain action, like saving a file to the file system. The user then gets presented their usual file selection dialog and the file is saved where they want. However, the requesting application does *not* get access to the full filesystem, the actual saving is handled via the portal.
OK, so it really is somehow similar the the android way of "the application requests $ACCESS and the system default dialog for handling $ACCESS then takes care of the user knowing what's going on". This sounds useful for security, even if it might be annoying in some cases (I don't think we will see a gcc secured in such a way anytime soon ;-)) Thanks for explaining this! (Thinking: maybe we really should emphasize these benefits instead of the trivial "it's easy to run Tumbleweed Firefox on leap42.3 with flatpak" style of stories. Even though these also have their merits, at least to me the "better security" story sells it much better) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hello, On Wed, Jul 06 2022, Dan Čermák wrote:
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key).
That is the idea, if the flatpak has no permissions to read & write your home directory and has no access to the GNUPG sockets, then it cannot interact with GPG at all.
How difficult is it to enable that when it is desirable (and have it survive updates)? Specifically, in order to integrate the pass password manager[1] to Firefox, I use a browser plug-in[2] and a "host" script[3] which invokes pass to get the passwords, which internally runs GPG which needs to use the normal gpg-agent which needs access to my (password protected) keys. I've been thinking of putting FF into some firejail or something before, but was always afraid that the above scheme just would not work. And while isolating browser is good idea security-wise, passing each and every password through clipboard every single time it is used - which is the only alternative I can think of - looks less so. I expect similar problem with enabling plug-ins like GhostText[4]. Thanks for any insights, Martin [1] https://www.passwordstore.org/ [2] https://github.com/passff/passff [3] https://github.com/passff/passff-host [4] https://addons.mozilla.org/en-US/firefox/addon/ghosttext/
On Mittwoch, 6. Juli 2022 23:23:26 CEST Martin Jambor wrote:
Hello,
On Wed, Jul 06 2022, Dan Čermák wrote:
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key).
That is the idea, if the flatpak has no permissions to read & write your home directory and has no access to the GNUPG sockets, then it cannot interact with GPG at all.
How difficult is it to enable that when it is desirable (and have it survive updates)?
Specifically, in order to integrate the pass password manager[1] to Firefox, I use a browser plug-in[2] and a "host" script[3] which invokes pass to get the passwords, which internally runs GPG which needs to use the normal gpg-agent which needs access to my (password protected) keys.
I've been thinking of putting FF into some firejail or something before, but was always afraid that the above scheme just would not work. And while isolating browser is good idea security-wise, passing each and every password through clipboard every single time it is used - which is the only alternative I can think of - looks less so.
I expect similar problem with enabling plug-ins like GhostText[4].
Thanks for any insights,
Martin
[1] https://www.passwordstore.org/ [2] https://github.com/passff/passff [3] https://github.com/passff/passff-host [4] https://addons.mozilla.org/en-US/firefox/addon/ghosttext/
https://opensource.com/article/19/11/secrets-management-flatpak-applications Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hi Martin, Martin Jambor <mjambor@suse.cz> writes:
Hello,
On Wed, Jul 06 2022, Dan Čermák wrote:
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote:
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible.
I did not yet look into that crazy new stuff, but is this flatpak thing also doing it like android with an own userid for every program? I'd like to see something like that (with the browser unable to steal my gpg key).
That is the idea, if the flatpak has no permissions to read & write your home directory and has no access to the GNUPG sockets, then it cannot interact with GPG at all.
How difficult is it to enable that when it is desirable (and have it survive updates)?
Specifically, in order to integrate the pass password manager[1] to Firefox, I use a browser plug-in[2] and a "host" script[3] which invokes pass to get the passwords, which internally runs GPG which needs to use the normal gpg-agent which needs access to my (password protected) keys.
I've been thinking of putting FF into some firejail or something before, but was always afraid that the above scheme just would not work. And while isolating browser is good idea security-wise, passing each and every password through clipboard every single time it is used - which is the only alternative I can think of - looks less so.
I personally am using flatseal[1] to give or take permission to or from flatpaks. As long as your plugin only needs access to files or sockets, you should be fine by simply allowlisting these sockets or files via flatseal (you can achieve this via config files as well, I just find the GUI much simpler here). You can of course also allow the flatpak access to everything and then no issues should appear, but that would kinda defeat the purpose of the sandbox. Hope this helps, Dan Footnotes: [1] https://github.com/tchx84/flatseal -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi, Am 06.07.22 um 17:41 schrieb Dan Čermák:
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 06.07.22 12:11, Dan Čermák wrote: If its not, then how is "put this into a fancy chroot with all deps" (that's how I understand containers ;)) "as isolated fromthe rest of your system as possible", because the Browser (for example) certainly then will still have access to outside of the chroot, or how would it save the downloads?
This is achieved via so-called freedesktop portals. This is essentially an interface where an application requests to perform a certain action, like saving a file to the file system. The user then gets presented their usual file selection dialog and the file is saved where they want. However, the requesting application does *not* get access to the full filesystem, the actual saving is handled via the portal.
I tried (only very few) flatpak apps yet. One was rocket.chat. I stopped using it because I was never able to save file people sent me via rocket. Actually the app was behaving totally normal but I never were able to find any download on my whole system. That was on Tumbleweed just a few months ago. So let me ask the question how well this stuff really works as of today? Wolfgang
I guess I will join in... On Wednesday, July 6th, 2022 at 9:48 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Hi,
Am 06.07.22 um 17:41 schrieb Dan Čermák:
Stefan Seyfried stefan.seyfried@googlemail.com writes:
On 06.07.22 12:11, Dan Čermák wrote: If its not, then how is "put this into a fancy chroot with all deps" (that's how I understand containers ;)) "as isolated fromthe rest of your system as possible", because the Browser (for example) certainly then will still have access to outside of the chroot, or how would it save the downloads?
This is achieved via so-called freedesktop portals. This is essentially an interface where an application requests to perform a certain action, like saving a file to the file system. The user then gets presented their usual file selection dialog and the file is saved where they want. However, the requesting application does not get access to the full filesystem, the actual saving is handled via the portal.
I tried (only very few) flatpak apps yet. One was rocket.chat. I stopped using it because I was never able to save file people sent me via rocket. Actually the app was behaving totally normal but I never were able to find any download on my whole system.
That was on Tumbleweed just a few months ago. So let me ask the question how well this stuff really works as of today?
Wolfgang
The quality of a Flatpak probably depends a lot on what software it is. For example, I have this game on Steam which uses Steam Proton that would not boot out of the box on any (non-Debian) distro-packaged Steam, so I had to hunt down some dependencies for Arch, set some stuff in the config file for NixOS, and for openSUSE Tumbleweed I still don't know why it doesn't work. The reason why I don't know why it doesn't work is because I decided to give Flatpak Steam a shot, and literally on the first boot of the game it works. No crashes, no more me needing to dive into wikis. The same applies to my other games too. Also, since codecs can't be packaged into the official repo due to licensing issues. Mozilla's Flatpak of Firefox is more convenient for me as I don't have to worry about managing a codec repo when the Flatpak already has some of the codecs so I can say watch Youtube videos or Twitch streams. Gordon Leung
On 07/07/2022 00.07, Gordon Leung wrote:
I guess I will join in...
On Wednesday, July 6th, 2022 at 9:48 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 06.07.22 um 17:41 schrieb Dan Čermák:
Stefan Seyfried stefan.seyfried@googlemail.com writes:
On 06.07.22 12:11, Dan Čermák wrote:
I tried (only very few) flatpak apps yet. One was rocket.chat. I stopped using it because I was never able to save file people sent me via rocket. Actually the app was behaving totally normal but I never were able to find any download on my whole system.
That was on Tumbleweed just a few months ago. So let me ask the question how well this stuff really works as of today?
The quality of a Flatpak probably depends a lot on what software it is. For example, I have this game on Steam which uses Steam Proton that would not boot out of the box on any (non-Debian) distro-packaged Steam, so I had to hunt down some dependencies for Arch, set some stuff in the config file for NixOS, and for openSUSE Tumbleweed I still don't know why it doesn't work. The reason why I don't know why it doesn't work is because I decided to give Flatpak Steam a shot, and literally on the first boot of the game it works. No crashes, no more me needing to dive into wikis. The same applies to my other games too.
Also, since codecs can't be packaged into the official repo due to licensing issues. Mozilla's Flatpak of Firefox is more convenient for me as I don't have to worry about managing a codec repo when the Flatpak already has some of the codecs so I can say watch Youtube videos or Twitch streams.
And will the legal team approve openSUSE distributing such a flatpack with the codecs included? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Am 06.07.22 um 12:11 schrieb Dan Čermák:
Michael Pujos <pujos.michael@gmail.com> writes:
I don't need to run Firefox, Thunderbird or some other desktop program containerized.
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible. Browsers currently have the ability to view local files (file:///...), would we then cut that off? These could be files in a home directory, and there could be cross-links between them.
Also, as you're probably aware, Firefox and other browsers already have their own sandboxing for content processes that is much stronger than containers. (They only have a handful of syscalls available and cannot e.g. open any additional files.) Sandboxing content processes makes more sense to me than sandboxing the entire browser, because lots of valuable secrets are already in the browser (passwords, cookies, other private data). But they shouldn't escape to other webservers than the one they're intended for. These kinds of barriers can only be erected within the browser. Aaron PS: I was also made aware of <https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/> today, which is another kind of sandboxing within the browser.
On 08.07.22 01:41, Aaron Puchert wrote:
Am 06.07.22 um 12:11 schrieb Dan Čermák:
Michael Pujos <pujos.michael@gmail.com> writes:
I don't need to run Firefox, Thunderbird or some other desktop program containerized.
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible. Browsers currently have the ability to view local files (file:///...), would we then cut that off?
They would probably need to go through a system-provided file->open dialog (similar like when you want to open something from arbitrary storage locations on recent android) to get to these files. This extra dialog when something wants to "reach outside" the restrictions is what got me sold on the idea. I hate selinux and apparmor and the like just because they deny access without talking to me about it, and thus are IMHO a UI nightmare (Also the windows UAC popups "this application wants to change *something*" are useless, because they do not actually tell *what* is about to be changed and are (AFAIK) just "confirm that i might run something with sudo" notifications).
These could be files in a home directory, and there could be cross-links between them.
Also, as you're probably aware, Firefox and other browsers already have their own sandboxing for content processes that is much stronger than containers. (They only have a handful of syscalls available and cannot e.g. open any additional files.)
That's true. But huge, complex, network-connected programs processing mostly untrusted input -- IMHO every single layer of isolation around them is a good idea.
Sandboxing content processes makes more sense to me than sandboxing the entire browser, because lots of valuable secrets are already in the browser (passwords, cookies, other private data). But they shouldn't escape to other webservers than the one they're intended for. These kinds of barriers can only be erected within the browser.
Yes, sure. But my machine stores many more valuable secrets outside the browser and I welcome any additional protection. And -- at least that's how I understand it now -- you could still just allow "any <---> any" for a given flatpak in your configuration, so if you do not want that extra isolation, this should be the simple fix for you. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Friday 2022-07-08 08:11, Stefan Seyfried wrote:
This extra dialog when something wants to "reach outside" the restrictions is what got me sold on the idea. I hate selinux and apparmor and the like just because they deny access without talking to me about it, and thus are IMHO a UI nightmare (Also the windows UAC popups "this application wants to change *something*" are useless, because they do not actually tell *what* is about to be changed and are (AFAIK) just "confirm that i might run something with sudo" notifications).
UAC pauses the syscall, SELinux/Apparmor don't. (FUSE could, heh.) SEL/AA just deny the request. If the application then does not report the error in a way that means something to the user, it is the application's fault. Bad: perl -e 'if(!open(FH,"/etc/shadow")) { die $!; }' Good: perl -e 'if(!open(FH,"/etc/shadow")) { die "Could not open /etc/shadow: $!"; }' For example, take <img> HTML tags. If it cannot be loaded, browsers just put a placeholder icon and there is no alt="" text/tooltip defined for what happened. No strerror(errno) for file:-scheme objects, no "404"/"503" for https:-scheme images. Fuck browsers! The only thing that Linux has going against it that there is nothing like Extended Error Reporting. All you get is the integer from the syscall return value, and the caller cannot see whether file access failed due to an LSM, or regular file permission bits.
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 08.07.22 01:41, Aaron Puchert wrote:
Am 06.07.22 um 12:11 schrieb Dan Čermák:
Michael Pujos <pujos.michael@gmail.com> writes:
I don't need to run Firefox, Thunderbird or some other desktop program containerized.
You don't, but from a security standpoint, you really do want to run your browser as isolated from the rest of your system as possible. Browsers currently have the ability to view local files (file:///...), would we then cut that off?
They would probably need to go through a system-provided file->open dialog (similar like when you want to open something from arbitrary storage locations on recent android) to get to these files.
No, file:/// paths don't go through portals, so you really only get to see the parts of the filesystem that the flatpak is allowed to access. E.g. my Firefox can only fully access ~/Downloads and that's it. *However*, it is really trivial to give it more or less access via flatseal [1].
This extra dialog when something wants to "reach outside" the restrictions is what got me sold on the idea. I hate selinux and apparmor and the like just because they deny access without talking to me about it, and thus are IMHO a UI nightmare (Also the windows UAC popups "this application wants to change *something*" are useless, because they do not actually tell *what* is about to be changed and are (AFAIK) just "confirm that i might run something with sudo" notifications).
In theory SELinux supports showing you notifications via the SELinux Alert Browser, but SELinux errors are so obscure in practice, that I never even bother reading them, as I'd have more luck understanding APL :-/
These could be files in a home directory, and there could be cross-links between them.
Also, as you're probably aware, Firefox and other browsers already have their own sandboxing for content processes that is much stronger than containers. (They only have a handful of syscalls available and cannot e.g. open any additional files.)
That's true. But huge, complex, network-connected programs processing mostly untrusted input -- IMHO every single layer of isolation around them is a good idea.
Yes, but we have to be careful here, because flatpak's isolation can disable certain other sandboxing techniques. E.g. firejail does not work inside a flatpak (because it's a setuid root binary), so we should really carefully review each application whether the flatpak sandbox provides a net benefit or whether it disables a (potentially much stronger) application sandbox. For most applications that will be rather simple though, as they don't have any sandbox whatsoever ;-)
Sandboxing content processes makes more sense to me than sandboxing the entire browser, because lots of valuable secrets are already in the browser (passwords, cookies, other private data). But they shouldn't escape to other webservers than the one they're intended for. These kinds of barriers can only be erected within the browser.
Yes, sure. But my machine stores many more valuable secrets outside the browser and I welcome any additional protection.
And -- at least that's how I understand it now -- you could still just allow "any <---> any" for a given flatpak in your configuration, so if you do not want that extra isolation, this should be the simple fix for you.
Precisely. And I definitely also agree with Aaron here: flatpaks are not some magic silver bullet to make browsers more secure. A flatpak _can_ prevent a local code execution exploit in a browser reading my gpg or ssh keys, but it cannot prevent such an exploit from stealing my browser's cookies or passwords. That's something that the browser must setup themselves (and iirc Firefox and Chromium are getting pretty good at this). We definitely must ensure that this sandbox is not hampered by the flatpak sandbox though. Cheers, Dan Footnotes: [1] https://github.com/tchx84/flatseal -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/6/22 09:15, Dan Čermák wrote:
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
The point Michael seems to be making is that currently he can go to command line (or package manager in GNOME) and do `zypper in MozillaFirefox` and it's installed. And then when the system is updated with `zypper patch`, everything is updated. From a user standpoint, it's very important that having different technology behind it, like flatpak, does NOT break the user experience when it comes to keeping the system or the applications updated or installing the application in the first place. So it doesn't matter if it's flatpak or RPM or whatever, it's really important that we don't have a Windows-like experience when it comes to updates where everything is on its own. Our basic job is not to make RPMs - we are *integrators* and a distribution is an *integration*. Now, I have only talked about *user-end* applications. But there was also mention of pip and related in this thread -- those are not meant for user-applications but for application dependencies so are a different topic altogether. - Adam
Adam Majer <amajer@suse.de> writes:
On 7/6/22 09:15, Dan Čermák wrote:
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
The point Michael seems to be making is that currently he can go to command line (or package manager in GNOME) and do `zypper in MozillaFirefox` and it's installed. And then when the system is updated with `zypper patch`, everything is updated.
From a user standpoint, it's very important that having different technology behind it, like flatpak, does NOT break the user experience when it comes to keeping the system or the applications updated or installing the application in the first place.
So it doesn't matter if it's flatpak or RPM or whatever, it's really important that we don't have a Windows-like experience when it comes to updates where everything is on its own. Our basic job is not to make RPMs - we are *integrators* and a distribution is an *integration*.
This is a very good point! Michael, Benjamin, what's your take on this? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am 06.07.22 um 13:56 schrieb Dan Čermák:
Adam Majer <amajer@suse.de> writes:
On 7/6/22 09:15, Dan Čermák wrote:
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak). The point Michael seems to be making is that currently he can go to command line (or package manager in GNOME) and do `zypper in MozillaFirefox` and it's installed. And then when the system is updated with `zypper patch`, everything is updated.
From a user standpoint, it's very important that having different technology behind it, like flatpak, does NOT break the user experience when it comes to keeping the system or the applications updated or installing the application in the first place.
So it doesn't matter if it's flatpak or RPM or whatever, it's really important that we don't have a Windows-like experience when it comes to updates where everything is on its own. Our basic job is not to make RPMs - we are *integrators* and a distribution is an *integration*. This is a very good point!
Michael, Benjamin, what's your take on this?
I agree with that, this is why I suggested to have a unified tool to update the systems that can handle all sorts of different backends. rpm, flatpack, transactional etc etc. Back then ppl disagreed with the idea because the backends might be too different to be unified behind one tool ( I'm still convinced we could find a abstraction that works). So I did not follow up on the idea, but i still have a document describing it more in confluence if anyone is interested. It was written 2 years ago and would need some updating to match our current situation , the general idea would still be valid though. Btw, in theory libzypp also could handle different backends but it probably would need to match a package based concept. A admin moving between different SUSE installations should not have to use completely different set of tooling to keep the system up to date, but even more important the admin should not need to remember all the different sources where software was installed from. "Did we use flatpak or rpm on this machine, or both?" Cheers, Benjamin
On Wednesday 06 July 2022 16:01:31 Benjamin Zeller wrote:
Am 06.07.22 um 13:56 schrieb Dan Čermák:
Adam Majer <amajer@suse.de> writes:
On 7/6/22 09:15, Dan Čermák wrote:
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
The point Michael seems to be making is that currently he can go to command line (or package manager in GNOME) and do `zypper in MozillaFirefox` and it's installed. And then when the system is updated with `zypper patch`, everything is updated.
From a user standpoint, it's very important that having different technology behind it, like flatpak, does NOT break the user experience when it comes to keeping the system or the applications updated or installing the application in the first place.
So it doesn't matter if it's flatpak or RPM or whatever, it's really important that we don't have a Windows-like experience when it comes to updates where everything is on its own. Our basic job is not to make RPMs - we are *integrators* and a distribution is an *integration*.
This is a very good point!
Michael, Benjamin, what's your take on this?
I agree with that, this is why I suggested to have a unified tool to update the systems that can handle all sorts of different backends. rpm, flatpack, transactional etc etc. Back then ppl disagreed with the idea because the backends might be too different to be unified behind one tool ( I'm still convinced we could find a abstraction that works). So I did not follow up on the idea, but i still have a document describing it more in confluence if anyone is interested.
It was written 2 years ago and would need some updating to match our current situation , the general idea would still be valid though. Btw, in theory libzypp also could handle different backends but it probably would need to match a package based concept.
Yes, zypp is a bit package-centric. But if you can imagine to automatically build a 'flatpack:MozillaFirefox-VERSION_RELEASE.rpm's from some source, which upon their installation/update/removal install/update/remove the corresponding MozillaFirefox flatpack and you can also imagine to maintain your flatpacks via your repo of `flatpack:` rpms, then you can also think about integrating flatpack: into libzypp (of course without actually building such rpms). Then 'flatpack' would become a kind of Solvable, like package,pattern,patch and product. We did something like this long (long) time ago, as a POC for RubyGems, however incl. actually building such rpms. But the rapidyl increasing amount of 'real' ruby .rpms stopped it. Nowadays we would not need physical .rpms, though the rpm rules (naming,versioning,dependencies) must be applicable. I don't say it's little effort, but the route would be quite straight IFF flatpacks fir into the schema.
A admin moving between different SUSE installations should not have to use completely different set of tooling to keep the system up to date, but even more important the admin should not need to remember all the different sources where software was installed from. "Did we use flatpak or rpm on this machine, or both?"
Definitely. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres (he/him/his), Engineering & Innovation, ma@suse.com +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman +------------------------------------------------------------------+
On 7/6/22 20:51, Michael Andres wrote:
I don't say it's little effort, but the route would be quite straight IFF flatpacks fir into the schema.
Flatpaks are very application centric which, I would say, is a subset of package centric approach. So it appears we are good from a technological possibility point of view ;) - Adam
On 06/07/2022 09.15, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
What impact will it have on old hardware? I fear we will need larger and more power computers, more disk space, and more bandwidth for updates, and more CPU and RAM to cope with all this. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
On Fri 08 Jul 2022 11:27:03 PM CDT, Carlos E. R. wrote:
On 06/07/2022 09.15, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
What impact will it have on old hardware?
I fear we will need larger and more power computers, more disk space, and more bandwidth for updates, and more CPU and RAM to cope with all this.
Hi Carlos Why not try it out? I have MicroOS-Desktop GNOME running on a HP Pavilion Laptop, with google chrome, flatseal and GPU-Viewer flatpaks running. free -h total used free shared buff/cache available Mem: 11Gi 1.4Gi 7.9Gi 36Mi 2.2Gi 9.8Gi btrfs fi show / Label: none uuid: Total devices 1 FS bytes used 4.68GiB devid 1 size 232.38GiB used 7.02GiB path /dev/sda2 flatpak info com.github.tchx84.Flatseal | grep Installed Installed: 2.7 MB flatpak info io.github.arunsivaramanneo.GPUViewer | grep Installed Installed: 18.3 MB flatpak info com.google.Chrome | grep Installed Installed: 20.0 MB -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20220706 | GNOME Shell 42.2 | 5.18.9-1-default HP Z440 | Xeon E5-2690 V3 X24 @ 2.60GHz | AMD RX550/Nvidia Quadro T400 up 1 day 0:36, 2 users, load average: 0.06, 0.47, 0.57
On 08/07/2022 23.42, Malcolm wrote:
On Fri 08 Jul 2022 11:27:03 PM CDT, Carlos E. R. wrote:
On 06/07/2022 09.15, Dan Čermák wrote:
Michael Pujos <pujos.michael@gmail.com> writes:
On 7/5/22 17:46, Dan Čermák wrote:
- aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak)
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
Would you mind to elaborate why? I would like to stress out that you will not be "forced" to download Firefox from flathub. You will get the same Firefox as you get today from OBS, it will just be a flatpak and not an rpm so that it can be reused across all released distributions (actually any Linux distribution supporting flatpak).
What impact will it have on old hardware?
I fear we will need larger and more power computers, more disk space, and more bandwidth for updates, and more CPU and RAM to cope with all this.
Hi Carlos Why not try it out?
I have MicroOS-Desktop GNOME running on a HP Pavilion Laptop, with google chrome, flatseal and GPU-Viewer flatpaks running.
free -h total used free shared buff/cache available Mem: 11Gi 1.4Gi 7.9Gi 36Mi 2.2Gi 9.8Gi
This laptop has only 4 GiB, of which 1.3 is buff/cache this moment. You are using 11. So the answer to my question is "no". I need FF, Thunderbird, and LibreOffice to run simultaneously. My normal minimum load. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
On Sat 09 Jul 2022 10:43:10 PM CDT, Carlos E. R. wrote: <snip>
Hi Carlos Why not try it out?
I have MicroOS-Desktop GNOME running on a HP Pavilion Laptop, with google chrome, flatseal and GPU-Viewer flatpaks running.
free -h total used free shared buff/cache available Mem: 11Gi 1.4Gi 7.9Gi 36Mi 2.2Gi 9.8Gi
This laptop has only 4 GiB, of which 1.3 is buff/cache this moment. You are using 11. So the answer to my question is "no".
I need FF, Thunderbird, and LibreOffice to run simultaneously. My normal minimum load.
Hi No, only using 1.4 and 2.2 cached? Sure system has 12GiB. I've been running Fractal and also playing with lollypop today up some 6 hours with 1.3 used and 1.6 cached. If I drop the caches, the 1.6 drops to 0.7Gi. Can the system take extra RAM, or onboard? -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20220706 | GNOME Shell 42.2 | 5.18.9-1-default HP Z440 | Xeon E5-2690 V3 X24 @ 2.60GHz | AMD RX550/Nvidia Quadro T400 up 4:05, 2 users, load average: 0.23, 0.22, 0.28
Am Dienstag, 5. Juli 2022, 18:19:37 CEST schrieb Michael Pujos:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
My fullest agreement, Michael!!! I do not want the containers and do not think much of them. I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better. When I already read a faltpak within a RPM. What kind of bullshit is that? Or that there should be different runtimes for KDE, GNOME, Tumbleweed and so on. What a bullshit. There is nothing easier...... And if I read this correctly, then there is no more KDE for the time being, but only Gnome. Possibly later then KDE should come. (Stand in eatherpad info) Ne. Not with me. In my opinion, I've said before and I'll stick to it, this is a marketing stuff, which sooner or later backfires. You won't need less work and less people, but more. I have already looked at Manjaro and am currently working my way in. A great distro. And I also think it would be more performant. So if this container stuff comes, I'm gone from SUSE after about 20years. :-( Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Dienstag, 5. Juli 2022, 18:19:37 CEST schrieb Michael Pujos:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
My fullest agreement, Michael!!! I do not want the containers and do not think much of them. I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better. When I already read a faltpak within a RPM. What kind of bullshit is that? Or that there should be different runtimes for KDE, GNOME, Tumbleweed and so on. What a bullshit. There is nothing easier......
I would kindly ask you to refrain from calling some technology bullshit only because you don't see its use-case. This is not productive use of our time. One of the ideas that we have is to deliver the community packages of e.g. Firefox from Tumbleweed as flatpaks to ALP. This simplifies the work for the involved packagers and improves the security isolation and is imho everything but cow excrement.
And if I read this correctly, then there is no more KDE for the time being, but only Gnome. Possibly later then KDE should come. (Stand in eatherpad info) Ne. Not with me.
The situation in ALP is no different than it is in SLED! SLED ships only the GNOME desktop, yet somehow you are still able to use KDE on Leap and on Tumbleweed. The community is providing the KDE packages for Leap and the same could happen with ALP. Now with using flatpaks, we have the ability to use a single code stream to provide an up to date KDE for all ALP and openSUSE users, which would be an improvement over the current state.
In my opinion, I've said before and I'll stick to it, this is a marketing stuff, which sooner or later backfires. You won't need less work and less people, but more. I have already looked at Manjaro and am currently working my way in. A great distro. And I also think it would be more performant. So if this container stuff comes, I'm gone from SUSE after about 20years. :-(
Or you could just stick to Tumbleweed, which will not get this "container stuff". Or you can join our discussion and find a way how to make alp work for all of us. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Mittwoch, 6. Juli 2022, 14:18:22 CEST schrieb Dan Čermák:
Eric Schirra <ecsos@opensuse.org> writes:
Am Dienstag, 5. Juli 2022, 18:19:37 CEST schrieb Michael Pujos:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
My fullest agreement, Michael!!! I do not want the containers and do not think much of them. I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better. When I already read a faltpak within a RPM. What kind of bullshit is that? Or that there should be different runtimes for KDE, GNOME, Tumbleweed and so on. What a bullshit. There is nothing easier......
I would kindly ask you to refrain from calling some technology bullshit only because you don't see its use-case. This is not productive use of our time.
Please do not take this personally.
One of the ideas that we have is to deliver the community packages of e.g. Firefox from Tumbleweed as flatpaks to ALP. This simplifies the work for the involved packagers and improves the security isolation and is imho everything but cow excrement.
Sorry. But for me, this is just a really stupid idea. And for me, that's just total crap.
And if I read this correctly, then there is no more KDE for the time being, but only Gnome. Possibly later then KDE should come. (Stand in eatherpad info) Ne. Not with me.
The situation in ALP is no different than it is in SLED! SLED ships only the GNOME desktop, yet somehow you are still able to use KDE on Leap and on Tumbleweed. The community is providing the KDE packages for Leap and the same could happen with ALP. Now with using flatpaks, we have the ability to use a single code stream to provide an up to date KDE for all ALP and openSUSE users, which would be an improvement over the current state.
Could happen. But does not have to. And not at all in the beginning. SUSE is simply out of the picture.
In my opinion, I've said before and I'll stick to it, this is a marketing stuff, which sooner or later backfires. You won't need less work and less people, but more. I have already looked at Manjaro and am currently working my way in. A great distro. And I also think it would be more performant. So if this container stuff comes, I'm gone from SUSE after about 20years. :-( Or you could just stick to Tumbleweed, which will not get this "container stuff". Or you can join our discussion and find a way how to make alp work for all of us.
Tumbleweed doesn't get containerized stuff? I have read other things. That is another point of criticism. Can someone create a table with the differences between Leap, Leap ALP, Leap micro, Leap micoos, Tumbleweed, SLES, SLED. What differences are there in all the "versions". I don't know anymore. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 6. Juli 2022, 14:18:22 CEST schrieb Dan Čermák:
Eric Schirra <ecsos@opensuse.org> writes:
Am Dienstag, 5. Juli 2022, 18:19:37 CEST schrieb Michael Pujos:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
My fullest agreement, Michael!!! I do not want the containers and do not think much of them. I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better. When I already read a faltpak within a RPM. What kind of bullshit is that? Or that there should be different runtimes for KDE, GNOME, Tumbleweed and so on. What a bullshit. There is nothing easier......
I would kindly ask you to refrain from calling some technology bullshit only because you don't see its use-case. This is not productive use of our time.
Please do not take this personally.
One of the ideas that we have is to deliver the community packages of e.g. Firefox from Tumbleweed as flatpaks to ALP. This simplifies the work for the involved packagers and improves the security isolation and is imho everything but cow excrement.
Sorry. But for me, this is just a really stupid idea. And for me, that's just total crap.
I am not taking this personally, I am merely telling you that calling a technology or approach against which you have some kind of gripe "crap", "bullshit" and "really stupid" without bringing any arguments why is disrespectful and unproductive. Thus please back your claims with technical arguments and use a different language. This is not a place for such a language.
And if I read this correctly, then there is no more KDE for the time being, but only Gnome. Possibly later then KDE should come. (Stand in eatherpad info) Ne. Not with me.
The situation in ALP is no different than it is in SLED! SLED ships only the GNOME desktop, yet somehow you are still able to use KDE on Leap and on Tumbleweed. The community is providing the KDE packages for Leap and the same could happen with ALP. Now with using flatpaks, we have the ability to use a single code stream to provide an up to date KDE for all ALP and openSUSE users, which would be an improvement over the current state.
Could happen. But does not have to. And not at all in the beginning. SUSE is simply out of the picture.
In my opinion, I've said before and I'll stick to it, this is a marketing stuff, which sooner or later backfires. You won't need less work and less people, but more. I have already looked at Manjaro and am currently working my way in. A great distro. And I also think it would be more performant. So if this container stuff comes, I'm gone from SUSE after about 20years. :-( Or you could just stick to Tumbleweed, which will not get this "container stuff". Or you can join our discussion and find a way how to make alp work for all of us.
Tumbleweed doesn't get containerized stuff? I have read other things.
Tumbleweed will be the place where development is going to take place, but there are no plans to fundamentally alter Tumbleweed. You'll still be able to use Tumbleweed like you used before. Additionally, you'll be able to use the "containerized stuff", but you won't have to, at least for the foreseeable future.[1]
That is another point of criticism.
Can someone create a table with the differences between Leap, Leap ALP, Leap micro, Leap micoos, Tumbleweed, SLES, SLED. What differences are there in all the "versions". I don't know anymore.
- Leap is the community edition of SLES. - SLES is the enterprise operating system of SUSE, with the latest release being SLE 15 which might be the last SLE. - SLED is the desktop edition of SLE, i.e. it's SLE + GNOME desktop. It is fully supported by SUSE and thus only ships the GNOME desktop. - Leap Mirco/MicroOS is based on SLE MicroOS, which is essentially a small footprint version of SLE/Leap with transaction-update and utilizes a read-only root partition. - Leap ALP is a potential community version of ALP. Hope this helps, Dan Footnotes: [1] And yes, I have no idea how long "foreseeable future" is or what will happen in the next 10 years. So I cannot guarantee what will happen. -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On Wed 2022-07-06, Dan Čermák wrote:
- SLES is the enterprise operating system of SUSE, with the latest release being SLE 15 which might be the last SLE. - SLED is the desktop edition of SLE, i.e. it's SLE + GNOME desktop. It is fully supported by SUSE and thus only ships the GNOME desktop.
Note that SLES also provides GNOME. (SLED adds LibreOffice, for example, whereas SLES has virtualization host support.) Gerald
-- Syds Bearda Treasurer openSUSE Project opensuse@syds.eu On Wed, 6 Jul 2022, at 14:43, Dan Čermák wrote:
Eric Schirra <ecsos@opensuse.org> writes:
Can someone create a table with the differences between Leap, Leap ALP, Leap micro, Leap micoos, Tumbleweed, SLES, SLED. What differences are there in all the "versions". I don't know anymore.
- Leap is the community edition of SLES. - SLES is the enterprise operating system of SUSE, with the latest release being SLE 15 which might be the last SLE. - SLED is the desktop edition of SLE, i.e. it's SLE + GNOME desktop. It is fully supported by SUSE and thus only ships the GNOME desktop. - Leap Mirco/MicroOS is based on SLE MicroOS, which is essentially a small footprint version of SLE/Leap with transaction-update and utilizes a read-only root partition. - Leap ALP is a potential community version of ALP.
one addition: Leap Micro is NOT MicroOS. - Leap Micro is based on SLE Micro and only supports containerized applications and uses it's own repos (does not work with Leap or Tumbleweed repos). - MicroOS is based on Tumbleweed and supports both containers AND has a desktop variant which is currently GNOME (beta) and KDE (alpha) and it uses the same repos as Tumbleweed, meaning you can install almost(!) everything from there. Only two things they have in common are: name both starts with Micro an they are immutable based systems. /Syds
Hope this helps,
Dan
Footnotes: [1] And yes, I have no idea how long "foreseeable future" is or what will happen in the next 10 years. So I cannot guarantee what will happen.
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany
(HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Donnerstag, 7. Juli 2022, 11:16:20 CEST schrieb Syds Bearda:
one addition: Leap Micro is NOT MicroOS. - Leap Micro is based on SLE Micro and only supports containerized applications and uses it's own repos (does not work with Leap or Tumbleweed repos). - MicroOS is based on Tumbleweed and supports both containers AND has a desktop variant which is currently GNOME (beta) and KDE (alpha) and it uses the same repos as Tumbleweed, meaning you can install almost(!) everything from there.
You see, this is exactly what I mean. Nobody can see through that anymore. And then another variant is to be added. And all this with the same personnel. It's like the employer. It simply won't work and will backfire. Regards Eric
Am Mittwoch, 6. Juli 2022, 16:43:56 CEST schrieb Dan Čermák:
- Leap is the community edition of SLES. - SLES is the enterprise operating system of SUSE, with the latest release being SLE 15 which might be the last SLE. - SLED is the desktop edition of SLE, i.e. it's SLE + GNOME desktop. It is fully supported by SUSE and thus only ships the GNOME desktop. - Leap Mirco/MicroOS is based on SLE MicroOS, which is essentially a small footprint version of SLE/Leap with transaction-update and utilizes a read-only root partition. - Leap ALP is a potential community version of ALP.
So I already know what SLES, SLED, Leap and Tumbleweed is. But the differences to the others (microos, leap alp, and apparently now alp should still get as a base microos) I unfortunately still do not understand. Maybe I'm just too old for something like that. But on the one hand, the differences are not clear to me here and on the other hand, the new things seem to me completely immature. Partly even wrong assumptions are used here by ALP advocates. So how is this all supposed to work. Furthermore a lot of people are needed for it. I think SUSE does not have that. Because otherwise there would be some not understandable errors less in the SLES environment. Regards Eric
On 7/8/22 07:23, Eric Schirra wrote:
Am Mittwoch, 6. Juli 2022, 16:43:56 CEST schrieb Dan Čermák:
- Leap is the community edition of SLES. - SLES is the enterprise operating system of SUSE, with the latest release being SLE 15 which might be the last SLE. - SLED is the desktop edition of SLE, i.e. it's SLE + GNOME desktop. It is fully supported by SUSE and thus only ships the GNOME desktop. - Leap Mirco/MicroOS is based on SLE MicroOS, which is essentially a small footprint version of SLE/Leap with transaction-update and utilizes a read-only root partition. - Leap ALP is a potential community version of ALP.
So I already know what SLES, SLED, Leap and Tumbleweed is. But the differences to the others (microos, leap alp, and apparently now alp should still get as a base microos) I unfortunately still do not understand. Maybe I'm just too old for something like that. But on the one hand, the differences are not clear to me here and on the other hand, the new things seem to me completely immature. Partly even wrong assumptions are used here by ALP advocates. So how is this all supposed to work.
Well that's what we are trying to figure out, how are the puzzle pieces supposed to fit together. What are the advantages/disadvantages of the current model (full integration) vs a model of isolation? In which context do advantages clearly outweigh the disadvantages of one or the other method. Is there a path where it all looks the same for the less interested user but still angers the fewest amount of people that dig deeper? No one is ever going to be completely happy ;) . How do we bridge the gap between slow (SLE/Leap) and fast (TW)? The increasing speed of the world is putting a lot of strain on the current model which is why all of this is being evaluated. What we have today has worked reasonably well for probably about 30 years but the model is certainly showing it's age. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Am Freitag, 8. Juli 2022, 14:39:10 CEST schrieb Robert Schweikert:
So I already know what SLES, SLED, Leap and Tumbleweed is. But the differences to the others (microos, leap alp, and apparently now alp should still get as a base microos) I unfortunately still do not understand. Maybe I'm just too old for something like that. But on the one hand, the differences are not clear to me here and on the other hand, the new things seem to me completely immature. Partly even wrong assumptions are used here by ALP advocates. So how is this all supposed to work.
Well that's what we are trying to figure out, how are the puzzle pieces supposed to fit together. What are the advantages/disadvantages of the current model (full integration) vs a model of isolation? In which context do advantages clearly outweigh the disadvantages of one or the other method. Is there a path where it all looks the same for the less interested user but still angers the fewest amount of people that dig deeper? No one is ever going to be completely happy ;) . How do we bridge the gap between slow (SLE/Leap) and fast (TW)? The increasing speed of the world is putting a lot of strain on the current model which is why all of this is being evaluated. What we have today has worked reasonably well for probably about 30 years but the model is certainly showing it's age.
That's not entirely wrong what you're saying. But I lack the belief that containers should be the solution. Regards eric
Hello, Am 06.07.22 um 16:13 schrieb Eric Schirra:
Sorry. But for me, this is just a really stupid idea. And for me, that's just total crap.
And why do you think that is a stupid idea? Just for me as a reference: Do you think also that the Android approach is also crap here? They also put the software into real distinct separated boxes. Is it an issue because of the approach appliance vs. personal computer?
Could happen. But does not have to. And not at all in the beginning. SUSE is simply out of the picture.
Well, that makes me a little bit sad. :(
Can someone create a table with the differences between Leap, Leap ALP, Leap micro, Leap micoos, Tumbleweed, SLES, SLED. What differences are there in all the "versions". I don't know anymore.
I admit i am also sometimes confused, but let me try: * SLES is the current enterprise server version of SUSE which is classically rpm-managed (and if active, apparmor and selinux for compartmentalization) * LEAP is the OPENSUSE/Community Version of SLES and they binaries/packages they share have the same codebase and we basically want to ensure binary compabitibility and already have that in a big part (as far as packages are already reproducible) * Tumbleweed is, "roughly said" the bleeding edge version of LEAP. Tumbleweed is a rolling release and always gets the latest rpm packages. LEAP has release cycles (and SLES also) * SLED is the enterprise Desktop version (SLED="SLE Desktop" and SLES="SLE Server") and has a release cycle None of the above have containers or flatpaks builtin from the getgo/current situation. * Leap MicroOS (here it is also a little bit fuzzy for me) is the approach to build a minimal base, managed with RPMs which should mainly manage containers, flatpaks and virtual machines forr workloads. MicroOS as a base should be minimal, therefore more easily updateable and largely "appliancy" stable and selfcontained. Your workload would be in a container or a VM. Everything with ALP is currently not decided to my knowledge and still in discussion, but with a desktop plans are there to integrate more sandboxed rpm packages via containers or flatpaks. And Leap ALP is the community/free edition. Kind regards, Dennis Knorr -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Am Mittwoch, 6. Juli 2022, 15:15:11 CEST schrieb Larry Len Rainey:
I too agree with Eric on this.
I use MATE desktop. OpenSUSE is my 6th Distribution since I started using Linux - the end of Centos 5 support moved me full time to OpenSUSE.
I ran OpenSUSE as a guest under Centos as I used to support Walmart and they uses SLE.
I have some old computers that cannot run OpenSUSE but run Sparky Linux just fine.
I have 4 other flavors of Linux as Guest OS - just in case I have to switch again.
Mint and Manjaro both are contenders although Mint like Ubuntu is moving to flatpak too. But both have MATE as a desktop.
Yes. Manjaro has: Gnome, Mate, KDE, Xfce, sway. Perhaps others. And what I really like is that you can install pre-compiled packages, but also have packages built on your own PC during "installation". Or you can just use git. And because of AUR, I feel there is significantly more software. The quality I could not check now yet. But I build packages under Suse, then ic will bring hes at Manjaro/Arch too. :-) Regards Eric
Hi Eric, On 06.07.22 13:25, Eric Schirra wrote:
I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better.
Just for the record: if I remember correctly, you recently told a story of a package you did update in its develproject (calibre? not sure) which then no longer built for Leap. So these seem to contradict themselves a bit ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am Mittwoch, 6. Juli 2022, 17:58:58 CEST schrieb Stefan Seyfried:
Hi Eric,
On 06.07.22 13:25, Eric Schirra wrote:
I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better.
Just for the record: if I remember correctly, you recently told a story of a package you did update in its develproject (calibre? not sure) which then no longer built for Leap.
And what does that have to do with this? Why this was not built was a spelling mistake, if you will. If you mean that the latest version of calibre can no longer be built for Leap, then it is, as I already wrote in other mails, due to the ancient and partly dead program versions. Especially calibre among other things a lot of missing python packages. Python 3.6 is dead!
So these seem to contradict themselves a bit ;-)
No. You could, if you wanted to and were not totally attached to the SLES, solve it differently. REgards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 6. Juli 2022, 17:58:58 CEST schrieb Stefan Seyfried:
Hi Eric,
On 06.07.22 13:25, Eric Schirra wrote:
I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better.
Just for the record: if I remember correctly, you recently told a story of a package you did update in its develproject (calibre? not sure) which then no longer built for Leap.
And what does that have to do with this? Why this was not built was a spelling mistake, if you will. If you mean that the latest version of calibre can no longer be built for Leap, then it is, as I already wrote in other mails, due to the ancient and partly dead program versions. Especially calibre among other things a lot of missing python packages. Python 3.6 is dead!
So these seem to contradict themselves a bit ;-)
No. You could, if you wanted to and were not totally attached to the SLES, solve it differently.
Which is by the way, what we are trying to achieve with ALP… -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Freitag, 8. Juli 2022, 14:00:19 CEST schrieb Dan Čermák:
And what does that have to do with this? Why this was not built was a spelling mistake, if you will. If you mean that the latest version of calibre can no longer be built for Leap, then it is, as I already wrote in other mails, due to the ancient and partly dead program versions. Especially calibre among other things a lot of missing python packages. Python 3.6 is dead!
So these seem to contradict themselves a bit ;-)
No. You could, if you wanted to and were not totally attached to the SLES, solve it differently.
Which is by the way, what we are trying to achieve with ALP…
Okay. Let's wait and see what comes out of it. I'm the only one who lacks faith. And depending on.... Other mothers also have beautiful daughters. :-) REgards Eric
On 08/07/2022 14.00, Dan Čermák wrote:
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 6. Juli 2022, 17:58:58 CEST schrieb Stefan Seyfried:
Hi Eric, On 06.07.22 13:25, Eric Schirra wrote:
I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better.
Just for the record: if I remember correctly, you recently told a story of a package you did update in its develproject (calibre? not sure) which then no longer built for Leap.
And what does that have to do with this? Why this was not built was a spelling mistake, if you will. If you mean that the latest version of calibre can no longer be built for Leap, then it is, as I already wrote in other mails, due to the ancient and partly dead program versions. Especially calibre among other things a lot of missing python packages. Python 3.6 is dead!
So these seem to contradict themselves a bit ;-)
No. You could, if you wanted to and were not totally attached to the SLES, solve it differently.
Which is by the way, what we are trying to achieve with ALP…
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this? It would be the end of using Linux on old computers. If this is so, I have to find another distro. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules. You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible. The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application. Regards, Stefan
Am Samstag, 9. Juli 2022, 14:41:42 CEST schrieb Stefan Brüns:
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules.
You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible.
The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application.
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again. Regards Eric
Op 09-07-2022 om 16:01 schreef Eric Schirra:
Am Samstag, 9. Juli 2022, 14:41:42 CEST schrieb Stefan Brüns:
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules.
You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible.
The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application.
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport: https://github.com/flathub/com.calibre_ebook.calibre/issues/17 Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe. Anyway, thanks Eric for work you do on calibre. Cor
Am Samstag, 9. Juli 2022, 22:16:30 CEST schrieb Cor Blom:
Op 09-07-2022 om 16:01 schreef Eric Schirra:
Am Samstag, 9. Juli 2022, 14:41:42 CEST schrieb Stefan Brüns:
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules.
You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible.
The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application.
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport:
https://github.com/flathub/com.calibre_ebook.calibre/issues/17
Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe.
Calibre serves me here only as an example. And I mean increasingly to read that this and that package may not work. So more and more packages actually can not be built as you want in ALP! And if I understand you correctly, you want to take a package that was built somewhere else and distribute it in Leap. So that what is prevented until now always and everywhere in SUSE and in the build server. Download of npm or python module or the installation of binary packages from upstream itself are prevented or forbidden. And now this should be allowed for flatpacks? I can not understand. The whole hubs, no matter if python, npm or whatever had recently increased security problems and I assume that this will increase. And then SUSE guarantees me a clean system and takes over the liability if I use SLES or SLED? I can not believe it. Whereby... With the answers you get as in SLES....... The last version of calibre that could have been built for Leap would be 4.23.0. This also runs on my Leap. And that this can not be built, are the ancient packages in Leap (SLES) and here especially the dead python 3.6. The main problem from my point of view is the extreme dependency of Leap to SLES. Something should be done here. I use Leap because I actually want a stable system, so I don't need the latest packages everywhere. Does not bring anything for me. But there are just a few packages that I really want to have up to date. And I think it's the same for some people. But how to bring this under one hat, unfortunately, I have no solution. Only flatpack and container is not the solution for me. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Samstag, 9. Juli 2022, 22:16:30 CEST schrieb Cor Blom:
Op 09-07-2022 om 16:01 schreef Eric Schirra:
Am Samstag, 9. Juli 2022, 14:41:42 CEST schrieb Stefan Brüns:
On Freitag, 8. Juli 2022 23:19:22 CEST Carlos E. R. wrote:
Does this mean that the flatpack of calibre would contain inside the proper version of python? Would this not mean that we would need powerful computers with huge hard disks, to have this pentaplication of libraries, and a corresponding large CPU to cope with all this?
It would be the end of using Linux on old computers. If this is so, I have to find another distro.
Each Python 3.x would probably be a flatpak runtime. On top of that you could have an "extra" (or whatever) runtime layered on top, which includes a set of very common dependencies/python modules.
You can think of flatpak runtimes as somewhat coarse-granular set of packages. There likely is *some* waste due to duplication or not strictly required depencies, but in most cases this is neglegible.
The calibre flatpak than only has to bring additional modules which are not included in the runtimes below, and are very often only used by this single application.
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport:
https://github.com/flathub/com.calibre_ebook.calibre/issues/17
Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe.
Calibre serves me here only as an example. And I mean increasingly to read that this and that package may not work. So more and more packages actually can not be built as you want in ALP!
And if I understand you correctly, you want to take a package that was built somewhere else and distribute it in Leap. So that what is prevented until now always and everywhere in SUSE and in the build server. Download of npm or python module or the installation of binary packages from upstream itself are prevented or forbidden. And now this should be allowed for flatpacks? I can not understand.
Somewhere else is in this case still the Open Build Service using the same packaging guidelines and the same review processes. The only real difference is that you can distribute your flatpak for Tumbleweed, ALP and Leap (and Fedora, Debian, Ubuntu, etc.). You will *not* be allowed to just dump random prebuilt stuff from the internet or run npm install in the build service. That is against the very idea of packaging applications. Please do not mistake flathub flatpaks with our flatpaks: we do intend to use flatpaks as a distribution mechanism but not adopt flathub's lenient packaging policies.
The whole hubs, no matter if python, npm or whatever had recently increased security problems and I assume that this will increase. And then SUSE guarantees me a clean system and takes over the liability if I use SLES or SLED? I can not believe it. Whereby... With the answers you get as in SLES.......
The last version of calibre that could have been built for Leap would be 4.23.0. This also runs on my Leap. And that this can not be built, are the ancient packages in Leap (SLES) and here especially the dead python 3.6. The main problem from my point of view is the extreme dependency of Leap to SLES. Something should be done here. I use Leap because I actually want a stable system, so I don't need the latest packages everywhere. Does not bring anything for me. But there are just a few packages that I really want to have up to date. And I think it's the same for some people. But how to bring this under one hat, unfortunately, I have no solution. Only flatpack and container is not the solution for me.
I would like to understand why a flatpak or a container is not a solution for you? Because we want to introduce them to solve exactly your pain point: ancient packages in the base OS that cannot be updated due to stability guarantees. I feel your pain with an ancient python, I have had exactly the same troubles with Ruby for vagrant and boost for RStudio. If I could build them into containers or flatpaks, then I'd be able to distribute vagrant and Rstudio for Leap users with little additional effort. Currently I'd have to jump through far too many hoops to make this doable. Again, I would really like to know why this wouldn't work for you, because we'd like to build an OS that caters for more people and not less. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Montag, 11. Juli 2022, 09:55:45 CEST schrieb Dan Čermák:
possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with
every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport:
https://github.com/flathub/com.calibre_ebook.calibre/issues/17
Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe.
Calibre serves me here only as an example. And I mean increasingly to read that this and that package may not work. So more and more packages actually can not be built as you want in ALP!
And if I understand you correctly, you want to take a package that was built somewhere else and distribute it in Leap. So that what is prevented until now always and everywhere in SUSE and in the build server. Download of npm or python module or the installation of binary packages from upstream itself are prevented or forbidden. And now this should be allowed for flatpacks? I can not understand.
Somewhere else is in this case still the Open Build Service using the same packaging guidelines and the same review processes. The only real difference is that you can distribute your flatpak for Tumbleweed, ALP and Leap (and Fedora, Debian, Ubuntu, etc.).
You will *not* be allowed to just dump random prebuilt stuff from the internet or run npm install in the build service. That is against the very idea of packaging applications. Please do not mistake flathub flatpaks with our flatpaks: we do intend to use flatpaks as a distribution mechanism but not adopt flathub's lenient packaging policies.
But further above it was said "but package the build provided by the developer". Which now? Build from upstream or build from OBS? Could it be that the people suggesting ALP don't agree themselves yet? And if only OBS. Then I don't understand the whole thing at all and see absolutely no added value. The goal of ALP and container should be, if I understand it right, that more packages run under different "suse distributions". But who does the work then? Create Rpm, create flatpack. The whole thing at the update again. Where is the added value? Where is that less work? I stay with it. The whole topic is an idea of the business administration people at SUSE. As in other areas of the economy, unfortunately.
The last version of calibre that could have been built for Leap would be 4.23.0. This also runs on my Leap. And that this can not be built, are the ancient packages in Leap (SLES) and here especially the dead python 3.6. The main problem from my point of view is the extreme dependency of Leap to SLES. Something should be done here. I use Leap because I actually want a stable system, so I don't need the latest packages everywhere. Does not bring anything for me. But there are just a few packages that I really want to have up to date. And I think it's the same for some people. But how to bring this under one hat, unfortunately, I have no solution. Only flatpack and container is not the solution for me.
I would like to understand why a flatpak or a container is not a solution for you?
Because we want to introduce them to solve exactly your pain point: ancient packages in the base OS that cannot be updated due to stability guarantees. I feel your pain with an ancient python, I have had exactly the same troubles with Ruby for vagrant and boost for RStudio. If I could build them into containers or flatpaks, then I'd be able to distribute vagrant and Rstudio for Leap users with little additional effort. Currently I'd have to jump through far too many hoops to make this doable.
Again, I would really like to know why this wouldn't work for you, because we'd like to build an OS that caters for more people and not less. I'm not saying that you can't solve the problem of ancient packages with containers. You could. It's just that I don't like it at all. For me, it tries to solve a problem that requires a certain amount of work to solve with another layer that requires even more work. In addition, there is another layer that can contain errors. The complexity increases. And when openSUSE wasn't so tied to SLES, I understand the reason, the problem didn't exist to such an extent. But as I said, I don't have a real solution either. Unfortunately.
Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Montag, 11. Juli 2022, 09:55:45 CEST schrieb Dan Čermák:
possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with
every other program I have to do that again.
Calibre will be a challenge, if possible at all. At Flathub they don't build it from source, but repackage the build that is provided by the developer (although there is an effort to make it build from source). See the bugreport:
https://github.com/flathub/com.calibre_ebook.calibre/issues/17
Still, with flatpak we would be able to provide a version for Leap, even if it is difficult. And the work done at flathub can provide a starting point, maybe.
Calibre serves me here only as an example. And I mean increasingly to read that this and that package may not work. So more and more packages actually can not be built as you want in ALP!
And if I understand you correctly, you want to take a package that was built somewhere else and distribute it in Leap. So that what is prevented until now always and everywhere in SUSE and in the build server. Download of npm or python module or the installation of binary packages from upstream itself are prevented or forbidden. And now this should be allowed for flatpacks? I can not understand.
Somewhere else is in this case still the Open Build Service using the same packaging guidelines and the same review processes. The only real difference is that you can distribute your flatpak for Tumbleweed, ALP and Leap (and Fedora, Debian, Ubuntu, etc.).
You will *not* be allowed to just dump random prebuilt stuff from the internet or run npm install in the build service. That is against the very idea of packaging applications. Please do not mistake flathub flatpaks with our flatpaks: we do intend to use flatpaks as a distribution mechanism but not adopt flathub's lenient packaging policies.
But further above it was said "but package the build provided by the developer". Which now? Build from upstream or build from OBS? Could it be that the people suggesting ALP don't agree themselves yet?
And if only OBS. Then I don't understand the whole thing at all and see absolutely no added value. The goal of ALP and container should be, if I understand it right, that more packages run under different "suse distributions". But who does the work then? Create Rpm, create flatpack. The whole thing at the update again. Where is the added value? Where is that less work?
The flatpak should be build from rpms in OBS. However, you could build one flatpak and distribute it for ALP, Tumbleweed and everything else out there, without having to care about dependencies on anything but your chosen baseline (which could be Tumbleweed or something else). This is where the time saver comes in: you don't have to try to keep your package building with ancient python, ruby or whatever else versions, because you can pick your baseline. And since the builds are still being done via rpms, our existing packaging and review guidelines apply, so we *do* provide additional value: 1. the packages are build according to the same quality standards 2. the packages are available for more distributions with less overall work
I stay with it. The whole topic is an idea of the business administration people at SUSE. As in other areas of the economy, unfortunately.
The last version of calibre that could have been built for Leap would be 4.23.0. This also runs on my Leap. And that this can not be built, are the ancient packages in Leap (SLES) and here especially the dead python 3.6. The main problem from my point of view is the extreme dependency of Leap to SLES. Something should be done here. I use Leap because I actually want a stable system, so I don't need the latest packages everywhere. Does not bring anything for me. But there are just a few packages that I really want to have up to date. And I think it's the same for some people. But how to bring this under one hat, unfortunately, I have no solution. Only flatpack and container is not the solution for me.
I would like to understand why a flatpak or a container is not a solution for you?
Because we want to introduce them to solve exactly your pain point: ancient packages in the base OS that cannot be updated due to stability guarantees. I feel your pain with an ancient python, I have had exactly the same troubles with Ruby for vagrant and boost for RStudio. If I could build them into containers or flatpaks, then I'd be able to distribute vagrant and Rstudio for Leap users with little additional effort. Currently I'd have to jump through far too many hoops to make this doable.
Again, I would really like to know why this wouldn't work for you, because we'd like to build an OS that caters for more people and not less. I'm not saying that you can't solve the problem of ancient packages with containers. You could. It's just that I don't like it at all. For me, it tries to solve a problem that requires a certain amount of work to solve with another layer that requires even more work. In addition, there is another layer that can contain errors. The complexity increases. And when openSUSE wasn't so tied to SLES, I understand the reason, the problem didn't exist to such an extent. But as I said, I don't have a real solution either. Unfortunately.
We can certainly create a new spin on Leap that will provide more up to date versions of python, ruby, etc. But the elephant in the room is that someone has to maintain all of this. The close tie to SLE "solves" this to a certain extent, obviously at a cost. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 09.07.22 16:01, Eric Schirra wrote:
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
I would guess that OBS could take off some of these packager burdens by providing (just as an example) a "tumbleweed base runtime"-flatpak against which the "calibre"-flatpak would be built and where the calibre flatpak would just need to bring along the very special own versions that are not in the general tumbleweed "tumbleweed base runtime" Maybe (I'm not sure about that, but I can easily imagine the possibility) it would also be possible to add a "python310 runtime"-flatpak added on top of the "leap154 runtime", on which then a calibre-flatpak could be built easily. Of course there will probably be an additional file in the package to specify the dependencies amongst the runtimes, similar to the BuildRequires: and Requires: lines in the spec file, but then many of these dependencies could be solved by the build service magic. Even things like finding out which is the "best" collection of packages for a base runtime and what are the most useful, but still not overbloated "runtime addon" packs could be derived automatically from OBS data (which could know how many packages need e.g. a specific python module and thus if it is a good idea to put it in a "runtime addon" (when needed often) or if it is better to just include it with a specific package flatpak (if it is only needed by very few packages). So I believe that this can be made to work in a way that does not impose that much additional work on the packagers. But of course we can not know that right now. Have fun anyway :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan Seyfried <stefan.seyfried@googlemail.com> writes:
On 09.07.22 16:01, Eric Schirra wrote:
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
I would guess that OBS could take off some of these packager burdens by providing (just as an example) a "tumbleweed base runtime"-flatpak against which the "calibre"-flatpak would be built and where the calibre flatpak would just need to bring along the very special own versions that are not in the general tumbleweed "tumbleweed base runtime"
Maybe (I'm not sure about that, but I can easily imagine the possibility) it would also be possible to add a "python310 runtime"-flatpak added on top of the "leap154 runtime", on which then a calibre-flatpak could be built easily. Of course there will probably be an additional file in the package to specify the dependencies amongst the runtimes, similar to the BuildRequires: and Requires: lines in the spec file, but then many of these dependencies could be solved by the build service magic.
Even things like finding out which is the "best" collection of packages for a base runtime and what are the most useful, but still not overbloated "runtime addon" packs could be derived automatically from OBS data (which could know how many packages need e.g. a specific python module and thus if it is a good idea to put it in a "runtime addon" (when needed often) or if it is better to just include it with a specific package flatpak (if it is only needed by very few packages).
So I believe that this can be made to work in a way that does not impose that much additional work on the packagers.
You are describing more or less exactly the setup that I envision. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Sonntag, 10. Juli 2022, 13:23:19 CEST schrieb Stefan Seyfried:
On 09.07.22 16:01, Eric Schirra wrote:
But that's a bit naive. Calibre needs about 40 python modules. If we assume that it would work with the "flatpack collection packages", then surely no one will first search these "collection packages" for possibly needed python modules. That's a lot of work. So much more work and therefore much more time. And with every other program I have to do that again.
I would guess that OBS could take off some of these packager burdens by providing (just as an example) a "tumbleweed base runtime"-flatpak against which the "calibre"-flatpak would be built and where the calibre flatpak would just need to bring along the very special own versions that are not in the general tumbleweed "tumbleweed base runtime"
Maybe (I'm not sure about that, but I can easily imagine the possibility) it would also be possible to add a "python310 runtime"-flatpak added on top of the "leap154 runtime", on which then a calibre-flatpak could be built easily. Of course there will probably be an additional file in the package to specify the dependencies amongst the runtimes, similar to the BuildRequires: and Requires: lines in the spec file, but then many of these dependencies could be solved by the build service magic.
Even things like finding out which is the "best" collection of packages for a base runtime and what are the most useful, but still not overbloated "runtime addon" packs could be derived automatically from OBS data (which could know how many packages need e.g. a specific python module and thus if it is a good idea to put it in a "runtime addon" (when needed often) or if it is better to just include it with a specific package flatpak (if it is only needed by very few packages).
So I believe that this can be made to work in a way that does not impose that much additional work on the packagers.
But of course we can not know that right now.
Sounds quite nice, only I lack faith. I'll let myself be surprised until the time comes. Regards Eric
On 7/8/22 07:37, Eric Schirra wrote:
Am Mittwoch, 6. Juli 2022, 17:58:58 CEST schrieb Stefan Seyfried:
Hi Eric,
On 06.07.22 13:25, Eric Schirra wrote:
I also don't know why it's so much easier than creating an RPM package. I build quite a few packages for Leap and Tumbleweed. I don't have any problems with that and I don't think it will get any better.
Just for the record: if I remember correctly, you recently told a story of a package you did update in its develproject (calibre? not sure) which then no longer built for Leap.
And what does that have to do with this? Why this was not built was a spelling mistake, if you will. If you mean that the latest version of calibre can no longer be built for Leap, then it is, as I already wrote in other mails, due to the ancient and partly dead program versions. Especially calibre among other things a lot of missing python packages. Python 3.6 is dead!
Well not for everyone. Let's say you are a large cooperation that has lots of in house code that uses the Python 3.6 syntax. Software development is not your core business, just a necessity to stay in business. As such keeping up to date with the next version of Python that introduces yet another set of syntax incompatibilities is not really what you are going to want to spend your money on. That company money is better spent on parts of the business that brings new revenue. And this does not only apply to companies, this stuff also applies to open source projects, it took 6+ months to get a new version dependency for colorama accepted in the boto project. We have to recognize that there is a large set of needs. Spanning the complete spectrum with only 1 solution is becoming ever more difficult, which is why multiple solutions are emerging each with it's own target for covering the spectrum between fast and slow. And it no longer is just around fast and slow, it is also around development techniques. There are still plenty of applications, and they will remain, for which containers make little sense and there are lots of applications for which containers are the way to go. As such, as the underlying technology we have to try and satisfy at least 4 dimensions. How do we do this in an efficient way that satisfies as many needs of the users in the various parts of the spectrum as possible? That's what is being explored. Maybe the answer is ALP, maybe it is not? Maybe ALP turns out to be a composable system with a fancy name and one offshoot of ALP is a distribution that looks and feels exactly like today's distribution and another offshoot is a distribution that is only useful for edge deployments where there is a very small kernel build, and .... Anyway, the only way we are going to get there is by having the conversations such that as many people as possible can weigh in. And in due time something will emerge that looks like a workable model. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On Friday 2022-07-08 14:56, Robert Schweikert wrote:
Well not for everyone. Let's say you are a large cooperation that has lots of in house code that uses the Python 3.6 syntax. Software development is not your core business, just a necessity to stay in business.
So what death will the company bear? Painstakingly waste time cherry-pick 15000 changes to 200 Python modules you don't know in detail, or just upgrade them, and change your own well-known software to 3.10?
As such keeping up to date with the next version of Python that introduces yet another set of syntax incompatibilities is not really what you are going to want to spend your money on.
It's called up-skilling. If one does not know the tools of the day, chances are they (individual or company) may be replaced by someone who has the advantage.
Jan Engelhardt <jengelh@inai.de> writes:
On Friday 2022-07-08 14:56, Robert Schweikert wrote:
Well not for everyone. Let's say you are a large cooperation that has lots of in house code that uses the Python 3.6 syntax. Software development is not your core business, just a necessity to stay in business.
So what death will the company bear? Painstakingly waste time cherry-pick 15000 changes to 200 Python modules you don't know in detail, or just upgrade them, and change your own well-known software to 3.10?
Businesses make their own risk and reward calculations and for some of them performing this cherry-pick is less dangerous than upgrading to python 3.10. Especially if they don't have to perform the cherry-pick themselves, but they can pay SUSE or some other vendor for that. Then you can keep your App running for a decade on a supported system. While you think that this is a waste, there are enough customers out there who wish exactly this setup and they are anything but dying. Maybe the industry will shift in a different direction and this traditional way of deployment will die out. Then SUSE will adapt (and ALP is one step in that direction), but as long as there are customers who wish this setup, it will be provided by companies as long as it is profitable to do so.
As such keeping up to date with the next version of Python that introduces yet another set of syntax incompatibilities is not really what you are going to want to spend your money on.
It's called up-skilling. If one does not know the tools of the day, chances are they (individual or company) may be replaced by someone who has the advantage.
This is not universally true everywhere, just take a look at the amount of COBOL still running on mainframes out there. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/9/22 04:40, Jan Engelhardt wrote:
On Friday 2022-07-08 14:56, Robert Schweikert wrote:
Well not for everyone. Let's say you are a large cooperation that has lots of in house code that uses the Python 3.6 syntax. Software development is not your core business, just a necessity to stay in business.
So what death will the company bear?
Neither for 10 or 13 years, that's why SUSE makes money. Later, Robert
Painstakingly waste time cherry-pick 15000 changes to 200 Python modules you don't know in detail, or just upgrade them, and change your own well-known software to 3.10?
As such keeping up to date with the next version of Python that introduces yet another set of syntax incompatibilities is not really what you are going to want to spend your money on.
It's called up-skilling. If one does not know the tools of the day, chances are they (individual or company) may be replaced by someone who has the advantage.
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Michael Pujos schrieb:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
That's my feeling as well, and if there's no RPM-based distro left without that weird packaging like flatpak, it's probably time to go back to Windows and at least doing away with all the complication that using Linux means in practice anyhow. KaiRo
On 2022/07/06 14:52:21 +0200, Robert Kaiser wrote:
Michael Pujos schrieb:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
That's my feeling as well, and if there's no RPM-based distro left without that weird packaging like flatpak, it's probably time to go back to Windows and at least doing away with all the complication that using Linux means in practice anyhow.
KaiRo
This feeling might be the first view ... nevertheless containers can have dependencies as well to other containers as well as to a specific host system. With containers and namespaces you can encapsulate essential software like firefox which makes the control what such a program/application does see from or can control on the host system much more easier. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
Robert Kaiser <kairo@kairo.at> writes:
Michael Pujos schrieb:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
That's my feeling as well, and if there's no RPM-based distro left without that weird packaging like flatpak, it's probably time to go back to Windows and at least doing away with all the complication that using Linux means in practice anyhow.
KaiRo
I think you greatly underestimate the amount of complexity that is in modern Windows compared to Linux even with containers and flatpaks in place. Also, Windows and MacOS are both already applying concepts that we want to try with ALP, like immutable system partitions, sandboxed applications, A/B system upgrades, etc. They just rolled them out and no one noticed, because they made sure that the UX stayed the same. So I think that the key take away is to ensure that the user experience is not degraded. -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/6/22 15:31, Dan Čermák wrote:
Robert Kaiser <kairo@kairo.at> writes:
I think you greatly underestimate the amount of complexity that is in modern Windows compared to Linux even with containers and flatpaks in place.
Also, Windows and MacOS are both already applying concepts that we want to try with ALP, like immutable system partitions, sandboxed applications, A/B system upgrades, etc. They just rolled them out and no one noticed, because they made sure that the UX stayed the same.
So I think that the key take away is to ensure that the user experience is not degraded.
Let's hope that this pursuit of replicating what MS/Google/Apple are doing, partly to lock everything as much as they can, will not make the ALP user experience miserable. I use my PC for developing and use Linux (Tumbleweed) because it gives me most control over it, and the cool new tech you mention is not mandatory. I hope ALP does not transform a desktop PC into an appliance, where each program asks for permission to do stuff iOS/Android style, and other annoyances. The good news is there will always be other distros keeping the regular packaging model, and I can switch to it if necessary. I'm also not persuaded switching to Flatpak for most user facing stuff will ease the burden of maintaining packages. It will just be shifted somewhere else, solving some problems and adding new ones. It will still be as complex, maybe even more.
Am Mittwoch, 6. Juli 2022, 14:52:21 CEST schrieb Robert Kaiser:
Michael Pujos schrieb:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
That's my feeling as well, and if there's no RPM-based distro left without that weird packaging like flatpak, it's probably time to go back to Windows and at least doing away with all the complication that using Linux means in practice anyhow.
Unfortunately also was. Then you can just take the "original". And save yourself a lot of work and problems that exist under Linux if you are honest. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Mittwoch, 6. Juli 2022, 14:52:21 CEST schrieb Robert Kaiser:
Michael Pujos schrieb:
The day some essential software (such as Firefox) is only available as flatpak on Tumbleweed (whether audited or not), will be the day I seriously consider switching distro. I sort of understand why the trend is to run software into boxes into boxes, but I really dislike it.
That's my feeling as well, and if there's no RPM-based distro left without that weird packaging like flatpak, it's probably time to go back to Windows and at least doing away with all the complication that using Linux means in practice anyhow.
Unfortunately also was. Then you can just take the "original". And save yourself a lot of work and problems that exist under Linux if you are honest.
You are blowing the added complexity out of proportions. I have been using flatpaks for Firefox, chromium, ungoogled chromium and OBS (the broadcasting/streaming software) for years now and I haven't faced any issues, even when removing some permissions of the flatpaks. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Has read now, had to much headache and cold earlier today to attend live, will try to attend the meeting on Thursday On Tue, Jul 5, 2022 at 5:46 PM Dan Čermák <dcermak@suse.de> wrote:
Hi everyone,
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
tl;dr; Fear not, you will not be forced to download random flatpaks or containers from dockerhub/flathub. We (probably) just change the deliver method, but the packaging workflow will stay the same.
long version:
Desktop in ALP (topic for next official ALP update at news-o-o)
How can we dispell fears of users that we will shove containers & flatpacks down their throats: - we will use flatpak/containers as a distribution format, the packaging model will not change, only the format - the fear is not necessarily flatpaks (probably), but the fear that you'll have to pull everything from flathub/docker hub
=> stress out that you won't have to pull $randomStuff from the internet, you'll get audited software as you were before
Questions that lkocman would ask Yi Fan on the meeting would be:
* Some users are concerned that everything on their desktop will run in a container. Can you address these fears? - flatpak/containers just a distribution mechanism, packaging not going to change - ALP is still in flux, nothing set in stone - aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak) - possible solution for display manager & lower level things: https://github.com/fcrozat/gdm-container - will allow seamless updates with flatpaks installed on the host
* Desktop not being part of PoC, but can we "tentatively" expect it in any snapshot after (Dec, May)? - gdm container makes good progress - good progress with Wayland issues like remote desktop (also upstream involvement) - maybe even have rough prototype in the PoC, will have more info this or next week
* I'd really love to see desktop image that you simply dump to disk e.g. with self-install and first-boot wizzard that lets user to configure system. What's YiFan opinion about this? (SUSE IT wants this approach). - no concrete plans here yet - PoC will not have an installer, just a disk image will be the deliverable -> need to figure out how to run an installer or what to use here - Ancor is driving a workgroup to look into the traditional installation -> https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/Installation
* Any tips, best practices for how to start with Desktop app development (Including things like Desktop Managers like XFce, Elightenment etc) in "openSUSE ALP" (Current reference for community part of ALP based distro, based on top of "base install image of ALP"). - for info, message Yifan directly (yfjiang@suse.com) or the ALP matrix room https://matrix.to/#/#alp:opensuse.org - currently focusing on upstream contributions (-> GNOME upstream) - downstream contributions go into Tumbleweed - for container specific stuff, maybe later, currently too much in flux - look into building flatpaks on OBS, this will become important very soon, so get started beforehands -> help OBS handling flatpaks & container images
* Preferred way to distribute apps we know there will be ALP flathub repo in OBS, I think we could have something like "Community version of it". But we should be really smart about this, as the same app could work on top of (Community) ALP as well as Tumblweed. - would be possible to create
* How many desktop environments will there be for ALP? Just GNOME like with SLED? - first focus on GNOME, might consider alternatives afterwards - will learn from going with GNOME first and apply this to others later on
Maybe publish the Desktop WG results to the openSUSE Wiki as well
And that's it for this week, see you again next week with Luboš back in the driver seat!
Cheers,
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany
(HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 05. 07. 22, 17:46, Dan Čermák wrote:
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
I have never looked into this container stuff in more detail. But one of the concerns I was always afraid of was how this behaves WRT shared libraries and their memory footprint? IOW, containers kill the purpose of shlibs completely and one has to hold all of the versions (per each container on the top of ones from the base system) in memory, right? This sounds as if using static libraries. And what about userspace live patching? Would we provide it for SLE for all the containers? Or don't you expect these continaers to be available on SLE (which would be against the advertised purpose, it seems)? thanks, -- js suse labs
Hello openSUSE! I'm happy to see these discussions, and this is precisely why we need to plan in an open way! I have an understanding of many concerns which are being raised here. Just an idea that I discussed with Dominique a few days ago. My first-time personal experience with our current "Immutable Desktop" was quite good, but not perfect. I definitely would have some RFEs, which seem to be relatively low-hanging fruits that would improve my day-to-day experience by a lot (mostly default configuration) I can see how the entry barrier may appear too high to people meeting such a concept for the first time. I'm thinking of an idea to make a "workshop" where users would install MicroOS Desktop and try to use it for a week, and then we'd meet to talk about the user experience, both good and bad). I think people liked our last *workshop. We've had around 50 visitors in total. We could start putting together known issues (FAQ), try to propose some changes, and make sure they're being tracked for ALP GA. Thoughts? [0]https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapDesk...
On 7/7/22 22:20, Lubos Kocman wrote:
Hello openSUSE!
I'm happy to see these discussions, and this is precisely why we need to plan in an open way! I have an understanding of many concerns which are being raised here.
Just an idea that I discussed with Dominique a few days ago.
My first-time personal experience with our current "Immutable Desktop" was quite good, but not perfect. I definitely would have some RFEs, which seem to be relatively low-hanging fruits that would improve my day-to-day experience by a lot (mostly default configuration)
I can see how the entry barrier may appear too high to people meeting such a concept for the first time.
I'm thinking of an idea to make a "workshop" where users would install MicroOS Desktop and try to use it for a week, and then we'd meet to talk about the user experience, both good and bad). I think people liked our last *workshop. We've had around 50 visitors in total.
We could start putting together known issues (FAQ), try to propose some changes, and make sure they're being tracked for ALP GA.
Thoughts?
Speaking with my Leap Desktop maintainer hat on what i'd like to see as soon as possible is us trying to build a "Leap" version with a couple of other desktops (Not specifically Enlightenment) so that we can start to look at what works and doesn't work so we can start fixing the things that need to be fixed on the SUSE side (ie things we can't fix as a Leap community later). I guess the other thing we need to think about is how closely other desktops follow what gnome does and whether they make the same design decisions or go for something completely different like being part of the host OS the sooner the community has some idea about whats happening here the sooner we can start looking at those questions. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Jiri Slaby <jslaby@suse.cz> writes:
On 05. 07. 22, 17:46, Dan Čermák wrote:
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
I have never looked into this container stuff in more detail. But one of the concerns I was always afraid of was how this behaves WRT shared libraries and their memory footprint? IOW, containers kill the purpose of shlibs completely and one has to hold all of the versions (per each container on the top of ones from the base system) in memory, right? This sounds as if using static libraries.
A lot of the containerized software is written in Go and that is already statically linked, so my guess is that no one really looked at this so far. However with flatpaks the situation is different and it would be theoretically possible to deduplicate shared runtimes of flatpaks. Unfortunately I don't know whether that is actually done in practice or even feasible.
And what about userspace live patching? Would we provide it for SLE for all the containers? Or don't you expect these continaers to be available on SLE (which would be against the advertised purpose, it seems)?
This would be a question for Libor, who is driving the Kernel and Live Patching WG. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Jiri Slaby <jslaby@suse.cz> writes:
On 05. 07. 22, 17:46, Dan Čermák wrote:
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
I have never looked into this container stuff in more detail. But one of the concerns I was always afraid of was how this behaves WRT shared libraries and their memory footprint? IOW, containers kill the purpose of shlibs completely and one has to hold all of the versions (per each container on the top of ones from the base system) in memory, right? This sounds as if using static libraries.
A small follow up on this one, more in the context of flatpaks though. The question has been raised, whether flatpaks sharing a runtime would benefit from memory deduplication of shared libraries in the common runtime. The short answer is: yes. The longer and much more elaborate answer can be found in this great reply from upstream: https://github.com/flatpak/flatpak/issues/4997#issuecomment-1192616912 So as long as we don't stop dynamically linking, there shouldn't be any huge memory penalties for flatpak applications. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/5/22 10:46, Dan Čermák wrote:
the fear is not necessarily flatpaks (probably)
Wrong, That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps. I don't need to waste resources with a native apache setup and a containerized implementation of a groupware package that runs on its own containerized apache. No thanks. New approaches are fine if they eliminate problems and bloat. New approaches are not fine if they create new problems and increase bloat. Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones. -- David C. Rankin, J.D.,P.E.
Unsure how apache (I guess httpd) and groupware are "desktop applications", but anyway. Flatpak is great for GUI desktop apps (like LibreOffice is), not for httpd or groupware. My 5 cents. T On Thu, Jul 7, 2022, 22:45 David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 7/5/22 10:46, Dan Čermák wrote:
the fear is not necessarily flatpaks (probably)
Wrong,
That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps. I don't need to waste resources with a native apache setup and a containerized implementation of a groupware package that runs on its own containerized apache. No thanks.
New approaches are fine if they eliminate problems and bloat. New approaches are not fine if they create new problems and increase bloat. Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones.
-- David C. Rankin, J.D.,P.E.
Tamás Cservenák <tamas@cservenak.net> writes:
Unsure how apache (I guess httpd) and groupware are "desktop applications", but anyway.
Flatpak is great for GUI desktop apps (like LibreOffice is), not for httpd or groupware.
That is where containers would be used instead. Flatpak is really not suited or even designed for console applications or daemons. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/7/22 16:45, David C. Rankin wrote:
On 7/5/22 10:46, Dan Čermák wrote:
the fear is not necessarily flatpaks (probably)
Wrong,
That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps. I don't need to waste resources with a native apache setup and a containerized implementation of a groupware package that runs on its own containerized apache. No thanks.
New approaches are fine if they eliminate problems and bloat. New approaches are not fine if they create new problems and increase bloat. Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones.
Funny, but there is a certain amount of truth to it. The angle that is missing from this point of view, IMHO, is the necessary integration work. Meaning as long as the necessary integration work is done, i.e. what we practice today, than flatpak, containers,....other formats of isolation are indeed mostly just overhead. However, if the integration work for apps A, B, C,.... is not done and they all get their own copy of the dependencies in the versions that they need then flatpak or other delivery mechanisms that provide isolation are necessary. Such isolation, from a developer point of view, has the advantage that if a team responsible for a dependency moves that dependency forward to a version that is incompatible with the app I maintain, I can stay behind and keep my own copy of the dependency version that the app needs. Meaning the other team cannot force me to do integration work on their time scale, I can do the integration work when it fits my time schedule or when upstream moves the dependency forward and then I worry about the packaging only. Also works the other way around, if the upstream of my app moves to a newer dependency version I can pick it up in my isolated environment and I do not have to wait for the team maintaining the dependency to catch up. This second case is generally less of a problem for Factory but certainly for slower moving distros. This is an advantage for isolation. But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat. If I build a flatpak for a python app and the flatpak is based on what I built in TW then that flatpak by necessity will have to include the Python 3.10 interpreter if I want to run that flatpak on SLE. And things will probably have to creep further down the stack since the Python interpreter needs a C runtime environment which comes from the gcc compiler that is in TW and that's not in SLE, and as such that also has to be thrown into the flatpak. Meaning it's not so easy as it is being made out to be, IMHO. This however is a technical problem and can be solved with tooling. What is not solvable with tooling is that the isolation and me staying behind has the disadvantage that I, as the app maintainer, am now taking responsibility for a version of the dependency for which I may no longer get help from the team that maintains the dependency. And that may mean that if a bug shows up I am on my own and the user maybe SOL as I may not have the expertise to fix/address the problem in the dependency that I am shipping in my flatpak, container... Meaning I probably have to do the integration work that I procrastinated with right then and there anyway. There are tradeoffs that have to be weight and the speed of the distribution and the development model have a big influence as to whether or not such isolation is worth it. There are certainly good examples for either case where isolation is worth it and where isolation is not worth it. As such having the necessary tools to go either way is certainly a worth while effort and then the decision about delivery format, rpm vs. flatpak, vs. container vs... is up the the developer/maintainer of the bits higher up the stack. For some developers doing the integration work whenever a dependency moves might be easy, see Wolfgang's message, and for others it may be painful and they'd rather maintain their own copies of dependencies. And then of course we have to consider how this mix of things looks from the user point of view. If the user has to know that application A is delivered as a flatpak and as such requires a different command for updating than application B that is delivered as a plain rpm then we are going to create a mess that no user is going to want to deal with. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Robert Schweikert <rjschwei@suse.com> writes:
On 7/7/22 16:45, David C. Rankin wrote:
On 7/5/22 10:46, Dan Čermák wrote:
the fear is not necessarily flatpaks (probably)
Wrong,
That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps. I don't need to waste resources with a native apache setup and a containerized implementation of a groupware package that runs on its own containerized apache. No thanks.
New approaches are fine if they eliminate problems and bloat. New approaches are not fine if they create new problems and increase bloat. Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones.
Funny, but there is a certain amount of truth to it.
The angle that is missing from this point of view, IMHO, is the necessary integration work.
Meaning as long as the necessary integration work is done, i.e. what we practice today, than flatpak, containers,....other formats of isolation are indeed mostly just overhead.
However, if the integration work for apps A, B, C,.... is not done and they all get their own copy of the dependencies in the versions that they need then flatpak or other delivery mechanisms that provide isolation are necessary.
Such isolation, from a developer point of view, has the advantage that if a team responsible for a dependency moves that dependency forward to a version that is incompatible with the app I maintain, I can stay behind and keep my own copy of the dependency version that the app needs. Meaning the other team cannot force me to do integration work on their time scale, I can do the integration work when it fits my time schedule or when upstream moves the dependency forward and then I worry about the packaging only. Also works the other way around, if the upstream of my app moves to a newer dependency version I can pick it up in my isolated environment and I do not have to wait for the team maintaining the dependency to catch up. This second case is generally less of a problem for Factory but certainly for slower moving distros. This is an advantage for isolation.
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat. If I build a flatpak for a python app and the flatpak is based on what I built in TW then that flatpak by necessity will have to include the Python 3.10 interpreter if I want to run that flatpak on SLE. And things will probably have to creep further down the stack since the Python interpreter needs a C runtime environment which comes from the gcc compiler that is in TW and that's not in SLE, and as such that also has to be thrown into the flatpak. Meaning it's not so easy as it is being made out to be, IMHO. This however is a technical problem and can be solved with tooling.
Sure, but this size increase will get smaller if you install more than one flatpak, provided of course that they share parts of the runtime (which would be desirable).
What is not solvable with tooling is that the isolation and me staying behind has the disadvantage that I, as the app maintainer, am now taking responsibility for a version of the dependency for which I may no longer get help from the team that maintains the dependency. And that may mean that if a bug shows up I am on my own and the user maybe SOL as I may not have the expertise to fix/address the problem in the dependency that I am shipping in my flatpak, container... Meaning I probably have to do the integration work that I procrastinated with right then and there anyway.
You are not wrong, but shipping a different dependency than upstream bears other risks as well. While your dependencies will get maintained by someone else in the distribution, you run the risks of subtle regressions. Additional, with sufficiently complex applications, there's really no way of checking that the different dependency version did not break something in a subtle way. Additionally, upstreams often tend to be hesitant at best with helping out in these cases and understandably so: they ship the application with dependencies pinned to certain versions to reduce their QA effort. So to be frankly honest here: both approaches have their downsides and upsides. We still will ship rpm content, but it will probably be limited to the parts of the system where dependencies don't have to be pinned. And the parts which are getting increasingly complex and where even unbundling all dependencies is a non-trivial effort, will be shipped as flatpaks or maybe not at all… I will probably get a lot of hate for this, but we have to always ask ourselves, whether packaging something really provides any value to our users. And if all that we do is recompilation with all bundled dependencies, then that added value is getting really small (albeit not zero).
There are tradeoffs that have to be weight and the speed of the distribution and the development model have a big influence as to whether or not such isolation is worth it. There are certainly good examples for either case where isolation is worth it and where isolation is not worth it.
As such having the necessary tools to go either way is certainly a worth while effort and then the decision about delivery format, rpm vs. flatpak, vs. container vs... is up the the developer/maintainer of the bits higher up the stack. For some developers doing the integration work whenever a dependency moves might be easy, see Wolfgang's message, and for others it may be painful and they'd rather maintain their own copies of dependencies.
And then of course we have to consider how this mix of things looks from the user point of view. If the user has to know that application A is delivered as a flatpak and as such requires a different command for updating than application B that is delivered as a plain rpm then we are going to create a mess that no user is going to want to deal with.
Definitely, the user experience should not suffer and we can take Ubuntu as an example here, who afaik integrated snaps into apt directly (thereby also making a lot of people very mad when `apt install firefox` gave them a snap…). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
So to be frankly honest here: both approaches have their downsides and upsides. We still will ship rpm content, but it will probably be limited to the parts of the system where dependencies don't have to be pinned. And the parts which are getting increasingly complex and where even unbundling all dependencies is a non-trivial effort, will be shipped as flatpaks or maybe not at all… I will probably get a lot of hate for this, but we have to always ask ourselves, whether packaging something really provides any value to our users.
Ha! And how to tell? As far as I know, there are no usage nor download statistics, at all. How can I judge the value of a package? It could be that a lot of packages in TW are only used by the maintainer itself, if at all... Cheers, Manfred
Manfred Schwarb <manfred99@gmx.ch> writes:
So to be frankly honest here: both approaches have their downsides and upsides. We still will ship rpm content, but it will probably be limited to the parts of the system where dependencies don't have to be pinned. And the parts which are getting increasingly complex and where even unbundling all dependencies is a non-trivial effort, will be shipped as flatpaks or maybe not at all… I will probably get a lot of hate for this, but we have to always ask ourselves, whether packaging something really provides any value to our users.
Ha! And how to tell? As far as I know, there are no usage nor download statistics, at all. How can I judge the value of a package? It could be that a lot of packages in TW are only used by the maintainer itself, if at all...
That is not what I meant. By value I meant what value does packaging it provide. E.g. if I just shove a precompiled binary into an rpm, then imho the value-add of that is next to none. On the other hand if I recompile everything from pristine sources, audit them and can build the program reproducibly, then I am adding a lot of value. -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am 08.07.22 um 12:54 schrieb Dan Čermák:
Manfred Schwarb <manfred99@gmx.ch> writes:
So to be frankly honest here: both approaches have their downsides and upsides. We still will ship rpm content, but it will probably be limited to the parts of the system where dependencies don't have to be pinned. And the parts which are getting increasingly complex and where even unbundling all dependencies is a non-trivial effort, will be shipped as flatpaks or maybe not at all… I will probably get a lot of hate for this, but we have to always ask ourselves, whether packaging something really provides any value to our users.
Ha! And how to tell? As far as I know, there are no usage nor download statistics, at all. How can I judge the value of a package? It could be that a lot of packages in TW are only used by the maintainer itself, if at all...
That is not what I meant. By value I meant what value does packaging it provide. E.g. if I just shove a precompiled binary into an rpm, then imho the value-add of that is next to none. On the other hand if I recompile everything from pristine sources, audit them and can build the program reproducibly, then I am adding a lot of value.
Yes, 20 years ago I was thinking the same. I had quite some trivial programs which I compiled from source (sometimes the most trivial variant: "gcc prog.c -o prog") or precompiled java packages downloaded from the web. But I figured with all the distribution upgrades and deployment to different boxes, it is actually simpler and less error-prone to write a simple spec file and place it to OBS than to deal with things manually. But I agree, a container would be overkill, probably... Cheers, Manfred
On 7/7/22 16:31, Robert Schweikert wrote:
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat.
It can get really, really, really fat quickly. Apps using a different version of plasma or frameworks5 can literally need close to 1G of dependencies just to run. There is far more downside and risk to commit to a flatpack approach than to maintain the status quo with a tight distribution, proper .spec dependencies and a SLE release based on a defined set of gcc, python, etc.... Hard to imagine a company with $2B in annuals and $1/2B quarterly just wants to throw flatpacks at it? https://ir.suse.com/websites/suse/English/6400/quarterly-reports.html Somewhere someone with little regard for openSUSE has made the decision to cut costs. Gleaning from the last few weeks on this list that means killing off openSUSE releases in lieu of SLE/ALP and Tumbleweed alone. The cost saving vision that one flatpack for Tumbleweed and ALP/SLE will cut costs. That seems horribly naive. Take your tumbleweed developers and look at what breaks every time there is a change in Python, or gcc or glibc or toolkit like Qt/Gtk/Frameworks5/Plasma or supporting library like libpng or libssl and on and on (take your pick). TW's flatpack/dependencies would remain somewhat unchanged in size and dependency content. However the impact SLE/ALP will be layers of differing versions of dependencies depending on whether the TW changes introduced versions not backwards compatible with current SLE/ALP (that happens a lot keeping a rolling release going). Even subtle upstream changes in obscure packages can introduce huge backward incompatibilities. (take icu 71 for example, and that's just one library introducing incompatibility in 1/4 of the releases packages) None of it results in cost savings but the guaranteed result is a huge growth in size and risk of requiring multiple versions of whole swaths of packages and libraries for SLE/ALP through flatpack. And if flatpack "sharing" isn't perfect, then that could happen on a per-package basis. This pinned on the hope that currently non-existant tooling will minimize the bloat and multiple versioning problems. I think that is worth a proof-of-concept. A wise path would be to proceed with 15.5 and for proof of concept do the same flatpack for ALP and TW. Mark the day the ALP/TW flatpack approach begins. Then after 6 months of development see where you are on the one flatpack approach. I suspect that ALP will suffer greatly due to the scenario described above. If it works, then kudos, there is more promise than I see in the approach. If it doesn't and we find ourselves having to push out some flatpack cobbled together ALP needing 2 DVDs worth of installer to meet an artificial release deadline -- the downside to flatpacks will have been borne out. But due to wise foresight, doing it in parallel with 15.5 done in a traditional way, you will still have one quality offering ready to go. Somewhere in the $500,000,000.00 in 1st quarter revenue, there has to be enough money to do this right and not just "hope" for the best. A one-flatpack between ALP and TW with at least 3 kernel versions and python versions and 7 gcc versions in between -- what could possibly go wrong? I hope it all works out and that ALP is stellar and one-flatpack for ALP/TW is the answer, but I've lived too long and witnessed far too many slow-motion train wrecks built on hope and unproven concepts. How many more https://download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/FreeCAD... and https://bugzilla.suse.com/show_bug.cgi?id=1200583 are we going to have? -- David C. Rankin, J.D.,P.E.
On Sun 2022-07-10, David C. Rankin wrote:
Hard to imagine a company with $2B in annuals and $1/2B quarterly just wants to throw flatpacks at it? https://ir.suse.com/websites/suse/English/6400/quarterly-reports.html
Thanks for providing that pointer. This makes it easy for folks to get to actual numbers (which are quite a bit different).
Somewhere someone with little regard for openSUSE has made the decision to cut costs.
I can guarantee this is not the case. This is about user experience, lifecycle challenges, technical questions, and balancing requirements. (Mind, I'm not claiming it's easy nor that the current drafts on the table are where things will end up. Just that the people working on this do care about open source and openSUSE and that cost cutting is not the driver.) Gerald
Am 11.07.22 um 01:04 schrieb Gerald Pfeifer:
On Sun 2022-07-10, David C. Rankin wrote:
Hard to imagine a company with $2B in annuals and $1/2B quarterly just wants to throw flatpacks at it? https://ir.suse.com/websites/suse/English/6400/quarterly-reports.html
Thanks for providing that pointer. This makes it easy for folks to get to actual numbers (which are quite a bit different).
Somewhere someone with little regard for openSUSE has made the decision to cut costs.
I can guarantee this is not the case. This is about user experience, lifecycle challenges, technical questions, and balancing requirements.
(Mind, I'm not claiming it's easy nor that the current drafts on the table are where things will end up. Just that the people working on this do care about open source and openSUSE and that cost cutting is not the driver.)
That is good to know, thanks. But what clear is: The current model does not work. Look at the certbot disaster (boo#1198851): since more than 2 months a major software component of openSUSE 15.4 is broken, and everybody is just waiting because some SLE components are involved. If some container-based machinery would exist, this could be solved faster, perhaps. But if such containers really need to be used for nearly everything is another question. Cheers, Manfred
Gerald
On Mon, Jul 11, Manfred Schwarb wrote:
If some container-based machinery would exist, this could be solved faster, perhaps. But if such containers really need to be used for nearly everything is another question.
Since I'm not willing to install additional 45 python packages just to execute certbot, luckily a container based machinery does exist :) podman run -it --rm --name certbot -p 80:80 -v "/srv/certbot/etc:/etc/letsencrypt" -v "/srv/certbot/var:/var/lib/letsencrypt" certbot/certbot renew --standalone openSUSE has now even systemd scripts to do that daily... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On Monday 2022-07-11 07:50, Thorsten Kukuk wrote:
On Mon, Jul 11, Manfred Schwarb wrote:
If some container-based machinery would exist, this could be solved faster, perhaps. But if such containers really need to be used for nearly everything is another question.
Since I'm not willing to install additional 45 python packages just to execute certbot, luckily a container based machinery does exist :) podman run -it --rm ...
So instead of installing 45, you're now (effectively) installing 56. Weird flex, but ok.
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
On 7/7/22 16:31, Robert Schweikert wrote:
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat.
It can get really, really, really fat quickly. Apps using a different version of plasma or frameworks5 can literally need close to 1G of dependencies just to run.
Certainly, but I imagine that we will have policies preventing exactly this. E.g. if you want to build a KDE flatpak, you have to use the KDE-stable or KDE-latest runtime. This would prevent such a bloat.
There is far more downside and risk to commit to a flatpack approach than to maintain the status quo with a tight distribution, proper .spec dependencies and a SLE release based on a defined set of gcc, python, etc....
Hard to imagine a company with $2B in annuals and $1/2B quarterly just wants to throw flatpacks at it? https://ir.suse.com/websites/suse/English/6400/quarterly-reports.html
Somewhere someone with little regard for openSUSE has made the decision to cut costs. Gleaning from the last few weeks on this list that means killing off openSUSE releases in lieu of SLE/ALP and Tumbleweed alone. The cost saving vision that one flatpack for Tumbleweed and ALP/SLE will cut costs. That seems horribly naive.
Take your tumbleweed developers and look at what breaks every time there is a change in Python, or gcc or glibc or toolkit like Qt/Gtk/Frameworks5/Plasma or supporting library like libpng or libssl and on and on (take your pick). TW's flatpack/dependencies would remain somewhat unchanged in size and dependency content. However the impact SLE/ALP will be layers of differing versions of dependencies depending on whether the TW changes introduced versions not backwards compatible with current SLE/ALP (that happens a lot keeping a rolling release going). Even subtle upstream changes in obscure packages can introduce huge backward incompatibilities. (take icu 71 for example, and that's just one library introducing incompatibility in 1/4 of the releases packages)
One aspect of ALP (that has not been mentioned here as this was originally just about the desktop) is to re-imagine the software lifecycles and provide means to have multiple streams of software components co-existing at the same time but be decoupled of the support cycles of the main distribution. This would allow you to build packages not necessarily on the "latest and greatest"^TM from Tumbleweed, but also from more "stable" runtimes.
None of it results in cost savings but the guaranteed result is a huge growth in size and risk of requiring multiple versions of whole swaths of packages and libraries for SLE/ALP through flatpack. And if flatpack "sharing" isn't perfect, then that could happen on a per-package basis.
This pinned on the hope that currently non-existant tooling will minimize the bloat and multiple versioning problems. I think that is worth a proof-of-concept.
A wise path would be to proceed with 15.5 and for proof of concept do the same flatpack for ALP and TW. Mark the day the ALP/TW flatpack approach begins. Then after 6 months of development see where you are on the one flatpack approach. I suspect that ALP will suffer greatly due to the scenario described above.
Leap 15.5 will happen, there are no plans (at least none that I am aware of) to cancel it because of ALP. The plan is afaik more or less what you're saying: ship Leap 15.5 and work on ALP in parallel.
If it works, then kudos, there is more promise than I see in the approach. If it doesn't and we find ourselves having to push out some flatpack cobbled together ALP needing 2 DVDs worth of installer to meet an artificial release deadline -- the downside to flatpacks will have been borne out. But due to wise foresight, doing it in parallel with 15.5 done in a traditional way, you will still have one quality offering ready to go.
Somewhere in the $500,000,000.00 in 1st quarter revenue, there has to be enough money to do this right and not just "hope" for the best. A one-flatpack between ALP and TW with at least 3 kernel versions and python versions and 7 gcc versions in between -- what could possibly go wrong?
I hope it all works out and that ALP is stellar and one-flatpack for ALP/TW is the answer, but I've lived too long and witnessed far too many slow-motion train wrecks built on hope and unproven concepts.
How many more https://download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/FreeCAD... and https://bugzilla.suse.com/show_bug.cgi?id=1200583 are we going to have?
Well, ALP should hopefully prevent exactly these issues from cropping up. Given that flatpaks have very little dependencies on the base system, a flatpak running on Tumbleweed should also run on Leap or ALP or everywhere else. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 7/11/22 19:05, Dan Čermák wrote:
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
None of it results in cost savings but the guaranteed result is a huge growth in size and risk of requiring multiple versions of whole swaths of packages and libraries for SLE/ALP through flatpack. And if flatpack "sharing" isn't perfect, then that could happen on a per-package basis.
This pinned on the hope that currently non-existant tooling will minimize the bloat and multiple versioning problems. I think that is worth a proof-of-concept.
A wise path would be to proceed with 15.5 and for proof of concept do the same flatpack for ALP and TW. Mark the day the ALP/TW flatpack approach begins. Then after 6 months of development see where you are on the one flatpack approach. I suspect that ALP will suffer greatly due to the scenario described above.
Leap 15.5 will happen, there are no plans (at least none that I am aware of) to cancel it because of ALP. The plan is afaik more or less what you're saying: ship Leap 15.5 and work on ALP in parallel.
Yes but also as far as i've heard there are no plans to do a Leap 15.6 or to have a SLE 16 / Leap 16 but rather have a Leap somehow based off the ALP stack. Maybe to continue the tradition of random numbers for major Leap releases we should call it Leap 87 [1]. I think another thing worth noting here is that if all of ALP's containers / flatpaks or whatever they end up being are based off rpm's built in obs it might be possible with some effort to put all or most (some might conflict) of those RPM's into one Repo and not require ALP users to use Flatpaks or containers but this would probably take slightly more effort from the community but unlike coming up with a complete new distro like we had before 42.1 (think 13.2, 13.1 and earier) this is probably more intergration work rather then packaging work and might be easier to manage. At the end of the day how the openSUSE community takes the Piece of ALP that its given and uses them will be up to the openSUSE community. 1. https://circleofcricket.com/category/featured/3220/Why-Australians-dread-the... -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Simon Lees <sflees@suse.de> writes:
On 7/11/22 19:05, Dan Čermák wrote:
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
None of it results in cost savings but the guaranteed result is a huge growth in size and risk of requiring multiple versions of whole swaths of packages and libraries for SLE/ALP through flatpack. And if flatpack "sharing" isn't perfect, then that could happen on a per-package basis.
This pinned on the hope that currently non-existant tooling will minimize the bloat and multiple versioning problems. I think that is worth a proof-of-concept.
A wise path would be to proceed with 15.5 and for proof of concept do the same flatpack for ALP and TW. Mark the day the ALP/TW flatpack approach begins. Then after 6 months of development see where you are on the one flatpack approach. I suspect that ALP will suffer greatly due to the scenario described above.
Leap 15.5 will happen, there are no plans (at least none that I am aware of) to cancel it because of ALP. The plan is afaik more or less what you're saying: ship Leap 15.5 and work on ALP in parallel.
Yes but also as far as i've heard there are no plans to do a Leap 15.6 or to have a SLE 16 / Leap 16 but rather have a Leap somehow based off the ALP stack. Maybe to continue the tradition of random numbers for major Leap releases we should call it Leap 87 [1].
I think another thing worth noting here is that if all of ALP's containers / flatpaks or whatever they end up being are based off rpm's built in obs it might be possible with some effort to put all or most (some might conflict) of those RPM's into one Repo and not require ALP users to use Flatpaks or containers but this would probably take slightly more effort from the community but unlike coming up with a complete new distro like we had before 42.1 (think 13.2, 13.1 and earier) this is probably more intergration work rather then packaging work and might be easier to manage. At the end of the day how the openSUSE community takes the Piece of ALP that its given and uses them will be up to the openSUSE community.
I guess you could _aggregate all packages from which flatpaks are build into one giant repository and hope that the buildservice does not run out of disk space due to that. -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hello, On 2022-07-11 11:35, Dan Čermák wrote:
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
On 7/7/22 16:31, Robert Schweikert wrote:
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat.
It can get really, really, really fat quickly. Apps using a different version of plasma or frameworks5 can literally need close to 1G of dependencies just to run.
Certainly, but I imagine that we will have policies preventing exactly this. E.g. if you want to build a KDE flatpak, you have to use the KDE-stable or KDE-latest runtime. This would prevent such a bloat.
Why prevent something? In particular why prevent something for openSUSE? I could imagine some fancy modern application that requires tons of various lower level stuff and all what can be done with reasonable effort is to strictly follow upstream so this application would have to be provided together with all its needed stuff exactly as upstream uses it. Likely SUSE could not provide maintenance for such an monster (perhaps except plain updates to a new version) so for officially maintained SUSE packages there will be certain conditions (i.e. restrictions) to what extent something is maintained by SUSE. But in general openSUSE should be free of restrictions as far as possible (e.g. legal restrictions remain). In particular it should be possible that an individual openSUSE contributor can provide some application as a big and fat all in one monster thing. With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers. With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers. I do not understand what could be wrong in general with more possibilities versus "one size fits all". Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)
On 7/11/22 20:13, Johannes Meixner wrote:
Hello,
On 2022-07-11 11:35, Dan Čermák wrote:
"David C. Rankin" <drankinatty@suddenlinkmail.com> writes:
On 7/7/22 16:31, Robert Schweikert wrote:
But the isolation comes with a potentially heavy price, to come back to what was stated a couple of times in this thread "we can ship the same flatpak on TW, Leap SLE...". True but that implies that your flatpak is really fat.
It can get really, really, really fat quickly. Apps using a different version of plasma or frameworks5 can literally need close to 1G of dependencies just to run.
Certainly, but I imagine that we will have policies preventing exactly this. E.g. if you want to build a KDE flatpak, you have to use the KDE-stable or KDE-latest runtime. This would prevent such a bloat.
Why prevent something?
In particular why prevent something for openSUSE?
I could imagine some fancy modern application that requires tons of various lower level stuff and all what can be done with reasonable effort is to strictly follow upstream so this application would have to be provided together with all its needed stuff exactly as upstream uses it.
Likely SUSE could not provide maintenance for such an monster (perhaps except plain updates to a new version) so for officially maintained SUSE packages there will be certain conditions (i.e. restrictions) to what extent something is maintained by SUSE.
But in general openSUSE should be free of restrictions as far as possible (e.g. legal restrictions remain).
In particular it should be possible that an individual openSUSE contributor can provide some application as a big and fat all in one monster thing.
With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers.
With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers.
I do not understand what could be wrong in general with more possibilities versus "one size fits all".
We currently have packaging guidelines that prevent packagers from doing things that aren't in the best interest of users, I guess in some ways you could think of our statically linked library policy as an example. Its probably in the end users best interest to have as few versions of kde on there system as possible so if its possible for someone to use an existing one then we should be very strongly encouraging them to. If they can come up with a very good reason not to follow that policy thats why we have things like rpmlintrc files and review teams to assess these things on a case by case basis. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 7/11/22 06:43, Johannes Meixner wrote:
Hello,
<snip>
With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers.
With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers.
I do not understand what could be wrong in general with more possibilities versus "one size fits all".
In principal there is nothing wrong with more choice. But more choice also means more work. We understand the work required by the current model, after all it's been practiced for a long time. I don't think there is a generally good understanding of the work required for a new model the builds on basic isolation. In addition this is not an either or choice. If a middle path is pursuit then there have to be some guidelines as to which use cases are better handled with integration vs. isolation. And of course with integration work still needed the question is how much integration work should be done? Do we build Python stacks for 3.8, 3.9, 3.10, 3.11? How many modules in how many versions of those modules? If none of this is provided by the "base" then those that build things higher up the stack have to take more ownership of their dependencies as they do today. Will that work? Are people willing to do that? Is it worth it for the reward of shipping 1 containment across multiple distros? There are many questions to be answered.... Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On 7/11/22 22:19, Robert Schweikert wrote:
On 7/11/22 06:43, Johannes Meixner wrote:
Hello,
<snip>
With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers.
With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers.
I do not understand what could be wrong in general with more possibilities versus "one size fits all".
In principal there is nothing wrong with more choice. But more choice also means more work.
We understand the work required by the current model, after all it's been practiced for a long time. I don't think there is a generally good understanding of the work required for a new model the builds on basic isolation. In addition this is not an either or choice. If a middle path is pursuit then there have to be some guidelines as to which use cases are better handled with integration vs. isolation. And of course with integration work still needed the question is how much integration work should be done?
Do we build Python stacks for 3.8, 3.9, 3.10, 3.11? How many modules in how many versions of those modules? If none of this is provided by the "base" then those that build things higher up the stack have to take more ownership of their dependencies as they do today. Will that work? Are people willing to do that? Is it worth it for the reward of shipping 1 containment across multiple distros?
There are many questions to be answered....
For SUSE to be interested in this idea I think that its reasonable to presume that SUSE is interested in shipping and maintaining more then one python stack as an example. So its probably reasonable to presume that there will be atleast one python stack provided most likely more then one but certainly once you start to get to the 4 or 5 mark its of less benefit. So I suspect the question for people higher up the stack will be which stack do I choose rather then how much more extra work is it for me. So I think the interesting questions are more in terms of lifecycle, if you kinda look at SLE-15 for what did and didn't work and what people actually want maybe we can get some ideas but also i'm just guessing. There is obviously a group of SUSE customers who value it not changing so you might say that using SLE-15 timelines as the example for 15 GA and SP1 we just have python 3.6 and we are committed to maintaining it for the full 10 year lifecycle because some customers want to pay for it. But then in SP2 we say introduce python 3.8 and support it for a shorter period until the end of say SP5 and at the same time we introduce 3.10 or 3.11 with SP5 to give people who want newer python a period to work with. In my mind thats probably a minimum you'd want to start with (without hearing any actual internal discussions on the topic). But obviously you could take my suggestion and add more take the latest for each SP for example or you could support newer versions for more or less service packs. So I think this is more where the discussion is happening rather then the question of will there be any supported python stack at all. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello, On 2022-07-11 14:49, Robert Schweikert wrote:
On 7/11/22 06:43, Johannes Meixner wrote: <snip>
With our current "all integrated into a whole" method (i.e. with our current "one size fits all" mindset) we (both openSUSE and SUSE) are rather restricted what we can provide to our users and customers.
With new additional "isolated self contained parts" methods we are less restricted what we can provide to our users and customers.
I do not understand what could be wrong in general with more possibilities versus "one size fits all".
In principal there is nothing wrong with more choice. But more choice also means more work.
Not necessarily until one has tried it out in practice. I have personal examples where "one size fits all" was impossible (i.e. "causes infinite additional work") so we could not provide what customers asked for while it was possible with very little additional work if we could provide alternatives to certain customers who of course must pay for our (little) additional work. Primarily I meant that with new additional "isolated self contained parts" methods we (openSUSE and SUSE) can provide more to our users and customers than we could before. So we can grow more than we could before. Less restrictions => more possibilities to grow. And SUSE can make more money which can pay the more work of SUSE employees. The idea behind business is that SUSE can make more money than what the more work costs ;-)
I don't think there is a generally good understanding of the work required for a new model the builds on basic isolation.
Of course not. We need to try it out - out there in the wild, so we can learn how to do it right in practice, cf. https://quoteinvestigator.com/2012/11/11/exhaust-alternatives/ To be able to exhaust alternatives a precondition is "no upfront restrictions" as far as (legally) possible. While we learn how to do it right the right guidelines what should be done and what should be usually avoided will emerge over time.
There are many questions to be answered....
Yes, but not upfront. Give openSUSE contributors and SUSE employees some credit for basic intelligence and let them try to do it right as they think it is best for them and for their users and customers. Let's learn together how to do it right in practice. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)
Hello, Am 07.07.22 um 22:45 schrieb David C. Rankin:
That is exactly the fear. I wouldn't touch a flatpak or containers with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps.
Well, just because you do not need it, that does not mean other people do not need it. I had quite a few times the need for multiple versions installed.
New approaches are fine if they eliminate problems and bloat. New
They do eliminate problems. Perhaps just not for you.
approaches are not fine if they create new problems and increase bloat.
What do you experience as bloat under the axiom that a person needs different versions of libraries installed due to the nature of the applications/services which need that?
Flatpack is an ill fit for a mature desktop distribution and more geared toward teenagers installing "apps" on smartphones.
That's a little bit condescending. Flatpaks definitely have a place in the ecosystem. Currently i also am not sure if we should start every application in flatpak, but perhaps that would have an advantage. We will only see that if we build and experiment with the stuff. Cheers, Dennis -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Am Freitag, 8. Juli 2022, 08:52:49 CEST schrieb Dennis Knorr:
Hello,
Am 07.07.22 um 22:45 schrieb David C. Rankin:
That is exactly the fear. I wouldn't touch a flatpak or containers
with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps.
Well, just because you do not need it, that does not mean other people do not need it. I had quite a few times the need for multiple versions installed.
He is not alone. I don't need it and I don't want it.
New approaches are fine if they eliminate problems and bloat. New
They do eliminate problems. Perhaps just not for you.
Not for me either
That's a little bit condescending. Flatpaks definitely have a place in the ecosystem. Currently i also am not sure if we should start every application in flatpak, but perhaps that would have an advantage. We will only see that if we build and experiment with the stuff.
That's not condescending. Why always be so sensitive? Flatpacks sometimes make sense. But certainly not as a basis for a distribution. Regards Eric
Eric Schirra <ecsos@opensuse.org> writes:
Am Freitag, 8. Juli 2022, 08:52:49 CEST schrieb Dennis Knorr:
Hello,
Am 07.07.22 um 22:45 schrieb David C. Rankin:
That is exactly the fear. I wouldn't touch a flatpak or containers
with a ten foot pole. I don't need 3G or dependencies for every "hello world" app that I may want to install. I don't need multiple versions of the same package installed as a flatpack dependency for different apps.
Well, just because you do not need it, that does not mean other people do not need it. I had quite a few times the need for multiple versions installed.
He is not alone. I don't need it and I don't want it.
New approaches are fine if they eliminate problems and bloat. New
They do eliminate problems. Perhaps just not for you.
Not for me either
That's a little bit condescending. Flatpaks definitely have a place in the ecosystem. Currently i also am not sure if we should start every application in flatpak, but perhaps that would have an advantage. We will only see that if we build and experiment with the stuff.
That's not condescending. Why always be so sensitive? Flatpacks sometimes make sense. But certainly not as a basis for a distribution.
It would come of far less condescending, if you would back your claims with facts and not just assertions like "flatpaks are bloated and thus bad". -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Am Freitag, 8. Juli 2022, 14:06:48 CEST schrieb Dan Čermák:
That's not condescending. Why always be so sensitive? Flatpacks sometimes make sense. But certainly not as a basis for a distribution.
It would come of far less condescending, if you would back your claims with facts and not just assertions like "flatpaks are bloated and thus bad".
I don't know what is supposed to be condescending in my comment. Such comments always come when one runs out of arguments. Then you denigrate the other and try to put him in a bad light. I have not written that they are generally bad. I wrote that it can make sense. But not as a basis for a distribution. Regards Eric
Hi Basil, "Basil Cat" <catice567@gmail.com> writes:
Hi. How much will ALP differ from Micro Os? Will it follow the same goal as SLE/Leap?
ALP will (probably[1]) be even more "radical" and different than MicroOS when compared to a more traditional Linux distribution like Leap. The basic idea is to rethink the current approach how we build Linux distributions, experiment with new means to maintain and distribute software to provide a net benefit to our users in the long haul. ALP will probably feature a very tiny base operating system with most of the software distributed as containers and flatpaks on top of that. There are ideas of multiple streams co-existing (e.g. stable, LTS, beta) floating around as well as some other new approaches. However, as I said, much is still in flux and only because ALP will follow down a certain path, does not mean the community spin has to follow, albeit it would be beneficial for both parties (the community and SUSE), which is why we're having this discussion here. Hope this helps a bit, Dan Footnotes: [1] A lot is still in flux and hasn't been nailed down yet. -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Op 05-07-2022 om 17:46 schreef Dan Čermák:
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
tl;dr; Fear not, you will not be forced to download random flatpaks or containers from dockerhub/flathub. We (probably) just change the deliver method, but the packaging workflow will stay the same.
Sorry to be a bit late in the discussion, but personally I think it looks promising. I don't know anything about the enterprise side, so I am strictly speaking as an end user. I am already using flatpak on my Leap installation and I direct others in that direction. Sometimes a new version adds a feature that can be beneficial, esp. in applications that see quite some development. Flatpaks are simpler than backporting an rpm. So the flexibility is good. Still, there are quite a number of papercuts, esp. when it comes to permissions. An example: I tried the digikam flatpak, but the flatpak by default wants the photos in xdg-pictures, but I have them not only in another folder, but also on another disk. So I needed to install flatseal and learn about permissions. I do that, but I know some people who simply get stuck there. If flatpak indeed will be used, I understand there will be a (open)SUSE repository, which for Enterprise users is a must. But for consumers like me and others I imagine not all apps will be there and we want to add flathub. Will they work together, esp. when it comes to similar run-times? As a packager I assume I need to learn how to package flatpaks. I hope the documentation will be there in a not too distant future, but I do not have that much time, so it will take me a longer period to learn it. One of the packages is LyX, which is not on flathub because there is no texlive runtime. Looking forward to the challenge. :) I understand the whole process has just started, but thanks for sharing this and for the work. Kind regards, Cor
Cor Blom <cornelisbb@gmail.com> writes:
Op 05-07-2022 om 17:46 schreef Dan Čermák:
we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop.
tl;dr; Fear not, you will not be forced to download random flatpaks or containers from dockerhub/flathub. We (probably) just change the deliver method, but the packaging workflow will stay the same.
Sorry to be a bit late in the discussion, but personally I think it looks promising. I don't know anything about the enterprise side, so I am strictly speaking as an end user.
I am already using flatpak on my Leap installation and I direct others in that direction. Sometimes a new version adds a feature that can be beneficial, esp. in applications that see quite some development. Flatpaks are simpler than backporting an rpm. So the flexibility is good.
Still, there are quite a number of papercuts, esp. when it comes to permissions. An example: I tried the digikam flatpak, but the flatpak by default wants the photos in xdg-pictures, but I have them not only in another folder, but also on another disk. So I needed to install flatseal and learn about permissions. I do that, but I know some people who simply get stuck there.
If flatpak indeed will be used, I understand there will be a (open)SUSE repository, which for Enterprise users is a must. But for consumers like me and others I imagine not all apps will be there and we want to add flathub. Will they work together, esp. when it comes to similar run-times?
This shouldn't be a problem as long as the runtimes have different names. If we would provide a runtime with the same name as flathub, then things will most certainly break, but I imagine that we will add a policy for naming flatpak runtimes e.g. as org.openSUSE.$runtime.$stream or something along those lines.
As a packager I assume I need to learn how to package flatpaks. I hope the documentation will be there in a not too distant future, but I do not have that much time, so it will take me a longer period to learn it. One of the packages is LyX, which is not on flathub because there is no texlive runtime. Looking forward to the challenge. :)
I understand the whole process has just started, but thanks for sharing this and for the work.
You are most certainly welcome and thank you for your kind words :) Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
participants (42)
-
Aaron Puchert -
Adam Majer -
Alois Wohlschlager -
Alois Wohlschlager -
Andrei Borzenkov -
Basil Cat -
Benjamin Zeller -
Carlos E. R. -
Cor Blom -
Dan Čermák -
Dan Čermák -
David C. Rankin -
Dennis Knorr -
Dr. Werner Fink -
Eric Schirra -
Felix Niederwanger -
Gerald Pfeifer -
Gordon Leung -
Jan Engelhardt -
Jason Craig -
Jiri Slaby -
Johannes Kastl -
Johannes Meixner -
Larry Len Rainey -
Lubos Kocman -
Luna Jernberg -
Malcolm -
Manfred Schwarb -
Martin Jambor -
Matěj Cepl -
Michael Andres -
Michael Pujos -
Robert Kaiser -
Robert Schweikert -
Simon Lees -
Stefan Brüns -
Stefan Seyfried -
Syds Bearda -
Tamás Cservenák -
Thorsten Kukuk -
Wolfgang Rosenauer -
Yifan Jiang