Distributing In-House Engineering Code?
caswelmo asks: "My company has recently moved from Solaris workstations to Windows workstations (Ohhh, the humanity). As an engineering focused company, we use our computers to run many in-house (command line) codes to analyze and design our products. We currently use NAS storage to store everything and use batch files and init scripts to run the correct codes over the network. This makes sure everyone is running the latest version. This also stinks. I know this isn't an original problem, so what are some other solutions for rolling out lots of simple codes like this?"
I don't know what is worse - that you went to Windows, or you had no idea how the heck to go to windows.
I have mod points and I am not afraid to use them
"Distributing In-House Engineering Code?"
I read that as "Disturbing In-House Engineering Code". Any chance we can talk about that, too?
"Derp de derp."
Wait a second.. you want to know what's the easiest and most efficient way to distribute code on Windows workstations?
Spyware, worms, and IE exploits. DUH!!
I think that Windows ships with the QBasic scripting / operating system language.
/e command.com > com1"
From what I hear, it's quite capable for simple "shell scripting" style tasks in Windows like:
"command.com
and
"echo ^G"
Have fun!
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
step 1: move all that stuff into cvs / source control system of your choice.
step 2: install cygwin on all the machines (http://sources.redhat.com/)
alternately: use ms's unix system services (go digging on the m$ website) theoretically this will give you a "real unix" running inside windows.
at least this way you don't have to spend as much effort porting your old tools.
They switched from Solaris to Windows? You don't work for this company do you?
"My company has recently moved from Solaris workstations to Windows workstations..."
Didn't check it first to see if critical work could be done?
Okay, here's what you do:
1. Send the person who made this decision to Singapore to be caned;
2. Send his boss to Singapore to be caned and send the boss' dog for caning too as the dog may be the true decision-maker here;
3. Get yourselves someone who has more than a two digit I.Q. to be your boss;
4. Profit!
Ciao.
Everything in the Universe sucks: It's the law!
...anything about code:
...he/she refers to source code as "codes". At least that's what the rumors on the internets tell me!
As an engineering focused company, we use our computers to run many in-house (command line) codes to analyze and design our products. We currently use NAS storage to store everything and use batch files and init scripts to run the correct codes over the network. This makes sure everyone is running the latest version. This also stinks. I know this isn't an original problem, so what are some other solutions for rolling out lots of simple codes like this?"
OtakuBooty.com: Smart, funny, sexy nerds.
I'll assume speed or CIFS creates the pain..
If you really need the speed, you can push out the code to the client machines and put a system in place to audit the distribution. It can end up being a bitch to maintain depending on how you dist and audit. You can write a script with rsync/robocopy and log errors and fix them or buy a commercial software package and check errors and fix them.
You spend the money to go to Copper Gbit and get some more speed, and keep the code centralized over CIFS. If you only need the stuff over the network for reading and not writing, and your apps don'y play well with CIFS, you could get some iSCSI drivers from MS (they're free) and put a initiator on your NAS box or in front of it, or bridge to it from an iSCSI->FC box. Then have your clients grab the LUN read-only over iSCSI and at least Windows thinks it's a local disk.
YMMV
-Vlad
Make python executable (with py2exe) on shared drive, linked from win desktops as shortcut and launch on startup.
said script has dedicated local directory like: c:\ourscripts\
and synchs everything from the network at launch. Script remains running and checks via xml-rpc for updates and will throughout the day get updates to particular files. If you do the xml-rpc check every minute, you'll have near-realtime distribution of cli scripts to windows clients.
I am assuming you have less than 1k people to do that with in your org. One server could easily handle it.
by the way, redhat autoupdate uses xml-rpc.
This has the advantage not to need any local machine deployments of software packages.
Let me know privately if you need this sort of solution built. Or ask the python mailing list.
"Piter, too, is dead."
just put all your scripts and whatnot into cvs, then write a nice little webservice interface to your cvs server and have your windows admin write a group policy to reference the URI of the script as a desktop icon via the Windows .NET framework and Active Desktop. The current/stable version is always called when the icon is executed and the user gets all the in-house widgets they need as part of the login process. All you have to do is manage your Active Directory and group membership.
Ok so the Solaris 'code' is on a NAS server, and it is run remotely. You also mentioned you recently moved to Win32.
Hmmm. It couldnt have been more unclear. Solaris most frequently runs on sparc architectures. Surely the code must be sitting one place, executing on another machine, and somehow the windows machines grab hold of the results...
So depending on your REAL situation:
(1) Run apache on the solaris box and display results.
(2) Run the code on a terminal server machine (Windows2000 terminal services or X11)
(3) Use rsync or the windows equivalent to redistribute code to all machines
(4) Use CVS
(5) Recompile the code for win32.
To get any more useful advice from slashdot, specify your problem better.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Actually, that indicates that it is really an engineering company. Among people whose first interest is science and programming is only a tool to solve scientific problems, it is common to refer to programs and libraries that solve specific problems as "codes". It is also a good bet that if it's called "a code", it's written in FORTRAN. And due to their science education, the authors were probably oblivious about principles of good software engineering.
...he/she refers to source code as "codes".
Old-school FORTRAN types often refer to single-purpose batch programs, like FEA jobs, as "codes". If you look in engineering magazines, HPC vendors often promise to run your "codes" faster than ever, etc.
I've seen the words 'codes' used quite frequently to refer to multipel variants of a given algorithm. This is especially the case with FEA analysis where there might there might be different versions of an algorithm depending on what type(s) of symmentry are exploited to simplify the problem and whether or not the analysis requires the use of complex numbers.
Come test your mettle in the world of Alter Aeon!
Sorry to burst your bubble, but referring to engineering programs as "codes" dates back at least to Fortran 66. It's still pretty common in the HPC world, and pretty much anywhere the focus is on getting engineering tasks done, and not on programming.
Envy my 5 digit Slashdot User ID!