summaryrefslogtreecommitdiff
path: root/published
diff options
context:
space:
mode:
Diffstat (limited to 'published')
-rw-r--r--published/blisk.txt31
-rw-r--r--published/ubuntu1610final.txt40
-rw-r--r--published/whyarch.txt29
3 files changed, 100 insertions, 0 deletions
diff --git a/published/blisk.txt b/published/blisk.txt
new file mode 100644
index 0000000..73eb3b8
--- /dev/null
+++ b/published/blisk.txt
@@ -0,0 +1,31 @@
+Mozilla's Firefox Developer Edition offers a fantastic array of tools for web developers. From profiling memory use to debugging WebSocket and other HTML5 APIs, Firefox DE is a very useful tool.
+
+The Developer Edition is of course based on Firefox, which isn't to every developer's liking.
+
+To say Firefox is slower than Chromium is, in my experience, sometimes true, sometimes not. The two tend to be a bit like race horses that are neck and neck, one occasionally inching ahead of the other only to be overtaken again a month later.
+
+The problem is, for those releases where Firefox is noticeably slower, it can be painful to move back to Chromium, which lacks tools I use everyday, like Responsive Design Mode or the pixel-based measurement tools.
+
+Enter Blisk. Blisk is a customized build of Chromium that bolts on nearly everything you'll find in Firefox Developer Edition and half a dozen very useful tools you won't. In fact once you try Blisk there's a good chance you'll never use anything else for web development.
+
+Blisk started life as a Windows-only application (which seems an odd choice for a browser aimed at the stereotypically Mac-obsessed web development crowd, though, if Stack Overflow's audience is representative, Blisk made the right choice) but has since added a Mac OS X version and claims that a Linux version is in the works.
+
+In addition to a suite of developer tools that's on par with Firefox DE -- which means all the standard Chromium Dev tools, plus niceties like one-click full screen screen caps -- Blisk has two things that will change your web developing life: auto-refresh on code changes and an analytics tool that will lint your code and check for cross-browser problems in the browser.
+
+Once your project is set up in Blisk, you can work in the text editor or IDE of your choice and every time you save your work any open Blisk tabs or device emulator windows will automatically refresh. You can specify which files and folders Blisk will watch if for some reason you don't want it to refresh on every change. This alone puts Blisk ahead of every other developer browser I've tested.
+
+Then there's the device emulation. Blisk ships with a variety of device emulators (like Chromium), but allows you to view them alongside your standard desktop browsing window rather than taking over the screen as Chromium does. Even better, Blisk synchronizes scrolling between the two views, so you can scroll one pane and the other follows suit. And any changes you make to your code automatically refreshes in both views.
+
+The downside to emulation of course is that you're not going to get, for example, the JavaScript behavior of an iPad, but the behavior of desktop Chrome, which sometimes means you will miss some possible bugs. Which is to say that while Chromium's emulators are a good start they're not a substitute for actual device testing.
+
+Another fantastically useful tool in Blisk is the built-in code "analytics" view, which checks your code through various syntax checkers and also looks at performance and cross-browser compatibility. It means you find bugs sooner than if you have to remember to run those tools on your own. It also makes it easier to diagnose the problem
+
+Blisk has a few features I haven't used extensively that might be handy in some workflows, including integration with a cloud-based back end that allows you to, among other things, quickly screenshot problem views and save the images to your Blisk account for sharing with team members. There's also a video recording tool if you need to demonstrate a bug in animation.
+
+Blisk is also planning to integrate with outside services that would make it possible, for instance, to screenshot a bug and file it to your team's Bugzilla tracker. The integration isn't baked in yet, but it makes Blisk worth keeping an eye on even if you don't jump on it right now.
+
+While Blisk has some very useful stuff, it's not yet available for my main development platform -- Linux. Thankfully, while Blisk does add some extras like the synced scrolling and code checking, I've found that most of its features can be replicated in Chrome proper with a few add-ons. If you're a fellow Linux user or you just don't want a dedicated development browser, there are Chromium add-ons that can do some of these things without needing to install Blisk. For instance <a href="http://re-view.emmet.io/">Emmet Re:view</a> offers a similar take on the built-in Chrome device emulator.
+
+The auto-refresh feature is harder to get. It will require a tool like <a href="https://www.browsersync.io/docs"<>Browsersync</a>, which in turn requires you first install Node.js. On the plus side Browsersync will work in any browser.
+
+Still, while you can get close to Blisk, it's unquestionably easier to just download Blisk and get to work.
diff --git a/published/ubuntu1610final.txt b/published/ubuntu1610final.txt
new file mode 100644
index 0000000..6140f38
--- /dev/null
+++ b/published/ubuntu1610final.txt
@@ -0,0 +1,40 @@
+Canonical has released Ubuntu 16.10, its second major update of the year. Ubuntu 16.10, codename "Yakkety Yak", is nowhere near the update that 16.04 LTS was earlier this year.
+
+That doesn't mean there's nothing new, in fact 16.10 does have a few new features to hold users over until the bright and shiny future of Unity 8 and Mir arrive sometime next year. Still it's very odd to have what feels like a smaller update arrive with Ubuntu's October release, which typically is the more experimental release with tons of new features being tested. This time around that's not really the case. In what's become a familiar refrain for Ubuntu, most of the work is happening with the still-not-quite-there Unity 8.
+
+Ubuntu 16.10 marks the seventh time Unity 8 has not been ready for prime time. While Unity 8 appears to be progressing -- judging by developer updates and playing with pre-release versions -- it is, at this point, in danger of joining Duke Nukem Forever on the great vaporware list in the sky. Still, take heart Ubuntu fans, just as Duke Nukem Forever did eventually see the light of day, it seems very likely that Unity 8 and Mir will in fact be released eventually. Perhaps even as early as 17.04. Also, I have a bridge for sale, if anyone is interested.
+
+What remains to be seen is how long the Ubuntu faithful will hang in there, waiting, hoping for Unity 8 and the accompanying Mir display server to get here, especially when, for the past few releases, there have been little more than bug fixes to the primary Unity 7 interface. On one hand Unity 7 works just fine and it's entirely possible that a year from now Unity 8 bugs will lead to a great wailing for a return to the stability of Unity 7. Still, when you've been promised something and it keeps getting pushed back you eventually start to feel like a kid who's been told once again that Christmas has been postponed.
+
+Unity 8 and Mir form two parts of what might loosely be called the future of Ubuntu. While two-thirds of the future may be still too deep in development to be usable, the other third is here, and has seen some real improvements in this release -- Snap applications.
+
+Ubuntu's Snap applications are self contained applications. That is, they package all their dependencies within a container, which means you can easily install applications that would otherwise have conflicting dependencies. For example, if the version of Gimp you wanted to install needs libjpeg version 1.0 but your existing install of Darktable needs libjpeg version 1.1, you have a problem that's not easy to solve. Unless of course both are Snaps, in which case each would have the needed version of libjpeg available in its container.
+
+Snap applications solve quite a few other problems and may even offer better security as well, but eliminating dependency conflicts is the biggest win for end users. For Ubuntu in particular Snaps represent a way around the problem of shipping very out of date GNOME packages. Snaps make it simple to keep the core GNOME packages wherever the Ubuntu devs need them, while allowing users to install more up-to-date version of their favorite 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.
+
+Ubuntu 16.10 improves the Snap installation process by making Snap packages available alongside everything else in the GNOME Software app, er, sorry, the Ubuntu Software app. There's still no easy way to search for Snap versions of apps specifically, but there are now screenshots available for Snap apps, something that was missing from the first release that arrived in 16.04. To find Snap apps you can search for "snap" and you'll get a partial list, but you'll still get far better results searching from the command line with the "snap find myapp" command.
+
+As for the experience of Snap applications themselves, well, it still very much depends on the application in question. LibreOffice, one of the bigger applications available as a Snap, is generally just as stable as its traditionally packaged counterpart, though thanks to the sandboxing of Snap apps, some features are missing (because they would be a security risk in the world of Snaps). Other applications I tried, like Krita, seemed to work just fine (though there was a warning about the Snap version not working with proprietary NVidia drivers).
+
+Like Unity 8 and Mir, Snaps are still a work in progress. The difference is that you can actually use Snaps today and there are real benefits to be had -- like avoiding dependency conflicts.
+
+It's also worth noting that Ubuntu has continued to work on its clone of the GNOME Software app and this release is, thankfully, much faster than what shipped with 16.04. The Software app also now handles stuff well outside the traditional software wheelhouse, like CLI apps, fonts and other system tools. I would call this a dubious "improvement". Fonts are certainly welcome, but does anyone really install CLI tools using a GUI? And many of the system tools feel like clutter when they show up in search results. The Software app's search results are also still a mixed bag, searching for "vi" returned no results at all. Searching for "vim" returned a dozen.
+
+
+Another noticeable GNOME upgrade in this release is the Nautilus file browser. Ubuntu 16.04 shipped with the new very out of date Nautilus 3.14. Ubuntu 16.10, on the other hand, has jumped all the way to Nautilus 3.20, which means Ubuntu users get some of the new tools that GNOME users have enjoyed for some time, like the file transfer progress widget in the toolbar, popover bubbles for quickly renaming files and huge improvements to the search capabilities.
+
+Ubuntu 16.10 brings the Ubuntu kernel up to version 4.8, which is good news if you've had the misfortune of trying to run Linux on a Skylake machine.
+
+It's also worth noting that this release is the first Ubuntu release to not fit on a single CD. As I noted in my review of the beta, the single CD is an arbitrary limit and there are both pluses and minuses to leaving it behind. One thing I failed to mention in the beta review though is that Unity 8 is packaged as part of the install CD now, which partly accounts for the increased size.
+
+At the end of the day the question for most users will be simply, "should I upgrade"?
+
+The answer this time around is not so simple. Most of what's new in this release will be backported to Ubuntu 16.04, which despite being an LTS release, has turned out to be a very bumpy ride for many users. But most of the standout updates -- like the Software Center and GNOME packages -- will get to 16.04 eventually, which makes 16.10 feel less essential.
+
+The updated kernel is certainly welcome and if you've had trouble with 16.04 on Skylake or had graphical problems then 16.10 is worth the upgrade. Likewise if you want to play with Unity 8, 16.10 is well worth the update.
+
+Screenshots:
+ubuntu1610-desktop.jpg Unity 7.5, looking about the same, save the new wallpaper.
+ubuntu1610-software.jpg The Ubuntu Software application is now much snappier.
+ubuntu1610-software-snap.jpg The process of installing a Snap application via the Software app has been greatly improved.
+ubuntu1610-nautilus.jpg Ubuntu users finally get the Nautilus improvements that arrived with GNOME 3.20
diff --git a/published/whyarch.txt b/published/whyarch.txt
new file mode 100644
index 0000000..6b6f01c
--- /dev/null
+++ b/published/whyarch.txt
@@ -0,0 +1,29 @@
+Dig through the annals of Linux journalism and you'll find a surprising amount of coverage of some pretty obscure distros. Flashy new distros like Elementary OS and Solus garner attention for their slick interfaces, and anything shipping with a MATE desktop gets coverage by simple virtue of using MATE.
+
+Thanks to television shows like Mr Robot I fully expect coverage of even Kali Linux to be on the uptick soon.
+
+In all that coverage though there's one very widely used distro that's almost totally ignored -- Arch Linux.
+
+Arch gets very little coverage for a several reasons, not the least of which is that it's somewhat difficult to install and requires that you feel comfortable with the command line to get it working. Worse, from the point of view of anyone trying to appeal to mainstream users, that difficulty is by design -- nothing keeps the noobs out like a daunting install process.
+
+It's a shame though because once the installation is complete, Arch is actually, in my experience anyway, far easier to use than any other Linux distro I've tried.
+
+But yes, installation is a pain. Hand partitioning, hand mounting and generating your own fstab files takes more time and effort than clicking "install" and merrily heading off to do something else. But the process of installing Arch teaches you a lot. It pulls back the curtain so you can see what's behind it. In fact it makes the curtain disappear entirely. In Arch you are the person behind the curtain.
+
+In addition to its reputation for being difficult to install, Arch is justly revered for its customizability, though this is somewhat misunderstood. There is no "default" desktop in Arch. What you want installed on top of the base set of Arch packages is entirely up to you.
+
+While you can see this as infinite customizability, you can also see it as totally lacking in customization. For example, unlike say Ubuntu, there is almost no patching or customization happening in Arch. Arch developers simply pass on what upstream developers have released, end of story. For some this good, you can run "pure" GNOME for instance. But in other cases some custom patching can take care of bugs that upstream devs might not prioritize.
+
+The lack of a default set of applications and desktop system also does not make for tidy reviews, or reviews at all really since what I chose to install will be different than what you choose. I happened to choose a very minimal setup of bare Openbox, tint2 and dmenu. You might prefer the latest release of GNOME. We'd both be running Arch, but our experiences of it would be totally different. This is of course true of any distro, but most others have a default desktop at least.
+
+Still there are common elements that together can make the basis of an Arch review. There is, for example, the primary reason I switched -- Arch is a rolling release distro. This means two things. First, the latest kernels are delivered as soon as they're available and reasonably stable. This means I can test things that are difficult to test with other distros. The other big win for a rolling distro is that all updates are delivered when they're ready. Not only does this mean newer software sooner, it means there's no massive system updates that might break things.
+
+Many people feel that Arch is less stable because it's rolling, but in my experience over the last nine months I would argue the opposite.
+
+I have yet to break anything with an update. I did once have to rollback because my /boot partition wasn't mounted when I updated and changes weren't written, but that was pure user error. Bugs that do surface (like some regressions related to the trackpad on a Dell XPS laptop I was testing) are fixed and updates are available much faster than they would be with a non-rolling distro. In short, I've found Arch's rolling release updates to be far more stable than anything else I've been using along side it. The only caveat I have to add to that is read the wiki and pay close attention to what you're updating.
+
+This brings us to the main reason I suspect that Arch's appeal is limited -- you have to pay attention to what you're doing. Blindly updating Arch is risky. But it's risky with any distro; you've just been conditioned to think it's not because you have no choice.
+
+Which leads me to the other major reason I embraced Arch -- the <a href="https://wiki.archlinux.org/index.php/Arch_Linux">Arch Philosophy</a>. The part in particular that I find appealing is this bit: "[Arch] is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems."
+
+As Linux moves further into the mainstream developers seem to feel a greater need to smooth over all the rough areas -- as if mirroring the opaque user experience of proprietary software were somehow the apex of functionality. Strange though it sounds in this day and age there are many of us who actually prefer to configure things ourselves. In this sense Arch may well be the last refuge of the DIY Linux user.