On 10/26/18 1:08 PM, Gordan Bobic wrote:


On Fri, Oct 26, 2018 at 5:58 PM Robert Moskowitz <rgm@htt-consult.com> wrote:


On 10/26/18 12:19 PM, Fred Gleason wrote:
> Howdy Folks:
>
>
> All of this to pose the question: is an ‘enterprise’ distro (in the
> specific sense meant here) an appropriate long-term choice for an
> ‘embedded’ project? Given the stated intention of the Upstream
> Provider to support only ARM systems that integrate APCI and comply
> with SBSA  [Server Base System Architecture] standards in future major
> releases (see
> https://lists.centos.org/pipermail/arm-dev/2017-October/003120.html),
> is such a distro an appropriate long-term choice for an ‘embedded’
> project?

There are a number of issues around embedded systems.

They have to work for 10 - 20 years.

They have to be 'safe' for as long as they are working. 

At development time, often the most current components are needed (e.g.
openSSL 1.1.1, TLS 1.3)
     This is because, often only patches are done and things still need
to work in 10 years.

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.
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.


I work with people that are mandated by law to perform updates for 10 years.  Some of these systems have been deployed for over 4 years already and are getting their updates as needed via different strategies.

Some of these companies are firmly in the BSD camp of one flavor or another for licensing reasons.  So they say.  Some have thousand to millions of systems deployed or planned.

Many vendors simply love the consumer purchase model as they hope they can just wash their hands of any future problems.  Make fixes available, but not easy.  Hey, it is cheap, go buy a newer model!  Look at the attacks against most of the Internet accessible baby monitors.  I met the researcher that compromised almost a dozen models (when we last talked).

Most maintain their own distribution services.  They like only needing the QA step before releasing an update.

The landscape if varied and full of landmines  :)

The current battle ground is the home controller.  Apple, Google, and Amazon are fighting for dominance and the rest are, perhaps, bit players.



I still deal with embedded systems that are 8bit processors with 32KB
memory/storage.  Those need not apply to this discussion.

I work with guys who write firmware for new devices with such specifications.
 

I have dealt with vendors that say they now charge extra for only 1GB
memory, as their current design is 2GB.  And they call this an IoT board....

There are many classes of embedded systems.  You look at what is being
embedded in home control gateways, they either are cloud service based
(great for captive customers and monetizing) or self-sufficient for lots
of reasons (privacy for one).

So I am here, because I believe in enterprise code for these systems.

What constitutes "embedded" varies depending on who you ask.
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".
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.

Unfortunately, as you increase the size and complexity, the probability of problems increases exponentially.

Why Apple has very limited partners that can add code at the OS level.  I know.  I was at Verizon when we wanted to do this and were told categorically NO.  Android was willing, but without both, the project died.