Adding ref to forks of LinuxCNC

[smoe]

This is more like a request for discussion, not so much a request to immediately merge this - although I do not see that it could not be merged. I found that all forks of LinuxCNC are declaring their provenance. And conversely, LinuxCNC should point to where LinuxCNC is hiding underneath.

Our LinuxCNC-derivative maintainers should be aware that LinuxCNC is likely to see the changes from other forks ported back. It would then be of interest for the derivative to remain (mostly) code-compatible with LinuxCNC-proper to merge these other changes back in. Such pointers to derivatives on the LinuxCNC website helps to ensure that every LinuxCNC-user works with the flavour of LinuxCNC that best matches their needs. Lots of "win"s for LinuxCNC, the derivatives, and foremost our users.

[jepler]

As I mentioned on IRC I think this is a great positive step that LinuxCNC can take to acknowledge work others are doing on the software. I'm not sure what "to mind come" means.

[smoe]

"to mind come" was meant as an indication that there is much more and someone more knowledgeable than me should complete the descriptions.

[silopolis]

This is genuinely excellent!
May this seed an ecosystem of collaborating projects 🙏
@cerna maybe you could give us more accurate infos about MK?

[cerna]

@cerna maybe you could give us more accurate infos about MK?

Not sure what would be the best explanation for Machinekit. I think it should be to the point (read short) as to not unnecessary confuse newcomers to the LinuxCNC project. To this point I (as a person with personal opinion) see the MK endeavor targeted more to the developer segment as opposed to the Ordinary-Joe-User one.

1. Control is allowed to run on small machine: I don't think the size of machine has to do anything with it. Maybe you meant size of the controller hardware, as in SBC, as in ARM powered boards? Well, LinuxCNC caught up in this regard.
2. Contact to controller possible via USB: There were people developing USB connected controller, true, but I have no idea where that idea/product is right now.

What I think is interesting:

1. Trying to decouple the parts into isolated functional blocks: The focus is no longer the CNC controller, but the CNC is just one application. There is - for example - the tormach/hal_ros_control for connecting to the ROS (I, soon II).
2. The Machinetalk remote communication protocol (bit bitrotten at the moment)
3. (Hopefully) more clear repository structure

[silopolis]

Le mar. 4 janv. 2022 à 01:39, cerna ***@***.***> a écrit :

What I think is interesting: 1. Trying to decouple the parts into isolated functional blocks: The focus is no longer the CNC controller, but the CNC is just one application. There is - for example - the github.com/tormach/hal_ros_control <http://tormach/hal_ros_control> for connecting to the ROS (I, soon II). 2. The Machinetalk remote communication protocol (bit bitrotten at the moment) 3. (Hopefully) more clear repository structure

All the reasons I hope MK to be a prospective spinoff with innovations to be merged back into LCNC once they're ready! First one on the list should be HAL "modularization" and then pushing point 1 into every subsystem, making them pluggable with clean documented interfaces. I see point point 3 as an infrastructure work going along 1. Then point 2 is surely a great promise too! Along with some kind of distributed storage like redis, it could do wonders I believe! Keep up the great work 👍💪

[smoe]

@SebKuzminsky , could you please comment? I would also like to a section on (almost) free and very non-free alternatives to LinuxCNC(-based projects). What I would then also want to link are reports on how well a migration of any of these more commercial alternatives from or to LinuxCNC went.