Use ReactJS to Build Native Apps - <AUTHOR> https://twitter.com/floydophone/status/560503411389390848 <comment><USER3> Hi, I'm Jordan from the React team. I'm happy to answer any questions about React Native, but @vjeux will be giving a more thorough talk tomorrow that you won't want to miss (if you're at ReactJSConf), so I might wait for him to answer some of them.

This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.

<comment><USER4> There will be more detail tomorrow, but at a high level:

* JS engine on a background thread

* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)

* Plug-in for React that speaks that protocol

* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)

* Designed to take advantage of native platform views, NOT be the next Java Swing

<comment><USER5> Please, please have constraint-based layout support- I know you want to have it, given your work on react-gss :-)

<comment><USER6> What would be awesome and truly useful is _real_ constraints, like in CAD software. I should be able to express every width, height, x, and y value as a variable, or as a function of other variables. So I call the device height "A", the width "B", and express the rest of the UI in terms of those variables. Then at runtime "A" and "B" are defined, and the rest of the layout magically does its thing.

What Apple calls "constraint-based layout" is cool, but does not follow the classical definition of what a constraint-based layout actually is. They don't use variables anywhere in the IB UI. You can only define proportions in code which is incredibly clunky.

<comment><USER7> QML has exactly this -- and you write the constraints (arbitrary complex, almost) in Javascript :)

</comment></comment></comment></comment></comment><comment><USER8> This is massive. Some more details:

"React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1]

"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]

"iOS and Android native using all the same ideas as React, all the power of native." [3]

React has been gaining traction as I'm sure we're all aware, but this is next- level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS- analogue?

[1] [https://twitter.com/AnnaPawlicka/status/560505089207463936](https://twitter.com/AnnaPawlicka/status/560505089207463936)

[2] [https://twitter.com/floydophone/status/560504204343521280](https://twitter.com/floydophone/status/560504204343521280)

[3] [https://twitter.com/voodootikigod/status/560503641920921600](https://twitter.com/voodootikigod/status/560503641920921600)

<comment><USER9> ahem. my bet - [https://github.com/facebook/css- layout](https://github.com/facebook/css-layout)

cannot wait for more details.

<comment><USER10> Seems like you won the pot. @vjeux will be giving a bigger talk about it tomorrow and he's the biggest contributor to the css project ([https://github.com/facebook/css- layout/graphs/contributors](https://github.com/facebook/css- layout/graphs/contributors)).

<comment> bjr- relevant talk by @vjeux: [https://speakerdeck.com/vjeux/react-css-in- js](https://speakerdeck.com/vjeux/react-css-in-js)

</comment></comment></comment></comment><comment><USER11> "I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a _huge_ deal."

[https://twitter.com/andy_matuschak/status/560511204867575808](https://twitter.com/andy_matuschak/status/560511204867575808)

</comment><comment><USER12> Summary of what I can make out so far:

* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.

* The code you write runs in a Javascript interpreter on the background thread.

* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.

* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.

<comment><USER13> Has anyone asked if this can use other JS libs other than just React ones? Also, if it's just using say JavaScriptCore and rendering native, I assume this means speed limitations imposed by the lack of Nitro/etc on the UIWebView are moot?

<comment><USER14> JSC doesn't have JIT.

They claim perf is fine though (e.g. because render is always async, app code is always in background).

We shall see!

</comment></comment></comment><comment><USER15> This is awesome news. I've been working on a desktop application using React, node-webkit and browserify and it's been a great development experience. Being able to leverage web technologies to build native apps has been a huge time saver. However, I'm relying on the NodeJS components in order to do things like access the file system and fork commands. I'm wondering how React Native will handle this functionality. Will it be an extended API or can you only do AJAX calls? Either way it's very exciting.

<comment><USER16> Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in terms of whatever native capability exposed. You can totally use npm modules, provided any module that it uses is polyfilled.

<comment><USER17> My bet is that they are working with thrift for their transport layer. We're moving the same direction. I should be landing a bunch of diffs over the next week to the JS thrift libraries to support XHR and websockets in the nodejs thrift library (for use with browserify).

</comment></comment></comment><comment><USER18> "Learn Once Write Everywhere"

I this this is a great mentality over the classic write once run everywhere approach.

We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.

<comment><USER19> > "Learn Once Write Everywhere"

I can't help but think about that other chestnut, "A determined programmer can write Fortran in any language."

Of course it makes sense to apply a pattern that you know worked great in the past. The tough part is deciding when it's worth trying something else.

</comment></comment><comment><USER20> I can't wait to see more details about this. I hope this isn't another botched attempt at trying to solve the cross compiled native app challenge. I've seen and signed up for so many hype machines for solving this problem including plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've invested time in learning about all of these platforms, but in the end they all fell short in some way or another. I have high hopes for $FB though because I've really enjoyed most of the projects they've open sourced including React and Pop. Personally, it's been easier for me to just learn and use Swift/Obj-C. The main caveat is that my apps are limited to running on iOS.

</comment><comment><USER21> Hi, I'm just reading through the ReactJS docs for the first time, and I found something peculiar. Let me explain.

So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified.

I can understand this, but... The DOM is _already_ incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method?

Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating _only_ the display.

So, as you can see, I'm a bit confused...

<comment><USER22> There are added benefits for an immutable / FRP style of building a UI, but I think you're more interested in the rest of my answer.

Nothing to be confused about, you have a valid hypothesis: "Rendering and Diffing in Javascript is slower than DOM manipulation". However, all hypothesis need to be experimented before having any real meaning.

It just happens that testing this hypothesis and finding it invalid was the foundation for React.

Watch this video[[https://www.youtube.com/watch?v=XxVg_s8xAms](https://www.youtube.com/watch?v=XxVg_s8xAms)] I think it does a good job discussing this hypothesis and why they chose not to worry about it.

<comment><USER21> So let's assume I have a listbox with N elements in it. I assume the render() method has to visit each of these elements every time an updates takes place, so it is O(N). Please correct me if I'm wrong here.

Now for a certain value of N, things will become slow, unresponsive. I'm guessing now that this value of N is above the value where the browser cannot handle this number of elements anyway. Is this correct?

PS: I understand that it is possible to completely optimize the listbox case. But that is not the scenario I'm interested in. I'm interested most and above all in the typical use-case. I'm just using a listbox as an example here. Just replace it by any other sufficiently complicated and customized UI component if desired.

<comment><USER23> A render in react doesn't return DOM elements. Render is a pure function which projects app state into a description of the view. Let's call this description A, so render(state) -> A. When state changes and render is called a second time we get a new description, render(newState) -> B. A diff is then applied to them diff(A, B). The diff can then be translated to an update strategy for the actual DOM (or in this case, native components). From this the smallest set of changes are applied to bring the DOM in line with the current state. It turns out it's far quicker to diff objects in memory than query the DOM. The DOM is treated as a stateless rendering engine, with progressive updates applied as app state changes.

Of course, in your example, there is a point where N gets so large that it poses problems. This is true whether you're using the raw DOM or an abstraction like React. The solution is the same in either case - cull non- visible elements from the render tree (again react makes this as efficient as possible).

EDIT: it's also worth noting you can skip updating entire subtrees in React with shouldComponentUpdate hooks. This avoids the case where you go through the render/diff cycle and it turns out there is no difference, and so nothing to update. Paired with immutable data structures this method can be a simple reference equality check (shallow equals) oldState !== newState, and therefore can really get the most efficient rendering possible

<comment><USER23> Amelius, I cannot reply to you directly for some reason. Anyway...

So say you're rendering some long list of items. Because react is just plain JS (no templates!), you will map the array of items to components in your render. You give each item a key so that react can reconcile components across renders. If component with same key is returned from render next time then it's kept in the DOM (and any updates applied), if not then it's removed. So the involved part becomes determining what is visible or not, and then slicing your list of items to only map a subset. This is the more involved part. I haven't built anything like this myself, but I'm guessing it basically boils down to: listening to scroll events on container, determining y offset, get height of contaoner and height of elements, use that to determine which items in list should be mapped to components in render. That bit is the same whether react or not.

See James Longster's epic blog post "Reducing User Interface Complexity, Or Why React Is Awesome" [0]. Where he details this kind of approach with his for-demp-purposes-only react-like lib.

[0] [http://jlongster.com/Removing-User-Interface- Complexity,-or-...](http://jlongster.com/Removing-User-Interface- Complexity,-or-Why-React-is-Awesome)

<comment><USER21> Thanks a lot for this detailed explanation.

If I get this clearly, then still:

render() -> returns N items every time it is invoked

And React will diff those N items against the DOM (using a key) every time an update is required.

So, to me it appears that still O(N) amount of work has to be done every time something small changes in the list.

This is not necessarily a bad thing. But here we assume that doing render() is faster than actually building the DOM from scratch, even though they have the same computational complexity, O(N).

Anyway, I'll have a look at that link. Very interesting, thanks again.

<comment><USER23> no, it doesn't compare to DOM, it compares to the last result of render - <USER2> important difference performance-wise. the DOM is many times slower to query than plain objects.

also remember big-O notation doesn't really capture the essence of the problem here. looping through and querying N DOM elements is probably orders of magnitude slower than doing the same with N objects in memory

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> What does this mean? Can't you use any javascript tech to build native apps with nwjs or cordova?

Edit: looks like this isn't hybrid as I assumed but truly native

<comment><USER25> I am pretty confused as to what this actually does. How can it be native?

<comment><USER24> My guess is we're missing an important piece of the puzzle. Unless they have a js to everything interpreter. In which case thats much bigger news than react.

<comment><USER26> Its more of a shiv to convert react elements/calls into native UI elements, using a native server to receive streams/messages (unsure which) and convert them.

</comment></comment></comment></comment><comment><USER27> Video of this keynote is now up: [https://youtube.com/watch?v=KVZ-P- ZI6W4](https://youtube.com/watch?v=KVZ-P-ZI6W4)

</comment><comment><USER28> Extremely excited about this!

I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 ([https://github.com/trueinteractions/tint2](https://github.com/trueinteractions/tint2)), but it's still not stable enough, IMO.

This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it _does_ become your bottleneck you can rewrite it natively!

<comment><USER29> What was the issues you had with Tint (just curious).

</comment></comment><comment><USER30> I'm a big ReactJS fan, however isn't moving React to native a bit like old school windows message loop ?

<comment><USER31> Yes, the whole system is just basically component rendering (react) + a message bus oriented architecture (flux). The architecture is not novel, but I think the big change between React Native (or whatever they're going to call it) and any actual native application is the same difference between approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform independence.

The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).

</comment></comment><comment><USER32> It occurs to me that, for years, web platforms sought to keep developers from ever having to touch dirty old JS. I can remember all sorts of overcomplicated ASP.NET widgets that were like that.

Now we want JS and don't want to deal with gross native APIs. Perhaps it's not the same "we", though I personally am very excited about this. I love JS and I think React's ideas are the right ones for building UIs.

</comment><comment><USER33> Cool. I've always thought that the native view layer is better viewed analagously to how web developers tend to view the DOM: a low(ish)-level API upon which to build abstractions that better fit the domain.

Hopefully, we will come to view manual NSView slugging in the same way that we'd now view building a single page webapp entirely with jQuery.

</comment><comment><USER34> Sorry for an ignorant question, but what would be the relationship between ReactJS and React Native?

<comment><USER35> React-native uses React code to build native applications.

</comment></comment><comment><USER36> I have long questioned the validity of middleware (for the lack of better terms, please don't be pedantic) to create native applications.

I get it, HTML can replicate performance of native apps to a certain extent now, but it's also bound by restrictions that native apps aren't.

Speed of innovation being one. HTML5 is a large ship that takes a long time to evolve (in comparison). iOS and Android aren't, by the same means. Particularly iOS since Apple has a habit of introducing backwards compatibility breaking new features.

I don't understand fully how hybrid made apps will ever be able to properly compete with a native platform for this reason alone, not mentioning some of the other problems that plague hybrid and middle ware apps.

<comment><USER37> React Native is not built on the DOM and thus is not "hybrid"\--it seems it's fully native under the hood.

</comment></comment><comment><USER38> This is huge. There are so many approaches to cross platform mobile development, yet none of them really make it easy to integrate a full stack web platform. This is one step closer.

</comment><comment><USER39> Very promising! As a (past) Titanium developer, FB Groups being in the wild for a while comes as a relieve to my hears.

I'd bet Angular going Native first, though, I guessed it was coming with 2.0

</comment><comment><USER40> So...a JS interface to a server that creates native views. I don't get it, what is all the hype about? You've got an extra layer and level of abstraction (read: complexity) in your pipeline. I don't see how you can abstract away the idioms of a platform - they're _native_. 'Write once, run everywhere' has failed time and time again. So marketing changed its tune to 'Learn once, run everywhere' and now people are gushing how HUGE this is?

</comment><comment><USER41> Cue Om Native...

<comment><USER42> God, I would love to see this (or Reagent Native).

</comment></comment><comment><USER43> Is there more information somewhere? Or just a tweet?

<comment><USER44> [https://twitter.com/fbOpenSource/status/560506714382802945](https://twitter.com/fbOpenSource/status/560506714382802945)

Looks like it's not being open sourced for a while, but apparently the attendees are going to have some hands on tomorrow.

2015 seems like it's shaping up to be the year of React!

<comment><USER45> > 2015 seems like it's shaping up to be the year of React!

Something needs to replace AngularJS I guess, until the next big thing.

</comment></comment></comment><comment><USER46> As someone who is just getting into iOS dev is there any benefit (that's at least known at this point) to using React over Swift for UI?

<comment><USER47> It really depends on what you are using iOS for.

If you already know ReactJS, then it'll probably be a lot easier for you to learn React Native than Swift or Objective-C.

If you are working on a team with primarily JS developers, React Native is probably a better choice to go with.

Will this cause Swift to be irrelevant? Probably not.

\--

If you are learning iOS and doing production / client work, you should be aware that using a third party framework could actually break your app. I'm interested in React Naive, but also very weary about it. Facebook released a framework called Three20 back in iOS 2.0/3.0 days and abandoned the project shortly afterwards. Of course being open source there is bound to be people who take over the project, but it's something to think about.

</comment></comment><comment><USER48> This sounds promising. I've been building something with Ionic recently and it's great 'cause it's just Angular but the documentation is a bit inconsistent and outdated. If React Native were to execute and deliver, I'd definitely love to switch over.

</comment><comment><USER49> Seasoned Appcelerator's Titanium Mobile SDK dev here. Looks like that a lot of people here is comparing this announcement from the react team to the Titanium Mobile SDK. I'd like to give some info to shed some light on the differences, and probably anticipate the challenges they have to (or _had_ to) solve.

## Architecture

Both Titanium SDK and this Native React thing _do have_ a JavaScript runtime behind the curtains.

Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using factories (`Titanium.UI.createScrollView({ })`) and you add those views to parent views (`parent.add(child)`). This is very similar to a browser DOM, and in fact it's cumbersome to work with. They built an xml preprocessor called Alloy which does a better job at exposing the view hierarchy right in the source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation _at least_ for the following reason: every time you update a property on a view (actually on a proxy object to the real view) you're _crossing the bridge_ and you have to pay that penality. The bridge is the void between the JS runtime's thread and the main, UI's one. This is incredibly painful when trying to do JS animations, sometimes if you're not careful you can get hurt very badly. You can still do great things, but it's way better to use the native `.animate()` methods, which cross the bridge only twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will be batched and updated on a update loop basis or at least debounced. Or at least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don't want the developers to understand every layout system every platform provides, they have to normalize it somehow. Titanium SDK has it's own layout system, incredibly easy to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal.

Native React will probably follow a more intimately web-ish approach, just look at this JS/C/Java implementation of the box-model and flex-box specification by Facebook itself [1]

[1]: [https://github.com/facebook/css-layout](https://github.com/facebook/css- layout)

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land;

2) they have to follow every release of the platform's SDK;

3) you cannot just put native code along-side your JS code, so you cannot go where they didn't.

Let's see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this issues. The project is code-named Hyperloop and is already working behind the curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I'll stop here.

It's interesting, but until they show us some (native) code... it's just ideas.

Follow me on twitter (@_pier) and github (@yuchi) for Titanium related stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on gh we're @smclab)

<comment><USER50> Titanium comparisons are some of my top thoughts too.

1) How do they access the native API?

If there's no abstraction, just a translation, then the apps must be different for each platform. If there is an abstraction, then how much of the native platform do they cover? It can't be 100%, and the native APIs change with every OS version. Basic calls are easy, integrating things like device keychain, intents, and services are not so easy -- we learned this with Titanium.

2) How will React Native do cross-platform local data storage?

Being able to easily import, retain, and sync remote data is an absolute need for today's apps. Titanium uses SQLite on both sides, and has modules for more (like TiTouchDB). Not abstracting data storage would be a major mistake IMHO.

3) Can we use standard npm modules?

JS's killer feature is the module ecosystem, it's no good having a JS engine if we have to reinvent common modules to match a new API. V8 is the gold standard here, fingers crossed.

4) Debugging?

Speaks for itself. Debugging both JS and native code together bridged from a device is _hard_. Hopefully they are adapting existing tools and IDEs like node-inspector and Sublime Text.

<comment><USER49> Exactly. As Haynie stated on tw, it's sad that they didn't included them in the design process. They already solved a lot of challenges.

BTW, did you have a look at titaniumifier? ([https://github.com/smclab/titaniumifier](https://github.com/smclab/titaniumifier)) it's a tool we built to port node packages to titanium (a declination of browserify, actually).

</comment></comment></comment><comment><USER51> Everyone felt that in terms of Javascript rendering on mobile you guys had the best shot.

Did you feel that JS had hit it's limits with rendering and wasn't strong enough for mobile sites/apps?

Looking forward to hearing more about React Native!

</comment><comment><USER52> Nilas[1] is using React with Atom Shell to build a native desktop mail client for all three major platforms on top of their API. Awesome stuff!

[1] [https://www.nilas.com/](https://www.nilas.com/)

</comment><comment><USER53> I didn't attend the conf. Is there a way to get access to the repo?

</comment><comment><USER54> Facebook, destroying the edifices of the Internet, one technology at a time.

Very excited for this. I have been looking at React for a while, now it's certainly time to take a plunge.

</comment><comment><USER55> How does React Native handle OpenGl ES calls? Does it convert Webgl calls to native OpenGL or provide an interface to directly make native OpenGl calls from javascript?

</comment><comment><USER56> On iOS I'd imagine this uses the underlying Webkit JavascriptCore engine. How about Android? Do I need to embed a V8 in my app if I want to use React Native?

</comment><comment><USER57> I see React effectively as the controller of UI state changes. This can be applied on any datapath, i.e. model to view rendering - web / native / games.

</comment><comment><USER42> This is very exciting. I've been using React for a bit now and have found it a pleasure to work with. I can't wait for more details on React Native.

</comment><comment><USER58> Does this include desktop apps?

</comment><comment><USER59> Doesn't it violate the apple policy about updating the app without reviewing?

</comment><comment><USER60> I would love to see React added to mobile app frameworks like Apache Cordova.

<comment><AUTHOR> You can use ReactJS now with Cordova/PhoneGap - no problemo.

This announcement is about replacing html elements (div, h1, img, etc.) with native elements. Should be faster going native than via web elements.

<comment><USER61> So does it use PhoneGap or something like it?

<comment><USER62> No, it skips the DOM entirely and works with native elements (iOS views) directly.

<comment><USER25> This is where I get confused. How is it compiling to these elements?

<comment><USER63> One possibility: You have a JS interpreter running your React code. You generate a virtual DOM and hand it off to React. React sends the virtual DOM through a message bus to native code. So far, nothing crazy here, this is how frameworks like cordova work. That native code dynamically translates the virtual DOM into native UI elements.

</comment></comment></comment></comment></comment></comment><comment><USER64> Will it work with Reagent?

</comment><comment><USER65> This is really exciting! Can't wait to use it.

</comment><comment><USER66> Coupling your app to any framework has proved to be a really bad idea in the long run, to me this is a step in the wrong direction. If I've understood this announcement correctly.

</comment><comment><USER67> React is the Future. Period!

</comment><comment><USER68> oh boy now i can call myself an app developer too</comment>


Machine translation of cortical activity to text with encoder–decoder framework - <AUTHOR> https://www.nature.com/articles/s41593-020-0608-8.epdf?referrer_access_token=yqi8gndGo3bsyqSOt-QH49RgN0jAjWel9jnR3ZoTv0PGGLjJSIdJ3hFHzrqzGtisj2DRxrMxg3xPhwYR9Or_MFFWi9FFLCitwQPN6hzDOfuddKxNu7NRPQzS80eVE9peKMdJN14zNjJ66HDiFw8OaB3K899HudKHwkGg7prtc2MKkCosR0Mg9lyu2R8tDA-O-XP-CgHFT7NJfXeq8il1mGo_26BUelda8VnFBttFRYIzC7ZAr5I03DG6S_NFvZQTiBj8zrA4P4qwNArhZ0sCMS7bc6l-KY6PS-SIqYDW2LvT2pkbfxepOjoNylWMqOyE&tracking_referrer=www.theguardian.com <comment><USER2> Really cool to see progress made here but this won't be available for public use any time soon (likely decades).

One of the biggest challenges with decoding brain signals is getting a large number sensors that detect voltages from a very localized region of the brain. This study was done with ECoG (Eletro-Cortico-Gram) which involves implanting small electrodes directly on the surface of the brain. Nearly all consumer devices use EEG (Electro Encephelo Gram) which involves putting sensors on the surface of the skin.

Commercially available ECoG is highly unlikely as it requires an extremely invasive brain surgery. For ethical reasons the implants from the study we're likely implanted to help diagnose existing life threatening medical issues.

Decoding speech from EEG won't work as well as ECoG a number of reasons. First the physical distance between the sensors and the brain Means the signals you pick up aren't localized. Second the skin and skull are great low pass filters and filter out really interesting signals at higher frequencies, 100-2KHZ. Additionally these signals have a really low signal power because they're correlated with neuronal spiking.

ECoG does a really good job picking on these signals because the sensor is literally on the surface of the brain. Its really hard to pick up these signals reliably with EEG.

<comment><USER3> No, actually high density electrode implants are right around the corner. Watch the neuralink press event.

<comment><USER4> > One engineering challenge is that the brain's chemical environment can cause > many plastics to gradually deteriorate. Another challenge to chronic > electrode implants is the inflammatory reaction to brain implants. > Transmission of chemical messengers via neurons is impeded by a barrier- > forming glial scar that occurs within weeks after insertion followed by > progressive neurodegeneration, attenuating signal sensitivity. Furthermore, > the thin electrodes which Neuralink uses, are more likely to break than > thicker electrodes, and currently cannot be removed when broken or when > rendered useless after glial scar forming.

Yeah, you're not putting that in my brain.

[https://en.wikipedia.org/wiki/Neuralink](https://en.wikipedia.org/wiki/Neuralink)

<comment><USER3> The inflammation and damage is seen in traditional arrays that are large and rigid. A thread with low enough moment of inertia will likely not cause as much damage. And the damage is only important if you put the electrodes in an important place... we currently screw two giant lag screws into people's heads and call it "deep brain stimulation" so I feel optimistic about the long game. But you'd still be right to be wary. And if I had it my way, this technology would never be allowed to exist at all...

<comment><USER5> Can you continue about your opposition to it existing?

<comment><USER6> It's a social crisis waiting to happen, especially if you can end up decoding more than just what someone uses their speech centers to articulate.

This is invasive to the extreme, and seems to open the door for violations of people's intimate thoughts down the road.

You may not think about it much now, but if you pay any attention to things like intrusive thoughts, or even have to deal with carefully maintaining a public face in the workplace, it should not be difficult to realize why these technologies are legitimately dangerous even as read only systems.

The real nightmare begins when you finally get fed up with Read-Only and figure out how to write in order to potentially mutate mental state.

I'm normally pretty forward-thinking in terms of embracing the March of technological progress. However, the last decade or so has shown we as a society have had our grasp exceed our socio/ethical/moral framework for using it responsibly; and the potential abuse a full read/write neural interface would enable is one of the few things that has managed to attain a "full-stop" in my personal socio-ethical-moral framework.

Not to sound like that an adult, but we're just not ready.

Before anyone points out that the same moral outrage probably occurred with the printing press; there is a big damn difference between changing someone's mind through pamphlets, and having a direct link to the limbic system to tickle on a whim. We do a very bad job of correctly estimating the long-term effects of technological advancement; just look at how destructive targeted advertising has been.

I haven't reached my conclusion on an existing preconception/predisposition either. I used to be massively for this particular advancement. Only through a long time spent reflecting on it has my viewpoint done a 180.

I'm aware of all of the positive applications for the handicap, brain-locked, and paralyzed; but I'm still reluctant to consider embracing it for their sake when I've seen how prone to taking a crowbar to a minor exception/precedent our legal system is.

Maybe I've just been in the industry long enough not to trust tech people to keep society's overall well-being and stability at heart. Maybe I'm becoming a luddic coward as I get older. I don't know, and I ask myself if I'm not being unreasonable every day. The answer hasn't changed though in a long while, even though I do keep trying to seek out opportunities to challenge it.

I hope that helps, and doesn't make me sound like too much of a nut.

<comment><USER7> > Before anyone points out that the same moral outrage probably occurred with > the printing press; there is a big damn difference between changing > someone's mind through pamphlets, and having a direct link to the limbic > system to tickle on a whim.

I've recently read a short story from Ted Chiang likened the development of writing to a fundamental cybernetic enhancement of the brain. I found it to be quite enlightening, as I never thought of how writing changes how we see ourselves and the environment. Our memories are imperfect and inaccurate and amplify biases we have, while writing loses much less information.

> just look at how destructive targeted advertising has been

Can you elaborate? Targeted advertising doesn't even make my top 100 of destructive technologies.

<comment><USER8> Instead of thinking of advertising as "technology" you might want to look into the military-esque research that brought it into the free market. Just like the internet, psyops was first destructed and formalized by people that value information over influence. As only one will beget the other with any statistical certainty.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is cool. For those who are not super familiar with language processing, I think it's good to point out the limitations of what's been done here though. They mention that professional speech transcription has word error rate around 5%, and that their method gets a WER of 3%. Sure, but the big distinction is that speech transcription must operate on an infinite number of sentences, even sentences that have never been said before. This method only has to distinguish between 30-50 sentences, and the same sentences must exist at least twice in the training set and once in the test set. Decoding word-by- word is really a roundabout way of doing a 50-way classification here.

It's an invasive technique, so they need electrodes on a human cortex. This means data collection is costly, so their operating in very low data regime compared to most other seq2seq applications. It seems theoretically possible that this could operate on Google translate level accuracy if the sentence dataset was terrabyte sized rather than kilobyte sized. That dataset size seems very unlikely to be collected any time soon, so we'll need massive leaps in data efficiency in machine learning for something like this to reach that level. They explore transfer learning for this, which is nice to see. Subject- independent modelling is almost certainly a requirement to achieve significant leaps in accuracy for methods like this.

<comment><USER10> Is the following quote at odds with what you are saying about 50-way classification?

"On the other hand, the network is not merely classifying sentences, since performance is improved by augmenting the training set even with sentences not contained in the testing set (Fig. 3a,b). This result is critical: it implies that the network has learned to identify words, not just sentences, from ECoG data, and therefore that generalization to decoding of novel sentences is possible."

<comment><USER9> The difficulty of the problem is that of a 50-way classification. If the only goal was to minimize WER, a simple post-processing step choosing the nearest sentence in the training set could easily bring the WER down further. They've chosen to do it the way they did it presumably to show that it can be done that way, and I don't fault them for it.

They claim that word-by-word decoding implies that the network has learned to identify words. This may well be true, but it isn't possible to claim that from their result. For example, let's say you average all electrode samples over the relevant timespan, transform that representation with a FFW neural net, and feed that into the an RNN decoder. It would still predict word-by- word, on a representation that necessarily does not distinguish between words (because the time dimension has been averaged over). Such a model can still output words in the right order, just from the statistics of the training sentences being baked into the decoder RNN.

</comment></comment></comment><comment><USER11> I have tried something similar 5 years ago using the meditation device from choosemuse.com. It was the cheapest option and provided hackable interface that you had access all the data. Then I wrote a small mobile app connects to headset.

Application was picking and showing a single random word from "hello world my name is hrgiger" then showing a greeen light, when I see green light, i think about the word and blink, headset was able to detect blinks as well so app was creating training data using blink time - xxx millis. So I created few thousands training data with 6 class using this and trained with my half-ass nn implementation and used generated weights to predict same way via mobile. Never achieved higher than 40%, tried all mixed waves, raw data, different windows of time series. Yet still it was a fun project to mess with, still I try to tune this nn implementation. If they achieve a practical solution I would use subtitles for the full length training. Simple netflix browser plugin might do the trick,but I am not sure if there will be a single AI algo that would understand everyones different data.

<comment><USER12> 40% over 6 classes is way above a random baseline. This is actually pretty cool. Congratulations!

<comment><USER11> Oh thank you! I wasnt even aware those numbers were promising.

</comment></comment></comment><comment><USER13> It looks cool, but they trained their models on people reading printed sentences out loud.

Would that actually translate to decoding the process of turning abstract thoughts into words?

The researchers also note that their models are vulnerable to over-fitting because of the paucity of training data, and they only used a 250-word vocabulary. Neuralink also has a strong commercial incentive to inflate the results, so I'm not too sure about this.

It's great to see progress in these areas, but it seems that technologies like eye-tracking and P300 spellers are probably going to be more reliable and less invasive for quite some time.

<comment><USER14> The speaking aloud is very suspicious. Why do subjects need to speak aloud? Are they actually decoding neural signals or just picking up artifacts introduced by the physical act of speaking (i.e. electrodes vibrating due to sound, etc)?

</comment></comment><comment><USER15> Fascinating work but far from what some might hope from reading only the title.

The translation is restricted to a vocabulary of 30 to 50 unique sentences.

<comment><USER16> They do mention that the network is partially learning the words themselves:

> "On the other hand, the network is not merely classifying sentences, since > performance is improved by augmenting the training set even with sentences > not contained in the testing set (Fig. 3a,b). This result is critical: it > implies that the network has learned to identify words, not just sentences, > from ECoG data, and therefore that generalization to decoding of novel > sentences is possible."

</comment></comment><comment><USER16> Can we remove the tracking query-string from this link, please? It works fine without it:

[https://www.nature.com/articles/s41593-020-0608-8.epdf](https://www.nature.com/articles/s41593-020-0608-8.epdf)

Edit. Sorry, seems to only show the first page if you remove the token.

<comment><USER17> Not only that, if you don't run the trackjs script, the pdf won't load at all. Sorry but a hard pass from me. Don't track my reading.

</comment></comment><comment><USER18> It seems like this field is at about the same stage of progress as image recognition was in the 90s when researchers were trying to getting a handle on MNIST-type tasks.

I wonder how much the language embeddings learned by the transformer are reflected in the actual physical structure of the brain? Could it be that the transformer is making the same sort of representations as those in the brain, or is it learning entirely new representations? My guess is that it's doing something quite different from what the brain is doing, although I wouldn't rule out some sort of convergence. Either way, this is a fascinating branch of research both for AI and the cognitive sciences.

</comment><comment><USER19> Looks like a good approach and the error rate of 3% is really good, I guess. Did they mention how they got the input data? I couldn't find it.

<comment><USER16> They use 250 ECG electrodes as input. I think that means it's above the skin, so not invasive.

<comment><USER20> You are mistaken. They use ECoG which is intracranial electroencephalography. These are electrodes placed on exposed surface of the brain. [https://en.wikipedia.org/wiki/Electrocorticography](https://en.wikipedia.org/wiki/Electrocorticography)

<comment><USER16> Thanks for the info!

</comment></comment></comment></comment><comment><USER21> I'm pretty sure you can get that with a HD camera or two and some hypnosis plus off-the-shelf ML.

One of the very first things I learned when I was studying hypnosis was to induce a simple binary signal from the unconscious. (Technically it's trinary: {y,n,mu} [https://en.wikipedia.org/wiki/Mu_(negative)](https://en.wikipedia.org/wiki/Mu_\(negative\)) )

(In my case my right arm would twitch for "yes", left for "no", no twitch for "mu" (I don't want to go on a long tangent about all the various shades of meaning there, suffice it to say it's a form of "does not compute."))

Anyway, it would be trivial to set up one or more binary signals, and detect them via switches or, these days, HD cameras and ML. You could train your computer to "read" your mind from very small muscular contractions/relaxations of your face. (The primary output channel, even before voice, of the brain, eh?)

Or you could just set up a nine-bit parallel port (1 byte + clock) and hypnotize yourself to emit ASCII or UTF_8 directly. That would be much much simpler because it's so much easier and faster to write mind software than computer software (once you know how.) And you could plug yourself into any USB port and come up as a HID (mouse & keyboard.)

I'll say it again: when you connect a brain to a computer the more sophisticated information processing unit is the point of greatest leverage. Trying to get the computer to do the work is like attaching horses to the front of your truck to tow it. Put the horses in the back and let the engine tow them.

<comment><USER22> Could you elaborate a little bit on the 'induce a simple binary signal from the unconscious'? That sounds fascinating.

<comment><USER21> Sure. (Thanks for asking.) It was one of the first things I learned when I started studying (self-)hypnosis. It's a simple way to have access to the unconsciousness without going into a trance.

There's really nothing to it. You induce a light trance and ask the unconscious mind to create a simple unambiguous yes-no signal. Finger motions are common. After that you can ask yourself questions and get y/n answers (or non-response, what I'm calling "mu", which indicates some issue with the phrasing or nature of the query.)

I should mention that you should be very careful about your self-model if you are experimenting with piercing the barrier between the conscious and unconscious minds. In computer terms, this signal corresponds to a kind of trans-mechanical _oracle_ and having it available to your (metaphorical) Turing machine mind makes you into a fundamentally different kind of processor, operating by rules that may be unfamiliar.

[https://en.wikipedia.org/wiki/Oracle_machine](https://en.wikipedia.org/wiki/Oracle_machine)

But see also: [https://en.wikipedia.org/wiki/Oracle](https://en.wikipedia.org/wiki/Oracle) because that's more accurate.

</comment></comment></comment><comment><USER23> [https://sci-hub.tw/https://doi.org/10.1038/s41593-020-0608-8](https://sci- hub.tw/https://doi.org/10.1038/s41593-020-0608-8)

</comment><comment><USER24> Speech From Brain Signals [https://youtu.be/YHFx6O5x5Hw](https://youtu.be/YHFx6O5x5Hw) (2019)

</comment><comment><USER25> Man, what is going on with Participant C's active neurons.</comment>


Hacking Microsoft SQL Server Without a Password - <AUTHOR> https://blog.anitian.com/hacking-microsoft-sql-server-without-a-password/ <comment><USER2> Nicely done. Just last month, Microsoft released TLS 1.2 support all the way back to SQL Server 2008 to prevent this kind of thing:

[https://blogs.msdn.microsoft.com/sqlreleaseservices/2016/01/...](https://blogs.msdn.microsoft.com/sqlreleaseservices/2016/01/29/tls-1-2-support- for-sql-server-2008-2008-r2-2012-and-2014/)

Given the slow patch speed of most SQL Server shops, though, this exploit will work for years.</comment>


Ask HN: What are your time-saving non-tech life hacks? - <AUTHOR> What are your time-saving non-tech life hacks?
I'm looking for things you do in your day-to-day life that save you significant amounts of time.
I shave my hair, and I do it myself.
I don't have to comb it. I don't have to spend time and money going to the barbershop. I don't have to expend mental energy thinking and worrying about whether my hair is messed up (rain, sports, winter hats).
I've been doing that for more than 15 years and the payback has been huge. It's very liberating. <comment> core-questions > I've been doing that for more than 15 years and the payback has been huge.

What about the opportunity cost from not looking as good as you might with a nice haircut? ;-)

Just bugging you. Wish I had a nice round skull that looked good with that style.

As far as life-hacks go, I generally seek to run my domestic operations like an OS scheduler - start background things first (get that kettle boiling, get that washing machine running, etc) and then proceed to interactive chores that need direct attention while other things are happening in the background. Keep as many things busy as possible. Buy a Roomba.

<comment><USER2> > As far as life-hacks go, I generally seek to run my domestic operations like > an OS scheduler - start background things first (get that kettle boiling, > get that washing machine running, etc) and then proceed to interactive > chores that need direct attention while other things are happening in the > background.

I too try to do this as much as possible. But I find that this is only possible with tasks that follow a specific pattern every time. If I try to change even a single thing in the background task, I have to interrupt interactive chores because I will have forgotten something else. To remedy this, I always take 5 min to mentally list each step before starting.

People recommend listening to podcasts/audiobooks in the background while working. I would recommend against that. Eliminate background distractions - reddit, podcasts, anything. If I browse reddit while I wait for something to complete, I waste a lot of time by finishing the article/thread before taking action on finished items. This makes a lot of difference when time is limited, especially in the morning when I'll be running to catch the bus on time. If I listen to podcasts, I miss some information in the podcasts, and I miss some things on the tasks I'm working on.

</comment></comment><comment><USER3> I built a canned food rack. It hangs on the wall and acts as a fifo. When canned good I like are on sale, I buy a ton and never worry that there is an old can at the back of the self.

<comment><AUTHOR> That's awesome. I'd love to see a picture of it.

</comment></comment><comment><AUTHOR> In the dishwasher, I group the cutlery to make it fast to unload. This front- loads the time slightly and reduces the unloading significantly.</comment>


Eric Idle's reading list - <AUTHOR> http://pythonline.com/pythonpost/eric_idle/read_along_with_eric

<comment><USER2> I came across his site before, he had a long list of good books he read with some reviews. I'm sure some googling can turn it up.

Also, Eli Bendersky's book reviews are fantastic when you need to find something to read. Eli's reviews are a little humbling, considering the pace he reads books in... in four languages. <http://eli.thegreenplace.net/category/book-reviews/></comment>


Are you a great web developer that's looking for an exciting challenge? - <AUTHOR>

Hi everyone, I've been working a my website for over a year now (I had to pay a web agency to do it for me = bad experience) and it is close to ready for launching. What do I need? YOU! a "class A" web developer willing to join me in my project (and others to come!). With you, it'll be much easier to get investors on board (I already made a few contacts)and from there we build up a winning team (top class SEO person and community manager...).
About me, I'm a 29 years old french guy, I live in France but as soon as possible I'll move to the Bay area. If you're good at what you do, we'll build great things together.
Check out the website: www.tiwy.org Watch the video on the home page
To try it out, search "rentals" in London, England
Contact me via the website directly
Cheers to all, let's beat that crisis up with great businesses <comment><AUTHOR> PS: note that I see major changes on the website to come, it's not like you join and just handle the bugs, you'll be improving the website constantly</comment>


Competition vs. Community - <AUTHOR> http://www.saurik.com/id/20 <comment><USER2> I got to the end of that article and thought "boy, I've really benefitted from the work Jay has done. I should send him some lunch money as a thank you" and there was the link right at the top of the page!

I sent you $20 for all the work you've done to teach me more about the inner workings of iOS, even if I have never installed Cydia. :)

</comment><comment><USER3> > Many of the things I obsess over no one actually truly [...] understands > (the font metric calculation logic in Cydia's CSS).

This sounds fascinating; I'd love to know more about it.

<comment><USER4> I've wanted to write a detailed blog post about the problem I needed to solve and what I ended up doing; the fact that you have said this just increased the likelihood of me doing that "soon" quite drastically.

<comment><USER5> I would read a blog full of obscure/behind the scenes details/problems people face and solve.

<comment><USER6> I wonder if a tumblr dedicated to post-mortems, tech crisis prevention, clever programming solutions, et al. would be popular (or already existing)

</comment></comment></comment></comment><comment><USER7> I've always wondered what the term "Cydia" meant, so I hope Saurik can clarify: "Cydia" the app, or "Cydia" the ecosystem?

The app itself, more or less, is a graphical frontend for APT on the iphone. On the other hand, a lot of applications and stuff that comes with "Cydia the app" that form the ecosystem- like MobileSubstrate, Cyscript, etc mentioned in the article.

I remember back in the "wild west" days of jailbreaking, where a jailbreak implied literally just that- the ability to run unsigned code on iOS. The jailbreak (redsn0w, I think) around the iOS 3 days didn't even come with Cydia- it just installed SSH, and the user had to install Cydia after SSHing into the device. I remember enjoying the Telesphoro repo just for the *nix frontend apps that it installed, the coreutils, netutils, vim, etc packages. I originally didn't jailbreak for Cydia/substrate/whatever, I jailbroke to use my iphone as a nix workstation; admittedly this is a extreme minority use.

I wonder if Saurik could separate the app and the ecosystem of packages. Is it even possible? I don't claim to understand how Cydia works now, but is it possible to split off the maintenance of the Cydia app and the core (jailbreak/cydia) ecosystem packages like MobileSubstrate?

<comment><USER4> > The jailbreak (redsn0w, I think) around the iOS 3 days didn't even come with > Cydia- it just installed SSH, and the user had to install Cydia after SSHing > into the device.

Very few versions of redsn0w ever installed just SSH (the ones that did were beta versions targeting iOS firmware versions where we didn't want to make things easy for end users). Cydia was included by default with the initial release of PwnageTool for iOS 2, and has been included in almost every jailbreak ever since.

> I've always wondered what the term "Cydia" meant, so I hope Saurik can > clarify: "Cydia" the app, or "Cydia" the ecosystem?

You use the term MobileSubstrate, which was the name of a dylib and the low- level name of a developer-only package for what was always called Cydia Substrate (the very first source code file for it I wrote in 2008 had Cydia Substrate at the top). Apple named most of their folders and files and bundle names at the time like that.

Cydia is a platform for runtime code modification that includes an SDK for making modifications (Substrate), a distribution system for installing them (Installer), a payment processing, licensing, and accounting backend (Store), and (on Android only, currently, and not really fleshed out yet) a USB device management tool (Impactor).

The icon for Cydia Installer is labeled "Cydia", so the boundaries between the terms "Cydia"-the-app and "Cydia"-the-platform is blurry. People then tend to talk about "Cydia Repositories" (APT repositories with content for usage with Cydia) and "Cydia extensions/apps" (what I normally call "Substrate extensions").

As for the "ecosystem", the line is often blurred here between the "iOS jailbreak ecosystem" and the "Cydia ecosystem" because almost every jailbreak tool has included Cydia Installer, Cydia Installer is the only way to get Cydia Substrate, and almost everything in the ecosystem is built as a Substrate extension of some form.

> I wonder if Saurik could separate the app and the ecosystem of packages.

As explained in the article, I am able to maintain all the things I'm responsible for, as well as have the time to help all the people who maintain all the things I'm not directly responsible for, because I have a semi- profitable business that I have managed to build out of the Installer and Store parts of the Cydia platform.

Alternatively, I could charge developers for licenses to use Substrate, and I could sell Cycript as some kind of stand-alone tool package, but that would have a massively stifling effect on the developer ecosystem. It isn't about "these things are overly coupled", it is "these things are effectively coupled but don't look to be".

Another option is that I could build first-party software for the device built out of Substrate, and distribute my software via someone else's software distribution and payments service. This sounds like an even worse scenario. In this case, I would be highly incentivized to hoard Substrate for only my products as a competitive advantage.

Essentially, if someone wants to compete with me on Installer/Store, they need to be prepared to handle everything else, because that's the place where I am able to make money: if they want the only part that's profitable they had better be prepared to take on all the things that aren't, as they aren't entitled to my effort.

Like, I don't know what you are hoping to obtain by splitting Substrate and Installer/Store apart, but if the goal is to be able to let people compete with some of the things I've built without just replacing me entirely, that isn't really possible and I honestly don't see the point: I would just leave if that happened.

<comment><USER7> >Very few versions of redsn0w ever installed just SSH

It might have not been redsn0w. Perhaps blackra1n or older, in the iOS 1/2 days, when people installed Cydia side by side with RipDev's Installer. My memory is pretty hazy on that. At any rate, this distinction is mostly a historical footnote at this point.

\</comment></comment></comment><comment></comment><comment></comment><comment></comment><comment>----

Anyways, I understand that from a practical perspective, it is impossible to separate Cydia-the-installer-and-store and Cydia-the-code-modification- platform. The former pays the bills, while the latter is the focus of most development effort and center of the jailbreak ecosystem, but not profitable without killing said ecosystem. As such, it probably would be foolish to ask to distinctly separate the app and platform code-wise, as people would aim to compete in the somewhat profitable storefront side- Rock is a good example, as mentioned. Again, I understand how you said <quote>It isn't about "these things are overly coupled", it is "these things are effectively coupled but don't look to be".</quote>

However, if I may: I would suggest you do a branding clarification to clarify, if not separate, the Installer and the Code Modification side of things. For people who aren't as familiar with the scene, it would probably help people understand what you do for the jailbreak community better.

As it is, the naming scheme for the entire ecosystem is pretty confusing. For non-jailbreak-devs, "Cydia" is seen as a platform containing just the APT- frontend installer app and the store; the code modification/extension side of things is less obvious, eclipsed by the installer. This is possibly part of the reason why some people are interested in competitors for Cydia: if it is only seen as a glorified app store storefront and installer, almost anyone can write a replacement, which may be the cause for discontent.

This also has the benefit of clarifying what you're trying to do for Android: the brand "Cydia" is very iOS-centered at this point, and perhaps distinguishing Substrate/etc as something else, more neutral, would be a good idea.

<comment><USER4> On the contrary, I would on the other side claim that allowing the branding to accidentally separate, into MobileSubstrate and Cydia, was actually a key mistake: it reinforces the belief that they are entirely unrelated things that can be thought of and selected separately. I wish I could go back in time and be more clear with the branding as always having said "Cydia Platform" and "Cydia Substrate" whenever possible, so people see all the pieces as a unified concept, as then I wouldn't run into problems where people think "well, I'll just compete with this profitable thing I see that is defined easily with this word people talk about". I actually only started being really consistent and forceful about Cydia as a platform in the last year, when I started zooming out and putting the puzzle together better. (Really, Substrate only doesn't ship together with the GUI for ancient political reasons.)

<comment><USER7> (I've edited my previous comment a bit to clarify, probably after you read the first revision and started commenting, so just a note)

(Anyways, thanks for responding and continuing the conversation. I definitely appreciate this chance to talk with you.)

\</comment></comment></comment><comment></comment><comment></comment><comment>

ARE they something that can't be thought of and selected separately, though?

I personally don't like that kind of thinking. It's similar to adding DRM to programs so that it stops pirates- just replace "DRM" with "branding uniformity" and "pirates" with "competitors".

Instead, if someone was truly interested in being an obnoxious competitor, they would "crack" the "DRM" by forcibly separate the branding. Read this in a TV advertisement voice: "Rock with Cydia Substrate, ALL of the Cydia extensions, but none of the slow!" "Replaces the installer, keep the plugins!" Sounds a bit familiar, hm? The end result is still the same, just like with piracy.

If anything, this may be worse. It pollutes your own brand, and if issues comes up, you can be blamed even more for stuff that wasn't your fault.

By keeping the code modification clear, you definitely would be able to better advertise to the Android side of things, and perhaps have other benefits with the current jailbreak community. You are in the unique position of being the only core jailbreak dev where all of the code that they ship doesn't need to be completely replaced every jailbreak. Unfortunately for other jailbreak devs, due to this, people have established an "everything is replaceable" mentality. People can clamor to kick devs out of the scene, like I0n1c. Cydia is not completely immune: if people think it is just a store and a frontend for APT, then people will think that almost any competent programmer can replace you- this is bad! By giving Substrate the individual brand that it deserves, and advertising the difficulty in building such a live code modification platform, it becomes that much more important in consumer's eyes.

Even if you don't care about the average jailbreak community member (seeing some tweets with death threats over not releasing something fast enough... make such a perspective all too understandable), the thing is that the next person to come along to compete will originate from this jailbreak community. Marketing a stronger brand to emphasize the irreplaceability of Substrate may only gather more respect and benefit you in the long run.

<comment><USER4> Your hypothetical situation cannot happen due to a combination of trademark and copyright law: you can't redistribute Cydia Substrate, nor could you attempt to dilute my branding or somehow accidentally ascribe fault to me. On Android, Cydia Gallery was designed (very poorly) to temporarily serve the purpose of Installer until I determined whether or not it was a good idea to bring the whole stack of Cydia over.

Again, your strong separation makes it sound easy to compete with Cydia separately from Substrate: what you are describing is _weaker_ branding, because it takes two things that are only not tied together due to happenstance of technology but which are intrinsically tied legally, economically, and even user-experientially, and separates them into two things that suddenly look like you can replace one but not the other.

You then talk of people thinking Cydia is "just a store frontend for APT", but that's what "Cydia" is in your version of the branding: Substrate is some entirely separate thing, leaving Cydia alone to be compete-able with. You make it sound like separating them _solves_ this problem, but them being accidentally separate is what _caused_ this problem in the first place: you have the entire scenario backwards :/.

Again, it is only in the last year year that I've gone out of my way to attempt to _fix_ the branding between these two things that previously the user community accidentally saw as highly separate, with "MobileSubstrate" being this thing that maybe anyone was allowed to use and "just some weird backend thing" and pulling it into the forefront as the development tool that embodies the end-to-end platform that is Cydia.

<comment><USER7> >cannot happen due to a combination of trademark and copyright law

There is no need to redistribute anything, as you've said yourself: pretty much every jailbreak tool comes with Cydia. This hypothetical new tool just needs to remove the installer part of Cydia, which would be legal. Also, advertising "compatibility with another product" is a pretty gray area of trademark law, and lawsuits are expensive- they can bet that you might not want to get embroiled in a lawsuit, where you have everything to lose and they have nothing to lose. It's not a completely far fetched idea.

> what you are describing is weaker branding

Let me clarify my points about branding: with separate branding, I was proposing "weaker combined branding, stronger individual branding". I am not arguing that they are not tied together economically and legally.

> You make it sound like separating them solves this problem, but them being > accidentally separate is what caused this problem in the first place

Oops, I think you might have misunderstood my examples. I wasn't saying that separating the brands make it harder to compete against. I was saying that combining the brands to reduce competition is just as effective as using DRM to reduce piracy- that is, not at all. A lot of game studios nowadays, instead of adding DRM to combat piracy, release games without DRM. Similarly, instead of combining the brands in an attempt to reduce competition, just embrace the fact that it will happen no matter what.

In formal logic, let p be "separate brands", and q be "more competition". You are saying "p then q, so it is better to not-p"; on the other hand, I'm trying to say "p AND not-p will still lead to q, and p has good effects, so just do p". Hopefully the previous sentence made sense, haha...

> and pulling it into the forefront as the development tool

I feel like this is a "mere" advertising problem, and not directly related to its branding. Currently, you're trying to make Substrate more popular by combining it into the brand that the Cydia installer has. Alternatively, you can make it more popular by creating another brand and advertising its power through that: say, create "Aidyc Substrate" ("Cydia" backwards) (ok that's a shitty name but w/e), and building on that and advertising that. Both methods could work in the end.

Apple themselves can show us the power of two individual brands that rely on each other while tied at the hip: "iPod" and "iTunes"! Creating separate brands do not take away from the individual products. Can you imagine if Apple decided to call both the music store and the device "iPod"? Separate brands, intrinsically tied together legally/economically/user-experimentally, and provides a great example of what could work out. If both products are strong, they only reinforce each other away from competition.

\</comment></comment></comment><comment></comment><comment>-----

As an humorous aside note, I just realized that since you have a monopoly on jailbreak tools, and SaurikIT is a "legal" company, someone can sue you for anti-monopoly for bundling stuff together. It would be extremely unlikely (although quite funny from a bystander perspective, probably less so for you) for the courts to pull the Sherman Antitrust Act on you like that, though.

<comment><USER8> > anti-monopoly for bundling stuff together

That's not how it works. Similarly, you can't sue Apple for their "monopoly" on iPhones which they use to bundle the app store. Markets are defined as product categories, not slices of an individual product, at least in the eyes of the Justice Department.

</comment></comment><comment><USER9> > Part of the issue is that payment processing is a brutal and painful battle.

Bitcoins might be a viable and less painful option

<comment><USER10> Not really.

You have to factor in the cognitive load of dealing with bitcoin and all that it entails, currency risk, regulatory headaches, banks and other financial institutions reacting negatively to your bitcoin exposure; not to mention the not inconsiderable security exposure you have to manage of having a valuable string of bits that must be secured and backed up and guarded from exposure.

Bitcoin is not cost-free, and right at the moment, it represents more risk than most legitimate businesses are willing to assume. This is not to say that bitcoin doesn't have benefits, it certainly does; but those benefits don't come for free.

</comment></comment><comment><USER11> I think you are always going to have people/groups your going to compete with and ones you cooporate with. You chose to compete with iOS by creating an alternative(jailbreaking). I agree trying to compete on minor changes seems like a pretty big waste of time, but your probably not going to get much value out of them as part of your community anyways. I guess it comes down to movitivation. If people are competing mostly because of ego or is there a deeper reason that will resonate with others.

</comment><comment><USER12> > The reality is that Apple makes money because Apple sells hardware: they > make more money on a single iPhone than they could ever hope to win back in > a lifetime of application sales, and most users purchase a new iPhone every > two years. You'd have to buy hundreds of $1-$2 apps every year for Apple to > care about that business.

Is this true? I was under the impression that Apple makes the _majority_ of their iOS money from royalties on the app store. What on earth could their expenses be to offset 30% of $1,000,000,000/quarter[1]?

1\. [http://www.forbes.com/sites/chuckjones/2014/01/07/apples- app...](http://www.forbes.com/sites/chuckjones/2014/01/07/apples-app-store- could-have-generated-1-billion-in-revenue-in-the-december-quarter/)

<comment><USER4> If we look at Apple's 10-Q for Q1 2014, we see ~$40b in revenue for iOS devices, and ~$10b in revenue for "iTunes, Software and Services", which "includes revenue from sales on the iTunes Store, the App Store, the Mac App Store, and the iBooks Store, and revenue from sales of AppleCare, licensing and other services".

[http://investor.apple.com/secfiling.cfm?filingID=1193125-14-...](http://investor.apple.com/secfiling.cfm?filingID=1193125-14-157311&CIK=320193)

Conservative high estimates of their profit margin on iTunes sales is 10% (often the more reasonable estimates are "low single digits"), the low-end estimates I've seen for hardware sales is 40% (you can find people who have done detailed charts, breaking down the parts and labor for building these devices).

 _While Apple has said little historically about individual product profitability, the patent lawsuit between the company and Samsung provided one small window into just how valuable the iPhone franchise has been. In just 18 months between October 2010 and March 2012, gross margins on iPhone were between 49 and 58%, an almost unheard of figure for a consumer electronics product._

[http://www.forbes.com/sites/markrogowsky/2013/09/11/marginal...](http://www.forbes.com/sites/markrogowsky/2013/09/11/marginal- cost-and-benefit-apples-addiction-to-iphone-profits/)

That's $16b profit on hardware, and $1b profit for all of iTunes (which analysts have claimed is likely similar for all of their various subdivisions); which, even if we took the crazy conservative assumption that that money is almost entirely revenue from the iTunes App Store, is only ~5% of their income.

But, as I bet is true for most of the people you know, I spend _way_ more money on movies and music than I do on apps. Sure, there are "whales" who buy tons of in-app purchases, but "whales" for music are also common, and the cost of a single season of a television show is a massive investment.

Many (not all, maybe not even most, but many) of the people I know also purchase AppleCare, which is $100 per device and allocated to the same revenue bucket. I think this also includes AppleCare for MacBooks, which is $250. The percentage is thereby certainly much much lower than 5%.

You can also look at this in the other direction: the iPhone costs ~$600 (you don't pay all of this to Apple, though, it being subsidized through payments to your carrier), with the income estimates being ~$250. To make Apple as much money as they make on a single iPhone sale you would have to buy 2,500 $1 apps ;P.

 _At that point, Peter Oppenheimer added, "We run the App Store just a little over breakeven," implicitly making the case that the App Store was not a big profit generator for the company._

[http://www.macobserver.com/tmo/article/apple_app_store_runs_...](http://www.macobserver.com/tmo/article/apple_app_store_runs_just_above_break_even)

 _If we add the content margins from music and apps and assume the store runs at break even we can get an idea of what it costs to operate the store. The latest number is $113 million per month (from a total income of $313 million /mo.). It implies over $1.3 billion per year._

 _Much of that cost does go into serving the content (traffic and payment processing). Some of it goes to curation and support. But it's very likely that there is much left over to be invested in capacity increases._

[http://www.asymco.com/2011/06/13/itunes-now- costs-1-3-billio...](http://www.asymco.com/2011/06/13/itunes-now- costs-1-3-billionyr-to-run/)

(One thing to note is that the amount of money they make off this division _has_ changed over time, and people are now sometimes reporting the division to be profitable and no longer mostly be running "break even". However, these reports cite the reason being that Apple's margins on _first-party_ software has increased and is in the same pile.)

 _For this reason, management has begun since 2010 to suggest that at least the App Store is run "a little over break-even". How little is a good question. A one percent operating margin (from gross revenues) would imply as much as $45 million margin. I estimate 2% is possible on Apps and 1% on Music._

 _My estimate is that Apple's own software generated $3.6 billion in Revenues in 2012. As you can imagine, this is a high margin business which grows at nearly 20% /yr. Although I estimate that the software business has been overtaken by the Apps and Music businesses in gross revenues, it keeps an operating margin similar to that of Microsoft or about 50%._

 _This means that iTunes inclusive of Apple's own Software generates as much as 15% operating margin on gross revenues. That's over $2 billion a year._

 _So much for breaking even._

[http://www.asymco.com/2013/03/22/so-long-break- even/](http://www.asymco.com/2013/03/22/so-long-break-even/)

<comment><USER12> Noted. That makes perfect sense - I was missing the bit of data on how high Apple's hardware margins were.

Thanks for the detailed reply!

</comment></comment></comment><comment><USER13> If there is a program that sucks and the maintainer is unwilling to merge your changes that (according to you) make it better, then what choice do you have but to compete? Or are you willing to just let it be and try to live with the shitty program?

Competition is not a choice, you can't just say "please don't compete with me because I'm not motivated by it" and hope it will work. Competition is just something that you have to do if you want your idea of what is right to remain at the top of the ladder.

</comment><comment><USER14> Man, saurik, you need a vacation. You need to not have to think about Cydia, or the community, or maybe even computers at all for at least a week or so.

You're talking about how all of these developments in the community wear on you, and how you view maintaining all this stuff in part as an obligation. I could be reading all this wrong, but I get the impression that dedicating so much of your life to Cydia is going to burn you out eventually, abrasive community or not. You just sound _tired_.

I feel like letting the project sit for a week or so while you take a break and get away from it all may actually be worth it in the long run. You sure as hell deserve it.

<comment><USER15> > You sure as hell deserve it.

Without a doubt. I've spent countless hours myself developing a mod for an old gaming community with some of the most unappreciative manchildren (trolls) in existence, and I saw it through to the end because I felt I had an obligation to finish it. And to this day, there are a handful of people from a subset of that community who blame me for the demise of said subset, even though I did everything they asked.

I learned a lot from it though, and not just about coding and development, but about communities in general. The entitlement that some people feel they have of your time can be astounding. Apparently when you do things for people for free out kindness or out of passion for something, it only leads some (many?) of them to expect you to continue to do it all, until they've sucked every bit out of you that they can. I'm sure this is especially worse in online communities, because to them, you're just text on their screen who provides them with something fun or useful, not a human being.

So yeah. Take a break. A week may not even be long enough. Work on other things, completely unrelated things. It'll give you a fresh perspective and help with realizing exactly how much time and energy of your life you're devoting towards something and how much of it is really worth it.

<comment><USER16> Over the years I've found the more I charge the less grief I get.</comment></comment></comment>


New iPhone beta - <AUTHOR> http://developer.apple.com/iphone

<comment><USER2> No need to wink and nudge--you can have the fruits of someone else's breaking of NDA:

<http://www.tuaw.com/2008/04/23/apple-iphone-sdk-beta-4/>

</comment><comment><USER3> Now we just wait for the release of Pwnage 1.2 from the iPhone dev team (<http://iphone-dev.org/>). Hopefully this build is not as slow and buggy as the previous ones (I know it's beta).

</comment><comment><USER4> Nice, but what I really want to know is: when will Apple start accepting more applications (mine, specifically) for the actual developer program?

<comment><AUTHOR> well... not to violate the nda, but the simulator is getting really nice. wink wink, nudge nudge.

<comment><USER5> i think he's talking about the dev certificates. anybody can download the iphone sdk, but only a handful of people are getting the certs you need to install actual apps on actual iphones.

and even if you're accepted, it sounds pretty brutal. if you offer up your phone for having your own apps installed on it, it becomes more or less unusable for anything but development testing.

<comment><USER2> Seems like $99 + $399 is a small price to pay for access to a whole new market --it's the wild west, or PC DOS time, all over again...

<comment><USER5> the early DOS days were indeed a gold rush. and no doubt, some people are going to get rich on early iphone apps. alas, i think that's about the end of the similarities. the pc platform was wide-open, but apple seems intent on maintaining tight-fisted control of the iphone space.

<comment><USER4> While, yes, I agree that Apple is keeping a bit of a stranglehold over the iPhone application market, that doesn't mean that there isn't a ton of opportunity for developers to succeed, provided they can color within the lines.</comment></comment></comment></comment></comment></comment>


What bandwidth addiction will cost - <AUTHOR> http://seattlepi.nwsource.com/opinion/372888_bandwidth31.html <comment><USER3> Interesting comparison.

Considering that the US hasn't managed to resolve its oil addiction yet, though, I think it's unlikely that this comparison is helpful - except in making people feel helpless.

Could you resolve this without government assistance? Perhaps. Maybe a company could sell a device that can be tuned to use whatever spectrum block is desired, and let people pick which bit of the unused spectrum they want to use. The government can't control what everyone does if everyone is doing it.

</comment><comment><USER4> Terrible, terrible metaphor.

First, power is limited by the laws of nature. A low-efficiency power generator can convert a third of the chemical energy in something like coal into electricity. The best one can possibly do is 100% efficiency meaning we could (should we develop a 100% efficient way to convert energy between forms) triple efficiency, but not more. Bandwidth, on the other hand, keeps seeing increases as things become more efficient.

Second, chemical energy cannot be produced. If I wanted to, I could lay new fiber which increases the amount of bandwidth in the world. So, as demand for bandwidth increases, the amount of bandwidth in the world can also increase. As demand for energy increases, energy cannot increase. In fact, this is the largest problem we're facing with oil. Demand is rising, but at a certain point, supply can't rise - there's only so much oil. Sure, there's only so much fiber RIGHT NOW, but more can be made and laid.

Third, new entrants can enter the bandwidth arena without displacing old hats. This builds nicely off the second. If one can produce new bandwidth, you can enter without taking/diminishing the bandwidth of another competitor. If all the oil in the world is owned, the only way you can enter is to buy or steal the oil from its previous owner. The fact that there aren't a lot of competitors in the arena is more a matter of the huge amount of capital required. However, we already see a ton of people who have laid fiber - <USER2> Summer Street in Boston (a data center) has over 40 different providers connecting through it.

The reason that most of our home connections are a monopoly/duopoly is that home connections form a market known as a "natural monopoly". Take water as an example. It doesn't cost much to provide a marginal unit of water to someone's home. It costs a TON to run water pipes to everyone's home. Likewise, providing bandwidth to people isn't the problem - it's running wiring everywhere in a city. It is actually wasteful to have multiple carriers in the economic sense. I mean, let's say that Comcast and Verizon makes a 50% profit when they're the only games in town gouging customers. Their costs are $1bn for the network and 1cent/GB for usage. OK, so two more companies enter the market and face the same costs. Now each carrier has 25% of the market and no one is making any money because they don't have enough customers to cover the cost of the network rollout/maintenance. There's a reason why it's a duopoly, but it's nothing like oil.

Ideally, someday, municipalities would take over the job of running the cabling to our home like they do with water and then people could just buy bandwidth from the central office to the internet from any number of providers - taking advantage of the economics of both natural monopolies (not building multiple infrastructures) and competition (having bandwidth providers compete on price for my business).

The comparison is simply inaccurate. Energy is a supply-side constricted commodity which means that supply doesn't change relative to demand. Bandwidth increases as demand for it increases - except in one place, wireless. Of course, there's still a lot of airwaves that can be auctioned in the future and wireless carriers have a lot further they can go in efficiency than what we can do with energy.

This story does have one value - it's a great, "you're scared about oil prices, I bet you'll read something I write to make you scared about all your other bills even if I'm full of it" story.</comment>


Graphene: The perfect water filter - <AUTHOR> http://www.extremetech.com/extreme/115909-graphene-the-perfect-water-filter <comment><USER2> On the water filtration front, one thing I'm curious to know is what happened to the LifeSaver bottle. Was that just the victim of TED hype?

<http://en.wikipedia.org/wiki/LifeSaver_bottle>

[http://www.ted.com/talks/michael_pritchard_invents_a_water_f...](http://www.ted.com/talks/michael_pritchard_invents_a_water_filter.html)

From the Wikipedia page: "In 2007, the LifeSaver bottle was tested by the London School of Hygiene & Tropical Medicine and the results found it to completely filter out all bacteria and viruses."

This may be a stupid question, but is that simply nothing remarkable?

Since graphene seems to be the best thing discovered for filtering evaporated water, not liquid water, is the LifeSaver not as great a solution as the TED video makes it out to be, for some reason?

<comment><USER3> The LifeSaver bottle is remarkable but it seems like the filtering process doesn't scale well. Imagine having to use this throughout the day each time you fill up.

My company works w/ a charity in rural India that makes BioSand filters. The filters allow people to clean large amounts of water and then save it in containers for later. 90-95% of the impurities are removed. More info here if curious: <http://faucetface.com/pages/1-for-100>

</comment></comment><comment><USER4> Water filtration is indeed a key survival technology for humanity in the next 50-100 years, so seeing technology already providing possible solutions to the so-called "water wars" of the future is great!

I presume such a filter will also remove all bacteria/etc from the water. So basically, you could grab some water from the Thames, stick it through one of those filters, and drink it. It might lack some minerals, but it won't get you sick.

<comment><USER5> From the article, they are talking about filtering _evaporated_ water through the membrane. It sounds like you will be waiting a long, long time for that drink of water filtered via its gaseous phase through this material.

Regarding bacterial contamination concerns that the posters below discussed, they are likely remedied if the filtration occurs in the gaseous phase of water, though some bacteria can climb substrate walls against gravity so it would be an interesting engineering design challenge.

<comment><USER6> But getting water into the gaseous state is quite easy, by adding heat, right? I realize that takes (quite a lot of) energy, but if all of the water that is heated past vaporization becomes 100% cleaned with no other energy input and no moving parts, that sounds like a rather nifty machine.

I'm sure there are engineering constraints that I'm not aware of, like the filtering clogging up and so on, of course. Still, it sounds almost magical with such a perfect filter.

<comment><USER7> You can do all of that without the filter though. There are very low tech products that already do this. <http://www.celsias.com/media/uploads/admin/watercone1.jpg>

<comment><USER8> The watercone is great for non-potable water that isn't contaminated with compounds that also boil below or near 100 °C and are either in A) high proportion or B) that bio-accumulate.

If the preliminary findings with the graphene oxide are hold true, you could stick a cap made of the stuff on a watercone evaporating a bunch of zombie blood and end up with ASTM Type I water to keep you hydrated after the zombie apocalypse.

<comment><USER9> In order for this statement to be relevant I think you must be of the opinion that zombie blood contains compounds that boil below or near 100°C. Otherwise you still wouldn't need graphene oxide cap.

So I'm wondering if zombie blood is known to have these type of compounds. But more importantly, how common is it for typically impotable water to have these type of compounds?

<comment><USER10> Off the top of my head, I can think of one toxic substance that easily mixes with water and boils below 100°C: methanol.

Some hydrocarbons might also fit the description.

<comment><USER7> You're right, which would explain why they experimented with vodka. It seems this filter is better at filtering water _out_ of a substance, rather then filtering _substances_ out of water.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> As a research who has worked with graphene. I would like to point out that Graphene oxide and graphene are two very different materials in terms of properties and synthesis.

The graphene oxide mentioned in this article tends to exhibit weaker electrical and mechanical properties than graphene oxide but is much easier to synthesize than conventional graphene, and so a future with graphene oxide products is not as far as away as one with real monolayer graphene.

<comment><USER12> FTA:

> _Now, technically graphene oxide isn't quite the same thing as graphene, but > in a good way: graphene oxide is much easier to make._

</comment></comment><comment><USER13> Evaporated water is already very clean. I would like to see this material tested as a regular filtration mechanism. Normally filters are rated by the size of molecule they allow to pass through them, flow rate and how many liters of water they can filter before it is necessary to replace or clean. I would also like to point out that filtration and sterilization are different processes. Filtration is usually a mechanical process and sterilization is normally done chemically (although not always).

</comment><comment><USER14> Original story: [http://www.sciencedaily.com/releases/2012/01/120126100639.ht...](http://www.sciencedaily.com/releases/2012/01/120126100639.htm)

</comment><comment><USER15> How can I make graphene? How's it made? What do I need?

<comment><USER16> Apparently you can make it with a pencil and some sticky tape: <http://youtu.be/LwmxSjydPEE>

edit: here they are in the lab at Manchester using a similar technique: <http://youtu.be/ehvksWx3AJQ>

</comment></comment><comment><USER17> This article only makes fun about making hard liqueur this way, but this could really revolutionize that business. Normal distillation is very violent procedure that unavoidably affects the taste. It would be possible to produce large amounts of rum just by leaving sugar cane juice in glass bottles to sunlight for a couple of months, with every bottle sealed with grapheme oxide.

</comment><comment><USER18> How much does it currently cost to obtain a 16cm^2 sheet of graphene oxide?

</comment><comment><USER19> I hope this works as proclaimed - the only two questions i have left are: do traditional desalination techniques require more energy than boiling the equivalent amount of water? if so, this might indeed be a breakthrough. and the second question: will the membrane ever need to be replaced?

<comment><USER20> "do traditional desalination techniques require more energy than boiling the equivalent amount of water?"

No, far less, because the end product is condensed liquid water (not vapor). When* the desalination method is distillation (evaporating + re-condensing), the heat used to evaporate water is released again when the steam is condensed, and can be recovered and reused. E.g. [1]. The real-world figure wikipedia cites is about 90 MJ/m^3, compared to about 2,250 MJ/m^3 for boiling water at STP [2]. The theoretical limit from thermodynamics -- the minimum energy needed to separate salt and water -- is about 3 MJ/m^3 for seawater [3] (or [4-5]).

*(as opposed to methods like reverse osmosis [6], which is forcing water through a filter with atom-sized holes -- no boiling involved)

[1] <http://en.wikipedia.org/wiki/Multi-stage_flash_distillation>

[2] [http://en.wikipedia.org/wiki/Enthalpy_of_vaporization#Other_...](http://en.wikipedia.org/wiki/Enthalpy_of_vaporization#Other_common_substances)

[3] [http://http://www.sandia.gov/water/docs/MillerSAND2003_0800....](http://http://www.sandia.gov/water/docs/MillerSAND2003_0800.pdf)

[4] <http://en.wikipedia.org/wiki/Enthalpy_change_of_solution>

[5] <http://en.wikipedia.org/wiki/Seawater>

[6] <http://en.wikipedia.org/wiki/Reverse_osmosis>

</comment></comment><comment><USER21> Would this include other areas of water purification such as softening and desalanization?

<comment><USER22> I don't think graphine oxide would be as applicable in the near future since these experiments use water vapour and pass it through the membrane, meaning that you already need to expand energy to heat up all that water, and there already exist more efficient methods of desalinization.

</comment></comment><comment><USER23> Four words: water recycling in spacecraft.

<comment><USER24> Now we just need SOMETHING to identify those Cylon sleepers that are going to blow up the water tanks...

On a more serious note, there certainly are regions on EARTH that could dearly use such a filter before we jump on building spacecrafts.

</comment></comment><comment><USER25> "finds that graphene capillaries either shrink in low humidity or get clogged with water molecules"

How useful will the filter be if it gets clogged? Reverse Osmosis needs high pressure and produces much less water than it takes in, then it needs remineralization. Same situation?

Maybe it will be better for filtering steam or air.

<comment><USER26> Exactly. I can see this being useful in, say, coal power plants which release a lot of water vapor, but also a lot of toxic chemicals. If one could develop a useful filter from this, could the burning of coal actually become a clean source of energy?

<comment><USER27> Coal can't be "clean" unless you can find a place to put the vast amount of carbon dioxide.

<comment><USER28> Use it to make more graphene oxide, obviously.

</comment></comment></comment></comment><comment><USER29> I keep seeing articles about all the wonders of Graphene (and its derivatives, like Graphene Oxide). When will I actually see any of these wonders affecting my life?

<comment><USER30> Yes. Previously this role was played by carbon nanotubes.

Even supposing we work out a way to manufacture graphene cheaply, it seems to me that there are lots of technical solutions to problems out there which remain undeveloped for lack of a viable financial model (or simply bad luck I suppose).

</comment></comment><comment><USER31> This is what I've always used <http://www.steripen.com/>

</comment><comment><USER32> This website loads the full desktop page before redirecting to the mobile version.</comment>


Yelp.com Stands Accused of Acting Like a "Modern-Day Mafia" - <AUTHOR> http://www.browardpalmbeach.com/2010-04-22/news/yelp-com-stands-accused-of-acting-like-a-modern-day-mafia <comment><USER2> _Every_ business has good and bad interactions with customers. For most businesses the bad ones are unfortunate but isolated cases. For those where it's a pattern, they'll eventually lose enough business that they'll change or die.

What yelp has done is to artificially magnify the effect of an individual complaint. Most people don't bother to write publicly one way or the other, and (I think) people with a negative experience are more likely to complain publicly.

The effect of yelp is "world changing" in some sense; they make it easier for perfectly good businesses to go out of business. Not really what I'd want my life's work to be, but to each his own, I guess.

<comment><USER3> Yelp's data would seem to indicate that users with a positive experience are more likely to write a review: <http://www.yelp.com/press>

<comment><USER4> I wonder if those figures are massaged, considering everything else going on!

<comment><USER5> Amazon has observed exactly the same behavior. The average review for something on the internet is 4.5 stars.

<comment><USER6> What about astroturfing by product vendors?

</comment></comment></comment></comment></comment><comment><USER7> And I'm supposed to let Facebook connect my profile to this site with it's OpenGraph?

</comment><comment><USER8> Unlike many lawsuits, this one is a testable hypothesis. It is knowable whether favorable reviews disappeared, whether an algorithm or person triggered the disappearance, and whether this occurred after a sales-rep made contact. The phone logs, syslogs, and code repositories should reveal the truth in this case.

</comment><comment><USER9> I see more "People Love us on Yelp" stickers in a 10 minute walk around SoMa than the 10 people who have joined this lawsuit. What's browardpalmbeach.com anyway? This article is just an echo of the hundreds of other articles from more reputable sources about this topic.

<comment><USER10> This one has allegations I haven't seen before. I've heard that yelp offers to rearrange reviews or remove one or two bad ones if you buy advertising, which sounds a little dodgy. I've never heard of it threatening to remove _good_ reviews if you _don't_ buy advertising. I'm more skeptical of that one.

</comment></comment><comment><USER11> _The company, which has yet to turn a profit despite astounding popularity_

Really? How is this possible?

<comment><USER4> It's a tech startup silly. Are you suggesting these companies focus on making money??????

What the hell are you smoking!!!

*sarcasm</comment></comment>


Apple Reports Second Quarter Results - <AUTHOR> http://www.apple.com/pr/library/2016/04/26Apple-Reports-Second-Quarter-Results.html <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11575497](https://news.ycombinator.com/item?id=11575497).

One can make a case for either article being better, but the other discussion was higher on the front page, and people obviously consider this an important story.</comment>