If you were correct in your analogy we would not have our current stagnation. At present, Compete.net decides to spend $10 million on lawyers and lobbyists to throw legal obstacles in front of potential adversaries to keep their effective regional monopoly and puts the other $55 million or $70 million it might have spent on network upgrades into profits, and lets their infrastructure continue to suck.

We still need a mixed public/private solution - regulation to keep the playing field open, and then competition on that open playing field. Pure private and pure public both lead to stagnation (even if the pure private solution stagnation is actually accomplished by having the private companies influencing public policy).

The article says "independent of activity level, sleep, and eating habits", so even people who eat and sleep the same amount and went jogging later in the afternoon were heavier.

But I think the study size is too small and the duration too short to mean anything.

You won't see it implemented in free services for the reasons you describe. But it could work as a pay service. Most people will skip that in favor of free services that scrape their data, but some might.

I'm tempted to rent a server from Amazon or DigitalOcean or whoever and put the application on it myself, so I can access my data from anywhere without dealing with advertisements and privacy concerns.

He had nine days to invent the language. I doubt there are more than a handful of computer scientists in the world that could invent a good language that fast.

And the reason C++ became so popular is the migration path from pure C code and the migration path for pure C developers. The reason Java became so popular is marketing and the syntactical similarities with C and C++. Javascript piggybacked on that, and now it's everywhere. We will never be rid of it, your dream of a superior replacement will never take off because there's no practical migration path from Javascript to wherever it is you want the world to go.

I'm sorry if my post was a little confusing - I don't consider ZFS experimental either. I meant that ZFS is a commonly used Unix filesystem that has more features than ext4, and it can't be part of the Linux kernel. btrfs is an attempt to bring ZFS to Linux without violating any software licenses.

I didn't know about LVM snapshots, thanks for informing me. I also didn't realize LVM supports adding and removing storage devices to the volume while the system is live. I considered snapshots and growth and shrinking of storage the two killer btrfs features, and now I see that one can get those from LVM + ext4.

Okay, I find the argument for adapting btrfs as a primary filesystem weaker. I hope there's something I'm missing.

Very cool, thanks for letting me know about that.

Someone upthread made the comment that 300 dpi is the limit of human vision for detail [i]assuming the print is 24 inches or further away in a magazine or newspaper or screen[/i]. I think that explains the other person's confusion.

I bought one of those comically large phones for exactly this reason. I want to be able to read it at arm's length, and I can. I figured if I had a smaller screen and spent too much time hunched over squinting at the thing, I would end up squatting in a corner somewhere muttering that some tricksy person stole the precious.

I believe you, though I have no formal knowledge about this. To me the other specs are more interesting - cross-provider LTE, potentially the new standard bearer for best Android smartphone camera, first Android phone (to my knowledge) with 3GB of RAM.

On the other hand, even with 300 dpi that puts the requirements for a screen pretty high, right? I mean the mainstream flagship Android phones these days have a 4.7 inch screen on bigger. If that's 2.5 inches horizontal and 4.0 inches vertical then 300 dpi requires just under 1280x800. For a screen with a 5.5 inch display to pass the 300 dpi threshold you need something between 1280x800 and 1920x1080. I'm not aware of many screens with non-standard display resolutions between those two points. So this 2560 by whatever may be marketing overkill for a phone this big, but full 1080p for phones with screens 5 inches or larger might actually make sense (?)

The ZFS filesystem from Solaris Unix has some features that ext4 does not, especially filesystem snapshots. That gives you the ability to take a filesystem snapshot at a certain date, and if the system has a filesystem problem in the future that is not from a hardware failure, you can instantly revert your filesystem to the snapshot. Here's a common use case: you take a snapshot, then apply a software upgrade to your system. If the upgrade goes well, you snapshot again. If the upgrade fails, you revert to the original snapshot and the system acts as if the failed upgrade never happened.

This is one of the reasons so many big companies use Solaris Unix. Unfortunately, the software license of ZFS prevents it from being incorporated into the Linux kernel by default. You have to download and install it separately.

Adding that feature to ext4 without completely rewriting it is impossible. That's why btrfs was created, to give many of the good features of ZFS to Linux. The thing is, btrfs needs to be battle-tested before businesses will use it on mission critical servers. You have to start somewhere. Maybe OpenSUSE 13.2 is too soon, maybe it needs another few years as alpha software. But maybe all of the people on this forum complaining about file corruption ran into bugs that have already been patched.

I can't speak to its reliability because I only used it a little bit. But in terms of features, from what I understand it the two killer features that slow btrfs down by make it so attractive (assuming it doesn't corrupt your files) are snapshots and live volume resizing. Those two things do what you might from the name - snapshots let you tag a certain point in time in the filesystem, and in the future you can revert your filesystem to look exactly as it did at that point in time. That is of course incredibly handy in the case of failed upgrades or accidental file deletions. Live volume resizing lets you grow and shrink partitions and I believe even add an additional storage device to an existing btrfs volume while the system is still mounted.

I think the slowdown versus ext4 is measurable but not killer, 5-10%. I'm more concerned with the stability.

I had not seen any assertion that Wayland would not work with Android GPU drivers. I don't understand the architecture of X, Wayland, and Mir. As I just wrote elsewhere, the only not-totally-vague explanation of technical differences between Wayland and Mir that I've seen is this: http://blog.cooperteam.net/201... If the author of that post is correct, then Mir has a resource management advantage over Wayland in resource-constrained environments. That doesn't matter if you're getting a $600 on-contract phone in the first world but it's a very big deal if Canonical is trying to enter the middle and low end first world market or any portion of the third world market with Ubuntu Touch.

But again, I don't know if the writer is correct about the details - and it's possible Wayland has some other effectively equivalent way of handling resources.

I don't understand enough of the technical differences between Mir and Wayland to make a real argument. The only technical post I read about Mir that wasn't too vague to be useful was this one: http://blog.cooperteam.net/201...

I'm not saying Wayland cannot work well on ARM devices, if the Raspberry Pi can run X than certainly a Nexus 5 can run Wayland. But if that post isn't full of nonsense, then properly configured Mir will work more efficiently than Wayland in an environment like that.

Most of the supercomputers in the world are built using Linux. Are you saying that Linux is used in those machines strictly because of commercial Unix licensing costs?

What makes the commercial Unix's better for heavy iron back use? (That's a genuine question, not a challenge.) I understand that earlier versions of the Linux kernel didn't do multi-threading in an efficient way - too much locking, and they lacked asynchronous IO and a few other similar technologies that made them inefficient for huge multi-threaded tasks. But my understand is that these days, it can keep up with just about anything for efficiency and stability.