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