From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
A lot of engineers prefer Linux over Windows and would use it on there test machines if at all possible. Instead of attempting to support a wide variety of flavors, wouldn't it be better if NI would derive it's own flavor from an existing distribution and committed to having full support for all NI software and hardware for this new flavor. This would give Linux aficionados the OS they crave and NI the power to control the direction of the OS such that it makes hardware and software compatibility easier.
That seems even worse because instead of having a limited selection of OSes to use, you only have 1 OS to use. And would anyone want to install a whole operating system for the sole purpose of NI products? You might as well just install Windows at that point.
>>A lot of engineers prefer Linux over Windows and would use it on there test machines if at all possible.
I dont know what made you say that but i have yet to come acroos something specific to linux. Preference will also be windows if you are going to ask the customer for options..
i am using a 64 bit linux version,so if i compile a c file in 64 bit linux operating system, then the .so file is of 64 bit.so can i call the 64 bit .so file 32 bit labview linux version?
What would make a little more sense is to support NI VeriStand (GUI not engine) under Linux and then use Hypervisor to boot LabVIEW Realtime. One of the biggest headaches with Linux is driver support. This is the most costly portion of development from NI's perspective as various flavors can cause massive issues a the driver level. However, all NI's hardware (except say some newer RF products and VXI interfaces) are supported under LabVIEW Realtime. Using hi-speed shared memory access and an assortment of plug-ins, you could achieve a lot of functionality via using (or perhaps modifying) the current architecture of VeriStand + RT + NI Hypervisor. Also, LabVIEW RT (Pharlap) support Windows DLLs which makes it easier to support 3rd Party Hardware. Also, using this architecture wouldn't be exclusive only for Linux but Windows Users wanting to isolate Driver issues from their main PC could also take advantage. The drawback is that VeriStand wasn't really design to pass massive amounts of data over a shared memory link in a driver type fashion so essentially you would be re-creating many plug-ins with almost driver-like quality but NI could do some things to incorporate an abstration layer to the drivers to make this easier. But even if NI didn't do anything, you could do this today and bring out what functionality you need. Hey, if you a Linux guy, you like doing things yourself anyway right! 🙂