5 ms·

Linux is a nightmare in the embedded/appliance space because one ends up just having platform engineers who spend their day fixing problems with the latest kern

Linux is a nightmare in the embedded/appliance space because one ends up just having platform engineers who spend their day fixing problems with the latest kernels, drivers, core libraries, etc, that the actual application depends on. Or one goes the route of 99% of the IoT/etc vendors, and never update the base OS and pray that there aren't any active exploits targeting it. This is why a lot of medium-sized companies cried about Centos, which allowed them to largely stick to a fairly stable platform that was getting security updates without having to actually pay/run a full blown RHEL/etc install. Every ten years or so they had to revisit all the dependencies, but that is a far easier problem than dealing with a year or two update cycle, which is too short when the qualification timeframe for some of these systems is 6+ months long. So, this is almost exclusively a Linux problem; any of the *BSD/etc. alternatives give you almost all of what Linux provides without this constant breakage.

bcantrill 3y ago
This is a really, really good point -- and is a result of the model of Linux being only a kernel (and not system libraries, commands, etc.). It means that any real use of Linux is not merely signing up for kernel maintenance (which itself can be arduous) but also must make decisions around every other aspect of the system (each with its own communities, release management, etc.). This act is the act of creating a distribution -- and it's a huge burden to take on. Both illumos and the BSD derivatives make this significantly easier by simply including much more of the system within their scope: they are not merely kernels, but also system libraries and commands. This weighed heavily in our own calculus, so I'm glad you brought it up!
- trhway 3y ago
  >including much more of the system within their scope: they are not merely kernels, but also system libraries and commands. giving limited resources of the dev team it may lead to limited support of the system outside of the narrow set of officially supported/certified hardware with that support falling behind on modern hardware, as it happened with Sun, and vendor lock-in as a result into overpriced and low performing hardware. There is a reason that back then at Solaris dev there was a joke about embedding Linux kernel as a universal driver for Solaris kernel in order to get reasonable support for the hardware around.
  - mardifoufs 3y ago
    Well they aren't burdened by having to make their own processors, like Sun had to do, or their own full custom chips in general. They just have to support the selection of hardware they pick, and they have complete oversight of what hardware runs on their racks. So I'm not sure if the sun comparison is relevant here, since they can still pick top of the line hardware. Just not any hardware
    - trhway 3y ago
      Any issues with funding or whatever, and their customers would get locked in on the yesterday's "top of the line hardware" (reminds how Oracle used lawyers to force HP to continue support Itanic). Sun was 50K persons company, and they struggled to support even reasonably wide set of hardware. Vendor lock in is like a Newton law in this industry.
  - cross 3y ago
    This is less of an issue for us at Oxide, since we control the hardware (and it is all modern hardware; just a relatively small subset of what exists out there). Part of Sun's issue was that it was tied not just to a software ecosystem, but also to an all-but-proprietary hardware architecture and surrounding platform. Sun eventually tried to move beyond SPARC and SBus/MBus, but they really only succeeded in the latter, not the former.
  - linksnapzz 3y ago
    >that support falling behind on modern hardware, as it happened with Sun, and vendor lock-in as a result into overpriced and low performing hardware. The Oxide hw is using available AMD SKUs for CPU.
GrumpySloth 3y ago
CentOS wasn’t used in embedded systems.
- dralley 3y ago
  Sure it was. So is RHEL. Embedded isn't limited to devices equal or less powerful / expensive than the Raspberry Pi.
- sarlalian 3y ago
  Arista EOS is definitely CentOS Linux release 7.9.2009 (AltArch) based.
- mlindner 3y ago
  Even Windows was and is used substantially in embedded systems.
  - GrumpySloth 3y ago
    I know about that. This is a special edition for embedded though. But CentOS is news to me. CentOS was targeted for servers.
pjmlp 3y ago
Interesting that you bring up embedded/appliance space, as I have noticed there are plenty of FOSS alternatives coming up, key features not being Linux based, and not using GPL derived licenses. FreeRTOS, Nuttx, Zephyr, mbed, Azure RTOS,...

bcantrill 3y ago

This is a really, really good point -- and is a result of the model of Linux being only a kernel (and not system libraries, commands, etc.). It means that any real use of Linux is not merely signing up for kernel maintenance (which itself can be arduous) but also must make decisions around every other aspect of the system (each with its own communities, release management, etc.). This act is the act of creating a distribution -- and it's a huge burden to take on. Both illumos and the BSD derivatives make this significantly easier by simply including much more of the system within their scope: they are not merely kernels, but also system libraries and commands. This weighed heavily in our own calculus, so I'm glad you brought it up!

trhway 3y ago
>including much more of the system within their scope: they are not merely kernels, but also system libraries and commands. giving limited resources of the dev team it may lead to limited support of the system outside of the narrow set of officially supported/certified hardware with that support falling behind on modern hardware, as it happened with Sun, and vendor lock-in as a result into overpriced and low performing hardware. There is a reason that back then at Solaris dev there was a joke about embedding Linux kernel as a universal driver for Solaris kernel in order to get reasonable support for the hardware around.
- mardifoufs 3y ago
  Well they aren't burdened by having to make their own processors, like Sun had to do, or their own full custom chips in general. They just have to support the selection of hardware they pick, and they have complete oversight of what hardware runs on their racks. So I'm not sure if the sun comparison is relevant here, since they can still pick top of the line hardware. Just not any hardware
  - trhway 3y ago
    Any issues with funding or whatever, and their customers would get locked in on the yesterday's "top of the line hardware" (reminds how Oracle used lawyers to force HP to continue support Itanic). Sun was 50K persons company, and they struggled to support even reasonably wide set of hardware. Vendor lock in is like a Newton law in this industry.
- cross 3y ago
  This is less of an issue for us at Oxide, since we control the hardware (and it is all modern hardware; just a relatively small subset of what exists out there). Part of Sun's issue was that it was tied not just to a software ecosystem, but also to an all-but-proprietary hardware architecture and surrounding platform. Sun eventually tried to move beyond SPARC and SBus/MBus, but they really only succeeded in the latter, not the former.
- linksnapzz 3y ago
  >that support falling behind on modern hardware, as it happened with Sun, and vendor lock-in as a result into overpriced and low performing hardware. The Oxide hw is using available AMD SKUs for CPU.

GrumpySloth 3y ago

CentOS wasn’t used in embedded systems.

dralley 3y ago
Sure it was. So is RHEL. Embedded isn't limited to devices equal or less powerful / expensive than the Raspberry Pi.
sarlalian 3y ago
Arista EOS is definitely CentOS Linux release 7.9.2009 (AltArch) based.
mlindner 3y ago
Even Windows was and is used substantially in embedded systems.
- GrumpySloth 3y ago
  I know about that. This is a special edition for embedded though. But CentOS is news to me. CentOS was targeted for servers.

pjmlp 3y ago

Interesting that you bring up embedded/appliance space, as I have noticed there are plenty of FOSS alternatives coming up, key features not being Linux based, and not using GPL derived licenses. FreeRTOS, Nuttx, Zephyr, mbed, Azure RTOS,...