Gabriel Staples Updated +Created
GitHub's replacement of master branch with main (2020) Updated +Created
By GitHub around Black Lives Matter, due to a possible ludicrous relationship with slavery of black people:For the love of God, the word "master" is much more general than black slavery. If you are going to ban it, you might as well ban the word "evil".
Several software projects followed the purge from their codebases, maybe GitHub followed someone else's lead, it's hard to say.
The words "whitelist" and "blacklist" were also targeted.
Google Updated +Created
One of the least evil of the big tech companies of the early 21st century, partly because Sergey Brin's parents fled from the Soviet Union and so he is anti censorship, although they have been tempted by it.
Google only succeeds at highly algorithmic tasks or at giving infinite storage to users to then mine their data.
It is incapable however of adding any obvious useful end user features to most of its products, most of which get terminated and cannot be relied on:
This also seems to extend to business-to-business: twitter.com/MohapatraHemant/status/1343969802080030720 ex-Googler tells how they lost the cloud to Amazon.
More mentions of that:
Too many genius engineers. They need some dumber people like Ciro Santilli who need to write documentation to learn stuff.
Ciro Santilli actually attempted two interviews to work at Google in the early 2010's but very quickly failed both on the first phase, because you have to be a fast well trained coding machine to pass that interview.
Ciro later felt better about himself by fantasizing how he would actually do more important things outside of Google and that they would beg to buy him instead.
He was also happy that he wouldn't have to use Google crazy internal tools: someone once said that Google's tools make easy tasks middle hard, and they also make impossible tasks middle hard. TODO source.
Hackathon Updated +Created
Hackathons are useless.
If you have a useful project, why would you ever restrict its development to a specific timeframe and with a specific set of contributors?
Just put your project on GitHub and promote it to try and get users and contributors instead!
Instead of announcing organizing hackathons, people should just curate forums where people with similar interests can talk to one another instead, to find new projects that might interest one another.
Restricting intensive development to a few days tends to produce crappy code and not reach real goals.
Hans Petter Langtangen Updated +Created
It should be mentioned that when you start Googling for PDE stuff, you will reach Han's writings a lot under his GitHub Pages: hplgit.github.io/, and he is one of the main authors of the FEniCS Project.
Unfortunately he died of cancer in 2016, shame, he seemed like a good educator.
He also published to GitHub pages with his own crazy markdown-like multi-output markup language: github.com/hplgit/doconce.
Rest in peace, Hans.
Version your material Updated +Created
Whenever you make a change to your material, people should still be able to access the previous version.
Maybe there was something in the previous version that they needed, and you just removed.
Git + GitHub is the perfect way to do versioning.
Hugging Face Updated +Created
Interesting website, hosts mostly:
Infinite Napkin Updated +Created
800+ page PDF with source on GitHub claiming to try and teach the beauty of modern maths for high schoolers. Fantastic project!!!
Interesting members of the Santilli family Updated +Created
Found through Google with no direct relation known to Ciro Santilli:
Possibly related variants:
Mailing list Updated +Created
It boggles Ciro Santilli's mind that people use mailing list to collaborate on projects!
The only explanation is that the dinosaurs who created the projects are unable to adapt to new superior technologies.
Yes, Ciro is talking to you, big fundamental projects from last century: Linux kernel, GNU Compiler Collection (gcc.gnu.org/lists.html), Binutils (sourceware.org/binutils/), etc.
Some of you are already using Bugzilla for the bugs, so kudos. But if you've seen their benefit, why you still use the mailing list for patches?
Advantages of mailing lists:
Disadvantages: everything else:
  • cannot subscribed to a single thread. Which forces you to create an email filter for each one of them you subscribe to.
  • no metadata, notably the notion of closing / merging, but also upvotes
    You have to read thirty messages before you can know if the bug was solved or not.
  • it is insanely hard to reply to messages from before you were subscribed: webapps.stackexchange.com/questions/23197/reply-to-mailman-archived-message/115088#115088
    This forces everyone to subscribe to all lists, and then set up email filters to not be flooded with emails.
  • Unless they use Patchwork, which adds one more website on top of the mess.
    And then Gmail corrupts your patches, and you are forced to use git send-email, which does not work on some network configurations: stackoverflow.com/questions/28038662/how-to-solve-unable-to-initialize-smtp-properly-when-using-using-git-send-ema or setup ThunderBird.
  • often have to subscribe to post at all, thus cluttering your inbox further
  • you can edit posts to make them clearer.
    Yes, people could vandalize their answers when they get mad, and threads might stop making sense after edits. But this can be solved with an undeletable post history like Stack Overflow has (but not any other tracker does).
    Or archive.org :-)
    In any case, what do you think will happen more often and have greater impact:
    • people vandalize their posts
    • people fix their silly typos and improve content
  • searchable by author, keyword, etc. without Google. Yes, mailing list trackers could have decent implementations to overcome that. But no, GNU Mailman which everyone uses does not have it. Google barely indexes it.
    And I don't think Google properly indexes many of the mailing list archives for some reason: I never get hits for my own posts a week later, while I often do on GitHub issues.
  • people have to learn about top posting vs inline posting, and this requires infinite education of new users
  • Line comments in code reviews like GitHub and GitLab.
    On mailing lists: either put a comment in the middle of a huge patch and let other people find it, or (more likely) copy paste the part of the patch that you are talking about.
  • most mail web UIs suck.
    OK, this is not an unsolvable or intrinsic problem, but still a problem.
    E.g.: ezmlm it is not possible to see the entire content in a single page: gcc.gnu.org/ml/gcc/2015-07/threads.html.
    Unless you like reading threads backwards and with 4 levels of > quotations.
    The alternative: do like LLVM and send attachments. Yes, I we all love opening up attachments on our browsers.
    The real solution: everyone can create branches and pull requests. Also has the benefit of running CI on the pull requests.
Not sure:
  • you can have infinitely many trackers to replicate data in case apocalypse happens in some part of the world.
    Although I'm not sure this is an advantage, as you don't know anymore which one is the canonical trackers an advantage, as you don't know anymore which one is the canonical tracker.
    And all web interfaces already have an API to export messages, and someone has already scripted it to import from any web UI to any web UI for you.
    And GitHub offers infinite precise history transparently on its API.
PlanetMath Updated +Created
Based on GitHub pull requests: github.com/planetmath
Joe Corneli, of of the contributors, mentions this in a cool-sounding "Peeragogy" context at metameso.org/~joe/:
I earned my doctorate at The Open University in Milton Keynes, with a thesis focused on peer produced support for peer learning in the mathematics domain. The main case study was planetmath.org; the ideas also informed the development of “Peeragogy”.
Quantum Algorithm Zoo Updated +Created
The most comprehensive list is the amazing curated and commented list of quantum algorithms as of 2020.
Quantum computing player in Brazil Updated +Created
Saylor Academy Updated +Created
This is an interesting initiative which has some similarities to Ciro Santilli's OurBigBook project.
The fatal flaw of the initiative in Ciro Santilli's opinion is the lack of user-generated content. We will never get there without UGC and algorithms, never.
Also as of 2021, it mostly useless business courses: learn.saylor.org unfortunately.
But it has several redeeming factors which Ciro Santilli aproves of:
The founder Michael J. Saylor looks a bit crooked, Rich people who create charitable prizes are often crooked comes to mind. But maybe he's just weird.
Video 1.
Michael Saylor interview by Lex Fridman (2022)
Source.
At the timestamp:
When I go, all my assets will flow into a foundation, and the foundation's mission is to make education free for everybody forever.
What statement... maybe he's actually not crooked, maybe it was just an accounting mistake... God, why.
If only Ciro Santilli knew how to contact him and convince him that his current approach is innefective and that Ciro has something better! Michael, please Google into this page some day, Ciro Santilli needs funding for OurBigBook.com. A hopeless Tweet at: twitter.com/cirosantilli/status/1548350114623660035. Also tried to hit his saylor@strategy.com.
SuperCollider Updated +Created
domain-specific language unfortunately, but at least it's on GitHub, looks promising.
How to play scores and save them to files is discussed at: doc.sccode.org/Guides/Non-Realtime-Synthesis.html
They have a nice looking IDE, but running anything from the command-line interface is super hard, much unlike Csound. How to get a decent hello world: stackoverflow.com/questions/65360414/how-to-play-a-supercollider-file-non-interactively-from-the-terminal-command-lin
Sample composition with custom synths + notes: sccode.org/1-5cl
leanpub.com/ScoringSound looks like a decent tutorial, it is basically the Csound FLOSS manual for SuperCollider.
SWE-bench Updated +Created
By Princeton people.
This one aims to solve GitHub issues. It appears to contain 2,294 real-world GitHub issues and their corresponding pull requests
The dataset appears to be at: huggingface.co/datasets/princeton-nlp/SWE-bench in Parquet format.
The Machiavellian Stack Overflow contributor Updated +Created
  • always upvote questions you care about, to increase the probability that they will get answered
  • never upvote other people's answers unless you might gain from it somehow, otherwise you are just giving other high reputation users more reputation relative to you
  • only mark something to close or as a duplicate if it will bring you some advantage, because closing things creates enemies, especially if the OP has a high profile
    One example advantage is if you have already answered the question (and the duplicate as well in case of duplicates), because this will prevent competitors from adding new better answers to overtake you.
  • protect questions you've answered whenever someone with less than 10 reputation answers it with a bad answer, to prevent other good contributors from coming along and beating you
  • when you find a duplicate pool answer every question with similar answers.
    Alter each answer slightly to avoid the idiotic duplicate answer detector.
    If one of the question closes, it is not too bad, as it continues netting you to upvotes, and prevents new answers from coming in.
  • follow on Twitter/RSS someone who comments on the top features of new software releases. E.g. for Git, follow GitHub on Twitter, C++ on Reddit. Then run back to any question which has a new answer.
  • always upvote the question when you answer it:
    • the more upvotes, more likely people are to click it.
    • the OP is more likely to see your answer and feel good and upvote you
  • if a niche question only has few answers and you come with a good one, upvote the existing ones by other high profile users.
    This may lead to them upvoting or liking you.
    Even if they don't, other people will still see your answer anyway, and this will lead to people to upvoting you more just to make your great answer surpass the current ones, especially if the accepted one has less upvotes than yours. Being second is often an asset.
  • always upvote comments that favor you:
    • "I like this answer!" on your answers
    • "also look at that question" when you have answered that question
  • don't invest a lot in edits. They don't give you rep, and they can get reverted and waste your time.
    Why are you trying to help other people's answers to get rep anyways? Just make a separate answer instead! :-)
  • if you answer a question by newbie without 15 reputation, find their other questions if any and upvote them, so that the OP can upvote your answer in addition to just accepting
  • If you haven't answered a question, link to related questions you've answered on question comments, so more people will come to your answers.
    If you have answered the question, only link to other questions at the bottom of your answer, so that people won't go away before they reach your answer, and so as to strengthen your answer.
  • if a question has 50 million answers and you answer it (often due to a new feature), make a comment on the question pointing to your answer
  • if you get a downvote, always leave a comment asking why. It is not because you care about their useless opinion, but because other readers might see the comment, feel sorry for you, and upvote.
  • ask any questions under a separate anonymous accounts. Because:
    • intelligent people are born knowing, and don't ever ask any questions, so that would hurt your reputation
    • downvoting questions does not take 1 reputation away from the downvoter, and so it greatly opens the door for your opponents to downvote you without any cost.