| --- Day changed Fri Apr 18 2008 | ||
| fenn | http://fennetic.net/pub/irc/autogenix-software.png | 00:13 |
|---|---|---|
| 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:17 |
| 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:18 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| fenn | movie of the seat tester http://www.kuka.com/taiwan/en/products/systems/occubot/\ | 00:27 |
| fenn | agh | 00:27 |
| fenn | http://www.youtube.com/watch?v=bPU3NpuMdg0 | 00:28 |
| fenn | so, i wonder if that tells you something | 00:28 |
| 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:29 |
| fenn | pressure, probably | 00:30 |
| kanzure | "I think human asses are still cheaper." - Blake | 00:30 |
| fenn | in^-2 (pressure per pound) | 00:31 |
| 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:32 |
| kanzure | wtf | 00:33 |
| kanzure | huh, okay | 00:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| fenn | see i got it wrong | 00:38 |
| fenn | kg*m^2/s^3 | 00:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| fenn | time, safety, reliability, autonomy | 00:43 |
| kanzure | uh? | 00:43 |
| fenn | autonomy is more or less the opposite of money? | 00:43 |
| kanzure | what is safety in terms of | 00:44 |
| kanzure | what units? | 00:44 |
| fenn | hell i dont know | 00:44 |
| fenn | (mean time before accident)/severity | 00:45 |
| fenn | what's the dollar value of a human life? | 00:46 |
| 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:47 |
| fenn | no, i havent figured it all out | 00:48 |
| 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:49 |
| fenn | take package A, find its cost appropriate to Fred (our end-user), tag package with that cost | 00:50 |
| 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:51 |
| 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:52 |
| fenn | you said 'design model worries me' | 00:53 |
| fenn | then started talking about autospec | 00:53 |
| 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:54 |
| fenn | ok, hopefully the diagrams will make more sense next time you look | 00:55 |
| 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:57 |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 00:58 | |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 07:23 | |
| 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 | 07:37 |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has quit ["Leaving."] | 08:02 | |
| -!- Splicer [n=p@h28n3c1o261.bredband.skanova.com] has joined #hplusroadmap | 15:28 | |
| -!- Splicer2 [n=p@h238n1c1o261.bredband.skanova.com] has joined #hplusroadmap | 17:36 | |
| -!- Splicer [n=p@h28n3c1o261.bredband.skanova.com] has quit [Read error: 110 (Connection timed out)] | 17:45 | |
| -!- Splicer2 is now known as Splicer | 18:00 | |
| -!- kanzure [n=bryan@cpe-70-113-54-112.austin.res.rr.com] has joined #hplusroadmap | 18:16 | |
| kanzure | Hey fenn. | 18:18 |
| kanzure | http://heybryan.org/mediawiki/index.php/2008-04-18 | 18:18 |
| kanzure | here's the summary: | 18:18 |
| 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:19 |
| kanzure | I'm thinking of a completely automated fab lab (except with human interaction when necessary, to some requisite degree of precision) | 18:20 |
| fenn | hi. i'm redoin the diagram because i was wrong | 18:24 |
| 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:26 |
| fenn | fully dead is like 'blackboxing', you specify exactly the package you intend to be used | 18:27 |
| 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:28 |
| fenn | obviously we cant do full simulations on (n!) connections in the db | 18:29 |
| fenn | (or can we?) | 18:29 |
| fenn | anyway, i think 'partially dead' is what we're going for | 18:31 |
| kanzure | Paul knows Freeman Dyson personally. | 18:47 |
| kanzure | full simulations / n! is obviously infeasible at this point, yes | 18:47 |
| 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:48 |
| 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:49 |
| fenn | ugh.. thinking is too hard | 18:55 |
| fenn | there's got to be a better way | 18:56 |
| kanzure | haha | 18:56 |
| 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:57 |
| fenn | this is halfway done: http://fennetic.net/pub/irc/autogenix-software2.png | 18:58 |
| 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 ;) | 18:59 |
| 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:00 |
| 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:01 |
| kanzure | nah, was just wondering | 19:02 |
| fenn | well too bad | 19:03 |
| fenn | so, are the class instances the nodes of the graph? | 19:06 |
| 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:14 |
| 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:16 |
| fenn | yes, a project would be a collection of instances of its parts | 19:23 |
| 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:25 |
| 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:27 |
| 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:36 |
| 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:37 |
| kanzure | sure, why not, there's no general requirements for what gets to be a package and not | 19:41 |
| kanzure | as long as they can ultimately be parsed and considered pertainent to the overall goals of skdb, yes? | 19:42 |
| fenn | what are the goals of skdb? | 19:46 |
| fenn | comp got hijacked by munchkins who promptly locked it up solid with tuxracer | 19:47 |
| 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:49 |
| 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:55 |
| kanzure | fenn: please kick me in the ass | 19:57 |
| 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) | 19:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| kanzure | ? | 20:14 |
| 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:19 |
| fenn | at the individual interface level everything is very standardized and specified. that's why all the lib.so.0 stuff | 20:23 |
| 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:24 |
| 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:25 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| fenn | ok | 20:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:43 |
| 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:44 |
| kanzure | I'd genuinely like the graph to be further updated though -- the more specific ideas I've mentioned can do wonders methinks :) | 20:45 |
| kanzure | blah | 20:48 |
| kanzure | if not that, then what's next? | 20:48 |
| fenn | well, graph looks pretty complicated, hard to add much more without it looking busy | 20:53 |
| kanzure | I would suggest splitting the graph then, but then we lose the "at a glance" functionality of the graphiness | 20:54 |
| fenn | can make new diagrams of sub-systems, i guess | 20:55 |
| fenn | what's next mister roadmap? :P | 20:57 |
| 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:58 |
| kanzure | so once we confirm the general taggy descriptions for everything, then I say let's go | 20:59 |
| 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:00 |
| 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:01 |
| kanzure | http://heybryan.org/music/Cradle%20Of%20Filth%20-%20Nymphetamine.mp3 | 21:02 |
| 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:06 |
| fenn | nothing fancy :) | 21:07 |
| fenn | i think i would die if i had to get graphviz to show that | 21:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| kanzure | tell me if this makes sense | 21:16 |
| kanzure | a site with 60 million members has periodic problems with their web services | 21:16 |
| 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:17 |
| kanzure | I'd describe it as neopets for anime fans | 21:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| kanzure | Noah just linked me over to http://cba.mit.edu/events/08.04.ASC/ - looks like David did a presentation yesterday | 21:22 |
| 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:23 |
| fenn | cool stuff, hurray for academia | 21:24 |
| 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:25 |
| kanzure | if I am ever forced to give a lecture, I'm going to immediately turn it into an informal unconference | 21:27 |
| kanzure | nah, nevermind | 21:28 |
| kanzure | I'd enjoy the attention | 21:28 |
| kanzure | my attention is shot - I can either do a block of text or go do something else | 21:30 |
| kanzure | need faster music | 21:31 |
| fenn | why dont you write out descriptions of subsystems | 21:31 |
| kanzure | ten thousand thoughts a second is rather debilitating | 21:32 |
| 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 | 21:59 |
| kanzure | http://heybryan.org/docs/dbz/goku.html hurray for pathetic attempts at writing out vague concepts | 22:26 |
| kanzure | other interpretations of the same character are much too violent | 22:28 |
| kanzure | (don't get me wrong, I can go for violence :)) | 22:29 |
| fenn | goku always seemed a little slow to me, good at heart but no prince vegeta | 22:41 |
| kanzure | in fact, none of them were all that bright | 23:15 |
Generated by irclog2html.py 2.15.0.dev0 by Marius Gedminas - find it at mg.pov.lt!
