... comments threads after 24 hours, on slashdot? Now we know which keyword turns off the slashdot crowd! :-P

+1. Yeap. You are on track, guys! The whole point is, that even if when we are involved commercially in a project, it's optimal to promote the usage of open source software anyhow, as a matter of enhancing community effort and investing time in a manner that you can benefit from it many times more in the future. Kudos.

OP here. Your concern is very valid and you are not alone, I have the same concerns. However, at the moment we know of no other standard that actually renders alike among zillions of Desktops, smartphones, automated processing agents etc. Can you really replace .pdf format with something of similar functionality AND not ask the majority of users to install X, Y, Z?

btw. have you ever heard of LRD? Language Restraint Disorder... I've spotted some examples over here: http://slashdot.org/~znrt

OP here. Somebody is listening ;-) Nope. It's not how you described it. But thanks to your nice language I need not explain you either :-P

Hi mark-t, OP here.

itext appears to miss two-three major targets:

• software architecture/api may not be too tidy; this is word of others, I cannot verify it since I've never used it
• unclear licensing scheme, not free of commercial clashes
• due to the above, community has been fragmented in 3 (?) big fragments :-(

Sorry to be cynical, but here it goes: Next time your smartphone slows down horribly or plainly crashes, remember the above words of you. It's how this game is played by you guys, yet all systems people frown upon the concept of "wrap around software deficiencies by buying more hardware"...

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/...