Displaying items by tag: Programmers
Think you know everything about sudo? Think again.
Everybody knows sudo, right? This tool is installed by default on most Linux systems and is available for most BSD and commercial Unix variants.
Still, after talking to hundreds of sudo users, the most common answer I received was that sudo is a tool to complicate life.
There is a root user and there is the su command, so why have yet another tool? For many, sudo was just a prefix for administrative commands.
Only a handful mentioned that when you have multiple administrators for the same system, you can use sudo logs to see who did what.
So, what is sudo? According to the sudo website:
"Sudo allows a system administrator to delegate authority by giving certain users the ability to run some commands as root or another user while providing an audit trail of the commands and their arguments."
By default, sudo comes with a simple configuration, a single rule allowing a user or a group of users to do practically anything (more on the configuration file later in this article):
%wheel ALL=(ALL) ALL
In this example, the parameters mean the following:
The first parameter defines the members of the group.
The second parameter defines the host(s) the group members can run commands on.
The third parameter defines the usernames under which the command can be executed.
The last parameter defines the applications that can be run.
So, in this example, the members of the wheel group can run all applications as all users on all hosts. Even this really permissive rule is useful because it results in logs of who did what on your machine.
Of course, once it is not just you and your best friend administering a shared box, you will start to fine-tune permissions. You can replace the items in the above configuration with lists: a list of users, a list of commands, and so on. Most likely, you will copy and paste some of these lists around in your configuration.
This situation is where aliases can come handy. Maintaining the same list in multiple places is error-prone. You define an alias once and then you can use it many times. Therefore, when you lose trust in one of your administrators, you can remove them from the alias and you are done. With multiple lists instead of aliases, it is easy to forget to remove the user from one of the lists with elevated privileges.
Enable features for a certain group of users
The sudo command comes with a huge set of defaults. Still, there are situations when you want to override some of these. This is when you use the Defaults statement in the configuration. Usually, these defaults are enforced on every user, but you can narrow the setting down to a subset of users based on host, username, and so on. Here is an example that my generation of sysadmins loves to hear about: insults. These are just some funny messages for when someone mistypes a password:
czanik@linux-mewy:~> sudo ls
[sudo] password for root:
Hold it up to the light --- not a brain in sight!
[sudo] password for root:
My pet ferret can type better than you!
[sudo] password for root:
sudo: 3 incorrect password attempts
Because not everyone is a fan of sysadmin humor, these insults are disabled by default. The following example shows how to enable this setting only for your seasoned sysadmins, who are members of the wheel group:
Defaults !insults Defaults:%wheel insults
I do not have enough fingers to count how many people thanked me for bringing these messages back.
There are, of course, more serious features in sudo as well. One of them is digest verification. You can include the digest of applications in your configuration:
peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 /usr/bin/passwd
In this case, sudo checks and compares the digest of the application to the one stored in the configuration before running the application. If they do not match, sudo refuses to run the application. While it is difficult to maintain this information in your configuration—there are no automated tools for this purpose—these digests can provide you with an additional layer of protection.
Session recording is also a lesser-known feature of sudo. After my demo, many people leave my talk with plans to implement it on their infrastructure. Why? Because with session recording, you see not just the command name, but also everything that happened in the terminal. You can see what your admins are doing even if they have shell access and logs only show that bash is started.
There is one limitation, currently. Records are stored locally, so with enough permissions, users can delete their traces. Stay tuned for upcoming features.
Starting with version 1.8, sudo changed to a modular, plugin-based architecture. With most features implemented as plugins, you can easily replace or extend the functionality of sudo by writing your own. There are both open source and commercial plugins already available for sudo.
In my talk, I demonstrated the sudo_pair plugin, which is available on GitHub. This plugin is developed in Rust, meaning that it is not so easy to compile, and it is even more difficult to distribute the results. On the other hand, the plugin provides interesting functionality, requiring a second admin to approve (or deny) running commands through sudo. Not just that, but sessions can be followed on-screen and terminated if there is suspicious activity.
In a demo I did during a recent talk at the All Things Open conference, I had the infamous:
czanik@linux-mewy:~> sudo rm -fr /
ommand displayed on the screen. Everybody was holding their breath to see whether my laptop got destroyed, but it survived.
As I already mentioned at the beginning, logging and alerting is an important part of sudo. If you do not check your sudo logs regularly, there is not much worth in using sudo. This tool alerts by email on events specified in the configuration and logs all events to syslog. Debug logs can be turned on and used to debug rules or report bugs.
Alerts Email alerts are kind of old-fashioned now, but if you use syslog-ng for collecting your log messages, your sudo log messages are automatically parsed. You can easily create custom alerts and send those to a wide variety of destinations, including Slack, Telegram, Splunk, or Elasticsearch. You can learn more about this feature from my blog on syslong-ng.com.
Configuration We talked a lot about sudo features and even saw a few lines of configuration. Now, let’s take a closer look at how sudo is configured. The configuration itself is available in /etc/sudoers, which is a simple text file. Still, it is not recommended to edit this file directly. Instead, use visudo, as this tool also does syntax checking. If you do not like vi, you can change which editor to use by pointing the EDITOR environment variable at your preferred option.
Before you start editing the sudo configuration, make sure that you know the root password. (Yes, even on Ubuntu, where root does not have a password by default.) While visudo checks the syntax, it is easy to create a syntactically correct configuration that locks you out of your system.
When you have a root password at hand in case of an emergency, you can start editing your configuration. When it comes to the sudoers file, there is one important thing to remember: This file is read from top to bottom, and the last setting wins. What this fact means for you is that you should start with generic settings and place exceptions at the end, otherwise exceptions are overridden by the generic settings.
You can find a simple sudoers file below, based on the one in CentOS, and add a few lines we discussed previously:
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
This file starts by changing a number of defaults. Then come the usual default rules: The root user and members of the wheel group have full permissions over the machine. Next, we enable insults for the wheel group, but disable them for everyone else. The last line enables session recording.
The above configuration is syntactically correct, but can you spot the logical error? Yes, there is one: Insults are disabled for everyone since the last, generic setting overrides the previous, more specific setting. Once you switch the two lines, the setup works as expected: Members of the wheel group receive funny messages, but the rest of the users do not receive them.
Once you have to maintain the sudoers file on multiple machines, you will most likely want to manage your configuration centrally. There are two major open source possibilities here. Both have their advantages and drawbacks.
You can use one of the configuration management applications that you also use to configure the rest of your infrastructure. Red Hat Ansible, Puppet, and Chef all have modules to configure sudo. The problem with this approach is that updating configurations is far from real-time. Also, users can still edit the sudoers file locally and change settings.
The sudo tool can also store its configuration in LDAP. In this case, configuration changes are real-time and users cannot mess with the sudoers file. On the other hand, this method also has limitations. For example, you cannot use aliases or use sudo when the LDAP server is unavailable.
There is a new version of sudo right around the corner. Version 1.9 will include many interesting new features. Here are the most important planned features:
A recording service to collect session recordings centrally, which offers many advantages compared to local storage:
It is more convenient to search in one place.
Recordings are available even if the sender machine is down.
Recordings cannot be deleted by someone who wants to delete their tracks.
The audit plugin does not add new features to sudoers, but instead provides an API for plugins to easily access any kind of sudo logs. This plugin enables creating custom logs from sudo events using plugins.
The approval plugin enables session approvals without using third-party plugins.
And my personal favorite: Python support for plugins, which enables you to easily extend sudo using Python code instead of coding natively in C.
Conclusion I hope this article proved to you that sudo is a lot more than just a simple prefix. There are tons of possibilities to fine-tune permissions on your system. You cannot just fine-tune permissions, but also improve security by checking digests. Session recordings enable you to check what is happening on your systems. You can also extend the functionality of sudo using plugins, either using something already available or writing your own. Finally, given the list of upcoming features you can see that even if sudo is decades old, it is a living project that is constantly evolving.
If you want to learn more about sudo, here are a few resources:
DevSecOps evolves DevOps to ensure security remains an essential part of the process.
DevOps is well-understood in the IT world by now, but it's not flawless. Imagine you have implemented all of the DevOps engineering practices in modern application delivery for a project. You've reached the end of the development pipeline—but a penetration testing team (internal or external) has detected a security flaw and come up with a report. Now you have to re-initiate all of your processes and ask developers to fix the flaw.
This is not terribly tedious in a DevOps-based software development lifecycle (SDLC) system—but it does consume time and affects the delivery schedule. If security were integrated from the start of the SDLC, you might have tracked down the glitch and eliminated it on the go. But pushing security to the end of the development pipeline, as in the above scenario, leads to a longer development lifecycle.
This is the reason for introducing DevSecOps, which consolidates the overall software delivery cycle in an automated way.
In modern DevOps methodologies, where containers are widely used by organizations to host applications, we see greater use of Kubernetes and Istio. However, these tools have their own vulnerabilities. For example, the Cloud Native Computing Foundation (CNCF) recently completed a Kubernetes security audit that identified several issues. All tools used in the DevOps pipeline need to undergo security checks while running in the pipeline, and DevSecOps pushes admins to monitor the tools' repositories for upgrades and patches.
What Is DevSecOps?
Like DevOps, DevSecOps is a mindset or a culture that developers and IT operations teams follow while developing and deploying software applications. It integrates active and automated security audits and penetration testing into agile application development.
To utilize DevSecOps, you need to:
Introduce the concept of security right from the start of the SDLC to minimize vulnerabilities in software code. Ensure everyone (including developers and IT operations teams) shares responsibility for following security practices in their tasks. Integrate security controls, tools, and processes at the start of the DevOps workflow. These will enable automated security checks at each stage of software delivery. DevOps has always been about including security—as well as quality assurance (QA), database administration, and everyone else—in the dev and release process. However, DevSecOps is an evolution of that process to ensure security is never forgotten as an essential part of the process.
Understanding the DevSecOps pipeline
There are different stages in a typical DevOps pipeline; a typical SDLC process includes phases like Plan, Code, Build, Test, Release, and Deploy. In DevSecOps, specific security checks are applied in each phase.
Plan: Execute security analysis and create a test plan to determine scenarios for where, how, and when testing will be done.
Code: Deploy linting tools and Git controls to secure passwords and API keys.
Build: While building code for execution, incorporate static application security testing (SAST) tools to track down flaws in code before deploying to production. These tools are specific to programming languages.
Test: Use dynamic application security testing (DAST) tools to test your application while in runtime. These tools can detect errors associated with user authentication, authorization, SQL injection, and API-related endpoints.
Release: Just before releasing the application, employ security analysis tools to perform thorough penetration testing and vulnerability scanning.
Deploy: After completing the above tests in runtime, send a secure build to production for final deployment.
Tools are available for every phase of the SDLC. Some are commercial products, but most are open source. In my next article, I will talk more about the tools to use in different stages of the pipeline.
DevSecOps will play a more crucial role as we continue to see an increase in the complexity of enterprise security threats built on modern IT infrastructure. However, the DevSecOps pipeline will need to improve over time, rather than simply relying on implementing all security changes simultaneously. This will eliminate the possibility of backtracking or the failure of application delivery.
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.