| 1 |
On 01/17/2017 12:26 PM, Michał Górny wrote: |
| 2 |
> [sent off list to reduce amount of spam] |
| 3 |
> |
| 4 |
> Please cease this off-topic. It has nothing to do with the subject |
| 5 |
> debated. If you want to talk over a beer, then please go to a pub. If |
| 6 |
> you want to compare your pe^w^w^w embedded systems, then please |
| 7 |
> find an appropriate media for that. |
| 8 |
|
| 9 |
Apologies. Agreed. |
| 10 |
|
| 11 |
|
| 12 |
Documents on embedded systems, now that we have a solid definition of |
| 13 |
what an embedded system actually is, is quite important and minimizing |
| 14 |
storage/ram usage of resources whilst accessing those docs is of great |
| 15 |
importance. Expecting a workstation or even a server to have the latest |
| 16 |
mix of documents for the variety of codes and hardware found in a |
| 17 |
heterogeneous cluster, is an unreasonable stretch, and often leads to |
| 18 |
mismatches, imho. Imagine a variety of embedded systems that morph in a |
| 19 |
different cluster matrix, dozens or hundreds of times a day. The |
| 20 |
admins, programmers or users with larger codes may need a deep read on |
| 21 |
the docs sporadically' but in a time-critical manner. They do not want |
| 22 |
or need extraneous or irrelevant docs in the pool. Heterogeneous |
| 23 |
clusters are now all the rage in clusters, particularly, for HPC. |
| 24 |
Current, accurate and minimized docs are keenly important for all |
| 25 |
embedded systems, particularly if they can |
| 26 |
receive codes or binaries dynamically and morph. |
| 27 |
|
| 28 |
|
| 29 |
As embedded systems venues of deployment morph, dynamically, their |
| 30 |
interned documentation should be "auto adjusted" like the system |
| 31 |
software despite being on identical hardware particularly since the |
| 32 |
embedded clusters grow more complex with the latest codes and hi level |
| 33 |
language codes on top of these embedded clusters. That is, in the role |
| 34 |
they (dynamically play) as well in how individual software is used on |
| 35 |
otherwise identical hardware can change rapidly. Lofty goals, yes, but |
| 36 |
since the subject of local documentation on embedded systems came up, |
| 37 |
naturally it is quite reasonable to seek the fastest possible diverse |
| 38 |
usage with the least footprint on resources. |
| 39 |
|
| 40 |
|
| 41 |
hth, |
| 42 |
James |
Archives