Может ли консольное приложение в Linux, повесить весь сервер?

может

Однозначно.

Иногда на форумах возникают темы "а давайте свою ОС напишем" и недалёкие как обычно говорят, да зачем, да кому это надо и тп.

Одна из причин это как раз и является то, что существующие ОС могут зависать из-за ошибок ядра, переполнения оперативки и тд. А ведь это на самом деле не сложно исправить если написать своё ядро более продуманно.

Кстати по этой же причине и возникли микросервисные системы с распределением нагрузки и дублирования чтобы при сбоях вся система не падала и те микросерсисы которые зависают их перезапускают.

А может просто не у всех хватает ума и квалификации осознать реальные причины этого вопроса. Это только на словах "просто". А на данный момент я знаю одного представителя из "далеких", кто нечто называемое "фреймворк" с очень скудным функционалом (что в реальности является уровнем небольшой курсач для "недалеких") пилит года с 19го кажется (и каждый день проект в состоянии  "я доделал"). Не знаете такого? ;)

И да и нет. Зависит и от того кто настроил и от того, кто хочет повесить. И тут дело не в графическое/псевдографическое или вообще без какого либо вывода. Если говорить с токи зрения пользователя обычного то сильно сложнее. В винде если уже повисло значит повисло, в линукс нереально сложно (если этого не захотеть специально) повесить так, чтоб не сработало хотябы REISUB  (что это такое уже погуглите).

Тем не менее, конечно же может быть ситуация  когда проблемы с самим ядром (кернел паник, например) тогда уже беда. Но тут, если вы используете стабильную версию дистрибутива, (и нормальный дистрибутив) - крайне редкий случай.  Иногда могут быть ведь и на уровне железа быть проблемы.

Приложение может вызвать что-нибудь уровня ядра, что может подвесить систему.

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

Не только.

Сама проблема кроется в самой архитектуре процессора, по хорошему нужна разработка новой архитектуры процессора. Многие подходы тянутся со времён самых первых процессоров с целью совместимости прежнего ПО в этом и кроются все подводные камни. Например стек, удобный вроде бы подход к записи динамических данных, вызовов процедур и возврат обратно, но он может затереть данные или код программы при плоской памяти и даже если его организовывать в отдельной странице за выход которой будет вызывать панику ядра. Да и другие подходы тоже с проблемами, та же куча, прерывания. Разные виды режимов, хоть они и дают некую иллюзию защищённости изоляции процессов друг от друга в конечном итоге приводит к коллапсу системы.

Да что ты говоришь..

Оно и видно как в тех же смартфонах постоянно возникает утечка и нехватка оперативки и приходится закрывать все приложения и открывать по новой или даже перезагружаться. Это и в серверах также происходит, я уже говорил про микросервисные системы.

Даже наращивание оперативки не помогает, всё равно наступают моменты когда оперативка засоряется и неэффективно используется, и возникает её нехватка не смотря на то что масса страниц отведённые под процессы можно сказать не используются.

ЗЫ. Да кому я это объясняю..

бизнесу это не надо, пишут правильный софт и железки работают десятилетиями без сбоев, потому что писать софт дешевле, чем проектировать железки)

Фреймворк я давно сделал, релиз не делаю потому что мне это не надо, я делал инструмент для себя и своих проектов. Не начинаю создание этих проектов наверно тупо из-за лени, фокус интереса переместился в сторону ИИ, разработку на Rust и тд.

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

Насчёт того что бизнесу это не надо, трудно не согласится, погоня за выгодой это одна из первых глупостей человечества.

Насчёт того что пишут правильный софт и железки работают, тут можно поспорить, пишут опять же ради наживы, в основном чтобы продать, а как это работает это уже меньше волнует, в этом и масса проблем возникающих у пользователей...

Написать софт не проще чем проектировать железки, просто требования к знаниям разные, по мне спроектировать железки даже проще. Это всё зависит от уровня знаний человека, если к примеру человек не разбирающийся как устроен и работает компьютер судит о его качестве, скорости работы и тд. исключительно по цене, чем дороже, значит лучше. А по факту сейчас куча разных вариантов на рынке и ПК за не большие деньги могут превосходить по скорости работы нежели если потратить в десятки раз больше. Так же и с другими вещами. К примеру мажоры друг перед другом красуются всякими дорогими вещами, а по факту цена этим вещам копейки, такие же вещи за меньшую цену будут даже лучше. А ведь это всё происходит из-за глупости, незнание того как эти вещи делаются и тд. маркетинг.. Умение продавать даже вредные, плохие вещи, вот что надо бизнесу..

Бывает. Среди админов, бывают "админы", которые так же как некие гении разработки не умеют читать документацию. В хороших руках, если мы говорим о сервере, даже выход из строя сервера не проблема. Но мы ведь про тех "кто ради наживы" учиться и понимает, что и зачем делает.

Да бывает, из криворуких программистов например.  Но при правильном подходе сервер останется в строю. Тупить будет - да. Положить - надо постараться. При этом действительно не увеличение ядер, ни памяти может не помочь, но сервер при этом останется доступным. Далее уже идут системы мониторинга и т.п. На десктопе REISUB на тяжелый случай.

Действительно... человек который не сделал ни одного проекта (до состояния, когда можно пользоваться хотя бы самому), не обслуживал ни одного сервера, ни разу ни на одном форуме (по крайней мере ИТ) не смог технически гармотно пояснить свою точку зрения......  Не надо не объясняй - опять ведь облажаешься как с тем же git