onionjake

While I'm sure this will help some people use git to address a use case that was previously impossible with git, I can't help but feel that it a bad step overall for the git ecosystem.

It appears to centralize a distributed version control with no option to continue to use it in a distributed fashion. What would be wrong with fixing/enhancing the existing git protocols to enable shallow fetching of a commit (I want commit A, but without objects B and C, which are huge). Git already fully supports working from a shallow clone (not the full history) so it wouldn't be too much of a stretch to make it work with shallow trees (I didn't fetch all of the objects).

I'm sure git LFS was the quickest way for github to support a use case, but I'm not sure it is the best thing for git.

I wrote my own hashing method [1] that given a correct spec for password restrictions would always generate a valid password. It does it by taking the hash in base64, then translating those a new set of base64 characters chosen to increase the likelihood of getting a valid password. If one generated is not valid, it then iterates until a valid one is found (by cycling the bits).

I have used this personally since I wrote it. Given the downsides, I agree that password managers are probably better for most people.

[1]: https://github.com/onionjake/doh

I believe the sentiment was more: I understand that you may have a bad day/week/month and do poorly on a project, but don't sweat it. If you really do know your stuff you can still prove it on the exams.

I think it is fair and better than purely weighted grades because it allows for momentary failure while still requiring knowledge of the material.

I took a class from Matt Might and I like how we were graded:

"Your grade is your tests grade or your projects grade, whichever is higher." http://matt.might.net/teaching/compilers/spring-2015/#gradin...

This allowed both the really good test takers to succeed and also those who did better on projects, without all the pressure.