epriest's comments

I think mouse users don't generally suffer from this problem: by default, MacOS always shows a scrollbar in all contexts if you have a mouse plugged in to your computer.

This is not accurate. You can report bugs, etc., on the community forum here, which has open registration:

https://discourse.phabricator-community.org/

I mean that GitHub does not "try", in the sense of looking at the interdiff, doing fuzzy matching, trying to identify line-by-line similarity, etc. It places comments only if the hunk is exactly unchanged and gives up otherwise.

Phabricator does "try", in the sense that it examines the interdiff and attempts (of course, imperfectly, because no implementation can be perfect) to track line movement across hunk mutations.

My claim is that all comments which GitHub places correctly, Phabricator also places correctly. And some comments which GitHub drops, Phabricator places correctly (on the same line a human would select)! However, some comments which GitHub drops, Phabricator places incorrectly (on a line other than the line a human would select).

So the actual implementation you prefer is not one that tries, but one that doesn't try! Phabricator could have approximately GitHub's behavior by just deleting a bunch of code.

That's perfectly fine: many other users also prefer comments be discarded rather than tracked to a possibly-wrong line, too. I strongly believe this isn't a good behavior for code review software, which is why Phabricator doesn't do it -- but Phabricator puts substantially more effort into trying to track and place comments correctly than GitHub does.

GitHub's implementation does not do what you claim it does. GitHub has no behavior around porting and placing comments (while Phabricator does), GitHub just hides anything it can't place exactly. See my link above for a detailed description of GitHub's very simple implementation. I believe this is absolutely the wrong tradeoff.

In particular, see <https://secure.phabricator.com/T7447#112231> for a specific example which I believe GitHub's implementation gets egregiously wrong, by silently discarding an inline which is highly relevant to discussing the change.

This is not (and has never been) the behavior of Phabricator.

See <https://secure.phabricator.com/T7447> for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for).

If you believe this feature is possible to implement the way you imagine, I invite you to suggest an implementation. I am confident I can easily provide a counterexample which your implementation gets wrong (by either porting the inline forward to a line a human user would not choose, or by failing to port an inline which is still relevant forward).

Open source projects generally want an exact feature-for-feature copy of GitHub that looks and works exactly like GitHub, except open source.

If Phabricator was this, there would be no reason for paying customers to ever choose it over GitHub, because paying customers generally do not care if a solution is open source or not.

But the bigger impact of this change was not a product impact at all: it was that interacting with paying customers is something I generally enjoy and feel good about, and interacting with open source users is something I generally hated and felt miserable about.

For whatever reason, Phabricator attracted a large number of users who wanted to argue with me about every technical decision, insist that whatever feature they wanted should be the highest upstream priority, suggest I should pay them for their "valuable suggestions" because they are an important CEO, take offense when I asked them to please please please read the documentation and provide reproduction instructions, bump every open task asking for status updates, etc. This stuff had a huge net cost to the project and only got worse over time as the project grew.

Writing off open source installs allowed me to stop dealing with all of this.

Facebook has not provided any contributions or material support to the open source version of Phabricator since around 2012.

In my view, refocusing the roadmap on only requests from paying customers was possibly the best change I've made for the health and longevity of the project.

Can you point me at any data which supports this? It seems like it should be true, but GHC didn't appear to see a year-over-year increase to contributors when they switched from Phabricator to GitLab in December 2018.

See: https://news.ycombinator.com/item?id=23686803

Do you have data to support this claim?

For example, GHC moved from Phabricator to GitLab in December 2018, citing ease of contribution as a major benefit:

https://twitter.com/bgamari/status/1069047550727069696

As of April 2020 (about a year after the transition), the GHC year-over-year contributor numbers didn't appear to change:

https://twitter.com/evanpriestley/status/1245817419441926144

(I'm not sure this is a fair comparison, and am not aware of other possible changes to GHC during those years, and bear in mind that I'm a highly biased party.)

Can you point at a project which made a switch like this and saw an actual significant change in contributions or contributors afterward?

Why do you believe Phabricator is practically abandoned?

Interesting! This isn't how I remember things at all. Do you know where you got this sense of things from, specifically?

In particular, do you remember what gave you the impression that Facebook "overinvested" a large amount of effort into Phabricator, that I developed and open sourced Phabricator primarily to get promoted, that I built Phabricator because of scaling concerns, or that the primary value I provided to Facebook during my employment there was just in not starting a competitor?

Here's the answer to that question, from the second paragraph of the linked article:

> Facebook officials said they bought the masks for their offices’ emergency disaster kits following wildfires in California.

I found this article on this topic from a lawfirm specializing in entertainment law interesting:

https://rodriqueslaw.com/blog/how-use-brands-and-products-fi...

It references some of the existing caselaw. My reading suggests Apple would be very unlikely to succeed in court if they legally challenged a filmmaker for simply giving an iPhone to a villainous character.

The title claim is untrue and trivially falsifiable, but I haven't seen any articles that have actually made an effort to verify it.

Here are screens from two recent movies where villainous characters use iPhones:

https://productplacementblog.com/movies/apple-iphone-smartph...

https://productplacementblog.com/movies/apple-iphone-4s-smar...

"Merman" was an internal project codename, not an individual user. I think it was a very early version of the feature that eventually became "Pages".

I can't speak beyond 2011, but in the early part of the last decade you're giving Facebook far too much credit.

Facebook went down for most of a day in ~2009 because a new hire mistakenly removed the memcached server config in sitevars.

Facebook went down for several hours in ~2010 because someone configured a cyclic dependency in GateKeeper.

Circa 2011, Facebook's deployment process was very good, but also very very far from infallible.

Here's how to actually "solve" this problem on an iPhone:

- Pay $1.99 to buy a silent ringtone from the ringtone store.

- Make that your default ringtone.

- Give everyone who you want to be able to call you an audible ringtone.

> For online attacks, an attacker can't even try the top 1000 passwords on for an account in any major website in reasonable time without triggering the alarm, as they all(?) have rate limiting (usually in the form of account lockdown after single-digit failed attempts).

This is empirically a practical attack: attackers successfully executed a common password brute force attack against GitHub in late 2013 by using a botnet with 40,000 distinct remote addresses:

https://github.blog/2013-11-20-weak-passwords-brute-forced/