I know I know, these threads get posted 10 times a day, but this one is different...I promise!

This is a special machine, purpose built for a specific job.

It will have a public IP and it will be in use for many years to come, so LTS security updates are important.

But here's the kicker - It's using a very large and very expensive A/D card as part of its place in this system. The card manufacturer does provide Linux drivers, but they're not exactly the most modern. The kernel module only supports 32-bit kernels, and will only work (so they claim) for kernels 2.6.35 and under. In addition to this, I've discovered that their closed-source shared object library requires libstdc++-libc6.1-1.so.2 - yes that's a 14+ year old c++ library.

I initially tried CentOS 6.5 64-bit because it's running 2.6.32 and will be supported until 2020 and the machine has 8 GB of RAM. Obviously I quickly ran into the 64-bit kernel problem, so I switched to CentOS 6.5 32-bit PAE. I couldn't find a source for libstdc++-libc6.1-1.so.2, so I installed the old compat library (which was libstdc++-libc6.2-2) and symlinked it with the correct name as a "good enough" approach. This allowed me to build and load the kernel module and run their demo application that pulls in data from the A/D, all of which ran great.

The problem came about when trying to develop my own application using their shared object library. They provide example code, which I started with, but quickly ran into a seg fault and started stripping pieces out to track it down. I stripped it down to literally:
which when compiled with
works fine, and with
it seg faults when trying to execute it (DSCIO is the closed source .so provided by the card manufacturer).

Is it a libstdc++ issue? I don't know, if it's not then I don't know what else it is. gdb and valgrind provide no useful info since it's failing inside of the closed source .so.

So, I decided to branch out and installed Debian 6 in a VM. I was able to track down a valid libstdc++-libc6.1-1.so.2 at http://archive.debian.org/debian/poo....66-4_i386.deb, installed it, built and loaded the kernel module, re-tried the above test with the stripped down application, and everything worked great!

The problem here is that Debian 6 is already EOL, and the extended LTS is only going to hold it for another year, and Debian 7 is running a kernel > 2.6.35.

Of course there's always the Windows alternative, for which the card manufacturer provides drivers all the way up through 8.1. Frankly I'd rather run a Linux distro that's past EOL than any version of Windows.

So, suggestions?

Well, you could try one of the *buntus. They tend to come with a lot of drivers and support vectors, but forewarned things in Linux aren't what they used to be.

One growing problem is several distributions that have switched to systemd and by it's design they are locked at certain minimal kernel versions so Linux distributions using that init system are becoming less backwards hardware compatible. With those you may run into less and less compatibility with a driver source package if it's too old.

Another problem is if a kernel driver provided by a manufacturer isn't patched to support modern glibc, gcc, or kernel revisions, it can tend to fail to compile. Without patches or an ability to patch code as needed, you can get stuck with dead or unsupported hardware.

The real question is how vital is this A/D card to the system?

If you say it has driver support up to Windows 8.1, then honestly, you should give it some thought to try at least Windows 7 first and foremost if the card is mission critical. Just because it's Microsoft, and yes you can stop groaning at the mentioning of that name now, doesn't mean you should forgo proper hardware support just because an OS isn't free or is made by an unwittingly evil company, shouldn't discourage you from getting the most out of your hardware properly.

Linux isn't a one shot kill all solution for all purposes. Often at times, you have to run other operating systems to get a means to an end. That doesn't make any OS better or worse, it's just if you want to do things properly, you have to use the right OS.

This computer, and the A/D contained within, is the key to the entire $150k+ system. Without it, the system doesn't work.

*buntu - I guess I did forget to mention that this machine will be installed in the boondocks and needs to function pretty much headlessly, with as much reliability and stability as possible from an operating system. The few times I've used Ubuntu since version 10.x it's been a buggy mess, I'm not going to use it for this system. Not to mention that Ubuntu hasn't used a <2.6.35 kernel since 10.04, which went EOL over a year ago (at least the desktop version did, the server version looks like it's only good for another ~9 months, even worse than Debian 6).

The system already runs Windows, never again. Scheduling is a pain in the ass, autonomy is a pain in the ass, everything is GUI based which makes remote management over low bandwidth connections almost impossible, and between software crashes, OS crashes, random reboots, lockups, and BSODs, it is the least reliable component in the entire system by at least an order of magnitude. I'm not opposed to Windows because of some "evil" notions about Microsoft, I'm opposed to Windows because it's an unapologetic piece of crap that compromises the usability and reliability of the entire system to a level I'm not willing to ignore any longer.

Modern Windows can use PowerShell very effectively even over remote protocols. As far as remote services, you can always add various things to ensure reliability.

Even headless and networked, you could always use free software within the box effectively to avoid more proprietary software.

Windows may be unapologetic, but all modern operating systems are becoming that as well. To be fair, I've ran Windows 7 for four or more years now since RC and it's been very reliable and stable which was not the case with Vista and prior versions. I only installed one time, which was never a norm for me having to redo a system every five months due to issues and stability.

I don't see Windows any different than OSX, FreeBSD, Slackware, or any other OS. To me, it's a set of software and tools formulated for a job, and regardless of how I feel, I have to say to myself, a tool is only as good as the person using it. Trust me, I wish I could switch full time to Linux for everything, but to me now that's a foolish thought. Every platform is good and bad in every area, but when you have to use something, you have to use it, no questions asked. A GUI may be bad in some ways, but it's good in others the same a command prompt is good in some ways and bad in others.

Just throwing ideas out there but how about a VM of some sort? Can you use IOMMU (or whatever the term is) to allow an antiquated or undesirable OS that lives in a container access the card you need then use a proper OS to firewall it and control access to it?

Possibly, I'm working with the card manufacturer right now to address the problems with their closed source drivers, so I'll see where that discussion leads before making any final decisions.

Is there some unique property of this particular A/D card that would preclude you selecting another? Maybe even a USB device (I am not actually familiar with any at the moment, but...), or even roll-your-own for a straight forward design with polled or interrupt driven sample rate might fit into a $150K+ system easily enough.

There might also be a requirement for g++ version. ABI compatibility is much trickier in C++ than C (in theory ABI incompatible versions of the compiler should use incompatible name-mangling so you get a link time error).

It turned out to be a PAE issue actually. For some reason the 36-bit internal memory addressing screws up their driver module. CentOS 6 doesn't have a non-PAE option, unfortunately. I had the same error when using the i686-bigmem kernel on Debian 6 too, it didn't go away until I switched to the true 32-bit kernel.

It's a pretty high end card with synchronous sampling, disciplined clock, on-board DSP for filtering and anti-aliasing, etc.

I am investigating alternatives though, ACCES I/O makes some nice units with good open source drivers, sample code, and amazing technical support (they're also significantly cheaper). I'd lose the on-board filtering and anti-aliasing, but there are some work-arounds that might still make it feasible.

36-bit memory addressing?

That's an odd amount.

http://en.wikipedia.org/wiki/Physical_Address_Extension

It's a way for "32-bit" kernels to utilize more than 4 GB of RAM, and it's the default on a lot of (most?) "32-bit" Linux distributions. RHEL/CentOS 6 doesn't even have a non-PAE option available. Debian has PAE (they call it "bigmem") as an option, but they also have a true 32-bit kernel as well.

Indeed, as I understand the CPU I'm running at the moment has a 48bit address space.