Fedora 35 To Support Restarting User Services On Package Upgrades

[er888kh]

The problem with .deb and .rpm is that they're not sandboxed and are free to do anything.
On Android, iOS and Universal Windows Platform (UWP) the applications have to ask permissions that you can allow deny.

That is not a problem. While there are programs that should absolutely be sandboxed, not every program should be sandboxed. And for sandboxing, there are specific implementations (snap and flatpak). Whether they are good solutions is another topic, but for now, deb and rpm are not flawed if they don't do what other programs are made to do.

[skeevy420]

Y'all know Fedora has a regular and sandbox editions, right? That other mainstream distributions like Ubuntu and Manjaro offer Flats and Snaps as an alternative to traditional packaging formats?

Pick the Linux that works for you. I don't see what the big deal is.

[tildearrow]

The problem with .deb and .rpm is that they're not sandboxed and are free to do anything.
On Android, iOS and Universal Windows Platform (UWP) the applications have to ask permissions that you can allow deny.

The problem is that you forgot these are system packages. Just like macOS .pkg or Windows .msi.
If you want something more Android/iOS/UWP-like, use Flatpak or Snap.

[gigi]

allows restarting of system services automatically when upgrading the packages for those services, there hasn't been that capability for user services to automatically restart as part of RPM package upgrades. But now approved for Fedora 35...

never knew about restarting services automatically.

definitly good news particularly if the package updates or closes high risk vulnerability.

anyhow, this kind of automation is necessary for end users. i found couple of persons bragging using linux os but in reality they havent even applied security updates for almost 9 months.

[Charlie68]

The problem with .deb and .rpm is that they're not sandboxed and are free to do anything.
On Android, iOS and Universal Windows Platform (UWP) the applications have to ask permissions that you can allow deny.

Not entirely true, it is true that they do not have a sandbox, however they are under the control of SElinux or AppArmor.

What if sshd restarts suddenly? Or if a media player is running while updating audio server?
Or if network restarts?
Care needs to be taken by package maintainers.

If I'm not mistaken openSUSE already does it, when I update and there is for example network manager among the updates, it shuts down and then restarts during the installation.

[faramirza]

System tools like ncdu don't work well in sandboxed environments. Applications like browsers are fine.

[Nocifer]

This is not exactly true. The idea of Sandboxing is interesting. Android and iOS definately are doing it right. Flatpak is sold to the people as an equal approach but they forget mentioning, that by using Flatpaks you require to install one or more runtimes to get things going. At the end you need to pull in plenty of gigabytes of runtimes to operate one tiny Flatpack packaged app. Not to mention about the huge abuse of links that get created inside /var/lib/flatpak. So you basicly end up installing a Linux system inside a Linux system.

This happens because Android's userland was built from the ground up around the concepts that Flatpak is now trying to shoehorn into the already existing Linux userland as a side-loaded add-on, so it's only natural that Flatpak is for the time being "a Linux system inside a Linux system". But in the future, if you so desire, you'll be able to use Flatpak-only apps and avoid this Linux inside Linux thing altogether. In fact in theory you can do this right now, though in practice it's an exercise in patience at best, due to Flatpak being still a pain in the a$$ in more than a few ways. But, the concept is pretty solid.

Also, those gigabytes of runtimes you mentioned are only needed on a fresh system; after installing a few common apps and the most common runtimes get installed alongside them, installing an app will take only the space of the app itself.

[kreijack]

The problem with .deb and .rpm is that they're not sandboxed and are free to do anything.
On Android, iOS and Universal Windows Platform (UWP) the applications have to ask permissions that you can allow deny.

With RPM an application can access your webcamera, access your location, access the network, access Bluetooth, etc.

With Snap and Flatpak you can sandbox applications, but I believe that each Snap gets mounted at system boot time hence adds time to the startup time of the system.

Flatpack and/or Snap are a different model than the historic linux distribution

The former model sandboxes each application from the others. It is good if you have a "store" which is not (don't want to be) responsible of the applications.
Pro:
- fast app update
- is difficult that an application can damage the others
Cons:
- a lot of code is replicated (each 'app' brigs its own dependencies)
- each application is not very integrated to the others
- the security updates relies to the single app publisher, which has to be in charge not only of the app itself, but also of the dependencies too

The latter model is based to a "community" voluntary based which integrate each packages with the system;
Pro:
- less code duplication
- the dependencies are shared, so all packages benefit of a dependency update
- each packages has an "independent" reviewer, the packager who is a different entity from the author
- better security management: each packager is responsible only of its own package
Cons:
- slower update rate

Pay attention that the packages which restart a service, typically are the ones which are not eligible to be sandboxed: a ssh server or a systemd-package are near to impossible to sandbox...

Moreover, in the app model (look at the phones) the apps do access to the webcamer, my location.. etc. Instead a debian or a fedora packages even if they can access , they don'taccess to these resources. This due to the review process described above. This is the most important differences.

Let me say it in another world: in the app model the sandboxing is needed because everyone (even bad person) can publish an app. You can't publish a debian (or a fedora) official package without be involved/checked by the packagers crew. This is a very strong filter. Look at many packages exist and how many security problemw exist.

Obviously if you get a .rpm (or a .deb) package from a forum and install it without any check... it is likely that you will encounter problem :-)

Anyway my bigger critics to the sandboxed app, is that the resource most important that has to be protected is not the webcam, but the user files. An app (even sandboxed) that can access the user files is a risk for these files: i.e. the app can share the files with other, or it can crypt the files... On the other side if you avoid the user files access to the sandboxed apps, these can't cooperate (think about to libreoffice that open a file download by the web browser...). What I mean is that a sandboxed app is:
- not useful if it can't access to the user files
or
- not really secure if it can access the user files

[andyprough]

Fedora stealthily climbing up out of the grave, dragging rpm and systemd along like a dog dragging the lightpost he was chained to down the street.

This is called "progress". After 18 years in existence, users won't have to restart the entire computer after every simple update.

[RahulSundaram]

Fedora stealthily climbing up out of the grave, dragging rpm and systemd along like a dog dragging the lightpost he was chained to down the street.

This is called "progress". After 18 years in existence, users won't have to restart the entire computer after every simple update.

These claims are just false.

This change is just a scriptlet that optionally allows a package to set a service to be restarted automatically after an update for user services (system services already had that capability a long time back). User services are not that common and most packages that use user services still won't use it leaving it to the user to restart the user services when they want to. Neither RPM or systemd required you to restart a computer after an update before or after the change.