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."
I've found it somewhat difficult to use since building their modules is really suggested on a generic rather than stock Redhat kernel (and building with what are claimed to be the RH sources and config files didn't work for me).
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.
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.
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
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/
If a user is running an app and he/she has just regular user priveldges then even a virus can not do damage. This is because the kernel checks access rights for files, directories, and programs. The important ones are marked "root" and unix will refuse to touch them unless the user is logged in as root. Windows NT, 2k, and XP have different users as well but the internal access rights are different. Any program can access the registry in Windows no matter what the user priveldge is. Thank Windows95 for making this standard. No app will run if you take that priveldge away sadly. This is where all OS and app information is and what causes 80% of the problems with Windows. Also as a developer you need administrator or root privedlges in WIndows to use com and the memory debugger. Another problem with WIndows.
Dll management is the other that causes those GP faults.
Unix is just better designed for this. Windows was never really designed but its a constant evolution from single user dos with a whole bunch of bandaid solutions.
One of these bandaids is the registry. The vast majority of screwups in Windows have do with an app or Windows itself corrupting the registry and fucking up the whole system with it. Only in W2k and XP 5 years after ms introduced the registry with WIndows95 did they began to fix this with registry tools and automated checkups. Its still really bad but registry corruption and dll management has improved. A bad app can still screw this up.
Everything in Unix is a text file so nothing gets corrupt unless its a hardware problem or a user did something dumb as root. Even the hardware is just text files in
Believe me I say that a bad programmer can write a bad app for every os. BSD is no exception but it certianlly is alot cheaper to use and operate. For a lab its essential to have good uptime. Especially if students needs these systems. A problem will usually never require a complete re-install. Just a fix with the app or config file that the particular app uses. Good os design is important in a lab environment.
http://saveie6.com/
Either that, or I'm way behind in the quality of Open Source RAD tools
You're way behind in the quality of open source RAD tools.
The python-libglade solution isn't as flashy as VB, but it's an extremely easy way to throw together an easily modifiable GUI app *fast*.
(Btw, I presented on this particular combination to my university's LUG a year or two back after writing a fairly fancy virtual machine/simulator frontend literally overnight in about 100 lines of python code and an XMl file created by dragging and dropping in glade).
I'm working in a lab doing "Quantum Chaos" experiments (manipulating cold atoms to investigate the difference between quantum and chaotic physics). We use the free (as in beer) version of RTLinux to run all our experiments, as timing is important and we didn't want to implement a hard real-time system. I coded most of the gui for the experimental interface using Borland Kylix and everything works quite nicely (apart from some evil memory leaks).
The real problem is the hardware - a real guru set that up for us. He wrote the "drivers" for the I/O cards himself (although that's meant to be a little easier in RTLinux than for normal linux) and also got a scientific grade CCD camera working even though the only linux drivers available were outrageously outdated. Sadly, we will definitely face some issues in the future if we want to upgrade to a new kernel!
Personally, I think the only way to move data files around is with a decent shell. Rename is perfect for all those times I put the wrong parameter in the file names of 160 different data sets. Most of the time our lab works quite smoothly with regard to the OS itself, and it's certainly an improvement on the old Win95/Scientific workplace combo of the past!