185 karma · joined October 27, 2021
I have some ex-coworkers and acquaintances working remotely from Europe for Bay area companies and they definitely have way higher compensations even without taking in account stock options.
My favorite by far is a "proposal" for an alternate notation which makes much more sense and, if adopted, would make mathematics way less intimidating (Triangle of Power (2016), 3Blue1Brown - https://www.youtube.com/watch?v=sULa9Lc4pck ).
I'd give him a Fields medal (or at least an honorary mention of some sort) :-]
You might consider posting that link a standalone entry on hacker news. That was a very great read well worth additional exposure.
> "cdd" "@c" is effectively a finger macro for me
That is pretty much how I use vi: muscle memory :]
Special:Version (example: https://en.wikipedia.org/wiki/Special:Version#mw-version-ski... )
An API query: * direct: https://en.wikipedia.org/w/api.php?action=query&format=json&... * demo: https://en.wikipedia.org/wiki/Special:ApiSandbox#action=quer...
Which yields the code name of each skins installed (eg: vector-2022, vector, monobook ...).
We do have direct point of contacts with engineers at Apple, Facebook, Google etc and do collaborate with them on a wide range of technical topics. The foundation has a dedicated team to vandalism, blocking etc https://www.mediawiki.org/wiki/Anti-Harassment_Tools . I forwarded your remark and maybe they can update the wiki page at https://meta.wikimedia.org/wiki/Apple_iCloud_Private_Relay (it is mostly from November 2021 and looks like it might use a refresh).
A new employee joined from one of the big tech players. They got hired for a role with X technology. Upon joining the thin team of 4 or 5 persons, including the double hat manager/engineer, the person legitimately though the whole team was SOLELY in charge of said X technology. That is how their previously larger employer operated with multiple such teams scattered around the world. To their demise, the person was now more or less the lone tech lead for X and Y, with a worldwide and leadership responsibility for both. With of course shared responsibility with other tech managed by their teammate.
Thankfully we have grown a little bit since then and the kind of position I described is less of an occurrence nowadays (but still is for some area). That is far from lavish for sure.
https://meta.wikimedia.org/wiki/Apple_iCloud_Private_Relay has some context and list potential problems that might arise (and do in your case).
https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re... is the related discussion page if you want to ask more.
Back in the old days, we maintained a list of trustworthy http proxies for which we trusted the IP of their client. The community could then block the user behind the proxy. With everything behind https nowadays, that is no more possible (the intermediate proxy can not inject any header to carry the information). So the sole thing we see is the Apple relays IPs and if those are a source of vandalism for sure the community will block them from contributing.
There is a more or less similar issue with TOR exit node for which the issue is described at https://meta.wikimedia.org/wiki/Editing_with_Tor
Given the relay is only enforced by Safari (as I understand it), you can use the IOS Wikipedia application for editing: https://apps.apple.com/app/wikipedia/id324715238 , though that will not pass through the Apple relays and leak your IP.
0x0A h e l l o _ w o r l d
But that limited the length of strings to 255 characters and using two bytes rather than one would add memory pressure. Dennis Ritchie then went with null terminated strings which has the advantage of allowing any size of strings and is consistent with the assembly they were used with. The drawbacks is decades of buffer overflows :)
Eventually I found an abstract on https://en.wikipedia.org/wiki/Null-terminated_string#History and there is a 2011 paper about it: Communications of the ACM - Volume 54 - Issue 901 - September 2011 - pp 42–44 - https://doi.org/10.1145/1995376.1995391 . Direct link to the PDF https://dl.acm.org/doi/pdf/10.1145/1995376.1995391
We have plenty of almost unicorns here in Europe, then they tend to be smaller. Albeit the European Union market is roughly equivalent to the USA one in term of population or wealth, it is heavily fragmented legally and culturally. If you want to grow out of your country, you get to address the challenge of various different cultural differences be it for your product, running a business or entirely different laws. And sometime there is not even a market cause your solution is already addressed in some of the other countries.
> You're going to argue that 4 months severance from FB, where average developer pay is the highest in the world with Sr. Engineers getting $300k in cash compensation
Those would involves RSU which I guess do not get vetted, even so 4 months several when having a $300k salaries yields out a $100k severance.
> is worse than 6-12 months severance from a European tech company, where cash comp is 20% of that?
I am not sure it would be that large. At least for France it is 25% of a monthly wage per year of tenure. So for a 5 years employment that would be 1,25 months. Then you get unemployment benefits, usually a package to assist in finding a new job and of course you keep your healthcare coverage. The system is entirely different really. We get less lump sum but have a lot of other benefits which definitely help in rough time.
At Wikimedia we adopted it which has cut our CPU usage by half and has saved a few hundred of servers. We had some Facebook engineers helping which involved patching the Linux kernel while at it. Those were good times.
Eventually PHP 7 followed up with a similar approach and had more or less the same performance as HHVM. Facebook went then to focus on the Hack language (a dialect of PHP with strong typing) and eventually phased out back compat with Zend.
From what I remember, Sara Golemon at Facebook has done a lot of outreaching to Open Source project and gave us a lot of assistance (as well as others at Facebook).
That is a good read thank you.
If configured you can send your review by emails https://gerrit-review.googlesource.com/Documentation/intro-u...
If you get the an email you can read it from your mail client, retrieve the change from Gerrit over git (git fetch gerrit.example.org refs/changes/45/12345,8 && git checkout FETCH_HEAD), address the review and send back to Gerrit (git push gerrit.example.org HEAD:refs/for/main). Though to mark the review comments you would have to reply to the email or indeed head to the Web UI to mark them resolved.
One can send a review vote and message over ssh which is quite convenient to a point I locally have aliases +1 / +2 to do it directly from the command line instead of heading to the web browser.
The API is quite powerful (the Gerrit web UI entirely relies on the REST API). James E. Blair wrote a ncurses client for Gerrit there is a quick demo at https://ttygroup.org/gertty/index.html (Pypi page https://pypi.org/project/gertty/ ).
There is also a (blessed) community fork at https://we.phorge.it/
The 50k daily hit on https://meta.wikimedia.org/wiki/Live_mirrors is merely to illustrate a web proxy can dramatically reduce the number of hits to the original site. They could have pick 42 or 7 billions, it is just an example.
The text dates from 2009, and in April 2009 this is roughly what we had in term of servers https://commons.wikimedia.org/wiki/File:Wikimedia-servers-20... Arguably a little more than a Raspberry pi
We already had a few million pages rather than 50k of them, and they were not static since pages get edited and made live as soon as one save their edit. Obviously, we already had million daily users and definitely requires a ton of caching all across the stack. Also good luck serving flat files that keeps being written too, that does not really work with hard drive and static files storage.
In September 2021 we have served 21 billion pages and 73 billions media files https://stats.wikimedia.org/#/all-projects . Almost all of them served primarily served from caches.
That being said, the wiki pages you have mentioned are a decade old. We definitely had trouble with people having the smart idea of scrapping the whole website, often using either uncacheable content or hitting barely served articles or history that were not cached and thus caused a full rendering of the page. Even with the servers we had, a single user could cause major havoc on the infrastructure and keep a good part of them busy just to serve that single person. Hence the recommendation to use the database dump which are still used: https://dumps.wikimedia.org/
cheers