3 ms·

Most interesting, thanks for commenting. This phrase caught my eye... "My entire management chain agrees that the cost of entry is lower to influencing and dri

Most interesting, thanks for commenting. This phrase caught my eye... "My entire management chain agrees that the cost of entry is lower to influencing and driving development in FreeBSD vs other kernels [...]" Is that simply a reflection of the smaller size of the FreeBSD project or does it stem from the 'tight core' model where the kernel and base system are co-developed?

kev009 11y ago
Both.. Facebook advertised "write your own ticket" not so long ago for Linux kernel developers. You are guaranteed to be going up against Google if you want Linux kernel talent that has significant influence. Xref Dan Luu's http://danluu.com/startup-tradeoffs/ http://danluu.com/startup-tradeoffs/ and multiply by 2 to see how much that will cost you. This kind of thing even lures ardent FreeBSD people away, for instance Justin Gibbs, President and Founder of The FreeBSD Foundation currently works at Facebook.. there are many other BSD people stuck in the Borg too. Aside from that, the tight core and stable ABIs and KPIs are much nicer to base things like an appliance off of that may have a long development and longer support lifecycle on. I do some firmware hacking and analysis sometimes for fun, and Linux firmware are always abhorrent in terms of security, quality, license compliance. IBM's disk storage subsystems as one example. I really can't fathom why anyone would base a closed source product on Linux other than wanton incompetence, and I'm not throwing that with tongue in cheek nor lightheartedly.
- kchoudhu 11y ago
  What are your thoughts on the 2.5 year support windows for "Extended Support" releases? (I have a view here, but I don't want to bias your response one way or another).
  - kev009 11y ago
    IMHO If you are doing a product, you should be doing your own RelEng and support. It takes about two engineers for good coverage.
    - kchoudhu 11y ago
      And your internal releng process should be handling security issues as they come up?
      - kev009 11y ago
        That may start to get rough with MFCs as the branch petrifies, but yes it should fall within the same crosschecked two engineer budget for a reasonable time span. You should seek commit bits to maintain said branches if you rely on them, because you're probably not alone.
  - corv 11y ago
    FreeBSD is switching to a 5 year window.
    - kchoudhu 11y ago
      For point releases? Or for ABI compatibility? Edit: Went digging. Here's the link: https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe... It's for ABI compatibility. It certainly adds a certain amount of certainty to the planning process. Right now, I'm running off 11.0-CURRENT in preparation for a deployment or around August 2016, which gives me certainty of support until mid-2021.
      - kev009 11y ago
        Are you doing HW that is frozen in time? I would suggest that many things should be branch rebased roughly every two years unless there are extreme circumstances. I think EMC Isilon has recently realized this as example.

kev009 11y ago

Both.. Facebook advertised "write your own ticket" not so long ago for Linux kernel developers. You are guaranteed to be going up against Google if you want Linux kernel talent that has significant influence. Xref Dan Luu's http://danluu.com/startup-tradeoffs/ http://danluu.com/startup-tradeoffs/ and multiply by 2 to see how much that will cost you. This kind of thing even lures ardent FreeBSD people away, for instance Justin Gibbs, President and Founder of The FreeBSD Foundation currently works at Facebook.. there are many other BSD people stuck in the Borg too. Aside from that, the tight core and stable ABIs and KPIs are much nicer to base things like an appliance off of that may have a long development and longer support lifecycle on. I do some firmware hacking and analysis sometimes for fun, and Linux firmware are always abhorrent in terms of security, quality, license compliance. IBM's disk storage subsystems as one example. I really can't fathom why anyone would base a closed source product on Linux other than wanton incompetence, and I'm not throwing that with tongue in cheek nor lightheartedly.

kchoudhu 11y ago
What are your thoughts on the 2.5 year support windows for "Extended Support" releases? (I have a view here, but I don't want to bias your response one way or another).
- kev009 11y ago
  IMHO If you are doing a product, you should be doing your own RelEng and support. It takes about two engineers for good coverage.
  - kchoudhu 11y ago
    And your internal releng process should be handling security issues as they come up?
    - kev009 11y ago
      That may start to get rough with MFCs as the branch petrifies, but yes it should fall within the same crosschecked two engineer budget for a reasonable time span. You should seek commit bits to maintain said branches if you rely on them, because you're probably not alone.
- corv 11y ago
  FreeBSD is switching to a 5 year window.
  - kchoudhu 11y ago
    For point releases? Or for ABI compatibility? Edit: Went digging. Here's the link: https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe... It's for ABI compatibility. It certainly adds a certain amount of certainty to the planning process. Right now, I'm running off 11.0-CURRENT in preparation for a deployment or around August 2016, which gives me certainty of support until mid-2021.
    - kev009 11y ago
      Are you doing HW that is frozen in time? I would suggest that many things should be branch rebased roughly every two years unless there are extreme circumstances. I think EMC Isilon has recently realized this as example.