Should you choose the type of linux.net deployment?

The current deployment of the linux.net environment is a variety of ways, both the traditional way of compiling the source code, and a wide range of one-click installation scripts, as well as green package installation, and with the official mono new station on-line, but also increased the use of RPM package deployment. What should we do for a beginner who is a linux.net? Below, this article will compare the advantages and disadvantages of these kinds of installation methods, so as to help readers choose the best way to deploy.

In this article, we will discuss the following deployment methods:

1. Source code Compilation

2. One-click installation script

3. RPM Package

4. Green Bag

First, the source code compilation

Installation deployment through source code compilation Linux.net is the most traditional and most original and reliable way, by getting the source code, and in the physical machine (virtual machine) to compile, the compiler can be targeted to the machine to build the most suitable for the machine to run the binary execution file. At the same time, the way to compile the source code is the most stable way of all deployment methods. At the same time, the use of source code to compile the deployment is also the most flexible. Readers who want to learn in depth must be deployed in this way.

To install the deployment linux.net in the form of source code compilation, we need to get to a copy of the source, there are two main ways to get mono source code, one is to pull the mono's managed code through GitHub to execute Autogen and execute make Install the installation, the other is through the Mono/source release of the source package (tar.gz or TAR.BZ2 package)./configuration and then do the make install the way to compile.

In fact, if the reader uses the former (that is, git pull) to compile the deployment environment, the obtained version will generally be higher than the version released from the Mono/source (in the case of compilation, of course), for those who wish to use the highest version or want to taste the early adopters, Using this approach is a good choice. But there are some drawbacks to choosing this approach, which is that we need to do git clone or git pull code before compiling, which will make it possible for us to download the GIT code repository on G. At the same time, because the external directory in mono also contains other. NET project git repositories, when executing Autogen, the system checks whether the code that includes the external directory is complete, so the compile-time system is also likely to execute the git pull code again. In addition, after we have git pull master, we may not be able to compile the pass. Fortunately, after the release of the article, Lexli gave some reminders, through his ideas, we found in fact Github/mono READMD is a current code can be compiled "cue light", by observing this "light" The displayed color we can know whether the current code can be compiled, but also here there is a version of the Test history, we can also according to its compilation test records that the source of the submitted version is ready to compile, and then just reset the code to this version can be compiled again.

And the use of Mono/source issued by the source package compiled by readers, reliability is greatly improved, after all, this is the release version. Although there are individual distribution packages because the file is missing can not be compiled, but always the most reliable, and the source package distribution size is generally within hundred trillion, compared to the Git warehouse on the G code is much smaller.

Finally, readers, whether in either of these two ways, will need to spend a long or lengthy compilation wait time, and compile may encounter some make error phenomenon, which requires the reader to overcome their own processing. But in any case, this is the kind of deployment that you need to master in a reader who wants to learn more about linux.net. (Readers who are in need can take a detailed "linux.net study notes")

Second, one-click installation script

Since the use of the source code compiled by the direct use of shell commands to operate, so a lot of people have extracted these shell commands to reassemble a shell script, as long as the execution of the script to complete the deployment of the environment, which is more enthusiasts ingenuity, on the basis of the command line to improve, provide similar The "interface" of the flow of the way, giving a better interaction with the user. Using scripted deployment environment is a sign of liberating productivity.

But even so, the use of script installation still has a considerable shortage, that is, the use of script installation is actually just a "gift box", "Gift box" content is still the source code compilation method, therefore, the use of script installation of the problem will not be more than the use of the source installed less. At the same time, the use of script installation still exists this "compatibility" problem, it is worth noting that the so-called "compatibility" does not mean that the script command does not work, but by the source code compiled "inherited" down "incompatible", that is, the complexity of the environment caused by different make error "incompatible." In addition, because everyone has their own installation style, some people may like to install things in "/usr" (like Woo, good friends of the tutorial, etc.), some people like to install into the "/usr/local/" (My Style, "linux.net Study Notes" tutorial path), others like to install to the "/ Opt "in ... All in all, the installation path written in the script is purely the author's decision, and the installation directory may not be the path that the reader wants, and there are some shortcomings.

Three, RPM package

With the launch of Mono's new website, the RPM installation that relies on Yum also quietly appears in the eyes of readers, for some time, many friends started or for the early adopters (no way, after experiencing the sweetness of Yum may be difficult to turn back) or receive the "official" Guidelines have adopted this approach to deploy the linux.net environment.

I have not tried this way (not bothered to add the image source myself), but from a lot of friends (Bao) feed (yuan) back (Niang) information, this method seems to be the most residual (zi) (SHA) in several methods. Because the RPM package is part of a binary package, the installation path has been preconfigured in the package, cannot be changed, we can not know where it is installed (only find), from some of the information provided by friends installed in this way, it is basically installed in the "/opt" directory (but there is no specific directory, there is " /opt/","/opt/mono "or even"/opt/201408xx/"directories). In addition, the use of RPM package installation is also a very serious problem, that is, the installation in this way did not register the Mono/bin path to the environment variable, resulting in the system cannot find mono.

Therefore, I personally do not recommend this method of installation in particular.

Four, green package (Jws.mono)

There is a common feature of the above three ways, which is that all need to be done with network conditions. And the green package is different from the former, green package is compiled from the use of the source of the machine to extract the reorganization and make appropriate changes into a new decompression can run the green version of the Linux.net operating environment.

The use of green packages has several advantages:

(1), rapid deployment, due to the deployment of this method only need to execute a decompression command (the need to self-registering environment variables), there is no compilation process, greatly saving because of the environmental deployment of the valuable time required to consume.

(2), targeted strong: Because each green package is for its labeling of the Linux distribution to compile, so the green package has a relatively strong distribution of targeted.

(3), delicate and yet functional: readers who have used the green package may find that the package file size is even smaller than the Mono/source-issued source package, but the functionality is not reduced. The secret is that Mono's library is backwards compatible with ms.net, so in each green package we remove the "duplicate" library to make the package sophisticated enough.

But gold is not can't pure, green package also faces some problems, the first is that it can not upgrade (this is going to be improved, in the next release to provide a script to upgrade), the second is to make the release package is a heavy workload and time-consuming work. We need a package that compiles and produces the corresponding distributions.

But for beginners and readers who need rapid deployment and large-scale deployment, the green package is the best choice because it's easy enough because it's fast enough.

Of course, the benevolent see, the above view is I use Linux.net compile time written (has failed almost 10 times) of the subjective views and suggestions, do not like to play ha, thank you.

Original link: http://jhonge.net/Home/Single/3788111

Should you choose the type of linux.net deployment?