On 2020-04-02 03:14, Przemek Klosowski wrote:
On Wed, Feb 19, 2020 at 1:51 AM Rafael Skodlar <ra...@linwin.com> wrote:


Think about LinuxCNC and it's packages. Using Slackware method you could
try to use different version of LCNC to see if it's good for your CNC
setup. If the new version fails (breaks your tool?) you could run
"cnc-admin script" to roll back, i.e. relink the app to previous version
and start it.

/opt/linuxcnc-v2.6/bin  <- binaries or scripts
/opt/linuxcnc-v2.6/etc  <- config files
...



/opt/linuxcnc-v2.7/bin
/opt/linuxcnc-v2.7/etc
...

What you suggest is not that simple. For starters, there are cross-package

It's simpler than have a full blown workstation to do the work of what a much smaller distribution could do. Now you have to manage much larger number of packages.

ls /usr/lib/ | grep python
python2.7
python3
python3.6
python3.7
python3.8

You just tell which one you want to use and all is fine. Same can be done with other software.

I believe that LinuxCNC would benefit with using Yocto because you can build software for different platforms at the same time. Used widely in automobile industry, avionics, and robotics as well.

dependencies, so in general you will have to carry various system libraries
required by each version. Then, modern programs use various forms of IPC,

We already have different versions of libs. Ever looked under */libs*?

Anaconda is the best utility to manage different versions of python in user space. Yocto takes it to another level.

so they need version specific versions of those IPC endpoints (things like
DBus, etc). IN the end, you can do it, but you replicate huge parts of the
OS. RedHat/Fedora tried to do Modularity, which is something like what you
propose except it turned out that you could have multi-version availability
but not multiversion installability (it was easy to switch versions, but
you could install only one). They put a lot of effort into making
dependencies work automatically, but in the end it turns out that lifecycle
management (patching/updating) is hard in a multi-version world: multiple
versions of multiple programs lead to combinatorial explosion of
dependencies and unresolvable conflicts when one program depends on ver. X
of something and another one on ver. Y. Currently Modularity is in retreat.


Software written so tight that it works only with a certain library but not on a newer one is just bad software. I hear this from other engineers developing for large software houses here in Silicon Valley.

The technology to do that exists---containers like Docker or Podman. The
downside is that your system is now a mess of versions, and you need to

What mess??? It's a flexible design that solves dependencies issues. When setup right it works automagically.

worry about patching and updating them. Containers provide a partial
solution to the Modularity problems---you can isolate such conflicts to
separate containers, but you still need to worry about lifecycle management.

If you are serious about those issues, read up on containers and
modularity---don't invent your own solutions, as a lot of people tried to
do it right and it's worth to learn from their experiences.

Using your logic nobody would ever invent or improve anything. So what if they failed? Somebody with make a difference then others will follow as usual.

When you spend as much time using and managing virtualization on servers as long as I have, install and setup containers etc. then ... I got tired of this kind of responses when you don't read on the subject matter before telling me I don't know anything.

The fact is that LinuxCNC is a mess in a sense because too many insist on basic real time functionality and top it off with full GUI instead of advancing from that original architecture. It helps if you study what large commercial manufacturers of CNC machines make. I provided links to some already.

How about telling others to go read about going metric and stop using STUPID system that is based on hundreds years dead British king butt or finger size?

G-code is archaic also. It's like programing PCs in assembly language in 1980s. Some bad things just never die.

--
Rafael
Linux specialist since 1994


_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to