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

Все равно лишнего до хрена.

А это и есть почти что json

ага
json + бюрократия == xml

KDE очень даже юникс-веен.

Гном — это, скажем мягко, не часть линукса.

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

Пока что его единственной крупной победой является слияние с udev (и тот можно собрать без systemd). Пользуйтесь нормальными дистрами и нормальными DE и нерабочая хернь от Леннарта вас не коснётся. :)

Расскажите, какой дистрибутив вы считаете нормальным. (См. ниже.)

А теперь мы внимательно слушаем рассказ о том, чем именно Win7 юникс-вейнее линукса.

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

А теперь ответьте, почему каждый дистростроитель по 100500 раз перепаковывает один и тот же софт год за годом? Зачем это нужно? И почему даже в этом случае я не могу поставить приложение и быть уверенным в том, что оно будет актуальной версии? (Предложите debian sid? Это смешно.)

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

А это и есть почти что json

Ну и нафига тогда выдумывать чтото странное? Сказал бы json а не выдумывал модификацию ini... json хорош как компромисс между машино и человеко читаемописаемостью.

когда не было ничего кроме plain text

Вообще говоря бинарные конфиги и вообще все - тотальная мода ДО появления юниксов :D Юникс был первой ОС где в дистрибутиве *все* было в виде текста. :D

Сказал бы json а не выдумывал модификацию ini

Просто мне нравится именно такой синтаксис.

Чтение конфигов - это где-то 0.001 процент от времени работы приложения. А вот удобное редактирование куда больше времени составляет. В Apple это просекли и сделали няшный plist, в результате чего настройки можно прямо из командной строки менять у любой софтины.

Просто мне нравится именно такой синтаксис.

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

Чем вот такой вот xml нечеловекочитаем? Или может неисправляем? Это от одного моего проекта конфиг

Тем что там сплошная куча мусора на глаз. вот это:

DistrCode=C7501
SAPNumber=104447

гораздо лучше читается человеком.

У вас единственный аргумент по сути - скорость начальной загрузки, при чем какая то долесекундная разница. Зачем в 21 веке скорость начальной загрузки когда у всех неретроградов есть suspend/resume - непонятно.

Мда…

Зачем в 21 веке скорость начальной загрузки когда у всех неретроградов есть suspend/resume - непонятно.

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

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

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

В дополнение сложного параметра: Нужно мне было дерево хранить... В хмл сплошное удовольствие, а делал тоже самое для конфига ключ-значение чуть не охренел от Root01..99 Leaf01..99 Level2Leaf01..99

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

То есть проблема в том что suspend кривой. Ну так давайте реальные проблемы решать а не дурью с наносекундами чтения конфигов маятся.

Нужно мне было дерево хранить...

Тут главная проблема в том что надо для себя решить - что именно нужно.

json читается человеком легче , xml тяжелее но это именно форматы по факту для человека не предназначенные. Это форматы где человек может чтото поправить или куда то глянуть, но в 99% случаев они именно для чтения-записи программой. К такому конфигу совсем другие требования

Если же вы планируете конфиги именно *удобные* для редактирования человеком, конфиги где это приоритетная задача(а не как в xml) , то нужно «свой формат». Естественно без лишних инноваций, но это должен быть формат где максимально лаконично и читабельно записана ваша конфигурационная мысль.

И да - это сложнее. Основная же причина бинарных конфигов в том что если в ТЗ нет удобства для чтения / записи конфига человеком и для переносимости формата конфига, то дампать/читать бинарь *гораздо* проще программисту. Особенно на этапе разработки и особенно если (как в случае венды) нет под рукой годных сеарилизаторов. Тем более что конфиг часто плавно переходит в данные для обработки.

PS
Глубокое дерево в конфиге можно хоть json вставками делать (примерно как предлагает Эдди, но без самодельного выеживания), все равно скорее всего глубокое дерево - признак того что где то проблемы в дизайне конфига. Делать деревья при помощи keyvalue это конечно же криво.

Что «все» , elf тоже текстовые ? :-) Да нет, спор сам по себе отвергает банальную вообще то мысль что если конфигов много, а сейчас их несравнимо больше чем на pdp :-) проще, удобнее и быстрее хранить их именно в бинарнике в одном месте. Когда конфигов было полторы штуки текстовые были удобнее, сейчас, увы , это уже анахронизм из талмуда.
Не все плохо в виндах :-), а хорошую идею можно стырить откуда угодно. Когда в досе autoexec.bat и config.sys были от силы в большинстве случае строк 10-20 естественно никакой бинарник там был не нужен, как и в винде 3.1 где было ну строк 100-150, когда в винде 95 эти конфиги разрослись неимоверно, приняли вообще то правильное решение перевести постепенно из все в бинарник.

Почему под линуксом нормально работающий цветной фотопринтер превращается в унылое никому не нужное барахло?

Потому что в Linux каждый находит то, что ему нужно. Вот, например, тебе нужна причина для нытья - ты ее нашел.

Тоже удобно, но ведь Ъ, бб :-), все что от билли или гейтса априори г..

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

Все очень просто. Unix-way это разработка софта таким образом чтобы из него можно было 'компилировать' (к компиляторам езыгов программирования отношения не имеет) нужные тебе системы.

То есть абстрагируясь от религиозных войн и сенситивных областей - например ты разрабатываешь некую большую систему. Если результатом твоей разработки является некий набор модулей и здоровый 'деплоймент дескриптор' реализующих композицию этих модулей так что получается некая система, и если нужно - то в этот дескриптор можно залезть грязными лапами и изменить композицию как нужно тому кому оно досталось - или даже ты само можешь таким способом создавать варианты системы - твоя система написана в рамках философии «unix-way». А если в результате твоей разработки есть один эхешник который запускает мегасистему которая умеет все включая кофе, но только так как задумал девелопер и три галки в менюшке опшенс - это не unix-way. И вообще говно.

гораздо лучше читается человеком.

Пока не приходят глубокие иерархии и повторяющиеся паттерны.

Глубокое дерево в конфиге можно хоть json вставками делать

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

В XML изкаропки идет куча технологий под это заточных - x:include, namespaces, validation, etc. То есть беря весь стек искаропки малыми усилиями можно получить кучу всего, чего в JSON надо велосипедить, а многое просто генетически невозможно.

все равно скорее всего глубокое дерево - признак того что где то проблемы в дизайне конфига

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

просто xml позволяет в будущем масштабировать конфиг для более сложных вещей, которые были не нужны на начальном этапе. А если изначально выбрать Key=Value конфиг, то при изменении ТЗ через год придется много переписывать.

Что «все» , elf тоже текстовые ? :-)

А что, тогда были ELF? Вы таки я смотрю к нам прямо из альтернативной вселенной. :D

Да нет, спор сам по себе отвергает банальную вообще то мысль что если конфигов много, а сейчас их несравнимо больше чем на pdp :-)

Так и pdp гораздо менее мощная машина чем современные компьютеры. Отношение конфиги/мощность сейчас упало до плинтуса по сравнению с теми временами, а не возросло. Сейчас все должно быть текстовым, вообще, если так смотреть .... (waitohshi111 - perl,python,php)

Проблема в том что мощности возросли - а погроммисты в среднем отупели. Отчего у нас и реестры .... :D

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

Во первых, не «проще и удобней», а устарело гораздо более чем «крайне прогрессивный» способ из 70-х, текстовые конфиги. Вы приходите сюда со своими ламповыми эниваками и ну рассказывать про «прогрессивные» технологии бинарных конфигов полувекой давности. Вы поймите, мир со времен бинарных конфигов 60-х далеко ушел вперед :D

(И в этом кстати вся микрософт - изобретают интернет после того как он уже стоит на компьютерах всех более-менее разумных людей)

Не все плохо в виндах :-), а хорошую идею можно стырить откуда угодно.

Зачем тырить устаревшие идеи? Они уже есть во всех учебниках. Но, я понемаю, «прогрессивные» идеи из 60-х это так инновационно. Скоро вы узнаете о микроволновках и микрочипах... о ужас. Кстате человечество уже побывало на луне :D

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

Когда в досе autoexec.bat и config.sys были от силы в большинстве случае строк 10-20 естественно никакой бинарник там был не нужен, как и в винде 3.1 где было ну строк 100-150, когда в винде 95 эти конфиги разрослись неимоверно, приняли вообще то правильное решение перевести постепенно из все в бинарник.

В винде такое решение приняли не потому что конфигов стало много, а потому что программисты MS в условиях MS просто ниасиливали более совершенные технологические решения. И делали как могли, через опу - бинарно.

Тут как бы их надо порнять - что прикажете делать если у вас в компании «ниасиливают» более прогрессивные методы? Очевидно что надо делать древним способом, криво и через опу - но зато можно захватить рынок и заработать денег. Не надо делать хорошо - надо делать плохо: альфа и омега технологического бизнеса :D

А критично для многих, которые задержек не любят.

Перестаньте передергивать - тут вот вы плавно перешли от старта системы к старту приложений.

Много причин почему виндовые прог стартуют быстрее, но одна из них это бинарный реестр.

Причина быстрого старта - это оптимизации на быстрый старт, включая загрузку приложения заранее в бекграунде. А в бекграунде - что бы замаскировать крайне тормозной старт винды как системы :D

Кста, если конфиги гнома или кед перевести в бинарник улучшение будет больше долей секунды :-)

Это можно сделать безо всяких бинарных конфигов - но на это нет средств. Включая предварительную загрузку приложений. :D А в винде на это средства есть - вот и вся разница :D

PS
А что бы документы OO быстро как в винде открывались, надо просто в документы кэш блоб пихать, как это делает венда - и все будет летать :D

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

У JSON есть пара фундаментальных проблем прямо не решаемых, которых в XML например нет.

Вполне логично. JSON прост как три копейки, а XML как множество технологий - это гребаный монстр.

Невозможность фрагментации,

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

ссылок, втавок чуждого конфига и т.д.

Если добавить это все - получится XML. С его монстровидностью.

а так же отсутствуют изобретаемые технологии но почему-то до сих пор не изобретенные.

А?

В XML изкаропки идет куча технологий под это заточных - x:include, namespaces, validation, etc.

В json это все на уровне приложения. Никто не мешает делать include json под-объекты.

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

Генетически там почти все возможно - но опять получится XML.

PS
Я тут недавно узнал с удивлением что энтерпрайз кастомеры считают XML говном. Я то думал все для них - а нет. Чисто программерский монстр от которого плюются все, кроме писателей мегасофта.

Так и старт системы и старт приложений быстрее с бинарными конфигами, Во в упор не пойму зачем отрицать очевидный факт , талмуд не велит ? :-) Чего, какая еще загрузка в бэкграунде, это касается только части прог от самого микрософта.
Сделать можно многое и разными способами, в том числе через ж. :-) Но всегда действует общий принцип - максимальная оптимизация не осуществляется одним путем. Поскольку старт зависит от многих факторов, то максимальная оптимизация получается при оптимизации всех факторов.
Никто не мешает использовать от же prelink вместе с бинарными конфигами, первый улучшает свое, второй свое, в результате выигрыш больше чем при использовании только одного метода.

Мощная машина для обработки конфигов не юникс вей, это типичная винда -вей :-))

Да? Прочитайте статью авторов юникса к его релизу - там как раз этосамое «Мощная машина для обработки конфигов - юниксвей». Там конечно более тонкое обоснование - но почитайте, почитайте. Аргументы в этой статье более новые чем мышекликательный интерфейс, по крайней мере. Вы же любите все новое в технологиях - как раз достаточно новое для вас :D

Что программеры микрософта не освоили писать парсеры это это уже фантастика

Дадада. «надо было написать всего лишь парсер111». Бугога.

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

какого юникса - 50 летней давности ? Смотрим в части талмуда :-)
остальное, аргументация в стиле «сам дурак» не комментируется, бо комментировать там нечего - аргументов нет :-)

Так и старт системы и старт приложений быстрее с бинарными конфигами, Во в упор не пойму зачем отрицать очевидный факт , талмуд не велит ? :-)

Так это не очевидный факт - это классический бред от недоучки, при чем бездоказательный, что характерно. :D

Чего, какая еще загрузка в бэкграунде, это касается только части прог от самого микрософта.

В линуксе вообще весь гуи хоть такой хоть, другой неоптимизированый. Просто и банально не хватает рук. Тем более на направления с приоритетом у плинтуса.

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

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

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

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

Редактор же реестра существует не потому что в ТЗ на реестр была «правка реестра», а потому что иначе бы правили бы в hex и страшно при этом ругали бы MS. И вот что бы ругали чуть менее страшно есть редактор.... хоть какойто.

какого юникса - 50 летней давности ? Смотрим в части талмуда :-)

Так я же говорю - ваши подходы - бинарные конфиги - древнее. Читайте свежак хотя бы 70-х, а потом уже вещайте на тему талмудов.

остальное, аргументация в стиле «сам дурак» не комментируется, бо комментировать там нечего - аргументов нет :-)

Что, слив защитан? Понемаю. Как только вам суют в нос аргументами - у вас дислексия «невижу аргментов1111 нетнетнет1111 не суйте мне в нос эти буковки я неумею читать1111» :D

Тьфу, е, ну опровергай что время доступа к одному бинарнику в памяти меньше чем к куче текстовых на диске Делать что ли нех.. ? :-)
Кому не нужен, тебе ? Мне нужен, я не люблю ждать пока прога запустится, даже доли секунды, она мне нужна сейчас сразу и немедленно, а ты можещь ждать :-)
Какая разница через какой редактор править конфиги ? :-)) Хочешь править в консоли, есть ncurses.

детсад :-))

отсюда и совершенно спокойное отношение к xml, редактирование конфига в xml редакторе ничем не отличается от редактирования текстового в текстовом редакторе, а где то даже и лучше :-)

XML удобен там, что о формате даже думать не требуется — оно способно покрыть почти любые задачи. Никаких мыслей!

Это конечно не совсем конфиг в исконном значении, но я как пример привел, а не как повседневную задачу.

Ну так я вам про то и говорю. Это не конфиг. :D

Как только у вас тонны неконфигов, при чем в условия гуя, сразу возникают эти самые проблемы.

Более того - я же вам не говорю что вы были неправы сделав такой конфиг. Я говорю если сравнивать XML с нормальным конфигом, то XML - говно. Просто в некоторых условиях *приходится* удовлетворятся говном. Ну вот селяви такая - увы и ах.

И прекрасно вы привели часть причин. Заказчик не готов оплачивать читабельные и писабельные конфиги:

просто xml позволяет в будущем масштабировать конфиг для более сложных вещей, которые были не нужны на начальном этапе. А если изначально выбрать Key=Value конфиг, то при изменении ТЗ через год придется много переписывать.

Вооот. Именно этого абзаца не понимает наш вендотролль с профессиональной дислексией. Патамучто дурак, да :D

MS может писать парсеры. Но внутренная структура MS во времена win95 это огромный трафик изменений в ТЗ в условиях постоянного цейнтнота. Система в постоянном хаосе.

Ни на какую человекочитаемость или переносимость конфига на другие виндовсы нет времени. Есть время только в билде 165237232 сдампать системные объекты в реестр вот так, а в 165237236 сдампать уже абсолютно иначе. При этом сам демон реестра (а это в терминах юникс - именно демон) постоянно меняется. И все на что можно рассчитывать в условиях цейнтнота это дампать состояние памяти в более менее адрес-независимом формате.

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

Тьфу, е, ну опровергай что время доступа к одному бинарнику в памяти меньше чем к куче текстовых на диске Делать что ли нех.. ? :-)

Ну и баклан же вы, батенька. Это же от общего дизайна зависит, что быстрее. Как то же попал в память этот бинарник, значит и конфиги могут так же заранее попасть в память. Почему у вас нету кеша для конфигов, если уж у вас именно этот момент, быстрый старт, ну так важен, например? Методов оптимизации придумали - громадье.

Кому не нужен, тебе ? Мне нужен, я не люблю ждать пока прога запустится, даже доли секунды, она мне нужна сейчас сразу и немедленно, а ты можещь ждать :-)

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

Какая разница через какой редактор править конфиги ? :-)) Хочешь править в консоли, есть ncurses.

Ну попробуй мне открыть бинарные конфиги неизвестной программы 20 летней давности....... а просто не венды ...а просто неизвестной программы ..... :D

сразу видно человека не успевшего посидеть на ext2 :)

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

но ИМХО, в теме скатились до поиска ответа на вопрос «что есть MS-way?» %)

неинтересно

детсад :-))

Ну вот я и говорю - нету аргументов ... при чем еще тогда когда вы употребили дедсадовский аргумент «вы молитесь на талмуд» у вас их не было :D

отсюда и совершенно спокойное отношение к xml, редактирование конфига в xml редакторе ничем не отличается от редактирования текстового в текстовом редакторе, а где то даже и лучше :-)

Ну так вы и реестр правите как робот из 60-х а не как белый человек, вот и спокойно относитесь. Зачем вам вообще удобства? хекс-едитор^W хмл-едитор и вперед, выполнять работу роботов :D

сразу видно человека не успевшего посидеть на ext2 :)

С чего вы взяли? Как раз у человека типично *классический* вендовый подход, который в 90-х был так же популярен как сейчас :D Система грохнула конфиги/как то покрылась медным тазиком? а) восстановим из бакапа б) неполучилось - настроим все заново.

тут уже была полемика по поводу запихивания конфигов в память и аналогичные тебе тут же стали приводить доводы что это нах.. не нужно так как есть дисковый кэш :-)) Впрочем даже в этом случае чтение из одного бинарника банально быстрее.
Ну ясно, линупсотроль, «если нет то значит и не нужно» :-) Мне нужен быстрый запуск прог, еще раз повторить ? :-)
Спич о том что что все должно храниться в одном бинарнике, берешь винду 95 и открываешь в неей ее реестр :-) берешь красную шапку 2020 и открываешь в ней реестр от шляпы 2020 Ферштейн ? :-)

Что не получилось - реестр восстановить ? :-) Ну сам дурак, бэкапы делать надо. То же самое делаю и в линупсе, полетели настройки шрифтов, новая крыса их покорежила, мне быстрее восстановить /etc/fonts из бэкпа чем православно тратить горахдо больше времени отыскивая что именно она там похерачила :-)

Совсем ты дурак :-) Чем отличается правка в одном редакторе от правки в другом ? :-)

Я вот не пойму банальной вещи, какая разница в каком редакторе править конфиги, в текстовом, xml или в редакторе реестра ? :-) Что то что то это редактор. разницы не никакой. В консоли править надо, велкам в ncurses

Мда…

Что, сказать совсем нечего?

Потому что в Linux каждый находит то, что ему нужно. Вот, например, тебе нужна причина для нытья - ты ее нашел.

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