6 ms·

We're heading for a brave new world where the kernel is just another package, not some immutable part of the whole system. While I can agree with this on the g

by Ixiaus 16y ago

We're heading for a brave new world where the kernel is just another package, not some immutable part of the whole system. While I can agree with this on the grounds that diversity of choice is a Good Thing and will introduce innovation and cross pollination between the two camps (hence my comment about being happy that they are experimenting with it); I disagree with it because the solidity and strength of FreeBSD primarily comes from it being developed and offered as a cohesive whole (Kernel and userland). Lack of cohesion is one of my major gripes with the GNU/Linux "distribution" model; although, I will say that Debian seems to be making up for this with excellent progress!

avar 16y ago
Sure, I mean that comment in the context of Debian. Debian GNU/kFreeBSD isn't going to be a replacement for FreeBSD any time soon for the people that prefer it. But it's an excellent alternative for Debian users who'd like to use ZFS and other FreeBSD features without throwing the rest of Debian out with the bathwater. This'll also be wonderful for the BSD's in terms of increasing the portability of packages in Debian that they might want to pick up.
- Ixiaus 16y ago
  But it's an excellent alternative... That's the key reason I think it's a Good Thing; portability for FreeBSD was never a big issue because of Linux Binary Compatibility, though...
- danieldk 16y ago
  Indeed. And an additional advantage to the FreeBSD may be that it can raise the profile/popularity of FreeBSD. The same would apply to an official port to the OpenSolaris kernel.
danieldk 16y ago
Maybe (I prefer GNU userland). But it does provide far nicer (or if you will, very different) package management from stock FreeBSD.
- Ixiaus 16y ago
  I seriously disagree with this. The Ports tree is much more coherent and easy to use than any of the Linux distribution's attempts. The key reason for this is the fact that FreeBSD is a cohesive whole rather than a "distribution". I'm always pulling out hair when using yum, apt, or any other package manager - updating repositories, dealing with 3rd party repositories; just plain old bleh. With the ports tree, I have a cron job that runs portsnap upgrade monthly (so I have the latest software). I never install binaries of a piece of software that requires a lot of configuration, like PHP, Apache, or et al. I will use pkg_add for things like vim, bash, zsh, etc...
  - __david__ 16y ago
    > FreeBSD is a cohesive whole rather than a "distribution". So far you're the second person in this thread to use that phrase. I saw it mentioned multiple times in another recent HN article's comments. I don't understand what it means. It seems to be said with an almost religious fervor, but I might just be misinterpreting it. What, specifically, does cohesive mean to you in practical real world terms? How do the BSD versions 'ls' or 'grep' or 'awk' benefit from being cohesively developed with the kernel? I feel I'm missing something here and would love to be enlightened.
    - Ixiaus 16y ago
      Some people use it with religious fervor, some do not; there is truth behind it though. Cohesive in this context refers to the user land and kernel software ecosystem of the project. GNU/Linux is called "GNU"/"Linux" because it is the user land software of the GNU project bundled with the kernel of the Linux project. The development of base user land utilities and software is done in completely separate fashion from that of the kernel - they are then mixed and matched into "distributions". That model has a key advantage, namely, organic growth through asynchronous development - innovation in the kernel has it's own programmer resources and isn't limited by the development path of the user land; the same can be said of user land. Now, it's also a disadvantage in that, you have gazillions of distributions that are now mixing and matching user land software with completely different methods of managing that software (yum, apt, rpm, etc..). FreeBSD, however, develops the kernel and its base user land all in unison. There are no distributions, there is just "FreeBSD" and as a result, there is just one method for managing user land software (ports). The key advantage here is uniformity and tight integration with the components of the kernel and the base user land system. BSD vs. GNU ls or grep or awk is moot - they are practically the same tools. The difference is that they are developed and refined with the base system (which means Clang/LLVM will now be compiling those tools). I liken the difference of FreeBSD vs. GNU/Linux to the days when vendor hardware was cohesively developed and the modern days where all of your components come from separate vendors. There are pros and cons to both. My preference is the *BSD way :)
_delirium 16y ago
> primarily comes from it being developed and offered as a cohesive whole (Kernel and userland) To a large extent this is also the Debian model, which is a lot more integrated than many Linux distributions--- they don't just cobble together a bunch of packages and call it a day. Like FreeBSD, they do take a lot of things from upstream (e.g. both use X.Org as their X11 server), but also like FreeBSD, they heavily customize the core packages and develop them so they work together well. There are core Debian teams working on its versions of the Linux kernel (http://wiki.debian.org/DebianKernel http://wiki.debian.org/DebianKernel), X.org (http://wiki.debian.org/XStrikeForce http://wiki.debian.org/XStrikeForce), Exim MTA (http://wiki.debian.org/PkgExim4 http://wiki.debian.org/PkgExim4), package manager (http://wiki.debian.org/Apt http://wiki.debian.org/Apt), etc., along with thousands of Debian-specific patches to other packages, which are maintained as far as possible in an integrated manner to meet the unified Debian system policies. It's not entirely identical, but I don't think it's that far off. I think the FreeBSD core system may be developed somewhat more as a single entity (for example, because FreeBSD literally develops its own kernel, rather than customizing an upstream one), but Debian may actually have more cohesive development across the entire system. My impression, though I could be wrong, is that FreeBSD ports are more spotty when it comes to really being managed seamlessly with the base system.
- tvon 16y ago
  > To a large extent this is also the Debian model, which is a lot more integrated than many Linux distributions (...) Is there anything that Debian does with regards to integration that Ubuntu, Fedora, CentOS/RHEL, and even Gentoo don't do?
  - thristian 16y ago
    A colleague was telling me yesterday that the official Apache Tomcat packages for CentOS/RHEL keep all their runtime temporary files in /usr/share/tomcat; that's the sort of thing that would never be allowed in a Debian package (runtime state belongs in /var). Another example: The Debian packaging guidelines demand that every executable have a man page available, even if the upstream project doesn't supply one. They're not always as complete and comprehensive as one might hope, but they're often enough to give you the general gist of what a command is supposed to do, and how to use it. Yet another example: Debian has an 'alternatives' system, by which you can configure the system and tell it that your preferred terminal emulator is 'xterm', your preferred text-editor is pico, etc. (this extends to man pages too - if you make "x-terminal-emulator" point at xterm, then "man x-terminal-emulator" will give you the xterm man page). Every package that Debian ships that is able to spawn a terminal emulator in some way is required to launch x-terminal-emulator rather than hard-coding xterm or rxvt or whatever. The downside to all this is that if you know how to configure/administer package X on RedHat or FreeBSD, you might get lost trying to find where the package keeps its stuff in Debian. The upside is that if you know how to configure/administer package X on Debian, you should find it pretty easy to configure/administer packages Y and Z as well. One more example: The last time I installed fetchmail on RedHat, I wound up having to create /root/.fetchmailrc and write my own cronjob to run it. The last time I installed fetchmail on Debian, it already came with an /etc/init.d script that would do all the periodic checking for me, all I had to do was create an "/etc/fetchmailrc" file (like any other system service) and start it up (like any other system service). Debian's integration goes far, far beyond any other distro I've seen.

by Ixiaus 16y ago

avar 16y ago

Sure, I mean that comment in the context of Debian. Debian GNU/kFreeBSD isn't going to be a replacement for FreeBSD any time soon for the people that prefer it. But it's an excellent alternative for Debian users who'd like to use ZFS and other FreeBSD features without throwing the rest of Debian out with the bathwater. This'll also be wonderful for the BSD's in terms of increasing the portability of packages in Debian that they might want to pick up.

Ixiaus 16y ago
But it's an excellent alternative... That's the key reason I think it's a Good Thing; portability for FreeBSD was never a big issue because of Linux Binary Compatibility, though...
danieldk 16y ago
Indeed. And an additional advantage to the FreeBSD may be that it can raise the profile/popularity of FreeBSD. The same would apply to an official port to the OpenSolaris kernel.

danieldk 16y ago

Maybe (I prefer GNU userland). But it does provide far nicer (or if you will, very different) package management from stock FreeBSD.

Ixiaus 16y ago
I seriously disagree with this. The Ports tree is much more coherent and easy to use than any of the Linux distribution's attempts. The key reason for this is the fact that FreeBSD is a cohesive whole rather than a "distribution". I'm always pulling out hair when using yum, apt, or any other package manager - updating repositories, dealing with 3rd party repositories; just plain old bleh. With the ports tree, I have a cron job that runs portsnap upgrade monthly (so I have the latest software). I never install binaries of a piece of software that requires a lot of configuration, like PHP, Apache, or et al. I will use pkg_add for things like vim, bash, zsh, etc...
- __david__ 16y ago
  > FreeBSD is a cohesive whole rather than a "distribution". So far you're the second person in this thread to use that phrase. I saw it mentioned multiple times in another recent HN article's comments. I don't understand what it means. It seems to be said with an almost religious fervor, but I might just be misinterpreting it. What, specifically, does cohesive mean to you in practical real world terms? How do the BSD versions 'ls' or 'grep' or 'awk' benefit from being cohesively developed with the kernel? I feel I'm missing something here and would love to be enlightened.
  - Ixiaus 16y ago
    Some people use it with religious fervor, some do not; there is truth behind it though. Cohesive in this context refers to the user land and kernel software ecosystem of the project. GNU/Linux is called "GNU"/"Linux" because it is the user land software of the GNU project bundled with the kernel of the Linux project. The development of base user land utilities and software is done in completely separate fashion from that of the kernel - they are then mixed and matched into "distributions". That model has a key advantage, namely, organic growth through asynchronous development - innovation in the kernel has it's own programmer resources and isn't limited by the development path of the user land; the same can be said of user land. Now, it's also a disadvantage in that, you have gazillions of distributions that are now mixing and matching user land software with completely different methods of managing that software (yum, apt, rpm, etc..). FreeBSD, however, develops the kernel and its base user land all in unison. There are no distributions, there is just "FreeBSD" and as a result, there is just one method for managing user land software (ports). The key advantage here is uniformity and tight integration with the components of the kernel and the base user land system. BSD vs. GNU ls or grep or awk is moot - they are practically the same tools. The difference is that they are developed and refined with the base system (which means Clang/LLVM will now be compiling those tools). I liken the difference of FreeBSD vs. GNU/Linux to the days when vendor hardware was cohesively developed and the modern days where all of your components come from separate vendors. There are pros and cons to both. My preference is the *BSD way :)

_delirium 16y ago

> primarily comes from it being developed and offered as a cohesive whole (Kernel and userland) To a large extent this is also the Debian model, which is a lot more integrated than many Linux distributions--- they don't just cobble together a bunch of packages and call it a day. Like FreeBSD, they do take a lot of things from upstream (e.g. both use X.Org as their X11 server), but also like FreeBSD, they heavily customize the core packages and develop them so they work together well. There are core Debian teams working on its versions of the Linux kernel (http://wiki.debian.org/DebianKernel http://wiki.debian.org/DebianKernel), X.org (http://wiki.debian.org/XStrikeForce http://wiki.debian.org/XStrikeForce), Exim MTA (http://wiki.debian.org/PkgExim4 http://wiki.debian.org/PkgExim4), package manager (http://wiki.debian.org/Apt http://wiki.debian.org/Apt), etc., along with thousands of Debian-specific patches to other packages, which are maintained as far as possible in an integrated manner to meet the unified Debian system policies. It's not entirely identical, but I don't think it's that far off. I think the FreeBSD core system may be developed somewhat more as a single entity (for example, because FreeBSD literally develops its own kernel, rather than customizing an upstream one), but Debian may actually have more cohesive development across the entire system. My impression, though I could be wrong, is that FreeBSD ports are more spotty when it comes to really being managed seamlessly with the base system.

tvon 16y ago
> To a large extent this is also the Debian model, which is a lot more integrated than many Linux distributions (...) Is there anything that Debian does with regards to integration that Ubuntu, Fedora, CentOS/RHEL, and even Gentoo don't do?
- thristian 16y ago
  A colleague was telling me yesterday that the official Apache Tomcat packages for CentOS/RHEL keep all their runtime temporary files in /usr/share/tomcat; that's the sort of thing that would never be allowed in a Debian package (runtime state belongs in /var). Another example: The Debian packaging guidelines demand that every executable have a man page available, even if the upstream project doesn't supply one. They're not always as complete and comprehensive as one might hope, but they're often enough to give you the general gist of what a command is supposed to do, and how to use it. Yet another example: Debian has an 'alternatives' system, by which you can configure the system and tell it that your preferred terminal emulator is 'xterm', your preferred text-editor is pico, etc. (this extends to man pages too - if you make "x-terminal-emulator" point at xterm, then "man x-terminal-emulator" will give you the xterm man page). Every package that Debian ships that is able to spawn a terminal emulator in some way is required to launch x-terminal-emulator rather than hard-coding xterm or rxvt or whatever. The downside to all this is that if you know how to configure/administer package X on RedHat or FreeBSD, you might get lost trying to find where the package keeps its stuff in Debian. The upside is that if you know how to configure/administer package X on Debian, you should find it pretty easy to configure/administer packages Y and Z as well. One more example: The last time I installed fetchmail on RedHat, I wound up having to create /root/.fetchmailrc and write my own cronjob to run it. The last time I installed fetchmail on Debian, it already came with an /etc/init.d script that would do all the periodic checking for me, all I had to do was create an "/etc/fetchmailrc" file (like any other system service) and start it up (like any other system service). Debian's integration goes far, far beyond any other distro I've seen.