I created the same app with React and Redux - <AUTHOR> https://medium.com/@sunilsandhu/i-created-the-exact-same-app-with-react-and-redux-here-are-the-differences-6d8d5fb98222 <comment><USER2> This article isn't really a comparison. It's almost completely dedicated to explaining Redux. In fact the complexity of explaining even this simple app with just a couple of components, should serve as a reminder of how complex Redux is. The only real mention of the plain ReactJS version is near the end, where it actually links to _another_ article which compares ReactJS and Vue.

<comment><USER3> Redux isn't complex. It's a philosophy on how to manage state, and a few simple concepts to realize that philosophy (store, reducer, action, ...). It has nothing to do with React. Articles which effectively explain Redux by wading through the minutiae of a boilerplate app are anathema to that goal.

If anyone reading this wants to learn Redux, just read the getting started guide, or watch the co-creator's video series.[1] It's wonderful. If anyone just wants a TL;DW, here's mine:

1\. The state of your application should be a tree. This tree is immutable. We call it a store.

2\. Each branch of your state tree is generated by a pure function of the previous state and an action. We call these reducers.

3\. The only way to effect change in your state is to dispatch actions. Dispatching action X triggers the root reducer for action X (which triggers the child reducers with action X, etc.), giving you the next state.

4\. Subscribe to store changes with listeners.

That's really it. A general roadmap for managing state in your software. Has nothing to do with React. Or with user interfaces. Just a general approach to software state. You can roll your own in a few minutes for your use-case. If your use case _happens_ to be a React UI or C# app, then yeah, reach for React-Redux or Redux.NET respectively.

But please, please don't learn Redux initially by looking at a React app that uses React-Redux. That's hardcore jumping the gun.

[1] [https://egghead.io/lessons/react-redux-the-single- immutable-...](https://egghead.io/lessons/react-redux-the-single-immutable- state-tree)

<comment><USER4> Yes, Redux is easy. The problem is the incredible amount of boilerplate and repeated code in most tutorials and beginner projects, in the form of actions, switch statements and ALL_CAPS_STUFF.

That boilerplate can easily take 10x more lines than "real" code in reducers, even in complex applications. Requiring three different files for each reducer, as in the article presented, is completely overkill, and it only makes sense when you're getting paid by the line of code.

However, there are great solutions to avoid that. I'll echo the recommendation of createSlice:

[https://redux-starter-kit.js.org/api/createslice](https://redux-starter- kit.js.org/api/createslice)

<comment><USER5> > Requiring three different files for each reducer, as in the article > presented, is completely overkill

He only has one [0]. Note that the parent directory is "redux", not "reducer" \- the actions and actionTypes are separate from the reducers, because there isn't a 1:1 relationship. This separation is because you could, for example, have a second reducer that listens to the same Add action as the one in this example - it doesn't need it's own action or actionType.

[0] [https://miro.medium.com/max/1383/1*JsqDyA2Wy_08GnHS6SMDmw.pn...](https://miro.medium.com/max/1383/1*JsqDyA2Wy_08GnHS6SMDmw.png)

<comment><USER4> While you're technically correct, this is exactly what's overkill.

Actions and ActionTypes are pure noise.

And idk, having multiple reducers responding to the same action is a recipe for trouble.

<comment><USER6> I'll disagree with you on that last point. We specifically encourage that pattern - treating actions as "events" that any part of the reducer logic can respond to independently, rather than "setters".

Now, it's certainly true that _most_ actions will only be handled by a single slice reducer, but having many slice reducers responding to the same action is an incredibly useful pattern:

[https://redux.js.org/faq/actions#is-there-always-a-one-to- on...](https://redux.js.org/faq/actions#is-there-always-a-one-to-one-mapping- between-reducers-and-actions)

<comment><USER4> I do get the point of it being this way, but my problem with it is that it feels too much like magic, I think I just prefer to have the 1:1 relationship, like I already do with javascript functions or HTTP calls.

But even leaving that aside, I still think that this specific "feature" is not worth the amount of boilerplate you need in most Redux apps, so it's not a nice tradeoff IMO :(

I worked in some bigger apps, and before adopting ducks (and later a homebrew version of createSlice) we had some bugs caused by multiple reducers firing.

I also think that it makes Flux/Redux a bit harder to explain

<comment><USER7> You're not alone in this.

Redux isn't complex, it's _complicated_ \- needlessly so.

It takes just one look at its competitors to see this.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This app is way too simplistic to yield any benefit from state management. This reads more like an intro to redux than a comparison of building apps with vs without redux.

<comment><USER9> From the bottom of the article:

>But wait, where is the app that just used React? I thought this was a comparison piece?

>This article is really a beginner's guide to Redux to demonstrate how you would go about adding Redux into an existing React app.

</comment></comment><comment><USER10> Every React + Redux I've worked with were needlessly bloated & slow. I think that there is something that leads to bloat and slow performance in the react+redux world, but I can't quite identify it yet.

<comment><USER11> I have had exactly the opposite experience. I recently rolled onto a React project without Redux and the code was pretty gross. Multi hundred line React components with markup, API calls, and business logic all mixed together in an untested and untestable cocktail garnished with a heavy dose of prop drilling and deeply nested callbacks.

Adding Redux to this app was a huge improvement. Test coverage is now almost 100%. The views are now tiny and simply render props and dispatch actions. Complex workflows are handled beautifully by Redux sagas. Overall, the codebase is now one of the cleanest I have ever worked on.

I am not saying you have to have Redux to have a good frontend codebase, but it definetly helps a lot. If your app is even remotely complex, its hugley helpful to have a global data store. If you are going to have workflows with asynchronous components, Redux sagas are an incredible tool.

My hunch is that the apps that don't use Redux either 1. suck or 2. have had some smart person hand roll a framework that has most of the core principles of Redux in it. I am not that smart, and I don't want my codebase to suck, so Redux is the best choice for me.

<comment><USER12> Have you used redux-sagas on any projects before this one? How do you feel it compares with redux-thunk?

I've used redux-thunk for all of my past projects but recently inherited a project using sagas. It seems to be pretty unorganized and I'm wondering how much effort I should put into cleaning it up, if it's even possible.

<comment><USER13> I far prefer redux-sagas personally. I find the generator/yield style to really reduce the mental overhead of a saga's flow as compared to a thunk.

<comment><USER14> Have you tried thunks using async/await? IMO its all the benefits of being easy to read and understand without having to learn a totally new concept (generators).

<comment><USER6> Yep, agreed. The biggest missing capability there is being able to _respond_ to dispatched actions, which thunks can't do. But, most apps don't immediately need to do that anyway.

</comment></comment></comment></comment></comment></comment><comment><USER15> React and it's cousin in tow, Redux put food on my table. But like a famous HN comment said: how many startups have been burn out due to the complexity of wiring up those two powerful tools. I think frankly, when comparing frontend frameworks the benchmarks should be 1. lines of code, since that determines delivery 2. ease of maintenance as that enables easy to add new features 3. how fast the app executes on the customers device. And frankly React + Redux results in writing a lot of code

<comment><USER16> I agree, but with CRA + JSX + React Hooks _usercode_ is a lot terser. I tried React around 2014-2015 and hated it, now I really like it. Besides declarative programming, styled components has been a life changer for the better.

I'm still torn with Redux though, seems great for big projects/teams, but total overkill for small ones. I wrote a small alternative for my personal projects ([https://github.com/franciscop/statux](https://github.com/franciscop/statux)), what do you think about how it'd fare with your points? Looking for improvements, and I saw a bug once (though I haven't been able to reproduce and not 100% sure it was within the lib).

<comment><USER8> This is super true, React/Redux with hooks is really nice to work with. If you use the redux hook it is super apparent what is coming from store, what is coming from external props and what is internal state.

It makes it dead easy to cold read a components functionality and super simple to detect code smells.

</comment></comment></comment><comment><USER17> With the useReducer hook a lot of these differences have gone away. The important difference is that redux will use global state. It's use of the Context API makes components less portable.

Redux has it's place, I think it's structure can be nice at times, but you pay for it. This app is not anywhere near the size where I would consider using Redux though.

<comment><USER18> I find where redux shines is when you move past the trivial app (which TODO mvc style apps are). Especially if you're sharing various portions of state between components at different levels and routes.

You have hooks for redux too, the following is at the top of pretty much all my main components.

        import { useSelector } from 'react-redux';
        import useActions from './ComponentActions';

In my *Actions file, I export a wrapper for the actions individually, which makes using actions pretty straight forward...

        import { bindActionCreators } from 'redux';
        import { useDispatch } from 'react-redux';
        import { useMemo } from 'react';
        ...
        export default deps => {
          const dispatch = useDispatch();
          return useMemo(
            () =>
              bindActionCreators(
                {
                  someAction,
                  anotherAction,
                  ...
                },
                dispatch
              ),
            deps ? [dispatch, ...deps] : [dispatch]
          );
        };

I also rely pretty heavily on redux-thunk, which lets me do simple workflows for async...

        export const someAction = (input1, input2) => async (dispatch, getState) => {
          try {
            dispatch(someActionStart());
            const result = await api.area.someCall(input1, input2);
            dispatch(someActionComplete(getState(), result));
          } catch(error) {
            dispatch(someActionError(getState(), error);
          }
        }

I'd probably use saga if I ever needed anything much more complicated, which is rarely the case.

In general, I tend to feel that following a few consistent patterns with Redux tends to let you avoid a lot of problem cases dealing with state compared to other options. Also, I tend to inject an intercept into my root reducer, this way I can force dispatch a starting state for purposes of integrated browser testing (gets deep-merged with current state).

        beforeEach(async () => {
          base = await page.evaluate(() => {
            // set store to a different initial state
            __STORE__.dispatch({ type: '__TEST_OVERRIDE__', payload: startingState });
            ...
            return __BASE__; // <-- injected configuration via server
          });
          ...

</comment></comment><comment><USER19> I ask myself this a lot, are all the boiler plating you have to do for Redux "really" necessary just to have state management?

Can we try combine the actions, types, and reducers into a single domain so they aren't seemingly repeated in 3-4 different locations. Maybe an option to combine or separate as needed.

I know there are alternatives like Mobx and even the newer React Hooks so this seem to affirm my thinking that it might not be all necessary.

And I personally haven't seen any benefits from all the separations you do in Redux at least from projects I've worked on, all it led to was verbosity and more typing. It tend to make code more prone to mistakes and harder to follow.

If I see the benefits, I wouldn't mind but either I don't see it or haven't seen it yet. It just feels a bit like pre-mature optimization or over- abstraction.

<comment><USER6> It's definitely _not_ necessary, and that's exactly what our Redux Starter Kit package can help with! See the `createSlice` function in particular:

[https://redux-starter-kit.js.org/api/createSlice](https://redux-starter- kit.js.org/api/createSlice)

[https://redux-starter-kit.js.org/usage/usage-guide](https://redux-starter- kit.js.org/usage/usage-guide)

<comment><USER19> Thank you! I didn't know you guys were even attempting to tackle this problem.

Looking forward to seeing more improvements in this area.

</comment></comment></comment><comment><USER20> A while back I was building a large application for an internal team at my company. It got to the point where local state was just not solving all of my problems so I started to explore Redux. I had been creating React apps for several years but I could not wrap my head around Redux - it was far too much complexity adding all sorts of actions, reducers, boilerplate, etc. I started looking for alternatives and stumbled upon Mobx which I liked much better and have been using ever since.

Mobx-react[0] felt like much less work with virtually the same outcome. You create a single (or multiple stores), pass it into your app with a

        <Provider Store={store}>
            <App />
        </Provider>

and you are off to the races. When adding the global state to a component, it was super easy:

        export default inject('Store')(observer(MyComponent))

        Or use decorators (requires ejecting create-react-app or modifying the webpack configuration settings):

        @inject('Store')
        @observer
        class MyComponent extends Component {...}
        export default MyComponent

Accessing the store:

        const {myValues} = this.props.Store

In the store you organize your code by observables (global variables), actions (functions that modify observables) or computed (highly optimized functions that return values derived from state). I treat it as a "source of truth" in a single file.

        import {observable, action, computed, decorate} from "mobx"

        class Store {
            // Observables
            myValues = [0, 1, 2, 3, 4]

            // Actions
            addValue = num => myValues.push(num)

            // Computed
            get getTotal() {
                return myValues.reduce((total, cur) => total + cur)
            }
        }

        decorate(Store, {
            myValues: observable,
            addValue: action,
            getTotal: computed
        })

        const store = new Store()
        export default store

In the end I felt that my code was far more readable and maintainable but your miles may vary.

Here is a relatively simple example of how to use mobx-react demonstrating an observable, action, and computed: [https://www.codementor.io/susanadelokiki/managing-state- with...](https://www.codementor.io/susanadelokiki/managing-state-with-mobx- iqax3wp63)

[0] [https://github.com/mobxjs/mobx-react](https://github.com/mobxjs/mobx- react)

<comment><USER21> I can attest to the genius that is MobX. Having worked on a frontend project built with RxJs + React for nearly two years, I feel like I have kept all of the benefits of reactivity and discarded a lot of complexity and learning curve that mostly came from RxJs.

The API surface of MobX is a breeze, and it kind of pushes you into the pit of success.

</comment></comment><comment><USER22> I've been rewriting one of my hobby projects. I'm going from vanilla javascript to react as a newbie in react. The project isn't even close to being finished when I started the task of rewriting a month ago and the main thing I've noticed is improvement in code structure.

I think someone would have a better time getting their head around the code now and without me guiding them than before. Although the project was already well organized. I make directory structure and naming conventions a high priority/OCD obsession. I think thats mainly why my hobby projects never see an end.

Unlike the author I haven't went with Redux and I've been just using react context with hooks for passing data. I'm really pleased with react context because now things are even more organized than without using context. The only downside with react that I've encountered is trying for the least amount of re-rendering when context changes. I've been reading a lot of optimizing react blogs online. I'm trying to make the app realtime focused with websockets and I don't want to face a difficult situation later on where many users blows up the app to a crawl. Anyway I just wanted to express context is really useful so far.

</comment><comment><USER23> If anyone here is familiar with the game factorio ... not using redux feels like conveior belts vs redux being flying robots. Suddenly everything seems easy and accessible. And writing spaghetti is nearly impossible.

If you ever intend to hire another person into a mature app using redux, he/she is gonna love you for presenting all state via dev toolbar on a silver platter.

<comment><USER24> +1 for the factorio reference

</comment></comment><comment><USER6> Hi, folks. I'm a Redux maintainer. Wanted to let everyone know about the two major things we're working on at this point.

First, we have a new official package called Redux Starter Kit [0], which is our recommended toolset for writing Redux apps with less boilerplate. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing _any_ action creators or action types by hand.

RSK is useful for both folks who are new to Redux and experienced users, and can be used day 1 in a new project or incrementally added to an existing project. I'd strongly encourage anyone who's using Redux to try it out. In particular, I'd suggest reading through the "Advanced Tutorial" page [1], which demonstrates how to use RSK with TypeScript, thunks for async data fetching, and our new React-Redux hooks API. You might also want to read through the issue comment that lays out my "Vision for Redux Starter Kit" and the problems it's meant to solve [2]

I just published RSK v0.8 this evening [3] which has a couple small breaking changes (primarily renaming a `slice` field to `name` and making it required). After that, I'm hoping to nail down a couple last bits of configuration, and then push it to 1.0 within the next week or two.

After that, we're going to start working on a major revamp of the Redux core docs. You can see my planned outline here [4]. The goals for the docs revamp include:

\- Updating the tutorials, including removing outdated concepts like references to "Flux", distracting mentions of terms or warnings that beginners don't need to worry about, adding diagrams, and finding ways to improve the explanations (like changing the "Middleware" page to explain how to _use_ middleware, rather than why they work this way). We will also add a tutorial section that shows how to use Redux Starter Kit, and recommend that people use it as the "default way to use Redux".

\- Adding a "Real World Usage" docs section. This would include topics like choosing async middleware, debugging, folder structures, performance, and so on.

\- Adding a "Style Guide" page. The Redux docs are deliberately unopinionated about things like folder structures, async middleware, structuring actions and reducers, and so on. However, we'd like to provide some official guidance on our current recommended best practices. The Vue docs have a great page with their recommendations, why they recommend certain patterns, and how strongly they recommend them, and we'd like to do the same thing here. For example, we'd recommend using a "feature folder" or "ducks" pattern for structuring files, treating actions as "events" instead of "setters", and trying to put as much logic as possible in reducers.

\- Adding a "Thinking in Redux" section. This would include concepts like mentally modeling actions, the history of Redux and its inspirations, how it's meant to be used, and why it works the way it does.

I'd love to have additional help from the community in working on this docs revamp - I certainly can't do it all myself :)

Finally, I'd encourage folks to watch my Reactathon 2019 talk on "The State of Redux" [5], where I talked about Redux's market share and how it compares to other tools, as well as future directions for the library. In addition, my post "Redux - Not Dead Yet!" [6] addresses some common questions about how things like hooks and GraphQL relate to Redux.

If anyone's got questions, feel free to ask!

[0] [https://redux-starter-kit.js.org](https://redux-starter-kit.js.org)

[1] [https://redux-starter-kit.js.org/tutorials/advanced- tutorial](https://redux-starter-kit.js.org/tutorials/advanced-tutorial)

[2] [https://github.com/reduxjs/redux-starter- kit/issues/82#issue...](https://github.com/reduxjs/redux-starter- kit/issues/82#issuecomment-456261368)

[3] [https://github.com/reduxjs/redux-starter- kit/releases/tag/v0...](https://github.com/reduxjs/redux-starter- kit/releases/tag/v0.8.0)

[4] [https://github.com/reduxjs/redux/issues/3313#issuecomment-45...](https://github.com/reduxjs/redux/issues/3313#issuecomment-450601554)

[5] [https://blog.isquaredsoftware.com/2019/03/presentation- state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of- redux/)

[6] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead- yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

</comment><comment><USER25> Redux isn't complex. It provides a simple way of doing state management. React-redux is slightly more complex, but only because the docs give the horrible advice of grouping things by type instead of domain. Using the "ducks" pattern is vastly superior and simplifies a lot. It also hurts, I think, that most people create actions and reducers that are 1:1. Those should be different things.

Hooks, imo, simplified a lot of these issues.

<comment><USER6> Yep, we're gonna change the tutorials and examples as part of the docs revamp to emphasize "feature folders" and "ducks".

It's admittedly hard to come up with examples of actions that _aren't_ a 1:1 mapping in a small tutorial app, but maybe we can figure something out.

Related FAQ:

[https://redux.js.org/faq/actions#is-there-always-a-one-to- on...](https://redux.js.org/faq/actions#is-there-always-a-one-to-one-mapping- between-reducers-and-actions)

</comment></comment><comment><USER26> Essentially redux is programming the state part of your app outside your UI and having an immutable approach where given a state X with Y action, Z will always result so its good for testing. This does allow you to reuse the redux parts in different frameworks quite easily but I have never done that myself. I personally find redux to be heavy for most apps as most apps are small but in teams redux shines.

</comment><comment><USER27> If you find Redux "Too complex" or you feel "it requires too much boilerplate" then this is a clear indication you don't need Redux. The real use-case for Redux is highly complex applications, if you're using redux for your todo app then of course the cost/benefit ratio for you is not gonna work out

</comment><comment><USER28> Thanks, I'll keep using QML ([https://github.com/jcelerier/TodoMVC- QML](https://github.com/jcelerier/TodoMVC-QML)) ;p</comment>


Anthem Breach May Have Started in April 2014 - <AUTHOR> http://krebsonsecurity.com/2015/02/anthem-breach-may-have-started-in-april-2014/ <comment><USER2> Is the 80 million stolen Social Security numbers figure quoted in this article accurate? I had no idea it was so high...that's 25% of the population of the US!

<comment><USER3> At some point, I think we just have to stop pretending that SS numbers are a secret piece of information. Maybe we should just publish them all and be done with it.

<comment><USER4> SSNs are _identifiers_ but not _authenticators_.

The _benefit_ to use of SSNs is that they're assigned by a central authority which does a pretty good (though not perfect) job of ensuring that there's a 1:1 correspondence of SSN to person.

The issues of how they were to be used _other_ than by the Social Security Administration has been up in the air for a long time. I remember in college when "student identifiers" were just SSNs, and grades and other student data would be posted on office doors by Student ID (that is: SSN). That started getting phased out in the 1990s. There's the matter of the namespace -- it was kept intentionally small, and SSN exhaustion is something that will be faced eventually -- the space is sufficient for "several generations", some 450 million have been issued. The total namespace is around 890 million numbers.

The problem is that when you sign up for new services (online, financial, other), there's a _desire_ though often not a specific _need_ , to associated an _account_ with a specific _person_. And so the SSN gets drafted to serve that purpose, as a _proof_ of identity, not as an _identifier_ based on _other_ proven identity.

It's a misuse of the identifier

<comment><USER5> Don't pretend that the government is without fault here. There's plenty of tax fraud that happens using social security numbers. People can steal your tax refund or even evade taxes by pushing them onto you through your social security number. The system is messed up, and the government is largely responsible for the mess. The Social Security Administration has to same security holes.

What you describe is ideal, but it's not what actually happened. The social security number has been used as identifier and proof of identification for a long time. Part of the problem is that it's from a time when technology did not allow anything more complicated. That's no longer an excuse though. Social security numbers should have been upgraded long ago.

</comment></comment></comment></comment><comment><USER6> Does anyone know why Anthem's clients have not been notified, at all, yet?

I am part of Anthem and I have heard literally nothing directly about this, it's all been through news/tech sites.

<comment><USER7> Anthem has stated that they will not be calling or emailing clients and you should check their site [http://AnthemFacts.com](http://AnthemFacts.com) for updates. (why that site is not protected by ssl I have no idea)

If you do get contacted personally it's a safe bet it's a phishing attack.

Our Company is affected and all our interaction has been through HR. I would contact your HR department.

<comment><USER8> Well, you need to correct this a bit.

Anthem will not be emailing individuals, but apparently _will_ be sending a snail-mail packet of information including an offer for credit-monitoring services. And they have been contacting, via email, the benefits/HR people of client _companies_ which used Anthem for group health plans for their employees.

(that all comes via my employer, which has been sending me updates about this)

</comment></comment></comment><comment><USER9> As long as U.S. laws fail to impose significant costs for data security breaches, we can expect companies to treat the costs of these breaches as the cost of doing business--just as they do with litigation costs for faulty automobile parts, manufacturing pollution, and the like.

<comment><USER10> even in tech companies (even Google) security is handle like that

<comment><USER11> I doubt Google-esque companies would store a users table with foreign keys to social security numbers, street addresses and phone numbers unencrypted (FDE does not count as it's for hardware loss, not data loss) or at least without some kind of base-level ACL, but I would love to be surprised.

Much of the data I presume that Google deals with is not sensitive enough to warrant the kinds of encryption that a health provider company should use. My search data and even my Google+/YouTube/Gmail accounts are enough to tie them to my person, but not my identity. I, or someone masquerading as me, cannot open a line of credit with my Google account at a bank.

<comment><USER12> Eh there was a story about Google leak of SSN a few years back on HN. I'll see if I can dig it up. I'm sure they've learned since then of course.

Edit: This wasn't it, but interesting nonetheless: [https://news.ycombinator.com/item?id=2254394](https://news.ycombinator.com/item?id=2254394)</comment></comment></comment></comment>


Ask HN: What is your morning routine? - <AUTHOR> I'm curious what people's morning routines are. Has there's been a particular change that you've made regarding what you do in the morning that you have found beneficial? <comment><USER2> I get my youngest up at 6:30 while the rest of the house is asleep. We watch some cartoons for 15 minutes then she helps make my coffee (Nespresso; purple, her choice). We watch a few more minutes of cartoons. I take her up to Mom, get changed and ready. Then, it's making my eldest daughter's lunch and out the door to catch the bus to work at 7:10.

</comment><comment><USER3> Up anywhere from 4:30 to 6, out the door anywhere from 7 to 8:30. Take meds that should be taken before I eat ... wait ... eat plain greek yogurt or oatmeal ... take meds that should be taken after I eat. Coffee, read news and HN during all that. Work on something if I'm working on something. Put in my teeth and go to work.

</comment><comment><AUTHOR> On a workday, I find that unless I have something specific booked in the morning it'll take me an hour from alarm to out the door. Shower, coffee, breakfast, and some light web reading. I've tried the odd run or workout, but usually fall back into this routine.</comment>


Artificial Intelligence Will Do What We Ask. That's a Problem - <AUTHOR> https://www.quantamagazine.org/artificial-intelligence-will-do-what-we-ask-thats-a-problem-20200130/ <comment><AUTHOR> "Like the robots, we're also trying to figure out our preferences, both what they are and what we want them to be, and how to handle the ambiguities and contradictions. Like the best possible AI, we're also striving — at least some of us, some of the time — to understand the form of the good, as Plato called the object of knowledge."</comment>


CenturyLink in Advanced Talks to Merge with Level 3 Communications - <AUTHOR> http://www.wsj.com/articles/centurylink-in-advanced-talks-to-merge-with-level-3-communications-1477589011?em_pos=small&ref=headline&nl_art=2 <comment><USER2> Seeing as how Google and other major content providers have moved to peering with consumer & business ISPs directly, and bought trans-pacific fiber and built datacenters all over Europe, Asia and South America to bring content closer to end users, I see how both Centurylink & Level 3 are in a weakened state. Both made tons of money shuttling data around on behalf of Netflix and others, and now Level 3 has taken a back seat, and Centurylink has been reduced to a last mile ISP.

Even on the consumer & small business front Centurylink seems to be scared, Portland is fiber only now, along with most of Seattle, only a decade after Verizon did the same thing just prior to selling the suburbs around Seattle.

How long will the merged company be viable? Will it descend similar to AMD/ATI's post merger valuation (combined value was much lower) while forestalling further, more substantial value loss?

With the rise of Internet Exchanges in Asia & South America, perhaps all that is left for these two tier one networks is rent seeking from content providers for access to consumers on Centurylink's network.</comment>


Self Hosted Private Repo Mirror from GitHub to Gitlab - <AUTHOR> https://github.com/DeepLinkCode/GithubToGitlab <comment><USER2> As some one who has hosted Gitlab before, it's very heavy if it's just a few users.

For personal use Gitea + Drone CI has been awesome with a much smaller memory footprint.

Gitea let's you import repos, I haven't checked on full mirror yet.

One thing that is not supported is Gitea doesn't have an endpoint for files changed (last I checked) so drone can't support build steps if a folder of file changes in a mono repo for example.

Other wise works great with a private registry and mirror for caching.

Can build a multi arch python Docker image with Docker buildx for amd64,arm64,arm6,arm7 in one pass.

Uncached its 30 minutes. With Buildx Canche takes 4 minute.

This is in VM on my NAS with old i7, 16gb ram.

<comment><AUTHOR> Yeah I have Used Gogs before, Although Gitlab is heavy but it brings more feature.

Also every piece of code or software comes with their own advantages and disadvantages.

My perception is like use those things which works for you.</comment></comment>


Ask HN: Azure customers, why do you host with Azure over AWS or GCP? - <AUTHOR> Additionally: - What OS do you run?
- Do you have a meaningful server-less component of infrastructure? - Do you containerize your hosted services?
- How big is your company (& does the company host exclusively one provider or give flexibility?)<p>Context: don't work for any of the Cloud Providers. mostly curious as an AWS cloud customer. <comment><USER2> With AWS you have to buy a new SQL Server license, with Azure you can carry it with you.

Replaced all the legacy services with Azure alternatives. For example, IIS Web Servers now run in containers. F5 has been replaced with CloudFlare/Front Door. File servers replaced with NetApp. SQL instance replaced with SQL MI. Jumpboxes replaced with Azure Bastion.

40,000+ employees. All the vendors are used. Multiple on premise data centers as well, looking to migrate.

<comment><AUTHOR> Super helpful - thank you! IIS / containerized .NET apps that may be optimized in Azure is compelling.

</comment></comment><comment><USER3> I use GCP because it is the best. I believe a lot of people using Azure and GCloud because it ties in with their emails and office systems. It's the same user and auth systems.

AWS is on its way down, when was the last time they came out with something exciting? All I've seen recently are high profile exits and some attempts at products in the leading emerging markets in tech that have not seen good reviews.

<comment><USER4> > AWS is on its way down, when was the last time they came out with something > exciting?

1\. AWS is still vastly more popular and with way more market adoption than another other provider (by a massive margin)

2\. Who cares about exciting? I want stability, with decent support, huge community and great tooling.

I think it's a case of YMMV. GCP works for some, likewise with Azure. AWS is just a good workhorse and a solid choice for just about any system.

Although I've always found it weird we have this 'us vs them' mentality with the cloud provider we end up choosing.

<comment><AUTHOR> Exciting is also a confusing property for me.

AWS has offered a superset of services beyond what I or colleagues have ever been able to apply.

<comment><USER3> By exciting, I mean pushing out research and open source, which eventually makes it into products. I have yet to see anything serious or popular comes out of Amazon. Compare this to Google and Microsoft and you can see a clear difference

<comment><USER4> > serious or popular

I'm still a little confused. What's not serious or popular coming out of Amazon? What's the different in Microsoft and GCP?

<comment><USER3> Kubernetes, Golang, Cuelang, Tensorflow ML research in particular for Google

Visual Studio Code, WSL, .Net on Linux, Hololens 2, MRTK, a number of interesting ML tools and research.

Amazon... do you know of any examples?

Largely GOOG and MSFT are giving back through research and open source while AMZN is rarely seen doing this and with little fanfare</comment></comment></comment></comment></comment></comment>


xkcd: Venting - <AUTHOR> http://xkcd.com/406/ <comment><USER2> Poor Summer; she's so typecast.

</comment><comment><USER3> You erred in your capitalization. From <http://xkcd.com/about/>

How do I write "xkcd"? There's nothing in Strunk and White about this. For those of us pedantic enough to want a rule, here it is: The preferred form is "xkcd", all lower-case. In formal contexts where a lowercase word shouldn't start a sentence, "XKCD" is an okay alternative. "Xkcd" is frowned upon.

<comment><USER4> This site seems to automatically capitalize the first letter of the first word you submit.

</comment></comment><comment><USER5> It should be titled "How to reply on HN" ;-)

<comment><USER6> Actually, most HN replies favor brevity. I like that.

<comment> patrickg-zill "HN replies favor brevity" is briefer.

<comment><USER7> HN ♥ brevity

</comment></comment></comment></comment><comment><USER8> But... How do we know that the original author would know who Summer Glau is?

</comment><comment><USER3> You erred in your capitalization. From <http://xkcd.com/about/>

How do I write "xkcd"? There's nothing in Strunk and White about this.

For those of us pedantic enough to want a rule, here it is: The preferred form is "xkcd", all lower-case. In formal contexts where a lowercase word shouldn't start a sentence, "XKCD" is an okay alternative. "Xkcd" is frowned upon.

<comment><USER3> Wait a minute, how did this double post happen? I didn't mean to do that! Sorry!</comment></comment>


WhatsApp confirms Google isn't buying it - <AUTHOR> http://venturebeat.com/2013/04/09/whatsapp-confirms-google-isnt-buying-it-but-you-can-bet-someone-will-soon/ <comment><USER2> It's time everyone understood a fundamental precept of startup acquisition rumors:

 _If an acquisition price is leaked before the deal is completed, the acquiree has no intention of selling._

In a private acquisition, there are only two parties in a position to leak: the acquirer and the acquiree. The acquirer, which has shareholders, competitors, and lots of money, has no incentive to leak the price on the table, or even the fact that there is a table. It gives away too much information to competitors and creates an unwanted news cycle. So in fact they'll be pissed if information about the negotiation is leaked.

If the acquiree actually wants to do a deal, they don't want to piss off the potential acquirer, so they'll keep their mouths shut. But they might have plenty of reasons to leak the negotation price, particularly if they're a company that is losing money and wants to inflate the company's valuation before another round of private financing. Going before investors saying "We turned down a billion dollars from Google, maybe you heard about it" creates a nice focal point for the ensuing discussion about the company's valuation.

Negotiating in bad faith like this happens all the time, most famously with Facebook/Yahoo! (2006) and Groupon/Google (2010). So the next time you read another news story about an acquisition rumor that includes a price tag, ignore it, because the story's not for you; it's for a future investor.

(Note that the foregoing logic does not apply if the acquiree is publicly traded, because the deal must be approved by shareholders, so the acquisition price is always "leaked" before the papers are signed.)

</comment><comment><USER3> Google better buy it, and convert it into normal XMPP service. Otherwise this sickness will just grow more.

 _> At WhatsApp, our engineers spend all their time fixing bugs, adding new features and ironing out all the little intricacies in our task of bringing rich, affordable, reliable messaging to every phone in the world. That's our product and that's our passion._

There is such thing - XMPP. Just create a reliable federated (and standard compliant!) service, and give people a decent client with audio/video XMPP/Jingle calling capabilities. Why their passion has to revolve around gutting security in the process of creating a non compliant walled IM abomination is really puzzling.

 _> Your data isn't even in the picture. We are simply not interested in any of it._

What about your identity being in the picture? Shouldn't they warn their users that they offer an insecure and identity leak / theft prone service?

<comment><USER4> XMPP performance on mobile platforms, especially on subpar networks, is pretty bad. It's designed for always-on networks and is a huge battery drain even if you can maintain that connection.

<comment><USER3> Whatsapp uses XMPP nevertheless. That's not the problem. The problem is that it modifies it, to make it non compliant, it doesn't federate and it also offers no way to control your user name and password, using phone hardware identity instead.

There are several ways to address XMPP energy drain, some of which were proposed as XEPs. Google uses one of such methods (google queue). Facebook uses another.

Example: <https://bugs.freedesktop.org/show_bug.cgi?id=38943>

</comment></comment></comment><comment><USER5> Obligatory calling out of blogspam and linking to the original article: [http://allthingsd.com/20130408/whatsapp-were-not-selling- to-...](http://allthingsd.com/20130408/whatsapp-were-not-selling-to-google/)

It never really made sense to me that Google would buy WhatsApp. What do they have that Google can't build themselves? An established userbase, sure, but any messaging app included by default in Android will have users migrating in droves.

<comment><USER6> Doesn't Google Talk qualify as the messaging app included by default? Not sure I see the droves of WhatsApp users migrating to that, sadly.

<comment><USER7> Sadly? Not for me. Here is one big reason I prefer services like WhatsApp (I don't actually use WhatsApp itself): I _do not_ want the presence reporting.

I want to send a message to people and they read and respond whenever they want. I want people to message me and I read and respond whenever I want.

I don't want to deal with ping, hey, you are online why are you not responding. This is why half my Gtalk contacts are always "away" even if they are at the keyboard: presence status has become useless, let's just get rid of it.

<comment><USER8> Tracking "presence" makes sense when the program implementing it is running on a computer sitting on a desk, and then you sometimes walk away from that desk.

Presence makes almost no sense when the program implementing it resides on a phone, where any time someone sends you a message--even if the application isn't running--you'll know (because your pants just buzzed), and could very well react to it if you felt like it. You're always "present"; you're just sometimes purposefully non-responsive.

...now, on the other hand, "openness to being interrupted" status could be pretty useful. :)

<comment><USER7> Half my contacts are always away, and have been for years.

I think what you want should be a setting in my machine (whether phone or computer): silence all notifications when I don't want to be interrupted (I use iOS "Do Not Disturb" all the time).

</comment></comment></comment></comment></comment><comment><USER9> This was possibly done to simply anchor [1] Whatsapp's value, should it seek to be acquired in the future.

[1] <http://en.wikipedia.org/wiki/Anchoring>

</comment><comment><USER10> I'm not familiar with WhatsApp, but from their front page blog article[1], it sounds like they could be at loggerheads with Google over privacy/advertising. You can't buy an ideologue.

[1] [http://blog.whatsapp.com/index.php/2012/06/why-we-dont- sell-...](http://blog.whatsapp.com/index.php/2012/06/why-we-dont-sell-ads/)

<comment><USER3> Whatsapp has several severe problems. Firstly it's proliferating non interoperable instant messaging networks. While it uses XMPP underneath, it modifies it in an incompatible fashion, and can't communicate with XMPP compliant clients and naturally it's not federated with any XMPP networks, so it reverses the point of XMPP completely, while using it.

Secondly, that it was created to exploit people's laziness - i.e. it skips registration step (one time thing) presenting it as a "convenience feature", but it does it at the cost of sacrificing security (i.e. it offers no way to choose user ID and password, instead of that it uses hardcoded information derived from the phone hardware ID), obviously not letting the user know about this downside. So it's a wicked trick which is used to attract unaware users.

<comment><USER11> Registration step is huge and annoying. I had to add my friends in ICQ, then MSN, then Facebook, then Skype, then Google+ (well no, not this one ...).

I use Whatsapp once per month and I'm not even sure what it does or how it does it. I just know I can send group messages to everyone in my contact list who have it and it WORKS.

<comment><USER3> "Huge and annoying" one time deal, which later allows you changing your password and also allows you choosing the ID of your liking, so you'd appear to your contacts with some recognizable name, and not as some numeric #########@whatsapp.com

When you sign up for e-mail, do you think it's normal to skip the registration step and to give you some random ID and password? Why is IM any different? Also, do you think it's normal for your e-mail ID to be tied to one device, or you'd expect to be able to access and read / send it from multiple devices / computers? Why should IM be any different? That's what XMPP is about. Whatsapp tries to create a crippled service instead, but somehow manages to wrap it as a "convenience".</comment></comment></comment></comment>


In Defense of Gen Y Workers - <AUTHOR> http://www.cio.com/article/157050 <comment><USER2> OK, I'll bite.

"Microsoft Power Point is better than 3-fold foam boards. Much. So please don't ask me to use inferior tools. Why should I?"

You claim you don't want to use inferior tools, and then claim Microsoft Power Point as a non-inferior tool?

BWA-HAHAHAHA!

Maybe if she said Keynote I could take her seriously.

I also find it amusing that she thinks the fact that she can use Facebook and IM makes her some kind of technological genius. And, no, I don't find an inability to find a book in the library a sign of intelligence. I don't think someone who doesn't think reading books is worthwhile should be making snide comments about other people's intelligence. Just yesterday the NYTimes reported on a study that basically said we're getting dumber because we don't read enough. Not just in reading skills, but even Math and Science.

<http://www.nytimes.com/2007/11/19/arts/19nea.htm>

So maybe Gen Y. needs to put down the cell phone, log off of Facebook and start reading a book before their IQ drops any farther than it already has.

</comment><comment><USER3> "I love the Internet, online communication and Facebook because these technologies allow me to do what I do best: multitask."

OK, let's get this straight once and for all...

THERE IS NO SUCH THING AS MULTI-TASKING.

Even when you think you are, you aren't. You're just switching really fast. Probably too fast to do any one thing well. Which makes the following statement all the more ridiculous:

"I want devices like BlackBerrys, Palm Pilots and the like, to allow me to stay focused on work at all times."

Does anyone even remember what "focused" means any more?

Just do one thing, the most important thing until it's not the most important thing any more. Then do THAT most important thing. Don't need much technology for that. Just a little discipline.

Now stop reading this and go do that.</comment>


Ask HN: Can I track browser extensions users are using while browsing my site? - <AUTHOR>

<comment><USER2> Do you mean plugins such as Flash and Java? These can be enumerated with Javascript code in Gecko/WebKit browsers[1]. AFAIK there's also something similar for IE.

When it comes to extensions such as HTTPS Everywhere and AdBlock etc I don't think it's supposed to be possible. Some extensions may unintentionally leak information that can be used to detect them though[2]. What are you trying to do?

[1] [https://developer.mozilla.org/en- US/docs/Web/API/NavigatorPl...](https://developer.mozilla.org/en- US/docs/Web/API/NavigatorPlugins.plugins) [2] [http://ha.ckers.org/blog/20060823/detecting-firefox- extentio...](http://ha.ckers.org/blog/20060823/detecting-firefox-extentions/)

<comment><AUTHOR> No, not plugins, extensions. I'm trying to find out two things: 1\. Trying to find out what extensions are used most of the times on my service so I can create a better experience by implementing those features. (Like if I would be Tumblr I would like to track how many users are using [http://missing-e.com/](http://missing-e.com/) or similar extensions.) 2\. Trying to find out how much revenue do I loose because of ad blocking extensions.</comment></comment>


Processing Emotions - <AUTHOR> http://www.willmeekphd.com/processing-emotions/ <comment><USER2> I'm not a fan of this discipline of managing and processing emotions as if they were opinions or the consequence of our thoughts.

Emotions are facts. This must be the premise. If you've felt them, they've happened already. The question is not "what are you feeling?" but rather, "what are you going to do about what you've felt?"

So as long as you're not confusing what you can change, you're good. You can prepare yourself and educate yourself for when you could feel something next time. But this is also already highly automated. Emotions tend to educate themselves. So I find a lot of this is just trusting yourself, and not overreaching into thinking you can change your past or twist the facts.

If you're sad you're sad. If you're happy you're happy.

It's not so much managing your emotions. It's more about managing the moment, and what you wish to do with yourself. It's about managing the things that make you feel things.

If you hate your job, quit your job. Don't manage the hate.

If you love someone, go for it. Don't manage your love.

And so on.

<comment><USER3> You'd be surprised how many people don't know what they are feeling. They are numbed, distracted and possibly have never given names to the experiences inside of them.

I agree that "managing" is a poor term here. In my practice I use the term "engage" with the emotion. Feel it. Surrender to it.

Action is very often a way to escape the intensity of an experience.

<comment><USER2> Yes absolutely. We have control of our actions. Emotions we have no control over. Or rather, that should not be the focus of our intentions. But we can control what we do about them, and we can connect the dots between our actions and our emotions when deciding what to do next.

And also there is hardly ever anything wrong with our emotions... I don't buy into negative emotions either. They're what you make of them -- after the fact.

I randomly came across this a while ago, and it remains the best example I have:

[https://medium.com/@sugarpirate/i-am-still- learning-f61c765d...](https://medium.com/@sugarpirate/i-am-still- learning-f61c765d657c)

> And I'm going to keep being afraid.

She talks about being afraid, except, she's no longer afraid of fear.

At which point, what is fear to you? What is fear?

The emotions, and the facts, remain. What has changed is you. This would not be possible if you = emotion. And it demonstrates how even fear is not negative. It's only negative if it leads to negative outcomes, which require your action.

When we are young, emotions become us. Someone takes your toy, and you cry. Maybe in your teens you punched someone in the face. But as we age, hopefully, these things happen less often. But you probably still get upset. The difference is in the control you have over your actions. And with this, our emotions seem to mature and sort themselves out also.

</comment></comment></comment><comment><USER4> This is a good article. I would just add that attending to an emotion and explaining to someone what you are feeling and why often results in a spontaneous process that produces positive changes such as lessening of intensity and change in perspective. This is much of how psychotherapy works, or for that matter just talking things over with a friend.

A good book on attending to feelings is Focusing, by Eugene Gendlin.

<comment><USER5> Agreed, in that regard I didn't find that example in the article very good:

> For example, if you were trying to impress a new date who wanted to go to > the zoo, you might have to find a way to play it cool in front of the > gorilla enclosure by using a discrete breathing technique.

Instead you could simply say that you actually have an irrational fear of gorillas. Worst case the date is actual a huge gorillas nerd and that would be a deal breaker, best case the date helps you change perspective and at the end of the date, you're not afraid of gorillas.

<comment><USER6> Yes. Honesty is more endearing than trying to pretend, and it's easier too.

</comment></comment></comment><comment><USER7> Hug of Death, there's a cache of it:

[http://webcache.googleusercontent.com/search?q=cache:RSEiWt4...](http://webcache.googleusercontent.com/search?q=cache:RSEiWt4desgJ:www.willmeekphd.com/processing- emotions/+&cd=1&hl=en&ct=clnk&gl=br)

</comment><comment><USER8> That's a good article - a nice overview. I have a conference talk I give on the same topic called Your Emotional API: [https://johnksawers.wistia.com/medias/wnlr918xe7](https://johnksawers.wistia.com/medias/wnlr918xe7)</comment>


Big Data Pricing Models - <AUTHOR> http://www.scalingdata.com/2014/01/big-data-pricing-models/

<comment><USER2> I'd say that most of the vendors selling commercial Hadoop derivatives aren't adding _that_ much value, and that's the problem.

With Hadoop, running a 3 machine cluster is about 30% of the work of running a 30 machine cluster. It gets really amazing when you realize you can get so big so fast.

The area where organizations run into trouble is in planning architecture, figuring out how to implement algorithms in Hadoop. The actual infrastructure software is a commodity.</comment>


MySpace Opens Up The OpenSocial Spigot - <AUTHOR> http://www.techcrunch.com/2008/03/13/myspace-application-gallery-goes-live-user-caps-lifted/

<comment><USER2> MySpace is obviously trying to learn from Facebook's success and incorporate a prominent feature of Facebook.

Unfortunately for MySpace, developers and the population in general are boarding the Facebook train and leaving MySpace back at the station.

MySpace is starting to remind me of the times when Friendster was technically sub par to its peers. All ugly/distasteful design considerations aside (seeing as how that has actually proven successful for MySpace) it is in fact technically inferior to its competitors.

Moreover, adding new features like OpenSocial without fixing its current fallacies could be detrimental.</comment>


On building portable Linux binaries - <AUTHOR> http://sagargv.blogspot.com/2014/09/on-building-portable-linux-binaries.html <comment><USER2> I've always thought it would be interesting to have a statically linked executable that was actually statically linked to externally-visible, signed copies of shared libs that are embedded in themselves, so that the dynamic linker could recognize when two processes, both of which are statically linked, could still share the same pages in memory because they have both statically linked the same lib+version. In other words, you get the memory and io savings of dynamic libs, but you get none of the dependency resolution problems (and none of the disk space savings).

<comment><USER3> I think the same could be done much easier using KSM [1] (Kernel SamePage Merging), which Linux now has.

1\. [https://en.wikipedia.org/wiki/Kernel_SamePage_Merging_%28KSM...](https://en.wikipedia.org/wiki/Kernel_SamePage_Merging_%28KSM%29)

<comment><USER2> Except KSM is not as well-suited to this problem as a dynamic linker would be, since KSM doesn't have as much insight into the semantics of the pages it's analyzing. I don't know all the details of how KSM works, but it must apply heuristics to _predict_ whether a page is going to get written to, whereas the dynamic linker knows exactly which sections of dynamic libs can be shared. Not to mention that KSM works less efficiently by recognizing duplicate pages after the fact and merging them, rather than skipping the duplication in the first place.

That's not to say that the KSM approach wouldn't be a big benefit (and you're right, it's much easier given that it's completely transparent), but it's definitely a less precise way to approach this specific problem.

<comment><USER3> > Except KSM is not as well-suited to this problem as a dynamic linker would > be, since KSM doesn't have as much insight into the semantics of the pages > it's analyzing.

Why would it need those insights? If two pages are identical, KSM de- duplicates them. The linker-assisted method would do the same, only earlier.

< [...] it must apply heuristics to predict whether a page is going to get written to, whereas the dynamic linker knows exactly which sections of dynamic libs can be shared.

I'm not sure which heuristics you're referring to. I think KSM de-duplicates the pages and sets the single remaining copy as copy-on-write, to detect writes (I wouldn't call this a heuristic). Both KSM and the dynamic linker would only be able to de-duplicate entire pages, since that's what the granularity the OS provides for sharing memory between processes.

> Not to mention that KSM works less efficiently by recognizing duplicate > pages after the fact and merging them, rather than skipping the duplication > in the first place.

OK, fair enough.

<comment><USER2> > I'm not sure which heuristics you're referring to.

As I said, the details are somewhat hazy for me, but my understanding is that KSM maintains a notion of how recently and how frequently a page changes, in order to determine whether it's a good candidate for deduplication or whether that would just be a waste of time that causes unnecessary page faults. I could be completely wrong on this, but I don't think it's quite as simple as "if two pages are identical, KSM de-duplicates them."

</comment></comment></comment></comment></comment><comment><USER4> You can use Gentoo Prefix for this:

[https://www.gentoo.org/proj/en/gentoo- alt/prefix/](https://www.gentoo.org/proj/en/gentoo-alt/prefix/)

It builds everyting except libc. Support for building libc is under development by the project. I used an early version of it to provide a build environment for the ZFSOnLinux kernel modules on CoreOS:

[https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos- tuto...](https://github.com/ClusterHQ/flocker/blob/zfs-on-coreos- tutorial-667/docs/experimental/zfs-on-coreos.rst)

</comment><comment><USER5> Another option:

Most/all modern distributions can run programs built with lsbcc[1] from the Linux Standard Base workgroup. The lsbdev environment links your program against "stub" .so files that advertise appropriate symbol versions, and prevent referencing library symbols that are not defined in the standard.

It can be somewhat of a hassle to get programs to build in this environment, but it greatly reduces the chances of finding an incompatibility when the program is later run under an unexpected Linux distribution. LSB includes an app checker[2] which can generate reports[3] showing compatibility with various distributions.

[1] [https://wiki.linuxfoundation.org/en/Book/HowToDevel](https://wiki.linuxfoundation.org/en/Book/HowToDevel)

[2] [http://ispras.linuxbase.org/index.php/About_Linux_Applicatio...](http://ispras.linuxbase.org/index.php/About_Linux_Application_Checker)

[3] [http://ispras.linuxbase.org/index.php/File:LAC_TestReportDis...](http://ispras.linuxbase.org/index.php/File:LAC_TestReportDist.png)

</comment><comment><USER6> By far the most reliable way I've found to run old binaries on Linux is ... to run a Windows binary under Wine.

We have the portable all-free-software binary handler, yay! It just has Win32 in the middle ...

<comment><USER7> Perhaps it's a side-effect of the open-source (or "source available but under a restrictive license") nature of *nix, and the larger number of systems it runs on that has lead to the "just compile the source on your system" way of doing things that makes the source more portable, but customises the binaries to the specific system(s) they're compiled for. Hardcoding the path to the dynamic linker in the executable certainly doesn't help...

It's definitely far easier to make small, self-contained binaries for e.g. x86-Windows versions that'll work from Win95 onwards than for, e.g. all x86-PC Linux distros in the last 20 years. Those compiled on one version of Windows, if linked to only the relatively stable set of system libraries and APIs, and not needing anything else, will simply "just work" with no installation, which I think is one of the nicer aspects of the Windows platform; the idea of "portable apps" seems far less developed on Linux.

(I suppose you could also use Java...)

<comment><USER8> I keep hearing that, but Linux has quite good backwards compatibility. I run a couple of 15 year old statically built executables on Linux, not because I have to but simply because I've kept them around. I believe Linux also keeps optional support for pre-ELF binaries, and that's even older. So I think Linux fares quite well in this regard.

Most things that create problems are auxilliary programs that people no longer keep around, such as mail transport software that has changed behaviour, or protocols that have changed. Those are things that would give you trouble on any platform.

<comment><USER9> Linus Torvalds was just at Debconf14 and specifically addressed how broken shipping application binaries for Linux desktop is.

[http://www.youtube.com/watch?v=5PmHRSeA2c8](http://www.youtube.com/watch?v=5PmHRSeA2c8)

The most relevant parts start at about 6min and 41min.

Highlights:

\- .deb vs .rpm misses the whole point. The problem is application writers just want to ship an application binary for "Linux", but it is a nightmare.

\- Except for the kernel which strives for ABI stability, everything else in the Linux distros constantly break binary compatibility, including the most important library, glibc.

\- Package maintainers are forced to use shared libraries for everything, even packages that are unstable and not well used which means apps will break

\- You can't install packages under these systems as non-root

\- He ships binaries for his SCUBA diving app for Windows and OS X. He only ships source for Linux. That's sad.

\- Static linking is a possible solution, but that is sad too.

(For the record, he points to Valve as a potential savior but says they will probably do the sad thing of static linking. They aren't doing quite this. They ship a set of dynamic libraries called Steam Runtime that all Steam games can draw from. Better than static linking, but still kind of sad.)

At the 41 minute segment, a user celebrates the "good backwards compatibility" for a 19 year binary he still has, and Linus points out that is "patting ourselves on the back", but doesn't address the real compatibility issues which are modern binaries.

I can attest to the glibc hell. Another simple example is clock_gettime(). Just trying to ship a binary between Ubuntu 14.04 and 12.04 is enough to bang your head. (I think this problem appears between 12 and 13 too.) On one version, it is found in glibc, but in the other it is in librt. This prevents the binary from working on both.

Linus also criticizes Java (mentioned in the parent). That didn't work for him either.

As for Windows, Windows still has DLL-hell. It's sad that Microsoft won't ship their Visual Studio common C and C++ runtimes with the OS (MSVC*dll), even though they finally put version numbers in the file name now. And they make it harder than it should be to deploy your app with them. However, this is still a vast improvement over what Linux distros are doing (as Linus points out).

(edit: formatting)

</comment></comment></comment></comment><comment><USER10> I know it's not a panacea, but the Open Build Service is helpful in building packages for multiple distributions.

</comment><comment><USER11> I recently started using Fedora, love it, hate the lack of software. I could always contribute to packaging software not yet available, like e.g. Atom, but in the time I could waste learning to do these things I could of installed Ubuntu. I'll keep it for now, though. Maybe I'll figure out how to package and somehow release some lovely RPM's. I love Fedora, hate the lack of packages.

<comment><USER12> I wonder if containers on the desktop would be useful for this kind of situation. You could have containers for different distributions, or even different versions of a distribution. For example, one for Ubuntu 14.04 and a different one for 13.10. The containers wouldn't do much, other than take up filesystem space, until they're needed.

This wouldn't work if the software requires a kernel module that isn't packaged for your distribution. It also wouldn't be particularly useful for a file system navigator or something that needs to see the rest of the system. That should still leave in quite a bit of useful software.

<comment><USER13> > I wonder if containers on the desktop would be useful for this kind of > situation.

Wouldn't that negate the benefits of things like shared libraries?

<comment><USER14> [http://harmful.cat-v.org/software/dynamic- linking/](http://harmful.cat-v.org/software/dynamic-linking/)

..comes to my mind. Shared libraries and their advantages are at least.. controversal.

<comment><USER13> What about the benefit of being able to (e.g.) update OpenSSL across the board? Imagine if each application needed a HeartBleed update because every application had their own copy of OpenSSL. How would that be preferable?

</comment></comment></comment></comment></comment><comment><USER15> A made a tool called Whack [1] as an attempt to solve a small part of the problem. The idea was that you could write scripts that would build statically-linked versions of binaries, such as Apache HTTPD [2]. Then, you could run a command like:

        whack install git+https://github.com/mwilliamson/whack-package-apache2-mod-php5 apps/apache2

to install to any location you wanted, and the installation would still work if you mv'd the entire directory somewhere else, or even onto another distribution (provided it didn't have an older libc).

I never really the pushed the idea further since I think doing a decent job requires a lot of time and effort, and it solves something which is a minor annoyance for me, rather than causing significant pain. I do still use it for when I need to quickly get a WordPress server for development up and running since it's one command to deploy from scratch.

It feels to me like there's lots of scope for something similar to apt-get that builds and installs static binaries (or, at the very least, lets you install to different directories without root, similar to, say, virtualenv for Python or RVM for Ruby).

EDIT: actually, from a quick glance, it seems like Gentoo Prefix [3], as mentioned by ryao, allows you to install things as you normally would on a Gentoo machine, but without being root and with a prefix of your choosing.

[1] [https://github.com/mwilliamson/whack](https://github.com/mwilliamson/whack) [2] [https://github.com/mwilliamson/whack-package-apache2-mod- php...](https://github.com/mwilliamson/whack-package-apache2-mod-php5) [3] [https://www.gentoo.org/proj/en/gentoo- alt/prefix/](https://www.gentoo.org/proj/en/gentoo-alt/prefix/)

</comment><comment><USER16> It's sad that this is still a problem. Every time it comes up the old "just open source it", "just dynamically link everything", "just make a package for every distribution and version of libc" people come out and stop and sort of progress.

Autopackage gave up because of this lack of progress.

So we are left with two equally awful "solutions":

1\. Do all your development on years-old linux distros. 2\. Use docker and essentially package an entire distro with your app.

This is never a problem on Windows.

<comment><USER17> > ... never a problem on windows

Hello? Dll-hell? Outdated dlls bundeled with an app? This essentially _the_ problem distros solve; fixed target against which to compile..

<comment><USER18> Erm, no?

Try installing a copy of Half-Life 1 from '98 on a modern machine (go on, I'll wait).

Note that it runs just fine, other than being confused if you've got more than 4GB of ram (which you can fake and fix in other ways).

Windows _had_ a lot of DLL issues, but the VC redstributables and vendors packaging their own blessed libraries solves almost all of those issues. I'll take that over the crackheaded Linux story any day.</comment></comment></comment>


How Athletes Get Great - j-g-faustus http://www.outsideonline.com/outdoor-adventure/media/books/How-Athletes-Get-Great.html?page=all <comment><AUTHOR> Here's another fairly thorough examination of the 10,000 hour idea:

[http://www.sportsscientists.com/2011/08/talent-training- and-...](http://www.sportsscientists.com/2011/08/talent-training-and- performance-secrets.html)

Key points:

1\. Ericsson only published averages. Nobody else has seen the raw data. He didn't even give standard deviation or error bars.

2\. "Talented" people get more positive feedback and so practice more.

3\. There are so many observable phenotypal inputs and as yet _unobserved_ phenotypal inputs into sports performance that pinning it to a single variable (hours of deliberate practice) is nuts.

My sport is Olympic weightlifting.

Some people will never be Olympic champions, no matter how hard they train. Factors affecting performance include:

* Height.

* Relative anthropometry: long legs are worse than short legs. Long torsos are better than short torsos. Long arms are better for the snatch, worse for the clean and jerk.

* Fast-twitch fibre / slow-twitch fibre ratios.

* Tendon insertion geometry.

* Muscle-belly / tendon ratio.

* Pelvic geometry.

* Soft tissue robustness.

* Natural hormonal environment: ratios, natural circulating testosterone and DHT, amounts of SBHG.

* Placement and density of testosterone receptors in muscle tissue.

* Myostatin production.

These are basic physiological qualities that cannot be changed by any amount of training. While the statistics show that lifters who start younger out- perform lifters who start later (because it's a high-skill sport and childhood neuroplasticity is much higher), the historically and currently dominant countries in weightlifting have gotten there by simply having much larger pools of candidates to find genetic outliers in.

<comment><USER2> This is all very interesting, but how much do you squat? Let's quantify the progress in absolute terms we all understand, like pounds on a bar through full ROM

<comment><USER3> What does his squat max have to do the point above? Besides, he's an oly weightlifter not a powerlifter.

<comment><USER4> It's a lifting culture meme, popularized on Reddit.

Source: I hoist and read r/fitnesscirclejerk during when I eat.

Which is often, because I lift.

<comment><USER5> I once browsed reddit, and I have no idea who this guy is. He's lying.

</comment></comment></comment></comment></comment><comment><USER6> Interesting article. I think when it comes to pure physical sports they're missing some of the original point. The concept of 10,000 hours is about developing a skill, not becoming physically gifted. Michael Jordan's 10,000 hours come from shooting and knowing where to go where the ball will be, more so than just being the most physically gifted.

<comment><USER7> Your ignoring the chess example where 3,000 hours get some people to masters status but 25,000 is not enough for others. 10,000 was an average but a useless one because it's for 20 year olds and there is only so much free time before 20 and many need far less time which means others needed even more.

<comment><USER6> Fair enough. The 10,000 hour rule is not iron clad, more a suggestion. The point I'm trying to get at is it's more about routines that require practice rather than pure physical exertion. As in, "Deliberate practice contributes more to the outcome of playing violin and shooting baskets than it does to a 50 yard dash"

<comment><AUTHOR> The Russians studied skill development in sport more than anybody. In weightlifting one of their leading coaches, Medvedyev, had a 7-year plan to take a promising 10 or 11 year from child to international competitiveness, planned down to the day.

As the plan progressed, the percentage of work dedicated to different training demands varied. By the time a trainee has pass into the final phase (Master of Sport International Class), he would only be performing the competition lifts for about 16% or 17% of overall training volume. The rest was taken up by a very large collection of assistance exercises, rotated as necessary.

After a while, the emphasis was on getting stronger. Their pattern of movement from tens of thousands of repetitions was sufficiently fixed that all that was left was maintaining the pattern and making them stronger.

<comment><USER6> I've heard similar for other sports too... That their Judo and Wrestling training has very little competition and much more drilling and supplementary conditioning.

<comment><AUTHOR> They had a cadre of sports scientists who worked on a range of sports and shared findings. I'm most familiar with weightlifting because that's my sport, but from one of my textbooks you can see how they applied common principles across a range of sports.

</comment></comment></comment></comment></comment></comment><comment><USER8> I don't think that Epstein is being very charitable with Gladwell's 10,000 figure. Gladwell:

a) Doesn't make the 10,000-hour figure a _rule_ as both Epstein and Repanich would have us believe.

b) Fully concedes that there are myriads of other factors that have an effect on how one reaches "expert status".

I'm also not sure how Epstein can claim that the chess master study is somehow disanalogous with the athlete one. An expert athlete might have some physical advantage over your "average Joe": speed, lean muscle, endurance, height, etc., etc. Similarly, one can say that an expert chess player may have some neurophysiological advantage over the "average Joe": better-formed synaptic pathways, higher attention span, etc., etc. I don't think there's any difference between an expert chess master or an NFL quarterback.

Both might have some genetic advantage; both have trained extensively. The idea behind Gladwell's figure is not that you can practice X for 10,000 hours and then you will instantly be an expert at it, but merely that after 10,000 hours (of deliberate practice plus a number of contingencies) you can expect to be somewhere in the realm of expertness.

There are plenty of other studies that favor this hypothesis; in particular, some very interesting double-blind identical twin studies[1].

Outside of extreme cases (e.g. I am 4'11'' and want to play in the NBA; I have an IQ of 90 and want to be an astronaut), I think Gladwell is right on the money: practice is more important than talent.

[1] [http://www.indiana.edu/~jkkteach/P335/shanks_expertise.html](http://www.indiana.edu/~jkkteach/P335/shanks_expertise.html)

<comment><AUTHOR> The problem is that the chess study shows that some people never became chess masters, no matter _how_ many hours they practiced.

There was a hard upper limit to their performance that no amount of training could surmount. Insofar as "expert" is defined by relative ranking, some people will never become experts. Why? Because they are outranked by the "naturals".

The general problem with the Gladwell/Ericsson hypothesis is that it sorta- kinda suggests that practice is both necessary _and_ sufficient to produce expert-level performance.

Everyone agrees on necessity. It is the question of sufficiency that is demonstrably false. People are different and are better suited to different endeavours; no amount or sort of training or practice can change the boundaries of your phenotypic potential.

You can move a long way from an average baseline in the direction of expertise -- humans are very malleable. But there are hard limits. Elite performers in any field are elite because they were better suited and _then_ did the practice.

<comment><USER9> I think you are missing part of the results of Ericsson's research. He makes a very specific point to distinguish _practice_ from _deliberate practice_. 10000 hours of practice is very different from 10000 hours of deliberate practice.

My interpretation of Ericsson's work is that natural talent can give certain individuals a head start in the beginning, but once you get into the domain of expertise, this head start at the beginning is very tiny and the effects of practice completely overpower it in comparison. However, I think in areas like sports - genetics do play more of a role. If you are less than 5 feet tall, you probably will not be an NBA point guard, even after 10000 hours of deliberate practice.

One of his papers for further reading:

From The Role of Deliberate Practice in the Acquisition of Expert Performance

" _Consider three general types of activities, namely, work, play,and deliberate practice. Work includes public performance, competitions, services rendered for pay, and other activities directly motivated by external rewards. Play includes activities that have no explicit goal and that are inherently enjoyable. Deliberate practice includes activities that have been specially designed to improve the current level of performance. "_

[http://graphics8.nytimes.com/images/blogs/freakonomics/pdf/D...](http://graphics8.nytimes.com/images/blogs/freakonomics/pdf/DeliberatePractice\(PsychologicalReview\).pdf)

<comment><AUTHOR> I'm familiar with the distinction that Ericsson made.

The chess study is based on people who deliberately practiced.

It still didn't matter. Some people are simply better at chess.

Seriously proposing that all humans everywhere have perfectly identical potential in all possible tasks is nonsensical. That is the strongest form of Ericsson's hypothesis. If you weaken the hypothesis -- eg. "some people take less time" \-- then why _only_ publish the _exact_ 10,000 average and fail to show variances in the original study?

And if there is variance in time-to-expertise ... what exactly does the "training is required, but the time needed varies based on talent" finding tell us over ... training is required, but the time varies based on talent?

Because that's already kinda known.

</comment></comment></comment></comment><comment><USER10> I'm happy that at least someone is trying out the 10,000 hour rule empirically: [http://thedanplan.com/](http://thedanplan.com/)

</comment><comment><USER11> I played high level golf for a while and a lot of these articles forget the two main rules I've learned from it. The first is intense practice. This means devoting 100 percent to every repetition. This is obviously difficult because of, among other things, repetition is inherently boring. Luckily for golf, there are an infinite number of shots to practice, and working on all of them should break up the monotony. This leads into the second rule for practice, which is to vary what you work on. For golf, this means playing different shots from all different locations. Besides making it more interesting, it makes you go through the actual process that you would encounter on the course.

This generalizes to other activities easily. The best practice I've found comes from complete effort in game/competition like environments.

<comment><AUTHOR> In fairness to Ericsson and Gladwell, they didn't say "any old 10,000 hours will do". The basic hypothesis was, as you say, that it had to focused and deliberate.

</comment></comment><comment><USER12> Interesting notes / anecdotes from me about 10,000 hours and genetics.

I played golf at a pretty high level throughout high school and college. I practiced and played golf on most days for 8 straight years. I'm sure I reached 10k hours. Currently, I don't have almost any time to practice and play golf. I haven't practiced or played regularly in at least 6 years. Yet, playing once every 2 months or so I'm still able to shoot at or near par most of the time. I suspect this has more to do with the 10k hours of practice than my natural abilities. Not really any way to prove that, but I suspect a similarly athletic person who hasn't put in that practice wouldn't generally shoot par playing 6 times a year.

</comment><comment><USER13> There's some interesting research done on myostatin. It's a protein that inhibits muscle differentiation. [http://en.wikipedia.org/wiki/Myostatin](http://en.wikipedia.org/wiki/Myostatin)

Genetic advantages are interesting.

</comment><comment><USER14> When I was 14 I was fed up with kids on my soccer team not wanting to win as much as me. I quit soccer and picked up tennis. Looking back, a large part of my inspiration to pick up tennis was I just wanted to see if anyone could actually learn to do anything. I was never great, and didn't bloom until the end of my junior career, but it did land me a partial scholarship and probably got me into some better schools than my grades and test scores show. Taught me a lot about life though, and really thats how athletes become great.

Another way athletes become great though, in all seriousness, is they hack their bodies with PEDs. Seems to me like sports these days are flooded with it.

<comment><AUTHOR> The effect of PEDs is also mediated by genetics. Take the grand-daddy of PEDs, testosterone.

Some people respond better to it than others. Some people have more testosterone receptors. Some people aromatise more of it into DHT or estrogen than others. Some people have more SHBG, a protein which disables sex hormones.

Variability in response happens for every PED. The introduction of PEDs has not removed selection, it's just changed the selection function.

</comment></comment><comment><USER15> "One of the coolest things is genetically tailored diet and training. It won't be perfect because we still don't know what most genes do. But exercise genetics will potentially produce some of the most widely used and effective medicine. You may be able to tell people how they can train to get a certain health benefit instead of taking a drug, or maybe that they can't get that benefit with training so they do need a medication. Also, injury predisposition genes are coming online right now. It would be nice to know more than just through straight trial and error what's the best training for your and how you can avoid injury."

This.

</comment><comment><USER16> "Talent Is Overrated: What Really Separates World-Class Performers from Everybody Else" by Geoff Colvin is the best book on this topic that i've read.</comment>


Foxconn Confirms Plans for U.S. Investment - <AUTHOR> https://www.bloomberg.com/news/articles/2016-12-07/apple-s-top-assembler-foxconn-confirms-plans-for-u-s-investment <comment><USER2> Why not? Foxconn is going robotic. Their new Foxbots are good enough to assemble iPhones. So why not make them nearer to the US market and avoid tariff problems?

50,000 employees is small for Foxconn. They have 1,300,000 employees now. (Yes, they really are that big.) They replaced 60,000 workers with robots earlier in 2016.[1] They plan to replace a lot more.

[1] [http://www.bbc.com/news/technology-36376966](http://www.bbc.com/news/technology-36376966)

</comment><comment><USER3> Smart move by both Apple and Foxconn.

Having your manufacturing based in one country isn't a good idea in terms of risk management.

Natural disasters, shipping delays, or presidential will could shut down production pretty quickly.

Trump will be very quick to use this as a point to show he was correct. I'd expect Foxconn to get some very good concessions out of this. SoftBank's Masayoshi continues to amaze me. Instead of talking tough about Trump's local manufacturing bluster, he quickly accepted it and started deal making with this new reality.

I'm no political expert but Id' be very surprised if Trump doesn't start picking fights with other governments about manufacturing jobs and tariffs. Companies and supply chains who don't anticipate this are going to be in for a rough 4 years.

Bloomberg's SPLC<GO> function is going to get alot more use in the coming days/weeks as people start to map out who is bring jobs back to America and who is standing firm:)

<comment> norea-armozel The problem is that these aren't high paying jobs likely like those in actual semiconductor fabrication. Plus, Foxconn already utilizes robots in the majority of it's facilities so you're not going to get much out of this as they continue the process of automation throughout their production processes. Expect some jobs, but most of them will be always replaceable with machines. All that's happened here is Trump got played by Foxconn.

<comment><USER4> I've been in many electronics factories, including ones used by Apple. There is still a lot of human labor. When people talk about robots replacing people in these factories, they aren't talking about robots driving screws or connecting assemblies together. Robots can do that, but many companies' demands for agile manufacturing make them hard to bring in.

I was in the factory that makes Apple Earpods. They are one of Apple's highest produced products because they ship with all their iOS devices. All the assembly was done by hand. They were proud that they added a robot to the line. Do you know what the robot did? It moved parts from one station to another station 12 feet away. They previously had a human doing that.

<comment><USER5> Nevertheless in the last 10 years factory automation has been explosive. Its not all done (or we'd have much higher unemployment) but its hurtling down that road.

</comment></comment></comment></comment><comment><USER6> I'm not clear about China/Japanese investment in the USA but doesn't that feel like the US is loosing it's edge and competitiveness. From an uninformed point of view it surely feels like China and Japan are actually in a position of control here more than ever?

</comment><comment><USER7> dang: where did we arrive on the politics matter yesterday? Is this in or out? Serious question.

<comment><USER8> It's clearly on topic for HN in general, but has to be out this week, given that we asked people to err on the side of flagging politics and the reason the investment was made was political.

Doing this experiment for a week is demonstrating how inseparable the political aspects of these stories are, and how "just ban politics" is not an answer to the flamewar and incivility problems that HN faces. So when it's done, our current thinking is to revert to the status quo ante, with some additional guidelines to encourage civility and to ask people not to use the site _primarily_ for politics.

<comment><USER9> A pity. I was hoping the ban could last a month or longer. The site is _wonderful_ now.

<comment><USER10> I'm liking it too!

</comment></comment></comment></comment><comment><USER11> Isn't HN supposed to be "detoxing" from politics this week?</comment>