Ubuntu changed /bin/sh link to point to minimal dash, instead of the more complete bash
Please edit configure script so that the first line is "#!/bin/bash". You should be able to go further.. I'll fix that in our source.
NI has a lot of IP that we're trying to protect.
What IP, worthy of "protection" by keeping it ultra-secret, could be there, in nothing but the protocol / register set to drive the HW ? It's like selling a car and never telling the customer how to refuel it or change the tires. Really stupid.
Oh, BTW, we could just reverse engineer it (actually, I've already proposed that to my clients). Obviously nobody was bored enough (or was paid) for actually doing it. YET.
IP and open-source just don't mix.
Actually, they do. We're dealing w/ that all the time. It's just a few companies, like NI, who burn tremendous resources in going the completely wrong way and insist in keeping such - business irrelevant - information ultra secret.
Consequence: no (usable) Linux support. Therefore: no sales to Linux users.
Having said that, there is hope. Basically money talks.
The money that NI does not get, due not offering usable products.
The real problem here is that we don't have enough data as to how much money/market-share there is out there for the open source solution.
For my clients alone, it could have been several millions. If there were open specs and free drivers. Due to the lack of these, I had to arrange that my clients, do not buy any NI hardware.
We have tried getting into the Linux support using the closed-source driver and that helped some.
Quite frankly: proprietary Linux drivers are bs. It's a contradiction in itself. Just extremly expensive and can never work reliably. Due to the fundamental architecture of the Linux kernel - and we, the Linux community never had any desire to support such crap, for thousands of reasons.
However, because of this, we have mostly data that supports the fact that big Linux customers don't really care about open source.
You only have those few Linux customers, which somehow manage to get the stuff somewhat running. Anybody else just doesn't buy NI hardware, as it is known to be pretty much unusable under GNU/Linux. It's a funny feedback loop.
We still don't have enough data that supports that supporting open-source driver will really be beneficial,
Because you just don't listen to the (potential) customers. My clients alone could have easily refinanced completely new drivers, written from scratch, for all drivers (the average budget requirement is about 4..8 man-weeks per device model).
Businesses can't survive well that way.
Business can't survive without customers. Windows in industrial/lab environments is dying out. Maybe NI just wants do die with it.
This is where you guys can help. If you care about NI open source driver, please talk to your NI representative in your area, so we have more data on how many customers and how many potentially big orders that we're losing for not supporting it.
Tried that several times. Didn't help. And actually, I don't think that we (the community) should burn our precious livetime w/ talking to an completely ignorant company, trying to convince it to do their own homework. We just buy from somebody else. Period.
NI is a business.
A bussiness which doesn't care about its customers, not to mention product quality (yes: this proprietary driver stuff belongs to the worst bunch code I've ever came around - school kids can do better).
We care about our customers, but we do have our limitations as to how we support certain customers (resources, IP concerns, etc) so we do need to be careful about where we would allocate our resources to tackle new market and support these customers.
NI could have picked the "new" (actually, 25 years old) strongly growing GNU/Linux market. It chose to completely ignore it and instead just spread marketing lies.
Evolution do its job and optimize away those companies.
The other group are companies (do they really exist?) which don't care to pay expensive support fees to redhad/novell/... for they enterprise distros. They are satisfied that NI only supports RHEL 4/SLES 10. For NI, this groups brings the money, at least for short term.
And there's another group (like myself and my clients), who wants to use the hardware in professional industrial environments, with their own software, needs long term availability, and has no use by any means for anything like LV. This group isn't visible as NI customer, as they just cannot use NI products w/o free drivers or at least free specs.
As long as the open-source drivers don't integrate the same way in LabView as nidaq/visa does, they are no really an option. I just hate to write the same program several times for each platfrom.
For my projects (which could have brought several millions to NI), LV is just completely irrelevant - we have no use for it. And as long as one needs LV to use the HW, it's just useless for us.
OTOH, I really wonder why they don't just add a backend for the kernel driver APIs.
For example, for DAQ devices the standard Linux API (which could also be ported to other platforms) is IIO - trying to do anything else is just silly.
Companies which distribute their drivers via the official kernel do only need to support this kernel (and some older ones from the stable branches).
Exactly. Development and primary support happens on the mainline kernel. Backporting to older/dist kernels is the job of the distros. That's the way it always worked in Linux world.
Most kernel developers think that loading proprietary drivers into kernel space is like linking, in which case NI violates the GPL license by distributing non-GPL kernel drivers.
Indeed it is - as soon as the proprietary module uses the kernel internal APIs (which is neccessary to do anything useful). These violations are often just tolerated / ignored - a major execption is the USB subsystem, which is explicitly gpl-only - the reason why NI's proprietary drivers are illegal on non-ancient kernels.
Besides the legal aspects, proprietary drivers are always very unstable, as there is no such think like a stable kernel internal ABI - it highly depends on how exactly the kernel was compiled. And even the APIs change frequently. This has always been the case - it's a monolithic kernel.
Concerning IP and open-source, in the "ms-world", a kernel driver does a lot more than only interfacing with the hardware. There may be algorithms included, which could be related to some form of "intellectual" activity. In the "Linux-world", these algorithms belong to user space and the kernel driver only acts as a "dumb" interface.
Correct. In Linux world, drivers are really just drivers - the few pieces of code to drive some specific hardware. They're not huge application stacks, like in ms-world.
I think the real reason for NI not do distribute a GPL driver is that they need to develop a completely new driver, because the current one is just the windows driver (with all the IP inside) and some glue layer.
Yes, of course. Sane drivers always have to be written for a specific OS/kernel - this is exactly the main purpose of a kernel, and where they differ massively. The whole idea of "cross platform drivers" is just nonsense.
Writing such a driver (eg. for IIO) is a task of a few weeks, and usually needs less than 1kLOC. YES: I'm doing that all the day.
Unfortunately there is the potential that the register map also contains valuable information, IP or not. I'm not sure how feasable this would be nowadays, with register models of custom interface chips going into the million of gates,
The register sets certainly do not contain any "valuable" information. It takes me about a day to fully define one (been there, done that). The real IP is in the logic/circuits behind - especially getting the whole HF part right, isn't trivial. OTOH, the register sets are too trivial for counting as an invention.
but there has been in the past a data aquisition manufacturer who lived from creating cheap copy cat hardware from some competitors hardware and when users asked for drivers they were pointed at the competitors downloads.
They just implemented compatible register interfaces (as they're trivial enough and haven't much to do w/ the actual circuits behind). Pretty common and pragmatic approach, which helps consolidating amount and quality of driver code - should be done more often. Actually, for wide ranges of devices there are even actual interface standards (eg. the whole USB world).
Even with such a scenario not being really feasable nowadays, there still is quite a bit of development in many of the custom chips that are on nowadays higly integrated data acquisition hardware and a business does not necesseraly want the competition to know what there is and how it was all implemented.
If "businesses" (actually, some folks in suits) really believe the dumb register sets tell anything valuable about the internals, they just don't know their own business. And finding out the register sets isn't a big deal for competitors, anyways.
But basically most lawayers into license right will tell you that it it is at best ambigues and at worst a time bomb to explode at some point when used commercially.
Most lawyers don't know much about legal issues. For kernel modules, the GPL isn't a problem for userland, as the kernel->userland APIs aren't affected by it.
LGPL makes this all a lot more complicated since at what point do you derive from the LGPL software and at what point do you simply link to it?
It's damn simple. Just link dynamically, and you're fine.