5 ms·

"Some time ago we started a complex, continuous and not always linear operation, that is to migrate, where possible, most of the servers (ours and of our custom

"Some time ago we started a complex, continuous and not always linear operation, that is to migrate, where possible, most of the servers (ours and of our customers) from Linux to FreeBSD." I don't really disagree with any of the stated reasons, but I also didn't see a reason that would make me even consider making the move with our servers, or even bother with some small number of servers. At least for me, I'd need a bunch of REALLY GOOD reasons to consider a move like that. A huge cost savings AND some huge time savings in the future might do it.

johnklos 5y ago
Some people see the bigger picture and recognize that a medium amount of work now is better than lots of small amounts of work stretched over many years. Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed.
- pm90 5y ago
  > Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed. But that's the thing. The pain points mentioned in this article aren't really that strong to need to ditch the OS and move to a new one. These kinds of decisions have huge tradeoffs. One could argue, in fact, that moving to a non-traditional OS will make it much harder to hire experts or hand off the system to another team in the future.
  - djbusby 5y ago
    What? FreeBSD as a non-traditonal OS? I must disagree, FreeBSD may not be as common as Windows or Linux but it's not like Plan9 (from outer space) or BeOS.
  - washadjeffmad 5y ago
    I think of it this way: If you interpret "rolling stones gather no moss" to mean you've always got to keep pushing forward or you'll become obsolete, choose Linux. If you venerate moss as proof of the stability granted by doing the same thing simply and perfectly, you're probably already using FreeBSD. After CentOS Stable was cancelled, I migrated a number of our platforms to FreeBSD because it met our needs and I enjoyed working on it. No surprises, nothing breaking, and most importantly, no drama.
raverbashing 5y ago
I agree. Nothing there seems to deliver explicit customer value when switching to FreeBSD. How will switching help you deliver your service? Or is it just a "nice to have thing"?
- linksnapzz 5y ago
  Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice?
  - lp0_on_fire 5y ago
    Normally the customer doesn't care. They will care, however, if something goes wrong during the migration or some unforeseen issue comes up later that degrades their experience.
  - brimble 5y ago
    It is definitely the case that underlying architecture, certainly all the way down to the OS, can be the difference between "I can create, test, and deploy this feature in a week, and it will be rock-solid" and "it'll take months and still fail on some edge cases—and fixing those is not remotely in our budget".
  - nine_k 5y ago
    I'd hazard to say that it delivers customer value via two avenues: (1) better SLAs, and (2) lower expenses. If your backend OS starts to run software more efficiently, cost less to host, has less maintenance downtime, has fewer security incidents, has fewer crashes, etc, having changed to it has produced customer value.
  - Twirrim 5y ago
    > Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice? Is the service working, is it not? (are there show stopping OS issues?) Are the performance characteristics we need there, or not? Is the service secure or not? There's a whole lot of things right through that entire space where the choice of operating system can make quite a fundamental difference. As a general statement, I wouldn't want to make this kind of a migration without something bordering on a killer feature that wasn't possible otherwise, or some fundamental driver problems (I've replaced Linux with FreeBSD on border devices in the past, due to particular issues with Linux in ways I couldn't afford to have keep biting me)
toast0 5y ago
I agree that the stated reasons don't sound very compelling. Maybe in aggregate, but not individually. But they left out one of the bigger reasons, IMHO. FreeBSD doesn't tend to churn user (admin) facing interfaces. This saves you time, because you still use ifconfig to configure interfaces, and you still use netstat to look at network statistics, etc; so you don't have to learn a new tool to do the same thing but differently every couple of years. Sure, there's three firewalls, but they're the same three firewalls since forever.
- crazy_hombre 5y ago
  ifconfig/netstat was deprecated more than a decade ago, that's more than a couple years don't you think?
  - NoSorryCannot 5y ago
    Since it was just an example, I don't think refuting this particular item will nullify the opinion. The idea, I think, is that there are always more pieces in a state of deprecation and replacement at any given time in Linux land than in FreeBSD land.
    - phkahler 5y ago
      I think that's just due to the pace of development. The BSDs are resource constrained, so they have to pick and choose what to work on. That is both a good thing and a bad thing. Here the benefit is less churn. On the downside, they're just catching the Wayland train recently. On the up side, by catching it late they didn't suffer a lot of the growing pains.
  - comex 5y ago
    Deprecated on Linux. But I for one can’t consign them to the dustbin of my memory, because on my Mac, they are not deprecated, while the `ip` command that replaces them on Linux does not exist. With this part of macOS being derived from FreeBSD, I don’t know whether that makes FreeBSD a savior or a villain. Personally I blame all of the major Unix-derived operating systems (Linux, macOS, BSDs), as none of them show any interest in standardizing any APIs or commands invented this millennium. The subset that’s common to all of them is frozen in time, and is slowly being replaced by new bits that aren’t. From epoll/kqueue to eBPF, containers/jails to seccomp/pledge, DBus/XPC to init systems… from low-level network configuration (ifconfig, ip) to high-level network configuration (whatever that is this month).

johnklos 5y ago

Some people see the bigger picture and recognize that a medium amount of work now is better than lots of small amounts of work stretched over many years. Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed.

pm90 5y ago
> Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed. But that's the thing. The pain points mentioned in this article aren't really that strong to need to ditch the OS and move to a new one. These kinds of decisions have huge tradeoffs. One could argue, in fact, that moving to a non-traditional OS will make it much harder to hire experts or hand off the system to another team in the future.
- djbusby 5y ago
  What? FreeBSD as a non-traditonal OS? I must disagree, FreeBSD may not be as common as Windows or Linux but it's not like Plan9 (from outer space) or BeOS.
- washadjeffmad 5y ago
  I think of it this way: If you interpret "rolling stones gather no moss" to mean you've always got to keep pushing forward or you'll become obsolete, choose Linux. If you venerate moss as proof of the stability granted by doing the same thing simply and perfectly, you're probably already using FreeBSD. After CentOS Stable was cancelled, I migrated a number of our platforms to FreeBSD because it met our needs and I enjoyed working on it. No surprises, nothing breaking, and most importantly, no drama.

raverbashing 5y ago

I agree. Nothing there seems to deliver explicit customer value when switching to FreeBSD. How will switching help you deliver your service? Or is it just a "nice to have thing"?

linksnapzz 5y ago
Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice?
- lp0_on_fire 5y ago
  Normally the customer doesn't care. They will care, however, if something goes wrong during the migration or some unforeseen issue comes up later that degrades their experience.
- brimble 5y ago
  It is definitely the case that underlying architecture, certainly all the way down to the OS, can be the difference between "I can create, test, and deploy this feature in a week, and it will be rock-solid" and "it'll take months and still fail on some edge cases—and fixing those is not remotely in our budget".
- nine_k 5y ago
  I'd hazard to say that it delivers customer value via two avenues: (1) better SLAs, and (2) lower expenses. If your backend OS starts to run software more efficiently, cost less to host, has less maintenance downtime, has fewer security incidents, has fewer crashes, etc, having changed to it has produced customer value.
- Twirrim 5y ago
  > Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice? Is the service working, is it not? (are there show stopping OS issues?) Are the performance characteristics we need there, or not? Is the service secure or not? There's a whole lot of things right through that entire space where the choice of operating system can make quite a fundamental difference. As a general statement, I wouldn't want to make this kind of a migration without something bordering on a killer feature that wasn't possible otherwise, or some fundamental driver problems (I've replaced Linux with FreeBSD on border devices in the past, due to particular issues with Linux in ways I couldn't afford to have keep biting me)

toast0 5y ago

I agree that the stated reasons don't sound very compelling. Maybe in aggregate, but not individually. But they left out one of the bigger reasons, IMHO. FreeBSD doesn't tend to churn user (admin) facing interfaces. This saves you time, because you still use ifconfig to configure interfaces, and you still use netstat to look at network statistics, etc; so you don't have to learn a new tool to do the same thing but differently every couple of years. Sure, there's three firewalls, but they're the same three firewalls since forever.

crazy_hombre 5y ago
ifconfig/netstat was deprecated more than a decade ago, that's more than a couple years don't you think?
- NoSorryCannot 5y ago
  Since it was just an example, I don't think refuting this particular item will nullify the opinion. The idea, I think, is that there are always more pieces in a state of deprecation and replacement at any given time in Linux land than in FreeBSD land.
  - phkahler 5y ago
    I think that's just due to the pace of development. The BSDs are resource constrained, so they have to pick and choose what to work on. That is both a good thing and a bad thing. Here the benefit is less churn. On the downside, they're just catching the Wayland train recently. On the up side, by catching it late they didn't suffer a lot of the growing pains.
- comex 5y ago
  Deprecated on Linux. But I for one can’t consign them to the dustbin of my memory, because on my Mac, they are not deprecated, while the `ip` command that replaces them on Linux does not exist. With this part of macOS being derived from FreeBSD, I don’t know whether that makes FreeBSD a savior or a villain. Personally I blame all of the major Unix-derived operating systems (Linux, macOS, BSDs), as none of them show any interest in standardizing any APIs or commands invented this millennium. The subset that’s common to all of them is frozen in time, and is slowly being replaced by new bits that aren’t. From epoll/kqueue to eBPF, containers/jails to seccomp/pledge, DBus/XPC to init systems… from low-level network configuration (ifconfig, ip) to high-level network configuration (whatever that is this month).