I am not a native English speaker and using google translation. If I offend you, I apologize. ๐
The biggest problem is the disk occupation. Whatever portainer of others panels, they cannot allow me dispatch the storage location. Espacially the docker cost a high require of storage. I am a SLC/MLC believer, and i am always worry about the read/write consume cost by docker, because the folder locate in the system partition.
Another misery is that many applications' set up script will pull many image and say nothing in the introdution. If i want to undo the installation, it is so hard to tell which one is foreign.
The following is my personal technology stack rank of prefer to install. The difficulty of deploy is the key judgment, and the web access will be the second factor:
- TypeScript/Node/JavaScript โโ Powerful package management. No compile requirement. Easy to customize, embed and reuse in personal projects.
- Go โโ One file and one command.
- PHP โโ No compile requirement. Easy to customize. Code fast. Abundant LNMP support tool.
- Java โโ Less files. Easy to run especialy springboot framework. But more and more project prefter front and rear separation.
- Python โโ No compile requirement. Easy to customize. But version problem is unbearable. The package management is centralized. Huge size package will be download into the system disk (The root folder), espacially the AI app.
- C# โโ If lucky enoungh, it is possible to run on the linux. But many of them are served for windows desktop.
- C/C++/Ruby โโ System invasion, hard to backup and deploy.
All the kind of project above, I am using supervisor and LNMP panel to manage, and deside the location among my 3 SSDs and 6 HDDs.
The .Docker and podman might be the trend, but in my humble oppinion, in most of senarion there is no need to use them. Native deployment can handle more and actually is not too hard, except something complex like Calibre and Jellyfin. Also I am looking for Alternative option of Calibre and Jellyfin.
Docker and Kubernetes are popular mostly because the industry has broadly given up on release engineering. This means applications/services can have different and conflicting dependencies, so the only way they can run on the same physical host is by putting each in their own containers or VM instances, each with their specific dependencies.
The alternative is to have a platform with standard libraries, and to port applications to the platform, using the platform's libraries as their dependencies, and thus avoid conflict. This requires effort and discipline, so of course it is not very popular, though it was the standard practice twenty years ago.
As far as I know the only Linux distribution which still follows the platform approach is Slackware. Applications which are ported to Slackware are guaranteed to work well together without conflicts, but not a lot of applications have been thus ported (Slackware only has about two thousand official packages, in all).
Wow. Thank you for introduction. ๐
I got the point now.