1. 26
  1. 12

    Some probably blame this on the Linux/AMD64 hegemony (with a dash of ARM thrown in) in the UNIX world, but I think this fade out would have happened regardless of that. This quote from cks nails it, in my opinion:

    and partly this is because cross machine shared home directories have gone out of style in general

    I believe it’s due to the rise in personal computing. The fact is that the majority of UNIX systems nowadays are not shared systems any more, they’re single operator (I’m using that term to avoid confusion with UNIX’s notion of a user) machines, more powerful than the shared systems that they’ve replaced. Having a shared /home or /usr/share would mean each and every user going out of their way to set up an NFS share on their networks, which in addition would be inaccessible or unreliable over wireless connections which have also become increasingly prevalent.

    In a university setting, like cks’ situation, most students and faculty have their own machines now, and the rise of file sharing and online collaboration software has rendered much of the need for those shared systems moot. The maths department where I studied still runs a fleet of servers with /home shared between FreeBSD and debian. The machines receive little use except for staff hosting their personal/professional sites, and the occasional coding assignment. Everything else is done by students and staff on their own machines.

    1. 13

      The fact is that the majority of UNIX systems nowadays are not shared systems any more, they’re single operator

      “We’ve gone from discussing users-per-CPU to CPUs-per-user” - paraphrase of Tom Van Vleck of Multics fame

      1. 4

        I believe it’s due to the rise in personal computing.

        Also probably the rise in affordable disk storage. Back when disk was expensive, it made much more sense to share it. These days storage is pretty cheap, so to avoid the complexity of a network sharing setup, just duplicating everything on install is pretty straightforward.

        1. 3

          I think the rise of personal computing is the main reason too, even though I lament the loss of a lot of the architectural diversity of the past. I have independent home directories on each one of my systems, and I really have no need for NFS or a similar shared directory system except for the handful of toys I have where this is useful or mandatory (such as no local storage of their own).

          At work, where I do have a shared home repository, everything is Windows (so home is the M: drive).

        2. 7

          There is a bit of cottage industry around putting your HOME in VCS. http://vcs-home.branchable.com/

          Shared home is out of fashion, but I don’t think the use case disappeared.

          1. 2

            I wish you could favourite replies on this site. Thank you for the link! :)

          2. 2

            multi-arch packages are well supported in Debian and used in embedded development and to do ports in general. ARM is the typical example and RISC-V the new use-case.

            The hegemony of AMD64 is holding back innovation and we should not allow our toolchains to become native-only.

            1. 2

              All of this pushed both Unix systems and user home directories in a certain direction, one where it was sensible to have both /usr/share and /usr/lib, or /csri/share and /csri/lib, the latter of which was magically arranged to be a symlink to the right architecture for your current machine.

              What was “csri”? Some site-specific thing?

              1. 4

                Most likely the Computer Systems Research Institute, also at the University of Toronto. See also: Rob Pike, Henry Spencer

              2. 2

                It’s a good article but I wish the author would have taken it farther.

                Like, why have we lost the knowledge of / ability to trivially do multi-architecture installations? One reason is that the tools that enabled them were hela-complex with a learning curve that was more like a cliff (I’m looking at you, Gnu autotools/autoconf).

                1. 1

                  This is my workaround for go get:

                  export OS=`uname`
                  
                  # make `go get` arch-aware
                  export GOBIN=$GOPATH/bin/$OS
                  
                  # make PATH arch-aware
                  export PATH=...$GOBIN...
                  
                  1. 2

                    You’d be slightly better off with:

                    export OS=$(uname -sm | sed 's/ /-/')
                    

                    That’d let you have different binaries for different processor architectures like ARM or POWER9