--- Day changed Fri Apr 18 2008
00:13 < fenn> http://fennetic.net/pub/irc/autogenix-software.png
00:17 < kanzure> in all honesty, how long did you spend on that tree? ;)
00:17 < fenn> i didnt draw the tree
00:17 < fenn> it came with dia
00:18 < kanzure> neat
00:18 < fenn> mm.. i guess
00:18 < fenn> i should probably use inkscape, but dia is special-purpose enough that it's nice for quick sketches where you delete things and move them around a lot. it preserves geometrical relationships
00:20 < fenn> it is nice to have a bunch of icons to pick from, instead of having to search the web for clipart
00:20 < kanzure> now,
00:20 < kanzure> 'design model' worries me
00:20 < kanzure> once you design your model, *go dump it into git*
00:20 < kanzure> no?
00:20 < kanzure> here I'm assuming git =~ skdb =~ ikiwki+git etc.
00:20 < fenn> yes, that git
00:21 < fenn> stuff in git should be generic enough to be read by any 'electricity' plugin we come up with
00:21 < kanzure> thus, you should be able to retrieve models from git too
00:21 < kanzure> huh?
00:21 < fenn> s/git/skdb/
00:21 < kanzure> what about the idea of the chair package?
00:21 < kanzure> our friendly chair package example, at least
00:21 < fenn> i cant think about chair units this late :P
00:21 < fenn> its too abstract
00:22 < fenn> 'comfiness' hmph
00:22 < kanzure> okay, so 'built-up units' are allowed
00:22 < kanzure> such that we can make more permutations and combinations and so on
00:22 < kanzure> and we get into fancy grounding problems, of course, but that's not too bad
00:22 < kanzure> since we can still get stuff done without a Theory of Everything for all units
00:22 < kanzure> which is pretty sweet :)
00:24 < fenn> seat comfiness measurement device : http://www.kuka.com/taiwan/en/products/systems/occubot/
00:24 < kanzure> comfiness would be more social data
00:24 < fenn> symbol grounding basically dumps the problem of measurement onto the user
00:24 < kanzure> yep
00:24 < kanzure> and society
00:24 < fenn> like, the user can measure a volt, so that's a volt
00:24 < kanzure> standards, etc.
00:25 < kanzure> haha -- giant mechanical arm to test the chair ... classic :)
00:25 < fenn> but see the prosthetic butt attachment
00:25 < kanzure> hehe
00:25 < kanzure> prosthetic ass?
00:27 < fenn> movie of the seat tester http://www.kuka.com/taiwan/en/products/systems/occubot/\
00:27 < fenn> agh
00:28 < fenn> http://www.youtube.com/watch?v=bPU3NpuMdg0
00:28 < fenn> so, i wonder if that tells you something
00:29 < kanzure> I wonder how that company got over the subjectivity stuff
00:29 < kanzure> I wonder what properties they are actually testing
00:29 < kanzure> heh
00:30 < fenn> pressure, probably
00:30 < kanzure> "I think human asses are still cheaper." - Blake
00:31 < fenn> in^-2  (pressure per pound)
00:32 < fenn> and maybe some thermal properties factor into it too
00:32 < kanzure> texture?
00:32 < fenn> water transport
00:32 < kanzure> pressure per pound per cm
00:32 < kanzure> or per mm, really, or whatever our tactile resolution is through clothing
00:32 < fenn> not high
00:32 < fenn> you can sit on a bed of nails and not know it
00:32 < fenn> it's like 1 dpi
00:33 < kanzure> wtf
00:33 < kanzure> huh, okay
00:34 < kanzure> re: autospec for 'unit simplification' methodology: find all units and then find all possible other ways of expressing the same units, then eliminate the ones that are not used for all of the original units, then the remaining ones are the options - then use the smallest possible number of units to connect all of the packages together
00:35 < kanzure> *then* the design phase where you paste together shell pipelining and so on to make sure that they can understand each other's formats and whatever other simulation modules have to be pasted together for interfaces etc.
00:35 < kanzure> right?
00:35 < kanzure> that's the 'design-phase' thing you labelled
00:35 < fenn> 'smallest possible number' is all of the base units
00:35 < kanzure> hopefully the interfacing will be somewhat automated/streamlined
00:35 < kanzure> perhaps not all of the base units will be used however
00:35 < fenn> oh, right
00:36 < fenn> base units is things like kg, m, s, whereas derived units are J, newton
00:36 < kanzure> sure
00:36 < fenn> i'd like to preserve the original units for displaying to the user
00:37 < kanzure> I've had 'go through all of the CRC Handbook of Chem/Physics variables' on my todo list for years
00:37 < fenn> obviously kW makes more sense in a generator context than kg*m^s2/s^2
00:38 < fenn> see i got it wrong
00:38 < fenn> kg*m^2/s^3
00:39 < fenn> anyway, GNU 'units' should handle this.. i cant think of any situation where you'd make up a unit that it couldnt handle
00:40 < kanzure> so autospec can do a simple scoring matrix
00:40 < kanzure> gnu units would simplify anything it is given
00:40 < kanzure> into more fundamental units
00:40 < fenn> but why bother simplifying
00:40 < kanzure> and then we get a list of those units and add them to their respective scores
00:40 < kanzure> at the end we choose the ones that have the highest scores
00:40 < kanzure> hm?
00:40 < kanzure> what's the alternative?
00:40 < fenn> calling gnu units when you want to do a comparison
00:41 < kanzure> but what if you want to try to 'optimize' all of the packages at once?
00:41 < kanzure> instead of your binary compare method?
00:41 < fenn> scoring is separate from units, it's more like you have a vector in units-space, and multiply it by your personality-matrix
00:42 < fenn> all people arent going to optimize things the same way all the time
00:42 < fenn> so you have to assign weights to each type of 'cost'
00:43 < fenn> time, safety, reliability, autonomy
00:43 < kanzure> uh?
00:43 < fenn> autonomy is more or less the opposite of money?
00:44 < kanzure> what is safety in terms of
00:44 < kanzure> what units?
00:44 < fenn> hell i dont know
00:45 < fenn> (mean time before accident)/severity
00:46 < fenn> what's the dollar value of a human life?
00:47 < fenn> there will be a series of questions we ask the end-user to figure these things out
00:47 < fenn> hence 'personality matrix'
00:48 < fenn> no, i havent figured it all out
00:49 < kanzure> look, doing a comparison between 500 different packages would require 500! comparisons, you see?
00:49 < kanzure> and you can't just do chaining
00:49 < kanzure> A-B, B-C, C-D, D-A
00:49 < kanzure> because that does not guarantee the shortest path
00:49 < fenn> er, you just sort a list of 500
00:49 < kanzure> that is the shortest computational path, not the shortest unit-path
00:49 < kanzure> huh?
00:50 < fenn> take package A, find its cost appropriate to Fred (our end-user), tag package with that cost
00:51 < kanzure> that's stupid
00:51 < kanzure> we're talking about evaluating unit feasability
00:51 < kanzure> whether or not the entire design can meet specifications
00:51 < kanzure> thus the specs must be programmed
00:51 < kanzure> i.e., "must provide within this range of whatever units"
00:51 < fenn> if i have a nuclear reactor (safety factor 1000yr/gigadollar-explosion) and a gasoline engine (100yr/kilodollar-explosion) we can find the safety value, no?
00:52 < fenn> and sort them in a list
00:52 < fenn> or are you talking about something completely different now?
00:52 < kanzure> I thought we were talking about autospec
00:53 < fenn> you said 'design model worries me'
00:53 < fenn> then started talking about autospec
00:54 < kanzure> how can you verify the design when you don't have the design? autospec verifies the feasability of the design (not whether or not it will work as you naturally-linguistically describe it)
00:54 < kanzure> anyway, I need to get going for the night
00:55 < fenn> ok, hopefully the diagrams will make more sense next time you look
00:57 < kanzure> nobody said they didn't make sense
00:57 < kanzure> that last one was pretty good
00:57 < kanzure> but 'design models' should be in skdb anyway, no? - and then users get to create new ones by plug-and-chug (lego building style)
00:57 < kanzure> http://fennetic.net/pub/irc/autogenix-software.png in particular
00:57 < kanzure> yeah, I'm crashing
00:57 < kanzure> g'night
00:58 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."]
07:23 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap
07:37 < kanzure> fenn: you have sufficiently disrupted my depiction of the system that I need your further clarification -- all of your talks on units seems to have ignored how the packages demand they be setup, such as the lathe-package, which has its own g-code and its own specifications for material requirements
07:37 < kanzure>  and so on, these material requirements for making the object are different from typical unit requirements, especially since you need to use some 'form' of material in many cases ("I need xyz type of material, I don't care if you can't magically extract it") 
07:37 < kanzure> -- which is where the Common Object Library (implemented by python plugins in skdb for user download) comes into play. I think these plugins would have to tie 
07:37 < kanzure> in their functions to some main 'processes', i.e. if you load in an extra module then the main functions running through the script should treat it like an API and just call $module.buildFunc() or something; *but* from the sounds of it this is not the case that you were suggesting
08:02 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."]
15:28 -!- Splicer [n=p@h28n3c1o261.bredband.skanova.com] has joined #hplusroadmap
17:36 -!- Splicer2 [n=p@h238n1c1o261.bredband.skanova.com] has joined #hplusroadmap
17:45 -!- Splicer [n=p@h28n3c1o261.bredband.skanova.com] has quit [Read error: 110 (Connection timed out)]
18:00 -!- Splicer2 is now known as Splicer
18:16 -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap
18:18 < kanzure> Hey fenn.
18:18 < kanzure> http://heybryan.org/mediawiki/index.php/2008-04-18
18:18 < kanzure> here's the summary:
18:19 < kanzure> the solution to my worries about the units stuff v. all-out packages is that the code to make something is simply code to query/ping an API for dealing with whatever equipment the user has in his fab-lab
18:19 < kanzure> so all of that code doesn't have to be evaluated until the end
18:20 < kanzure> I'm thinking of a completely automated fab lab (except with human interaction when necessary, to some requisite degree of precision)
18:24 < fenn> hi. i'm redoin the diagram because i was wrong
18:26 < fenn> dead dependency tree is preferable because it means a comparison is very simple. the alternative means calling possibly large amounts of code for every comparison
18:26 < fenn> but, there are varying degrees of dead-ness vs alive-ness
18:27 < fenn> fully dead is like 'blackboxing', you specify exactly the package you intend to be used
18:28 < fenn> partially dead is to cite a specification, such as a standardized connector, which makes use of units and named geometry to ensure that things will fit together
18:28 < fenn> fully alive does simulations on the geometry of the parts involved, collision detection, thermal analysis, etc
18:29 < fenn> obviously we cant do full simulations on (n!) connections in the db
18:29 < fenn> (or can we?)
18:31 < fenn> anyway, i think 'partially dead' is what we're going for
18:47 < kanzure> Paul knows Freeman Dyson personally. 
18:47 < kanzure> full simulations / n! is obviously infeasible at this point, yes
18:48 < kanzure> we need a 'printing server' for fabrication
18:48 < kanzure> I think we are wrong about the local user skdb cache of metadata files etc
18:48 < kanzure> technically it's not just a file cache
18:48 < kanzure> it should be a physical tool cache too
18:48 < kanzure> plus the configuration information specifying on what ports the instruments are connected to the server
18:49 < kanzure> plus a common API so that drivers can be written for the API, and then all packages in skdb can query that interface to make the tools do something (no matter what weird device-driver implementation the physical instruments happen to involve, see)
18:49 < kanzure> wtf, Dyson doesn't have a PhD.
18:55 < fenn> ugh.. thinking is too hard
18:56 < fenn> there's got to be a better way
18:56 < kanzure> haha
18:57 < kanzure> it's been making good sense to me so far
18:57 < kanzure> I mean, I had a bit of a blip last night and this morning
18:57 < kanzure> but I was explaining it to a kid at school (rubber ducky method), and had a few generated insights while talking
18:58 < fenn> this is halfway done: http://fennetic.net/pub/irc/autogenix-software2.png
18:59 < fenn> yep, explaining things will do that
18:59 < kanzure> a few things that I kept floating back to: (1) grounding problem, (2) analogies to the compiler bootstrapping problem, (3) linux printing server ;)
19:00 < kanzure> is the top left pictogram supposedly a servo?
19:00 < fenn> its an electrical plug
19:00 < fenn> like you plug into a wall
19:01 < kanzure> please excuse me, my eyes.
19:01 < kanzure> on the right I see the outlet, at least
19:01 < fenn> i'll make it bigger
19:02 < kanzure> nah, was just wondering
19:03 < fenn> well too bad
19:06 < fenn> so, are the class instances the nodes of the graph?
19:14 < kanzure> hrm
19:14 < kanzure> there are many graphs to consider
19:14 < kanzure> oh
19:14 < kanzure> so we can do instances which make up a project in skdb?
19:16 < kanzure> but that would still be a package in skdb, IMO
19:16 < kanzure> even if it is a package that doesn't offer new python plugins (new classes)
19:23 < fenn> yes, a project would be a collection of instances of its parts
19:25 < fenn> like, a vacuum cleaner wouldn't redefine the NEMA-5-15P connector, it would just include nema-5-15p.skdb, instantiate it, and connect the relevant signals/wires
19:27 < fenn> or... is nema-5-15p.skdb simply data that gets parsed and stuffed into a generic electrical connector object?
19:27 < fenn> 3-prong connector
19:36 < kanzure> hm
19:36 < kanzure> it would be an instance of a generic part, yes
19:36 < kanzure> an obviously much more specific instance than could otherwise be provided
19:37 < kanzure> however, it is *not necessarily* stuffed into generic electrical connectors.skdb .... that skdb file in particular might go point to nema-5-15p.skdb (which could be downloaded at the same time for all we care)
19:37 < kanzure> I think that nema-5-15p.skdb must exist if we are to allow python plugins (for instances) to have their own classes too, yes?
19:37 < kanzure> or, hm..
19:41 < kanzure> sure, why not, there's no general requirements for what gets to be a package and not
19:42 < kanzure> as long as they can ultimately be parsed and considered pertainent to the overall goals of skdb, yes?
19:46 < fenn> what are the goals of skdb?
19:47 < fenn> comp got hijacked by munchkins who promptly locked it up solid with tuxracer
19:49 < kanzure> I thought the goals are to just dump as many projects as possible into the mix, then fix up some of the connections and then do searches for self-replicating machines
19:55 < kanzure> re: fully alive simulations; this is where it becomes more optimal to experiment and build it first, then report on the results or whatever (ideally, only report on the positives, but showing an error log would be excellent)
19:57 < kanzure> fenn: please kick me in the ass
19:58 < kanzure> what do we have left to do?
19:58 < fenn> empirical testing can be represented as a sort of simulation (it doesnt necessarily apply to all instances of the project everywhere)
20:00 < fenn> or is that totally backwards and inside out thinking?
20:00 < kanzure> hm
20:00 < kanzure> yeah, who cares how the simulation is done
20:00 < kanzure> it could be physical or virtual, either way.
20:00 < kanzure> it could be done if you shuffle neurotransmitters around for all I care
20:00 < kanzure> as long as you do it right
20:01 < kanzure> even physical experiments can be faultily setten-up (woah, wording issues here)
20:01 < kanzure> *even physical experimental implementations can be faulty setups
20:02 < fenn> now that i think about it, a standard electrical plug is an interference fit
20:02 < kanzure> hm?
20:02 < fenn> you have to know the spring constants and do FEA and all sort of nastiness to get the insertion force
20:02 < fenn> not just geometry
20:03 < kanzure> also, a short rant on the package manager on the user end -- it will have to be able to manage the fab-lab; this means precise positioning of input materials, output materials, the machinery, cords and wires (wireless would be ridiculously useful)
20:03 < kanzure> hm
20:03 < kanzure> insertion force for a plug?
20:03 < kanzure> true that
20:03 < fenn> wireless isnt going to happen
20:03 < kanzure> yeah :(
20:03 < kanzure> so it has to have a managed cord environment
20:03 < kanzure> very meticulous configurations
20:03 < kanzure> (but that's okay)
20:04 < fenn> not a big deal once you figure out the algorithm
20:04 < kanzure> worst case scenario: you make it a genetic algorithm so that it can find the best way to position all of the equipment in whatever dimensionality-room you have available
20:04 < kanzure> and then wire management can be computer-automated too
20:04 < fenn> i'm more concerned about the things that are not black-boxy, like electrical interference, temperature, vibration (and modal analysis)
20:04 < kanzure> how so?
20:05 < fenn> if package A works in one situation, it might not work in another situation because we failed to simulate everything happening at once (which is impossible without recreating the universe)
20:06 < kanzure> I thought you said autospec would take care of this
20:06 < kanzure> in partial-alive/dead simulation stuff.
20:06 < fenn> well, it depends on the specs being well written
20:06 < kanzure> and why can't we come up with algorithms for managing that stuff anyway?
20:14 < kanzure> ?
20:19 < kanzure> fenn: that might be more from the social knowledge side
20:19 < kanzure> remember, automated design is not our goal
20:19 < kanzure> just widespread diffusion and easy modifications + experimentation, not a guarantee that anything will work
20:19 < kanzure> (with linux 'it just happens to work', really - there's no monarch sitting at the top making sure all lines conform)
20:23 < fenn> at the individual interface level everything is very standardized and specified. that's why all the lib.so.0 stuff
20:24 < fenn> when the .0 changes to .1, the libraries are no longer compatible
20:24 < kanzure> but it's all blackboxed, this is necessarily different
20:24 < kanzure> user experimentation/learning is necessary
20:24 < kanzure> that's all there is to it.
20:24 < fenn> why?
20:24 < kanzure> hell if I know
20:24 < kanzure> but there are obviously emergent effects that have to be dealt with
20:24 < kanzure> electrical interference could be an algorithm that we apply over a person's design before making it
20:24 < kanzure> for final checks and so on
20:24 < kanzure> sure, but that's bloody hard to write
20:25 < kanzure> the point is that those interactions do not happen all the time, therefore there is a likelihood that users can learn how to optimize manufacturing routines or whatever to either avoid those problems or find ways around them
20:25 < kanzure> the system is not totally useless if it can't predict all possible emergent interference (or other) effects
20:28 < fenn> blah.. i dont know what's next: http://fennetic.net/pub/irc/autogenix-software2.png
20:28 < kanzure> btw, you realize the example MD file is suspect right?
20:29 < kanzure> but that's obviously something we can deal with later
20:29 < fenn> suspect how?
20:29 < kanzure> just doesn't feel right
20:29 < kanzure> but back to the 'stuck' part
20:29 < fenn> it's the heart of the system :)
20:29 < fenn> the source of all truth and beauty
20:30 < fenn> it defines the possible logical connections in the graph
20:30 < kanzure> do you assert the general validity of the design of the entire software architecture as shown in the image?
20:30 < fenn> if the MD is wrong, we're screwed
20:30 < fenn> so that's why i want it as simple and hand-crafted as possible
20:30 < kanzure> is that even valid yaml?
20:30 < fenn> close, i need to add some :'s
20:31 < kanzure> also, where's the g-code? etc.
20:31 < kanzure> that's why I say it can wait until later
20:31 < kanzure> the details can be hashed out later, the point is that the rest of the system has to be able to cope with such details
20:31 < fenn> g-code is auto-generated from cad files, or included in the package
20:31 < fenn> g-code sucks
20:31 < kanzure> whatever, I'm using it as a blackbox at the moment
20:31 < fenn> it's very machine specific because the standard is so poor to begin with
20:31 < kanzure> anyway, you may want to add in something about autospec getting the python plugins from skdb (as skdb packages themselves)
20:31 < fenn> you might as well consider it written english
20:32 < kanzure> also, the PV=IR stuff -- you might want to mention 'GNU units'
20:32 < kanzure> is that how bad it is? yikes
20:32 < fenn> well, its bad
20:32 < kanzure> you may want to connect the factory back to the 'optional simulation' (which also adds it back to adding the designs back into skdb, with use-case reports, bugzilla additions, whatever)
20:33 < fenn> ok
20:34 < kanzure> process state config might be the 'print server and fab-lab management / resources / automated tool infrastructure management' stuff, dunno
20:34 < kanzure> I'm assuming yes
20:35 < fenn> yes
20:35 < kanzure> this brings me back to my talk on the "fablab tool API" or whatever -- obviously all tools will have drivers, yes? These drivers will have weird interfaces, sure, so we need to abstract it away from all of the skdb pack
20:35 < kanzure> ages with code in 'em so that the code just queries the server and formulates a yaml production request or whatever, controlling the defined standards for the machinery. 
20:35 < kanzure> does that make sense?
20:35 < fenn> no, not all tools will have drivers, obviously hand tools won't
20:36 < fenn> many operations will have to be explained with english
20:36 < kanzure> hand tools can be controlled by hand-manipulators
20:36 < kanzure> yes
20:36 < kanzure> that is true
20:36 < kanzure> ideally, all packages will have loads of natural language stuff dumped into them (kind of like man pages)
20:36 < kanzure> you know how my biohack zip file has tons of information?
20:36 < kanzure> the biohack kit would be a good example of an extra resource to cite in a dot-skdb file
20:37 < fenn> yeah, i figured you wanted to boil biohack.zip down into a series of skdb files
20:37 < kanzure> sure
20:37 < kanzure> but 
20:37 < kanzure> but the written text is also important for the by-hand and so on
20:37 < kanzure> sooo the skdb files should also be able to cite alternatives to programmed functions for making things
20:37 < fenn> of course
20:38 < kanzure> "here's what a human could do in this situation" or something
20:38 < kanzure> ok good
20:38 < kanzure> ideally, we could have the program figure out how much can be optimized, and then generate a routine to print out and give to the humans
20:38 < kanzure> and they can walk around and do their checklist
20:38 < kanzure> or query the database for more info (etc.)
20:38 < fenn> this is why all the skill-set theorizing
20:38 < kanzure> "wtf, how do I turn on a microwave"
20:39 < fenn> if you are a total moron you can still pay other people to do operations for you
20:39 < kanzure> hurray for capitalism
20:39 < fenn> meh
20:39 < kanzure> obvious sarcasm
20:39 < kanzure> but anyway
20:39 < fenn> i'd rather people be forced to learn how to survive :)
20:40 < kanzure> you said 'no, [that does not make sense] -- so I think you would now answer 'yes'?
20:40 < kanzure> oops, forgot to closequotes
20:40 < fenn> what didnt make sense?
20:40 < kanzure> I was talking about the fablab tool API
20:40 < kanzure> see, when you program on linux for example
20:40 < kanzure> you just talk about /dev/stuff
20:40 < kanzure> instead of a specific driver for something
20:41 < kanzure> so we need this same sort of system in the sense that there is an abstraction layer that is well-defined
20:41 < fenn> /dev/ is an abstraction layer
20:41 < kanzure> now, some tools might have extra features over other 'equivalents in the same class' of course, but in general, 
20:41 < kanzure> yeah
20:41 < kanzure> but I am also pairing this with the ideas of inventory management, layout management (of the equipment and so on), etc.
20:41 < kanzure> so we can still use /dev/ as it is
20:43 < kanzure> also, instead of a vague-amorphous 'internet', we can say "internet = skdb = ikiwiki + git + http interfaces + pgp signing + ... " or something as a temp placeholder
20:43 < kanzure> blah, you have not updated the diagram
20:43 < fenn> well, v=ir is social knowledge that's not yet in skdb
20:43 < fenn> when it gets coded into the plugin, then it puts the DB into skdb
20:44 < fenn> so that layer with the two cylinders is the skdb
20:44 < fenn> below that is code that runs on end-user computer
20:44 < fenn> below that is physical movements etc
20:45 < kanzure> I'd genuinely like the graph to be further updated though -- the more specific ideas I've mentioned can do wonders methinks :)
20:48 < kanzure> blah
20:48 < kanzure> if not that, then what's next?
20:53 < fenn> well, graph looks pretty complicated, hard to add much more without it looking busy
20:54 < kanzure> I would suggest splitting the graph then, but then we lose the "at a glance" functionality of the graphiness
20:55 < fenn> can make new diagrams of sub-systems, i guess
20:57 < fenn> what's next mister roadmap? :P
20:58 < kanzure> processing
20:58 < kanzure> okay, how about this
20:58 < kanzure> instead of diagrams of subsystems, I'll go write up a brief list of descriptions of all of the subsystems
20:58 < fenn> i know you love big blocks of text, but i'm gonna put the diagram on yer wiki
20:58 < kanzure> and then once we validate this list and say 'go ahead'
20:58 < kanzure> yeah, go ahead
20:58 < kanzure> if it's graphviz then you can use <graphviz> random shit here </graphviz>
20:59 < kanzure> so once we confirm the general taggy descriptions for everything, then I say let's go
21:00 < kanzure> in the mean time I'm experimenting with python, yaml, the yaml type repository, pickles, ikiwiki, git, investigating apt a bit more, and really itching to write a giant block of text
21:00 < kanzure> I feel one coming ;)
21:01 < kanzure> http://heybryan.org/music/Grayson/Land%20of%20the%20Free%202/07-empress-qtxmp3.mp3 is on a loop in the background (+ Cradle of Filth - Nymphetamine)
21:01 < kanzure> it's odd how similar these two songs are
21:01 < kanzure> it must be a niche
21:02 < kanzure> http://heybryan.org/music/Cradle%20Of%20Filth%20-%20Nymphetamine.mp3
21:06 < kanzure> please link me once you dump it on the wiki
21:06 < kanzure> btw, image uploads are now allowed
21:06 < fenn> http://heybryan.org/mediawiki/index.php/skdb
21:07 < fenn> nothing fancy :)
21:07 < fenn> i think i would die if i had to get graphviz to show that
21:09 < kanzure> so, for the implementation of skdb and all of this underlying software
21:09 < kanzure> obviously we are to some extent rewriting portage and apt and so on
21:09 < kanzure> or using parts of them at least
21:09 < fenn> yeah
21:10 < kanzure> so my plan is to release this as a meta package called metarepo
21:10 < kanzure> but that essentially we 'strongly encourage' all instances of the software to be networked together
21:10 < kanzure> ideally you and I can setup an aggregation server or even a main server
21:10 < kanzure> but I would like to see people taking the code and using it for their own local implementations of the entire architecture
21:10 < kanzure> we obviously don't want some guys a few years down the road to come across the software and say "WTF" the same way we did to the lack of an APT website ;)
21:11 < fenn> the idea behind autogenix is that it's a distribution like debian, instead of a bunch of rpm files scattered around the net like redhat seems to have encouraged (or failed to encourage)
21:11 < kanzure> plus the ability to set up clones of the software is an obvious advantage
21:11 < kanzure> sure
21:11 < kanzure> with debian, anybody can set up and provide a mirror
21:11 < kanzure> the .skdb files allow us to point to other resources and splice networks together
21:11 < kanzure> but the goal will be consolidation, yes
21:12 < fenn> bittorrent provides some nice facilities, md5 verification, tracker info etc
21:12 < kanzure> my thoughts exactly
21:12 < kanzure> torrents come into play at multiple points in this system
21:12 < fenn> no need to set up a bunch of 'centralized' servers if we're just going to decentralize them
21:12 < kanzure> but it seems like the implementation details can be held off until long after a first release
21:12 < kanzure> well
21:12 < kanzure> hm
21:12 < kanzure> but I thought we want centralization? a total database that keeps all of the files cached?
21:12 < kanzure> because we don't really want to rely on third party servers to keep up
21:12 < kanzure> or for people to pay their bills etc.
21:12 < kanzure> bad, bad idea.
21:13 < fenn> yes, we'll keep a sort of 'archive' that keeps the torrents seeded?
21:13 < kanzure> k
21:13 < fenn> can torrent software handle downloading 1000's of files at once?
21:13 < kanzure> surely?
21:13 < kanzure> can http software ?
21:13 < fenn> i think http turns to crap after about 4 connections
21:14 < kanzure> that is not encouraging ...
21:14 < kanzure> worst case scenario: we dump all data on to a handful of DVDs or a large hard drive and mail it to interested third parties
21:14 < fenn> so, lots of little files makes for a more up-to-date system, but glomming into tarballs makes for better compression
21:14 < kanzure> yes
21:14 < fenn> hah if we ever get that much data i'm going to declare success and move to mars
21:15 < kanzure> I like the idea of an underlying distribution grassroots thing
21:15 < kanzure> with us seeding
21:15 < kanzure> that makes good sense IMHO
21:16 < kanzure> tell me if this makes sense
21:16 < kanzure> a site with 60 million members has periodic problems with their web services
21:17 < kanzure> who the hell is running that place
21:17 < kanzure> *development servers*
21:17 < fenn> sourceforge? what a crock
21:17 < kanzure> http://gaiaonline.com/
21:17 < kanzure> I go there occassionally to check for priv-msgs from a certain somebody
21:17 < fenn> never heard of it
21:18 < kanzure> I'd describe it as neopets for anime fans
21:19 < fenn> did i ever tell you about smirf?
21:19 < kanzure> no?
21:19 < fenn> http://fenn.freeshell.org/smirf/smirf.html
21:19 < fenn> the idea was to make an MMO that was based on engineering/physics principles
21:20 < fenn> the project would harness the vast numbers of players to make a better in-game cad system/physics simulator
21:20 < kanzure> interesting
21:20 < kanzure> you took a much more technical approach to what I was doing
21:20 < kanzure> in my "I wanna write an MMO days", I mean.
21:20 < fenn> eventually all the 'magical' devices would fail and you'd rely on deterministic clockwork stuff like we have to use in the real world
21:21 < fenn> i didnt want to write an mmo, i wanted a cad system with corresponding physics simulator :)
21:21 < fenn> alpha and beta would correspond to new buggy software of course
21:22 < kanzure> Noah just linked me over to http://cba.mit.edu/events/08.04.ASC/ - looks like David did a presentation yesterday
21:23 < kanzure> The Internet as a Computing Surface
21:23 < kanzure> fab in a boxd
21:23 < kanzure> *box
21:23 < kanzure> Reverse engineering the brain
21:23 < kanzure> How to build a brain (but it's Minsky)
21:24 < fenn> cool stuff, hurray for academia
21:25 < fenn> bussard said the main reason he never gave lectures and conferences was so he could get some work done
21:25 < fenn> (i'm probably misquoting him)
21:27 < kanzure> if I am ever forced to give a lecture, I'm going to immediately turn it into an informal unconference
21:28 < kanzure> nah, nevermind
21:28 < kanzure> I'd enjoy the attention
21:30 < kanzure> my attention is shot - I can either do a block of text or go do something else
21:31 < kanzure> need faster music
21:31 < fenn> why dont you write out descriptions of subsystems
21:32 < kanzure> ten thousand thoughts a second is rather debilitating
21:59 < fenn> hah. some very smart brazilians turned my penguin sketch into a 3d model http://videolog.uol.com.br/video.php?id=321558&grupo=161
22:26 < kanzure> http://heybryan.org/docs/dbz/goku.html hurray for pathetic attempts at writing out vague concepts
22:28 < kanzure> other interpretations of the same character are much too violent
22:29 < kanzure> (don't get me wrong, I can go for violence :))
22:41 < fenn> goku always seemed a little slow to me, good at heart but no prince vegeta
23:15 < kanzure> in fact, none of them were all that bright