Login
You're viewing the mstdn.social public feed.

Replies

  • Resunaresuna@ohai.social
    Jun 27, 2026, 9:00 PM

    @nixCraft

    Meanwhile I once changed Linux distributions because the one I was using didn't let me make the initramfs large enough without going through more shenanigans than I felt was worth my while.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 2
  • ARGVMI~1.PIFargv_minus_one@mastodon.sdf.org
    Jun 27, 2026, 10:47 PM

    @nixCraft

    #NeXT / #Apple had the right idea.

    * User homes are in /Users

    * Each app is in /Applications and looks like a regular file but is actually a folder (i.e. you can cd into it and examine the contents)

    * The operating system is in /System

    * Files shared among apps (except files that come with the OS), including configuration files, are in /Library

    * Static libraries, debug info, C headers, OS API reference docs, etc go in /Developer

    #macOS #MacOSX #NeXTSTEP #Linux #Unix #BSD

    💬 3🔄 5⭐ 9
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 1
  • 💬 1🔄 0⭐ 0
  • David Chisnall (*Now with 50% more sarcasm!*)david_chisnall@infosec.exchange
    Jun 28, 2026, 8:13 AM

    @argv_minus_one @GnosticStreetSweeper @nixCraft

    They also have /proc, but not /sys. Linux’s sysfs serves largely the same purpose as sysctl on BSDs, but sysctl has a few benefits:

    • It’s structured and the types are introspectable (nodes also expose human-readable descriptions). The command-line tool that exposes them for scripting can provide the structure to scripts.
    • Reading or writing one is a single system call, not an open, read/write, close sequence.
    • They don’t look like files, so don’t fail in weird ways (e.g. requiring reads of specific sizes).
    • They don’t consume a file descriptor.

    Their one disadvantage is that they don’t automatically benefit from file-namespace sandboxing tools. On FreeBSD, for example, there’s an allow list for sysctls that can be used in Capsicum capability mode but there’s no way of adding a sysctl to that list.

    💬 1🔄 1⭐ 5
  • 💬 0🔄 0⭐ 0
  • Xenotarxenotar@mastodon.social
    Jun 30, 2026, 4:28 PM

    @argv_minus_one @nixCraft I liked the setup SunOS 4 used. User home directories were located in `/home/hostname`, which made it easy to share them via NFS across multiple workstations. Shared applications resided in `/usr/local` on the disk server and were shared by all workstations, while accounts were managed via NIS.
    +

    💬 1🔄 0⭐ 1
  • Xenotarxenotar@mastodon.social
    Jun 30, 2026, 4:29 PM

    @argv_minus_one @nixCraft
    With Linux creating local `/home` directories, placing applications in `/usr/bin` and `/usr/lib`, and merging `/lib` with `/usr/lib`, `/bin` with `/usr/bin`, and `/sbin` with `/usr/sbin`, etc we are heading toward a Linux version of `C:\Windows`.

    💬 0🔄 0⭐ 1
  • Nazonazokiyoubinbou@urusai.social
    Jun 27, 2026, 10:55 PM

    @nixCraft I'm starting to really understand lately how much there really is a bureaucracy in Linux of all things lately, especially with stuff like how everyone just accepted integrating systemd deep in their systems solely because the bureaucracy did (and it really kind of decided against the votes saying to at least review it more before actually doing it.)

    There are so many examples of this sort of thing really. It truly would help if a lot of these people would take a better look back at the origins and reasons of these things and actually be willing to question if they should continue things that ultimately aren't helping at all (or even worsening everything.)

    💬 1🔄 0⭐ 3
  • Norman Wilsonoclsc@mstdn.ca
    Jun 28, 2026, 3:17 PM

    @nazokiyoubinbou @nixCraft Large groups of people act like that, unfortunately. Consensus becomes impossible.

    The Computing Science Research Center at Bell Labs, whence came Unix, was relatively small. I was there in the late 1980s and it was only about 60 people, not all interested in system design and organization. Consensus was easier and worked well. Granted that by the late 1980s that group's influence over Unix had waned considerably.

    💬 0🔄 0⭐ 2
  • Douglas Floyddfloyd888@fosstodon.org
    Jun 28, 2026, 1:38 AM

    @nixCraft /usr/usb and /usr/X11 or /usr/bin/X11 are good historical stories as well. /usr/ucb should never exist on any Linux distro, regardless of time, unless it is a symlink for old school compatibility purposes.

    💬 1🔄 0⭐ 1
  • JdeBPJdeBP@mastodonapp.uk
    Jun 28, 2026, 9:54 AM

    @dfloyd888 @nixCraft

    You haven't gone down the rabbit hole far enough if you haven't yet reached /usr/amdahl/ . (-:

    jdebp.info/FGA/unix-path-and-p

    It is amusing that you state that /usr/ucb should never exist, given that Arch Linux has had to invent in place of it /opt/bsdutils in order to accommodate David Cantrell's import of actual BSD tools (from FreeBSD) that conflict with the GNU coreutils tools placed in /usr/bin , /opt/BSDuserland for @diegomagdaleno's fork of Cantrell's work, and /usr/lib/vlang-coreutils for yet another conflicting set of tools.

    Cantrell's own spec file for RPM actually specifies /usr/ucb as the install directory.

    I submit that /usr/ucb is alive and well in Linux distributions, just hiding under several pseudonyms, or actually out in the open in the case of RedHat. (-:

    aur.archlinux.org/packages/bsd

    aur.archlinux.org/packages/bsd

    aur.archlinux.org/packages/vla

    archlinux.org/packages/core/x8

    codeberg.org/dcantrell/bsdutil

    #Unix #PATH #ArchLinux #Illumos #RedHat

    💬 0🔄 0⭐ 1
  • 💬 0🔄 0⭐ 0
  • Norman Wilsonoclsc@mstdn.ca
    Jun 28, 2026, 3:08 PM

    @nixCraft Basically correct but mistaken in one or two minor details.

    The origin of /usr/bin and /usr/lib is as described, but original ken/dmr Unix had no sbin. sbin these days is taken to mean programs meant only for sysadmins; in the early such programs were in /etc or just /bin.

    As I vaguely remember--and I may be mistaken myself here--the s in /sbin originally meant statically-linked, programs like mount that were need to make /usr and hence shared libraries available. (What about /bin/sh? I don't remember.) In that meaning there was no /usr/sbin; it made no sense.

    As an old-timer who is always looking to make things smaller and simpler, were it up to me (and it surely is not), I'd abolish /usr except as a place for users' home directories. And I'd abolish /etc as well: executables have a good home now in /sbin, config/data files should move to /lib, which was originally a general library of files need by programs in /bin, not just subroutine libraries.

    💬 0🔄 0⭐ 0