Cost is typically LCOE - levelized cost - which takes life time, maintenance, fuel, construction, etc into consideration

This is quite a complex topic and you can google and wiki LCOE for all the gory details.

Can anyone comment on the CPU requirements for such a system? (either this one or AlphaGo) How many commutative CPU/GPU hrs are required to get to here?

Just make sure you have an over night bag ready ;)

Prediction market have been declared illegal in the US.

UIGEA carve out is specifically restricted to sports and scoring related simulation (guess who lobbied for it).

This is regardless of various state-specific laws, as well as the current daily-league legal battle.

Any futures trading is also regulated by the CFTC

Haha I hope it doesn't come to that. In the excerpt above, it states "participation in any fantasy or simulation sports game or educational game or contest". There are also other non-sports related fantasy websites such as Celebrity Fantasy Draft which have won awards from the Fantasy Sports Trade Association. We, and our lawyer, did not think that this violated the law.

As mentioned in other comments, we do not allow players to "cash out" if they are from states in which fantasy is banned. This is similar to what DraftKings and FanDuel do.

Does that address your concern?

Does this create a new DHT entry per tweet or per user ?

I think the DHT itself can quickly become overloaded/slow - DHT does impose some b/w overhead for each node

One DHT entry per tweet. I do agree that it does create overload on the DHT. Initially in fact I was looking at implementing it as such: https://github.com/bittorrent/bittorrent.org/issues/19#issue...

Problem is that you don't get the "hosting" effect that you get with the DHT so you always need a peer seeding your feed or else it won't be reachable.

Anyway, I hope others take on the challenge of implementing alternatives looking at different methods.

Actually - i have been playing around with building a feed on top of a single torrent - so it would be one torrent per user - and subscribers to the torrent would (hopefully ;)) get a feed of updates

Could this interest u ?

I have always thought that it would be great if the original uploader of a torrent could (securely) modify the torrent so it could have multiple versions, ie if they found one file was corrupt they could update just that file, or add more files (say it was a TV series, they could just keep updating the original torrent with the new episodes). And when you connected to the DHT it could ensure you had the latest version. Of course it would add complexity and I'm not sure how torrent indexing sites would cope but it could be cool.

Signed torrents with versioning.

you have some example about this?

yep.. seems to work in alpha..

No changes required to other DHT node. Which is cool. And i was specifically aiming for a low/scalable bandwidth overhead

Each new "announce" propagation is kinda slow.. 1-10min to spread through the DHT..

I am more worried about the obvious attack of sending a person a large known plaintext, and then using this to decrypt his tarball.

Setting aside the effects of hype, hipness and herd -iness..

Are you asking about the language or the platform ??

The usual argument for node vs java (for example) is that node has many small libraries (really code sniplets) which are instantly usable. So a lower activation energy!

As far as platform, the technical merits of a JVM are so much down the road so as to be completely meaning less at the critical early stages.

Nice app. Please please add any sort of import capability

(You can look at simplenote export/import csv/json format)

Why oh why do people still write standard GUI applications in non-portable platform ?!

Its a mystery to me

You either make it look beautiful in one place, or make it look like ass in three places.

Or, option C: You use Electron, like Slack.

I keep waiting for Slack to realize that they're a big enough company now that they can afford to make native apps that look and work better than the Electron version. I'd much rather have a real native app than a webpage inside some minimal window chrome. Different strokes for different folks I guess.

The Slack client looks nice but it's incredible how inefficient it is (presumably due to being a web app in an Electron wrapper). I used it recently on a low powered laptop and keystrokes sometimes took 100-300 msec to appear on screen. No other text entry application on that computer had that problem.

What would be some of the improvements making slack native? I don't have many problems with the current one other than it is quite large.

Memory usage, CPU usage, OS integration, security.

Gotcha, thanks

Qt looks very nice to me. But then again my preferred GUI is ncurse in my terminal (urxvt) with tmux in a tiled window manager (i3).

Another option - you can do everything in a terminal. Not everyone finds minimalism beautiful, but - if you do.

It's still going to be a bit of a problem, as you have the Unix terminals (bash, zsh, fish, among others), and then you have the Windows terminals (cmd.exe and PowerShell).

There are benefits to having a pure, native app. Quiver starts literally instantaneously without any lag, partly because it's less than 5MB(!) in size. Here's a good read from the author: http://yaoganglian.com/2015/11/21/Quiver-3/

Yep. Speaking specifically about developing for OS X only vs. multiplatform, there are big tradeoffs to be made by taking multiplatform options outright. In my eyes, nothing is as great for UI-centric desktop application development as Obj-C/Swift paired with Cocoa/AppKit. It just works so well, and though Qt is probably the best of native multiplatform solutions it’s still not comparable.

Exactly. I used another note taking app, aptly named "Notebooks" (http://www.notebooksapp.com), which is built with Qt. It's cross platform, open data format, and while it sort of looks and feels almost like a native app, it just doesn't compare to a true native app like Quiver.

I was disappointed to see it was OS X only, but having written several GUIs (single and cross platform), I understand the trade off they made.

It really is one-platform or web, and web is not for everyone (least of all programmers writing notes about their code at work.)

That's my experience as well. Electron/NW.js is the best option, but 1) it's like designing a website, which can get annoying at times, and 2) the file size :(

I agree on that. Unless you are developing a platform specific utility that is not meaningful in other environments, it is not a good practice to limit yourself. It also makes sense is when you are not creating a product bust just playing with a technology.

Even Microsoft is now doing multi-platform tools for developers (https://code.visualstudio.com/).

Because otherwise they don't look or behave nicely.

Or you end up writing the same product multiple times.

Because the result is always better?

Might be a mystery but I'm really glad they keep doing it, because the alternatives are 1) all your data are belong to us, or 2) it looks terrible everywhere.

IMO there is nothing worse than a non-native app, especially if it's something designed for a web browser like NodeJS and friends.

Free beats the rest ;)

Maybe not having all these features is part of the concept?

Maybe, but at least the lack of "search" is critical.