Re: [gentoo-dev] bzipped manpages

[james]

On 01/13/2017 02:45 AM, Sven Eden wrote:

> Btw.: Even "embedded experts" wholeheartedly agree that they disagree what
> "embedded" actually is. But I do think SoCs actually *do* qualify, at least to
> some degree...


Huh?

Probably who you deem as an expert; they have not clearly defined 
systems types and semantics of an embedded systems. An embedded system 
is one that is 'closed' to pedestrian/consumer/user modifications, 
excepting rooting and other non-normal bypass mechanisms. A modification 
is not the same thing as a configuration. An embedded system is designed 
with limited functionality or "canned product functionality" for 
consumers of very specific task-sets.  Early Micros where often more 
accurately referred to as 'microcontrollers' as their function was 
simply to replace mechanical control systems that were prone to wear and 
failure. When programming occurs (again rooting and hacking do not 
count), it is only allowed by the system designer(s). So a Rasp. Pi on 
the internet, open to dozens or thousands of coders, is not an embedded 
system. At some point it may become an embedded system, but it must be 
locked down, limited in functionality and purged of all that software 
used for development but not needed to run and function as the 
designer(s) intend. Updates are usually in a binary form, again under 
the strict control as designed by the product (embedded systems) developer.


Given that, the reason why so many folks are confused as to what an 
embedded system actually is, is that there are lots of "open" platforms
where users are encouraged to be the designer, thus having architecture, 
coding, and modification access that an ordinary user would not have; 
again, security hacks that grant non-normal access
do not count. That is if you 'hack' into the product or the bios of a 
computer, you have not converted the device's intended usage into a 
embedded system, although you may have low level access to the hardware, 
firmware and other subsystems that the designers did not intentionally 
make available to you. When a computer is 'locked down and limited' like 
a kiosk, it actually is an embedded system.


Traditionally, the easy way to set up product developers was through 
vendors (OEM like Freescale, Samsung, Broadcom, etc) via a  'dev board'. 
Example codes, minimal stack of an rtos or vendor supplied software 
system, along with documentation and details of the in-situ hardware 
that comprise the 'dev board'. Small systems did not have (nor do they 
now) have an 'OS' instead they were simple state-machines or run a 
polling algorithm. Most embedded systems still operate on these sorts of 
codes, even today.


Fast forward, Rasp. Pi et. al are dev boards that can be turned into 
open, multi user systems, say if you make it a typical minimized linux 
system. Some even have inputs for keyboard, mouse and terminal; so that 
sort of system, would not be an embedded system. Now take the same 
board, lock it down so all it does is control the sprinklers in your 
yard, with limited functional interfaces to the 'standard user' and it 
is indeed an 'embedded system'. Most products with a small 
microprocessor are 'embedded systems'. Most Rasp. Pi boards are user 
systems because they are open and unlimited an any given time and are 
not 'locked down'.


It takes a designer, or a team of designers to create an 'embedded 
system', particularly if the embedded system is to be turned into a 
commercial product. The net effect of boards like Rasp. Pi is open up 
the opportunity for folks to learn 'product development'. Most have 
chosen to create  user systems with some functionality not found in 
traditional desktop systems. Surely there are edge cases that blur
the lines of distinction; but most are not a finalized product (embedded 
system) as they are in a constant state of flux related to the interned 
software, thus they are not an 'embedded system'. A properly designed 
embedded system can last in its minimized and limited form for decades 
or more and operated as intended (think digital alarm clock). Others do 
need an update to the firmware (locked down internal software), but that 
is only performed by the product owners or vendors, in the normal case 
of operation. Indeterminant hardware is just hardware; it has to be 
robustly defined, tested and implemented to be a user system, an 
embedded system, or whatever the designer has in mind.


  So hopefully, I have articulated the fact that an 'embedded system' is 
determined by the designer, not the underlying hardware from a vendor.
Robust embedded system design, regardless of VHDL or C or ? codes
are more of an art-form than a technical expose on software development.
I know embedded designers that have created thousands of products  some 
in a matter of weeks, and other teams that fail to produce a single 
robust product, in their entire lifetime.  The most prolific designer of 
them all, is simple referred to as 'doctor bitch' by her subordinates 
and friends. Some, more respectfully refer to her as the queen of 
assembler, as she has fixed thousands of compiler bugs from a myriad of 
compiler vendors, not for compensation, but because the bugs got in her 
way.......



hth,
James