# Some general observations on FreeBSD from a rookie coming from Linux



## mrbeastie0x19 (Sep 17, 2021)

Hi everyone. I have used Linux since Ubuntu 12.04. Lately I have noticed a gradual decline in that system and even seem to enjoy using Windows 10 more, so I have been looking at alternatives.

These are just some of my thoughts on the installer process and base system.

Copying the ISO very easy and many options available. Good start. The installer is very plain. However it is functional, unlike Red Hat's Anaconda which has crashed my system multiple times. Not quite as beautiful as Ubuntu's live installer, but perhaps less likely to crash than its command line installer (which I think is a fairer comparison given the base install is similar to a server install).

Selecting keyboard layout easy enough. The modular separation of optional components is great, as is the fact my hardware actually seems to be automatically detected (Debian's has choked on finding the cdrom or network interfaces multiple times). Partitioning easy enough with the default options selected. Fetching the distribution took a matter of minutes, significantly faster than the Debian apt-get, although I think that fetches the files from the network whereas this ISO already has them available and just does the extraction.

Setting the root password was a little confusing, if you make a mistake you kind of just have to type it in wrong twice.

Creating a user account was actually really easy.

Timezone setting was a little unintuitive. Many options and did not seem to detect daylight savings.

On the whole I found the process to be very pleasant, the system (particularly the file system) seems more consistent and the boot times are quicker than my Linux install was. 

That installed a very quick but bare bones system that does not include a graphical display. Setting that up was also very easy, just pulling in pkg, which seems slightly slower than apt but comparatively fast compared to dnf on Fedora.

Some not so good things:

Multiple LLVM versions are required to build packages and ports. The current implementation leads to a polluted file system structure, I think a better solution would be a dedicated /usr/local/bin/llvm/version/ directory. I did think it would be more consistent to compile ports with the same compiler as the base but I understand there might be technical limitations to that.

The ports and packages system seems really dependent on pulling in a large number of unnecessary software, I understand the approach is generic in the case of packages but it does have a tendency to bring in Linux stuff like pulseaudio. That's really quite unfortunate. I don't know what the solution to that would be in large software projects like Firefox where you guys might not have much control over the source.

The base system seems to include references to Xorg, which confused me since Xorg is not included by default.

Some of the naming seems a little inconsistent. For example why is there a CC and Mail in /usr/bin? These look like links to c++ and mail, but why are these treated specially?

I noticed that svn has been replaced by git, but the svn tools remain in base. Are these being replaced?

On the whole I am really impressed with the project and the amount of work that has gone into it seems really quite remarkable given the lack of awareness of the system.


----------



## SirDice (Sep 17, 2021)

mrbeastie0x19 said:


> Some of the naming seems a little inconsistent. For example why is there a CC and Mail in /usr/bin? These look like links to c++ and mail, but why are these treated specially?


cc(1) is part of LLVM, there is an LLVM version (specific version depends on the FreeBSD version) included with the base OS. mail(1) is part of the sendmail suite, which is also included with the base OS.



mrbeastie0x19 said:


> I noticed that svn has been replaced by git, but the svn tools remain in base. Are these being replaced?


Eventually. The transition to git was fairly recently done. The next major version (14) will likely remove those old svn tools. There's still some debate about which tool(s) to include for git, net/gitup appears to be a strong contender.


----------



## mrbeastie0x19 (Sep 17, 2021)

SirDice said:


> cc(1) is part of LLVM, there is an LLVM version (specific version depends on the FreeBSD version) included with the base OS. mail(1) is part of the sendmail suite, which is also included with the base OS.
> 
> 
> Eventually. The transition to git was fairly recently done. The next major version (14) will likely remove those old svn tools. There's still some debate about which tool(s) to include for git, net/gitup appears to be a strong contender.


With regards to the CC and Mail I don't think I have quite understood you (or you me?), I am curious why there is both a lowercase and uppercase cc (there is both a cc and CC in the directory, and a mail and Mail). And thanks that makes sense about git!


----------



## Jose (Sep 17, 2021)

mrbeastie0x19 said:


> Multiple LLVM versions are required to build packages and ports. The current implementation leads to a polluted file system structure, I think a better solution would be a dedicated /usr/local/bin/llvm/version/ directory. I did think it would be more consistent to compile ports with the same compiler as the base but I understand there might be technical limitations to that.


Use poudriere(8) to build ports if you're concerned about filesystem pollution. It builds everything in a jail.



mrbeastie0x19 said:


> The ports and packages system seems really dependent on pulling in a large number of unnecessary software, I understand the approach is generic in the case of packages but it does have a tendency to bring in Linux stuff like pulseaudio. That's really quite unfortunate. I don't know what the solution to that would be in large software projects like Firefox where you guys might not have much control over the source.


The philosophy is to provide pre-compiled packages that include most of the things any reasonable person is likely to want. This does translate into often very heavy dependency trees for even trivial software. Some packages have -lite, and even -tiny versions, like git(1), for example. It sounds like you may be building your own packages using the ports framework. You can tune dependencies in the ports tree using a custom make.conf(5). Again poudriere(8) makes it easy to use different make.conf files for different package sets. I use it to build the packages for both this machine and my headless server.








						Share your make.conf and src.conf
					

Hello :)   It would be nice that experienced users shared their make.conf and src.conf to help new users like me :)  I know that there are man pages and I read both of them, but real user's configurations are IMHO also helpful!




					forums.freebsd.org


----------



## zirias@ (Sep 17, 2021)

Additionally, you'll almost always have a lot more build-time dependencies than run-time. So don't compare using the ports-tree, building your own, to some binary package manager on some Linux dist. Compare using pkg(8) to that (or compare building your own packages using the methods of some Linux dist to using the ports tree).


----------



## SirDice (Sep 17, 2021)

With regards to mail(1):

```
root@molly:~ # ls -ali /usr/bin/Mail /usr/bin/mail
251018 -r-xr-xr-x  3 root  wheel  102696 Sep 15 14:44 /usr/bin/Mail
251018 -r-xr-xr-x  3 root  wheel  102696 Sep 15 14:44 /usr/bin/mail
```
They're the same executable (they're hardlinked; inodes are the same). To be honest I don't know why there's a 'Mail' and a 'mail', I suspect it has something to do with an old habit or something from the past. 

I'm not sure why /usr/bin/CC and /usr/bin/cc exist. Might be because lots of scripts (and makefiles) use a variable named CC, that's set to a compiler. Failure to declare it properly would result in an error. It's easy to mistype `$CC`, forget to include the `$` to get `CC`. But that's just speculation on my part.


----------



## zirias@ (Sep 17, 2021)

SirDice said:


> I suspect it has something to do with an old habit or something from the past.


Probably, some ancient tools/scripts exist(ed) somewhere expecting the capitalized names, yes. A hardlink hardly costs anything, so, why not


----------



## SirDice (Sep 17, 2021)

Zirias said:


> Probably, some ancient tools/scripts exist(ed) somewhere expecting the capitalized names, yes. A hardlink hardly costs anything, so, why not


Apparently it's been there since 1.0-RELEASE. Might be something that was common on 4.4BSD or even older. 




__





						Makefile « mail « usr.bin - src - FreeBSD source tree
					






					cgit.freebsd.org


----------



## Argentum (Sep 17, 2021)

mrbeastie0x19 said:


> The ports and packages system seems really dependent on pulling in a large number of unnecessary software, I understand the approach is generic in the case of packages but it does have a tendency to bring in Linux stuff like pulseaudio. That's really quite unfortunate. I don't know what the solution to that would be in large software projects like Firefox where you guys might not have much control over the source.


BTW, Firefox has a build option to switch the pulseaudio off.
`cd /usr/ports/www/firefox`
`make config`


----------



## mrbeastie0x19 (Sep 17, 2021)

Thanks for the comments everyone really helpful. Loving the system so far!


----------



## astyle (Sep 17, 2021)

mrbeastie0x19 said:


> The ports and packages system seems really dependent on pulling in a large number of unnecessary software, I understand the approach is generic in the case of packages but it does have a tendency to bring in Linux stuff like pulseaudio. That's really quite unfortunate. I don't know what the solution to that would be in large software projects like Firefox where you guys might not have much control over the source.


Some of that 'unnecessary' software is actually 'Build' dependencies, in  addition to 'Run' dependencies.  For example devel/oclgrind actually pulls in devel/llvm80. Useless, I know, but FreeeBSD can do nothing about it. It's up to the oclgrind devs to re-work the project to compile with devel/llvm12.


----------



## gpw928 (Sep 17, 2021)

SirDice said:


> To be honest I don't know why there's a 'Mail' and a 'mail', I suspect it has something to do with an old habit or something from the past.


The executable `Mail` has been present in BSD Unix for as long as I can remember.  Wikipedia attributes the authorship to Kurt Shoens for 2BSD in 1978.


SirDice said:


> I'm not sure why /usr/bin/CC and /usr/bin/cc exist.


`CC` has traditionally been the name of the `c++` executable on some platforms (e.g. native `c++` compiler on Solaris).


----------



## mrbeastie0x19 (Sep 17, 2021)

gpw928 said:


> The executable `Mail` has been present in BSD Unix for as long as I can remember.  Wikipedia attributes the authorship to Kurt Shoens for 2BSD in 1978.
> 
> `CC` has traditionally been an alias for `c++` on some platforms (e.g. native `c++` compiler on Solaris).


The man page says:
"Usually, *mail* is just a link to *Mail* and *mailx*, which can be confusing."

I'm inclined to agree as I am still not sure which particular variation of the program this is


----------



## eternal_noob (Sep 18, 2021)

gpw928 said:


> Wikipedia attributes the authorship to Kurt Shoens for 2BSD in 1978.


Damn. I want to write software which is being used for 40 years too!


----------



## zirias@ (Sep 18, 2021)

mrbeastie0x19 said:


> I'm inclined to agree as I am still not sure which particular variation of the program this is


It's simply all the same. There were different names for the standard mailer on different Unix systems, so they are kept (for obscure ancient tools expecting one of those old names).


----------



## grahamperrin@ (Sep 18, 2021)

Argentum said:


> … Firefox has a build option to switch the pulseaudio off. …





Jose said:


> Use poudriere(8) to build ports if …



With ports-mgmt/poudriere-devel and `PULSEAUDIO=off += www/firefox` in /usr/local/etc/poudriere.d/make.conf:


```
root@mowa219-gjp4-8570p-freebsd:~ # grep PULSEAUDIO /usr/local/etc/poudriere.d/make.conf
PULSEAUDIO=off += www/firefox
root@mowa219-gjp4-8570p-freebsd:~ # poudriere pkgclean -j main audio/pulseaudio
[00:00:00] Cleaning in previously failed build directory
[00:00:00] Gathering all expected packages
[00:00:00] Creating the reference jail... done
[00:00:02] Mounting system devices for main-default
[00:00:02] Mounting ccache from: /var/cache/ccache
[00:00:02] Mounting ports from: /usr/local/poudriere/ports/default
[00:00:02] Mounting packages from:
[00:00:02] Mounting distfiles from: /usr/ports/distfiles
[00:00:02] Copying /var/db/ports from: /usr/local/etc/poudriere.d/main-options
[00:00:02] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:02] Starting jail main-default
[00:00:02] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:00:03] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:03] Gathering ports metadata
[00:00:05] Calculating ports order and dependencies
[00:00:05] Sanity checking the repository
[00:00:05] Unqueueing existing packages
[00:00:05] Unqueueing orphaned build dependencies
[00:00:05] Sanity checking build queue
[00:00:05] Looking for unneeded packages
[00:00:05] No stale packages to cleanup
[00:00:05] Cleaning up
main-default: removed
main-default-n: removed
[00:00:05] Unmounting file systems
root@mowa219-gjp4-8570p-freebsd:~ # poudriere bulk -j main -b latest -n www/firefox
[00:00:00] [Dry Run] Creating the reference jail... done
[00:00:03] [Dry Run] Mounting system devices for main-default
[00:00:03] [Dry Run] Using packages from previously failed build: /usr/local/poudriere/data/packages/main-default/.building
[00:00:03] [Dry Run] Mounting ccache from: /var/cache/ccache
[00:00:03] [Dry Run] Mounting ports from: /usr/local/poudriere/ports/default
[00:00:03] [Dry Run] Mounting packages from: /usr/local/poudriere/data/packages/main-default
[00:00:03] [Dry Run] Mounting distfiles from: /usr/ports/distfiles
[00:00:03] [Dry Run] Copying /var/db/ports from: /usr/local/etc/poudriere.d/main-options
[00:00:03] [Dry Run] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:00:03] [Dry Run] Starting jail main-default
[00:00:03] [Dry Run] Will build as nobody:nobody (65534:65534)
[00:00:03] [Dry Run] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2021-09-18_11h55m57s
[00:00:03] [Dry Run] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:00:04] [Dry Run] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:04] [Dry Run] Inspecting ports tree for modifications to git checkout... yes
[00:00:05] [Dry Run] Ports top-level git hash: 188df2a78 (dirty)
[00:00:05] [Dry Run] Gathering ports metadata
[00:00:09] [Dry Run] Calculating ports order and dependencies
[00:00:10] [Dry Run] Trimming IGNORED and blacklisted ports
[00:00:10] [Dry Run] Package fetch: Looking for missing packages to fetch from pkg+http://pkg.FreeBSD.org/${ABI}/latest
Updating FreeBSD repository catalogue...
[main-default] Fetching meta.conf: 100%    163 B   0.2kB/s    00:01  
[main-default] Fetching packagesite.pkg: 100%    6 MiB   6.6MB/s    00:01  
Processing entries: 100%
FreeBSD repository update completed. 31021 packages processed.
All repositories are up to date.
[00:00:29] [Dry Run] Package fetch: Will fetch 118 packages from remote or local pkg cache

Number of packages to be fetched: 118
No packages are required to be fetched.
Integrity check was successful.
[00:00:30] [Dry Run] Sanity checking the repository
[00:00:30] [Dry Run] Checking packages for incremental rebuild needs
[00:00:34] [Dry Run] Deleting adwaita-icon-theme-40.1.1.pkg: missing dependency: pango-1.48.7
[00:00:34] [Dry Run] Deleting ffmpeg-4.4_3,1.pkg: missing dependency: libass-0.15.2
[00:00:34] [Dry Run] Deleting frei0r-1.7.0.18.pkg: missing dependency: cairo-1.17.4,3
[00:00:34] [Dry Run] Deleting stale symlinks... done
[00:00:34] [Dry Run] Deleting empty directories... done
[00:00:34] [Dry Run] Package fetch: Generating logs for fetched packages
[00:00:48] [Dry Run] Unqueueing existing packages
[00:00:48] [Dry Run] Unqueueing orphaned build dependencies
[00:00:48] [Dry Run] Sanity checking build queue
[00:00:48] [Dry Run] Processing PRIORITY_BOOST
[main-default] [2021-09-18_11h55m57s] [load_priorities:] Queued: 126 Built: 0   Failed: 0   Skipped: 0   Ignored: 0   Fetched: 115 Tobuild: 11   Time: 00:00:45
[00:00:48] [Dry Run] Dry run mode, cleaning up and exiting
[00:00:48] [Dry Run] Would build 11 packages using 4 builders
[00:00:48] [Dry Run] Ports to build: graphics/cairo graphics/frei0r graphics/libepoxy graphics/librsvg2-rust multimedia/ffmpeg multimedia/libass print/harfbuzz www/firefox x11-themes/adwaita-icon-theme x11-toolkits/gtk30 x11-toolkits/pango
[00:00:48] [Dry Run] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2021-09-18_11h55m57s
[00:00:48] [Dry Run] Cleaning up
main-default: removed
main-default-n: removed
[00:00:48] [Dry Run] Unmounting file systems
root@mowa219-gjp4-8570p-freebsd:~ #
```

– `poudriere bulk -j main -b latest www/firefox` _would build 11 packages_.


----------



## zirias@ (Sep 18, 2021)

grahamperrin said:


> `PULSEAUDIO=off += www/firefox`


And how do you think this should do anything meaningful?  It will just define a `PULSEAUDIO` variable to some silly value.

What you're probably looking for is `${OPTIONS_NAME}_UNSET`, in this case `www_firefox_UNSET+= PULSEAUDIO`.
See Mk/bsd.options.mk for complete docs of the ports' options framework.


----------



## ondra_knezour (Sep 18, 2021)

It may be, that that silly value set in the poudriere configuration file may change how poudriere does something? Eg. build the www/firefox port in this case?


----------



## grahamperrin@ (Sep 18, 2021)

ondra_knezour said:


> … value set in the poudriere configuration file …



Set by me, to show how poudriere can create a local repo including Firefox _without_ downloading a package for PulseAudio.


```
% pkg -vv | grep url | grep -v -i PkgBase
    url             : "pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest",
    url             : "file:///usr/local/poudriere/data/packages/main-default",
%
```

mrbeastie0x19 FYI <https://www.freshports.org/www/firefox/#message> the *Audio backend* sub-section. Here, forcing OSS:


----------



## zirias@ (Sep 18, 2021)

ondra_knezour said:


> It may be, that that silly value set in the poudriere configuration file may change how poudriere does something? Eg. build the www/firefox port in this case?


Well, no. Poudriere just generates a make.conf from the fragments in /usr/local/etc/poudriere.d. It still must be understood by the normal ports' make framework.


----------



## mrbeastie0x19 (Sep 18, 2021)

Quick question about the .cshrc and .profile at the top level. Just tinkering with the system to get a general idea of how it works.

Looks like the .sujournal is important and used by the fs.
./.snap/ I cleared as it looks like it is for recovery (is that autogenerated when needed if I delete it?)

So the .cshrc and .profile look like they are the shell configuration used by root. I was curious so I deleted them. Surprisingly nothing happened, I exited the privileged user and relogged and it created the files in /root/ instead (which is the root user's home directory). Curious again to see what would happen if the root user had no access to any shell (and if I could recover it), I deleted the root directory and remade it.

Now I appear to have no .cshrc or .profile but it still works. So two questions:

Where is the default? (Does it check .cshrc, then /root/.cshrc, and then where?)
Is there any difference between these versions? Will I miss something by deleting the top level one.


----------



## Tieks (Sep 18, 2021)

/.sujournal is the journal for soft updates when you activated soft update journaling for your file system. See `tunefs -p /` for that.
/.snap I don't know for sure, could be for "trash can" deletions.
/.profile and /.cshrc on my disk are hardlinked to the ones I have under /root. Using `ls -lia /.cshrc` and Using `ls -lia /root/.cshrc` give the same inode for both. Since yours are probably mising now, you can find the originals on your install medium, possibly under /usr/src too.


----------



## grahamperrin@ (Sep 18, 2021)

mrbeastie0x19 said:


> … .cshrc and .profile at the top level. Just tinkering



Files such as those should be at the root of the home directory, not the root of the file system. 

(I found one such file misplaced a few months ago. Probably the result of me tinkering without paying attention to the working directory.)


----------



## mrbeastie0x19 (Sep 18, 2021)

grahamperrin said:


> Files such as those should be at the root of the home directory, not the root of the file system.
> 
> (I found one such file misplaced a few months ago. Probably the result of me tinkering without paying attention to the working directory.)


It looks like these are being created in the top level by default on first su in FreeBSD 13 release.


----------



## astyle (Sep 18, 2021)

mrbeastie0x19 said:


> Quick question about the .cshrc and .profile at the top level. Just tinkering with the system to get a general idea of how it works.
> 
> Looks like the .sujournal is important and used by the fs.
> ./.snap/ I cleared as it looks like it is for recovery (is that autogenerated when needed if I delete it?)
> ...


Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc. This is straight from the Handbook. I would suggest that you spend some quality time reading it, it contains a surprising amount of useful info to get you *started* on a LOT of stuff.


----------



## grahamperrin@ (Sep 18, 2021)

mrbeastie0x19 said:


> … rookie … On the whole I am really impressed …



If you haven't been there already: <https://freebsdfoundation.org/> in particular, yesterday's Technology Roadmap and (more generally) the Journal.









						Technology Roadmap
					

https://freebsdfoundation.org/blog/technology-roadmap/  Enjoy.




					forums.freebsd.org


----------



## mrbeastie0x19 (Sep 18, 2021)

astyle said:


> Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc. This is straight from the Handbook. I would suggest that you spend some quality time reading it, it contains a surprising amount of useful info to get you *started* on a LOT of stuff.



Excellent thanks. I have been reading parts of it, but as you say it contains such a surprising amount of useful info that sometimes it is very easy to get lost in it! 



grahamperrin said:


> If you haven't been there already: <https://freebsdfoundation.org/> in particular, yesterday's Technology Roadmap and (more generally) the Journal.
> 
> 
> 
> ...



Fantastic. I have been finding as much interesting documentation as I can, I have read a few of the journal articles already, but did not see this page. Rather remarkable how much info is on here!


----------



## Tieks (Sep 19, 2021)

astyle said:


> Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc.


Correct, but a clean install gives you these files in the root dir, hard linked to the ones in /root. They're referenced by /etc/freebsd-update.conf and /usr/sbin/mergemaster. From the latter:

```
echo "   *** Historically BSD derived systems have had a"
echo "       hard link from /.cshrc and /.profile to"
echo "       their namesakes in /root.  Please indicate"
echo "       your preference below for bringing your"
echo "       installed files up to date."
```
So I think it's best to leave 'em there. Things like `pw useradd` may need them.


----------



## grahamperrin@ (Sep 19, 2021)

Tieks said:


> hard linked



Given the inode (number) of a file, how does a person discover the names/paths?


----------



## dave01 (Sep 19, 2021)

mrbeastie0x19 said:


> Excellent thanks. I have been reading parts of it, but as you say it contains such a surprising amount of useful info that sometimes it is very easy to get lost in it!
> 
> 
> 
> Fantastic. I have been finding as much interesting documentation as I can, I have read a few of the journal articles already, but did not see this page. Rather remarkable how much info is on here!


You might also find these Desktop Tutorials useful too.


----------



## chungy (Sep 19, 2021)

grahamperrin said:


> Given the inode (number) of a file, how does a person discover the names/paths?


You can use `find / -inum 47` to do so.


----------



## grahamperrin@ (Sep 19, 2021)

```
root@throwaway:/ # bfs / -inum 28

/.cshrc
/dev/klog
/root/.cshrc
root@throwaway:/ # bfs / -inum 30

/.profile
/dev/io
/root/.profile
root@throwaway:/ # file /dev/klog

/dev/klog: character special (0/28)
root@throwaway:/ # file /dev/io

/dev/io: character special (0/30)
root@throwaway:/ # exit
```

… interesting, the character special devices.


----------



## Erichans (Sep 19, 2021)

grahamperrin said:


> Given the inode (number) of a file, how does a person discover the names/paths?



As indicated, you can use find(1) to search for files matching an inode number used as input. However, the combination of the _device_ and the _inode_ belonging to the file located on that device is unique. So you can have two files that are in your filesystem your mounted directory structure* that have the same inode number but are located on different devices. If that is the case then those two identical inode numbers represent *different* files. I also suspect that traversing (parts of) a large filesystem with `find` will not always give satisfactory results, performance wise.

The internal structure is such that the device is represented by st_dev (Numeric ID of the device containing the file) and  st_ino (The file's inode number). These are part of a struct as described in stat(2); using this you could write a (e.g. C) programme that intelligently searches the internal structure of inodes. Currently FreeBSD does not have such a programme or command.

AIX does have such a command, see: istat {FileName | i-nodeNumber Device}

ls(1) gives you slightly more info how many filenames refer to the same inode:

```
$ ls -il /bin/tcsh /bin/csh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8  2021 /bin/csh
48635176 -r-xr-xr-x  2 root  wheel  424304 Feb  8  2021 /bin/tcsh
```

Here you see the filenames csh and tcsh refer to the same inode (=the same file). The number 2 before root is the number of links, indicating that there are exactly 2 references active to that specific inode (=48635176).

You can "increment" and "decrement" the number of links. When you create a new file and (hard) link that to an already present file on the same device via ln(1), you'll increment that number (deleting a file will decrement it). That is hard linking, as opposed to soft linking, via a symbolic link.


```
% touch file1 ; ls -il
total 0
34759410 -rw-r--r--  1 sox  sox  0 Sep 19 20:45 file1
% ln file1 file2 ; ls -il
total 0
34759410 -rw-r--r--  2 sox  sox  0 Sep 19 20:45 file1
34759410 -rw-r--r--  2 sox  sox  0 Sep 19 20:45 file2
% rm file1 ; ls -il
total 0
34759410 -rw-r--r--  1 sox  sox  0 Sep 19 20:45 file2
```

___
* edit: clarification added about files system versus directory structure.


----------



## grahamperrin@ (Sep 19, 2021)

Erichans said:


> … exactly 2 references active to that specific inode …





Tieks said:


> … a clean install gives you these files in the root dir, hard linked to the ones in /root. …



With the clean installation above and below, I see: 

two regular files /.cshrc and /root/.cshrc *plus* one character special file for inode 28 with two links, not three
two regular files /.profile and /root/.profile *plus* one character special file for inode 30 with two links, not three
Ignoring the numbers 28 and 30, are these trios normal?


----------



## Erichans (Sep 19, 2021)

Compare with stat(1) and, in all likelyhood, you'll find different values for *Device* in the output:
`$ stat -x /.cshrc`
`$ stat -x /dev/klog`

Such trios indeed exist; for example, for me:

```
# find / -inum 7
/dev/console
/root/.cshrc
/.cshrc
```

However, they do not indicate the resemblence you might think.

___
P.S. At first I suspected that your `bfs` (in `# bfs / -inum 28`) had something to do with btrfs, clearly not correct. I think that you've defined that as an alias for some incarnation of `find`.


----------



## gpw928 (Sep 19, 2021)

Inode numbers are unique to the file system in which they occur.   These days, /dev is a separate file system:
	
	



```
[f13.270] $ mount | grep /dev 
devfs on /dev (devfs)
```


----------



## gpw928 (Sep 19, 2021)

The presence of .profile and .cshrc in the root is a throwback to the time when the home directory of the root account was "/".  It would have been required during transition to using "/root".  I would be staggered if anything relied on those links today.  Having said that, I leave them in place, unmolested.


----------



## mrbeastie0x19 (Sep 19, 2021)

Thanks guys some interesting discussion on those files. I noticed there are about four files in my /tmp directory on startup that have a . in front like .ICE-unix, do these serve any purpose outside of an X server?


----------



## grahamperrin@ (Sep 20, 2021)

Thanks, people.



gpw928 said:


> … I would be staggered if anything relied on those links today. Having said that, I leave them in place, …



For what it's worth, I haven't noticed any problem since (a few weeks or months ago) I weeded the supposedly superfluous links, from my everyday environment, however this is 14.0 CURRENT. 

PS, that's not to recommend removal. (The weeding was performed after comparing notes, online, with other people whose installations were without the files at the / level.)



grahamperrin said:


> clean installation



More accurately: I installed just one package.


```
root@throwaway:/ # pkg info
bfs-2.2.1                      Breadth-first version of the UNIX find command
pkg-1.16.3                     Package manager
```



Erichans said:


> … suspect that traversing (parts of) a large filesystem with `find` will not always give satisfactory results, performance wise. …



True.

My _nearly_ clean installation of FreeBSD had no large file system but (before the pastes above) I ran both bfs(1) and find(1) with time(1), sure enough the results with `bfs` were (with minimal file systems) fractionally faster. From <https://github.com/tavianator/bfs#user-content-breadth-vs-depth>:



> … The advantage of breadth-first over depth-first search is that it usually finds the file(s) you're looking for faster. …



sysutils/bfs


----------



## tux2bsd (Sep 20, 2021)

mrbeastie0x19 said:


> Hi everyone. I have used Linux since


The separation of OS and other software (pkg or ports) is great.  `freebsd-update` is quite slow but you learn to live with it, kinda has its charm.
"Staff" on the forums are just forum mods (or admins/whatever), not associated with the FreeBSD Foundation.
You buy hardware to suit the OS, not the other way around (unless you're a developer and know how to do that stuff).


----------



## matt_k (Sep 20, 2021)

mrbeastie0x19 said:


> Thanks guys some interesting discussion on those files. I noticed there are about four files in my /tmp directory on startup that have a . in front like .ICE-unix, do these serve any purpose outside of an X server?




```
5.2. Socket directory ownership and permissions
The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:


/tmp/.font-unix
/tmp/.ICE-unix
/tmp/.X11-unix
These directories are used by the font server, xfs, applications using the Inter-Client Exchange protocol (ICE) and the X server, respectively.
There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time.


The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.
```

^^this info may be outdated, as it it from 2005 , but yea, they are X-relevant files, you don't need to worry about them.

Do you have _clear_tmp_enable="YES"_ in /_etc/rc.conf?_


----------



## a6h (Sep 20, 2021)

mrbeastie0x19 said:


> Where is the default? (Does it check .cshrc, then /root/.cshrc, and then where?)


/usr/share/skel/
hier(7)


----------



## SirDice (Sep 20, 2021)

The so-called "skeleton" files are copied when creating a new user account. 


```
-m            This option instructs pw to attempt to create the user's
                   home directory.  While primarily useful when adding a new
                   account with useradd, this may also be of use when moving
                   an existing user's home directory elsewhere on the file
                   system.  The new home directory is populated with the
                   contents of the skeleton directory, which typically
                   contains a set of shell configuration files that the user
                   may personalize to taste.  Files in this directory are
                   usually named dot.⟨config⟩ where the dot prefix will be
                   stripped.  When -m is used on an account with usermod,
                   existing configuration files in the user's home directory
                   are not overwritten from the skeleton files.
```
pw(8)


As for the order of startup scripts, that depends on the shell and how that shell is invoked.

```
Startup and shutdown
       A login shell begins by executing commands from the system files
       /etc/csh.cshrc and /etc/csh.login.  It then executes commands from
       files in the user's home directory: first ~/.tcshrc (+) or, if
       ~/.tcshrc is not found, ~/.cshrc, then the contents of ~/.history (or
       the value of the histfile shell variable) are loaded into memory, then
       ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell
       variable) (+).  The shell may read /etc/csh.login before instead of
       after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or
       ~/.cshrc and ~/.history, if so compiled; see the version shell
       variable. (+)

       Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
       startup.
```
tcsh(1)


```
Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.
```
sh(1)


----------



## mrbeastie0x19 (Sep 20, 2021)

matt_k said:


> ```
> 5.2. Socket directory ownership and permissions
> The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:
> 
> ...


Thanks yes I have clear_tmp_enable set but did not notice them disappear, perhaps because they are hidden? Would these files be created by an xorg install if they were removed manually before doing so?


----------



## SirDice (Sep 20, 2021)

mrbeastie0x19 said:


> Would these files be created by an xorg install if they were removed manually before doing so?


No, they would not. And `clear_tmp_enable` actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)). 

```
# X related directories to create in /tmp.
        local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \
                               ${tmp}/.ICE-unix ${tmp}/.font-unix"
```
See /etc/rc.d/cleartmp


There is a `daily_clean_tmps_enable` you can set in /etc/periodic.conf (it's disabled by default). And that too ignores those directories. By default, unless you modified `daily_clean_tmps_ignore`. 

```
daily_clean_tmps_ignore=".X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore quota.user quota.group .snap"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore .sujournal"
```


----------



## matt_k (Sep 20, 2021)

SirDice said:


> No, they would not. And `clear_tmp_enable` actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)).
> 
> ```
> # X related directories to create in /tmp.
> ...





Spoiler: offtopic ramble



I know that this is offtopic, but with a bit of technical background one just has to admire the design of this operating system. Everything is laid out plainly and simply,(almost) everything is well documented and can be easily found. Even I can read /etc/rc.d/cleartmp and understand what it does.


----------



## trev (Sep 24, 2021)

mrbeastie0x19 said:


> ./.snap/ I cleared as it looks like it is for recovery (is that autogenerated when needed if I delete it?)


UFS file system snapshots are stored in that directory:



> *trev*@shadow [/.snap] $ ll
> total 58912
> -r--r-----  1 root  operator   3.8G 24 Sep 14:58 snapshot_20210906040300
> -r--r-----  1 root  operator   3.8G 24 Sep 14:58 snapshot_20210907040300
> ...


----------

