<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 5:58 PM Robert Moskowitz <<a href="mailto:rgm@htt-consult.com">rgm@htt-consult.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 10/26/18 12:19 PM, Fred Gleason wrote:<br>
> Howdy Folks:<br>
><br>
><br>
> All of this to pose the question: is an ‘enterprise’ distro (in the <br>
> specific sense meant here) an appropriate long-term choice for an <br>
> ‘embedded’ project? Given the stated intention of the Upstream <br>
> Provider to support only ARM systems that integrate APCI and comply <br>
> with SBSA  [Server Base System Architecture] standards in future major <br>
> releases (see <br>
> <a href="https://lists.centos.org/pipermail/arm-dev/2017-October/003120.html" rel="noreferrer" target="_blank">https://lists.centos.org/pipermail/arm-dev/2017-October/003120.html</a>), <br>
> is such a distro an appropriate long-term choice for an ‘embedded’ <br>
> project?<br>
<br>
There are a number of issues around embedded systems.<br>
<br>
They have to work for 10 - 20 years.<br>
<br>
They have to be 'safe' for as long as they are working. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At development time, often the most current components are needed (e.g. <br>
openSSL 1.1.1, TLS 1.3)<br>
     This is because, often only patches are done and things still need <br>
to work in 10 years.<br></blockquote><div><br></div><div>Most embedded devices don't get firmware update after a couple of years if they ever get any in the first place. It's a tragic state of affairs, but that's my experience at least.</div><div>Unless there is a major issue that is likely to get somebody outright killed, your chances of getting a firmware update after a few years, expecially after the appliance is no longer manufactured, is very close to 0.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I still deal with embedded systems that are 8bit processors with 32KB <br>
memory/storage.  Those need not apply to this discussion.<br></blockquote><div><br></div><div>I work with guys who write firmware for new devices with such specifications.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have dealt with vendors that say they now charge extra for only 1GB <br>
memory, as their current design is 2GB.  And they call this an IoT board....<br>
<br>
There are many classes of embedded systems.  You look at what is being <br>
embedded in home control gateways, they either are cloud service based <br>
(great for captive customers and monetizing) or self-sufficient for lots <br>
of reasons (privacy for one).<br>
<br>
So I am here, because I believe in enterprise code for these systems.</blockquote><div><br></div><div>What constitutes "embedded" varies depending on who you ask.</div><div>15 yers ago I laughed at a MS developer who programmed "embedded" systems based on XP, which back then to him meant "a device with 'only' 128MB of RAM".</div><div>My modified ancient WRT56GS WiFi router has 64MB of RAM and a 32-bit MIPS processor - a spec for which I would have had to sell most of my vital organs 20 years go to get it in a monster workstation on my desk.</div><div><br></div><div>Unfortunately, as you increase the size and complexity, the probability of problems increases exponentially.</div><div><br></div><div><br></div></div></div>