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.
If you are concerned about the security and don't want to deal with putty (I can commiserate), there's always the secure shell chrome/chromium extension. If you haven't seen it already you might want to give it a look.
Well right off the bat: You don't have to install anything. You also don't need to worry about updating a thousand clients if a security problem crops up--you just update the server and you're done.
Also, in terms of "why" there's all sorts of neat things you can do with a web browser that aren't so easy with regular terminals. For example, displaying inline images (if you code it right). Gate One can display images, PDFs, and play back sound files right there in your terminal if you do something as simple as 'cat somefile.png' or 'cat somefile.ogg'.
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.
Seems like the landing page is full of fluff. All I see are feel good sentences about helping each other, Albert Einstein, etc.
The big down side is this: "“What’s this?” That query is submitted to some people in your network who also have Jelly".
I have +400 friends on Facebook. Out of those, maybe 3 will install Jelly to try it out. Even with taking friends-of-friends taken in to consideration, it's just a very limited set of people. Would I really want to use this app to post a question that I can probably find answer just by looking a map, doing a google search or posting to Facebook/Twitter?
I'm following a lot of Twitter and other SF tech people on Twitter, and I had tons of questions waiting. Maybe it will stick for a some people, but indeed, I don't think most people have enough questions to check this kind of app often.
Indeed. PHP is often criticized for having inconsistently named or patterned libraries, and the response is usually "PHP is a relatively light wrapper to a bunch of C libraries" -- In fact I saw 3 versions of strstr in PHP core - strstr, mb_strstr, and grapheme_strstr. I guess I would have expected one of them to be a somewhat thin wrapper around libc's strstr.
As another commentator pointed out, libc's strstr assumes NUL-terminated strings. Maybe php's doesn't? Which seems a bit odd to me in light of the explanation of PHP's genesis as having roots in C, but stranger things...
I'm not surprised at all that libc's strstr would be 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.