public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: james <garftd@verizon.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] bzipped manpages
Date: Tue, 17 Jan 2017 09:08:54 -0500	[thread overview]
Message-ID: <1a12720e-e81f-c5d9-8a68-9bf2827dce7a@verizon.net> (raw)
In-Reply-To: <6c4309ca-bdc7-5a1a-b0de-628b5175685e@gentoo.org>

On 01/17/2017 01:05 AM, Daniel Campbell wrote:
> On 01/13/2017 08:06 AM, james wrote:
>> 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
>>
> Whoa, quite a post there! It was a good read. Is this coworker looking
> for any volunteer distro work by any chance? *wink wink* :P



Never. She does not believe in open source donations; strictly 
mercenary. She eats her own young and spits out the bones.....   If you 
have ideas or a business proposal, drop it to me privately.....
in case you have mused "coworker"  with "she". If you have embedded 
needs,  including help and advise, drop me some private email.


I also have a member of my stable that is world class on Rf (anything 
and everything); but is only available for projects (thru me) that are 
in the upmost realm with the most pristine of intentions, as "we" are 
encumbered by stringent standards of purpose..... That is, folks with 
money, guns and lawyers can only drool over this (world class) expert. 
Unlike 'the bitch" he is the kindest person you'd ever meet and can 
teach and show  anything in mathematics (EE stuffage) or how to build 
things. He disassembled old electronics and started building audio amps 
at the age of 6, all on his own, no books no help, but lots of 
fireworks. He still enjoys "smoking" fancy electronics in a variety of 
creative ways whilst capturing and manipulating the wave_forms, just 
like a child in a lab. Savant does not even come close to describing 
this unique individual. He is the "number one EE" wherever he goes, 
putting even "Spock" to shame on knowledge.


My minimal cluster works are becoming "unikernels" and as such there is
quite a lot in common with embedded systems that coalesce into 
morph-able clusters, damn near real-time. They use ethernet or board 
based data busses in a variety of ways. IoT devices are so hacked right 
now, there is a huge need for (gentoo) hardened on embedded 64 bit 
systems, in case you have some useful links. If the devs pull this off, 
hardened-embedded gentoo, and and disseminate that knowledge succinctly, 
then gentoo-embedded will explode inside of secure product development labs.


All of this is very, very expensive expertise, only available to those 
with the deepest pockets and connections focused on  honorable 
intentions. My work, will be shared, as soon as I master the bare-metal
to booted part of the cluster work. It's like automated installs, 
something that gentoo-leadership strives to prevent, over the years.


hth,
James




  reply	other threads:[~2017-01-17 14:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09  8:08 [gentoo-dev] bzipped manpages Jan Stary
2017-01-09  9:30 ` Mike Auty
2017-01-09 21:17   ` Kent Fredric
2017-01-10 11:54   ` Jan Stary
2017-01-10 11:59     ` Jan Stary
2017-01-10 12:04     ` Vadim A. Misbakh-Soloviov
2017-01-10 12:08       ` Jan Stary
2017-01-10 12:19         ` Vadim A. Misbakh-Soloviov
2017-01-10 12:36           ` Jan Stary
2017-01-11 12:34             ` Sven Eden
2017-01-11 16:15               ` Jan Stary
2017-01-13  0:08                 ` Walter Dnes
2017-01-13  7:45                   ` Sven Eden
2017-01-13 16:06                     ` james
2017-01-17  6:05                       ` Daniel Campbell
2017-01-17 14:08                         ` james [this message]
     [not found]                           ` <20170117182639.1d0eed6a.mgorny@gentoo.org>
2017-01-17 19:18                             ` james
2017-01-10 13:01           ` Mart Raudsepp
2017-01-10 13:39             ` Ulrich Mueller
2017-01-10 14:02               ` Mart Raudsepp
2017-01-10 14:21             ` Michał Górny
2017-01-10 14:06     ` Michał Górny
2017-01-17  2:31       ` Kent Fredric
2017-01-11 14:20     ` Michael Orlitzky
2017-01-09 21:49 ` Jeroen Roovers
2017-01-10 12:05   ` Jan Stary
2017-01-14 12:52     ` Kent Fredric
2017-01-10 13:16 ` Fabian Groffen
2017-01-16 17:20   ` Jan Stary
2017-01-17  6:13   ` Daniel Campbell
2017-01-17  8:06     ` Fabian Groffen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a12720e-e81f-c5d9-8a68-9bf2827dce7a@verizon.net \
    --to=garftd@verizon.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox