iCloud was storing cleared browsing histories - <AUTHOR> http://www.theverge.com/2017/2/9/14559376/apple-icloud-cleared-browsing-history-stored <comment><USER2> After a crash Safari is nice enough to restore your open windows and tabs... I've noticed several times that it's also nice enough to re-open your private browsing windows, too. That throws up some red flags for me.

<comment><USER3> That's a MacOS thing, not just a Safari thing. Windows stay open until you close them, even across restarts. MacOS, like iOS, has mostly retired the concept of "quitting an app kills state".

(You can go back to the old behavior via a system setting: "Close windows when quitting an app")

<comment><USER4> This feature isn't some kind of evil magic... it isn't like it is serializing the virtual memory state of the entire process to disk in the style of unexec(): programs have to manually decide what they think matters for their suspension state; correspondingly, if this happens, Safari would have to be incorrectly saving information that the user clearly doesn't expect or want.

<comment><USER3> _> Safari would have to be incorrectly saving information that the user clearly doesn't expect or want._

This is vestigial thinking from the MacOS perspective. The concept of "saving" is gone. The concept of "memory state" versus "disk" is gone, from the user perspective. Those are all implementation details now. For the user it's simply, your windows stay open until you close them. Quitting does not close windows, so it's not unusual to see them when you return to an app.

By the way, Safari in iOS does exactly the same thing. And given that iOS kills apps on its own, there would be no question that randomly killing private sessions would be a bug.

I mean maybe you could distinguish between a force quit and an OS quit, but why? Just close the windows if you want to clear them. The private window guarantee is there will be no trace after you close the window. It's just vestigial thinking that quitting apps also closes windows.

</comment></comment></comment></comment><comment><USER5> Sounds like a mistake rather than some nefarious data collection strategy.

Apple doesn't rely on advertising revenue like Google or Facebook so in the past they've been much more likely to _avoid_ collecting data whenever it could get in the way of their self-professed privacy narrative.

<comment><USER6> Storing data on Apple's cloud services is a privacy risk given their inability to keep it secure. We had the celebrity iCloud hack, caused at least in part by Apple not using 2FA for iCloud logins. And now this privacy failure.

Storing your data on a cloud service that isn't competent is a privacy risk.

And a reliability risk, as I found out last year when my albums on iCloud Photos disappeared. Not the photos themselves, just the albums in which I organised them, but organising data can take a lot of time, and any data loss is unacceptable. They weren't in trash.

Apple's "self-professed privacy narrative" is partly right, but partly marketing, and partly disingenous, as if collecting data has no other purpose than advertising: [https://dcurt.is/privacy-vs-user- experience](https://dcurt.is/privacy-vs-user-experience) To be clear, I'm not taking a black-and-white view; it's partly right, partly wrong.

BTW, The Verge wasn't clear — was the forensics firm getting data from an iDevice or Mac's local storage, or across the Internet from iCloud servers?

<comment><USER7> Apples approach to security is nicely summarized by the fact, that you're not allowed to use 2FA for iCloud at all on a Mac if you don't own an iPhone.

<comment><USER8> Both two step authentication and two factor authentication can be set up to use text message or phone call verification to an arbitrary phone number.

<comment><USER7> According to this: [https://support.apple.com/en- us/HT204915](https://support.apple.com/en-us/HT204915)

a "trusted device" is only an Apple device, phone calls are for backup when you lose them. Even after that it's significant inconvenience in comparison to any other vendor using a standardized OTP approach working with any application that implements the standard. It's one of the little ways how Apple makes not owning an iOS device inconvenient for mac users.

<comment><USER9> It's extremely confusing, but Apple has two types of multple-factor authentication solutions in use.

The 'legacy' (my phrasing, only because it was the first implemented) MFA is SMS-based, and thus has not dependency on iPhones.

There's a newer (about a year or two old by this point) solution which has a 'richer user experience' and depends on having other Macs or iPhones to receive the MFA authentication dialogs.

<comment><USER10> The newer solution ("Two-factor authentication") also allows non-Apple phones to receive a code on their "trusted phone number". From the support page linked in a nearby comment:

 _What if I don't have access to a trusted device or didn 't receive a verification code?

If you're signing in and don't have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text or a phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device._

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> If you're concerned about artifacts being left around, then you should also know that there is a log file of every file you've ever downloaded, including in private browsing mode. You can see it with this: [https://macdaddy.io/cleandisk/](https://macdaddy.io/cleandisk/)

<comment><USER12> Today I learned that $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 is a sqlite database. The LSQuarantineEvent table contains every file you ever downloaded, the source URL is in the LSQuarantineDataURLString column.

sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'select LSQuarantineDataURLString from LSQuarantineEvent'

sqlite3 $HOME/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 'delete from LSQuarantineEvent'

<comment><USER13> Select gives me 22 rows. I'm pretty sure I've download much more. Maybe per session?

<comment><USER12> I saw stuff in there I downloaded days or maybe even weeks ago. (Couldn't tell you exactly when since I've deleted it all now.) I've heard reports of people seeing downloads from years ago.

Here is a SQL to view timestamps:

SELECT datetime(LSQuarantineTimeStamp + 978307200, "unixepoch", "localtime") as LSQuarantineTimeStamp from LSQuarantineEvent

(Based on [http://www.forensicswiki.org/wiki/Mac_OS_X](http://www.forensicswiki.org/wiki/Mac_OS_X) with modification.)

In my testing, only downloads from Safari are logged here, not those from Firefox (haven't tested Chrome). If you don't use Safari as your primary browser, that might explain not seeing many downloads.

</comment></comment></comment></comment><comment><USER14> Apple engineers are not different from the rest of people - deliver first, fix when fails. Wiping tombstones in constantly-syncing environment is a cumbersome piece of engineering.

</comment><comment><USER15> That's why I'm wary of browser sync as a concept. Maybe it's not as convenient, but I would better transfer bookmarks as an export file, and passwords as a password manager encrypted container. As for browsing history I'm not even sure it has any long-term importance - useful browsed links can be bookmarked, saved to delicious/diigo/pinboard, tweeted, upvoted on reddit/hn, whatever.

<comment><USER16> FF used to have browser-sync that you could send to your own server. Last I checked they had disabled it, but I wish it could be revitalized.

<comment><USER17> I didn't try but it doesn't seem to be disabled. They have two guides

Self hosted sync server [https://docs.services.mozilla.com/howtos/run- sync-1.5.html](https://docs.services.mozilla.com/howtos/run-sync-1.5.html)

Self hosted accounts server [https://docs.services.mozilla.com/howtos/run- fxa.html#howto-...](https://docs.services.mozilla.com/howtos/run- fxa.html#howto-run-fxa)

The latter includes instructions about how to add the accounts server url to about:config

<comment><USER18> Can confirm, still works fine as it always did.

</comment></comment></comment></comment><comment><USER19> Original, non-blogspam article: [http://www.forbes.com/sites/thomasbrewster/2017/02/09/apple-...](http://www.forbes.com/sites/thomasbrewster/2017/02/09/apple- safari-web-history-deleted-stored-icloud/)

</comment><comment><USER20> That's not good, but at least they had this going for them?

> Unlike most iCloud data, the records don't seem to have been accessible to > law enforcement requests. Apple declined to comment when reached by The > Verge.

<comment><USER21> I would like more clarification as to what this means. Does this mean the histories are purely client-side? If that's not the case, I don't see how they can make this claim.

<comment><USER22> That whole sentence seems mistaken since _no_ iCloud data is available to law enforcement. iCloud is AES encrypted with keys that are held by the user-only (not Apple).

As people have pointed out, yes, Apple is a trusted part of the system and could release a new iOS/macOS update that captures these keys but short of that, neither Apple nor law enforcement have any access to your iCloud data.

<comment><USER23> If that were really the case, how could you restore your data to a new iPhone? It's probably like the Dropbox encryption: its encrypted but they do have the key.

<comment><USER24> The key could be encrypted using the account password.

</comment></comment></comment></comment></comment><comment><USER25> backup system probably supports do not follow links, just need to add safari cache to the list. seems pretty innocuous. And if you are doing illegal stuff in your non-private browsing session, on a device that automatically backs up all of your data to the cloud... pretty sure you've left plenty of paper trail elsewhere.

</comment><comment><USER26> Doesn't matter, it's Apple and not Microsoft or Google, all is forgiven.</comment>


Bitcoin is acceptable payment for attorneys, Israel Bar Association rules - <AUTHOR> http://www.haaretz.com/news/national/.premium-1.539001

<comment><AUTHOR> Sorry for the Haaretz paywall, but I can't find the whole news in another site.</comment>


Ask HN: What could we human do with more computing power? - <AUTHOR>

Hi,
yesterday i discussed with a friend of mine what would change with quantum computers.
Would we overcome milestones in medical & biotech science? Would we explore more of our universe? I'm already very excited about this topic. What will change with exponential increased computer power?
Right now as quantum computers are not normalcy - what impact does current crowd computing have on science? There are a few project we you can let your computer compare proteins etc. - is it worth it my time, cpu power and electricity costs? How important is crowd computing?
Excited to hear your thoughts on that.
Best
ugd <comment><USER2> This is probably a silly idea, but I read that 2013 chemistry Nobel prize was given to guys to simulated complex chemical system. I am probably extrapolating this WAY too much, but I think if we have more computational power we can simulate cells. Protein structures are still not understood well.

<comment><AUTHOR> Hm. Sounds all not very exciting right now. We have to understand more to build algorithms that take away some work we'd 've to do manually

</comment></comment><comment><USER3> Waste it on more slower code.

<comment><AUTHOR> What do you mean?

<comment><USER3> Better computers mean developers waste more memory and more cpu cycles doing pointless things. More animation, more eye candy.</comment></comment></comment>


Turbulenz HTML5 gaming platform and engine released free of charge to developers - <AUTHOR> http://biz.turbulenz.com

<comment><USER3> This is not a free engine for HTML5 games. You are required to sign up to release a game on their proprietary * distribution platform* and give them 30% of your net revenue. Very misleading headline.

From the page:

"We supply your team with the Turbulenz HTML5 JS engine and all the Turbulenz APIs, free of charge. You bring a great game that embraces the way the web works; dynamic, social, and connected. We provide engine technical support, payment processing, analytics, game marketing services, and in some cases we may fund or co-fund the development of your game.

"The end result is a direct revenue stream, full control over the marketing of your game, and your game reaching millions of game players on many different devices and web destinations. Developers retain 70% of all net revenues."

Oh, and their platform seems immediately awful too, considering that you need to sign in to even SEE a single game they're offering.

A shame, too. Was hoping for a nice, free alternative to the Impact Engine (<http://impactjs.com/>).

<comment><AUTHOR> You don't have to release it via their distribution platform - you're free to distribute it as you like. They only take the 30% cut if you distribute it via them, which I'd say is pretty reasonable. FYI I'm not in any way associated with Turbulenz - I'm just at a conference where they demoed it.

<comment><USER4> That's not what the website says...

 _Games developed with the Turbulenz SDK will also be released and published on turbulenz.com at Turbulenz' own discretion._

No thanks.

<comment><USER5> The biz site had been updated:

 _4\. Release your game on any web destination of your choice, including your own website or established online platforms such as Facebook. There are no royalty or license payments due to Turbulenz._

You can release your game anywhere by yourself and it would be free. Alternatively, you can also release it on turbulenz.com and we will get 30% from all the payments we process.

</comment></comment></comment></comment><comment><USER6> Where/how can I see a demo?

And don't think you need my email or facebook login before I've seen what you offer and whether it's any good.

<comment><USER7> <http://www.youtube.com/watch?v=gjLaNjkYnrI>

<comment><USER6> Sorry that's not a demo, that's a showreel.

This is of interest to me, but I want to quickly see actual performance on a variety of test devices I have to hand.

</comment></comment></comment><comment><USER7> Here is the demo Video of it: <http://www.youtube.com/watch?v=gjLaNjkYnrI> (Gameplay starts at ~00;40)

</comment><comment><USER8> EDIT: As I mention in a reply below, this is now working for me after force enabling WebGL in chrome for ATI cards. My apologies to David and the team for jumping the gun.

\----

I get "Turbulenz is not currently supported on your platform, but we're working on it!" running Chrome under Ubuntu.

Sure, Linux gaming isn't a big market, but surely one of the big points of HTML/web gaming is cross-platform support?

I wish these guys luck - I actually interviewed there a while back, and the technical members really know their stuff - but I think they've got a few more barriers to cross first to get to 'it just works'.

<comment><USER9> Most of our developers use Ubuntu and I just tried to play Score Rush and it worked fine for me on Chrome under Ubuntu. Perhaps the browser is black- listing your video card and not supporting WebGL? If I can get more details about your system I can try to help.

<comment><USER10> It would be nice if the SDK were available for linux.

<comment><USER9> Most of the developers at Turbulenz use Ubuntu, so everything does work on Linux, it was more a case of lack of requests for a Linux version of the SDK so we concentrated our release process in the versions that our developers needed at the time. Now that we have a couple of requests for a Linux version we will probably release one shortly.

</comment></comment></comment></comment><comment><USER11> I am a bit disappointed, they promised a lag free network stack, but they just use websockets, so that's an empty promise. You can't have realtime multiplayer without UDP.

<comment><USER9> I think we need to update that bit in the whitepaper, it was written long before we developed our WebGL stack which as you pointed out now uses WebSockets. We are working on a multiplayer version of Score Rush that would be available on our website for everyone to try.

</comment></comment><comment><USER12> The technology and features of the engine and platform look awesome! That quake demo is really slick (and seems it was released 2 years ago, would be nice to see some newer videos).

I'm worried about the pricing model though, you say it's free but on the developers page it mentions that Turbulenz is able to put any game developed with it on their site at any time they like. That doesn't sit right with me and perhaps you could improve that in some way to attract more developers to use the engine (I can see you're following in apples footsteps but you really don't have the market power apple has).

Also when I went to the main website it's telling me Javascript is disabled even though it's not. I'm running Chrome V22 (the latest beta) on Windows 7 and have whitelisted the domain in adblocker to no avail.

<comment><USER9> It seems to be a bug in the latest beta of Chrome when using backbone.js (which we use):

<https://code.google.com/p/chromium/issues/detail?id=136381>

</comment></comment><comment><USER13> From the whitepaper:

 _"As a comparison, the Turbulenz Engine is equivalent to the Unreal engine."_

Really?

<comment><USER14> Perhaps they were not comparing the performance, but just trying to explain their product? However, it also says in the paper:

"Originally we created a technology demo using the Quake 4 assets. The demo created an FPS on top of the standard Turbulenz Engine but implemented a modern deferred renderer in place of Quake's original forward renderer. Once we had this multiplayer demo running at over 60 fps with particle effects, full screen effects, character animations, a full physical environment, 3D audio, networking and the deferred lighting solutions, we decided that JavaScript was absolutely capable and suitable for creating modern games."

<comment><AUTHOR> They showed this demo running live in Chrome, and to say it was awesome would be an understatement.

</comment></comment></comment><comment><USER15> both games aren't loading , i checked the console and it says assets not loading

<comment><USER9> Could you give some information about which browser are you using and were are you located? which game are you trying to play? Thanks.

</comment></comment><comment><USER16> I love how all the people trying to sell the latest and greatest HTML5 game engine solutions don't seem to understand what matters to actual developers:

First, the pipeline for actually building the game - what's the workflow like, what's your build system like, how easy is it to integrate with existing tools... If you're going to compare yourself to the goddamn Unreal engine, you had better at least have an answer to the utterly AMAZING tools they provide for artists, programmers, and other developers. Real game developers don't give two flying f--ks about whether you have Tumblr integration if they have to write a bunch of JSON to build levels and integrate into your build pipeline (and it's probably being generous to assume that their tech is sophisticated enough to use JSON files).

Second, the experience for players - sure, you've got a deferred renderer and a network stack. How much latency does your network stack introduce on top of the actual round-trip latency between the player and the server? How efficiently is your network stack able to use bandwidth (and is your prediction good enough to let me send less traffic for state updates?) How much memory and video memory do your demos use compared to a somewhat equivalent native app - will my players need a machine that's twice as beefy just to run a game in the browser using your tech? What are the average framerates like on an average machine - the canned videos suggest the framerates are bad, but actual runtime performance isn't even mentioned. How do you handle deploying assets for a game with a large amount of assets - <USER2> the player going to have to download 250MB of game textures and sounds into his cache every time he plays because you haven't done anything to cache them locally?

Toy demos like the one in the demo footage (<http://www.youtube.com/watch?v=gjLaNjkYnrI>) are basically only useful for demonstrating that it is possible to run toy demos. In the real world, you need to actually prove that you can run real games on your technology by running real games. It's all the more insulting that this toy demo seems to have repurposed assets from one of id's games in order to promote a product that these guys are trying to sell to you - I hope they got id's permisssion...

How about instead of trying to compare yourself to Unreal, you start with a lower target: Unity. Can you provide performance comparable to Unity across various target platforms, along with something approaching their ease of development and distribution? If you can't even compete with something as cheap/affordable as Unity on those points, then what is your unique value add that makes you a look? If the answer is nothing, well then, good luck - hopefully you have enough VC funding to burn that maybe you can be competitive before you run out of money.

EDIT: Oh, that's sneaky. If you dig into some of their documentation, it turns out that they _require a custom binary plugin_ to support some unknown subset of their feature list because 'browsers don't support them yet'. So this isn't even technically an HTML5 engine; it's more like a native engine with partial HTML5 fallback.

<comment><USER9> We did demonstrate real games using our technology, this is the presentation I gave at WebGL Camp Europe:

        http://www.youtube.com/playlist?list=PLF06FB93083F1D460

The demonstration at Develop Evolve was more business oriented.

All our tools and pipelines are explained and documented on our SDK, online docs at:

        http://docs.turbulenz.com

You are free to download the SDK and try it for yourselves, but we will try to provide more specific details in the future.

<comment><USER16> Thanks for the links to details. Which of those videos is a real game? I clicked through them and only saw one game demo and the speaker explicitly said it's 'just one car', so that's probably not the one you're referring to. Is there a specific video I should look at?

<comment><USER9> This one:

        http://www.youtube.com/watch?v=k2C5govjl5Y&list=PLF06FB93083F1D460&index=7&feature=plpp_video

I apologise for the darkness of the recording of the Quake 4 demo, we did another presentation at Develop - Evolve this morning that will show the demo in all its glory.

<comment><USER16> Thanks for the link. The Score Rush and Space Ark demos represent you much better, especially since they are by third-party developers (despite the poor video quality). Were they both running in pure WebGL under Chrome, or did they rely on your native plugin? I was unable to find any documentation on your site that actually explained what specific features require the plugin.

<comment><USER9> Everything run in pure WebGL. The sound used Web Audio (but we also support HTML5 Audio).

We do not demo anything running with the plugin any more.

Lack of WebGL support is the only reason to use the plugin. Now we also have a pure JavaScript 3D physics and collision solution (to be available on the next SDK release).</comment></comment></comment></comment></comment></comment>


Instagram 3.0 Bets Big On Geolocation With Photo Maps,  - <AUTHOR> http://techcrunch.com/2012/08/16/instagram-3-0-bets-big-on-geolocation-with-photo-maps-letting-you-showcase-the-story-behind-your-photos/ <comment><USER2> Techcrunch title is not representative of the matter. How is this "betting big"? It is just and additional feature. What are they exactly betting here?

</comment><comment><USER3> So this is a mash up of the iPhones places view of my pictures and what Color.com was originally trying to do.

Now we have a places photo-map of shared photos with the ability to filter stuff out...

Sounds interesting, and surely they will be far more successful than color.com was... But I don't yet know how useful this will be.

I am sure this will be mildly interesting for a long time... But it still doesn't solve my photo problem.

<comment><USER4> > But it still doesn't solve my photo problem.

Which is...?

<comment><USER3> I take a ton of pictures on my phone, Right now I have 3,946 pics on my phone and just this morning I had to delete some so I could take more.

I am not so interested in sharing the pics I take, though I do want that ability, but I need a superb way to organize the photos I take.

For example, in the last week I have take nearly 100 photos. Some of them are work, some are my kids, some are interest shots. I like to keep them all - some I want to have in a gallery (Madeline wearing glasses and a wig), others I want to write more about, like blog, others I want to keep in a bucket hierarchy of pics I take about the work I am doing.

I need a way to create these different buckets for my pics and choose for them to be public galleries, blog posts and categories.

Frankly, I think this is an avenue that IMGUR could go down. I have been a premium subscriber to IMGUR since it was available - and I love having them as a dumping point. But managing the galleries is sort of a pain, and I cant blog etc...

So, ultimately the company whom I feel is best suited to solve this problem for me is Dropbox.

I have uploaded all 3,946 photos to dropbox via the camera upload feature - and I have a monthly gallery - but now I want to do more with them - I want to tag them (Show me all pics of Madeline), blog about them etc...

So far - all the photo services provide me about 60% of what I really want.

Ill never put photos in Facebook (I don't have an account and never will) and this is another reason I am not happy with Instagram... but overall its about the fact that I don't feel anyone has made the killer photo management service.

</comment></comment></comment><comment> chris-allnutt All I can think of is this: <http://instaearth.me> an app myself and another guy wrote at the last company I worked for. View all your Instagram photo's geo-located on a map. It's nice to see Instagram finally integrating it with the app.

</comment><comment><USER5> Google Maps huh? Millions of views a day. I wonder how much that is going to cost Facebook. Way more than rolling out their own service, I'm sure. People expect Gmaps though.

<comment><USER6> I think Google maps API on iOS is free to use. Apple foots the bill for usage.

<comment><USER7> It's not free, it's just effectively free as long as you don't run up against Google Map's daily usage thresholds [1].

[1] [http://www.techradar.com/us/news/applications/software/after...](http://www.techradar.com/us/news/applications/software/after- ios-6-snub-google-dramatically-slashes-price-of-google-maps-api-1086816)</comment></comment></comment>


Making the Tokio scheduler 10x faster - <AUTHOR> https://tokio.rs/blog/2019-10-scheduler/ <comment><USER2> Author here. I'll be watching the comments and can answer any questions!

I do want to make clear that most of the optimizations discussed are implemented in the Go scheduler, which is where I discovered them. I wrote the article to call them out as they were not easy to discover.

<comment><USER3> The Go team is working on an update of its scheduler to make it preemptive. Will Tokio follow suit?

[https://github.com/golang/go/issues/24543](https://github.com/golang/go/issues/24543)

<comment><USER2> My understanding of that PR is it relates to how the Go compiler does code generation. Rust takes a different approach and is about to ship `async / await` which is a different strategy.

Preemption is out of scope for Tokio as we are focusing on a runtime to power Rust async functions. So, for the foreseeable, Tokio will using "cooperative preemption" via `await` points.

</comment></comment></comment><comment><USER4> I thought this was super interesting; it's great to see a solid writeup.

The consumer-side mutex works pretty well, until you take an interrupt while holding it; then, you need to make sure you're using an unfair mutex, or you'll get a lock convoy.

The non-blocking version isn't hard to write, though. IIRC, for the Windows threadpool, I used [https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues....](https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf) for the implementation.

I'm really impressed by the concurrency analysis tool; again for the threadpool, we used model-based-testing to write tests for every permutation of API calls, but we never got down to the level of testing thread execution permutations; that's amazingly good to see, and really builds confidence in their implementation.

<comment><USER2> Thanks! I agree with your assessment of the Mutex. Improving that is included in the follow up work.

I could have kept working on this for many more months... but my collaborators were starting to get grumpy and telling me to ship already :)

</comment></comment><comment><USER5> Tiny comment:

In "A better run queue" the second code block has

      self.tail.store(tail + 1, Release);

Should this not instead look like the following?

      self.tail.store(tail.wrapping_add(1), Release);

\---

Another comment:

> _The first load can most likely be done safely with Relaxed ordering, but > there were no measurable gains in switching._

This code is using an Acquire/Release pair, except it's Acquire/Release on different memory slots, which means there's no actual happens-before edge. This makes the Acquire/Release pair somewhat confusing (which tripped me up too in the first version of this comment).

Furthermore, I don't see anything in here that relies on the head load here being an Acquire. This Acquire would synchronize with the Release store on head in the pop operation, except what's being written in the pop is the fact that we don't care about the memory anymore, meaning we don't need to be able to read anything written by the pop (except for the head pointer itself).

This suggests to me that the head load/store should be Relaxed (especially because in the load literally all we care about for head is the current pointer value, for the length comparison, as already explained by the article). The tail of course should remain Release on the push, and I assume there's an Acquire there on the work-stealing pop (since you only list the local-thread pop code, which is doing an unsynced load here as an optimization). I don't promise that this is correct but this is my impression after a few minutes of consideration.

<comment><USER2> Ah thanks! You are correct! Perhaps you should also review the PR? (a tiny bit longer) :)

<comment><USER5> I'm not done with the article yet ;) (BTW I just updated my comment, not sure if you saw the first "another comment" addendum but I got it wrong and rewrote it)

If I have the time tonight I'll try to look over the PR. No promises though.

<comment><USER2> I saw your edit. Your summary of why `Relaxed` matches my reasoning. The code should probably be switched to `Relaxed`.

</comment></comment></comment></comment><comment><USER6> Awesome work!

FWIW: Hyper is among several that are bandwidth-limited by the 10-gigabit Ethernet in our (TechEmpower) Plaintext test. We hope to increase the available network bandwidth in the future to allow these to higher-performance platforms an opportunity to really show off.

<comment><USER7> This might be slightly off topic, but what are the others in this same space?

<comment><USER6> In the Round 18 Plaintext results that the OP linked to [1], you can see a pretty clear convergence at ~7 million requests per second, which I've screen captured in [2].

[1] [https://www.techempower.com/benchmarks/#section=data-r18&hw=...](https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext)

[2] [https://www.techempower.com/images/misc/converge.png](https://www.techempower.com/images/misc/converge.png)

<comment><USER8> How can you tell how each test is bottlenecked? Is it something as simple as saying that if the processor isn't at 100% utilization then the bottleneck is somewhere else?

I read a long time ago about how the linux kernel handled incoming packets in a really inefficient way that led to the network stack being the bottleneck in high performance applications. Is that no longer true?

I'd love to learn more about this whole area if anyone has any good links.

<comment><USER9> Well, to start with you can actually compute the optimal number of packets per second, if you know the bit rate and the packet size.

[https://packet.company/ethernet-statistics](https://packet.company/ethernet- statistics)

So the theoretical optimum is 14.88 Mpps (millions of packets per second). That's with the smallest possible payload. You need to divide that by two because the test involves both a request and a response, which gives you 7.44 million requests per second as the theoretical maximum.

The best tests max out around 7 M rps. This gives an implied overhead of about 6%, which corresponds to the HTTP overhead.

<comment><USER10> Why would you divide by two? Tx/Rx are separate.

<comment><USER9> You're right. But I assume the benchmark basically implements a ping-pong game instead of DoSing the server to see how many requests actually survive (I could be wrong).

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> You should sign your name under the blog post. So many references to "I" and I didn't know who to be impressed by until I clicked through to the PR.

</comment><comment><USER12> From a QA perspective, I feel like you buried the lede on this Loom tool. Benchmarks are nice, but confidence is an elusive thing when it comes to non- trivial concurrency.

I'll be spending some time on the CDSChecker and dynamic partial-order reduction papers.

<comment><USER2> True... correctness is very important! I made mention of loom for correctness in the intro at least.

The goal for this article was primarily to focus on scheduler design.

I'm hoping to get posts dedicated to loom soon. It's been an indispensable tool.

<comment><USER13> Yes loom seems very important. I would interested to know how it compares with similar tools like nidhugg[1][2] for the C and C++.

[1] [https://github.com/nidhugg/nidhugg](https://github.com/nidhugg/nidhugg) [2] [https://uu.diva- portal.org/smash/get/diva2:1324003/FULLTEXT0...](https://uu.diva- portal.org/smash/get/diva2:1324003/FULLTEXT01.pdf)

<comment><USER2> I skimmed the paper and it looks similar to loom. Specifically they cite CHESS and Cdschecker as prior art. Both of those are what loom is based on.

I guess 2019 is the year of concurrency checking :-)

</comment></comment></comment></comment><comment><USER14> Warning, since I've never written line of Rust code never mind working with Tokio I might be just full of it. If that's the case please forgive me ;)

From a short glance my understanding of Tokio is that at high level it is an execution environment that basically implements data exchange protocols based on asynchronous io.

Then they say the following: _Tokio is built around futures. Futures aren't a new idea, but the way Tokio uses them is unique. Unlike futures from other languages, Tokio's futures compile down to a state machine_

So the question here is why not to expose generic state machine framework (FSM/HSM) which can deal with those protocols but is also very useful for many other tasks as well?

<comment><USER2> > So the question here is why not to expose generic state machine framework > (FSM/HSM) which can deal with those protocols but is also very useful for > many other tasks as well?

Short answer is: you can.

Tokio is more like "node.js for Rust" or "the Go runtime for Rust".

The bit about Tokio & futures is how you use Tokio today. Tasks are defined as futures, and Rust futures are FSMs. So, a protocol can be implemented as a FSM completely independently of Tokio / futures and then used from Tokio.

In Tokio's next major release (coming soon), it will work with Rust's async fn feature (which is also about to hit stable).

Hope that clarifies things.

<comment><USER14> _So, a protocol can be implemented as a FSM completely independently of Tokio / futures and then used from Tokio_

But that was the point of my question. Since you've already built that FSM framework inside, why not to expose it? Or I guess it might be too specialized for your particular case.

<comment><USER2> Ah, all the helpers around the "FSM" aspect of things are already exposed as part of the `futures` crate: [https://github.com/rust-lang-nursery/futures- rs/](https://github.com/rust-lang-nursery/futures-rs/)

<comment><USER15> Which is different than the standard adopted `std::futures`?

<comment><USER16> Not quite. The futures crate, version 0.1, contained a definition of the `Future` trait and a bunch of the combinator methods. This was iterated on a lot. Eventually, the bare minimum traits were added to the standard library.

The futures crate, version 0.3 (released under the name `futures-preview` right now with an alpha version number), contains the helper methods for the standard library's trait.

<comment><USER17> Just the bare minimum traits required for built-in async/.await, right?

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Even though I don't use Rust myself, I still admire the Rust community for the awesome technical blog posts they produce all the time.

<comment><USER2> Thanks! I appreciate it.

</comment></comment><comment><USER19> Thank you for posting articles like these. I feel a bit relieved seeing how its not demigods with decades of in-domain experience who create sometimes huge, monumental modules or building blocks of whole languages, but instead: actual human beings who might have been short on options, time or bought into some technical debt in the process of creating something useful.

</comment><comment><USER20> First of all, great article! Lots of interesting details and great explaination.

A few questions:

Did you consider work sharing or work requesting instead of work stealing (the global queue is a form of work sharing of course)? With work requesting you can avoid the required store/load on the pop path. Of course work requesting is not appropriate if the scheduler need to protect against the occasional long running job that doesn't yield to the scheduler in time to service a work request with appropriate frequency, but assuming this is rare enough, an expensive last resort work stealing path could be done via asymmetric synchronization (i.e. sys_membarrier or similar), keeping the pop fast path, well, fast.

Is there any way to make (groups of) tasks be constrained to a specific scheduler? This is particularly useful if they all need to access specific resources as there is no need of mutual exclusion; this works well in applications were executors are eterogeneous and have distinct responsibilities.

Because of the global queue and the work-stealing behaviour, absolutely no ordering is guaranteed for any task, is that correct?

I find surprising that you need to reference count a task explicitly. Having implemented a similar scheduler (albeit in C++), I haven't found the need of refcounting: normally the task is owned by either a scheduler queue or a single wait queue (but obviously never both). In case the task is waiting for any of multiple events, on first wake-up it will unregister itself from all remaining events (tricky but doable); only in the case were is waiting for N events you need an (atomic) count of the events delivered so far (and only if you want to avoid having to wake up to immediately go to sleep waiting for the next event). Also this increment comes for free if you need an expensive synchronization in the wake-up path.

That's all so far, I'm sure I'll come up with more questions later. Again great job and congratulations on the performance improvements.

<comment><USER2> > Did you consider work sharing or work requesting instead of work stealing

Not really. It did cross my mind for a moment, but my gut (which is often wrong) is the latency needed to request would be much higher than what is needed to steal. I probably should test it though at some point :)

> assuming this is rare enough, an expensive last resort work stealing

It's not _that_ rare. Stealing is key when a large batch of tasks arrive (usually after a call to `epoll_wait`). Again, I have no numbers to back any of this :)

<comment><USER20> The idea is to steal only if request fails to return work in a reasonable time frame i.e. if a job is keeping the scheduler busy for more than a minimum amount of time.

I also have no number to back it up (we deal wit a relatively small numbers of fds at $JOB and we care of latency more than throughput), but I do not buy epoll_wait generating late batches of work: it seems to me that you should only be using epoll for fds that are unlikely to be ready for io (i.e those for which a speculative read or write has returned EWOULDBLOCK), which means you should not have large batches of ready fds. Even if you do, the only case you would need to steal after that is if another processor run out of work after this processor returned from epoll wait (if it did before, it should have blocked on the same epoll FD and got a chunk of the work directly or could have signaled a request for work), which might be less likely.

Anyway at the end of the day a singe mostly uncontested CAS is relatively cheap on x86 especially if the average job length is large enough, so maybe it is just not worth optimizing it further, especially if it requires more complexity.

</comment></comment></comment><comment><USER21> Howdy, I'm not familiar with Tokio (or Rust much). Is Tokio sort of like Node for Rust (packaged as a library rather than executable)?

Or maybe more like Scala Akka Futures?

<comment><AUTHOR> Rust, as a systems language, doesn't include a large runtime. It's about the same size as C or C++'s. But if you want to do asynchronous IO, you'll need a runtime to manage all of your tasks. Rust's approach is to include the interface to make a task (futures and async/await) into the language and standard library, but lets you import whatever runtime you'd like. This means that you can pull in one good for servers, one good for embedded, etc, and not be partitioned off from a chunk of the ecosystem. And folks who don't need this functionality don't have to pay for it.

Tokio is the oldest and most established of these runtimes, and is often the basis for web servers in Rust.

So yeah, "the node event loop as a library" is a decent way to think about it.

<comment><USER15> > Rust's approach is to include the interface to make a task (futures and > async/await) into the language and standard library, but lets you import > whatever runtime you'd like.

Why is this better than having one official, standardized, optionally importable runtime?

<comment><AUTHOR> Each point has something different:

1\. official - it's not clear how this would be better; that is, the team is not likely to have more expertise in this space than others do

2\. standardized - it is standardized, as I said, the interface is in the standard library

3\. optionally importable - this is fine, of course, but so are these, so this attribute isn't really anything better or worse.

But I don't think this is the biggest strength of this approach, the big strength is that not everyone wants the same thing out of a runtime. The embedded runtimes work very differently than Tokio, for example. As the post talks about, it's assuming you're running on a many core machine; that assumption will not be true on a small embedded device. Others would develop other runtimes for other environments or for other specific needs, and we'd be back to the same state as today.

</comment></comment></comment></comment><comment><USER22> Oh man, I really wish ya'll had chosen a name other than "Loom" for your permutation tool. Loom is also the name of a project to bring fibers to the JVM.

</comment><comment><USER23> Really cool. Tokio is the core of Linkerd ([https://linkerd.io](https://linkerd.io)) and I am really excited to see exactly what kind of impact this will have on Linkerd performance. A super fast, super light userspace proxy is key to service mesh performance.

</comment><comment><USER24> Also it would be interesting to have a benchmark to compare different approaches to multicore e.g. [https://parsec.cs.princeton.edu/overview.htm](https://parsec.cs.princeton.edu/overview.htm)

</comment><comment><USER25> The result is pretty impressive. Go's scheduler is not this good. When my Go GRPC servers get up near 100,000 RPS their profiles are totally dominated by `runqsteal` and `findrunnable`.

<comment><USER26> Weird. In one of my Go explorations I wrote a naive trade algo backtracker which ingested 100,000 datapoints per second from SQLite on commodity hardware.

I'd expect something highly specialized such as GRPC server to perform better.

<comment><USER25> Reading 100k rows per second from sqlite sounds WAY easier than serving 100k HTTP/2 queries in the same time.

<comment><USER26> True. But in my case the code also distributes these datapoints to multiple threads, computes technical indicators and simulates tradings while gathering statistics to finetunne parameters.

The only optimization I've done was to ditch maps wherever I could. They were dominating flamegraphs.

This is why I expected GRPC to perform better. But I agree it depends heavily on what's being done.

</comment></comment></comment></comment><comment><USER27> Does anyone know how to print the blog post. Storing it as a pdf only saves first page, not the entire conent.

<comment><USER28> If you enable readability mode in Firefox first, the entire article shows up in the PDF.

</comment></comment><comment><USER29> _" Many processors, each with their own run queue"_

 _" Because synchronization is almost entirely avoided, this strategy can be very fast. However, it's not a silver bullet. Unless the workload is entirely uniform, some processors will become idle while other processors are under load, resulting in resource underutilization. This happens because tasks are pinned to a specific processor. When a bunch of tasks on a single processor are scheduled in a batch, that single processor is responsible for working through the spike even if other procesors are idle."_

The trade off of this is high performance over uniform utilization, which is a better goal than loading cores evenly. And all you have to do to make use of it is a bit of thought about your load distribution, but you also have plenty of thought budget here by not having to think about synchronization. Stealing work from other queues is not going to be faster, it's going to be wasted on synchronization and non-locality overhead and would require you to do synchronization everywhere, not a good direction to pursue.

<comment><USER30> Other parts of the Rust ecosystem have had great luck using work-stealing queues. There's a talk about how Rayon did this[1] and a good article about using it in Stylo[2], a new CSS engine written by Mozilla.

[1] [https://www.youtube.com/watch?v=gof_OEv71Aw](https://www.youtube.com/watch?v=gof_OEv71Aw)

[2] [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css- en...](https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine- quantum-css-aka-stylo/)

<comment><USER31> The thesis of Practical Parallel Rendering was that any useful task distribution strategy requires a work stealing mechanism because you are leaving serious amounts of responsiveness on the table if you don't.

With an infinite queue, the same number of tasks per second happen either way, but the delay until the last task you care about finishes can be pretty substantial.

</comment></comment></comment><comment><USER32> Does this new scheduler require a dedicated thread pool for CPU intensive futures, as the current scheduler does?

(Thank you for your hard work on Tokio!)

<comment><USER2> Thanks, I appreciate it!

The new scheduler will still require using a special API to run CPU intensive futures: `tokio_executor::blocking::run(|| cpu_intensive())`

</comment></comment><comment><USER33> Thank you for the detailed write up!

Why are their many processors? If it's all one thread, why not just use one processor?

<comment><USER2> There is one processor per thread.

Sorry, the article must not have been clear. If you can point out where in the article you got the impression there were multiple processors per thread, I can try to update the article to fix.

<comment><USER33> I just got a bit into the "One queue, many processors" section and that's where I got confused. Knowing it's one processor per CPU is the information I needed. Thanks!

<comment><USER2> From that section.

> There are multiple processors, each running on a separate thread.

It's probably easy to miss, do you have thoughts on where else this can be clarified?

</comment></comment></comment></comment><comment><USER34> Not to be snarky, but the easiest way to get a 10x speedup is to make the previous one 10x too slow. 10x feels pretty good until you find out it was really 40x too slow. I say this only because getting 100x improvements on naive designs has led me to be suspicious of 10x improvements. The principle is that where 10x was available, more is there.

The writeup doesn't mention design choices in Grand Central Dispatch. Is that because we have moved on from GCT, or because it's not known?

<comment><USER35> You should look at the http server benchmarks before writing this.

Hint: tokio based web servers are the fastest.

<comment><USER34> Getting downvoted for asking a serious question tells me all I needed to know.

<comment><USER35> I wasn't downviting you, but I'm sure it was the first part of your comment with unchecked facts, not your question that got you downvoted.

<comment><USER34> There were no unchecked facts in the original post. It is a fact that I have got 100x speedups, and it is my personal experience that 10x speedups rarely come close to exhausting the opportunities.

It is a fact that I did not notice any reference in the article to GCD or the techniques that have made it a success.

<comment><USER34> Clearly the facts are not the problem. My guess would be that Rust fans are unusually thin-skinned. Let us see...

In the meantime, it would not hurt even Rust fans to learn more about how Grand Central Dispatch works.

<comment><USER36> You might suggest specific GCD mechanisms that might be usefully adopted by tokio.</comment></comment></comment></comment></comment></comment></comment>


NBA will consider shortening games due to millennial attention spans - <AUTHOR> http://www.usatoday.com/story/sports/nba/2017/01/13/nba-shortening-games-millennial-attention-spans/96535434/ <comment><USER2> The meat of the article is about the flurry of timeouts you get late in a close game, which have never not been incredibly boring.

</comment><comment><USER3> This title is so funny! I ll not even read the article, it made my day.</comment>


Nodejs: Fast, disk space efficient package manager: pnpm - <AUTHOR> https://pnpm.js.org <comment><AUTHOR> ### Features:

\- Fast. As fast as npm and Yarn.

\- Efficient. One version of a package is saved only ever once on a disk.

\- Deterministic. Has a lockfile called shrinkwrap.yaml.

\- Strict. A package can access only dependencies that are specified in its package.json.

\- Works everywhere. Works on Windows, Linux and OS X.

\- Aliases. Install different versions of the same package or import it using a different name.

Edit: formatting</comment>


You don't need a problem-solving idea - <AUTHOR> http://www.vusal.me/essays/ideas/

<comment><USER2> This is a bit of a bait and switch, because all of the options the author lists are solving problems (even if just improving upon existing solutions, you are still solving sub-problems of existing solutions). Instagram readily solved a problem: photo editing / stylizing had been difficult and/or expensive prior (yes, I hate their filters as much as the next guy, but most people find some value in it). It may have not been the first app to do it, but it still solved a problem.

<comment><USER3> I think the author means that people shouldn't look for just for problems that aren't solved yet like pg wrote, but also problems that are solved but needs some tweaks. Of course every startup means a new solved problem.

<comment><USER4> +1 same here. I like the 2nd kind of ideas. Tweak it and voila! You have a better product and you know that you can sell it.

</comment></comment></comment><comment><USER5> _Because most of essential problems are already solved, you can only find solutions for unsolved small problems that interests only small group of people._

I disagree. Some huge problems remain unsolved because they are big beasts to tackle. Education, for example, is ripe for disruption, and while there have been some advances (Khan Academy, Edx), we have a long way to go before you can get a respected degree online.

</comment><comment><USER6> For the last paragraph, I should add that Yandex was founded before Google. <http://en.wikipedia.org/wiki/Yandex> It is not an application of a global idea.</comment>


This Transgenic Rice Could Prevent HIV Infections - <AUTHOR> https://labiotech.eu/medical/hiv-prevention-transgenic-rice/ <comment><AUTHOR> What does this mean for resistance against antibiotics?

This study says that resistance against microbicides might transfer to resistance against antibiotics: "Microbicides – The Double‐Edged Sword: Environmental Toxicity and Emerging Resistance"

[https://onlinelibrary.wiley.com/doi/abs/10.1002/978111842583...](https://onlinelibrary.wiley.com/doi/abs/10.1002/9781118425831.ch11)</comment>


Ask HN: Need career advice facing burnout? - <AUTHOR> I can't seem to work 5 days a week, somedays I wake up and just decide I rather take a vacation or sick day than show up.
I just don't know how to cope.
Please advise on how you handled workplace burnout?
Thanks <comment><USER2> 1\. Take a long vacation. Spend some time talking to friends.

2\. Figure out what you _do_ want in a job. Personally I quite enjoy working, if it's the right work. But I still don't want to work 40 hours a week, so I work less when I can.

3\. Try to get whatever it is you realized you want. (If shorter working hours turns out to be your thing, I've written a book about it: [https://codewithoutrules.com/saneworkweek/](https://codewithoutrules.com/saneworkweek/)).

This is also probably a good time to make sure you have lots of savings, in case you hit the point where you _can 't_ work and you have to quit without a plan.

</comment><comment><USER3> Can you pivot and try to do something different within the same industry? Assuming you are currently working as a developer, try your hand at management / project management / sysadmin / etc? Working in a different aspect of the field you know well has worked for me in the past to help keep things fresh.

Alternatively, you might just need a break to give your head a rest. How long have you been in your current job?

<comment><AUTHOR> Im paid as a developer, but do mindless work that doesnt relate.

Also, Ive been at my job for about a year and a half.</comment></comment>


Secret developers of the video game industry - <AUTHOR> http://www.polygon.com/2015/9/30/9394355/the-secret-developers-of-the-video-game-industry <comment><USER2> Crediting is a much larger issue than just what's referred to in the article.

I worked on a title for ~3 years, many of those being 6-8 months of 75-100hr weeks. Saw marriages destroyed on that project, people pushed to the edge.

I left ~4 months before ship because I knew if I didn't it would be the end of me. Twice I blew the stoplight in front of our house because I was so exhausted. Yet it was insinuated that I didn't work hard enough since I came in the office at 8am and left at 10pm(everyone else left 12am-2am).

You want to know what I was credited as?

"Special Thanks"

That and many other reasons is why you'll see the game industry burn through talent. I've never seen a collective of some of the sharpest, creative people I've ever worked with exploited to such a degree under the misplaced reason of "Passion".

The place I worked before then was very much white-label, with very similar issues and working conditions. I think we did get the studio logo on the back of the box but there was a very clear agreement where no logos could be placed in-game.

<comment><USER3> The games industry has a worker abuse problem.

All those companies proudly talking about their 18 months of crunch? Nooooope, shouldn't happen. This shouldn't be a thing you're proud of. You shouldn't be proud of your employees for slaving to death on those projects.

It's very tough. Compared to the "regular" tech industry, people in video games can be _so_ passionate about what they're making. It almost seems comparable to founding a startup, except you're just an employee working on a project.

You, reader, wherever you're working: Imagine if every single member of your team was _incredibly_ passionate about the work they do. They are building their own baby. They have the vision, they have the motherly drive that puts the existence of their baby ahead of their own. You can see how that could be abused by companies?

It's possible to be passionate without driving yourself crazy like that, but in the video games industry it's far too common and it becomes the norm. In fact, I was going to post about this a few minutes ago - and then you yourself described the problem better than I could.

Credit in your story is not the issue. The 8 months of 100 hour weeks is.

<comment><USER4> When I was young, I was in the simulation industry in Orlando and the game industry was taking off there. Tiburon, who would become part of EA later, was snapping up the young simulation talent, in the area and I had an offer to move over. That was the day I decided that web development did not look like that bad of a tradeoff. Game dev was a cut in pay from simulation salaries, which where already well under web dev salaries and the work days my friends where pulling bordered on the insane, crunch mode for 12 months or more with no ownership stake.

Now I was young at the time and had no issue with a long day, I ended up in a startup, pulling similar hours but I had a small stake in ownership. My friends that did go into the field, on the other hand, have very fond memories of the work (similar to soldiers in battle trying to pull off a heroic effort) but they have a lot of regrets overall for entering the industry and feel that they have been damaged as an employee after they inevitably became disillusioned as happens when you life goals of your 30's and 40's start to materialize.

Simply put, the game industry has an almost inexhaustible supply of young bright talent that are falling over one another to get a break in the industry. My nephew being one of them, I literally staged an intervention with him and asked him to talk to several of my friends that left the industry. But he is young and cannot see past his 20's so he is well on his way in the industry. His college girlfriend just split on him over the hours, as she wants to go out and be 20 something, but that has not rocked his confidence in maintaining course in the industry. It is unfortunate, a lot of bright kids get sucked down that hole, I am thankful I was not.

</comment></comment></comment><comment><USER5> Not to derail an otherwise interesting article, but the OP picked a not-great anecdote to lead with. The Red Ash Kickstarter was controversial because it was launched by the studio that was (and _is_ ) behind a high-profile Kickstarter: Mighty No. 9, a game billed as the spiritual successor to Mega Man which raised $3.85M. At the time that Red Ash was announced, Comcept claimed that Mighty No. 9 was pretty much done and that they needed to get another game into the pipeline. Midway through the Red Ash campaign, people noticed that Mighty No. 9 was marked by retailers as being delayed. When Comcept was questioned about this, they claimed that it was a mistake...only shortly after the Red Ash Kickstarter failed did Comcept admit that Mighty No. 9 would be delayed [1].

As you can imagine, that led backers to think that Comcept had tried to be hush-hush about the delay so that it wouldn't affect the Red Ash campaign. It hasn't helped matters since then that Mighty No. 9 continues to be delayed, even failing to meet a deadline to produce a demo that was meant to make up for the delay.

So...to use Comcept in the lede of this story, as if it were the use of these "secret developers" that pissed fans off and caused the Kickstarter to fail...That just seems...a bit misguided...The OP couldn't find any other anecdote to lead off with?

[1] [http://kotaku.com/the-story-behind-mighty-no-9s-shady- delay-...](http://kotaku.com/the-story-behind-mighty-no-9s-shady- delay-1722766843)

<comment><USER6> What makes you think there was only one thing that made fans upset? The OP links to a concerned fan, as well.

</comment></comment><comment><USER7> It's interesting to hear more about the video game industry insides.

I wonder if id's success helped start this atmosphere. (Read masters of doom)

They were portrayed as rockstars, friends, who busted ass and made a popular game which made them all rich.

I fell for that idea when i was young, luckily i never got into the industry. I later read some blog post of an EA developer's wife or something, going on and on how much he had to work and wasn't compensated for it, etc.

<comment><USER8> I love Masters Of Doom, it's one of my favourite books (make of that what you will). But I guess the main difference is that the id guys were pushing boundaries and working themselves to the bone on something they truly loved and felt passionate about. It was self-imposed and unlike the hordes of faceless developers working in sweatshop conditions to churn out the latest CoD or whatever, they actually received a huge amount of credit (and the fame and fortune that goes with it) for their hard work.

I agree, there's definitely this romanticised image of game development in the developer community. It's something I always aspired to get into but the sacrifices don't seem to be worth the rewards, at least in my case.

<comment><USER9> That's a bad example. I'm sure the CoD developers generally think they're making some of the best games ever, and they have the sales figures and the plaudits to prove it. Gamers like to sneer at CoD, but I'm certain there's a lot of care and enthusiasm that goes into each iteration. It just gets sneered at harder than a lot of games, because it's perhaps overpopular for what it is.

The people making uber-cynical cash-milkers at Zynga or King, or those German shovelware job-simulator games with Microsoft-style trade dress are likely far more likely to fit your description than some blockbusting AAA bestseller like CoD.

</comment></comment></comment><comment><USER10> Related and interesting: the IGDA's guidelines on credits: [http://c.ymcdn.com/sites/www.igda.org/resource/collection/6C...](http://c.ymcdn.com/sites/www.igda.org/resource/collection/6CD37C4B-C8E6-42BB- AC7B-E5A52615F622/IGDA_Game_Crediting_Guide_Draft_9-2.pdf)

<comment><USER11> It's particularly interesting to this conversation because it has no teeth. IGDA is hope and a dream. It took real unions a lot of hard work to get movie credits to accurately credit people. Presumably it would take the same for games.

</comment></comment><comment><USER12> It's not easy for indies, either [http://gamasutra.com/blogs/QuantumPotato/20150928/254690/iOS...](http://gamasutra.com/blogs/QuantumPotato/20150928/254690/iOS_Game_Discovery_is_Broken.php)

(Disclaimer, I work with for poster's company)

</comment><comment><USER13> How cute. Sometimes you don't appear on credits. I have been working with more than 100 people on 2.9 millions of real-time safety critical code for nearly a decade. It has been unknowingly used by millions of people around the world and there will never be any recognition for any of us. Grow up.

<comment><USER10> In a few industries, for industry-specific reasons, who appears on credits and the _exact_ contents of those credits actually does matter for career advancement purposes. Video games are one of those industries. Film and academia are two others. It is _critically important to your future_ if you're an assistant professor or software developer working on the 3-D engine that your work get recorded in the industry-standard manner. It is difficult to appreciate this if you're not in academia, but getting your name listed first (and not second!) in the paper edition of a magazine that no one reads is actually _really important_.

Many of the rest of us work in industries without this professional norm. That's wonderful for us, but does not itself fix the problems of this norm for people affected by it.

<comment><USER14> There is no industry-standard record of credits in the games, JFYI. Mobygames is a good collection of crowd-sourced info, but it is far from being comprehensive (even major AAA games and/or their credits can be missing). Without a proper record credits cannot be that _critically important_ and they are not from my experience. Nobody is going to find the games you said you have been working on and play them through to get to the credits to verify. Your experience is supported by references (formal and otherwise) and your portfolio if you are an artist or a designer. Credits are just bragging rights.

Now, if there had been some kind of official record then credits might have had a bigger weight but, with a lot of people's experience being in unfinished/cancelled projects, still it would not reach the level of _critical importance_ IMHO.

<comment><USER15> _There is no industry-standard record of credits in the games_

No, but that doesn't mean people don't use it as hiring critera. Some software companies use github profiles to screen candidates. Open source contributions in general, and github in particular are a comically inept way of evaluating candidates, even in comparison to credits. But it still happens.

<comment><USER14> It sure does not. People are free to use whatever criteria they want for hiring. Even illegal ones would be impossible to prove as long as they are not advertised. But neither this nor the fact that some companies outside the games use github as a criterion proves that credits are important. What you can do is important. What you have already done is too. Credits in movies and academia are an expression of these things. They are not in the games though.</comment></comment></comment></comment></comment>


Think small: Less red tape, and more red carpets for European entrepreneurs. - <AUTHOR> http://thenextweb.org/2008/07/14/think-small-less-red-tape-and-more-red-carpets-for-european-entrepreneurs/

<comment><USER2> This is great news. There's a tremendous amount of potential in both the blue banana and the hot banana. As someone's who's dream it is to work for a startup located near the intersection of the two bananas, I very much hope the Mediterranean can California some competition.</comment>


America's Genius Glut - <AUTHOR> http://www.nytimes.com/2013/02/08/opinion/americas-genius-glut.html

<comment><USER2> This is so mistaken. How could anyone not notice there is a talent war happening in Silicon Valley? The single biggest problem facing just about every one of the most successful startups we've funded is finding more good programmers.

And I know many startups that are eager to get visas for people they want to hire, and would have zero interest in having employees that felt trapped at their company.

(I had to go and investigate what the Economic Policy Institute was. Apparently it's funded by a consortium of labor unions. Odd that they would bother about this, since few to none of the jobs involved are union jobs.)

<comment><AUTHOR> I was shocked to read this as well. This summer I went to meetups where after talking with somebody new for five minutes, they would say, "By the way, we're hiring...", to which I would reply, "Yeah, so are we!"

About half of my classmates (in a Statistics PhD program) are foreigners. These are literally the brightest statisticians of their year from their respective countries, and making it even the least bit hard for them to stay in the US is a big mistake. We could use their talent!

<comment><USER3> > About half of my classmates (in a Statistics PhD program) are foreigners. > These are literally the brightest statisticians of their year from their > respective countries, and making it even the least bit hard for them to stay > in the US is a big mistake. We could use their talent!

What makes you think they are going to have a hard time to stay in the U.S.? Honestly if they are good, literally stapling a green card to their PhD once they graduate is the only thing that is going to be easier than the current system. Let me explain: You finish your PhD, you can work for a period of 27 months for any related employer under your F1 visa, then you can work for a period of 6 years on an H1B. While this is happening, your employer can file for a Green Card for you. Hell, if you are "literally the brightest statisticians of their year", you can apply for a Green Card as a person of extraordinary ability.

<comment><USER4> As explained almost everywhere, losing your job under an H1B visa is a huge pain.

The brightest student in my class is working for Microsoft on an H1B. He's relatively happy and he's managed to "switch jobs" within Microsoft, but he's unable to leave.

That's not a great way to encourage the best and brightest. I know this guy would be awesome for several Silicon Valley startups for example, but he literally has to stay in Microsoft or another high-stability company.

No idea if he would get a Green Card as a person of extraordinary ability, I believe him to be, but don't know the requisites.

My country has FAR less stringent requirements (yet we're not really a talent destination :) ).

<comment><USER3> > As explained almost everywhere, losing your job under an H1B visa is a huge > pain.

This is exactly my problem with the H1B. The solution to this is not to have a glut of more H1Bs but to make the H1B a job portable six year visa much like a European employment visa.

</comment></comment></comment></comment></comment><comment><USER5> I wonder if more bright engineers would actually solve SV's labor problem? Startups are like lotteries and engineers are their customers. A certain percentage of engineers are going to want to start their own lotteries rather than play someone else's. Increasing the number of engineers won't change that percentage. Currently, these "lotteries" don't have a great payout and unsurprisingly, they have a difficult time finding "customers".

Currently these "lotteries" are unwilling or unable to increase their payouts. Unless you can create a glut of customers/engineers that are somehow constrained from starting their own lotteries, I don't see why the lack of engineers willing to work at startups would change.

It's a little like complaining that "we can't find interns willing to work for free" when the interns have better alternatives.

<comment><USER3> This is an excellent point. There are enough engineers out there who reach a certain stage in their life (kids, family, bored of stupid "benefits" like xbox, free lunches and worthless stock options) basically say fuck you, pay me. It is not that startups can't find people at any price, it is just that really really good people could work on your interesting problem but they could also work on another interesting problem that pays them a market rate.

> Currently these "lotteries" are unwilling or unable to increase their > payouts. Unless you can create a glut of customers/engineers that are > somehow constrained from starting their own lotteries, I don't see why the > lack of engineers willing to work at startups would change.

I don't know whether you made this point unknowingly or not: However, the whole deal with the way an H1B is designed right now is that it is close to impossible to start your own lottery. You have to sponsor your own visa which the way nascent startups work is close to impossible.

</comment></comment><comment><USER6> This article seems to confuse degrees with "genius". It's mostly just toil and it's not surprising people fearing deportation are better motivated to acquire them and less choosy about jobs they take.</comment>


Show HN: Catapulty, utility for when you design cross-browser - <AUTHOR> http://catapulty.com/

<comment><USER2> Better explanation at the top would be nice. Something like:

"Tired of designing for 10 browsers and needing to copy and paste the site's URL to each one? Here are two simple bookmarklets will make it a snap."

I had to come back to Hacker News to actually figured out what it did!

<comment><AUTHOR> Nice spot, I can see now it was hard to figure out what on earth the app does, wish I'd realised, feel pretty stupid.

So big thank you for the feedback, I've updated the text based on your suggestion:

"Are you a cross-browser coder tired of copying the same URL into 10 different browsers? Then Catapulty's bookmarklets are here to help you…"

</comment></comment><comment><USER3> Neat idea, good work. Does it work by matching IPs?

Would be awesome if this worked browser <\--> iPhone.

<comment><AUTHOR> Thanks cj. Spot on about IP matching. Took a little while to figure out how to get the client IP on Heroku, write up here: [http://catapulty.tumblr.com/post/8303749793/heroku-and- node-...](http://catapulty.tumblr.com/post/8303749793/heroku-and-node-js-how- to-get-the-client-ip-address)

About browser <\--> iPhone, it'll work if your phone has the same IP as your browser, this might happen if your phone is using your home WiFi. Getting the bookmarklets into your phone might be a bit trickier and require some manual editing of bookmarks. Would be good to come up with a nice way of getting the bookmarklets onto phones.

To avoid the requirement of same IPs, I guess that'd require a way to create and identify an account on Catapulty. If that looks like it'd be useful I'll add that in.

</comment></comment><comment><AUTHOR> Weekend project to save ctrl+c/v-ing addresses when coding cross-browser support. Would love any and all feedback.

</comment><comment><USER4> Great tool, thank you!</comment>


Facebook gets closer to letting you type with your mind - <AUTHOR> https://edition.cnn.com/2019/07/30/tech/facebook-mind-reading-research/index.html <comment><USER2> Previous submission with comments:

[https://news.ycombinator.com/item?id=20566499](https://news.ycombinator.com/item?id=20566499)

</comment><comment><USER3> Just to point out (again) that you don't need fancy equipment to do this. Connecting electrodes to the brain is unnecessary. Some simple external sensors† and hypnosis and you're good to go.

The basic idea is to set up simple binary signals between your unconscious mind and your sensors. This is trivial.

Then you can take e.g. eight data plus one clock and gang them together to make a simple parallel port between your brain and the computer. Easy. (The obvious thing to do is use eight fingers plus a thumb.)

The brain is already a hugely sophisticated information processing device. The problem is not to get the raw signal out of it and then decipher it. That's just pushing sideways on the train. Just use simple hardware and let the brain do the pre-processing to get legible signals (with the subjective perception of direct mind-to-screen typing, say.)

†Galvanic skin response, or these days use little IMUs in gloves to detect twitches. The signals you're generating are not subtle. Another thing, the brain already has a high-bandwidth output device: the face. These days it should be trivial to train a NN to read expressions and "micro-tics" from e.g. some HD cameras trained on your face, and co-evolve a protocol between mind and machine.

\- - - -

Edit to add, you guys have seen "Forbidden Planet" right? Take heed of the fate of the Krell, design your tools well, raise no "Monsters from the Id"...

<comment><USER4> Much of these can be done via EEG sensors.

</comment></comment><comment><USER5> >Machine learning algorithms eventually determined how to spot when participants were answering a question and which one of the 24 answers they were choosing

Seems like it might be a bit of an overstatement to say that Facebook is close to anything of the sort. Assuming that neural typing is as simple as running some real-time classification algorithm on brain states, to predict words correctly you'd have to be able to predict about tens of thousands of different possibilities. Not to mention the more difficult problem of individual idiosyncrasies in neural architecture and language embeddings for any given brain. Building a word classifier for a single brain is one thing, but I doubt if any two brains process language in the exact same way, so building some general-purpose classification model that works on all brains still seems intractable with current ML techniques. It's a nice start, but I think we're a long way from fully automatic neural typing.

</comment><comment><USER6> hmmm [https://www.youtube.com/watch?v=jroQCyWwEgE](https://www.youtube.com/watch?v=jroQCyWwEgE)

<comment><USER7> You just know there's some $30,000 voice activated potato cannon stuffed in a Menlo Park basement...

</comment></comment><comment><USER8> Appreciate this a lot. Cousin is disabled and can't speak enough for voice software nor use the computer but is a smart guy. Would open so many doors if this works.

</comment><comment><USER9> I can already type with my mind. I had my brain internally wired to a pair of biomechanical "limbs" with graspers on the end that just happen to interface with a standard keyboard really well. I trained a neural net to run the setup, and since then it's served my needs very well. Granted, some of the inner workings are mechanical rather than electrical, but I can already type faster than I can think.

</comment><comment><USER10> Why would anyone want that? People never post what they really think on Facebook...unless of course they write without thinking enough.

</comment><comment><USER11> Facebook gets closer to reading your mind. FTFY.

</comment><comment><USER12> > Facebok

It's funnier when they don't proofread.

</comment><comment><USER13> So, eventually more completely unfiltered stream of consciousness posting? What could possibly go wrong?

</comment><comment><USER14> One step closer to stopping wrongthink.

</comment><comment><USER15> Hard pass. There is not one good argument why Google or Facebook of all companies should be in charge of this technology.

I am all for advancing technology, but not by all means and not at all costs. Advertising companies (with a bad track record nonetheless) being the first to gain from this kind of technology is reckless at best, and dangerous at worst.</comment>


Cracking the puzzle of automated low-cost malaria diagnosis - <AUTHOR> https://twitter.com/PrakashLab/status/1144453714637230083 <comment><USER2> I just did a quick visual scan of the PDF. Some parts have to be fabricated. _Custom parts of the microscope were designed with Autodesk Inventor Professional and 451 fabricated by Protolabs and 3D Hubs..._ I do not think this is open source. At least I do not find a link to the file.

 _The measurement results were 465 saved as CSV files and processed with MATLAB_ There are open source MATLAB alternatives.

Great project. With effort it could be reverse engineered, but links to all the required files would make it far easier.

<comment><USER2> Seems the title of this post has changed since I first commented (it had referenced open source). Still, it would be nice to see all the design an operational files involved.

</comment></comment><comment> d-sc I've worked on $100k devices that are used for research. I believe there's a good future for this type of work. Most of what makes those devices expensive is the R&D that goes into them, not the production costs.

<comment><USER3> That is somewhat true but there are some fixed costs that cannot be easily brought down.

1\. Optics- especially when you start talking 63x (looking at internal cell structures) color corrected objectives are generally going to run around 10k, there is really no way around that. A microscope like the one shown here (and the GRIN lens miniscopes used in brains recently and the ball lens microscopes) don't require as good optics as they aren't imaging at super high resolution and color misalignment won't hurt them.

2\. The camera chip/housing/frame grabber- Generally the actual chip is pretty low cost. But the system to cool and grab a lot of frames really fast is pretty expensive. The rates of commercial cameras-120 FPS at their highest, is completely insufficient for a research machine. Also the sensitivity of an 'off the shelf' camera is not going to be appropriate for a research machine. These costs hold these cameras around 5-10k. This project doesn't require these systems because they are looking at whole cells so they can afford to 'lose' a lot of photons.

3\. Lasers- if a microscope has a laser (generally only 2 photons or certain types of confocals), it's going to cost a lot. I don't know what costs go into making a laser but the technology is pretty well established and the power of laser required for these machines seems to consistently run into the 20-50k range.

Other parts that are can be made cheap, but cost more (1-2k) when they need to be long lasting and highly precise. Stages (xyz stepper motors in particular), dichroic mirrors/filters, housing body, LED/fluorescent lighting source. This project got around that by specializing these components and using off the shelf stuff. I think probably many of these components could have their prices dropped a lot.

I think there is a future in bringing some of the costs down, but until we get a cheaper way to grab a lot of frames quickly or make good optics on the cheap, I don't know if research scopes (except the ones currently under patent like STORM) will drop much. Though alternative scopes (like the miniscope- 1k) can sometimes surprise people and replace expensive microscopes (120k two- photon), but that's more about being able to build into the niche and cutting out the need for more expensive components. Though from what I've read/seen microscope companies have a ton of overhead.

<comment><USER4> Can you elaborate on why optics are so expensive and why it isn't likely that manufacturing methods will come down in cost any time soon?

<comment><USER5> Only very high-end optics are expensive if your goal is to just get reasonable objectives you don't have to spend a lot of money it gets more complicated when you're doing things like laser illumination or if you need a really really low n.a.

</comment></comment></comment></comment><comment><USER6> $250 in parts is not a $250 microscope.

The expertise required to design, source, align, calibrate, stock, distribute, sell, and support such a microscope is not without cost.

<comment><USER7> But usually nobody quibbles about the same sort of definition for say a $250 3d printer (which requires all that fiddling too)

<comment><USER8> The difference being that professionals don't generally buy $250 3d printers - and when they do, i expect they do factor those costs in.

The difference is that professionals get paid and they know the value of their time. If you cannot rely on free labour, factoring in associated costs is important.

</comment></comment></comment><comment><USER9> It seems like there are a mountain of health related challenges that would benefit from some application of a little tech. I came here to ask what were some other hacking opportunities, how to find them, and how to collaborate with the med/bio people that need it.

Billg funded this project, and of course he's got something to say: [https://www.gatesnotes.com/Development/William-Wu-changed- hi...](https://www.gatesnotes.com/Development/William-Wu-changed-his-career- to-help-the-poor)

<comment><USER10> You can find those challenges yourself by volunteering your time at the grass roots level. One of the top of my head - One of the challenges in mass immunization (especially in poorer countries) is that the 'last mile' data is very sketchy and mostly self-reported. Many times people just have to assume that immunization campaigns are successful without proof. It would be nice to create a device/method/protocol that could automatically collect data, like say who was immunized, what were they given, number of doses, etc, etc. Conceptually the challenge looks to be easy, but in practice at the ground level is where the real challenges lie.

Another idea is creating a smartphone app that end-users can upload test results via the camera. for e.g. in the case of tuberculosis, once you administer the test, you have to observe a color change on your skin within a certain period of time. The key thing here is that in places where the number of doctors are few, we want to create a system where the patient who is taking the TB test only goes to the doctor if they actually have TB. A smartphone app that can deal with various lighting conditions, various resolutions, various color casts (due to auto white balance issues), etc, etc would be an interesting option.

</comment></comment><comment><AUTHOR> The paper supporting this work: [https://www.biorxiv.org/content/10.1101/684423v1](https://www.biorxiv.org/content/10.1101/684423v1)

</comment><comment><USER11> It scans blood thin smears for malaria; but scans sputum samples for Tb.

Cheers Manu Prakash

<comment><USER12> Can you compare this approach to the origami and spinning projects for malaria detection? Are they complementary?

</comment></comment><comment><USER13> I was thinking about an all-in-one device like this, naively wondering if it would work to throw many phases and frequencies of light at the sample, and train AI on that.

Though this microscope has specific modules for tb or malaria, I wonder how well those filters would find other things with some ML.

</comment><comment><USER14> If only this were out before the fall of Theranos, they could have stuck it in a fancy box with a robot and called it "Einstein".

<comment><USER15> I can easily say that this happened despite theranos.

</comment></comment><comment><USER16> Sounds like a promising approach. Maybe they should ask Gates for some funding.

<comment><USER17> They are funded through the gates foundation

[https://twitter.com/PrakashLab/status/1144453793485955081](https://twitter.com/PrakashLab/status/1144453793485955081)

</comment></comment><comment><USER18> Wrong. It's a $250 microscope. Any other cost is culturally imposed. Values are not objects.

<comment><USER19> Time isn't free.

<comment><USER20> It is given to us freely everyday without asking. What we do with it determines its value.

<comment><USER21> If you create powerful microscopes with that time, what value would be determined?

<comment><USER20> I think everyone has 3 numbers. A number that they will not go below, a number that two parties can agree on for a transaction, and a number which they would be extremely happy with (with no upper limit obviously). No different than negotiating a salary / contract which is what it is. I think when someone designs something with the intent to sell it however, that cost of research and development gets baked into the expected returns on the volume of sales. Its like an artist who sells originals versus an artist who sells copies of artwork, if that makes sense.

</comment></comment></comment></comment></comment><comment><USER22> I have Twitter blocked. Is there another source?

<comment><USER19> From the twitter post:

[https://www.biorxiv.org/content/10.1101/684423v1](https://www.biorxiv.org/content/10.1101/684423v1)

<comment><USER22> ty</comment></comment></comment>


Introducing Stellar: a decentralized protocol for sending and receiving money - <AUTHOR> https://www.stellar.org/blog/introducing-stellar/

<comment><USER2> >Facebook

Ha ha ha. No.

The rest of it looks interesting, however.

<comment><USER3> Hi from Stellar. I know FB isn't the ideal login method. But our goals were to provide easy access to people and to have a method to detect spam accounts. Today is our first day out. We will be releasing other ways to claim soon so I hope you check back. Thanks.

<comment><USER4> You are leaving the Chinese users behind. They contribute to 50% of Ripple's traffic.

<comment><USER5> We definitely want to expand beyond Facebook for distribution as quickly we can. We'd love to hear — do you have any suggestions for the best way of doing distribution within China?

<comment><USER4> Well if you (via Stripe) cooperate with Alipay do a giveaway via them.

</comment></comment></comment></comment></comment><comment><USER6> My account password recovery "token" was sent via email. I thought that was a no-no wrt security.

Edit: This was the text below the token:

Keep this code SAFE. Anyone with this code and your username can gain access to your account. If you lose both your password and your recovery code, you will lose access to your funds so be safe!

<comment><USER7> Ya, that was a bad idea on their part.

</comment></comment><comment><USER8> This is _extremely_ cool; I started putting together some of the same pieces after Stripe's blog post last week ([https://stripe.com/blog/bitcoin-the- stripe-perspective](https://stripe.com/blog/bitcoin-the-stripe-perspective)) and figured it was only a matter of time before something was launched. I'm glad it's open source and not for profit.

I do have a few concerns, though. Some of them require a bit more digestion so I won't comment on those here, but one that I'm sure about: _WTF is the reference client written in browser JS??_ It doesn't make any sense, for all the same reasons as the last time someone dragged out that dead horse.

<comment><USER5> The reference client being in-browser is a very deliberate choice: most users aren't going to download a client to play around with a new currency. It's certainly our hope that people will start building non-browser clients, and because everything is open-source and available it should be easy to do so.

As soon as you're in-browser, you have a choice: do it server-side, which means you have access to people's funds (at least while they're logged in), or do it via client-side JS, in which case you don't. The choice there for Stellar ended up being pretty straightforward, though the simple implementation leads to some UX surprises such as: [https://www.stellar.org/faq/#_Why_do_I_need_to_authenticate_...](https://www.stellar.org/faq/#_Why_do_I_need_to_authenticate_with_Facebook_to_receive_my_stellars_).

<comment><USER8> _> or do it via client-side JS, in which case you don't._

Of course you do, it just takes a teeny bit more work--you swap the contents of crypto.js with the contents of malicious-crypto.js. The threat model is exactly the same (users either trust the server or they don't) but the browser crypto option adds a layer of (respectfully, because I know you're a very intelligent person who means well) bullshit.

<comment><USER5> Ah, so certainly malicious JS code could misbehave and gain access to your account. But this is true also for someone publishing a desktop client — in practice, people aren't going to check the code going into each release, any more than they're going to inspect the JS running on their page before entering the password.

I think the question of where your password _by design_ will go is very important. If it's transiting the server, suddenly there's a lot more surface area to worry about. Logfiles, databases, and the like suddenly can be called into scope, and an attacker might be able to steal credentials even without being able to substitute out code.

In any case, the great thing about an open ecosystem is that, if you don't like the choices someone else has made, you are more than welcome to make your own implementation with choices you prefer!

</comment></comment></comment></comment><comment><USER9> Disappointed that I have to sign in with facebook to receive stellars.

<comment><USER3> I am one of the folks working at Stellar. Yes, FB isn't a login method that will work for everyone. But today is our first day saying hello to the world; we do plan on adding more methods soon. Thanks.

<comment> ryan-c A few suggestions (which would probably need to be limited to over X age):

* Google accounts

* Github accounts

* Twitter accounts

* bitcoin-otc accounts (probably with a minimum reputation)

* GPG keys with some minimum threshold of age and "signedness"

* S/MIME certificates from issuers that verify government ID.

I'm guessing the difficulty with supporting multiple methods is a desire to limit this to 5k/person. I'm not sure there's a good solution to this, though I will say that you may have just added some additional incentive to steal Facebook credentials.

</comment></comment></comment><comment><AUTHOR> It seems that this is the "secret bitcoin project" that Jed McCaleb (formerly of Ripple) has been working on. Very interesting.

<comment><USER10> It's his next pump and dump.

[https://xrptalk.org/topic/2629-selling-my- xrp/](https://xrptalk.org/topic/2629-selling-my-xrp/)

<comment><USER11> Long pump, though. The founders can't sell for 5 years.

[https://www.stellar.org/about/mandate/#Stellar_distribution](https://www.stellar.org/about/mandate/#Stellar_distribution)

</comment></comment></comment><comment><USER12> The sign-in process creates an unfunded wallet. Facebook login is required to receive 5k free Stellars (5k is 5 x 10^-8 of the available supply).

Cool idea. The idea of a distributed exchange is interesting.

</comment><comment><USER13> >Your Facebook account is too new to qualify. Stay tuned for new ways to grab stellars.

I've had my facebook account for something like 8 years. Oh well.

</comment><comment><AUTHOR> See the announcement from Stripe: [https://stripe.com/blog/stellar](https://stripe.com/blog/stellar) and the HN thread for the Stripe announcement: [https://news.ycombinator.com/item?id=8114901](https://news.ycombinator.com/item?id=8114901). Stripe invested in Stellar and the CEO of Stripe is on their board.

</comment><comment><USER14> Interesting project, I only wish I'd understand the mechanics behind it (apart from what the site tells me). Hopefully there will be layman's video explanation about it.

On another notice, this is one of the situations where it makes a lot of sense to register a simple username _just in case_ , so I don't regret it later where the only available are longer ones :)

</comment><comment><USER15> Where do they explain the concept of what a stellar is used for? I assume you would convert other currencies to stellars but I cannot find that detailed

</comment><comment><USER16> "A decentralized protocol for sending and receiving money": How is this news, exactly?

<comment><USER16> Or, just rephrasing:

Decentralized as in bitcoin, where proofs of work confirm transactions? That is not news, since 6 years ago.

Decentralized as in any other electronic transfer system, where you trust a few nodes to confirm the transaction? "Each node in the network communicates with a set of other nodes that it believes will not collude (such as nodes run by universities, governments, and companies)" That is not news, it's from decades ago. (Some people even tried to put a patent on it, like 15 years ago: [http://www.google.com/patents/US6173272](http://www.google.com/patents/US6173272))

</comment></comment><comment><USER17> can anyone briefly explain the difference between this and something like ripple?</comment>