mediocregopher

My understanding of pinning is that it could just as well be used in a namecoin based system, and could enhance the security of that scheme just as it does with the CA scheme. All of these ideas could work together, with namecoin as the external, third-party source of trust instead of the CAs.

So I guess a better title for the post would have been: "Namecoin, A Replacement For Certificate Authorities"

To play the devil's advocate, if you're already a happy user of tarsnap then you (like me, in fact) are probably quite comfortable on the command-line, and may even prefer it. As of right now Cryptic doesn't have a command-line utility, although building one is definitely on our radar! But until then you may find it more comfortable. Thanks for checking us out though!

For your second question, all resources for the site, including javascript, are served over SSL. This will prevent about 99% of MITM tampering attacks. While we can't overcome the inherent weakness in SSL, or guarantee against compromise on the server-side, we are working on a browser extension which will check the code you receive from the server against what is in the repository, so you can at least be alerted of any inconsistencies.

And since the website is all open-source, we're going to make it simple to host it yourself, if you want to be extra-sure that it's not compromised.

EDIT: By "website" I'm referring to the frontend, in-browser code

There is a difference between a string and a byte array. A string is a string. A byte array is a []byte (byte slice). You have to explicitly cast from one to another. Neither are inherently utf8. A string is represented by a byte array under-the-hood, and string literals in your code are read as utf8 encoded. Strings themselves are not necessarily utf8 encoded, and if you need to use a different encoding there's libraries for that (unless you're using something really esoteric).

A bit off-topic from the original article, but I wrote a little tool for this very purpose. It's still not fully fleshed out, but we're using it at my place of work and it's worked out pretty well so far. I haven't gotten much coverage of it though, so if anyone wants to take a look at it and send some comments/suggestions, that'd be pretty awesome:

https://github.com/mediocregopher/goat

The nice thing about goat is that if you've been following go's best practices for development (namely, all of your import paths use the absolute import path, for example "github.com/whatever/myproject/submodule") then you won't have to change ANY of your existing code.

http://bitcoinwisdom.com/markets/btce/btcusd

(They both show the same trend, I'm just being pedantic)

This event didn't cause the price to be halved. It actually didn't effect the price at all. The article makes a strange mention of some $230 number, which might have been the price like a year ago, but it's been pretty constant around 110-120 for a while now.

EDIT: Sorry, this was supposed to be a response to lnanek2, mis-clicked.

I feel like the author hasn't used go much. You almost never work with arrays directly, you use slices, which CAN be efficiently passed around.

EDIT: Upon re-reading I think the author was making a point about the consistency of go, and how different types have different behavior with regards to pass-by-reference/copy. There's actually a pretty simple rule for it:

If the variable is a primitive, or defined by the user, it is passed by copy (ints, strings, structs, etc...). Everything else (compositional types like slices and maps, and others like channels) are passed by reference.

The outlier are raw arrays, but again you don't ever actually use those, so you can just ignore them.

>I need to check return values at each step of the call stack, which is tedious and ugly.

I see it more as explicit. You HAVE to decide what you're going to do in case of an error. Usually it's as simple returning that error, but sometimes you want to do more, and having the question constantly being asked means you think about it for all cases.

A large sharktank in sweden

If someone taking off their shirt (and pants?) is enough to divert a significant number of security personnel such that a "hole" in the security wall is created, then I'd want to take a serious look at the level of training these people are getting. That's a job for like.... two people.

When you go to the site it already knows what school you go to (or at least it did for me). There's more then one school in my town, so I don't know if they just do geo-location and go with the larger school, or if they have some other source (I don't see how or what though). On one hand very cool, on the other a little worrying.

My only concern is my ability to get content back for archiving. Is there a way we could export the articles to some simple format? Either markdown or even just a plain text file?

Considering there hasn't been a major console (including xbox) that's been immune from crackers running arbitrary code, I'm pretty confident that we'll be seeing linux running on the surface at some point. Unfortunately the article's title is probably accurate; It's probably going to be too difficult for someone who's not a very-motivated linux fan to do it.

It's a shame too, when I first saw the surface my initial reaction was "Holy crap, if I can wipe it and put Arch on it it's the perfect mobile laptop replacement, I'll buy it for sure". Oh well, guess I'll have to wait to see how easy the jailbreak is.

javascript:void(document.getElementsByTagName("body")[0].bgColor="#eeeeee");void(document.getElementsByTagName("body")[0].text="#333333");

Makes the article readable

For us the logs are not opened in append-mode, just write. We don't do any house cleaning except for logrotate, but that only runs nightly and isn't the cause of what we're seeing. Like I said, it may not be for the normal mongod instance, but it's definitely true for mongos. I'll double-check on the version number of what we're running

> do you host your databases on Amazon?

Nope, all owned servers, over a local network on a switch we own as well. The switching happens on some clusters more then others, so it's possibly a usage related thing.

The setup alone is just bizarre, for each replica set you have to have 3 (and only 3!) config server instances associated with your set, along with possibly an "arbiter" instance depending on what circumstances you're operating under. I could do a whole rant (and have, in the past, to anyone who would listen) on the arbiter/voting system mongo uses. We've been left in a situation in the past where one of our secondaries randomly died (more on these lovely "random occurences" later), leaving the cluster with a master and an arbiter left over. Mongo decided that since there was an even number of votes (and why is my production-critical database voting on things?!) it couldn't promote a master (even though the master never actually died), dropped the master down to being read-only, leaving us completely boned. They have since fixed this issue (I think), but it definitely garnered a lot of ill-will from me, and should never EVER have even been a problem.

"Random occurrences" have always plagued us with mongo. Whether it's been random segfaults (less common with more recent versions, but oh dear god were they frequent pre-2.0), secondaries being promoted to master with no clear reason as to what sparked this (which has left us flailing twice now, when a master decided to step down while one secondary was in RECOVERING mode and the other was AWOL), config servers getting out of sync (one time one of the config server sets decided it was going to start hosting the config for an entirely different replica set, luckily no production mongos instances had to reload the config before we noticed), mongos instances getting out of sync/crashing (less common now than before, thankfully), and I'm sure much more that I'm not thinking of now.

To make all of the above about 10x worse the mongo logs are terrible. There is no distinction between INFO messages and ERROR messages in the logs, so everything has to be treated as an error of some kind. And there are many "errors" that we should "just ignore". This makes debugging pretty much impossible. Another nice feature is when you restart a mongos instance (and possibly a mongod instance too, although I could be wrong on that) all the logs from the old process get clobbered by the new one (so backup those logs folks!). It's extremely difficult to track down why slow queries are happening unless you can catch them in the act, and even then it's not trivial.

Mongo has many great qualities. It's one of the few (if the only, that I know of) that can do many of the things that it does, and for that it's very useful. But for it to have been marketed as a production-ready database was a bit disingenuous I think. It scales OK. Not well, just OK. You can make it scale if you try real hard and tiptoe around it so you don't wake it up and make it cry. I think someday in the future all of these issues will be fixed, but at the moment I don't recommend anyone use mongo for anything they plan on a significant number (200k+ users at any given moment) of users being dependent on.

Edit: Based on tessellated's response I may not be understanding the question. By workspace are you referring to the different "desktops" you can reach through the numbered boxes on the upper left (in the default config)?