Help me understand: relation between LinuxCNC and Linux OSs.

I'm stuck at Ubuntu 12.04 LTS, which went EOL in 2017. (I've been getting regular security warnings about the need to upgrade.)

I started out with LinuxCNC 2.4 on Ubuntu 10.04 LTS as I recall, and it all worked, but again as I recall, 12.04 was already pretty long in the tooth when I upgraded to 2.6/12.04.

Somewhere in the back of my mind I seem to think that I've been waiting for a LinuxCNC paradigm shift (to "machinekit"?), but among 2.7 versions offered (thank you, developers) I see the familiar RTAI (parallel-port) and RT-PREEMPT (FPGA-card/Mesa) bases. (I am indebted to this reply for that insight.)

However, what I do see , which is unfamiliar, are clues that [favored?] development?/distribution? platform for LinuxCNC changed from Ubuntu to Debian--in the sense that the 2.7 branch is available on more recent branches of Debian (Stretch/9, released 2017) than on Ubuntu (Precise/12.04, released 2012).

[I'm having difficulty figuring out what I want to ask. If the following questions seem un-sane, please substitute freely.]
Q1. Is a real-time-version of LinuxCNC for a "more recent" Ubuntu comtemplated?
Q1.1. As it seems that availability of LinuxCNC on "latest" Linux OS versions requires the availability of a real-time-version of that OS kernel, what does it take to produce the latter?
Q1.1.1. What's the holdup? ;^)

Q2. Will a Debian-based version install and run under a "suitably recent" version of Ubuntu--because (it is my understanding) "Ubuntu is built on Debian?"
A2. No. [I'll take this one...]
It was an ignorant question, answered by ruminating on the distribution tables at buildbot ; for example, the following entry:
Precise (realtime with RTAI)
architectures: i386
means, "if you want to run LinuxCNC in Ubuntu, you will need to install the "realtime Precise(12.04) kernel built with RTAI which will only run on i386 architectures." A different pkg allows simulation on general, 64-bit kernels.

That said then, "if you want to run LinuxCNC on the latest-supported 64-bit Linux, you'll need to install the Uspace version of Debian Stretch/9 first." (More options and how-to on gnipsel.com .)

"Machinekit" is listed as a "See also" in the Wikipedia article on LinuxCNC . Suddenly, I recall that machinekit was suggested as a way to free LinuxCNC installation from the requirement to produce a RT version of a current Linux kernel--but see note above.

Q3. Is there collaboration between Machinekit and LinuxCNC development?

Finally, I realized that have competing goals. I want to keep my OS current in order to "stay safe", but I "need" to access my LinuxCNC machine from my local network, so it's 'online' in that sense, and gee-it-would-be-nice-if I could do-some-stuff while sitting at the LinuxCNC machine, waiting for a job to finish. That last means there's going to be a temptation to install latest cool-apps--probably whacking LinuxCNC's response time--which of course I'll never bother to check again after the initial install...

"How about I promise" to "just" keep the LinuxCNC RT environment "pure"? Can I have a version that will run in the latest-model/most-secure OS? :^)

Thank you for reading. And thank you for the support. And for the particular brilliance of LinuxCNC.
--
The CNC Zane

I think one key issue that needs clarifying is what brand of realtime kernel are you looking to use - RTAI or RT_PREEMPT?

"RTAI (parallel-port) and RT-PREEMPT (FPGA-card/Mesa)".
please note that this isn't necessarily true: depending on your needs from the CNC machine, and depending on the hardware you use for your PC, a rt-preempt may very well work with a parallel port configuration.
I'd suggest checking this, as using the rt-preempt kernel will allow you to use much more up-to-date kernel versions.

The change of the distro was before my time but driven by licensing requirements. Strict interpretation of the GPL license by Ubuntu meant that Linuxcnc was unable to continue to create ISO based on that distro.

As various old distros have gone end of life, its become increasingly harder for the dev team to support RTAI for par ports as prerequisites moved repos or were retired. I think they finally got it going again recently.

For modern hardware PREEMPT_RT is a better option but it won't be usable on older hardware.

If you learn to compile from source, you can basically run from any distro you want if you first patch the kernel with a real time variant.

@gambaf
My preference is to be in a position to keep the underlying OS 'recent' so that security patches can be duly applied. The older the OS, the less likely it is to see patches developed and the more likely it will be to have undiscovered holes discovered by perps.

It may be that Everyone But Me Knows That's Stupid, and if so tell me and tell me why. I do have the LAN behind a firewall (behind a firewall), but of course there's always a danger I'm inviting something in which will savage and ravage the local network anyway... I develop my stuff in one, comfortable room and scp it to the noisy, work room. If the CNC computer has to be off the network then I'll has to resort to sneakernet.

I don't have a preference for RTAI or RT_PREEMPT, which is to say, in pursuit of the Prime Directive (to keep the OS patchable), if I have to buy a Mesa card or move to one RT kernel or the other, I'll do it.

In my case, I had a ChineNC that came with an interface that had what looked like an ancient PC gameport connector and some goofy interface: NG-something as I recall. (Later discovered the method behind the madness: apparently the gameport spec includes 5V, whereas the parport does not. Who knew?) I stripped it out, bought a "Mach3 controller board" from ebay and rewired it for parallel port operation--having to supply a USB jumper alongside to get 5V to the controller from the PC--with LinuxCNC.

Well you could try the Linuxcnc stretch PREEMPT_RT distro here
www.linuxcnc.org/testing-stretch-rtpreempt/

The only caviat is that on old 32 bit hardware, I found this unusable due to latency. This is less important with mesa hardware as it does not require the base thread for step generation.