From 40c66ec8979ef45d2e9406e787a4a94fbdca1d30 Mon Sep 17 00:00:00 2001 From: luxagraf Date: Mon, 23 Nov 2015 10:53:43 -0500 Subject: moved this month's work to published --- amp.html | 85 --------------------------------- amp.txt | 118 ---------------------------------------------- published/amp.html | 85 +++++++++++++++++++++++++++++++++ published/amp.txt | 118 ++++++++++++++++++++++++++++++++++++++++++++++ published/ubuntu1510.html | 56 ++++++++++++++++++++++ published/ubuntu1510.txt | 91 +++++++++++++++++++++++++++++++++++ ubuntu1510.html | 56 ---------------------- ubuntu1510.txt | 91 ----------------------------------- 8 files changed, 350 insertions(+), 350 deletions(-) delete mode 100644 amp.html delete mode 100644 amp.txt create mode 100644 published/amp.html create mode 100644 published/amp.txt create mode 100644 published/ubuntu1510.html create mode 100644 published/ubuntu1510.txt delete mode 100644 ubuntu1510.html delete mode 100644 ubuntu1510.txt diff --git a/amp.html b/amp.html deleted file mode 100644 index 884a190..0000000 --- a/amp.html +++ /dev/null @@ -1,85 +0,0 @@ -

There's a story going around in these days that the web is too slow, especially over mobile networks. It's a pretty good story. It's a perpetual story. The web, while certainly improved from the days of 14.4k modems, has never been as fast as we want it to be, which is to say the web has never been instant.

-

Curiously though, rather than focusing on possible cures like increasing network speeds, finding ways to decrease network latency or even speed up web browsers, the latest version of the "web-is-too-slow" story turns the blame on the web itself. And perhaps more pointedly, the people who make it.

-

Certainly there is some truth to the slow web story. The average web page has been increasing in size at a fantastic rate. In January of 2012 the average page tracked by HTTPArchive transferred 1239kb and made 86 requests. Fast forward to September 2015 and the numbers are 2162kb of data and 103 requests. Overall size doesn't directly correlate to page load time, but it is a pretty good indicator that the web is slow and things are actually getting worse, not better.

-

While the web is slow and getting slower, native mobile applications are getting faster. Mobile devices get more powerful with every release cycle and applications take advantage of that. Apps get faster, the web gets slower.

-

This, so the story goes, is why Facebook must invent Facebook Instant Articles, why Apple News must come to exist and why Google must now go and create Accelerated Mobile Pages (AMP). Users have come to expect that everything should be as fast as native apps so Facebook, Apple and Google need to make sure the web feels the same way.

-

Google is late to the game, but its new Accelerated Mobile Pages project has the same goals as Facebook and Apple's efforts -- make the web feel like a native application on mobile devices. It's worth noting that all three companies seem utterly unconcerned with speeding up the web on the desktop.

-

All of these efforts -- Instant Articles, Apple News and AMP -- are to help speed up our experience of the web on mobile devices by stripping out all that junk that messy web developers and publishers have included in their websites. All those ads, all those images, all those interactive graphics, all those comment sections, all those extras that take too long to load.

-

Instead, Facebook Instant Articles, Apple News and now AMP will present stripped down pages that load quickly even over the paltry 3G speeds still found in much of the United States.

-

In the case of AMP there are apparently two things playing the role of villains in the "web is too slow" story: JavaScript and advertisements that use JavaScript.

-

It sounds like a pretty good story. It has good guys (Google) and bad guys (everyone not using Google Ads) and it's true to most of our experiences. Who isn't sick of intrusive ads and terrible JavaScript libraries begging for us to sign up for some terrible newsletter?

-

But this story has some fundamental problems. For example, Google owns the largest ad server network on the web, if ads are the problem, why doesn't Google get to work speeding up the ads? More on that in a bit.

-

But first, AMP.

-

What is AMP?

-

To understand AMP first you need to understand Facebook's Instant Articles. Instant Articles uses RSS and standard HTML tags to create an optimized, slightly stripped down version of an article. Facebook then allows for some extra rich-content like auto-playing video or audio clips. Despite this Facebook claims Instant Articles are up to 10 times faster than their siblings on the open web. Some of that speed gain comes from stripping things out, some likely comes from aggressive caching.

-

But the key is that Instant Articles are only available via Facebook's mobile apps and only to established publishers who sign a deal with Facebook. That means reading articles from Facebook's Instant Article partners like National Geographic, BBC, Buzzfeed and others is a faster, richer multimedia experience than those same articles when they appear on the publisher's site.

-

Apple News appears to work roughly the same way, taking RSS feeds from publishers and then optimizing the content for delivery within Apple's application.

-

All this app-based content delivery cuts out the web. That's a problem for the web and by extension, Google, which leads us to Google's Accelerated Mobile Pages project.

-

Oddly though, unlike Facebook Articles and Apple News, AMP eschews standards like RSS and HTML in favor of its own little modified subset of HTML. AMP HTML looks a lot like HTML without the bells and whistles. In fact, if you head over to the AMP project announcement you'll see an AMP page rendered in your browser. It looks like any other page on the web.

-

AMP markup uses a basic set of tags from HTML. An extremely limited set of tags. Form tags? Nope. Audio or video tags? Nope. Embed? Certainly not. Script tags? Nope. There's a very short list of the HTML tags in allowed in AMP documents available over on the project page. There's also no JavaScript allowed. Those ads and tracking scripts will never be part of AMP documents (don't worry, Google will still be tracking you).

-

AMP defines several of its own tags, things like amp-youtube, amp-ad or amp-pixel. The extra tags are part of what's known as web components, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure).

-

So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs.

-

But then there are some problematic design choices in AMP. The more you look at AMP the less it looks like a good idea.

-

Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards.

-

AMP re-invents the wheel for images using a custom component amp-img instead of HTML's img tag (not only does Google ignore RSS, JSON and RDF, it ignores HTML). AMP doesn't stop there. It does the same things with amp-audio and amp-video rather than the HTML standard audio and video. AMP developers argue that this allows AMP to only serve images when required, which isn't possible with the HTML img tag. That, however, is a limitation of web browsers, not HTML itself. AMP also very clearly has treated accessibility as an after thought, or more likely, not a thought at all. You lose more than just HTML tags with AMP.

-

In other words AMP is technically half baked at best. The good news is that AMP developers are listening. One of the worst things about AMP's initial code was the decision to disable pinch and zoom on articles. Thankfully Google has reversed course and eliminated the tag that prevented pinch and zoom.

-

There are also dozens of other open issues calling out some of the most egregious decisions in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article.

-

But the markup that is AMP is really only one part of the picture. After all, as pointed out above, if all they really wanted to do is strip out all the enhancements and just present the content of a page there are quite a few already existing ways to do that, including RSS, JSON and RDF. In fact, Google used to have an RSS reader that did just this. So why AMP?

-

Speeding things up for users is a nice side benefit, but the point of AMP, like Facebook Articles, is to lock in users to a particular site/format/service. In this case the users aren't you and I reading, it's the publishers putting the content on the web.

-

It's the Ads Stupid

-

The goal of Facebook Instant Articles is to keep you on Facebook. No need to explore the larger web when it's all right there in Facebook, especially when it loads so much faster in the Facebook app than it does in a browser on the web.

-

AMP exists because Google recognized what a threat Facebook Instant Articles is to Google's ability to serve ads.

-

This is why it's called Accelerated Mobile Pages. Sorry desktop users, Google already knows how to get ads to you.

-

If you watch the AMP demo, which shows how AMP might work when it's integrated into search results next year, you'll notice that the viewer effectively never leaves Google. The AMP pages are laid over the Google search page much the way outside webpages are loaded in native applications on most mobile platforms. The experience from the user's point of view is just like the experience of a mobile app.

-

Google needs the web to be on par with the speeds in mobile apps. Google has been trying for some time to speed up the web, but as the stats at the start of this piece indicate, it hasn't really worked.

-

To its credit the company has some of the smartest engineers around working on just this problem. Google has made one of the fastest web browsers around (if not the fastest) and in doing so has pushed other vendors to speed up their browsers as well. Since Chrome debuted web browsers have become faster and better at an astonishing rate. Score one for Google.

-

It's also been touting the benefits of mobile-friendly pages, first by labeling them as such in search results on mobile devices and then later by ranking mobile friendly pages above not-so-friendly ones when other factors are the same. It's also been quick to adopt speed improving new HTML standards like the responsive images effort, which was first supported by Chrome. Score another one or two for Google.

-

The company has also been championing speed through its various page speed tools and has even gone so far as to include speed as a factor in search engine rankings. And yet, look at those page size charts again. Pages keep getting bigger, networks speeds do not. So the web keeps slowing down. Score one for nobody.

-

In other words Google has tried just about everything within its considerable power as a search monopoly to get web developers and publishers large and small to speed up their pages.

-

It just isn't working.

-

Content Blockers 'comin'

-

Google is hardly alone in wanting the web to be fast. You and I want that too. And when web pages slow down we go looking for a way to speed them up again.

-

One increasingly popular reaction to slow web pages are content blockers, typically in the form of browser add-ons that stop pages from loading anything but the primary content of the page. Content blockers have been around for over a decade now (No Script first appeared for Firefox in 2005), but their use has always been limited. That changed with Apple's iOS 9, which for the first time has put content blocking tools in the hands of millions.

-

It's worth noting that the existence of content blockers is not entirely the result of slow websites, much of the appeal also lies in blocking intrusive ads and stopping the intrusive tracking which often comes with those ads.

-

But it's those two things, advertisements and trackers -- which typically mean loading at least a few, and in the most egregious examples dozens, of third-party scripts -- that form no small part of why even some of the web's most popular sites are, frankly, dog slow.

-

And dog slow sites are a problem for Google. If a site takes too long to load users leave and never see those Google ads. But dog slow sites are even more of a problem if sites are only dog slow in the web browser -- where Google has free reign -- and not in native apps like Facebook and Apple News, where Google has limited, if any access at all. Given a choice between fast walled gardens and slow open web Google is worried that most of us will chose fast walled garden.

-

Combine all the eyeballs using iOS with content blockers, reading the web via Facebook Instant Articles and Apple News and you suddenly have a whole lot of eyeballs that will never see any Google ads. That's a problem for Google, one that AMP is designed to fix.

-

AMP: Static Pages that Require Google's JavaScript

-

The most basic thing you can do on the web is create a flat HTML file that sits on a server and contains some basic tags. This type of page will always be lightning fast. It's also insanely simple. This is literally all you need to do to put information on the web. There's no need for JavaScript, no need even for CSS.

-

This is more or less what AMP wants you to create (AMP doesn't care if your pages are actually static or -- more likely -- generated from a database, the point is what's rendered is static).

-

But then AMP wants to turn around and require that pages include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until the script loads and only then is the page revealed.

-

As developer Justin Avery asks, "surely the document itself is going to be faster than loading a library to try and make it load faster." Pinboard.in creator Maciej Cegłowski did just that, putting together a demo page that duplicates the AMP-based AMP homepage, but without that JavaScript. Over a 3G connection Cegłowski's page fills the viewport in 1.9 seconds. The AMP homepage takes 9.2 seconds.

-

JavaScript slows down page load times, even when that JavaScript is part of Google's plan to speed up the web.

-

Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, keeping scripts to a minimum and aggressively caching content -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP.

-

In the end, developers and publishers who have been following best practices for web development and don't rely on dozens of tracking networks and ads have little to gain from AMP.

-

Unfortunately, the publishers building their sites like that right now are few and far between. Most publishers have much to gain from generating AMP pages -- at least in terms of speed. Google says that AMP can improve page speed index scores by between 15-85%. That huge range is likely a direct result of how many third-party scripts are being loaded on some sites.

-

The dependency on JavaScript has another detrimental effect, AMP documents depend on JavaScript, which is to say that if their (albeit small) script fails to load for some reason -- you're going through a tunnel on a train, only have a flaky one bar connection at the beach or any other myriad familiar mobile web scenarios -- the AMP page is completely blank.

-

When an AMP page fails, it fails spectacularly. Google knows better than this. Even Gmail still offers a pure HTML-based fallback version of itself.

-

AMP for Publishers

-

Why require a bit of JavaScript to load what amounts to one of the simplest possible pages on the web? Well, the developers would argue (correctly) that it's needed to parse, among other things, those amp-img, amp-youtube and other non-standard elements.

-

It also creates a kind of lock-in. Not nearly the sort of lock-in that publishers get into with Facebook Instant Articles, AMP is after all available for everyone, not just big name publishers who sign a deal with Google.

-

In this deal, all big media has to do is give up their ad networks. And their interactive maps. And their data visualizations. And their comment systems. And their community of readers.

-

So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), is still a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens.

-

Unlike Facebook Instant Articles though, this deal isn't just for big media, your WordPress blog can get in on the stripped down action as well.

-

Given that WordPress powers roughly 24 percent of all sites on the web, having an easy way to generate AMP documents from WordPress means a huge boost in adoption for AMP. It's certainly possible to build fast websites using WordPress, but it's also easy to do the opposite. WordPress plugins often have dramatic and negative impact on load times. It isn't uncommon to see a WordPress site loading not just one, but often several external JavaScript libraries because the user installed 3 plugins that each used a different library.

-

AMP neatly solves that problem by stripping everything out.

-

Why would anyone want to do this? Well, most probably wouldn't want to do just this. That is, AMP isn't trying to get rid of the web as we know it, it just wants to create a parallel one.

-

Publishers will not stop generating regular pages, they will simply also generate AMP files, usually, judging by the early adopter examples, by appending /amp to the end of the URL.

-

The AMP page and canonical page would reference each other through standard HTML tags. User agents could then pick and choose between them, that is, Google's web crawler might grab the AMP page, but desktop Firefox might hit the AMP page and redirect to the canonical URL.

-

On one hand what this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make /amp-specific mobile pages. Potato, potato.

-

On the other hand this nudges publishers toward an idea that's big in the IndieWeb movement: Publish (on your) Own Site, Syndicate Elsewhere, or POSSE for short.

-

The idea is own the canonical copy of your content on your own site, but then send that content everywhere you can. Or rather, everywhere you want to reach your readers. Facebook Instant Article? Sure, hook up the RSS feed. Apple News? Send the feed over there too. AMP? Sure, generate an AMP page. No need to stop there either, tap the new Medium API and half a dozen others as well.

-

Reading is a fragmented experience. Some people will love reading on the web, some via RSS in their favorite reader, some in Facebook Instant Articles, some via AMP pages on Twitter, some via Lynx in their terminal running on a restored TRS-80. The beauty of the POSSE approach is that you can reach them all from a single, canonical source.

-

AMP and the Open Web

-

AMP is not going to help the open web. With luck though, it won't hurt it either, which isn't true of either of its forerunners.

-

If you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the web.

-

As noted web developer (and AMP optimist) Jeremy Keith writes in a piece on AMP, "my hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask 'Why can't our regular pages be this fast?' By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be."

-

Not everyone is that optimistic about AMP though. Developer and Author Tim Kadlec writes, "[AMP] doesn't feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web... Using a very specific tool to build a tailored version of my page in order to 'reach everyone' doesn't fit any definition of the 'open web' that I've ever heard."

-

Indeed AMP is very much Google's moderately walled garden response to Facebook's impenetrable fortress of a garden.

-

There's one other important aspect to AMP that helps speed up their pages -- Google will cache your pages on its CDN for free.

-

As developer and creator of RSS, Dave Winer says in a post on AMP, "AMP is caching... You can use their caching if you conform to certain rules. If you don't you can use your own caching. I can't imagine there's a lot of difference unless Google weighs search results based on whether you use their code."

-

And therein lies the biggest potential problem with AMP. If Google decides to abuse its position as the default search provider for the web and prioritize AMP pages above others then AMP becomes a threat to the open web.

-

So far Google has said that AMP pages will not get any priority over regular pages in search results. But that could change. It's hard to imagine why that wouldn't change. Why would Google have faster pages at its disposal and not prioritize them over slower pages? After all speed is already a factor in rankings and AMP does make pages faster.

-

Of course it's hard to tell what AMP will do in the long run. Google throws out new projects all the time, sometimes seemingly at random. Some, like GMail, redefine the world's experience of something previously taken for granted. Other projects go the way of Wave. Remember Google Author? That was the last time Google set out to "help" the publishing industry.

-

For the web's sake let's hope Google sticks with AMP long enough to convince publishers that the real future is speeding up their own pages and embracing a POSSE-style approach. As Cegłowski writes on his AMP satire page, "it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources... Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version."

-

Let's just make sure that fast, readable version is one that lives at a URL on the open web.

diff --git a/amp.txt b/amp.txt deleted file mode 100644 index efe2ea5..0000000 --- a/amp.txt +++ /dev/null @@ -1,118 +0,0 @@ -There's a story going around today that the Web is too slow, especially over mobile networks. It's a pretty good story—and it's a perpetual story. The Web, while certainly improved from the days of 14.4k modems, has never been as fast as we want it to be, which is to say that the Web has never been instantaneous. - -Curiously, though, rather than focusing on possible cures like increasing network speeds, finding ways to decrease network latency or even speeding up Web browsers, the latest version of the "Web is too slow" story pins the blame on the Web itself. And, perhaps more pointedly, on the people who make it. - -Certainly the story has some truth to it. The average Web page has increased in size at a terrific rate. In January 2012, the average page tracked by HTTPArchive transferred 1,239kB and made 86 requests. Fast forward to September 2015 and the average page loads 2,162kB of data and makes 103 requests. These numbers don't directly correlate to longer page load-and-render times, of course, especially if download speeds are increasing too, but they are one indicator of how quickly Web pages are bulking up. - -Native mobile applications, on the other hand, are getting faster. Mobile devices get more powerful with every release cycle, and native apps take better advantage of that power. Apps get faster, the Web gets slower. This, so the story goes, is why Facebook must invent Facebook Instant Articles, why Apple News must be built, and why Google must now create Accelerated Mobile Pages (AMP). Google is late to the game, but AMP has the same goal as Facebook's and Apple's efforts—making the Web feel like a native application on mobile devices. (It's worth noting that all three solutions focus exclusively on mobile content.) - -For AMP, two things in particular stand in the way of a lean, mean browsing experience: JavaScript... and advertisements that use JavaScript. The AMP story is compelling. It has good guys (Google) and bad guys (everyone not using Google Ads), and it's true to most of our experiences. But the story also has some fundamental problems. For example, Google owns the largest ad server network on the Web. If ads are such a problem, why doesn't Google get to work speeding up the ads? - -More on that in bit. But first, AMP. -

What is AMP?

-To understand AMP first you need to understand Facebook's Instant Articles. Instant Articles uses RSS and standard HTML tags to create an optimized, slightly stripped down version of an article. Facebook then allows for some extra rich-content like auto-playing video or audio clips. Despite this Facebook claims Instant Articles are up to 10 times faster than their siblings on the open web. Some of that speed gain comes from stripping things out, some likely comes from aggressive caching. - -But the key is that Instant Articles are only available via Facebook's mobile apps and only to established publishers who sign a deal with Facebook. That means reading articles from Facebook's Instant Article partners like National Geographic, BBC, Buzzfeed and others is a faster, richer multimedia experience than those same articles when they appear on the publisher's site. - -Apple News appears to work roughly the same way, taking RSS feeds from publishers and then optimizing the content for delivery within Apple's application. - -All this app-based content delivery cuts out the web. That's a problem for the web and by extension, Google, which leads us to Google's Accelerated Mobile Pages project. - -Oddly though, unlike Facebook Articles and Apple News, AMP eschews standards like RSS and HTML in favor of its own little modified subset of HTML. AMP HTML looks a lot like HTML without the bells and whistles. In fact, if you head over to the AMP project announcement you'll see an AMP page rendered in your browser. It looks like any other page on the web. - -AMP markup uses a basic set of tags from HTML. An extremely limited set of tags. Form tags? Nope. Audio or video tags? Nope. Embed? Certainly not. Script tags? Nope. There's a very short list of the HTML tags in allowed in AMP documents available over on the project page. There's also no JavaScript allowed. Those ads and tracking scripts will never be part of AMP documents (don't worry, Google will still be tracking you). - -AMP defines several of its own tags, things like `amp-youtube`, `amp-ad` or `amp-pixel`. The extra tags are part of what's known as web components, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure). - -So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs. - -But then there are some problematic design choices in AMP. The more you look at AMP the less it looks like a good idea. - -Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards. - -AMP re-invents the wheel for images by using the custom component `amp-img` instead of HTML's `img` tag, and it does the same thing with `amp-audio` and `amp-video` rather than the HTML standard `audio` and `video`. AMP developers argue that this allows AMP to serve images only when required, which isn't possible with the HTML `img` tag. That, however, is a limitation of web browsers, not HTML itself. AMP has also very clearly treated accessibility as an after thought. You lose more than just a few HTML tags with AMP. - -In other words AMP is technically half baked at best. The good news is that AMP developers are listening. One of the worst things about AMP's initial code was the decision to disable pinch and zoom on articles. Thankfully Google has reversed course and eliminated the tag that prevented pinch and zoom. - -There are also dozens of other open issues calling out some of the most egregious decisions in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article. - -But AMP's markup language is really just one part of the picture. After all, as pointed out above, if all AMP really wanted to do was strip out all the enhancements and just present the content of a page, there are existing ways to do that. Speeding things up for users is a nice side benefit, but the point of AMP, as with Facebook Articles, looks to be more about locking in users to a particular site/format/service. In this case, though, the "users" aren't you and I as readers; the "users" are the publishers putting content on the Web. - -

It's the ads, stupid

- -The goal of Facebook Instant Articles is to keep you on Facebook. No need to explore the larger Web when it's all right there in Facebook, especially when it loads so much faster in the Facebook app than it does in a browser. (As Facebook puts it, "articles load instantly, as much as 10 times faster than the standard mobile Web." - -Google seems to have recognized what a threat Facebook Instant Articles could be to Google's ability to serve ads. This is why Google's project is called Accelerated Mobile Pages. Sorry, desktop users, Google already knows how to get ads to you. - -If you watch the AMP demo, which shows how AMP might work when it's integrated into search results next year, you'll notice that the viewer effectively never leaves Google. AMP pages are laid over the Google search page in much the same way that outside webpages are loaded in native applications on most mobile platforms. The experience from the user's point of view is just like the experience of using a mobile app. - -Google needs the web to be on par with the speeds in mobile apps. And to its credit the company has some of the smartest engineers around working on the problem. Google has made one of the fastest web browsers around (if not the fastest) and in doing so has pushed other vendors to speed up their browsers as well. Since Chrome debuted web browsers have become faster and better at an astonishing rate. Score one for Google. - -The company also been touting the benefits of mobile-friendly pages, first by labeling them as such in search results on mobile devices and then later by ranking mobile friendly pages above not-so-friendly ones when other factors are the same. It's also been quick to adopt speed improving new HTML standards like the responsive images effort, which was first supported by Chrome. Score another one or two for Google. - -But pages keep growing faster than network speeds, and the Web slows down. In other words, Google has tried just about everything within its considerable power as a search behemoth to get Web developers and publishers large and small to speed up their pages. - -It just isn't working. - -One increasingly popular reaction to slow Web pages has been the use of content blockers, typically in the form of browser add-ons that stop pages from loading anything but the primary content of the page. Content blockers have been around for over a decade now (No Script first appeared for Firefox in 2005), but their use has largely been limited to the desktop. That changed in Apple's iOS 9, which for the first time put simple content-blocking tools in the hands of millions of mobile users. - -Combine all the eyeballs that are using iOS with content blockers, reading Facebook Instant Articles, and using Apple News, and you suddenly have a whole lot of eyeballs that will never see any Google ads. That's a problem for Google, one that AMP is designed to fix. -

Static pages that require Google's JavaScript

-The most basic thing you can do on the web is create a flat HTML file that sits on a server and contains some basic tags. This type of page will always be lightning fast. It's also insanely simple. This is literally all you need to do to put information on the web. There's no need for JavaScript, no need even for CSS. - -This is more or less the sort of page AMP wants you to create (AMP doesn't care if your pages are actually static or—more likely—generated from a database. The point is what's rendered is static). But then AMP wants to turn around and require that each page include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until this script loads. Only then is the page revealed. - -This is a little odd; as developer Justin Avery writes, "Surely the document itself is going to be faster than loading a library to try and make it load faster." - -Pinboard.in creator Maciej Cegłowski did just that, putting together a demo page that duplicates the AMP-based AMP homepage, but without that JavaScript. Over a 3G connection Cegłowski's page fills the viewport in 1.9 seconds. The AMP homepage takes 9.2 seconds. - -JavaScript slows down page load times, even when that JavaScript is part of Google's plan to speed up the web. - -Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, keeping scripts to a minimum and aggressively caching content -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP. - -In the end, developers and publishers who have been following best practices for web development and don't rely on dozens of tracking networks and ads have little to gain from AMP. - -Unfortunately, the publishers building their sites like that right now are few and far between. Most publishers have much to gain from generating AMP pages -- at least in terms of speed. Google says that AMP can improve page speed index scores by between 15-85%. That huge range is likely a direct result of how many third-party scripts are being loaded on some sites. - -The dependency on JavaScript has another detrimental effect, AMP documents depend on JavaScript, which is to say that if their (albeit small) script fails to load for some reason -- say, you're going through a tunnel on a train, only have a flaky one bar connection at the beach -- the AMP page is completely blank. When an AMP page fails, it fails spectacularly. - -Google knows better than this. Even Gmail still offers a pure HTML-based fallback version of itself. - -

AMP for publishers

-Under the AMP bargain, all big media has to do is give up its ad networks. And interactive maps. And data visualizations. And comment systems. - -The deal isn't just for big media, either; your WordPress blog can get in on the stripped-down AMP action as well. Given that WordPress powers roughly 24 percent of all sites on the web, having an easy way to generate AMP documents from WordPress means a huge boost in adoption for AMP. It's certainly possible to build fast websites using WordPress, but it's also easy to do the opposite. WordPress plugins often have a dramatic (negative) impact on load times. It isn't uncommon to see a WordPress site loading not just one but several external JavaScript libraries because the user installed three plugins that each use a different library. AMP neatly solves that problem by stripping everything out. - -So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), remains a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens. - -AMP isn't trying to get rid of the Web as we know it; it just wants to create a parallel one. Under this system, publishers would not stop generating regular pages, but they would also start generating AMP files, usually (judging by the early adopter examples) by appending /amp to the end of the URL. The AMP page and the canonical page would reference each other through standard HTML tags. User agents could then pick and choose between them. That is, Google's Web crawler might grab the AMP page, but desktop Firefox might hit the AMP page and redirect to the canonical URL. - -On one hand what this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make `/amp`-specific mobile pages. Potato, potato. - -On the other hand this nudges publishers toward an idea that's big in the IndieWeb movement: Publish (on your) Own Site, Syndicate Elsewhere, or POSSE for short. - -The idea is own the canonical copy of your content on your own site, but then send that content everywhere you can. Or rather, everywhere you want to reach your readers. Facebook Instant Article? Sure, hook up the RSS feed. Apple News? Send the feed over there too. AMP? Sure, generate an AMP page. No need to stop there either, tap the new Medium API and half a dozen others as well. - -Reading is a fragmented experience. Some people will love reading on the web, some via RSS in their favorite reader, some in Facebook Instant Articles, some via AMP pages on Twitter, some via Lynx in their terminal running on a restored TRS-80. The beauty of the POSSE approach is that you can reach them all from a single, canonical source. - -  -

AMP and the open Web

-While has problems and just might be designed to lock publishers into a Google-controlled format, it does so far seem to be friendlier to the open Web than Facebook Instant Articles. - -In fact, if you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the Web. As noted Web developer (and AMP optimist) Jeremy Keith writes in a piece on AMP, "My hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask 'Why can't our regular pages be this fast?' By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole Web could be." - -Not everyone is that optimistic about AMP, though. Developer and Author Tim Kadlec writes, "[AMP] doesn't feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the Web... Using a very specific tool to build a tailored version of my page in order to 'reach everyone' doesn't fit any definition of the 'open Web' that I've ever heard." - -There's one other important aspect to AMP that helps speed up their pages -- Google will cache your pages on its CDN for free. - -As the developer and creator of RSS, Dave Winer, says in a post on AMP, "AMP is caching... You can use their caching if you conform to certain rules. If you don't, you can use your own caching. I can't imagine there's a lot of difference unless Google weighs search results based on whether you use their code." - -And therein lies the biggest potential problem with AMP. If Google decides to abuse its position as the default search provider for the web and prioritize AMP pages above others then AMP becomes a threat to the open web. - -So far Google has said that AMP pages will not get any priority over regular pages in search results. But that could change. It's hard to imagine why that wouldn't change. Why would Google have faster pages at its disposal and not prioritize them over slower pages? After all speed is already a factor in rankings and AMP does make pages faster. - -Of course it's hard to tell what AMP will do in the long run. Google throws out new projects all the time, sometimes seemingly at random. Some, like GMail, redefine the world's experience of something previously taken for granted. Other projects go the way of Wave. Remember Google Author? That was the last time Google set out to "help" the publishing industry. - -For the web's sake let's hope Google sticks with AMP long enough to convince publishers that the real future is speeding up their own pages and embracing a POSSE-style approach. As Cegłowski writes on his AMP satire page, "it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources... Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version." - -Let's just make sure that fast, readable version is one that lives at a URL on the open web. diff --git a/published/amp.html b/published/amp.html new file mode 100644 index 0000000..884a190 --- /dev/null +++ b/published/amp.html @@ -0,0 +1,85 @@ +

There's a story going around in these days that the web is too slow, especially over mobile networks. It's a pretty good story. It's a perpetual story. The web, while certainly improved from the days of 14.4k modems, has never been as fast as we want it to be, which is to say the web has never been instant.

+

Curiously though, rather than focusing on possible cures like increasing network speeds, finding ways to decrease network latency or even speed up web browsers, the latest version of the "web-is-too-slow" story turns the blame on the web itself. And perhaps more pointedly, the people who make it.

+

Certainly there is some truth to the slow web story. The average web page has been increasing in size at a fantastic rate. In January of 2012 the average page tracked by HTTPArchive transferred 1239kb and made 86 requests. Fast forward to September 2015 and the numbers are 2162kb of data and 103 requests. Overall size doesn't directly correlate to page load time, but it is a pretty good indicator that the web is slow and things are actually getting worse, not better.

+

While the web is slow and getting slower, native mobile applications are getting faster. Mobile devices get more powerful with every release cycle and applications take advantage of that. Apps get faster, the web gets slower.

+

This, so the story goes, is why Facebook must invent Facebook Instant Articles, why Apple News must come to exist and why Google must now go and create Accelerated Mobile Pages (AMP). Users have come to expect that everything should be as fast as native apps so Facebook, Apple and Google need to make sure the web feels the same way.

+

Google is late to the game, but its new Accelerated Mobile Pages project has the same goals as Facebook and Apple's efforts -- make the web feel like a native application on mobile devices. It's worth noting that all three companies seem utterly unconcerned with speeding up the web on the desktop.

+

All of these efforts -- Instant Articles, Apple News and AMP -- are to help speed up our experience of the web on mobile devices by stripping out all that junk that messy web developers and publishers have included in their websites. All those ads, all those images, all those interactive graphics, all those comment sections, all those extras that take too long to load.

+

Instead, Facebook Instant Articles, Apple News and now AMP will present stripped down pages that load quickly even over the paltry 3G speeds still found in much of the United States.

+

In the case of AMP there are apparently two things playing the role of villains in the "web is too slow" story: JavaScript and advertisements that use JavaScript.

+

It sounds like a pretty good story. It has good guys (Google) and bad guys (everyone not using Google Ads) and it's true to most of our experiences. Who isn't sick of intrusive ads and terrible JavaScript libraries begging for us to sign up for some terrible newsletter?

+

But this story has some fundamental problems. For example, Google owns the largest ad server network on the web, if ads are the problem, why doesn't Google get to work speeding up the ads? More on that in a bit.

+

But first, AMP.

+

What is AMP?

+

To understand AMP first you need to understand Facebook's Instant Articles. Instant Articles uses RSS and standard HTML tags to create an optimized, slightly stripped down version of an article. Facebook then allows for some extra rich-content like auto-playing video or audio clips. Despite this Facebook claims Instant Articles are up to 10 times faster than their siblings on the open web. Some of that speed gain comes from stripping things out, some likely comes from aggressive caching.

+

But the key is that Instant Articles are only available via Facebook's mobile apps and only to established publishers who sign a deal with Facebook. That means reading articles from Facebook's Instant Article partners like National Geographic, BBC, Buzzfeed and others is a faster, richer multimedia experience than those same articles when they appear on the publisher's site.

+

Apple News appears to work roughly the same way, taking RSS feeds from publishers and then optimizing the content for delivery within Apple's application.

+

All this app-based content delivery cuts out the web. That's a problem for the web and by extension, Google, which leads us to Google's Accelerated Mobile Pages project.

+

Oddly though, unlike Facebook Articles and Apple News, AMP eschews standards like RSS and HTML in favor of its own little modified subset of HTML. AMP HTML looks a lot like HTML without the bells and whistles. In fact, if you head over to the AMP project announcement you'll see an AMP page rendered in your browser. It looks like any other page on the web.

+

AMP markup uses a basic set of tags from HTML. An extremely limited set of tags. Form tags? Nope. Audio or video tags? Nope. Embed? Certainly not. Script tags? Nope. There's a very short list of the HTML tags in allowed in AMP documents available over on the project page. There's also no JavaScript allowed. Those ads and tracking scripts will never be part of AMP documents (don't worry, Google will still be tracking you).

+

AMP defines several of its own tags, things like amp-youtube, amp-ad or amp-pixel. The extra tags are part of what's known as web components, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure).

+

So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs.

+

But then there are some problematic design choices in AMP. The more you look at AMP the less it looks like a good idea.

+

Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards.

+

AMP re-invents the wheel for images using a custom component amp-img instead of HTML's img tag (not only does Google ignore RSS, JSON and RDF, it ignores HTML). AMP doesn't stop there. It does the same things with amp-audio and amp-video rather than the HTML standard audio and video. AMP developers argue that this allows AMP to only serve images when required, which isn't possible with the HTML img tag. That, however, is a limitation of web browsers, not HTML itself. AMP also very clearly has treated accessibility as an after thought, or more likely, not a thought at all. You lose more than just HTML tags with AMP.

+

In other words AMP is technically half baked at best. The good news is that AMP developers are listening. One of the worst things about AMP's initial code was the decision to disable pinch and zoom on articles. Thankfully Google has reversed course and eliminated the tag that prevented pinch and zoom.

+

There are also dozens of other open issues calling out some of the most egregious decisions in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article.

+

But the markup that is AMP is really only one part of the picture. After all, as pointed out above, if all they really wanted to do is strip out all the enhancements and just present the content of a page there are quite a few already existing ways to do that, including RSS, JSON and RDF. In fact, Google used to have an RSS reader that did just this. So why AMP?

+

Speeding things up for users is a nice side benefit, but the point of AMP, like Facebook Articles, is to lock in users to a particular site/format/service. In this case the users aren't you and I reading, it's the publishers putting the content on the web.

+

It's the Ads Stupid

+

The goal of Facebook Instant Articles is to keep you on Facebook. No need to explore the larger web when it's all right there in Facebook, especially when it loads so much faster in the Facebook app than it does in a browser on the web.

+

AMP exists because Google recognized what a threat Facebook Instant Articles is to Google's ability to serve ads.

+

This is why it's called Accelerated Mobile Pages. Sorry desktop users, Google already knows how to get ads to you.

+

If you watch the AMP demo, which shows how AMP might work when it's integrated into search results next year, you'll notice that the viewer effectively never leaves Google. The AMP pages are laid over the Google search page much the way outside webpages are loaded in native applications on most mobile platforms. The experience from the user's point of view is just like the experience of a mobile app.

+

Google needs the web to be on par with the speeds in mobile apps. Google has been trying for some time to speed up the web, but as the stats at the start of this piece indicate, it hasn't really worked.

+

To its credit the company has some of the smartest engineers around working on just this problem. Google has made one of the fastest web browsers around (if not the fastest) and in doing so has pushed other vendors to speed up their browsers as well. Since Chrome debuted web browsers have become faster and better at an astonishing rate. Score one for Google.

+

It's also been touting the benefits of mobile-friendly pages, first by labeling them as such in search results on mobile devices and then later by ranking mobile friendly pages above not-so-friendly ones when other factors are the same. It's also been quick to adopt speed improving new HTML standards like the responsive images effort, which was first supported by Chrome. Score another one or two for Google.

+

The company has also been championing speed through its various page speed tools and has even gone so far as to include speed as a factor in search engine rankings. And yet, look at those page size charts again. Pages keep getting bigger, networks speeds do not. So the web keeps slowing down. Score one for nobody.

+

In other words Google has tried just about everything within its considerable power as a search monopoly to get web developers and publishers large and small to speed up their pages.

+

It just isn't working.

+

Content Blockers 'comin'

+

Google is hardly alone in wanting the web to be fast. You and I want that too. And when web pages slow down we go looking for a way to speed them up again.

+

One increasingly popular reaction to slow web pages are content blockers, typically in the form of browser add-ons that stop pages from loading anything but the primary content of the page. Content blockers have been around for over a decade now (No Script first appeared for Firefox in 2005), but their use has always been limited. That changed with Apple's iOS 9, which for the first time has put content blocking tools in the hands of millions.

+

It's worth noting that the existence of content blockers is not entirely the result of slow websites, much of the appeal also lies in blocking intrusive ads and stopping the intrusive tracking which often comes with those ads.

+

But it's those two things, advertisements and trackers -- which typically mean loading at least a few, and in the most egregious examples dozens, of third-party scripts -- that form no small part of why even some of the web's most popular sites are, frankly, dog slow.

+

And dog slow sites are a problem for Google. If a site takes too long to load users leave and never see those Google ads. But dog slow sites are even more of a problem if sites are only dog slow in the web browser -- where Google has free reign -- and not in native apps like Facebook and Apple News, where Google has limited, if any access at all. Given a choice between fast walled gardens and slow open web Google is worried that most of us will chose fast walled garden.

+

Combine all the eyeballs using iOS with content blockers, reading the web via Facebook Instant Articles and Apple News and you suddenly have a whole lot of eyeballs that will never see any Google ads. That's a problem for Google, one that AMP is designed to fix.

+

AMP: Static Pages that Require Google's JavaScript

+

The most basic thing you can do on the web is create a flat HTML file that sits on a server and contains some basic tags. This type of page will always be lightning fast. It's also insanely simple. This is literally all you need to do to put information on the web. There's no need for JavaScript, no need even for CSS.

+

This is more or less what AMP wants you to create (AMP doesn't care if your pages are actually static or -- more likely -- generated from a database, the point is what's rendered is static).

+

But then AMP wants to turn around and require that pages include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until the script loads and only then is the page revealed.

+

As developer Justin Avery asks, "surely the document itself is going to be faster than loading a library to try and make it load faster." Pinboard.in creator Maciej Cegłowski did just that, putting together a demo page that duplicates the AMP-based AMP homepage, but without that JavaScript. Over a 3G connection Cegłowski's page fills the viewport in 1.9 seconds. The AMP homepage takes 9.2 seconds.

+

JavaScript slows down page load times, even when that JavaScript is part of Google's plan to speed up the web.

+

Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, keeping scripts to a minimum and aggressively caching content -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP.

+

In the end, developers and publishers who have been following best practices for web development and don't rely on dozens of tracking networks and ads have little to gain from AMP.

+

Unfortunately, the publishers building their sites like that right now are few and far between. Most publishers have much to gain from generating AMP pages -- at least in terms of speed. Google says that AMP can improve page speed index scores by between 15-85%. That huge range is likely a direct result of how many third-party scripts are being loaded on some sites.

+

The dependency on JavaScript has another detrimental effect, AMP documents depend on JavaScript, which is to say that if their (albeit small) script fails to load for some reason -- you're going through a tunnel on a train, only have a flaky one bar connection at the beach or any other myriad familiar mobile web scenarios -- the AMP page is completely blank.

+

When an AMP page fails, it fails spectacularly. Google knows better than this. Even Gmail still offers a pure HTML-based fallback version of itself.

+

AMP for Publishers

+

Why require a bit of JavaScript to load what amounts to one of the simplest possible pages on the web? Well, the developers would argue (correctly) that it's needed to parse, among other things, those amp-img, amp-youtube and other non-standard elements.

+

It also creates a kind of lock-in. Not nearly the sort of lock-in that publishers get into with Facebook Instant Articles, AMP is after all available for everyone, not just big name publishers who sign a deal with Google.

+

In this deal, all big media has to do is give up their ad networks. And their interactive maps. And their data visualizations. And their comment systems. And their community of readers.

+

So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), is still a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens.

+

Unlike Facebook Instant Articles though, this deal isn't just for big media, your WordPress blog can get in on the stripped down action as well.

+

Given that WordPress powers roughly 24 percent of all sites on the web, having an easy way to generate AMP documents from WordPress means a huge boost in adoption for AMP. It's certainly possible to build fast websites using WordPress, but it's also easy to do the opposite. WordPress plugins often have dramatic and negative impact on load times. It isn't uncommon to see a WordPress site loading not just one, but often several external JavaScript libraries because the user installed 3 plugins that each used a different library.

+

AMP neatly solves that problem by stripping everything out.

+

Why would anyone want to do this? Well, most probably wouldn't want to do just this. That is, AMP isn't trying to get rid of the web as we know it, it just wants to create a parallel one.

+

Publishers will not stop generating regular pages, they will simply also generate AMP files, usually, judging by the early adopter examples, by appending /amp to the end of the URL.

+

The AMP page and canonical page would reference each other through standard HTML tags. User agents could then pick and choose between them, that is, Google's web crawler might grab the AMP page, but desktop Firefox might hit the AMP page and redirect to the canonical URL.

+

On one hand what this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make /amp-specific mobile pages. Potato, potato.

+

On the other hand this nudges publishers toward an idea that's big in the IndieWeb movement: Publish (on your) Own Site, Syndicate Elsewhere, or POSSE for short.

+

The idea is own the canonical copy of your content on your own site, but then send that content everywhere you can. Or rather, everywhere you want to reach your readers. Facebook Instant Article? Sure, hook up the RSS feed. Apple News? Send the feed over there too. AMP? Sure, generate an AMP page. No need to stop there either, tap the new Medium API and half a dozen others as well.

+

Reading is a fragmented experience. Some people will love reading on the web, some via RSS in their favorite reader, some in Facebook Instant Articles, some via AMP pages on Twitter, some via Lynx in their terminal running on a restored TRS-80. The beauty of the POSSE approach is that you can reach them all from a single, canonical source.

+

AMP and the Open Web

+

AMP is not going to help the open web. With luck though, it won't hurt it either, which isn't true of either of its forerunners.

+

If you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the web.

+

As noted web developer (and AMP optimist) Jeremy Keith writes in a piece on AMP, "my hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask 'Why can't our regular pages be this fast?' By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be."

+

Not everyone is that optimistic about AMP though. Developer and Author Tim Kadlec writes, "[AMP] doesn't feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web... Using a very specific tool to build a tailored version of my page in order to 'reach everyone' doesn't fit any definition of the 'open web' that I've ever heard."

+

Indeed AMP is very much Google's moderately walled garden response to Facebook's impenetrable fortress of a garden.

+

There's one other important aspect to AMP that helps speed up their pages -- Google will cache your pages on its CDN for free.

+

As developer and creator of RSS, Dave Winer says in a post on AMP, "AMP is caching... You can use their caching if you conform to certain rules. If you don't you can use your own caching. I can't imagine there's a lot of difference unless Google weighs search results based on whether you use their code."

+

And therein lies the biggest potential problem with AMP. If Google decides to abuse its position as the default search provider for the web and prioritize AMP pages above others then AMP becomes a threat to the open web.

+

So far Google has said that AMP pages will not get any priority over regular pages in search results. But that could change. It's hard to imagine why that wouldn't change. Why would Google have faster pages at its disposal and not prioritize them over slower pages? After all speed is already a factor in rankings and AMP does make pages faster.

+

Of course it's hard to tell what AMP will do in the long run. Google throws out new projects all the time, sometimes seemingly at random. Some, like GMail, redefine the world's experience of something previously taken for granted. Other projects go the way of Wave. Remember Google Author? That was the last time Google set out to "help" the publishing industry.

+

For the web's sake let's hope Google sticks with AMP long enough to convince publishers that the real future is speeding up their own pages and embracing a POSSE-style approach. As Cegłowski writes on his AMP satire page, "it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources... Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version."

+

Let's just make sure that fast, readable version is one that lives at a URL on the open web.

diff --git a/published/amp.txt b/published/amp.txt new file mode 100644 index 0000000..efe2ea5 --- /dev/null +++ b/published/amp.txt @@ -0,0 +1,118 @@ +There's a story going around today that the Web is too slow, especially over mobile networks. It's a pretty good story—and it's a perpetual story. The Web, while certainly improved from the days of 14.4k modems, has never been as fast as we want it to be, which is to say that the Web has never been instantaneous. + +Curiously, though, rather than focusing on possible cures like increasing network speeds, finding ways to decrease network latency or even speeding up Web browsers, the latest version of the "Web is too slow" story pins the blame on the Web itself. And, perhaps more pointedly, on the people who make it. + +Certainly the story has some truth to it. The average Web page has increased in size at a terrific rate. In January 2012, the average page tracked by HTTPArchive transferred 1,239kB and made 86 requests. Fast forward to September 2015 and the average page loads 2,162kB of data and makes 103 requests. These numbers don't directly correlate to longer page load-and-render times, of course, especially if download speeds are increasing too, but they are one indicator of how quickly Web pages are bulking up. + +Native mobile applications, on the other hand, are getting faster. Mobile devices get more powerful with every release cycle, and native apps take better advantage of that power. Apps get faster, the Web gets slower. This, so the story goes, is why Facebook must invent Facebook Instant Articles, why Apple News must be built, and why Google must now create Accelerated Mobile Pages (AMP). Google is late to the game, but AMP has the same goal as Facebook's and Apple's efforts—making the Web feel like a native application on mobile devices. (It's worth noting that all three solutions focus exclusively on mobile content.) + +For AMP, two things in particular stand in the way of a lean, mean browsing experience: JavaScript... and advertisements that use JavaScript. The AMP story is compelling. It has good guys (Google) and bad guys (everyone not using Google Ads), and it's true to most of our experiences. But the story also has some fundamental problems. For example, Google owns the largest ad server network on the Web. If ads are such a problem, why doesn't Google get to work speeding up the ads? + +More on that in bit. But first, AMP. +

What is AMP?

+To understand AMP first you need to understand Facebook's Instant Articles. Instant Articles uses RSS and standard HTML tags to create an optimized, slightly stripped down version of an article. Facebook then allows for some extra rich-content like auto-playing video or audio clips. Despite this Facebook claims Instant Articles are up to 10 times faster than their siblings on the open web. Some of that speed gain comes from stripping things out, some likely comes from aggressive caching. + +But the key is that Instant Articles are only available via Facebook's mobile apps and only to established publishers who sign a deal with Facebook. That means reading articles from Facebook's Instant Article partners like National Geographic, BBC, Buzzfeed and others is a faster, richer multimedia experience than those same articles when they appear on the publisher's site. + +Apple News appears to work roughly the same way, taking RSS feeds from publishers and then optimizing the content for delivery within Apple's application. + +All this app-based content delivery cuts out the web. That's a problem for the web and by extension, Google, which leads us to Google's Accelerated Mobile Pages project. + +Oddly though, unlike Facebook Articles and Apple News, AMP eschews standards like RSS and HTML in favor of its own little modified subset of HTML. AMP HTML looks a lot like HTML without the bells and whistles. In fact, if you head over to the AMP project announcement you'll see an AMP page rendered in your browser. It looks like any other page on the web. + +AMP markup uses a basic set of tags from HTML. An extremely limited set of tags. Form tags? Nope. Audio or video tags? Nope. Embed? Certainly not. Script tags? Nope. There's a very short list of the HTML tags in allowed in AMP documents available over on the project page. There's also no JavaScript allowed. Those ads and tracking scripts will never be part of AMP documents (don't worry, Google will still be tracking you). + +AMP defines several of its own tags, things like `amp-youtube`, `amp-ad` or `amp-pixel`. The extra tags are part of what's known as web components, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure). + +So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs. + +But then there are some problematic design choices in AMP. The more you look at AMP the less it looks like a good idea. + +Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards. + +AMP re-invents the wheel for images by using the custom component `amp-img` instead of HTML's `img` tag, and it does the same thing with `amp-audio` and `amp-video` rather than the HTML standard `audio` and `video`. AMP developers argue that this allows AMP to serve images only when required, which isn't possible with the HTML `img` tag. That, however, is a limitation of web browsers, not HTML itself. AMP has also very clearly treated accessibility as an after thought. You lose more than just a few HTML tags with AMP. + +In other words AMP is technically half baked at best. The good news is that AMP developers are listening. One of the worst things about AMP's initial code was the decision to disable pinch and zoom on articles. Thankfully Google has reversed course and eliminated the tag that prevented pinch and zoom. + +There are also dozens of other open issues calling out some of the most egregious decisions in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article. + +But AMP's markup language is really just one part of the picture. After all, as pointed out above, if all AMP really wanted to do was strip out all the enhancements and just present the content of a page, there are existing ways to do that. Speeding things up for users is a nice side benefit, but the point of AMP, as with Facebook Articles, looks to be more about locking in users to a particular site/format/service. In this case, though, the "users" aren't you and I as readers; the "users" are the publishers putting content on the Web. + +

It's the ads, stupid

+ +The goal of Facebook Instant Articles is to keep you on Facebook. No need to explore the larger Web when it's all right there in Facebook, especially when it loads so much faster in the Facebook app than it does in a browser. (As Facebook puts it, "articles load instantly, as much as 10 times faster than the standard mobile Web." + +Google seems to have recognized what a threat Facebook Instant Articles could be to Google's ability to serve ads. This is why Google's project is called Accelerated Mobile Pages. Sorry, desktop users, Google already knows how to get ads to you. + +If you watch the AMP demo, which shows how AMP might work when it's integrated into search results next year, you'll notice that the viewer effectively never leaves Google. AMP pages are laid over the Google search page in much the same way that outside webpages are loaded in native applications on most mobile platforms. The experience from the user's point of view is just like the experience of using a mobile app. + +Google needs the web to be on par with the speeds in mobile apps. And to its credit the company has some of the smartest engineers around working on the problem. Google has made one of the fastest web browsers around (if not the fastest) and in doing so has pushed other vendors to speed up their browsers as well. Since Chrome debuted web browsers have become faster and better at an astonishing rate. Score one for Google. + +The company also been touting the benefits of mobile-friendly pages, first by labeling them as such in search results on mobile devices and then later by ranking mobile friendly pages above not-so-friendly ones when other factors are the same. It's also been quick to adopt speed improving new HTML standards like the responsive images effort, which was first supported by Chrome. Score another one or two for Google. + +But pages keep growing faster than network speeds, and the Web slows down. In other words, Google has tried just about everything within its considerable power as a search behemoth to get Web developers and publishers large and small to speed up their pages. + +It just isn't working. + +One increasingly popular reaction to slow Web pages has been the use of content blockers, typically in the form of browser add-ons that stop pages from loading anything but the primary content of the page. Content blockers have been around for over a decade now (No Script first appeared for Firefox in 2005), but their use has largely been limited to the desktop. That changed in Apple's iOS 9, which for the first time put simple content-blocking tools in the hands of millions of mobile users. + +Combine all the eyeballs that are using iOS with content blockers, reading Facebook Instant Articles, and using Apple News, and you suddenly have a whole lot of eyeballs that will never see any Google ads. That's a problem for Google, one that AMP is designed to fix. +

Static pages that require Google's JavaScript

+The most basic thing you can do on the web is create a flat HTML file that sits on a server and contains some basic tags. This type of page will always be lightning fast. It's also insanely simple. This is literally all you need to do to put information on the web. There's no need for JavaScript, no need even for CSS. + +This is more or less the sort of page AMP wants you to create (AMP doesn't care if your pages are actually static or—more likely—generated from a database. The point is what's rendered is static). But then AMP wants to turn around and require that each page include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until this script loads. Only then is the page revealed. + +This is a little odd; as developer Justin Avery writes, "Surely the document itself is going to be faster than loading a library to try and make it load faster." + +Pinboard.in creator Maciej Cegłowski did just that, putting together a demo page that duplicates the AMP-based AMP homepage, but without that JavaScript. Over a 3G connection Cegłowski's page fills the viewport in 1.9 seconds. The AMP homepage takes 9.2 seconds. + +JavaScript slows down page load times, even when that JavaScript is part of Google's plan to speed up the web. + +Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, keeping scripts to a minimum and aggressively caching content -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP. + +In the end, developers and publishers who have been following best practices for web development and don't rely on dozens of tracking networks and ads have little to gain from AMP. + +Unfortunately, the publishers building their sites like that right now are few and far between. Most publishers have much to gain from generating AMP pages -- at least in terms of speed. Google says that AMP can improve page speed index scores by between 15-85%. That huge range is likely a direct result of how many third-party scripts are being loaded on some sites. + +The dependency on JavaScript has another detrimental effect, AMP documents depend on JavaScript, which is to say that if their (albeit small) script fails to load for some reason -- say, you're going through a tunnel on a train, only have a flaky one bar connection at the beach -- the AMP page is completely blank. When an AMP page fails, it fails spectacularly. + +Google knows better than this. Even Gmail still offers a pure HTML-based fallback version of itself. + +

AMP for publishers

+Under the AMP bargain, all big media has to do is give up its ad networks. And interactive maps. And data visualizations. And comment systems. + +The deal isn't just for big media, either; your WordPress blog can get in on the stripped-down AMP action as well. Given that WordPress powers roughly 24 percent of all sites on the web, having an easy way to generate AMP documents from WordPress means a huge boost in adoption for AMP. It's certainly possible to build fast websites using WordPress, but it's also easy to do the opposite. WordPress plugins often have a dramatic (negative) impact on load times. It isn't uncommon to see a WordPress site loading not just one but several external JavaScript libraries because the user installed three plugins that each use a different library. AMP neatly solves that problem by stripping everything out. + +So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), remains a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens. + +AMP isn't trying to get rid of the Web as we know it; it just wants to create a parallel one. Under this system, publishers would not stop generating regular pages, but they would also start generating AMP files, usually (judging by the early adopter examples) by appending /amp to the end of the URL. The AMP page and the canonical page would reference each other through standard HTML tags. User agents could then pick and choose between them. That is, Google's Web crawler might grab the AMP page, but desktop Firefox might hit the AMP page and redirect to the canonical URL. + +On one hand what this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make `/amp`-specific mobile pages. Potato, potato. + +On the other hand this nudges publishers toward an idea that's big in the IndieWeb movement: Publish (on your) Own Site, Syndicate Elsewhere, or POSSE for short. + +The idea is own the canonical copy of your content on your own site, but then send that content everywhere you can. Or rather, everywhere you want to reach your readers. Facebook Instant Article? Sure, hook up the RSS feed. Apple News? Send the feed over there too. AMP? Sure, generate an AMP page. No need to stop there either, tap the new Medium API and half a dozen others as well. + +Reading is a fragmented experience. Some people will love reading on the web, some via RSS in their favorite reader, some in Facebook Instant Articles, some via AMP pages on Twitter, some via Lynx in their terminal running on a restored TRS-80. The beauty of the POSSE approach is that you can reach them all from a single, canonical source. + +  +

AMP and the open Web

+While has problems and just might be designed to lock publishers into a Google-controlled format, it does so far seem to be friendlier to the open Web than Facebook Instant Articles. + +In fact, if you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the Web. As noted Web developer (and AMP optimist) Jeremy Keith writes in a piece on AMP, "My hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask 'Why can't our regular pages be this fast?' By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole Web could be." + +Not everyone is that optimistic about AMP, though. Developer and Author Tim Kadlec writes, "[AMP] doesn't feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the Web... Using a very specific tool to build a tailored version of my page in order to 'reach everyone' doesn't fit any definition of the 'open Web' that I've ever heard." + +There's one other important aspect to AMP that helps speed up their pages -- Google will cache your pages on its CDN for free. + +As the developer and creator of RSS, Dave Winer, says in a post on AMP, "AMP is caching... You can use their caching if you conform to certain rules. If you don't, you can use your own caching. I can't imagine there's a lot of difference unless Google weighs search results based on whether you use their code." + +And therein lies the biggest potential problem with AMP. If Google decides to abuse its position as the default search provider for the web and prioritize AMP pages above others then AMP becomes a threat to the open web. + +So far Google has said that AMP pages will not get any priority over regular pages in search results. But that could change. It's hard to imagine why that wouldn't change. Why would Google have faster pages at its disposal and not prioritize them over slower pages? After all speed is already a factor in rankings and AMP does make pages faster. + +Of course it's hard to tell what AMP will do in the long run. Google throws out new projects all the time, sometimes seemingly at random. Some, like GMail, redefine the world's experience of something previously taken for granted. Other projects go the way of Wave. Remember Google Author? That was the last time Google set out to "help" the publishing industry. + +For the web's sake let's hope Google sticks with AMP long enough to convince publishers that the real future is speeding up their own pages and embracing a POSSE-style approach. As Cegłowski writes on his AMP satire page, "it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources... Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version." + +Let's just make sure that fast, readable version is one that lives at a URL on the open web. diff --git a/published/ubuntu1510.html b/published/ubuntu1510.html new file mode 100644 index 0000000..bd6311d --- /dev/null +++ b/published/ubuntu1510.html @@ -0,0 +1,56 @@ +

Canonical recently released Ubuntu 15.10, nicknamed Wily Werewolf.

+

In the past the Autumn releases of Ubuntu Linux have often been more experimental affairs and warranted some caution when updating. They weren't quite update-at-your-own risk rough, but they were often packed full of new features that were not fully baked.

+

Whereas Spring .04 releases tended to be stable (and every two years packaged as Long Term Support releases), Autumn was a time to experiment.

+

For example, the now shuttered Ubuntu One first debuted in 9.10. The Unity desktop became a default in 11.10 and the controversial Amazon search results in the Unity Dash made their debut in 12.10.

+

Unfortunately -- or fortunately, depending on how you feel about desktop experiments -- that's not a case with Wily Werewolf.

+

There are new features worth updating for in this release, but on the whole this is Canonical refining what it has already created, getting ready for the next LTS release (Ubuntu 16.04, due toward the end of April 2016), which will also likely be the last LTS release based on Unity 7.

+

By this time next year 16.10 will be back to the experimental new features with an entirely different beast on the desktop -- Unity 8, Mir and other big changes will return next year's .10 release to the kind of playground status of the past.

+

More on Unity 8 and what it means for Ubuntu in a minute. But first, Ubuntu 15.10, which might be the very last of its kind for a little while -- a stable, welcome update that doesn't require you to radically change your workflow or habits.

+

Ubuntu 15.10

+ +[image="ubuntu1510-desktop.png" caption="Visually Ubuntu 15.10 looks a lot like previous releases."] + +

While Ubuntu 15.10 is unlikely to win any awards for innovation there are some very useful new features in the kernel update, a couple of UI changes for Unity and plenty of application updates, all of which make it well worth the update.

+

The most notable UI changes in this release are the scrollbars, which are now pulled straight from GNOME 3. Canonical has abandoned its little disappearing "handle"-style scrollbars in favor of GNOME's defaults (which have improved considerably since Ubuntu started work on its own version). The change appears to based more on code maintenance and development effort than any strong aesthetic feelings from Canonical. It would seem that writing and maintaining your own scrollbar code is more work than it's worth. The visual change is minor and solves quite a few bugs in Canonical's home-grown scrollbars, making it a win for users as well as the programmers once tasked with maintaining the old code base.

+ +[image="ubuntu1510-scrollbars.png" caption="The old Ubuntu-created scrollbar is on the left, the new upstream version from GNOME on the right."] + +

Abandoning the homegrown scrollbars might also mean that Unity is able to integrate upstream GNOME updates faster than it has been lately. With this release most of the GNOME suite of tools that powers much of Unity have finally been updated to 3.16, though a few holdouts like GEdit remain at much older versions.

+

Aside from the scrollbars, there's not a lot of visual changes to this release. Unity itself gets a slight version bump with some bug fixes and a couple new features, including a new option to drag icons out of the Dash launcher and onto your desktop. If you were really missing the ability to clutter your desktop with something other than files, well, now you can throw some application launchers in there for good measure.

+

Other notable bug fixes in Unity include an annoying problem with fullscreen menu bars and the ability to access locally integrated menus -- that is, menus within the window rather than in the top bar -- on unfocussed windows.

+

While those are welcome fixes, most of what's interesting in this release is not directly from Canonical. The most exiting thing in Ubuntu 15.10 is probably the updated kernel, which is now based on the upstream Linux Kernel 4.2.

+

The 4.2 line brings support for for recent Radeon GPUs, as well as some new encryption options for ext4 disks. There's also support for Intel's new Broxton chips, which just might be finding their way into an Ubuntu Mobile device at some point. 15.10 also marks the first time that the new live kernel patching has been available in Ubuntu. This release also adds a new kernel for the Raspberry Pi 2.

+

Linux game aficionados will be happy hear that this release ships with support for the new Steam controller.

+

Developers get some love in this release too, with updates for Python and Ubuntu Make, Ubuntu's impressive suite of developer tools. If you're looking for a quick way to get, for example, a basic Android development environment set up, you'd be hard pressed to beat Ubuntu Make's simple umake android command.

+

Anyone doing tech support from an Ubuntu machine will be happy to hear that Virtualbox has been updated with the latest version, which offers guest additions for Windows 10. The rest of Ubuntu's standard application suite has been updated as well, including the latest version of Firefox, Thunderbird, Chromium and more. Of particular note is LibreOffice, which has been upgraded to version 5, a major update for LibreOffice users.

+

Ubuntu 15.10 has been rock solid in my testing. That said, I have had some trouble installing 15.10 via Chrubuntu on a new Dell 13 Chromebook, primarily related to trackpad drivers. Chrubuntu is a bit of a hack though, it's probably not fair to hold it against Ubuntu. Otherwise 15.10 has been very stable and wonderful to use on all the devices I've tested it on -- especially my old Eeepc where Ubuntu offers something that gets very little press -- UI scaling. Typically HiDPI screens get all the attention, and indeed Unity looks great in high res, but Ubuntu also has some great scaling in the opposite direction. Using the slider under Settings >> displays it's possible to downsize the entire UI, which gains you some precious real estate on smaller screens. It doesn't work everywhere -- Firefox is my most-used exception -- but it does make it easy to reclaim a few pixels on small screens.

+

Ubuntu 15.10 Flavors

+

When most people refer to Ubuntu they mean the Unity desktop version, but there are half a dozen other official Ubuntu "flavors" using just about every popular desktop available for Linux.

+

The release of Wily Werewolf brings updates for all of them, but perhaps none as big or impressive as Kubuntu 15.10. Kubuntu has always been one of the nicer KDE-based distros, but this release is particularly impressive. With Kubuntu 15.04 earlier this year, Kubuntu made the leap to Plasma 5, the next generation of KDE, but things were rough around the edges in my experience. Kubuntu 15.10 adds an impressive list of bug fixes and some added UI polish that make it one of the best KDE desktops available right now (the other standout being openSUSE Leap). This update features Plasma 5.4 and KDE Applications 15.08, which means the latest set of stock KDE apps and underlying tools you can get in a KDE distro.

+ +[image="kubuntu1510-desktop.png" caption="Kubuntu 15.10 with the new Breeze KDE theme."] + +

The new Breeze desktop with its flat, colorful, high-contrast look is what KDE refers to as a modernized interface, with "reduced visual clutter throughout the workspace." For more details on what's new in Plasma 5, see Ars' earlier review.

+

Unfortunately Kubuntu 15.10 comes along with news that the lead developer of Kubuntu is leaving the project. The good news is that he'll still be actively involved in KDE, but the bad news is he made some troubling accusations about Canonical's misuse of donations as the reason for his departure. Canonical has reportedly launched an internal audit to figure out what, if anything, went wrong.

+

The other notable update among the various Ubuntu flavors is an Ubuntu MATE release intended for the Raspberry Pi 2. The lightweight MATE desktop is a natural fit for the Pi and the new tailored release makes it much easier to get it installed and up and running on your Raspberry Pi 2.

+

Unity 8

+

Despite a healthy list of new features in Unity and quite a bit of change in some of the other flavors, many, including me, feel a certain sense of disappointment with 15.10.

+

While there's something to be said for solid updates that don't rock the boat and let you keep getting work done, that's really what LTS releases were designed for. If you prize stability, stick with 14.04 (or use Debian stable). It would be nice to see Ubuntu's x.10 releases return to something a bit edgier and more experimental.

+

That said, you actually can get something very experimental in this release, something so experimental in fact that it isn't quite ready for even a .10 release, you'll need to install it yourself -- Ubuntu running Unity 8.

+

Yes, the very thing that has made Ubuntu a tad boring lately -- as all development effort has been focused on Ubuntu Mobile and the new Unity 8 desktop -- is actually relatively easy to install. It's still very buggy though, which is why it's available as an LXC container, which helps keep it fully isolated from your production machine.

+ +[image="ubuntu1510-unity-8.png" caption="Unity 8 as a log in option. This is likely the approach Canonical will take at least for the first few releases -- Unity 8 as a separate log in option."] + +

I took it for a spin and, well, here's the thing about Unity 8: it's buggy and unstable, but it's getting really close. It's possible to experience what Canonical has in mind and it actually looks pretty great.

+

The real exciting part of Unity 8 though isn't on the desktop, but on Ubuntu Mobile and Canonical's vision of "convergence". Convergence, for Canonical, means the mobile device becomes, which the addition of a larger screen monitor, a full desktop PC. To make this possible Canonical has developed Unity 8, which will bring the same underlying code base to both the desktop and mobile versions of the OS.

+

The most impressive Unity 8 demo I've seen comes from Canonical engineers, who have posted a couple of video demos of GIMP running on an Ubuntu Mobile device.

+ +[Note to eds, I can't figure out how to embed that video...] + +

The point isn't that GIMP is on your phone, that's more a novelty since the interface would be unusably small and, in the end, pointless beyond the "hey look at that" factor. The point is that you plug your phone into a monitor and all the sudden you have the full power of GIMP running on a device that fits in your pocket (and reverts to a mobile OS when you unplug it from the monitor). It sounds good and now, for the first time, it actually looks believably good.

+

What you can see in the desktop version is the opposite portion of Canonical's convergence, mobile applications scaling up to run on the desktop device, along with some new visual splashes like the 3D app switcher and flatter visual look showcased in the video below.

+

https://www.youtube.com/watch?v=kiw1XDVopjc

+

It won't be for everyone, but if you're underwhelmed by iOS and Android's attempts to provide a desktop-quality experience with the applications you already use, Ubuntu Mobile is looking like it might finally deliver the goods.

+

Ubuntu Mobile is also the reason you have boring .10 releases like Wily Werewolf. Canonical is getting its ducks in a row for Unity 8. There will be a day soon when the minor, perhaps unremarkable releases like 15.10 are a thing of long lost memories. There will no doubt be growing pains involved with the transition to Unity 8.

+

If you want a desktop that's reliable, solid, but also pushing things forward, which is to say if you want the experience Unity has been providing for the last three, perhaps even four releases, then you will likely want to get the 16.04 LTS release coming next April. It will likely be the last Unity 7 release.

+

If you want to live on the edge, Unity 8 will likely be, if not the default, at least only a login screen away come this time next year. In the mean time enjoy your quiet days of Ubuntu 15.10.

diff --git a/published/ubuntu1510.txt b/published/ubuntu1510.txt new file mode 100644 index 0000000..f95cd82 --- /dev/null +++ b/published/ubuntu1510.txt @@ -0,0 +1,91 @@ +Canonical recently released Ubuntu 15.10, nicknamed Wily Werewolf. + +In the past the Autumn releases of Ubuntu Linux have often been more experimental affairs and warranted some caution when updating. They weren't quite update-at-your-own risk rough, but they were often packed full of new features that were not fully baked. + +Whereas Spring .04 releases tended to be stable (and every two years packaged as Long Term Support releases), Autumn was a time to experiment. + +For example, the now shuttered Ubuntu One first debuted in 9.10. The Unity desktop became a default in 11.10 and the controversial Amazon search results in the Unity Dash made their debut in 12.10. + +Unfortunately -- or fortunately, depending on how you feel about desktop experiments -- that's not a case with Wily Werewolf. + +There are new features worth updating for in this release, but on the whole this is Canonical refining what it has already created, getting ready for the next LTS release (Ubuntu 16.04, due toward the end of April 2016), which will also likely be the last LTS release based on Unity 7. + +By this time next year 16.10 will be back to the experimental new features with an entirely different beast on the desktop -- Unity 8, Mir and other big changes will return next year's .10 release to the kind of playground status of the past. + +More on Unity 8 and what it means for Ubuntu in a minute. But first, Ubuntu 15.10, which might be the very last of its kind for a little while -- a stable, welcome update that doesn't require you to radically change your workflow or habits. + +## Ubuntu 15.10 + +[image="ubuntu1510-desktop.png" caption="Visually Ubuntu 15.10 looks a lot like previous releases."] + +While Ubuntu 15.10 is unlikely to win any awards for innovation there are some very useful new features in the kernel update, a couple of UI changes for Unity and plenty of application updates, all of which make it well worth the update. + +The most notable UI changes in this release are the scrollbars, which are now pulled straight from GNOME 3. Canonical has abandoned its little disappearing "handle"-style scrollbars in favor of GNOME's defaults (which have improved considerably since Ubuntu started work on its own version). The change appears to based more on [code maintenance](https://plus.google.com/+WillCooke/posts/4WnzUY2PHix) and development effort than any strong aesthetic feelings from Canonical. It would seem that writing and maintaining your own scrollbar code is more work than it's worth. The visual change is minor and solves quite a few bugs in Canonical's home-grown scrollbars, making it a win for users as well as the programmers once tasked with maintaining the old code base. + +[image="ubuntu1510-scrollbars.png" caption="The old Ubuntu-created scrollbar is on the left, the new upstream version from GNOME on the right."] + +Abandoning the homegrown scrollbars might also mean that Unity is able to integrate upstream GNOME updates faster than it has been lately. With this release most of the GNOME suite of tools that powers much of Unity have finally been updated to 3.16, though a few holdouts like GEdit remain at much older versions. + +Aside from the scrollbars, there's not a lot of visual changes to this release. Unity itself gets a slight version bump with some bug fixes and a couple new features, including a new option to drag icons out of the Dash launcher and onto your desktop. If you were really missing the ability to clutter your desktop with something other than files, well, now you can throw some application launchers in there for good measure. + +Other notable bug fixes in Unity include an annoying problem with fullscreen menu bars and the ability to access locally integrated menus -- that is, menus within the window rather than in the top bar -- on unfocussed windows. + +While those are welcome fixes, most of what's interesting in this release is not directly from Canonical. The most exiting thing in Ubuntu 15.10 is probably the updated kernel, which is now based on the upstream Linux Kernel 4.2. + +The 4.2 line brings support for for recent Radeon GPUs, as well as some new encryption options for ext4 disks. There's also support for Intel's new Broxton chips, which just might be finding their way into an Ubuntu Mobile device at some point. 15.10 also marks the first time that the new live kernel patching has been available in Ubuntu. This release also adds a new kernel for the Raspberry Pi 2. + +Linux game aficionados will be happy hear that this release ships with support for the [new Steam controller](http://arstechnica.com/gaming/2015/10/steams-living-room-hardware-blitz-gets-off-to-a-muddy-start/4/). + +Developers get some love in this release too, with updates for Python and Ubuntu Make, Ubuntu's impressive suite of developer tools. If you're looking for a quick way to get, for example, a basic Android development environment set up, you'd be hard pressed to beat Ubuntu Make's simple `umake android` command. + +Anyone doing tech support from an Ubuntu machine will be happy to hear that Virtualbox has been updated with the latest version, which offers guest additions for Windows 10. The rest of Ubuntu's standard application suite has been updated as well, including the latest version of Firefox, Thunderbird, Chromium and more. Of particular note is LibreOffice, which has been upgraded to version 5, a major update for LibreOffice users. + +Ubuntu 15.10 has been rock solid in my testing. That said, I have had some trouble installing 15.10 via Chrubuntu on a new Dell 13 Chromebook, primarily related to trackpad drivers. Chrubuntu is a bit of a hack though, it's probably not fair to hold it against Ubuntu. Otherwise 15.10 has been very stable and wonderful to use on all the devices I've tested it on -- especially my old Eeepc where Ubuntu offers something that gets very little press -- UI scaling. Typically HiDPI screens get all the attention, and indeed Unity looks great in high res, but Ubuntu also has some great scaling in the opposite direction. Using the slider under Settings >> displays it's possible to downsize the entire UI, which gains you some precious real estate on smaller screens. It doesn't work everywhere -- Firefox is my most-used exception -- but it does make it easy to reclaim a few pixels on small screens. + +## Ubuntu 15.10 Flavors + +When most people refer to Ubuntu they mean the Unity desktop version, but there are half a dozen other official Ubuntu "flavors" using just about every popular desktop available for Linux. + +The release of Wily Werewolf brings updates for all of them, but perhaps none as big or impressive as Kubuntu 15.10. Kubuntu has always been one of the nicer KDE-based distros, but this release is particularly impressive. With Kubuntu 15.04 earlier this year, Kubuntu made the leap to Plasma 5, the next generation of KDE, but things were rough around the edges in my experience. Kubuntu 15.10 adds an impressive list of bug fixes and some added UI polish that make it one of the best KDE desktops available right now (the other standout being openSUSE Leap). This update features Plasma 5.4 and KDE Applications 15.08, which means the latest set of stock KDE apps and underlying tools you can get in a KDE distro. + +[image="kubuntu1510-desktop.png" caption="Kubuntu 15.10 with the new Breeze KDE theme."] + +The new Breeze desktop with its flat, colorful, high-contrast look is what KDE refers to as a modernized interface, with "reduced visual clutter throughout the workspace." For more details on what's new in Plasma 5, see Ars' [earlier review](http://arstechnica.com/information-technology/2014/08/17/kde-plasma-5-for-those-linux-users-undecided-on-the-kernels-future/). + +Unfortunately Kubuntu 15.10 comes along with news that the lead developer of Kubuntu is [leaving the project](https://kubuntu.org/news/jonathan-riddell-stands-down-as-release-manager-of-kubuntu/). The good news is that he'll still be actively involved in KDE, but the bad news is he made some troubling accusations about Canonical's misuse of donations as the reason for his departure. Canonical has reportedly launched an internal audit to figure out what, if anything, went wrong. + +The other notable update among the various Ubuntu flavors is an Ubuntu MATE release intended for the Raspberry Pi 2. The lightweight MATE desktop is a natural fit for the Pi and the new tailored release makes it much easier to get it installed and up and running on your Raspberry Pi 2. + +## Unity 8 + +Despite a healthy list of new features in Unity and quite a bit of change in some of the other flavors, many, including me, feel a certain sense of disappointment with 15.10. + +While there's something to be said for solid updates that don't rock the boat and let you keep getting work done, that's really what LTS releases were designed for. If you prize stability, stick with 14.04 (or use Debian stable). It would be nice to see Ubuntu's x.10 releases return to something a bit edgier and more experimental. + +That said, you actually can get something very experimental in this release, something so experimental in fact that it isn't quite ready for even a .10 release, you'll need to install it yourself -- Ubuntu running Unity 8. + +Yes, the very thing that has made Ubuntu a tad boring lately -- as all development effort has been focused on Ubuntu Mobile and the new Unity 8 desktop -- is actually [relatively easy to install](https://wiki.ubuntu.com/Unity8inLXC). It's still very buggy though, which is why it's available as an LXC container, which helps keep it fully isolated from your production machine. + +[image="ubuntu1510-unity-8.png" caption="Unity 8 as a log in option. This is likely the approach Canonical will take at least for the first few releases -- Unity 8 as a separate log in option."] + +I took it for a spin and, well, here's the thing about Unity 8: it's buggy and unstable, but it's getting really close. It's possible to experience what Canonical has in mind and it actually looks pretty great. + +The real exciting part of Unity 8 though isn't on the desktop, but on Ubuntu Mobile and Canonical's vision of "convergence". Convergence, for Canonical, means the mobile device becomes, which the addition of a larger screen monitor, a full desktop PC. To make this possible Canonical has developed Unity 8, which will bring the same underlying code base to both the desktop and mobile versions of the OS. + +The most impressive Unity 8 demo I've seen comes from Canonical engineers, who have posted a couple of [video demos of GIMP](https://plus.google.com/+MichaelHall119/posts/HBRyD8npeJk) running on an Ubuntu Mobile device. + +[Note to eds, I can't figure out how to embed that video...] + +The point isn't that GIMP is on your phone, that's more a novelty since the interface would be unusably small and, in the end, pointless beyond the "hey look at that" factor. The point is that you plug your phone into a monitor and all the sudden you have the full power of GIMP running on a device that fits in your pocket (and reverts to a mobile OS when you unplug it from the monitor). It sounds good and now, for the first time, it actually looks believably good. + +What you can see in the desktop version is the opposite portion of Canonical's convergence, mobile applications scaling up to run on the desktop device, along with some new visual splashes like the 3D app switcher and flatter visual look showcased in the video below. + +https://www.youtube.com/watch?v=kiw1XDVopjc + +It won't be for everyone, but if you're underwhelmed by iOS and Android's attempts to provide a desktop-quality experience with the applications you already use, Ubuntu Mobile is looking like it might finally deliver the goods. + +Ubuntu Mobile is also the reason you have boring .10 releases like Wily Werewolf. Canonical is getting its ducks in a row for Unity 8. There will be a day soon when the minor, perhaps unremarkable releases like 15.10 are a thing of long lost memories. There will no doubt be growing pains involved with the transition to Unity 8. + +If you want a desktop that's reliable, solid, but also pushing things forward, which is to say if you want the experience Unity has been providing for the last three, perhaps even four releases, then you will likely want to get the 16.04 LTS release coming next April. It will likely be the last Unity 7 release. + +If you want to live on the edge, Unity 8 will likely be, if not the default, at least only a login screen away come this time next year. In the mean time enjoy your quiet days of Ubuntu 15.10. diff --git a/ubuntu1510.html b/ubuntu1510.html deleted file mode 100644 index bd6311d..0000000 --- a/ubuntu1510.html +++ /dev/null @@ -1,56 +0,0 @@ -

Canonical recently released Ubuntu 15.10, nicknamed Wily Werewolf.

-

In the past the Autumn releases of Ubuntu Linux have often been more experimental affairs and warranted some caution when updating. They weren't quite update-at-your-own risk rough, but they were often packed full of new features that were not fully baked.

-

Whereas Spring .04 releases tended to be stable (and every two years packaged as Long Term Support releases), Autumn was a time to experiment.

-

For example, the now shuttered Ubuntu One first debuted in 9.10. The Unity desktop became a default in 11.10 and the controversial Amazon search results in the Unity Dash made their debut in 12.10.

-

Unfortunately -- or fortunately, depending on how you feel about desktop experiments -- that's not a case with Wily Werewolf.

-

There are new features worth updating for in this release, but on the whole this is Canonical refining what it has already created, getting ready for the next LTS release (Ubuntu 16.04, due toward the end of April 2016), which will also likely be the last LTS release based on Unity 7.

-

By this time next year 16.10 will be back to the experimental new features with an entirely different beast on the desktop -- Unity 8, Mir and other big changes will return next year's .10 release to the kind of playground status of the past.

-

More on Unity 8 and what it means for Ubuntu in a minute. But first, Ubuntu 15.10, which might be the very last of its kind for a little while -- a stable, welcome update that doesn't require you to radically change your workflow or habits.

-

Ubuntu 15.10

- -[image="ubuntu1510-desktop.png" caption="Visually Ubuntu 15.10 looks a lot like previous releases."] - -

While Ubuntu 15.10 is unlikely to win any awards for innovation there are some very useful new features in the kernel update, a couple of UI changes for Unity and plenty of application updates, all of which make it well worth the update.

-

The most notable UI changes in this release are the scrollbars, which are now pulled straight from GNOME 3. Canonical has abandoned its little disappearing "handle"-style scrollbars in favor of GNOME's defaults (which have improved considerably since Ubuntu started work on its own version). The change appears to based more on code maintenance and development effort than any strong aesthetic feelings from Canonical. It would seem that writing and maintaining your own scrollbar code is more work than it's worth. The visual change is minor and solves quite a few bugs in Canonical's home-grown scrollbars, making it a win for users as well as the programmers once tasked with maintaining the old code base.

- -[image="ubuntu1510-scrollbars.png" caption="The old Ubuntu-created scrollbar is on the left, the new upstream version from GNOME on the right."] - -

Abandoning the homegrown scrollbars might also mean that Unity is able to integrate upstream GNOME updates faster than it has been lately. With this release most of the GNOME suite of tools that powers much of Unity have finally been updated to 3.16, though a few holdouts like GEdit remain at much older versions.

-

Aside from the scrollbars, there's not a lot of visual changes to this release. Unity itself gets a slight version bump with some bug fixes and a couple new features, including a new option to drag icons out of the Dash launcher and onto your desktop. If you were really missing the ability to clutter your desktop with something other than files, well, now you can throw some application launchers in there for good measure.

-

Other notable bug fixes in Unity include an annoying problem with fullscreen menu bars and the ability to access locally integrated menus -- that is, menus within the window rather than in the top bar -- on unfocussed windows.

-

While those are welcome fixes, most of what's interesting in this release is not directly from Canonical. The most exiting thing in Ubuntu 15.10 is probably the updated kernel, which is now based on the upstream Linux Kernel 4.2.

-

The 4.2 line brings support for for recent Radeon GPUs, as well as some new encryption options for ext4 disks. There's also support for Intel's new Broxton chips, which just might be finding their way into an Ubuntu Mobile device at some point. 15.10 also marks the first time that the new live kernel patching has been available in Ubuntu. This release also adds a new kernel for the Raspberry Pi 2.

-

Linux game aficionados will be happy hear that this release ships with support for the new Steam controller.

-

Developers get some love in this release too, with updates for Python and Ubuntu Make, Ubuntu's impressive suite of developer tools. If you're looking for a quick way to get, for example, a basic Android development environment set up, you'd be hard pressed to beat Ubuntu Make's simple umake android command.

-

Anyone doing tech support from an Ubuntu machine will be happy to hear that Virtualbox has been updated with the latest version, which offers guest additions for Windows 10. The rest of Ubuntu's standard application suite has been updated as well, including the latest version of Firefox, Thunderbird, Chromium and more. Of particular note is LibreOffice, which has been upgraded to version 5, a major update for LibreOffice users.

-

Ubuntu 15.10 has been rock solid in my testing. That said, I have had some trouble installing 15.10 via Chrubuntu on a new Dell 13 Chromebook, primarily related to trackpad drivers. Chrubuntu is a bit of a hack though, it's probably not fair to hold it against Ubuntu. Otherwise 15.10 has been very stable and wonderful to use on all the devices I've tested it on -- especially my old Eeepc where Ubuntu offers something that gets very little press -- UI scaling. Typically HiDPI screens get all the attention, and indeed Unity looks great in high res, but Ubuntu also has some great scaling in the opposite direction. Using the slider under Settings >> displays it's possible to downsize the entire UI, which gains you some precious real estate on smaller screens. It doesn't work everywhere -- Firefox is my most-used exception -- but it does make it easy to reclaim a few pixels on small screens.

-

Ubuntu 15.10 Flavors

-

When most people refer to Ubuntu they mean the Unity desktop version, but there are half a dozen other official Ubuntu "flavors" using just about every popular desktop available for Linux.

-

The release of Wily Werewolf brings updates for all of them, but perhaps none as big or impressive as Kubuntu 15.10. Kubuntu has always been one of the nicer KDE-based distros, but this release is particularly impressive. With Kubuntu 15.04 earlier this year, Kubuntu made the leap to Plasma 5, the next generation of KDE, but things were rough around the edges in my experience. Kubuntu 15.10 adds an impressive list of bug fixes and some added UI polish that make it one of the best KDE desktops available right now (the other standout being openSUSE Leap). This update features Plasma 5.4 and KDE Applications 15.08, which means the latest set of stock KDE apps and underlying tools you can get in a KDE distro.

- -[image="kubuntu1510-desktop.png" caption="Kubuntu 15.10 with the new Breeze KDE theme."] - -

The new Breeze desktop with its flat, colorful, high-contrast look is what KDE refers to as a modernized interface, with "reduced visual clutter throughout the workspace." For more details on what's new in Plasma 5, see Ars' earlier review.

-

Unfortunately Kubuntu 15.10 comes along with news that the lead developer of Kubuntu is leaving the project. The good news is that he'll still be actively involved in KDE, but the bad news is he made some troubling accusations about Canonical's misuse of donations as the reason for his departure. Canonical has reportedly launched an internal audit to figure out what, if anything, went wrong.

-

The other notable update among the various Ubuntu flavors is an Ubuntu MATE release intended for the Raspberry Pi 2. The lightweight MATE desktop is a natural fit for the Pi and the new tailored release makes it much easier to get it installed and up and running on your Raspberry Pi 2.

-

Unity 8

-

Despite a healthy list of new features in Unity and quite a bit of change in some of the other flavors, many, including me, feel a certain sense of disappointment with 15.10.

-

While there's something to be said for solid updates that don't rock the boat and let you keep getting work done, that's really what LTS releases were designed for. If you prize stability, stick with 14.04 (or use Debian stable). It would be nice to see Ubuntu's x.10 releases return to something a bit edgier and more experimental.

-

That said, you actually can get something very experimental in this release, something so experimental in fact that it isn't quite ready for even a .10 release, you'll need to install it yourself -- Ubuntu running Unity 8.

-

Yes, the very thing that has made Ubuntu a tad boring lately -- as all development effort has been focused on Ubuntu Mobile and the new Unity 8 desktop -- is actually relatively easy to install. It's still very buggy though, which is why it's available as an LXC container, which helps keep it fully isolated from your production machine.

- -[image="ubuntu1510-unity-8.png" caption="Unity 8 as a log in option. This is likely the approach Canonical will take at least for the first few releases -- Unity 8 as a separate log in option."] - -

I took it for a spin and, well, here's the thing about Unity 8: it's buggy and unstable, but it's getting really close. It's possible to experience what Canonical has in mind and it actually looks pretty great.

-

The real exciting part of Unity 8 though isn't on the desktop, but on Ubuntu Mobile and Canonical's vision of "convergence". Convergence, for Canonical, means the mobile device becomes, which the addition of a larger screen monitor, a full desktop PC. To make this possible Canonical has developed Unity 8, which will bring the same underlying code base to both the desktop and mobile versions of the OS.

-

The most impressive Unity 8 demo I've seen comes from Canonical engineers, who have posted a couple of video demos of GIMP running on an Ubuntu Mobile device.

- -[Note to eds, I can't figure out how to embed that video...] - -

The point isn't that GIMP is on your phone, that's more a novelty since the interface would be unusably small and, in the end, pointless beyond the "hey look at that" factor. The point is that you plug your phone into a monitor and all the sudden you have the full power of GIMP running on a device that fits in your pocket (and reverts to a mobile OS when you unplug it from the monitor). It sounds good and now, for the first time, it actually looks believably good.

-

What you can see in the desktop version is the opposite portion of Canonical's convergence, mobile applications scaling up to run on the desktop device, along with some new visual splashes like the 3D app switcher and flatter visual look showcased in the video below.

-

https://www.youtube.com/watch?v=kiw1XDVopjc

-

It won't be for everyone, but if you're underwhelmed by iOS and Android's attempts to provide a desktop-quality experience with the applications you already use, Ubuntu Mobile is looking like it might finally deliver the goods.

-

Ubuntu Mobile is also the reason you have boring .10 releases like Wily Werewolf. Canonical is getting its ducks in a row for Unity 8. There will be a day soon when the minor, perhaps unremarkable releases like 15.10 are a thing of long lost memories. There will no doubt be growing pains involved with the transition to Unity 8.

-

If you want a desktop that's reliable, solid, but also pushing things forward, which is to say if you want the experience Unity has been providing for the last three, perhaps even four releases, then you will likely want to get the 16.04 LTS release coming next April. It will likely be the last Unity 7 release.

-

If you want to live on the edge, Unity 8 will likely be, if not the default, at least only a login screen away come this time next year. In the mean time enjoy your quiet days of Ubuntu 15.10.

diff --git a/ubuntu1510.txt b/ubuntu1510.txt deleted file mode 100644 index f95cd82..0000000 --- a/ubuntu1510.txt +++ /dev/null @@ -1,91 +0,0 @@ -Canonical recently released Ubuntu 15.10, nicknamed Wily Werewolf. - -In the past the Autumn releases of Ubuntu Linux have often been more experimental affairs and warranted some caution when updating. They weren't quite update-at-your-own risk rough, but they were often packed full of new features that were not fully baked. - -Whereas Spring .04 releases tended to be stable (and every two years packaged as Long Term Support releases), Autumn was a time to experiment. - -For example, the now shuttered Ubuntu One first debuted in 9.10. The Unity desktop became a default in 11.10 and the controversial Amazon search results in the Unity Dash made their debut in 12.10. - -Unfortunately -- or fortunately, depending on how you feel about desktop experiments -- that's not a case with Wily Werewolf. - -There are new features worth updating for in this release, but on the whole this is Canonical refining what it has already created, getting ready for the next LTS release (Ubuntu 16.04, due toward the end of April 2016), which will also likely be the last LTS release based on Unity 7. - -By this time next year 16.10 will be back to the experimental new features with an entirely different beast on the desktop -- Unity 8, Mir and other big changes will return next year's .10 release to the kind of playground status of the past. - -More on Unity 8 and what it means for Ubuntu in a minute. But first, Ubuntu 15.10, which might be the very last of its kind for a little while -- a stable, welcome update that doesn't require you to radically change your workflow or habits. - -## Ubuntu 15.10 - -[image="ubuntu1510-desktop.png" caption="Visually Ubuntu 15.10 looks a lot like previous releases."] - -While Ubuntu 15.10 is unlikely to win any awards for innovation there are some very useful new features in the kernel update, a couple of UI changes for Unity and plenty of application updates, all of which make it well worth the update. - -The most notable UI changes in this release are the scrollbars, which are now pulled straight from GNOME 3. Canonical has abandoned its little disappearing "handle"-style scrollbars in favor of GNOME's defaults (which have improved considerably since Ubuntu started work on its own version). The change appears to based more on [code maintenance](https://plus.google.com/+WillCooke/posts/4WnzUY2PHix) and development effort than any strong aesthetic feelings from Canonical. It would seem that writing and maintaining your own scrollbar code is more work than it's worth. The visual change is minor and solves quite a few bugs in Canonical's home-grown scrollbars, making it a win for users as well as the programmers once tasked with maintaining the old code base. - -[image="ubuntu1510-scrollbars.png" caption="The old Ubuntu-created scrollbar is on the left, the new upstream version from GNOME on the right."] - -Abandoning the homegrown scrollbars might also mean that Unity is able to integrate upstream GNOME updates faster than it has been lately. With this release most of the GNOME suite of tools that powers much of Unity have finally been updated to 3.16, though a few holdouts like GEdit remain at much older versions. - -Aside from the scrollbars, there's not a lot of visual changes to this release. Unity itself gets a slight version bump with some bug fixes and a couple new features, including a new option to drag icons out of the Dash launcher and onto your desktop. If you were really missing the ability to clutter your desktop with something other than files, well, now you can throw some application launchers in there for good measure. - -Other notable bug fixes in Unity include an annoying problem with fullscreen menu bars and the ability to access locally integrated menus -- that is, menus within the window rather than in the top bar -- on unfocussed windows. - -While those are welcome fixes, most of what's interesting in this release is not directly from Canonical. The most exiting thing in Ubuntu 15.10 is probably the updated kernel, which is now based on the upstream Linux Kernel 4.2. - -The 4.2 line brings support for for recent Radeon GPUs, as well as some new encryption options for ext4 disks. There's also support for Intel's new Broxton chips, which just might be finding their way into an Ubuntu Mobile device at some point. 15.10 also marks the first time that the new live kernel patching has been available in Ubuntu. This release also adds a new kernel for the Raspberry Pi 2. - -Linux game aficionados will be happy hear that this release ships with support for the [new Steam controller](http://arstechnica.com/gaming/2015/10/steams-living-room-hardware-blitz-gets-off-to-a-muddy-start/4/). - -Developers get some love in this release too, with updates for Python and Ubuntu Make, Ubuntu's impressive suite of developer tools. If you're looking for a quick way to get, for example, a basic Android development environment set up, you'd be hard pressed to beat Ubuntu Make's simple `umake android` command. - -Anyone doing tech support from an Ubuntu machine will be happy to hear that Virtualbox has been updated with the latest version, which offers guest additions for Windows 10. The rest of Ubuntu's standard application suite has been updated as well, including the latest version of Firefox, Thunderbird, Chromium and more. Of particular note is LibreOffice, which has been upgraded to version 5, a major update for LibreOffice users. - -Ubuntu 15.10 has been rock solid in my testing. That said, I have had some trouble installing 15.10 via Chrubuntu on a new Dell 13 Chromebook, primarily related to trackpad drivers. Chrubuntu is a bit of a hack though, it's probably not fair to hold it against Ubuntu. Otherwise 15.10 has been very stable and wonderful to use on all the devices I've tested it on -- especially my old Eeepc where Ubuntu offers something that gets very little press -- UI scaling. Typically HiDPI screens get all the attention, and indeed Unity looks great in high res, but Ubuntu also has some great scaling in the opposite direction. Using the slider under Settings >> displays it's possible to downsize the entire UI, which gains you some precious real estate on smaller screens. It doesn't work everywhere -- Firefox is my most-used exception -- but it does make it easy to reclaim a few pixels on small screens. - -## Ubuntu 15.10 Flavors - -When most people refer to Ubuntu they mean the Unity desktop version, but there are half a dozen other official Ubuntu "flavors" using just about every popular desktop available for Linux. - -The release of Wily Werewolf brings updates for all of them, but perhaps none as big or impressive as Kubuntu 15.10. Kubuntu has always been one of the nicer KDE-based distros, but this release is particularly impressive. With Kubuntu 15.04 earlier this year, Kubuntu made the leap to Plasma 5, the next generation of KDE, but things were rough around the edges in my experience. Kubuntu 15.10 adds an impressive list of bug fixes and some added UI polish that make it one of the best KDE desktops available right now (the other standout being openSUSE Leap). This update features Plasma 5.4 and KDE Applications 15.08, which means the latest set of stock KDE apps and underlying tools you can get in a KDE distro. - -[image="kubuntu1510-desktop.png" caption="Kubuntu 15.10 with the new Breeze KDE theme."] - -The new Breeze desktop with its flat, colorful, high-contrast look is what KDE refers to as a modernized interface, with "reduced visual clutter throughout the workspace." For more details on what's new in Plasma 5, see Ars' [earlier review](http://arstechnica.com/information-technology/2014/08/17/kde-plasma-5-for-those-linux-users-undecided-on-the-kernels-future/). - -Unfortunately Kubuntu 15.10 comes along with news that the lead developer of Kubuntu is [leaving the project](https://kubuntu.org/news/jonathan-riddell-stands-down-as-release-manager-of-kubuntu/). The good news is that he'll still be actively involved in KDE, but the bad news is he made some troubling accusations about Canonical's misuse of donations as the reason for his departure. Canonical has reportedly launched an internal audit to figure out what, if anything, went wrong. - -The other notable update among the various Ubuntu flavors is an Ubuntu MATE release intended for the Raspberry Pi 2. The lightweight MATE desktop is a natural fit for the Pi and the new tailored release makes it much easier to get it installed and up and running on your Raspberry Pi 2. - -## Unity 8 - -Despite a healthy list of new features in Unity and quite a bit of change in some of the other flavors, many, including me, feel a certain sense of disappointment with 15.10. - -While there's something to be said for solid updates that don't rock the boat and let you keep getting work done, that's really what LTS releases were designed for. If you prize stability, stick with 14.04 (or use Debian stable). It would be nice to see Ubuntu's x.10 releases return to something a bit edgier and more experimental. - -That said, you actually can get something very experimental in this release, something so experimental in fact that it isn't quite ready for even a .10 release, you'll need to install it yourself -- Ubuntu running Unity 8. - -Yes, the very thing that has made Ubuntu a tad boring lately -- as all development effort has been focused on Ubuntu Mobile and the new Unity 8 desktop -- is actually [relatively easy to install](https://wiki.ubuntu.com/Unity8inLXC). It's still very buggy though, which is why it's available as an LXC container, which helps keep it fully isolated from your production machine. - -[image="ubuntu1510-unity-8.png" caption="Unity 8 as a log in option. This is likely the approach Canonical will take at least for the first few releases -- Unity 8 as a separate log in option."] - -I took it for a spin and, well, here's the thing about Unity 8: it's buggy and unstable, but it's getting really close. It's possible to experience what Canonical has in mind and it actually looks pretty great. - -The real exciting part of Unity 8 though isn't on the desktop, but on Ubuntu Mobile and Canonical's vision of "convergence". Convergence, for Canonical, means the mobile device becomes, which the addition of a larger screen monitor, a full desktop PC. To make this possible Canonical has developed Unity 8, which will bring the same underlying code base to both the desktop and mobile versions of the OS. - -The most impressive Unity 8 demo I've seen comes from Canonical engineers, who have posted a couple of [video demos of GIMP](https://plus.google.com/+MichaelHall119/posts/HBRyD8npeJk) running on an Ubuntu Mobile device. - -[Note to eds, I can't figure out how to embed that video...] - -The point isn't that GIMP is on your phone, that's more a novelty since the interface would be unusably small and, in the end, pointless beyond the "hey look at that" factor. The point is that you plug your phone into a monitor and all the sudden you have the full power of GIMP running on a device that fits in your pocket (and reverts to a mobile OS when you unplug it from the monitor). It sounds good and now, for the first time, it actually looks believably good. - -What you can see in the desktop version is the opposite portion of Canonical's convergence, mobile applications scaling up to run on the desktop device, along with some new visual splashes like the 3D app switcher and flatter visual look showcased in the video below. - -https://www.youtube.com/watch?v=kiw1XDVopjc - -It won't be for everyone, but if you're underwhelmed by iOS and Android's attempts to provide a desktop-quality experience with the applications you already use, Ubuntu Mobile is looking like it might finally deliver the goods. - -Ubuntu Mobile is also the reason you have boring .10 releases like Wily Werewolf. Canonical is getting its ducks in a row for Unity 8. There will be a day soon when the minor, perhaps unremarkable releases like 15.10 are a thing of long lost memories. There will no doubt be growing pains involved with the transition to Unity 8. - -If you want a desktop that's reliable, solid, but also pushing things forward, which is to say if you want the experience Unity has been providing for the last three, perhaps even four releases, then you will likely want to get the 16.04 LTS release coming next April. It will likely be the last Unity 7 release. - -If you want to live on the edge, Unity 8 will likely be, if not the default, at least only a login screen away come this time next year. In the mean time enjoy your quiet days of Ubuntu 15.10. -- cgit v1.2.3-70-g09d2