От systemd он, скорее всего, не зависит — можно предположить, что всё дело в logind. Хотя, опять же, это догадки.

UPD: судя по Makefile, ни от чего он не зависит.

Нормальные шрифты (начиная с юникода: в ядерном терминале его нет)

И давно ядерная консоль разучилась юникод?

Надо признать, я в input layer не разбираюсь...

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

kmscon в initramfs.

Ну да, согласен.

А кто в итоге это стартовать будет всё? Я так понимаю, что сейчас systemd просто выводит текст на VT, который запускается непосредственно ядром.

Так же, как я понимаю, сейчас в initrd стартует свой systemd, который всё монтирует и передаёт ядру, которое запускает уже другой systemd.

Кто будет запускать consoled в таком случае? На ум приходит только перезапускать consoled после загрузки ядра. Или он как-то хитро может передать сервисы?

Отлично! Как мне поставить этот терминал без хттп сервера и генерилки картинок?

Если китайские линуксоиды так сильно страдали без возможности набирать и отображать иероглифы в ядерной консоли, что ж они раньше это не реализовали самостоятельно? Или можно показать ссылочку, где они слёзно просят того-кого-нельзя-называть запилить им эту фичу?

С другой стороны, если CONFIG_VT будет выключен, а юзерспейсная реализация от сабжа внезапно сегфолтнется, то всё, компьютер превращается в тыкву при работающем ядре, поможет только reset

И давно ядерная консоль разучилась юникод?

С рождения.

Костыли вроде terminus'а с глифами из koi8-r, переведёнными в юникодные codepoint'ы — не поддержка юникода. В этих шрифтах отродясь не было больше 512 символов. В районе 2.6.x была ровно одна попытка заставить ядро уметь настоящие юникодные шрифты хотя бы с фреймбуфером, она быстро провалилась, вскрыв тонну багов в терминале из CONFIG_VT. А в VGA-режиме ты не можешь больше 512 символов, не меняя прошивку видеокарты.

Так же, как я понимаю, сейчас в initrd стартует свой systemd

Зачем сразу целый systemd, если ты не собираешься использовать logind и прочее? А маленький init там всегда был.

судя по Makefile, ни от чего он не зависит.

По ссылке в новости

The systemd-consoled binary should be run as `systemd --user' unit.

Уверен, что ни от чего не зависит? Возможно, он dbus активно пользует, и не факт, что без него сможет.

А от logind зависимость ещё хуже, чем от systemd. logind в initrd нет смысла запихивать.

Давай без троллинга. Моё мнение о нужности сабжа основывается на других вещах. В основном — на том, что эмулятор терминала в юзерспейсе куда более просто поддерживать и допиливать (в частности, этот самый CJK ввод),чем в кернелспейсе.

Во-вторых, эмулятор терминала в юзерспейсе в составе systemd — это менее bloated, чем в составе ядра. Как минимум по следующей причине: в составе systemd это отдельный бинарь, а в составе ядра это часть ядра (т. к. CONFIG_VT=y).

Тебе перевести слово should?

Я правильно понимаю, что это решит проблему с неродным разрешением монитора в терминале при использовании проприетарных драйверов nvidia?

Это не зависимость, а предпочтительный способ запуска. Дальше — не знаю.

Нет. Это не имеет отношения к режиму фреймбуфера.

Тебе смотреть в сторону uvesafb.

Зачем сразу целый systemd, если ты не собираешься использовать logind и прочее?

Ну там сильно кастрированный, но systemd можно использовать. Новости были о том, что когда в initrd запилили systemd, то смогли загрузиться быстрее, чем вообще без initrd.

Беглый анализ кода показал, что он зовёт logind по шине. Хорошо это или плохо — не знаю. По крайней мере, техническая причина для этого понятна: DRM-ноды (видеоадаптеры) могут появляться динамически и в произвольное время. Каждый видеоадаптер — это новый сит. В systemd слежением за ними занимается logind.

Ну тогда ждём в fedore.

Хорошо это или плохо — не знаю

Ну с точки зрения проблем с запуском logind - очень плохо. В initrd тоже какую-то консоль надо запихнуть.

Ну с такими очевидными проблемами они должны были fallback-режим без logind(без dbus?) предусмотреть.

Умеет xkb и рендеринг через DRM.

Ух ты, ждемс.

Для кедарастов-мышевозов может и ненужная.

Типа, теперь никакой консоли не будет пока systemd не разогреет свое гомно, поэтому если у кого-то какой-то косяк при загрузке, он его на консоли более не увидит, поскольку и самой консоли тоже не будет. Это перемога, однозначно.

отож :)

я о чем говорю

О, вот кстати интересный вопрос - а как теперь fsck пускать?? Или типа «оно будет пускаться само, а если не восстановилось в автомате, считается к восстановлению непригодной»?

CONFIG_VT=n никто не заставляет. Всё это пока что сугубо экспериментально. Не надо FUD, пожалуйста.

Когда они выпилили forcefsck я молчал...

Всё верно, функционал fsck будет частично реализован в systemd-fsckd, если не восстановилось, юзер должен будет переустановить свой линукс, а те, кто попытаются воспользоваться fsck - ретрограды

Нужно больше говнокода. Быстрее рипнется.

forcefsck? Ты серьёзно? Монтировать повреждённую ФС в режиме read-write — нормально? fsck.mode=force концептуально правильнее.

Embrace, Extend, and Extinguish во всей красе. LOL

А как всё мило начиналось... «мы только напишим новый init и всё...», «а теперь мы тут добавим маленький xyz» ... «и ещё один маленький uvw» ... «и ещё один маленький abc» (А чё? всё равно всё в одной кодовой базе, чёб не добавить?!) ... «Так, дорокие мои, а не пошли бы вы все подальше — у нас тут теперь своя песочница!»

All your base are belong to us! Жрите, чё дают! Мухаха... :(

кедарастов

Всегда забавляли люди, не любящие kde, и в тоже самое время защищающие systemd.

Хватит, а? Запилили экспериментальную тулзу — всё, ппц, жизнь кончилась.

Перед тем, как выпиливать CONFIG_VT (если это вообще произойдёт) сабж десять раз отполируют, запилят какой-нибудь минималистичный режим для initramfs и так далее. И то в ваших дебианах с рхелами это появится хорошо если через пять лет.

С другой стороны, если CONFIG_VT будет выключен, а юзерспейсная реализация от сабжа внезапно сегфолтнется, то всё, компьютер превращается в тыкву при работающем ядре, поможет только reset

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

И кто её перезапустит? А если перезапускалка тоже упадёт?

systemd? потому что consoled отдельный демон?
если перезапускалка упадёт, то плохо, конечно.
но ядро линукса монолитное, и когда падает что-то ядерное, падает всё. а вынос чего-то в юзерспейс - это плюс к надёжности.

А если ядерная реализация VT упадёт.

ядерная реализация консоли не пытается юникод полностью поддерживать, потому и мест для возможного падения в ней меньше

она проще, чему там падать

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

Ну а сабж не на С что ли? :)

Когда ты последний раз видел падение ядра в коде VT?

Сабж приближает к всеми любимому микроядру.

Не хочу с тобой спорить. Дело как бы не в этом. Если глянуть на вопрос чуть шире, то и в самом деле просматриватся старый метод мелко-мягких. Это то мне и не нравится.

Надеюсь не увидеть, и сабж в этом должен помочь.

к всеми любимому микроядру.

4.2

Т.е. раньше ты линуксом не пользовался?

Лет десять назад нет, а что?

Подожди. Допустим, Embrace есть. Я не понимаю, как можно осуществить Extend и Extinguish, оставаясь при этом СПО?

ненужно

одно упадёт -> всё упадёт

говоришь словно юзаешь микроядро с модульной либц

В консоли не только комманды набирают

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