"Snap an App" allows a phone-sized app to fit in a 20em-wide column of the screen on desktops, laptops, and 10" tablets. So why would it be so hard to allow the Start screen to start snapped on desktops, laptops, and landscape tablets? A snapped Start screen would at least be consistent with Windows Phone's Start screen.

I don't see how that can work in the present U.S. cellular market. Sure, Google gives 15 GB of storage, but if your cellular ISP doesn't let you upload or download more than a third of that per month, what's the use? The big reason I own a laptop is to get work done while riding the city bus, which lacks Wi-Fi.

Then the PC maker could install only Windows plus a package manager analogous to Mac App Store, Ubuntu Software Center, or Steam. Then when the user inserts a DVD-Video disc, the package manager could connect to the Internet and send the machine's serial number to the repository to present a list of "third-party crapware" that the machine's administrator is entitled to install. For a PC configured with an optical drive, this would include DVD player software. If the user knows he's going to play a DVD while away from the Internet, he could start the package manager and install it ahead of time. A copy of the qualified packages could even ship (uninstalled) on the hard drive, with an option in the package manager to purge them to reclaim the space.

That's an interesting idea, at least from the accessibility perspective. I've wondered for a while what'd be the most effective way for someone who can only push one button to control a mouse-driven application.

I think the point was that additionally requiring "appropriate Internet connectivity" limits the market for the product too much compared to requiring only electricity and a computer. The same is true of requiring a bleeding edge computer instead of the computer one is more likely to already own.

Yes. Comcast still has the 300 GB per month limit in many markets, and cellular has a cap two orders of magnitude smaller than even that.

For someone born in a country whose home Internet pricing expectation is stuck in the past, such as the United States, Canada, or especially Australia or New Zealand, it can be expensive and a pile of red tape to relocate to a country in the present.

A big citation needed there. The last time I looked at the data was in 1998, but back then English tax payers were paying an average of around £100 each for the upkeep of Scotland, if you didn't include the north sea gas revenues.

The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:

Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.

There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.

There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).

The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.

XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.

None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).

If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.

It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.

There's nothing intrinsically good about the UNIX mindset. For example, UNIX originally put globing in the shell as a work around for not having shared libraries and claimed it was a feature (which led to all sorts of problems - for example */*/* can overflow the command-line argument length limit, whereas a system that had put globing in a shared library would have lazily expanded it in the called program). The problem with the systemd developers is not that they lack the UNIX mindset, it's that they produce utter crap and somehow are able to market it successfully.

That particular use is quite uncommon, but it's increasingly common to stick a recovery root partition in flash (or even in a kernel-embedded RAM disk on a recovery USB drive or similar) so that if you screw up some core configuration you can boot the core system and recover everything else. Keeping it small and self-contained has several advantages. If it's being loaded to RAM on recovery boot, you don't want it to be large and you do want to be able to write the recovery images quickly. If it's in flash (or even a separate FS on the main storage pool) then you don't want it to be too big.

It matters less for big users, who will fix a machine by simply reimaging it and have redundant everything, but if's very useful for a small company that only has a few servers. It's also useful if you're building an appliance and want to be able to have two root partitions that you switch between for atomic updates (boot one, update the other, reboot on the other, always have one bootable root).

The only thing ARM ships that might speed up Dalvik is Thumb-2EE (a.k.a. Jazelle RCT), which neither Dalvik nor ART actually use. No idea what your /proc/cpuinfo is talking about.

Phenibut is more like Valium up to 11 than GHB yes. Have you ever had valium delivered as a continuous intravenous drip? You won't remember a damn thing, but you'll be awake and compliant. Mind you, that's a massive bioavailable dose compared to a pill.

Phenibut really is useless, though.

Now after having waited a couple days for this to cool down and for the offtopic police to move on: I agree that travel is necessary. I'm just unsure about the means. Will I need to buy a car to get a job?

I decided to fact check this claim. Eusociality, according to Wikipedia and the references it cites, is defined as three aspects of the behavior of a species:

• "cooperative brood care (including brood care of offspring from other individuals)": Daycare is a thing.
• "overlapping generations within a colony of adults": Grandparents are a thing.
• "a division of labor into reproductive and non-reproductive groups": Humankind appears to be moving in the direction of breeder vs. thinker classes. More affluent classes already tend to produce fewer children, and the public has become more accepting of a gay lifestyle. Furthermore, I've seen plenty of contempt for "breeders" and other childfree-by-choice advocacy on Slashdot.

I agree that humans are not as close to the eusocial ideal as bees and mole rats, but we're closer than a lot of other species.

I guess you'd stream a game for about three days to see if you like it, after which you'd buy your own copy. But wouldn't buying your own copy run up a 30 GB bandwidth bill by itself, now that console games ship on BD-ROM and PC games are BD-ROM-sized downloads?