Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sat, Aug 14, 2021 at 07:48:06AM +0100, Jonathan Dowland wrote:
> Backports is not analogous to the concepts Timothy was presenting. It's
> *one* repository, not a system where people (not just Debian maintainers)
> can create repos.
extrepo tries to help there, and now that bullseye is released, should
be more usable for everyone.
Unfortunately it requires you to do all the handywork in order to have
an actual, signed, repository, but reprepro is easy enough to use and
works well enough for most use cases; it's something that we could
document somewhere and then point people to it.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
Jonathan Dowland schrieb: >> Amarok was removed as it required the obsolete Qt 4 library. Now that >> upstream has finally ported it to Qt5, it could be reintroduced to >> Debian. > > That's an interesting way of presenting the situation. Amarok was > removed because we aggressively removed Qt4, dropping packages that were > still using it, rather than dropping it once it was no longer in use, > which would be the more traditional approach. We didn't "aggressively remove" it; Qt4 was already a long time EOLed when we started to prune reverse deps. The same process which also happens/ happened for many other outdated and security relavant libs, think OpenSSL 1.0. Talk is cheap if you're not the one who has to deal with the consequences (like backporting security fixes to an unsupported release) Cheers, Moritz
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Thu, Aug 12, 2021 at 04:42:51AM +, Paul Wise wrote: > On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote: > > > Debian is missing KDE's Amarok music manager. > > Amarok was removed as it required the obsolete Qt 4 library. Now that > upstream has finally ported it to Qt5, it could be reintroduced to > Debian. That's an interesting way of presenting the situation. Amarok was removed because we aggressively removed Qt4, dropping packages that were still using it, rather than dropping it once it was no longer in use, which would be the more traditional approach. > > where people can create Repo's of newer software versions to > > use with stable Debian. > > We have backports for that, and there is the bikesheds idea. > > https://backports.debian.org/ Backports is not analogous to the concepts Timothy was presenting. It's *one* repository, not a system where people (not just Debian maintainers) can create repos. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
Quoting Andreas Tille (2021-08-12 23:06:47) > On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote: > > Maintainers like their freedoms, but enforcing some tools at some > > point could make it easier for everyone to contribute and not > > relearn the packaging process for every package, because currently > > every package is different. We are getting there by looking at the > > number of "3.0 (quilt)" packages and "dh" usage, but when a package > > does not conform to this norm, it triggers a mental freeze on my > > side (and I want to migrate it all to dh/3.0 quilt etc.). > > +1 > > May be we start defining workflow recommendations in policy or we > draft some development policy. I'm aware that there are may be < 100 > packages inside the Debian package pool that are hard to push into > some default shape - but most packages with "unusual" workflows are > that way for no good reason. >From where do you get those estimates? I think a good start would be to try identify which packages are maintained in which style and for which reasons. I imagine that https://trends.debian.net/ can help to some extend but that's not enough to identify e.g. how many packages use cdbs due to being tied to Haskell, or how many packages of a certain "smell" have seen no recent maintainer update. Just an idea for a concrete task that I think would help us understand what is holding back progress towards streamlining of packaging. I am not volunteering to do the work myself, sorry: I have too much on my plate already. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
Hi, On Thu, Aug 12, 2021 at 02:06:37PM +0200, Romain Porte wrote: > > Looking at Arch, one workflow, one way to package, one init system, etc. > > Looking at Fedora, one workflow, one way to package, one init system. > > I think this is a major point. I am a new Debian contributor after a > good time of ArchLinux PKGBUILD writing. I find Debian technically > superior on the packaging side, and would not trade it for PKGBUILD. But > there are so many ways to do things. After a lot of exploration, I have > found that the tooling that I was the most comfortable with was: > > * Salsa VCS > * GBP for git + patching (+ DEP-conformant branch names) > * dh > > However there are so many other ways to do things. Some packages are not > on Salsa. Some packages use manually generated diff files. Different > branch names everywhere (debian/latest vs. debian/master vs. > debian/unstable vs. master…). I think progressive enforcing of a > workflow would help new maintainers to not be lost in the packaging jungle. Amen. > > I still trust Debian to be the most technically excellent distribution, > > but that's not all it makes to stay relevant. My point is that it would > > help to reduce the technical liberties we take in Debian. However, I > > don't think that's who we are. > > Maintainers like their freedoms, but enforcing some tools at some point > could make it easier for everyone to contribute and not relearn the > packaging process for every package, because currently every package is > different. We are getting there by looking at the number of "3.0 > (quilt)" packages and "dh" usage, but when a package does not conform to > this norm, it triggers a mental freeze on my side (and I want to migrate > it all to dh/3.0 quilt etc.). +1 May be we start defining workflow recommendations in policy or we draft some development policy. I'm aware that there are may be < 100 packages inside the Debian package pool that are hard to push into some default shape - but most packages with "unusual" workflows are that way for no good reason. Kind regards Andreas. -- http://fam-tille.de
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
Hi, 11/08/2021 16:08, Vincent Bernat : > I think we have more systemic issues. I am quite impressed how Nix/NixOS > is able to pull so many packages and modules with so few people. But > they use only one workflow, one way to package, one init system, etc. > Looking at Arch, one workflow, one way to package, one init system, etc. > Looking at Fedora, one workflow, one way to package, one init system. I think this is a major point. I am a new Debian contributor after a good time of ArchLinux PKGBUILD writing. I find Debian technically superior on the packaging side, and would not trade it for PKGBUILD. But there are so many ways to do things. After a lot of exploration, I have found that the tooling that I was the most comfortable with was: * Salsa VCS * GBP for git + patching (+ DEP-conformant branch names) * dh However there are so many other ways to do things. Some packages are not on Salsa. Some packages use manually generated diff files. Different branch names everywhere (debian/latest vs. debian/master vs. debian/unstable vs. master…). I think progressive enforcing of a workflow would help new maintainers to not be lost in the packaging jungle. > I still trust Debian to be the most technically excellent distribution, > but that's not all it makes to stay relevant. My point is that it would > help to reduce the technical liberties we take in Debian. However, I > don't think that's who we are. Maintainers like their freedoms, but enforcing some tools at some point could make it easier for everyone to contribute and not relearn the packaging process for every package, because currently every package is different. We are getting there by looking at the number of "3.0 (quilt)" packages and "dh" usage, but when a package does not conform to this norm, it triggers a mental freeze on my side (and I want to migrate it all to dh/3.0 quilt etc.). > Let me take again the example with Nix. Anyone can do a simple pull > request and gets its change accepted. Each package has a maintainer, but > the ownership is quite weak. The maintainer may say no, but if they are > just busy, someone else may merge the change if it looks reasonable. Maybe the interface helps too. With a single repository, everyone can see every pull request easily. For Debian you would have to monitor all repositories/bugs for NMUs waiting. > In Debian, we have many workflow (BTS, MR to submit changes, Git, not > Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to > package (just one makefile, old debhelper, new dh), many init systems. > And the ownership problem prevents people to help from time to time. > There are so many packages I come accross that could just be updated to > a more recent version and looks like semi-abandoned but I just don't try > any more because there are so many ways to fail. To me the problem is not to do the technical migration, but to make it acceptable to the current maintainer that will usually not want to change their workflow — or not answer at all. One issue is that you cannot repack everything and propose a NMU, because it is a major change. So what do? Apart from RFS or co-maintaining, I do not know how I can help "modernize" these packages. If I propose it as a .patch in a bug and it is refused because the maintainers "does not like 3.0 (quilt)", I have lost a good chunk of time. > Today, it is very difficult to only use Debian own packages. We just > tell people "just add random repositories". Nix and Arch are able to > have almost everything packaged. Nix is able to include into a single > workflow most other language ecosystems. We could have the same in Debian, but the constraints of "build from source" and lack of interest for "contrib" and "non-free" channels is in my opinion severely limiting the number of available packages. AUR contains many packages that are not open-source nor built from source, but users are happily using them when they want to. For example for Spotify or VS Code (or many other external, sometimes proprietary tools) you need to add an external repository. While on Arch I guess you would use AUR. Why could not we use "contrib"/"non-free" for the same purpose? In the fonts team, it is increasingly complicated to build fonts from source because they use so many javascript dependencies. I could propose to ship the final .ttf/otf fonts into "contrib" instead. But given the review duration for getting into "main", I guess "contrib" and "non-free" are worse in terms of given attention. Looking forward to pursue the discussion. Best regards, Romain.
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
2021, ഓഗസ്റ്റ് 12 8:51:55 AM IST, Timothy M Butterworth ൽ എഴുതി >I am fine with Debian's release cycle but It would be nice to see more >packages. For example Debian is missing KDE's Amarok music manager. I >am happy to see Debian 11 gained KDE Elisa music manager. I am sad to >see that VirtualBox is not available on Debian 11. I had to jerry-rig >it using the Ubuntu Focal repo from Oracle. > We have https://fasttrack.debian.net and currently gitlab, matrix synapse and virtual box is available there in buster-fasttrack suite (though only gitlab is available via bullseye-fastrack now, I hope other two will come soon). Packages that don't fit in regular backports can be shipped via Fast Track. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote: > Debian is missing KDE's Amarok music manager. Amarok was removed as it required the obsolete Qt 4 library. Now that upstream has finally ported it to Qt5, it could be reintroduced to Debian. https://tracker.debian.org/pkg/amarok https://tracker.debian.org/news/1055955/removed-290-2-from-unstable/ https://bugs.debian.org/935022 https://amarok.kde.org/en/node/890 https://www.debian.org/doc/manuals/developers-reference/ch05.html#reintroducing-pkgs > VirtualBox is not available on Debian 11. VirtualBox is not suitable for Debian stable because of how upstream does security updates. https://tracker.debian.org/pkg/virtualbox https://bugs.debian.org/794466 Also, it isn't in main because it needs a non-free compiler to build the BIOS. > I got tired of the constant need to download all of the packages. > I am on a metered internet connection. There are a couple of Debian initiatives that could help here: https://debdelta.debian.net/ https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs > where people can create Repo's of newer software versions to > use with stable Debian. We have backports for that, and there is the bikesheds idea. https://backports.debian.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
I am fine with Debian's release cycle but It would be nice to see more packages. For example Debian is missing KDE's Amarok music manager. I am happy to see Debian 11 gained KDE Elisa music manager. I am sad to see that VirtualBox is not available on Debian 11. I had to jerry-rig it using the Ubuntu Focal repo from Oracle. OpenSUSE Tumbleweed is a good rolling distro, I am surprised Steam did not use it. OpenSUSE was the repo Plasma Active shipped with. I tried Tumbleweed but I got tired of the constant need to download all of the packages. I am on a metered internet connection and a Rolling Distro is just not for me. Debian needs to have a mechanism like the openSUSE OBS Open Build Service, where people can create Repo's of newer software versions to use with stable Debian. On openSUSE I use the stable KDE Repo's to keep KDE up-to-date with the latest stable releases. Tim
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Wed, Aug 11, 2021 at 04:08:13PM +0200, Vincent Bernat wrote: > I think we have more systemic issues. I am quite impressed how Nix/NixOS > is able to pull so many packages and modules with so few people. But > they use only one workflow, one way to package, one init system, etc. > Looking at Arch, one workflow, one way to package, one init system, etc. > Looking at Fedora, one workflow, one way to package, one init system. I wouldn't call it "issues" per se. It's all about trade-offs. Having only one way to do things helps velocity, but it also impedes flexibility, which some users and developers value. Having a faster release cycle either requires a lot more engineering resources (volunteers or paid, depending on the distro) and/or it forces users to continually update to new major releases if they want to continue getting security updates. There still *are* enterprise customers who like the longer release cycles. Some of them even use Debian and have privately referred to it as "their secret advantage". Whether it is a large number or not, and whether they are contributing back to the Debian community (and whether that is important to us) are different questions. Requiring that all packages use the common distro-shipped shared libraries (or Perl or Python components) as opposed to shipping their own is another engineering tradeoff where there may be some advantages, but also disadvantages, in terms of effort, pain if the shared libraries or Perl/Python components laugh at the concept of "stable API's", and userspace package upstreams that want to work across a large number of distributions all supporting different versions of their dependencies, and/or upstream that want to move faster than Debian is willing to release. These are all tradeoffs, and there is no one right answer. That may be painful for those who believe that there is, and it is a hidden assumption in the blithe assertion that Debian should be "The Universal OS". Unfortunately, these tradeoffs mean that there can *be* no single "Universal OS". There will always be a need for different horses for different courses. Debian has taken a strong opinionated stance on many of these tradeoffs, and that's fine. It's not necessarily a problem, except insofar that some people want Debian to be applicable for a particular use case, such as for example Steam OS. It might be the answer is that Debian simply can't be as Universal as we might aspire to be. Cheers, - Ted
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
❦ 11 August 2021 11:27 +02, Steffen Möller: > I have no exact idea what to change, though. A rolling Debian would be > cool, yes, but also a bit late when compared with environments that > Conda offers or the ease that comes with multiple installations of conda > to e.g. avoid name conflicts. If we had a chroot for which you do not > need to be root, then together with snapshot.d.o we would be darn close > to what Conda is offering. I have no idea how to get there, though. With > singularity maybe? We package only a very small subset of Conda, I don't see in what universe we could be competitive, rolling or not rolling. I think we have more systemic issues. I am quite impressed how Nix/NixOS is able to pull so many packages and modules with so few people. But they use only one workflow, one way to package, one init system, etc. Looking at Arch, one workflow, one way to package, one init system, etc. Looking at Fedora, one workflow, one way to package, one init system. Let me take again the example with Nix. Anyone can do a simple pull request and gets its change accepted. Each package has a maintainer, but the ownership is quite weak. The maintainer may say no, but if they are just busy, someone else may merge the change if it looks reasonable. In Debian, we have many workflow (BTS, MR to submit changes, Git, not Git, Git workflow 1, Git workflow 2, Git workflow 3), many ways to package (just one makefile, old debhelper, new dh), many init systems. And the ownership problem prevents people to help from time to time. There are so many packages I come accross that could just be updated to a more recent version and looks like semi-abandoned but I just don't try any more because there are so many ways to fail. I still trust Debian to be the most technically excellent distribution, but that's not all it makes to stay relevant. My point is that it would help to reduce the technical liberties we take in Debian. However, I don't think that's who we are. Today, it is very difficult to only use Debian own packages. We just tell people "just add random repositories". Nix and Arch are able to have almost everything packaged. Nix is able to include into a single workflow most other language ecosystems. -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On 11.08.21 08:46, Marc Haber wrote: On Wed, 11 Aug 2021 01:09:29 -0400, Calum McConnell wrote: On Wed, 2021-08-11 at 00:51 +, Paul Wise wrote: On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote: "So, Arch Linux, one of the main reasons, there's a couple, but the main reason is the rolling updates of Arch allows us to have more rapid development for SteamOS 3.0," says Yang. "We were making a bunch of updates and changes to specifically make sure that things work well for Steam deck, and Arch just ended up being a better choice for them." Sounds like Debian testing would have worked for them too. Except testing lacks direct security support, and spends about a quarter of the time in a feature freeze. It isn't a true rolling release: the wheels are squares instead of circles. I think that the experience that Debian has made with Stream is our classic problem: We try to cater for all, and annoy the people who want quicker releases. After we have driven away the users who want quicker releases in the early 2000s (they have moved to Ubuntu or to the rolling release distributions), we have taken a quicker pace, driving away the users that want more stability (they have probably moved to the Red Hat / CentOS world despite them having actually less stability by defining stability and support time differently than we do), and still we're too slow for downstream users like Steam. This is either going to continue, or we finally commit to having more than one release train, which of course comes with its own set of issues, the biggest of them being volunteers and personpower. There is no glory in supporting long support cycles. For steam, our competitor may be arch. For science projects, it is conda (ok, hello, yes, you brew and guix people, you are also competitors) - which rolling and (bonus feature) cross-platform - with CI and often it is upstream preparing and using these packages themselves. I have no exact idea what to change, though. A rolling Debian would be cool, yes, but also a bit late when compared with environments that Conda offers or the ease that comes with multiple installations of conda to e.g. avoid name conflicts. If we had a chroot for which you do not need to be root, then together with snapshot.d.o we would be darn close to what Conda is offering. I have no idea how to get there, though. With singularity maybe? Best, Steffen
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Wed, 11 Aug 2021 01:09:29 -0400, Calum McConnell wrote: >On Wed, 2021-08-11 at 00:51 +, Paul Wise wrote: >> On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote: >> >> > "So, Arch Linux, one of the main reasons, there's a couple, but the >> > main >> > reason is the rolling updates of Arch allows us to have more rapid >> > development for SteamOS 3.0," says Yang. "We were making a bunch of >> > updates and changes to specifically make sure that things work well >> > for >> > Steam deck, and Arch just ended up being a better choice for them." >> >> Sounds like Debian testing would have worked for them too. > >Except testing lacks direct security support, and spends about a quarter >of the time in a feature freeze. It isn't a true rolling release: the >wheels are squares instead of circles. I think that the experience that Debian has made with Stream is our classic problem: We try to cater for all, and annoy the people who want quicker releases. After we have driven away the users who want quicker releases in the early 2000s (they have moved to Ubuntu or to the rolling release distributions), we have taken a quicker pace, driving away the users that want more stability (they have probably moved to the Red Hat / CentOS world despite them having actually less stability by defining stability and support time differently than we do), and still we're too slow for downstream users like Steam. This is either going to continue, or we finally commit to having more than one release train, which of course comes with its own set of issues, the biggest of them being volunteers and personpower. There is no glory in supporting long support cycles. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Wed, 2021-08-11 at 00:51 +, Paul Wise wrote: > On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote: > > > "So, Arch Linux, one of the main reasons, there's a couple, but the > > main > > reason is the rolling updates of Arch allows us to have more rapid > > development for SteamOS 3.0," says Yang. "We were making a bunch of > > updates and changes to specifically make sure that things work well > > for > > Steam deck, and Arch just ended up being a better choice for them." > > Sounds like Debian testing would have worked for them too. Except testing lacks direct security support, and spends about a quarter of the time in a feature freeze. It isn't a true rolling release: the wheels are squares instead of circles. signature.asc Description: This is a digitally signed message part
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote: > "So, Arch Linux, one of the main reasons, there's a couple, but the main > reason is the rolling updates of Arch allows us to have more rapid > development for SteamOS 3.0," says Yang. "We were making a bunch of > updates and changes to specifically make sure that things work well for > Steam deck, and Arch just ended up being a better choice for them." Sounds like Debian testing would have worked for them too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Tue, Aug 10, 2021 at 01:31:12PM -0400, Sandro Tosi wrote: > > I think it would be quite nice to hear from Valve or some of the Debian > > folks who work(ed) with them, about the reasons for the rebase. With no > > ill will, just to understand what the problems were and if we can learn > > something from them. > > https://www.pcgamer.com/this-is-why-valve-is-switching-from-debian-to-arch-for-steam-decks-linux-os/ TLDR: At launch, the Steam Deck will undoubtedly need multiple small updates to make sure everything works flawlessly. Some of which could affect the underlying kernel—not something that Debian readily lends itself to. That's something Valve designer, Lawrence Yang, told us during our hands-on time with the Deck when we asked about the switch from Debian to Arch. "So, Arch Linux, one of the main reasons, there's a couple, but the main reason is the rolling updates of Arch allows us to have more rapid development for SteamOS 3.0," says Yang. "We were making a bunch of updates and changes to specifically make sure that things work well for Steam deck, and Arch just ended up being a better choice for them." -- WBR, wRAR signature.asc Description: PGP signature
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
> I think it would be quite nice to hear from Valve or some of the Debian > folks who work(ed) with them, about the reasons for the rebase. With no > ill will, just to understand what the problems were and if we can learn > something from them. https://www.pcgamer.com/this-is-why-valve-is-switching-from-debian-to-arch-for-steam-decks-linux-os/ -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Steam Deck: good news for Linux gaming, bad news for Debian?
Hello Simon, That's an awesome reply, thank you very much for having the time to write all of this and adding the links, I have found the Steam runtime bit particularly interesting. > (Disclosure: I work for Collabora, and I'm currently working on the > Steam Runtime.) If you're ever feeling like it, I would love to see a talk from you about the inner workings of Steam on Linux/Debian. > Anyway, enough email-writing, time to get back to Assassin's Creed > Odyssey, under Proton, in a Debian-10-based Steam Runtime 2 container, > on a Debian 11 machine :-) Nice, I loved Odyssey and Origins, although I had a little bit of issues on Odyssey because I didn't go for the hard difficulty when I knew I was gonna try and do all the side quests... I ended up too powerful at the end xD. Cheers, -- Samuel Henrique
Re: Steam Deck: good news for Linux gaming, bad news for Debian?
(Disclosure: I work for Collabora, and I'm currently working on the Steam Runtime.) On Sat, 17 Jul 2021 at 13:48:32 +0100, Samuel Henrique wrote: > As some of you already seem, we have very good news for the Linux > gaming community, although somewhat bad for Debian: ... > https://www.steamdeck.com/en/tech > Operating System: SteamOS 3.0 (Arch-based) I think this is still good for Debian, although arguably less good for Debian than it might have been if it was directly based on Debian like the earlier-generation Steam Machines were. Rather than thinking "ugh, this isn't Debian", I'm thinking of this as "good, this is modern Linux", and in particular not Windows! SteamOS 2 is stuck on Debian 8, which is a long way out of support at this point, so SteamOS needed a significant amount of work to catch up with the last ~ 6 years of development somehow. You might notice from https://repo.steampowered.com/steamos/dists/clockwerk/ that packaging metadata for a Debian-9-based version appeared at one point, although I don't think any packages appeared in that repository. Obviously, as a Debian developer, the route I would have tried first for that work would be to rebase onto a newer version of Debian - either a stable release, or testing, or their own testing-like snapshots of unstable like Ubuntu does - but Valve have chosen to rebase on Arch instead. I am not the right person to say why, sorry. Arch and Debian are not actually a million miles apart: they're both package-based binary distributions in a nearly-FHS directory layout (unlike for example NixOS), using glibc and GNU userspace (unlike for example Alpine), booting with systemd by default (unlike for example Devuan), community-maintained rather than driven by a single corporate sponsor, with divergence from upstream generally being treated as a bug but tolerated if there's a good enough reason why it's necessary. (Of course, there are other distros that I could say similar things about, Debian's threshold for what is a good enough reason for divergence from upstream tends to be lower than Arch's, and we make different technical decisions in various places.) In terms of the upstream versions involved, Debian 11 is more like Arch than it is like Debian 8 (although obviously the packaging and OS layout are rather different!) so this still seems better for Debian in terms of having the games that run successfully on the Steam Deck also run successfully on Debian (and Ubuntu, and Fedora, and other modern distributions). I would hope that if Valve later decide that they need to be basing a future SteamOS release on something that has periodic stable releases and a security update story other than "upgrade everything", the obvious choice would be Debian - but we'll have to see what happens. > the gaming side of Linux still > receives major improvements with new releases of things like Proton You might have noticed that https://www.steamdeck.com/en/developers emphasizes Proton over native Linux games at the moment, as a way to get a broader range of games available, and the publicity videos seem to be mostly (entirely?) things like Jedi: Fallen Order that are Windows(-and-Proton)-only. Valve have said they're looking into getting a solution for Windows "anticheat" mechanisms under Proton, which are one of the biggest gaps in what Proton can do at the moment. Anything they do to improve Proton is going to benefit Arch and Debian equally. Current versions of Proton run in a container that is mostly Steam Runtime 2 (+ graphics stack from the host system). Steam Runtime 2 is very heavily based on Debian 10, with selected packages like SDL backported. A Steam Runtime 3 prototype based on Debian 11 exists, although there's no public release of it at the moment; if Proton starts requiring newer versions of something, it would be natural to assume that the priority of getting that prototype released will suddenly go up :-) Similarly, it is possible to set native Linux games to be run in a container via the "Steam Linux Runtime" compatibility tool, although it isn't the default. Until recently, this was Steam Runtime 1 (based on Ubuntu 12.04) plus the graphics stack from the host system. As of a recent update, it's changed to Steam Runtime 2, with a few libraries taken from Steam Runtime 1, and the host system's graphics stack as before - so a combination of a Debian derivative, an old Ubuntu derivative and the host system. I'm hoping that will result in better compatibility for games that implicitly assumed they were actually running on something newer than Steam Runtime 1. These benefit ordinary Linux systems like Debian just as much as the Steam Deck - perhaps more, because if the Steam Deck is running an Arch derivative, it will always need to be up-to-date (because that's the only way to get security updates in a rolling release), whereas non-rolling-release systems can easily have libraries that are older than those in a runtime container. I'm also
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Mon, 19 Jul 2021 at 02:25:16 +, Paul Wise wrote: > BTW, the Valve Arch Linux overlay thing appears to be here: > > https://repo.steampowered.com/arch/valveaur/ FYI, that's an overlay for "upstream" Arch, for Arch users who want to try out Mesa and kernel patches that are not yet mainline - analogous to the various PPAs provided by https://launchpad.net/~kisak. The name is analogous to AUR, the repository for unofficial addon packages for Arch. When SteamOS 3 becomes available to the public, I would expect it to be more likely to appear in some other directory on repo.steampowered.com. smcv
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sun, Jul 18, 2021 at 8:30 AM Hanno 'Rince' Wagner wrote: > On Sun, 18 Jul 2021, Paul Wise wrote: > > > Valve have said that this will be an open device that any OS can be > > installed on, just like on PCs, they even mentioned Windows so > > presumably it will be able to run Debian amd64 too if Valve are > > mainlining Linux hardware support. > > do we have a direct contact to steam regarding this? since I was able > to order one of these devices, I'd be interested in hearing wether > they will maintain the hardware support and would only have to add > their sources in apts repository. IIRC I heard it in one of these two IGN videos about the Steam Deck: https://www.youtube.com/watch?v=oLtiRGTZvGM https://www.youtube.com/watch?v=h9eihvhM_KE > if we do not have this communication (yet), I'd offer trying to start > such a conversation with Valve. Please do. IIRC they have been good about upstreaming their work on Wine/Proton so I would be surprised if they didn't do that for Linux support. So eventually you could skip using Arch Linux SteamOS and switch to Debian. BTW, the Valve Arch Linux overlay thing appears to be here: https://repo.steampowered.com/arch/valveaur/ The old Debian repos are on the same domain too: https://repo.steampowered.com/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sat, Jul 17, 2021 at 12:49 PM Samuel Henrique wrote: > The Steam Deck is a portable gaming device, running SteamOS, to be > released later this year. ... > SteamOS used to be based on Debian, and Valve seems to have decided to > go with Arch instead (great news for Arch, don't get me wrong). Valve have said that this will be an open device that any OS can be installed on, just like on PCs, they even mentioned Windows so presumably it will be able to run Debian amd64 too if Valve are mainlining Linux hardware support. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sat, Jul 17, 2021 at 01:48:32PM +0100, Samuel Henrique wrote: > SteamOS used to be based on Debian, and Valve seems to have decided to > go with Arch instead (great news for Arch, don't get me wrong). > > The reasons for the switch have not been publicized, but I think we're > safe to assume it's because Debian is not fit for the majority of the > desktop/gaming users, at least not officially (since testing is not a > supported release). I remember having some issues due to SteamOS being > based on stable. These are the people who need to be able to run the > most up-to-date packages, especially drivers and kernel (backports is > not always there). For information, a stable release including backports [1] is now available. 1: https://www.derivations.org/mirrorrib/ The stable release including backports is automatically updated every two or three months when the standard stable release (10.8, 10.9, 10.10 and so on) is issued. The manual page [2] explains. 2: https://www.derivations.org/mirrorrib.1.pdf What Valve does is up to Valve, but to the extent to which Valve requires stable releases (which Arch does not offer but Debian does), the foregoing might solve or partly solve Valve's driver problem without forcing Valve to transition away from Debian. Valve might try it before committing to the switch. The software that assembles the stable release including backports is available at [1] now and is to be uploaded to sid after bullseye's release. signature.asc Description: PGP signature
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sat, 2021-07-17 at 13:48 +0100, Samuel Henrique wrote: > Hello d-devel, > > As some of you already seem, we have very good news for the Linux > gaming community, although somewhat bad for Debian: > https://www.steamdeck.com > > The Steam Deck is a portable gaming device, running SteamOS, to be > released later this year. > Review video from 2kliksphilip: > Valve Steam Deck - The Budget Gaming PC We Need > https://youtu.be/zBEpymHvrpo > > The bad news for Debian comes from this page: > https://www.steamdeck.com/en/tech > Operating System: SteamOS 3.0 (Arch-based) > > SteamOS used to be based on Debian, and Valve seems to have decided to > go with Arch instead (great news for Arch, don't get me wrong). > > The reasons for the switch have not been publicized, but I think we're > safe to assume it's because Debian is not fit for the majority of the > desktop/gaming users, at least not officially (since testing is not a > supported release). I remember having some issues due to SteamOS being > based on stable. These are the people who need to be able to run the > most up-to-date packages, especially drivers and kernel (backports is > not always there). > > Now, this is ok for regular users, as they can take the risk[0] of > running testing to get all the benefits from it, and that's what I > recommend to pretty much anyone running Debian on a desktop, though I > recognize some people prefer to run stable. > > Debian Testing is very close to Arch wrt up-to-date packages (when not > frozen) but most people don't know this and we end up being known for > not supporting newer hardware/software[1]. > > This is a niche that is currently fulfilled by Fedora, Ubuntu non-LTS, > Arch... and Debian Testing (only one which is not an official > release). > > I know the situation is not as simple as calling Debian Testing > something else and making it an official release, my intentions here > are to expose the current issue we have: that we don't fulfill the > needs of a lot of desktop users and SteamOS is now Arch-based, most > likely because of this. > > So here's my wish that someday we can have a Debian semi-rolling > release (if we want to have it based on Testing), with security > support and a different name other than "Testing". > > [0] No security team support. > [1] And software matters here because the gaming side of Linux still > receives major improvements with new releases of things like Proton. > > Have a nice weekend! I think it would be quite nice to hear from Valve or some of the Debian folks who work(ed) with them, about the reasons for the rebase. With no ill will, just to understand what the problems were and if we can learn something from them. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Steam Deck: good news for Linux gaming, bad news for Debian :(
On Sat, Jul 17, 2021 at 01:48:32PM +0100, Samuel Henrique wrote: > that we don't fulfill the needs of a lot of desktop users It is known, as we don't even provide an official installer ISO that makes their hardware usable. > So here's my wish that someday we can have a Debian semi-rolling > release (if we want to have it based on Testing), with security > support and a different name other than "Testing". Obligatory https://wiki.debian.org/ReleaseProposals -- WBR, wRAR signature.asc Description: PGP signature
