Сервер - это по сути инструмент

Ты же не копаешь колодцы для воды и не строишь электростанции для тока.

Фрагмент из сериала "Кремниевая долина" (2014)

Устройство асинхронных фреймворков для Python

Асинхронный подход появился еще очень давно, когда надо было эмулировать параллельное выполнение задач на одноядерных процессорах и старых архитектурах.

«Асинхронность» и «параллельность» — довольно-таки ортогональные понятия, и один подход задачи другого не решает. 

Тем не менее асинхронности нашлось отличное применение в наше высоконагруженное время быстрых интернет-сервисов с тысячами и сотнями тысяч клиентов, ждущих обслуживания одновременно. 

Откровенно говоря, есть только два варианта работы с сокетом — синхронный и асинхронный.

С синхронным в целом все понятно — пришел клиент, открылся сокет, передали данные, если это все — сокет закрылся. В этом случае пока мы не закончили локальный диалог с одним клиентом — не можем начать его с другим. По такому принципу обычно работают простые серверы, которым не надо держать сотни и тысячи клиентов. В случае если нагрузка возрастает, но не критично — можно создать еще один или несколько потоков (или даже процессов) и обрабатывать подключения еще и в них. Это обкатанный годами, стабильно работающий подход, который, например, использует сервер Apache, — никаких неожиданностей, данные от клиентов обрабатываются в порядке строгой очереди, а в случае запуска какого-то «долгого» кода — например, каких-то вычислений или хитрого запроса в БД — это все никак не влияет на других клиентов.

Но есть проблема: сервер не может плодить потоки и процессы вечно — есть же, в конце концов, вполне ощутимые ресурсы, которые тратятся при каждом таком действии, и имеется верхний порог использования этих ресурсов. И вот тогда все вдруг вспомнили про асинхронность и системные вызовы для неблокирующего ввода-вывода. Зачем плодить кучу сокетов и потоков, выедать ресурсы, если можно данные от многих клиентов сразу одновременно слушать на одном сокете?

Можно ли ставить на Linux-сервер GUI?

Минусы

• тянет много ресурсов (а если desktop GUI не держать постоянно в памяти на сервере?!)
• нет смысла
• вероятность существования какого-либо технологического отверстия увеличивается с каждым новым установленным пакетом (а если сервер внутренний и находится за корпоративным файерволом и наружу выставлен не целый адрес, а только один порт?!)

Плюсы

• быстро сделать что-то мышкой (а если разобраться и написать скрипт?!)

Выводы

GUI для взаимодействия между человеком и компьютером это как правило проще чем CLI. Вопрос не в том GUI это хорошо или плохо, GUI это хорошо (например, браузерные панели управления серверами и графическая статистика), вопрос в том куда его ставить? GUI должен быть отделен от ядра системы! От ядра нужно отсечь всё лишнее, чтобы достичь его совершенства. Если код GUI сильно переплетен с кодом ядра, то разделить их невозможно и это плохо. По хорошему каждая система должна предоставлять возможность удаленного подключения GUI. Модульность это хорошо. А удаленная модульность еще лучше.