03-01-2012 09:46 AM
I address this quastion to my local NI reps but thay didnt return to me with any helpfule information.
my group is working using Linux 64bit as the main testing platform. in spite I manged to install and run LabVIEW 32 bit
on the Fedora 14 64bit distro I run into problem since I need to call 64bit compile libs.
So is thre is any news from NI side regurding to the road map of LabVIEW For Linux 64 bit?
the industry is there and we need NI to join us 🙂
03-01-2012 10:47 AM
Sorry, I have no update to give you on this topic.
06-09-2014 04:08 PM
OK, a couple more years have elapsed. What plans, if any, are there for LabVIEW 64-bit for Linux?
08-13-2014 01:36 AM
labview 2014 released with this: http://www.ni.com/pdf/manuals/374718a.html#lv64bit
08-25-2014 08:16 PM
A lot of their drivers aren't supported yet, so we will still need to wait on those.
08-26-2014 02:20 AM
What drivers are supported 64-bit OS? Is Ni-DAQmx Base support 64-bit Linux?
08-26-2014 02:40 AM
You can look at here for the support
http://digital.ni.com/public.nsf/allkb/4857A755082E9E228625778900709661
but beware that PXI Platform services is not supported.
08-26-2014 09:29 AM
Thanks, Daqmx Base with 64-bit is not released yet.
03-04-2018 01:47 PM
@anshuljainMajority of the companies wanting to provide drivers for Linux have come up against the GPL license of the Linux kernel.
Yes, that's the basic rule for Linux drivers. BTW: they always need to be compiled for the exact kernel version *and* configurations. For some rare cases, out-of-tree modules are a usable (that's what dkms is for), but usually they belong directly into the kernel tree. Binary-only modules *never* work reliably.
However, there are a few like Nvidia which provide binary-only drivers which can be installed on pretty much *any* distro.
Only on a few selected ones, on some selected version ranges, on few hand-picked cpu architectures. (IIRC only x86 - which is completely unusable for anything security or safety related).
Expect crashes, hard lockups, data loss. Anything but reliable.
But Nvidia stuff is meant just for game consoles, where reliability doesn't matter - and they're fraudsters anyways.
They are also very quick at updating their drivers with their product releases. I believe NI can look into the Nvidia model of providing a single "*.bin" which will run under any Linux kernel.
No, absolutely *NOT*. It will *NOT* work reliably. It's russian roulette.
Writing kernel drivers are my daily business, and I wouldn't even think about such completely ridiculous ideas.
The best solution is, of course, to open source the drivers.
That's the *only* usable solution for any industrial application. Proprietary drivers are always unstable and dangerous !
But I can understand business considerations behind them (licenses, IP, patents etc)
NI should understand the business considerations of their (not-anymore) customers:
No free drivers -> no usable product -> no deal. Period.
Usable depends on free.
Over the recent years I had to kill lots of purchases at several clients. Don't recall the exact numbers, but should sum up to at least over a truck load full of NI HW, which my clients did *NOT* buy - exactly due to lack of free and usable drivers.
If NI really want's to shut down it's business, somebody else will fill the gap.
03-04-2018 02:01 PM
By using a real time OS, I would be concerned about the hardware drivers such as for my digitizers.
Linux *is* a real time OS (if applying tglx'es -rt patches).
It seems that vendors are struggling with maintaining shared libraries for Windows and Linux.
That's exactly the ridiculous idea to begin with !
HW drivers are *exactly* the primary domain of an operating system, that's the area where they differ most. Drivers - at leas low-level ones (and for DAQ devices a driver only needs to do low-level stuff, the generic hilevel stuff is already included in the kernel) always have to be written for an specific OS/Kernel. Ridiculous ideas like "multiplatform drivers" just make the whole thing at least 10-times larger than it needs to be, horribly slow and unstable and practically unmaintainable.
For Linux, the proper way is to write drivers for the corresponding subsystems - in that case IIO. Anything else is just a really bad idea. Trying to bypass the whole kernel, as NI does, will never work reliably and is *extremly* expensive.
Unfortunately, they just don't learn. Tried several times, but had to give up. My clients won't buy NI. Period.
BTW: usual HW vendors shouldn't even try to hack up Linux drivers own, but hire experts instead, which also bring the drivers into mainline.
Of course, that requires releasing the specs. Exactly what NI refuses to accept.
So, back to square one: NI is unusable on Linux.