Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

I loved FreeBSD all through the late 90s / early 2000s in high school and college. I was working for a small ISP that ran 100% FreeBSD and cut my teeth on *nix in general on the platform. My first foray into Linux (Debian) felt sloppy and discombobulated comparatively. Why? FreeBSD is an entire OS, not a menagerie of tools wrapped around a common kernel. FreeBSD always felt much more polished, complete and predictable. Unfortunately our team made the choice to migrate to Debian for ease of upgrades and security patches (no more building world). Back in the day the limited resources from a processing perspective made those upgrades much longer than an apt-get upgrade.

I love Linux (Arch / Debian), but I still have a soft spot for FreeBSD. I have flashbacks to the network install via a floppy that remind me of the simpler time of the Internet. I need to re-engage with 10. Lots of great platforms I use are still based on it - FreeNAS and PFSense.

If you've never tried it, I encourage you to learn the system.



After working Solaris and AIX for years, I still prefer BSD's userland to Linux's, but Linux's overwhelming HW support eventually won me over. Would anyone else here be interested in a distro with a Linux kernel with FreeBSD's userland? I've experimented with Starch Linux and MirOS, but both are pre-alpha.


What's better about the FreeBSD userland? Are you talking about the shell tools like coreutils/diffutils/etc., or more about daemons like DNS/mail/etc.?

I am actually thinking of doing the opposite: using GNU user land tools (coreutils etc.) with the FreeBSD kernel. I know there are some projects already in this direction -- Debian/BSD, Arch/BSD, and I think Gentoo has some relation to BSD.

Reason: I want some BSD kernel features but don't want to waste time porting shell scripts and so forth.


> What's better about the FreeBSD userland?

For one example, take networking tasks:

Task / BSD / Linux

set ip / ifconfig / ifconfig or now "ip" which is confusing

wifi / ifconfig / iwconfig

speed / ifconfig / miitool or ethtool

duplex / ifconfig / miitool or ethtool

vlan / ifconfig / vlan

wol / ifconfig / miitool or ethtool

bridge / ifconfig / brctl

link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart all networking or reboot server

Want find out which nic is occupying ethX perhaps for tuning or scripting etc?

Linux = complicated, by distro/version

FreeBSD = nic by device eg em0


Most of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue. Certainly dumping everything in the same tool is no less "confusing". I just googled the FreeBSD man page for ifconfig -- yikes!

The last bit is unfair. Yes, Linux distros have recently diverged on network device naming. But that's for a good reason: the old scheme wasn't robust against probe order, the new systemd one is, and FreeBSD's isn't either. The systemd naming (while ugly) is better, period. That's a feature for Linux, not a confusing problem with its userland.


> Most of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue.

No, its not that.

It clearly shows how fragmented Linux ecosystem is..

On Freebsd, on the other side, if a new kernel/OS feature is created, the enginner/designer of that feature can count on, create (or modify) existing tools in the userland, cause he knows the userland will ship together with the modified version of the kernel(or dinamic module)

It gives the whole system, a consistency; not easilly found anywhere else, much less in Linux.. if you start to use Freebsd for some time, you will just note this..

It gives you a better, and consistent experience, and i think is this what Unix should look like..


> the old scheme wasn't robust against probe order

Very true.

> and FreeBSD's isn't either

Very untrue. FreeBSD does serial enumeration which results in static devices each time. There is no equivalent tool in FreeBSD to udev or systemd because it isn't needed(although devd does a certain subset of some of their functionality). About the only place out of order probing can occur is with external disk expander where FBSD isn't doing the actual probing. In this case, labeling disks or using the cam wire down method. man 4 cam


I bet you it doesn't. The BSD name a driver name and a number, and that's not enough state. If you swap two identical cards between PCIe slots, does it still work? If you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2? If you have a fixed external network with its own routing rules on a USB ethernet adapter, does it work correctly if you happen to boot with another such device connected?

I admit I'm chuckling a little about the idea of udev not being "needed". :)


> I bet you it doesn't.

What exactly are you willing to bet?

> and that's not enough state.

It's enough.

> If you swap two identical cards between PCIe slots

It's probed by slot so in the case you present no config would generally be needed unless you have something dependant on layer 2 in the setup.

> If you pull em1 and add a new card in its place does it come up as em1 (incorrect)

Yes it does and actually that is correct. I don't want to have to muck with configs simply because I swapped a nic. If you like doing it that way have at it.

> If you have a fixed external network with its own routing rules on a USB ethernet adapter, does it work correctly if you happen to boot with another such device connected?

Depends on the setup, you can have it pretty much do anything but by default it would work if you swapped it out with something that used the same driver.

> I admit I'm chuckling a little about the idea of udev not being "needed".

As someone who has ripped udev out of a distribution and replaced it with something easier(auto provisioning) for a specific large SaaS stack, I can assure you udev is not needed.


    If you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2?
Am I misreading, or do you mean to say that if you replace a failed part, the ‘correct’ thing is for the replacement to come up with a different name so that the box stays out of production until someone can manually reconfigure it?


That's how I read it too....uff da.


giant?

Freebsd 9.1 RELEASE: 260k /sbin/ifconfig

My Arch box: 76K /usr/bin/ifconfig

I have to use linux for work, but he's right, keeping everything in ifconfig is much more close to the old school "unix" way than "lets play 20 commands" that seems to be present in most linux mindsets.


This may be the first time I've every heard the "old school unix way" defined as (heh) "packing all related functionality into one command".

But use what you like. Just don't pretend that it's anything other than taste.


Its more keeping networking related things for interfaces in the InterFaceCONFIG command seems to be a more "one tool for the same thing" in my mind.


> I admit I'm chuckling a little about the idea of udev not being "needed".

If you're calling my tastes simple then guilty as charged.


old school? what about git?

> git pull

> git push

> git clone

or would you prefer a binary for each command:

> git_pull

> git_clone

> git_push

now, what really looks old school to you?


Its one command with subcommands for each sub function.

What you're contorting is more akin to: ifconfig_wireless ifconfig_vlan ifconfig_foo

Bit of a reach there.


The need for binary updates is certainly understandable, and was a reasonably common complaint. Binary updates have now largely become a "solved problem" on FreeBSD, through freebsd-update (ca. 2007, for the base system) and pkgng (ca. today, for third party software).


I dont think theyre a solved problem yet. Strangely enough the ports system appears to be too flexible. Which one should I be using in 2013 to install packages - pkg_add, pkgng, portmaster, portupgrade, running make install from within the ports source tree? Could someone who knows more about FreeBSD than I do comment on whats state of the art in terms of installing / upgrading packages?


ports - `cd /usr/ports/mail/postfix && make install` compiles postfix from source, as an example. It allows you tremendous and easy control over compile time options. No hunting down just the right package for the features you need. No waiting for some long lost maintainer to update their package. Everything is compiled against the libraries you have installed.

pkg_add - Installs a binary package that someone else compiled directly from the port. Fast and easy. These may lag behind a little bit behind bleeding edge, and you don't get to choose compile-time options. You can (mostly) mix and match software installed from pkg_add and ports.

pkgng - is the new binary package management system. It is pretty great, but still teething a bit. PC-BSD is offering the most up to date pkgng style package repository was twice-monthly updates. You have to set your system up as old style package (still default) or the new pgkng, and you can't mix and match different package types.

portmaster - is a software upgrade tool, and I think the most popular at this time. It just uses the ports tree (or optionally packages) to do the magic.

portupgrade - the former favorite, works much like portmaster to upgrade software (and perform other tricks) on top of the ports/packages system.

poudriere - Another ports upgrade tool. It has many fans. Harder for Americans to spell.

At this time, I would recommend using ports to install things, and portmaster for upgrades. Keep your eye on pkgng as the package repositories come up to speed and the supporting tools (portmaster, etc) mature their support for the new format.


poudriere isn't a ports upgrade tool (afaik), it's a tool to roll your own binary package repository. It's mostly useful for building a pkgng repository, since there wasn't any official one out.


Thanks for taking the time to write this up. I really appreciate it.


for binary packages; pkgng: "$ pkg add ..."

for source code install; ports

pkg_add and pkg_delete are becoming obsolete by pkgng


People won't get that same sense trying it now. FreeBSD has gone so far towards the random bloated complexity of linux distros that you really don't feel much of a difference at all. To get that feeling now someone would need to try out one of the other BSDs.


What do you think is an example of FreeBSD bloat?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: