Also systemd has a "file-hierarchy" man page for its understanding of the hierarchy, which includes e.g. its use of /run and which directory can be read-only - https://man7.org/linux/man-pages/man7/file-hierarchy.7.html
https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
Not only feasible but it's been implemented a few times over the years. The most notable being GoboLinux[1][2], which is nearly 20 years old.
[1] https://en.wikipedia.org/wiki/GoboLinux
> I was thinking "just symlink /sbin with /bin", but there would probably be conflicts
Given how long /sbin et al have been around, there would always be some edge cases. However it is still possible to do. GoboLinux uses symlinks to achieve LFH[3] compatibility while still having friendly directory names. ArchLinux also just has one bin directory and uses symlinks for compatibility:
» ls -l / | grep bin
lrwxrwxrwx 1 root root 7 2021-12-07 02:41 bin -> usr/bin
lrwxrwxrwx 1 root root 7 2021-12-07 02:41 sbin -> usr/bin
» ls -l /usr | grep bin
drwxr-xr-x 5 root root 110,592 2022-05-06 09:23 bin
lrwxrwxrwx 1 root root 3 2021-12-07 02:41 sbin -> bin
The problem is that the actual benefits a pretty nebulous, so it's probably not worth the effort (and drawbacks of using different conventions than most others *nix users).
On FreeBSD 3rd party packages go into /usr/local and not /usr
You absolutely will get base packages in /usr/bin (eg `env`) so nuking /usr/bin will break your FreeBSD install.
There's a good write up here: https://unix.stackexchange.com/questions/332764/role-of-the-...
It means that if someone decides to get away from this legacy structure and move OS into something like /system/debian-11.1.2/ all those programs would break.
Examples: [1], [2]. I assume that developers have hardcoded those paths because /sbin is often not included into PATH.
[1] https://github.com/blueman-project/blueman/blob/fcef83a01c80...
[2] https://github.com/blueman-project/blueman/blob/fcef83a01c80...
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
You may be thinking of the /bin and /usr/bin difference, though.
> Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.
> /bin/ User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
> /sbin/ System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.
It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.
Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).
He's even added a warning to dpkg and a "usrunmess" tool to switch a system to his preferred way of doing things.
It's not clear to me where the breakage lies and I've not seen any actual reports of it.
For more context see https://lwn.net/Articles/890219/
FWIW, Slackware keeps the separate, following the Linux Standard Base.
What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in.
Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap.
Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped.
Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix.
Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden.
There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356
[2]: https://github.com/kubernetes/kubernetes/issues/56402
[3]: https://github.com/flatpak/flatpak/issues/1651
[4]: https://savannah.gnu.org/support/?108134
[5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...
[6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...
[7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...
Of course, the "stuff from BSD" winds up in /bin and /usr/bin anyway, so it's still a mess.
https://developer.apple.com/library/archive/documentation/Fi...
https://stackoverflow.com/questions/12427245/installing-in-p...
- Make sure alsa-utils is installed
- Auto-configure hardware devices: alsactl init
- View hardware for playback (use arecord for opposite): aplay -L | grep “^hw:”
^ Use that to make sure your hw is being detected
- Lower level list of sound cards, if having issues: cat /proc/asound/cards
- Base alsa conf: /usr/share/alsa/alsa.conf
^ go there to dive deeper into what alsa is actually doing. It will also show you the priority for config files, so you can go through that and check which ones are in use and modify accordingly. alsactl init should handle most configuration though.
- you will want to mess with this: /etc/modprobe.d/alsa-base.conf …and get it working for your hardware. This is a resource to understand that file better: https://alsa.opensrc.org/MultipleCards
You can google configuration files and find one that works for you. Most issues for normal use will revolve around which card gets set to index 0 / default, so if you know your card you want as default, I’d recommend finding your device id (i think cat /proc/asound/cards will give you vendor/product ids you can use) then making a config using that id to set it as the default card, independent of indexing.
Turned into a lot, stopping here. Sound really shouldn’t be this hard for end users or devs, but it is what it is right now. Anyway, it’s fresh on my mind so at the very least, I might be able to point you in the right direction.
Good luck!
- Someone with no more hair left to pull out