I'm not happy with the decisions discussed here, too, and I don't want to support that decision with this mail, but if I understand it right, at least partly what you describe might be wrong.

If I read right, the Labs environment basically is a kind of private cloud, using lots of virtual machines as servers in a hardware setup of less machines with more power each.

If that's true and provided that the corresponding admins would allow it, then some of your points are wrong. (comments between your posts lines)

Am 26.09.2012 16:10, schrieb Merlissimo:
temporary blockers
* no support for script execution dependency (on ts: currently done by sge)
if scripts run on virtual machines of the labs environment, it's possible
1) to run several scripts on the same machine, keeping dependencies in the execution,
2) to run several scripts on different machines with execution dependency modelled by web apis/interfaces. For some combinations that's overkill in complexity, but sometimes it might be useful, too.
* no support for servlets
most likely wrong as it should be possible to use virtual machines running java and a servlet container like tomcat or jetty on it.
missing support blockers
* no support for new users not familar with unix based systems
* no transparent updating of packages with security problems/bug
permanent blockers
* license problems (i wrote code at work for my company and reuse parts for my bot framework. I have not the right to declare this code as open source which is needed by labs policy.)
well... yes, but I doubt this is a big issue at all for most toolserver users as when I joined the toolserver a (declared) open source licensing declaration was a necessary condition for the tools.
* no DaB.
+10 (well... or more)

And after reading a little bit more about labs some points to add:

- as DaB already pointed out: no OSM database, and it's not possible even to use OSM data as every content used has to be under CC-license, which isn't true any more for OSM.
- osm, which was a (not sure, how it was called exactly) partner project for WMDE - at least one that is acknowledged to be supportable by WMDE, is neither Wikimedia nor mediawiki and therefore not possible to work on at labs with projects, that are not directly incorporated to mediawiki (especially as the content isn't CC, see above)


P.S.: Interestingly very strict rules about personal data, but passwords are only to be hashed - someone could use unsalted md5 or even the hash-function myHash(s) { return substr(s, 0, 12) } which is a hash function, but neither cryptographic nor secure...