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."
Research companies write their software in VB? No wonder there's still no cure for cancer!
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.
As someone who has been a sysadmin for a 20-person femtosecond laser group, may I suggest Labview (www.ni.com)? It runs on Linux & Windows, many hardware cards support it, and it's honestly better than VB.
Your time is your most important resource. Don't waste it recoding.
R.
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.
Actually, I sometimes feel that this is the number one symptom of the obstacles that OSS/free software face. Multiple times, I have been labeled a nut for wanting to us Linux/OSS. I had a roommate in the dorms once who insisted that I would be "happier" using Windows.
As far as experience moving labs from Windows to OSS, I have never moved an entire "lab" so-to-speak to Linux, but it is my experience that in the past three or so years since I was introduced to Linux, it has made big inroads into becoming easier to install and use. The hardware support is definitely better. I remember when I first tried Linux, support for USB mice was still experimental.
These days, migrations from Windows to Linux have been relatively smoothe. I've had great success moving a fileserver from a Windows NT workstation to a less-used Linux box. Usually, it will eventually go down because of a power outage - so I recently purchased a UPS.
The bottom line is, I think that the problem of colleages who drag their feet on using Linux/OSS will be reduced as major distros become increasingly easy to setup and operate and hardware support improves.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
simply because certain hardware manufacturers utterly refuse to support anything other than Windows."
Just pick your hardware manufacturers more carefully. There is plenty of analog and digital I/O boards for PCs that have Linux support. Even better, Linux is very popular on embedded systems (like PC104), so you don't even need a whole desktop PC but can use a small, embedded PC running Linux, together with hardware that comes with Linux drivers.
It is also my experience that manufacturers that ship Windows-only hardware are generally substandard. They probably don't support Linux because they are very tight on resources. If they don't give you low-level documentation, it's probably because they don't have it. And you end up between a rock and a hard place with that kind of hardware when VB wants you to upgrade your OS and their proprietary Windows driver won't work anymore.
UNIX itself has a very long tradition for experimental applications, so if there is nothing for Linux, consider getting a cheap Sun workstation with hardware that is supported under Solaris. That will still work a lot better than the Windows stuff, and it will interoperate nicely with Linux machines.
If you absolutely must do something on Windows, use Python, Perl, and/or wxWindows rather than VB. CygWin is also great. That way, your developers will acquire open source and Linux expertise and won't be locked into the Windows upgrade treadmill.
So, while occasionally some cheap peace of Windows hardware may seem alluring, if you just look around a bit more, you'll probably find something at least as good or better for Linux.
Clearly VB is the winner here as it perfectly mimics the unpredictability of quantum mechanics!
I have never known a lab that used VB as its programming environment. Usually it is either c/c++, Java, or one of the math programs (matlab, mathematica, maple, etc...). In general, I would recommend using microcontollers for controlling your experiments. However, you mentioned that you are doing stuff at the quantum level, so these may not be fast enough for you (the ones I use are 20MHZ). However, I must say that the PIC series of microcontollers can be programmed in a variety of languages and has a great deal of flexibility. One of the main problems is that a lot of the software for contolling lab equipment is either homebrew for a specific application (as is the case with some dynamic clamping software in the neurosciences) or made for a wide variety of applications (labview), but is not open source. The best option may be to get a company made environment which can have functions written for it in another programming language and customize it. However, coming from a biology side of things I do not know what your specific needs would be for quantum computing, and thus cannot give any ideas as to that specifically. Good Luck.
I've used comedi with a National Instruments NiDAQ 16 channel acquisition card on a P3 laptop running debian - it worked very well.
However, can I offer the following advice, which may save some people from smashing their head into a bloody pulp against a wall...
* Turn off APM!!! *
You can do this by passing apm=off to the Linux kernel with your bootloader (I think - can't actually check that at the moment) if you don't want to actually remove it from the kernel (APM is useful on a laptop normally).
If you don't do this, you might find your acquisition mysteriously stalling after random intervals. It's to do with APM interrupt handling. Not sure if it's restricted to PCMCIA cards.
Is it really worth your time, your professor's time, or the government grant's time to spend your quantum research dollar in overhead costs as you bang your head away in frustration trying to cludge together some string of 0.2 beta versions of open source data collection programs?
And what about when you leave? Does the next grad student have to spend 3 years learning your absolutely unique software setup instead of learning physics?
In the Big Name(TM) physics lab I work in, grad students cost about $200 a day (to the grant), and postdocs cost about $500 a day. If I need a program that would take me a month to write or costs $2,000 to buy today, it's my job do know to just buy the program.
We used to use LabWindows (call it C++) and VisualBasic, but the last person who know LabWindows left and now looking at the code when things go wrong is a nightmare.
So, anything new is being done in LabView. (Disclaimer - I don't work for National Instruments) Sure, it costs $2K for the good suite, but I guarantee you will make up for it in productivity. Plus, debugging LabView code as a beginner is waaaaay easier than debugging someone's crazy spaghetti C code. With the high turnover rate of a research university, it's very important to retain the chain of knowledge. Otherwise things progress into the realm of Black Boxes.
My opinion is not to waste your valuable research time worrying about software. Especially in quantum computing where you will be left in the dust if you fart around worrying about open source too long.
Best of luck,
Muerte
[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is.
You have to phrase your request nicely:
"Give us the technical specs, or we will crack your company encryption keys with our quantum computer, access all your specs, and post them on usenet."
However you do not have to run VB only. My Windows2k box has opengl, openinventer, vtk, ativePerl, active Python, gVIm, cygwin, gnuc/c++, Devc++, ruby, tk/tlc, apache, php, etc.
Infact the win32 ports for these opensource apps are very well integrated with Windows. FOr example I can use gvim aka VI to replace my editor in VC++, create ole programs in python, and even use Perl to create Excell macro's.
Your Windows based collauges will get use to opensource and be more open later on after they get used to it.
As a scientist I assume you use VB for similiations and or to interface with your devices for experiments.
For similiations try vtk++ and openinventor. Your colleagues probably used them in Irix quite heavily. THe libary comes with a great
If your equipment provider only provides
http://saveie6.com/
Well it's so simple you're gonna laugh, I'm controlling a two-axis pulsed-laser spectrometer. The problem is that I've got a National Instruments PCI-7324 stepper motor card to work with and even Comedi (which looks kewl BTW) doesn't support it. I can't blame them, there's just no information out there to start with. NI won't even reply to my emails.
:(
I thought it would be clever to implement a GUI using QT and then simply compiling on Windows with the stubs filled in to use the DLL. How wrong I was. The GUI looks great, but Trolltech's official position is that the Non-Commercial version of QT for Windows isn't supported any more, so you have to use QT 2.3 when 3.1 is out for Linux. I would have even ported my code back to 2.3 but then I would still need MS Visual C++ or Borland C++ Builder 5 (yes, I have version 6 and that's not binary compatible with the QT distribution). In case you're wondering, I did try MinGW but in the time I had available I didn't get anywhere because qmake still looks for a C++ Builder 5 DLL which I don't have. I could download the MS VC++ version of QT 2.3 but I expect to have the same problems all over again. And really if you've paid good money for a development environment like Borland C++ Builder 6, you might as well just use it instead. Oh and I did try to get the NI software running under Wine, I think I might have had some luck that way but I couldn't see how to get the Windows DLL talking to the PCI card in the time I had.
Then came a flurry of ideas for changing the stepper card to something else, say a timer/counter card, and use Comedi. But I quickly came to the conclusion that I've wasted enough time, I have a working stepper card already, and my supervisor really wanted a product using VB anyway because it's the easiest way to get physicists with zero coding experience to use and modify the application to fit their needs. It's logic I can't really beat right now, I wish it weren't so, I *so* wish I could hand him a free software solution with the same benefits to him as a VB solution, but I just can't.
Oh and if you were still wondering, I have to use Win95. That or replace it with the free (as in beer) OS of my choice, which would be Mandrake 9.1. Maybe I'll get an upgrade to Win2K but it bothers me to pay good money for a piece of software I wouldn't need if a) the original Win95 worked without blue-screening randomly, or b) NI would have some Linux support.
There's a guy upstairs who used to have an entire lab running GNU/Linux until he battled Agilent's and NI's lousy Linux support. He finally gave up and converted his lab from Linux to Windows (at great financial cost) so he could keep working on his experiments. Along came the customary driver conflicts, forced expensive updates, etc. etc. It's a sad tale, and it's what I was told when I began asking around in desperation. Now I know he wasn't kidding around
Yes and no.
A research lab, especially a public one, is first and foremost obligated to do science. To clarify what I mean by this, let me say what I mean:
The experiment must
In a physical experiment, it is perfectly acceptable to use a proprietary kit, provided that you can:
That is true for physical experiments. For manipulation of the data of an experiment, however, the procedure must follow a published or publication-pending method of analysis if you intend to have your research be considered legitimate.
It is coming to pass that algorithms are becoming complex enough and analysists savvy enough, that it is often more practical to produce clear, well-documented source code in addition to your paper than it is to go over and over again the fine points of your method with every interested party.
This leads me to my point: in physical interaction, proprietary and closed methods will most likely remain prevalent for many years to come.
In information manipulation, however, open methods are becoming a dominating trend, if only for the clarity they afford.
In my lab we do bioinformatics research, and we could not do research on the scale we are doing at the pace we are doing it if we were depending upon proprietary software: the proprietary companies cannot compete on customization, new development (after all, we're the ones creating the method), user interface (we're improving all the time, most proprietary packages have ancient user interfaces that are clunky and just plain awful, read: GeneSpring and friends), and cross-lab communication and auditing.
These proprietary solutions are forcing many theoreticians to use software that is "open" in another way: Excel. Yes, I kid you not. Quite a bit of bioinformatic analysis development is done in Excel because the proprietary solutions are just too closed.
The only proprietary companies that are on the right track, in my opinion, are the ones that allow you to use the app as a hub for many other componentized programs.
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;