[Edbrowse-dev] wikipedia

[Edbrowse-dev] wikipedia

[Karl Dahlke]

I was flirting with the idea of writing a wikipedia article on edbrowse,
since I believe it has become "notable".
I have three sources to confirm credibility: it's packaging in debian, ubuntu,
and free bsd.
So I wrote the article, which is really the easy part.
Then moving on to submit the article, a process which ironically
could likely be done entirely with edbrowse, except for the captchas.
Here is my brief excursion into wiki.

1. Creating an account is highly recommended, but requires getting
past a captcha. No audio version.

2. It is possible to submit an article without an account, but at the last step,
to submit, you must get past another captcha.  Christ!
This hurdel will exist I'm sure whether you have an account or not.

3. The article must be written in a specialized markup language,
not html and not nroff or troff, or anything I know.
Something else to learn.

4. They won't submit an article for you, or help you format one;
I asked.
They will however create an account for you,
https://en.wikipedia.org/wiki/Wikipedia:Request_an_account
Then click on {Request an account}
I needed the vs option here, their certificate is not known to my root.
Account setup is pretty straightforward after that,
but what about the markup language?
the tutorial on it is horribly visual.
I can't make heads or tails of it.
The best bet is perhaps to find a short article on anything,
and edit it, like you're going to fix a problem with it,
and maybe then you can read the raw markup that generates the article,
and reverse engineer the language.
I suppose I wouldn't mind doing that if I were to submit or modify
dozens of wiki articles in the future,
but boy that seems like a lot of work for submitting one article.
And even if I did all that I still have to get past the last captcha.
So I'm not sure at this point if I'm going to bother.

Karl Dahlke

Re: [Edbrowse-dev] wikipedia

[Chris Brannon]

> I have three sources to confirm credibility: it's packaging in debian, ubuntu,
> and free bsd.

It's also packaged on Gentoo, and it is available from the 
Arch User Repository (a collection of community-supplied build scripts)
on Arch Linux.
So if you count Arch, that makes 4 Linux distros and a BSD.

> And even if I did all that I still have to get past the last captcha.

Well sometimes I get around them using the following techniques.
Unbrowse the page.  Find the form.  Find the <img> tag for the captcha.
Send the image to a sighted friend.
Also, are they using recaptcha?  It is ubiquitous, so they probably are.
If they are, then there's an audio captcha.
Recaptcha is very JS-intensive, and by default it isn't usable.  They do
have a non-JS option though.  It's inside a <noscript> tag on the page
containing the form.  Unfortunately, edbrowse discards text in
<noscript></noscript>.  So you'll have to edit the page and remove the
tags to find it.  Once you have the JS-free recaptcha html, it's fairly
straightforward to get an audio captcha from them and fill it out.
Technically straightforward.  In the past, their audio captchas were
notoriously hard to understand.  For instance, when we deleted our
Facebook accounts last year, I had to listen to between 30 and 50 of
them before I could find one that I could understand.  Google owns
recaptcha, and I think they've fixed this by now.  They got a lot of bad
press last summer, because a blindness-related petition on
whitehouse.gov was protected by their inscrutable audio captcha, and
therefore inaccessible to most of the blind!  I solved it, but I have good
hearing and lots of patience.

-- Chris

Re: [Edbrowse-dev] [commandline] Re: wikipedia

[Robert Ransom]

On 2/14/14, Chris Brannon <chris@the-brannons.com> wrote:

> Also, are they using recaptcha?  It is ubiquitous, so they probably are.

They are not.  It's a home-grown CAPTCHA.


Robert Ransom

Re: [edbrowse-dev] wikipedia

[Kevin Carhart]

There's a new remark on the deletion discussion page which makes me think 
that they are going to delete the page.  They aren't accepting that distro 
presence demonstrates that the project extends far outside of the biases 
of edbrowse-dev aka us, whose perceptions are clouded by 
loooove for edbrowse.  I'm not sure why usage itself can't be thought of as something 
that applies "show, don't tell" to a FOSS project.  Articles document that 
something is valuable, while stepping outside of the thing's own medium to 
talk about it in prose, and then you have to step back in to use it. 
Retrieving something and trying it out because it's FOSS and you can do 
this immediately, is a tough, disinterested inline test of whether the 
thing has merit which takes place without stepping outside to prose and 
then stepping back in.  If the library or application isn't good, you're 
going to delete it quickly and it will be considered for deletion from the 
distro.  But I guess this point of view is not going to 
get past the Wikipedia consensus process and the arguments that the 
members of the deciding committee have been posting for "DELETE", which 
they then back up with references to Wikipedia's ground rules.  I think if 
we have examples of endless inconsistency and other articles that remain 
published even though they don't pass a ground rule either, the committee 
just says "too bad."

So the second half of this for me at least is that we tried.  I'm sorry I 
couldn't make it happen through trying to write them something methodical 
and clear.  If we lose, I don't think it's an important proxy for the 
value of the work.  It's not an omen.  I'm sorry that it has that 
discouraging quality to it but don't let it get you down. As KD noticed 
while we were working on drafts, hell, duktape doesn't have its own page 
and they are thriving.  So maybe there are plenty of other venues we can 
use instead, such as all of those Stack Overflow answers where someone 
says "what are my options for a CLI browser with pretty decent 
javascript?"  And people say edbrowse since that happens to be true.