New to FreeBSD - Some questions

Thu Jun 21 16:55:41 UTC 2012

On Thu, 21 Jun 2012 13:24:26 +0200, Fred Morcos wrote:
> On Wed, Jun 20, 2012 at 9:58 PM, Wojciech Puchar
> <wojtek at wojtek.tensor.gdynia.pl> wrote:
> >> I'm quite new to FreeBSD too (RHEL/Fedora background), and am most
> >> impressed with it so far.
> >
> >
> > rather huge difference.

If you use the "right" Linusi, you can gain lots of useful
knowledge. Basics are important, and older versions of Linux
can really teach them. Of course a "click'n'grunt" environment
won't teach you much.

> >> Secondly (and probably stating the obvious), the handbook
> >>
> >> <http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/>
> >>
> >> is the place I always look first.
> >
> > and third - manuals. They are in sync with system and actually VERY useful.
> >
> > while i was still (long time ago) using linux most common manual was like
> >
> > "this manual is outdated. Use texinfo documentation". and texinfo docs was
> > often outdated too.
> >
> > Today it is most probably "look at wikipedia" ;)
> >
> > Of course i means FreeBSD base system, ports are not part of FreeBSD and
> > quality varies.

In "modern applications", documentation is often left out
("Who ever reads that?!"), or it's scattered across web
forums, user web pages and wikis. Some ports for FreeBSD
have good manpages (e. g. "man mplayer", "man xmms" or
even "man opera"), some don't (try to find manpages for
KDE programs, also no "man firefox").

> I have been using GNU/Linux for quite a while and I am most
> comfortable with Archlinux.

That should have provided you with essential basic knowledge
that you can apply in FreeBSD without problems.

> The reason I like it is it's simplicity
> from the ground up without wasting too much time on unimportant
> details (unless you want to).

You will find that aspect in FreeBSD.

> Another strong point is that it provides
> binary packages by default, user-building of packages if you want to,
> and the same level of customization you can achieve with - say -
> Gentoo Linux. FreeBSD seems to provide that.

FreeBSD offers two methods: Source-based or precompiled. Both
of them are build from the ports collection, a kind of means
to control dealing with sources and automatically build from
them.

> I learned over the years that (re-)compilation of packages is not
> something I want to do regularly, but something I would like to do
> only when I need and want to (ie, to strip out or add a certain
> compile-time feature from/to a package).

A prominent example is mplayer / mencoder to deal with codecs.
It's also typically needed to build OpenOffice with non-US
language and "unusual" settings like no integration with KDE
or Gnome (if you're not using them).

> I also learned that the
> performance gains of tuning compiler flags for a certain CPU are not
> that drastic for a desktop/laptop/workstation machine workflow and
> that this category of computing is mostly bound by IO speed
> (especially with HDDs).

It's only needed when you have to get things running on older
hardware. Again, mplayer is a good example for where you intendedly
would deal with compiling in such a constellation.

> q) Is it possible to run a FreeBSD system without much building? In
> other words, can I survive by depending on packages and only resorting
> to ports when really needed?

It is. You're basically using "pkg_add -r <name>" to install
the packages you want. The required dependencies will automatically
be installed.

> What set me off, and got me tired of dealing with Linux-based systems
> is a set of patterns that have been repeating over for some years
> now. Generally:
> 
> 1. Too often, core system components break (especially with every
>    Linux kernel release).

They don't in FreeBSD. Only tested and verified modifications
will be committed to the non-experimental branches (the security
branch of -RELEASE, and the -STABLE branch). If you're following
the experimental development branch -HEAD, it _might_ happen that
the system doesn't even compile, but updated 30 minutes after
that "accident", it runs fine again. :-)

>    1. Yesterday I spent 30 minutes until my webcam worked, dealing with
>       v4l, gstreamer and cheese.

FreeBSD - unlike Linux! - has a differentiation between the OS
(FreeBSD itself, the operating system) and 3rd party applications
("everything else", the ports collection). Even if you mess up
all your ports, you _never_ will end up with a defective OS. So
even in such a worst case, you can still access system means for
diagnostics and repair.

> 2. Sudden drastic changes that are deviating from simplicity.
>    1. The sudden flood of daemons that are designed to do everything
>       for me, without giving me much say in the matter. My computer is
>       supposed to help me, not decide for me or replace me.

The concept of FreeBSD includes to have several system-level
deamons available, but only few of them are running by default.
You have to enable them if you feel you need them. This is
done in centralized (!) system configuration files. The most
important one is /etc/rc.conf.

Did I already mention the problem of documentation?

On FreeBSD, you can always do "man rc.conf" to find out what
this file is. The manpages include documentation for system
binaries and services, configuration files, kernel interfaces,
library calls and maintenance procedures. Your Linux background
will have taught you how to deal with "apropos", "whatis" and
"man", and on FreeBSD, they actually work!

>    2. Those daemons are hard to get rid of and are tightly integrated
>       into higher-level components in the stack (ie, into the desktop
>       environment).

As many software for FreeBSD is ported over from Linux, it might
be neccessary to run some of those deamons, e. g. DBUS to enhance
the functionality. But _you_ need to enable it, it won't do by
itself, so _you_ stay in control. The case of being "Linux-centric"
already shows some downsides when there are interfaces needed that
FreeBSD doesn't have (because it has other interfaces, and had them
for many years). A known example is Xfce where the unavailability
of some Linux-specific component reduces its functionality.

>    3. Those daemons are increasingly hard and obscure to configure
>       (ie, huge XML files, complex hierarchies, etc).

Again, this is something you'll also sadly find on FreeBSD.
I remember dealing with HAL - already deprecated in Linux.
You needed to fiddle with XML in order to get your non-US
keyboard working again. The standard means to do so would
have been the X configuration file where _all_ X related
settings are present without being tied to a specific desktop
environment. Rebuilding X without HAL and creating xorg.conf
the traditional way solves such problems.

> 5. I think many of the developers of those components are trying to
>    reach a Mac-like experience? I am not against that in any way, but
>    it needs to be working well.

Not sure. Bloat, as I've been told, is a natural means of
modern application development. However, I don't believe
that. The problem is that most software wants to be wide-spread,
so it needs compatibility across many platforms, therefore
lots of abstraction layers and libraries are used. This all
adds up to a pile of... software... that requires increasing
resources in order to get the simplest things done.

> Those are dbus, hal, udev, udisks, upower, pulseaudio, systemd,
> consolekit and policykit.

Except u{dev/disks/power} and systemd, you'll find them on FreeBSD
too. Luckily they're optional.

> q) Where does the FreeBSD project stand on this matter? From what I
> noticed is that the base system seems to adhere to the tranditional
> flat text files for configuration and simple tools that do a good job,
> leaving it up to the user to combine those small tools to create
> larger, more complex ones (a UNIX inheritance).

FreeBSD (the operating system) exactly follows this approach.
Others (ports, at least some of them) do not.

> q) Is a FreeBSD stable base system with "current" high-level
> components possible?

Yes, follow the -RELEASE branch and use freebsd-update (a binary
updating tool for your OS installation).

> Will it avoid the issues I experienced on
> Linux-based systems?

Possibly.

> q) I would assume UFS with J+SU is "fast enough" for a laptop?

I think so. For a laptop, you _might_ consider adding encryption.
Just in case. You never know.

> q) Does ZFS make sense on a laptop? Any advantages of using it over
> USF with J+SU? I am not interested in any striping or mirroring on
> the laptops, but the compression features is very attractive for the
> HDDs in the first laptop.

I would not recommend ZFS for this specific kind of use, as you
can easily create striping and mirroring settings with gstripe
and gmirror, using UFS.

> q) The second laptop has an SSD, would UFS with/without J and
> with/without SU or ZFS make more sense for it?

There are several parameters that you can tweak (see "man tunefs"),
I would suggest a single partition spanning the whole SSD, and
journaling would not be contraproductive.

> q) Can I live with a desktop environment (Gnome or KDE) and desktop
> applications (Firefox, Libreoffice, etc) by relying only on packages?

I think so. LibreOffice... I'm not sure about the language
versions that are offered precompiled. Is your required language
(unless it's English) present? If yes, no problem.

> q) Does ntfs-3g from ports work reliably with external HDDs or USB
> flash drives with read and write support? I would like to hear
> personal experiences with that.

I can't answer that, except forensic analysis and data recovery
I'm not a MICROS~1 person. :-)

> q) Does the NVIDIA binary driver work reliably? I would like to hear
> personal experiences with that.

I'm using it here (nVidia GeForce 7600 GS - G73), nvidia-driver-270.41.19
using xorg-7.5.1. No problems, except the GPU is broken and sometimes
locks the system. :-)

> I am also planning to setup a micro-server for home use (either a
> ready-built one or by simply building a PC and using it as a server),
> questions about that will come later. The main use of it would be
> hosting my multimedia, streaming music and making backups of the
> laptops on it (cron + rsync). Also, maybe some web/ftp and git
> servers.

You'll find all required parts to do that in ports. It doesn't
sound much complicated.

> I installed the base system into Virtualbox and everything works quite
> well. Everything is so... clean, and tidy, and consistent, and
> simple. Very well thought out.

I may add that I'm happy to experience that every day since 4.0. :-)

> I am also very impressed with the
> amount of properly written man pages and with the handbook. I would
> like to thank and congratulate all of the people who work on the
> FreeBSD base system, a true masterpiece.

You actually _do_ recognize that this voluminous and quality
documentation is accessible for you even without Internet
connection? In a worst case scenario, it's a real benefit.

> q) Does the bsdinstall align partitions to device blocks by default
> for optimal speed? If not, I have found that I can use gpart with -a
> and -b which will require me to calculate the start and end offsets of
> each partition manually. Is there a tool that can automatically do
> that for me?

I've not bsdinstall, so I can't comment on that. I prefer using
a live media (CD or USB stick) and then use the command line tools
according to the requirements (either fdisk, disklabel and newfs
for the "MBR approach", or gpart and newfs for the "GPT approach").

> q) Is it possible to get native resolution on the console? I played
> with vesa and vidcontrol but could never get what I wanted. Native
> resolution would require KMS?

As far as I know, KMS (kernel mode settings) is specific to Linux.
FreeBSD has several VESA modes bigger than 80x25. But I have to
admit that I don't see a problem in using this default mode during
initialization time. Later on, xterms (also those containing SSH
and screen sessions) can be configured any size under X.

> q) Adding tmpmfs="YES" to /etc/rc.conf is analogous to a tmpfs /tmp on
> Linux-based systems, correct? Any other directories that might make
> sense to have as an mfs (ie, in /var)?

Maybe subdirectories of the /var tree. Note that /var/db contains
important databases for the system, and /var/log contains logs
that you don't want to loose in case of a system crash. Things
like /var/spool may be well in volatile memory. Note that the
use of /var/tmp vs. /tmp is also debatable: While /tmp is really
temporary, as it can be erased on system startup (see rc.conf
option clear_tmp_enable) or when residing on a RAM disk, /var/tmp
is often considered to be kept across reboots.

> q) Is there a place where all sysctl variables are documented? It
> occurred to me when I was trying to find the memory usage on my system
> but `sysctl -a | grep mem' shows a whole bunch of stuff.

See "man sysctl", you can use the -d option to see the description.
Also there definitely is some source code where everything is stored.

> q) How can I set proxy settings system-wide? Same for PACKAGESITE (for
> the pkg_* tools), how can I set a mirror system-wide? /etc/profile?

Depending on your shell, you can set it in /etc/csh.cshrc (for the
C shell, which is FreeBSD's default dialog shell).

> q) I noticed all file/data-sizes are in bytes (ls, dd, etc), is there
> a way to change that system-wide to be in human-readable format?

What's not "human-readable" in bytes? I always thought 8k blocks
where non-"human-readable"! :-)

Aliases can do that. For example, you could use something like
this:

	alias ls 'ls -FG -D "%Y-%m-%d %H:%M:%S"'
	alias ll 'ls -laFG -D "%Y-%m-%d %H:%M:%S"'

See "man ls" and add options for dealing with sizes (display of
SI units).

Also you can "setenv BLOCKSIZE K" in your csh config file ~/.cshrc.

> To assess my understanding, the system is split into kernel, base,
> documentation, games, lib32 (on 64-bit systems) and ports.

Those are sometimes called distributions (do not confuse with
the Linux term).

> There is
> another split between base and ports where base includes everything
> previously mentioned minus ports. Now, there are 3 "branches" of the
> base system: RELEASE, STABLE and CURRENT. RELEASE means 9.0 and stays
> that way until 10.0 is released.

No. RELEASE means 9.0, 9.1, 9.2 and so on. This branch also
considers the security updates ("patches"), often denoted as
9.0-p1, 9.0-p2 and so on.

> STABLE means 9.0, 9.1, 9.2,
> etc.

No. STABLE is a continuous branch of approved development where
the minor version number "disappears", e. g. 8-STABLE and 9-STABLE.
Those branches have tested and verified development in them which
is "newer" than -RELEASE, but might result in a future security
patch. There are no patchlevels or version numbers per se.

> CURRENT means "trunk" in SVN terms.

CURRENT or HEAD is the "faster" continuous development branch.
It contains stuff that might not be stable, e. g. experimental
changes.

> Is all that correct?

Almost. :-)

> Also,
> when somewhere is mentioned `make world', this means to rebuild all
> installed ports which doesn't include base, I assume?

No. "make world" means to build and install all components of
the operating system (but not the kernel). See /usr/src/Makefile,
the comment header, where the most common "make targets" are
explained.

Basically:

make world = make buildworld + make installworld
make kernel = make buildkernel + make installkernel

Also note that a specific order is important here.

> q) The files in /etc/rc.d are all executable, from my understanding,
> those files will get executed and it is their duty to check the
> variable `<rc-script-name>_enable' for whether they should start or
> not. Wouldn't it be more efficient to chmod -x or +x them to
> disable/enable?

I don't think so. Settings are centralized in a "control file",
even if it just consists of "setting variables". So everything
is in one place.

> q) What is analogous to /etc/rc.local from Linux-based systems?

It's /etc/rc.conf and maybe /etc/rc.conf.local. See "man rc.conf"
as well as /etc/defaults/rc.conf for details.

> q) Is there something analogous to the Linux magic sysrq key?

I don't think so. FreeBSD isn't about magic, it's about power,
the power to serve. =^_^=

> I must say, the ports collection being built on makefiles was a
> welcome enlightenment, it just, naturally, made sense. The *-recursive
> make targets are a blessing, especially for configs.

True. If you want to make the work with ports more easy, use
a port management tool. For example portmaster (considered the
best one), but there's also portupgrade and portmanager, as
well as helpful tools in bsd-admin-scripts (also a port).

> q) Is there a tool that can test a set of mirrors for connection time
> and speed (for packages and ports)? Analogous to Archlinux's
> rankmirrors?

I'm not sure, but it can easily be implemented. :-)

> q) Is it possible for the pkg_* tools (especially pkg_add -r) to
> display progress?

Maybe the -v option? :-)

No, there is no real progess indicator, especially not an
overall indicator (regarding dependency traversal), as far
as I know.

> q) I noticed in the ports collection that there were some outdated
> packages (skype-2.2, gimp-2.6), should I report that and where? (A
> PR?)

_If_ they are in ports, they still work, so why get rid of them?
Only ports that do not work anymore, aren't maintained or cannot
be fetched anymore (no distfile mirrors) will be removed. There
are also some versioning: "portname" is the current version,
"portname<n>" is the older version n which still works, and
"portname-devel" is the development version with "bleeding edge"
features.

> q) Is it possible to have the ports system compile into an mfs (to
> avoid disk access)?

Yes, there is a variable to control it. See "man 7 ports" and
maybe /etc/make.conf. I have to admit that I forgot it currently.
$WORKDIR? $WRKPREFIX?

> q) Is it possible to have the user asked to change their password the
> first time they log in (using an OTP) in a simple way? I looked at
> OPIE but it seems to be much more complex than what I need.

I think this is possible. Maybe see "man passwd" and "man adduser"
for this step.

> Also, I would like to have a system where user home directories are
> encrypted based-on and using the user's password. From what I could
> find, gbde and geli don't really provide that without any
> administrator intervention.

Correct, they work on "system level", not directly on user
level.

> q) What should I be looking at to achieve the above?

You can generally encrypt the /home partition (implying that this
is a separate partition or whole disk), and using per-user userland
tools to deal with (typically changing!) passwords.

I'm leaving out the ZFS questions as those have been already
very nicelyn answered, and my ZFS knowledge is already too old.
It's still from Solaris. :-)

> q) I would like to hear anyone's recommendation of a cheap, low-power
> ready-made hardware for such a purpose which is supported by
> FreeBSD.

Everything that contains standard-compliant components will do.
Dell servers are known to work very well.

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...