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

[re:fi.64]

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

Hey there! It's great that you've had such a good experience with Flatpak. However, your app should probably target at least GNOME runtime 3.28, as the base platform (the freedesktop runtime) underwent a big internal change that was an all-around improvement, and it more actively receives e.g. the required security fixes and such now thanks to that.

Depending on what language your app is written in you may also not need the entire GNOME runtime, since the freedesktop runtime already has GTK installed for C usage.

[re:fi.64]

if you reboot your computers only 2 or 3 times a year you are clearly an idiot
look alone 2018 how many security updates the kernel got and "kexec" isn't an option for every environment

leave the kernel alone, there are a ton of libraries linked against nearly every package and it's much safer and quicker doing a controlled reboot then dig around what needs to be restarted and in which order when a reboot of a gateway VM is losing just fucking 6 pings to the machines behind

yeah, when it takes a minute or more i think twice about a reboot, 6 pings - forget it - prove me that it wasn't your internet access because you are not fast enough to verify if something else was down too for sure

Startup finished in 531ms (kernel) + 565ms (initrd) + 1.133s (userspace) = 2.230s

before you even type the commands to restart single services that thing is rebootet, full stop

systemd updates don't require a reboot, easily to prove by looking at "lsof" that pid1 has no old, updated files open

[root@localhost:~]$ systemctl daemon-reexec
[root@localhost:~]$ dmesg -c
[Sat Apr 13 06:46:51 2019] systemd[1]: Reexecuting.
[Sat Apr 13 06:46:51 2019] systemd[1]: systemd 238 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[Sat Apr 13 06:46:51 2019] systemd[1]: Detected virtualization vmware.
[Sat Apr 13 06:46:51 2019] systemd[1]: Detected architecture x86-64.

So I'm a huge systemd fan, but important note: you *can* use an updated systemd without reboot via 'systemctl daemon-reexec', but it's a tad bit risky and not something you want to rely on 100% of the time. It pretty much always works, but in theory you should be prepared to reboot due to a failure.

In general this is less of a problem nowadays with container deployments, since you can just temporarily disable one of your nodes for a reboot, and all the services will be moved to other nodes during the downtime.

[oiaohm]

Probably you have the same secret systemd manual of your comrades above.

Its not some secret systemd manual. People don't read the systemctl man page or the administrators guides so claim this crap.

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.

kexec only avoids bios/firmware lag.

You have 3 different live kernel patching solutions ksplice, kGraft and kpatch. These for a long time could not apply every single security patch. When systemd first started even using live patching you had to reboot at least 6 times a year to be perfectly secure.

To apply even now every security patch by live patching requires developer time to get the patches correct.

https://www.kernelcare.com/pricing/

Yes live patching has a price per server its not free. If you try live patching and get it wrong you can have total data corruption and loss.

99.999 or know as 5 nines depends on how it calculated how much time you got.
99.999% ("five nines")
5.26 minutes if it yearly.
26.30 seconds if monthly.
6.0 seconds if it weekly
0.9 second if it daily.

Yes 5 nines in a SLA can be stated all those different ways. If it daily you are kind of screwed rebooting and sticking to SLA. Daily you have a max of 1.8 seconds to reboot is pushing things up hill. Heck even weekly is still down right hard to pull off..

https://itsfoss.com/linuxboot-uefi/

To get to monthly 5 nines normally means custom motherboards.

Rebooting 2-3 times a year if you are on a monthly calculated 5 nines SLA each reboot still must complete in under 26.30 seconds and that is complete reboot. Failure to meet these requirements are breach of contract. So rebooting 12 times per year and rebooting 2-3 times on a monthly calculated 5 nine contract is basically the same thing.

When systemd appeared bring up webservers with databases with sysvinit was at times costing over 3 min per reboot so only could only reboot once per year on yearly 5 nines SLA that is not security suitable..

Live kernel patching is not without its problems at times either. Places like facebook and google operate on 5 nines monthly calculated with server rebooting. Live patching is still a hell of a risk if you don't need it.

The idea that boot speed is not import to servers is total crap its totally over looks how restrictive SLA contracts are when they start demarding uptime by 5 nines heck 4 nines(99.99) calculated weekly only gives you 1 min to reboot with. Reboot time is critical on servers that are contractually covered by SLA.

Anyway in my Debian testing, not often, but at certain systemd updates is required a reboot to make the changes active.

I also run debian testing and I have never had to reboot to make systemd changes active.
systemctl daemon-reload as per man page pull up your unit file changes.
systemctl daemon-reexec as per man page restarts the PID1 with current version. No reboot required for system in the complete time Debian has provided systemd if you have bothered to learn how to operate systemd. The reason why I reboot my Debian Testing systems is kernel updates.

[Mateus Felipe]

You really managed to start a systemd discussion here.

[Weasel]

If it just "sounds like", then why not better inform yourself, before making arbitrary accusations?

But it is an over-engineered piece of crap when all people really want is to run an app, no pseudo security bullshit on top. On Windows for example, or any sane OS not this over-engineered garbage, if you want a sandbox you use it yourself (like sandboxie) for just the app you want and however you want.

[oiaohm]

But it is an over-engineered piece of crap when all people really want is to run an app, no pseudo security bullshit on top. On Windows for example, or any sane OS not this over-engineered garbage, if you want a sandbox you use it yourself (like sandboxie) for just the app you want and however you want.

Problem is name a OS that is not having major security issues with third party packages. Sorry Windows does not count as a arguement.

Sandboxie has been breached many times. https://github.com/sandboxescape/San...Escape-Exploit Sorry you could claim that Sandboxie is over-engineered piece of crap and here is you recommending it Weasel.

Turns out its not simple or easy to Sandbox applications properly. Flatpak is a long term project to attempt to get around the current limitations.

[Zyklon]

But it is an over-engineered piece of crap when all people really want is to run an app, no pseudo security bullshit on top. On Windows for example, or any sane OS not this over-engineered garbage, if you want a sandbox you use it yourself (like sandboxie) for just the app you want and however you want.

You seem to not understand what Flatpak is at all. You can run Flatpaks without a sandbox – so tell me why you think Flatpak is a sandbox thing?

So I quickly explain for you: We indeed have over-engineered crap, like you wrote – but it is surely not the Flatpak system, but instead our current packaging and distribution system. To give an example: For distributing one(!) program across say 20 distributions, we need about 10-15 packagers. And what you then get is not this exact program like intended by the author, but instead twenty different modified variants of it! This is because every packager can build the program with other compilers, with other compiling flags, with other (soft/hard) dependencies and with other system libraries (just compare Arch and RHEL). I don’t even use arcane stuff, still I had to request changes in compilation flags for two times on both Debian and FreeBSD packages. Additionally there are chances that for quite some distributions, these programs are outdated or not maintained anymore at all (think security fixes). That’s why I cannot use Debian – if there are new features I like to be able to use, I had a massive problem – and don’t accept having to compile everything for myself. I want to be productive I do not want to do useless redundant work. Or there may be no maintainer, so you have to build it by yourself – which is well out of focus for most Linux users.

Here Flatpak comes in, because it unifies all this superfluous work, which just introduces fragmentation, hinders bug fixing and even blocks package distribution to not-supported distributions. With Flatpak we finally can forget about these non-system-packages packagers. Instead we get reproducible builds (Google why this is important) and everybody runs the same program in the same environment, so that bug reports or stack traces are finally useful for the developer(s). In fact I just today was able to generate a stack trace of a crashing Flatpak program with just entering one single command! Flatpak also has much more advantages, but this is the core thing.

So now you tell me if Flatpak or 20 redundant packagers with diverging results is the over-engineered piece of crap?

And if you want to rant about something, please address specific issues instead of meaningless phrases and maintain some level, please.

[oiaohm]

that two don't match because when i get a security update of a library from my distribution your upstream flatpak package still uses it's bundeled version which introduces fragmentation on a different and more important level which is the whole purpose of a Linux ditribution to avoid

Really this is problem because what you just wrote is not absolutely true. Linux distributions do not always avoid this. You see distributions like Debian and Fedora installing multi versions of particular libraries for compatibility reasons as well.

The questions is where should the duplication line be that is still open for different points of view..

[Weasel]

You seem to not understand what Flatpak is at all. You can run Flatpaks without a sandbox – so tell me why you think Flatpak is a sandbox thing?

I never said you have to use it, but it shouldn't be a part of it, because that's exactly what over-engineering means. Even a custom FUSE filesystem, really?

Stuffing so many features into one thing when you can clearly and easily separate them is the point.

And yeah I agree, the current packaging system is also over-engineered garbage, but honestly if you want to replace it, you should do it properly, IMO. People forgot how to keep it simple because they want constant updates 24/7 adding more feature creep.

BTW, I 100% agree that flatpak is "needed" because the current distribution is just horrible. I'm a super hater of that centralized crap. But that doesn't mean you have to stuff so much into flatpak.

On that note yes, the kernel is full of feature creep as well, but it's separated into modules. That's technically still part of the kernel, but you can't do anything about that since it has to run in kernel space, there's no way around it... so it is excused. (I know starshipeleven will use some kernel analogy so...)

[Weasel]

Sandboxie has been breached many times. https://github.com/sandboxescape/San...Escape-Exploit Sorry you could claim that Sandboxie is over-engineered piece of crap and here is you recommending it Weasel.

So what? Any sandbox can be breached. Sandboxie is not over-engineered because it does one thing, and that's sandboxing apps.