A namespace implementation for Emacs Lisp - <AUTHOR> https://github.com/Bruce-Connor/names

<comment><USER2> Personally, in terms of just convention, I've taken to the style of using "packagename/" as a function-name prefix in my own Elisp code. Since the hyphen is the conventional between-word character for function names, it sets it off much better visually.

But more specificially, I don't really like the idea of adding this "feature". I don't mind the extra characters in the function names. Verbosity and clarity are good things. So long as package maintainers follow naming conventions, that's far preferable to trying to read code that may or may not have apparent duplicate function names.

</comment><comment><USER3> I've seen this before and it's definitely a nice stop-gap solution to a well known and common problem.

However the existence of something like this IMO really shows that a feature like this should be Emacs (25?) itself, at the core, preferably without creating indentation issues by leaving your entire module a nesten s-exp.

In an ideal world something like (ns 'my-package) statement at the start of your module should be enough.

In a less ideal world, that simple solution will cause compatibility problems when you want packages to work for both Emacs _pre-ns_ and Emacs _post-ns_.

How to get that done properly is a genuinely hard question. Any suggestions? Any takers?

<comment><USER4> For what it's worth, this macro doesn't cause the indentation issue due to how it's defined[1]. It does, however, leave the extra sexp around your package.

From my experimentation the package worked quite well for the most part but I ended up not using it in the end.

1: [https://github.com/Bruce- Connor/names/blob/master/names.el#L...](https://github.com/Bruce- Connor/names/blob/master/names.el#L373)

</comment></comment><comment><USER5> Isn't it amazing how well Emacs development scaled without basic features like namespaces and lexical scope?

These days I find myself more inclined to try and borrow ideas from Emacs Lisp than to retrofit modern ideas back onto it.

How important can those features really be if their absence has only been a nuisance during decades of development?

<comment><USER6> Dynamic scope (the expectation of it, and the patterns of programming that it encourages) become more than just a nuisance when you try to separate work into tasks that can be handled by any form of task pool. In general any form of concurrency combined with dynamic scoping is at best painful, and at worst a disaster, and working round those issues introduces considerable runtime inefficiency.

<comment><USER7> That is true, but IMHO it is probably irrelevant to Emacs because adding concurrency to Emacs is probably a bad idea.

Firefox of course has concurrency, and IMHO it makes Firefox a lot "glitchier" than Emacs is (or Firefox would be if it did not have concurrency). Several times a day, Firefox goes unresponsive for a few seconds. That does not make Firefox unusable or unsatisfactory, but not being able to rely on a timely response from Firefox 100% of the time to a keypress or pointing-device input really does seem to change the way I use Firefox.

Anyone with experience with math, even with doing multiplications and divisions in one's head, can see that how much complexity the mind can handle is dependent on how quickly one can execute sub-tasks. That is an example of the general principle getting fast -- reliably fast -- at the sub-tasks increases the complexity of the tasks one can handle (and of course it is the reliable quickness of small sub-tasks that glitchiness of the user experience interferes with).

Those without experience with Emacs or Vim (which I am guessing is like Emacs in being 100% responsive) can get an idea of what I mean by comparing their experience in using Firefox or Google Chrome with their experience of using a terminal-emulation app and a Unix shell: although some shell command lines do take a while to produce a response from the system, most of the time, the user can predict when a delay will occur (e.g., a `find` over the whole directory hierarchy) and even when the user is surprised by the presence of a delay, in retrospect there is always a reasonable explanation for the delay if the user is willing to think through and learn about enough details about the system.

(Yes, I realize that there are some applications that some people would like to write in Emacs Lisp that simply cannot be written without concurrency without blocking Emacs for many many seconds at a time. I am skeptical that being able to write those application in Emacs Lisp is worth the cost in complexity and in glitchiness of the user experience.)

The above is a simplification: in reality, glitches do happen in Emacs and in an interactive Unix shell, _but_ I am almost sure that the cause of those glitches is in the underlying OS, not in the Emacs or the Unix-shell process.

<comment><USER8> > Several times a day, Firefox goes unresponsive for a few seconds.

This is caused by concurrency?

<comment><USER7> That is my best guess. I could be wrong. Should people refrain from publishing their guesses on HN?

None of the programs I have used that lack threads, including lynx, have this kind of glitchiness. (Also, I think early versions of X lacked threads and at least when paired with certain video cards, were free of glitchiness -- or more precisely, a user could learn to operate X in such a way as to avoid glitchiness.)

In particular, my guess is that although it is theoretically possible to write huge multi-threaded programs that do not exhibit glitchiness, in reality it is too hard for even very skilled human programmers to do it, and that is why Firefox has the glitchiness property.

I am willing to listen to arguments to the contrary.

P.S. I would have supposed that those who disagree with my conclusion would simply deny that Firefox is glitchier than Emacs or would simply conclude that the difference in glitchiness is irrelevant. Do you agree with me that it is glitchier and that the glitchiness matters?

(Again, I realize the glitches are rare -- maybe only a few a day. They do affect my experience of the app, though.)</comment></comment></comment></comment></comment>


Ask HN: Ruby cache solution - <AUTHOR>

Is it redis the best solution to caching rails app? <comment><USER2> It depends on many factors: whether content changes on a per-user basis, what you're caching, how volatile the data is, what the expiration strategy is, how many separate app servers you have, etc.

If you're caching publicly viewable pages which change infrequently, you should probably be using either page caching (if you have one or a small number of app servers) or a caching proxy like e.g. Varnish.

If you're caching intermediate calculations which are very volatile, Memached is a great choice.

If you're caching intermediate calculations which should be persisted for arbitrarily long periods of time, Redis is a great choice.

I personally use a combination of memcached and Redis for most of my Rails projects. Rails.cache is the memcached instance but I keep a ModelObject.cache instance around which encapsulates a Redis instance but conforms to the general CacheStore contract with regards to read, write, and fetch semantics.

<comment><USER3> I think Memcached is currently better in some specific cluster scenarios, which would hopefully be researched in more depth than "Ask HN" before planning. Otherwise, anything you can do with Memcached, you can do with Redis, but without keys arbitrarily falling out the bottom. Also unless you're bigger than StackOverflow, most of those scenarios can be solved by "throw more RAM in it."

Memcached isn't bad or anything like that. There are many algorithms where "let old stuff fall off the page" is perfectly healthy. I just don't see a need to use both, and I prefer explicitly designed expiry behavior vs. letting stuff fall out of memory, and I find Redis easier to work with.

$0.02, YMMV. If your engineers are used to working with both, having both available costs way less than making them do mental gymnastics to get around not having it, although that might take itself out in onboarding time or code complexity or whatever. But mostly not, if you have good interfaces set up like Patrick.

P.S. - Don't put sessions in Memcached, ever. Having users sessions die randomly because you used too much RAM is terrible design. Putting them in Redis is fine, in which case you probably want to set an expires property when they're created & update it when they're read. Or issue a rename if you're doing one-request-per-key, whichever.

</comment></comment><comment><USER4> Redis isn't a cache, so no it is not the best solution for caching a Rails app. Keeping in mind that other tools you might use, such as background processors like Resque/Sidekiq, also use Redis you should definitely not be using Redis as a cache.

If your setup is simple (single node, few processes) and caching is minimal (just caching some things at boot time) you could get away using ActiveSupport's MemoryStore. Otherwise I recommend just setting up Memcached (it's dead simple).

</comment><comment><USER5> I am wondering if Fragment Caching on File is good enough for a rails app with several K's visits per month?

<comment><USER6> I also wonder about this because the operating system maintains its own cache for frequently accessed files. Or even one could put the file cache on a ramdisk.

Looks like this has been asked before: [http://serverfault.com/questions/624104/rails-filestore- with...](http://serverfault.com/questions/624104/rails-filestore-with-linux- disk-caching-or-ramdisk)

</comment></comment><comment><USER7> Memcached is better suited as an actual cache. Last time I looked if Memcached runs out of memory it purges old cache data. Not sure if Redis can be configured to do this.

<comment><USER8> Yes, there's a Redis eviction policy called `allkeys_random` that's basically the same thing.</comment></comment>


Why Unix needs a standard way to deal with the file durability problem - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/unix/WhyFileSyncStandardNeeded <comment><USER2> IMO the way to tackle a problem like this is:

1\. Figure out the right primitive(s) that applications need to provide both correctness and performance. Make these as simple as possible.

2\. Make a portable library that implements the simple primitives by doing whatever is necessary on each platform to provide the API's guarantees. This will likely require a lot of research/expertise on each platform. The result will be an ugly mess of #ifdef, but _using_ the library will not be ugly.

3\. If implementing the library is impossible or unnecessarily slow on some platform, lobby the maintainers of that platform to provide something better. If they fundamentally disagree with the abstraction, put it on them to counter-propose a better one.

4\. (Optional) lobby to have the primitive become part of the C standard library or POSIX to shift the maintenance burden to the platform owners.

<comment><USER3> Okay, here's a stab at it:

• SIGIOFIN works like SIGIO except it fires when the IO operation completes (is on the disk; has left the network card, etc).

I should be able to use signalfd() to collect these. Let me use TCP_DEFER_ACCEPT on regular file descriptors -- basically let me make sure there are _n_ bytes before being woken up on a fifo, and _n_ events in my signalfd() before waking up.

Here's another idea:

• all() returns a file descriptor that is initially readable.

• on(POLLIN,f,d) while poll(f,POLLIN) would block, d is unreadable

• POLLSYNC added to poll(), etc which is flagged when all previous writes to the file descriptor have reached the disk (has left the network card, etc). To get multiple checkpoints use dup().

I'm not sure which one I'd like better. If we didn't have to make it "primitive", we could simply copy what windows does[1], since they figured this out years ago.

What do you think?

[1]: [https://msdn.microsoft.com/en- gb/library/windows/desktop/aa3...](https://msdn.microsoft.com/en- gb/library/windows/desktop/aa365198\(v=vs.85\).aspx)

<comment><USER4> I advise skipping the signal nonsense and making the interface purely fd- based. The only "advantage" of signals over fd readiness is that signals can interrupt syscalls that don't expect them, and this can be emulated without undue performance loss using asynchronous requests and epoll-style architectures. Signals cause a lot of pain in concurrent (e.g. coroutines and reentrancy) and multithreaded contexts. Plus, including data about which IO request finished and whether it succeeded or failed is more complicated with signals than simply including it in the event structs read from an fd.

Another problem is that this doesn't really address the synchronous assumptions of filesystem (rather than file content) operations: applications expect that they can "mkdir(...); chdir(...); open(...);" and the filesystem doesn't know if the application would work properly with those operations reordered (it may or may not depending on the values of their arguments). Applications need to be more explicit with the transactional nature of what they're requesting from filesystems. Right now the filesystem tries to guess at the transaction structure based on fsync/fdatasync hints, and can't do as good a job scheduling as a result.

<comment><USER5> > Applications need to be more explicit with the transactional nature of what > they're requesting from filesystems. Right now the filesystem tries to guess > at the transaction structure based on fsync/fdatasync hints, and can't do as > good a job scheduling as a result.

How about a transactional filesystem API, where applications can call an API saying "start transaction on current thread", do some IO operations, and then call one saying "end transaction on current thread" (or abort/rollback)?

Windows has something like it: [https://msdn.microsoft.com/en- us/library/windows/desktop/bb9...](https://msdn.microsoft.com/en- us/library/windows/desktop/bb968806\(v=vs.85\).aspx)

Albeit, it is rarely used, and Microsoft suggests one shouldn't use it, and that maybe a future version of Windows might remove it.

I think part of the reason it is rarely used is that it is a whole new API–for many of the existing filesystem APIs calls, they have new versions with "Transacted" appended to their names, and an additional transaction handle argument. If they'd made the current transaction implicit (i.e. thread-local) in the standard filesystem API, it might have seen more adoption.

</comment></comment></comment></comment><comment><USER6> So I never dug deep into the POSIX but I still miss this question answered before I accept the blog post's premise:

What's wrong with the standard procedure

        1. open / create file
        2. write to file
        3. sync file
        4. possibly rename file to final location
        5. sync parent directory of file

Which compliant file systems don't guarantee that this is durable (notwithstanding disks that tell lies)?

Maybe POSIX doesn't specify this exact sequence explicitly (don't know), but this is the folklore which you find everywhere, and it's just what you arrive at naturally when you consider the object model on which the API is built (where an object is an "open file", i.e. what fds reference). (I mentioned this: it's basically the model that git also adopts, except that git objects are immutable).

<comment><USER7> The issue is that most programs do _not_ do step 3: e.g. fsync is not called by C's stdio.

Which means that the `rename` might get reordered before the `write`. Which means data loss. yay!

<comment><USER6> The discussion hasn't been about stdio so far.

Btw. my fflush(3) manpage does mention that fsync(2) is required to ensure data reaches the disk. Of course it's not nice that we have to drop abstractions (and portability) to go the safe way. Let's just say stdio is a bit simplistic.

Btw. many file systems don't reorder write and rename for exactly this reason. But at least ext2 and btrfs seem to do it.

</comment></comment></comment><comment><USER8> I wrote about this yesterday, in yesterday's topic.[1]

Some of the ideas I presented there are from UCLA Locus, circa 1980.[2] UCLA Locus was a distributed UNIX, and an improvement on most of its successors. Multiple machines on a network could not only share files, but you could run a program on a different machine than its files. The machines didn't even have to have the same type of CPU.

Overwriting a file resulted in creating a new file which initially shared all its blocks with the old one. Updating was a copy-on-write type operation. The new file became visible to other readers when closed, or when the writer called "commit()". If the writer crashed, or a network connection was lost, the file reverted. There was also a "revert()" call. Readers thus always saw a consistent version of the file.

Locus also supported replicated files, where two nodes had copies of the same file, but the file was treated as being a single file. If changed, all nodes saw the change.

This was before there were databases for UNIX, and so they gave the file system database-like semantics. It was a good idea that didn't catch on. The technology was sold several times (the sale to SCO was the killer) and eventually open-sourced.[3] It hasn't been updated since about 2010, though.

[1] [https://news.ycombinator.com/item?id=11511269](https://news.ycombinator.com/item?id=11511269) [2] [https://en.wikipedia.org/wiki/LOCUS_%28operating_system%29](https://en.wikipedia.org/wiki/LOCUS_%28operating_system%29) [3] [http://openssi.org/cgi- bin/view?page=openssi.html](http://openssi.org/cgi-bin/view?page=openssi.html)

</comment><comment><USER9> Here's a relevant passage from the essay "Worse Is Better" by Richard P. Gabriel:

[http://dreamsongs.com/WIB.html](http://dreamsongs.com/WIB.html)

"""

Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT.

The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.

"""

<comment><USER10> The quote continues, "The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity. "

As I see it, too many people abuse / misunderstand "worse is better". "Worse" might be better than "perfect" in some cases, but "perfect" is better than "crap", and "trying to be worse" usually results in "crap" whereas "trying to be perfect" usually results in "worse".

Even in the above example, the MIT guy pointed out that the simple implementation results in a complex interface, and undoubtedly much much more time was wasted in the end.

</comment></comment><comment><USER11> The UNIX filesystem should not be used for applications, in my opinion. And for the underlying technologies, like databases, object stores, etc, it's the only option (but not a great one).

Even for something simple like photos, it's not good:

* durability problems

* hierarchy doesn't work out well (browsing by dates vs people vs event types can't all work in the same hierarchy)

* you want storage on and accessibility from more than one machine

* something like content-addressed storage probably makes sense to avoid unnecessary duplication

Then, for underlying tech like databases it's not great either. Postgres used to initialize the data directory without syncing it. That makes sense for production, because who is going to put important data in it and crash within a few minutes? But it caused problems with testing, so I fixed it. To do such a trivial thing: write out a bunch of files and sync the whole directory, it was very non trivial. Syncing the files individually was very slow (because I have no clue what the most convenient order is for the OS to sync the files). I had to use the linux-specific sync_file_range() to get decent performance, and then it was still slow so we needed a way to optionally turn it off (e.g. for tests where it's not important). Horrible. It would have been much better to just say: do all of these things and sync them in the most convenient order, then tell me when you are finished. Kind of like a log based system.

<comment><USER12> You can fake multiple hierarchies with hard links. The only problem is you can't delete every hardlink easily.

<comment><USER13> Your app has to define it's own cascading delete strategy.

</comment></comment></comment><comment><USER4> I'm so glad this is being discussed. The intricate and weak durability guarantees, the unaddressed dangers of global mutable state (without reasonable locking capabilities outside of "only ever write something so small the OS wouldn't ever decide to break it up"), and the inability to properly deal with files and the filesystem asynchronously are gaping holes in POSIX (and Linux) semantics.

Maybe we can actually get a powerful asynchronous IO API that allows the OS to schedule disk requests effectively and applications to avoid blocking in situations where they don't have to, while providing more guarantees about data durability and concurrency. It's undeniably possible, but it will require a level of coordination between parties (standardization and work from kernel hackers in Linux and other OSes, userspace libraries to expose new kernel functionality, applications switching over to use the libs) that I hadn't expected to see come together. Maybe these discussions will provide some impetus to get people working on all sides of the issue.

Anyone who hasn't read them should see the comments on previous discussion of this topic, which demonstrate how hairy this area is right now: [https://news.ycombinator.com/item?id=11511269](https://news.ycombinator.com/item?id=11511269)

</comment><comment><USER14> I said this in the previous thread and I'll say it here too: Rethink the Sync is an attempt to solve this problem from ten years ago.

[https://www.usenix.org/legacy/events/osdi06/tech/nightingale...](https://www.usenix.org/legacy/events/osdi06/tech/nightingale/nightingale.pdf)

Basically (read my comment in the other thread for a bit more info), you get file durability and good performance without ever having to type the word "sync", all with the standard POSIX interface.

<comment><USER15> That paper was the first thing I thought of when I read this, too. It really is a fascinating solution to this problem. Any ideas why external synchrony didn't catch on?

I suppose one could argue that the implementation would add a decent amount of conceptual overhead to the kernel, for comparatively little reward (application authors can fsync now, etc.).

<comment><USER14> I wonder if the Linux folks are even aware of this paper. Maybe they're not?

</comment></comment></comment><comment><USER16> I still don't see why this is such a big deal. Let's say everyone agrees on a standard and guarantees to make fsync() send data to a disk. Does this guarantee even worth anything? Will every disk suddenly disable write cache on itself by default? Who is going to sacrifice performance and make it a default? Even if somebody is going to do it, will disks suddenly become bug- free, 100% reliable and indestructible?

<comment><USER17> fsync works fine with on disk write caches (if the OS so chooses, ie not OS X). It's all specified in SATA and SCSI. Yes you can have bugs and lying devices, but reputable stuff is generally fine.

<comment><USER13> Many consumer drives tend to omit this feature (or lie about it) because all anybody looks at is size and iops. Nobody sells more consumer drives by advertising that the writeback cache on the drive respects flush commands (and barriers).

<comment><USER17> Which current or recent sata/scsi drive omits or lies about cache flush commands? Leaving FUA unimplemented is fine. Bottom of barrel flash sticks probably do lie, and some IDE era PC drives did, but major disk vendors are pretty sensitive about their reputations wrt data integrity now.

<comment><USER13> A few years ago some of the intel SSD drives has issues with this. [http://www.evanjones.ca/intel-ssd- durability.html](http://www.evanjones.ca/intel-ssd-durability.html) Drive was advertising FUA but it didn't actually implement it (or implemented it incorrectly).

Then there were drives that were storing things in cache and reporting as written but didn't actually have capacitors to write out the data in case of power failure. [http://lkcl.net/reports/ssd_analysis.html](http://lkcl.net/reports/ssd_analysis.html) , also the paper from FAST13.

I think in 2016 the situation looks much better.

</comment></comment></comment></comment></comment><comment><USER18> No this isn't the same article that was posted the other day. Is a response to comments.

</comment><comment><USER19> Even if API gave you strong durability guarantees, it still wouldn't mean much. Disk caches, big enterprise SAN attached storages etc, they can also "cheat", saying they flushed the cache while they actually didn't.

<comment><USER20> The API allows blaming the right cog in the machinery. Now everyone gets a Get Out Of Jail Free card because they can blame the kernel, filesystem drivers, userspace libraries, application developers, disk controllers, and whatnot, and thus nothing forces a single direction in that cyclic graph of blame.

</comment></comment><comment><USER21> While OP makes good points, I think there is no way to guarantee data persistence on a single node. Especially with the SSDs.

<comment><USER22> OP is not asking for something that will guarantee a complete, safe write on all systems under all conditions in all logically-possible universes.

OP is asking for something that, if it loses data due to the way the filesystem or operating system behaves, would be treated _as a bug in the filesystem or OS_ , rather than a "lol, this idiot didn't even do (set of syscalls unique to the particular FS/OS combination), not our fault it didn't actually write after it said it would".</comment></comment>


Advanced Economies Must Still Make Things - <AUTHOR> http://spectrum.ieee.org/at-work/tech-careers/advanced-economies-must-still-make-things <comment><USER4> Advanced economies must still make things, but there's no rule that says that those things have to be made by _people_. In inflation-adjusted dollar value terms, the value of US manufacturing has never been higher. In employment terms, it's never been lower. While there are those who blame outsourcing for that, the vast majority of manufacturing job losses have been due to automation, rather than competition from abroad.

For example, look at this video of a MillTurn M60: [https://www.youtube.com/watch?v=81UjjSH2iFw](https://www.youtube.com/watch?v=81UjjSH2iFw). This one machine replaces an entire shop floor of lathes and mills... and all their operators, too.

<comment><USER5> > the vast majority of manufacturing job losses have been due to automation, > rather than competition from abroad

Source?

<comment><USER6> >the vast majority of manufacturing job losses have been due to automation, rather than competition from abroad

The reason why this lie is so commonly repeated is that technology makes a better scapegoat than the American elites for declining standards of living.

You can't jab a pitchfork into technology.

You _can_ jab a pitchfork into the American elites who formulate trade policy that ships jobs overseas.

This misdirection and the anger it fomented is largely responsible for the sudden rise of Donald Trump.

<comment><USER7> ...Who plans to get rich by selling pitchforks, but has no intention of allowing them to be used - except possibly to remove his competitors.

I'd guess that only around 10% of the US population - 20% at best - has any practical understanding of how the US economy and political system actually works.

It's the easiest thing in the world to move blame towards immigrants, high rents, automation, Google, and just about any other target far removed from the actual architects of declining general living standards.

<comment><USER6> We'll see. Trump has said that he will prevent TTIP/TPP and put a 40% tax on Chinese imports, but who knows if he will follow through.

I certainly don't think that he'd be at all bothered by the economic fallout of those things.

<comment><USER8> If Trump really wanted to make America great again, he'd drop all import tariffs, put a 40% tax on American _exports_ , and throw some chum in the water.

When the acquisition-merger frenzy dies down, the last corporations standing would not be ones that you would want to encounter in a dark alley. And, apparently, they would all be software development houses, agribusinesses, LEO launches, and pizza delivery chains. Americans would no longer do _anything_ that they are not objectively best at doing in the global marketplace. They could not afford to even _try_ anything else.

But whatever. Let's just try the Hawley-Smoot tactic all over again, and see if it turns out differently this time.

<comment><USER9> Why would you want to tax exports? It is as damaging as taxing imports, as it stands into exactly the same kind of barrier.

It's way better to base taxation choices on the need to collect money, plus a rare, exceptional sin tax. Taxation choices based on commercial strategies are almost universally poor.

<comment><USER8> Sorry. That was intended to project as facetious. This US presidential elections cycle has made me more cynical and pessimistic than ever. I was just making a modest proposal for an _all-new_ horribly bad idea rather than repeating the same old horribly bad idea once more.

The best trade policy for everyone is to have no artificial barriers to trade at all. But such a policy cannot be as easily exploited for votes.

<comment><USER9> You simply won't get an argument about foreign commerce that sounds too stupid to be taken seriously.

This export tax, for example, it was not only proposed but even implemented several times around the world - Russia has once gone to the extent of forbidding agricultural exports.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Amen to that. In general, I think successful economies should strive to be pretty balanced sector-wise, for two reasons:

1\. Like with outsourcing, if you have enough people to be experts in a given thing, it will probably cost you more to outsource than to keep local expertise, due to additional transaction cost (transport, culture barrier, outsourcer profits, corruption..). And nations typically have more than enough people to be experts in some basic economic production infrastructure.

IMHO, it only pays off to outsource high-end stuff, like microprocessors, to other nations. It is also good for a nation to be expert/leader in some area like that. Switzerland is a good example of this.

2\. There are network effects when you have mixed economy. How can you produce any good, say, agricultural machinery without agriculture? You may be the best machinist in the world, but without trying it out you don't know what problems you're solving. IMHO, this adds up very quickly. Similar with computing - <USER2> cannot solve manufacturing problems without having manufacturing industry in the same place you have the people who know computers.

It may seem that in today's connected world it wouldn't matter, but I doubt it. You need to get people from different fields to know each other, to talk over lunch or beer about problems they have. I think (in the U.S. at least) there is also social stratification issue, which is partly resulting at people poking at startups (sometimes rightfully so) for stupidly catering to middle classes instead of solving real problems.

<comment><USER11> _> successful economies should strive to be pretty balanced_

The economy is not a thing that can "strive" for anything. Rather, the economy is simply the collection of actions taken by people in the market.

Let's ask, why are those economies successful in the first place?

 _> stupidly catering to middle classes instead of solving real problems_

That's a bit condescending, don't you think?

<comment><USER10> > The economy is not a thing that can "strive" for anything.

Of course it can, it's a component of human society, and societies can "strive".

> Rather, the economy is simply the collection of actions taken by people in > the market.

Just like actions of individual humans is "simply" result of actions taken by individual neurons.

> Let's ask, why are those economies successful in the first place?

Sure - Ha-Joon Chang was already mentioned, and I wholeheartedly recommend his books. From his perspective, "free trade" is just one possible economic strategy, that is useful on a certain level of economic development.

> That's a bit condescending, don't you think?

Sometimes deservedly so. If I believed in the rationality of the free market, I would be confused by huge valuations of advertising IT companies.

Anyway, I am not really judging those people, I was just making remark that they are criticized. In fact, I am (almost) one of them, I work for large SW company that does IT support software for big corporations like banks. I would probably prefer to improve software for manufacturing, but the truth is, it just doesn't pay that well as this.

</comment></comment></comment><comment><USER12> Why do we have to make things? Or why tangible things?

Take for instance the financial sector. They make allocation decisions in essence and sell service around management, consulting, and financial engineering. A large chunk of our economy is based around resource allocation, not actually turning resources into products more efficiently than the last guy.

As an economy progresses, it moves further and further away from things and towards ideas. We went from hunters and gatherers of food and clothing, to agriculture, to machining things, to primitive banking, all the way up to modern financing.

At each step we became further and further removed from actually putting iron- to-iron and producing this. We become more involved in how to efficiently allocate resources for those that did produce.

And that population of those that do produce continues to fall as automation comes along and we become better at making more with less. Finance has really put productive resources to amazing efficient use though capitalism.

We will get to a point where almost nobody does machines or sits on an assembly line anymore, and their jobs will give way to a larger and larger pool of people who work in the meta-market, the mental-based market that really drive the physical-based market.

<comment><USER13> There's a well-trodden argument that much of financial innovation has little positive effect or even negative effect on the larger economy.

Jack Bogle, founder of Vanguard Group:

"The job of finance is to provide capital to companies. We do it to the tune of $250 billion a year in IPOs and secondary offerings. What else do we do? We encourage investors to trade about $32 trillion a year. So the way I calculate it, 99% of what we do in this industry is people trading with one another, with a gain only to the middleman. It's a waste of resources."

[http://time.com/money/3956351/jack-bogle-index- fund/](http://time.com/money/3956351/jack-bogle-index-fund/)

Paul Volcker, former chairman of the Federal Reserve:

"Echoing FSA chairman Lord Turner's comments that banks are 'socially useless', Mr Volcker told delegates who had been discussing how to rebuild the financial system to 'wake up'. He said credit default swaps and collateralised debt obligations had taken the economy 'right to the brink of disaster' and added that the economy had grown at 'greater rates of speed' during the 1960s without such products."

[http://www.telegraph.co.uk/finance/economics/6764177/Ex- Fed-...](http://www.telegraph.co.uk/finance/economics/6764177/Ex-Fed-chief- Paul-Volckers-telling-words-on-derivatives-industry.html)

IMF:

"...the effect of financial development on economic growth is bell-shaped: it weakens at higher levels of financial development."

[http://www.imf.org/external/pubs/ft/sdn/2015/sdn1508.pdf](http://www.imf.org/external/pubs/ft/sdn/2015/sdn1508.pdf)

OECD:

"...above a certain point, further financial expansion is associated with slower growth."

[http://www.oecd.org/eco/How-to-restore-a-healthy- financial-s...](http://www.oecd.org/eco/How-to-restore-a-healthy-financial- sector-that-supports-long-lasting-inclusive-growth.pdf)

<comment><USER14> > "The job of finance is to provide capital to companies. We do it to the tune > of $250 billion a year in IPOs and secondary offerings. What else do we do? > We encourage investors to trade about $32 trillion a year. So the way I > calculate it, 99% of what we do in this industry is people trading with one > another, with a gain only to the middleman. It's a waste of resources."

Very few people would invest in IPOs or secondary offerings without a secondary market for the shares.

</comment></comment></comment><comment><USER15> I find the whole discussion of what "economies must" and what "economies should" baffling. Economies don't have wills of their own. Economies describe the voluntary economic activity of millions to billions of people. Economies end up doing what is profitable, and possible (given skills, capital investment, infrastructure). When someone says "Economies should" what they're actually saying is: "I wish the government would spend a lot of money or pass a lot of laws to force the economy in the direction I want".

<comment><USER16> If you understand what people mean, why do you find it baffling?

But in any case, it's not necessarily a prescription, it can be simply an observation, as in, "advances economies must make things [if they are to remain advanced]", no different than a biologist might say "species A must increase their reproduction rate [or go extinct]".

<comment><USER17> I think what he's saying (and your example doesn't contradict) is that there exists a common fallacy of confusing individual firms' complex behaviors, like planning and executing a new manufacturing plant, with emergent behavior.

Similarly a species doesn't increase its reproduction rate: it grows in numbers or it shrinks (to the point of extinction) based on individual specimens' reproductive behavior. The equivalent in economics here, I think, would be net exports. Though there is correlative power between the firm and the economy, the specimen and the species, the incentives and long-term/short- term outcomes might not be aligned, which has implications for policy.

</comment></comment></comment><comment><USER18> _" manufacturing is still important for the health of a country's economy, because no other sector can generate nearly as many well-paying jobs"_

This is a tricky starting point. Economies have all sorts of side effects that are important. But ultimately, economies are supposed to produce stuff that people consume. We have plenty of pots and pans, furniture, cars, etc. The price of manufactured goods has been dropping for centuries and the quantity has been rising. As the article states, manufacturing is still growing. Wanting manufacturing to keep pace and maintain a proportion of the economy well... We don't need that much manufactured goods.

<comment><USER19> > We don't need that much manufactured goods.

And I think we're needing less of them too. Everyone who opts to rent vs own is one less mower to sold, one less shed to be built, one less piece of "infrastructure" to maintain. We're all begging for shared public transport which will result in less vehicle production. The way we live fundamentally shapes our economy; I feel like we forget this sometimes.

</comment></comment><comment><USER20> This has been known for some time (and proven with some good examples) but still is a shock to people who believed somewhere in '90 that the next stage in the economy is the shift to services instead of industry.

I recommend this book from Ha-Joon Chang that has a nice chapter on that (a very pleasant read with references): [http://www.amazon.com/Things-They-Dont- About-Capitalism/dp/1...](http://www.amazon.com/Things-They-Dont-About- Capitalism/dp/1501266306)

<comment><USER7> > still is a shock to people who believed somewhere in '90 that the next stage > in the economy is the shift to services

You should tell the UK's political class. Moving away from manufacturing to services has been been official dogma here since the very late 1970s.

As a result we have an economy founded almost entirely on tax havens, speculation, sporadic renovation projects for rich people, and asset price bubbles, with a bit of marketing and corporate communications around the edges.

</comment></comment><comment><USER21> Unfortunately, making _things_ reduces your profit margin. You can't be a unicorn if you actually have to live on a profit margin.

<comment><USER22> Although bsder was snarky as fuck when he wrote the above comment, I don't think he should be downvoted for it. I mean, frankly, I agree with the sentiment.

A lot of unicorn fillies seriously try to base their model around doing as little as possible, as flashy as possible, with as little expense as possible.

On paper, that is a great idea, everyone should do it, viva la venture capital, etc. In reality, it isn't shareholder value you need to provide: it is _customer_ value. If you are not a valuable product or service to your customers, _you have no shareholder value_.

A lot of silicon valley venture capitalists forget that very important distinction, and we are well on our way to Dot Bomb 2.0, repeating the late 90s clusterfuck that made a few billion dollars vanish overnight.

To tie this into the "advanced economy" theme, an advanced economy doesn't inflate bubbles. America still inflates bubbles: we aren't as advanced as we think we are, but we _are_ improving.

<comment><USER23> I am horrid at predicting the future, but I'm seeing too many of these cute companies' commercials like Birchbox, Lollipop, cute.com, cute30employedfemale.com, cutesinglebadgirl.com, boredhubbyathome.com, buymycutechinesegabage.com, hayourvansarecutebuyyme.com, dinkswhobuythings.com,(this will perk up marketing majors.), etc.

I see a big crash. So big, rents will drop in the Bay Area--big time!

I guess homeless shelters/programs won't be controversial? I really cringe when I think about the future.

(I'm kinda just kidding, but some of these companies just look like they are trying to spend what's left of the funding on advertising? Don't get me wrong EBay needs competition, and dating services need competition, but don't do it in a cute way? Just offer a good product. Low fees, and honesty. Get rid of the MBA's. Get rid of the Designers, at least the one's who are just copying a TED presentation?)

</comment></comment></comment><comment><USER24> I didn't feel this article was clearly thought out. If just manufacturing things, whatever things are, were important then possibly replacing (magically) the industrial sectors in the US with those from China would be a good thing. If that came about then of course the US would be much poorer, possibly as poor as China. Its also not sufficient to say manufacturing is a source of good paying jobs. Highly skilled manufacturing sectors provides good wages and benefits (say, semiconductor manufacturing), piece work in say the garment industry provides sub subsistence level wages. A better title would be - "it matters what an advanced economy produces". I used to work in manufacturing (all over the world) and here a few impressions based on my experience. In the factories, today, where people in advanced economies would want their children to work, there are more robots than people. The ratio of automation will increase over the next 10 years as the machines become smarter. In advanced countries it is more and more common for manufacturing facilities to require the skills of people with PhD's, Masters degrees and highly trained vocational workers to function. There are going to be very few jobs in 10 years for people who can just contribute muscle power. Even in the far east, manufacturing is going to be a sector of falling employment (like agriculture in the past) and at the same time of rising output (like agriculture). And lastly, here is a thought, based on my experience running a business. There is lots of competition out there in the world. One cant make a good living producing any "Thing". One has to find a product that is differentiated, valuable to others, and not easily reproduced by thousands of other businesses all over the world. And then one has to sell it. That's turns out to be a difficult job -- much more complicated than a slogan like "manufacturing".

</comment><comment><USER25> There is not much if anything in this article to support the headline claim. I'm not saying it isn't true, but the article doesn't provide any evidence of that.

Yes Toyota employs more people than Facebook. What does that tell us exactly? The film industry employs more people in the U.S than the auto industry.

If the numbers in this article show anything, it is that the most advanced economies vary hugely when it comes to the size of the manufacturing sector.

I think the case for a manufacturing sector that isn't 0% of the economy can absolutely be made, but this article doesn't even start making it.

</comment><comment><USER26> With the same argument, agriculture is important for advanced economies, because no other sector can generate as many jobs. Remember, not too long ago a large majority of the people were farmers.

Eventually we'll have to move away from the notion that everybody needs a job that contributes to GDP.

<comment><USER27> > Eventually we'll have to move away from the notion that everybody needs a > job that contributes to GDP.

The goal is not maximum employment, The goal is maximum production. Whether that involves more employees is a totally different topic.

<comment><USER28> The goal should be maximum happiness.

<comment><USER29> Employment and production are easy to measure. Happiness, less so.

<comment><USER28> That's a bit of an odd reason to change the whole goal, isn't it?

So we track the kinds of things that we can measure and that we hope correlate with happiness, but we carefully check that they keep doing so. We shouldn't let one of them (like "maximize production") become the end goal itself!

<comment><USER29> > That's a bit of an odd reason to change the whole goal, isn't it?

Having a goal of 'maximising production' is the status quo - I am not proposing any changes.

I agree with you that the world would be a better place if our economy was focussed on achieving maximum global happiness, I just wanted to point out why it is easier to focus on an objective, numeric value like production than a subjective feeling like happiness (Gross National Happiness notwithstanding).

</comment></comment></comment></comment></comment></comment><comment><USER30> Oversupply and stagnation were solved in the past by wars or new worlds' colonisation. Considering that Planet Earth is full and that we do not want a nuclear war, the best opportunity for mankind is Moon or Mars colonisation. Exploration has always been the distinctive trait of humans and still will be.

<comment><USER31> > the best opportunity for mankind is Moon or Mars colonisation.

Mars and the Moon are not suitable for long-term colonization. Maybe research bases, like Antarctica. But it's hard to see why anyone would want to live in a near vaccuum (average pressure on Mars is 0.6% of Earth's average) in a low- gravity environment (38% of Earth and 16% of Earth, respectively) for their whole life.

We may be able to engineer successful Moon and Martian bases in the near future. But live there? You'd always either be underground or in a heavily shielded dome, never able to go outside, and the compromise of which would mean almost certain death. Further, low gravities have negative long-term health effects, and even if we ignore those, if you spend your whole life on Mars, going to Earth is going to be hellish torture.

I'm all for space colonization, but I think if we're going to look at _colonizing_ an extraterrestial body, which should at least be looking for something that has approximately Earth gravity and a real atmosphere. In our solar system, that just leaves Venus, which obviously comes with huge problems of its own, but perhaps they can be resolved with some kind of terraforming technology and a lot of time. (Bacteria to convert CO2 to oxygen to cool the atmosphere and make it breathable?) Probably we'd be better off looking for extrasolar planets that fit our criteria and developing the necessary engine technology and maybe cryogenics - keep relativistic effects in mind.

Or we could just invent artificial gravity. That solves a lot of problems. :)

I think we're best off looking after the Earth, for which we are tailor made.

<comment><USER32> Maybe not large scale colonization - but once the Martians start having kids (if possible) and produce them in large numbers, imports from Mars (specialized, high tech manufacturing equipment) will increase. The Martians born there will not care living under harsh circumstances - they won't know any better. They will just keep working to make their lives a bit more comfortable, one generation at a time.

<comment><USER33> What product do you imagine can be created on Mars that cannot be created and delivered to a customer on Earth from some other place on the planet or from orbit? Mars has nothing we need or want and is too far away to make shipment worthwhile.

<comment><USER34> >Mars has nothing we need or want and is too far away to make shipment worthwhile.

They might have some rock there which would make for some really unique countertops or jewelry. Considering how much money people spend on diamonds, which are really quite worthless because they're so commonplace, I could see people spending tons of money on jewelry made with Martian rocks.

</comment></comment></comment></comment></comment><comment><USER35> the statement " no other sector can generate nearly as many well-paying jobs" would mean more if they showed loss of jobs due to automation and projected how future automation would effect the ability of manufacturing to produce so many well-paying jobs.

Because maybe the argument is Advanced Economies must still make things for the next 15 years after which it's not really worthwhile.

</comment><comment><USER36> I have predicted this for a long time (not just me, but a lot of people).

The demand for human labor is going down on average, so wages are going down - and have been on a decline since the 70s. Capitalism relies on employers to value their employees for the money to trickle down and the system to work. Our grandfathers used to work for the same employer for decades and got a pension. Today, that loyalty is unheard of from either side. We have the rise of temps and the contractor economy and unemployed living with parents.

Yes, the cost of mass produced consumer goods is going down. So the wage repression is mitigated. With the explosion of consumer credit in the 80s and 90s, the unsustainability of consumer spending was also masked. Now it has come to the fore, in exactly the areas where costs are not going down: rent and real estate. In every major city including NYC and SF, the costs of rent are sky high relative to wages. Wonder why? Look at the rest of the country and it's true too -- the rents are slightly lower but the wages are lower too.

So the predictions are borne out... automation has reduced demand for human labor, reduced wages for the average worker (or they got laid off / became temps), reduced the prices of mass produced goods, but the cost of real estate keeps rising.

<comment><USER37> Capitalism relies on employers to value their employees for the money to trickle down and the system to work.

It is not capitalism but rather neoliberalism/monetarism that propels the trickle-down theory. The time period where grandfathers worked for the same employer and then got a pension coincided with the post-depression/WW2 period of Keyensianism when many western governments pursed full employment economies via fiscal policy.

In the period from the early 1970s onwards when neoliberalism/monetarism has been dominant, we have seen falling real wages, the financialisation of the economy (including the consumer credit explosion you describe), governments restricting themselves to managing the economy only through the very blunt tool of monetary policy (i.e. interest rates via a central bank).

I would argue that the symptoms we both identify are the result of neoliberal/monetarist policy rather than decreased demand for human labour. If governments still pursued full employment via fiscal policy things would be very different.

<comment><USER38> How do you encourage full employment with fiscal policy?

Does the concept of full employment imply large corporations hire most of the people or do the fiscal policies also encourage small business and self employment?

<comment><USER37> It can be all of the above, plus government employees.

An example would be government funding of large infrastructure projects that employ lots of people during construction.

</comment></comment></comment></comment><comment><USER39> A few notes about the shift from manufacturing to a service based economy:

\- Services take a larger share of GDP by staying flat while prices of goods fall. You pay less for most manufactured goods than you did 20 years ago, while your haircut cost about the same.

\- Services are generally harder to export. You can ship a physical product, it's hard to export a haircut.

\- Goods can be stockpiled/scaled if needed, services cannot.

</comment><comment><USER40> It's kind of obvious that no one can live if we only have services and money printing.

Someone must produce something (and preferably something with a high price / cost ratio), this applies to manufacturing as well as agriculture.

The biggest news (and very sad at that) is that "making things" is so far away from the mainstream economic models that formerly common sense rules are worth a headline.

</comment><comment><USER41> > And yet manufacturing is still important for the health of a country's > economy, because no other sector can generate nearly as many well-paying > jobs. Take Facebook, which at the end of last year had 12,691 employees, > versus the 344,109 that Toyota had at the end of its fiscal year, in March > 2015. Making things still matters.

There are so many assumptions in this article but especially here. Author assumes people are required to make things, they are not. Author assumes factory jobs will pay well, they often don't, and there's no reason they will. And the employment disparity between IT companies and Manufacturing is showing that you can create a ton more wealth with a small number of IT people than a huge number of manufacturing people, which is why Wall Street values those companies higher these days.

</comment><comment><USER42> >Take away manufacturing and you're left with...selfies

It's not true. Take for example Jersey, Luxembourg and the like. In those places there is insignificant manufacturing and the main business is banking. That's the whole thing about trade - one place can do one thing and one can do another.

<comment><USER43> Yes, let's even look at London. Stupidly reliant on banking, billions defrauded via Libor fixing etc.

What happens when there's a "credit crunch"[1]? Quantitative Easing! [2]

The 50-60% of the economy not in banking, and not needing a loan at the moment, is _talked_ into a recession by the twits in the media.

The SaaS business in Manchester, Leeds or Newcastle didn't change, lose customers, or become more risky, but the banks won't lend because the whole banking sector became suspect, so they just lost their cashflow.

Perhaps the problem is that the entire country wasn't working for the dishonest banks[3]? Presumably watching Wall Street and Liar's Poker every morning with the cornflakes?

Yet the first thing retrenched in a recession is optional services - <USER3> loans, insurance. It's no longer possible to trade our way out of recessions like the UK, and much of the world, did postwar ("export or die"). We solved a postwar recession of far higher percentage of GDP via creation and trade.

George Osborne has reduced the rate of increase of the debt a bit.

We're left with the ineffectiveness, and downright fraudulence, of quantitative easing and austerity.

If you're old enough to remember the 80s, you'll remember that was no better. With the added fun of 15% mortgage rates.

No thanks. More metal bashing please. More encouragement of _every_ sector that isn't in the square mile. A diverse, resilient, economy.

[1] I love this euphemism (/s). The biggest fraud in human history and the media calls it the credit crunch.

[2] Print money to give to the banks, to encourage them to lend, that they use to pad their bottom line. Repeat numerous times, _as though it is effective._ Toughen up capital requirements to further encourage use on the bank rather than advertised purpose. Sending cheques to each voter GW Bush style would be more effective getting money into the business economy.

[3] Unlike retail, pharmaceutical, industrial and a dozen other sectors banking regulation was abolished wholesale.

<comment><USER44> Clearly you're angry, but the post you're replying to has a point. There is a tendency for countries to shed manufacturing and move into other sectors, and it's often a sign of success rather than decline.

When there's a major economic event, all of the other competing philosophies zoom out of the desert seeking followers like Small Gods. The risk is that if you get driven by your anger rather than your mind, you'll find yourself in the arms of a new bizareness, rather than something better.

<comment><USER43> Not angry in the least. Just very cynical of suggestions banking is better than more industrial sectors. Besides it's not like Detroit or Sheffield could reinvent themselves as a banking centre without extreme subsidies to encourage mass relocations. Money neither has.

Even for ROI you'd have to go back a very long way to do worse than RBS, and will probably be sitting on that loss for another decade or more.

Banking does have several advantages - get big enough and the taxpayer will bail you out. So the downside becomes an externality. That is not good for encouraging ethics. Also through the miracle of fiat money and fractional reserve banking you get to print your own!

You have to wonder therefore how they manage to make such a bloody mess of it so often. Oh of course - greed and total lack of adequate regulation.

</comment></comment></comment></comment><comment><USER45> This inference of "making implies jobs therefore make things" is just short sighted. Is making things really the _only_ option of making providing jobs?! It's not realistic when there's nothing more we need to make and consume!

</comment><comment><USER46> Great article, terrible site design. Seriously, who limits their content to a single 300px wide column when there are 3 other columns with only links to other parts of the site?

</comment><comment><USER47> noteworthy that the author is Vaclav Smil: [http://www.wired.com/2013/11/vaclav-smil- wired/](http://www.wired.com/2013/11/vaclav-smil-wired/)

</comment><comment><USER48> but, but how about intellectual property ?!? I thought patenting the round corners is the future ..</comment>


The Death and Life of the 13-Month Calendar - <AUTHOR> http://www.citylab.com/work/2014/12/the-world-almost-had-a-13-month-calendar/383610/ <comment><USER2> "The International Fixed calendar sucked the personality out of marking time, making every week and month as predictable as humanly possible. [...] It's an impossible feat that doesn't need pulling off and, thankfully, no one is trying to anymore."

Spoken like someone who's never had to write date handling logic. Having "personality" in your calendar system is a bug, not a feature. I feel confident that we could maintain our overall levels of personality/joie de vivre/je ne sais quoi by spending less time dealing with an incredibly arbitrary calendar system and more time doing things we actually enjoy.

<comment><USER3> A very small percentage of the population ever has to write date handling logic. For the rest, things "just work", thanks to those few.

Besides, even as a member of that small group, I like the variety of the current calendar, inefficient as it is.

<comment><USER4> One has to admit that it complicates even trivial communications about days and times. Even questions like "What's the date of friday next week?" can't be quickly answered. Or "Is Nov 12th on the weekend?" I feel these are practical things that _most_ people would _like_ to easily reason about, but can't.

It imperial units for days; or like trying to do math in a numerical system where each significant digit has a different random radix. Does it have variety? Yes... Is even remotely fun to do anything practical with? No.

<comment><USER5> _Even questions like "What's the date of friday next week?" can't be quickly answered._

Fortunately we don't have a very pressing need to answer these sorts of questions; we have tools galore to handle them for us: smartphones, calendars, messaging apps, meetup etc. Topics like these often remind me of one of Einstein's more famous quotes:

 _[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think._

We used to spend an enormous amount of time teaching our children mathematical tricks which have now all been made completely obsolete by the scientific calculator. Only the most rudimentary of arithmetical strategies have survived, if only for the fact that it's still a little inconvenient to reach into your pocket when scanning and counting objects with your eyes.

<comment><USER6> I disagree, many times people are trying to coordinate and one person says the 8th thinking it's a friday, but it's actually thursday. So some people think they were talking about the 8th, others talk about it like it were the 9th, and there's confusion all about.

Casual calendar coordination is really easy to mess up in the current state.

</comment></comment></comment></comment></comment><comment><USER7> This. I have been thinking about this for a long time. Basically, 364 days are exactly the same, and what is currently December 31st would become the Year Day where everyone has it off. If it's a leap year, there'd be two Year Days. Simple, efficient, and easy to understand.

Birthdays being on the same day of the week is a poor objection: your birthday already falls on a weekday much more often then not, and chances are you celebrate it on the weekend before or after. We'd lose variability in holidays that are "last Thursday of the month": they'd just be on a specific date every year.

One nice thing we'd gain is that the phase of the moon would shift much slower with respect to our calendar (the moon doesn't do a Year Day). I suppose some superstitious healthcare workers might object to this. If you think about it, there are many more things naturally tied to 28 days than 28/30/31.

<comment><USER8> Actually the synodic month is closer to 365/12 days than to 28 days, so the 13-month calendar drifts slightly faster with respect to phases of the moon.

</comment></comment><comment><USER9> Fun fact:

The arabic calendar which is based on Moon movements used to have an extra month every four(?) years to adjust the season changes. It was called Nasi' month. But after a Quran Sura published that prohibited this month Arabic calendar lost it's accuracy for seasons.[1]

The Iranian Calendar that is based on sun movements was safe from this Sura because it didn't have an extra month but an extra day each five years.[2]

[1] [http://en.wikipedia.org/wiki/Nasi%27](http://en.wikipedia.org/wiki/Nasi%27)

[2] [http://en.wikipedia.org/wiki/Iranian_calendars](http://en.wikipedia.org/wiki/Iranian_calendars)

<comment><USER10> The Hebrew calendar (also lunar) still does this - a leap month in (IIRC) 7 out of every 19 years.

</comment></comment><comment><USER11> Eviatar Zerubavel's _Seven Day Circle_ is a detailed and complex history of time telling.

It really helps to understand that in a calendar we're trying to measure three distinct (and variable) cycles, none of which fits precisely into the others, and each of which imposes its own rhythms on human life. Attempts to break each from the current 7/12/365 basis have virtually all failed.

The first is the Earth's rotation about its own axis -- different when measured with respect to the stars or the Sun.

The second is that of the Moon about Earth.

The third is of the Earth about the Sun.

We overlay them on each other and pick rough correspondences.

Much of the division has to do with Babylonian time reckoning, based on 360, and its factors: 2 * 2 * 2 * 3 * 3 * 5. From that you find 2, 4, 5, 6, 8, 9, 10, 12, 15, 18, 20, 24, 30, 45, 72, 90, 180, and 360. A seven-day week doesn't fit this directly but is close (between 6 and 8), and a 30-day month also fits well.

Then you come to realize that all timekeeping, _especially_ that which picks a specific starting point, is arbitrary.

The book also details several attempts to change the system, particularly following the French and Russian revolutions (oh, and the reason for that being the October revolution -- and there's the question of what was the last nation to adopt the Gregorian calendar, and why the output of 'cal 1752' is what it is ... and why even _that_ is arbitrary (it depends on where you're specifying the date).

[http://www.powells.com/biblio/61-9780226981659-2](http://www.powells.com/biblio/61-9780226981659-2)

<comment><USER12> It's not clear that the rotation of the moon has much significance in modern life any more, so maybe the problem can be simplified.

What was the significance of cycles of the moon in the past, anyway? The main thing I can think of is astrology. Can tides be predicted accurately using phases of the moon?

<comment><USER13> Month = "Moonth"

Aside from the female menstrual cycle, the gestational cycle is also in line with the moon: A baby is brought to term in 10 moons or 280 days (9 months or so).

You would also have an easy way for disparate peoples to mark time, since in the past there was no such thing as telegraphs or even pony express.

<comment><USER14> That's only because we have a weird method for calculating pregnancies, for historical reasons.

A human pregnancy is around 266 days +- 16. The reason for 280 days or 9 months is because that measures the time span since the last menstruation, not since conception.

(I was personally a bit surprised by this when expecting our first child. It's one of those things you apparently know about but still use "9 months" as a bit of a fixed expression.)

</comment></comment></comment></comment><comment><USER15> This seems to be slightly inferior to the Pax calendar[1].

The Pax calendar has another very cool property, which is that the weekdays are always in sync with Gregorian calendar. This is done by carrying over leapdays until you have one full week accumulated, which is then inserted as a leapweek, in the same way we insert leapdays in the Gregorian calendar.

[1] [http://en.wikipedia.org/wiki/Pax_Calendar](http://en.wikipedia.org/wiki/Pax_Calendar)

</comment><comment><USER16> Also in alternate calendars:

 _Each day in the Republican Calendar was divided into ten hours, each hour into 100 decimal minutes, and each decimal minute into 100 decimal seconds. Thus an hour was 144 conventional minutes (more than twice as long as a conventional hour), a minute was 86.4 conventional seconds (44% longer than a conventional minute), and a second was 0.864 conventional seconds (13.6% shorter than a conventional second)._

[http://en.wikipedia.org/wiki/French_Republican_Calendar](http://en.wikipedia.org/wiki/French_Republican_Calendar)

</comment><comment><USER17> When I was at Intel they marked everything in Work Weeks, that was essential for scheduling things like chip fabrication plants. It took a little while to get used to but then it made computing questions of 'when' quite straight forward.

I'm personally in favor of a more structured system like this, my wife on the other hand is viscerally opposed. If that schism is widespread I expect the next calender change to occur when the known world is ruled by an emperor :-)

</comment><comment><USER18> "We've always done it this way" are the seven most expensive words in business. Catherine DeVrye (2000)

</comment><comment><USER19> In addition to the 13 month calendar, I wish the year started in March or April. The beginning of Spring* makes more sense for a new year than the middle of winter.

*I realize this is only true in the northern hemisphere, but 90% of the world's population lives in the Northern Hemisphere. The other 10% can start their year in the Fall.

<comment><USER20> This is how the calendar originally worked (DECemeber is 10th month), until politics intervened in ancient Rome.

<comment><USER21> The Julian calendar typically started the year on the 25th of March (Lady Day) at noon (prior to clocks it was much easier to reckon mid-day than mid- night... navies kept this practice at least into the 1800's). This was true into the 1600's in parts of Europe and North America.

</comment></comment></comment><comment><USER22> Reading this article is my first exposure to this 13-month calendar [I don't count the Simpson's episode]. I'm glad for the read and found it very interesting.

</comment><comment><USER23> This is a little bit different from the accounting 13 month calendar -- an "Adjustment" month that usually falls in the next FY that the accounting/auditors can do adjustments and still have 'true' dates on everything.

Honestly, having another month to pay bills (and you know that nobody's going to pro-rate everything down to 13 months) isn't really appealing right now, nor would the additional overhead of two more payroll cycles.

Logically, it makes sense, though.

<comment><USER24> For what it's worth, I'm already paid for 26 pay cycles each year, and I work at a company of 30k+.

</comment></comment><comment><USER25> This would complicate anything that is paid for monthly, including but not limited to: employee salaries, rent/mortgage, subscriptions, utilities, etc. Do we just ignore Sol for those purposes or roll it into another month?

Having your birthday perpetually on a wednesday would also not be so much fun. Perhaps "year day" could shift every year forward by 1 week day - year day could be Monday and then Jan 1 of the next year could be a Tuesday etc.

<comment><USER26> Don't some companies already run salary in thirteen four week periods? I've worked at at least one that did.

<comment><USER27> I'm not 100% sure, but in the US, this is relatively rare, as it's required in most situations to be paid at least 2 times per month.

I think all but 5 states have laws dictating pay frequency, and in most cases they require at least two times a month pay frequency.

The most popular pay schedules tend to be 24, 26, and 52 times per year.

EDIT: This was supposed to be a reply to redblacktree. State law examples: \- [http://www.dir.ca.gov/dlse/faq_paydays.htm](http://www.dir.ca.gov/dlse/faq_paydays.htm) \- [http://labor.ny.gov/legal/counsel/pdf/frequency-of-pay- frequ...](http://labor.ny.gov/legal/counsel/pdf/frequency-of-pay-frequently- asked-questions.pdf)

<comment><USER28> I would like you to explain to me what the situation is in which you imagine that being paid every 2 weeks would result in you being paid less than twice a month.

</comment></comment></comment></comment><comment><USER29> Using the same calender every year might work fine in America and some of the Western European countries. (According to the article, Easter and Thanksgiving can be given fixed dates in the 13-month calendar.) But many non-Western cultures have holidays tied to phases of the moon. Chinese New Year would still move around a lot from year to year, making it impossible to reuse last year's calendar. Ditto for _Chuseok_ in Korea, which needs to coincide with a full moon.

So yeah, this looks like a nice change, but it's not going to be completely static from year to year in every culture.

Besides, I don't think it will completely eliminate the difficulty of figuring out what date "next Thursday" is. We at HN tend to be mathematically competent, so we can easily calculate multiples of 7 in our heads and subtract a few without breaking a sweat. Most ordinary people, on the other hand, have difficulty figuring out what date next Monday is even when it's Friday and you just need to add 3. They'll just look it up in a paper calendar or their mobile device.

</comment><comment><USER30> Okay, but can we come up with a calendar system where the months September, October, November, and December don't have the wrong names? It has always bothered me that the prefix sept- means seven, but it is the ninth month, oct- is for the tenth month, etc...

<comment><USER31> Have a 14-month year, then start the following year in March.

<comment><USER30> Sold. This could have the added benefit that every leap year we can get two days off for new years eve, since people will be used to getting Feb 28th off anyway ;)

</comment></comment></comment><comment><USER32> There's also the ill-fated Soviet Revolutionary Calendar

[http://en.wikipedia.org/wiki/Soviet_calendar](http://en.wikipedia.org/wiki/Soviet_calendar)

<comment><USER33> And the similarly fated French Republican Calendar: [http://en.wikipedia.org/wiki/French_Republican_Calendar](http://en.wikipedia.org/wiki/French_Republican_Calendar)

</comment></comment><comment><USER34> Somewhat related: the other day (this week even!) my wife was puzzled by the names of months and she asked me about the meaning of each. If you think about it for a moment you'll figure most of them out, but in any case this is a good summary: [http://www.design.caltech.edu/erik/Misc/month_names.html](http://www.design.caltech.edu/erik/Misc/month_names.html)

</comment><comment><USER35> It's brilliant, I love it! That said, I'd be happy just to see the Daylight Saving time-switch left on the dustbin of history.

</comment><comment><USER36> From the article:

> Easter would fall on April 15 every year on Cotsworth's calendar

I don't understand why this would be. Can someone explain?

<comment><USER37> Easter is tied to the days of the week, it's always on a Sunday. So it's going to be week-aligned.

This calendar aligns months with weeks. Months are always exactly 4 weeks.

<comment><USER36> But Easter moves around quite a bit during the year, sometimes being on the 83rd day of the year (in 2008), sometimes on the 110th day of the year (2014), and various dates between. I don't see how changing to a 13 month calendar would affect the first full moon after the spring Equinox, since the lunar cycle doesn't mesh with the solar one.

<comment><USER37> > I don't see how changing to a 13 month calendar would affect the first full > moon after the spring Equinox, since the lunar cycle doesn't mesh with the > solar one.

Just checked... you seem to be correct. The lunar calendar isn't aligned with this well enough. While the equinox date is fixed, the first full moon after that should bounce around by several days at least. Even allowing that it's always the Sunday after that, it still seems as if it could fluctuate by a week in either direction.

</comment></comment></comment></comment><comment><USER38> I love the idea of a 13 months calendar; however, you're birthday would be on the same day every year :0/.

<comment><USER39> Unless you were born Feb 29, I guess everyone's birthday is on the same day every year. Mine, for instance, is always on Sep 11, every single year.

<comment><USER40> You're confusing day (Monday, ...) with date (12th Dec).

<comment><USER41> He's pointing out that those stuck on a leap day are still stuck.

If you count by day-of-year when doing the conversion, though, it's the people born new year's eve on a leap year that are impacted.

</comment></comment></comment></comment><comment><USER42> Why do we even have a 7-day week?

7 and 28 are just as arbitrary as 12.

Why do we even have a solar year?

If the year was 100 days, we could have a whole year of summer.

<comment><USER43> You're not going to convince either the Christians or the Jews to do a week that isn't 7 days long. That number is more or less fixed by the sizeable minority who need it for the rest of their habits.

The solar year is convenient so that one can speak of "the average historical weather for this month" and such... but it's true that many others have done lunar calendars etc.

<comment><USER42> Muslims use the lunar calendar for religious occasions (Ramada, Hajj, Eid) but use the Christian, solar calendar (like the rest of the world) for everyday life.

</comment></comment></comment><comment><USER44> I really like this idea - it makes scheduling things a whole lot easier. I also like the concepts of the one week month and "year day" \- for some reason I feel like I'd get more pumped about year day than I'll ever get about new years.

<comment><USER36> I didn't see anything about a one-week month on there, but the diagrams sure make it look that way.

</comment></comment><comment><USER45> I wonder what Jews, Seventh Day Adventists, and Sabbatarians in general would think of this.

</comment><comment><USER46> Lousy Smarch weather.

</comment><comment><USER47> This makes more sense than switching to the metric system.

<comment><USER48> Why? I'm curious.

</comment></comment><comment><USER49> Mars Inc. uses 13-period calendar for everything.

<comment><USER50> When I worked for Royal Ahold they used a 13 period calendar. The date logic was much worse to manage because you still had the rest of the world and every programming language and database that used the Gregorian calendar.

We had a single mainframe subprogram that managed the whole thing. It was written in assembler and the few times it broke, the entire company stopped. Financials, ordering, invoicing, everything. Eventually they rewrote it in a more modern language, COBOL. This was in 2010.

</comment></comment><comment><USER51> My birthday would always be on a Sunday!

<comment><USER52> Also for the superstitious there would always be Friday the 13th

<comment><USER53> Easy fix, just start the month on a Monday instead of a Sunday

<comment><USER31> Starting the week on Monday seems more common than Sunday for most countries, I believe France does. And China and Japan name their days literally "Day 1" for Monday, ... "Day 6" for Saturday, and "Day Sun" for Sunday.

<comment><USER54> This is wrong. Saturday in Japanese is 土曜日, which is like "Earth day".

There's also "Sun day"(Sunday), "Moon day"(Monday), "Fire day"(Tuesday), "Water day"(Wednesday), "Tree day"(Thursday), "Gold day"(Friday), "Earth day"(Saturday). So your claim is wrong in Japanese for every day except Sunday.

If you see something written like 四日("4 day"), this refers to the day of the month not the day of the week(for Japanese).

<comment><USER31> Chinese uses the numbers for days of the week, so 星期一,星期二,星期三,星期四,星期五,星期六,星期日 for Monday to Sunday. They can use 周 or 礼拜 instead of 星期.

I remembered Japanese copied the Chinese at something there, but, whoops, it was the names of the planets that were copied. So the Chinese names of Mars(火星), Mercury(水星), Jupiter(木星), Venus(金星), and Saturn(土星) are copied onto the same days as planets that Romance languages name their days after.

<comment><USER55> FYI, 日 is not "seven". It's "sun" or "day". It's almost like someone had a sense of humor when they named that day.

My interpretation has always been that 日 is meant to represent "zero", but I never put any thought into why they didn't just call it 星期零.

<comment><USER31> "星期日" is generally written Chinese, but in speech Chinese say "星期天" where 天 could mean "God" when the 7-day week was copied from "Christian" Europe. I just found [http://www.cjvlang.com/Dow/dowchin.html](http://www.cjvlang.com/Dow/dowchin.html) to explain the history of Chinese and Japanese day names in detail.

I've noticed while living in China that, whereas Westerners like me virtually always remember what day of week it is but often forget the date in the month, Chinese are more likely to remember the day of the month and forget the day of the week.

<comment><USER55> Ah. I grew up in a Cantonese-speaking Christian family in America, so I've never heard 星期天 used in speech at all.

Confusingly, the "seven luminaries" system in that article aren't just referencing the planets: they're also the names of Sun, Moon, Fire, Water, Wood, Metal, and Earth. I did get that sorted out by looking up Western alchemical ordering for the planets, which is in the same order. Wikipedia helpfully provides a table that includes the _old_ names for the planets as well:

[http://en.wikipedia.org/wiki/Classical_planet#East_Asia](http://en.wikipedia.org/wiki/Classical_planet#East_Asia)</comment></comment></comment></comment></comment></comment></comment></comment></comment>


True value of a PhD - <AUTHOR> https://hackernoon.com/the-true-value-of-a-phd-94885fdcdaf4 <comment><USER2> Seems they might not have learned as much as they think.

Hyperbolic self-congratulatory nonsense. Numerous logical fallacies presented throughout.</comment>


Spark Labs Raises $4.9M to Help Engineers Make Their Devices Smart - <AUTHOR> http://blogs.wsj.com/venturecapital/2014/07/08/spark-io-raises-4-9-million-to-help-engineers-make-their-devices-smart/

<comment><USER2> Congrats to the Spark team. Sad to see the Twin Cities lose another IoT startup, but I hope this positions them in the best possible way for success. Welcome to San Francisco!

<comment><USER3> A lot of us are staying in the Twin Cities, and we're hiring! ([https://www.spark.io/jobs](https://www.spark.io/jobs)), we're looking for great engineers, and we support remote work as well. :)

</comment></comment><comment><USER4> Well deserved. Their chip is practically the only chip that works and can be easily integrated into arduino boards.

<comment><USER5> They don't make a chip. They use a CC3000 from TI -- which costs about $10 -- and provide a thing wrapper around TI's own provided driver.

You can take the same CC3000 from TI -- around $11 in low volume -- put it on your board and write your software with their driver.

They basically make a good dev board but for anyone wanting to make anything in a volume beyond 1K they'd use the TI module directly. You don't put a dev board in an end product.

I fail to see how their business is going to scale beyond this.

<comment><USER6> They recognize that it's more for prototyping and wouldn't be used at a production level:

"We use industry-standard components — chosen to be powerful, inexpensive, and widely available — that can be designed directly onto your own circuit board, bringing your Bill of Materials down for volume production."

<comment><USER5> Right, I agree. That is what I gathered before but the article and their new splash page makes it seem like they want to supply this to large device makers (i.e. anyone not building things out of their basement) and I don't see how this could work.

They can't make money on the hardware, because TI makes the chip and provides the reference design and drivers for free. Spark boards are all OSHW anyways. You'd spend the extra week and integrate the TI part into your device anyways.

Their cloud stack is open source, and is basically a transport. As the device maker you'd still have to write the cloud app that gathers data from different points and sends commands to the end unit.

Beyond the dev kits I'm having a hard time seeing the revenue stream and/or value proposition.

What am I missing? Maybe guys from Spark want to chime in?

If I use Spark to prototype, is there a product they are offering me that I would need to pay for at scale?

<comment><USER3> Hi bravo22,

      I'm from Spark, and I can try to answer! :)

With more than 20,000 units in the field, the Spark community is the largest consumer of the CC3000 module, so you get the benefits of driver testing and patches, and great community support. Large businesses could certainly use the open source modules and run with them, but if you're a large business you generally want to pay for support and licensing. Next for us is building a suite of fleet management tools and controls that larger companies want that also benefit hobbyists.

If you're a business or a maker, using the Spark Cloud saves you from having to worry about building your own protocol, dealing with socket programming, spinning up servers, as well as worrying about encryption on microcontrollers, or wearing a pager. Having the source code available means you can keep your private things private by not going over the internet, as well as building things we haven't thought of yet.

Thanks!

David

<comment><USER5> Thank David. Thanks so much for answering!

Couple of questions: \- Are you always sticking w/ CC3000 or are there other WiFi modules you intend to support?

My main question, might have gone unnoticed in my long post... Is there a service of yours that I need to pay for to get these features, or do I get the benefits you outlined above by running your firmware and deploying your open source cloud code on my system?

Do you have plans to go closed source in the future?

<comment><USER7> Zach here, also from Spark. We're definitely working on next-gen hardware now, haven't selected a final chipset yet.

Our hosted cloud is somewhat different from the open source version, and the differences will grow over time. As an open source company, the question always comes to "how do we make money?" Our open source thesis is to give away basic technology and sell advanced technology. Right now the biggest differences between our hosted cloud and the open source version is scalability; our system is designed to scale horizontally whereas the open source one is a single instance (although it could, of course, be modified). We are still deciding which features that are still in development will be open sourced, and which won't. We've learned from other for-profit open source companies (like MongoDB, for instance), that even after being on the market for years they're still trying to figure out which features to give away and which to sell.

<comment><USER5> Thanks for answering Zach! Your answer certainly helps make it more clear.

To use your feature rich cloud, would one have to use your spark core board or one can roll own CC3000 based board + your open source firmware but pay you and have it talk to your closed cloud for scale? When is your plan to announce pricing for this feature rich cloud?

<comment><USER8> You've got it- you can build your own board using our reference design and pay us a minor fee to use our lovely cloud. Pricing isn't public yet, but we can discuss it privately if you have a need. Thanks!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Sounds a lot like [http://electricimp.com](http://electricimp.com)

<comment><USER10> It's more expensive than imp but has a smoother wifi pairing process.

<comment><USER8> And a lot cheaper than Imp at scale- <$15 per device in hardware at scale.

</comment></comment></comment><comment><USER11> Do these guys have any patents on their tech?

<comment><USER5> Their product is open source: board design, firmware, and cloud software. The WiFi module is CC3000 from TI.

<comment><USER11> my next project is going to be in this area and you seem like a good person to know. get in touch with me if you want. email address in my profile.

<comment><USER3> We have a really awesome community that can help too! - [https://community.spark.io/](https://community.spark.io/)

</comment></comment></comment></comment><comment><USER12> Can we stop naming things Spark already? There are

\- these guys

\- [http://www.sparkjava.com](http://www.sparkjava.com)

\- [http://spark.apache.org](http://spark.apache.org)

Even worse, they're all high-quality projects. I can process data from my Spark devices on my Spark cluster and serve the results via Spark.

<comment><USER13> Even more so in this area with [http://SparkFun.com/](http://SparkFun.com/) who had to deal with issues arising from having a name with "spark" in it: [https://www.sparkfun.com/news/300](https://www.sparkfun.com/news/300)</comment></comment>


Did they know what they were making?- FB/Linkedin/Twitter/Ebay - <AUTHOR> http://andrewchen.co/2013/05/13/linkedin-facebook-google-twitter-ebay-youtube-wikipedia-amazon-hotmail-blogger-apple-how-they-used-to-look/#

<comment><USER2> read parts of these in the past. But it is always great to see them. Atleast works as a moral booster for me :P</comment>


iCloud cost pegged at $25 per year, all 4 major labels signed - <AUTHOR> http://arstechnica.com/apple/news/2011/06/icloud-rumored-to-cost-25-per-year-all-four-major-labels-signed.ars

<comment><USER3> I'm betting this "just" buys you the ability to sync all your music (and pretty much everything else that can go on your iphone) to every device you have over the air.

I'm already spending that 30 bucks on Pandora One and I'm not sure the added burden of having to maintain and manage a music library is something I'm up for anymore. I'd rather just stream some semi-random music in the background and go see some good live shows.

<comment><USER4> I'm in the same boat. I'm very happy with the unlimited streaming model of rd.io (and Netflix) and not very interested in a service that makes it slightly more convenient for me to move big media files around and pay $9 a pop to "own" a digital copy of an album.

</comment></comment><comment><USER5> $25 a year is certainly in the ballpark of acceptable yearly subscription fee, but i'm not convinced about the actual product here..

i don't think i'd see a use from it, in the same way mobile me hasn't been of much interest.. but then again, i could say the same about a lot of apple products, and they're fairly successful.

then again, i don't think i am (or most of HN demographic are) the target here.

<comment><USER6> If the service is indeed $25 a year, and lets you listen to unlimited amounts of music, than this is a gamebreaker and would stop music piracy in its tracks.

Think about it - this used to be the cost of a single CD! Netflix, by comparison, charges $108/year for its offering.

More details about what the $25/year gets you is needed before one can make a definitive judgement.

<comment><USER7> I think the $25 per year is for access to the cloud service. You'll still have to buy your tracks.

<comment><USER8> On the surface $25/year seems too low to cover a music subscription service but there are about 140 million iOS devices out there and probably 50 million Macs? If 50% of them were to signup for iCloud and pay $25/year with 70% going to the labels/publishers they would make about $1.7 billion dollars. The entire digital music market was $2.2B in 2010. It's definitely in the ballpark to replace existing iTunes music sales. Apple may have sold the labels/publishers on the idea that a low cost service that gives people what they really want, unlimited access to endless amounts of music, is viable if it's priced low enough. It would probably turn a lot of career pirates into paying customers.

<comment><USER9> You're probably mostly double counting, unless that's $25/year/device - <USER2> users generally have iOS devices and may well have multiple iOS gadgets accumulated over the years. (There are a lot of iPhone users who don't use a mac, but not the other way around.)

</comment></comment></comment></comment></comment><comment><USER10> I'm not exactly sure I'd feel comfortable funneling a chunk of that $25 a year to record labels for the right to store my music in the cloud... Also, I stopped maintaining my own "library" of music months ago and have resorted to basically YouTube + unlimited subscription music service.

Concept of "library" should be dead.

</comment><comment><USER11> Is this $25 per year to stream music I already own to myself?

<comment><USER12> We don't know but it's probable (and also in line with what one would pay for Amazon's service†, depending on how much music you can upload).

†You can get up to 20GB for free from Amazon but I think we all know that Apple doesn't do free. I expect a much more generous limit for those $25 and maybe a trial period but no free service.

</comment></comment><comment><USER13> What the hell exactly costs $25/year. I've been hearing that number for some time, but no one seems to indicate what it's for.

I'm paying $25 a year for an online drive? That's unlimited? I'm impressed if so.

<comment><USER12> One plausible scenario is that you have to upload all your non-iTMS while your iTMS music can be streamed right from the start. Well, that's at least the minimal required scenario to make this service attractive when compared to Google's and Amazon's services. Apple gets extra points if you can immediately stream all the music in your library – no matter its source – if it is also available in the iTMS. (That would, by the way, also save them space and bandwidth and make it possible for them to be pretty competitive.)

My guess is that it's either unlimited or has a pretty high limit. Google's service is currently capped at 20,000 songs†, Amazon's free service has space merely for a few thousand songs (5GB or 20GB if you purchase an album from Amazon MP3).

Paying $30/year (after buying an album and getting the 20GB bump) gets you altogether 50GB of Amazon Cloud Drive space. That would be my minimum expectation for Apple's service, too. (I would still be disappointed. 50GB still fit my current music library – but for how long?) A 20,000 song limit (that's about 160GB assuming 3:30 long 256kBit/s AAC files∆) would be more reasonable and at least be much cheaper than Amazon's service (if you go with Amazon, 100GB cost you $80, 200GB cost you $180).

It's also possible that those $25 include some or all services that are currently part of MobileMe (iDisk, email, calendar and other syncing, …).

†It's currently free and requires an invitation but might be no more after it is out of beta. Comparisons with Google Music are at this point in time moot.

∆Apple wouldn't actually need all that space and the associated bandwidth. First of all, not all people have 160GB music collections. Also, all music bought from the iTMS (and maybe all music available on the iTMS depending how the service will work in the end) doesn't have to be uploaded and only one copy of it has to be saved. I have 20GB of music bought in the iTMS and 20GB of ripped music, I would only need 20GB of space.

<comment><USER14> It's worth bearing in mind that Amazon's service has unlimited storage for music you purchase from Amazon. Purchases there don't count against your space allowance.

So for new music purchases Amazon is pretty tempting to me even if I intend to move the files to one of the other services at some point. Lifetime re- downloading is a nice perk.

<comment><USER12> Ah, ok, that's good to know. If that's the case than I would be disappointed about anything below 50GB for my non-iTMS music and would very much expect no limit on iTMS music and maybe a 20,000 or so limit for non-iTMS music.</comment></comment></comment></comment>