А какой он, этот мифический Unix-way?

Подписался

А какой он, этот мифический Unix-way?

Вот и дожили :)

На каждую функцию своя софтина и всё связано через пайпы и exec()'и. Морда только морда и не более; весь функционал в другом софте.

А как вы подписались? Меня на главную выкидывает.
По теме. Я использую единственный лозунг, который, как я помню, относят к принципам unix-way: если ты этого не знаешь, значит оно тебе не нужно. =)

Нажми «отслеживать».

Говорю же, перекидывает на главную. При этом тема не становится отслеживаемой.

МакИлрой: Четверть века UNIX

Дуг МакИлрой, изобретатель каналов UNIX и один из основателей традиции UNIX, обобщил философию следующим образом:

«Философия UNIX гласит:

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

Обычно эти высказывания сводятся к одному «Делайте что-то одно, но делайте это хорошо».

Из этих трёх принципов только третий является специфичным для UNIX, хотя разработчики UNIX чаще других акцентируют внимание на всех трёх принципах. Майк Ганцарз: Философия UNIX

В 1994 году Майк Ганцарз (англ. Mike Gancarz) объединил свой опыт работы в UNIX (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями программистами и людьми из других областей деятельности, так или иначе зависящих от UNIX, для создания Философии UNIX, которая сводится к 9 основным принципам:

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

Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):

Позвольте пользователю настраивать окружение. Делайте ядра операционной системы маленькими и легковесными. Используйте нижний регистр и придерживайтесь кратких названий. Не храните тексты программ в виде распечаток («Спасите деревья!»). Не сообщайте пользователю об очевидном («Молчание — золото»). Разбивайте сложные задачи на несколько простых, выполняемых параллельно («Мыслите „параллельно“»). Объединённые части целого есть нечто большее, чем просто их сумма. Ищите 90-процентное решение. Если можно не добавлять новый функционал, не добавляйте его («Чем хуже, тем лучше»). Мыслите иерархически.

Реймонд: Искусство программирования в UNIX

Эрик С. Рэймонд (англ. Eric S. Raymond) в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию «Будь попроще, тупица» (Принцип KISS). Затем он описал, как эта обобщенная философия применима в качестве культурных норм UNIX. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии UNIX:

Правило модульности: Пишите простые части, соединяемые понятными интерфейсами. Правило ясности: Ясность лучше заумности. Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами. Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine). Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо. Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся. Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки. Правило надёжности: Надёжность — дитя прозрачности и простоты. Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной. Правило наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей. Правило тишины: Если программе нечего сказать, пусть лучше молчит. Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее. Правило экономии: Время программиста дорого; сократите его, используя машинное время. Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы. Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте. Правило многообразия: Отвергайте все утверждения об «единственно правильном пути». Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

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

Бага видимо, отпишись maxcom и hizel.

Мм.. а ничего что этой писанине 50 лет ? Прогресс в умах остановился и в башке только талмуд ?

0) Морда в одной софтине, сам загрузчик в другой, конфигуратор - в третьей. 2) В .config/softname 4) Должны присутствовать те, которые поставил пользователь. 5) Сейчас вроде все правильно происходит. *DM запускает окошко логина, из него запускается окружение, которое запускает отдельные процессы для панельки и прочего.

Укажите пункты, которые до сих пор недействительны. Вашему дедушке тоже небось за 50, вы же не собираетесь его на свалку выкидывать как устаревшую модель?

Такова парадигма, она и не должна меняться каждый год.

Так юниксвейным только lfs может считаться, ну и генту(etc) и арч, т.к. конструкторы.

2) Как должны храниться конфиги по Unix-way?

Так же как они зранятся сейчас, в текстовых файлах.

Ну да.

текстовый файл текстовому файлу рознь, xml считаем unix-way?

Так же как они зранятся сейчас, в текстовых файлах.

Да, Gnome тому подтверждение, XML реестр это простые текстовые файлы.
Т.е. Gnome не unix-way?

0) sysvinit
1) daemon start/stop, service start/stop, /etc/rc.d/service start/stop
2) в ~/.progname/conf
3) POSIX ++
4) те, что нужны, должны присутствовать, лишние - нет
5) login [ + startx] или через dm

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

Загрузчик по Unix-way?

программа

2) Как должны храниться конфиги по Unix-way?

plain text. Внутри можешь делать yaml, xml, ini, whatever, можешь если хочешь кешировать в бинарь, но обновлять при изменении файла.

3) Какой должен быть IPC по Unix-way?

обычный способ это pipe и plain text, но фанатичность тут не обязательна, любой другой вариант сокеты, dbus и прочий не требующий специальной магической библиотеки.

4) Какие утилиты должны присутствовать в системе, а какие не должны, по Unix-way

это ортогонально unix-way

5) Как должен запускаться сеанс пользователя (панелька, рабочий стол, плазма, т.п.) по Unix-wa

это ортогонально unix-way то тут интересно почитать Витуса Вагнера, про его взгляд на DE.

Надо бы поднять статистику по организациям, участвующим в разработке ядра linux. А то мне что-то кажется, что указанные дистрибутивы, если и присутствуют в списке, то плетутся где-нибудь в конце. Получается такой унылый, никому не нужный unix-way, духом которого провоняли лиш некоторые красноглазые дистрибутивы.

2) в ~/.progname/conf

кстати ~/.config/progname/ было очень логичной идеей.

ls-h
xml я лично считаю unix-way.
Но предлогаю прикастовать олдфагов, а конкретнее KRoN73.

предлагаю тебе поднять и посмотреть :) а так же по патчам людей работающих с этими дистрами.

В этом нет ничего нового, ибо вообще ничего нового нет.

каждая утилита занимается одной вещью и делает это хорошо

--> Emacs не unix-way. Столлман противник Unix-way'я.

Только если эта progname не мусорит еще по всяким ~/.local/share и т.п.

xml я лично считаю unix-way

Хранить конфиги в формате, недоступном человеку для непосредственной правки/чтения, вряд ли можно назвать unix-way

В общем то со всем согласен, ни арч, ни гента вроде в ядре и других проектах ничем не занимаются, только всё собирают.

emacs не unix-way — на мой взгляд да, но лучше юзеров спросить

Столлман противник Unix-way — нет, хотя если бы и был, то это ничего не меняет, Столлман в первую очередь апологет GPL, а не юникс-вей.

xml как раз можно читать/править. Не слишком удобно, но можно.

в xdg-directory чётко прописано, где должна мусорить прога, что стоит кешировать, а что чистить :) вроде всё логично

Присоединяюсь в Eddy_Em.
Мне больше идея JSON нравится, как и косом относящаяся к ней гомоиконность. Ведь практически любой ЯП использует данные и функции, почему бы не выделить для формата данных то, как в этом ЯП данные записываются.

Столлман в первую очередь апологет GPL, а не юникс-вей.

столлман на тему юниксвея писал, что-то вроде «юникс далеко не идеал, но и не совсем говно, так что решили ориентироваться на него»

А на тему емакса было много споров, кто-то (уже не помню) писал, что это просто другой уровень: емакс - это система, а отдельные его расширения - отдельные компоненты этой системы, аналогично шелл-скриптам

Мне больше идея JSON нравится

как у него с валидацией?

Ведь практически любой ЯП использует данные и функции, почему бы не выделить для формата данных то, как в этом ЯП данные записываются.

здравая идея, но далеко не все и далеко не всё пишут на js

Насчёт валидации что имеется ввиду? Есть ли тулзы?
Что мешает json в других языках использовать, мейнстримные языки большей частью основаны на С, да и довольно простой синтаксис сам по себе.

так и личкрафты unix-way. имхо, если расширения можно оттуда выдернуть или заменить на другие/включить другие программы, то это unixway.

xml как раз можно читать/править. Не слишком удобно, но можно.

Не хочу троллить,но мастдаевский реестр тоже можно можно читать/правит. Не слишком удобно, но можно.

Настройки должны быть в текстовом виде. Как список «параметр = значение».

Да и в бинарном виде можно. Ассемблер будет.
Но видимо *предки* имели ввиду и xml и json под текстовыми, так что они кошерны.

А что делать, если параметр будет массивом, или списком?

он же вообще бинарный…

очевидно, что данный вариант покрывает не все возможности. И зачастую приходится использовать более сложные варианты такие как свой язык конфигов или готовые языки и технологии yaml/xml/source-code. Логично, что в зависимости от задачи выигрывать может тот или иной вариант. В любом случае это unix-way, но тут нужно не забывать и про KISS.

Параметр = [элемент0, элемент1, элемент2]

или так:

параметр = { "элемент0", "элемент1", …}

Насчёт валидации что имеется ввиду? Есть ли тулзы?

Тулзы - вторичны. В XML указывается DTD, который можно использовать для проверки корректности документа (а не только синтаксиса). У JSON аналог есть?

Что мешает json в других языках использовать

да и довольно простой синтаксис сам по себе.

тогда каким боком гомоиконность?

мейнстримные языки большей частью основаны на С

- ерунда

- при чем тут C?

Зумель зато оче юниксвейно можно внешней утилитой редактировать, с гарантией что на выходе будет нечто валидное. А для NIH-формат конфигов нужны сотни sed'а с awk, да и рухнет все от первого же чиха.

1) daemon start/stop, service start/stop, /etc/rc.d/service start/stop

Не с т.з. пользователя, а с т.з. системы. Должны быть скрипты или что-то вроде systemd?
Почему systemd не unix-way? Ведь он выполняет одну работу - управляет службами.

вот и появляется нужда в json, или libconfig.

любым текстовым редактором?

Скрипты.

Почему systemd не unix-way

потому что объединяет в себе уйму всего. И не нужен.

а если будут вложенные массивы/списки?