Comment by comex | Hacker News Reader

Comment by comex | Hacker News Reader

Parent Full thread

It's my impression that the discussion about ports, "full range of bits", "assurance that it works" vs. "decentralized" misrepresents Linux distros, or at least Debian - apt provides the full range of dependency tracking, package configuration, etc., and Debian maintains a centralized repository, often with local patches (just like ports), where things are guaranteed to work. The only real difference is the emphasis on source vs binary, which is important but not as fundamental as the article suggests.

Edit: And later on...

The individual releases of a given distribution are much more independent of each other, so it's harder to turn your RedHat 7.3 system into a RedHat 8 system. [...] With a Linux system, however, you tend to find yourself trying to keep a handful of obvious things upgraded, while others get further and further behind, until eventually you just reinstall with the latest version to bring it up to date.

That may be true for RedHat (which I've never used), but Debian has always had good old apt-get update && apt-get dist-upgrade to bring everything up to date.

Edit 2: Whoa, randomly changing site theme.

The article seems to be a little old: "Netscape's browsers, Opera, some office programs, RealPlayer, etc."

Your comment "The only real difference is the emphasis on source vs binary, which is important but not as fundamental as the article suggests" reminds me of a line from someone about compiling kernels: new users use the default kernel because it just works, power users compile their own kernel and are able to eke out a bit more power, and experienced admins use the default kernel because it just works...

Indeed the memories I have of Mandrake and RedHat is a package management nightmare, where not enough things were in the official repos, urpmi had to be installed after the fact, you had to add many third-party repos and/or many standalone rpm packages. Often you'd end up with X.rpm needing Y.rpm v1.1 and Z.rpm needing Y.rpm v1.2, and you had to be really cautious not to screw up your system.

Now the argument that with BSD and ports you have no library problems because you compile everything from source and the ports are all centralized is, well, wrong. Say you install X and Y which depend on libZ; you then upgrade Y, which pulls in a new libZ, which breaks the unchanged X (since it has been built against the earlier libZ). That is, unless you rebuild X to link against the new libZ. Even heard of Gentoo's revdep-rebuild? Hopefully this is mitigated on FreeBSD (and conversely made comparatively worse on Gentoo) because base components do not get bumped like that, so most things link against the seldom moving base and you're done (whereas on Gentoo, you have fun bumping libc or libxml).

I agree, though the extend of that depends on what you put on the machine and it's use.

On a typical server, with less that 100 external ports installed, FreeBSD will rarely need to rebuild libs, because most of the stuff links to the base.

On a typical desktop, with > 1000 ports installed, things get very messy. And the legacy package management of FreeBSD shows its limits. Things are improving, mainly with a move to improved binary tools, but it's been behind linux for a long time.

That may be true for RedHat

It _was_ maybe true, kind of, sometimes: config files were not always marked as config files, for example.

It's definitely no longer true now. On Fedora you run preupgrade. For RHEL point releases, yum. For RHEL major releases, you need to run a kickstart upgrade.

Not to mention that the BSD community as a whole is being slowly taken over by pkgin..

Only pkgsrc part of the community ;)

Also, it's only used for packages distribution and the packages are still build from the ports:

    pkgin is aimed at being an apt / yum like tool for managing pkgsrc binary packages.

FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals. I'm not sure what the OpenBSD guys are doing

And yes, it's only for distribution. But if it works well, it's the only thing end users should care about. Though I'm not exactly sure the BSDs have basic end users in the way linux does.

> FreeBSD is (more or less) moving towards pkgng, which has roughly the same goals.

Yeah, but the BSDs always had pkg_add and other pkg_* tools, pkgin is just a nice alternative that works on more than one system... I don't believe it provides any crucial feature that was missing in the pkg_tools.

> And yes, it's only for distribution. But if it works well, it's the only thing end users should care about.

From OpenBSD's FAQ:

    The ports tree is meant for advanced users.
    Everyone is encouraged to use the pre-compiled binary packages.

Basically, if you're running unmodified OS (i.e. official release) and don't enable any options disabled by default in the ports then you're just wasting CPU power rebuilding stuff that you could easily grab from the nearest mirror.

As far as I can tell, there is no tool in FreeBSD base that provides a simple way to check and update all ports using binaries. FreeBSD's pkg_add only handles direct installs of new packages. Upgrade management, things like "update everything" or "update this package and its dependencies" is usually done through one of the external tools like portmaster, portupgrade, pkg_upgrade, etc. Which interact with the ports tree and pkg_add behind the scenes, but with additional info on dependencies to keep the whole thing sane. They do the job okay, but they all have their quirks.

From its man page, it seems OpenBSD's pkg_add supports updating (and a lot of other things), so I guess they don't have this problem to start with. That's interesting, I wonder why the feature is lacking on the FreeBSD side.

Ah, indeed, it seems that FreeBSD is a lot less package-friendly than OpenBSD & NetBSD.

OpenBSD have always encouraged the use of the pkg* tools to install binary packages rather than using ports: http://openbsd.org/faq/faq15.html#Ports

OpenBSD (or espie, rather) rewrote pkg_add to fix a lot of update issues a long time. It's not going to be replaced.

The theme change was really unexpected. Nearly made me close the browser tab.

Yeah, these comparisons suffer from the fact Linux really is just a kernel: There's no single Linux community, no single Linux technical standard, etc. Instead, we have Debian, Red Hat, Slackware, Ubuntu, SuSE, etc., all sharing software but not necessarily sharing culture or methodology.

(And on the Linux side, we have people who apparently believe that the distro you choose determines what desktop environment you have to run. If I hear about one more person dropping Ubuntu because of Unity ... I'll get more confused, I suppose, and wonder why they don't just install Window Maker or Xfce or something else from the package repos and use that, instead.)

It would be more enlightening to pick a specific distro to do your comparing to, as a specific version of a BSD project (OpenBSD, say) is more comparable to a whole Linux distribution than to a specific version of the Linux kernel.

Then you have missed the point of the article. The intro even says that the point is to compare the Linux world with the BSD world, not specific distros. The author highlights - stresses even - that there is no homogenous Linux community, that Linux development is 'chaotic' compared to BSD development, and that that chaos is the source of Linux's strength. That sense of chaos is the core shared culture in Linux.

What you want - distro-to-distro comparison - would suck; and age rapidly.

Reply on news.ycombinator.com