Prefered linux distribution

[Randy_H]

So right now we support 3 distributions (RHEL, Scientific Linux, and openSuSE) and 2 versions of each (latest and one back). That gives us 6 total. Would you suggest fewer than that? Also, at what frequency would you suggest updates (2, 4, or 6 times per year for example)? Thank you.

[2verb]

Maybe the way to solve the Linux distro complexity issue is for NI to create their own Linux distro.

[AKHuettel]

Actually, the best way would be to cooperate with the packagers from existing distributions, or at least make it legal for them to help out. See this thread for the detailed legalese issue. Then, most of the "distribution support issues" that I've come across are actually simple bugs that can be fixed. (For example, the gcc version detection, see here - I'm just deactivating it, but a more intelligent output parsing can't be that hard- and this affects both Gentoo and Ubuntu.)

[janaf]

As I guess resources are limited, I surely prefer one well supported version than multiple less well supported. It's not an issue of which distro or how many, I do not really have an opinion on this. I's more that I'd prefer any Linux to Win. I reacted on OPs question and the comments on the complexity of keeping up support and install scripts for several distros. So I'd even prefer one distro only, instead of having to switch to Win for the latest hardware support and software updates. I can only comment from my own perspective; I would throw in a new disk/partition with any distro into my PC/PXI controller just to run NI software. But then I guess other people will want to run combinations with anythig from smartphones and RasPies to old mainfranes..... I also guess you will also sooner or later need to support 64-bit versions too, doubling the number of versions to support. My 2c.

[pallen]

2verb wrote:

Maybe the way to solve the Linux distro complexity issue is for NI to create their own Linux distro.

I think this could be a very interesting project, and I have no doubt that NI could put together a distro that would have their own software fully installed and running beautifully.  Unfortunately it would be the getting everything else that everyone would want in a distro that would be the tricky part. 

Still, an NI branded 'demo' distro would be pretty cool.  Maybe a live cd?     (...it can be done...or at least it worked once.)      

[metux]

---

@AdamKemp wrote:

Also, to be fair, the installer could be simpler if Linux distributions weren't so incredibly varied.

Actually, the installer isn't necessary in the first place - you just have to properly package for the corresponding distros - using the distro toolchains, like buildd+friends - and provide apt/yum repos. And building for various distros is pretty simple - I'm doing that all the day, totally boring routine.

It is very difficult to support many distributions because they keep changing things (like which versions of libraries are installed, where things go, which SELinux security settings are enabled, etc.).

Actually it's pretty simple and straightforward, once you've learned to use the distro build/packaging tools. A few days for setting up the CI, and then everything goes fully automatically.

Every release it seems we have to fix things up for some newer distribution that has changed things around yet again. 

Because your workflows are completely, fundamentally wrong. Starting with completely wrong basic assumptions.

Need consulting ? Just insert coins and call me.

I know Linux users love choice, but at some point you lose more than you gain by making it really difficult for us to keep up. I would love to say we support all Linux distributions, but that just isn't at all practical.

In fact, it *is* pretty *simple* and straightforward. Just use the distro toolchains and dont even think about bypassing the whole ecosystem.

There is no one "Linux" to support.

Yes, there is none. Because your stuff is completely unusable for any decent application.

Starting w/ broken-by-design drivers.

There are hundreds. Even if we used a packaging system we would have to pick one (say, .rpm) at the expense of all the distributions which use another (say, .deb), and then there are distributions like Gentoo which have their own completely custom packaging system.

 You'll basicly have to pick three packaging toolchains:

* deb/apt

* rpm/yum

* portage

Put that together into an CI, which automatically builds for hundreds of different distros / versions. Maybe some minor tweaks here and there, but that are coffe break tasks.

And for the really exotic ones, people can use containers.

Our INSTALL script is meant to be able to run on any of those distributions, with workarounds for as many silly little distro-specific quirks as we can. 

The whole idea is ridiculous in the first place. Use the package manager and provide repos. Of course, everything has to be built for the individual distros / releases. But that's the CI's job. Iron is cheap.

Oh, and the whole idea of proprietary drivers is even more ridiculous. This just can't work reliably. Don't even try that - it's *DANGEROUS* !

It's not ideal, but we're doing the best we can to support you on whatever you want to run, and none of the "standard" packaging systems for Linux can do that. 

If that's really the best you can do, then I'd suggest to hire experts.

[metux]

---

@irwan

The rest is up to your preference. If you want Enterprise support, usually people go with RedHat. Otherwise, you might go with Sci Linux or OpenSUSE.

---

I would stay away from distribution with 4KB kernel stack by default, e.g. RHEL 4&5, Sci Linux 4&5, AFAIK. The 4K kernel stack wasn't enough for some calls so it's troublesome for our driver.

Can't you just write proper code, as everybody of us (kernel community) does ?

What exactly do you need bigger stack frames for in the first place ?

[metux]

---

@irwan wrote:

Apologies for the crappy installer.. There's been complaints internally too, but unfortunately, we haven't revisited our linux installer since we created it so long ago.

Why did you create that ridiculous monster in the first place ?! We've got proper package management since over 20 years ! This had been invented exactly for getting rid of the insane installer hell. A company that - even after two decades - didn't learn such fundamental things, just can't be taken seriously. Sorry, we can only laugh about this ignorance.

There was a reason for why we couldn't rely on pre/post-install scripts of rpm .. something to do with displaying license agreement + can't fail and bail out properly during post-install or something like that.

*facepalm* RTFM. The package manager is *NOT* supposed to do such silly "license agreement" questionaries on per-package level. The correct way to do that is at adding the repo to the system. YES! Provide a proper repo instead of installing individual rpm's directly. Really, you folks just didn't get the fundamental concepts. RTFM !

RPM and packaging technologies in general are geared toward user mode programs/libraries, not so much kernel drivers. The result was all that messy complexity.

*facepalm* RTFM. All large distros have their mechanisms for dealing w/ extra kernel modules. (this does *NOT* belong into post-inst scripts - that's what triggers are for) OTOH, OOT-modules are a bad idea for this usecase, not meant for general use.

Linux packaging packaging technologies have evolved a lot since then. I think it can accommodate our needs better today. There's been plans to rework that stuff, but unfortunately, that work has been lower priority than everything else that needs our resources currently...

Aha, making the SW actually usable is just a low priority. What a silly joke.

[metux]

---

@AdamKemp wrote:

Also, to be fair, the installer could be simpler if Linux distributions weren't so incredibly varied.

Actually, the installer is a ridiculous idea in the first place. Distros have their package management infrastructures - exactly for *NOT* having to deal with ill-minded crap like installers. Use them !

It is very difficult to support many distributions because they keep changing things (like which versions of libraries are installed, where things go, which SELinux security settings are enabled, etc.).

Actually, it's pretty trivial, if you just learn the fundamental concepts and do it that way.

Every release it seems we have to fix things up for some newer distribution that has changed things around yet again.

Because your approach is completely, fundamentally wrong. Grow up, kids !

I know Linux users love choice, but at some point you lose more than you gain by making it really difficult for us to keep up.

You could just hire some seasoned gnu/linux developers / dist maintainers. Obviously, you just have a bunch of bloody rookies.

Even if we used a packaging system we would have to pick one (say, .rpm) at the expense of all the distributions which use another (say, .deb), and then there are distributions like Gentoo which have their own completely custom packaging system.

Because your sw architecture is completely broken. Beginning w/ that ridiculous nikal.

Our INSTALL script is meant to be able to run on any of those distributions, with workarounds for as many silly little distro-specific quirks as we can.

Completely stupid idea to begin with.

[metux]

---

@AdamKemp wrote:

Ah, you're talking about VISA and GPIB. Drivers are even harder to support across many distributions because of the many kernel variants.

Because your approach is fundamentally wrong. Just publish them for inclusion into mainline, and everything's pretty easy.

Again, we try our best, but there's only so much we can do.

---

And you're failing miserably - because your whole approach is completely broken.