public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: James <wireless@tampabay.rr.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user]  Re: rsync internal mirror configuration
Date: Wed, 13 Jul 2005 16:03:31 +0000 (UTC)	[thread overview]
Message-ID: <loom.20050713T175139-530@post.gmane.org> (raw)
In-Reply-To: 002301c587ba$f2652970$5f01010a@jnetlab.lcl

Dave Nebinger <dnebinger <at> joat.com> writes:



> Yes but we get back to the point that I had been trying to make - the
> embedded devices (even nanobots) would not need to build from source.  I
> know if I had embedded nanobots I would want them focusing on the job they
> were embedded for, not recompiling source from the latest software updates.

> That's the distinction between a source based an binary based distribution.
> Use the source based distro to optimize for hardware then that is the
> template for the binary based distro to the embedded systems.

Well you may be right the majority of the time, but as complex sytems grow
and the number of difference in peripherals, sensors, and other variable
hardrware details, make issuing a single binary for upgrade, problematic.
Just like the kernel on a workstation can be compile specifically for a 
target mix of devices and the applications then are compiled, sometimes
dependant on the kernel/rtos/executive/statemachine details for the binaries that
result. Furthermore, often you are resource constrained on an embedded
micro:timing, interrupts, code space, processor, cache, or ram limits
(just to name a few). It's very common, particulary in the 8/16 bit micro
world to make sifnification changes to the statemachine, just because
the bloating of features has now created performance or code space issues.
Often, Ansi C code is replaced with assembler to compact the executables.

You have a valid point, but, things are more complicated than that. Often
haredware gets replaced or upgraded because the increasing diversity of
the code bloats beyond what the resources can handle. Hareware designers
often screw up the amount of computational resources needed on an embedded
device.  That's way so many Cell phones are thrown away each year, they
cannot properly handle software (rtos and apps) upgrades....

Statistically you are correct. In actuality, a significant and growing protion
of embedded devices lack the ability (resources) to have their software upgraded
or not viable mechanism (like attaching your gameboy to a linux system)
exists to extend the life of the micro based product.....

Think about it. Microsoft and the OS vendors are abandoning  586, p1 and 
p2 machines in droves. Yet linux/BSD et. al. offer extended life to
these aging machines. Embedded devices are only limited by the
forward thinking of their designers.....

Besides what else would I do with my fleeting free time?

James



-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2005-07-13 16:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 18:18 [gentoo-user] rsync internal mirror configuration James
2005-07-11 18:37 ` Dave Nebinger
2005-07-12  2:42   ` [gentoo-user] " James
2005-07-12  6:51     ` A. Khattri
2005-07-12 15:16       ` James
2005-07-12 13:06     ` Dave Nebinger
2005-07-12 15:03       ` James
2005-07-12 15:29         ` Dave Nebinger
2005-07-12 16:03           ` James
2005-07-12 16:36             ` Dave Nebinger
2005-07-12 19:24               ` James
2005-07-12 19:47                 ` Dave Nebinger
2005-07-13 14:35                   ` James
2005-07-13 14:55                     ` Dave Nebinger
2005-07-13 16:03                       ` James [this message]
2005-07-13 14:51                   ` James
2005-07-13 15:12                     ` Dave Nebinger
2005-07-13 16:16                       ` James
2005-07-13 17:54                         ` A. Khattri
2005-07-13 20:35                           ` James
  -- strict thread matches above, loose matches on Subject: below --
2005-07-12 13:09 Dave Nebinger
2005-07-12 15:04 ` James
2005-07-12 15:36   ` Dave Nebinger

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=loom.20050713T175139-530@post.gmane.org \
    --to=wireless@tampabay.rr.com \
    --cc=gentoo-user@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