Hi.
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
+1
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)
regards
Peter
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...