[Hplusroadmap] Fwd: Re: Mediawiki file uploads

[Bryan Bishop]

I haven't been too active because of lab work and orientation.
	http://heybryan.org/utorientation2008/

The university had me running around for a week doing busywork. I can't 
get anything done like that. I need my down time. :-)

- Bryan

----------  Forwarded Message  ----------

Subject: Re: Mediawiki file uploads
Date: Sunday 22 June 2008
From: Bryan Bishop <kanzure at gmail.com>
To: openvirgle at googlegroups.com

On Sunday 22 June 2008, mike1937 wrote:
> Hopefully everyone's still reading this after the spam (maybe we
> should just start a new group called FOSS engineering or OSCOMAK or
> whatever).
>
> I came across this page:
> http://meta.wikimedia.org/wiki/Help:Images_and_other_uploaded_files#S
>upported_file_types which implies that you can upload CAD and other
> engineering files to the wiki if the upload feature is enable, I
> checked and it isn't. If that function was turned on and CADs could
> be stored with a link to them on the wiki article, isn't the only
> disadvantage to using the wiki and nothing else some minor features
> of a version control system like git or subversion or both? IMHO they
> would create a minor, easily fixed, inconvenience.

Meh. The other solution is already up and running:

	http://heybryan.org/gitweb.cgi
	http://heybryan.org/biotech.git
	http://heybryan.org/new_exp.html

That's a limited subset of the overall project, but that's no problem.

> Even if I'm horribly confused it looks to me like their are a lot of
> solutions out there and there is no reason one of them wont work
> pretty well for us. I decided to take a look into all this content
> management stuff I was hoping would magicaly go away and in about
> twenty minues found dozens of options that all looked easy to
> implement. All it comes down to is comparing them and choosing one,
> and if the wiki has an easy way to upload CADs there's no reason not
> to just call it good enough for now. Heck, just host the CAD files

Yes, there is very good reason. For one, there's not a really, really 
good open source CAD program out there and the majority of the CAD 
information is going to be proprietary. And it's not entirely easy to 
write up a GUI app for constructing CAD models. Much less even a 
script-based environment for building models -- something that I'd be 
interested in, but I'd need to explore the actual frameworks for CAD 
GUI apps more thoroughly before I go around recommending this [I'm 
pretty sure it'll work].

> Bryan you said you didn't want it to sit on the server doing nothing.
> I don't see how having git and yaml is going to make it "do" anything
> but have an esoteric interface that makes half of the users download
> cygwin. I also don't see anything in yaml that can't be done with the
> semantic features of the halo extension. BTW, can we have an update
> to how that route is going or a link to where we can find one (sorry
> if you already gave one, I can't remember it)? I'm just curious, I
> dislike the route you've chosen but proceeding is up to you and we're
> at the point where we (ok, "I" really) can do my own thing on the
> wiki. And the git/yaml stuff may yet convince me of its superiority.
> This will be the last time I argue about it unless something new
> comes up, I feel like I'm beating a dead horse. Or cow, I can't
> remember the saying.

The real, actual issue at this point is that nobody who is currently 
contributing has information on the manufacturing processes 
(matter/energy conversion, the "unit processes") that we want to 
include. I don't mean that we're being selective ('want') but rather 
that I haven't found anybody that can put in this information yet, and 
I've been slowly accumulating information in some odd areas, here and 
there and such, and while I have some models and variables unfolding in 
my head, there's actually a subset route that I'm going to have to 
recommend -- that 'bioreactor' project that I linked to. It's a subset 
of the overall system, i.e. one project within the overall database, 
and the idea is that this can be used to show what it's all about. It's 
easier to implement too since life is all around us and the materials 
for manipulating these organisms are rapidly dropping. On top of that, 
the organisms are already manufacturing systems to some extent, so it 
makes it all the better. You see, while we could go around finding 
information from Google and throwing it into the database in formalized 
models [which would be awesome in the first place], the issue that will 
develop is simply that we need to relate it to the physical materials 
that we have around is. It's no good if we've come up with a way to 
make a spacecraft out of Unobtainium. :-/ This is no way steering off 
course of the original goals, but it's a direction that is much more 
accessible. A while back I was pointing out some origami applications, 
and I thought they would work out pretty well. In truth, the problem 
that arised was (1) the lack of easily accessible 3D models on the 
internet (sketchup.google.com was not nice to work with, and there are 
only about 100 models in the Blender databases, and then lots of stuff 
to buy over the net, but meh), and then on top of that there is this 
pesky learning curve for blender, which is where I was using the 
unfold/mesh script which would turn the 3D models into the 2D outputs 
for printers (demonstrating the 'manufacturing' aspect to some extent) 
and then with supplementary origami folding instructions (papakura 
instructions) for users to fold (the users are the 'arms' of the 
manufacturing system). This could still work out as a basic 
demonstration, but I haven't gottent it to work (Ben has), and I'm not 
too keen on that whole 'steep learning curve' of Blender, which is 
really off-putting. The idea isn't to do typical 3D modeling -- we're 
doing a bit more than that -- and maybe Blender isn't the best way to 
show this? It can easily give the wrong impression.

> Paul, with the mediawiki that we (or at least I) have decided is
> "good enough" what's the next step? On my little project I get the
> feeling that unless an engineer happens to enjoy spending their days
> typing in random URLs and offers some advice the only way to get much
> farther is to spend a lot of time doing research that said engineer
> can do in half a second, and later spend money doing experiments that
> have already been done but that only said engineer knows about. It
> seems like to get a community you need examples, and to get examples
> you need a community. My current plan is to work until I hit these

Relevant examples:
	1) Papakura / origami
		- tried and 'failed' (sort of - it's still possible, if you want to)
	2) Biotech toolkit
		- you're made up of the stuff :)

> But I've rambled a lot. All I was planning on saying was "can we
> upload CAD files to the wiki?"

Did you see my youtube video?
	http://heybryan.org/exp.html somewhere near the bottom

> http://williamabaris.net78.net/motivationmoralityandcapitalsim.html

Re: motivation. One of my projects is the automation and mechanization 
of motivation, in a sense. See:
	http://heybryan.org/recursion.html
	http://heybryan.org/mediawiki/index.php/Sustained_attention
	http://heybryan.org/mediawiki/index.php/New_comp ;-)
	http://heybryan.org/interfaces.html
	http://heybryan.org/bookmarking.html (esp. last paragraph)

... which says:
> I wrote the above document sometime in 2006 or maybe 2007. I don't
> remember anymore. More recently I have come up with a few solutions
> to the dillemma, involving a synthesis of computational neuroscience
> / biofeedback, squid-proxy, and openmosix. The idea is to use
> clusters to process biofeedback information extracted from the brain,
> the grammar unfolding scenarios that have been proposed by Ted Nelson
> and others, and then as you browse, squid-proxy automatically
> archives everything, unless you specifically delete (via a specific
> key press), information is tagged with the "unused" brain output
> information which can be acquired via EROS, fMRI, MEG, brain implants
> (MEAs), or other forms of neurobiofeedback; as you continue to
> process the information that is coming in at you, the kernel can
> slowly (effortlessly) use the openmosix system to slip/slide
> different programs across the cluster and have it "sift" further down
> and out of your way, but still being ultimately accessible in a
> methodolical, archival manner (known locating scheme). The
> neuroscience/neuroengineering behind the idea of the reduction of
> attentional effort required to do 'hard' things simply implicates the
> reduction of overhead via offloading "unused" information that
> doesn't make it to your fingertips and so on, and then correlating
> that information to do the tagging and "real-time programming" so
> that the functionality of the websites can be more thoroughly
> integrated or whatever, so that they don't just become this 'stale'
> representation of yet another item on the todo list to process, but
> rather something that is actively, immediately digested, with minimal
> overhead in click-click-click form, but maximized retention /
> processing / focus on the relevant tidbits. There is no reason why
> one has to limit himself to one brain per lifetime, and this begins
> to get into the ideas of neurofarms, building brains, and exponential
> growth. On those last two topics, see recursion.html and exp.html;

You continue:
> Becoming self-disciplined is easier said than done.

Heh. So let's automate it.

- Bryan

Something I wrote last night (it's quick):
	http://heybryan.org/2008-06-21.html
________________________________________
http://heybryan.org/

-------------------------------------------------------
________________________________________
http://heybryan.org/