Hacker News Reader

Comment by bborud | Hacker News Reader

Make managing FreeBSD not suck?

Perhaps you could constructively expand on this?

For the most part, I find managing FreeBSD to be painless, with one glaring exception I'll get to in a minute. I really love that the base system and the 3rd party packages are iterated separately -- I can have a stable base OS, while also running modern software.

The problem is the ports system. Building your own software is a nice option to have, but it's usually just a waste of everyone's time, and it tends to fail in annoying, new, and magical ways.

Fortunately, we have https://wiki.freebsd.org/pkgng coming down the pipeline, which solves the problem (finally).

On top of the hassle of using ports, writing ports is a huge hassle of battling archaic crap. Rather than using destroot, like every other package manager from the past 15 years, FreeBSD requires the package maintainer to manually list out each file that will be installed on the target system, and will fail to properly clean up ports if those file lists are incorrect.

That said, it's not all that much worse than what's necessary to produce a debian/ubuntu package -- it just could be better.

I've been running pkgng on CURRENT for a bit...It's really quite painless, even if you prefer compiling everything. The new pkg tool does some stuff easily that is painful even in debian (which in my opinion has always done packages right...I was burned by rpms in the 90s/00s many times). For instance I just discovered 'pkg which' which will tell you which package installed any file. I believe this is possible on debian, but not a two word command (I could be wrong).

One benefit as well is that it seems to do less random io/spinlocking when doing stuff with the package database than the old tools, which means large install runs (compiled or not) go much faster.

It also builds in vulnerability auditing, which is also great. Previously this required a separate port.

Just in case you (or anyone else) is wondering. You can find out which rpm installed a file with rpm -qf <file>. And you can see all the files in an installed rpm with rpm -ql <pkg>.

I'm also curious about the dpkg equivalent.

> I'm also curious about the dpkg equivalent.

dpkg -S /path/to/file

dpkg -L <package> lists files in a package.

edit: dpkg -l | --list lists packages, -L|--listfiles lists files in packages (which is why it isn't just dpkg -l)

Even the old pkg_info -W offered this.

As already mentioned "dpkg -S file" will show which package installed which file. If you install apt-file, you can also search for which package, installed or not, contains a file:

  $ apt-file search /etc/apache2/ports.conf
  apache2.2-common: /etc/apache2/ports.conf
  $ aptitude search apache2.2-common
  p   apache2.2-common    - Apache HTTP Server common files
  $ dpkg -S /etc/apache2/ports.conf
  dpkg-query: no path found matching pattern
    /etc/apache2/ports.conf

I'd be happy to.

I'm old and grumpy and I just want my computers to work. Even though I did spend a lot of years hacking more than a dozen different UNIX flavors, it is close to 15 years since I found the easter-egg hunt of upgrading he OS even vaguely satisfying.

About a decade ago I discovered Ubuntu. I had just gotten a new ThinkPad and I needed to install Linux on it. I started the install and went back to hacking. At the end of the day I checked in my code and I remembered that oh fuck I'm installing Linux and now it is time to fight with X11 for the rest of the day in order to get a vaguely acceptable X11 setup. Better call my wife and say that I'd be spending the rest of the evening at the office swearing at my computer and using the competition's search engine to look for "X11" and "ThinkPad".

Except that didn't happen. I touched the keyboard and there was the X11 login screen. Just like that. Wow.

And Ubuntu just kept getting better over the next years. Until it reached a point where upgrading it was just a matter of running a few commands and reboot. Neat.

Of course, some time in 2006 I developed a serious case of suspend-envy and I ditched Ubuntu for OSX and a MacBook Pro. Imagine that: just being able to slap your laptop closed, carry it off somewhere, open it and it would just work. Without me having to spend about one man-week per year trying to make my laptop not self-destruct by burning its way through my backpack.

Funny that: me growing tired of constantly having to manage the operating system and fiddle around with the kernel to make my computer stay out of my way while I am programming.

It took me a good 6 months to get used to all the annoying aspects of using a Mac to develop software. But you know what: I got to spend more time programming and less dicking around with the OS so I was happy.

Of course, in 2008 I got the crazy idea that I wanted to store all my photos on a computer that had a decent filesystem. FreeBSD had ZFS, so while I wasn't overly fond of FreeBSD, I thought ZFS was worth the hassle. The downside is that FreeBSD, while a good basic OS, never quite grew up. It is still a pain in the ass to manage because it is no different from back in the 1990s when I made a living setting up SunOS machines for the math and chemistry department at my local university. Or dicking around with Ultrix at the mechanics dept. Upgrading the OS back then was like performing brain surgery. You needed notes and you needed to remember all the weird-ass quirks and pitfalls.

The other day I realized that my storage server is running an old version of FreeBSD and could do with an upgrade. Only I've forgotten the procedure and when reading up on it I realized that ... boy this sucks ass.

What is mostly annoying is that people think this is okay. It is like having to listen to people who think that the Model T Ford was the pinnacle of automotive usability: http://www.modelt.ca/drive-fs.html

This is 2013. Excuse me if I don't find manually upgrading operating systems amusing.

# freebsd-update upgrade -r 9.1-RELEASE

... wait while the new release is downloaded ...

# freebsd-update install

... watch the new kernel get installed ...

# shutdown -r now

... wait while the box reboots ...

# freebsd-update install

... watch the new world get installed

And you're done.

right:

  # freebsd-update upgrade -r 9.1-RELEASE
  Looking up update.FreeBSD.org mirrors... 3 mirrors found.
  Fetching public key from update5.freebsd.org... failed.
  Fetching public key from update3.freebsd.org... failed.
  Fetching public key from update4.freebsd.org... failed.
  No mirrors remaining, giving up.

It looks like your network is failing.

It isn't.

Which version of FreeBSD are you running? Usually people get that because freebsd-update cannot fetch metadata for the release they're running.

7.2-STABLE

That's the problem then -- you need to be running a release. The argument being that if you can get yourself to -STABLE, you're obviously comfortable with source upgrades.

That's certainly fair, although the error message gives no indication of that and appears to be a problem with the FreeBSD-update infrastructure.

You should post this on the FreeBSD forums -- there are a lot of helpful people there who can help you troubleshoot this.

http://forums.freebsd.org/

I'll leave freebsd-update aside, since Colin already touched on that.

I too am old, and often extremely grumpy. That said, I think you might be having a "senior moment" regarding your recollection of administering SunOS systems, if you're comparing the hassle of SunOS to FreeBSD.

If you are looking for something like that, take a look at PC-BSD, not FreeBSD directly.

I agree with the parent poster that package management and graphical environments on FreeBSD is NOT very easy compared to Ubuntu, for example.

pkgng supposedly brings FreeBSD's package system close to Debian's which would be a great advance. I almost wonder why they didn't port Debian's system over completely. Is it a GPL thing, or did they do apt-get better?

On top of the hassle of using ports...

I have a nearly friction-free experience with FreeBSD ports.

  portsnap fetch && portsnap extract
  cd /usr/ports/lang/python && make install clean
  cd /usr/ports/www/nginx && make install clean
  ...etc

Sometimes, during an extensive upgrade of hundreds of ports (portupgrade -a) I've gotten into a situation in which the ports system got confused a bit (it happened twice with a PHP extension). In such a case, pkg_deinstalling liberally Apache, PHP, PHP extensions, Apr-utils and maybe some others like freetype, and then installing the web stack ports again has always solved the problem.

What do you feel is wrong with it now? It's much easier to implement features/fixes/improvements when you have an idea of what people want, and why they want it; there's not much you can do with "it sucks".

Reply on news.ycombinator.com