archived published articles

12 files changed, 145 insertions, 0 deletions

diff --git a/published/gnome-320-cal-edit.jpg b/published/gnome-320-cal-edit.jpg
new file mode 100644
index 0000000..54de505
--- /dev/null
+++ b/published/gnome-320-cal-edit.jpg
diff --git a/published/gnome-320-maps-edit.jpg b/published/gnome-320-maps-edit.jpg
new file mode 100644
index 0000000..1f66856
--- /dev/null
+++ b/published/gnome-320-maps-edit.jpg
diff --git a/published/gnome-320-maps-layer.jpg b/published/gnome-320-maps-layer.jpg
new file mode 100644
index 0000000..c282260
--- /dev/null
+++ b/published/gnome-320-maps-layer.jpg
diff --git a/published/gnome-320-photos-edit.jpg b/published/gnome-320-photos-edit.jpg
new file mode 100644
index 0000000..9dbdfda
--- /dev/null
+++ b/published/gnome-320-photos-edit.jpg
diff --git a/published/gnome320review.txt b/published/gnome320review.txt
new file mode 100644
index 0000000..d928006
--- /dev/null
+++ b/published/gnome320review.txt
@@ -0,0 +1,39 @@
+The Gnome Project recently released version 3.20, which offers an extensive set of new features, but unfortunately for GNOME the project's release schedule is largely out of sync with the big GNOME-base distros. Fedora 24 is still a beta, though it will feature GNOME 3.20 when it arrives later in June, but Ubuntu GNOME users will have to wait (or upgrade on their own) since the recently released Ubuntu GNOME 16.04 arrived too soon to offer 3.20.
+
+To see what the state of the GNOME world is, I took that latest version of GNOME for spin via Fedora's Rawhide release. Because Rawhide is pre-release software, I won't dive into any bugs since it's difficult to tell what's related directly to GNOME and what's related to Rawhide. That said, I did not encounter any major bugs at all, even with Rawhide.
+
+GNOME 3.20 doesn't offer a lot of new features for the GNOME Shell environment. Indeed that's been the case for the last couple of releases. While the GNOME developers add a widget here, a darker color there, most of the project's current effort has focused on developing a native suite of common apps to ship with GNOME. Applications like Gnome Software, Maps, Videos, Photos and the Nautilus file manager have received the majority of the attention in recent GNOME releases.
+
+GNOME 3.20 is no exception in this regard. While there are some minor improvements to the Shell, it's the applications that have most of the new features.
+
+GNOME Software -- which is now the basis for Ubuntu's new Software app as well -- has some nice upgrades, including support for upgrading to new major versions of the operating system. That means all you have to do to update your distro after GNOME 3.20 is installed is head to GNOME Software and select your distro upgrade. GNOME Software also now has support for user reviews, which you can see in action in the recent version of Ubuntu as well (that's actually the only place I've seen them, they're not in Fedora Rawhide's Software app just yet).
+
+GNOME Software also now supports xdg-app packages, which paves the way for more secure, sandboxed applications. Xdg-app packages work with Wayland as well and there are in fact a few already available, notably LibreOffice (though not the version you'll find in Fedora's repos).
+
+GNOME's Photos application continues to progress as well. It's no replacement for Shotwell just yet (unless your photo needs are very limited), but GNOME 3.20 sees the first photo editing features arrive. GNOME Photos can now crop and rotate photos, as well as perform rudimentary color adjustments, "enhance" (sharpen and denoise) and even apply some Instagram-inspired filters. Perhaps most notable is that any changes made using GNOME Photos are non-destructive. The original photo is preserved, always available and any changes can be undone. In a move anyone you email photos to will appreciate, Photos has a new export option to shrink your images down to a more network-friendly size.
+
+Considering this is Photo's first foray into image editing the features are actually quite nice and will serve the casual photographer well. 
+
+GNOME 3.20 also brings some new features for the already quite nicely done Maps app. Perhaps the best news for map nerds is that Maps now allows adding and editing place information from OpenStreetMap. You too can contribute to open source maps without leaving the clean, comfortable interface of Maps. Equally exciting, Maps now supports custom layers using most of the common map layer formats like GeoJSON, KML and GPX, which means you can import your own data and work with it without installing non-free, possibly snooping on you, RAM-chewing monstrosity that is Google Earth.
+
+Maps also has better place popovers with more useful information like phone numbers and web addresses if that data is available (if it's not and you know it, you can add it). There's also support for printing directions, exporting maps as PNG images and support for opening any "geo:" prefixed urls in Maps. Frankly, Maps is so good that even if you hate the rest of GNOME, it's worth grabbing the dependencies just to install Maps.
+
+It's too bad the same can't be said of GNOME's Calendar application. This release does see new support for selecting the calendar you want to save to within the "quick add" popovers, and some additional support for the tasks portion of Calendar. Unfortunately the all import sync system still hasn't been improved. If you use anything other than Google Calendar or OwnCloud you're more or less out of luck. Support for handling calendar files like .ics is reportedly coming in GNOME 3.22.
+
+There are a couple of welcome changes lower down in the GNOME stack. GNOME 3.20 adds a more fine grained set of controls for which apps can access GNOME's location services. Previously location services were either an on or off proposition. That's still what's offered in the initial GNOME setup screens, but if you dive into system settings you can control location services on a per-application basis.
+
+There's also a helpful new shortcuts window available in some GNOME apps like Nautilus, er, Files, as well as Gedit, Maps and Photos. Hit the Ctrl + ? keyboard shortcut and a window will pop up with all the keyboard shortcuts available, as well as any multitouch gestures. 
+
+Speaking of Files, nee Nautilus, I'm happy to report that no features have been removed. In fact, it looks like Files might even get a new batch rename feature in the next release, provided hell doesn't freeze over as a result. In the mean time GNOME claims the search feature is a bit speedier, though I didn't particularly notice it in everyday use.
+
+The GNOME Shell interface does gain a couple of new features in this release as well, the most noticeable of these is that media controls are now displayed in the notification area. Provided your favorite media player supports <a href="https://specifications.freedesktop.org/mpris-spec/latest/">MPRIS</a>, you'll be able to control music and videos without diving into a separate app.
+
+GNOME 3.20 also continues to add Wayland support. Provided your hardware is Wayland-compatible GNOME 3.20 should work on Wayland. 
+
+If it's been a while since you checked out GNOME, GNOME 3.20 makes a good spot to jump back in and give it a try. GNOME 3.20 is still definitely not a lightweight desktop, but provided you have newer hardware and a decent amount of RAM, it's not the sluggish nightmare that early 3.x releases were. And the application suite GNOME is developing is increasingly impressive. There's still room to grow, but some apps, like Maps are already well worth installing.
+
+screenshots
+gnome-320-cal-edit.jpg - Quick edit now allows for selecting a calendar to save your event to.
+gnome-320-maps-edit.jpg - If you have an OpenStreetMap account your can contribute to the project directly from GNOME Maps.
+gnome-320-maps-layer.jpg - GNOME Maps now handles most common GeoData formats for adding additional layers.
+gnome-320-photos-edit.jpg - Photos gains new, albeit somewhat limited, photo editing tools.
diff --git a/published/open-source-insider-01.txt b/published/open-source-insider-01.txt
new file mode 100644
index 0000000..4986154
--- /dev/null
+++ b/published/open-source-insider-01.txt
@@ -0,0 +1,27 @@
+Open source software rarely receives the kind of attention that the press lavishes on the latest hot new thing blessed by Silicon Valley venture capitalists. Yet these projects are the foundations of the web world.
+
+Without open source there would be no Slack, no Medium, no Github. Nor would there be Google, Facebook, or much of anything else. Without open source projects like Apache, Nginx, OpenSSL, OpenSSH and others (to say nothing of GNU/Linux, which does get some attention), the latest hot new thing would likely not exist. More fundamentally, the web as we know it would not exist.
+
+There is a kind of myth that has grown around this lack of attention. It's the myth of the lone developer creating powerful magic. It's a myth the open source community likes to tell itself: that open source software is created by individuals working on labors of love in their spare time. This isn't always a myth, indeed it's often surprising how little support key open source projects get considering how many companies would cease to exist without them. 
+
+All myths have an element of truth to them, however the myth of the lone developer completely ignores the fact that much of the money going into open source software is directly and indirectly (in the form of employing developers who contribute to open source projects) coming from corporations. 
+
+There's a tension in open source between individuals building projects out of love or frustration or other personal motivations and corporations pouring time and money into projects that further their bottom line.
+
+Occasionally the web gets a wake up call about this tension that exists between individual developers and corporations building fortunes atop their code. 
+
+The recent kerfuffle at NPM, which is currently the default package manager for the very popular Node.js project, nicely illustrates exactly this tension. It's a somewhat convoluted story, see The Register's <a href="http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/">early coverage</a> for full details, but the short version is that NPM bowed to legal pressure and renamed developer Azer Koçulu's kik package without asking him. This angered Koçulu so he deleted all of his code on NPM, one piece of what happened to be very widely used and, after it went missing, all the code built on it broke. 
+
+There's a lesson here for everyone -- consider your dependencies carefully -- but there's also a wakeup call here for both to developers and corporations.
+
+Developers like Koçulu got a little reminder that the NPM project is ultimately corporate-controlled. It will make decisions in its best interest, which may not be in every developer's best interest. It's a not so subtle reminder for Koçulu and other NPM developers that they serve at the pleasure of the king, in this case NPM Inc. For his part Koçulu clearly got the message, he referred to deleting his code as "<a href="https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c#.tqxmtpeko">liberating</a>" it. It's now hosted with Github. Another large corporation.
+
+On the other side of the coin NPM <a href="http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm">learned</a> that it's vulnerable to the whims of individual developers contributing (and un-contributing) code. Anyone who relies on NPM is similarly vulnerable. The NPM community quickly stepped forward and, because Koçulu's code is open source, forks were quickly put up in NPM's repositories. 
+
+There's really nothing new about this story, it happens all the time. It's part of the tension that seems inherent in software development at this stage. It's so common in fact that open source software has a simple mechanism for handling this situation -- the fork. Don't like where a project is headed or who's in charge of it? Great, go make your own. It happens with small projects like Koçulu's and big ones like the MariaDB fork of MySQL.
+
+So while the short version of the NPM story has a happy ending -- Koçulu's code is now free of NPM and NPM has forks of it available for developers who depend on it -- the longer story remains undecided. As software developer Dave Winer <a href"http://scripting.com/liveblog/users/davewiner/2016/03/24/1139.html">writes</a> in reference to replacing NPM, "we need a framework, legal and social, for projects that are not 'owned' but are just there". 
+
+In fact there are quite a few frameworks out there, albeit none that's a perfect fit. But part of the reason that the code underlying the web continues to be developed in spite of no large corporate backing is because non-profit foundations like the Apache Foundation, The Free Software Foundation, the Python Software Foundation and dozens of others sit behind the code, quietly raising money, keeping the lights on and the web humming.
+
+The NPM community and the larger Node.js community might want to think about setting up something similar. Similarly anyone hosting code on GitHub might want to think about what the transition away from GitHub will look like for their project. As Winer notes about Github, "the VCs are going to want an exit... then what happens?" What indeed. Most likely developers will get another reminder of the tension between open source developers and corporations.
diff --git a/published/standardize-instant-articles.txt b/published/standardize-instant-articles.txt
new file mode 100644
index 0000000..aef8abd
--- /dev/null
+++ b/published/standardize-instant-articles.txt
@@ -0,0 +1,37 @@
+Facebook recently opened up its Instant Articles platform to all publishers after an early test run with an anointed few publishers. Instant Articles in its current form uses a specially crafted RSS feed to reformat articles for Facebook. In a nutshell, it strips out all the crap publishers have festooned on their own sites. The result is a cleaner reading experience that also loads much faster.
+
+Google has a very similar publishing tool available known as Google AMP, though in true Google fashion AMP eschews existing standards like RSS or JSON in favor of re-inventing the wheel. Apple's News tool is designed to do much the same things, but it too uses an RSS-based approach.
+
+The current situation -- three competing formats for three competing publishing platforms -- reeks of the XKCD favorite, <a href="https://xkcd.com/927/">Standards</a>. It's also a lot of work for publishers who'd like to support all three.
+
+Aside from a few platform specific details -- all three want media like image or video wrapped in different tags -- the overall goal is the same with all of these tools. They're performance frameworks. 
+
+Somewhere along the way publishers and web developers lost sight of performance as a feature. Google and Facebook know that performance is a feature and they're both great at providing users with fast experiences, until they have to hand their users some page with 35 JavaScript libraries and images designed to look good on the 8K monitors no one actually has. 
+
+Instant Articles and AMP pages strip out all the JavaScript, kill the animations, prohibit the ubiquitous "sign up for my newsletter" overlay pop ups and deliver, well, the actual content readers come to read. And it turns out, without all the fluff no one wants, web pages load very quickly. 
+
+However, with a couple of exceptions, most notably the use of a content distribution network to cache pages, there's nothing in Google's AMP spec or Facebook's Instant Article feeds that publishers can't do for themselves. Except that they aren't doing it for themselves, so Google and Facebook have taken matters into their own hands, offering the promise of their content hungry audiences in exchange for less encumbered content.
+
+So what do publishers get out of reformatting their content to suit Google and Facebook? Nothing directly. What Instant Articles and Google AMP pages provide is verification for themselves. Google knows that an AMP page will be fast because -- assuming it's validly formated -- it can't not be fast. Ditto properly formatted Instant Article content. Performance is the whole goal of both efforts and performance is built into the requirement of the format.
+
+The downside for publishers, and ultimately the rest of us as well, is that their verification comes from using a specific set of tools, tools that Google may decide it doesn't care about in two years, tools that Facebook may alter or get rid of at any time. The verification of speed that's inherent in these formats is inexorably tied to the platforms they're a part of and ultimately only helps those platforms. Visit a slow site outside of Facebook's mobile app and it's still going to be slow and its still going to chew through your data plan with all its superfluous downloads.
+
+What if the web itself had some kind of performance policy? What if there were a standardized way of publishing a subsection of content with the express goal of providing a stripped down, fast reading experience? 
+
+That's the goal behind a proposed web standard known as Content Performance Policy.
+
+Yes, another standard to save us from a quagmire of competing quasi-standards. But none of the other solutions are actually standards. 
+
+To be fair, the Content Performance Policy proposal is a long way from being an actual standard too, but the brainchild of web developers Tim Kadlec and Yoav Weiss wants to <a href="https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/">give developers</a> a "standardized way to provide similar verification [to what AMP offers]. Something that would avoid forcing developers into the use of a specific tool and the taste of 'walled-garden' that comes with it."
+
+The <a href="http://wicg.github.io/ContentPerformancePolicy/">proposed spec</a> lists a variety of optimizations sites could use to speed up their content, including delayed image loading, throttling CPU consumption, no auto-play of audio and video content, and no external scripts among other things. 
+
+But since publishers and site owners aren't actually following those best practices, the standard helps to define an alternative set of content. Which is to say that a publisher would do with the CPP formatted page exactly what it does now with Google AMP pages, publish them alongside their regular, bloated content.
+
+In short, it standardized current best practices for creating high performance websites. Google and Facebook would still get all the benefits their homegrown solutions offer -- namely, a guarantee that the page in question will load quickly -- but so would every other content consuming party on the web.
+
+User-agents would then be able to chose which content to display. This is helpful for user-agents that will pull content into other sites. For example Facebook when it includes articles in its timeline or Google's carousel. But it would also allow, for example, mobile browsers on a limited-bandwidth connection to do the same thing. Rather than the ad blocker that iOS currently employs, users could simply check a box to "prefer faster pages" when sites make a CPP page available. In fact, from a user point of view it's hard to imagine a scenario in which the faster loading, less cluttered content that CPP pages envision would not be preferable. 
+
+It's not just user agents though. This might also end up being that carrot that convinces publishers to come back around to building faster websites. 
+
+If the vast majority of traffic is going to the optimized version of a site while the festooned version sits virtually unused perhaps publishers will finally come around. Without a standardized way to do that publishers remain at the mercy of the walled gardens.
diff --git a/published/ubuntu1604final/ubuntu1604-01.jpg b/published/ubuntu1604final/ubuntu1604-01.jpg
new file mode 100644
index 0000000..ac7288d
--- /dev/null
+++ b/published/ubuntu1604final/ubuntu1604-01.jpg
diff --git a/published/ubuntu1604final/ubuntu1604-02.jpg b/published/ubuntu1604final/ubuntu1604-02.jpg
new file mode 100644
index 0000000..b5ee5ed
--- /dev/null
+++ b/published/ubuntu1604final/ubuntu1604-02.jpg
diff --git a/published/ubuntu1604final/ubuntu1604-03.jpg b/published/ubuntu1604final/ubuntu1604-03.jpg
new file mode 100644
index 0000000..69fdcb4
--- /dev/null
+++ b/published/ubuntu1604final/ubuntu1604-03.jpg
diff --git a/published/ubuntu1604final/ubuntu1604-04.jpg b/published/ubuntu1604final/ubuntu1604-04.jpg
new file mode 100644
index 0000000..1ce6a5e
--- /dev/null
+++ b/published/ubuntu1604final/ubuntu1604-04.jpg
diff --git a/published/ubuntu1604finalreview.txt b/published/ubuntu1604finalreview.txt
new file mode 100644
index 0000000..eae0290
--- /dev/null
+++ b/published/ubuntu1604finalreview.txt
@@ -0,0 +1,42 @@
+Canonical has released Ubuntu 16.04, Xenial Xerus, as this release is nicknamed.
+
+Ubuntu 16.04 is a Long Term Support release, which means Canonical will provide support for 5 years. It also means that this is what the more cautious among us will be using for some time going forward. Fortunately for those who stick with the LTS releases this is an excellent release.
+
+There's still no Mir or Unity 8. There's not going to be any "convergence" in 16.04. 
+
+There is however plenty here to get excited about, including some new tools that have the power to change how you get your updates going forward. 
+
+Before I dive into what's new in 16.04 though, there's one big thing that <em>isn't</em> in 16.04 -- online search results. The long reviled, Stallman-branded "spyware" has at last been turned off by default. That means no more potentially socially awkward search results when all you really wanted to was to open Brasero (speaking of which, Brasero is gone too). No word yet on whether Stallman will rescind his spyware label, but at least that little nightmare is behind Ubuntu.
+
+If you're making the leap from the last LTS version, 14.04 this will be the first time you encounter systemd. Ubuntu's own effort to build an init system was abandoned several releases ago in favor of what has quickly become the only option in Linux init systems -- systemd. The transition from Upstart to systemd is not as dramatic as moving from older init systems, but there are still a number of "gotchas" to be aware of. The Ubuntu wiki has a page to <a href="https://wiki.ubuntu.com/SystemdForUpstartUsers">help Upstart users</a> get up to speed with systemd.
+
+It's a small thing, but this release is the first to allow you to move the Unity launcher to the bottom of the screen. What makes it interesting isn't so much that you can move the launcher, but that most of the work appears to have come from <a href="https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1552630">the Ubuntu Kylin developers</a>. The launcher on the bottom will be the default option for the official Chinese version of Ubuntu and it's definitely one of the most noticeable Unity features to come from outside Canonical.
+
+Whatever the case, if you've always dreamed of moving the launcher to the bottom of the screen, the Ubuntu Kylin developers have you covered. To actually move it you'll need to install the dconf-editor, or use a third-party utility like Ubuntu Tweak.
+
+Ubuntu 16.04 has finally managed to shed the Software Center, which has been little more than abandonware for some time now. Instead this release see Ubuntu adopting the GNOME Software app, which has been somewhat customized to fit into the Unity theme. The move to the upstream software center also means that Ubuntu users now have the ability to apply firmware updates directly through the software center (provided the hardware manufacturer in question makes them available).
+
+Functionally GNOME Software is not much different from Ubuntu's homegrown app, though the user interface is simpler, cleaner and most importantly more reliable. That said, it feels a bit like the old Software Center has been forcibly shoved into GNOME Software. The experience is fine for a 1.0 release, but there is clearly work to be done here. Hopefully this iteration of a software center app will not suffer the same fate as the last.
+
+Perhaps far more significant than the updated software center is 16.04's support for installing "snap" packages alongside traditional deb packages. To understand what Snap packages are and why you want them you first need to understand how packages work now. A package is simply all the code you need to install an application, including, critically, a list of package that the one you want to install depends on. Generally package managers like apt-get are pretty good at dealing with dependencies for you, but sometimes conflicts happen. You want to install something that depends on one version of another package, but another app wants a different version.
+
+Snap packages eliminate this confusion by making packages self-contained and keeping them isolated. Snap packages include all the libraries and other packages they need, so there are no outside dependencies. Ubuntu has done some "duplication" work to make sure that if two Snap packages want to install the same library it isn't installed twice, so Snaps shouldn't take up any more space.
+
+While the main draw of Snaps in, for example, server environments is the ability to pass self-contained environments from one machine to another, on the desktop there's an additional appeal -- easier, safer updates of userland software. Which is to say you can have your LTS release and get your latest and greatest application updates too. Because there's no danger of pulling upgrades that mess up the rest of your system, you can always have the latest software without having to run the bleeding edge of the actual system software. 
+
+If that sound amazing, well, it is. Unfortunately it's not quite there yet. But the underlying support is in this release, the main thing missing are the actual snaps. You won't find, for example, a Snap version of GIMP just yet. But since Ubuntu has laid the groundwork for it, you might be able to install a Snap package of GIMP before you upgrade your LTS again.
+
+Another huge new feature in this release is support for the ZFS file system. ZFS is known for its snapshot and backup capabilities, both of which would be handy on the server and desktop. So far though, Ubuntu's support is clearly aimed primarily at the server use case. ZFS is not an option within the installer. In fact you'll need to install the userland parts of ZFS yourself before you can format disks and get everything working. Still, if you're interested in trying Ubuntu atop ZFS, Canonical has a <a href="https://wiki.ubuntu.com/Kernel/Reference/ZFS">guide to using ZFS</a>.
+
+Other notable new features in this release include updates for all the usual slew of GNOME apps, though as noted above the disc-burning utility Brasero is no longer part of the default install, nor is the instant-messaging client Empathy (fear not, upgrading won't removed them, they're just not part of the install ISO anymore). Also worth noting, Ubuntu finally ships with actual ffmpeg instead of the libav fork that replaced it for a few releases.
+
+Along with Ubuntu's Unity desktop, the various Ubuntu flavors also have LTS releases available though not all of them offer five years support. The Ubuntu Mate flavor, based around the Mate desktop has put together a particularly nice release that's well worth checking out if Unity is not to your liking.
+
+Ubuntu 16.04 still doesn't have Unity, Mir or some of the other things Canonical has been working on for some time, but it is one of the best, if not the best, releases the distro has turned out in a long time. LTS releases always have to find a balance between incorporating the best of what's new with the need to support those features and apps for five years. From the more privacy-friendly defaults to the under the hood support for ZFS and Snap packages Ubuntu 16.04 is not just great today, but lays the foundations for what looks like a bright future.
+
+Screenshots:
+
+ubuntu1604-01.jpg Ubuntu 16.04, now with launchers on the bottom
+ubuntu1604-02.jpg By default Unity search no longer queries online sources.
+ubuntu1604-03.jpg The new GNOME Software-based Ubuntu Software Center.
+ubuntu1604-04.jpg Ubuntu MATE make a nice alternative if Unity isn't to your liking.