In Other BSDs for 2014/05/17

Some leftovers from last week since I’m catching up, so get ready to read.

6 Replies to “In Other BSDs for 2014/05/17”

  1. JabirOS doesn’t have much in the way of information on their page, I don’t really understand the purpose or goals, nothing is really listed. They were once Ubuntu based, then FreeBSD based, not independently maintain their own code that was forked from FreeBSD 10, but why? A school project for some festival. I don’t understand what makes it different, by concept, design, or goals. Anyone know anything more?


    That summarizes it a little better, he started it while in high school, wants to fork with kernel changes similar to how DragonFlyBSD did. What I really don’t like is that he says his ideas are secret but his code will be open, so there isn’t really documentation for a roadmap or intention for the project, just this mystical futuristic demand that you’ll like it, because.

  3. I have mixed feelings about systemd. On one hand, it is in some ways clearly better than the mess of SysV scripts Linux has employed for eons, but I can’t help but see its rapid growth and feature creep as if it were a cancer, infecting everything it touches, growing uncontrollably. That said, seeing it as an attempt at bringing some kind of consistency to the Linux world (kind of like the base systems in BSD), isn’t something I can condemn.

    Of course my concern isn’t for Linux since I rarely use it (Android aside ;), but how it is slowly becoming required by software I do care about, making it evermore Linux-only. Being a BSD person, that is a big problem looming on the horizon.

    WRT PBIs, it looks more like they are going away, as opposed to being changed “for the better.” No longer will they be self-contained entities like applications on OS X, which to me was the single defining feature of PBIs over ports.

    Stack shuffles! I always love seeing the things that OpenBSD implements to make their system more hostile to badly written crapware. I liked that DragonFly used to incorporate some of the features like the malloc changes from OpenBSD 3.8(ish) but IIRC was later replaced by a new allocator that prioritized scalability instead. I’m not complaining, I just think that if more systems made it harder for buggy software to run, we’d collectively be in a better place.

    “Why doesn’t it show up in a man page search at the site?”

    OpenBSD is really the only platform I’ve used where I’ve come to expect man pages to be not only present but correct and up to date. Few people from other projects seem to update man pages when they make changes to software, or when code is imported from other systems, at least not in a timely manner. In the past I’ve found DragonFly and to a lesser extent FreeBSD to be spotty in places. On the plus side, it is nowhere nearly as bad as the situation on Linux…

    I’m certainly grateful for the great stuff I get for free from all these various projects and developers, and am not the sort of person who generally expresses any opinion on how people can or “should” spend their free time, but the lack of/incorrect/incomplete manual thing is something that bugs me when I’m trying to figure something out. The people who write the code really are IMHO the very best people to be documenting what they wrote.

  4. Lazarus – for what it’s worth, the web page presentation of the DragonFly man pages is updated twice a day, I think it is, from dragonfly-current, so that is almost always correct. I mention that just because whenever I’m linking to a new commit, the man page (if there is one) is 99% of the time already built online so I can link to that for an explanation – a habit I really appreciate.

    That’s separate from the commit of man page information with each change, I know, but I had to say where I was coming from.

  5. Lazarus

    Undocumented features from man pages are a feature of Linux :)

    I wish systemd would go away and take java with it and never show its ugly face again.

Comments are closed.