Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Any news on 64-bit LabVIEW for Linux?

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 🙂

Message 11 of 22
(1,278 Views)

Sorry, I have no update to give you on this topic.

0 Kudos
Message 12 of 22
(1,278 Views)

OK, a couple more years have elapsed.  What plans, if any, are there for LabVIEW 64-bit for Linux?

Message 13 of 22
(1,278 Views)

labview 2014 released with this: http://www.ni.com/pdf/manuals/374718a.html#lv64bit

0 Kudos
Message 14 of 22
(1,278 Views)

A lot of their drivers aren't supported yet, so we will still need to wait on those.

0 Kudos
Message 15 of 22
(1,278 Views)

What drivers are supported 64-bit OS? Is Ni-DAQmx Base support 64-bit Linux?

0 Kudos
Message 16 of 22
(1,278 Views)

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.

0 Kudos
Message 17 of 22
(1,278 Views)

Thanks, Daqmx Base with 64-bit is not released yet.

0 Kudos
Message 18 of 22
(1,278 Views)

@anshuljain

Majority 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.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 19 of 22
(1,228 Views)

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.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 20 of 22
(1,226 Views)