delluminatus
For example, humans evolved to be social creatures. Interactions with other humans impact our body chemistry in dramatic ways. I want to avoid loneliness, so I selfishly hold relationships with others. I want to hear people say "thanks" to me, so I selfishly give people gifts. I want to be able to be righteous without hypocrisy, so I selfishly stick to my principles.
Just my two cents. There are a lot of different types of desire in the world. Who's to say that UBI wouldn't be in folks' best self-interest?
I find this is effective even if you actually do want them to change their decision. Come in with a compliment, then try to lead them to recognize the flaws in the decision themselves.
In my experience, H.N. comments have a lot of wrong. But when the content is good, it can be truly great.
If they are running multiple Docker containers, the improved efficiency would allow them to run more containers per host computer. Maybe that's what they meant, although it's not really horizontal scaling either.
Having said that, thanks for the interesting digression. You've made me want to try out ipfs.
This is especially bad for Samsung, I think, because it doesn't just affect folks with a Note 7 -- everyone waiting at the gate hears the announcement. Talk about negative brand associations.
A Pi, though, couldn't do well at all, just like you said. If I wanted to build a system like this for myself, I would target an HTPC form factor.
edit: Another possibility, which was explored elsewhere in this thread, would be to keep the listening device "thin", but have the ability to offload the processing to a machine in my LAN instead of one the "cloud".
Applications behave consistently because all state is stored in a single object, so it can't be desynchronized across components. Because all updates use a single function, it becomes easy to track and respond to any state changes by applying middlewares to that function. Things are more testable because all state is available for stubbing, and because the "reducer" is a testable, pure function typically composed of many other smaller, testable pure functions.
Things like time travel become possible because of the purity of the reducing function. Since it's pure, it can't modify the old state object (technically, it can, but it's against the rules). So in theory, we can undo any state change simply by loading the old state object from where it's being stored by some kind of history middleware.
Also, sometimes even just using console.log can cause bugs to appear or disappear. I recently encountered a bug which was almost impossible to diagnose with console.log, because the string returned by the .toString() call didn't correspond to the real object's actual properties. Of course, this is a rare case, but it highlights the benefit of trying different tools!
More to the point, I think that definition is a little dissatisfying. By that metric, I have probably never created any art in my life -- because I'm not an artist with limited-edition work in a gallery. To me, that is unacceptable for a definition of art. Artistry is something more intrinsic to human nature than just being a thing made by an "artist" and put in an artistic context to be admired by hipsters and to confuse people.
Suppose a trolley is barelling down a track towards five tied-down people. If it continues, it'll kill them. But, you have access to a lever which would send the trolley down a side-track instead. But the side-track also has one person tied to it. By pulling the lever, you are effectively murdering that helpless, innocent person -- but you would save the other five. If you don't touch the lever, then you are just an innocent bystander who happened to see a quintuple homicide.
In this case, if you insist that murder is evil, and you refuse to be evil, then you have no choice but to let the five people die. But if you allow that murder is sometimes okay -- which is a utilitarian perspective, in the sense that you care more about the ends than the means -- then it becomes much fuzzier whether murder is inherently evil. Indeed, as soon as you give an explicit definition for evil, it becomes very difficult to defend it. The fact of the matter is, the good/evil dichotomy is false and artificial.
To someone who's never experienced it, it might seem like having no work would be great, but it's actually terrible for our sense of self-worth in my experience. A surprising number of people are too afraid to leave a position even if they feel it's soul-sucking. It takes serious guts to leave a steady job even if it sucks.
Good luck finding a more exciting position!
Also, I haven't written any books, but I wonder if Markdown is the best choice for a canonical format. The syntax is lightweight but also limited. For example, it doesn't support tables, and doesn't differentiate between source code (which should be syntax highlighted) and literal text (which shouldn't). You could define your own extensions, of course, but that breaks the compatibility feature. I think reStructuredText (for example) might be a better choice, although Emacs' Org-mode is my personal favorite document format. I suppose that in the end, whichever's most comfortable for the author to write in is the best.
edit: I should mention that this is in reference to a technical book because I've been thinking about technical writing lately. It just occurred to me that you could be writing the type of book that doesn't need tables or source code, in which case Markdown is probably perfect.
I also find it interesting that you claim that humans don't notice latency under 100ms as though it is established fact, considering the OP spends basically the whole first section trying to debunk that incorrect but commonly quoted belief.
I think the really difficult problems for that project will probably be importing data into the model (i.e. semantic analysis of content) and scaling the model to a great enough extent for the real benefits of using a semantic structure to appear. The problem of defining a networked object model is arguably already solved, but I don't think there are any solutions that could scale to the extreme number of concepts and connections that such a system would require.
I also have to say, that site really made me want to use Smalltalk as a PIM for some reason.
The main benefits of Cycle.js in my eyes are:
1. Emphasis on a single entry point for event handling instead of a million separate event handlers. This is similar to the idea of the "Dispatcher" in Flux -- it's a central handler that manages all user input. But the Flux dispatcher has a specific purpose, whereas the main Cycle handler is more generic (which is, in my opinion, preferable).
2. Use of reactive programming, which is an extremely powerful paradigm in asynchronous environments like the browser. It takes a while to wrap your head around reactive programming but once you do it's absolutely fantastic. The only concern I would have here is that Rx.js adds overhead that might be unnecessary in some cases. But then I guess you would just use a more lightweight framework., so it's not exactly a criticism of Cycle.