On Wed, Mar 9, 2011 at 1:53 PM, Tim Niemueller <tim(a)niemueller.de> wrote:
On 09.03.2011 19:33, Martin Langhoff wrote:
> On Wed, Mar 9, 2011 at 1:19 PM, Tim Niemueller <tim(a)niemueller.de> wrote:
>> That still is way to vague. I suggest creating a package per
>> robot/board/platform/sensor/actuator. If there is a canonical software
>
> We are talking about 1 package for a 1-line file. That's very OCD :-)
> One single package simplifies maintenance for this maintainer, reduces
> metadata load on fedora infra, cuts your "yum downloading metadata"
> times.
I know, but one catch-all package is just not the proper way.
Well that's just an unfounded statement.
I have an NXT, a GoGo board, a Pico/Scratch board all on my desk right
now. I'll get my hands on a wedo and arduino kit soon.
They are _extremely_ similar, they are actually are all variations on
a theme; just like printers are. All have 3 to 5 inputs (usually read
as an unsigned int) and 3 to 5 "controller" ports. Some have a cpu you
get to program, plus a tiny bit of RAM. They all cost < USD 100 (or
around $250 in a kit with sensors and motors).
If the API (and CPU/RAM) allows, you can copy some bytecode files to
the device and execute them independently. Otherwise you read the
inputs and write commands to the controller ports.
They are _so_ similar, that we control them all from TurtleArt, or
from Scratch. Their sensors are mostly the same across different
boards.
Is there any problem if we end up with a package with udev rules for
50 similar-ish robots that can be controlled by more than one library?
Why are the bluetooth and printer rpm maintainers not hitting that
problem? File a bug against their packages too ;-)
m
--
martin(a)laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
-
http://wiki.laptop.org/go/User:Martinlanghoff