Hm, that rang a bell...

I also find inappropriate a similar recent evolvement within IEEE politics; in this case it relates to LGBT rights, see for yourself: http://www.hrc.org/blog/entry/... To be sure, LGBT rights are important and it is good that laws protect them - and more could and should be done about it. The same applies for Human Rights, overall; no person in his secular humanist mind would ever object to that.

It is doubtful, though, that LGBT groups would ever add banners in their statutes in relation to engineers' rights and ethics, so it is questionable why the reverse should ever be true. There is really no point in adding pompous statements in relation to sex, sexual orientation, skin color, disabilities etc. Making such a list is itself a kind of discrimination (!), since you hand-pick which kind of discrimination is bad, as if similar non-professional conduct is any more tolerable. Sorry, that's not correct and, it's even not fair for those who really cherish a generic concept of citizenship and may get discriminated for a reason not declared in the list.

Please, guys from the US, let's keep the focus on what the original subject is and, avoid making professional bodies appear as vehicles for (valid) political ideals, which distract from the original cause and warrant conflicting agendas! And if somebody goes against constitutional mandates, the juries are there to put things in order.

ACM carries a historic name, but subscriptions cannot justify buying just that. IMHO, most techie people do try it out and then have their memberships lapse.

A small step for a person, a giant leap for mankind. In god we trust, etc etc

who would you vote for, if you were in their shoes? I mean, really, who?

This!

I've been managing systems with hundreds of well-meaning and not-so- scientists, for years.
Generally, I subscribe to the school of thought that putting too many fences does more damage than good.

I know for myself, that I *can* create trouble in a zillion of ways on a system, that fencing against it is almost pointless:
* fork bombs
* malloc bombs
* /tmp overuse
* /dev/shm overuse
* deliver daemonized processes in the background
The first two you may handle a bit with the PAM limit techniques described by a fellow poster, but not without limiting the capabilities of the system (ie. you take out useful features, to enforce some policy). The rest you can attempt to handle with some other clumsy fencing techniques, but again not without side-effects.

In short, do not overengineer, yet be totally reactive: let the rules be relaxed in the beginning, monitor tightly, react quickly and be sure to have often your users at the other end of the phoneline/email justifying their tasks' activity. You'd be surprised how much you'll discover by doing that and policies will be far more justified.

> One thing that shouldn't be underestimated is the ability of a user (especially a young user) with *lots* of free time on his/her hands to figure out ways to game the system...

Also this!
Young users with lots of free time will give you a headache, one way or another. But you can often stop them by just blinking an eye.

To begin with, I'm a Pythonista for much of the time. Even so, I can see how you will probably land in the world of R; here is why:

• * R comes with reasonable facilities for statistical processing and, on top of that, has important extensions that allow for remarkable features. Example: Setup R language, with snowfall->snow->Rmpi extensions. The result of this would be *fault-tolerant* *scalable* code, within relatively simple codebase. It cannot be overemphasized how much functionality you get out of the box in such setup, with basically zero code changes (in R).
• * Python is great when it comes to integration with other languages/codebases. It could well be the best scripting language since... the invention of bread. As another poster mentioned, it can also interface with R via Rpy, so it's not at all a black-or-white decision.

In short, both are first-class tools for scientific computing and you should compare and choose them on technical merits basis.

In case you are in position to help as the article suggests and, you just need a little kick to get you in action, watch this one: http://www.gapminder.org/news/...

The biggest reason of interest is that it helps non-computer-science scientists write up computational codes, neither having to devote excessive amount of time in memory management, nor deviate from the classic imperative programming model. And, it is also important for a purely non-technical reason: a generation of domain experts in engineering and scientific domains where trained in FORTRAN codes.

As managers of High Performance Computing platforms, we generally take an a-religious approach and deliver to the users all possible permutations of language types that a given community may need. The following is a very common setup, containing both GNU & Intel compilers: https://hpc.uni.lu/users/softw...

btw. I'm not defending Fortran in any kind of way; ask any Fortran-fun, in which language his compilers are written in ... there is a reason :)

IFF you have even done wget/tar xvf/patch/make/make install - and wondered,
if this process could be ever improved and make sense, you have found your project!

EasyBuild allows you to tame scientific software of the following type:
* Download and build GROMACS over FFTW/3.3, applying patches X,Y,Z, using CUDA for speed.

Here is your initial reference: http://hpcugent.github.io/easy...
And here is the juice: https://github.com/hpcugent/ea...
The code lives across 3 repos on github, I am sure you will find your way.

Probably all you are missing over there are scheduled maintenance windows.

You give them a list once per month about what is about to change, get a confirmation, proceed with them available on standby for fixes on the spot or, rollback.

Try to think the big picture: how would you maintain the systems, if they were life-supporting medical equipment? Why not give same quality of service?!

OK, the rope won't do as much for accuracy as actually working out the math a bit, but nevertheless it WILL be better and more guaranteed result than a shotgun.

Also, if you can curry a shotgun for the post-apocalyptic world, you can as well carry a clay tablet with "355/113" written on it and save on the bullets for the moments that you will be in higher need... (having a monopoly on circular constructions might make you a highly sought target :-P )

Imperial Units also worked fine, until 1999-09-23: http://en.wikipedia.org/wiki/M... Having said that, what is your imperial definition of "dangerous"?!

the longer version of what you started above is here: http://hpcbios.readthedocs.org... (different people need different subsets, but the total is a safe bet)

...setting up a phone consolation center is so much cheaper than meeting all those expectations about monies!