Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wikimedia is moving to Gitlab

mediawiki.org

Post reply on HN
Print view View original

201–210 of 408 posts

Re: Wikimedia is moving to Gitlab

#201

Post by protoduction »

aeyes wrote: post #189
protoduction wrote: post #133

Earlier quoted context omitted.

Hi phikai, I built a privacy friendly alternative to ReCaptcha called FriendlyCaptcha [1], is there a possibility to see this integrated as a more user friendly alternative? Happy to chat (e-mail in profile) [1] https://friendlycaptcha.com/

Is the demo somehow tweaked to be less hard? On my machine it doesn't take any time to solve it and I see no signs of CPU usage. Even trying a couple of times in incognito mode and watching CPU immediately after loading the page for the first time. On many sites creating a profile takes a few seconds. Loading one of my CPU cores for another 5 seconds doesn't really bother me if I wanted to create massive amounts of p…

The default difficulty is set to a difficulty that makes sense on websites that have a varied audience (which includes some ancient browsers on old devices).

The solver runs in WebAssembly and is really really fast (~4M hashes per second) - but not every browser supports WASM yet (around 0.3% empirically). The JS fallback is around 10 times slower (more in 5+ year old browsers) - for those users you want at least a decent solve time too.

For Gitlab's audience the difficulty can probably be increased a lot - it all depends on the website and usecase. I'm sure the JS fallback's performance can be improved (it involves a lot of operations on 64bit ints that need to be represented as two numbers in JS), happy to accept PRs [1] :)

[1]: https://github.com/FriendlyCaptcha/friendly-pow/blob/master/...

Re: Wikimedia is moving to Gitlab

#202

Post by robotmay »

ran3824692 wrote: post #149
sytse wrote: post #126

Earlier quoted context omitted.

I think the code of this problem is that it is hard to identify if a user is a bot or a human. I've not seen any elegant free solutions to this.

That is not the core of the problem. Spammers are humans, and sometimes they will solve recaptchas in large quantities to get their spam through. Its about having a multipronged approach for administrators to stay ahead of them. For some examples of free solutions see https://www.mediawiki.org/wiki/Manual:Combating_spam . It's even possible to connect spamassassin to forms. Gitlab needs tools and automation that dete…

I'm curious about the spamassassin integration. Do you know of any open source projects currently using it for a web application?

Re: Wikimedia is moving to Gitlab

#203

Post by js2 »

depressedpanda wrote: post #130
js2 wrote: post #12

Earlier quoted context omitted.

I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. A…

But you don't force push with Gerrit? Just update your change set, then push to refs/for/ again.

It's been a while since I used it, but I guess the more important point is that it's a rebase-based workflow.

My memory was you had to force push your working branch to refs/for. Thank you for the correction.

I've actually setup and run instances of it as two companies, but as I say, it's been a while.

Re: Wikimedia is moving to Gitlab

#204

Post by FredFS456 »

boneitis wrote: post #192
Siira wrote: post #180

Earlier quoted context omitted.

How do you know they are real humans? I imagine bots doing 2FA would still be cheaper.

Many bots are likely still powered under the hood by humans. On my backlog of projects to do is to make a browser extension that solves the more obnoxious captchas for me, as I'm regularly behind vpn and fall into ridiculously long solve loops. On the most popular api i could find, $10 buys you a shockingly LOT of solves (not that I've tested it yet). It is automatable but ultimately still powered by humans.

Already exists: https://github.com/dessant/buster

Edit: on re-read, you meant solving using humans. Buster uses speech-to-text APIs to solve.

Re: Wikimedia is moving to Gitlab

#205

Post by boneitis »

dannyw wrote: post #196
boneitis wrote: post #192

Earlier quoted context omitted.

Many bots are likely still powered under the hood by humans. On my backlog of projects to do is to make a browser extension that solves the more obnoxious captchas for me, as I'm regularly behind vpn and fall into ridiculously long solve loops. On the most popular api i could find, $10 buys you a shockingly LOT of solves (not that I've tested it yet). It is automatable but ultimately still powered by humans.

It’s incredibly sad how the open web is being destroyed by google’s recaptcha.

I'm totally in that camp of opinion, although I'll acknowledge the escalating abuses carried out by both "sides."

In the meantime, i hope to have the savviness to program my own way out of unsolvable captchas.

Re: Wikimedia is moving to Gitlab

#206

Post by boneitis »

FredFS456 wrote: post #204
boneitis wrote: post #192

Earlier quoted context omitted.

Many bots are likely still powered under the hood by humans. On my backlog of projects to do is to make a browser extension that solves the more obnoxious captchas for me, as I'm regularly behind vpn and fall into ridiculously long solve loops. On the most popular api i could find, $10 buys you a shockingly LOT of solves (not that I've tested it yet). It is automatable but ultimately still powered by humans.

Already exists: https://github.com/dessant/buster Edit: on re-read, you meant solving using humans. Buster uses speech-to-text APIs to solve.

Every lead to spice(e:solve, lol gboard) my problems is probably worth a peek. I'll take a look, thank you.

Re: Wikimedia is moving to Gitlab

#207

Post by brennen »

zdw wrote: post #162

I'd be interested in the CI aspects of this transition, which seem to be glossed over. The combination of Gerrit with Jenkins and Jenkins Job Builder blows everything else I've seen out of the water with how easy it is to make both per-patchset and post-integration changes in an infrastructure-as-code manner across multiple repos, once you get over the learning curve.

We recently conducted an extensive evaluation of CI options[0], concluding at the time that GitLab could meet our needs but didn't make a whole lot of practical sense unless we also migrated to it for code review. Other considerations (Gerrit user experience and sustainability, onboarding costs, a de facto migration of many projects from our Gerrit instance to GitHub, etc.) led us to re-evaluate whether a migration for code review would make sense, and that's what the decision linked here addresses.

I am on the team that maintains our existing CI system[1] (Zuul, Jenkins, JJB), though I mostly work on other things. While this system is certainly quite powerful, I would not personally describe it as easy. We have a lot of work in front of us in migrating it to GitLab, but so far I've found the experience there quite a bit more pleasant than grepping through JJB definitions and the like.

At any rate, if you're interested in how all of this pans out, we will as ever be doing the work in a very public fashion.

[0]. https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering...

[1]. https://www.mediawiki.org/wiki/Continuous_integration

Re: Wikimedia is moving to Gitlab

#208

Post by LockAndLol »

zzzeek wrote: post #116

I think I have some relevant experience here. We host all of our projects on github: https://github.com/sqlalchemy/ yet we also use gerrit! https://gerrit.sqlalchemy.org/ users send us pull requests, and they never have to deal with Gerrit ever. We use a custom integration, the source code to which is here: https://github.com/sqlalchemyorg/publishthing/tree/master/pu... and then we mostly bidirectional synchronizatio…

> # Why

> For the past two years, our developer satisfaction survey has shown that there is some level of dissatisfaction with Gerrit, our code review system. This dissatisfaction is particularly evident for our volunteer communities. The evident dissatisfaction with code review, coupled with an internal review of our CI tooling and practice makes this an opportune moment to revisit our code review choices.

and then further down

> # FAQ

> * Why is GitHub not considered?

> - GitHub would be the first tool required to participate in the Wikimedia technical community that would be non Free Software and non self-hosted.

> - GitHub also does not meet all of our needs; for example, GitHub grants little control of metadata, no influence over privacy policy/data retention, sanctions and bans, little control over backups and data integrity checks, and no long-term guaranteed access to underlying repository settings and configuration.

Re: Wikimedia is moving to Gitlab

#209

Post by nerdkid93 »

dannyw wrote: post #196
boneitis wrote: post #192

Earlier quoted context omitted.

Many bots are likely still powered under the hood by humans. On my backlog of projects to do is to make a browser extension that solves the more obnoxious captchas for me, as I'm regularly behind vpn and fall into ridiculously long solve loops. On the most popular api i could find, $10 buys you a shockingly LOT of solves (not that I've tested it yet). It is automatable but ultimately still powered by humans.

It’s incredibly sad how the open web is being destroyed by google’s recaptcha.

I'd argue that it's equally sad to see the open web get destroyed by massive DDoS attacks and malicious actors. How would you keep your own website up if it was constantly being attacked?

Re: Wikimedia is moving to Gitlab

#210

Post by dspillett »

chrisweekly wrote: post #156
dfabulich wrote: post #110

Earlier quoted context omitted.

If you allow new users to create user profiles with links, and those user profiles are visible to Google, spammers will create a bunch of new user accounts and fill them with spam links. The easiest way to prevent this is to block Google from seeing user profiles by requiring login to see the profiles.

> "and those user profiles are visible to Google" googlebot adheres to robots.txt, right? in which case couldn't self-hosted gitlab admins add a robots.txt entry for the profile page url?

Most bots aren't going to bother checking if you've done that, so while they'll not get the expected benefit you'll still get the spam.
Post reply on HN