Advocacy just for fun -- little (?) things to love about FreeBSD

zirias@

zirias@

Developer
It's that time again that I discovered some gems in this system I'm just about to start to really use (as opposed to: experiment with) and I thought it might be fun to collect things about FreeBSD you really love :)

This time:
  • the /usr/src/release subtree with advanced make magic that just allowed me to get the base I carefully configured and tested -- on an USB stick to install my new server with. Just type make memstick. Amazing.
  • little useful "unixy" things in the base system. Quite some time ago, my old (XEN/Linux) server's NIC froze, leaving only the serial console. I was shocked because I had only an USB stick with a -CURRENT installer at hands and was used to having to install some kind of terminal application -- well not so with FreeBSD, that's what cu(1) is for. Next nice surprise today: my base system doesn't include vi, because I install editors/vim anyways, everywhere. Too bad the update of my pkg repo for 11.0-RC2 is still running. Nevermind, I managed to edit /etc/rc.conf using ed(1). Ok, using it reminds me of the description of the pangalactic gargleblaster ... nevertheless it got the job done, so great it's there :)
Earlier discoveries involve things like -- hey, they use a CI for the whole system with automated testing, great! Or -- who said software mixing isn't possible with a traditional /dev/dsp? And a lot of "well, this design is somewhat elegant and makes sense" -- like the possibility to use a central mouse daemon, or the overall design of the ports with the nice Makefile library. The list probably goes on.

Care to list what you really love about FreeBSD? Of course those are just opinions, but I could imagine to stumble upon further gems myself, reading the replies here!

Regards, Felix
 
Hehe, I disabled ee(1) as well, trying to get a "blueprint" base for my personal needs, because the editor I prefer is, as I mentioned, editors/vim ;) So it was a very good thing (TM) that at least the ancient ed(1) (it's from the 70s, isn't it?) is always there.

On a side note, about ARM boards -- I still have a "Banana PI" around here, it was a gift 2 years ago and because of building a new house and all the stuff, I didn't have time to play with it so far ... you don't happen to know whether FreeBSD runs fine on it? I think it would make for a nice "surf station" for the guest room :)
 
I like how things change with time but not dramatically. Sometimes I chuckle when I look at a man page and its dated 2003 or older.
 
Phishfry, thanks for the answers, and sorry to hear about your broken banana :(

I'll definitely have a look ... what should break building ports like a desktop environment for ARM if the base system is working just fine? Well, I will see, as soon as I find the time :)

Good point btw about the slow and steady change, that's just what a stable system should do! I guess it somehow gives you this feeling of reliability you feel comfortable with, and the things I described like nice old UNIX tools always available and the traditional /dev/dsp modernized without breaking the contract -- are just symptoms of that :)

Any other points?
 
One of the things I like very much at FreeBSD is the sc console. Its scrollback buffer which you even can extend via kernel option (my setting is SC_HISTORY_SIZE=2500 instead of the default 100) is just awesome.
(Yes I know that some people want vt to replace sc because sc would need some updating for UEFI. But vt breaks suspend/resume on many systems and is still extremely buggy and sluggish yet. For example vt needs 5 sec for switching consoles due to a completely unnecessary mode reset inbetween.)

Zirias said:
Next nice surprise today: my base system doesn't include vi, because I install editors/vim anyways, everywhere. Too bad the update of my pkg repo for 11.0-RC2 is still running.
Click to expand...

At me it's because FreeBSD contains a true vi (in /usr/bin/vi) unlike most Linuxes. (I hate vim because its colorfulness distracts and annoys me.)
BTW I doubt that your installation does not contain vi. I guess vim installs an alias vi vim or such.
 
Snurg said:
I hate vim because its colorfulness distracts and annoys me.
Click to expand...

In command mode:
Code: 
:syntax off
or
~/.vimrc
Code: 
syntax off

Snurg said:
I guess vim installs an alias vi vim or such.
Click to expand...
Code: 
406K: /usr/bin/vi
406K: /usr/bin/nvi
2.5M: /usr/local/bin/vim

vi(1): nex/nvi are intended as bug-for-bug compatible replacements for the original Fourth Berkeley Software Distribution (4BSD) ex and vi programs.
 
Zirias said:
Code: 
... /etc/src.conf ...
Click to expand...
Now that is nice! Even more configurability! +1 :)
Didn't know of this file.
It is apparently not mentioned at all in the build(8) manpage on versions before FreeBSD 11-RC1 or 12 even though the src.conf(5) manpage says it's there since FreeBSD 7.0.

If I understand the src.conf(5) manpage correctly, some settings seem to be redundant with the kernel configuration file settings (/usr/src/sys/<arch>/conf), while others can be specified only in /etc/src.conf?
 
Last edited by a moderator:
Snurg said:
Now that is nice! Even more configurability! +1 :)
Didn't know of this file.
It is apparently not mentioned at all in the build(8) manpage on versions before FreeBSD 11-RC1 or12 even though the src.conf(5) manpage says it's there since FreeBSD 7.0.

If I understand the src.conf(5) manpage correctly, some settings seem to be redundant with the kernel configuration file settings (/usr/src/sys/<arch>/conf), while others can be specified only in /etc/src.conf?
Click to expand...

They are not redundant but complementary. The kernel config(5) file is for setting kernel internal settings and selecting which device drivers are included in the monolithic kernel file. The src.conf(5) on the other hand is where you select which parts of the system get built in the first place, for example if you select WITHOUT_ZFS the ZFS modules and the related utilities are not built at all. Same with for example the WITHOUT_PF setting, regardless of what you set in the kernel config file for the PF devices this setting would give you a system without PF (and I think you would get a linker error because of a missing module if you have "device pf" in kernel config but the module isn't built because of WITHOUT_PF).
 
Sorry to go off topic but I have questions.
Zirias said:
zsh 387 # grep VI </etc/src.conf
Click to expand...
I am trying to learn Unix command prompt. Could you hep me understand this?

zsh = shell (why call up this shell?)
387 = ?
# = ?
grep VI = Search for text string "VI"
</etc/src.conf = ? I recently learned redirect, This looks similar except angle bracket in other direction.

A rough guess is you are commenting out line 387 from etc/src.conf?
 
Zirias said:
Care to list what you really love about FreeBSD?
Click to expand...
No show-off, my list is simple:
  1. UFS2
  2. init(8)/rc.d
  3. hier(7), style(9), ports(7), jail(8)
  4. sysctl(8) : System Calls, MIB, "C calling convention"/UNIX convention, parameters/stack.
  5. fortune freebsd-tips
  6. loader_logo="beastie"
  7. firewall_enable="YES"
  8. Defaults:
  9. Junk-free installation (CLI/TUI)
  10. doc, man, lists, wiki, forums, ... so forth and so on.
  11. Newbie/distro-fanboy repellent.
  12. A policy of zero tolerance in forums, ... concerning idiots situation.
 
Phishfry said:
zsh = shell (why call up this shell?)
Click to expand...
It's not a call, it's just part of the prompt -- the command starts with grep.
Reason for using zsh has nothing to do with the particular command: I want a bourne compatible shell, so tcsh is out already, and I like my shell with lots of useful extra features like intelligent auto-completion, mathematical expressions, git integration and so on. bash would be a candidate, but zsh can just do more ;)

Phishfry said:
387 = ?
Click to expand...
Well I admit, I'm lazy and used a pre-made prompt .. this one puts the "command count" here since the shell was started. Something I don't need, but it doesn't hurt :)

Phishfry said:
# = ?
Click to expand...
This is just the typical "end prompt character" for a privileged shell, while > or $ are often seen for unprivileged shells. Of course you can configure whatever you like, but following the convention here has its benefits.

Phishfry said:
</etc/src.conf = ? I recently learned redirect, This looks similar except angle bracket in other direction.
Click to expand...
< is indeed a redirection, it redirects stdin (the input). So with this command, the shell reads the file and feeds it to the standard input of grep. Of course, grep can also read a file itself ... but there are tools around that can only process data on standard input, that's why I got used to use shell redirects and pipes often ...
 
I have found most people here genuinely trying to help anybody who asks. Just don't insult them.

I need to read up on style(9) I had not seen that before.

I had wondered why dmesg.boot and messages reside in different directories and the hier(7) page explained it well.
 
vigole said:
style(9)
Click to expand...
That's an interesting read, and while some points are a matter of taste, most are just sensible and of course it's always important to agree upon one coding style.

But reading through it, one thing kind of hit me:
Code: 
     Use printf(3), not    fputs(3), puts(3), putchar(3), whatever; it is faster
     and usually cleaner, not to mention avoiding stupid bugs.
So why is this? Especially, why should printf(3) be faster if no formatting and conversions are needed, and isn't it printf(3) that introduces bad format-string attack bugs when writing e.g. printf(message); instead of printf("%s", message); while puts(message); would be totally fine?

I tend to strongly disagree with just that little part of style(9), but maybe someone can tell me something I've overlooked ;)
 
  • Thanks
Reactions: a6h
You must log in or register to reply here.
Back
Top