Разработчики популярного дистрибутива Arch Linux объявили о переходе на систему загрузки SystemD. Новая система имеет более продуманную конструкцию, предоставляет больше административных возможностей и, что самое главное, позволяет существенно быстрее загружать операционную систему.
Полный список отличий SystemD от старой системы загрузки можно найти здесь. Из списка видно, что SystemD превосходит и относительно новую систему Upstart, разработанную Canonical и применяемую в современных версиях Ubuntu.
Да уж, прогресс. Бинарные логи и слияние с менеджером устройств. Арч деградирует. Единый конфиг поломали, установщик убрали, образы урезали до неприличия. Пора драпать. Только вот некуда.
Факты остаются фактами: юниксовые идеологии разработки мелких программ, которые "каждая делают свою работу" и "хранения всего в строках" уже не оправдывают себя.
Во-первых, с мелкими программами очень сложно проводить координированное внедрение необходимых возможностей (а они всё чаще требуют изменения не одного, а нескольких компонентов системы). В случае с объединёнными, или хотя бы разрабатываемыми одними разработчиками, подсистемами добавление таких возможностей не составляет труда, в отличие от.
---------------------------------
Во-первых, чего плохого в "бинарных логах"? Работа с ними будет происходить значительно быстрее, т.к. вместо работы со строками будет происходить работа с намного более "родными" числовыми параметрами. Этим снимаются значительные затраты ресурсов. Софт же, их создающий, будет следовать указанному формату, что значительно облегчит работу с ними.
(Windows, кстати, хранит свои логи в бинарном формате, который через Event Viewer смотреть значительно проще, чем текстовые логи.)
---------------------------------
Когда тот же Microsoft писал ветку NT, они хотя бы сделали однообразный метод доступа ко всем _системным_ настройкам, причём даже работающий по сети -- консоль MMC. Причём написали они её так, что внешние разработчики вполне могли добавить в неё свои "оснастки". И получился инструмент настолько мощный, что не знающие о его существовании люди до сих пор говорят о сотнях "скрытых настроек в реестре Windows" -- хотя все они доступны через эту самую консоль.
А у нас для редактирования приходится вместо графической однообразной консоли MMC использовать текстовую консоль линукса, редактируя конфиги, которые все обладают разными форматами.
Кому как. Мне поиск по текстовым логам с помощью grep кажется более удобным. К тому же, текстовые логи и более практичны. Например, если система, простите, нае...бнется, то можно загрузиться с LiveCD и сразу начать расследование инцидента, а не думать чем бинарники ковырять.
Не понял мысли. Поясните, если не трудно. Пример из практики тоже лишним не будет.
... до сих пор понять не могут как этот постоянно раздувающийся системный реестр можно почистить от мертвых данных. Если в Линуксе программа насрала конфигом в /etc и после удаления не убрала за собой, то можно по ее названию найти нужный конфиг и зачистить его. А вот обходить все ветки реестра Windows в поисках какашек - то еще удовольствие. Поэтому народ предпочитает не связываться с этим настолько мощным инструментом и сносить вместе с ним всю Винду.
Почему приходится? Вас кто-то заставляет? Крепостничество, вроде как, отменили и каждый волен использовать именно те инструменты, которые кажутся ему наиболее удобными.
Давайте не будем лукавить, редко когда откроешь конфиг и сразу не выезжаешь в синтаксис. Говнистый формат конфига могу припомнить только у Sendmail, там разработчик постарался на славу и нагадил от души.
>> Кому как. Мне поиск по текстовым логам с помощью grep кажется более удобным. К тому же, текстовые логи и более практичны. Например, если система, простите, нае...бнется, то можно загрузиться с LiveCD и сразу начать расследование инцидента, а не думать чем бинарники ковырять.
У текстовых форматов есть одна большая проблема -- использование строк там, где не надо, накладывает большой оверхед при создании работающих с такими данными скриптов.
(И да, я почему-то уверен, что уже есть программа, конвертирующая бинарные логи systemd в текстовый формат.)
Во-вторых, бинарные логи в линуксах уже есть. Например, лог wtmp, который читают (и преобразовывают в текстовый формат) программы last, who и другие.
А через эдак годик, когда systemd будет принят повсеместно, софт для чтения бинарных логов systemd тоже будет наличествовать в большинстве LiveCD.
-------------------------------------------------------------------------
Тут, кстати, стоит заметить предложение о переработке использования юниксовых пайпов, разрешающее софту передавать данные не только в виде строк, но и в виде произвольных структур (в т.ч. в двоичном виде). И их старая функциональность, стоит заметить, никуда не уйдёт. В результате обрабатывать их содержимое будет значительно проще.
Вам жалко несколько процессорных тактов ради удобства пользователя? :) Если бы была хоть какая-нибудь заметная выгода от бинарных форматов в плане производительности, то мы бы не наблюдали победное шествие таких форматов, как HTML, XML и т.п.
>> Вам жалко несколько процессорных тактов ради удобства пользователя? :)
Это же какой у вас "пользователь", что ему надо смотреть содержимое логов системы?
Если же серьёзно, то systemd'шный лог можно легко показать как текстовый одной командой:
# journalctl(А добавив параметры к этой строке, можно легко сделать фильтрацию по параметрам без всяких grep. В том числе параметрам, в текстовом логе не отображённым.)
И кстати. БОЛЬШЕ всех выгадает в этом случае не столько программист, сколько пользователь. Объясняю, почему.
С использованием текстовой выдачи данных, программист, пишущий скрипты, может использовать самые разные методы для выбора нужных ему данных из строк -- он может выбрать нужные ему столбцы через аргументы и использовать только их, а может взять их из списка столбцов через кол-во позиций (т.е. от-scanf'ать нужные столбцы согласно тому, как они расположены.) И если программист решился на второе (а иногда это бывает нужно), то автор первой программы уже не может поменять формат вывода (например, добавить столбец или сделать формат какого-либо из них более удобным -- например, размер файла в ls -l размещать ИЗНАЧАЛЬНО в байтах, а не в блоках, не требуя ключ -h.)
Если же софт будет пайпать не строки, а структуры и объекты, то внутри этого софта будет значительно легче добавлять новые поля или изменять формат старых. А пользователь сможет получать данные не в формате, задуманном в 198-каком-то году, а в соответствующем последней версии этой программы.
>> до сих пор понять не могут как этот постоянно раздувающийся системный реестр можно почистить от мертвых данных. Если в Линуксе программа насрала конфигом в /etc и после удаления не убрала за собой, то можно по ее названию найти нужный конфиг и зачистить его.
Единственная часть реестра, согласно которой я могу с вами согласиться, это когда в реестре начинают появляться всякие CLSID. У остальных ключей в реестре вполне очевидный формат, несколько даже совпадающий с форматом
HKEY_CLASSES_ROOT = смесь /usr/share/applications и /usr/share/mime/ .
HKEY_CURRENT_USER/Software = ~/.config (или другие папки на .)
HKEY_LOCAL_MACHINE/Software и HKEY_LOCAL_MACHINE/System/CurrentControlSet = /etc/.
(Там есть ещё другие ControlSet. Они предназначены для загрузки "последней удачной конфигурации". Жаль, что похожей фичи (восстановления /etc/ при неудачном запуске) нет ни в одном дистре линукса. )
HKEY_USERS/ - то же самое, что HKCU, только для других юзеров.
Хотя отсутствие в винде единой системы репозиториев, благодаря которой нельзя узнать, кому принадлежит какой-то файл или ключ реестра, конечно, тоже неприятно.
>> Почему приходится? Вас кто-то заставляет? Крепостничество, вроде как, отменили и каждый волен использовать именно те инструменты, которые кажутся ему наиболее удобными.
Потому что других инструментов для редактирования конфигов данного ПО пока что нет :(
И собственно, отсутствие этих инструментов -- одна из основных причин, по которой Windows Server имеет уже почти половину рынка серверов, отвоёвывая уже те места, где юниксы и линуксы были всегда. (Хотя поддержку Exchange и SharePoint тоже не надо забывать.)