He said that this is just to try out github for now. And for now the official development will be on Google Code. And then when he's ready to move it over, he'll wipe the current repository on github.
"To see how well this works I have created a SNAPSHOT of the repository.
This way we can try it out. "
I'm not sure what PGP would buy us over everything going over https from sites under Meteor's control? Cryptographic verification is great when you want to deliver the bulk of the content over http, or via untrusted mirrors, but we're not doing that.
However, if you want greater assurance, Meteor is open source, and easy to run from a git checkout. That seems to solve even more problems than PGP would, though then you should worry about whether you should compile nodejs yourself, and eventually you start eyeing your CPU suspiciously... :-)
(BTW, I think this is why just linking to a HN thread is tricky... it's difficult to know which of the many viewpoints on any thread you share!)
It buys you almost nothing. The only thing it buys you is avoidance of knee-jerk reactions from certain people, who most likely never were interested in Meteor in the first place.
> I'm not sure what PGP would buy us over everything going over https from sites under Meteor's control?
Rogue CA certificates, targeted MITM -> RCE attacks (Nation State Adversaries, etc.)
By using PGP (or, hell, openssl) to sign the package with a key that remains offline/air-gapped and then writing installer instructions that verify the signature before running anything, you reduce the odds of this happening significantly.
Additionally, it allows you to mirror the contents on CDNs with some peace of mind.
PGP would get you a lot. See this discussion for why https "only helps in a small way and is not enough to provide users with a reasonable level of trust that it's safe to use your
software."
I thought it would be cool to use Firebase to add a widget to my blog to show what song I'm currently listening to with pianobar (a command line pandora client).
Yes, my gist, but also a Twitter conversation on how strong typing altered the need for tests. I've heard from a couple Haskell programmers about how the language practically eliminated the need for tests. I don't see how that's possible, but I also know Haskell.
I asked for a specific code example, and I threw out the scenario of a client who wants a contact us form that logs all responses and sends notification emails. I threw out a simple Ruby example where I tested the functionality, and I'm waiting to see the alternative.
Haskell does not practically eliminate the need for tests. I am very concerned that Haskell programmers are getting the reputation for claiming such things because they're simply not true.
Haskell's type system does statically check many things you might want to write tests for which makes those particular tests unnecessary, but it doesn't eliminate the need for tests in general. If you hear any Haskell programmers making claims that sound like that please ask them to be more precise.
It's an honest question to ask in the face of an assertion about testing -- or how strong or static typing eliminates the need to verify that the code behaves as written. In the sample I provided, I provided a concrete example as to how I could verify that the code accomplishes the task. If tests are not needed, then fine... show me how with code that accomplishes the task and that show how.
Like the "unit" where the two operations are covered in one method... Sure, but how else would it be done? The client asked for the log and the email, so somehow, someway... someone has to write code to do it.
I threw up my Ruby sample in just a few minutes... why can't the alternative be coded up in a few more?
I love this idea! I work in an open space with a bunch of developers in close quarters, and we're constantly interrupting each other. The collaboration is great, but sometimes it would be nice to be able to get some uninterrupted time to really get stuff done.
My only concern is that the sign always says "Wired in" even when you aren't wired in. I know I could teach my co-workers what each color means, but I would like it if it was a little more intuitive. What are your thoughts on how to get your co-workers on board with this idea?
I think that's a cool idea for an app, but I also love the idea that it didn't really matter what the idea was, the point was to deliver something. That's inspiring!
"To see how well this works I have created a SNAPSHOT of the repository. This way we can try it out. "