How to Install Software from Source Code… and Remove it Afterwards

By Sylvain Leroux

How to install software from source code

Brief: This detailed guide explains how to install a program from source code in Linux and how to remove the software installed from the source code.

One of the greatest strength of your Linux distribution is its package manager and the associated software repository. With them, you have all the necessary tools and resources to download and install a new software on your computer in a completely automated manner.

But despite all their efforts, the package maintainers cannot handle each and every use cases. Nor can they package all the software available out there. So there are still situations where you will have to compile and install a new software by yourself. As of myself, the most common reason, by far, I have to compile some software is when I need to run a very specific version. Or because I want to modify the source code or use some fancy compilation options.

If your needs belong to that latter category, there are chances you already know what you do. But for the vast majority of Linux users, compiling and installing a software from the sources for the first time might look like an initiation ceremony: somewhat frightening; but with the promise to enter a new world of possibilities and to be part of a privileged community if you overcome that.

A. Installing software from source code in Linux

And that’s exactly what we will do here. For the purpose of that article, let’s say I need to install NodeJS 8.1.1 on my system. That version exactly. A version which is not available from the Debian repository:

sh$ apt-cache madison nodejs | grep amd64
    nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages
    nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages
    nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages
    nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages
    nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Step 1: Getting the source code from GitHub

Like many open-source projects, the sources of NodeJS can be found on GitHub: https://github.com/nodejs/node

So, let’s go directly there.

The NodeJS official GitHub repository

If you’re not familiar with GitHub, git or any other version control system worth mentioning the repository contains the current source for the software, as well as a history of all the modifications made through the years to that software. Eventually up to the very first line written for that project. For the developers, keeping that history has many advantages. For us today, the main one is we will be able to get the sources from for the project as they were at any given point in time. More precisely, I will be able to get the sources as they were when the 8.1.1 version I want was released. Even if there were many modifications since then.

Choose the v8.1.1 tag in the NodeJS GitHub repository

On GitHub, you can use the “branch” button to navigate between different versions of the software. “Branch” and “tags” are somewhat related concepts in Git. Basically, the developers create “branch” and “tags” to keep track of important events in the project history, like when they start working on a new feature or when they publish a release. I will not go into the details here, all you need to know is I’m looking for the version tagged “v8.1.1”

The NodeJS GitHub repository as it was at the time the v8.1.1 tag was created

After having chosen on the “v8.1.1” tag, the page is refreshed, the most obvious change being the tag now appears as part of the URL. In addition, you will notice the file change date are different too. The source tree you are now seeing is the one that existed at the time the v8.1.1 tag was created. In some sense, you can think of a version control tool like git as a time travel machine, allowing you to go back and forth into a project history.

NodeJS GitHub repository download as a ZIP button

At this point, we can download the sources of NodeJS 8.1.1. You can’t miss the big blue button suggesting to download the ZIP archive of the project. As of myself, I will download and extract the ZIP from the command line for the sake of the explanation. But if you prefer using a GUI tool, don’t hesitate to do that instead:

wget https://github.com/nodejs/node/archive/v8.1.1.zip
unzip v8.1.1.zip
cd node-8.1.1/

Downloading the ZIP archive works great. But if you want to do it “like a pro”, I would suggest using directly the git tool to download the sources. It is not complicated at all— and it will be a nice first contact with a tool you will often encounter:

# first ensure git is installed on your system
sh$ sudo apt-get install git
# Make a shallow clone the NodeJS repository at v8.1.1
sh$ git clone --depth 1 
              --branch v8.1.1 
              https://github.com/nodejs/node
sh$ cd node/

By the way, if you have any issue, just consider that first part of this article as a general introduction. Later I have more detailed explanations for Debian- and ReadHat-based distributions in order to help you troubleshoot common issues.

Anyway, whenever you downloaded the source using git or as a ZIP archive, you should now have exactly the same source files in the current directory:

sh$ ls
android-configure  BUILDING.md            common.gypi      doc            Makefile   src
AUTHORS            CHANGELOG.md           configure        GOVERNANCE.md  node.gyp   test
benchmark          CODE_OF_CONDUCT.md     CONTRIBUTING.md  lib            node.gypi  tools
BSDmakefile        COLLABORATOR_GUIDE.md  deps             LICENSE        README.md  vcbuild.bat

Step 2: Understanding the Build System of the program

We usually talk about “compiling the sources”, but the compilation is only one of the phases required to produce a working software from its source. A build system is a set of tool and practices used to automate and articulate those different tasks in order to build entirely the software just by issuing few commands.

If the concept is simple, the reality is somewhat more complicated. Because different projects or programming language may have different requirements. Or because of the programmer’s tastes. Or the supported platforms. Or for historical reason. Or… or.. there is an almost endless list of reasons to choose or create another build system. All that to say there are many different solutions used out there.

NodeJS uses a GNU-style build system. This is a popular choice in the open source community. And once again, a good way to start your journey.

Writing and tuning a build system is a pretty complex task. But for the “end user”, GNU-style build systems resume themselves in using two tools: configure and make.

The configure file is a project-specific script that will check the destination system configuration and available feature in order to ensure the project can be built, eventually dealing with the specificities of the current platform.

An important part of a typical configure job is to build the Makefile. That is the file containing the instructions required to effectively build the project.

The make tool), on the other hand, is a POSIX tool available on any Unix-like system. It will read the project-specific Makefile and perform the required operations to build and install your program.

But, as always in the Linux world, you still have some latency to customize the build for your specific needs.

./configure --help

The configure -help command will show you all the available configuration options. Once again, this is very project-specific. And to be honest, it is sometimes required to dig into the project before fully understand the meaning of each and every configure option.

But there is at least one standard GNU Autotools option that you must know: the --prefix option. This has to do with the file system hierarchy and the place your software will be installed.

Step 3: The FHS

The Linux file system hierarchy on a typical distribution mostly comply with the Filesystem Hierarchy Standard (FHS)

That standard explains the purpose of the various directories of your system: /usr, /tmp, /var and so on.

When using the GNU Autotools— and most other build systems— the default installation location for your new software will be /usr/local. Which is a good choice as according to the FSH “The /usr/local hierarchy is for use by the system administrator when installing software locally? It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.”

The /usr/local hierarchy somehow replicates the root directory, and you will find there /usr/local/bin for the executable programs, /usr/local/lib for the libraries, /usr/local/share for architecture independent files and so on.

The only issue when using the /usr/local tree for custom software installation is the files for all your software will be mixed there. Especially, after having installed a couple of software, it will be hard to track to which file exactly of /usr/local/bin and /usr/local/lib belongs to which software. That will not cause any issue to the system though. After all, /usr/bin is just about the same mess. But that will become an issue the day you will want to remove a manually installed software.

To solve that issue, I usually prefer installing custom software in the /opt sub-tree instead. Once again, to quote the FHS:

_”/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider’s LANANA registered name.”_

So we will create a sub-directory of /opt specifically for our custom NodeJS installation. And if someday I want to remove that software, I will simply have to remove that directory:

sh$ sudo mkdir /opt/node-v8.1.1
sh$ sudo ln -sT node-v8.1.1 /opt/node
# What is the purpose of the symbolic link above?
# Read the article till the end--then try to answer that
# question in the comment section!

sh$ ./configure --prefix=/opt/node-v8.1.1
sh$ make -j9 && echo ok
# -j9 means run up to 9 parallel tasks to build the software.
# As a rule of thumb, use -j(N+1) where N is the number of cores
# of your system. That will maximize the CPU usage (one task per
# CPU thread/core + a provision of one extra task when a process
# is blocked by an I/O operation.

Anything but “ok” after the make command has completed would mean there was an error during the build process. As we ran a parallel build because of the -j option, it is not always easy to retrieve the error message given the large volume of output produced by the build system.

In the case of issue, just restart make, but without the -j option this time. And the error should appear near the end of the output:

sh$ make

Finally, once the compilation has gone to the end, you can install your software to its location by running the command:

sh$ sudo make install

And test it:

sh$ /opt/node/bin/node --version
v8.1.1

B. What if things go wrong while installing from source code?

What I’ve explained above is mostly what you can see on the “build instruction” page of a well-documented project. But given this article goal is to let you compile your first software from sources, it might worth taking the time to investigate some common issues. So, I will do the whole procedure again, but this time from a fresh and minimal Debian 9.0 and CentOS 7.0 systems. So you can see the error I encountered and how I solved them.

From Debian 9.0 “Stretch”

itsfoss@debian:~$ git clone --depth 1 
                             --branch v8.1.1 
                             https://github.com/nodejs/node
-bash: git: command not found

This problem is quite easy to diagnosis and solve. Just install the git package:

itsfoss@debian:~$ sudo apt-get install git
itsfoss@debian:~$ git clone --depth 1 
                             --branch v8.1.1 
                             https://github.com/nodejs/node && echo ok
[...]
ok
itsfoss@debian:~/node$ sudo mkdir /opt/node-v8.1.1
itsfoss@debian:~/node$ sudo ln -sT node-v8.1.1 /opt/node

No problem here.

itsfoss@debian:~/node$ ./configure --prefix=/opt/node-v8.1.1/
WARNING: failed to autodetect C++ compiler version (CXX=g++)
WARNING: failed to autodetect C compiler version (CC=gcc)
Node.js configure error: No acceptable C compiler found!
        Please make sure you have a C compiler installed on your system and/or
        consider adjusting the CC environment variable if you installed
        it in a non-standard prefix.

Obviously, to compile a project, you need a compiler. NodeJS being written using the C++ language, we need a C++ compiler. Here I will install `g++`, the GNU C++ compiler for that purpose:

itsfoss@debian:~/node$ sudo apt-get install g++
itsfoss@debian:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok
itsfoss@debian:~/node$ make -j9 && echo ok
-bash: make: command not found

One other missing tool. Same symptoms. Same solution:

itsfoss@debian:~/node$ sudo apt-get install make
itsfoss@debian:~/node$ make -j9 && echo ok
[...]
ok
itsfoss@debian:~/node$ sudo make install
[...]
itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1

Success!

Please notice: I’ve installed the various tools one by one to show how to diagnosis the compilation issues and to show you the typical solution to solve those issues. But if you search more about that topic or read other tutorials, you will discover that most distributions have “meta-packages” acting as an umbrella to install some or all the typical tools used for compiling a software. On Debian-based systems, you will probably encounter the build-essentials package for that purpose. And on Red-Hat-based distributions, that will be the “Development Tools” group.

From CentOS 7.0

[itsfoss@centos ~]$ git clone --depth 1 
                               --branch v8.1.1 
                               https://github.com/nodejs/node
-bash: git: command not found

Command not found? Just install it using the yum package manager:

[itsfoss@centos ~]$ sudo yum install git
[itsfoss@centos ~]$ git clone --depth 1 
                               --branch v8.1.1 
                               https://github.com/nodejs/node && echo ok
[...]
ok
[itsfoss@centos ~]$ sudo mkdir /opt/node-v8.1.1
[itsfoss@centos ~]$ sudo ln -sT node-v8.1.1 /opt/node
[itsfoss@centos ~]$ cd node
[itsfoss@centos node]$ ./configure --prefix=/opt/node-v8.1.1/
WARNING: failed to autodetect C++ compiler version (CXX=g++)
WARNING: failed to autodetect C compiler version (CC=gcc)
Node.js configure error: No acceptable C compiler found!

        Please make sure you have a C compiler installed on your system and/or
        consider adjusting the CC environment variable if you installed
        it in a non-standard prefix.

You guess it: NodeJS is written using the C++ language, but my system lacks the corresponding compiler. Yum to the rescue. As I’m not a regular CentOS user, I actually had to search on the Internet the exact name of the package containing the g++ compiler. Leading me to that page: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

[itsfoss@centos node]$ sudo yum install gcc-c++
[itsfoss@centos node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok
[itsfoss@centos node]$ make -j9 && echo ok
[...]
ok
[itsfoss@centos node]$ sudo make install && echo ok
[...]
ok
[itsfoss@centos node]$ /opt/node/bin/node --version
v8.1.1

Success. Again.

C. Making changes to the software installed from source code

You may install a software from the source because you need a very specific version not available in your distribution repository. Or because you want to modify that program. Either to fix a bug or add a feature. After all, open-source is all about that. So I will take that opportunity to give you a taste of the power you have at hand now you are able to compile your own software.

Here, we will make a minor change to the sources of NodeJS. And we will see if our change will be incorporated into the compiled version of the software:

Open the file node/src/node.cc in your favorite text editor (vim, nano, gedit, … ). And try to locate that fragment of code:

   if (debug_options.ParseOption(argv[0], arg)) {
      // Done, consumed by DebugOptions::ParseOption().
    } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {
      printf("%sn", NODE_VERSION);
      exit(0);
    } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) {
      PrintHelp();
      exit(0);
    }

It is around line 3830 of the file. Then modify the line containing printf to match that one instead:

      printf("%s (compiled by myself)n", NODE_VERSION);

Then head back to your terminal. Before going further— and to give you some more insight of the power behind git— you can check if you’ve modified the right file:

diff --git a/src/node.cc b/src/node.cc
index bbce1022..a5618b57 100644
--- a/src/node.cc
+++ b/src/node.cc
@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc,
     if (debug_options.ParseOption(argv[0], arg)) {
       // Done, consumed by DebugOptions::ParseOption().
     } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {
-      printf("%sn", NODE_VERSION);
+      printf("%s (compiled by myself)n", NODE_VERSION);
       exit(0);
     } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) {
       PrintHelp();

You should see a “-” (minus sign) before the line as it was before you changed it. And a “+” (plus sign) before the line after your changes.

It is now time to recompile and re-install your software:

make -j9 && sudo make install && echo ok
[...]
ok

This times, the only reason it might fail is that you’ve made a typo while changing the code. If this is the case, re-open the node/src/node.cc file in your text editor and fix the mistake.

Once you’ve managed to compile and install that new modified NodeJS version, you will be able to check if your modifications were actually incorporated into the software:

itsfoss@debian:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)

Congratulations! You’ve made your first change to an open-source program!

D. Let the shell locate our custom build software

You may have noticed until now, I always launched my newly compiled NodeJS software by specifying the absolute path to the binary file.

/opt/node/bin/node

It works. But this is annoying, to say the least. There are actually two common ways of fixing that. But to understand them, you must first know your shell locates the executable files by looking for them only into the directories specified by the PATH environment variable.

itsfoss@debian:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Here, on that Debian system, if you do not specify explicitly any directory as part of a command name, the shell will first look for that executable programs into /usr/local/bin, then if not found into /usr/bin, then if not found into /bin then if not found into /usr/local/games then if not found into /usr/games, then if not found … the shell will report an error “command not found”.

Given that, we have two way to make a command accessible to the shell: by adding it to one of the already configured PATH directories. Or by adding the directory containing our executable file to the PATH.

Adding a link from /usr/local/bin

Just copying the node binary executable from /opt/node/bin to /usr/local/bin would be a bad idea since by doing so, the executable program would no longer be able to locate the other required components belonging to /opt/node/ (it’s a common practice for a software to locate its resource files relative to its own location).

So, the traditional way of doing that is by using a symbolic link:

itsfoss@debian:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
/usr/local/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)

This is a simple and effective solution, especially if a software package is made of just few well known executable programs— since you have to create a symbolic link for each and every user-invokable commands. For example, if you’re familiar with NodeJS, you know the npm companion application I should symlink from /usr/local/bin too. But I let that to you as an exercise.

Modifying the PATH

First, if you tried the preceding solution, remove the node symbolic link created previously to start from a clear state:

itsfoss@debian:~/node$ sudo rm /usr/local/bin/node
itsfoss@debian:~/node$ which -a node || echo not found
not found

And now, here is the magic command to change your PATH:

itsfoss@debian:~/node$ export PATH="/opt/node/bin:${PATH}"
itsfoss@debian:~/node$ echo $PATH
/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Simply said, I replaced the content of the PATH environment variable by its previous content, but prefixed by /opt/node/bin. So, as you can imagine it now, the shell will look first into the /opt/node/bin directory for executable programs. We can confirm that using the which command:

itsfoss@debian:~/node$ which -a node || echo not found
/opt/node/bin/node
itsfoss@debian:~/node$ node --version
v8.1.1 (compiled by myself)

Whereas the “link” solution is permanent as soon as you’ve created the symbolic link into /usr/local/bin, the PATH change is effective only into the current shell. I let you do some researches by yourself to know how to make changes of the PATH permanents. As a hint, it has to do with your “profile”. If you find the solution, don’t hesitate to share that with the other readers by using the comment section below!

E. How to remove that newly installed software from source code

Since our custom compiled NodeJS software sits completely in the /opt/node-v8.1.1 directory, removing that software is not more work than using the rm command to remove that directory:

sudo rm -rf /opt/node-v8.1.1

BEWARE: sudo and rm -rf are a dangerous cocktail! Always check your command twice before pressing the “enter” key. You won’t have any confirmation message and no undelete if you remove the wrong directory…

Then, if you’ve modified your PATH, you will have to revert those changes. Which is not complicated at all.

And if you’ve created links from /usr/local/bin you will have to remove them all:

itsfoss@debian:~/node$ sudo find /usr/local/bin 
                                 -type l 
                                 -ilname "/opt/node/*" 
                                 -print -delete
/usr/local/bin/node

Wait? Where was the Dependency Hell?

As a final comment, if you read about compiling your own custom software, you might have heard about the dependency hell. This is a nickname for that annoying situation where before being able to successfully compile a software, you must first compile a pre-requisite library, which in its turn requires another library that might in its turn be incompatible with some other software you’ve already installed.

Part of the job of the package maintainers of your distribution is to actually resolve that dependency hell and to ensure the various software of your system are using compatible libraries and are installed in the right order.

In that article, I chose on purpose to install NodeJS as it virtually doesn’t have dependencies. I said “virtually” because, in fact, it has dependencies. But the source code of those dependencies are present in the source repository of the project (in the node/deps subdirectory), so you don’t have to download and install them manually before hand.

But if you’re interested in understanding more about that problem and learn how to deal with it, let me know that using the comment section below: that would be a great topic for a more advanced article!

From: It’s FOSS

Great News! LTS Release of Linux Kernel will be Supported for 6 Years Now

By Abhishek Prakash

Linux Kernel LTS releases will be supported for next 6 years

Brief: Linux Kernel Long Term Support (LTS) releases will now be supported for six years instead of two. This will enable Android devices to survive four OS upgrades.

Linux kernel has two kinds of releases: Long Term Support (LTS) releases and the regular releases.

A regular Linux kernel release arrives at an interval of 8-10 weeks. This means that devices running regular Linux kernel must be updated every 10 weeks.

This is where LTS Kernel release comes to save the trouble of upgrading devices every 10 weeks. An LTS release comes with 2 years of support and provides security and bug fixes.

Linux LTS Kernel will live for 6 years

But even two years of support for the LTS version is not enough for many and Google is one of them. In order to support Android devices for a longer period (current is 3 years), the two-year lifecycle of Linux LTS kernel is being upgraded to six years.

This announcement was made by Google’s Iliyan Malchev during Linaro Connect 2017 presentation. Malchev announced the extended lifecycle of LTS kernel when he was discussing the changes being brought to Android update cycle with Project Treble:

Greg Kroah-Hartman has given me permission to announce this here: He will extend LTS to six years, starting with kernel 4.4.

Greg Kroah-Harman is the current Linux kernel maintainer for the LTS releases. He approved of the news in a tweet saying, “this is going to be fun”:

This is going to be fun! https://t.co/JGCJQdWa58

— Greg K-H (@gregkh) September 29, 2017

It’s not just for Android

While Google’s Android devices seem to be the biggest beneficiary of this announcement, Malchev specified that it’s not something exclusive to Google or Android. It will be available for everyone.

LTS is LTS. Greg Kroah-Hartman, the LTS maintainer, is committing to do [a six-year LTS]. Not because of Google or Android or Treble, but because everything is on LTS; it’s not on upstream.

If interested, you can watch Malchev’s keynote speech below:

[youtube https://www.youtube.com/watch?v=Ksegw928gUM?version=3&rel=1&fs=1&autohide=2&showsearch=0&showinfo=1&iv_load_policy=1&wmode=transparent&w=640&h=390]

Starting from Linux kernel 4.4

The new 6-year Linux kernel LTS lifecycle will be applicable from Linux kernel 4.4 onwards. As Linux Kernel 4.4 was released in January 2016, we can expect it to be supported till 2022.

Linus Torvalds, the creator of Linux, hasn’t been a great fan of LTS releases lately as he thinks, “… it’s proving a tricky one, as the emergence of a LTS release sees developers push to make sure the stuff that matters to them makes it in.”

What do you think?

While we wonder what Linus thinks of the Linux Kernel LTS lifecycle increase, why not share your view on it. In my opinion, this is a welcome move as it means a longer support for not only Android devices but other connected and smart devices. What do you think?

Sources: Ars Technica and FOSS Bytes

From: It’s FOSS

Great News! LTS Release of Linux Kernel will be Supported for 6 Years Now

By Abhishek Prakash

Linux Kernel LTS releases will be supported for next 6 years

Brief: Linux Kernel Long Term Support (LTS) releases will now be supported for six years instead of two. This will enable Android devices to survive four OS upgrades.

Linux kernel has two kinds of releases: Long Term Support (LTS) releases and the regular releases.

A regular Linux kernel release arrives at an interval of 8-10 weeks. This means that devices running regular Linux kernel must be updated every 10 weeks.

This is where LTS Kernel release comes to save the trouble of upgrading devices every 10 weeks. An LTS release comes with 2 years of support and provides security and bug fixes.

Linux LTS Kernel will live for 6 years

But even two years of support for the LTS version is not enough for many and Google is one of them. In order to support Android devices for a longer period (current is 3 years), the two-year lifecycle of Linux LTS kernel is being upgraded to six years.

This announcement was made by Google’s Iliyan Malchev during Linaro Connect 2017 presentation. Malchev announced the extended lifecycle of LTS kernel when he was discussing the changes being brought to Android update cycle with Project Treble:

Greg Kroah-Hartman has given me permission to announce this here: He will extend LTS to six years, starting with kernel 4.4.

Greg Kroah-Harman is the current Linux kernel maintainer for the LTS releases. He approved of the news in a tweet saying, “this is going to be fun”:

This is going to be fun! https://t.co/JGCJQdWa58

— Greg K-H (@gregkh) September 29, 2017

It’s not just for Android

While Google’s Android devices seem to be the biggest beneficiary of this announcement, Malchev specified that it’s not something exclusive to Google or Android. It will be available for everyone.

LTS is LTS. Greg Kroah-Hartman, the LTS maintainer, is committing to do [a six-year LTS]. Not because of Google or Android or Treble, but because everything is on LTS; it’s not on upstream.

If interested, you can watch Malchev’s keynote speech below:

[youtube https://www.youtube.com/watch?v=Ksegw928gUM?version=3&rel=1&fs=1&autohide=2&showsearch=0&showinfo=1&iv_load_policy=1&wmode=transparent&w=640&h=390]

Starting from Linux kernel 4.4

The new 6-year Linux kernel LTS lifecycle will be applicable from Linux kernel 4.4 onwards. As Linux Kernel 4.4 was released in January 2016, we can expect it to be supported till 2022.

Linus Torvalds, the creator of Linux, hasn’t been a great fan of LTS releases lately as he thinks, “… it’s proving a tricky one, as the emergence of a LTS release sees developers push to make sure the stuff that matters to them makes it in.”

What do you think?

While we wonder what Linus thinks of the Linux Kernel LTS lifecycle increase, why not share your view on it. In my opinion, this is a welcome move as it means a longer support for not only Android devices but other connected and smart devices. What do you think?

Sources: Ars Technica and FOSS Bytes

From: It’s FOSS

How to Install Multiple Linux Distributions on One USB

By Ambarish Kumar

How to install multiple linux distributions on a single USB

Brief: This tutorial shows you how to install multiple Linux distributions on one USB. This way, you can enjoy more than one live Linux distros on a single USB key.

I enjoy trying out different Linux distributions via live USB. It gives me the option to test the OS on a real hardware, not in a virtualized environment. Also, I can plug in the USB to any system (read Windows), do whatever I want and enjoy the same Linux experience. And yes, in case something goes wrong with my system I can use the USB drive to recover!

Creating a single bootable live USB of Linux is easy, you just download an ISO file and burn it to a USB drive. But, what if you want to try more than one Linux distribution? You can either use more than one USB or you can overwrite the same USB to try other Linux distributions. Neither of these methods is very convenient.

So, how about installing more than one Linux distributions on a single USB? We are going to see how to do it in this tutorial.

How to create a bootable USB with multiple Linux distributions on it

Well, we have a tool which does exactly the same by keeping more than one Linux distribution on a single USB drive. All you have to do is select the distributions you want to install. In this tutorial, we will cover how to install multiple Linux distribution on a USB stick for live sessions.

Just to make sure, you should have a USB drive big enough to have several Linux distributions on it, so an 8 GB USB key should be enough for three or four Linux distributions.

Step 1

MultiBootUSB is a free and open source cross-platform application which allows you to create a USB drive with multiple Linux distributions. It also supports uninstalling any distribution at any point in time, so you can reclaim space on your drive for another one.

Download the .deb package and install it by double-clicking on it.

Download MultiBootUSB

Step 2

The recommended filesystem is FAT32, so make sure to format your USB drive before creating a multi-boot USB stick.

Step 3

Download the ISO images of Linux distributions you want to install.

Step 4

Once you have everything, start MultiBootUSB.

MultiBootUSB

The home screen asks you to select the USB disk and the image file for the Linux distribution which you want to put on your USB.

MultiBootUSB supports persistence for Ubuntu, Fedora and Debian distros, which means that changes made to the live version of the Linux distributions are saved to the USB disk.

You can select the persistence size by dragging the slider under MultiBootUSB tab. Persistence gives you an option to save changes to the USB drive in runtime.

MultiBootUSB persistence storage

Step 5

Click on Install distro option and proceed with the installation. It will take some time to complete before showing a successful installation message.

You can now see the distribution in the installed section. For another OS, repeat the process. This is what it looks like when I installed a copy of Ubuntu 16.10 and Fedora 24.

MultiBootSystem with Ubuntu and Fedora

Step 6

Next time I boot through the USB, I get the option of choosing either of the distributions.

Boot Menu

You can add as many distros as you want and your USB storage allows. For removing a distro, select it from the list and click on Uninstall Distro.

Final Words

MultiBootUSB really looks handy for installing multiple Linux distribution on a USB stick. With just a few clicks, I have a working drive with two of my favorite OS and I can boot into them on any system.

Let us know in the comments if you face any issue while installing or using MultiBootUSB.

From: It’s FOSS

How to Install Multiple Linux Distributions on One USB

By Ambarish Kumar

How to install multiple linux distributions on a single USB

Brief: This tutorial shows you how to install multiple Linux distributions on one USB. This way, you can enjoy more than one live Linux distros on a single USB key.

I enjoy trying out different Linux distributions via live USB. It gives me the option to test the OS on a real hardware, not in a virtualized environment. Also, I can plug in the USB to any system (read Windows), do whatever I want and enjoy the same Linux experience. And yes, in case something goes wrong with my system I can use the USB drive to recover!

Creating a single bootable live USB of Linux is easy, you just download an ISO file and burn it to a USB drive. But, what if you want to try more than one Linux distribution? You can either use more than one USB or you can overwrite the same USB to try other Linux distributions. Neither of these methods is very convenient.

So, how about installing more than one Linux distributions on a single USB? We are going to see how to do it in this tutorial.

How to create a bootable USB with multiple Linux distributions on it

Well, we have a tool which does exactly the same by keeping more than one Linux distribution on a single USB drive. All you have to do is select the distributions you want to install. In this tutorial, we will cover how to install multiple Linux distribution on a USB stick for live sessions.

Just to make sure, you should have a USB drive big enough to have several Linux distributions on it, so an 8 GB USB key should be enough for three or four Linux distributions.

Step 1

MultiBootUSB is a free and open source cross-platform application which allows you to create a USB drive with multiple Linux distributions. It also supports uninstalling any distribution at any point in time, so you can reclaim space on your drive for another one.

Download the .deb package and install it by double-clicking on it.

Download MultiBootUSB

Step 2

The recommended filesystem is FAT32, so make sure to format your USB drive before creating a multi-boot USB stick.

Step 3

Download the ISO images of Linux distributions you want to install.

Step 4

Once you have everything, start MultiBootUSB.

MultiBootUSB

The home screen asks you to select the USB disk and the image file for the Linux distribution which you want to put on your USB.

MultiBootUSB supports persistence for Ubuntu, Fedora and Debian distros, which means that changes made to the live version of the Linux distributions are saved to the USB disk.

You can select the persistence size by dragging the slider under MultiBootUSB tab. Persistence gives you an option to save changes to the USB drive in runtime.

MultiBootUSB persistence storage

Step 5

Click on Install distro option and proceed with the installation. It will take some time to complete before showing a successful installation message.

You can now see the distribution in the installed section. For another OS, repeat the process. This is what it looks like when I installed a copy of Ubuntu 16.10 and Fedora 24.

MultiBootSystem with Ubuntu and Fedora

Step 6

Next time I boot through the USB, I get the option of choosing either of the distributions.

Boot Menu

You can add as many distros as you want and your USB storage allows. For removing a distro, select it from the list and click on Uninstall Distro.

Final Words

MultiBootUSB really looks handy for installing multiple Linux distribution on a USB stick. With just a few clicks, I have a working drive with two of my favorite OS and I can boot into them on any system.

Let us know in the comments if you face any issue while installing or using MultiBootUSB.

From: It’s FOSS

Atari is Launching a Linux Based Retro Gaming Console Called Ataribox

By Derick Sullivan M. Lobga

Brief: Atari has just announced a new retro gaming console based on Linux. It will be available in Spring 2018 and is expected to cost between $249-$300.

The good old gaming company Atari is back in news. They are planning to launch a crowdfunding campaign for their proposed gaming console called Ataribox.

The retro-gaming console, Ataribox, plans to run Linux based operating system on its device that is expected to be released in Spring 2018. The gaming console will have a selection of Atari arcade games as well as the ability to play games from different platforms. It is expected to cost between $249 – $300 depending on its specifications or configurations.

As per the details revealed so far, Ataribox will have a custom AMD processor and Radeon Graphics. It will also have apps, streaming, music, web browsing and social features like any other gaming console.

For those who do not know, Atari built world’s first commercially available gaming console back in 1972. It sold millions of arcade games in the early years of video gaming. The company has not seen much success in last two decades but it is still a legendary name in the gaming industry.

Ataribox retro gaming console

So why is it being publicized as retro gaming console when it has all the functionalities of a modern gaming console?

The answer lies in the looks and the games it will have installed by default.

Ataribox has been modeled after the superhit Atari 2600 and it will have hundreds of old Atari arcade game.

According to the official announcement, “Our objective is to create a new product that stays true to our heritage while appealing to both old and new fans of Atari.” Other traditional Atari games will also run on it though it will use less horsepower to run them.

Ataribox will come in two models – one is black and red while the other will be a classic wood grain front. It is slim and looks more like a streaming set-top box or a cable box.

Based on pictures published on their site, the Ataribox will have HDMI output, USB ports as well as an Ethernet cable port to be used for the wired Internet. It is also expected that it will support SD cards that will allow for games and other content to be brought to your Ataribox.

What do you think of Ataribox?

The Ataribox is expected to be available through a pre-order campaign in Indiegogo and will begin in Spring 2018. For now, you can subscribe to their website for latest updates.

It is obvious that Ataribox will be compared with Steam Machine as it is also a Linux based gaming console. It can also be compared with Nintendo’s retro gaming console NES. But for me, it is too early to draw conclusions before we have more details.

What do you think about the new Ataribox? Share your opinion with us in the comment section.

From: It’s FOSS

Atari is Launching a Linux Based Retro Gaming Console Called Ataribox

By Derick Sullivan M. Lobga

Brief: Atari has just announced a new retro gaming console based on Linux. It will be available in Spring 2018 and is expected to cost between $249-$300.

The good old gaming company Atari is back in news. They are planning to launch a crowdfunding campaign for their proposed gaming console called Ataribox.

The retro-gaming console, Ataribox, plans to run Linux based operating system on its device that is expected to be released in Spring 2018. The gaming console will have a selection of Atari arcade games as well as the ability to play games from different platforms. It is expected to cost between $249 – $300 depending on its specifications or configurations.

As per the details revealed so far, Ataribox will have a custom AMD processor and Radeon Graphics. It will also have apps, streaming, music, web browsing and social features like any other gaming console.

For those who do not know, Atari built world’s first commercially available gaming console back in 1972. It sold millions of arcade games in the early years of video gaming. The company has not seen much success in last two decades but it is still a legendary name in the gaming industry.

Ataribox retro gaming console

So why is it being publicized as retro gaming console when it has all the functionalities of a modern gaming console?

The answer lies in the looks and the games it will have installed by default.

Ataribox has been modeled after the superhit Atari 2600 and it will have hundreds of old Atari arcade game.

According to the official announcement, “Our objective is to create a new product that stays true to our heritage while appealing to both old and new fans of Atari.” Other traditional Atari games will also run on it though it will use less horsepower to run them.

Ataribox will come in two models – one is black and red while the other will be a classic wood grain front. It is slim and looks more like a streaming set-top box or a cable box.

Based on pictures published on their site, the Ataribox will have HDMI output, USB ports as well as an Ethernet cable port to be used for the wired Internet. It is also expected that it will support SD cards that will allow for games and other content to be brought to your Ataribox.

What do you think of Ataribox?

The Ataribox is expected to be available through a pre-order campaign in Indiegogo and will begin in Spring 2018. For now, you can subscribe to their website for latest updates.

It is obvious that Ataribox will be compared with Steam Machine as it is also a Linux based gaming console. It can also be compared with Nintendo’s retro gaming console NES. But for me, it is too early to draw conclusions before we have more details.

What do you think about the new Ataribox? Share your opinion with us in the comment section.

From: It’s FOSS

Pay Attention! Ubuntu is Officially Dropping 32-bit Desktop Images

By Abhishek Prakash

Ubuntu is dropping 32 bit support

Brief: Ubuntu is dropping 32-bit desktop images from the upcoming Ubuntu 17.10 release. This paves the road for killing 32-bit support entirely from future Ubuntu releases.

Remember I told you about Ubuntu considering to drop 32-bit support in March this year? It seems the decision has been finally made.

Ubuntu is officially dropping 32-bit builds of the Ubuntu 17.10 desktop.

Canonical’s Dimitri John Ledkov, who had proposed the removal of 32-Bit support in March, has instructed the Ubuntu release team to remove the Desktop i386 images.

Please action the below and remove Ubuntu Desktop i386 daily-live images from the release manifest for Beta and Final milestones of 17.10 and therefore do not ship ubuntu-desktop-i386.iso artifact for 17.10.

The main argument for dropping the 32-bit Ubuntu desktop build is that “there is no longer any effective QA or testing of the desktop product on actual i386 hardware”. Shrinking 32-bit userbase is the obvious driving factor here.

Wait! This is not the end of 32-Bit Ubuntu. At least not yet!

Before you jump to conclusions, let me make a few things clear. This is not the end of 32-bit Ubuntu entirely. At least not just yet.

The idea here is to drop the DESKTOP i386 images. The desktop image is what you get by default from Ubuntu’s website.

But there are other variants of the same image. There is net install that lets you install Ubuntu over a network. There is also a minimal install alternative with image size around 60 Mb and consists of only the Ubuntu base. This decision of dropping 32-bit support doesn’t impact these installs, yet.

Also, you can still upgrade your existing 32 bit install to the newer Ubuntu 17.10.

So ultimately, you won’t get the default Ubuntu 17.10 32-bit ISO from its website. You’ll have to resort to the minimal ISO and the net install. Both of these are not straightforward install and do not allow a live preview.

To summarize:

  • Only 32-bit Ubuntu desktop builds are being removed
  • 32-bit net install option is still available
  • 32-bit minimal ISO is still available
  • Upgrade from older 32-bit Ubuntu versions still available
  • Other official Ubuntu flavors such as Xubuntu, Kubuntu, Lubuntu etc have not dropped 32-bit support yet

32-bit support will continue to fade away

Ubuntu is not the only one to show its unwillingness to support 32-bit. Manjaro Linux had dropped 32-bit support earlier along with Arch Linux. Newer Linux distributions like Nitrux and Antergos never had a 32-bit option.

On top of that, many application developers have also stopped support for 32-bit systems. Google Chrome is one such example. New Skype for Linux also doesn’t support 32-bit Linux.

Considering that the last 32-bit system was manufactured probably more than 10 years away, it is only natural that the support for older hardware goes away gradually. Which brings us to the burning question: are we looking at the end of 32-bit Linux?

Surprise anyone?

While it may not come as surprise to everyone, I was taken aback by the news of Ubuntu dropping 32-bit desktop builds.

The reason is that I was at UbuCon Paris earlier this month. And there was a particular discussion about 32-bit support. Dustin Kirkland, VP of Product Development at Canonical, had specifically ensured that Ubuntu will continue 32-bit support at least till 2021.

He might not be wrong here because Canonical has not dropped the 32-bit Ubuntu support entirely. Ubuntu should be continuing the 32-bit support for existing LTS release but the same cannot be said about the upcoming releases.

Quite obviously, there won’t be more 32-bit support for the upcoming Ubuntu releases. It would be interesting to see how other Ubuntu flavors handle this. Considering that minimal install is still supporting the 32-bit support, I think that some Ubuntu flavors like Lubuntu and Xubuntu would continue providing 32-bit desktop ISO.

What do you think? Share your views in the comment section below.

From: It’s FOSS

Pay Attention! Ubuntu is Officially Dropping 32-bit Desktop Images

By Abhishek Prakash

Ubuntu is dropping 32 bit support

Brief: Ubuntu is dropping 32-bit desktop images from the upcoming Ubuntu 17.10 release. This paves the road for killing 32-bit support entirely from future Ubuntu releases.

Remember I told you about Ubuntu considering to drop 32-bit support in March this year? It seems the decision has been finally made.

Ubuntu is officially dropping 32-bit builds of the Ubuntu 17.10 desktop.

Canonical’s Dimitri John Ledkov, who had proposed the removal of 32-Bit support in March, has instructed the Ubuntu release team to remove the Desktop i386 images.

Please action the below and remove Ubuntu Desktop i386 daily-live images from the release manifest for Beta and Final milestones of 17.10 and therefore do not ship ubuntu-desktop-i386.iso artifact for 17.10.

The main argument for dropping the 32-bit Ubuntu desktop build is that “there is no longer any effective QA or testing of the desktop product on actual i386 hardware”. Shrinking 32-bit userbase is the obvious driving factor here.

Wait! This is not the end of 32-Bit Ubuntu. At least not yet!

Before you jump to conclusions, let me make a few things clear. This is not the end of 32-bit Ubuntu entirely. At least not just yet.

The idea here is to drop the DESKTOP i386 images. The desktop image is what you get by default from Ubuntu’s website.

But there are other variants of the same image. There is net install that lets you install Ubuntu over a network. There is also a minimal install alternative with image size around 60 Mb and consists of only the Ubuntu base. This decision of dropping 32-bit support doesn’t impact these installs, yet.

Also, you can still upgrade your existing 32 bit install to the newer Ubuntu 17.10.

So ultimately, you won’t get the default Ubuntu 17.10 32-bit ISO from its website. You’ll have to resort to the minimal ISO and the net install. Both of these are not straightforward install and do not allow a live preview.

To summarize:

  • Only 32-bit Ubuntu desktop builds are being removed
  • 32-bit net install option is still available
  • 32-bit minimal ISO is still available
  • Upgrade from older 32-bit Ubuntu versions still available
  • Other official Ubuntu flavors such as Xubuntu, Kubuntu, Lubuntu etc have not dropped 32-bit support yet

32-bit support will continue to fade away

Ubuntu is not the only one to show its unwillingness to support 32-bit. Manjaro Linux had dropped 32-bit support earlier along with Arch Linux. Newer Linux distributions like Nitrux and Antergos never had a 32-bit option.

On top of that, many application developers have also stopped support for 32-bit systems. Google Chrome is one such example. New Skype for Linux also doesn’t support 32-bit Linux.

Considering that the last 32-bit system was manufactured probably more than 10 years away, it is only natural that the support for older hardware goes away gradually. Which brings us to the burning question: are we looking at the end of 32-bit Linux?

Surprise anyone?

While it may not come as surprise to everyone, I was taken aback by the news of Ubuntu dropping 32-bit desktop builds.

The reason is that I was at UbuCon Paris earlier this month. And there was a particular discussion about 32-bit support. Dustin Kirkland, VP of Product Development at Canonical, had specifically ensured that Ubuntu will continue 32-bit support at least till 2021.

He might not be wrong here because Canonical has not dropped the 32-bit Ubuntu support entirely. Ubuntu should be continuing the 32-bit support for existing LTS release but the same cannot be said about the upcoming releases.

Quite obviously, there won’t be more 32-bit support for the upcoming Ubuntu releases. It would be interesting to see how other Ubuntu flavors handle this. Considering that minimal install is still supporting the 32-bit support, I think that some Ubuntu flavors like Lubuntu and Xubuntu would continue providing 32-bit desktop ISO.

What do you think? Share your views in the comment section below.

From: It’s FOSS

Spice up Your Linux Desktop with Shadow Icon Theme

By Aquil Roshan

Shadow Icon Theme

Icon themes are the little things that make a big difference in the visuals of your desktop. Until you get the right icons to match your desktop environment and the wallpaper, your desktop is not complete. You have to get that feeling of perfection when you look at your desktop. What I’m trying to say is, icon themes are really important.

GNOME shell has a huge range of icon themes. Today, let’s have a look at the vibrant Shadow icon theme.

If you need something that is eye-catching, something that showcases vibrant, bright colors, while still maintaining a sense of uniformity across all the icons, look no more. Shadow icon theme is right for you.

Shadow Icon Theme

Shadow Icon Theme contains nearly 900 app icons. So whatever you install on your computer, will get a nice colorful icon. The shadow trail on the lower left of the icons brings about a feeling of uniformity. These icons look particularly good stacked in the dash of your Ubuntu.

Installing Shadow icon theme

On Arch Linux/ Manjaro/ Antergos, install Shadow Icon Theme from the AUR by running the below command in the terminal

yaourt -S shadow-icon-theme

On Ubuntu/ Linux Mint/ Elementary OS and other distros based on Ubuntu, run the below commands one by one:

sudo add-apt-repository ppa:noobslab/icons
sudo apt-get update
sudo apt-get install shadow-icon-theme

You can use Shadow Icon Theme using the Tweak Tool(s) in your distribution.

While we’re at it, also check out the best icon themes for Ubuntu. We’ve got pretty good selections.

Users of other Linux distributions can download the tar file from openDesktop and extract the content in ~/.icons directory:

Download Shadow Icons

And if you need a hand with the wallpapers, don’t forget to check out WallpaperDownlader, an automated wallpaper downloader, and manager.

Wrapping up

Whatever distro or desktop environment you are running, Shadow Icons don’t fail to give a boost to the aesthetics. Do give it a try. Also, use the comments section below and let us know what icon themes you think totally rock the desktop. We will be happy to hear. Cheers.

From: It’s FOSS