Displaying items by tag: fedora
Linux-based operating systems (often called Linux Distributions, or just Distros) are quite popular among programmers and developers since their announcement in the 90s. The Linux kernel itself is designed to be flexible and open for modifications and contributions, thus it can run on any hardware. The same principle is applied to almost the whole software stack above the kernel that constitutes the Linux Distribution as a complete product. In general, it is designed from programmers for programmers and freely available to everyone.
All of the Linux-based distributions share common code – the Linux Kernel itself, but many different methods of software distribution to the end users appeared. Some of them tend to provide a stable environment while others tend to provide the very latest software available all the time.
Stable vs Rolling Distros for Development
Linux-based distributions that are focused on stability achieve it by freezing the software as much as possible. An updated version of some software will be distributed to end users only in critical situations. Most of the time those are security updates and bug fixes but for sure no new features are being added until the end of life for that release is reached. In short, if it is not broken don’t fix it.
There are Linux distributions that tend to offer the latest of everything. “Latest must be greatest” is in their genes. Usually, the term rolling distribution is used as a description for these distros. It is very common to receive an update every hour or two. Although this looks like an awesome concept, in practice it is shown to bring some sort of instability with it and in some cases, even breaking the system.
There are pros and cons in both. Stable distributions prefer safety rather than features. This is important if you are working on a product that must be running 24/7 and must be error-free. They are often used for servers, data centers, and home users. Developers choose this type of distribution when they need to provide long-term support for the product or if the developing of the product requires an extended amount of time, like 5 or more years.
For programmers, each of their programs relies on features offered by some other program. Those are called dependencies. A stable environment can guarantee that no bugs will appear overnight due to changes in some of the dependencies. In other words, if there is a bug, don’t waste time trying to find it somewhere else rather than in your own code. This saves a lot of time and frustration.
The cons of the stable environment is that most of the time they are lacking all the cool new features. Sometimes this forces developers to utilize a harder route to achieve the desired point and nothing else. But sometimes this means that end product will run slower in production due to missing optimizations in some of the dependencies, or it will be less secure due to unpatched exploits etc.
Rolling Distributions prefer and lean towards new features and bleeding-edge software as compared to stable ones. Those are preferred among programmers and developers working on continuous integration. For example, if a program is tightly coupled with many dependencies.
Being informed of every change in your dependencies forces developers to resolve minor conflicts on a daily basis. This opens an opportunity to immediately inform third parties that they are breaking your code. Sometimes it is much easier to release a fix on their side instead in your own. Asking them to undo all the patches released in the last few years because just now you are aware of having a problem with them is a no-go. Simply, they won’t accept the undo request, so everything must be fixed on your side.
Also, you have a chance to develop your product with the latest and greatest tools available at the time. This can improve the performance, reduce the cost, can introduce a new and easier way of doing things (new API) etc.
It’s worth noting that constantly throwing updates can break things. Most of the time it is about not simultaneously updating to a new release when needed. Some apps are intended to work with the exact version of another app so breaking this creates undesired behavior. In this case, both apps must be updated at the same time which is not the case in a rolling release model.
Best Linux Distros for Programming Compared
Now, to the main part, choosing the best Linux distro for you. This is an overview and comparison of the best Linux distros for programming.
Ubuntu is the most popular Linux Distribution among all of them. It is used by programmers and most of the home users too.
There is one major release every two years. This is called an LTS (Long Term Support) release. Those are stable thus receiving only bug fixes and security updates in next 5 years. As the release model prefers stability its underlying layers are mostly stable (unchanged) during this 5 years period. The latest LTS release as of writing is Ubuntu 18.04 LTS.
There is one non-LTS release every 6 months supported for a period of 9 months. Those releases are not considered as stable. Big and significant changes can occur in every release. Sometimes those releases are caring packages that break dependencies with a previous release. It is like a playground for merging software and continuously searching for incompatibilities in a desire to provide the best fit solution for the next LTS release. Developing software in this kind of unpredictable environment is not clever. But in real life, it is not so frightening. Even non-LTS releases offer a crash-prone environment. Many home users are using them as a daily driver with no issues at all. They see a benefit from having more recent software than what is available in the latest LTS release for example.
As you can see it is a mix of everything. You can have 5 years or stability, or stability for 9 months depending on what fits the best. Even mixing packages is possible but not recommended. A user of an LTS release can obtain a newer version of the same software from a more recent non-LTS release. This is handy as a one-time workaround but it is like a tempered bomb waiting to break the system. Pooling recent packages will continue until some incompatibility occurs. It is better to switch to a non-LTS version instead.
It is worth mentioning that Ubuntu is the place where developers and home users meat each other. Therefore, Ubuntu is the starting point for a company offering a product or a service on a Linux-based operating system. Here they find an environment that is stable and familiar to the developers but also many target users. In addition, it is best to develop the software in the native environment as the product or service that’s going to be deployed and used in production. Sounds like a perfect balance.
Ubuntu is one of the most popular Linux distro for servers, and most people use it as their main distro with their Cloud hosting.
Some of the companies that love Ubuntu and that are offering their products or services on Ubuntu as a first choice are: Nvidia, Google, Dell, STMicroelectronics etc. Most companies that sell Linux laptops offer Ubuntu as the first choice for a pre-installed distro.
- Nvidia is offering the CUDA toolkit natively on Ubuntu as a first choice. Only the LTS releases are officially tested and supported, thus Ubuntu is the best fit if you rely on CUDA for your project. But it is not exclusive. The CUDA toolkit is available on non-LTS releases and many other Linux-based distributions, but without support or guarantees that things will behave as expected.
- Google is the company behind Android. They offer developing Android applications on Windows, Mac OS, and Linux-based distributions. Ubuntu is their first choice. Android Studio (IDE) and all other tools are tested on LTS releases of Ubuntu before distribution to end users.
- STMicroelectronics is a company producing ARM-based CPUs for embedded devices. Developing software for their CPUs is possible on Windows, Mac OS and Linux-based distributions. They support Open STM 32 for developing a free and cross-platform IDE, System WorkBench. Again, LTS releases of Ubuntu is their first choice for a Linux Distribution.
- Dell is known for their laptops, ultra-books, PCs and monitors. Their products are mostly offered with Windows preinstalled and Ubuntu for some of them. The Dell XPS 13 Developer Edition is a small, light, fast, and beautiful, and runs an Ubuntu LTS release by default.
There are more companies that offer and use Ubuntu, but this should give you an idea of how software and development companies incorporate Ubuntu.
2. Arch Linux
Arch Linux is just the opposite of Ubuntu. It is a rolling release Linux Distribution. There are constantly new updates. Every hour or two something new arrives in your system. It is a perfect working environment for some. As we mentioned earlier this type of software distribution is best suitable for developers working on software that is highly coupled with some or many dependencies. They will receive an updated version of their dependencies with almost no delay. But this comes at a price for sure. The instability of the system offers no guarantees for the origins of the new bugs.
Also, Arch Linux is hard to install. An advanced user can do it in no more than 15 minutes, but it is almost impossible for a newcomer to succeed. It requires a lot of knowledge because there is nothing preconfigured, there is no default, everything is custom instead. A pure mechanism for distributing software and nothing more, it is up to the user to install and configure things according to their personal requirements. This is why many people use Arch Linux as a lightweight Linux distro, by installing a lightweight window manager/desktop environment, and only the essential software. As you can already see Arch Linux provides a perfectly configured environment for every developer that knows how to utilize it.
Every Arch Linux is unique thus each of them encounters unique obstacles. This is what makes it special and loved among programmers. Just by using it on daily basis you grow. There is a giant and thorough wiki page. It’s one of the best wikis you can find with very detailed and strict explanations and guides for configuring stuff and encouraging the use of what is said to be good practice. Its necessity can be seen just when you try to install it (as we mentioned earlier, it is hard if not following the wiki the first time). Reading documentation may seem like wasting time but it is an essential skill for every programmer. Just by reading good documentation developers also learn how to write good documentation.
Tinkering here and there with the operating system itself will teach you how one works so you can build your own later. It’s an important skill to have, especially if you end up working with embedded devices in your career. Every day you can read about some unexpected issues on the forum and very clever workarounds for each of them. Just being aware of what might go wrong makes a developer produce code with better quality if paying attention.
The best thing about Arch Linux is its huge repository of available software. Personally, I can’t think of something that I need that is unavailable. Although the software is there, because of the very different configurations among users, the quality of provided software can be lower than expected. It is not unusual if users need to get their hands dirty doing some minor manual intervention. It’s brilliant for improving skills but some can struggle with the maintenance at the beginning.
It’s worth to be mentioned that there are no devices that come with Arch Linux preinstalled. It is painful to do so since until the device reaches the customer, the software is out of date and performing one giant update is very likely to break the system (while constant minor updates don’t). Even if some vendors do, advanced users will find it uncomfortable and will change it anyway.
Fedora is another popular Linux Distribution among programmers. It is just in the middle between Ubuntu and Arch Linux. It is more stable than Arch Linux, but it is rolling faster than what Ubuntu does.
There is one major release every 6 months supported for 13 months. Basically, 13 months of a stable environment is just fine. Also, 6 months of delay between the next big update is fine too. No software is growing so fast so it is good even for those who want to experience and work with the latest stuff in a stable environment while still doing their integration job without issues. Excellent balance as Ubuntu does but with a smaller amount of home users.
In terms of software availability, there is no such broader range as in Ubuntu or Arch Linux. If you are looking for proprietary software the situation is even worse. There isn’t any official support for it. But if you are working with open source software instead Fedora is excellent.
The people behind Fedora embrace free and open software and do the best for it but it is a big no go for any proprietary stuff. You can’t find Java, DVD codecs, Flash Player etc. Of course, all those are available in some private repositories with weaker license policies but they are not officially supported so no guarantees for any incompatibilities or misbehavior. It is a big issue if you are working on a project that costs money or that is expected to have a big impact because you don’t want to rely on unreliable sources. You want support instead. On Ubuntu for example, companies do offer support for their proprietary software.
There are several Fedora “Spins”, which are similar to Ubuntu flavors. It’s basically Fedora with software pre-installed for a specific purpose, but the main difference is the desktop environment. We featured the Games Spin of Fedora in our Best Linux Gaming Distros list.
Do not forget that the Fedora project is founded by Red Hat Linux distribution which is targeting the enterprise sector and offer paid support for it. Fedora is like a playground but a good one. At some point, the Fedora release will become a Red Hat release. Everybody has some benefits. Big companies receive a rock solid and stable system with years-long support (from Red Hat) while casual users receive a big amount of free software and a stable environment that is more recent than Ubuntu (from Fedora).
Just like Arch Linux, there are no devices with Fedora preinstalled because of very short time between major releases. In 6 months there is no time for manufacturers to produce and sell the device.
There are hundreds of Linux distros out there, each more different than the other. Though the 3 distros we mentioned are great for developers, you may find a better fit in a different distro. For example, if you’re developing an application that’s supposed to run on a server, you may need to use a server distro like Ubuntu or CentOS. So do your research and you may find a better one for you.
Overview of The Best Tools for Programmers on Linux
Out of the box, no distro comes with IDEs and toolkits pre-installed, neither Windows nor Mac OS do, so developers have to install them manually. Only a simple text editor like gedit or nano (command line text editor) can be found preinstalled. Some popular IDEs are: Eclipse, QT Creator, NetBeans etc. but many developers dislike IDEs in general and use simpler text editors like Sublime, Atom or Vim instead.
Eclipse is the most commonly used IDE. It supports multiple programming languages like C, C++, Java etc. Its basic features can be extended by various plugins. This allows a company to develop a complete IDE for their product just by writing a small plugin and relying on Eclipse for everything else.
Until 2016, Eclipse was actively supported by Google as the recommended IDE for Android applications development. Later Google migrated to InteliJ IDE and abandoned Eclipse, but users continued developing plugins like gradile-android-eclipse and still providing easy to use Android IDE based on Eclipse.
Eclipse is the recommended IDE for CUDA development on Linux-based operating systems (Visual Studio for Windows). Nvidia is distributing a slightly customized version of Eclipse called Eclipse Nsight. For them, It is much easier to provide an IDE by reusing components, but also it is even easier for developers when they don’t have to endure the hassle of building custom toolchains even for simple “Hello World” examples.
System Workbench is an IDE for programming ARM-based CPUs. This IDE is free and built by the community but also supported and recommended by STMicroelectronic, a company that produces ARM-based CPUs. The IDE can be downloaded standalone, or by adding a plugin on top of existing Eclipse installation.
The latest stable version of Eclipse is 4.7, named Oxygen. As Arch Linux tends to have the latest of everything, version 4.7 is available in the repositories. On Ubuntu 16.04, which is latest stable release at the moment. version 3.18 of Eclipse is available while Fedora offers version 4.7 just like Arch Linux.
QT Creator is another very popular IDE. It is developed by the QT Company as an IDE for the QT framework. Although targeting a single C++ framework, because the nature of the language it is commonly used for developing non-QT applications with plain C or C++. It cannot be extended like Eclipse but it is much faster because it is written in C++. Also, it provides better theming options than Eclipse that blends well with the native desktop environment.
On Arch Linux users can obtain the very latest version 4.6 but on Ubuntu, we are stuck with version 3.5 while on Fedora it’s version 4.5.
Netbeans is an IDE for developing in C, C++, Java, PHP, Node JS, Angular JS etc. It is most popular among PHP developers and Web developers. Also, some tend to use it for Android application development with the NBAndroid plugin. There are many other plugins that enable a better integration with various technologies like WordPress, Ruby, Ruby on rails etc. Much like Eclipse.
The latest stable version of Netbeans is 8.2 and the same is available in the Arch Linux repositories. Ubuntu users can obtain version 8.1 while Fedora users must do a manual installation by downloading Netbeans from the website and eventually manually resolving conflicts and dependency issues if any. Just a warning than officially supported software is always of a better quality.
Sublime is one of the most famous text editors available. Sublime is mature, supports extensions and has autocomplete and code highlight for almost any kind of programming. Even though it is just a text editor, its extensions can easily add every feature that is expected from a modern IDE. Those are the main selling points. Once you get familiar with it, you are going to use it for everything.
Ubuntu doesn’t ship Sublime in their repositories, but Sublime developers offer a packaged version in their private repository, just follow the instructions and obtain the very latest version available from their website. Arch Linux also doesn’t distribute it in the official repositories but it is available from the AUR (packaged from users, also unofficially). Fedora requires manual installation too, see their website for instructions.
Atom text editor is an alternative to Sublime. It is free as in freedom and it is based on Electron. Although it has the very same features set and capabilities it tends to be heavier than Sublime so some developers are simply rejecting it.
As with Sublime, Atom on Ubuntu and Fedora can be installed manually by following instructions on the website while on Arch Linux they distribute version 1.25.
Developers who are doing most of the work in a terminal use the Vim text editor, especially on servers. It is a free and extensible command line text editor. It is an improved version of the older Vi text editor. One can use Vim for developing in any programming language or toolkit. Vim is the most customizable of them all by adding additional plugins. It is the most keyboard-friendly text editor available too. Some developers find using the mouse hurting their shoulders and muscles thus being able to do anything with only a keyboard is like being blessed.
Vim behaves like a person. Stand-alone is nothing, but plugins make It evolve to anything. Many actions are just like having a conversation with the editor. For example, to delete next three words after the cursor you just type “d3w” (Delete 3 words) and done, or to move the cursor 4 rows down type “4j” and done. There are many many more similar shortcuts that allow developers to do things faster and easier compared to other text editors or IDEs.
Both Arch Linux and Fedora distribute version 8.0 of Vim, while Ubuntu version 7.6.
Introduction to the Linux Shell for Development
Beside IDEs and text editors, Linux-based operating systems are popular because of the Shell. Ba Shell, known as bash, is most commonly found preinstalled on every major Linux distribution but it’s not the only one available. There are zsh, tcsh, ksh etc. They all do the same job but with minor differences that are not part of this introduction. The thing about shells is that they are an environment for interaction with the system. Often shells are used for automating things.
Some tasks through the development lifecycle are repetitive and require time synchronization in terms of executing the next task when the previous is done. Very common in embedded development like build kernel, then waiting until it is done to start building the image, then again waiting to start the transferring the image to the device, and waiting one more time until transfer complete to boot finally boot the device.
The point is that no one wants to sit in front of the PC or sever waiting for a job to finish then manually executing the next one. It is nicer for developers if they can just write the code and let someone or something else to manage task execution in the right order. It’s about not hurting your eyes while paying attention to the execution status. A simple five-line shell script can automate all of this. In addition, the shell can even send a notification to your smartphone when all the jobs are done or if there is a crash.
Another use case when the shell is important is automating the crashes. Knowing that each build generates text output and that the output can be redirected to shell script we can automate the crash handling process. Thus, if compiling fails due to a missing header, a shell script can search the file system to find the location of the header and check if that location is included in our build. If not, then alter the content of a single file and add the path to the header. Now the shell script can simply inform the developer of the crash, what actions were taken if any and retry to compile. This is handy for long-lasting projects.
Windows vs Linux for Programmers
Nevertheless, developing on Windows requires installing more additional software. For example, for Android development, device drivers are required. Sometimes drivers might crash or cannot be installed or don’t work on recent versions of Windows (if it is an older device). But a good programmer must have many devices around and test the program on each one of them. This can complicate the setup of the working environment quite a bit.
On Linux distros, this is a very smooth process. All the drivers are already present in the Linux kernel (with just a few exceptions) so no additional installation is required beside the IDE. Just plug in a device and you are ready to go. As smooth as that.
Another use case is when developers have to obtain support for multiple products at the same time. This is fine until two products enforce the existence of software that cannot coexist. For example, version 3.1 of a given program and version 4.2 of the same program but for the other project.
On Windows, installing a newer version often requires deleting the older version. Even if the older version is not automatically deleted, environmental variables are being automatically modified so pooling wrong dependencies or pooling a dependency twice might occur.
On Linux distros, this can be resolved quite easily. Just extract one version in one folder, extract another version in another folder and you are halfway done. Second part is either change the global environment variable to point to only one path, or alter the content of the variable but with a tighter scope. Thus, the same variable will have a different property for different compilations. Isn’t this great? Not just resolving the coexistence problem, in addition, a developer can even run two compiles at the same time without issues.
Conclusion – Best Linux Distro for Programmers
In general, Linux-based operating systems offer a more than excellent environment for developers. It just takes some time to learn the cool stuff. No matter which distribution you choose you won’t regret doing it. Just pay attention to the method of software distribution. Choose what suits you best and the projects you are working on. If not sure, just choose Ubuntu, overall it is the best-balanced Linux distribution.
A snapshot of the current state of Desktop Linux at the start of 2019—with comparison charts and a roundtable Q&A with the leaders of three top Linux distributions.
I've never been able to stay in one place for long—at least in terms of which Linux distribution I call home. In my time as a self-identified "Linux Person", I've bounced around between a number of truly excellent ones. In my early days, I picked up boxed copies of S.u.S.E. (back before they made the U uppercase and dropped the dots entirely) and Red Hat Linux (before Fedora was a thing) from store shelves at various software outlets.
Side note: remember when we used to buy Operating Systems—and even most software—in actual boxes, with actual physical media and actual printed manuals? I still have big printed manuals for a few early Linux versions, which, back then, were necessary for getting just about everything working (from X11 to networking and sound). Heck, sometimes simply getting a successful boot required a few trips through those heavy manuals. Ah, those were the days.
Debian, Ubuntu, Fedora, openSUSE—I spent a good amount of time living in the biggest distributions around (and many others). All of them were fantastic. Truly stellar. Yet, each had their own quirks and peculiarities.
As I bounced from distro to distro, I developed a strong attachment to just about all of them, learning, as I went, to appreciate each for what it was. Just the same, when asked which distribution I recommend to others, my brain begins to melt down. Offering any single recommendation feels simply inadequate.
Choosing which one to call home, even if simply on a secondary PC, is a deeply personal choice.
Maybe you have an aging desktop computer with limited RAM and an older, but still absolutely functional, CPU. You're going to need something light on system resources that runs on 32-bit processors.
Or, perhaps you work with a wide variety of hardware architectures and need a single operating system that works well on all of them—and standardizing on a single Linux distribution would make it easier for you to administer and update all of them. But what options even are available?
To help make this process a bit easier, I've put together a handy set of charts and graphs to let you quickly glance and find the one that fits your needs (Figures 1 and 2).
Figure 1. Distribution Comparison Chart I
Figure 2. Distribution Comparison Chart II
But, let's be honest, knowing that a particular system meets your hardware needs (and preferences) simply is not enough. What is the community like? What's in store for the future of this new system you are investing in? Do the ideals of its leadership match up with your own?
In the interests of helping to answer those questions, I sat down with the leaders of three of the most prominent Linux distros of the day:
- Chris Lamb: Debian Project Leader
- Daniel Fore: elementary Founder
- Matthew Miller: Fedora Project Leade
Each of these systems is unique, respected and brings something truly valuable to the world.
I asked all three leaders the exact same questions—and gave each the chance to respond to each other. The topics are all over the place and designed to help show the similarities and differences between the distributions, both in terms of goals and culture.
Note that the Fedora project leader, Matthew Miller, was having an unusually busy time (both for work and personally), but he still made time to answer as many questions as he could. That, right there, is what I call dedication.
Introduce your Linux distribution (the short, elevator-pitch version—just a few sentences) and your role within it.
elementary is focused on growing the market for open-source software and chipping away at the share of our closed-source competitors. We believe in providing a great user experience for both new users and pro users, and putting a strong emphasis on security and privacy. We build elementary OS: a consumer-focused operating system for desktops and notebooks.
My role at elementary is as Founder and CEO. I work with our various teams (like design, development, web and translation teams) to put together a cohesive vision, product roadmap and ensure that we're following an ethical path to sustainable funding.
Not only does it have stellar reputation for stability and technical excellence, it has a unwavering philosophical stance on free software (i.e., it comes with no proprietary software pre-installed and the main repository is only free software). As it underpins countless derivative distributions, such as Ubuntu, et al., it is uniquely poised and able to improve the Free Software world as a whole.
The Debian Project Leader (DPL) is a curious beast. Far from being a BDFL—the DPL has no authoritative or deciding say in technical matters—the project leader is elected every year to a heady mix of figurehead, spokesperson and focus/contact point, but the DPL is also responsible for the quotidian business of keeping the project moving with respect to reducing bureaucracy and smoothing any and all roadblocks to Debian Developers' productivity.
The Fedora distribution brings all of the innovation of thousands of upstream projects and hundreds of thousands of upstream developers together into a polished operating system for users, with releases on a six-month cadence. We're a community project tied together through the shared project mission and through the "four Fs" of our foundations: Freedom, Friends, Features and First. Something like 3,000 people contribute directly to Fedora in any given year, with a core active group of around 400 people participating in any given week.
We just celebrated the 15th anniversary of our first release, but our history goes back even further than that to Red Hat Linux. I'm the Fedora Project Leader, a role funded by Red Hat—paying people to work on the project is the largest way Red Hat acts as a sponsor. It's not a dictatorial role; mostly, I collect good ideas and write short persuasive essays about them. Leadership responsibility is shared with the Fedora Council, which includes both funded roles, members selected by parts of the community and at-large elected representatives.
With introductions out of the way, let's start with this (perhaps deceptively) simple question:
How many Linux distributions should there be? And why?
As long as there are a set of users who aren't getting their needs met by existing options, there's a purpose for any number of distros to exist. Some come and some go, and many are very very niche, but that's okay. I think there's a lot of people who are obsessed with trying to have some dominant player take a total monopoly, but in every other market category, it's immediately apparent how silly that idea is. You wouldn't want a single clothing manufacturer or a single restaurant chain or a single internet provider (wink hint nudge) to have total market dominance. Diversity and choice in the marketplace is good for customers, and I think it's no different when it comes to operating systems.
[Responding to Daniel] Yes, I agree exactly. That said, creating an entirely from scratch distro is a lot of work, and a lot of it not very interesting work. If you've got something innovative at the how-we-put-the-OS-together level (like CoreOS), there's room for that, but if you're focused higher up the stack, like a new desktop environment or something else around user experience, it makes the most sense to make a derivative of one of the big community-powered distros. There's a lot of boring hard work, and it makes sense to reuse rather than carry those same rocks to the top of a slightly different hill.
In Fedora, we're aiming to make custom distro creation as easy as possible. We have "spins", which are basically mini custom distros. This is stuff like the Python Classroom Lab or Fedora Jam (which is focused on musicians). We have a framework for making those within the Fedora project—I'm all about encouraging bigger, broader sharing and collaboration in Fedora. But if you want to work outside the project—say, you really have different ideas on free and open-source vs. proprietary software—we have Fedora Remixes that let you do that.
The competing choice of distributions is often cited as a reason preventing Linux from becoming mainstream as it robs the movement of a consistent and focused marketing push.
However, philosophical objections against monopolistic behaviour granted, the diversity and freedom that this bazaar of distributions affords is, in my view, paradoxically exactly why it has succeeded.
That people are free—but more important, feel free—to create a new distribution as a means to try experimental or outlandish approaches to perceived problems is surely sufficient justification for some degree of proliferation or even duplication of effort.
In this capacity, Debian's technical excellence, flexibility and deliberate lack of a top-down direction has resulted in it becoming the base underpinning countless derivatives, clearly and evidently able to provide the ingredients to build one's "own" distribution, often without overt credit.
Matthew wrote: "if you want to work outside the project—say, you really have different ideas on free and open source vs. proprietary software—we have Fedora Remixes that let you do that."
Given that, I would be curious to learn how you protect your reputation if you encourage, or people otherwise use your infrastructure, tools and possibly even your name to create and distribute works that are antithetical to the cause of software and user freedom?
Thinking about it from a slightly different angle—how many distros would be TOO many distros?
More than the market can sustain I guess? The thing about Linux is that it powers all kinds of stuff. So even for one non-technical person, they could still end up running a handful of distros for their notebook, their router, their phone someday, IoT devices, etc. So the number of distros that could exist sustainably could easily be in the hundreds or thousands, I think.
If I may be so bold as to interpret this more widely, whilst it might look like we have "too many" distributions, I fear this might be misunderstanding the reasons why people are creating these newer offerings in the first place.
Apart from the aforementioned distros created for technical experimentation, someone spinning up their own distribution might be (subconsciously!) doing it for the delight and satisfaction in building something themselves and having their name attached to it—something entirely reasonable and justifiable IMHO.
To then read this creation through a lens of not being ideal for new users or even some silly "Linux worldwide domination" metric could therefore even be missing the point and some of the sheer delight of free software to begin with.
Besides, the "market" for distributions seems to be doing a pretty good job of correcting itself.
Okay, since you guys brought it up, let's talk about world domination.
How much of what you do (and what your teams do) is influenced by a desire to increase marketshare (either of your distribution specifically or desktop Linux in general)?
When we first started out, elementary OS was something we made for fun out of a desire to see something exist that we felt didn't yet. But as the company, and our user base, has grown, it's become more clear that our mission must be about getting open-source software in the hands of more people. As of now, our estimated userbase is somewhere in the hundreds of thousands with more than 75% of downloads coming from users of closed-source operating systems, so I think we're making good progress toward that goal. Making the company mission about reaching out to people directly has shaped the way we monetize, develop products, market and more, by ensuring we always put users' needs and experiences first.
I think it would be fair to say that "increasing market share" is not an overt nor overly explicit priority for Debian.
In our 25-year history, Debian has found that if we just continue to do good work, then good things will follow.
That is not to say that other approaches can't work or are harmful, but chasing potentially chimeric concepts such as "market share" can very easily lead to negative outcomes in the long run.
A project's user base is directly tied to its ability to have an effect in the world. If we were just doing cool stuff but no one used it, it really wouldn't matter much. And, no one really comes into working on a distro without having been a user first. So I guess to answer the question directly for me at least, it's pretty much all of it—even things that are not immediately related are about helping keep our community healthy and growing in the long term.
The three of you represent distros that are "funded" in very different ways. Fedora being sponsored (more or less) by Red Hat, elementary being its own company and Debian being, well, Debian.
I would love to hear your thoughts around funding the work that goes into building a distribution. Is there a "right" or "ideal" way to fund that work (either from an ethical perspective or a purely practical one)?
Clearly, melding "corporate interests" with the interests of a community distribution can be fraught with issues.
I am always interested to hear how other distros separate influence and power particularly in terms of increasing transparency using tools such as Councils with community representation, etc. Indeed, this question of "optics" is often highly under-appreciated; it is simply not enough to be honest, you must be seen to be honest too.
Unfortunately, whilst I would love to be able to say that Debian is by-definition free (!) of all such problems by not having a "big sister" company sitting next to it, we have a long history of conversations regarding the role of money in funding contributors.
For example, is it appropriate to fund developers to do work that might not not be done otherwise? And if it is paid for, isn't this simply a feedback loop that effectively ensures that this work will cease to within the remit of volunteers. There are no easy answers and we have no firm consensus, alas.
I'm not sure that there's a single right way, but I think we have the opinion that there are some wrong ways. The biggest questions we're always trying to ask about funding are where it's coming from and what it's incentivizing. We've taken a hard stance that advertising income is not in the interest of our users. When companies make their income from advertising, they tend to have to make compromises to display advertising content instead of the things their users actually want to see, and oftentimes are they incentivized to invade their users' privacy in order to target ads more effectively. We've also chosen to avoid big enterprise markets like server and IoT, because we believe that since companies will naturally be incentivized to work on products that turn a profit, that making that our business model would result in things like the recent Red Hat acquisition or in killing products that users love, like Ubuntu's Unity.
Instead, we focus on things like individual sales of software directly to our users, bug bounties, Patreon, etc. We believe that doing business directly with our users incentivizes the company to focus on features and products that are in the benefit of those paying customers. Whenever a discussion comes up about how elementary is funded, we always make a point to evaluate if that funding incentivizes outcomes that are ethical and in the favor of our users.
Regarding paying developers, I think elementary is a little different here. We believe that people writing open-source software should be able to make a living doing it. We owe a lot to our volunteer community, and the current product could not be possible without their hard work, but we also have to recognize that there's a significant portion of work that would never get done unless someone is being paid to do it. There are important tasks that are difficult or menial, and expecting someone to volunteer their time to them after their full work day is a big ask, especially if the people knowledgeable in these domains would have to take time away from their families or personal lives to do so. Many tasks are also just more suited to sustained work and require the dedicated attention of a single person for several weeks or months instead of some attention from multiple people over the span of years. So I think we're pretty firmly in the camp that not only is it important for some work to be paid, but the eventual goal should be that anyone writing open-source code should be able to get paid for their contributions.
Daniel wrote: "So I think we're pretty firmly in the camp that not only is it important for some work to be paid, but the eventual goal should be that anyone writing open-source code should be able to get paid."
Do you worry that you could be creating a two-tier community with this approach?
Not only in terms of hard influence (eg. if I'm paid, I'm likely to be able to simply spend longer on my approach) but moreover in terms of "soft" influence during discussions or by putting off so-called "drive-thru" contributions? Do you do anything to prevent the appearance of this?
Chris wrote: "Do you worry that you could be creating a two-tier community with this approach?"
Yeah, this is a big challenge for us. We have many people who are paid by Red Hat to work on Fedora either full time or as part of their job, and that gives a freedom to just be around a lot more, which pretty much directly translates to influence. Right now, many of the community-elected positions in Fedora leadership are filled by Red Hatters, because they're people the community knows and trusts. It takes a lot of time and effort to build up that visibility when you have a different day job. But there's some important nuances here too, because many of these Red Hatters aren't actually paid to work on Fedora at all—they're doing it just like anyone else who loves the project.
Chris wrote: "Do you worry that you could be creating a two-tier community with this approach?"
It's possible, but I'm not sure that we've measured anything to this effect. I think you might be right that employees at elementary can have more influence just as a byproduct of having more time to participate in more discussions, but I wouldn't say that volunteers' opinions are discounted in any way or that they're underrepresented when it comes to major technical decisions. I think it's more that we can direct labor after design and architecture decisions have been discussed. As an example, we recently had decided to make the switch from CMake to Meson. This was a group discussion primarily led by volunteers, but the actual implementation was then largely carried out by employees.
Daniel wrote: "Do you worry that you could be creating a two-tier community with this approach? ... It's possible, but I'm not sure that we've measured anything to this effect."
I think it might be another one of those situations where the optics in play is perhaps as important as the reality. Do you do anything to prevent the appearance of any bias?
Not sure how best to frame it hypothetically, but if I turned up to your project tomorrow and learned that some developers were paid for their work (however fairly integrated in practice), that would perhaps put me off investing my energy.
What do you see as the single biggest challenge currently facing both your specific project—and desktop Linux in general?
Third-party apps! Our operating systems are valuable to people only if they can use them to complete the tasks that they care about. Today, that increasingly means using proprietary services that tie in to closed-source and non-native apps that often have major usability and accessibility problems. Even major open-source apps like Firefox don't adhere to free desktop standards like shipping a .desktop file or take advantage of new cross-desktop metadata standards like AppStream. If we want to stay relevant for desktop users, we need to encourage the development of native open-source apps and invest in non-proprietary cloud services and social networks. The next set of industry-disrupting apps (like DropBox, Sketch, Slack, etc.) need to be open source and Linux-first.
Third-party apps/stores are perhaps the biggest challenge facing all distributions within the medium- to long-term, but whilst I would concede there are cultural issues in play here, I believe they have some element of being technical challenges or at least having some technical ameliorations.
More difficult, however, is that our current paradigms of what constitutes software freedom are becoming difficult to square with the increased usage of cloud services. In the years ahead we may need to revise our perspectives, ideas and possibly even our definitions of what constitutes free software.
There will be a time when the FLOSS community will have to cease the casual mocking of "cloud" and acknowledge the reality that it is, regardless of one's view of it, here to stay.
For desktop Linux, on the technical side, I'm worried about hardware enablement—not just the work dealing with driver compatibility and proprietary hardware, but more fundamentally, just being locked out. We've just seen Apple come out with hardware locked so Linux won't even boot—even with signed kernels. We're going to see more of that, and more tablets and tablet-keyboard combos with similar locked, proprietary operating systems.
A bigger worry I have is with bringing the next generation to open source—a lot of Fedora core contributors have been with the project since it started 15 years ago, which on the one hand is awesome, but also, we need to make sure that we're not going to end up with no new energy. When I was a kid, I got into computers through programming BASIC on an Apple ][. I could see commercial software and easily imagine myself making the same kind of thing. Even the fanciest games on offer—I could see the pixels and could use PEEK and POKE to make those beeps and boops. But now, with kids getting into computers via Fortnite or whatever, that's not something one can just sit down and make an approximation of as a middle-school kid. That's discouraging and makes a bigger hill to climb.
This is one reason I'm excited about Fedora IoT—you can use Linux and open source at a tinkerer's level to make something that actually has an effect on the world around you, and actually probably a lot better than a lot of off-the-shelf IoT stuff.
Where do you see your distribution in five years? What will be its place be in the broader Linux and computing world?
Debian naturally faces some challenges in the years ahead, but I sincerely believe that the Project remains as healthy as ever.
We are remarkably cherished and uniquely poised to improve the free software ecosystem as a whole. Moreover, our stellar reputation for technical excellence, stability and software freedom remains highly respected where losing this would surely be the beginning of the end for Debian.
Our short-term goals are mostly about growing our third-party app ecosystem and improving our platform. We're investing a lot of time into online accounts integration and working with other organizations, like GNOME, to make our libraries and tooling more compelling. Sandboxed packaging and Wayland will give us the tools to help keep our users' data private and to keep their operating system stable and secure. We're also working with OEMs to make elementary OS more shippable and to give users a way to get an open-source operating system when they buy a new computer. Part of that work is the new installer that we're collaborating with System76 to develop. Overall, I'd say that we're going to continue to make it easier to switch away from closed-source operating systems, and we're working on increasing collaborative efforts to do that.
When you go to a FOSS or Linux conference and see folks using Mac and Windows PCs, what's your reaction? Is it a good thing or a bad thing when developers of Linux software primarily use another platform?
Rushing to label this as a "good" or "bad" thing can make it easy to miss the underlying and more interesting lessons we can learn here.
Clearly, if everyone was using a Linux-based operating system, that would be a better state of affairs, but if we are overly quick to dismiss the usage of Mac systems as "bad", then we can often fail to understand why people have chosen to adopt the trade-offs of these platforms in the first place.
By not demonstrating sufficient empathy for such users as well as newcomers or those without our experience, we alienate potential users and contributors and tragically fail to communicate our true message. Basically, we can be our own worst enemy sometimes.
Within elementary, we strongly believe in dogfood, but I think when we see someone at a conference using a closed-source operating system, it's a learning opportunity. Instead of being upset about it or blaming them, we should be asking why we haven't been able to make a conversion. We need to identify if the problem is a missing product, feature, or just with outreach and then address that.
How often do you interact with the leaders of other distributions? And is that the right amount?
Whilst there are a few meta-community discussion groups around, they tend to have a wider focus, so yes, I think we could probably talk a little more, even just as a support group or a place to rant!
More seriously though, this conversation itself has been fairly insightful, and I've learned a few things that I think I "should" have known already, hinting that we could be doing a better job here.
With other distros, not too often. I think we're a bit more active with our partners, upstreams and downstreams. It's always interesting to hear about how someone else tackles a problem, so I would be interested in interacting more with others, but in a lot of cases, I think there are philosophical or technical differences that mean our solutions might not be relevant for other distros.
Is there value in the major distributions standardizing on package management systems? Should that be done? Can that be done?
I think I would prefer to see effort go toward consistent philosophical outlooks and messaging on third-party apps and related issues before I saw energy being invested into having a single package management format.
I mean, is this really the thing that is holding us all back? I would grant there is some duplication of effort, but I'm not sure it is the most egregious example and—as you suggest—it is not even really technically feasible or is at least subject to severe diminishing returns.
For users, there's a lot of value in being able to sideload cross-platform, closed-source apps that they rely on. But outside of this use case, I'm not sure that packaging is much more than an implementation detail as far as our users are concerned. I do think though that developers can benefit from having more examples and more documentation available, and the packaging formats can benefit from having a diverse set of implementations. Having something like Flatpak or Snap become as well accepted as SystemD would probably be good in the long run, but our users probably never noticed when we switched from Upstart, and they probably won't notice when we switch from Debian packages.
Big thanks to Daniel, Matthew and Chris for taking time out to answer questions and engage in this discussion with each other. Seeing the leadership of such excellent projects talking together about the things they differ on—and the things they align on completely—warms my little heart.
Debian's Unwavering Philosophical Stance on Free Software
Debian's 25th Birthday
Benevolent Dictator for Life (Wikipedia)
Debian Project Leader Elections 2017
Debian Project Leader Elections 2018
Bits from the DPL (October 2018)
Fedora's Mission and Foundations
Celebrate 15 Years of Fedora
Publish on AppCenter
I have to confess, this particular topic is a tough one to address. Why? First off, Linux is a productive operating system by design. Thanks to an incredibly reliable and stable platform, getting work done is easy. Second, to gauge effectiveness, you have to consider what type of work you need a productivity boost for. General office work? Development? School? Data mining? Human resources? You see how this question can get somewhat complicated.
That doesn’t mean, however, that some distributions aren’t able to do a better job of configuring and presenting that underlying operating system into an efficient platform for getting work done. Quite the contrary. Some distributions do a much better job of “getting out of the way,” so you don’t find yourself in a work-related hole, having to dig yourself out and catch up before the end of day. These distributions help strip away the complexity that can be found in Linux, thereby making your workflow painless.
Let’s take a look at the distros I consider to be your best bet for productivity. To help make sense of this, I’ve divided them into categories of productivity. That task itself was challenging, because everyone’s productivity varies. For the purposes of this list, however, I’ll look at:
- General Productivity: For those who just need to work efficiently on multiple tasks.
- Graphic Design: For those that work with the creation and manipulation of graphic images.
- Development: For those who use their Linux desktops for programming.
- Administration: For those who need a distribution to facilitate their system administration tasks.
- Education: For those who need a desktop distribution to make them more productive in an educational environment.
Yes, there are more categories to be had, many of which can get very niche-y, but these five should fill most of your needs.
General Productivity Ubuntu
For general productivity, you won’t get much more efficient than Ubuntu. The primary reason for choosing Ubuntu for this category is the seamless integration of apps, services, and desktop. You might be wondering why I didn’t choose Linux Mint for this category? Because Ubuntu now defaults to the GNOME desktop, it gains the added advantage of GNOME Extensions (Figure 1).