Running a Research Lab on Free Software? 354
"[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."
Name Drop (Score:2)
Uh... (Score:5, Funny)
Re:Uh... (Score:2)
VB is very useful to create windows only apps quick and dirty. Infact I dont know of a language/development environment where i can do that quicker.
Re:Uh... (Score:5, Insightful)
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.
Re:Uh... (Score:3, Interesting)
One example, (albiet cheaper one) I've been dealing with is a simple scale that sends data over a serial port to a PC. Using VB, you can occasionally get reliable results while taking data into Excel. Even through the software to do this cost as much as the scale.
On the other side of my fence, I've been using Linux for about a year now to do video capture and acquire temperatures from a networked
Re:Uh... (Score:3, Insightful)
However, we don't mark our products up enoug
A couple great alternatives (Score:5, Insightful)
The other alternative I can think of is RealBASIC [realbasic.com]. 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.)
Re:A couple great alternatives (Score:3, Interesting)
Re:Uh... (Score:3, Insightful)
The question is, if you're going to write a single app and throw it away, why are you wasting time on a GUI at *all*?
Linux in Research (Score:5, Insightful)
Comedi (Score:5, Informative)
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).
Re:Comedi gooooood, APM baaaad..... (Score:5, Informative)
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.
Re:Comedi gooooood, APM baaaad..... (Score:2)
Nope. Since fairly recent desktop machines without PCMCIA slots are perfectly capable of sleeping/hibernating with the apm 1.x spec. And, yes, APM interrupt handling is involved here.
And the last thing I need is having a desktop box fall to sleep when I'm doing benchmarking of (say) C library function calls for an extended period (a.k.a. generating datasets that need to be reliable to make sense).
Although i.e. my de
Re:Comedi gooooood, APM baaaad..... (Score:2, Informative)
David Schleef pointed this fix out to me after I asked him very politely about what the $#@$ was going on...
Re:Comedi gooooood, APM baaaad..... (Score:3, Insightful)
An opensource group would do well to attempt some sort of "workalike" to the language - the ease-of-use is stunning.
That being said, part of the reason it is popular is that instrument companies are pretty goo
Re:Comedi (Score:5, Interesting)
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
Re:Comedi (Score:4, Insightful)
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
Re:Comedi (Score:4, Insightful)
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.
GPIB cards (Score:5, Interesting)
Recently this went so far that I had a very candid talk with one of their sales people. I made it clear I would move to a different manufacturer if they would not provide drivers or some means for me to write them. He would ask within their organisation. Several days later I received an email titled "Solution to your GPIB driver problem". To my astonishment, it gave contact details for several other manufacturers of GPIB cards!
So, isn't this weird? They'd rather lose our custom than provide us with a driver, or sufficient details to write our own! And given the amount of stuff we are buying from them that's a pretty big decision.
So now we are talking with National Instruments, and they are very pleased to have us as customers. Moreover, they have Linux drivers for their GPIB cards. I haven't seen these drivers yet, and I sure hope they will be of acceptable quality.
I'm interested in hearing what experiences other people here have had with GPIB cards under Linux - especially those of NI, which we are about to buy. When you mention lousy Linux support, does that include their GPIB cards?
Re:GPIB cards (Score:3, Interesting)
As a 9yr veteran of Agile
cool. (Score:3, Informative)
Re:cool. (Score:2, Interesting)
I second that sentiment!
"Alessandro Rubini's excellent book Linux Device Drivers (another fine O'Reilly publication)" Ahh, knowledge, what could be finer. Free software, free info. Go get it and become the research tech God you want to be.
Well I've read Linux Device Drivers, nearly cover to cover, and I've implemented Linux drivers for the chip I designed during my Engineering Honours project. So I'm not scared of doing it although I know of how much effort it takes. The main thing
I know. (Score:3, Interesting)
Ah, that's what my knee jerk reaction [slashdot.org] was all about. Discresion is the better part of valor. Use hardware that's got drivers already for new projects and use the old junk till it blows up. I presume someone will have sucess stories that I was only able to dream of four years ago.
I get ill thinking of VB. Learning C++ and the win95 API was easier for me. One week of happy brainwash VB trainin
When I was a work study (Score:4, Interesting)
Funny thing is, the two and a half weeks that the "all BSD" lab lasted, we had no work orders concerning crashes. I learned BSD only because the LAN manager in question made me learn it to move a email server over to it (Novell GroupWise used to be VERY expensive, and this square-headed manager didn't want to pay a bunch of cash to run one secure and isolated mail server on Novell stuff).
Business is business I guess.
Re:When I was a work study (Score:2, Insightful)
Re:When I was a work study (Score:3, Insightful)
Sure, you have the same problem in Linux or FreeBSD if you have a 3rd-party app twiddling a buggy kernel driver or X server -- but buggy kernel drivers are exceedingly rare these days except in corner cases (say, complicated ha
Re:When I was a work study (Score:2, Insightful)
Likewise, the most critical data on a system actually used for productive work is the user-writab
Re:When I was a work study (Score:2)
What if the university buys a new software package for the whole lab and later finds out that it fucks all the machines up? Your lab is gone until the problem is fixed.
The former poster does have a point about distributions comming with beta quality packages. May god help you if its rpm based and you can not downgrade to m
Re:When I was a work study (Score:3, Insightful)
If only that were the case. But all too often it is not. Debian and Slackware are exceptions, but the others (even Gentoo) have the motto "ship tomorrow's release today". Debian is utterly stable (if you use stable) but the number one complaint with Debian is that it's so outdated. Slackware is frequently dissed by having a nine month release cycle instead of three or six months. On the o
Re:When I was a work study (Score:5, Informative)
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.
Re:When I was a work study (Score:3, Informative)
The registry has ACLS, just like the filesystem. You can only screw up the keys that you have access to (namely, your own personal profile).
Labview (Score:5, Informative)
Your time is your most important resource. Don't waste it recoding.
R.
Re:Labview (Score:2, Informative)
Re:Labview (Score:5, Insightful)
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...
Re:Labview (Score:2)
Re:Labview (Score:2, Interesting)
Your time is your most important resource. Don't waste it recoding.
That's some good advice, I agree. But still my ideals die hard.
Re:Labview (Score:2)
LabVIEW also runs on OS X (Score:3, Insightful)
LabVIEW [ni.com]
IGOR [wavemetrics.com]
Re:Labview okay, Igor Better (Score:2, Informative)
I work in an IR laser lab actually doing labview development and it is VERY easy to program with.
Do it on a project-by-project basis (Score:5, Insightful)
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.
Re:Do it on a project-by-project basis (Score:4, Insightful)
Thank you.
the problem (Score:5, Interesting)
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.
Device Drivers (Score:3, Informative)
Since you mentioned you did some coding, you may want to check out Linux Device Drivers [oreilly.com] plus some of their other kernel tweaking/modding books [oreillynet.com].
Re:Device Drivers (Score:4, Informative)
certain hardware manufacturers utterly refuse to support anything other than Windows
Since you mentioned you did some coding, you may want to check out Linux Device Drivers plus some of their other kernel tweaking/modding books.
Buying a book isn't going to get her the board spec, unfortunately. To get the job done quickly, she'll need the board spec.
Otherwise, she could start by using the generic pci driver [gsp.com] to probe the board's parameters in freebsd, or use phob [linux.it] to observe the board's parameters.
This would be an excellent chore for a grad student, as it would provide her with a useful skill while not really interrupting her studies of, e.g. The Effect of Gamma Rays on Man-in-the-Moon Marigolds [amazon.com]
Re:Device Drivers (Score:3, Informative)
pick your hardawre more carefully (Score:5, Informative)
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.
Re:pick your hardawre more carefully (Score:3)
The key isn't to just demand more money (though it can't hurt) but to hav
Obviously... (Score:5, Insightful)
Functionality
Availability
Budget
Useability
Philosophy is far down the list.
Re:Obviously... (Score:5, Insightful)
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.
Best tool for the job (Score:5, Funny)
Controlling quantum computing using VB? (Score:5, Funny)
Realities are.... (Score:2)
Programming in VB? (Score:5, Informative)
NOOOOOOO!!!!! (Score:3, Insightful)
Don't do it! If you have to learn something, at least go to C#. Visual C++.NET would be OK, too. Both of those are better languages all around. And you can still interface to DLL's with either. To almost any programming question VB is NOT the answer.
Re:NOOOOOOO!!!!! (Score:3, Interesting)
1. You have programming skills, no one else in the lab does (they're all scientists with pure science backgrounds, you're the only one with a mixed engineering/science background), except the staff programmer. He is good, but also thinks there's nothing wrong with VB. Fine. Your code needs to be read, supported, and developed once you're gone.
2. You need a little experimental control program with a GUI that is
Re:NOOOOOOO!!!!! (Score:5, Informative)
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).
Re:NOOOOOOO!!!!! (Score:4, Informative)
In fact to many programming questions VB is the perfect solution. Why do you think there are so many VB programmers and VB apps out there? Its so easy a complete novice can learn how to build reasonable applications quickly. As applications start getting more complex then by all means use Java, C# or C++, with more experienced developers to do it properly. In a lot of cases VB is perfect for quick simple solutions. Some of the stuff I have seen talented coders produce in VB is not half bad either.
C++, great suggestion (Score:2)
And one more thing, drop the elitism. Maybe VB isn't the answer to your programming questions, but when I need a graphical
Not ready for precision? (Score:3, Funny)
First, naturally, there is the question of "Who do you sue" when things go wrong (which in itself is a statement of the issues surrounding responsibility in community development.) Commercial software vendors strive to meet a standard of reliability because they've implied with the sale of their software a warranty of fitness.
Also, there is a question of reliability. Commercial software is designed towards a goal; Open Source is designed almost by accident. Integrating commercial products tends to work better than Free Software because of an accumulation of tolerances.
Most importantly, using commercial software makes repeatibility in other labs a more likely possibility. A Windows setup is standard. A Linux (or whatever) setup depends on any number of factors, from the versions of the software to the distributions of the kernels. Irregardless of the general expense involved in setting up commercial software testing, this is perhaps the most important thing: your colleagues won't have a chance at duplicating your results if they don't know what you're running.
Re:Not ready for precision? (Score:2, Insightful)
"who do you sue" isn't relevant; you can't meaningfully sue a software vendor, because the licenses almost always absolve them of all liability for their product's failures beyond perhaps giving you back the purchase price of the software (which is meaningless compared to a failed experiment). if you actually want the software to work, you're often better off with the source code so that you can make it work yourself, in
What's valuable to you? (Score:5, Informative)
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
PS (Score:2)
Muerte
ps. sorry for being such a troll to reply to my own post.
You gotta be nuts. (Score:3)
Au Contrere, my silly AC frere. If you got stuck with some fancy device that only works in windblows, the least you can do for youreself is learn to use it's C interface. Almost anything that has a dumb VB interface also comes with one that works with C. While VB works for M$ and only M$, C is everywhere and a much better thing to learn. All VB can add for you is a dinky interface and loads of heartache and rewrites.
Lab view might be useful, but real labs do
You said quantum computing? (Score:5, Funny)
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."
What about running Free software on Windows (Score:5, Informative)
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
Re:What about running Free software on Windows (Score:3, Informative)
Not necessarily true. I work on research for the university I study at, and the particular branch I work on uses comedi drivers [comedi.org] to interface with our pci data acquisition boards. Take a look, it might support what you're using.
Many things people would ordinarily think linux can't do is already, or will one day be possible, so keep looking. A lot of people tend to t
Start with new projects. (Score:4, Interesting)
What about trunking DLL's? (Score:2)
Maybe the sci apps developers should investigate how the trunking of manufacturer supplied win32 dll's can be used to give at least x86 machines with free operating systems access to the hardware. It's better than nothing at least.
But yeah, I know it sucks. The hardware vendors shouldn't whine. They shouldn't care what OS is used to drive their hardware, j
Phew (Score:2)
Well, thank goodness for that!
Sometimes it's the other way (Score:3, Interesting)
Yes, it is possible (Score:2, Insightful)
http://www.csm.ornl.gov/
http://www.csm.ornl.g o v/torc/
we are mostly linux. We do some windows because we choose too (for varying reasons, most of us really like Open Source but are relativly OS agnostic).
Besides our CS work we run things such as the human genome project, nuclear fallout modelling, vis applications, process data from some of the colliders, basically govt researchy type stuff.
So yes, it is VERY possible to run a research lab under linux, unix, or windows, t
heisenberg is rolling over in his grave (Score:5, Funny)
You guys are trying to get Windows running on quantum computers? Talk about uncertainty!
Re:heisenberg is rolling over in his grave (Score:2)
ActiveState (Score:4, Insightful)
its' the fault of the professors (Score:2, Interesting)
A researcher with certain year of experience would have thru the nightmare of getting obsoleted hardware to work - it's not that the hardware itself is getting out-dated, it's about its interface i.e. the device driver. E.g. the VPL optical gloves are still usable today as we've the driver source came with them, even when the comp
Open source DARPA projects (Score:2, Informative)
Not only is the project using open source as the infrastructure, but contributing to the open source community with projects like Cougaar [cougaar.org] and PMD [sourceforge.net].
We use Linux primarily because of the simplification of administration and maintanen
If it ain't broke (Score:5, Funny)
I know what I'm missing out on, in the free software world.
Followed immediately by:
I've wasted a *lot* of time and effort trying to implement some very simple stuff with free (and better) alternatives
Yeah you're missing out on the struggle and pain of hacking together ad-hoc solutions to an already-solved problem.
Way to go, buddy.
We use *nix (Score:2, Interesting)
Linux and LabView? (Score:2, Interesting)
QNX - Free as in beer (Score:2)
Linux isn't really mature yet for real-time control. Another year or two, and it might be a contender.
As for Visual Basic, my controls people all want to use Matlab.
Use Python instead of VB (Score:3, Informative)
VB and data acquisiton (Score:4, Informative)
Our shop builds test equipment with lots of analog and digital I/O - some of it high speed.
We started off 20 years ago using C but switched to whatever-the-current-version of Microsoft's BASIC was at the time. Each system was unique and you can't beat VB for fast coding/debugging.
In the beginning we had to write assembler code to access the hardware regs on the acq boards for speed but when DLL's began to be supplied with the hardware things got much easier. The huge library of controls and DAQ add-ons for VB just cannot be ignored. For a laboratory the advantages would be similar - fast prototyping and debugging for unique applications with lots of off-the-shelf code and low labor costs. VB has it's faults but for this kind of work it is well suited.
There is really no economic advantage to using free software in this instance.
Re:VB and data acquisiton (Score:2)
P.S. I write instrument drivers for a living.
Flamebait, I'm sure... but VB kicks ass now. (Score:3, Insightful)
Re:Flamebait, I'm sure... but VB kicks ass now. (Score:2)
Wine? (Score:2)
the politics of IT change (Score:5, Interesting)
First, re convincing colleagues that open source / free software has a role in your work: do something they envy. Produce a tool they want to use, or find some existing software that does something useful and cool, or even just do the great unix thing of tying a bunch of small programs that do one or two things well together to do something that no existing monolithic package really offers. Then point out that it either can't be done on the current platform of choice, or, while it can be done, it requires spending $$$ on some proprietary solution. Doing something like this tends to legitimize the use of the toolset you'd like to use, and gives you a good foot in the door for more abitious moves later.
Second, re working with third party suppliers who don't currently produce software or drivers or whatever that work with non-MS platforms. If there's more than one vendor who supplies something that does what you want, pick the smallest one. They're more likely to be interested in finding niche markets, less likely to be bogged down by bureacracy when it comes to doing something new or different. And a three-person company is more likely to have two of the three who've recently been working in your field & remember what it's like trying to do the usual research thing of trying to get an existing tool to do something that no-one's done before - hence more likely to give you access to the kind of more detailed information you might need, even if they can't really expend the effort themselves right now.
Anyway, that's my take on 'what worked' after a couple of years of win-some, lose-some politics around research and IT.
What hardware (Score:5, Interesting)
If you need real-time look into QNX.
BTW we operate what is probably the deepest running webserver. We have a vehicle monitoring system that is controlled via a Linux/Apache machine setting at depth reporting topside via fiber connection. This system controls power reports temperatures, pressures, inclination, depth, smoke, leak, etc.
Not quite Quantum Computing, but... (Score:3, Interesting)
Our lab is entirely Linux (Score:2, Interesting)
My Experience (Score:3, Informative)
In my experience... (Score:4, Informative)
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!
Specifications and how to get them (Score:5, Insightful)
[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.
A mixture of Open Source/Commercial Unix/Windows (Score:3, Interesting)
I'm a Physics UG at the University of Oxford, and have done the odd part-time job writing code for some of the groups (I worked for CMP last year and will start in the Teaching Course next month). All of the code that I have written was released as OSS, because other research groups can then modify it and use it in their experiments, without affecting the originality of our work.
The systems I worked on in CMP were almost entirely Red Hat, and some of the code I had to work with was being ported to C/Linux from Delphi/Windows it was stupid to ask people to pay for Delphi licenses just to tweak a few lines of code in a detector controller. Some of the older computers were running Win95 with X11 and SSH clients and were just used as terminals for the beefier Linux boxen.
The computer I'll be using in my next project is a little meatier, a four CPU Sparc box. There are a couple of these in the department, each with a few dozen SunRays attached. The code developed on here will still be OSS, and the box has a fair amount of the GNU userland sitting side-by-side with the Solaris rubbish.
Other than that, my knowledge is a bit sketchy and is inferred through what I hear or see around the department. There are a number of Windows workies around, because software like SPSS or Origin or Minitab only exists on Windows, and there either don't exist Unix or Linux alternatives, or they aren't yet mature enough to want to switch onto. Many of these workstations also have Cygwin or at least DJGPP.
But the main point to be answered is whether or not a research group should be OSS. My opinion is yes as far as in-house code is concerned, because this facilitates collaboration between groups using similar code, hence quickly smoothing bugs. OSS also neatly fits the philosophy of shared information many scientists have.
Should the computers all use Open Source operating systems? I just don't think this should be a requirement in most cases. Yes Linux and the BSDs are stable and mature enough to be used in a research environment, but then so are Slowlaris and Mac OS X, and you can develop and build your code on both of these systems too. The only situation OTTOMH in which having an OSS OS would be directly beneficial is when custom-built embedded devices are required, for instance in HEP detectors or beam controllers. In these circumstances the ability to modify the OS kernel would be useful, but if you're just developing your C code in a Unix environment to be used on bog-standard Unix or Linux machines, then a good set of manpages and a functional cc is really all that's needed.
Matlab! (Score:3, Interesting)
I switched to Windows 2000 Pro for the vastly superior support for data acquisition hardware, framegrabbers, and so on. Along the way I switched from doing GUI stuff in wxWindows/C++ to Matlab. The GUI stuff in Matlab 6.x is pretty good. It's got a bigger learning curve than LabView but it can also be used to implement much of your data analysis as well, with its vast libraries of mathematical functions and decent performance.
With the new hardware coming out, our lab now has a standing policy to only purchase items with USB or FireWire interfaces whenever possible, so the PCs don't even need to be opened up anymore. These drivers are rarely if ever available for Linux.
Use whatever makes your lab the most productive. Standard lab software like LabView, Matlab, and Mathematica are a safe way to implement software since they're so popular and they're more efficient and productive than C/C++ or VB. If you need high performance computing, then go consider F90, C++, etc., but instrumentation should never be controlled like that. You need real time? Buy a real time board.
Some straegic thoughts (Score:3, Insightful)
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.
GPIB? (Score:3, Insightful)
http://www.mock.com/gpib/ has an excellent library for GPIB in Perl. It only supports older equipment, but at least in the GPIB world, nearly everything has a published command set, and the library makes adding support for other instruments extremely simple. (I have yet to find an instrument that didn't have detailed programming info. It takes me an average of an hour to implement most of the funcionality of a new piece of equipment. Sadly, the work I've done on that lib will most likely stay in-house.)
Now if only Octave had the external interfacing capabilities that Matlab did. (Even with some of the "Matlab compatibility" libraries like octave-forge, Octave is still missing a ton of signal processing toolkit functions like psd() - Octave will also not interface with any of our digital I/O cards). Even Matlab under Linux won't help us here.
In short: We've basically replaced LabVIEW with Perl here (to much rejoicing - People at this facility are more familiar with text-based programming than GUI programming.), but I don't forsee us replacing Matlab any time soon.
Linux DAQ hardware (Score:3, Informative)
There's a lot of VME/VXI hardware out there that will also work well with linux kernels (I've done it). Compact PCI (cpci) should work as well, although much of it seems to be driven by x86 / Windows embedded computers...
Any hardware which communicates to the workstation via a standard interface (ethernet, usb, gpib, serial, etc) should work just fine.
The real issue is simply checking the vendors of your hardware BEFORE you make the purchases to see if the hardware is supported. This should be true with any hardware purchase. (It is possible to buy hardware that doesn't work with Windows...)
If you're trying to use legacy instruments (which you already own) whose manufacturer does not support Linux and who refuses to release interface information (because of it's proprietary nature); well then, you're out of luck unless you can kludge an interface with a Windows PC talking to the device(s) (acting as an ad-hoc interface) and a Unix system doing the rest of the work. You'll get better performance this way than trying to have the Windows PC do all the work.
I'd urge you to use Unix or Linux variants for data acquisition and controlls. Windows is not deterministic and DOES NOT do real-time (I don't care what Microsoft says or how fast the machine runs).
that's just my 2cents worth...
What exactly are you missing out on? (Score:4, Insightful)
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.
Re:windows-only, huh? (Score:2, Interesting)
Well according to your next post you think I'm working on NMR quantum computing. I'm not. It's an optical scheme involving coherent transients in rare-earth doped inorganic crystals. So we aren't using a bought system, it's a system that's been put together over a decade, out of all sorts of discrete pieces of equipment, many of which were not bought by us for this purpose, all of which must be usable under a given OS for the whole experiment to use that OS. The only software that real