Content deleted Content added
m Fix Linter errors. |
|||
| (12 intermediate revisions by 10 users not shown) | |||
Line 1:
{{WikiProject
{{WikiProject Computing |importance=Mid |science=y |science-importance=Mid |software=y |software-importance=Mid}}
{{WikiProject Linux |importance=Mid}}
}}
== /sbin's name ==
Pretty sure that sbin intially stood for static linked binaries. <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/173.55.202.3|173.55.202.3]] ([[User talk:173.55.202.3|talk]]) 08:16, 3 May 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
:Given that <
::I always understood it to mean "system administration binaries", but I can't remember ever having an explicit explanation of the name. [[User:Qwertyus|Q<small>VVERTYVS</small>]] <small>([[User talk:Qwertyus|hm?]])</small> 23:16, 19 November 2013 (UTC)
:::I have the impression that ("system administration", or something such as that) was what the "s" meant. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 00:09, 20 November 2013 (UTC)
== /usr/libexec is in FHS ==
Line 18:
http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html
:That URL has "betaspecs" in it; [http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#THEUSRHIERARCHY the /usr section of the 2.3 version of the FHS] doesn't mention <
== So where did /sbin, /usr/sbin, and /var come from? ==
Actually, unless my memories are too faded, I ''know'' where they came from - some people at Sun, around the time SunOS 4.0 was being developed, were making some changes to the directory layout, oriented towards NFS-only diskless workstations (when Sun were killing of the ND remote-disk-access protocol), and one of the changes was the introduction of <
I seem to remember a document written describing this, and possibly even being circulated outside Sun (possibly amongst licensees of NFS and/or the BSD folk). However, I can't seem to find any trace of that document online. Anybody have less-faded memories than mine? [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 01:26, 17 November 2013 (UTC)
:I don't have the document you want, but wouldn't <
::(<
::Yeah, I think that was another reason for creating <
::I think the split between <
::But this is all fading memories from the mid '80's, which is why I wish the stuff the Sun folks had written about this was available somewhere. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 20:16, 18 November 2013 (UTC)
Line 39:
[[Special:Contributions/174.46.232.2|174.46.232.2]] ([[User talk:174.46.232.2|talk]]) 18:19, 3 April 2014 (UTC)
:That was the original split. The directory layout was changed in SunOS 4.0, with <
== Other Unices, other filesystems ==
Line 90:
:::::::::So it would be a mistake to say that {{mono|/tmp}} ''is'' a small file system or a file system that ''will'' be cleared or reboot or that ''will'' have files not recently referred to removed. We should, at most, note that it ''might be'' small (it is quite literally no smaller than {{mono|/var/tmp}} on my machine, as they're on the ''same partition'', and [[HFS+]] doesn't have per-directory size limits) and that files ''might be'' removed on reboot or ''might be'' removed after some period of time, depending on whether the OS you're using happens to use tmpfs or clean {{mono|/tmp}} on reboot (that's not a requirement, and, in fact, FreeBSD 10.1 didn't remove a file in {{mono|/tmp}} on reboot when I tried it just now) or whether {{mono|/tmp}} happens to be on a small root partition or whether it happens to be a tmpfs file system that imposes a RAM-only-based size limitation. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 17:22, 30 March 2015 (UTC)
::::::::::Tmpfs on Solaris supports large files if the kernel is running in 64 bit mode. This is because a 32 bit kernel cannot deal with an address space > 4 GB (which still is larger than the official large file limit of 2**31-2 ;-) [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 13:09, 31 March 2015 (UTC)
:::::::::the thing with filesystems, people know how big their hard drives are. Compared to that RAM+swap is usually ridiculously small, sometimes less then the memory of a mediocre phone and imho this is worth noting.[[User:Richiez|Richiez]] ([[User talk:Richiez|talk]]) 22:29, 30 March 2015 (UTC)
Line 114 ⟶ 116:
::::::::::11 years ago, I build my first Opteron based PC and there are 4 GB RAM, 10 GB swap, 10 GB root fs with 1 GB free space and /var/tmp is now on that space, so I have 10 GB of free space in /tmp and 1 GB of free space on /var/tmp. The ratio did not really change since 1988. But even on a newer server at my university, /var/tmp/ is not larger than /tmp. So the text introduced by [[User:Richiez]] is at least missleading and if we rate tmpfs, we should look at the original implementation instead of a Linux clone. [[User:Schily|Schily]] ([[User talk:Schily|talk]]) 12:07, 31 March 2015 (UTC)
== Add the /run directory ==
The run directory is a new addition to Linux that contains files that programs need through reboots, because /tmp is vulnerable to getting wiped. Is this a useful addition to the article? I'm asking this because this is article for the industry standard Unix filesystem, and not anything added by an OS. <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:One Blue Hat|One Blue Hat]] ([[User talk:One Blue Hat#top|talk]] • [[Special:Contributions/One Blue Hat|contribs]]) 20:51, 16 January 2020 (UTC)</small> <!--Autosigned by SineBot-->
:{{u|One Blue Hat}}, I'd say probably not, because, as you said, this is based on the standard UNIX filesystem. [[User:Moonythedwarf|MoonyTheDwarf (Braden N.)]] ([[User talk:Moonythedwarf|talk]]) 20:55, 16 January 2020 (UTC)
::Yes - {{mono|/run}} is already covered in [[Filesystem Hierarchy Standard]], but not all Unix-like systems follow the FHS in its entirety. (macOS, for example, currently has {{mono|/var/run}} but not {{mono|/run}}.) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 21:17, 16 January 2020 (UTC)
== Merge with [[Filesystem Hierarchy Standard]]? ==
The ''Conventional directory layout'' section contains information also in [[Filesystem Hierarchy Standard]]. Should the two be merged? <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/151.53.72.73|151.53.72.73]] ([[User talk:151.53.72.73#top|talk]]) 23:22, 9 September 2020 (UTC)</small> <!--Autosigned by SineBot-->
:They both contain that information because the FHS is based on conventional UN*X usage, as per the quote from that section:
:{{quote|The details of the directory layout have varied over time. Although the file system layout is not part of the [[Single UNIX Specification]], several attempts exist to standardize (parts of) it, such as the [[UNIX System V|System V]] [[Application Binary Interface]], the [[Intel Binary Compatibility Standard]], the Common Operating System Environment, and [[Linux Foundation]]'s [[Filesystem Hierarchy Standard]] (FHS).}}
:I wish I could find a reference for this, but at least some of the layout comes from a proposal that some people at Sun made in the 1980's containing, among other things, the {{mono|/var}} directory; at least part of the goal was better support for [[diskless workstations]], with per-machine and shareable information divided up so that they could be on different remote-mounted file systems.
:Not every system that uses some form of the conventional layout follows the FHS. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 00:23, 10 September 2020 (UTC)
| |||