How to help?
Emlyn
I think I'll be talking a lot more on this list, but I may be able to
pay my way (irony intended).
Got any coding that needs doing? Or something else?
In answer to Bryan earlier, yes, I'm addressing the list gods. Anyone
is hereby empowered to reply on their behalf :-)
--
Emlyn
http://emlynoregan.com - my home
http://emlyntech.wordpress.com - coding related
http://point7.wordpress.com - downshifting and ranting
Bryan Bishop
> I think I'll be talking a lot more on this list, but I may be able to
> pay my way (irony intended).
Actually, we have housing under control:
http://hexayurt.com/
http://openfarmtech.org/weblog/?p=340
.. okay, not really. Getting there. Can't house you in particular just
yet, but I think that's partly the dream.
> Got any coding that needs doing? Or something else?
Yes :-). Here's the codemonkey todo list:
Also, today I wrote up an email re: recipe representation. In it, I
have some ideas/thoughts about recipe.psl files for inclusion in open
source hardware packagings -- particularly regarding either the use of
URIs or otherwise integrating the PSL spec with other information in
the dot skdb files. Maybe you know more about markup languages and
those types of specs than I do and could shed some light on the
situation?
Otherwise, there's some other software work on that todo list of
course. There's the git repository that you can look into. At the
moment there's a (partial) representation of a screw. I've been
playing around with BRLCAD, and I figure it would be useful to include
the dot g files (what BRLCAD makes) in the dot skdb packagings, either
as a bash shell script to generate a list of commands to tell mged
(the BRLCAD main CGS system) what to do, or just the raw binary output
version. Like, maybe "make a generic screw", and then ways to control
the parameters from the python class instantiation and methods (in the
git repo (see the todo list email)).
There's a lot of other tasks though that have been floating around,
and we haven't really been keeping a community, overall todo list
(i.e., "+1 put a stop to that world hunger thingy") of the comments we
make off-hand in our mailings.
Other stuff here escaping my memory.
Paul D. Fernhout
these days),
http://sourceforge.net/projects/pointrel/
http://www.oscomak.net/wiki/Main_Page
but maybe you could say where your interests/experiences are, either in
manufacturing or programming?
Any particular licenses you prefer? GPL, LGPL, BSD, MIT, CC, GFDL, etc?
I see you do Delphi, C++ and Flash (and Windows audio stuff).
On Delphi, have you tried Lazarus? It's at least cross platform.
(By the way, the top blue text links like "About Me" gave me errors, but the
middle of the page links were OK.) I'd try to tempt you to try Jython, but
if you know Delphi, Lazarus is a great way to be doing entirely open stuff.
http://www.lazarus.freepascal.org/
My wife and I used Delphi to write a lot of code in the past -- I actually
wrote something that does a lot of the heavy lifting of converting Delphi to
Jython. Anyway, just trying to pry you off the Windows platform. :-)
Bryan has a lot going on with SKDB, which is more GNU/Linux-ish. He's more
interactive too, with chat channels and stuff. :-) Also, Bryan seems to have
the most happening group with fenn and others. :-)
If you are getting into Flash, like with your pong game (nice sounds), a
cool games about open manufacturing might be nice. Anything about making
things. I have some ideas, but you might have better ones if you just think
about it yourself first.
Also, any sort of work systematizing content, or just becoming familiar with
existing manufacturing content would be great.
http://en.wikipedia.org/wiki/Manufacturing
Harvesting stuff from the mailing list and organizing it would be useful.
Related to that, making sure everyone who's work you harvested had agreed to
let their text be used under a free license in the recent thread on that.
You mention "downshifting, materialism, and maybe the possibility of finding
an authentic life" -- anything you do to systematize those issues would be
appreciated by lots of people. Or any related simulations you develop. Maybe
you could integrate that with the factor-e farm people?
http://factorefarm.org/
http://openfarmtech.org/weblog/
Or you could systematize voluntary simplicity issues:
http://en.wikipedia.org/wiki/Simple_living
Like make a list of life support needs for a family and list all the
options? Try to quantify them (pounds of different foods, energy use in
kilowatt hours, numbers of socks, etc. :-) Maybe come up with a better way
to organize and present different options and tradeoffs and risks and
priorities related to frugality? Then estimate what things could be made at
home with what effort? Anyway, just some ideas.
This is an educational experience for us all, so just jump in on something
you think might be fun and maybe even useful to you or others. But
freeloaders are OK too. :-) We are all that way in different situations in
life.
--Paul Fernhout
Emlyn
>
> On Tue, Dec 23, 2008 at 10:32 PM, Emlyn <emlyn...@gmail.com> wrote:
>> I think I'll be talking a lot more on this list, but I may be able to
>> pay my way (irony intended).
>
> Actually, we have housing under control:
> http://hexayurt.com/
> http://openfarmtech.org/weblog/?p=340
> .. okay, not really. Getting there. Can't house you in particular just
> yet, but I think that's partly the dream.
It's a great dream.
>
>> Got any coding that needs doing? Or something else?
>
> Yes :-). Here's the codemonkey todo list:
>
> http://groups.google.com/group/openmanufacturing/browse_thread/thread/8465dc23eb48e332/e185e43b59db6b7d?lnk=gst&q=todo#e185e43b59db6b7d
>
> Also, today I wrote up an email re: recipe representation. In it, I
> have some ideas/thoughts about recipe.psl files for inclusion in open
> source hardware packagings -- particularly regarding either the use of
> URIs or otherwise integrating the PSL spec with other information in
> the dot skdb files. Maybe you know more about markup languages and
> those types of specs than I do and could shed some light on the
> situation?
Probably not, but I'll have a look at that email :-)
>
> Otherwise, there's some other software work on that todo list of
> course. There's the git repository that you can look into. At the
> moment there's a (partial) representation of a screw. I've been
> playing around with BRLCAD, and I figure it would be useful to include
> the dot g files (what BRLCAD makes) in the dot skdb packagings, either
> as a bash shell script to generate a list of commands to tell mged
> (the BRLCAD main CGS system) what to do, or just the raw binary output
> version. Like, maybe "make a generic screw", and then ways to control
> the parameters from the python class instantiation and methods (in the
> git repo (see the todo list email)).
I'm in the process of reading what I can find about what you are
doing. It is not clear what you are doing :-)
I have a vague idea of the overall goal (a complex directed-graph type
representation of engineering processes, machine readable, for
purposes of automating the invention of automation and discovering
novel compound processes, plus software to do some of that discovery?
Something like that? Plus automated downloading of chunks of graph,
repo-style?), and I can also see that you have a git repository
(although I haven't looked; I've never used git, I'm an svn person,
but git does look intriguing).
Do you have any kind of planning type doco around the place? For
instance, a spec? Architectural descriptions, diagrams? Or maybe
details of the various sub programs that make up the entire vision,
and what each non-existing piece needs to do?
If not, perhaps I could help in compiling this stuff, to make it a bit
easier for others to see in, and potentially join in, in the future?
> There's a lot of other tasks though that have been floating around,
> and we haven't really been keeping a community, overall todo list
> (i.e., "+1 put a stop to that world hunger thingy") of the comments we
> make off-hand in our mailings.
My main observation here is again that it's very difficult to get any
kind of overview from the outside. I'm happy to help out here, again.
Wiki work? Maybe an issue list in Mantis, something like that?
>
> Other stuff here escaping my memory.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
--
Emlyn
>
> I have some suggestions I could make on stuff I've been doing (mostly Jython
> these days),
> http://sourceforge.net/projects/pointrel/
> http://www.oscomak.net/wiki/Main_Page
> but maybe you could say where your interests/experiences are, either in
> manufacturing or programming?
Coding. IANAE (Engineer). I'm a comp sci guy, withered into a golem
like creature through years of commercial windows platform
development.
> Any particular licenses you prefer? GPL, LGPL, BSD, MIT, CC, GFDL, etc?
Any or all, whatever's compatible with what others are doing.
In my c# open source bits and pieces I tend to use MIT (iirc), so I
can use it in paid work without freaking people out. But some bits are
GPL, too; I have more and more sympathy for GPL. Bugger the closed
source world, it can reinvent the wheel, that's what it's good at
(well, it's what it does often and with great mediocrity :-) ).
>
> I see you do Delphi, C++ and Flash (and Windows audio stuff).
And C#! A beautiful language, from out of the belly of the beast! So sad.
> On Delphi, have you tried Lazarus? It's at least cross platform.
> (By the way, the top blue text links like "About Me" gave me errors, but the
> middle of the page links were OK.) I'd try to tempt you to try Jython, but
> if you know Delphi, Lazarus is a great way to be doing entirely open stuff.
> http://www.lazarus.freepascal.org/
> My wife and I used Delphi to write a lot of code in the past -- I actually
> wrote something that does a lot of the heavy lifting of converting Delphi to
> Jython. Anyway, just trying to pry you off the Windows platform. :-)
I'm trying to pry myself off the Windows platform, don't worry! From a
user point of view, I scrubbed Vista off my laptop (my main machine,
the other half of my mind) with a Vista stick about a month and a half
ago, and put Ubuntu on; an awakening. I'll never go back. I still
develop under windows for work on this machine, using VMWare.
I haven't jumped into development on Linux yet, but I need to. I'll
need to flooze around a bit, language-wise, and see what's hot and
what's not.
I see my choices grouped something like this:
- c/c++: Rusty, but I can bring these back up to scratch. Really, if
you're doing stuff that doesn't need to be close to the machine, these
are truly horrible languages (sorry for any offense in advance). But,
the global code conversation is largely happening in them, due to the
culture of Unix (and I think another surprising factor on which I'll
post separately; it should be recognised that the vast new work being
done in such unproductive languages presents a quandary, on the face
of it, it doesn't make sense for volunteers to waste time like that!).
So anyway, I do need to get back on top of C++ in particular.
- Dynamically typed "scripting" languages: I tried Perl a while back,
and still feel a bit dirty. However, Python looks decent at first
glance, and looks to have the benefit of being one of the few cross
platform choices, people are even building cross platform desktop apps
in it (eg: Miro). I take it that you like Python, being a Jython fan.
Why Jython rather than Java, btw?
- Statically typed high level OO Languages: That is, Java (that's
about it in the open source world, no?) Java is a short leap for a c#
monkey, but seems to be terribly out of fashion. Why do people hate
the statically strongly typed languages so much? I can't imagine
building something big without one. Probably this is a failure of my
imagination, but I'd like to know why.
- Functional languages: I only ever studied these at uni, I've never
used one in anger, but people are making intriguing noises about them
now that massively multi-core processors are on the horizon.
Certainly, traditional concurrent programming (ie:
thread/process/mutex/semaphore wrangling, what I spend a lot of my
paid life doing) is a big fail for mainstream software development.
Too hard, far too error prone. Functional languages, anyway,
beautiful, I'm intrigued at the possibilities of them wandering into a
practical toolkit.
Python (and Jython!) is what I'm leaning toward at the moment.
Have you guys looked at the mono project, btw? C# can be free too.
Culturally incompatible though unfortunately.
>
> Bryan has a lot going on with SKDB, which is more GNU/Linux-ish. He's more
> interactive too, with chat channels and stuff. :-) Also, Bryan seems to have
> the most happening group with fenn and others. :-)
>
> If you are getting into Flash, like with your pong game (nice sounds), a
> cool games about open manufacturing might be nice. Anything about making
> things. I have some ideas, but you might have better ones if you just think
> about it yourself first.
Well, Flash was an interesting diversion. Did you see my solar system
thing? I made the mistake of embarking on a concept for an environment
without an idea for a game; I couldn't easily retrofit one (and to be
honest I lost interest).
I was writing in actionscript 3. Bad language. Bad bad. That's
probably the main reason I lost interest.
> Also, any sort of work systematizing content, or just becoming familiar with
> existing manufacturing content would be great.
> http://en.wikipedia.org/wiki/Manufacturing
No engineering background, so probably not best for me.
> Harvesting stuff from the mailing list and organizing it would be useful.
> Related to that, making sure everyone who's work you harvested had agreed to
> let their text be used under a free license in the recent thread on that.
Now that's something I'm interested in (similar to my suggestions to
Bryan). This list is a goldmine of amazing stuff, carefully hidden
amongst the disorganisation of an email list. A lot of it is way too
good to be so obscured.
> You mention "downshifting, materialism, and maybe the possibility of finding
> an authentic life" -- anything you do to systematize those issues would be
> appreciated by lots of people.
Not really my strength
> Or any related simulations you develop. Maybe
> you could integrate that with the factor-e farm people?
> http://factorefarm.org/
> http://openfarmtech.org/weblog/
> Or you could systematize voluntary simplicity issues:
> http://en.wikipedia.org/wiki/Simple_living
> Like make a list of life support needs for a family and list all the
> options? Try to quantify them (pounds of different foods, energy use in
> kilowatt hours, numbers of socks, etc. :-) Maybe come up with a better way
> to organize and present different options and tradeoffs and risks and
> priorities related to frugality? Then estimate what things could be made at
> home with what effort? Anyway, just some ideas.
This whole area I am interested in, but through the lens of
post-scarcity. The thinking on this list needs to come together in a
more systematic fashion some time in the near future; along the lines
of "we are at A, the goal is B. Define A. Define B. Lots of gap
analysis and ideas for bridging the gap".
>
> This is an educational experience for us all, so just jump in on something
> you think might be fun and maybe even useful to you or others. But
> freeloaders are OK too. :-) We are all that way in different situations in
> life.
>
> --Paul Fernhout
We are all freeloaders no matter how much we contribute; we have an
asymetrical relationship to the domain of freed knowledge, because of
its vastness and our non-vastness. It's important to figure out how to
feel ok about that :-)
Paul D. Fernhout
> Why Jython rather than Java, btw?
>
> - Statically typed high level OO Languages: That is, Java (that's
> about it in the open source world, no?) Java is a short leap for a c#
> monkey, but seems to be terribly out of fashion. Why do people hate
> the statically strongly typed languages so much? I can't imagine
> building something big without one. Probably this is a failure of my
> imagination, but I'd like to know why.
Think of Java as like assembly language for the Java Virtual Machine (I know
there is a lower level, but in practice Java is the assembler).
Then, think of the JVM as a free-as-is-speech-finally platform that happens
to run on other platforms (Mac, Windows, GNU/Linux).
Then think -- you can run any of hundreds of languages on that platform
(like the mono/dot-net idea, too, but with less patent mine field worries):
http://user.cs.tu-berlin.de/~tolk/vmlanguages.html
"The following is a list of programming languages for the Java virtual
machine aside of Java itself. "
Some functional ones in there -- Scala is tempting and I've tried it. Scala
is in a way a better Java.
Anyway, that's how I see it.
So, for why Jython -- it lets me work in a dynamically typed language while
still being able to access all the compiled libraries written in Java.
There are several things I do not like about Jython/Python, but the value in
the leverage is really high.
An alternative I pine for is Smalltalk, and I'm sad Squeak has had so many
difficulties. I'm always tempted by it though. Or writing such a system for
the JVM. But Jython gets me a lot of the benefits, so it would be hard to
make that investment.
> Have you guys looked at the mono project, btw? C# can be free too.
> Culturally incompatible though unfortunately.
I worry about software patents there.
> Well, Flash was an interesting diversion. Did you see my solar system
> thing? I made the mistake of embarking on a concept for an environment
> without an idea for a game; I couldn't easily retrofit one (and to be
> honest I lost interest).
No, is there a link?
Al Globus suggested to me a game idea where kids would start out in the
solar system and get resources and use them to keep spacepeople alive. Maybe
you could adapt your system somehow? Just a thought, that would be a lot of
work, but is essentially, at least for me, a long term goal. And you could
make it cooperative too, so two or more players could play together.
> I was writing in actionscript 3. Bad language. Bad bad. That's
> probably the main reason I lost interest.
I'd be curious to see how JavaFX progresses, and if I can put Jython stuff
on it. Evaluating JavaFX as a platform and a community and assessing its
momentum could be useful.
>> Also, any sort of work systematizing content, or just becoming familiar with
>> existing manufacturing content would be great.
>> http://en.wikipedia.org/wiki/Manufacturing
>
> No engineering background, so probably not best for me.
It's never too late to start. 10000 hours is all it takes. That's seven
years of a couple hours a day. :-)
"It Takes 10,000 Hours of Practice to Become a Genius"
http://www.infoniac.com/science/it-takes-10,000-hours-of-practice-to-become-a-genius.html
""It seems it takes the brain this long to assimilate all it needs to know
to achieve true mastery," explained neurologist Daniel Levitin to Focus, a
BBC science magazine, which published The Story of Success. "
Seriously though, even just a hundred hours spent engaged with that sort of
content in some way might start to give you ideas for programs.
>> Harvesting stuff from the mailing list and organizing it would be useful.
>> Related to that, making sure everyone who's work you harvested had agreed to
>> let their text be used under a free license in the recent thread on that.
>
> Now that's something I'm interested in (similar to my suggestions to
> Bryan). This list is a goldmine of amazing stuff, carefully hidden
> amongst the disorganisation of an email list. A lot of it is way too
> good to be so obscured.
Yes, we practice encryption through chaffing here. :-)
http://people.csail.mit.edu/rivest/Chaffing.txt
http://people.csail.mit.edu/rivest/chaffing-980701.txt
You could think of yourself as a decryption algorithm. :-)
> This whole area I am interested in, but through the lens of
> post-scarcity. The thinking on this list needs to come together in a
> more systematic fashion some time in the near future; along the lines
> of "we are at A, the goal is B. Define A. Define B. Lots of gap
> analysis and ideas for bridging the gap".
I think we will get there, but it's "herding cats" (and by whom?) and I
don't think there will ever be just one approach. I like the idea of
"stigmergy" which is cooperation through building on each other's artifacts
(in this context, freely licensed code and data). The cooperation happens in
an indirect fashion. That is not to argue against direct cooperation, just
to supply an alternative paradigm.
http://en.wikipedia.org/wiki/Stigmergy
That's why I feel free licenses are so important (even for this list
content), so people can pick things up and go with them without needing to
ask for permission.
> We are all freeloaders no matter how much we contribute; we have an
> asymetrical relationship to the domain of freed knowledge, because of
> its vastness and our non-vastness. It's important to figure out how to
> feel ok about that :-)
Yes. We can all learn to be thankful.
"An Iroquois Prayer for Thanksgiving"
http://awrungsponge.blogspot.com/2006/11/iroquois-prayer-for-thanksgiving.html
"""
We return thanks to our mother, the earth, which sustains us.
We return thanks to the rivers and streams,
which supply us with water.
We return thanks to all herbs,
which furnish medicines for the cure of our diseases.
We return thanks to the corn,
and to her sisters, the beans and squash,
which give us life.
We return thanks to the bushes and trees,
which provide us with fruit.
We return thanks to the wind,
which, moving the air,
has banished diseases.
We return thanks to the moon and the stars,
which have given us their light
when the sun was gone.
We return thanks to our grandfather He-no,
who has given to us his rain.
We return thanks to the sun,
that he has looked upon the earth
with a beneficent eye.
Lastly, we return thanks to the Great Spirit,
in whom is embodied all goodness,
and who directs all things
for the good of his children.
"""
So, that's another asymmetrical thing -- the wonderful planet and universe
that supports us. And what did we pay or return for all that?
But here is a different perspective:
http://www.organicconsumers.org/bytes/112603.cfm
"Don't ask yourself what the world needs - ask yourself what makes you
come alive, and then go do it. Because what the world needs is people who
have come alive." -- Harold Thurman Whitman
--Paul Fernhout
Bryan Bishop
> 2008/12/24 Bryan Bishop:
>> Otherwise, there's some other software work on that todo list of
>> course. There's the git repository that you can look into. At the
>> moment there's a (partial) representation of a screw. I've been
>> playing around with BRLCAD, and I figure it would be useful to include
>> the dot g files (what BRLCAD makes) in the dot skdb packagings, either
>> as a bash shell script to generate a list of commands to tell mged
>> (the BRLCAD main CGS system) what to do, or just the raw binary output
>> version. Like, maybe "make a generic screw", and then ways to control
>> the parameters from the python class instantiation and methods (in the
>> git repo (see the todo list email)).
>
> I'm in the process of reading what I can find about what you are
> doing. It is not clear what you are doing :-)
I'll let Eric do the talking for me first:
http://heybryan.org/manufacturing_ecology.html
"With the Open Source Everything project idea I was thinking not just
about cultivating and disseminating Open Source knowledge to make end
products but also about the evolution of standardized semantic and
visual systems for representing their 'recipes' as I tend to call them
because you need more than just 'plans' to explain how to make things.
You have to represent a fabrication process, not just an end-form. And
you need to standardize to make the information portable, modular, and
reconfigurable across networks, across languages, etc. Making that
work would take experimentation and evolution, hence another reason
for employing a group project. I've often been critical of the sorts
of silly things the Make and Instructables blog participants seem to
focus on. I keep thinking; "What's with these people and their toys?
Where's the open source car? The open source hand-tractor? The
refrigerator? Wind turbine? Compact gas turbogenerator? Water
purifier? Things that would really shake-up this world if they were
open source." But I've also come to realize there's more going on with
these blogs than just people sharing instructions for making toys. The
real 'craft' of these blogs isn't in the stuff people are making. It's
in the language they are cultivating to communicate the instructions
for making things. You could be able to make Faberge eggs but your
social status on these blogs is based not on how impressive your
personal end-results but on your ability to communicate techniques in
a way that is effective and entertaining. So it's really the evolution
of another kind of literature going on here -a sophisticated mixed-
media literature for fabrication knowledge. Right now it's a pretty
messy, fast, and loose system but I'm noticing some consistent
structure emerging as people interact with each other's recipes and
refine them. This is the latest branch of evolution in DIY literature
and it is adapting old schemes from that to new media with some
interesting results."
One of the ongoing themes from my end on this mailing list is the
standardized, systematic packaging of open source hardware projects
into a standardized format, conceptually mirroring that of dot deb,
rpm, and others-- see yum, yast, apt, etc. One of the enduring themes
is that of 'dependencies'. You need some industrial ecology going on
to get to the point of manufacturing advanced microprocessor devices
[I'm not mentioning some simpler alternatives to silicon-based
microprocessors here though. Illustrating a point.] And what
industrial ecology is that? As you start making a "bill of materials"
and a "bill of technologies", you see that one technology relies upon
another, and so on. Kevin Kelly (and everyone else) has mentioned
this--
http://www.kk.org/thetechnium/archives/2007/03/bootstrapping_t.php
"Let's take a very sophisticated item: one web page. A web page relies
on perhaps a hundred thousand other inventions, all needed for its
birth and continued existence. There is no web page anywhere without
the inventions of HTML code, without computer programming, without
LEDs or cathode ray tubes, without solid state computer chips, without
telephone lines, without long-distance signal repeaters, without
electrical generators, without high-speed turbines, without stainless
steel, iron smelters, and control of fire. None of these concrete
inventions would exist without the elemental inventions of writing, of
an alphabet, of hypertext links, of indexes, catalogs, archives,
libraries and the scientific method itself. To recapitulate a web page
you have to re-create all these other functions. You might as well
remake modern society."
((I recently linked to this same article in another email:
http://groups.google.com/group/openmanufacturing/browse_thread/thread/4a6f612fb2d9069a/6711e131807fb152?lnk=gst&q=gingery#6711e131807fb152
))
Also in kk's article:
"I've been thinking of civilization (the technium) as a life form, as
a self-replicating structure. I began to wonder what is the smallest
seed into which you could reduce the "genes" of civilization, and have
it unfold again, sufficient that it could also make another seed
again. That is, what is the smallest seed of the technium that is
viable? It must be a seed able to grow to reproduction age and express
itself as a full-fledge civilization and have offspring itself --
another replicating seed.
This seed would most likely be a library full of knowledge and perhaps
tools. Many libraries now contain a lot of what we know about our
culture and technology, and even a little bit of how to recreate it,
but this library would have to accurately capture all the essential
knowledge of cultural self-reproduction. It is important to realize
that this seed library is not the universal library of everything we
know. Rather, it is a kernel that contains that which cannot be
replicated and that which when expanded can recover what we know."
re: self-replication, see also quotes from AASM and KSRM:
http://groups.google.com/group/openmanufacturing/msg/4ff7a92e2425dde2
Self-replication is a big topic around here. Some dependency chain
analysis tools can be written once we get more than one or two open
source hardware projects packaged. The idea of space-habitats, like
found in Orion's Arm, or in the other lessly collaborative scifi
literature that Paul can probably more readily reference, plays a big
role here as inspiration and common ground, but is not necessary for
an understanding of what's going on (but I'm sure you're interested).
OSCOMAK: "The project's ultimate long-term goal will be to generate a
repository of knowledge that will support the design and creation of
space habitats. Three forces -- individual creativity, social
collaboration, and technological tools -- will join to create a
synergistic effort stronger than any of these forces could produce
alone."
Getting back down to earth: the short term work that I've been kicking
around here is the basic packaging of open source hardware projects.
At the moment we have (partially) packaged a screw. Other things to
package include basic mechanisms like fasteners, joints, springs,
bearings, gears, shafts, clutches, breaks, couplings, belts, ropes,
chains, and then some of the pre-existing open source hardware
projects like MechMate (which isn't really open source), Gingery
stuff, OpenMoko, Arduino, OpenCores, and in fact, anything listed
here:
http://p2pfoundation.net/Product_Hacking
"""
E-Risc: a scaleable RISC microprocessor for embedded applications
Gumstix: the world's smallest full function, open source computers.
Open SPARC [4] is a project with an already created UltraSPARC T1
multicore chip by Sun Microsystems. As of August 2007 a T2 chip is
also in the pipeline Sun's OpenSPARC
OpenRISC is a group of developers working to produce a very high
performance open source RISC CPU.
LEON is an open source 32-bit SPARC-like CPU created by the ESA. It's
the standard CPU for the European Space Industry.
Coreboot [5], aimed at replacing the proprietary BIOS (firmware)
F-CPU, Freedom CPU project initiated in mid-1998.
Arduino is an open-source physical computing platform based on a
simple I/O board and a development environment that implements the
open source Processing / Wiring language.
Arduino Nano is a small 16MHz embedded micro controller
SquidBee - Open Mote based in Arduino for developing sensor networks.
"Open Hardware and Source wireless sensor device. The goal of SquidBee
is getting an "open mote" to create Sensor Networks"
OpenBook - tablet design, positioning between $100 laptop and consumer
Tablet PC´s price, which wants allow tablet usage to masses by high
volume production.
BalloonBoard.org produces open arm-based development boards, aimed at
OEMs and further education.
PLAICE - an open source hardware and software project developing a
powerful in-circuit development tool that combines in one device the
features of a FLASH Programmer, Memory Emulator, and High Speed
Multi-Channel Logic Analyzer. It runs uClinux.
OpenPCD - Open RFID reader/writer project, using AT91SAM7S128 microcontroller.
ASoC (ALSA System on Chip).
Free Telephony Project, Astfin provides free reference designs for
embedded telephony. s,h
IP04 Four Port IP-PBX: Open Hardware Four Port IP-PBX
IP08 Eight Port IP-PBX: Similar to IP04 with 8 ports. Will be produced
by Atcom.
Maemo: Open source software development kit for mobile internet
devices. Founded and maintained by Nokia for there N770, N800, N810
internet tablets.
Open Handset Alliance
Opencellphone.org - an RFID-enabled Open Cellphone project, also
called 'TuxPhone'
Open Moko - open phone framework (first use case: FIC neo1973,
expected in Q4, 2007), see Open Mobile Telephony
Ucasterisk, free hardware designs for telephone systems. Both the
hardware and software are open.
Chumby, a powerful little device with Wi-Fi, a 3.5-inch screen and an
interface that you can customize s
Elphel, cameras and imaging solutionss,h
gEDA - full GPL'd suite of Electronic Design Automation tools.
iLiad: electronic handheld device which can be used for document
reading and editing.
Jaldi Battery Charger s,h
Neuros Technology and its OSD Open Source Device
Open Beacon: a free design for an active RFID device
Open Bios, Open Firmware implementations
Open FM
Open GPS Tracker
Open Micromanufacturing and Nanomanufacturing Equipment
Open PCD: a free hardware design for Proximity Coupling Devices or
Open RFID Reader
Open-rTMS - creating a low cost rTMS device and free software to go with it.
OKVM Project, open source console and KVM management software / open
source KVM hardware.
Roku Netflix Player [12]
Ronja by Twibright Labs, optical point-to-point data link device
Ybox, an internet connected set-top box
"""
(links available in the p2pfoundation link)
Some of those are software tools rather than hardware that would be
packaged, but I still find it related. For instance, gEDA certainly
plays a prominent role because it's GNU electronic design automation
that basically puts the mechanical engineers to shame. ;-) Also,
machine shop tools, anything in the fablabs, etc. All of it.
~ At about this point in writing this email, I got distracted reading
an Ian Jackson interview:
http://web.archive.org/web/20061017190133/http://www.debianplanet.org/node.php?id=735
"When I first joined the project, dpkg was a very evil shell script
that was little moroe than a placeholder. I wrote dpkg v2, a Perl
script, because it was the thing that needed writing next." "Around
the introduction of the C version, the format was changed from the old
`two lines of text and two gzipped tarfiles'." "Also, Debian has too
many developers and not enough really good developers. Many of
Debian's current decision processes work on a kind of inertia basis:
it's really hard to get anything to happen (become a maintainer, fix a
process problem, get a recalcitrant maintainer to fix a bug, ...) and
the way we prevent bad things happening is by just making it too much
hard work to do anything serious at all."
http://slashdot.org/comments.pl?sid=35937&cid=3879354
Anyway, back on topic.
> I have a vague idea of the overall goal (a complex directed-graph type
> representation of engineering processes, machine readable, for
> purposes of automating the invention of automation and discovering
> novel compound processes, plus software to do some of that discovery?
> Something like that? Plus automated downloading of chunks of graph,
> repo-style?), and I can also see that you have a git repository
> (although I haven't looked; I've never used git, I'm an svn person,
> but git does look intriguing).
Yes, more or less. But not so much on the discovery side of things. It
would be nice and interesting if machines one day start inputting data
that they are able to get from the literature or the world through
novel experimentation, symbolic regression, maybe doing what EXPO
(ontology for scientific experiments) and its robots are doing; but
that's by no means fundamental or integral to the functioning of the
overall system. The data is going to come from package maintainers--
hopefully taking submissions and helping non-package-maintainers
package their stuffs into the reusable standardized format.
> Do you have any kind of planning type doco around the place? For
> instance, a spec? Architectural descriptions, diagrams? Or maybe
> details of the various sub programs that make up the entire vision,
> and what each non-existing piece needs to do?
Sort of. Old content here (including diagram :-)):
http://heybryan.org/mediawiki/index.php/Skdb
Though the emails on this list would be more informative. Here's some
information on architecture (sort of):
http://groups.google.com/group/openmanufacturing/browse_thread/thread/3f991441a6860b51/e7aa2f93e40ec8d6?lnk=gst&q=Sepehr#e7aa2f93e40ec8d6
(What follows is an excerpt from that page, it's mostly just
ramblings, so it's ignorable I guess.)
=========================================
stuff for userspace
autospec - validates the units for the packages, validates the yaml,
gets additional python plugins if necessary when the yaml specifies
some weird class that is not yet installed.
Are the 'python plugins' (that specify additional classes) to be
provided in package (.skdb) files? tentatively: yes. Then why wouldn't
this be specified in the metadata for the skdb file as a 'dependency'?
agx-get - gets packages from the database, gets all metadata (local
user cache in ~/.skdb/mimedb/ or something), allows the user to search
for packages, uses a sources.list type file to connect to skdb or
other metarepo installations, torrent functionality would be nice, and
must be able to process the metadata files and give the user options
to download particular parts (or everything) related to a .skdb file
-- this will typically involve downloading a new skdb package in the
first place in order to understand the skdb file in its entirety (for
example, different types of packages will most likely have different
types of metadata specified, different types of resources, with data
worth parsing on the user-end for options related to seeking out the
package-contents).
disambiguator - lets user specify what sort of file formats need to be
processed, what the input/outputs have to be, and finds puzzle pieces
that match these specs
agx-sim - the simulator
Packages (.skdb) would describe how they are to be simulated, if at
all. I am sure somebody would like to come up with a standardized
simulation interface. There are a few problems (computationally) that
have to be addressed, like whether or not it should be a binary sort
comparison, n!, or something else. Hard to tell, but the important
aspect is that the architecture allows for this sort of thing.
agx-make - considering fablab facilities (/dev stuff), configuration,
layout, orientations, inventory, number of humans available, etc.,
generate an overall recipe for the entire lab to execute and make the
product ('go command' should be avoidable via passing a parameter)
Generating the programming for the machinery will be somewhat
high-level: this would not be an immediate compiling down to "turn the
servo" sort of code, but rather something that each of the machines
with their pre-installed firmware can understand.
Generating the programming in the first place: run through each of the
(.skdb) files in the overall design (itself a .skdb), load up the
modules geared towards interpreting these variations on (.skdb) (i.e.,
some have particular data formats that can only be parsed in certain
ways), assemble a list of all code (within the packages) that is to be
called/evaluated. The code within each of the packages should 'call a
standard API' to make things happen. This API will abstract the
actual, physical hardware away from the (.skdb) python scripts so that
a variety of configurations can be used without having to go in by
hand and making hundreds of versions of (.skdb) internal python
scripts.
standard-API: all (.skdb) scripts will know how to call specific
functions and actions of the machinery, and then the 'print server'
will figure out the relationship between those functions and the
actual drivers and /dev/ while also providing garbage collecting (so
that wires aren't tripped over and so on).
Alternative to the standard-API idea: what if the python scripts in
(.skdb) files printed out code, and this code could then be compiled
for the specific fablab config that the user has?
Note: whether or not a bug report is from agx-sim, agx-make, or
autospec is irrelevant; all of this data should be fed back into skdb.
Especially user-reports, bug reports, usecases, feedback, etc.
=========================================
The todo list that I've recently been focusing on: XMLized PSL
compliance with RDF URIs pointing to local files which would serve as
parameters to other packages in the database (such as parameters to
the CNC machine, which would be gcode; the cnc machine module should
have an instruction python module/class that would translate the gcode
to human readable text). Argh, I keep forgetting that gcode isn't the
best example here since a direct translation is a useless thing to
have .. a better thing would be origami folding, but we don't have a
folding machine :-). So maybe another example would be a printer.
IIRC, older printers accepted direct ASCII dumps from LTP. So there
you go: a shared format: both people and the printer know how to
read/write the ASCII charset (hehe). (I'm cheating with this example,
I know. A better one would be a 3D laser printer - STL can be visually
displayed, and also translated into movements for the lasering
process).
But there are other things on the list that are worth attention of
course. I just figure recipes and instructions are an important thing
to get up and running as soon as possible, so I've been wrestling
around with that (it's my awkward way of going about programming I
guess).
> If not, perhaps I could help in compiling this stuff, to make it a bit
> easier for others to see in, and potentially join in, in the future?
That would be appreciated too.
>> There's a lot of other tasks though that have been floating around,
>> and we haven't really been keeping a community, overall todo list
>> (i.e., "+1 put a stop to that world hunger thingy") of the comments we
>> make off-hand in our mailings.
>
> My main observation here is again that it's very difficult to get any
> kind of overview from the outside. I'm happy to help out here, again.
> Wiki work? Maybe an issue list in Mantis, something like that?
An issue tracker would be awesome. Any particular reason for Mantis?
What about bugzilla, trac, etc.?
http://ifdefined.com/blog/post/2007/10/Links-to-other-comparisons-of-issue-trackers.aspx
Emlyn
>
> On Wed, Dec 24, 2008 at 3:07 AM, Emlyn wrote:
>> 2008/12/24 Bryan Bishop:
>>> Otherwise, there's some other software work on that todo list of
>>> course. There's the git repository that you can look into. At the
>>> moment there's a (partial) representation of a screw. I've been
>>> playing around with BRLCAD, and I figure it would be useful to include
>>> the dot g files (what BRLCAD makes) in the dot skdb packagings, either
>>> as a bash shell script to generate a list of commands to tell mged
>>> (the BRLCAD main CGS system) what to do, or just the raw binary output
>>> version. Like, maybe "make a generic screw", and then ways to control
>>> the parameters from the python class instantiation and methods (in the
>>> git repo (see the todo list email)).
>>
>> I'm in the process of reading what I can find about what you are
>> doing. It is not clear what you are doing :-)
>
>> I have a vague idea of the overall goal (a complex directed-graph type
>> representation of engineering processes, machine readable, for
>> purposes of automating the invention of automation and discovering
>> novel compound processes, plus software to do some of that discovery?
>> Something like that? Plus automated downloading of chunks of graph,
>> repo-style?), and I can also see that you have a git repository
>> (although I haven't looked; I've never used git, I'm an svn person,
>> but git does look intriguing).
>
> Yes, more or less. But not so much on the discovery side of things. It
> would be nice and interesting if machines one day start inputting data
> that they are able to get from the literature or the world through
> novel experimentation, symbolic regression, maybe doing what EXPO
> (ontology for scientific experiments) and its robots are doing; but
> that's by no means fundamental or integral to the functioning of the
> overall system. The data is going to come from package maintainers--
> hopefully taking submissions and helping non-package-maintainers
> package their stuffs into the reusable standardized format.
>
Righto. Here are some thoughts, tell me to pull my head in if I've
overstepped the mark.
You're rummaging around in a very large design space, huge. It's a
testament to your abilities that you haven't completely lost
motivation already; I'd be floundering (and am, in fact :-) ).
I think I can see where you want to go with this whole thing, more or
less. It's a pretty serious project. Big danger of burning out under
the sheer weight of multiplying unknowns. In your place, to make sure
I didn't lose my momentum, I'd be looking at narrowing things down a
bit.
I like to use a three part model when thinking about how to accomplish
something real, which is "version 0.1, version 1.0, version 10.0".
version 0.1: What the smallest possible useful thing that you can hack
together in minimum time to demonstrate your idea, and communicate the
vision to others? A stone for your stone soup.
version 1.0: What's the first minimal real thing going to look like,
feature-wise, architecturally, etc?
version 10.0: When it's been around for 5 to 10 years and has matured,
what will it look like? ie: what's the ultimate vision?
When you are listing what you want your project to do, put each
feature/idea/point against one of these three. And then, when you are
ready, you can start on 0.1 .
My thought on a 0.1: What seems most important atm is
1. Get a minimal format sorted out (even if it is missing stuff, you
can expand it later).
2. Start encoding stuff in the format.
This seems to be along the lines of what you are doing. But there also
needs to be something else, some usable 0.1 thing that is more than a
collection of data files.
I would suggest that some GUI based client tools for working with
these files would be the thing. Specifically, a website into which
people could add designs, and see other people's designs (and use them
as dependencies, make variations, etc etc) might be good. Although,
that's not really quite the philosophy here; you've got a more codey
thing going, caches of stuff on developer's machines, tied together
with a packaging system, so maybe a desktop tool would be better?
I would be considering a web version of this, though. You've got the
maker community out there, and the whole web 2.0 thing, you really
want to tap into that if at all possible. Letting people code up their
recipes in a fun way, link them up in a fun visual way, explore the
space a bit, and link to this stuff from their various websites and
social networking stuff, it'd be good.
Something is missing here; a point for the people encoding the
recipes. Maybe the ability to explore the whole space is enough point?
What about, if you are into making things, it might be good to have a
tool where you start with someone's high level recipe, and can
generate a low level bill of materials, and possibly an integrated set
of instructions where all sub-projects are pulled in and included? The
possibilities there are pretty strong.
Maybe humans would be a better first target fabrication platform, than
any specific equipment? A bit more margin for error?
>> Do you have any kind of planning type doco around the place? For
>> instance, a spec? Architectural descriptions, diagrams? Or maybe
>> details of the various sub programs that make up the entire vision,
>> and what each non-existing piece needs to do?
>
> Sort of. Old content here (including diagram :-)):
> http://heybryan.org/mediawiki/index.php/Skdb
>
> Though the emails on this list would be more informative. Here's some
> information on architecture (sort of):
> http://groups.google.com/group/openmanufacturing/browse_thread/thread/3f991441a6860b51/e7aa2f93e40ec8d6?lnk=gst&q=Sepehr#e7aa2f93e40ec8d6
>
> (What follows is an excerpt from that page, it's mostly just
> ramblings, so it's ignorable I guess.)
>
> =========================================
> stuff for userspace
>
Here's the meat :-)
First question; which one of these gets the most bang for the buck?
Which one is the least dependent on others?
> autospec - validates the units for the packages, validates the yaml,
> gets additional python plugins if necessary when the yaml specifies
> some weird class that is not yet installed.
> Are the 'python plugins' (that specify additional classes) to be
> provided in package (.skdb) files? tentatively: yes. Then why wouldn't
> this be specified in the metadata for the skdb file as a 'dependency'?
Not sure what this does.
>
> agx-get - gets packages from the database, gets all metadata (local
> user cache in ~/.skdb/mimedb/ or something), allows the user to search
> for packages, uses a sources.list type file to connect to skdb or
> other metarepo installations, torrent functionality would be nice, and
> must be able to process the metadata files and give the user options
> to download particular parts (or everything) related to a .skdb file
> -- this will typically involve downloading a new skdb package in the
> first place in order to understand the skdb file in its entirety (for
> example, different types of packages will most likely have different
> types of metadata specified, different types of resources, with data
> worth parsing on the user-end for options related to seeking out the
> package-contents).
>
What is the different between agx-get and, say, apt-get? Can existing
metarepo tools be used in its place? Could we live with them at least
for a v0.1?
> disambiguator - lets user specify what sort of file formats need to be
> processed, what the input/outputs have to be, and finds puzzle pieces
> that match these specs
I think I almost grasp what you are saying here, this intrigues me.
Something like, given an incomplete graph, go hunt for pieces in the
meta repos, that would fit in a static-typing way (lego) ?
>
> agx-sim - the simulator
> Packages (.skdb) would describe how they are to be simulated, if at
> all. I am sure somebody would like to come up with a standardized
> simulation interface. There are a few problems (computationally) that
> have to be addressed, like whether or not it should be a binary sort
> comparison, n!, or something else. Hard to tell, but the important
> aspect is that the architecture allows for this sort of thing.
Are we simulating the process of following the recipes, ie:
constructing stuff? Or are we simulating particular hardware to be
used in constructing stuff? Or some of all of that? Or is the
particular hardware itself to come from recipes, so these are
different ways of saying the same thing? Or something else?
>
> agx-make - considering fablab facilities (/dev stuff), configuration,
> layout, orientations, inventory, number of humans available, etc.,
> generate an overall recipe for the entire lab to execute and make the
> product ('go command' should be avoidable via passing a parameter)
> Generating the programming for the machinery will be somewhat
> high-level: this would not be an immediate compiling down to "turn the
> servo" sort of code, but rather something that each of the machines
> with their pre-installed firmware can understand.
I can't wait until this exists! Fun.
I think in the 0.1 discussion above, I was suggesting making an early
version of this, with possibly no machine instructions involved.
Ok, this email is kind of the start of that.
I forget if I asked this already; is there a specific wiki for this?
If not, I tend to use wikidot.com (excellent, unless you are a
religious objector to "the cloud").
>
>>> There's a lot of other tasks though that have been floating around,
>>> and we haven't really been keeping a community, overall todo list
>>> (i.e., "+1 put a stop to that world hunger thingy") of the comments we
>>> make off-hand in our mailings.
>>
>> My main observation here is again that it's very difficult to get any
>> kind of overview from the outside. I'm happy to help out here, again.
>> Wiki work? Maybe an issue list in Mantis, something like that?
>
> An issue tracker would be awesome. Any particular reason for Mantis?
> What about bugzilla, trac, etc.?
>
> http://ifdefined.com/blog/post/2007/10/Links-to-other-comparisons-of-issue-trackers.aspx
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
We've been starting to use Mantis, looks good. But otoh, in this kind
of context you want something that someone else will host for you
indefinitely :-)
Left to my own devices, I'd probably use something like sourceforge
for code repo + issue tracking + other stuff. What do you guys use /
like?
Bryan Bishop
> You're rummaging around in a very large design space, huge. It's a
> testament to your abilities that you haven't completely lost
> motivation already; I'd be floundering (and am, in fact :-) ).
Most of the trouble is in talking about it. The code is embarrasingly simple.
> I would suggest that some GUI based client tools for working with
> these files would be the thing. Specifically, a website into which
> people could add designs, and see other people's designs (and use them
> as dependencies, make variations, etc etc) might be good. Although,
> that's not really quite the philosophy here; you've got a more codey
> thing going, caches of stuff on developer's machines, tied together
> with a packaging system, so maybe a desktop tool would be better?
Way ahead of you ..
http://heybryan.org/graph/bloodgate.com/graph-easy/
(uh, it doesn't work because it's supposed to be on the lab server;
try this (older) version: http://bloodgate.com/graph-easy/ )
Also:
http://function.device.mst.edu:16080/repositoryEntry/
http://function.device.mst.edu:16080/FunctionCAD/
http://www.me.utexas.edu/~adl/graphsynth/
Unfortunately, these applications don't use quite the right format.
And frankly I don't think the repository entry application is quite
what we want. Anyway, one of the big things I have against web/GUI
stuff is that I fear that somebody is going to come along and ask
users to just write stuff down in English, and *pop* we have another
craptastic Wikipedia or Cyc, which is not what's going on here.
Anyway, a gallery for showing projects wouldn't be bad, go talk with
Sam Rose if he's still listening in on things.
> I would be considering a web version of this, though. You've got the
> maker community out there, and the whole web 2.0 thing, you really
> want to tap into that if at all possible. Letting people code up their
> recipes in a fun way, link them up in a fun visual way, explore the
> space a bit, and link to this stuff from their various websites and
> social networking stuff, it'd be good.
Right, but I'm not sure that there's that many people that know how to
program. That's why the debian package maintainer model might be
useful here. Have some people send in all sorts of documentation and
information and collaboratively work with a package maintainer to make
a new package that passes the standards.
> Something is missing here; a point for the people encoding the
> recipes. Maybe the ability to explore the whole space is enough point?
Well, a game.
http://en.wikipedia.org/wiki/Cooking_Mama
"In Cooking Mama, the player is tasked with cooking various meals
using the Nintendo DS's touch screen. Following the instructions of
the titular "Mama", the player uses the stylus to chop vegetables,
slice meat, flip food in pans, and arrange the final items on the
plate. Each of these tasks is performed by completing a mini-game
which usually lasts less than 10 seconds. The gameplay structure
consists of the player progressing through a series of short
minigames. The game features a total of 76 different dishes."
.. except, for virtual manufacturing automation and other simulator
goodness (we've talked about it in the archives).
> What about, if you are into making things, it might be good to have a
> tool where you start with someone's high level recipe, and can
> generate a low level bill of materials, and possibly an integrated set
> of instructions where all sub-projects are pulled in and included? The
> possibilities there are pretty strong.
Yes, that's the idea. But recipe representation has to be solved first ;-).
> Maybe humans would be a better first target fabrication platform, than
> any specific equipment? A bit more margin for error?
Right, that's why all packages are going to have a 'serialization
module' so that, given the same parameters, whether there's a physical
instantiation of that piece of hardware, or if there's just a human
reading a printout, the "package" can do its job - either by informing
the user or physically doing it in an instantiation.
Consider a fictional program called "fold-it". The man page says:
fold-it: a program that folds TMD (origami) structures into STL (a model)
usage:
./fold-it <origami file> <crease ID to fold> [--o=<file>]
So then let's pretend that you do:
./fold-it crane.tmd A --o=crane.or
./fold-it crane.tmd B --o=crane.stl (uh, so apparently this crane only
had two creases)
Let's imagine also two scenarios where we have the origami folding
machine, and just human hands. The program would spit out instructions
like "FOLD A" and "FOLD B". A human could read both of those, and so
could a fictional machine. So :-).
>>> Do you have any kind of planning type doco around the place? For
>>> instance, a spec? Architectural descriptions, diagrams? Or maybe
>>> details of the various sub programs that make up the entire vision,
>>> and what each non-existing piece needs to do?
>>
>> Sort of. Old content here (including diagram :-)):
>> http://heybryan.org/mediawiki/index.php/Skdb
>
> First question; which one of these gets the most bang for the buck?
agx-get (which is a dpkg-equivalent too, I guess). See below.
> Which one is the least dependent on others?
Wrong question - once we have a few packages in the format, these
programs nearly write themselves. (hehe)
>> autospec - validates the units for the packages, validates the yaml,
>> gets additional python plugins if necessary when the yaml specifies
>> some weird class that is not yet installed.
>> Are the 'python plugins' (that specify additional classes) to be
>> provided in package (.skdb) files? tentatively: yes. Then why wouldn't
>> this be specified in the metadata for the skdb file as a 'dependency'?
>
> Not sure what this does.
Each package has metadata about the "inputs" and "outputs", so a car
would have an input of a certain unit amount of gasoline, and the
output would be the amount of transitional acceleration I guess. Bad
example. Ah, here's a better one - take a look at electronic component
datasheets, which clearly specify input requirements, such as voltage
levels. Now, if you connect two hardware packages together, and one
gives peanut butter, the other wants jelly as an input, well, autospec
is going to complain about your absurdities.
>> agx-get - gets packages from the database, gets all metadata (local
>> user cache in ~/.skdb/mimedb/ or something), allows the user to search
>> for packages, uses a sources.list type file to connect to skdb or
>> other metarepo installations, torrent functionality would be nice, and
>> must be able to process the metadata files and give the user options
>> to download particular parts (or everything) related to a .skdb file
>> -- this will typically involve downloading a new skdb package in the
>> first place in order to understand the skdb file in its entirety (for
>> example, different types of packages will most likely have different
>> types of metadata specified, different types of resources, with data
>> worth parsing on the user-end for options related to seeking out the
>> package-contents).
>
> What is the different between agx-get and, say, apt-get? Can existing
> metarepo tools be used in its place? Could we live with them at least
> for a v0.1?
Since the difference is non-existent, that's the first thing I checked
out. Believe it or not, apt-get and the overall repository
architecture isn't a separate project in debian. It's kind of a cruel
hack underneath everything else.
>> disambiguator - lets user specify what sort of file formats need to be
>> processed, what the input/outputs have to be, and finds puzzle pieces
>> that match these specs
>
> I think I almost grasp what you are saying here, this intrigues me.
> Something like, given an incomplete graph, go hunt for pieces in the
> meta repos, that would fit in a static-typing way (lego) ?
Yep. The software (repository entry app, functioncad, and graphsynth)
that I linked to above already does this, in a very similar manner,
though not for what we're doing here word-for-word. (I've also been
lazily writing a paper about doing this with biobricks for the
prediction of incomplete genetic regulatory network datasets, but I
haven't gotten around to going much further with this.)
>> agx-sim - the simulator
>> Packages (.skdb) would describe how they are to be simulated, if at
>> all. I am sure somebody would like to come up with a standardized
>> simulation interface. There are a few problems (computationally) that
>> have to be addressed, like whether or not it should be a binary sort
>> comparison, n!, or something else. Hard to tell, but the important
>> aspect is that the architecture allows for this sort of thing.
>
> Are we simulating the process of following the recipes, ie:
> constructing stuff? Or are we simulating particular hardware to be
> used in constructing stuff? Or some of all of that? Or is the
> particular hardware itself to come from recipes, so these are
> different ways of saying the same thing? Or something else?
The primary discussion has been about simulating the function of the
artifacts encoded in the package. However, if you're able to do that,
then I don't see why you couldn't simulate the making of a particular
artifact, since the recipe 'merely' references *other* packages --
which you would simulate together acting in tandem. The specifics of
physical orientation and so on would be some really (un?)fun bugs to
work out later, but I think that would be a good problem to have.
>> agx-make - considering fablab facilities (/dev stuff), configuration,
>> layout, orientations, inventory, number of humans available, etc.,
>> generate an overall recipe for the entire lab to execute and make the
>> product ('go command' should be avoidable via passing a parameter)
>> Generating the programming for the machinery will be somewhat
>> high-level: this would not be an immediate compiling down to "turn the
>> servo" sort of code, but rather something that each of the machines
>> with their pre-installed firmware can understand.
>
> I can't wait until this exists! Fun.
Part of it already does-- your printer?
> I think in the 0.1 discussion above, I was suggesting making an early
> version of this, with possibly no machine instructions involved.
I'm not convinced whether or not that's a good idea. :-/
>>> If not, perhaps I could help in compiling this stuff, to make it a bit
>>> easier for others to see in, and potentially join in, in the future?
>>
>> That would be appreciated too.
>
> Ok, this email is kind of the start of that.
>
> I forget if I asked this already; is there a specific wiki for this?
http://heybryan.org/mediawiki/index.php/Skdb is one place for stuff.
But there's also a wiki on http://oscomak.net/ and
http://p2pfoundation.net/ so those are some other options. And I'm
sure Paul could throw up a wiki on openmanufacturing.net if we wanted.
One of the original ideas that we were toying around with was ikiwiki
as a frontend to the git repositories. So, this way, people without a
clue could use the wiki to modify the files and so on-- maybe from my
crappy AJAX frontend too. But ikiwiki wouldn't be for documentation
purposes, so that's different.
> If not, I tend to use wikidot.com (excellent, unless you are a
> religious objector to "the cloud").
Yep, I'm an objector to the cloud. Unless it's my cloud.
>> An issue tracker would be awesome. Any particular reason for Mantis?
>> What about bugzilla, trac, etc.?
>
> We've been starting to use Mantis, looks good. But otoh, in this kind
> of context you want something that someone else will host for you
> indefinitely :-)
At the very least, a weekly distributed backup wouldn't be terrible.
Maybe Paul could also weigh in on the issue/bug tracker deal and maybe
throw something up on openmanufacturing.net?
> Left to my own devices, I'd probably use something like sourceforge
> for code repo + issue tracking + other stuff. What do you guys use /
> like?
Homebrew stuff on our own servers. ;-) See the git repo, for instance.
Emlyn
> Emlyn wrote:
>> Well, Flash was an interesting diversion. Did you see my solar system
>> thing? I made the mistake of embarking on a concept for an environment
>> without an idea for a game; I couldn't easily retrofit one (and to be
>> honest I lost interest).
>
> No, is there a link?
http://emlynoregan.com/writing.aspx?code=SolarSystem
Paul D. Fernhout
It's a start of an idea. Maybe a spaceship could move stuff around from one
world to another to make more space ships?
--Paul Fernhout