Half the world is now middle class or wealthier (2018) - <AUTHOR> https://www.brookings.edu/blog/future-development/2018/09/27/a-global-tipping-point-half-the-world-is-now-middle-class-or-wealthier/ <comment><USER2> Incorrect use of the term "tipping point". Reaching this point may be noteworthy, but there is absolutely no evidence or reason to believe that the remaining poverty will diminish much more rapidly, which is what "tipping point" implies.[1] Nor do they actually claim this in the article, they just keep on misusing the term.

Also, I live in a small city in a developing country where this phenomenon was quite visible; certainly people have a lot more material wealth than they did, say 20 years ago, but education and public health have not improved significantly, and possibly even declined for the lower middle-class. And while people used to be poor here, nobody was malnourished in the bad old days, but now, with their new industrialized middle-class diets, they are getting "starving fat" like American inner city kids. If people are really better off is debatable.

And all those new middle-class consumers are doing a real number on the environment, probably more so than a "first world" consumer of similar means because of the crappy infrastructure (proper waste management anyone?) and because the consumer goods here are of significantly lower quality (and so need to be replace more frequently).

[1] [https://en.wikipedia.org/wiki/Tipping_point_(sociology)](https://en.wikipedia.org/wiki/Tipping_point_\(sociology\))

<comment> barry-cotter > but education and public health have not improved significantly, and > possibly even declined for the lower middle-class.

There's an upper limit to the proportion of the population that can do doctoral/professional/executive level work because people's capacities are limited. If you bump up against that limit further attempts to increase qualifications or learning will fail or the qualifications will be debased. If there is a single first world country where life expectancy has declined from 20 years ago to now I haven't heard of it.

> And while people used to be poor here, nobody was malnourished in the bad > old days, but now, with their new industrialized middle-class diets, they > are getting "starving fat" like American inner city kids.

Starving fat doesn't exist. If people choose to eat bad food that's their choice. We can lament it; we can take action to encourage healthier diets but that doesn't mean "starving fat" isn't an oxymoron.

<comment><USER3> > Starving fat doesn't exist. If people choose to eat bad food that's their > choice.

We can't place blame fully on consumers. "Food deserts" are spreading while quality, variety and abundance of fresh food is decreasing. Meanwhile fast food is cheap, heavily marketed, and engineered for its addictiveness. In many areas poor people don't actually have much choice.

<comment><USER4> Except this isn't really supported by the evidence. We have examples of fast food being restricted, and it has virtually no impact on obesity or health[1]. We now have tons of data regarding the Federal government's efforts to build full-fledged grocery stores in low-income areas. And the results show virtually no impact on health[2]

The second point I want to make is that you have a mis-placed emphasis on "fresh food". Frozen or canned vegetables, fruits and legumes are actually more nutritious than fresh produce. And the cost, variety and quality of canned and frozen produce has been improving steadily for decades.

The food desert hypothesis sounds compelling, but simply doesn't jibe with the evidence. Obesity among the lower classes is almost certainly driven by cultural and/or genetic factors, not lack of access to healthy food.

[1] [https://www.npr.org/sections/thesalt/2015/03/20/393943031/wh...](https://www.npr.org/sections/thesalt/2015/03/20/393943031/why- los-angeles-fast-food-ban-did-nothing-to-check-obesity) [2] [https://www.vox.com/2015/12/22/10644738/food-desert- evidence](https://www.vox.com/2015/12/22/10644738/food-desert-evidence)

<comment><USER5> >We have examples of fast food being restricted, and it has virtually no impact on obesity or health[1]

Your own link does not support your point, and contains a detailed analysis of why that particular experiment failed (it was completely ineffectual at actually restricting fast food).

Focusing on physical locations of supermarkets is missing the forest for the trees. As your link points out, the problem is that healthy food costs more. A "food desert" is just as real if you can't afford it, as if the food weren't there.

>Obesity among the lower classes is almost certainly driven by cultural and/or genetic factors

Ouch. Lower classes genetically inferior? That's a real dangerous road you're on pal.

<comment><USER4> > Ouch. Lower classes genetically inferior? That's a real dangerous road > you're on pal.

Decades of twin studies have consistently shown that IQ[1], obesity[2], educational attainment[3], and lifetime earnings[4] all have significant components of genetic heritability. These are among the most replicated results in all of psychology.

GWAS have also found that intelligence is highly polygenic, involving at least 500 SNPs[5]. GWAS has confirmed that obesity is also highly polygenic, involving at least 400 SNPs[6]. The majority of those SNPs occur on genetic loci relating to brain function[7].

Given the fact that intelligence (a major determinant of SES in modern industrial economies) and obesity both involve a huge number of genes specifically related to neurological development, it would be shocking if there _wasn 't_ at least some overlap between the respective genetic structure of the two traits.

[1] [https://en.wikipedia.org/wiki/Heritability_of_IQ](https://en.wikipedia.org/wiki/Heritability_of_IQ) [2] [https://academic.oup.com/epirev/article/29/1/49/437222#35942...](https://academic.oup.com/epirev/article/29/1/49/437222#35942739) [3] [https://link.springer.com/article/10.1007/BF01065905](https://link.springer.com/article/10.1007/BF01065905) [4] [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2253264](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2253264) [5] [https://www.nature.com/articles/mp201185](https://www.nature.com/articles/mp201185) [6] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6028139/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6028139/) [7] [https://www.biorxiv.org/content/10.1101/274654v2](https://www.biorxiv.org/content/10.1101/274654v2)

<comment><USER5> The problem with this theory is that it's lazy. It's quite probably true to some extent that _some_ of the negative outcomes disproportionately experienced by poor people are not a direct consequence of poverty, but due to common intrinsic factors that make them poor in the first place. Some of these may even be heritable. Great, now what? Short of eugenics, there's nothing you can do about that. But, and here's the thing, such common intrinsic factors cannot account for _all_ of the negative outcomes we see. There has to be _some_ element of poor circumstance, some lever we _can_ push - we surely can influence outcomes positively one way or another. This whole discussion is about exploring those ways. So why on Earth would you bring up the stuff we _can 't_ change, except to shut down that discussion?

<comment><USER4> Let me draw an analogy with baldness. We can agree that baldness is a problem for humanity. Maybe not the biggest problem, but every year many people go bald and are unhappy about it. So, if we could eliminate involuntary baldness that'd be great.

Now, let's say our philanthropic anti-baldness initiative notices that men go bald at significantly higher rates than women. So, we come to the conclusion that we have to figure out the sociological factors that make men bald. Maybe video games contributes to baldness, or maybe it's the stress of having looser ties to family, or maybe its the rate of military service?

As we both know, baldness, including the higher rate of male baldness, is driven by genetic-biological factors. If we refused to even consider this hypothesis it would lead to some pretty absurd conclusions and policies. But knowing that the problem has a biological basis lets us direct our humanitarian efforts at the root cause. We know that to treat baldness we need to target biology, with things like Rogaine and hair transplants, not sociology.

<comment><USER6> Social factors require social responses. Your analogy doesn't follow.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This framing is extremely suspect IMO; the article and figure 1 calls people in extreme poverty "poor" and people in poverty "vulnerable". Extreme poverty is not just "poor", extreme poverty is a line below which one cannot afford enough food to keep them alive, and doesn't include housing or anything else. The "vulnerable" line is below $11/day, and some economists have argued the definition of global poverty should be higher than that. These dollar numbers are in adjusted PPP (purchasing power parity) so you can compare them to what you make & spend in the US, for example. $11/day is $4k/year, which is very far below what we call poverty in the US (our line is almost $12k), so why are we okay with calling that poverty elsewhere? People earning the equivalent of $11/day are not going to movies.

There was an enlightening article & discussion about this last year on HN [https://news.ycombinator.com/item?id=19133221](https://news.ycombinator.com/item?id=19133221)

</comment><comment><USER8> > the majority of humankind is no longer poor or vulnerable to falling into > poverty

This isn't a definition of middle-class I've ever encountered, the bar is surely a bit higher than simply 'not poor'.

They've used $11 PPP as the lower bound. That's totally ridiculous, in most of Europe that's not even liveable. Perhaps they mean discretionary income? That would make a bit more sense.

Otherwise, it seems like they've chosen figures such that middle class ~= median global income, which is a circular definition.

<comment><USER9> The numbers are supposed to be purchasing power parity adjusted. But then, they're supposed to be purchasing power parity adjusted to reflect _US_ purchasing power, and $11/hr certainly isn't middle class in most parts of the US. [the reality is that PPP adjustments are impossible to do accurately; some people earning $11PPP have big houses, servants and privately educated kids and some people are actually earning $11/hr in the US or Western Europe]

The other dimension is what they're doing to earn that sort of disposable income. There are people doing some very unattractive or unsafe jobs for mid to high income by local standards.

<comment><USER10> It's $11/day, not $11/hr.

Yes, the authors are either using a poor interpretation of PPP, or a very inclusive definition of middle-class.

</comment></comment></comment><comment><USER11> Reminds me of Hans Rosling's talks, for example [https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve...](https://www.ted.com/talks/hans_rosling_the_best_stats_you_ve_ever_seen).

</comment><comment><USER12> > enough discretionary expenditure to be considered "middle class"

I don't think money makes you 'middle class'. You can be a millionaire but working class, or destitute but upper class. Class is about things like background, education, tastes, social status and connections. Not cash.

<comment><USER8> This is only true in one direction.

You can be wealthy and working class, sure. But the converse is simply impractical.

How many upper class individuals are there living in a rotting house share, on benefits, hitting up the food bank?

There's a minimum amount of capital required to be able to meaningfully participate in social activities at different levels. That might not mean fantastic wealth but neither does it mean working in the corner shop (unless by choice).

<comment><USER12> If you're born a baronet, go to Eton, take a commission in the Guards, but end your days alone and penniless in a care home then I think you're still upper class until the day you die.

Likewise I could win the lottery tomorrow but I'd never have the background and connections to become upper class.

<comment><USER8> Hmm, yeah, you're right there (on both examples).

I'm still not so sure though. That's something of a special case, the extreme upper end and also at the end of one's life.

It feels like you at least need to at _some_ point have the wealth if not necessarily personally (e.g. whilst growing up).

</comment></comment></comment></comment><comment><USER13> The only reason it gives you the illusion of beeing richer then our previous generations is, that you can now buy tons of cheap Chinese shit for which your grandparents had to buy very expensive western utilities (the stuff that still works).

Otherwise, we are, on average, poorer then our parents. Our kids, if you are still consider having them, will be poorer then you.

A necessary result from capitalism with fiat money. However, if your wealth exceeds a certain threshold, currently something around 1.5-2 million €, you will benefit from this system and earn more all the time.

</comment><comment><USER14> half of what world? certainly not earth?

</comment><comment><USER15> When will half of the world be upper class, where making more money won't increase their happiness? That is $75,000 per year in 2013 USD.

This second transition almost certainly won't appear like the last. There are reasons to believe it may not be gradual like the transition from poverty to middle class.

Will the population be launched into wealth piece by piece, as subgroups of developed economies get access to education and then the capital necessary to make the salary of a Bay Area software engineer, for example? Are there any "natural" forces within capitalism to proliferate this prerequisite education and capital? Can a person with enough intelligence to work in a factory but not enough to get a tertiary degree hope to make this transition into wealth "on their own"?

My only bet is that the current global state of "business as usual" is completely insufficient to make the second transition for any significant proportion of the world's inhabitants.

<comment><USER16> I think we can do things better for sure, and it's a tragedy for all those in poverty that it will still take time, perhaps outside their lifetime.

But to suggest there is some wall to the second transition seems unfounded, as "business as usual" is what lead us here in the first place.

</comment></comment><comment> m-p-3 Wealth classes are relative to the purchasing power and cost of living.

With many more reaching middle class it just means that the threshold to be considered middle class increases, so the bottom of the middle class will simply be downranked at some point as even though they're making more money, their power diminished.

<comment><USER17> The article gives a definition of what they mean by middle class in absolute terms: \- being able to afford durable goods such as motorcycles and washing machines \- not having to fear extreme poverty due to illness or unemployment right away

In many developed nations, this definition would comprise a large majority of the population, and some people who would be considered poor on relative terms there (i.e. make less than half the average income) would comfortably fit into this definition of a global middle class.</comment></comment>


Ask HN: Rethink DB or SQL? - <AUTHOR> <comment><USER2> Yes, more context in planned use-case would be good. I'm a SQLServer DBA fwiw.

</comment><comment><USER3> Depends on what you are doing.</comment>


A theoretical approach to body language and emotion - <AUTHOR> http://www.zacharyburt.com/2010/06/what-every-body-is-saying-a-theoretical-approach-to-body-language-and-emotions/ <comment><USER2> Summary for the interesting points of the article

Look at the persons feet - "Our bodies are compelled to advance toward objects of interest and avert our gaze/bodies from objects of disinterest."

Happy = Draw attention to self; we are lighter than air and our appendages can't help but float up.

Sad = Remain small and non-threatening; when we are sad gravity weighs on our body.

<comment><AUTHOR> Also,

* Amygdala triggers emotions, rationalized by neocortex

* Our bodies respond automatically to emotions, even though through the neocortex we can try to modulate and fake our body language</comment></comment>


Reproducing Go binaries byte by byte - <AUTHOR> https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/ <comment><USER2> > Note: the default GOROOT, the one that the compiler will use if the > environment variable is not set, must also match, since it will be copied > into binaries

This seems worrisome for the privacy of builders. What if someone wishing to stay anonymous built and distributed a Go binary from a system where GOROOT included their home directory and revealed their identity? Am I misinterpreting something?

<comment><USER3> Yes, it's worrisome. An issue like this was brought up on golang-nuts in 2014 [1]; the response from the devs was that this behavior is intentional [2], and they note that this happens with other compilers as well.

I'm attempting to say this without sounding facetious: it's generally bad for privacy if you install tools and compilers to a personally-identifiable path, compile programs from personally-identifiable directories, perhaps using personally-identifiable accounts. Using generic paths (which is in this case the Go default), generically-named work directories, and generic-sounding user accounts is a viable mitigation, that has been used by many programmers who get burned by this from various environments.

As you suggest, perhaps there's an education gap here, because this is well- known by security professionals and intelligence services (like the CIA [3]), and less well-known by developers. Furthermore, most of these privacy-leaking behaviors are being (re-)discovered or discussed as a part of the 'reproducible builds' movement (like this one) to attempt to identify context- specific behavior, rather than a concentrated approach about privacy in particular.

[1] [https://groups.google.com/forum/#!topic/golang- nuts/oVDD8oPv...](https://groups.google.com/forum/#!topic/golang- nuts/oVDD8oPvDIY)

[2] [https://groups.google.com/d/msg/golang- nuts/oVDD8oPvDIY/fQ_r...](https://groups.google.com/d/msg/golang- nuts/oVDD8oPvDIY/fQ_r_gECFbUJ)

[3] [https://wikileaks.org/ciav7p1/cms/page_27721733.html](https://wikileaks.org/ciav7p1/cms/page_27721733.html)

<comment><USER4> The devs were right that this does happen with other compilers as well and has been an issue with a great many compilers across a great many languages for as long as I can recall (I remember tearing Windows binaries apart in the 90s to glean information about the developers environment).

Thankfully this is less of an issue these days due to the proliferation of containerisation technologies and automated build pipelines, meaning the build system can be completely separated from developers working environment (eg a Jenkins box)</comment></comment></comment>


Show HN: Duo – a next-generation package manager for the front end - <AUTHOR> http://duojs.org/ <comment><USER2> One question I always ask when looking at a package manager is, "Will this help me have reproducible builds?" ([http://martinfowler.com/bliki/ReproducibleBuild.html](http://martinfowler.com/bliki/ReproducibleBuild.html))

I've worked on enough large projects that relied on prayer and optimism instead determinism when resolving dependencies, and eventually you end up losing hours or days trying to get the app running on a new server or a new developer's box.

Not requiring a manifest is a bug, not a feature. If people can specify dependencies, and information about the version used is lost, then you can be sure that it will happen in practice. Code designed for "proofs of concept" has a funny way of making it into production.

As we know from studies of things like organ donation rates, even the smartest humans get tired or distracted and make bad decisions. The only guard we have against it is choosing sane defaults. (See Yehuda Katz' RailsConf keynote for some interesting insight into how this interacts with convention over configuration: [http://www.confreaks.com/videos/3337-railsconf- keynote-10-ye...](http://www.confreaks.com/videos/3337-railsconf- keynote-10-years)).

While the simplicity of DuoJS allows it to win the Pepsi Challenge against other options, where the first sip tastes very sweet, I would never again willingly choose a dependency manager that makes reproducibility anything other than mandatory.

<comment><AUTHOR> Author here.

@tomdale We're on the same page. I've worked with many large JS codebases as well and consistency and repeatability are a must.

However, as with any tool, it's effectiveness comes from how you use it. There are so many NPM modules that use "*" in their manifests. That's not very robust. Having a manifest isn't a solution, it's how you use the manifest.

In Duo you can pin down any dependency right in the file via require('some/repo@tag'), which is the same as having a manifest with a pinned version.

With that being said, I'm open to any and all contributions or ideas on how to make Duo more consistent and repeatable. I love what Docker does for it's image builds and I think if we could get that kind of robustness going on the frontend, we would all benefit.

<comment><USER3> > In Duo you can pin down any dependency right in the file via > require('some/repo@tag'), which is the same as having a manifest with a > pinned version.

That will do nasty things for your ecosystem if people start doing that in libraries. You'll end up with version lock on shared dependencies:

        - My app depends on foo and bar.
        - foo and bar both depend on baz.
        - They both specify different tags.

Now your solver has a sad, and your user has a sad.

<comment><USER4> Sorry, I think I'm missing something because I don't see the problem -- why can't foo and bar just use different versions of baz? Is it not possible to do that?

<comment><USER3> Let's say your app my_app uses foo and bar. They both use baz. You give them each their own version of baz: foo gets baz 1.0 and bar gets baz 2.0.

Now, at runtime:

        my_app calls foo.giveMeAWidget()
        foo calls new baz.Widget() on its 1.0.0 version of baz
        my_app gets that back
        then it calls bar.doSomethingWithAWidget(widget) and passes it in
        bar calls baz.flummoxAWidget(widget) and passes the widget in
        baz.flummoxAWidget() starts doing stuff with the widget

The last step is bad. You have baz 2.0.0 code that assumes it has a baz 2.0.0 widget, but it's actually a 1.0.0 one. It could work, crash, or fail in some subtle way.

Note that this isn't statically detectable. It's based on how _objects_ flow around in memory at runtime.

Now, in cases where you _don 't_ pass objects around like this, you'll avoid this problem. But it's really hard to tell when that's the case and when it isn't.

<comment><USER5> "Doctor, it hurts when I do this."

What you're describing is an inappropriate intimacy antipattern.

<comment><USER5> Because people keep pinging me on twitter about this, I feel like I ought to explain a bit more.

What's going on in the pattern described is that you're getting a `BazWidget1` object from the `foo` module. Then, you're passing that object you got from `foo` into `bar`, which passes it to `Baz2Flummox(BazWidget2 widget)`.

Why are you flummoxing widgets that you don't know the origin of?

What kind of program needs to mutate state on a object, by passing it from one object-mutator to another? Why do you not have clearly defined ownership of objects, and clearly defined functions that take arguments and return values?

"Inappropriate Intimacy" is a code smell where one class is delving into the inner workings of another, depending on things that ought to be private. The `BazWidget` should be a private implementation detail of `foo` and `bar`, but instead, we are passing this implementation detail from one function call to another.

More specifically, we have `BazWidget1` and `BazWidget2` objects being used interchangeably. It's tempting to blame this on the package manager or module system, but it is just a badly designed program.

This is one class of errors that a "strongly" typed language can often detect and prevent at design time. However, I've seen C++ and Java programs with the same problematic antipattern, just with more layers of Interface wrapping. And, whatever, JavaScript is what it is, and is not "strongly" typed. It lets you pass any value as any argument to any function, and leaves it up to the callee to decide what to do with it.

Personally, I have no strongly held opinion about who's best to handle this responsibility: the compiler, the caller, or the callee. There are benefits to "loosely" typed languages as well, and I'd rather not make this about that.

I've referred to this sort of thing as a "gumby baton". You're passing an object from one worker to another, and each one mutates it a little bit, like runners in a relay race where the baton is made of clay, so it gets the finger print of each worker in turn.

This is a terrible antipattern! This is how we end up with middleware depending on other middleware having been executed in exactly the right order. It is terrible for reasoning about program behavior, and results in unexpected behavior when workers are combined in novel ways. Making programs harder to reason about makes security virtually impossible, and increases the cost of maintenance and re-use. Even up front, it is a challenging pattern to use in building an application, though it sounds appealing in principle if you've never been handed a warped and mangled baton.

So, when I say "Doc, it hurts when I do this", I'm implying that the proper response is "Don't do that".

Ultimately, it's not the compiler's fault. Gumby batons exist in C++ and Java and C and are even possible in pure functional languages. Be on the lookout for it. The compiler won't protect you. The module system won't protect you. You have to use your human brain.

Another caveat just to avoid any "tu quoque" responses: I've made this mistake (and sworn to never do it again!) _many_ times. The most egregious offender in Node is mutating the req and res objects. But, it can be very subtle and hard to spot in the initial design. We just fixed a bunch of really subtle bugs in the lockfile module by changing how it was handling the options object, because it had taken on a gumby-baton behavior internally.

<comment><USER6> Mutation isn't necessary to demonstrate the problem. Consider three libraries: first, there's a basic, widely-used datetime library. There's also a timezone library depending on datetime 1.0 and a dateformat library depending on datetime 2.0.

      # Get the current time in the PST time zone (returns a 1.0 object)
      now = timezone.now_in_zone("PST")
      # Format the date for display (accepts a 1.0 object but depends on 2.0)
      formatted = dateformat.format(now)

Now the problem: imagine that datetime 2.0 switched from one-indexed months (1 is January) to zero-indexed months (1 is February). The timezone library depends on datetime 1.0, so it used "1" to indicate January, giving me a datetime value with month=1. The dateformat library depends on datetime 2.0, so it incorrectly interprets that month=1 as February. All of my January dates will now be incorrectly formatted as February.

(Switching month representation is a rather drastic example, but it's also clear. Substitute a more subtle data format change if you'd like.)

There's no mutation here, and the dependency graph is trivial. I just received a datetime from one library and passed it to another library.

It's possible that I'm missing something, but I've been asking Node users about this for a couple years and I usually get blank stares. I also have no horse in this particular race. Vendoring seems like a great idea to me, but I fear the uncertainty of this version mismatch situation.

<comment><USER7> The problem is here: "(accepts a 1.0 object but depends on 2.0)"

This case actually has nothing to do with nested dependencies. Your time zone lib is returning a datum with one type, which you're passing to a formatting lib that expects a datum with another type. This can happen if your libs have dependencies that are totally different libraries instead of the same library with different versions. It can also happen if your libs have no dependencies at all. This is not an issue of dependencies but of you not understanding your libs' APIs.

<comment><USER6> In most languages, a type mismatch would always correspond directly to a type _name_ mismatch. In e.g. Python (since it has a clear module system), if I know that f() returns a datetime.datetime, and I know that g(t) takes a datetime.datetime, then I know that they will compose. (Modulo bugs of other types, of course.)

When using NPM, I don't have that guarantee. The docs for these libraries could clearly state that they'll integrate around the datetime type, but that may be false in practice. And I'll only know that ahead of time if (1) I know that they both use datetime internally, (2) I know exactly the versions of datetime that they use, and (3) I know exactly how datetime changed in between those versions. With non-vendoring package management, I don't have to know any of these things.

<comment><USER7> You've correctly identified a guarantee that you don't have with npm. In practice, anecdotally, I've never run into this issue, while I have many times and with much pain dealt with conflicting deep dependencies using bower and bundler. Which may explain the blank stares. It's a tradeoff I am personally happy to make.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> It sounds like this means that if I wanted to use a specific version of Ember, I would have something like the following line in many files:

      require("emberjs/ember-component@^1.6.1")

Doesn't this mean that to update an Ember package, I have to change every file that references that package? That would mean having to touch the JS file for every component in your project to bump the version.

Am I missing something?

<comment><USER9> You'd use a component.json to lock it down for an app. The inline versioning is really just a way to quickly write code and get something up and running. Manifests are just a pain when you're just getting started with a project or a small script.

If a component.json is present, it'll use that to get the versions and you just require('emberjs/ember-component')

<comment><USER8> Ah. I would probably clarify the language to make it clear that having a manifest approach is the intended approach for real-world apps, but that it can be left out when playing around.

</comment></comment></comment><comment><USER10> I like the ideas, but it feels like it's just a small incremental step over established solutions like webpack and browserify.

Does this have any more to offer other than deducting what to download&install from the dependency tree? Because if that's "all", it would be easily added to e.g. webpack, I suppose. Is it really worth making yet another dependency _and_ build tool just for that one feature? If you build on top of webpack, you get a lot of stuff for free, like speedy and dependable file watching, hot-reloading development servers, support for nearly any imagineable frontend language, and a remarkably decent extensible architecture. All this has to be made _again_ for Duo.

Both dependency management and frontend building are highly complex tasks. I'm not saying that therefore it couldn't be done better, but I do honestly, without judging, wonder whether the authors seriously considered existing solutions and ran into impossible problems, or whether this is just the Not Invented Here syndrome at work.

</comment><comment><USER11> People interested in Duo may also want to have a look at jspm.io. It solves a similar problem, but with a few differences which to me are advantages:

\- Transparently supports modules from CommonJS, AMD, ES6 or globals.

\- Enforce a manifest (config.js) that let you pin dependencies (incl. transitive dependencies) to exact versions. Unlike RequireJS config, jspm automatically manages that file for you.

\- Support multiple package providers, e.g. NPM, on top of Github.

\- Based on SystemJS, a polyfill for the upcoming standard System loader. This hopefully makes it future-proof.

\- Does not require a compilation step: dependencies can be pulled dynamically from a CDN over SPDY. Alternatively they can be cached locally as well. A compilation step (jspm bundle) is still available.

\- Works both in the context of Node and the browser.

We've been successfully using jspm and SystemJS in production at the Guardian. It's still early days, but the devs are very active and responsive.

This isn't meant to distract people away from taking a look at Duo and making up their own mind, but I noticed nobody mentioned jspm in this thread and thought people may want to look at both and compare.

</comment><comment><USER12> I'm not sure this actually improves the flow for me. I (like most sane devs), like to lock my deps to specific versions (or vendor them). Currently, it's just a matter of running:

npm install --save dep

With this, I either have to be satisfied with not locking down the version, or go lookup the current version manually before adding the reference to my code.

It also looks like upgrading a dep would mean changing every require.

</comment><comment><USER13> Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.

<comment><USER14> I used to think this too, but the more I use Go the more I enjoy not needing to maintain a silly manifest

<comment><USER15> Then when you need to pin down versions and such, it's a massive pain (in terms of not being able to have a manifest file in Go's native case).

<comment><USER16> Pote's GVP/GPM works really well here. It's such a small system to learn and use, but does everything you could ever need when versioning godeps:

[https://github.com/pote/gpm](https://github.com/pote/gpm) && [https://github.com/pote/gvp](https://github.com/pote/gvp)

</comment></comment></comment></comment><comment><USER17> So earlier this summer I learned how to use RequireJS + a smidgen of Grunt, then I felt the need to move towards Gulp and Browserify (which I've just recently started), and now I'm excited about Duo.

It would be interesting for someone with more expertise to do a compare/contrast further down the line of all three.

"...I show you how deep the rabbit hole goes" \- Morpheus

Also, does someone know how the Closure compiler fits into all of this? It might be totally unrelated but I'm trying to learn more about JavaScript application architecture, and I'm not sure where that fits in.

<comment><USER3> > I felt the need to move towards Gulp and Browserify

Dude, you're so behind the times. It's Yeoman and Bower now. Wait, Broccoli and Duo.

<comment><USER18> Yeoman isn't a build tool though, it just generates the application skeleton.

</comment></comment></comment><comment><USER19> Maybe it's just me but having no manifest makes using this tool quite painful. It has taken me 10 mins just to figure out how to structure the require()'s so that it doesn't error out, and that's with only requiring two packages.

For example I created a quick index.js file and required angular and restangular. It immediately errored out because the angular.js repo doesn't use semver on it's master branch. Ok fine, switch to angular/bower-angular, nope, it looks for index.js so my require now has to read: require('angular/bower-angular:angular.js'). Run again, error, same issue with restangular, it's looking for index.js. That require now reads: require('mgonto/restangular:dist/restangular.js'). I had to actually find where the files are that I wanted to require and explicitly state them in the require. Shouldn't this automatically parse bower/component/package.json files for this info, especially if you're touting the 'No Manifest' thing.

<comment><USER9> index.js as the entry point for a module is pretty standard with projects built around Component and npm. It's bower and the lack of the standard there that creates the issue.

<comment><USER20> As an author of a (small) number of npm+bower packages I must admit that nope, that's not "standard" in any meaningful way.

<comment><USER15> It's definitely standard in Node land and also Component(1). Bower, on the other hand, does not and thus is the culprit.

<comment><USER21> index.js is only 'standard' in node insofar as it is the fallback entry point if a package.json file is not found or does not specify a 'main' file.

</comment></comment></comment></comment></comment><comment><USER22> But, but.. I _just_ decided to use webpack :(

More seriously: do you feel like it incorporates all the lessons of its predecessors?

</comment><comment><USER23> I think I'm missing something. I see how this would be great when it's build time but during development I don't want to have to keep running build commands each time I want to use a new package I'm development. Using Grunt and Bower may be a little time consuming up front but once things are set up its very easy to keep a separate Dev and prod environment in sync between different contributors. I only see the value at build time with Duo which is why I'm sure I missed something.

<comment><USER15> You inherently need a build step when working with remote dependencies or even any dependency. Especially when you're working with various assets like templates, css, images, etc...

Typically, let's say for an app, you'll run a watcher which will trigger the builder, so you can just spin it up and leave it alone. For smaller components that are meant for consumption, a simple Makefile is more than enough and running the command isn't too terribly bad.

</comment></comment><comment><USER24> Does a simple `require('package')` without the slashes fetch the thing from NPM?

Maybe it could. Maybe it could also work with `require('firstname.lastname@example.com')` and other sugars like this.

<comment><AUTHOR> require('package') will look into the manifest to see if there's a remote path and version to use, otherwise it will be set as unresolved and ignored in the build.

</comment></comment><comment><USER25> I am a little confused about how Duo actually transforms dependencies into JS values. When I write, say,

var uid = require('matthewmueller/uid');

as in the home page example, what gets bound to the uid identifier?

The point is that a package manager does not only need to fetch dependencies, but also to specify relations between modules. This is why, for instance, Bower only does half the story (fetching) and it has to be coupled with a tool like Require.js to actually provide modules.

<comment><USER25> For clarity, let me make a comparison with the JVM. On the JVM, when one requires a class in a package, it is up to a classloader to find it. The default classloader will look up the class code in a directory structure based on the package name. Where to locate this directory structure is decided based on environment variables, but usually it ends up to having multiple entry points, either on the filesystem or inside zipped files called JARs. A separate tool, like Maven on SBT, can help you fetch JARs from repositories. But what actually makes everything click is the fact that once you have fecthed the JAR, you know where to locate classes inside it based on their name.

In the frontend world there just isn't such a standardization on paths, and this is what makes it difficult to locate a module even when the Github repo for it has been downloaded.

How does Duo solve this issue?

</comment></comment><comment><USER26> I have a hard time seeing what exactly the point of having another package manager is. We already have a very established way of managing front-end packages: NPM and Browserify. I don't see why you would want any of the features that are advertised in this package manager, namely using Github repos vs. npm packages, and manifestless packages. All it gives you is a more fractured ecosystem and code that won't run on the server.

</comment><comment><USER27> Is Duo smart enough to remember when it finds a library requirement with a specific tag? So that it is not necessary to indicate the tag on the other places where this same library is required.

If so, manifests could be written in a very neat way. See: [https://gist.github.com/aymericbeaumet/22c3a9deba54549821e3](https://gist.github.com/aymericbeaumet/22c3a9deba54549821e3)

<comment><USER9> You could also just export from each of the requires in that manifest.js file you have there.

Although there's no real benefit of doing that over using the manifest other than it's kinda cool :)

<comment><USER27> A one could indeed export its requires. However, my idea was was to stay close to the require caching system existing in Node.

As a personal taste, I by far prefer to configure my application in a JavaScript file rather than a JSON file. And I consider dependencies as a part of the configuration process. It agrees with the Duo philosophy which aims to simplify the building process from A to Z.

</comment></comment></comment><comment><USER28> Is there support for symlinking for easy development? I mean the equivalent for 'npm link' or 'bower link'.

Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub?

Bower and npm supports these, and that's what I'm using currently.

<comment><USER9> For private packages, you'd just make the repo private on Github and make sure you have auth details in your .netrc file. So you don't really need your own "registry". There is talk about supporting more than just Github too.

<comment><USER28> That's a rather centralized solution. There are many companies who host their own npm/bower registries, and they won't move to Duo.js until that's possible.

<comment><USER9> But if you're at that point you probably have your own private git hosting somewhere too (or just private repos somewhere else). When there is support added for different remotes you could just require from there instead of Github.

Point is, just use the git repos instead of needing that registry at all.

<comment><USER28> Yeah, that's working solution, when support for that is added. Assuming versioning works with these git urls.

</comment></comment></comment></comment></comment><comment><USER29> Just released a new library so Sass users can now use Duo.js with duo-sass ([https://github.com/stephenway/duo-sass](https://github.com/stephenway/duo- sass)). Check it out!

</comment><comment><USER30> Reading the copy on the page, I wonder if the author has heard of _npm init_ and _npm install --save_. I haven't had to edit _package.json_ in quite a while.

<comment><USER31> Reading the copy on the page, I get the impression that the author dislikes the idea of a manifest (at all) rather than just the act of editing it.

</comment></comment><comment><USER32> npm supports git repositories as dependencies already (git://github.com/...), so that feature doesn't seem like much added value to me.

And considering that any real project needs a manifest, the versioning syntax doesn't seem especially compelling.

I'd like to be proven wrong, because this looks cool... but I don't see the value over npm and browserify other than some syntactical sugar (which could probably be achieved with an npm wrapper). Am I missing something?

<comment><AUTHOR> don't remember the details, for simple repos it's fine, i think it's a dependency of dependency problem, that isaac's didn't want to support for some reason.

here's a rabbit hole of additional information: [https://github.com/npm/npm/issues/3014](https://github.com/npm/npm/issues/3014)

:-)

</comment></comment><comment><USER33> Things are moving fast in the front-end world. Just as we've stopped using RequireJS and accept Browserify as the new king DuoJS comes and overthrows everything again.

</comment><comment><USER34> I love simple things, this gets my +1, look forward to learning more.

I can't see why this is browser only, am I missing something?

<comment><USER13> I'd imagine doing this for node.js would require modifications to node itself since the behaviour of require would need to change. On second thought, I suppose you could just rename packages and mess with their path in node_modules to make things work. But that would mean moving out of the npm ecosystem which seems rather bold.

<comment><USER28> Duo.js could implement duo_require for Node.js. Every "Duo.js Node.js" app would need to be bootstrapped with Node.js require, though.

<comment><USER34> It would be beautiful to have such a simple and open package manager for node. Git FTW :-)

</comment></comment></comment></comment><comment><USER35> The Go link should point to [http://golang.org](http://golang.org)

</comment><comment><USER36> Is it fast during development on large codebases? (e.g. by compiling incrementally)

<comment><USER15> The slow part is fetching dependencies. The "compiling" isn't compiling in the traditional compiled-language sense, where that would most likely take a significant amount of time.

<comment><USER36> The tool might have to recursively parse each file into an AST to find the `require` statements, and potentially apply various transforms (e.g. coffeescript).

On large frontend codebases, these tasks can take an annoyingly long time. Hence, some tools cache (e.g. see browserify vs. watchify).

<comment><USER37> Yup, it will cache the files automatically and check mtime's so that only the changed files need to be reparsed for dependencies. It ends up being really fast to build once dependencies are installed.

<comment><USER36> Fantastic!

</comment></comment></comment></comment></comment><comment><USER38> This looks superb. Great work.

</comment><comment><USER39> _You can require dependencies and assets from the file system or straight from GitHub:_

Oh my. You've essentially killed Bower and NPM in one swoop then haven't you?

An exciting time to be a web developer to say the least, this looks simply amazing.

<comment><USER40> well, except for the `npm install -g duo` bit :-)

</comment></comment><comment><USER41> Did Duo the same as gulp+browserify ?</comment>


Show HN: my iPhone app on algorithm and data structure puzzles - <AUTHOR> http://itunes.apple.com/us/app/code-puzzles/id566255734?ls=1&mt=8

<comment><USER2> tried, its good. keep adding new entries.</comment>


Top Twelve Tips for Running a Beta Test - <AUTHOR> http://www.joelonsoftware.com/articles/BetaTest.html

<comment><USER2> Is it really true you need four betas? That seems high from the betas I've seen.

</comment><comment><AUTHOR> If you're planning on running a private beta, this article is a MUST-READ.</comment>


Free app allows public to anonymously report, share info on sexual behavior - <AUTHOR> http://phys.org/news/2012-09-kinsey-free-app-anonymously-sexual.html

<comment><USER2> Talk about promoting way-skewed sampling bias. But then again, that was pretty much always what the Kinsey Report was about, wasn't it?</comment>


"World's First Solar-Powered Train" Is in Reality a Battery-Powered Train - <AUTHOR> http://www.cat-bus.com/2017/12/the-worlds-first-solar-powered-train-is-in-reality-a-battery-powered-train/ <comment><USER2> Except that batteries don't generate power.

The author goes on to point out that all of the power used by the train is indeed solar-generated, provided by a combination of onboard panels and a solar power plant at its station.

<comment><AUTHOR> Author here: maybe the tone is too controversial. That wasn't really intended as such. I'll try to tone it down.

My twitter was full of 'first solar train' posts, always with the image showing the solar panels on top of the train. I found that the various posts don't make it very obvious where the power for this train is really coming from, implying it's from the panels on top of the train.

My overarching point is that roof-top solar-powered trains are not really possible -- unless you spend most of the time standing still. And that the real innovation in this concept is to power a train by battery, which is something that has had few working implementations and may have a huge impact.

</comment></comment><comment><USER3> Would be nice to fix the units in the article.

In the 'fact sheet' box, the only correctly abbreviated unit is the 'km'. Every 'KWh' should be 'kWh', i.e. kilo and not Kelvin. Similarly, footnote 1 uses both kwh and KWh, neither of which are right. The numbers in the box are interesting, especially since I can't find them on the train's official site (where did they come from?).

The last row in the 'fact sheet' box says "Power of solar plant at station: 30Kwh". Should that be 30 kW? Or is there a battery at the station as well, in which case the text should probably be different. The train's own website (second link in the blog post) doesn't mention a battery at the station and refers to the connection to the grid as "just like a bank", which makes me think that the train is solar powered in a 'bookkeeping' sense.

Another nit is that San Francisco has "solar insolation" and not "insulation".

<comment><AUTHOR> fixed the typos, thanks.

Various numbers in the box are links to articles where they are in the text.

<comment><USER3> It's changed, but not correct.

Currently, all the units in the 'fact box' are KWh. That is "Kelvin Watt hours", which makes no sense. You want kWh, i.e. lower case 'k', upper case 'W', lower case 'h'.

Wikipedia has a reasonable article explaining that 'K' is Kelvin and 'k' is the prefix for 10^3: [https://en.wikipedia.org/wiki/International_System_of_Units](https://en.wikipedia.org/wiki/International_System_of_Units)

Same problem in the footnotes, though MWh is correct, so that's good.

<comment><AUTHOR> Fair enough.

I hope that one day, you'll Win the war against Incorrectly capitalized physical Units that still make sense Due to Context. :-)</comment></comment></comment></comment>


Happy Cogs Redesign Mozilla - <AUTHOR> http://redesignmozilla.org/

<comment><USER2> Wow. I'm pretty underwhelmed by these designs.

IMO all the concepts are giving too much emphasis on big slick graphics and too little on content. I was still left asking "what's your point?" and "am I on a band's website?"

I like that in the current design the focus is on the products. I wish they'd maintain that and use the emphasis on products as the starting point for the redesign.

More people care about Mozilla's products than the _idea_ of open-source.

<comment><USER3> There's a difference between Mozilla.org and Mozilla.com. These designs are for Mozilla.org, home of information about what Mozilla as an organization and the Mozilla foundation are about (as well as for developer resources, which I imagine would be a little less heavy handed than the landing page, regardless of what style is chosen) -- _not_ for Mozilla.com, the product-focused site intended to handle download requests and information about Firefox and Thunderbird.

I think that, while these designs might be a little art heavy for some, they are on the right track, as when you're talking about Mozilla as a public organization and an umbrella of properties, it makes sense to have the sites talking about their broader goals and trying to educate people about the ideas behind the group. Mozilla.com can "sell you" on Firefox and Thunderbird. Mozilla.org can do the same for the principles and resources behind the products.

<comment><USER4> I get that they want to talk more about their principles, but ever heard of "show, don't tell"? If Mozilla really is a vibrant community, then the front page should demonstrate this by being useful to that community. Links to all the things that Mozilla developers do, or mailing lists, or whatever else.

People know when they are being sold. These web page designs are trying to sell. The "product" is that Mozilla is better because of its principles and because there's a community. I admire Mozilla a lot, but... newsflash: NOBODY CARES. Users don't care. Developers sort of care but they know about Mozilla already. If they are looking for donors, perhaps some deluded people think "community" is automatically great, but I'd think it would be more effective to talk about success stories and how provably influential Mozilla is. Once the potential donor is fished in, then talk about why this happens at Mozilla and not at Microsoft.

Even as a marketing website these designs are not very fresh nor do they get to the heart of what makes open source different. It's like someone said "global community" and the designer thought "global... global... how about a globe?" and "community... community... I know, constructivist graphics reminiscent of 1920s communism!" These designs are clueless about what a real software community is like.

I did like the watercolor backgrounds, though.

<comment><USER3> "Show don't tell" is an extremely valid point. I guess I was pleased enough to see that it was so apparent that they told their designers what they were excited about and that it was not the sort of thing that a professionally designed marketing-style website tries to ever communicate, that I was blinded to the fact that I was being punched in the face by a lot of telling and not a lot of showing.

</comment></comment></comment></comment><comment><USER5> Wow. This really brings back the Blake Ross interview from Founders at Work, where he was talking about how the Mozilla developers and designers just plain didn't understand Real People. His descriptions of the crazy design ideas those guys were coming up with read like they were critiquing the designs in this article. It's actually spooky.

The funny thing is, this was the reason that FireFox forked from Mozilla in the first place, and the reason why it became popular with regular people. Now it's back as the main branch of Mozilla, and it looks like the Crazy Communist Dinosaur team is back at the helm.

It's fascinating to watch.

<comment><USER6> I disagree that this is the same thing.

At the release of Mozilla 1.0, the website looked like this: [http://web.archive.org/web/20020802080030/http://mozilla.org...](http://web.archive.org/web/20020802080030/http://mozilla.org/) \-- clearly targeted towards developers, with product download links hidden in a nondescript column. I suppose that's what Ross was talking about: The site didn't offer any convincing arguments as to why you'd want to download their browser, and didn't make it easy to do so.

Nowadays, the download site has moved to mozilla.com which is very much targeted at "Real People", and .org is about evangelism and developer info, at least the first of which these designs reflect quite well. If they go overboard it's on the marketing speak and boldness, but certainly not on technical details and programmer jargon like the old mozilla.org did.

That said, the .com vs .org distinction is probably confusing: They should just move Firefox to firefox.com and drop the Mozilla brand from it altogether.

</comment></comment><comment><AUTHOR> I think these designs fail pretty badly, for the first part, I think I can see around 1/2 elements on each design with my browser opened at slightly than larger size. which is more than enough for every other website I use.

I dont care for the open source propoganda, as far as I can tell from these designs is mozilla want to engage the community a bit more, but nothing pulls me in. I would guess I am in the target market for this and I am not in anyway more inclined to become part of mozillas community

and only 1 of the 3 even have a somewhat decent introduction to the suite!

<comment><USER7> Same impression here.

The huge header graphics are a joke, I'm at a 1920x1600 screen but still get the vertical scrollbar at my normal browser-size.

I also find all offered layouts annoyingly cluttered and uncomfortable to read. The artsy colors and low contrast may work for a webdesign studio portfolio - but I'll prefer the current mozilla.org over each of them any day.

<comment><USER8> Since when were vertical scrollbars bad?

<comment><USER7> They are not inherently bad. It's just a bad idea to have a header graphic take up half of the screen, pushing most of the content below the fold...

<comment><USER9> Oh, lord. Go do layout for a newspaper. There IS NO FOLD... <http://www.boxesandarrows.com/view/blasting-the-myth-of>

<comment><USER7> Yes, there is. The fold is exactly where my browser viewport ends.

Worse yet, google says that most people don't look beyond the _third_ result. So the mental fold is even higher than that.

</comment></comment></comment></comment></comment></comment><comment><USER10> I don't like any of them actually. The most important part of the site, Mozilla's products, are listed below the fold.

<comment><AUTHOR> I mentioned the same point but it isnt really the most important part of the site, obviously a number of people will be looking for firefox etc so it should be easy for them to go to the right site: mozilla.com

but this is mozilla.org, its about the community and the developers, .com is about the products

<comment><USER2> >it should be easy for them to go to the right site: mozilla.com

Theoretically, yeah. But see, a lot of people know mozilla is a non-profit. And thus, must automatically type mozilla.org instead of .com. IMO the two should show the same site.

Of course they must have more solid data and hopefully they are using it to make their decisions.

<comment><USER3> Try an I'm Feeling Lucky for "Firefox." "A lot of people know Mozilla is non- profit," sure, but more people know that there is a browser called "Firefox" and don't give two craps about Mozilla or non-profit or open source or anything else. Surely there will be some fringe cases, but I bet most people who still go to "mozilla.org" for Firefox requests are die-hard old FF/Moz fans from before the .com site appeared, or developers. Most people will, I'd bet, just google Firefox or type in "firefox.com" and be correct.

</comment></comment></comment></comment><comment><USER11> s/Mozilla/Mozilla's website/

Not as advertised.

</comment><comment><USER4> That line "a postmodern style that would make artists like Robert Rauschenberg proud" makes me shudder.

It gives me the sense that, like many designers, they are in frustrated-artist mode. They don't care so much about what Mozilla needs as their personal desire to make super-sized gorgeous graphics that wow their colleagues.

Believe me, I understand the motivation... but I don't think these designs are going to help Mozilla.

<comment><USER12> I was very uplifted by the Rauschenberg name-dropping. Until I saw the design.

;-)

Naw, they will hopefully get better in the next couple of iterations.

</comment></comment><comment><USER13> I'm a little baffled by the 3rd redesign and FutureRuby's (<http://futureruby.com/>) choice of using a Soviet Russia inspired design. I get that they have a futuristic edge to them, and that this is considered cool. But the connotations these designs can imply may make it really difficult to get approval/funding/adoption by gray hairs.

</comment><comment><USER14> Do they not understand the irony of making website mockups for a _browser vendor_ solely as giant images in Photoshop?

<comment><USER3> If they actually implemented them they wouldn't be mockups. If they hacked together some shim to get the text represented as in-browser text instead of baked into the image, people would waste time shitting on their code. Some people prototype extremely quickly in Photoshop, some people prototype extremely quickly in a text editor. No need to hate. :( I imagine, also, that if there really is any irony there, they do understand it.

</comment></comment><comment><USER15> The first design is easily the best, but none are very good. They need to tone down the approach significantly -- all of them are too cluttered to really extract the information people will care about. They need to do something bold and h2-like to explain quickly (one sentence, ideally) what Mozilla is, and then say "Here are our products:" with big, paragraph-level links, icons, and descriptions to Mozilla's flagships, with miscellaneous/other information at the bottom with modest 200x200 pixel icons and three-four items per line, or something like that. They're going way, way overboard -- this can and should be almost all text that follows the reader's flow and puts all the pertinent information right there. Ads for opensource can be placed below the fold or on a separate page. I'm tempted to do a mockup; Mozilla, feel free to send me money if you want one. ;)</comment>


Pixel art stickers - <AUTHOR> http://www.stickaz.com/en/17-invader

<comment><USER2> I tried this out. I think it is really good idea, but really bad implementation. I wanted to draw something, and save it. But I had to login first. If you log in, you lost your drawing. Then I redraw it from scratch, then clicked on the save, and the server went down, so again, lost everything. Sometimes the cursor draws without any click, and ruins all your previous work, and you can't turn it off (maybe a bug). Then I tried other way. What if I just draw a small part, and save it? Before save it automatically cropped my pic for best fit (if you resize your drawing area, you lost everything).

So, for about the tenth time, I finally finished my "nyan cat", and published it, to see what's gonna happen? Some time after, I got an email, that they refused to publish it, and gave me some bullsh*t (one or more of the following) reasons. So one, or more? Why don't they tell me specifically? And some of the reasons were hurtful for someone, who tried so hard to finish something.

Anyway... As I sad before, I like the idea, but the implementation is pretty flawed, and painfully slow.

</comment><comment><USER3> So are the 'classic' sprites public domain? I'm sure the other characters are some minor variation of the original - but it leaves me wondering if copyright has a lower threshold/bound in terms of resolution?

In a 7x7 grid theres still a lot of variations (2^49?) - ranging down to the 'single pixel' works of early 20th century avant-garde monochromatic paintings.

Anyhow, neat product and I'm sure even a lawsuit from Midway/Atari would be good press.

<comment><USER4> There's one case I recall that's close enough. A couple years ago there was a chiptune cover album of the Miles Davis classic Kind of Blue, complete with a pixel-art version of the cover. The photographer of the original cover art sued over the pixelized version. You can read the whole story here: <http://waxy.org/2011/06/kind_of_screwed/>

</comment></comment><comment><USER5> It's very pretty, and I'll likely buy some.

But oh-my-gosh is your server slow! Having to wait 60s between page loads is stopping me from exploring your collection and buying stuff. You need to fix the speed issue, because it's costing you money, right now.

<comment><USER6> Could be that they are in France :)

<comment><USER5> It shouldn't take so long to get from the UK to France though, eh? ;-)

</comment></comment></comment><comment><USER7> So I guess you are familiar with the french street art artist Invader (<http://en.wikipedia.org/wiki/Space_Invader>)

<comment><USER8> it seems so! :)

</comment></comment><comment><USER9> You might want to know that in Italian the name of your startup reads (and sounds) quite badly.

<comment><USER10> I think they know, otherwise they wouldn't have this:

"It all starts with the kaz" prominently featured here

<http://www.stickaz.com/en/info>

<comment><USER11> Explanation for those who don't speak Italian?

<comment><USER10> Kaz sounds a lot like cazzo which means dick.

'Sti cazzi' is a common phrase that is used to express lack of interest in central Italy (who gives a flying fuck!) or amazement in northern Italy (holy shit!).

<comment><AUTHOR> We are sorry if we have offended he italians (especially the ones from the center). It's pretty hard to come up with a name that has no meaning anywhere. If we have enough success, maybe Stickaz will mean "pixel art stickers" in Italy later! Like the Nintendo Wii ;)

<comment><USER12> Italian here (living in Paris BTW): I don't think you've offended anybody, it's just that the name sounds really bad in Italian.

Naming products for an international market is quite difficult: in the 90s Sega tried to sell their game consoles into the Italian market and failed miserably because (my interpretation) nobody wanted to publicize that he bought a product whose name means "masturbation". The Nissan Pajero is another example, they had to rename it Montero in some Spanish-speaking countries.

<comment><USER13> Good comment, although the Pajero is from Mitsubishi, not Nissan.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Your model is excellent. I love it. It's simple, it looks good, and contrary to what others said, you actually have a pretty innovative business model with the possibility to sell crowdsourced designs. But if I were you, I'd make it more interesting for graphics guys. The real innovation would be to do a 70-30 cut like for iPhone apps. If it worked economically, even if it merely covered your costs, it would attract much better designers and many more buyers that would also buy your own designs on which you could make more profit. You're solving a real problem here: geek decoration. Be more ambitious about it!

</comment><comment><USER15> Careful -- Atlus got sued for their game 3D Dot Game Heroes (which was fantastic) over copyright-infringing user-generated avatars. This seems eerily similar.

</comment><comment><USER16> Something random I wanted over the weekend: drop-shipping stickers. Let me set up an account and order stickers via an API given a customer address.

</comment><comment><USER17> Do you have some really LARGE ones ? I just want to restart some post-it war with more modern ammo ;-)

<comment><AUTHOR> We have some large ones! Also you can choose the size of your pixels (up to 5cm), which can make even models with few pixels pretty big!

</comment></comment><comment><USER18> I like the idea, and the website looks good.

However, the website is very slow, I don't know much about your tech team, but IMHO this is something you should investigate if you want to increase your conversion rate.

Good Luck.

</comment><comment><USER19> We built an app thats scarily similar in spirit to this. its at <http://tiny.by> Pretty cool coincidence

</comment><comment><USER10> I noticed some problems with English version (e.g. each is singular), you might want to have a professional check that for you.

<comment><AUTHOR> Thanks for the input, we will fix it!

</comment></comment><comment><USER20> That's pretty cool. I like it.

</comment><comment><USER21> So...if I start selling stuff on ebay, does that make me a "start-up"?

I'm pretty sure you are a couple of guys who setup a wordpress site with a generic theme on a shared server. Also it seems to be having trouble handling the small amount of traffic that comes from 5am hacker news.

<comment><AUTHOR> Well we are really 4 french guys, we are located in Paris in a small office. This is not a wordpress, but a prestashop and the theme is not generic. And the stuff that is innovative is that all the products are created by the community using the studio (<http://www.stickaz.com/en/studio>). Have a look at <http://www.stickaz.com/en/info> for more infos about the Stickaz concept. Tell me if you find similar businesses (appart from sites that let's you decline an image on mugs or t-shirts). Hope you look at it with a different angle :)

PS: we know puxxle, we existed before them and there's no user generated content on puxxle.

<comment><USER21> It definitely looks like wordpress, and it says it is wordpress and prestashop on the bottom. Also prestashop looks like it is just an ecommerce plugin.

Did you guys take VC money or something? This just looks like a normal business to me. I mean I run a small business that makes mobile apps. Is that a start up as well? Is any kind of business with a website that sells something a start up?

<comment><USER18> As much as I agree with the whole discussion surrounding the definition of a startup, your arguments are weak and pointless to say the least.

Would this company be more of a startup if their website was powered with a custom made app written in Erlang on the backend and Haxe on the frontend? ...

Would this company be more of a startup if they could lure some VCs to invest in them? ...

Please come back to earth and provide constructive comments, or better arguments, like pan69 did [1].

[1]: <http://news.ycombinator.com/item?id=4592559>

</comment></comment></comment></comment><comment><AUTHOR> What do you think?

<comment><USER22> Pretty Nice designs, but i find the price a little bit too high considering that your designs are so minimalistic that you are competing with 5mins of Photoshop(to recreate an image) and 3$ of sticker printing paper.

Nonetheless i'll probably order a few for our glass doors in the office.

<comment><AUTHOR> We propose 40 colors, which is pretty hard to find when you try to do a DYI pixel art with photoshop. Also the stickers we propose are high quality vinyl (which is repositionnable). I often see guys do home made pixel arts and Stickaz is just here to make their life easier and their designs cooler!

</comment></comment></comment><comment><USER23> The name in italian sounds hilarious. Awesome

</comment><comment><USER24> Exit through the gift shop...

</comment><comment><USER25> cool</comment>


Ask HN: What happened to https://whytheluckystiff.net/? - <AUTHOR> Based on the current content, it seems the domain has become another how-to tech blog using Wordpress. (Not that there's anything wrong with that.)<p>Has this "passing of the torch" of whytheluckystiff.net been covered before on HN? <comment><USER2> This should maybe be left as an exercise for the reader, but here's the solution:

[https://news.ycombinator.com/front?day=2009-08-19](https://news.ycombinator.com/front?day=2009-08-19)

[https://news.ycombinator.com/front?day=2009-08-20](https://news.ycombinator.com/front?day=2009-08-20)

[https://web.archive.org/web/20090820010834/http://news.ycomb...](https://web.archive.org/web/20090820010834/http://news.ycombinator.com/)

What people may not remember is that, sometime between [https://news.ycombinator.com/item?id=775727](https://news.ycombinator.com/item?id=775727) and [https://news.ycombinator.com/item?id=776473](https://news.ycombinator.com/item?id=776473), we got the second HN Erlang avalanche. I doubt anyone remembers who triggered that one. I tried to find a screenshot of the frontpage at peak Erlang but the Wayback machine wasn't crawling HN so often back then. (It didn't get it the first time, either, but [https://news.ycombinator.com/front?day=2009-03-11](https://news.ycombinator.com/front?day=2009-03-11) is an approximation.)

Later follow-ups:

[https://hn.algolia.com/?query=whytheluckystiff%20points%3E30...](https://hn.algolia.com/?query=whytheluckystiff%20points%3E30&sort=byDate&dateRange=all&type=story&storyText=false&prefix=false&page=0)

<comment><AUTHOR> OP here. It turns out it was explained back in 2013: [https://news.ycombinator.com/item?id=7357580](https://news.ycombinator.com/item?id=7357580)

For some reason, I got my dates mixed up. At one point, _why did publish something post-2009, then went silent. I thought it was back in 2013, but it was earlier than that (between 2010-2012). Then in 2013 people discussed the new Wordpress site on the domain.

It was a problem with my memory, not with being too lazy to "site:news.ycombinator.com whytheluckystiff". Sorry for the mix-up.

<comment><USER2> I didn't mean to imply that you were being lazy! more that some things are best left to be dug up but I couldn't resist spelling it out.

</comment></comment></comment><comment><USER3> [http://whymirror.github.io/](http://whymirror.github.io/)

But potion is now maintaining by me under perl11. libsyck also needs a minor revival I think. I once stood at his front porch but didn't dare to ring the bell. He's doing fine I guess.

</comment><comment><USER4> Don't forget: [https://en.wikipedia.org/wiki/Why_the_lucky_stiff](https://en.wikipedia.org/wiki/Why_the_lucky_stiff)

</comment><comment><USER5> This is around the time I've started my programming career. Many of my buddy went with RoR while I stuck with PHP. I went to a few Ruby meetup with my friends before the web dev boot camps phase started.

If I recall correctly, because this is such a while back, he left and wants to be left alone. Seems like he got issues to resolve and what ever it is it's personal.

As for the website there are dupes out there.</comment>


Is Vendor Lock-In Really a Bad Thing? - <AUTHOR> http://devcentral.f5.com/weblogs/macvittie/archive/2009/11/13/is-vendor-lock-in-really-a-bad-thing.aspx

<comment><USER2> I hope that's a rethorical question ?

The author tries to link the fact that people would like to see data portability in cloud computing to the success of consumer stuff like the iphone and the like.

They are completely different beasts and you can't compare them like that.

As for the closing question: "Has the possibility of "vendor lock-in" ever stopped you from making a purchasing decision or is it just a "potential risk" that's weighed in the overall decision making process?"

Yes, every time. And unless the product has very limited utility for me (say facebook or something like that) I refuse to put myself in to a position of 'lock-in' because experience has taught me that it is only a matter of time before the thumb screws come out.

So even 'free'+'lock-in' won't cut it for me.

<comment><USER3> Playing devil's advocate, I think there's a difference between what you would do and what the average consumer would do.

There's also a difference between something that might be better in the short- term (say over 2-3 years) and something that is good for the long haul.

But I feel the same way as you do, mostly. I'm just more willing to make that trade off for say, a Kindle, knowing that in the near future I'm jumping to an open platform as quickly as possible.

<comment><USER2> I'd never buy an iphone for that reason, and as for the kindle, I'd buy one but _only_ to use it as a reader for open format text files.

The DX isn't available here though, so I guess even that will have to wait.

The reason your 'typical' consumer and the HN audience approach this in a different way is probably because a consumer usually isn't aware of the exact moment they are locked in, they only find out to their regret much later.

But by then it is too late, and the price to switch is too high.

</comment></comment></comment><comment><USER4> Next: Is Sticking Your Hand in a Bear Trap Really a Bad Thing?

<comment><USER5> Vendors like this is what makes me want to get out of IT.

</comment></comment><comment><USER6> Consider the mainframe, and, say, CICS. Things in that end of things are now such that IBM and others are making special efforts to recruit youngsters to work in that world. It seems reasonable to suggest that the reason that there is still all that many COBOL and mainframe shops in the world is due to vendor lock-in.

The cost of that? Well, one can sketch out part of the opportunity cost of that. Consider ITA which fuels Orbitz and others. Their technology, running our idea of modern servers, gets at least an order of magnitude better results than the mainframe technology it replaced.

This old iron doesn't even have _files_ or _filesystems_.

<comment><USER7> But the old iron is almost completely reliable. Forget "five nines" of uptime; we're talking a one and two naughts. CPU modules, disks, and I/O peripherals can be hot-swapped with no interruption to service. Furthermore, the I/O bandwidth on those suckers is through the roof. Likely that's partially because a mainframe computer system consists of a CPU which does the heavy lifting and a whole bunch of satellite computers -- actual computers -- whose whole purpose in life is to drive I/O devices and relay information between them and the mainframe CPU.

When your application _has_ to be up and _has_ to service an entire department or organization for decades on end, the IBM mainframe platform is pretty much the only choice.

<comment><USER2> Tandem (now HP) made good money because IBM stuff wasn't always up.

I've worked for a bank and have seen two serious mainframe crashes. They're rare, but they do happen, and when they happen you can bet that the vendor will get involved because it really isn't supposed to happen. Unlike the PC world, where if a machine crashes it gets rebooted and nobody bats an eye. I blame the 'we're not to blame' culture around PC software manufacturers.

You're spot on about the IO, that is the place where big iron really shines.

The place where I worked had both Sperry and IBM stuff (we got 'bought' and had to move all the software from the Sperry machines to the CICS environment on a 4381).

</comment></comment></comment><comment><USER8> yes</comment>


Feds seized $2.9M from Mt. Gox, court docs show - <AUTHOR> http://gigaom.com/2013/08/19/feds-seized-2-9m-in-bitcoin-funds-from-mt-gox-court-docs-show/

<comment><USER2> Misleading title, USD funds were frozen, not actual bitcoins.

<comment><USER3> Doesn't the technical architecture of the Bitcoin system make the seizure of actual Bitcoins by a third-party impossible or at least very difficult?

<comment><USER2> Yeah definitely more difficult, but it depends on the storage mechanism. But I suppose even if you simply had a private key hidden in some random folder or written down somewhere (there are more secure ways - one is breaking a key into multiple parts and spreading to separate people), it would be hard to locate or identify.

<comment><USER4> It also depends on what possible legal action those parties might have taken against them for not complying with a disclosure request on those funds.

<comment><USER3> So basically: "we can't find your money so you're going to jail unless you find it for us?"

I was talking to a friend about encryption the other day and that was his salient point. Unbreakable key? Break it or go to jail.

<comment><USER5> "Break it or go to jail" is already established law that pre-dates computers ("open this combination safe or go to jail"), but courts have generally held that this law also applies to encryption keys.

<comment><USER6> And if the contents of the safe are written in code, or some made up language that the courts don't understand, can they compel you to translate them?

<comment><USER5> Yes, they can. This has also been true for hundreds of years.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> It appears Mt. Gox CEO Mark Karpeles (MagicalTux on #mtgox) declines to comment: [http://www.reddit.com/r/Bitcoin/comments/1kp4uf/gigaom_repor...](http://www.reddit.com/r/Bitcoin/comments/1kp4uf/gigaom_reporting_that_feds_seized_29million_from/cbr88ch)

      (6:39:17 PM) *Blitzboom*: http://gigaom.com/2013/08/19/feds-seized-2-9m-in-bitcoin-funds-from-mt-gox-court-docs-show/
      (6:39:59 PM) *Blitzboom*: MagicalTux: good thing we hear this from the media, and not you guys
      (6:40:13 PM) *Blitzboom*: now everybody is going to be very calm about this i'm sure
      (6:41:55 PM) *Blitzboom*: though i'm sure mtgox has at least 29k BTC even if it didn't have the cash
      (6:42:01 PM) *AnonX*: god
      (6:42:56 PM) *AnonX*: Reminds me of when the DOJ cracked down on online poker
      (6:45:36 PM) *Blitzboom*: MagicalTux: can we hear something substantial now on this?
      (6:45:40 PM) *Blitzboom*: cat's out of the bag
      (6:45:43 PM) *Blitzboom*: do you have the money or no
      (6:46:43 PM) *Blitzboom*: i mean, if you said you have 90% of the money you owe, then even that would be an improvement to the current spread if it's to be believed
      (6:46:51 PM) *Blitzboom*: that would be only 10% spread
      (6:46:55 PM) *MagicalTux*: Blitzboom: we cannot comment on this
      (6:47:10 PM) *Blitzboom*: you can't comment on whether or not you are solvent?
      (6:47:21 PM) *MagicalTux*: We can't comment on the legal actions in the US
      (6:47:28 PM) *dust-otc*: MagicalTux: as in, compelled by the government not to comment, or advised by your own lawyers not to comment?
      (6:47:32 PM) *Blitzboom*: can you comment on your solvency?
      (6:47:53 PM) *dust-otc*: Blitzboom: Roger Ver can comment on solvency, apparently
      (6:47:53 PM) *Blitzboom*: can you pay out the people you owe?
      (6:47:54 PM) *MagicalTux*: I could comment on the fact that our income since April is around 8 million USD
      (6:48:14 PM) *MagicalTux*: (anyone seeing trading volume can compute that one)
      (6:48:31 PM) *Blitzboom*: all i'm asking is, do you have the money to pay everyone's balance?
      (6:48:38 PM) *dust-otc*: MagicalTux: no, they could estimate your revenue, not income
      (6:49:02 PM) *MagicalTux*: dust-otc: our transparency reports show the costs of running mtgox, and it hasn't changed much

</comment><comment><USER8> They seized these $2.9M months ago, but this re-hashing of the news is causing a run on the money: people are frantically buying bitcoins on MtGox to transfer them out of MtGox (since dollars withdrawals have been somewhat delayed and generally very slow to execute). This is pushing the exchange rate to 120 USD at MtGox, instead of ~100 USD as seen on other exchanges.

[http://bitcoincharts.com/markets/](http://bitcoincharts.com/markets/)

<comment><USER9> Doesn't that mean that there's some crazy arbitrage potential right now for cycling BTC through exchanges?

<comment><USER8> There is a crazy opportunity. But it comes with risk. Risk that it may take months for you to eventually withdraw the dollars from MtGox to your bank account (wire transfers are executed at a glacial pace as reported by users). By that time, who knows what the BTC exchange rate will be. It may not be possible anymore to then buy BTC at $100 on other exchanges.

The last withdrawal I executed from MtGox (1000 EUR in April) took 3 months to be done (saw the money hit my bank account in July). MtGox was apologetic in support ticket I filed, but did not explain why it took so long other than they had "issues".

<comment><USER10> > MtGox was apologetic in support ticket I filed, but did not explain why it > took so long other than they had "issues".

Elsewhere MtGox employees have explained that their bank has limited them to 10 international wire transfers per day due to capacity issues - they claim at one point they were responsible for 50% of the international wire transfers of their bank, the second largest in Japan. Apparently international wire transfers aren't very popular in Japans o they're all processed manually, which doesn't scale to what MtGox are doing.

</comment></comment></comment></comment><comment><USER11> Since when is Union Square been renamed "Satoshi Square"?</comment>


Rise of the Robots: On Peter Thiel's argument about robots and low wages - <AUTHOR> http://www.project-syndicate.org/commentary/j--bradford-delong-questions-paypal-co-founder-peter-thiel-s-argument-that-robots-will-save-us-from-a-low-wage-future

<comment><USER2> "One worker and a computer system can thus do what PayPal would have had to hire 1,000 workers to do a generation ago. Given that the computer system does not need things like food, that thousand-fold increase in productivity will redound entirely to the benefit of the middle class."

Really? I think rather it benefited Peter Thiel's pocketbook.</comment>