Hacker News Reader

Comment by harrytuttle | Hacker News Reader

Wonderful!

I may actually consider dumping Debian for FreeBSD 10.

I've never been totally happy with Linux after moving off "proper" UNIX machines. I had a FreeBSD 4.4 machine floating around for years which I was rather happy with but drifted off to Linux-land primarily due to convenience when it came to Flash and audio.

So many compelling reasons to switch back to FreeBSD now.

View on HN

What exactly is attracting you to FreeBSD?

I ask because Debian has a FreeBSD "port". That is, it offers the Debian userland on top of the FreeBSD kernel.

So, depending on what you're looking for, you might be able to gain access to the best of both worlds.

If you're after the FreeBSD experience (i.e. the community, the BSD command line utils, ports, and the preference for permissive licenses), then I guess Debian/kFreeBSD really isn't of any interest to you.

Well the main things for me are

1. feels closer to "old fashioned non-Canonical'ed UNIX" which I was brought up on.

2. Way less politics due to license.

3. Less crazy forking and wheel reinventing (basically everything Ubuntu isn't).

4. It has orders of magnitude better documentation

5. pkgng is actually really nice

6. separation of core OS vs ports/packages so easy to stage updates compared to catch all Linux distros.

7. pf is miles better than iptables

8. ZFS.

9. I have a Sun Ultra 30 sitting in my cupboard which Linux doens't like.

10. Has valgrind that works properly unlike the other BSD's.

That's about it but it's enough.

My use cases are: personal use, professional use (devops), professional use (production).

It also has dtrace, including kernel support enabled by default.

Forgot about dtrace - good point!

So much goodness!

> I ask because Debian has a FreeBSD "port"

I've used FreeBSD and before that Gentoo (which has a package manager, portage, influenced by BSDs ports system) for more than a decade, and I've never understood the appeal of apt or the other Debian tools. In my experience, they just don't work as well as ports, constantly require adding additional repositories (because the official repository is missing some relatively popular package for who knows what reason) - which may or may not conflict with others I have -, and in general, are just more work than ports, portage, or MacPorts.

Inflicting apt on a system with a superior package management system seems like a sysadmin's bright idea - having no experience with ports or other package managers.

I've used apt on several systems - Maemo, Debian, Ubuntu, OS X (as fink), and always found it to be one of the weakest package managers (I've even had better experience with yum/RPM).

So how do you use ports in practice? Do you use sources or binary packages? Which management solution do you use, or do you just use the make files? I am constantly thinking about revisiting BSD, but in contrast to your experience I found the apt package solution to work very well and just be better.

I install everything from source. Except for thing like desktop environments, building from source is a non-issue on modern hardware. It also gives me some confidence in the binary compatibility of the packages I have installed.

For installing:

    pushd /usr/ports/*/$PACKAGE ; sudo make install clean && popd

For upgrading (ports):

    sudo portsnap fetch update ; sudo portmaster -ad

(In reality, portsnap is run nightly).

A quick read - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/po...

I use FreeBSD on a desktop at home and for a personal web server. I'm not performing large scale deployments (but if I were, I'd probably write a port for my application, define my dependencies, and install it just like anything else).

I'm not about to move to FreeBSD, but I did just discover pushd and popd from this comment. Thanks!

You can also use parentheses to create a scope for the current directory and environment variables (the shell forks a subprocess to run parenthesized commands).

    (cd /usr/ports/*/$PACKAGE ; sudo make install clean)

See http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu...

In your example, however, the failure of `make install clean` will put you back in the original directory and not in the port's directory where you probably want to be to debug the failure. My original example keeps you in the port's directory in the event of installation failure.

Personally, I couldn't anymore handle the way ports asks for configuration options for every package that has configurable options. I'm spoiled by the "sane defaults" stance of better Linux distros like Arch.

    echo BATCH=1 >>/etc/make.conf

No more prompts for options - they should all certainly have sane defaults. If not, it's a good reason to run send-pr.

I've always been a fan of

    make config-recursive && make install clean

which runs `make config` on the package and all dependencies before installing. It's the best of both worlds IMO -- the port will build unattended and you still have a chance up-front to skim the available options for things you need.

Also

  make -DBATCH install clean

in port directory will do unattended build with default settings. It affects current port and all of its dependencies.

Either set BATCH env variable or use portupgrade/portinstall with -c or -C flags. The latter gathers all the dependencies of a given port and let's you configure them up front, and then the compilation and installation goes without any interruptions.

    -c 
    --config
     	 Run "make config-conditional" before everything for all tasks.
    -C 
    --force-config
     	 Run "make config" before everything for all tasks.

http://www.gsp.com/cgi-bin/man.cgi?topic=portupgrade

I use poudriere and pkgng - the former for building my own package repository, the latter for installing and upgrading. The pkgng side is comparable to apt: `pkg install vim`, `pkg upgrade`, `pkg autoremove` etc; the poudriere side isn't much worse: https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/pkgng_r...

I admit I had some level of apt-envy back when I was using portupgrade. pkgng has nicely eliminated that.

From my perspective (I'm not the GP), I will be using a custom configuration management system that I wrote back in 1999. It's. Like puppet but ssh based, written in sh and standard Unix tooling. It doesn't use a DAG so you have to order dependencies carefully.

That will pull binary packages from ports builds on another machine and install and configure them.

I use debian/kfreebsd on my server so I can use zfs. Had Freebsd previously, but the lack of a Stable ports tree meant updating broke things often.

Although many things don't work on debian/kfreebsd, and searching for help is tricky, do I go the debian way or the freebsd way, it's always updated with few problems.

Port updates are a lot nicer now we have poudriere and pkgng - I haven't had a "pkg upgrade" break anything in months, and that was prior to automatic shared library tracking and just needed a "pkg install -Rf lang/perl" to fix.

e.g. the latest entry in UPDATING is for any port depending on converters/libiconv. Using portmaster or portupgrade requires querying the package database for the list of depending ports, force-deleting libiconv and then force-rebuilding from the previously saved list. With pkgng it's a case of "pkg upgrade && pkg autoremove".

I have been using ZFS on Linux[1] for about six months now, on both Debian and Ubuntu. Installation is trivial and it seems to work quite well, though I do not stress it very much.

[1] http://zfsonlinux.org/

I've heard Debian/kFreeBSD has poor multithreading support because it's built against glibc/libpthread rather than the native freebsd libc (which has an NPTL-equivalent).

kFreeBSD recently gained native support (called FBTL).

See http://lists.debian.org/debian-bsd/2013/07/msg00060.html and http://asdfasdf.debian.net/~salinger/eglibc.fbtl/

Reply on news.ycombinator.com