Bug#1035904: What does merged /usr bring us
On 2023/05/15 20:26, Sam Hartman wrote: I want to stress that I'm not a huge fan of merged /usr, and I know you've encouraged me not to argue from a devil's advocate position in the past. And this is where I stop reading any further. To merge or not to merge is no longer an interesting or more importantly, a relevant discussion. The project has made the choice to implement it, after we've been one of the last major distributions to hold out on implementing it. Sure, it's been bumpy, and there's potential downsides, but none of the technical problems are as harmful as still trying to make this a debate. So, please, file bugs or fix bugs and support the people who need to complete the remaining bits of merged-/usr, or otherwise please move on. -Jonathan
Bug#1035904: What does merged /usr bring us
> "Sam" == Sam Hartman writes: Sam> Hi. Off list, I wanted to try to explain what I think merged My apology for sending a mail intended to be private to the bug. It was not my intent to clutter an already cluttered discussion. I was really just trying to help provide what understanding I had to a friend. --Sam
Bug#1035904: What does merged /usr bring us
Hi. Off list, I wanted to try to explain what I think merged /usr has brought us that is positive. I want to stress that I'm not a huge fan of merged /usr, and I know you've encouraged me not to argue from a devil's advocate position in the past. All the things I cite here are things I actually think are a positive value, but I fully agree they do not justify the change to me. * Normalization of paths. Whether things ended up in /usr/bin or /bin tended to vary between unixes and especially between linux distros. That has produced a lot of complexity over the years in build systems. But it's also produced a lot of non-portable software--stuff written either for Redhat or Ubuntu that manages to get the path wrong for the other, and doesn't have the complexity of something like autoconf to detect the change. It's kind of nice to ignore all that. * There's work, from people related to the systemd crowd, to effectively get to a place where the initial state of a system is very close to empty with a few symlinks and a read-only /usr. And then possibly things get filled in a bit on first boot if necessary. So, for example the systemd style split of /usr/lib/systemd/system vs /etc/systemd/system where the /etc path generally gets to be empty at least initially is part of this. In some ways it reminds me of how AIX dealt with diskless workstations. (I realize that's based on how Sun did it, but I never dove into SunOS or Solaris as deep as AIX). The goal is more for containers or for deploying updates to EOT devices than for diskless. The ideais kind of cool. The updater/installer/container creater knows very little and can start with an initial state. It's easy to figure out what has been customized because anything in /etc is a customization. doing a factory reset is fairly easy. It works well with signed OS images and ostree for deploying updates/the sort of thing Endless does. And yet there are probably other ways to get all the same benefits. --Sam
