I think we have at least two discussions going on in the same thread: - what features should LinuxCNC3 have - when, how, and after which preconditions ticked off should planning and work on LinuxCNC 3 start
It is wonderful and lusty to muse on the first item on end, but my point to start with was: I by now firmly believe there are some not-so-lusty preconditions and decisions to be looked at (2), and work done, before (1) becomes more than a blue-sky exercise without much consequence. This conclusion is driven by the following observations: 1. there are several software parts in the software which are a legacy 2. there are several structural and design decisions which may have been warranted at the time, but are due for review 3. the two of the above restrict the development model to a - lets call it 'very incremental change' - model; others might call less friendly 'patching around' 4. the LinuxCNC license situation puts severe restrictions on how 1) can be addressed without scratch rewrite of a replacement component - in the face of existing viable alternatives. I am happy to outline in detail why I arrive at these conclusions but I probably should do that in separate email, or a wiki page. With respect to 4), let me only say that I'm not putting the blame on someone's doorstep here; things just happen and much of this issue at hand derives from the bizarre license compatibility situation in the FLOSS space. I do have an opinion on these wars, and some of the acting persons, and not necessarily positive - but that's irrelevant. The only thing which counts is to remove any roadblocks wrt to the LinuxCNC future, and I feel that cannot be done without movement on our side. As I said, I'm willing to take on a bit of a study which triages and gauges the issues, like - which parts are essential carrying forward; which might need a license change, which size of developer consent would be required to achieve that. That can be a basis for an informed decision to go forward. A quick preview actually shows that HAL and RTAPI come from very small subsets of the developers; component infrastructure: a bit more but 'looks doable'. I need to do this more thorough. I will tag the next thread clearly whether it belongs to the first or second issue at the top. - Michael --- ps: wrt to the performance discussion it is instructive to read http://git.mah.priv.at/gitweb/emc2-dev.git/commit/645bcebd3382c1686367b686c3b815372f071b78, which in essence says: up to Sept 1 2006 your hypothetical 100-million-lines-a-second interpreter was limited to an actual speed of about 30 blocks/second by the way task scheduled the interpreter. Historians: was there a sigh of relief after this patch? I wasnt around at the time. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
