On Wed, 12 Jun 2013 16:27:24 +0200
Michael Haberler <[email protected]> wrote:
> The question I would have is: how relevant is that comparison - and
> the case you cite - anywhere relevant to 'inhibiting use of LinuxCNC'?
I think Dave's point was that we've only experienced one "brush with
the law" so far, and that if things go well for us we can expect more
of them. He wasn't trying to connect the name change issue with the
current subject ('inhibiting use of LinuxCNC').
> Please describe a comprehensible example attack vector, I have
> problems imagining 'what could'.
We can talk about this in detail next week, but here's an example: Way
back when, Fred Proctor & I were trying to extend EMC to control
stepper motors. We were having no luck at all, primarily because we (I)
didn't really understand the problem. At one point I had the idea of
treating the stepper motors like servos. Instead of the motion system
sending _position_ commands, and essentially "navigating by dead
reckoning", I suggested sending _velocity_ commands just like you do
with servos and having the step pulse generating code keep track of the
actual pulses it had sent out in real time. This pulse count was fed
back to the motion module just like encoder position would be in a
servo system. If you are really interested look up 'steppermod' and
'freqmod' which are the position and velocity control methods
respectively. AFAIK the 'freqmod' method is still used in linuxcnc
today, although brighter brains than me have added to and further
refined the implementation.
Now, although I think I invented this concept, I have no idea if that's
true. This could be covered by a patent somewhere in the world. There
could be other methods used in linuxcnc that infringe on someone's
patent.
> If one is really concerned about such theoretical problems, which
> they are as I view them, I would suggest two practical action items
> to follow through which improve the project's capability to withstand
> such vectors besides yielding other very practical benefits. Those
> are:
>
> (1) modularize and slice-and-dice critical components, which might
> mean introducing new API's. Better modularisation reduces the damage
> done by throwing out disputed code (and we would already benefit now
> if we had more of that).
>
> As an example, I would rather have 5 implementations of motion each
> composed of a few smaller comps than a single one. Take the current
> motion module out: things grind to a halt.
>
> (2) encourage, and take appropriate steps regarding licensing, to
> maximize adoption by commercial users - that is, companies whose
> revenue depend on LinuxCNC remaining freely available.
>
> Besides other obvious advantages, that has the upside of enlargening
> the army, including attached coffers, which fights on your side when
> push comes to shove.
I couldn't agree more and I promise to help make these things happen.
Thanks,
Matt
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
