<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 10/26/18 1:08 PM, Gordan Bobic
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMx4oe0SySo8C1Rj6mXtRTgXfDAdKZ=LYQ+d_pk8FZLyCNrq+w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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>
</div>
</blockquote>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Most maintain their own distribution services. They like only
needing the QA step before releasing an update.<br>
<br>
The landscape if varied and full of landmines :)<br>
<br>
The current battle ground is the home controller. Apple, Google,
and Amazon are fighting for dominance and the rest are, perhaps, bit
players.<br>
<br>
<blockquote type="cite"
cite="mid:CAMx4oe0SySo8C1Rj6mXtRTgXfDAdKZ=LYQ+d_pk8FZLyCNrq+w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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.<br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
</body>
</html>