I believe many users have never seen arch Linux. Why do they rarely see arch Linux? Because arch Linux does have some disadvantages in terms of services, let's take a look at the four reasons why arch Linux is not suitable as a server operating system.
Why is arch Linux not suitable as a server operating system?
1. Overly aggressive rolling update
Rolling update is the biggest advantage of arch Linux, but it is also one of the biggest disadvantages. Given that Linux is a completely open project, the ability of technicians is uneven, and the code quality contributed is certainly uneven. For other distributions, the software package needs to be tested by the community before it can be released to the software source and updated by users; However, the rolling update mechanism of arch Linux is too radical, and the testing of software packages by arch community is not absolutely perfect (how many people have rolled up?). In a sense, the release of arch relies heavily on its user group as the test object; Its user group is the existence of similar testers. Arch community encourages users to feed back bugs to the upstream, which is also a manifestation of this special system. The following figure is a "temporary solution" published from time to time on the arch official website to help technicians manually solve the update problem:
If an arch server rolls up during the update, the technicians, under the pressure of the boss, should not only try to restore the server, but also feed back bugs and issues to the upstream of the arch community. No one wants to do such a thing.
2. Radical kernel update mechanism
Many Linux desktop users have asked me more than once why their desktop Linux will not immediately delete the old kernel like arch when updating? Isn't that a waste of space?
This update mechanism to immediately delete the old kernel is also one of the disadvantages of arch as a server. First, not all new kernels will work properly. In case your new kernel crashes, you can't load the old kernel immediately, but you have to reinstall the old kernel. This process is very troublesome. You not only need to start from the installation media, but also try to get the software package of the old kernel. For remote servers, there is almost no solution. Here are the solutions from arch wiki. You can see how troublesome this is:
Secondly, deleting the old kernel immediately requires the system to restart to load the new kernel, otherwise it is prone to strange problems. This is because the so-called "kernel" of Linux contains a large number of dynamic loading modules. If a module has not been loaded after a startup, and then the system kernel updates and deletes the old kernel, these modules will never be loaded - unless you restart the system and completely switch to the new kernel - because they are deleted with the old kernel.
If you have an arch system on hand, you can try not inserting any USB device after a boot, and then update the kernel. You will find that if you do not restart the system, no matter how hard you try, the newly inserted USB device will not be loaded - because the modules that need to be loaded have been deleted with the old kernel. Rebooting the system can completely switch to the new kernel to use the new dynamic loading module.
However, for the server, it is impossible to restart in three days or two; However, arch Linux is a faster iterative operating system that is smaller every week and larger every month. This makes arch unsuitable as a server operating system.
3. Software package management system
Part of the reason why Linux package management system is highly praised is that it is easy to use. Unlike apt / dpkg of Debian series and dnf (Yum) / RPM package management system of red hat series, arch Linux uses only one tool, Pacman, to obtain and install two functions. This reduces the threshold of making software packages for arch Linux, which is the main reason why AUR can almost cover the whole linux software ecosystem.
Since one tool can complete the work, why do two other mainstream series still have two tools to manage the software package system? This is because in the system of using these two tools to manage software packages, the part responsible for handling local dependencies and local packages does not just exist to manage dependencies and install software packages. It also has a more useful function: providing "virtual package" support. When it comes to "virtual package", we have to mention the platform of Java. Because of the openness of Java, there are two common Java runtime environments: one is the official JRE of Oracle, and the other is the open JRE created by the open source community. They all provide a high level of support for Java, but there are still subtle differences. For example, when Android studio runs with open JRE, strange bugs occasionally appear, while a small part of the software cannot run normally on Oracle JRE. Both provide JRE support, but for Debian or red hat, the two can coexist: dpkg or Yum can decide which JRE to choose for which applications to provide JRE dependency.
But for Pacman, what virtual package supports does not exist. Only one package can provide JRE support: install one and then remove the other. This is quite embarrassing for the server: there is no guarantee that all programs can find perfect dependencies.
4. Packing granularity
Although it has improved in recent years, the packaging granularity of arch Linux is too large for the server. We may only use part of a package, but Pacman will install the whole package for you - you don't have a choice yet. For the server, the fewer software packages installed to realize the functions, the better - on the one hand, it can save resources and on the other hand, it can reduce the loopholes brought by the software system. This is one of the reasons why arch is not suitable as a server operating system.
Supplement: server introduction
Servers, also known as servers, are devices that provide computing services. Since the server needs to respond to service requests and process them, generally speaking, the server should have the ability to undertake services and ensure services.
The composition of the server includes processor, hard disk, memory, system bus, etc., which is similar to the general computer architecture. However, due to the need to provide highly reliable services, it requires high processing capacity, stability, reliability, security, scalability, manageability and so on.
In the network environment, according to the different types of services provided by the server, it is divided into file server, database server, application server, web server, etc.
Related reading: what are the server FAQs
1. System blue screen, frequent crash, restart, slow response
The of the server is very similar to our ordinary computer, whether it is hardware structure or running system. Therefore, just like our computers, they may be infected with viruses, crash, blue screen, restart and other failures due to system vulnerabilities, software conflicts and hardware failures, and slow response due to too much garbage cache information.
2. The remote desktop connection exceeds the maximum number of connections
Since the server allows 2 connections by default, if you forget to log off after logging in and directly close the remote desktop, the server recognizes that the login is still on the server side. In this case, the most common is to restart the server. However, if it is the peak period, the loss caused by restarting the server is obvious. At this time, you can use the mstsc / console command to forcibly log in. Open the "run" box and type "mstsc / V: xxx.xxx.xxx.xxx (server IP) / console" to forcibly log in to the remote desktop.
3. How to clean up files that cannot be deleted
In this case, it may be that the file is still running. You can restart and delete it, or run CMD, enter the name of the folder arrtib-a-s-h-r you want to delete, and finally enter the name of the folder del wants to delete. It cannot be recovered after running this command. Please use it with caution.
4. Hidden trouble of system port
For the server, the first thing is to ensure stability and security. Therefore, we only need to ensure the most basic functions of the server, just like the sound card is prohibited by default. We don't need too many functions and port support. For example, some unnecessary and high-risk ports can be blocked. For some necessary and risky ports, such as ports 3389 and 80, we can set them as non-special secret ports by modifying the registry, so that the security hidden dangers of server ports no longer exist.