
Local Linux User Tries FreeBSD - Arnavion
https://www.arnavion.dev/blog/2019-10-20-local-linux-user-tries-freebsd/
======
toast0
Some notes from a FreeBSD user:

> shell things

(duplicating from other comments) Bash is indeed not in FreeBSD base; it's
easy to install it, but not installing it is also a valid choice. The default
login shell doesn't make a big difference, you can use chsh to change that. I
also agree POSIX sh isn't quite enough for a lot of scripts.

> [ sysfs, procfs]

These are sort of available, but really just for compatibility with Linux
binaries; take a look at the man pages for linsysfs and linprocfs. Just a note
to say they're not totally missing, but I would agree they probably don't
contain what you're looking for anyway.

> In some cases the sysctl output is not easily machine-parseable. For
> example, the uptime information from sysctl -n kern.boottime

Depending on how easy it is to process binary values, sysctl -b kern.boottime
could be useful here; you'd get two raw integers.

> FreeBSD's netstat -I em0 -bin returns a tabular display,

You might try netstat -I re0 -bin --libxo json or similar. libxo was added in
FreeBSD 11.0, and I think got plumbed to the networking commands at least (I
see it's not hooked to sysctl in 12.0, so probably not in whatever 11.X
pfSense is on either, although it would be useful). check man xo_parse_args
for more details.

> nothing recognizes --help

\--help is a GNUism; usually the BSD version is -h (although, not for
netstat), and yeah, the included help text isn't super useful unless you know
what the things mean... pfSense is intended for resource constrained systems,
which I guess justifies no man text... but I'd install it it's possible, it's
super useful.

> Perl would probably be another good choice

(this isn't accurate, as noted by comments) Perl is a nice choice on FreeBSD,
because it is part of the base system (unlike, as you noted, bash). This can
sometimes be a bit tricky, if you want a new perl feature, but as long as
you're writing run of the mill perl (which everything described here should
fit), as long as it's not a positively ancient system, you should be ok.

Anyway; it looks like you've learned quickly; enjoy!

~~~
petre
Perl hasn't been part of the base system since FreeBSD 8 or so. It's also
fairly recent, 5.26 I think, whereas the current one is 5.30 (even minor
versions numbers are stable).

Also pfSense is a constrained environment wothout all the feature of a full
FreeBSD install.

~~~
Arnavion
It's definitely there on pfSense 2.4.4 (based on FreeBSD 11.2), which is why I
mentioned it in the blog post. So if it isn't part of FreeBSD base then
pfSense is installing it anyway.

~~~
petre
It's probably installed by default as a pkg.

------
doc1623
I used to use Freebsd. It was great until it wasn't. Mainly, I would recommend
not using it as a desktop. It's perfect for a server or FreeNAS but the ports
for common desktop applications seem to be broken fairly often which causes
usability issues and some very heavy frustration. From the forums (you will
use them allot), I learned that the developers mainly use Macs as their
primary PC's. So this problem is not likely to change.

As far as Awk over Perl. It's been quite some time but when I did awk scripts
they had some pretty annoying quirks that you just had to learn. Perl was just
easier. Has that changed? I know that Perl as a larger language is languishing
but isn't it still perfect for this type of thing?

~~~
bachmeier
> It's perfect for a server or FreeNAS but the ports for common desktop
> applications seem to be broken fairly often which causes usability issues
> and some very heavy frustration.

I briefly tried FreeBSD. Only briefly, because that ports thing was a mess. My
trial lasted only a few days before my system was an unusable mess.

~~~
doc1623
Part of that is, it's just a fairly steep learning curve. I did learn to stick
with one way of doing ports. I used Portmaster then you learn not to
troubleshoot too much as you can really make a mess of things. You need to let
the tools work for you, but again... when the ports themselves are broken
(i.e. not your machine/dependency .."heck") then you can't do anything.

------
juped
More accurate title: Local Linux user discovers awk is a great and portable
tool for handling structured text (it is)!

~~~
cstross
I'd have gone for "can't use perl, that's obsolete (uses awk instead)" which
is kind of ironic if you remember the days of a2p. As it is, a combination of
sh/awk will do the job, but is likely slower and less flexible than doing it
in perl because this is exactly the sort of job perl was designed for, back in
the day.

~~~
juped
Perl is not quite standard Unix, though (it should be imo)

------
jlg23
> The default FreeBSD shell is tcsh. I was prepared to not have bash, but tcsh
> is quite alien in its syntax compared to regular POSIX sh.

 _All_ FreeBSD scripts I encountered use posix shell.

> does have a dependency on perl to get the current time in seconds from the
> Unix epoch. This is because FreeBSD's date does not have a way to get
> milliseconds in the time

One could just install the GNU coreutils (probably, not checked though, much
less overhead than a full perl install) or kill that problem with very few
lines of C.

~~~
JoshTriplett
> All FreeBSD scripts I encountered use posix shell.

Defaults matter, and it's helpful when the default shell for command-line use
matches the shell used for scripting, because people often do scripting on the
command line.

~~~
throw0101a
Tell that to Debian/Ubuntu as well: default user shell is Bash, default
/bin/sh is dash.

If you need more-than-POSIX in your scripts, then use the proper shebang.

~~~
JoshTriplett
I use Debian, and I'm aware. Bash still uses primarily POSIX sh syntax, with
extensions. It's helpful for people to be able to apply knowledge from the
command line to shell scripting and vice versa, even if they have to do a bit
of porting work, rather than using _completely_ different shells and syntax.

------
superkuh
I love that you can comment by sending an email with the title of the post in
the subject.

>You can post comments on this blog post by: sending mail to email@address.dev
with a subject starting with [blog-2019-10-20-local-linux-user-tries-freebsd]

~~~
jdofaz
Would be fancier if it was a mailto link with the subject already populated

~~~
kevin_thibedeau
Spammers would hammer it with bots.

------
lwb
> I decided to write a script that would repeatedly flash the LED on the Pi in
> morse code corresponding to its current IP address

I wish my day job was this exciting!

~~~
agapon
I feel compelled to point out that FreeBSD manual page for the led driver has
this example:

    
    
      /usr/bin/morse -l "Soekris rocks" > /dev/led/error
    

Guess what it does :-)

~~~
throw0101a
For those curious:

* [https://www.freebsd.org/cgi/man.cgi?query=led&sektion=4](https://www.freebsd.org/cgi/man.cgi?query=led&sektion=4)

* [https://www.freebsd.org/cgi/man.cgi?query=morse&sektion=6](https://www.freebsd.org/cgi/man.cgi?query=morse&sektion=6)

------
simonblack
For the 'best of both worlds' scenario, use Slackware Linux in place of
FreeBSD.

Slackware is one of the very oldest Linuxes, and traditionally used a BSD-
flavored 'init' system, rather than a System-V syle init, or even the newer
'systemd'. It has traditionally concentrated on being extremely stable, and
more slanted towards server work, though I used it for many years as my main
desktop.

~~~
lightbulbjim
I would say it's more slanted towards desktop use than server use.

Generally you want to automate server management with some sort of config
management. While possible with Slackware, it's easier with a Debian or Red
Hat style system.

For a desktop Slackware is pretty nice. It's easy to understand and gets out
of your way. I used it for over a decade until, one day, I realised I was
tired of recompiling slackbuilds after each low level dependency upgrade.

------
boomboomsubban
>DuckDuckGo would not return that URL when searching for, say, freebsd man
netstat

!man netstat

~~~
Arnavion
TIL. Thank you.

------
rhinoceraptor
> I decided to write a script that would repeatedly flash the LED on the Pi in
> morse code corresponding to its current IP address

Wouldn't it be a lot easier to use mdns/zeroconf, or static IPs? Or use a
label maker and put the MAC address on it, and then use arp-scan?

~~~
Arnavion
It was mostly just a fun thing I decided to do to flex my newly-acquired awk
skills.

~~~
pbhjpbhj
Is Morse ab efficient way to present dotted-quads, it doesn't seem like it
would be?

~~~
Arnavion
The code is what I described in
[https://news.ycombinator.com/item?id=21567202](https://news.ycombinator.com/item?id=21567202)
. It's equivalent to first converting 0 to E and 1 to T, then transmitting
that. It's not using the representations of 0 and 1 themselves, which are five
times longer.

------
musicale
My brain immediately filled in the imaginary clickbait headline:

Local Linux User Tries FreeBSD - You Won't Believe What Happens Next!

(Actually nothing much happened at all. A few differences, but nothing major.)

------
tedunangst
luajit makes it pretty easy to call arbitrary sysctl and ioctl functions.

You can start with popen to some command, then when that's slow, switch to ffi
calls.

------
MuffinFlavored
> The default FreeBSD shell is tcsh. I was prepared to not have bash, but tcsh
> is quite alien in its syntax compared to regular POSIX sh. I decided to
> ignore it and just use POSIX sh.

Would FreeBSD consider POSIX sh as their default shell instead of tcsh?

~~~
toast0
You can easily change your login shell with chsh. If you install bash first,
you can change your shell to bash. It's an inconvenience to change it, but
changing the default is a major effort.

~~~
JoshTriplett
FreeBSD wouldn't select a default shell that uses the GPL, but using a simple
POSIX shell as the default would make sense.

~~~
toast0
POSIX sh is a sensible default; and the technical work to do it would take
less time than we've spent writing these comments. However, actually changing
the default, would be a major effort; you'd need to form a consensus that the
new default is better than the old default, that it's so much better than the
old default that invalidating any documentation that relies on the old default
is worth it.

