Slashdot Mirror
Running a Research Lab on Free Software?
"[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is. Who could blame them? Their Windows DLL is the perfect solution under [most] circumstances.
I'm not the only one around here getting frustrated, but all before me have been defeated. It seems I am to be as well, for today I have started to learn Visual Basic.
Has anyone had any *positive* experiences trying to move a lab from proprietary to free software? Surely the government-funded researchers of the world have a responsibility to ensure that their work is free, as in freedom. However, I have found out the hard way that it's usually just not worth the effort, following such ideals. You just get frustrated by apathetic colleagues, useless product support, and the conventional wisdom that it's OK to ignore your ideals, so long as you get the experiment working. Additionally, my ordeals convince my peers that free software isn't worth the trouble."
For almost any government project i have seen, Windows is the choice by the government. Getting them to switch over makes no sense to them, because why switch when you have something that works? Cost benefits don't really seem to do anything, but they seem afraid of switching and trying something new because Windows is just the way it has been, and will continue to be for them. Research might be the same way. UNlesss their research IS software like this, they may just want to stick with what has already beenw orking for them.
I work in a Corporate R&D lab and we're pushing open source technologies here, but you have to be patient and strategic.
First off, are you trying to make programmers convert? If so then you're in a losing battle. People will almost always stick with what they're comfortable with. You'll only get them to look at something else if it is 1 or 2 orders of magnitude simpler to use.
Set an example with your work. If you can do your work using OS tools and you can do it quicker, cheaper, and easier then that's how you convince people. Comments like, "But VB is lame. MS is the anti-christ. etc..." do NOT a good case for conversion make.
Finally, if you can't do it in OS then don't. If you're stuck because of specific hardware/OS issues then don't try to fight the beast on those for now. Pick projects and things that you can migrate and move those instead. (Move the intranet site to JSP or PHP or whatnot on Linux/BSD/Apache. Throw out some NT/2000 Domain boxes and use SAMBA instead.) If you can show the advantages of OS tools for certain tasks then you can get people thinking about it. If you can't do it because of the hardware you're using then you're just going to appear as a stubborn zealot to your colleagues.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
..you choose whatever platform/software that will do the job the best.
Functionality
Availability
Budget
Useability
Philosophy is far down the list.
ActiveState: Python, Perl, Tcl, etc for Windows.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
However, if part of the motivation is moving to free or cheap software alternatives, Labview is not the answer. NI charges one metric shitload for their products. But... for people running and working in a research lab, time is extremely valuable - perhaps moreso than money. You'll probably make up for the money cost of Labview with the time saved easily interfacing software/hardware. Time saved = salary saved, after all...
It wasn't true until .NET, but now I have to say, after using about 1/4 of the languages out there (and that's still a lot), VB has truly matured. I'd say that for anything except embedded software, or that which simply must work on *ix, VB is probably the best choice overall. Consider things like ease of use, learning curve, cost per hour per programmer, and it makes some sense.
When you pay $20K-$200K for a piece of hardware, you find as many ways to use it as possible before you throw it away. Just because a new version of the software comes out a year or two later doesn't mean that the lab is going to be able to afford the new version. If a lab can afford a new version of the $100K toy, chances are that they'll had-me-down the older version to the undergrads.
I can understand that a company doesn't want to support more than one or two OSs, but it gets reall annoying if they don't give you the data so that you can roll your own support.
I take it that there isn't a different company that you can go to to get an equivalent machine??? If there is, then try playing them off against each other. For the more expensive equipment, at least, they should be willing to do some work to get the sale -- if that means releasing the register data, then they'll probably do it.
OS Software is like love: The best way to make it grow is to give it away.
My first choice is Delphi. I don't think I'd ever say Delphi is better at creating quick`n`dirty apps than VB, but I would most certainly say that it is completely on par in that area, with the added benefit of being much more powerful. (My opinions here are based on VB6 and Delphi5, which are the last two I used heavily before being liberated from Windows GUI work.)
The other alternative I can think of is RealBASIC. Their development environment used to only run on Mac OS, even though it could compile apps for either Mac OS or Windows. Nowadays, the environment itself as well as the apps it creates all run on both Mac OS 9/X and Windows, although I've never used the Windows development environment. I've only had limited exposure to RealBASIC, but based just on those few hours, I would highly recommend any fan of VB at least give it a shot--I know if I ever have to go back to Windows GUI work, I certainly will. (It seems it would especially shine for quick`n`dirty apps because it seems to focus more on simplicity and cross-platform rather than feature bloat.)
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
First off, skip VB6 and anything before it. Go to .Net. You can do true OO programming using VB.Net, C#, C++ and a bunch of other .Net CLI languages. They can all communicate with ANY sort of DLL/COM combo your board manufacutuers give you.
.Net language, or if you're a good programmer, and you know C/C++ use that.
Second, dump Win95 NOW. Your logic on why you don't want too is flawed. WinNT/2K has nothing in common with Win95. They are Two different products. Your not "Upgrading" your buying a different product.
Win95 was designed for the home, and a stepping point from DOS. Not as some sort of platform for stability and IO/Data Gathering, Realtime acquisition..etc. It's a hack and an old one at that. Would you use a build of Linux from 1995? 98? Hell no.
I'm really serious on this last point. Many people fail to realize just how stable Windows 2000 is. I'm amazed Win95 is still floating around in labs like this. Win98 is no better either (same thing). Did it come on the computer? I think i've been running win2k for nearly 5 years now in October. That's about the limit for a development platform imo (win2003 i'll ugprade to at SP1 level).
If you can find an Open Source alternative using Linux and other free stuff great. But honestly, I bet you end up spending more time getting things up and running and working, then programming/inventing.
Whatever you do, dont use VB6. It's not worth 'learning'. Stick to a
-Malakai
-Malakai
A Dragon Lives in my Garage
[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is.
What exactly did they say when you asked? Have you made sure that they understand what you want to do? (Create a driver that makes the card work on linux, that anyone can get, potentially increasing the sales for the card). The key is to present the request not as "we need this" but as "you will get this if we can get that". They may still not be willing to help and then you explain that whenever you do the purchasing decisions you will prefer a company that provides specifications (or linux drivers). They still might not listen so you may have to wtick with windows, just make sure you remember who foreced you to it whenever you get a budget to buy new equipment.
- We are the slashdot. Resistance is futile. Prepare to be moderated -
I am a physicist at Vanderbilt University, in the Free Electron Laser Center, who has been doing various kinds of distributed data acquisition and control for about 25 years. I have run into many of the same problems with closed interfaces the author describes, and am slowly developing a strategy to minimize the impact of this problem.
First, I try to avoid products which depend on a closed library/DLL/whatever to control them. This has resulted in my shifting away from a lot of PCI-card devices to (when possible) external devices which communicate via GPIB/IEEE-488, rs233/422/488 interfaces, USB interfaces, network interfaces and (I hope soon) FireWire/IEEE-1394 interfaces. For such devices, one can often find programming specifications, although not always. Obviously, using the slower interfaces may result in lower performance in high-bandwidth environments, so it won't always be an option. However, the fastest current IEEE-1394 looks very promising, as it can support speeds that only a few years ago would saturate a PCI bus.
I have also discovered another interesting phenomenon: 'hidden' standards. In the past year, I became aware of a little-advertised standard, VXI-11, (www.vxi.org), which is a protocol for communicating with GPIB-like devices over TCP/IP. Although one almost never hears about it, a lot of devices support it. Tektronix and Agilent Infiniium scopes use it, and Ethernet-GPIB converters from Agilent, Tektronix and National Instruments all use this. The protocol is open, sunrpc based, and quite easy to implement. However, each company hides any reference to it deep inside the documentation, and basically provides their own Windows dll for communicating with their devices. The Agilent E5810 Ethernet-GPIB converter (a very elegant box) even calls itself a GPIB-LAN interface for Windows, as its official product name, even though it is almost fully VXI-11 compliant and can be used from any platform. I have no idea why they actively _hide_ its cross-platform compatibility.
<slight advertisement> I am trying to address some of these issues by releasing a lot of the code I am working on to interface various devices. I am a python fan, so I have a sourceforge project PythonLabTools which is a library of open-source code to implement communications with various types of devices which are effectively GPIB devices but run over the net via TCP/IP. I am also adding other classes of interface support to this library. An example is the Verinier Software LabPro, a low-end but quite nice and inexpensive a/d, d/a, and digitial i/o box which communicates via serial and USB. There are also data analysis tools in this package (fitting, et.c), and support for the National Instruments DSTP protocol, which allows LabVIEW to share data over a network, and (in this case) allows a Python program to directly interact with a LabVIEW program. This allows separation of the fancy user interface capabilities of LabVIEW from more intensive data analysis which can be executed in Python. <end advertisement>
I am looking forward to a day when more and more external devices with published interfaces become available. Internal devices (PCI or whatever), of course, take a lot of work to make drivers, but since communications with external devices can be carried out in userland, they are easier to provide cross-platform support for. I am alos watching as bandwidth on external interfaces rises to the point where there may not be any need for internal cards and the hassles they create.
I spent a fair amount of time a couple days ago lobbying our National Instruments representative for opening up the interfaces to more of their devices, especially their FireWire/1394 based products, which are right now only supported on Windows (which _really_ galls me, since Apple and Sony spearheaded this interface!). We are a fairly significant customer of theirs, and I think they actually listen.
Earth to clueless person....
he cant. thereare TONS of real reasearch boards out there that cost more than you will ever spend on a complete computer that is 100% incompatable with Windows NT and it's diraviatives like 2000 and XP.
I have a drawer FULL of $7000.00 a piece video analysis cards that cannot be used in anything higher than a Windows 95 box. and we require them here for several processes and projects.
so get a clue first. Microsoft is a consumer OS not a reasearch OS so they happily ditch compatability all the time with hardware.
VB6 is the last VB that isn't bloated all to hell. I actually reccomend that everyone use VB4 for the quick and dirty here as it's 1/5th the size and much faster than anything that vb6 can produce.
so dont go around offering advice that can completely devastate someone's reasearch when you haven't even the slightest clue about what you are talking about.
Do not look at laser with remaining good eye.
not just a pride thing, unlike many colleagues I know what I'm missing out on, in the free software world
Like what, for example? Under Windows you can run Emacs, Vim, Perl, Python, Ruby, etc. You can get bash or another UNIXy shell if you like, and all the same command line tools. Putting together GUI interfaces for little tools with Visual Basic is a *great* idea. You could use something else, of course, like Tcl/Tk, or a free VB-like system, but VB is very good at what it does.
Reliability isn't an issue, if you're running Windows 2000. I have never had a single crash doing heavy software development under Windows 2000.
To me, it sounds like you just want to avoid Microsoft and Windows at all costs, but you don't have a real reason. In fact, you're even attempting to move away from the OS that most of your peripherals are designed to run under. Very strange.