So I spent a few hours polishing my crystal ball today, so here are some predictions for Linux on the Desktop in 2018. The advantage of course for me to publish these now is that I can then later selectively quote the ones I got right to prove my brilliance and the internet can selectively quote the ones I got wrong to prove my stupidity :)
Prediction 1: Meson becomes the defacto build system of the Linux community
Meson has been going from strength to strength this year and a lot of projects
which passed on earlier attempts to replace autotools has adopted it. I predict this
trend will continue in 2018 and that by the end of the year everyone agrees that Meson
has replaced autotools as the Linux community build system of choice. That said I am not
convinced the Linux kernel itself will adopt Meson in 2018.
Prediction 2: Rust puts itself on a clear trajectory to replace C and C++ for low level programming
Another rising start of 2017 is the programming language Rust. And while its pace of adoption
will be slower than Meson I do believe that by the time 2018 comes to a close the general opinion is
that Rust is the future of low level programming, replacing old favorites like C and C++. Major projects
like GNOME and GStreamer are already adopting Rust at a rapid pace and I believe even more projects will
join them in 2018.
Prediction 3: Apples decline as a PC vendor becomes obvious
Ever since Steve Jobs died it has become quite clear in my opinion that the emphasis
on the traditional desktop is fading from Apple. The pace of hardware refreshes seems
to be slowing and MacOS X seems to be going more and more stale. Some pundits have already
started pointing this out and I predict that in 2018 Apple will be no longer consider the
cool kid on the block for people looking for laptops, especially among the tech savvy crowd.
Hopefully a good opportunity for Linux on the desktop to assert itself more.
Prediction 4: Traditional distro packaging for desktop applications
will start fading away in favour of Flatpak
From where I am standing I think 2018 will be the breakout year for Flatpak as a replacement
for gettings your desktop applications as RPMS or debs. I predict that by the end of 2018 more or
less every Linux Desktop user will be at least running 1 flatpak on their system.
Prediction 5: Linux Graphics competitive across the board
I think 2018 will be a breakout year for Linux graphics support. I think our GPU drivers and API will be competitive with any other platform both in completeness and performance. So by the end of 2018 I predict that you will see Linux game ports by major porting houses
like Aspyr and Feral that perform just as well as their Windows counterparts. What is more I also predict that by the end of 2018 discreet graphics will be considered a solved problem on Linux.
Prediction 6: H265 will be considered a failure
I predict that by the end of 2018 H265 will be considered a failed codec effort and the era of royalty bearing media codecs will effectively start coming to and end. H264 will be considered the last successful royalty bearing codec and all new codecs coming out will
all be open source and royalty free.
I would agree with most of these, apart from 4.
GNOME-based desktop Linux desktops are now looking competitive with macOS, for me, the main disadvantage is software availability. The way that Homebrew enables you to have the latest CLI tools and services on a stable desktop is a big advantage of macOS, and there are some pieces of proprietary software that are not available for Linux. Nonetheless, I have secondary desktops running Linux, and expect my next main personal desktop to run Linux.
By design, Flatpak does not address the problem of running current CLI tools on a stable or older base OS, and it is also does not seem to be heavily promoted outside the FOSS world (to proprietary ISVs). In contrast, the snap system works for CLI tools and services, and Canonical have two full-time employees working on promoting and supporting adoption of snaps by commercial vendors. At the moment, there seems to be little public comment on the fact that snap is hard-wired to Canonical’s proprietary infrastructure.
Snap will fail for the same reason that literally every other Canonical initiative has failed — because it’s a thinly-veiled attempt to push adoption of a technology they have complete control over.
Prediction 7: you will fix your editor/blog to not insert hard line breaks inside paragraph tags.
I’m not at all convinced that Rust will be ready to replace C/C++ for libraries any time soon, at all. Is there any sign of a stable ABI on the horizon? It looks to me like it can only be used as an internal component or for applications right now, but compatibility with anything else seems severely limited.
Also, while biased, nor am I sure it’s ready or desirable to replace C++ for general development. Every new language that comes out seems to make this fanfare about itself, but no sea change has happened yet. It’s hard to gain the momentum needed, beyond the level of enthusiastic internet communities, which usually aren’t sufficient on their own. Plus, a pile of revolutionary stuff is hitting C++20 or roundabout. (Such bias!)
I tend to think that everyone ultimately would be far better served by something that isn’t C, and C++ goes quite a long way towards fitting that role, naturally, as it retains the low-level power of C while adding a lot of safety. It’s far more established, stable, and vetted than all the new stuff, too. (But I also know that it has a more polarising effect in Linux land…)
But of course, let’s see what happens. Things like this tend to occur under our noses and be far more obvious in retrospect.
The best way for Linux on the desktop to assert itself more has to be more marketing to where the users are at. Unfortunately, that means Red Hat would have to add a marketing budget for Fedora.
As I see things 2018 will be the year of broken packaging as having to maintain a pile of half baked Flatpaks, another half of Snaps, plus the usual dose of distro packages and also random stuff like AppImages… So inseatd of one we’re kinda moving towards having more than 3 problems to deal with.
And it’s kinda much to expect for both Flatpaks and discreet graphics, as Flatpaks don’t even work with current solutions, or that we don’t even have any Vulkan support for common use cases…
But well I hope that won’t be the case…
While I agree with you on #6, this is completely dependent on AV1. The must release something that is a better mix of 264 and 265. If they release something that at any encoding speed is better visual quality than 264 then your prediction will come true. What I worry about is they will release something that is slower than 264 but better visual qualify than 265. This will be great for major media but a complete failure in streaming which is why 265 has failed.
1. I really should learn meson now and start to port my projects to it.
2. Rust is interesting, but some relevant architectures are still not supported. This is a blocker for me. Also, if GCC had a Rust frontend, it would be game changer.
3. Yes, let’s hope, Linux and/or Gnome gets a handful of their users.
4. I will stay with my beloved .debs. While I like the very nice isolation of flatpack programs with portals, I dislike the idea of going away from well-defined dependencies. Programs as .deb, but with isolation and portals would be perfect for me.
5. & 6. I hope with you!
“Snap will fail for the same reason that literally every other Canonical initiative has failed — because it’s a thinly-veiled attempt to push adoption of a technology they have complete control over.”
You mean like what Red Hat has done with SystemD, PulseAudio and other beauties?
I think you are overstating the success of Meson. I hadn’t heard of it at all until last week when I wanted to write a quick patch for hexchat (and abandoned my attempt when I discovered I’d spend all the time I allocated to the task learning (yet) another build system).
I’ve been on a “holiday” from Linux on the desktop for 3-4 years, using OS X in that time (now back to Linux). So I might have missed more of a Meson critical mass. but on the other hand, for something like that to take off in F/OSS, I think it has to be popular across systems. I spent my time on OS X using brew.sh package manager and building, installing and hacking on loads of F/OSS tools and yet I never once came across Meson. I also never stopped using Linux on my non-desktop systems (NAS, VPS) which I continued to build, tweak, hack on, etc.; and likewise, never came across Mason. So IMHO there’s still a pretty important milestone to hit before I’d be prepared to predict it would actually replace autotools (a curse I certainly interacted with over and over again on OS X)