Leaderboard

It never will be until they resolve their distribution issues which they simply do not even acknowledge. Even Linus Torvalds refuses to use other distro's because of that. What Windows did was to move common user space features into the kernel. The Linux community refuses to do that for ideological reasons. The net result is that application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's and effectively tieing them to specific distro's with certain addons. Those addons also have to be installed by the end-user who's level of expertise is assumed to be very high.

Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath. LabVIEW will never be open source. It would not make sense, nobody outside of NI would be able to maintain it. LabVIEW is not the Linux kernel which is of huge interest to millions of others. The area of the intersection on the Venn diagram of skilled enthusiastic LabVIEW developers, ultra-skilled C++ developers, and those with enough spare time is approximately zero. The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

The problem with the argument about better mergeability if LabVIEW would use a text based file format is that XML and really any format that can represent more complex data structures, can not easily be merged with current tools. It doesn't even fully work for normal text based languages as the merge tool can NOT determine what to do when two code modifications occurred at the same or immediately adjacent line location in a text file. You end up with conflicts that have to be resolved manually. While that is doable although not fully painless for normal text based languages, XML and similar formats pose an additional challenge since a change in one element can actually cause changes in multiple line locations, often separated by many text lines. As soon as two different changes are somehow not totally independent in line location, you can't merge just based on line information. And in the worst case a single change can basically mean a modification right in the beginning of the file and one at the end. With such a change any other change is potentially very problematic to merge. And just doing the standard conflict resolution for text files as it is done now, with including both sections and letting the user manually decide which to use, would basically just create a double as big file, which would be pretty useless to try to manually merge. So while converting LabVIEW binary files to XML or similar sounds like a good idea, it won't solve the problem of merging in source code control really. In a way the current situation is easier: You know it can't be done automatically so are forced to plan accordingly! XML may in that respect seem to many to promise something that could not be delivered anyways in most merge situations. To do any meaningful merging for anything but the most trivial modifications in XML format, one would have to create a diff/merge tool that fully understands XML and to make matters worse, it should also be aware of the actual schema used in the XML file. Even then creating an XML format from that merge result would be only partly helpful, one would really need an interactive merge visualizer that presents the XML data structure to the user directly in a suitable graphical form such as a tree view and lets him select the relevant modification when there are any logical conflicts. As to creating external tools for dealing with LabVIEW files without the need to script things in LabVIEW itself, the idea sounds good, but I doubt it will be used a lot. Maybe a translation tool for different languages but many such things are rather runtime features than edit time features. About throwing away LabVIEW for non-Windows platforms: That is hardly an argument to even start to try to remain relevant in comparison to things like Python or in a far far future from now maybe .Net. Python runs on pretty much every hardware you can imagine that has a C compiler available, from low end 8-bit microprocessors to extreme high end system. There are also literally exclusive points in that list. * Stop adding new features to LabVIEW for several years This directly contradicts several other items in that list.