For me, the biggest issue is that most videos still require Flash.

Google is the biggest hypocrite here. One part of the company paid a lot of money to promote patent-free video on the Internet, but the YouTube team won't use it for music videos and prefers to use Flash even when HTML5 <video> is available. The Chrome team not only backpedaled on removing patent-encumbered <video>, but also partnered with Microsoft and Netflix to bring DRM into the HTML5 standard.

My practice is to use Google Chrome when I really do need Flash or some other Google monstrosity, but otherwise keep that browser closed.

Oh, come on, it's not just that. It's also PulseAudio, also from Poettering, and udev, from RedHat's Kay Sievers, and how glibc emphasizes performance over security, from (formerly) RedHat's Ulrich Drepper, and possibly some of the silliness around RedHat-funded KVM, and the NIH silliness around ZFS vs (Oracle) btrfs, and dtrace vs strace/ftrace/whatever, and the performance of NetFilter and its proposed replacement nftables vs BSD's pf...

systemd might be the straw that breaks the camel's back, but there are many areas where someone might have issues with Linux. Personally, I'm not that invested in it either way, so I'm most swayed by software and hardware compatibility, where Linux wins really, really big. Though, I wonder what sort of reality distortion bubble RedHat is projecting around their developers, that so many of the issues are with RedHat stuff.

Even better, The Register found somebody from Intel to claim that it's an Atom 3700 series device, meaning Bay Trail. Now I'm much more interested in this device, but I'm still inclined to wait until firm confirmation.

A couple points that come to mind:

1. Better performance per clock, due to instruction set simplification and larger working set of registers.
2. Slightly better security, because of more address space to do ASLR.
3. Finally enough address space to mmap everything. If your memory usage is dominated by static assets like graphics, this would allow you to use the operating system's virtual memory paging to handle which assets are in RAM at any time.

They don't explicitly say, but it looks very much like they're using a Moorefield system, like the Nokia N1. The PowerVR graphics in the Moorefield benchmark well on Android, but it's no good.

The PowerVR drivers are closed-source, the company is hostile to open source, and even on Android the performance is inconsistent. See page 2 of Ars Technica's review of the Nexus Player. And in Jolla, the device driver is not native to the operating system, but goes through libhybris.

I refuse to support PowerVR outside of iOS, so I'm going to sit this one out.

You're an idiot (from Greek: "idios," meaning someone thinking only of yourself). Just because you find it so relaxing to change your clocks on cue like an animal in a circus, doesn't mean I want to do that.

There's nothing magic about the clocks in smartphones and computers. Those things take a lot of human labor to build and maintain, and frequently the humans make mistakes. Which you can't fix because with all that "magic," they leave out the manual controls. Or have you forgotten how iPhones sometimes make people late to meetings, or how Zunes used to die completely, or how every new program that deals with local time acts weird during the time switches, or how your unpatched system would show you the wrong time for about a month ever since this latest time switch?

I hate experiencing anxiety every time I get a new gadget that has a magical networked clock, wondering whether the clock will change correctly, or whether I'll unnecessarily wake early in the autumn or come to work late in the spring. That's on top of the general misery of changing my biological clock, and knowing that all this hassle is scientifically proven to be wrong and counterproductive but still it continues.

I don't mind having more sunlight in the afternoon. I hate changing the clock.

I don't care whether it's DST all year or standard time all year, but I hate switching back and forth. It's responsible for so much loss of life and productivity. I feel that DST switching is a twice yearly reminder that our "betters" in Congress are in charge and easily capable of messing with our lives. Until it's eliminated, I'll continue voting against my local Representative and Senators.

Yours wouldn't be the first software that has become abandonware. Users may appreciate the stability of an unchanging release. If it's distributed under a Libre license, then it can be forked and redistributed, but chances are that kids would rather make their own mistakes than work on your program.

Argh! No! CUPS did not originally come from Apple, and Apple did not own CUPS back in 2000. Apple bought CUPS and its main developer in 2007.

Oops, I meant Samba 4. Starting in MacOS X 10.7 Lion, Apple has used the closed-source SMBX instead of Samba to provide SMB service, and Apple's SMB client is licensed under APSL 2.0, which is not compatible with GPL. Apple's SMB software has also been slower and buggier than Samba.

I think Apple's aversion to GPLv3 is wrongheaded, as is Google's avoidance of GPL in Android other than the kernel. I'm not saying that it's evil, just a mistake.

Wait, what? Where'd all this hostility come from? I've used Macs for 25 years, and I'm using a Mac to type this. I like parts of Apple and MacOS X, but I recognize some of its shortcomings. In my opinion, nothing is perfect.

I didn't say that Apple does not do open source. CUPS, LLVM, Clang, and KHTML (predecessor of WebKit) were not invented at Apple, and Apple complies with the license terms of the original projects. ZeroConf and OpenCL are examples of basic infrastructure that Apple decided would be in their interests if they were widely adopted. Apple has some surprisingly small teams for some projects, and I think of ZeroConf as a Stuart Cheshire project more than a faceless corporate project. Even so, Apple initially did their open-source releases under the Apple Public Source License, which is not compatible with GPL, and the existing OpenCL kernels are all proprietary. Or did you not notice that Mesa had to reimplement OpenCL from scratch?

In contrast, I notice Apple protocols such as AirPlay and AirPrint, the whole Designed for iPhone licensing system, and how Apple is going out of their way to avoid any GPLv3 software such as Samba 3.

I don't see how you got that conclusion from what I wrote. I said that CUPS was not developed at Apple, so its peculiarities are not typical to Apple.

No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple, and it would have been even more confusingly documented. It would never have become widely adopted across the Unix world, partly because Apple would not have chosen GPLv2. Instead, Lennart Poettering would have been so in awe of it that he would have created his own unstable version of it, which would immediately have been adopted across the Linux distributions to the exclusion of any other printing system, because Lennart is the best programmer and all crashes are everybody else's fault. It would have stabilized when he got bored and started copying another Apple innovation. Like, say, launchd.

CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.

I think the keyword there is companies. The main reason for CUPS is support for IPP, a particularly enterprisey protocol. I could tell that it's enterprisey because it's full of XML and I couldn't figure out how it's supposed to work. Once I got printing to work, I didn't bother to look further into it. Printing is just an occasional hassle for me.

Of course, once CUPS got the momentum, then CUPS got more support, more printer drivers, more GUI front-ends, so right now it's just easier to get a working system using CUPS than LPRng. I'm surprised that LPRng is still seeing development as late as 2012, and the web site apparently got tweaked in March this year.

Apple is not the developer of CUPS. Apple bought CUPS back in 2007 and hired its main developer.

CUPS is an example of the sort of hairy mess that open-source developers don't like to deal with, like OpenSSL. It was the inspiration for Eric Raymond (the main guy of the Open Source movement) to scold the OSS community back in 2004. I think Eric Raymond's ire is misplaced; CUPS was uniquely horrible back then. But printing in Unix has always been bad, and CUPS made it much better than before, so everybody standardized on it.

Sure, I'd rather store stuff on my own machines than SpiderOak. A cursory read of how some SpiderOak features work doesn't give me confidence that it's an especially secure option once you start sharing files. But it's still much better than leaving everything in plaintext in Dropbox. I just link to them as an alternate to one of the panel's participants, where the alternate is actually viable already.

If Google and Facebook made the same claims as SpiderOak, then I'd be inclined to trust. There are laws about truth in advertising, and they have a history of following through in the limited areas where they do provide security: SSL for everyone, and certificate pinning in Google's web browser. Privacy also totally wrecks their business model, so I don't expect them to do so.