Monthly Archives: October 2011

LibreCAD Wiki Opened

About a month ago the mastermind behind LibreCAD (RVT/ries) and I were talking about the need for a new manual and we settled on the idea of using a wiki as a good place to start. So I set one up. And then didn’t have any time to do much else other than push out a few Fedora and RHEL/SL RPMs, write up a bounce page that explains why/how LibreCAD exists across the web, and put up a quick post about it before the Task Monster caught me by surprise and chained me to a huge amount of extra work in other areas (secure infrastructure expansion and ERP system development — noooo~!).

The wiki was originally closed to public edits because we were really concerned about spam being a problem. Since we weren’t really going to announce the wiki anywhere until we had a decent manual already written (or at least the promising beginnings of one) I didn’t expect any traffic to the wiki — and it doesn’t require much imagination to understand what happens to low-traffic, open-edit wikis tucked in the dusty corners of the web. So I had account creation locked and public edits disallowed.

Well, I was wrong. There has been an enormous amount of traffic to the wiki site, and not primarily by spam bots (which amazes me). There is a huge amount of traffic from people who are looking for a “librecad manual”, a “librecad wiki”, “librecad howto” and “librecad”, in that order. I feel bad about not providing a polished manual already (well, only a little bad, its not like I’m being paid anything for this), and considering the traffic situation it seems that maybe opening edits to the public isn’t as dangerous as I had originally thought.

So I opened things up today and we’ll see where this leads. In the event that spam fighting gets to be too time consuming I’ll just close it off again. That would be a pity, but its the nature of dealing with anything “pubic”.

Not Really Forking Tryton

I have a customer in desperate need of a service that a customized deployment of Tryton can provide. This is a normal thing in Tryton Land. In fact, Tryton itself is merely a framework and useless without extensive module installation. But even with quite a lot of module installation Tryton is generally still useless, and indeed requires an ERP expert’s (or more likely a team of ERP experts’) attention to do anything positive for a business.

The reasons for that are pretty basic. On the one hand every business is pretty different from any other business, and the use cases for an ERP system are so varied that there is almost no way the same ERP solution would ever fit everybody. On the other hand, some of the design decisions embodied in Tryton seem to conspire at times to make default/raw deployments of Tryton particularly user unfriendly even for basic use cases like double-entry accounting or just organizing customer contact information.

But again, Tryton never claimed to be anything other than a framework — the canonical modules provided at the centrol Tryton repo were never purported to be anything more than a free, example-oriented fleshing out of the underlying bones.

And that brings me to what I’m about this month. I have a semi-urgent need to get some major time sinks my customer is experiencing to go away and Tryton is not just a good way to do this in the short-term, it is also a great way to start them on the road to solving a lot of time-wasting, ankle-biter problems across the long-term as well because of the way data work can be centralized in a single system this way.

I mentioned above that there are a few awkward-seeming design features to Tryton. That is true for nearly every project, particularly open source ones where it isn’t very unusual for too many cooks to be spoiling many versions of the same family of broth willy-nilly (and occasionally producing masterpieces in the chaos — which is the real point).

But there is a different set of unfortunate situations surrounding Tryton development, problems that cause Tryton to be a little bit confusing to bugtrack, follow development, contribute to, etc. The first problem is the choice of version control system.

Most projects, including the Linux kernel and LibreCAD are developed using Git, and a huge number of such projects either are fully hosted on sites such as GitHub or SourceForge or at least show their face one of the two places (or both). But Tryton uses Mercurial for version control, which drives some developers away (it would have driven me away as well if Tryton weren’t as perfect a fit for my client).

The big issue here is that Mercurial does nearly exactly the same things as Git, in nearly exactly the same way, but colors its nearly identical commands in slighly incompatible ways in an attempt to appear to not be a Git clone and the documentation is laced with (inaccurate) FUD on Git and SVN, which just makes reading it try my patience (and if the comments on the site are any indication I’m not alone). The functional differences between the two being minimal, the presence of two similar, competing systems makes learning the otherwise trivial differences between the two irritating and merely a pain in the ass rather than being something forward and productive to do.

The other major problem with Mercurial is that while it does provide built-in features to make serving private repositories via Apache or other webservers realtively easy, almost nobody does this in practice — and when people do serve their own getting access to actually push to the project is a much more convoluted process than simply doing it on a content management site such as SourceForge or GitHub which already have well understood, well documented and easily discoverable mechanisms for publicly forking, pulling, branching and pushing branches and changes around wherever one likes. People get more antcy about hosting everyone’s forks publicly when its their own “private” repo they are hosting on their own hardware. That is just human nature, but it really makes open source projects turn very closed in a sense.

There is, sort of, a place to do this at, but despite the benefit of a cool name, the site itself is rather opaque and weird to use — and breaks down (today, for example, even the FAQ/help page gave me 403 errors). As is somewhat normal for open source projects, the existence of Tryton as a project extends way beyond intuxication. The problem, though, is that Tryton is abnormally nebulous in nature and to a newcomer is very difficult to track — actually, it extends to far that finding all of it across the web is a sub-task of its own — and there is no bounce page maintained anywhere I could find that explains the situation, and much of the existing wiki documentation is not very up to date (part of this being because the wiki is maintained at google and seems to have a very limited set of eligible editors, a pain I fully sympathize with…).

So all of this sucks.

Without spending any more time getting into details I am simply going to state that for the above reasons and others related to the difficulty/complexity of contributing directly to Tryton as a project and getting modules included in the central repo I am putting up a Tryton repo on GitHub, based on the changes I need to make for my client. This is not a fork of Tryton, however. I am not proposing to hack on core Tryton code, or even make big changes to existing key modules (I was originally intending to, but Udo Spallek graciously showed me that this is not as necessary as I originally thought it to be).

So my GitHub goals are not to fork the project, but rather to provide a public window into my otherwise private Tryton module customization and development in a way that is easier to access, understand and contribute to than the current canonical Tryton project. By the end of my project I intend to have a working set of features that include a pass management module (“pass” as in access and vehicle passes/badges for access to restricted areas that expire on a set timeline), contract management module that links to projects, a way for heirarchal groups of parties to relate to one another in a customer -> prime -> super -> sub-contractor sort of relationship (strongly tied to the functionality necessary for contracts and projects to work correctly), and new features to handle the quirks inherent in Japanese language environments where up to four spellings of the same name are correct and should be uniformly searchable.

That’s a lot of work. Its a lot of testing. I don’t have all year to discuss this with a committee, either. So I’m putting this on GitHub as a public window into my private efforts against this problem set, again, not as an actual fork of Tryton. Hopefully once the dust settles I’ll have a set of features that is workable enough to push for inclusion back into the central Tryton project. Of course, GitHub being what it is it wouldn’t be unusual at all for others to fork things on their own and play around — but that’s the beauty of a place like GitHub.

Gravity: Not what it does, what it causes

In addition to the LibreCAD thing, OS support stuff, etc. I’m also working on an ERP solution for my clients. This solution has an enormous number of obvious advantages over the way they are using software right now, but it requires me as an individual to understand how their business works better than any individual in that company does (or at least it seems that way after talking with all the different section leaders over there). My thinking about their problems and how to model them accurately in an ERP system leads me back to the problems that can be solved in my own company by a similar system, which leads me to the idea of generalization of functions and rules. This is, of course, the goal of good software design, but without spending some time reflecting on the nature of problems, the nature of data, and the nature of computing it is impossible to identify the parts that can be correctly be said to be general to all problems of a similar type, and what elements remain that make the specific problem at hand unique and identify it as that specific problem and not the same problem also found somewhere else.

This is, in a sense, what must be done when designing general functions, or correct object design, or deciding what utilities and handy tools should be considered to be “system utilities” and what other are just niche applications or personal tools. The concept of classification implies description, and at a certain level specifying a problem implies the ready resolution of the same problem (pretty neat!). But many times we get the identification of the problem wrong. More correctly, we inadequetely or incorrectly specify a problem and then develop whatever solution naturally follows from this mistaken version of the problem as we (wrongly) understand it.

As I was driving home in the rain today I was thinking about this — both the nature of the specific problems my ERP system needs to solve for the customer and the nature of problem classification itself. This led to a thought on how the precise, yet incorrect understanding of problems can lead to silly things like the widely misquoted statement “mathematics/physics states that bees can’t fly.” But quite clearly they do — which means neither mathematics nor physics is what says bees can’t fly, but rather an inaccurate mathematical model of flight predicts that bees can’t fly. But the misquote above is the more popular concept (its more fun, anyway, because it leaves the door open to magical thinking and the world of foolish mystery). The problem with this thinking is not just that it misleads people into thinking that math and physics don’t work — it also personifies math and physics (as in, creates the idea that “they” are beings of some sort who would attempt to prevent bees from flying as if the “can’t” in the misquote relates to the idea of permission) in a way that is weird and leads to more wrong thinking later. That idea led me down a mental journey into physics and I recalled an article I read recently about M-theory, gravity and General Relativity — and, specifically, the parts in the article that relate to the idea that gravity might be repulsive at great distances.

So… Gravity, at great distances, is it repulsive? Does this make sense? Or is there, perhaps, a misconception of the problem space here? There quite definitely is a miconception of the problem — that is evident in our inability to describe gravity in a mathematically consistent way that reconciles relativity with quantum physics. But what sort of misconception? I’m not part of the physics community, but from the way articles written for the layman put things (which is highly suspect) it seems as though people are personifying gravity a bit much. In other words, they are looking for what gravity “does” and from that trying to derive an accurate model of how gravity does that instead of thinking about what gravitiy “is” and then following the path of consequences to its existence.

The four basic forces (weak atomic, strong atomic, electromagnetic and gravity) are fairly well established. Interactions of things (space/matter/energy) those forces have to explain all phenomena — and so far pretty much do, which indicates that this is likely a correctish concept of the way things are. There doesn’t seem to be room for a fifth basic force, though there may be room for more things or types of things with which they might interact or ways they might interact (that is, unthought of dimensions, unobserved particles, etc, but not new forces themselves).

So… Gravity. It a sense it is a side effect of what happens when you concentrate mass in a single place. We say it “curves” space, though the way I tend to picture this in my mind is more of compression that bending, because bending can only happen to things that are truly unbounded, and space seems to be bounded by itself. The most common demonstration is to take a taught, suspended sheet and place something heavy on it, and then say “like this, it bends the surface down” and then the path of a marble on the sheet when rolled across tends towards the heavy thing. But this is a massive oversimplification.

If we take the suspended sheet as a 2D object then the downward direction that it bends to when something is placed on it represents a third dimension for that thing to bend “to” — hence it is bendable because it is unbounded in a new direction. The situation with space and gravity doesn’t seem to be the same because while we are fairly certain there are far more than 3 simple dimensions, we’re not being told to imagine that space itself bends in a 4th extra direction due to the influence of gravity/the presence of mass.

Another problem is the reason for the bending. Space is being directly influenced by the presence of matter via gravity, wheras the sheet is being influenced by something pressing on it. In other words, to get something to bend in an extra direction/new dimension it must be pushed, not contracted. So space under the influence of gravity behaves more the way that a wet cotton sheet contracts towards a spot that warm, dry air is applied to while the wet remainder stays lose and stretched out than the way that a sheet with something heavy on gets forced down in a single spot by the heavy thing.

And another problem with this sheet example is the rolling of the marble in an attempt to explain how things get drawn toward “gravity wells” in the same way the marble gets drawn to the lower points of the sheet. In the case of gravity the path of something under the influence of inertia is to continue moving in a straight line. But the straightness of that line is through space and gravity has contracted space into a smaller area than it normally would have been (or at least it appears so) and so the “straight” line is now curved relative to things that aren’t as local to the mass as the moving thing is. With the sheet example the path of the marble is actually longer than the original path, so this is a mis-example.

So this explanation and concepts derived from it are wrong. Now let’s return to the 2D sheet, because the number of dimensions really isn’t important here. If we were to draw a straight grid on it (or just a bunch of uniformly even or uniformly random dots), get it wet and then apply a hairdryer to a single part of it, we would start to see a subtle warping of the lines on the sheet, though over the whole sheet the size and general shape of things would remain the same. Now if we traced a line from one side to the other we would continue on that line just fine, but our path would bend toward the point we applied the hairdryer (interestingly, using a bounded space/area the path bends, but the medium itself does not, it just contracts in an area).

A more extreme example (and the one that came to mine while driving) was the shrink wrap we used to use when I was a teenager working at a video store. We would put items for sale into a polymer bag, and then blow hot air on the bag to make it shrink down. Being michievious kids we would sometimes experiment on down times with the stuff, and found that you could really make some weird things happen by blasting select spots of a large, flat sheet of the wrap material when spread out against the wall or floor. We were forcing local contractions on a self-bound 2D plane when we did this on material that was stretched out flat.

What does this have to do with gravity and localized attraction vs distant repulsion? Everything. If we blow hot air at points opposite one another on the same stretched out sheet the wrap material in between the two sheets get stretched tigher. Anything point that is closer to one point than another is pulled away from the center and toward the opposite point — relatively speaking this means that a point that is distant enough from one spot is traveling away from it. And this happens despite the fact that our actual influence on the sheet is constrictive in nature — all pull and no push. If space behaves in anything approaching this, then gravity can easily have a secondary effect of causing points beyond a certain distance from one another to grow further apart and yet not have any properties of repulsion at all. This increasing distance of points beyond a certain distance also does not require that the sheet continues to expand overall, either. That the universe itself likely is expanding just confuses the issue a bit more.

To a tiny observer on a whirling rock out in deep cold space this effect could definitely look forbiddingly like an unfriendly “push” effect to gravity. If that observer were prone to personify elements of existence (in other words, assign blame for effects on them) then it would be very natural to blame the observed possible increasing rate of expansion of the universe on a property of gravity rather than on an indirect effect or condition that it causes. One effect per force makes more sense than having a magical force that somehow exhibits one behavior in one place and yet another in another place.

Of course, the mental idea above that space doesn’t “bend” is going to probably bother people who carry with them a mental model of space as a bendy thing, and of blackholes as places where space “folds back on itself” when contraction is really the issue. The mental picture of a black hole just gets all screwy then — but this is probably more correct, not less. Anyway, with teeny tiny dimensions apparently being all over yet so small in scale, yet so universal because they represent entire dimensional planes that have been prevented from much direct interaction with our normal Euclidian(ish) selves, it seems likely that perhaps the folded up space stuff that makes up matter and energy might just be manifestations of tiny black holes compressed in directions that are just not a part of our 3 spacial dimensions, and all those black holes bubbling in and out of existence could have a lot to do with the basics of why/how all subatomics are unstable, yet predictably so. But that is a whole different discussion.

I am completely unqualified to make any statements about physics anyway, but these were the thoughts that went through my mind as I drove home in the rain. Unfortunately I’ll probably never have the time to really study physics, so the common crap written in the press for the layman (this includes most “science magazines” as well) are all I’ll likely ever get a chance to read and be mislead into dumb mental models like the ones above by.