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.
The problem I believe is that Microsoft products are so commonly used, that for a relatively small business (as opposed to the whole german goverment) it is detrimental to go against the flow. What about software that is specifically written for windows and not alternative OS's? You CAN make a statement and try to use another OS, but you are only going to hurt yourself from a business perspective
..you choose whatever platform/software that will do the job the best.
Functionality
Availability
Budget
Useability
Philosophy is far down the list.
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.
That is all.
Depends on the research I guess:
o v/torc/
http://www.csm.ornl.gov/
http://www.csm.ornl.g
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, though there will generally be some mix. Here, compute power is usually linux/unix, developer platforms are generally linux/unix, office work is usually windows - though sometimes windows has some software that is really kick ass.
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it
And this software *couldn't* crash the operating system if it weren't for bugs in *something* with OS-level privileges allowing the buggy software to bring down the rest of the box. Otherwise just the one buggy program would crash and the rest of the system would get along just fine.
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 hardware for which drivers haven't been officially accepted into the kernel yet), and X has gotten dramatically more stable in the last five years or so.
Keep in mind, too -- while a FreeBSD base install is made up of software built by the same team that wrote the kernel, a Linux distribution is almost *all* 3rd-party software. From that perspective, saying that the free OSen will get unstable when there's 3rd-party software available for them is rather untenable.
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...
This post is mindboggling wrong in so many ways it's probably a troll, but here goes...
"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, instead of having to fight with vendors to prove that it doesn't work, then wait 6 months until the fix fits into their product update cycle. (NB: not all vendors suck, just the big ones)
reliability: for many applications, open source software is better than proprietary because there are _more_ people improving the system. For specialized applications from small companies, there may be only a single engineer, whereas an open source system can benefit from the direct involvement of all of its users. Also, vendors have an agenda to hide problems (you often are required to sign an NDA before receiving bg fixes so that you can't even tell the vendor's other customers about the problems you found), while open source app's status is transparent, so it _has_ to work.
Finally, the "windows" environment is far from standard -- beyond major changes between every different OS MS has shipped (95/98/ME/NT/XP/CE, home/server/embedded, etc.) there are zillions of patch levels and, even worse, random OS patches installed by MS Office, IE, WMA, etc., installers. It's nearly impossible to document, much less duplicate a specific Windows configuration without making a disk image and completely standardizing all hardware. Also, it's literally impossible to purchase most versions of Windows (MS only sells the current versions), so it's impossible to legally duplicate an older environment. With Linux (or BSD) I have access to any revision of the platform and any applications. Not that configuration management is easy, but it's doable. And since there aren't any licensing issues, I can build out any configurations I need without requiring me to keep track of certificates of authenticity, or whether I have to pay a second OS license for a box because I installed a different copy of the OS than the one that was shipped by the OEM.
Users don't care about the OS crashing. They care about the application crashing. And users of dedicated machines in a research lab care about a dedicated set of applications. So it makes no difference if the application crashes the OS or the application itself just crashes. The user is going to say 'the computer crashed again' and the whole user/root timesharing mindset of the freenixes will be irrelevant.
Likewise, the most critical data on a system actually used for productive work is the user-writable data in the home directory and/or on the shared user-writable network drive. Again, it makes no difference that the OS can't be screwed up by the user. If a script s/he downloads from somewhere smokes his/her home directory, the significant damage is done.
a Linux distribution is almost *all* 3rd-party software
That statement demeans the whole purpose of what's called a 'distribution.' A 'distribution' is and should be a tested and known well-functioning collection of software made into a usable system. That's radically different from the third party software a user drags in from, say freshmeat and inflicts recklessly on a system.
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;
A 'distribution' is and should be a tested and known well-functioning collection of software made into a usable system.
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 other side of the spectrum, there's one very popular distro that I suspect doesn't even have a QA process. Another has the reputation to avoid their dot-oh releases.
I would put up with this shoddy QA if it were done by non-commercial distros, but the strange thing is that the non-commercial distros have the highest quality! Go figure...
A Government Is a Body of People, Usually Notably Ungoverned
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 -
Specifically quick-and-dirty Windows *GUI* apps, kind of like Hypercard was for the Mac.
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*?
May we never see th
All I want to know is why the fuck are the hardware makers so damn reluctant to tell you how to use thier products (as in write drivers for them)? Does Microsoft have that much of a stranglehold on them or is there some other consideration (such as possible appropriation of trade secrets or some other such nonsense.)
...as does IGOR, which someone else mentioned:
LabVIEW
IGOR
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.
Speaking of NI, some labs I've worked with use LabVIEW. Yes, its prohibitively expensive (especially compared to VB) but its spectacular for scientific RAD. Plus, the programming is wholly graphical, which should be refreshing to those scientists that have no experience with text-based programming.
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 good for providing drivers for LabVIEW. An open-source project would lack that unless they also implemented their driver system, which would probably get that project in big trouble.
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 sure what protocols your company uses, but at my company, nearly everything is GPIB controlled. Most stuff in the past was either done using LabVIEW or manually - In my lab it's almost all Perl these days thanks to me.
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.
retrorocket.o not found, launch anyway?
Yeah, if I worked as an application engineer for that company I definately want a phone call from you ever ten minutes "hey this doesn't work right... how do I do what your software already does?"
See, they *advertise* the cards and hardware as what they are... They work, they have windows libraries. If you don't want to play by the rules, don't buy their hardware. But don't buy the stuff, then give the poor people who work there a hard time because you're a nutsack.
Call them up, "Do you have FreeBSD/AmigaOS libraries for your product?" "No, we don't" "okay, I will find a product that does". If enough people were calling them with that, they'd be making FreeBSD/AmigaOS libraries for their hardware.
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.
For products with simple hardware interfaces, releasiing the register data is often a good solution in order to sell products to customers with very specific needs. At the company I work at we do release the register data for several of our products. It's in the hardware manual you get with the products, and our application engineers often have experience writing drivers for those products and can answer some questions to help customers write their own drivers.
However, we don't mark our products up enough to pay for us to provide the kind of support that some customers need while writing their own dirvers.
I just got a phone call while typing this and just spent the last hour trying to get information for a customer about a hardware feature that we don't use in our own drivers, so none of our software engineers could tell me how it works.
Supporting someone else's driver development is not a simple task when the hardware is not simple task, and the customers usually don't have the proper tools such as a PCI bus analyzer to debug problems when they occur. I've done a lot of ports to a lot of systems, and seen a lot of problems where the driver is written correctly, however the motherboard manufacturer of chipset designer didn't follow or implement the PCI spec properly and problems result. This could result in poor performance, or even data being dropped between the PCI Bus and the memory controller.
Supporting other people's developement can be very expensive.
Supporting Linux drivers also has it's own issues. We provide Linux drivers for our products on both X86 and PPC systems. I've seen drivers that work fine with one kernel revision break with the next minor revision. Linux customers also like to apply kernel patches which sometimes break our drivers. It's impossible to properly retest a complicated driver every time a new kernel revision comes out. We often ship customers a borad and a driver that was tested with a version of Linux other than what the customer is using. We warn the customers of this, however if they run into problems we end up having to load a system with that version of Linux and testing it to discover if there really is a problem, or if the customer has doen something strange with their configuration.
Even though we have Linux drivers there isn't a huge demand for them. This results in us spending a lot and time and money supporting an OS that isn't making us as much money. This is one of the main reasons a lot of hardware manufacturers don't bother with Linux support.
One other reason is that you often use third party ASICs in your products, and how to interface whith their registers is often provided under NDA, so that it's impossible to release to a customer without proper NDAs and licensing agreements.
Yet another reason is that often the hardware provides only a small portion of the functionality of the product. The rest of what makes the product valuable is done in the driver. If you have a product that uses commodity hardware and provides additional functionality though software, you can't simply give away the source code to that software and still pay for your development. People will take your software and buy the hardware from someone else, which can sell the hardware cheaper because they didn't invest in the software development.
Many of these issues depend on the hardware involved. Others depend on the skill and resources of the customer.
In the case of our Company we are willing to work with customers to provide reasonable solutions. However for customers that want to buy one hardware unit, and want us to help them develop a custome driver for their particular OS and platform, those solutions are usually very expensive.
If a driver on Windows with an interface writter in Visual Basic meets the technical needs of your project (including reliability) then it's often a pretty cost effective choice.