mediocregopher

This was made by a friend of mine. It uses only CSS and DOM elements, no WebGL/canvas/anything-else. You can also check out the actual repo here:

https://github.com/likethemammal/css-visualizer

Except that that's not true:

http://arstechnica.com/information-technology/2013/10/google...

Unless you're trying to run a commercial website from your apartment, but I don't think that's unreasonable.

I think you'll find this ted talk interesting, as it explores that exact idea:

http://www.ted.com/talks/jack_horner_shape_shifting_dinosaur...

It's also pretty entertaining to watch

> flymake in emacs, don't know what in vim

https://github.com/scrooloose/syntastic for vim.

What steps did you take to get it running on Arch? I got as far as convincing it to use python2, but then realized I need gnome-keyring, and kind of stopped there. Which keyring package did you install?

There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like:

  type PoolObject interface {
      Destroy()
  }

And have it interact with that. The NewPool func would look like:

  func NewPool(func() PoolObject) Pool

EDIT: Changed my code a bit

Reading the documentation, it seems that sync.Pool will automatically shrink the pool size when it's not being used? If so, unless in the future it provides some way to specify a cleanup function for those values, using it for connections and the like would result in hanging connections (I think, not 100% sure).

Someone posted the bobrossquotes linke above, and it had this little gem in it:

Oooh, if you have never been to Alaska, go there while it is still wild. My favorite uncle asked me if I wanted to go there, Uncle Sam. He said if you don't go, you're going to jail. That is how Uncle Sam asks you.

I wrote this to scratch an itch of mine: There is nothing about go which prevents the use of generics. I wrote the following library to scratch an itch of mine:

https://github.com/mediocregopher/seq

It provides clojure-like data-structures and functions for interacting with them (like map and filter). It's completely immutable and generic, and supports lazy operations.

Basically to install a dependency you do something like "go get github.com/mediocregopher/somelib", and the tool will fetch it and put in the appropriate spot on your GOPATH. So the universal name of your package is also the address the package is retrieved from. You COULD host the package multiple places and it wouldn't be true that it would be unique in the whole universe, but that's up to you.

Agreed. Erlang's maps have two different operators when setting values on them, one if you care that the key already existed and one if you don't, so in that way you can still somewhat enforce strictness of keys. But you can relax that strictness when it comes time to roll out changes.

The addition of maps is really awesome. In my applications I've had records, which are kind of like C structs, being passed around to represent state. But if I need to add features the records become very constraining, because adding another key to them invalidates any previously existing records when you do a hot reload. So you have to jump through a bunch of hoops to get the records migrated, or just restart the whole system, which is less than ideal.

With maps this whole class of problems goes away.

My friend found you can get pretty far in the game (at least a 1024 block) if you just spam RIGHT-DOWN-LEFT-DOWN repeatedl (basically rolling your fingers across the bottom row of arrow keys).

It was a little upsetting when I had actually been putting thought into my play and he was doing better.

It's more than that. It's an extremely easy to use frontend. For instance, that link you posted doesn't have any way to see the JSON form of the profile. It also doesn't do any of the fanciness you mentioned below with joining together split up profiles that you mentioned in a comment earlier. More than that, this space needs some sort of de-facto standard for the protocol, and yours is as simple as any else.

Here's the use-case I'm thinking of. I want to create an in-browser pgp-messager using pgp keys that are on the nmc blockchain. If the onename "protocol" became ubiquitous this would be more or less trivial. A simple webpage with a "username" field and a "message" field. Javascript fetches the public key listed in the profile and encrypts the message (ignoring potential issues with using javascript for encryption).

That would be awesome, and there would be a million other applications besides. The problem is "onename.io" is a central point, both for failure and attack. If others could run this same pretty frontend, then there could be third field on that page for "onename endpoint", which would default to "onename.io" but could be anything. I could have my own personal instance, my employer could run one, my ISP for my neighborhood, etc... Farther down the line it could even be something built into a browser or OS, where you can specify custom default endpoints just like you do with DNS.

I don't really have any say with what you've created, it's your thing and you do with it as you see fit. But in my opinion your "pretty front end" is the best one so far, and I think could actually have appeal outside of crypto-geek-world. You just need to open-source it :P

Just registered my name and I have to say I really like the whole process. It was very smooth, and I like the way it looks and the potential it has.

Is there any way this can be a truly open-source project? Right now the "protocol" is open, but if wanted to host my own front-end for me and friends then I'm out of luck.

Never be embarrassed for the music you listen to. Some of us genuinely enjoy listening to shitty house music outside of work :)

I also recommend death/folk metal. It's very high energy, and while there are lyrics they're generally unintelligible or in another language. Equilibrium or Wintersun are good starts.

In my mind it could be something run on a local lan, or at the organization or neighborhood ISP level. In those cases there is still a question of how trustworthy those sources are. But there is also a reduction in the ability to compromise many connections. An attacker targeting a specific computer or person or organization still has an avenue, but there is much less room for compromising the entire scheme as a whole (of which there is plenty of room currently).

The solution as presented doesn't solve ALL of our problems, but solutions rarely do, and it's not reasonable to expect them to. But it does solve SOME, and doesn't present any new ones (although I expect to eat my words as I type that). Progress is progress, even if it doesn't get us the full mile.

As for trusting those writing this particular software, we don't really have to trust them, we simply have to trust the code.

This is super-cool. Not sure it's recommendable to use it in place of ssh, but maybe with ssl+http-auth it could be workable? It definitely adds some convenience for when I'm away from one of my boxes and I don't want to deal with putty.

As per all HN comments, one downside is that it kind of messes up with my vim colors, but that may be that my vim colors are messed up to begin with.

It's not currently possible to withdraw your 26k worth of BTC from MtGox, and for a long time now it is very difficult to withdraw USD as well. You could buy 26k of MtGoxBTC right now and wait for them to start withdrawls back up, and that would indeed net you a nice bit (assuming the market doesn't fluctuate very much during that event). However, right now it seems most are betting against that ever happening.

Nope, I posted this gist in a comment on the parent already:

https://gist.github.com/mediocregopher/8319986

The author says go doesn't have generics, and he had to rewrite the same set operations for each type that he used. Would this not work?

https://gist.github.com/mediocregopher/8319986

The items in the sets don't even have to be the same type

From the page: "Jelly works with your existing social networks."

My understanding was that it works as an addon to facebook or twitter or whatever. Maybe one of the creators is floating around here and can clear this up.

I think your parent was referring to why php's implementation is so complex.

I like that they're addressing this issue and think this is a good way to do it. My only concern is a semantic one: currently "d/" is the prefix for domains, "a/" for alias information (basically a global address book), etc... It doesn't make sense to create another prefix for domains (actually, many more prefixes for domains, since I imagine this won't just apply to com). I think instead they should consider something like "d/com/*" or something long those lines. It keeps DNS information all under the same prefix, and still conveys that the information is for the "legacy" com tld.

As you say, only the tail (or really, the head, if you think in terms of cons-ing onto a linked list) needs to be present for a client to operate at almost full operation. The only entities that really NEED the full chain are those who are doing historical accounting, like the various blockchain explorers and those who run analytics. These people are already putting some investment into scaling and processing concerns anyway, so I'm not worried about them.

I'll throw my hat in with all the other contenders in here. I've written a tool called goat which wraps around the normal go utility and sandboxes it to a directory, as well as providing versioned dependency management.

It's very simple and easy to use (there's only one new command), and adding it to a project requires no changes to existing code. We've been using it where I work and it's been very effective.

V1 is going to be released soon, check out the current version at https://github.com/mediocregopher/goat

For that case you're right, the scheme suffers from the same concerns as the CA scheme. The difference is that there is room to move forward, in that you can host the namecoin chain yourself and be sure of its accuracy. I think we could even have browsers have it built-in that they host a copy of the chain (the whole chain doesn't have to be downloaded, nor does all that's been downloaded need to be in memory).

When you create an account with cryptic.io, a private key is generated in browser and encrypted with the hash of your password. This encrypted private key is what we keep server-side. All files you upload, and all of your user-data, is encrypted using that private key. In short, all encrypting/decrypting of ANY sort happens inside your browser. So someone logging onto the server and viewing data as it is uploaded is still seeing encrypted data. Short of compromising a user's computer there is no way for them to see it. Our encryption scheme is nothing like the scheme that lavabit used.

The extension won't be able to mitigate an attack, but it will be able to alert you to one, which for someone who had the initiative to install it (which we will be heavily encouraging users to do) would be enough to inform them that something is amiss. And if something is amiss they can host the front-end themselves and use a local copy of the html/js/css so they can be sure they're getting a good copy of the site (something we will also be making easy to do).

A wildcard cert, which you would likely want/need if you're running a business, does indeed go for about $200 (that's the minimum I've seen it, if you have a cheaper source it would make me very happy :))

One of cryptic's features is that the front-end is completely open-source. You can see the source for the current prototype here:

https://github.com/cryptic-io/web

We'll be releasing tools, like a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.

And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary.

To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.