Speaking of implicit dependencies, here are a few: env, path, any executable file either in the current directory or in the search path. env = functions and aliases, and can be modified by any shell script. The path is an implicit dependency in the sense any chmod +x files in any of these directories can affect the shell. Which means the shell is also dependent on the file system itself.
Independently of the generality of your remark, here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody.
> here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody.
Totally right, because I didn't know how Servo is implemented, I've asked. Sorry for mixing in some emotion and hope about which answer I would get. I respect any developer doing any work and do realize it's all too easy to spread opinion without hacking on some solution.
Maybe as a non-contributor I should not have ventilated my opinion.
The issue at hand here is interesting: GIT _commit_ integrity is not guaranteed over all operations, even if you sign commits.
The problem is that GIT often changes commit details. If you, for example, rebase or cherry-pick a commit, the identity changes - as the commit includes a reference to the parent commit(s). This means that once you do any of those (standard) operations, the signature becomes invalid.
Signing only makes sense on a tag level or in repositories that keep all commits and never change them (e.g. by explicitly merging and adding merge commits).
There are systems that preserve commit integrity during all of those operations, e.g. DARCS.
I am aware of the mechanics of Google. In the context of the obvious stab of the parent to GitHub introducing a CoC and recommending to support GitLab was funny though, especially when throwing those terms in the ring.
Do you have any plans to revise that in order to preempt the sorts of problems that users are having with Github? I would imagine that most of the new users are expecting an environment there which isn't r-------.
That CoC is for GitLab the project. Not for GitLab.com. Right now we handle GitLab.com issues on a case by case basis. So far it was only Gamergate but I'm sure more will come up in the future. Gamergate opted to run their own GitLab instance http://gitgud.io/users/sign_in
Just want to say thank you for creating the free, open tools needed to host even more controversial stuff like this. Even if you're afraid to host it yourself, you've truly created a good for the world at large.
> I'm not sure whether Ruby is a good intro to programming.
> It doesn't have first-level functions, instead it has blocks
Hold it right there. If first-level functions, blocks and module systems are the first thing that springs to your mind when talking about teaching people with _zero, none, absolutely no_ previous experience with coding, you are speaking at a completely different level.
That reads far more like an attempt to discredit a language you don't like then actually caring about the subject matter at hand (teaching coding to kids).
I taught code at a programming bootcamp for a little over year to people who mostly had no experience programming. For the first 12 months the curriculum was mostly Ruby. I found it incredibly easy to teach Ruby to people and my students were able to build cool stuff relatively quickly with Ruby.
I taught over 100 people in that time and the vast majority of them are doing just fine now. Many are programming in some other language (Java, c#, python, js are common ones). Something about Ruby worked for them.