Charles, On 1/16/2014 11:03 AM, Charles Steinkuehler wrote: > Either way, I don't really think the ARM/x86 platform key belongs in > the configuration selector at all. Then I guess we are at really opposite points of view on this topic.
Let's take a bit little tip in the way back machine.... in the olden days EMC (I use that name as that is what it was called during the time I refer to) was not anywhere near as much of a platform specific project as it is today. It started out designed to be able to run a variety of hdw+sftw platforms. It was only as time has passed by that a particular hardware/software came to dominate EMC installations: the X86 PC + Linux combination. Today that hdw/sftw platform is so intertwined with EMC/LCNC that the idea that you might want to run EMC (or at least parts of it) on a non-linux platform combination will likely get may get one receiving derisive mailing list comments. An example from fairly recent history: Consider that this is so much a "fish being unaware of water situation" that when EMC corp came along and panicked the herd into a renaming stampede, the "obvious" name became *_Linux_*CNC. Yet conceptually Linux is far from a single OS environment and is only one software (family) environment that EMC could be applicable to. (Side bar contemplation: I have no idea how to refer to LinuxCNC that has one, or more, or all, modules not running on Linux anymore - what will we call such an animal?!? ) There are lots of assumptions that come along with the x86+PC choice - and they strongly color all the design decisions that get made within the project. Example: I suspect that no one thinks that making LCNC more dependent on Linux could possibly be a topic for much discussion, let alone a bad idea. The community takes the path of least resistance - we don't even talk much about what flavors of Linux that LinuxCNC will run with. The reality is that the project has a strong tendency to gravitate toward Ubuntu or Debian flavors. I see that the default attitude tends to be that if it does not work on Linux flavors that are more removed from Debian derivatives, then it's the OS flavor that is at fault (it must have not implemented something correctly - i.e. "correct" == the way Debian does things). This autopilot approach to hdw+sftw platform has worked OK for many years - in large part it has been pushed along by the economics of PC hardware. But computing economics have shifted... and now we are seeing interest in what I'll call "embedded CNC" and "distributed CNC". In the LCNC space this has manifested as the interest in BeagleBone and RasPi as SOC oriented hardware platforms. Yet this combination does not fit the unstated PC+Debian flavored Linux combo so nicely - it chafes a bit. I know you've seen that first hand in dealing with the AM335x Angstrom patches into machine kit stuff. As the OS assumption drifts away from PC + Debian or Ubuntu, things fit less well. Consider Machinekit: One consequence of where we are today is that the machinekit stuff lives on SD cards and runs Debian. There is a cost associated with that: we can't run LCNC on the Angstrom flavor of linux that comes on a BBB and we can run from the built in eMMC. That's an example where the OS assumptions (even within the Linux family) have added cost (SD card) and removed functionality (can't pare it down to run from eMMC). The monolithic PC platform has done (IMHO, with the aid of hindsight) great damage to the modularity of LCNC. (I know some will remember that EMC ran on Windows in the early days and that this was not considered a bad thing.) The decrease in modularity and increase in pc+Linux platform dependence didn't happen all at once, but, slowly over years (the same way many entities get addicted to substances). Consider again the BBB and the "problems" around graphics performance and GUIs for LCNC. These are only issues if you start from the assertion that everything runs on the single CPU in the (assumed) monolithic PC platform (which is the base assumption implicit in much of LCNC today). If you think of a BBB as a little PC you get one set of conclusions. If you think of it as a platform well suited to runs parts (but not all) of LCNC, you get different conclusions. For an embedded or distributed CNC widget, why does _the _gui (for for that matter _any _gui (or X server) ) have to be running on the BBB? Look at your own recent interest in a non-X gui. That does not fit the PC + Linux assumptions as well, and you found the pickings slim. I tend to see these issues as attempts to fit the PC driven square peg assumptions into the embedded CNC round hole. Another example: Think about how AXIS reaches down into LCNC internal structures to do some of what it does. It was (IHMO) not the best decision to do that, but it was easy to do - and so human nature won and it came to be - and it's served it's intended audience well. I will note that it was only possible to do because all the LCNC modules were (known) to be running on the single monolithic PC platform. Now split up LCNC differently as to what runs where and the AXIS tricks are not as attractive. Rhetorical question: Would Axis's authors have made the same choices if there were a significant number of non-PC EMC installations at that time? One of the reasons I'm interested in Michael's re-architecture work is that it offers a chance to undo some of this insidious binding to PC assumptions. As an example, the judicious application of ZMQ to create module interfaces could allow this to happen without negatively impacting the LCNC PC platform installed base. I also think that Putting the modularity back into LCNC enables lots of new non-PC platforms and I see the future for LCNC involving many platforms that are not PCs. Accordingly I would like to see LCNC become less PC dependent. But for that to have any chance, we fish have to become aware of the water we swim in. So, I think that it's really important that we start realizing that PCs (and all that a PC implies) are NOT the only target for LCNC. I honestly don't think that a config structure oriented around Mill/lathe then a hardware interface is sufficiently cognizant of the possibilities of modular/distributed CNC. While while the X86 and ARM stuff is similar today, that's because it has to be... technical evolution has not yet had time to drive the modifications that will make these diverge further apart than they are today. I think we do ourselves a favor if we organize (at least as a start) along "PC assumption made here" and "PC assumptions are no longer constraints here". The easiest way to do that is to let X86 PC configs handle the legacy and installed base, while we let the ARM based SOC stuff be more distinct and more free to grow different ways. Dave ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
