Re: merged /usr considered harmful
Summary: let go, let go On Sat, Jul 17, 2021 at 09:13:57PM +, Thorsten Glaser wrote: > > And no, I’m not going to embrace every unnecessary change thrown my way. None of us does embraces every unnecessary change. We all choose our battles wisely. > No; usrmerge is broken from the PoV of Debian’s package manager. > Running usrmerge breaks assumptions done by dpkg; you can probably > do it with RPM or something, but it’s not supported with dpkg. Hence a change. Groeten Geert Stappers -- Silence is hard to parse
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
Bug#991219: ITP: ruby-kas-grpc -- Auto-generated gRPC client for KAS
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-kas-grpc Version : 0.0.2 Upstream Author : Gitlab.org * URL : https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent * License : Expat Description : Auto-generated gRPC client for KAS The Kubernetes Agent Server (KAS) is a GitLab backend service dedicated to managing Kubernetes Agents. This gem is the auto-generated gRPC client for it.
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: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Sat, 17 Jul 2021 at 20:34:41 +, Johannes Drexl wrote:
> /usr is allowed to be not only on a separate partition, but even on a
> network device
This has been discussed at considerable length before, but I'll try to
recap:
A separate or network-mounted /usr is possible in Debian, whether
merged-/usr is used or not, but only if /usr is already mounted
by the time the system hands over from the initramfs (usually generated by
initramfs-tools, or sometimes dracut or another alternative) to the main
system (which starts systemd, sysvinit or some other init system as the
main pid 1 and proceeds from there). Merged /usr is actually better for
this configuration than unmerged /usr in some ways: it lets you share
*all* the non-modifiable files between machines, not just the ones that
are in /usr (as opposed to /lib, /bin, /sbin).
This is not a new requirement: Debian >= 9 (2017) officially did not support
mounting /usr halfway through the main system boot process. Older Debian
releases aimed to support /usr being mounted during boot (for example
during the rcS sequence in sysv-rc) but it frequently didn't actually
work in practice, particularly if combined with network mounts.
The reason why mounting /usr during main-system boot is no longer
supported is that it often didn't work. A major reason why it often didn't
work is that depending on how the system is configured, mounting /usr can
require networking; but bringing up networking can require arbitrarily
many programs and libraries (networking infrastructure like ifupdown or
NetworkManager often has either a plugin architecture, or an arbitrary
hooks mechanism that executes programs of the sysadmin's choice that
will often have dependencies in /usr, or both).
Similarly, udevd needs to run early in the main system boot to bring up
/dev, but udev rules can run arbitrary programs, some of them in /usr;
and for the main system, those programs often need data from /usr/share.
More generally, if we took every library and every program that could
conceivably be a dependency of /usr and moved them from /usr into the
root filesystem, then the root filesystem would become increasingly large
over time, negating any benefit that you hoped to gain by mounting /usr
separately. Over time, this approach would tend towards the layout that
the Debian Hurd port briefly tried to use, which was the opposite of
merged-/usr (you could call it "merged rootfs"), with /usr as either a
symlink to /, or containing only symlinks to /lib, /bin and so on.
Instead, we require everything that is needed in *your* configuration
(not necessarily in *anyone's* configuration, just yours!) to be part
of the initramfs, which is generated per-machine.
Effectively, the requirement to mount /usr before pivoting from initramfs
to main system means that instead of a small rootfs (which can be used for
recovery) and a larger /usr, we have a small initramfs (which can be used
for recovery) and a large main system.
One key advantage of this is that decisions about what to include in
the rootfs (of non-merged-/usr systems) have to be made globally for all
of Debian, but decisions about what to include in the initramfs can be
made per-machine, allowing some otherwise impossible situations to be
resolved. If your /usr is mounted via NFS, but bringing up my network
requires /usr (perhaps for a VPN), in the old model with a small rootfs
and a larger /usr it was impossible for us both to have what we needed:
we could not bring up networking both before /usr (as you would have
needed) and after /usr (as I would have needed).
> /usr is allowed to be [...] on a network device shared by other machines
The FHS may allow this, but it has significant practical problems,
unrelated to merged-/usr, on machines that receive security/stable updates
(which I would hope by now should mean all machines). Updates to Debian
packages can touch both mutable per-machine files (/etc, /var) and
immutable/shareable per-(package,version) files (/usr, /lib*, /bin, /sbin).
If a machine's /usr is not in sync with its /etc and /var, then it is likely
to work incorrectly: at a minimum, asking dpkg which packages and versions
are installed will give you an answer that does not match what is actually
in /usr.
On non-merged-/usr systems, the machine's /usr and {/lib*,/bin,/sbin}
must also be kept in sync: for example, there is no guarantee that
/usr/bin/dbus-daemon (in /usr) will work correctly with a mismatched
version of /lib/x86_64-linux-gnu/libdbus-1.so.3 (on the rootfs of a
non-merged-/usr system). On merged-/usr systems, it is impossible for
those directories to become out-of-sync, so this particular requirement
becomes trivial to achieve.
A more robust approach to sharing /usr between machines (or containers)
might be to give each machine (or container) its own private /usr or even
its own private root filesystem, and then carry out file- or block-level
deduplication on the storage backend (for example, if /usr is NFS-sh
Re: merged /usr considered harmful
Johannes Drexl dixit: >embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that >/usr is allowed to be not only on a separate partition, but even on a >network device shared by other machines: This hasn’t been true on Debian for a while (partially due to the systemd/usrmerge proponents, partially due to the difficulty of deciding what needs to be present). You have had to either ensure /usr is mounted by an initrd or it’s not on a separare filesystem for a while, already (and that was fine with me, it’s the usrmerge crap that totally pointlessly breaks things). And no, I’m not going to embrace every unnecessary change thrown my way. Magissia dixit: >In this case, this page should be updated to reflect the fact it is not >broken. No; usrmerge is broken from the PoV of Debian’s package manager. Running usrmerge breaks assumptions done by dpkg; you can probably do it with RPM or something, but it’s not supported with dpkg. bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
Am Freitag, dem 16.07.2021 um 10:09 +0200 schrieb Thomas Goirand: > Merging binaries in /usr and getting rid of /bin and /sbin, at the > end, > WILL be an improvement. Debian cannot be the last distro not doing > the > move, I hope you understand that. > > Also, I'm having a hard time understanding why moving binaries around > should just break any system Well, I'm only an interested SysOp here, but I share his reluctance to embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that /usr is allowed to be not only on a separate partition, but even on a network device shared by other machines: Quoting FHS 3.0, chapter 4.1, Purpose of /usr: '/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to.' On the other hand /bin and /sbin need to be on the root partition in case mounting of other partitions doesn't work (as in "no network available"). Quoting FHS 3.0, chapter 3.16.1, Purpose of /sbin: '/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin.' So yes, with getting rid of /bin and /sbin you break the systems emergency resilience and deviate from a known and not really that old standard. I'm not quite sure how this is an improvement - rather I'm curious how one could perceive this as such. For all I've seen in my time as a SysOp, I'd rather have my emergency tools in /sbin and /bin than booting a live system every time a server has broken mounts. That all said, I'm not fully against the change, I just don't see the benefit but instead quite a lot of problems down the road. BR Jo signature.asc Description: This is a digitally signed message part
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
Steam Deck: good news for Linux gaming, bad news for Debian :(
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! -- Samuel Henrique
