Flatpak 1.3.2 Released - Now Makes Use Of A Custom FUSE File-System

[Candy]

OK so why do you think you can transform every thread into a systemd flamewar only because you succeeded at doing so in a Fedora thread?

You are getting me wrong here. I am using this stuff to trigger hreindl and it usually ends up becoming a 100% success

[edwaleni]

The biggest use (for me) of Flatpak more recently has been in Clear Linux. I don't have to go find or build a bundle. In fact the Clear Linux app store is all Flatpaks.

Unfortunately, anyone who doesn't have a Flatpak of their app is told to go install it in a container instead.

Can't tell you how many requests I have seen from people who want to convert .rpm or .deb install packages directly to a Flatpak package. Not possible today, but that gives you an idea what people are thinking. Flatpak is becoming the training wheels to avoid weird or arcane installation dependencies across different spins.

[Danielsan]

I see a lot of confusion...

Because we have systemd portable services for system packages and Flatpak for desktop packages, two separate systems to delivery packages against the common practice of having repositories maintained from the distributions. At this point Ubuntu Snap is more practical because it solves the issue of having two separate package managers if we can consider "portable services" a package manager...

Anyway as I already wrote the Nix package managers already resolved all the issues about atomic upgrades, containerization, rollbacks, system and per user package. There also a side project for delivering nix packages as bundles.

It is clear that the big names want only put their stamps on everything they consider critical, it is just another way to exert control over the linux market, the other vendors, the other distribution as well as the end users.

[Danielsan]

just because I assume after 7 years systemd on servers that everybody not capable to
operate systemd must be an idiot don't make me trying desperately trying anything

Unfortunately it seems the ignore function is not working properly. I don't get what you are trying to say mumbling non-sense comments. I just use personal computers, actually I don't use all the thousand extra-cool options that systemd provides by default, I think that is a bad design choice for a desktop init. If I could have the option to select a simple init on my OS like runit I would surely selected it because I don't need all the functions that systemd provides that are clearly focused for it people, server admins and devops guys...

But I am still happy for you, I hope in some changes in the future where people can be able to setup again the components they like and not the one that impose Redhat or something else.

[Danielsan]

funny that the other half of you idiots state for years that systemd is targeting only desktops and has no place on servers

That is happens because when it appeared the first time systemd was mostly focused on boot speed and it needs to restart to make its changes effective, two things unnecessary for a server purpose, but during the time is changed because it is changed everything with the advent of the cloud and the containers.

Anyway offending people don't give you the power of the truth, but clearly states the you are rude person. Usually I don't speak with boorish like you so please ignore me, you don't need to speak with an idiot as well and I don't need to speak with a boor.

[Danielsan]

and I like to talk with idiots

In that case then use a mirror...

[dkasak]

I'm in my 1st client project using flatpak to package our software, and I must say, it's going very well. We had previously relied on deploying an entire VM, or building our entire stack on-site. Both have issues, including clients being ultra-paranoid and wanting to do a security audit of every single package. With flatpak, we just ask for "any base linux VM", and then say to them "OK so you know docker? Well this is similar to docker, and you can audit our build project if you like". They just nod and go "Yeah cool, and no, that sounds fine". It means we can hit the ground running, and be 100% certain every piece of software in our stack is built and configured exactly as we've been developing and testing with. With over 100 pieces of software involved just in our flatpak app ( ie not included in the flatpak runtime we base on ), and nasty unicode compatibility issues unless you do everything *just* right ... it can save us weeks even on a short 3-month project. Very nice! There's the added bonus that if they give us an old VM that doesn't have the minimum requirements ( eg we target gtk 3.20 at this point ), that's not a problem, because we use the 3.20 branch of the runtime "org.gnome.Platform", and this has us covered. Don't know how we managed without it, honestly

[oiaohm]

That is happens because when it appeared the first time systemd was mostly focused on boot speed and it needs to restart to make its changes effective, two things unnecessary for a server purpose, but during the time is changed because it is changed everything with the advent of the cloud and the containers.

Boot speed can be critical in server purposes. Systemd can reload a lot of itself. You have to remember you are still required to reboot Linux kernels to get the latest security upgrades. We have not got to rebootless kernels yet. Doing 99.999 uptime does not give you unlimited time to reboot servers.

Systemd daemon-reload was a very early systemd command so that you were not in fact restarting systemd but reading all the configurations. daemon-reexec command that is not used very often at all came later and in fact restarts the systemd service and is not very much used.

Deamon-reload running over the complete configuration was slower but it also to make sure the configuration is not currently goofed.

So the first point fast boot and shutdown speed was required for server purpose when systemd started. The second point is simple incorrect from the first version of systemd you were not restarting it to make changes effective some people though that because the deamon-reload process was slow but again this is for servers so you know sooner when you have bad configuration.

[Danielsan]

no need as long as you and your friends are here making a fuss about trivial tech stuff they aren't capable to deal with

I don't know what you are talking but all your technical comments can be summarized in this your previous reply

7 years systemd

That's why people stop to argue with you, because when you finish your refrain where you try to convince the other that you have a not specified superior knowledge you start be what you really are: a boorish. I don't care about you neither your opinions, but I don't lack to respect to you then I expect the same, but really I don't care it either. Just I wish you get your job at Redhat.

[Danielsan]

Boot speed can be critical in server purposes. Systemd can reload a lot of itself. You have to remember you are still required to reboot Linux kernels to get the latest security upgrades. We have not got to rebootless kernels yet. Doing 99.999 uptime does not give you unlimited time to reboot servers.

Systemd daemon-reload was a very early systemd command so that you were not in fact restarting systemd but reading all the configurations. daemon-reexec command that is not used very often at all came later and in fact restarts the systemd service and is not very much used.

Deamon-reload running over the complete configuration was slower but it also to make sure the configuration is not currently goofed.

So the first point fast boot and shutdown speed was required for server purpose when systemd started. The second point is simple incorrect from the first version of systemd you were not restarting it to make changes effective some people though that because the deamon-reload process was slow but again this is for servers so you know sooner when you have bad configuration.

Probably you have the same secret systemd manual of your comrades above. But I guess that the speed boot is not critical in computers that you probably reboot 2 o 3 times at years. And if I don't remember wrongly "kexec" is available since Linux 2.4 or 2.6, and other techniques to patch the kernel without rebooting exist since a very long time. Anyway in my Debian testing, not often, but at certain systemd updates is required a reboot to make the changes active.