steam-for-linux
steam-for-linux copied to clipboard
ValveSoftware
Snap or flatpak to distribute games
But could games through steam be distributed as snaps or flatpaks instead?
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.
If snaps or flatpaks were used then Steam wouldn’t work anymore here, so bad idea.
Please provide a snap package. Snap is also working on other distributions.
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.
@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.
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)
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.
@Avamander
- we have a vendor lockin vs. something supported by all major distros including debian, arch, suse, fedora, ...
- 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.
- issue of trust specially after canonical claiming patents
- 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
You are making a lot of assumptions and mention "issues" that can be fixed.
@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.
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.
@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!
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
@mhall119 I apologies, canonical no longer require copyright transfer. old CLA did require that.
That's a step in the right direction. Thank you.
@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
@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.
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.
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.
@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.
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!
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/
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.
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.
@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.
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.