filed all published articles

9 files changed, 56 insertions, 0 deletions

diff --git a/invoices/scott_gilbertson_invoice_89.doc b/invoices/scott_gilbertson_invoice_89.doc
new file mode 100644
index 0000000..ad98a3f
--- /dev/null
+++ b/invoices/scott_gilbertson_invoice_89.doc
diff --git a/published/flatpak-snap.txt b/published/flatpak-snap.txt
new file mode 100644
index 0000000..c0224b9
--- /dev/null
+++ b/published/flatpak-snap.txt
@@ -0,0 +1,25 @@
+The world of Linux has long been divided into tribes, or distros as we called them. But what actually makes a distro? The packages it uses? The people who put those packages together? The philosophy behind the choices the people who put the packages together make? The question of what makes a distro is actually very difficult on to answer and it's about to get even more difficult.
+
+There's a change coming to the world of Linux that's potentially big enough to make us rethink what a distro is and how it works. That change is Ubuntu's Snap packages and the parallel effort dubbed Flatpaks. While these two projects differ in the details, for the purposes of this overview I'll be considering them the same thing and using the terms interchangeably.
+
+If you're familiar at all with the trends in Linux-based servers you'll likely be familiar with containers. Snaps and Flatpaks are more or less the desktop version of containers. 
+
+Whether a package is a Snap or Flatpak, there are few common things that make it significantly different than the packages your distro provides. For one thing your distro doesn't provide it. A Snap package comes straight from the developer of the application itself. Your distro may go ahead and put some Snap packages in its repositories so the installation experience may be the same, but behind the scenes the way Snaps are packaged, installed and run is very different.
+
+While there's still some polishing needed in most distro's current implementations of Snap packages that I've used, for the most part the experience from the user point of view is pretty much the same as any other software. However, installing Snaps by searching your distro's repositories is probably the least interesting way to install them. 
+
+Where Snaps and Flatpak's excel is application outside your distributions repos. Consider Firefox Developer Edition. Very few, if any, distros have it available in their repos, which means if you want to run it you'll have to install and manage it separately. There are a variety of ways to do this, Ubuntu has .deb files, Arch has the AUR, and you could always compile it yourself. The problem is that Firefox Developer Edition updates daily, or close to daily. Package maintainers -- the people creating those deb files or packaging them up for the AUR -- have to update their packages.
+
+Install Firefox Developer Edition as a <a href="https://firefox-flatpak.mojefedora.cz/">Flatpak package</a> (currently that's unofficial, maintained by Fedora and Red Hat developers) and all the sudden you're directly tied to Mozilla's updates. So far Mozilla hasn't produced an official Developer Edition Flatpak or Snap, but the company does <a href="https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/">plan to do it for Firefox itself</a> and Snaps provide a means to switch to beta/dev "channels" of a packaged app.
+
+A Snap/Flatpak version of Firefox has two huge advantages over the distro-based version of Firefox. First, updates come faster from a single source, which makes for better security and eases distro package maintainers' workload. Second, Mozilla can continue to provide updates well past the point that Ubuntu or Fedora might want to.
+
+Faster updates and eliminating the distro middleman are just two advantages of Flatpaks though. Perhaps the even bigger advantage -- especially with software like web browsers -- is the security sandboxing. Flatpaks/Snaps have much more limited access to your operating system than traditional apps. Sometimes this means not all features of an app are currently available in the Flatpak/Snap version, as is currently the case with the Snap version of LibreOffice, but as the platform matures expect those issues to be ironed out.
+
+So what's the current experience of using Flatpaks/Snaps like? I've been using the unofficial version of Firefox Developer Edition for quite some time now and am happy to report that it's much easier to update than even the AUR-based version I used previously. A single command that I put in a cron task updates my browser every night without me needing to every think about it. I always have the latest release and I don't have to do anything to get it. My only gripe is that the unofficial version requires installing a bunch of GNOME dependencies I don't otherwise need.
+
+I also run the Flatpak versions of LibreOffice, Inkscape and Blender. All three are indistinguishable from the distro versions I used previously. I don't need the features in LibreOffice that currently aren't supported in the Flatpak version so I don't have any issues there, but be sure to double check the known issues before you try it out.
+
+If they're indistinguishable from the distro versions why bother? Well since a lot of what I do with LibreOffice is open other people's documents I like the sandboxing -- which admittedly has some bugs, but is probably, at least under Wayland, more secure than a packaged version. 
+
+The other reason I've embraced Flatpaks is that I believe they're the future of Linux software distribution. While it's true that the history of computing is littered with examples of failed write-once, run-anywhere software, Flatpak and Snaps really aren't that. They do simplify developers' lives by making it easier to package apps independently of distros, but that's as far into the dangerous run-anywhere territory as they get. I don't think that distros will disappear as a result of Flatpaks/Snaps, but I do think that the division between rolling release distros like Arch and conservative distros like Debian will be less important. The kernel itself isn't going to be a Flatpak any time soon, but if you're using Arch for the reasons I am -- to get the latest versions of Userland software in a sane way -- then Flatpaks accomplish the same thing without the need to run bleeding edge kernels.
diff --git a/open-source-insider-1704.txt b/published/open-source-insider-1704.txt
index 69b9165..69b9165 100644
--- a/open-source-insider-1704.txt
+++ b/published/open-source-insider-1704.txt
diff --git a/published/ubuntu-what-now.txt b/published/ubuntu-what-now.txt
new file mode 100644
index 0000000..42e7ef3
--- /dev/null
+++ b/published/ubuntu-what-now.txt
@@ -0,0 +1,31 @@
+Canonical's recent, rather abrupt announcement that it would abandon work on its Unity 8 desktop/phone interface and the Mir display server that would have powered it, has left many Ubuntu fans scratching their heads, wondering what comes next.
+
+However, if the news caught you totally off guard it's only because you haven't been paying attention to the ups and down of the Linux world. 
+
+Unity 8 and Canonical founder Mark Shuttleworth's vision of convergence did not find a market in time for it to come to fruition. I have the advantage of having always known Shuttleworth's convergence idea would never work simply because I loved it and technology I love almost always gets the ax. 
+
+Sure, I was not a huge fan of the Unity interface, but give me a phone that turns into a desktop machine every time a monitor appears and I can easily forgive whatever aesthetic differences I might have. Alas, I will never be getting a phone like that. Neither will you. We're stuck with Android.
+
+Since the news that Unity 8 was being abandoned and the resulting staff reshuffling and layoff at Canonical did happen rather abruptly it's worth asking -- what now Canonical?
+
+If you've been around the Linux world for long you probably have a pretty good idea. Red Hat has been down this road before, as has SUSE. If you're new to this and stricken by a doomsday-like panic, relax. Canonical is probably going to be just fine. It's highly likely it will more or less abandon its desktop product to the community, but the core of Ubuntu isn't going anywhere.
+
+The difference between Canonical of the past and the Canonical that appears to be going forward is that now the bottom line matters. Which is to say that the parts of Ubuntu not making money are probably on the way out. In the Linux world that typically means the focus is going to be on the enterprise market. If the enterprise market wants an Ubuntu desktop then that will be a focus. But, spoiler alert, there's no money in desktop Linux.
+
+It makes little sense for Canonical to waste its suddenly smaller development staff on the desktop when containerization and Ubuntu on the server is where the money is. Desktop users will have Ubuntu GNOME, which has already taken over as the main distro, and there are plenty of other community-driven 'buntus to pick up the slack there.
+
+The Ubuntu GNOME distros blog post tells you everything you need to know: "There will no longer be a separate GNOME flavor of Ubuntu. The development teams from both Ubuntu GNOME and Ubuntu Desktop will be merging resources and focusing on a single combined release... We are currently liaising with the Canonical teams on how this will work out."
+
+Liaising is a French word for having a crap ton of work dumped on your head and an unspecified amount of help to go with it.
+
+Old hands in this field may recall a similar refocusing happened to Red Hat back in 2003. Red Hat dropped its desktop, then called Red Hat Linux, and started up Red Hat Enterprise Linux in the process becoming the boring enterprise-focused company it is today. But it did created the community-based Fedora to serve as what Red Hat Linux had once been so not all was lost.
+
+However, while this is the likely script for Canonical over the next few years, it is possible that it may not go this way. Canonical may stick with it's desktop and still make it a major focus of its development because while the money is in enterprise, what made Ubuntu very nearly a household name is not enterprise, but community.
+
+Something similar happened to SUSE, albeit in a very different way. When Novell bought SUSE in 2003 it wasted no time rebranding it SUSE Linux Enterprise Server. But then something happened. A couple of years later Novell announced the openSUSE Project community as a way to create a more open development process. 
+
+If there's one thing Shuttleworth and Canonical understand it's community. Ubuntu is as popular as it is in part because of the very hard work of its developers, but also in part because it listened to its community.
+
+It's also worth noting that Mir and Unity 8 are far from Ubuntu's only ideas over the last half decade. In fact Snap packages, which Canonical has assured me are very much a part of its future, may turn out to be a far better and more revolutionary idea. 
+
+The most optimistic reading of the tea leaves here is that Canonical may be cutting the fat not to become another enterprise-focused giant -- thought it already is that in many ways -- but to refocus on what it's user actually want rather than its own vision of the future of computing. 
diff --git a/ubuntu1704-desktop.jpg b/published/ubuntu1704/ubuntu1704-desktop.jpg
index 6b1654e..6b1654e 100644
--- a/ubuntu1704-desktop.jpg
+++ b/published/ubuntu1704/ubuntu1704-desktop.jpg
diff --git a/ubuntu1704-final-review.txt b/published/ubuntu1704/ubuntu1704-final-review.txt
index 45bd7d4..45bd7d4 100644
--- a/ubuntu1704-final-review.txt
+++ b/published/ubuntu1704/ubuntu1704-final-review.txt
diff --git a/ubuntu1704-nightlight.jpg b/published/ubuntu1704/ubuntu1704-nightlight.jpg
index 6ec07cf..6ec07cf 100644
--- a/ubuntu1704-nightlight.jpg
+++ b/published/ubuntu1704/ubuntu1704-nightlight.jpg
diff --git a/ubuntu1704-photos.jpg b/published/ubuntu1704/ubuntu1704-photos.jpg
index 4dbf94e..4dbf94e 100644
--- a/ubuntu1704-photos.jpg
+++ b/published/ubuntu1704/ubuntu1704-photos.jpg
diff --git a/ubuntu1704-recipes.jpg b/published/ubuntu1704/ubuntu1704-recipes.jpg
index d130d16..d130d16 100644
--- a/ubuntu1704-recipes.jpg
+++ b/published/ubuntu1704/ubuntu1704-recipes.jpg