does anyone know what's up with http://alu.cliki.net?
I get an error message when i try to update a page on it.
error opening #P"/home/telent/var/www/alu/Munich.70": Permission denied
However, the "Contact Us" people do not respond to email
asking when the permissions will be turned back on.
Any clues anyone?
-jim
Jim Newton <·····@rdrop.com> writes:
> does anyone know what's up with http://alu.cliki.net?
Yes. (If you'd gone to that page, you would too.)
> However, the "Contact Us" people do not respond to email
> asking when the permissions will be turned back on.
Maybe because they expect that you'll read the front page:
Editing on this site has been disabled indefinitely due to spam; the
site itself will probably be removed shortly too. If you'd like to
help, please volunteer to host the site: you can download the data
from http://ww.telent.net/alu.tar.gz. Thanks. -dan
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Jim Newton <·····@rdrop.com> writes:
>
> > does anyone know what's up with http://alu.cliki.net?
>
> Yes. (If you'd gone to that page, you would too.)
>
> > However, the "Contact Us" people do not respond to email
> > asking when the permissions will be turned back on.
>
> Maybe because they expect that you'll read the front page:
>
> Editing on this site has been disabled indefinitely due to spam; the
> site itself will probably be removed shortly too. If you'd like to
> help, please volunteer to host the site: you can download the data
> from http://ww.telent.net/alu.tar.gz. Thanks. -dan
If an enterprising coder would make cliki run under AllegroServe, this
functionality could be dropped right into the existing ALU web site.
If this project seems interesting to anybody contact me privately.
Christophe Rhodes wrote:
> Jim Newton <·····@rdrop.com> writes:
>
>
>>does anyone know what's up with http://alu.cliki.net?
>
>
> Yes. (If you'd gone to that page, you would too.)
>
Perhaps an error message saying "please see http://alu.cliki.net for
details" might have helped. rather than the terse
"error opening #P"/home/telent/var/www/alu/Munich.70": Permission denied"
From: Edi Weitz
Subject: Re: http://alu.cliki.net/ not writable?
Date:
Message-ID: <uu0pbolc3.fsf@agharta.de>
On Thu, 20 Jan 2005 22:07:55 +0100, Jim Newton <·····@rdrop.com> wrote:
> does anyone know what's up with http://alu.cliki.net?
> I get an error message when i try to update a page on it.
>
> error opening #P"/home/telent/var/www/alu/Munich.70": Permission denied
>
> However, the "Contact Us" people do not respond to email
> asking when the permissions will be turned back on.
>
> Any clues anyone?
<http://ww.telent.net/diary/2005/1/#19.1586>
<http://lemonodor.com/archives/001040.html>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: drewc
Subject: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <41F03C75.9040004@rift.com>
I've set up a new lisp wiki to replace the ALU wiki. it is available at
lisp.tech.coop. It's been up for about a month now.
With the ALU wiki going away, i wouldn't want to lose all the great
content (RtL anyone?), so I've added all the content from the ALU wiki.
http://lisp.tech.coop
check it out, comment/flame (but don't say a word about my cliki-gnome).
drewc
Jim Newton wrote:
> does anyone know what's up with http://alu.cliki.net?
> I get an error message when i try to update a page on it.
>
> error opening #P"/home/telent/var/www/alu/Munich.70": Permission denied
>
> However, the "Contact Us" people do not respond to email
> asking when the permissions will be turned back on.
>
> Any clues anyone?
>
> -jim
From: Ng Pheng Siong
Subject: Re: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <csrf6o$lf5$1@nobel.pacific.net.sg>
According to drewc <·····@rift.com>:
> http://lisp.tech.coop
Didn't know there is a .tld called coop.
$ whois chicken.coop
Domain ID: 10947D-COOP
Domain Name: chicken.coop
Expiry Date: 25 Jul 2007 21:14:02 UTC
Created: 25 Jul 2002 21:14:02 UTC
Damn!
;-)
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
From: drewc
Subject: Re: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <2%jId.139179$8l.88747@pd7tw1no>
Ng Pheng Siong wrote:
> According to drewc <·····@rift.com>:
>
>>http://lisp.tech.coop
>
>
> Didn't know there is a .tld called coop.
>
> $ whois chicken.coop
>
> Domain ID: 10947D-COOP
> Domain Name: chicken.coop
> Expiry Date: 25 Jul 2007 21:14:02 UTC
> Created: 25 Jul 2002 21:14:02 UTC
>
> Damn!
>
> ;-)
>
That's the first thing i tried when i head about the .tld as well :).
It is, of course, short for co-operative. The americans don't hyphenate
the word, so we are left with a silly pronunciation. There's a couple
more .coop's i've thought up, but .coop is a little too expensive for
joke domains :).
chcken.coop is actually owned by chicken farmers :).
drewc
From: Ng Pheng Siong
Subject: Re: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <csvh01$tr1$1@nobel.pacific.net.sg>
According to drewc <·····@rift.com>:
> chcken.coop is actually owned by chicken farmers :).
I think an email address ···@chicken.coop will be cool! ;-)
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
From: T. Kurt Bond
Subject: Re: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <87y8eit96k.fsf@citynet.net>
drewc <·····@rift.com> writes:
> The americans don't hyphenate the word, so we are left with a silly
> pronunciation.
An absurd over-generalization.
--
T. Kurt Bond, ···@citynet.net
From: drewc
Subject: Re: New Lisp Wiki! (was ""Re: http://alu.cliki.net/ not writable?")
Date:
Message-ID: <rKkJd.164838$8l.61982@pd7tw1no>
T. Kurt Bond wrote:
> drewc <·····@rift.com> writes:
>
>
>>The americans don't hyphenate the word, so we are left with a silly
>>pronunciation.
>
>
> An absurd over-generalization.
>
True 'nuff. The Americans DO hyphenate _co-op_ (a synonym for 'a
co-operative', rather than 'being co-operative'), but not co-operatve
(spelling it cooperative). This is consistent with the Chicago Manual of
Style(and in fact CMS mentions co-operate specfically) This is also the
spelling in the American heritage and M-W American dictionaries.
I can't speak for modern British English (although my Oxford dictionary
mentions both spellings, and says that the hyphenated spelling is UK
english), but here in Canada we keep the hyphen. Perhaps this is
archaic, and that is what offended you, so i apologize if that's the case.
Regardless, maybe if you mentioned what you thought was so absurd about
my statement, i wouldn't think you were just being an asshole :).
drewc
From: Rahul Jain
Subject: American English (Was: Re: New Lisp Wiki!)
Date:
Message-ID: <87vf9jy0pj.fsf_-_@nyct.net>
drewc <·····@rift.com> writes:
> True 'nuff. The Americans DO hyphenate _co-op_ (a synonym for 'a
> co-operative', rather than 'being co-operative'), but not co-operatve
> (spelling it cooperative). This is consistent with the Chicago Manual of
> Style(and in fact CMS mentions co-operate specfically) This is also the
> spelling in the American heritage and M-W American dictionaries.
Actually, we spell it co�perative.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Just a thought as how to prevent spam on cliki. Maybe
require pages to be submitted in one of the Lisp HTML
markup languages, or even require a Lisp program that generates a
HTML page. It could be verified by the cliki server
before changes go ahead. It would make the cost to spammers
too large to be worth it.
Wade
Up spake Wade Humeniuk:
> Just a thought as how to prevent spam on cliki. Maybe
> require pages to be submitted in one of the Lisp HTML
> markup languages, or even require a Lisp program that generates a
> HTML page. It could be verified by the cliki server
> before changes go ahead. It would make the cost to spammers
> too large to be worth it.
FWIW, c2.com and usemod / oddmuse wikis have been bombarded by spamming
lately. You could ask how they work around it, but I suspect they
simply have a higher WikiGnome to Spammer ratio.
Usemod wikis have an RSS mode for their changelogs, so I can easily
discover spam changes on those wikis from my RSS aggregator. Does Cliki
have this?
--
-trent
"They're dogs," Muldoon said. "Intelligent talking dogs from the dog
star, Sirius. They came here and ate Malik. Just like they ate that guy
in Kansas City, except that time they didn't get to finish the job."
Trent Buck wrote:
> Up spake Wade Humeniuk:
> > Just a thought as how to prevent spam on cliki. Maybe
> > require pages to be submitted in one of the Lisp HTML
> > markup languages, or even require a Lisp program that generates a
> > HTML page. It could be verified by the cliki server
> > before changes go ahead. It would make the cost to spammers
> > too large to be worth it.
>
> FWIW, c2.com and usemod / oddmuse wikis have been bombarded by
spamming
> lately. You could ask how they work around it, but I suspect they
> simply have a higher WikiGnome to Spammer ratio.
The problem most analyses have (not yours) is they don't break out of
the server paradigm. Really good wikis that I like tend to have
friendly bots visit their site and rollback spam. All the wiki admin
does is ensure those bot rollbacks aren't too annoying on the Recent
Changes page (maybe a grey color?), and some sane limits on editing.
For example:
http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?RecentChanges
Now, I'm sure the c2 wiki does lots server-side too. But they're very
high-traffic and Ward/others seem willing to invest that time.
But now that Drewc has taken over the ALU wiki, it sounds like it's in
good hands. I mean really, the last owners didn't know that Dan was
hosting/adminning it. This appears to be an ideal solution for all
those involved, modulo that Santa beaming down at you. ;P
MfG,
Tayssir
Tayssir John Gabbour wrote:
>
> But now that Drewc has taken over the ALU wiki, it sounds like it's in
> good hands. I mean really, the last owners didn't know that Dan was
> hosting/adminning it. This appears to be an ideal solution for all
> those involved, modulo that Santa beaming down at you. ;P
Don't mess with the gnome.
drewc
>
>
> MfG,
> Tayssir
>
drewc wrote:
> Tayssir John Gabbour wrote:
> > But now that Drewc has taken over the ALU wiki, it sounds like it's
> > in good hands. I mean really, the last owners didn't know that Dan
> > was hosting/adminning it. This appears to be an ideal solution for
> > all those involved, modulo that Santa beaming down at you. ;P
>
> Don't mess with the gnome.
Don't worry, I've learned to respect things which tell me to kill.
-- Tayssir
Up spake Tayssir John Gabbour:
> Really good wikis that I like tend to have
> friendly bots visit their site and rollback spam.
I didn't know that. Thanks for the pointer.
> modulo that Santa beaming down at you. ;P
Star Trek is really clutching at straws, eh?
--
-trent
One of the main causes of the fall of the Roman Empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs. -- Robert Firth is a Quiche Eater
What about this?
http://www.google.com/googleblog/2005/01/preventing-comment-spam.html
Maybe CLiki should add rel="nofollow" to links?
Wade Humeniuk wrote:
> Just a thought as how to prevent spam on cliki. Maybe
> require pages to be submitted in one of the Lisp HTML
> markup languages, or even require a Lisp program that generates a
> HTML page. It could be verified by the cliki server
> before changes go ahead. It would make the cost to spammers
> too large to be worth it.
>
> Wade
>
>
>
From: Edi Weitz
Subject: Re: http://alu.cliki.net/ not writable?
Date:
Message-ID: <u8y6nnoy9.fsf@agharta.de>
On Fri, 21 Jan 2005 11:01:02 +0300, Ivan Shvedunov <·······@depni.sinp.msu.ru> wrote:
> What about this?
> http://www.google.com/googleblog/2005/01/preventing-comment-spam.html
>
> Maybe CLiki should add rel="nofollow" to links?
That implies that you also punish legitimate links, i.e. pages linked
from a CLiki page wouldn't get any credit by Google anymore. Which is
a bad thing as sometimes CLiki is the only place they're referenced
from.
FWIW, Dan Barlow made a reasonable suggestion that to me sounds better
than adding this attribute to all links:
<http://ww.telent.net/diary/2004/10/#26.86194>
But as usually the Google folks behaved like assholes and more or less
ignored this suggestion... :(
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> FWIW, Dan Barlow made a reasonable suggestion that to me sounds better
> than adding this attribute to all links:
>
> <http://ww.telent.net/diary/2004/10/#26.86194>
I was wondering this morning if it would be possible to achieve the
same thing by fidgeting with the robots.txt file in real time.
O.K. what about this:
When a page is edited, links are replaced by something like
http://www.cliki.net/temporary-redirect?url=... which has nofollow
attribute. When there are no edits within 24 hours, URLs are restored
(temporary-redirect stuff is removed). If google caches rel="nofollow"
attributes for links, that cache will become irrelevant as the links are
changed. Also, it's possible to implement this in such way so that only
changed part of text is affected by "link mangling".
Some other possible extensions (didn't check whether this is already
implemented): CLiki admin may maintain a blacklist of strings (such as
URLs that are posted by spammers) so that page edit cannot be submitted
if the edited text contains one of such strings.
Edi Weitz wrote:
> On Fri, 21 Jan 2005 11:01:02 +0300, Ivan Shvedunov <·······@depni.sinp.msu.ru> wrote:
>
>
>> What about this?
>> http://www.google.com/googleblog/2005/01/preventing-comment-spam.html
>>
>> Maybe CLiki should add rel="nofollow" to links?
>
>
> That implies that you also punish legitimate links, i.e. pages linked
> from a CLiki page wouldn't get any credit by Google anymore. Which is
> a bad thing as sometimes CLiki is the only place they're referenced
> from.
>
> FWIW, Dan Barlow made a reasonable suggestion that to me sounds better
> than adding this attribute to all links:
>
> <http://ww.telent.net/diary/2004/10/#26.86194>
>
> But as usually the Google folks behaved like assholes and more or less
> ignored this suggestion... :(
>
> Cheers,
> Edi.
>
Some additions on how link mangling can be implemented: for each page, a
collection of links that are present on that page should be maintained,
together with timestamps indicating when they were created. When page
is displayed, all links are checked against that collection, and links
that are "too young" are mangled.
Concerning substring blacklisting mechanism, there can be even more
cruel measures: when spam URL is detected in posted text, a cookie is
injected into spammer's browser so he/she can no longer post to CLiki.
Well, this can be defeated, but still it will make spammers' life
somewhat worse.
Up spake Ivan Shvedunov:
> When spam URL is detected in posted text, a cookie is
> injected into spammer's browser so he/she can no longer post to CLiki.
> Well, this can be defeated, but still it will make spammers' life
> somewhat worse.
Probably they aren't using a browser, but a script. It will just
discard cookies. (Anyway, many browsers reject cookies by default.)
--
-trent
Due to the new requirement for 24-hour access to the PTW/STS VOBS by
engineers working at all hours, backups will now be run between the
newly created hours of bleen and dorch. -- Mike Stoddard
Trent Buck wrote:
> Probably they aren't using a browser, but a script. It will just
> discard cookies. (Anyway, many browsers reject cookies by default.)
It shouldn't be too hard to set up cliki so that cookies must be enabled
for editing to work.
Paul
Trent Buck <·········@tznvy.pbz> wrote:
> Probably they aren't using a browser, but a script. It will just
> discard cookies. (Anyway, many browsers reject cookies by default.)
if it is a script, spam can be prevented by asking a question before
posting, like Wade suggested, like showing a picture with a number and ask
to enter the number. I don't think that the spammers check the websites by
hand and probably the scripts don't have OCR integrated.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Up spake Frank Buss:
> > Probably they aren't using a browser, but a script. It will just
> > discard cookies. (Anyway, many browsers reject cookies by default.)
>
> if it is a script, spam can be prevented by asking a question before
> posting, like Wade suggested, like showing a picture with a number and ask
> to enter the number. I don't think that the spammers check the websites by
> hand and probably the scripts don't have OCR integrated.
I think that should only be a last resort, if nothing else works. You
don't want to piss off contributors. Also, I suspect that even fewer
browsers support images than cookies.
I've read the source for UseMod, and for that wiki, I think changing the
textbox's name from "text" to "fnord" (or any other random word) would
defeat scripts without interactive users even noticing a difference.
Sure, spammers can easily defeat it (unless you change the word once a
day), but will they bother to rewrite the script for *one* wiki when
they can still spam hundreds of unmodified UseMod wikis.
--
-trent
This sig in violation of U.S. trademark registration number 2,347,676
(http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=75502288) :-(