На что способна чистая консоль

я вспоминал про давние времена – 90-е годы; но пруфов у меня нет. может и не было ничего.

А получить список доступных вариантов для конкретной железяки как-то можно?

Не знаю.

Раньше можно было в параметрах ядра написать vga=ask. Оно помигает немного (потестирует) и выдаст результат. Удобно делать в режиме редактировании параметров ядра в загрузчике. Но какой-то умник выбросил поддержку этого параметра из ядра.

Еще есть консольная команда hwinfo --framebuffer (запускать из-под рута). Но мне она не показала текстовые режимы. На мой взгляд этого потому, что у меня в ядре прописана прошивка видеокарты (linux-firmware), и ЕМНИП выключена поддержка VESA. Может если на голом ядре попробовать...

Еще есть команда grub2 vbeinfo. Это не команда Линукс - это если при загрузке в меню grub2 нажать «e», а потом «c». Да, перед выполнением лучше сделать set pager=1. Но мне эта команда тоже не показала текстовых режимов.

Разве что перебором пробовать - не зря vga=ask мигала.

а по сути настоящий текстовый режим чем был?

Вот чем:

Есть стандарт VESA, который специфицирует понятие «текстовый режим», который состоит в том, что если в определенный участок памяти зашлешь байт 65, то видеокарта тебе покажет букву «A», а не пиксель соотв. цвета.

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

Их не могло быть. Форма написания символов задавалась в «трафарете» - другом участке памяти: на каждый символ ты 8x16 пикселями рисова изображение. То есть ничего кроме 256 «спрайтов» ты на экране получить не мог.

Был а псевдографика, то есть какие-то символы представляли собой «линия вверх», «линия всторону», «поворот».

Norton Utilites и некоторые другие баловались тем, что мышку делали стрелочкой, а не прямоугольником. Выглядело очень круто, но это они тоже делали путем динамического перерисовывания 1-4 символов трафарета.

Еще были ассемблерные утилиты, которые могли рисовать горизонтальные цветные линии в текстовом режиме. Эта была та магия, в которой я не смог до конца разобраться. Утилита занимала что-то около 100 байт (именно байт), я пытался ее дизассемблировать, и судя по тому мозголомству что я получил, она работала напрямую с видеокартой, и по идее просто в нужное время меняла интенсивность луча ЭЛТ монитора. То есть к настоящей графике это не имело никакого отношения.

Но на текстовой консоли чисто технически нарисовать произвольную линию невозможно.

И это давало офигительную скорость на компьютере даже самой маленькой мощности.

после 19 века

Что, и КР580ВГ75 подойдёт? «А если найду?» (с)

Была псевдографика

Ага, я не зря ВГ75 вспомнил. Для «Партнёра» с модулем цветности народ перепрограммировал знакогенератор на набор спрайтов, получались игры с почти настоящей графикой, хотя под капотом была ПСЕВДОграфика.

Но это не PC, конечно, это был отдельный мир…

т.е. если переключить загрузку с UEFI на CMS видеоадаптер переключиться с фреймбуфера на знакогенератор?

Да, например чтобы сказать что OC не найдена и т.п. Загрузчик может перевести её снова в графический режим сразу.

есть какие-нибудь источник где всё это рассматривается? // не для спора, а для утоления любопытства

Кое что есть вот тут /usr/src/linux/Documentation/fb , а вообще инфа клочками тут и там разбросана. Я просто достаточно давно глубоко ковырялся и с текстовыми режимами и с фреймбуфером, так что инфы сам насобирал.

А ещё был модуль ядра mga_vid, шел вместе с mplayer, позволял выводить видео в оверлей поверх истинной текстовой консоли с аппаратным масштабированием. Я так в консоли фильмы смотрел. Но это была магия видеокарт matrox ЕМНИП. Ещё кажется можно было с использованием svgalib вывести картинку, но с переключением видеорежима в момент вывода.

А получить список доступных вариантов для конкретной железяки как-то можно?

Можно, если на компе BIOS. Тогда, грузимся в DOS, а дальше - «Библиотека системного программиста» том 21, «Программирование видеоадаптеров EGA, VGA и SVGA». Там и утилита для SVGA есть.

Ну на ноуте, про который я писал, к примеру, UEFI, но можно включить Legacy BIOS. Предлагаешь смонстрячить флешку с FreeDOS? :)

Именно!

Интересно, что тему я создавал в первую очередь по «чисто текстовым» режимам, но в итоге большая часть обсуждение таки вырулила на фреймбуфер, что несколько другое.

так не одна современная карта уже не поддерживает текстовый режим аппаратно.

Вот уж не думаю. VESA-совместимость, наверное, по старой памяти сохраняют. Стандарт, как-никак.

так не одна современная карта уже не поддерживает текстовый режим аппаратно.

Вот этого я всю тему и добивался. Пруфы есть? Где можно почитать?

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

а какие поддерживают из несовременных?

Интересно, что тему я создавал в первую очередь по «чисто текстовым» режимам, но в итоге большая часть обсуждение таки вырулила на фреймбуфер, что несколько другое.

Конечно, а чего ты ещё ждал. Его увидеть то сейчас мало где можно, многие уже даже и не догадываются о чём ты пишешь и чем это от фреймбуфера отличается. Для них «текстовый режим» - это консоль на весь экран с буквами. IMHO vga text mode сейчас остался исключительно 80x24 и эмулируется для совместимости со старьём, для галочки и чтобы был, судя по тому как он тормозит.

Я сам помню как деградировал этот режим. Сначала из бивисов видеокарт пропали text mode больше чем 80x24, затем выпилили vga=ask...

вообще остались «чисто текстовые» режимы, или они эмулируются графикой?

Вопрос содержит фундаментальную ошибку.

«Чисто текстовый» режим возможен при работе с «чисто текстовым» устройством вывода - например, телетайпом.

В IBM PC (так же как в других машинах того времени - ZX Spectrum, Atari, etc) «текстовый режим» - это специальный режим работы видеоподсистемы, позволяющей модифицировать сразу целую область выходного буфера видеопамяти готовым шаблоном с помощью простой инструкции. Как правильно написал Kroz - работа спрайтами.

Подозреваю, что не позднее появления SVGA вся работа осуществляется прошивкой карты. но скорее всего осуществлялось ПЗУ видеокарт еще в эпоху EGA/CGA.

Вопрос опоздал примерно на четверть века.

Но вот вопрос — имеет ли оно вообще сегодня смысл…

Представь ситуацию, твоя система на пороге повисания из-за нехватки ОЗУ.
Для справки скажу что этого можно добиться размещая на tmpfs достаточно крупный фаил.

Так вот, если консоль есть, то ты можешь успеть нажать Ctr-Alt-Fnum и скажем запустить htop или mc, которые сами по себе много места не займут и главное не просят дополнительную память для тех или иных операций.

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

Ну и программы искать с помощью apt list | regexp намного удобнее.

Так что даже если мониторы доброворльно-принудительно поменяют на 3D шлемы чистая консоль всё равно будет нужна.

Вот тут есть описание как можно эту не самую современную видеокарту подружить с 4К. А там в консоли будет автоматически выбран режим максимального разрешения. И там уже будет места куда больше изначальных 25х80. Да и увеличили ограничение в новых ядрах. Так то эмуляторы вроде kitty задействуют графическую карту чтобы текстом пуляться и это вроде как быстрее. Так что такие способы именно текст именно через процессор наверное лишние.

https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en

Вот к стати свежий пример, забил tmpfs до 71,795 items, totalling 1.8 GB (2.0 GB on disk), сижу смотрю ютуб, вдруг вентилятор процессора начинает бешенно крутится, ролик не воспроизводится, интерфейс тормозит, спешно переключаюсь в консоль, спешно набираю mc, буквы появляются с задержкой, сам mc вплоть до убийства файрфокса даже не смог нарисовать свой интерфейс.
Потом я перещёл в другую консоль в которой убил файрфокс по пиду.
После этого вентилятор успокоился, компьютер дальше работает нормально.

Если бы не родная консоль пришлось бы мне кнопку резета нажимать.

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

Эта проблема решается разными способами:

1. Открыть окно менеджера процессов заранее в скрытом виде и показать при вызове.
2. При запуске системы выделить дополнительную балластную память, которая освобождается при вызове диспетчера задач.

Например в Haiku обычно запущен ProcessController через который можно завершить процесс при нехватке памяти.

Представь ситуацию, твоя система на пороге повисания из-за нехватки ОЗУ.

Нормальные системы не зависают при нехватке ОЗУ. В худшем случае malloc/mmap возвращает NULL и программа падает или нормально обрабатывает ситуацию нехватки памяти.

Открыть окно менеджера процессов заранее в скрытом виде и показать при вызове.

Только в такой ситуации может оказаться что ни какое, в том числе и окно диспетчера задач развернуть или свернуть нельзя, или его разворпот приводит к увеличению занятого ОЗУ с последующим параличём системы.

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

Но под консольную утилиту этот резерв будет меньше и более предсказуем.
(Вообще я впервые слышу про такую возможность)

окно диспетчера задач развернуть или свернуть нельзя, или его разворпот приводит к увеличению занятого ОЗУ с последующим параличём системы.

Если используется нормальный GUI сервер и тулкит, то какого не будет. GUI сервер должен быть спроектирован с учётом нехватки памяти как например в Haiku и Windows.

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

Это означает, что в Линуксе делать надёжное GUI не умеют. Не знаю какая ситуация с Wayland, но подозреваю что такая же.

Ну винда к стати тоже так повисала, как сейчас правда не знаю, давно её не использую.

Ну винда к стати тоже так повисала

4.2 же. Встроенный taskmgr по three finger salute отрабатывает всегда. Единственное исключение - смерть видеодрайвера и ядра, но это уже за рамками защиты от user mode.

Чтобы виндовый менеджер процессов заработал, он должен сначала нарисовать окно, а свободного ОЗУ нет.
В принципе часто на его вызове компьютер окончательно и повисал.

а свободного ОЗУ нет

Не бывает такого никогда. Просто убьётся процесс, который не смог выделить память и всё. Windows рулит.

Windows will NOT overcommit memory. This is actually a big difference compared to Linux. Windows «commit limit» is simply the RAM size + the current pagefile size.

как такое сделать в лине?

Вот что гуглится: https://serverfault.com/a/142003

Попробуй…

У современных видеокарт (последние лет 15 и до нашего дня) вообще остались «чисто текстовые» режимы

С ЖК мониторами чисто текстовый режим превращается в тыкву. У него такое разрешение, что найти ЖК монитор с таким разрешением можно и не мечтать. А на чужих разрешениях ЖК мониторы показывают мыло.

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

Ты лучше расскажи как фреймбуфер заставить работать в 4к разрешении.

Наверное, как обычно. Примерно такой ядерной опцией:

video=nouveaufb:4096×3072@60,mtrr=3,ywrap

Видимо, потом придётся самому патчить (если получится). А пока что FullHD наше всё.

А directfb такое не осилит? У меня больше FullHD не получалось выставить. Надо попробовать с nouveaufb, благо карточка nvidia сейчас.

DirectFB давно помер. Его уже давно выпиливают из софта.

А с чего ты взял что причина именно в оверкомите?
Исчерпать память можно и другими средствами.

Причина описанного мной в динамическом выделении памяти, когда процесс берёт ровно столько памяти, сколько ему надо на текущий момент и когда для продолжения работы ему нужна дополнительная память то он уходит в цикл ожидания её выделения, которого не будет никогда, ибо и все другие процессы с динамическим выделением памяти стоят по этой же причине, а вот статические процессы продолжают работу.
Более того, в сумме нужный объём ОЗУ даже может быть и свободен, но память фрагментирована и по этому выделить единый блок нужного размера нельзя_

И именно по этому когда весь гуй стоит я и могу в терминале запустить ‘killall -9 prog_name’.о

он должен сначала нарисовать окно, а свободного ОЗУ нет.

x64:

taskmgr.exe	0.01	6 472 K	12 908 K	2544	Windows Task Manager	Microsoft Corporation

6 472 K - private
12 908 K - shared

Венда резервирует часть памяти специально под задачи блокировки экрана и управления процессами.

Я доводил её до жёсткой нехватки памяти - не отрисовываются пиктограммы на окнах, не запускаются процессы, но taskmgr всегда стартовал.

и когда для продолжения работы ему нужна дополнительная память то он уходит в цикл ожидания её выделения

Это где такое? Только при overcommit. Никто никакие циклы не делает. Если память не удалось выделить, то большинство программ завершается. Показывай где там какие-то циклы ожидания.

Ладно, позорище программисткое.

Вот грузишь ты небольшую програмку которая скажем в совокупности занимает в озу 5кБ. Она там в цикле читает /dev/stty1 и когда там появляется последрвательность fuck она выводит окно с надписью «Fuck message прявился!» и на этом завершает работу.
Вроде как всё просто, но вот на порт пришёл этот фак и надо создавать окно, а там, id окна, координаты окна, размер окна, биты статуса окна, копия текста сообщения, кординаты и статусы кнопки ОК, которая по сути отдельное окно, и куча всего что я не знаю, да и нет смысла перечислять и вишенкой к чему будет буфер в котром всё это окно отрисовывается и всё это занимает явно не один десяток килобайт.

Да хоть 10 терабайт, где циклы ожидания? Программа требует ресурсов для создания окна, если их нет, то всё, хана. Программа умирает.

Смерть программы тоже требует выделение ОЗУ, если только это не kill -9

винда сильно получше в этом плане: если GUI подвис пользователю обычно ничего делать не нужно – либо отвиснет, либо покажет синий экран. тянуться к reset требуется очень и очень нечасто.

А с чего ты взял что причина именно в оверкомите?

Overcommit - это когда программе выделяется больше памяти чем физически доступно (ОЗУ + файл подкачки) и если программа обратится к не выделенной памяти, а выделять не от куда, то будет плохо. В Windows и Haiku нет overcommit и ситуация нехватки памяти обрабатывается лучше.

Более того, в сумме нужный объём ОЗУ даже может быть и свободен, но память фрагментирована и по этому выделить единый блок нужного размера нельзя

Память выделяется страницами (4096 байт) и транслируется с физических адресов на виртуальные, так что фрагментация физической памяти не имеет значения.

Проще разработчиков tracker застрелить чем лечить принудительно борщивиком что гуляющие трекеры надо удалить везде из автозапуска

Ну ХЗ, то что я пишу это то, как воспринимается комп при рулении в состоянии острой нехватки памяти и интенсивном гудении вентиляторов.

Overcommit

Что мешает не делать этот оверкоммит, а просто в рамках динамического выделения ОЗУ поросить выделит дополнительную память, потому де что она стала нужна?

Что мешает не делать этот оверкоммит

Кривые руки разработчиков программ и реализации malloc в libc. Многие кривые программы выделяют много памяти которую потом не используют. В Musl сейчас делают нормальную реализацию malloc (https://github.com/richfelker/mallocng-draft), которая не выделяет память впустую и работает также быстро как актуальные реализации.

Дело не в нерациональном использовании памяти, а в том что вся совокупность запущенных программ и загруженных в ОЗУ данных превысила некоторый лимит.

alt+sysrq+f

и настрой уже cgroup для жручих программ/поставь юзерспейсный oom killer/включи уже свап+zswap