CLiki sites (CLiki itself, the ALU CLiki and the McCLIM CLiki) are
increasingly valuable resources for the Lisp community. But it looks
like attacks by spammers and vandals are increasing.
I encourage all Lispers to regularly and frequently check the Recent
Changes pages of all CLikis and look for potential damages to the
content. In particular, be sure to check all modifications to the
Sandbox pages, where most spam is added.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
>>>>> On Wed, 02 Jun 2004 11:36:24 +0200, Paolo Amoroso ("Paolo") writes:
Paolo> CLiki sites (CLiki itself, the ALU CLiki and the McCLIM CLiki) are
Paolo> increasingly valuable resources for the Lisp community. But it looks
Paolo> like attacks by spammers and vandals are increasing.
Paolo> I encourage all Lispers to regularly and frequently check the Recent
Paolo> Changes pages of all CLikis and look for potential damages to the
Paolo> content. In particular, be sure to check all modifications to the
Paolo> Sandbox pages, where most spam is added.
Rather than constantly cleaning up,
why not implement some simple security?
Rather than allowing unknown random modifications to any visible part
of the web site, have a place where interested folks can register to
automatically be issued tentative login credentials. Tentative users
can only make modifications to a segregated area that is not normally
seen by anybody (and is only visible upon demand to registered users,
and to the tentative user who authored it). Allow any known user to
approve a tentative user's account, promoting them to also be a known
user with normal capabilities. It would be sufficient to authenticate
logins with a password issued and given over HTTPS.
Rather than searching sandbox content, registered users would
merely browse the current list of tentative users, showing their
names, some stats on them, how many changes they have pending, etc.
Maybe in the login application there would be something to fill
out that summarizes the person's credentials or something.
This whole summary page should be only one or two lines per user.
A registered user could dispose of offenders with one click,
or drill down into their tentative pages if needed.
Or, they could click on "approve" to promote the user,
which would allow the new user to install content into
the normal stream.
The point is, nobody would be even having to waste time looking
at spam or vandalized pages. (Make sure that the way things work
is labeled so that offenders would understand their futility.)
The above could obviously be simplified even more by closing things
up except to registered users that are managed out of band, without
automatic on-line account applications and multiple content streams.
(I bet there are not really any unknown Lisp people running around
who would be so frustrated by such a policy that they would decide
not to contribute to the web page.)
Christopher C. Stacy <······@news.dtpq.com> wrote:
> Rather than constantly cleaning up,
> why not implement some simple security?
It wouldn't be a wiki then, would it?
Seriously, though -- One feature which other wikis have proven useful in
deterring spam is to make it at least as easy to revert a page to an
older version as it is to post the spam in the first place.
This is currently not the case on alu.cliki.net. One time, I went to
the main page and found it had been blanked (edited, and a blank version
saved). There is no link from the main page view to the older versions
of a page -- I had to go to www.cliki.net, figure out the URL syntax for
"retrieve older version", then edit the old and new versions and paste
the old one into the new.
It's pretty well-established by example that popular wikis are resistant
to vandalism. They are resistant in the way that a linoleum floor is
resistant to mud: not that it is impossible to track mud on it, but
that it is easy to clean the mud off, and the mud does no permanent
damage. This is, for instance, the case on Wikipedia: although there
is a small amount of vandalism and spam posted, it is rapidly removed
because it is easy to do so. (The level of vandalism and spam on
Wikipedia is far below, for instance, the level of disputes among
legitimate users over page content.)
On Wikipedia, the procedure to revert a vandalized page to an earlier
version is simple and well documented: view the page's history, select
the version you wish to revert to, hit the edit link, enter "rv
vandalism" in the edit comment, and hit the commit button. No cutting
and pasting is needed. Copying this feature would probably make CLikis
easier to keep clean.
(It's true, of course, that a spammer can sit on the wiki and revert the
page back to the spammed version. In practice, it doesn't happen --
spammers are not known for their long attention spams. I mean, spans.)
Speaking of Wikipedia, we can always use more informed contributors to
the Lisp articles there. I have been expanding them somewhat of recent
but there is still a lot to be done:
http://en.wikipedia.org/wiki/Lisp_programming_language
http://en.wikipedia.org/wiki/Common_Lisp
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" wrote:
>
> Christopher C. Stacy <······@news.dtpq.com> wrote:
> > Rather than constantly cleaning up,
> > why not implement some simple security?
>
> It wouldn't be a wiki then, would it?
Sure it would. I regularly use access-controlled wikis.
Paul
>>>>> On Wed, 2 Jun 2004 16:49:07 +0000 (UTC), Karl A Krueger ("Karl") writes:
Karl> Christopher C. Stacy <······@news.dtpq.com> wrote:
>> Rather than constantly cleaning up,
>> why not implement some simple security?
Karl> It wouldn't be a wiki then, would it?
I don't know. Someone asked people to spend valuable time monitoring
and cleaning up messes. I suggested a way to minimize that cost.
Other people obviously have different value systems where they compare
the cost of human lifetimes against other things, and come up with
different answers. Wiki seems to be a game for youngsters.
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> >>>>> On Wed, 2 Jun 2004 16:49:07 +0000 (UTC), Karl A Krueger ("Karl")
writes:
>
> Karl> Christopher C. Stacy <······@news.dtpq.com> wrote:
> >> Rather than constantly cleaning up,
> >> why not implement some simple security?
>
> Karl> It wouldn't be a wiki then, would it?
>
> I don't know. Someone asked people to spend valuable time monitoring
> and cleaning up messes. I suggested a way to minimize that cost.
> Other people obviously have different value systems where they compare
> the cost of human lifetimes against other things, and come up with
> different answers. Wiki seems to be a game for youngsters.
By the same token, the "peer reviewed user acceptance policy" that you
proposed asks a similiar behavior, asking of peoples time to research and
understand the intent of an anonymous poster in order to approve the
proposed and all future content.
The idea of the wiki is that it can be self correcting, to a point.
If a person coming to the wiki sees obvious vandalism and spam, he can
simply edit it out. If he sees blatant destruction, they can easily restore
it (assuming such a mechanism).
The wiki traveler need not be a frequent visitor, even a casual visitor to a
lightly used portion of the site can perform this maintenance. You don't
have to pick up that discarded cup next to the trash can on your morning
walk, but it's not a lot of effort to do so.
The trick here is that the mechanism of restoration need be obivious and
particularly incapapable of being destroyed (such as having a "view history"
button on even a blank page to enable restoration of a previous version).
You don't need an RCS system to do this, managing diffs or anything else. It
can be as crude as renaming files .1, .2, .3, .4, etc.
Making correction simple and easy to do encourages corrections to happen,
even by those just traveling through.
It's susceptible to wanton, organized vandalism and destruction, but it's
also suseceptible to simply have the host hard drive explode, so there will
always need to be another means of restoration.
Regards,
Will Hartung
(·····@msoft.com)
>>>>> On Wed, 2 Jun 2004 12:13:25 -0700, Will Hartung ("Will") writes:
Will> "Christopher C. Stacy" <······@news.dtpq.com> wrote in message
Will> ··················@news.dtpq.com...
>> >>>>> On Wed, 2 Jun 2004 16:49:07 +0000 (UTC), Karl A Krueger ("Karl")
Will> writes:
>>
Karl> Christopher C. Stacy <······@news.dtpq.com> wrote:
>> >> Rather than constantly cleaning up,
>> >> why not implement some simple security?
>>
Karl> It wouldn't be a wiki then, would it?
>>
>> I don't know. Someone asked people to spend valuable time monitoring
>> and cleaning up messes. I suggested a way to minimize that cost.
>> Other people obviously have different value systems where they compare
>> the cost of human lifetimes against other things, and come up with
>> different answers. Wiki seems to be a game for youngsters.
Will> By the same token, the "peer reviewed user acceptance policy" that you
Will> proposed asks a similiar behavior, asking of peoples time to research and
Will> understand the intent of an anonymous poster in order to approve the
Will> proposed and all future content.
My idea involves people spending orders of less magnitude of their time.
But I can see tha people are not interested for some reason,
and am no longer following this thread.
Christopher C. Stacy <······@news.dtpq.com> wrote:
>>>>>> On Wed, 2 Jun 2004 16:49:07 +0000 (UTC), Karl A Krueger ("Karl") writes:
> Karl> Christopher C. Stacy <······@news.dtpq.com> wrote:
> >> Rather than constantly cleaning up,
> >> why not implement some simple security?
>
> Karl> It wouldn't be a wiki then, would it?
>
> I don't know. Someone asked people to spend valuable time monitoring
> and cleaning up messes. I suggested a way to minimize that cost.
So did I.
I hold, moreover, that requiring account registration fails to minimize
cost.
First, it has its own cost: it dissuades ad-hoc contributors who are
not interested in "signing up" for anything. The higher the barrier to
entry, the more contributors you turn away.
Second, it does not actually -solve- the problem of wiki spam and
vandalism: people who want to spam and vandalize aren't prevented from
registering. Even if you require user logins, there will still be the
need to remove spam and revert vandalism.
(By the way, the line "It wouldn't be a wiki then, would it?" was
intended as flip. It was not the point of my post.)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
On Wed, 2 Jun 2004 18:43:20 +0000 (UTC), "Karl A. Krueger" <········@example.edu> wrote:
> Second, it does not actually -solve- the problem of wiki spam
Your way of emphasizing words by surrounding them with hyphens results
in words that are crossed out in Gnus (which, I think, is used by many
people in this newsgroup). Other, more fitting, characters would be
/slashes/ (results in italics), _underlines_ (results in underlining),
or *asterisks* (results in bold face) although the latter doesn't mix
well with CL source code... :)
Cheers,
Edi.
Edi Weitz <···@agharta.de> writes:
> Your way of emphasizing words by surrounding them with hyphens results
> in words that are crossed out in Gnus (which, I think, is used by many
> people in this newsgroup).
A recent CVS Gnus actually stops treating strikethru, since more
people these days seem to be using it for general emphasis. I dunno
why that's picked up so much recently... maybe because _ requires a
shift. But I've seen a number of people on different groups using
that style.
--
Alan Shutko <···@acm.org> - I am the rocks.
Give 'em 2.54 centimeters, they take 1.6 kilometers!
Alan Shutko <···@acm.org> writes:
> A recent CVS Gnus actually stops treating strikethru, since more
> people these days seem to be using it for general emphasis. I dunno
> why that's picked up so much recently... maybe because _ requires a
> shift. But I've seen a number of people on different groups using
> that style.
Does that mean programmers will now start naming their identifiers like:
long-variable-name instead of long_variable_name? ;)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> "Rahul" == Rahul Jain <·····@nyct.net> writes:
Rahul> Does that mean programmers will now start naming their identifiers like:
Rahul> long-variable-name instead of long_variable_name? ;)
No it doesn't. Only the most sophisticated programming languages
allows the free choice between '-' and '_' in identifiers.
In fact that is probably the primary reason why lisp programmers are
so much more productive than say C programmers: we can type faster
because we do have to use shift all the time.
:-)
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Edi Weitz <···@agharta.de> writes:
> On Wed, 2 Jun 2004 18:43:20 +0000 (UTC), "Karl A. Krueger" <········@example.edu> wrote:
>
> > Second, it does not actually -solve- the problem of wiki spam
>
> Your way of emphasizing words by surrounding them with hyphens results
> in words that are crossed out in Gnus (which, I think, is used by many
> people in this newsgroup). Other, more fitting, characters would be
> /slashes/ (results in italics), _underlines_ (results in underlining),
> or *asterisks* (results in bold face) although the latter doesn't mix
> well with CL source code... :)
I don't know. I think perhaps global variables /should/ be *bold*.
Chalk me up as a gnus user.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Edi Weitz <···@agharta.de> wrote:
> On Wed, 2 Jun 2004 18:43:20 +0000 (UTC), "Karl A. Krueger" <········@example.edu> wrote:
>
>> Second, it does not actually -solve- the problem of wiki spam
>
> Your way of emphasizing words by surrounding them with hyphens results
> in words that are crossed out in Gnus (which, I think, is used by many
> people in this newsgroup). Other, more fitting, characters would be
> /slashes/ (results in italics), _underlines_ (results in underlining),
> or *asterisks* (results in bold face) although the latter doesn't mix
> well with CL source code... :)
That's interesting to know. My newsreader (tin) displays all four as
different colors -- -blue-, /cyan/, _magenta_, and *yellow*.
I'm not sure why I moved from *stars* to -dashes- for emphasis; it may
be that the former seemed nearly as shouty as ALL CAPS. /This/ looks
too much like a Perl regex match, while _underlines_ are for book
titles.
But I'll keep Gnus in mind ... I'm sure it's common in this froup at
least.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> wrote in message news:<············@baldur.whoi.edu>...
>
> I'm not sure why I moved from *stars* to -dashes- for emphasis; it may
> be that the former seemed nearly as shouty as ALL CAPS. /This/ looks
> too much like a Perl regex match, while _underlines_ are for book
> titles.
I think that historically (as in: several hundred years ago)
underlining was how you indicated when marking up text that it should
be in italics (I think single underlines meant italic/slanted, double
meant bold). Obviously it's more recently been used to indicate
emphasis when using typewriters.
··········@tfeb.org (Tim Bradshaw) writes:
> I think that historically (as in: several hundred years ago)
> underlining was how you indicated when marking up text that it should
> be in italics (I think single underlines meant italic/slanted, double
> meant bold). Obviously it's more recently been used to indicate
> emphasis when using typewriters.
Emphasis as in a replacement for italicization on typewriters that
didn't have exchangable fonts (or users that didn't have the patience).
In that way, it's basically a continuation of the historical use of
underlining. But these days underlining something means that you can
click it. Go figure.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
······@news.dtpq.com (Christopher C. Stacy) writes:
> Wiki seems to be a game for youngsters.
Others have pointed out the flaws in your claim to find a global
minimum of cost, despite your later acknowledgment that no such
minimum exists; I'd just like to acknowledge the willingness of
youngsters to play games that indirectly benefit the ancient among us,
even if they show no willingness to participate in those games.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
>>>>> On Wed, 02 Jun 2004 20:35:20 +0100, Christophe Rhodes ("Christophe") writes:
Christophe> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> Wiki seems to be a game for youngsters.
Christophe> Others have pointed out the flaws in your claim
Christophe> to find a global minimum of cost,
Why what?
Christophe> despite your later acknowledgment that no such minimum exists
My what?
I'm done with this thread.
Quite sorry I said anything, now.
······@news.dtpq.com (Christopher C. Stacy) writes:
> I don't know. Someone asked people to spend valuable time monitoring
> and cleaning up messes. I suggested a way to minimize that cost.
I should have mentioned that I consider this an interim and suboptimal
solution, not the best way of handling CLiki vandalism.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Karl A. Krueger wrote:
> Christopher C. Stacy <······@news.dtpq.com> wrote:
>
>>Rather than constantly cleaning up,
>>why not implement some simple security?
>
>
> It wouldn't be a wiki then, would it?
<http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity>
<http://www.usemod.com/cgi-bin/mb.pl?HardSecurity>
<http://www.usemod.com/cgi-bin/mb.pl?WikiLifeCycle>
--
Jens Axel S�gaard
"Karl A. Krueger" <········@example.edu> writes:
> On Wikipedia, the procedure to revert a vandalized page to an earlier
> version is simple and well documented: view the page's history, select
> the version you wish to revert to, hit the edit link, enter "rv
> vandalism" in the edit comment, and hit the commit button. No cutting
> and pasting is needed. Copying this feature would probably make CLikis
> easier to keep clean.
You should find that the same or similar procedure now works on CLiki
and the ALU Wiki: if showing an old version of a page, pressing the
'edit' link will use that older version as a starting point for your
change. The ALU wiki now also has a link in the page footer to show
older versions, which it previously lacked.
Anybody wishing to document this is welcome to edit the appropriate
cliki page to add description ;-)
-dan
--
"please make sure that the person is your friend before you confirm"
Unfortunately wiki upon which cliki is designed is made such that anyone
can add comments
and contents. What you want would require a complete rewrite.
On Wed, 02 Jun 2004 15:32:08 GMT, Christopher C. Stacy
<······@news.dtpq.com> wrote:
> Rather than allowing unknown random modifications to any visible part
> of the web site, have a place where interested folks can register to
> automatically be issued tentative login credentials. Tentative users
> can only make modifications to a segregated area that is not normally
> seen by anybody (and is only visible upon demand to registered users,
> and to the tentative user who authored it). Allow any known user to
> approve a tentative user's account, promoting them to also be a known
> user with normal capabilities. It would be sufficient to authenticate
> logins with a password issued and given over HTTPS.
>
> Rather than searching sandbox content, registered users would
> merely browse the current list of tentative users, showing their
> names, some stats on them, how many changes they have pending, etc.
> Maybe in the login application there would be something to fill
> out that summarizes the person's credentials or something.
> This whole summary page should be only one or two lines per user.
> A registered user could dispose of offenders with one click,
> or drill down into their tentative pages if needed.
> Or, they could click on "approve" to promote the user,
> which would allow the new user to install content into
> the normal stream.
>
> The point is, nobody would be even having to waste time looking
> at spam or vandalized pages. (Make sure that the way things work
> is labeled so that offenders would understand their futility.)
>
> The above could obviously be simplified even more by closing things
> up except to registered users that are managed out of band, without
> automatic on-line account applications and multiple content streams.
> (I bet there are not really any unknown Lisp people running around
> who would be so frustrated by such a policy that they would decide
> not to contribute to the web page.)
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> Unfortunately wiki upon which cliki is designed is made such that
> anyone can add comments
> and contents. What you want would require a complete rewrite.
How about adding some test that only humans can pass before submitting the
change? E.g. like Yahoo's distorted pictures whose content you have to
insert in a field. I think this shouldn't be too hard to implement and
it's also reasonable secure, isn't it?
-ts
Thomas Schilling <······@yahoo.de> wrote:
> John Thingstad wrote:
>> Unfortunately wiki upon which cliki is designed is made such that
>> anyone can add comments
>> and contents. What you want would require a complete rewrite.
>
> How about adding some test that only humans can pass before submitting the
> change? E.g. like Yahoo's distorted pictures whose content you have to
> insert in a field. I think this shouldn't be too hard to implement and
> it's also reasonable secure, isn't it?
That's called a "captcha". It might be adequate for CLiki's purposes,
but it is proven susceptible to a man-in-the-middle attack:
http://en.wikipedia.org/wiki/Captcha#Circumvention
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Thomas Schilling <······@yahoo.de> writes:
> John Thingstad wrote:
>
>> Unfortunately wiki upon which cliki is designed is made such that
>> anyone can add comments
>> and contents. What you want would require a complete rewrite.
>
> How about adding some test that only humans can pass before submitting
> the change? E.g. like Yahoo's distorted pictures whose content you
> have to insert in a field. I think this shouldn't be too hard to
> implement and it's also reasonable secure, isn't it?
Nah. Spammers have a clever way around these. They offer free porn
but require the porn surfer to occasionally decode distorted pictures
that are forwarded from such protected sites.
`Give a million monkeys a million dildoes and with enough time they'll
break into any wiki.'
--
~jrm
Joe Marshall wrote:
> Thomas Schilling <······@yahoo.de> writes:
>> How about adding some test that only humans can pass before submitting
>> the change? E.g. like Yahoo's distorted pictures whose content you
>> have to insert in a field. I think this shouldn't be too hard to
>> implement and it's also reasonable secure, isn't it?
>
> Nah. Spammers have a clever way around these. They offer free porn
> but require the porn surfer to occasionally decode distorted pictures
> that are forwarded from such protected sites.
>
> `Give a million monkeys a million dildoes and with enough time they'll
> break into any wiki.'
>
Do spammers really have the network to immediately get the feedback from
some porn-surfer out there? I mean the gatchas can be newly-generated and
may be valid for only 30sec or so.
Ok, otherwise I'd plead for the easy-remove-button + version history ;)
-ts
Thomas Schilling <······@yahoo.de> writes:
> Do spammers really have the network to immediately get the feedback
> from some porn-surfer out there? I mean the gatchas can be
> newly-generated and may be valid for only 30sec or so.
Reported on CNet:
http://news.com.com/2100-1023_3-5207290.html
--
~jrm
Thomas Schilling <······@yahoo.de> writes:
> Joe Marshall wrote:
>
> > Thomas Schilling <······@yahoo.de> writes:
> >> How about adding some test that only humans can pass before submitting
> >> the change? E.g. like Yahoo's distorted pictures whose content you
> >> have to insert in a field. I think this shouldn't be too hard to
> >> implement and it's also reasonable secure, isn't it?
> >
> > Nah. Spammers have a clever way around these. They offer free porn
> > but require the porn surfer to occasionally decode distorted pictures
> > that are forwarded from such protected sites.
> >
> > `Give a million monkeys a million dildoes and with enough time they'll
> > break into any wiki.'
> >
>
> Do spammers really have the network to immediately get the feedback
> from some porn-surfer out there? I mean the gatchas can be
> newly-generated and may be valid for only 30sec or so.
What I would do, were I unethical to do it, would be to (when I have a
porn surfer at hand), grab, show and ask for a decode of a gatcha on
the fly, instead of gathering a vast stack of them, hoping to find a
porn surfer to decode them for me.
It's the ever-curious race between "this is computationally hard" and
"how can we get a decent parallel wet-ware to do the job for us".
//Ingvar
--
When in douFNORD! This signature has been hi-jacked by Fnord Information
systems, to fnordprovide you with unfnordlimited information.
Thomas Schilling <······@yahoo.de> wrote in message news:<················@news.CIS.DFN.DE>...
> John Thingstad wrote:
>
> > Unfortunately wiki upon which cliki is designed is made such that
> > anyone can add comments
> > and contents. What you want would require a complete rewrite.
>
> How about adding some test that only humans can pass before submitting the
> change? E.g. like Yahoo's distorted pictures whose content you have to
> insert in a field. I think this shouldn't be too hard to implement and
> it's also reasonable secure, isn't it?
I've always wondered how things like this are meant to work for blind
people. Or maybe no-one cares about them.
In article <····························@posting.google.com>,
Tim Bradshaw <··········@tfeb.org> wrote:
> I've always wondered how things like this are meant to work for blind
> people. Or maybe no-one cares about them.
Oh, that's easy - just use an image with distorted braille. :)
Seriously, most sites I've seen that seem to care about blind users
provide a link to a semi-distorted spoken version of the same
information to enter.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing <·············@lavos.net> wrote in message news:<·····················@attbi_s03>...
>
> Seriously, most sites I've seen that seem to care about blind users
> provide a link to a semi-distorted spoken version of the same
> information to enter.
That would work.
In Europe (well, in the UK, but I suspect it's european legislation)
there is a while bunch of legislation about accessibility. My current
plan for getting rich involves finding a tame lawyer and then suing
every e-commerce website I can, since I'm fairly sure that essentially
*none* of them comply. I mean, only about 5% of them are accessible
by fully-abled people...
After I've done this I will come after Lisp for its evil parentheses
and over-long standard names.
--tim
Tim Bradshaw <··········@tfeb.org> wrote:
>
> After I've done this I will come after Lisp for its evil parentheses
> and over-long standard names.
I think it's perfectly fair and balanced to say that anyone who spells
out "CALL-WITH-CURRENT-CONTINUATION" in this newsgroup is probably
engaging in Lisp-vs.-Scheme flamebait.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> Tim Bradshaw <··········@tfeb.org> wrote:
> >
> > After I've done this I will come after Lisp for its evil parentheses
> > and over-long standard names.
>
> I think it's perfectly fair and balanced to say that anyone who spells
> out "CALL-WITH-CURRENT-CONTINUATION" in this newsgroup is probably
> engaging in Lisp-vs.-Scheme flamebait.
Huh? That's only 30 characters long. In Lisp, we have such beauties
as the 35 character Gray streams name
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM, and the 38 character CL names
UPDATE-INSTANCE-FOR-REDEFINED-CLASS and
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT.
The MOP wins, of course, with the 48-character long beauty
GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER !!!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>
>> Tim Bradshaw <··········@tfeb.org> wrote:
>> >
>> > After I've done this I will come after Lisp for its evil parentheses
>> > and over-long standard names.
>>
>> I think it's perfectly fair and balanced to say that anyone who spells
>> out "CALL-WITH-CURRENT-CONTINUATION" in this newsgroup is probably
>> engaging in Lisp-vs.-Scheme flamebait.
>
> Huh? That's only 30 characters long. In Lisp, we have such beauties
> as the 35 character Gray streams name
> FUNDAMENTAL-CHARACTER-OUTPUT-STREAM, and the 38 character CL names
> UPDATE-INSTANCE-FOR-REDEFINED-CLASS and
> LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT.
>
> The MOP wins, of course, with the 48-character long beauty
> GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER !!!
>
I'm all for long names for things you aren't likely to see often.
If you need to use them a lot, you can rename them (wrappishly)
appropriately, much the same way that call/cc was.
Svein Ove Aas wrote:
> Thomas F. Burdick wrote:
>> Huh? That's only 30 characters long. In Lisp, we have such beauties
>> as the 35 character Gray streams name
>> FUNDAMENTAL-CHARACTER-OUTPUT-STREAM, and the 38 character CL names
>> UPDATE-INSTANCE-FOR-REDEFINED-CLASS and
>> LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT.
>>
>> The MOP wins, of course, with the 48-character long beauty
>> GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER !!!
>>
> I'm all for long names for things you aren't likely to see often.
Me, too. Furthermore you have code-completion (at least in slime). E.g.
*pr C-. pp C-. gives me *print-pprint-dispatch*. (C-. is my autocomplete
in slime-mode)
>
> If you need to use them a lot, you can rename them (wrappishly)
> appropriately, much the same way that call/cc was.
That'll fix the problem of too wide code, which sometimes really bugs me.
(Have a small screen.)
-ts
In article <···············@famine.OCF.Berkeley.EDU>,
Thomas F. Burdick <···@famine.OCF.Berkeley.EDU> wrote:
> Huh? That's only 30 characters long. In Lisp, we have such beauties
> as the 35 character Gray streams name
> FUNDAMENTAL-CHARACTER-OUTPUT-STREAM, and the 38 character CL names
> UPDATE-INSTANCE-FOR-REDEFINED-CLASS and
> LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT.
>
> The MOP wins, of course, with the 48-character long beauty
> GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER !!!
I think CLIM wins, with the 57-character
COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND
Although I think their should be some sort of award for
NOTE-OUTPUT-RECORD-CHILD-CHANGED's lambda-list:
NOTE-OUTPUT-RECORD-CHILD-CHANGED
record child mode old-position old-bounding-rectangle stream
&optional erases moves draws erase-overlapping move-overlapping
&key check-overlapping
#lisp 2004-03-02:
16:43:30 <Kryztof> I have to say, note-output-record-child-changed has
hit my "worst API ever" button
16:44:33 <Kryztof> typical call:
(note-output-record-child-changed
or cr #o0777 opos br pane nil nil nil nil nil
:check-overlapping t)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
> I think CLIM wins, with the 57-character
> COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND
*Urgs*. BTW, is there any way to split a single symbol over more than one
line? (Not that it should be neccessary.)
> Although I think their should be some sort of award for
> NOTE-OUTPUT-RECORD-CHILD-CHANGED's lambda-list:
>
> NOTE-OUTPUT-RECORD-CHILD-CHANGED
> record child mode old-position old-bounding-rectangle stream
> &optional erases moves draws erase-overlapping move-overlapping
> &key check-overlapping
Especially, since that keyword arg is totally useless, since you have to
specify all optional args if you want to use it.
-ts
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
Paolo Amoroso schrieb:
> CLiki sites (CLiki itself, the ALU CLiki and the McCLIM CLiki) are
> increasingly valuable resources for the Lisp community. But it looks
> like attacks by spammers and vandals are increasing.
>
> I encourage all Lispers to regularly and frequently check the Recent
> Changes pages of all CLikis and look for potential damages to the
> content.
I'm the current maintainer of PhpWiki, and we also have to add Hard- and
SoftSecurity to the engine:
block ip ranges
block usernames
block excessive usage: to fast pageviews or too fast edits,
block bouncing email which registered for pagechange notification.
But the best tool is to set up boxes of RssFeeds to the three
recentchanges at your main (or test) wiki, so you see all the changes at
the wikis you want to watch (at least the name, summary and ip) at a glance.
Setting up rss feeds and rss parsers was really easy.
The second best solution is to add pagechange notification, which sends
diff's to the maintainer(s) per email.
> content. In particular, be sure to check all modifications to the
> Sandbox pages, where most spam is added.
Well, Sandbox spam is not a problem usually.
You can setup a script which overwrites the sandbox daily or weekly.
--
Reini Urban
http://phpwiki.sf.net/
Paolo Amoroso <·······@mclink.it> wrote in message news:<··············@plato.moon.paoloamoroso.it>...
> I encourage all Lispers to regularly and frequently check the Recent
> Changes pages of all CLikis and look for potential damages to the
> content. In particular, be sure to check all modifications to the
> Sandbox pages, where most spam is added.
Some features that come to mind which are not mutually incompatible:
- autorevert
A thread could occasionally revert certain pages to "official" forms.
Say every 2 hours. This shouldn't appear on Recent Changes.
- metawiki protocol per trusted user
You know you want it. Customize views and augment yourself with
spam-killing weapons.
- minor edits page
Sandbox could show up only on this page. But this has dependencies on
things like diff views for users, so this is pi-in-the-sky currently.
Still, the big annoyance is seeing Sandbox warfare played out on
Recent Changes page.
- hide non-text media?
Perhaps the wiki already doesn't show non-text media currently, I
dunno.