Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday November 05 2019, @12:03PM   Printer-friendly
from the potato-potatoe dept.

System administrator and former ski instructor, Albert Valbuena, has posted a table with accompanying analysis comparing several of the BSDs against Illumos and Linux. Among the topics in the analysis are licensing, how licensing is abused by companies, benchmarking, and of course a comparison of how various features are or aren't implemented across the spectrum.

The writing of this piece comes from the annoyance I get from reading about the prominence of Linux (the kernel) in almost all the computing spaces. And since electronic devices are gaining relevance in our daily lives and society in general this question of prominence of not just Linux but 'X' gains importance too.

More specifically this writing comes after reading someone who has participated in relevant software which is in a gazillion people's pocket. In a very unfortunate reply to the question: 'What are the advantages Linux has over BSD now?' the individual in question (which I'd like to preserve his identity) replied something close to (I do paraphrase): Linux receives much more investment from companies and therefore more paid developers are in it, plus BSD's feature parity with that of Linux doesn't hold.

This is mainstream opinion. Linux is better than anything else and money is poured in constantly, more than in other platforms. And aside this is not true, this is not based in facts but on feelings. Most GNU/Linux distributions are very average on many aspects. The fact they run on many servers on this planet and many developers work on them, doesn't make them better than 'X'. They are popular but that's it.

The individual in question did not, because he could not, point to relevant feature differences bettween the two operating systems.

Now go back to the top of this article and start checking features in a specific OS and start comparing, from that fastly written, from the top of my head, chart. Have fun doing that.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by bzipitidoo on Tuesday November 05 2019, @02:01PM (4 children)

    by bzipitidoo (4388) on Tuesday November 05 2019, @02:01PM (#916236) Journal

    Hardware device drivers are king. Most of the Linux kernel source is drivers of that sort. The kernel module system was improved and enhanced to better handle the sheer quantity. Most especially, it was necessary to keep generic kernels within practical size limits while still being able to communicate with the most common hardware.

    Being able to unload modules was added quite a while ago. Another really nice thing for those who want to roll their own kernel is an option to automatically select the modules that the particular hardware is running, introduced around 2.6.28. Before that, if you wanted a lean kernel with support for only the hardware that is actually present, you had to check back and forth to make sure your selection of modules matched the modules that the generic kernel had loaded. Rather tedious.

    The impression I've always had is that the BSDs simply do not support as much hardware. Stick with mainstream hardware, and the BSDs are okay. Also, I think drivers for new hardware land in Linux sooner. Like, I got this ASUS Stick computer (TS10), and learned the driver I needed was introduced in kernel version 4.11, which was brand new at the time. Had to have 4.11. So I built my own Ubuntu live flash drive with a custom 4.11 kernel I built, no distros having yet adopted 4.11. And then the stick proved prone to overheating, so all that effort was largely wasted :p.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1, Interesting) by Anonymous Coward on Tuesday November 05 2019, @04:06PM (3 children)

    by Anonymous Coward on Tuesday November 05 2019, @04:06PM (#916311)

    FreeBSD, OpenBSD, NetBSD all break the ABI every major release distribution. In order to do an in-place upgrade you have to compile either the kernel or the new world in compatibility mode for the previous edition, then restart with the new userspace/kernel, then rebuild the world or kernel again.

    Linux in comparison has only had major breakage a few times, and those were mostly around the migration from A.OUT to ELF, from static /dev to devfsd to tmpfs/udev, and certain networking/security features. Most of the breakage in fact was simply developer laziness in adding compatibility codepaths, and in fact some code will run across many different versions (busybox for instance, although with a subset of networking took and other features disabled to run from 2.4->4.x).

    As a result of this, while Linux is messier to bootstrap, you can, outside of mainstream distros, set up a system that will last for years with few modifications other than security fixes. BSD in comparison requires a completely new userspace each time and has been steadily bloating up (as have the mainstream linux distros.)

    As stated elsewhere, Linux has also had more hardware driver development which has helped immensely.

    • (Score: 5, Insightful) by Dr Spin on Tuesday November 05 2019, @08:40PM (1 child)

      by Dr Spin (5239) on Tuesday November 05 2019, @08:40PM (#916509)

      FreeBSD, OpenBSD, NetBSD all break the ABI every major release distribution.

      I am not sure this is true. However, they all say "if you plan to break the API, you MUST wait until the next major release". That is why it is called a major release!

      And ABI changes are typically few and relatively minor. Most users probably won't notice them.
      Having said that, for those who don't know, the BSDs are not distributions with a common kernel. Each has its own kernel, designed and built with completely different priorities,
      and they are distros in the sense that the entire userland is bundled with the kernel - and the production engineering and quality control covers the combination.
      In most cases, all releases are what Linux would be considered "Long term support" releases, and breaks in the ABI are not exactly a big issue to most users, because when
      you move to the newer release, you would normally replace your entire system - leaving the /home partition alone. You would have backups of all user data (probably on tape,
      because you are a professional).

      As a BSD user for over 20 years (probably over 40 years), I normally upgrade servers by building a replacement, and migrating the data before shutting down the old one. After
      a month or two without problems, the standby machine is de-commissioned, cleaned, and built as a standby replica of the live system until next upgrade time. BSD users tend to think
      10 years is "a relatively short time" and much of the (command line) user interface is little changed since 1978. Bug fixes are important - "Oh Shiny" is not. Tried and tested hardware
      is probably valued over "the cheapest you can get from Ali Express". Hardware support is likely to reflect this.

      BSD GUIs are the same ones you find in Linux.

      In short, the BSDs target a market more like that of an 18 wheeler than a sports car. They do not really compete with Linux.

      --
      Warning: Opening your mouth may invalidate your brain!
      • (Score: 0) by Anonymous Coward on Tuesday November 05 2019, @10:33PM

        by Anonymous Coward on Tuesday November 05 2019, @10:33PM (#916576)

        CentOS is your solution.

    • (Score: 2) by TheRaven on Saturday November 09 2019, @10:59AM

      by TheRaven (270) on Saturday November 09 2019, @10:59AM (#918204) Journal
      Note, the following applies to FreeBSD only:

      ABI is an overloaded term when talking about an OS. There are a lot of different parts.

      FreeBSD's system call ABI is stable. If there's a breaking change, it's done by adding a new system call, rather than modifying an existing one. By default, the kernel is built with compat layers for the last 2-3 major releases (so around 10 years). You can disable them for embedded products if you want a smaller kernel and you can typically enable them for older ones if you have more legacy software. This is a slightly weaker guarantee than Linux, which tries to avoid having a compat layer and aims to maintain all system calls in perpetuity (which mostly works). Minor releases can add new system calls, major releases remove them but add compat layers.

      The libc and core libraries use symbol versioning. This means that, if you have dynamically linked to libc, you can typically move between major releases without any issues, even if the underlying system calls that are used by libc have changed. This is roughly the same guarantee as glibc and a stronger guarantee than provided by some other Linux libc implementations. Most software works like this. Where there is a major library version bump, FreeBSD provides compat packages that provide the older versions of the base-system libraries. This is a strong guarantee than most Linux distributions, which don't have a notion of a base system as separate from third-party software. If you depend on an old version of OpenSSL across an ABI-breaking change then your binary will stop working. On FreeBSD, the compat package for the old version (installed by default when doing an upgrade across major versions) will install an ABI-compatible version of the old library. Minor releases can add new (versioned) symbols, major versions can bump the SO version of libraries and remove interfaces, but must provide a compat pacakge that includes the old SO version.

      The system administration interfaces, for example the ioctls on network devices to configure WiFi, are stable within a major version but change between versions. A few of these have compat interfaces (for example, to allow people to use ifconfig in a jail that supports an older version). This is a weaker guarantee than Linux for the core system, but a stronger guarantee than some Linux devices provide. Linux, as far as I am aware, does not have an explicit policy on this and individual device drivers can change their userspace API / ABI across any kind of release.

      Note that the reason for the reboot sequence as you describe it is exactly the opposite of what you seem to be claiming. FreeBSD kernel N+1 is guaranteed to work with FreeBSD userland N, but the converse is not true. No OS (Linux, Windows, whatever) makes the converse guarantee. If your new userspace software uses a new system call or a new device ioctl, it will not work on the new kernel. As a result, the recommended upgrade procedure is to install the new kernel (which will support all of your existing software), reboot, and then install the new userspace software (which will work with the new kernel but not necessarily with the old one). In practice, the new userland usually works with the old kernel, which causes people to periodically forget this step if installing from source and then end up with a userland that relies on missing kernel interfaces.

      --
      sudo mod me up