Hallo,
>- what features should LinuxCNC3 have
>- when, how, and after which preconditions ticked off should planning and
work on LinuxCNC 3 start
To guide these 2 processes I think I should quote something I found in
Edsger Dijkstra, long ago:
"The price of reliability is the pursuit of the utmost simplicity.
It is a price which the very rich find most hard to pay."
Sir Antony
Hoare, 1980
So I guess lets leave the holy cows out on the grass for a bit, and think
this issue through, little bit by little bit. Mindful of Sir Antony Hoare.
Lets take each part of EMC and strip it to the bare minimum requirements.
See how we could implement it in such a way that it will be easy to
acommodate wishes from another quarter, or indeed embellishments that exist
at this moment inside EMC.
After we have found this minimum implementation (even if it is only in
block diagram form) we might make a list for each part of EMC of te various
embellishments that people feel they cannot live without. And see how that
could easily be implemented into the minimum structure in such a way that
the *utmost simplicity* and thus the *reliability* are not compromised.
(I repeat: the criterium will not be: "but I need this!" rather the
criterium will be: "how is this *simple* and *reliable*!")
A few cycles of this process will reveal the most beautiful CNC software
ever written.
Cheers,
j.
On Sat, Aug 11, 2012 at 3:04 PM, Michael Haberler <mai...@mah.priv.at>wrote:
> 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
>
------------------------------------------------------------------------------
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
