Snap or flatpak to distribute games

[Avamander]

But could games through steam be distributed as snaps or flatpaks instead?

[Tele42]

Partial duplicate of #4473 / #4499. Also, how would snap / flatpak deal with updates, no sane user is going to tolerate re-downloading the full contents of a game on every update.

[stqn1]

If snaps or flatpaks were used then Steam wouldn’t work anymore here, so bad idea.

[Avamander]

@stqn1 Would not work any more where?

[Avamander]

@Tele42 Delta (partial) updates are a planned feature of snaps.

[0xBADEAFFE]

Please provide a snap package. Snap is also working on other distributions.

[muayyad-alsadi]

Please provide a snap package. Snap is also working on other distributions.

this is not true. a canonical employee published a personal third-party repo (think PPA) for some distros. But it's not yet accepted by any non-canonical/ubuntu mainstream distro in the official repo.

on the other hand. Flatpak is in the official repos of all mainstream distros.

[0xBADEAFFE]

@muayyad-alsadi Sorry but you are wrong. ;) As yo can read here: https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/, snaps are working on various distros.

[muayyad-alsadi]

what is the thing you don't understand in the word "official"?

a single canonical employee created a personal repo for some distros is so way different that being shipped in the official repos of suse, fedora, debian and arch (as with the case of flatpak)

[Avamander]

How does it matter if it's official or not? If the thing works, gets support by other devs/Steam (thus becoming official) and is better than Steam runtime, it's totally okay.

[muayyad-alsadi]

@Avamander

1. we have a vendor lockin vs. something supported by all major distros including debian, arch, suse, fedora, ...
2. we have something that requires voiding your security (turning off selinux) vs. something that is officially supported by your distro/provider. it's like asking for iphone jail break to just open a website.
3. issue of trust specially after canonical claiming patents
4. copy right re-assignment to someone that is not trust worthy

quoted from their IPPolicy

You cannot use Canonical’s patented materials without our permission.

double those fears after canonical suing a hosting provider for redistribution of ubuntu.

so If I want to use steam I should accept canonical's fishy terms. no thanks

[Avamander]

You are making a lot of assumptions and mention "issues" that can be fixed.

[muayyad-alsadi]

@Avamander how can you fix canonical not being a team player and asking every body to transfer copyright to them? how can you fix canonical claims of patents? How can you fix not being supported by official providers and lake of official support in major distros (support mean what support is supposed to mean, not 3rd party personal repo)? How can you fix lake of proper security (SELinux)?

You don't have to answer any of those questions. Why bother going with snap in the first place when we have flatpak which is already solve all those problems without raising any concern.

[mhall119]

Canonical does not require copyright transfer, nor are there any patents on the Snap format or associated software. Snaps are a part of Ubuntu and Debian now, with COPR packages for Fedora and I believe AUR packages for Arch. The lead Snap developer is working with a Fedora developer to fix the issues with SELinux on Fedora (it's not a generic SELinux problem) and get it into the official repos there.

[muayyad-alsadi]

@mhall119 I did not say that packing steam with snap would require transfer copyright of steam to canonical. That's too evil!

Contributing to snap would require copyright transfer as this is part of CLA unlike to contributing to flatpak (when talking about community driven)

I'm sorry if this is not clear enough about what is required, I thought it's obvious.

Are you sure there are no IP associated with Snap? Any link to patent policy is appreciated because the only Ubuntu IP Policy I'm aware of says otherwise. Quoted

Canonical has made a significant investment ... You cannot use Canonical’s patented materials without our permission.

if you have a list of those patents and what they do cover exactly that would be great!

[mhall119]

The CLA does not require a copyright transfer either

I'm not aware of any patent covering Snaps, and the fact that they are in Ubuntu and Debian means that if there are it must allow unlimited, royalty-free distribution anyway. Furthermore Snappy is licensed under the GPLv3, which has an explicit patent license grant that keeps it "Free Software" by the FSF's definition

[muayyad-alsadi]

@mhall119 I apologies, canonical no longer require copyright transfer. old CLA did require that.

That's a step in the right direction. Thank you.

[mhall119]

@muayyad-alsadi yes, the original CLA was more like the FSF's Contributor Agreement, which transfers copyright. The new one is more like Apache's, which is is only a license grant

[devopsdeluxe]

+ 1 For flatpak

Steam itself could be distributed in one as well...

[Avamander]

Heart if FlatPak, Hooray if Snap!

[muayyad-alsadi]

@Avamander are you authorized to take the decision if I voted with heart?

@mhall119 as I said, it's a step in the right direction (because FSF is a non-profit org, it can ask for copyright assignment from contributors). What bothers me is the "sub-license/re-license" terms in your CLA. I want to make sure everybody have equivalent writes to my contributions in other orders if canonical need to sub-license or re-license those new licenses should be under same terms (ex. if I contributed to a GPLv3 code, canonical should not be able to re-license my contributions into Apache or BSD ending into a proprietary software).

I would like to hear more about patent policy and possibly a link to detailed list.

[Avamander]

@muayyad-alsadi Irrelevant. It's needed to show the preference.

[Raulvo]

Flatpak plan is to use SELinux as Security Module. Snapd uses AppArmor as security module. You don't lose security by using Snapd.
SELinux is promoted by Red Hat. AppArmor is developed by SUSE and Canonical. Choose your poison. AppArmor is easier for administration and features continue to be added.

Being a non-profit organization does not entitle you to ask for a copyright transfer. Thanks to that, Libreboot could leave the GNU umbrella after the anti-transexual dispute.

Now, back to the distribution of games. Flatpak or Snapd? Whichever uses AppArmor for administration easyness.

[muayyad-alsadi]

I guess it's easy to see the real adoption

https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/

and asking me to turn off my security to install it does not translate as choose your poison. but this issue is promised to be solved (which is a good thing, calling it a poison does not help)

ps. SELinux protected me from venom and last docker vulnerability, while app armor did not. AppArmor is just path based policy (ex. a file called xyz ), it does not fit to lock processes to the guest/container it belongs to. the same way app armor did not protect us from venom and docker last vulnerability it won't protect us when snappy future vulnerability come.

[Raulvo]

@muayyad-alsadi
So you had both SELinux and AppArmor on the same system? Congratulations for getting two LSM online at the same time.
AppArmor is path based and SELinux is inode based, so what? That does not add anything to security but complicates things to system administrators. Why AppArmor can not lock processes to the guest/container it belongs to? Containers are deployed with distinct users, AppArmor can set permissions by user.
Kernel patch for hardlinks: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7
Sysctl enablement options:
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
These two are enabled in Ubuntu.
I would consider revisiting your AppArmor policies.

Snappy allows core system software to be distributed while Flatpak is though for user session software.

Flatpak would be OK if they supported both AppArmor and SELinux.

[muayyad-alsadi]

So you had both SELinux and AppArmor on the same system?

No i manage both ubuntu and centos/fedora on production both with mac enabled. I thought this is obvious!

[muayyad-alsadi]

Why AppArmor can not lock processes to the guest/container it belongs to? Containers are deployed with distinct users, AppArmor can set permissions by user.

I would appreciate if you provide me a link how apparmo could mitigates venom or CVE-2016-9962
Because qemu and venom.website says that only selinux work and that app armor did not.

http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/

[troyfolger]

Flatpak has wider adoption, a roadmap for sandboxing and delta updates, and is largely seen as the more serious long-term player in this space. +1 for Flatpak.

[Raulvo]

I dont see the wider adoption. Other factors subjective. Ubuntu is the most used distro, and snap is being ported to others. Snap has apparmor and selinux support. Snap already provides delta updates. Snap is more complete than flatpak and is already being deployed for containers of al kinds, including system and user software.

[muayyad-alsadi]

@Raulvo if you opened the wordpress link above you would see the status of both, if you cared to look you had seen that flatpak in the official repos of all distros unlike snap.

Being able to do system containers is out the scope steam is a user session app.

We don't care about system and daemons because that's what docker is for.

[Raulvo]

If you even cared to read these messages you would know I already know that. The thing is, snap has more features than flatpak already in place. Flatpak is the inferior approach.
I suppose you know the existance of SteamOS, based on Debian which already has Snap support.

[adityashah1212]

@Raulvo as far as support is concerned, snap running on any system not using apparmor is has no containerization; look at https://github.com/snapcore/snapd/wiki/Distributions most distros are in devmode. As far as flatpak's is concerned, it is based on bubblewrap which uses User namespaces for containerization (and setuid if user namespaces are disabled), meaning you always have containerization.

Now coming to the point of size, I do not know current status of snaps, but flatpaks tend to have a smaller size than snaps, plus flatpaks uses ostree, which automatically deduplicates files at base by using hash tree, thus saving more space.

Now, coming to the point of owning your own repo, I am certain that doing that on flatpaks would be much easier than dealing with Canonical.

I agree to your point that flatpaks is not completely ready yet, there quite a few features pending in its issue list, but I am certain that snapd isn't complete either.

[muayyad-alsadi]

I suppose you know the existance of SteamOS, based on Debian which already has Snap support.

and they are stuck with ubuntu 12.04 which reached its end of life! and that's the price they pay for using heavily forked non-standard things. I believe folks at valve learned a lesson (the hard way).

[h1z1]

From their project page

Essential Dependencies

Component
systemd
go
--

-- No. Much like every other project that has tried to follow this camps view of the world, it's not acceptable. They forced changes down the throats of users rather then producing stable code. Users, companies and other projects end up getting hit in the cross fire when they realize such drastic changes are made.

It's pure insanity to say either fappak or snap is any where near stable let alone actually implement half of what they claim. As is allowing companies to publish system level changes through steam. Content, sure.

I seriously don't understand why these are even needed when distros already have their own package formats. The difference is sandboxing at least RPM, is already well understood and there are a plethora of utilities to do it. One of them is literally called sandbox.

What is the end these projects are trying to accomplish? Simple user level isolation with a false sense of local security or actual security?

[muayyad-alsadi]

Simple user level isolation with a false sense of local security or actual security?

@h1z1 if you look here, I was able to run flatpak apps with limited access to my system (I control what they see) using --nofilesystem=host --filesystem=/home/alsadi/Documents , the app can access documents but not the rest of my home

What is the end these projects are trying to accomplish?

I can install apps without affecting my system. I can install whatever app without pulling its runtime systemwide (just like python's virtualenv or php's composer for users). Are you a developer? have you worked on a project that needs a specific django version and another project than need different one at the same time?

[h1z1]

@muayyad-alsadi : The basic idea of a chroot or jail has been around for many, many years.. My point was these are not new features nor are they difficult to implement. I don't need YAPM (yet another package manager).

Are you a developer? have you worked on a project that needs a specific django version and another project than need different one at the same time?

Not sure what point you were addressing, certainly wasn't security. You've kind of proven my point none the less. Are you telling me django devs are unable to have more then one version installed? What does that have to do with Steam? Are there games written in django, on Steam? Is GO required to use django?

[Avamander]

What would flatpaks achieve? Steam no longer installing annoying 32 packages, Steam and games breaking every major system update, other distributions not relying on patches, scripts etc. Steam not even having the chance of deleting my home folder. Basically so much more security, privacy and stability. It's better in every way if something like Steam is isolated from the rest of the system.

[muayyad-alsadi]

I don't need YAPM (yet another package manager).

it's not a package manager! a package manager can get you a single version django
you can't have both libreoffice 5 and 4 at the same time.

What does that have to do with Steam?

steam is a runtime, which is based on legacy ubuntu 12.04 (which I don't want to pollution my main system with)

Is GO required to use django?

go is a build time dependency for snap not runtime dependency (you don't need to install go)

and flatpak is written in C and does not depend on systemd quoting from FAQ

is Flatpak tied to systemd?

No. Versions of flatpak 0.6.10 relied on systemd for cgroups setup, but this is no longer required.

What would flatpaks achieve?

I currently use flatpak to install skype

• as a user I don't have to care which glibc version it was compiled for
• skype careless developers might have legacy conflicting dependencies that I can't put system wide (even if I'm crazy enough to install them system wide)
• I can control which parts of my system do skype see

Steam not even having the chance of deleting my home folder.

@Avamander true story

[h1z1]

Sooo installing another dependency is the answer? Again you've proven my point. The number of packages is not the issue. I'm rather glad they are listed so I know they aren't linking against some old, exploitable SSL lib. The features you believe unique to fappak aren't either.

Steam already runs in a jail for me, as does any content. Without another dependency.

[Raulvo]

I don't see any good in chosing Flatpak over Snapd or Snapd over Flatpak.
Flatpak is more oriented towards user space software while Snapd is available for the full system stack: it can distribute both system packages and user packages.

Heavily forked? What is that? Snapd is as standrad as Flatpak. LXD is as standard as LXC. With Snapd you get automatic LXD management.

As for package managers allowing multiple revisions you have Flatpak, Snapd and GuixSD.

[muayyad-alsadi]

I don't see any good in chosing Flatpak over Snapd or Snapd over Flatpak.

because you fail to see, it's the difference between being stuck to a canonical in-house next-generation unity/bazar/mir/upstart/... (and the long list of their phased out failed projects)
verses using a standard freedesktop.org technology

Heavily forked? What is that?

stand in front of the mirror and ask your self why does arch linux have to ship libs from ubuntu 12.04 to make steam work?

[Raulvo]

Because Steam decided to compile against a single version of Ubuntu and give support to that version of Ubuntu? That means single version of libraries which are available for any distribution.
Debian instead (and as a consequence Ubuntu too) provides multiple versions of the same library, greatly managed by APT.
But anyways, your trolling does not go much far beyond anyways.

[muayyad-alsadi]

Fyi if you compiled something with something old like centos 6 it would run on virtually any linux distro. Would you please try to read the discussion on debian ticket on porting unity from ubuntu to debian. Why this failed? Because Ubuntu's libraries are not what their name claim to be.

…

On Jul 30, 2017 5:56 PM, "Raul Vidal" ***@***.***> wrote: Because Steam decided to compile against a single version of Ubuntu and give support to that version of Ubuntu? That means single version of libraries which are available for any distribution. Debian instead (and as a consequence Ubuntu too) provides multiple versions of the same library, greatly managed by APT. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4512 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHqx5eXiBAuRvmpuHjnKqJ0wxJerVfks5sTJm4gaJpZM4I8oea> .

[adityashah1212]

@h1z1 You missing the very point here. Leaving the sandboxing part for later, think about a application you wrote, which needs to be distributed. There are about 20 major distributions, atleast 100 minors forks of them, and a million unidentified. How will you package your app for even the first 120? Considering that each of them has their own set of patched/forked/modified/polluted libraries build with different configurations, and not to mention each of them have their own packaging policy of how an app is packaged (mind you I am not talking about package format, an rpm for opensuse may not always work for fedora, or a deb for ubuntu may not always work with debian). Flatpak is just trying to give you a single platform on which you can build your application and it runs on all distribution who have flatpak available in their repository (since flatpak runtimes are common across all distributions maintained upstream and not by distribution). Now that coming to the point of sanboxing, why do you want to complicate things by creating a sandbox manually, when the distributing mechanism itself is giving to that ability.

@Raulvo according to your argument, it should be fine if I just downloaded all the sources of the same version as that of those packaged in Ubuntu 12.04, but from upstream. But do you realize it won't work that way? Do you know why? Answer is simple, because ubuntu unlike Arch doesn't ship upstream unmodified packages. It customizes each library to their own needs. That is also why port of pantheon doesn't work 100% on fedora (because some libraries are customized and thus some pantheon apps cannot be compiled on fedora).

[Raulvo]

I am tired of reading your stupid messages talking about things which do not have anything to do with others.
Have a nice day.

[h1z1]

@adityashah1212 : Leaving the bulk of your reply out for sake of space, however

You missing the very point here. Leaving the sandboxing part for later, think about a application you wrote, which needs to be distributed. There are about 20 major distributions, atleast 100 minors forks of them, and a million unidentified.

Are you sure? I don't think we're reading the same responses. Sandboxing is one of the very things being discussed. Hell @muayyad-alsadi even linked a screenshot.

Sure steam is based on an "old" distribution of Ubuntu but the issues it has, have nothing to do wit that. The core issues come from a rather silly paradigm called rolling releases. It assumes a symbiotic relationship between vendors and end users where one can dictate the demands upon another. It doesn't work that way. You cannot force vendors to update or they'll simply leave your platform. Maintaining backwards compatibility is absolutely critical especially in fluid markets like Game development. You cannot as an end user trust vendors not to spy on you, nor have your best interest in mind when it comes to secure programming. Fact that you'd dismiss this is hilarious.

Your comparison of RPM vs the other three I suspect comes from your not understanding rpm or yum (nor apt?). They can already do the versioning control you seek, and more.

[Avamander]

@h1z1 The thing is you're totally ignoring Valve's and game maker's track record, they absolutely SUCK at backwards compatibility and maintaining something. The current solution does not work (rpm, and whatever more) and they will spend as little effort as possible keeping it barely working, having a flatpak would mean that piece of software stays inside flatpak and gets removed totally after it's no longer needed, it also means we all get a working piece of software which in my opinion is the most important aspect.

[h1z1]

@Avamander

The thing is you're totally ignoring Valve's and game maker's track record, they absolutely SUCK at backwards compatibility and maintaining something.

I literally said the exact opposite.

[adityashah1212]

@h1z1

You cannot force vendors to update or they'll simply leave your platform. Maintaining backwards compatibility is absolutely critical especially in fluid markets like Game development.

That is what flatpak's is about, give a stable long-term runtime, across multiple distributions without breaking anything. Just target available runtimes (or maybe create your own and maintain it).

Are you sure? I don't think we're reading the same responses. Sandboxing is one of the very things being discussed.

I did say that flatpak has its own sandboxing, we don't need to go about creating sandboxes, apps are automatically sandboxed.

Your comparison of RPM vs the other three I suspect comes from your not understanding rpm or yum (nor apt?). They can already do the versioning control you seek, and more.

No I am not talking about version, I am talking about how each distribution has customized those libraries for their own needs. Because of that an app compiled and packaged for one rpm based distribution doesn't work with another rpm based distribution. Thus the ground the developer has to cover is huge, while writing and testing the app.

[h1z1]

@adityashah1212

I don't know where to even begin. Your reply contradicts things both of us have already said. Worse you actually selectively quote me.

Example, you left out or forgot you said:

You missing the very point here. Leaving the sandboxing part for later, think about a application you wrote

To wit I responded:

Are you sure? I don't think we're reading the same responses. Sandboxing is one of the very things being discussed.

I did say that flatpak has its own sandboxing, we don't need to go about creating sandboxes, apps are automatically sandboxed.

Ironically you said above:

I agree to your point that flatpaks is not completely ready yet, there quite a few features pending in its issue list, but I am certain that snapd isn't complete either.

I don't think you understand, I'm not for either solution. The importance I place on true security is km's above you. As I already said package managers are able to do what you're asking whether you know how to do it or not is another question.

No I am not talking about version, I am talking about how each distribution has customized those libraries for their own needs. Because of that an app compiled and packaged for one rpm based distribution doesn't work with another rpm based distribution.

Except, you are? What do you think the linker does exactly? This has nothing to do with RPM nor any package manager. It has to do with vendors not shipping libraries. RPM itself is quite capable of handling customized libraries as are the system linkers and have been for decades.

[muayyad-alsadi]

rpm/deb/yum/apt would require granting full root access to apps (a package can even change security policy). with flatpak/snap I install them unprivileged. I don't have to give some random angry birds clone full root access to my laptop! I want to manage what they see of my laptop.

Flatpak has very good storage saving thanks to ostree content-addressable (if same file came from multiple packages it would be stored once)

[h1z1]

Is Avanmander a bot?? Gave you a thumbs up within seconds.

Regardless how do you think fappak is able to? Surprise, with root. Your point is moot.

[adityashah1212]

@h1z1 Ok, first did you read my post carefully, about sandboxing I said "I will leave it for later" and I came back to the point.

Now that coming to the point of sanboxing, why do you want to complicate things by creating a sandbox manually, when the distributing mechanism itself is giving to that ability.

About flatpak's not being ready, what I meant by that was flatpak as a tool has still features being added. Like for example it doesn't yet support null runtime. But that doesn't mean flatpak runtimes are unstable.

Well about RPM, I have no grip about current package managers and I never said they were at fault (also I didn't say throw them away), but do tell me that you have two customized versions of libpqrs.so for 2 different applications; how would you have them both remain on your system, without complicating things, like preloading the library or linking the application itself during compile time with a specific version and enforcing it. Think as a layman and not as a IT professional. With flatpaks/snaps you as a developer have a clean slate to start from, where you can pick and choose libraries you need. All the user has to do is install the app and run it, flatpak takes care of everything.
Also what if the original application was built on distribution using customized libpqrs.so, while every other distribution is packaging upstream libpqrs.so. The application won't work out of the box on other distribution. What do you do then? Package the library with application (that is what flatpak/snap are doing, better than current packaging methods I might add). Or do you expect the user to go hunting for all those customized libraries.

There are two things flatpaks/snaps are trying to achieve,

1. Give a unified platform for app distribution, so that developers don't have to worry if their application is working with some xyz distribution, because it will always work out of the box no matter which distribution you develop on. Plus it makes it lot easier for the end user to get the app.
2. They provide containerization (or sandboxing) for security.

[h1z1]

@h1z1 Ok, first did you read my post carefully, about sandboxing I said "I will leave it for later" and I came back to the point.

Yes, I read that. Point made no sense, "the distributing mechanism" cannot be trusted. Hiding HOW docker, or failpak, or InsertNewBuzzwordHere, handles doing what they claim behind in many cases system calls directly, is not security. The day I have to run steam as root is the day I sell my account.

About flatpak's not being ready, what I meant by that was flatpak as a tool has still features being added. Like for example it doesn't yet support null runtime. But that doesn't mean flatpak runtimes are unstable.

And if those mattered in your narrative why do they not mine? What was the point in arguing those "features being added", meant anything but weasel words?

Well about RPM, I have no grip about current package managers and
I never said they were at fault (also I didn't say throw them away),
but do tell me that you have two customized versions of libpqrs.so
for 2 different applications; how would you have them both remain
on your system, without complicating things, like preloading the
library or linking the application itself during compile time with a
specific version and enforcing it.

So we come to the crux of many arguments from SystemD people, you state a requirement then subsequently preference any "answer" to exclude the one you don't agree on. What you're describing is EXACTLY WHAT THE DAMNED LINKER WAS DESIGNED FOR. What do you think it does all day with properly compiled applications? Resolve symbols. Resolve dependencies. Make things just work (tm). Steam actually goes through some rather arcane loops to duplicate the system linker.

Think as a layman and not as a IT professional. With flatpaks/snaps you as a developer have a clean slate to start from, where you can pick and choose libraries you need. All the user has to do is install the app and run it, flatpak takes care of everything.

And this is a big part of the problem. You SHOULD care . We do not need to go back in history with people randomly clicking on executables.

Also what if the original application was built on distribution using customized libpqrs.so, while every other distribution is packaging upstream libpqrs.so. The application won't work out of the box on other distribution. What do you do then? Package the library with application (that is what flatpak/snap are doing, better than current packaging methods I might add). Or do you expect the user to go hunting for all those customized libraries.

What are you talking about? Where is it going to pull those dependencies from three years from now? Are you going to maintain those systems for eternity? Securely?

There are two things flatpaks/snaps are trying to achieve,

Give a unified platform for app distribution, so that developers don't have to worry if their application is working with some xyz distribution, because it will always work out of the box no matter which distribution you develop on. Plus it makes it lot easier for the end user to get the app.

This is pie in the sky bullshit. It doesn't address the underlying problem of what happens (aka whose responsible), when those "distros" need updating since you refuse to let the system linkers do their jobs. You're still forcing fragmentation on the entire platform.

What happens in your little garden when NVIDIA decides to end support for older hardware, including pulling it from drivers thus not even available for download.? Tell users to upgrade their hardware? This level of thinking facilitates forced deprecation and needs to stop.

Hell what about kernel level changes breaking userland?

They provide containerization (or sandboxing) for security.

lul.

[Avamander]

@h1z1 Your talk sounds nice but the real world is different. Sure we have the technical capability to do things nicely, but Valve/EA/whatever aims at a profit as big as possible, maintaining bunch of different versions and backwards compatibility will NEVER happen but containers that work on many platforms, old and new, can happen.

[h1z1]

A container does not magically make all dependencies disappear. You're confusing VM's with containers anyway, the former being portable.

[adityashah1212]

The day I have to run steam as root is the day I sell my account.

That is where you are wrong, steam isn't running as root. It is running in userspace. The system calls controlling the container are made by flatpak, not by steam. I wonder if you have even bothered to read flatpak architecture before criticizing it.

A container does not magically make all dependencies disappear. You're confusing VM's with containers anyway, the former being portable.

It is portable as long as kernel as some set of features enabled. Because primary assumption in containers is that there is nothing other than kernel itself.

And anyways, if this is not the solution than propose one better than this.

[h1z1]

The day I have to run steam as root is the day I sell my account.

That is where you are wrong, steam isn't running as root. It is
running in userspace. I wonder if you have even bothered to read
flatpak architecture before criticizing it.

How am I wrong??? What the fuck. I never said it was running as root.
From their docs regardless:

Under the hood¶

The bubblewrap utility from Project Atomic, which lets unprivileged users set up and run containers, using kernel features such as:

systemd to set up cgroups for sandboxes
D-Bus, a well-established way to provide high-level APIs to applications
The OSTree system for versioning and distributing filesystem trees
Appstream metadata, to allow Flatpak applications to show up nicely in software-center applications

Running as root and running with root privileges are in this context, the same. Requiring systemd and dbus on systems that don't use nor want them is bullshit. They all basically share themselves as users. Appstream is literally a manifest... in XML.. with copyright.

A container does not magically make all dependencies disappear.
You're confusing VM's with containers anyway, the former being >> portable.

It is portable as long as kernel as some set of features enabled.
Because primary assumption in containers is that there is nothing
other than kernel itself.

Which NEVER happens right? Contrast that with true portability like I gave, VMs.

And anyways, if this is not the solution than propose one better than
this.

I have, in this thread alone they were RPM, Yum, sandbox (the util), hell even firejail.

I'm done with this thread. I expect you'll continue opening threads in an effort to sell the fake outrage and support. Good luck.

[muayyad-alsadi]

Running as root? Who the heck talked about running? Installing as root, running as regular user is capable for modifying your system in an unpredictable way including installing setuid, modifing security policy, missing with shared libraries...

…

On Mon, Jul 31, 2017, 1:51 AM h1z1 ***@***.***> wrote: The day I have to run steam as root is the day I sell my account. That is where you are wrong, steam isn't running as root. It is running in userspace. I wonder if you have even bothered to read flatpak architecture before criticizing it. How am I wrong??? What the fuck. I never said it was running as root. From their docs regardless: Under the hood¶ The bubblewrap utility from Project Atomic, which lets unprivileged users set up and run containers, using kernel features such as: systemd to set up cgroups for sandboxes D-Bus, a well-established way to provide high-level APIs to applications The OSTree system for versioning and distributing filesystem trees Appstream metadata, to allow Flatpak applications to show up nicely in software-center applications Running as root and running with root privileges are in this context, the same. Requiring systemd and dbus on systems that don't use nor want them is bullshit. They all basically share themselves as users. Appstream is literally a manifest... in XML.. with copyright. A container does not magically make all dependencies disappear. You're confusing VM's with containers anyway, the former being >> portable. It is portable as long as kernel as some set of features enabled. Because primary assumption in containers is that there is nothing other than kernel itself. Which NEVER happens right? Contrast that with true portability like I gave, VMs. And anyways, if this is not the solution than propose one better than this. I have, in this thread alone they were RPM, Yum, sandbox (the util), hell even firejail. I'm done with this thread. I expect you'll continue opening threads in an effort to sell the fake outrage and support. Good luck. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4512 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHq2nTQKiWQjWaGp9ymh681AkvPScBks5sTQkLgaJpZM4I8oea> .

[Avamander]

Steam seems to be available as Flatpak! Woo.

https://github.com/flathub/com.valvesoftware.Steam/blob/master/com.valvesoftware.Steam.json

[muayyad-alsadi]

@Avamander but that's just a community effort (not supported by valve). we hope that valve would pick that up.

No, that manifest was written by Flatpak devs. However, it's Flathub's policy to give the application developers write-access if they request it. So in theory, it could become official.

you can read more at OMG Ubuntu article

[Avamander]

@muayyad-alsadi didn't claim otherwise, I simply stated it's available. I have to say it's the least painful and most secure install of steam I've had, though maybe I could achieve better with firejail but that'd require me to install the debian package.