Freedom to change

[vitus_wagner]

Вот смотрю я на развитие проекта Devuan и думаю, что форк без systemd это, конечно, благая идея. Но если не отказаться от GTK и Qt, создать систему в которой от использования GUI будет легко перейти к его модификации, не получится.

Comments

[balu]

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

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

Кстати, цитата с багзиллы системд только по федоре: This list is too long for Red Hat Bugzilla's little mind; the Next/Prev/First/Last buttons won't appear on individual bugs.

[vitus_wagner]

systend это бинарная монолитная фигня. Ей не может быть удобно польщзоваться. потому что она использует для чтения логов не штатные средства обработки текстов, как было в нормально Unix, а СПЕЦИАЛЬНЫЕ КОМАНДЫ.

Проблема именно в этом. Что вместо грамотного использования средств общего назначения, заводятся специальные API, специальные команды etc. В системе не должно быть "черных ящиков". Любой компонент должен быть пригоден для того, чтобы открыть крышку, заглянуть и разобраться как работает. Подправить при необходимости.

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

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

[balu]

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

И за этот год он забывает синтаксис специальной команды.
Если пользователь умеет грипать, то он не перетрудится и от man-а раз в год.

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

----------
* - А если совсем по-уму, то положить метаинформацию рядом с текстовым логом и писать их паралельно.

[vitus_wagner]

> А без них в нашем деле пока никак.

А вот тех, кто умножает их количество нужно курощать и низводить.


Причем тех, кто делаает это в проприетрном софте - финансово. А кто в опенсурнсом репутационно.

Мне, честное слово, жалко что Поттеринга не довели до самоубийства.

Тех кто предлагает маны читать грепом тоже нужно бить больно.

Тексты нужно писать для читания подряд. Чтобы было интересно и из прочтения запоминалась логика.

[balu]

А вот тех, кто умножает их количество нужно курощать и низводить.
Хм... по-моему проще воспользоваться маленькой специализирванной утилью, чем писать многобукв. Вот на конкретном сислоге. Часть пожата гзипом. Часть сообщений разбросанно по разным файлам. Как без многобуков сделать grep по дате/службе?

Тех кто предлагает маны читать грепом тоже нужно бить больно.
А кто и где предлагает?

Кстати, я по пальцам могу пересчитать интересное профчтиво.

[vitus_wagner]

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


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

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

[balu]

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

Эту позицию я полностью поддерживаю. Но: в никсы уже понабежали толпы леммингов, которым это не близко и котрые даже со stackoverflow невнимательно копипастят. Т.е. видение уже даже не фрагментарное. И о каком продумывании архитектуры и знании общих принципов у таких может идти речь? И ХЗ как к этому приспосабливаться.

[vitus_wagner]

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

[balu]

системд и есть ниша для всех. И мы в ней сидим и обдумываем, как лучше сделать систему для умных.

[balu]

Я понял в чем у нас тут несостыковки:
1) я не предлагаю читать маны грипом. Имелось в виду, что читать лог будет кто-то, кто уже знает команды grep и man.
2) да, то, что для чтения лога требуется специальная утилита, это плохо. Но тут есть пара нюансов. Во-первых часть лога у нас и так бинарная и требуется утиль для его извлечения в текст. Во вторых, необходимость утилиты компенсируется ее удобством для админа. Собственно, более удобный инит и эта утиль и решили дело в пользу системд.

Есть вариант, как отплеваться от системд? Есть. Сделать нормальный инит и утиль для логов, но уже с учетом косяков системд, но с его плюшками.

[vitus_wagner]

Нужно не делать нормальный init, нужно делать нормальную сессию. Обобщить понятие сессии и группы процессов так, чтобы им было удобно пользоваться для работы в desktop environment и для демонов. Потому что последовательные терминалы, под которые оно остается заточенным, мертвы давно.

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

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

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