I got a few emails this week too. So this is the last list by me. If you still
on this list, don't forgot to send me an email till friday, or you will have
problems with login ;). If you send me an email allready and you are still on
this list, please come to chat and speak with me - one of us have problems
with email ;).
I don't understand why "sql" command gives access to any base on any cluster and "mysql" command gives access to bases on s2 cluster only.
sql enwiki_p runs
mysql -D enwiki_p doesn't run
sql dewiki_p runs
mysql -D dewiki_p runs
sql frwiki_p runs
mysql -D frwiki_p doesn't run
Under these conditions, tell me how does you start a command line query on s1 or s3 databases?
For example to replace:
mysql -D enwiki_p -e "sql-queries"
Thank you for your help.
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
I have submitted a BRFA for a redundant copy of the [[en:User:HBC AIV
helperbot]] and have been given trial approval.
I have setup everything on my own box here at my home but do not seem to be
getting any edits out of it at all... its been running for the last 7 hours.
Is there a possibility of running it on the toolserver without using too
much memory? The source code is available at [[en:User:HBC AIV
helperbot/source]] if you want to have a look :)
All I would need to have installed would be the following three Perl
Please let me know what you think - if it were to be run on the toolserver,
I would be very grateful :)
Thanks in advance,
Administrator | English Wikipedia
-----BEGIN PGP SIGNED MESSAGE-----
if a toolserver running Windows were available, would anyone use it?
are there people not using the toolserver (or not as much as they'd
like) because they are unwilling to learn Unix?
any other comments? (please, avoid comments about why we
should/shouldn't use Windows.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
-----END PGP SIGNATURE-----
River asked for technical only, I think.
I see some people going down the "windows sucks" path... and some going down
the "how do we license" path. Both seem premature to me (valid for later)
Hobby mail: Lar at Miltontrainworks dot com
Well, OK Danny.
I'm typing this on a laptop running WinXP (as the previous.)
Yes, Linux FTW, blah, blah, blah.
I have written some stuff in Cache MUMPS that I haven't yet converted to
GT.m. But then again, Cache runs on Solaris and RedHat (and Win*, and
VAX/VMS) so it isn't a reason to run on a Windows platform in and of itself.
Anything I port from my home Linux server or from my home WinXPpro, I have
to change directories, SQL connectors, ports, and the like for. The port
from WinXP to Linux is mainly switching "C:\" to "/home"....and finding
anyplace I've hard-coded a "\".
I am not as optimistic that River will _buy_ a cache license from
www.intersys.com, as I am optimistic that he'll be able to get a version
(any version!) of GT.m (free beer/speech) installed for me. Both run
approximately as well in both environments.
Downstairs on my Linux boxen, I have shell scripts. I don't have a single
.BAT file on Windows that might be applicable on toolserver. Not one.
(That kindof makes sense, in that you'd use batch files to move files
around, perhaps. Even if you had equivalent files, they'd have to be
rewritten for toolserver.)
Converting my stuff from Fedora to Debian is challenging enough. The
directories, per se, are all different. (It's an exercise in proper
discipline, to make sure configuration stuff like that is /relative/ and in
a .config file. But a good discipline, no matter how you look at it.)
But converting from a single-user WinXP environment to a Vista Server
environment? Doing such a thing would be much more challenging and
difficult than just converting it to a Linux flavor.
(Oh, except for the fact that Cache 5 runs on WinXP, not Vista...that
requires Cache.2007b, with it's per-connection licensing. And some amount
of exhaustive testing to make sure things still work right in the version
for the new platform.)
Did I say Linux FTW? I guess I should now. I very strongly feel that
wherever possible, proprietary systems (anti-freedom) should be avoided.
(Again, typing this on one-such hated Windows OS, with Cache running in the
Windows, as a platform, has done everything it can to make command-line
programming something for "other" OSes. Well, whether Windows, Linux,
Solaris or something else, the toolserver shared environment is a
command-line environment. You really can't do anything useful on a
long-distance GUI. VNC or Remote Desktop work the same, bandwidth-wise.
Running AWB would copy the screen image frames to you slowly over teh
internets...that would be much, much slower than running AWB locally.
(Plus: it wouldn't take many VNC/RD connections to saturate the bandwidth to
On another note, someone devoted enough could probably port the IRC linkbot
code to Windows and we could exile the linkbots there. (That's almost
certainly been done by someone, somewhere.) But only if it has been a
I dunno - I just don't get where this request is coming from. Are there
disadvantaged programmers wandering around carrying signs that say "WILL
WORK FOR VISTA LICENSES" or something? If you're going to port
local-specific code to a command-line environment...why would you ever
choose Windows? You'd have to really like "\" and really haet "/".
A "Windows programmer" would still have all the same barriers to entry -
none of their stuff would work on a shared WinTS, and the GUI would just be
slower than if they ran stuff locally. Much slower.
Connel (LFTW) MacKenzie
> Date: Wed, 06 Feb 2008 09:52:15 +0100 (CET)
> From: Danny B.<Wikipedia.Danny.B(a)email.cz>
> Subject: Re: [Toolserver-l] Windows toolserver
> I support Windows toolserver. I actually proposed it already
> pretty long time ago.
> Of course, it depends on what will be installed on it, but I
> guess some SBS package could solve it.
> It's not the question of unwilling to learn Unix, but the
> question of reusability of previous work - if somebody
> already has something he can can use, he most probably won't
> want to rewrite it completely in different language.
> Eg. I personally have a bunch of stuff written in ASP I could
> use, as well as standalone scripts in VBS/JS. There are also
> some useful freeware programs or libraries which could be
> helpful and I don't know about any Linux alternative to them
> (not saying it doesn't exist, but simply didn't find it).
> Danny B.
I agree with Danny B. If there is a significant chance that making this
available would bring new tools from people not otherwise inclined, or even
from people who have stuff on this platform who already contribute, it's
worth evaluating. How to determine whether there are such possible tools?
Perhaps a survey or something similar at an appropriate point? But there is
a significant body of (client side) tools that use .net already developed
(AWB, Huggle and a bunch more), some in fact are among the most popular and
powerful tools extant (run Huggle and you'll see what I mean about power and
efficiency, it's actually kind of scary how fast you can revert and block
vandal activity... and I think many people know how very useful AWB is... I
for one swear by it for a large class of tasks) so clearly there are some
relevant skills out there.
I also see where Brianna's coming from, in that there are those that might
object to providing a facility on such a closed system but I think River's
right, we should see if there's a need first before having the religious war
Hobby mail: Lar at Miltontrainworks dot com
Even /if/ it allowed GUI access for roots via VNC, it wouldn't allow random
toolserver users to use GUI based applications. In my experience, I've
never seen anyone who would successfully set up a VNC session, who didn't
have the knowledge /intelligence to be able to use an ssh command line.
The notion of per-user-seat licensing for DB access on
per-user-seat-licensing Windows domain becomes (very quickly)
astronomical. There are 273 lines in hemlock's /etc/passwd. Even if
"ONLY" 200 or so of them had ToolserverDomain access...
...well, all notions of "small business" or MSDN subscriptions are obviously
inapplicable. I don't know how many thousand's of dollars PER USER it would
cost, but I would guess the licensing alone (PER USER) would be about $4,
000.00 US. (Plus the all the server costs.)
Tell ya what - pay me $4k for each user I teach to use X Forwarding + ssh...
this message is from the MediaWiki API-mailing list and it should be
interesting for those which use the old query.php API interface...
-------- Original-Nachricht --------
Betreff: ATTENTION: query.php will be removed soon
Datum: Sat, 2 Feb 2008 14:46:49 -0500
Von: Yuri Astrakhan
For those who use old query.php API interface:
Per http://bugzilla.wikimedia.org/show_bug.cgi?id=12881 , query.php has
been fully ported to the api.php, and thus no longer needed. Unless
there are significant reasons to keep it around, it will be removed both
from the extensions and from the mediawiki sites fairly soon.
If you are still using it, see http://www.mediawiki.org/wiki/API
description on how to use the new api.php.
Thanks for all the support!