Open source
C
Development for Linux
Comments 700
+161
«Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал.»
Охренеть, одолжение сделал :)
-2
Ну, мне-то и сливать было нечего, но мир не без добрых людей- спасибо за минусы
-2
кто-то оголтело лепит минус просто потому что сказанное идет вразрез с его убеждениями, а кто-то ставит плюс к статье за то что в ней есть котик. Скоро котировки валют на месяц вперед будет проще предсказать чем собственную карму/рейтинг на хабре.
-16
Да, всё так. Я бы ещё проехался по любимому языку юниксоидов — голым сям, Уже лет 20 нет ни одной причины не использовать вместо него си с плюсами, даже для системных вещей, тем более что в с-стиле можно и на плюсах прекрасно писать.
А вообще проблема не в юникс, не в прочих ос или инструментах, проблема в людях. Из любой достаточно долгоживущей и сложной системы, над которой работает масса людей, по факту получается свой клубок костылей с велосипедами, можно даже никакие статьи с критикой не читать. Панацеи тут быть не может, поэтому просто надо набираться опыта и самому делать хорошо. Получится не сразу, а когда начнет получаться, будет уже поздно. Выхода нет, смиритесь.
-4
На работе всегда говорю, «ошибки не в людях, а в сервисах». Люди не ошибаются, они делают не всегда то что от них кому-то хочется. А вот сервисы уже предназначены для того, чтобы делать то, что хочется его владельцу, поэтому если делают не то — ошибаются.
+3
Проблема в том что для системного программирования кроме С и С++ пока к сожалению ничего нет (ну вот появился Rust но он еще мало распространен… да и с синтаксисом некоторые вопросы к интуитивности, в тех же же C# или Java все гораздо более понятно, причем сходу, без необходимости погружаться в нюансы языка).
-6
Ну так большая разница же, с и с++, я про что и пытался сказать. С++ рулит, в отличие от.
+13

C++ — это такой ужасный монстр. И иногда вместо C++ нужно использовать C. Чтобы вместо вот этого монстра использовать монстрика поменьше

0
Настоящая причина использовать Си вместо С++ в 90% случаев куда тривиальнее: отсутствие компилятора С++ для конкретного устройства. Никто же не заставляет использовать все эти «монструозные» вещи типа буста, можно даже писать большую часть кода на общем подмножестве.
+5
Монстры только у людей в головах. Ничего же не мешает вам писать на ++ в стиле си и аккуратно использовать некоторые полезные плюшки, тот же RAII, но без фанатизма, без буста, без лямбд.
А вот в голом си приходится изголяться, дефайны, goto, MyObject_DoSomething(MyObject* self) и прочие радости.
0

Я считаю, у C++ нет самодостаточных подмножеств, не считая самого C++, разумеется (C, к сожалению, не является подмножеством C++). Попытка выделить некоторое подмножество C++ для своего проекта обречена на провал. Вот допустим, есть проект "в стиле C" для UNIX, я хочу заюзать в нём RAII для файловых дескрипторов (fd). Окей, написал свой объект-обёртку для fd. Потом выясняется, что нужно либо запретить копирование для этого объекта, либо реализовать в конструкторе копирования dup. И не зависимо от выбранного варианта нам нужно уметь возвращать наш объект из функции, а для этого уже нужен конструктор перемещения, а это уже C++11. Ну и так далее, так постепенно вы притянете весь C++ во всей своей красе.


When you’re programming C++ no one can ever agree on which ten percent of the language is safe to use. There’s going to be one guy who decides, “I have to use templates.” And then you discover that there are no two compilers that implement templates the same way

https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus

+3
Потом выясняется, что нужно либо запретить копирование для этого объекта, либо реализовать в конструкторе копирования dup. И не зависимо от выбранного варианта нам нужно уметь возвращать наш объект из функции, а для этого уже нужен конструктор перемещения, а это уже C++11

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

https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus

напомнило
+3
Я раза 3-4 порывался перейти с C на C++, даже в некоторых больших проектах на плюсах принимал участие, но не прёт меня от них, всегда возвращался к голому C. Единственное, чего мне не хватает на «голом» по сравнению с плюсами — это libslave (скоро допишу свою на сях), нормальной библиотеки под протобуф и RapidJSON (тоже можно пережить).

Голый C прекрасен, просто он не всем подходит.
+3

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

+4
BF вообще замечательный, его лаконичность потрясает. А если вам не нравится, то вы просто школотроны, единственно на что способные — кнопки по формам расставлять. Fixed for ya.
-1
Именно! Все языки по-своему прекрасны и у каждого найдутся приверженцы.
+13
Уже лет 20 нет ни одной причины не использовать вместо него си с плюсами, даже для системных вещей, тем более что в с-стиле можно и на плюсах прекрасно писать.

Есть. libstdc++ во флешу не пролазит. Толстая слишком.

-23
А вот эта вся экономия на копеечных флэшах она как правило боком выходит рано или поздно. Должен быть запас минимум в 2 раза, если планируется хоть какое-то минимальное развитие продукта. У нас тоже в свое время в одном из продуктов лет 12 назад наэкономили, поставили 4ГБ, и рамки впритык. Потом через 2-3 года сразу в 8 раз запас сделали, экономия сильно убыточная вышла по факту.
+4

На attiny младших ещё меньше, и ничего, на плюсах писать вполне можно. Без экзепшонов и rtti, конечно, но плюсы ими не ограничиваются.

0

Ну я их в итоге завёл там без стандартной библиотеки путём выключения лишнего во флагах компиляции и написанием заглушек под хлам типа __verbose_terminate_handler. Что не отменяет упитанности libstdc++.

+2
А вы вкурсе, что есть ОС (стоит отметить, *nix ОС) под всякие встраиваемые системы и МК? Там такая память только в очень сладких снах может сниться.
-3
Я где-то говорил что предлагаю всем 4 гига ставить? Это пример был, из личного опыта. Если у Вас 32 КБ (это наверное что-то космическое суперотказоустойчивое), то можно взять запас до 64 КБ, да в конце концов, из любого правила есть и исключения, пишите в этом случае на си, на здоровье, не надо же все советы так буквально воспринимать, а то я смотрю народ прям переволновался. Под 32 кб можно и на асме написать.
0
можно взять запас до 64 КБ

У меня не получалось упихнуть libstdc++ и в 64 кб. Говорю же, толстая слишком. А без неё запас неплохой есть, да.

+1
Так не нужно использовать std от C++. Это чудовищное поделие. Там из полезного только exceptions, но я думаю их как-нить можно вынуть оттуда, не таща с собой весь остальной хлам.
А сам С++ с RAII и остальным весьма крут, хотя сильно больше нюансов, чем в голом С.
-3
<сарказм>
Не оскорбляйте святое. Люди привыкли писать на голом С, это развивает внимательность, аккуратность. Сделал, как говорится, fopen, не забудь про fclose, да и код получается длинный, солидный. А все эти ваши гейские RAII — не нужны и не влазят в 8 кБ памяти, особенно если boost весь ещё заинклюдить.
</сарказм>
-1
Механизм исключений без RAII бесполезен. Плюс, очень удивительно, что вы выделяете самую запрещаемую в проектах фичу языка как его основное преимущество
+1
Ну так я и говорю, что нужно RAII + exceptions. Но их реализация находится в райтайме С++. Хз кем и где она запрещена. Везде, где писал на С++ все использовали исключения и RAII как самое базовое, что С++ предоставляет по сравнению с голым С.
То, что это в публичном стайлайде гугла написано, так это сильно не так внутри и сильно зависит от команд и наличия легаси кода. А изначально это пошло из-за плохой реализации исключений в старых компилярах с точки зрения производительности.
+2
То, что это в публичном стайлайде гугла написано, так это сильно не так внутри и сильно зависит от команд и наличия легаси кода

Вот что написано в публичном стайлгайде гугла.


On their face, the benefits of using exceptions outweigh the costs, especially in new projects.
+1
А изначально это пошло из-за плохой реализации исключений в старых компилярах с точки зрения производительности.

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

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

0
Какие, нафиг, слухи? SJLJ — это единственное что работает на всяких хитрых, нестандартных, платформах (типа тех же микроконтроллеров), а dwarf2 — очень и очень жирный (что может быть, опять-таки, большой проблемой для микроконтроллеров).

Вот тут подробнее.
0
Верно, но старая реализация исключений просаживала производительность просто от куска try-catch. То есть даже той ветви, которая успешная.
На хабре где-то было про реализацию исключений статья.
0
В нынешний век интерпретаторов и П-кода это не то чтобы просадка, это погрешность измерений =)

Там расходы были — пяток лишних ассемблерных инструкций.
0
Нет, ну overhead есть даже если нет исключений. Скажем, в Windows надо для каждого try, в том числе скрытого, создать элемент SEH, а в конце — удалить его. Да, это мизер.
+1
libstdc++ во флешу не пролазит. Толстая слишком.
Давно, если честно, не смотрел, но были же проекты uclibc++ и подобные, все умерли?
+43
И эти файлы надо заново читать и заново парсить при каждом вызове ls -l! Было бы гораздо лучше использовать бинарный формат. Или БД. Или некий аналог реестра. Как минимум для вот таких вот критичных для производительности ОС файлов.

Не стоит недооценивать производительность текстовых файлов.
Собственно, какая вам разница, будет ли конец строки обозначать символ \0 или символ \n?
SQLite/Berkley или на таких размерах проиграют по производительности.

Полагаю, что чтение и парсинг /etc/passwords выиграет по скорости у чтения из реестра на порядки. Но это все в целом не важно, потому что роль идет даже не о миллисекундах — я набросал простенький скрипт на perl, он с парсит /etc/passwd с помощью регулярного выражения 100 тысяч раз за ~3s.

printf внезапно является далеко не самым быстрым способ вывода информации на экран или в файл

Форматируемый вывод оказывается не самый быстрый вывод! Я прямо-таки потрясен этим откровением. А нет, не потрясен. Это все написано в любой книге по С.
+2
Собственно, какая вам разница, будет ли конец строки обозначать символ \0 или символ \n?

Скорее, в случае с БД, она ничем заканчиваться не будет, будет указан её размер.
/etc/passwords маленький файл для примера. А вот с большим файлом, со сложным форматом (вложенные секции, например), выигрыш будет на стороне БД. Файл не надо будет разбирать на строки, и эти строки парсить в дерево.
0
Скорее, в случае с БД, она ничем заканчиваться не будет, будет указан её размер.

В postgresql, например, безразмерные строки будут незначительно быстрее строк с фиксированным размером.

+1

Вы путаете "fixed size strings" и "pascal strings".
"Безразмерные" строки в postrgesql как раз паскалевские и хранят свой размер (каламбур).

+2
Предполагается что у баз данных есть индексы и самое главное контроль целостности до записи(имеется в виду завершение транзакции), чего нет у идеологии 'все есть текст', т.е. в случае с /etc/passd об ошибке скорее всего узнаем по факту использования.
+4
Форматируемый вывод оказывается не самый быстрый вывод!

Дело не в этом, а в том, что строка формата разбирается каждый раз во время выполнения.


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

-1
Форматируемый вывод оказывается не самый быстрый вывод! Я прямо-таки потрясен этим откровением. А нет, не потрясен. Это все написано в любой книге по С.

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


Вдобавок, во многих реализациях стандартной библиотеки C++ (как минимум до недавнего времени) потоки ввода-вывода были реализованы поверх форматных функций C! (Facepalm!) То есть в API C++ строк формата уже нет, внутри всё можно реализовать без них. Но эти идиоты всё равно внутри пихают форматные строки. Чтоб медленнее было. Я-то думал, что программисты умные. Что реализуют всё всегда как надо. Как бы не так! Есть ли этот баг по-прежнему в основных реализациях стандартной библиотеки C++, я не знаю. Вполне мог остаться

0

Там, где мне, наверное, единожды за последние года три это было важно, istream был быстрее scanf.


Ну а самым быстрым вариантом был mmap + парсер на boost::spirit + boost::string_view. Но это так, заодно к слову о монстрах C++ vs C.

+18
Особенно умиляет твердокаменная уверенность в том, что при крахе системы у бинарной конфигурации больше шансов выжить, чем у текстовой.
Оставляя за скобками такой важный нюанс, что текстовую конфигурацию, при повреждении, куда легче и быстрее восстановить вручную, чем бинарную без дополнительного специфического инструментария
-7
Бинарные сами следят за своей целостностью. Убить реестр внезапным ребутом почти не реально.
+5
юзеры ещё не то могут убить… Приходилось чинить. Там не все в двух копиях, вообще-то.
0
Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно. До этого — сколько угодно.
Тем не менее — если регистр повреждён (да даже действиями пользователя) до степени незагужаемости системы, это требует специфических инструментов для ремонта, в отличии от текстовых конфигов.
С точки зрения производительности системы, можно хранить в памяти результат чтения текстовых конфигов и обращаться к нему (рано или поздно вся эта концепция systemd к такому и приведёт).
0
Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно.

Отключение питания на этапе загрузки убивает реестр и на 7. Никогда не понимал логики, зачем надо писать в реестр до логина пользователя.
0
На каком? Как минимум до этапа chkdsk ОС точно ничего на диск не пишет.
0
На каком?

Где-то в районе анимированного бут-лого или сразу за ним.
0

У меня есть многострадальный комп, которым мне лень заниматься. Для кино и всякого. У него что-то с железом, что он часто ресетится. Иногда не включается. Но проводом подергал и завелось. Пару раз вис и не загружалась винда из за одного диска. Я его и сам не жалею. Долго выключается — ресет, долго думает — ресет, долго не включается — ресет. Винде по барабану. Живет не тужится.

0
Долго выключается — ресет, долго думает — ресет, долго не включается — ресет

В вашем опыте ключевое слово «долго», т.е. весь io уже закончился.
В моём опыте, всё внезапно и с железом всё нормально — старт системы, потеря питания, «убитый» реестр.

Показательно, что это не единичные случаи, несколько раз восстанавливал юзерские, когда в нервах ресет жмут на загрузке. И у себя словил 2 раза, чистой воды невезение, один раз аккум ноута в 0 ушёл на загрузке, второй раз электросети «уронили» десктоп.
0
Это ооооооочень пространное указание точки времени. Там мягко говоря много всего в этот момент происходит.
0
Суть то одна, пропадание питания в этот момент и как результат битый software.
0
В чём проблема воспользоваться резервной копией? По-умолчанию в винде включены опции по созданию точек восстановления и копий реестра…
0
Которые умельцы сроду отключают и жалуются, что глючную винду приходится переустанавливать после каждого чиха.
0
Ну как зачем — процесс сверки обнаруженных устройств с существующими с last known good, например, или ещё какое-нибудь вуду. Регистр — он не для пользователя, по большому счёту, точнее у пользователя есть свой кусочек, в профиле, куда и начнут писАть, после того как он залогинится.
Я уже было решился спросить у человека какие именно технические детали позволяют ему с таким апломбом утверждать о самовосстановлении регистра (а вдруг?), а тут вы пришли и… разрушили мою веру в светлое бинарное завтра юникс-систем.
0
Ну как зачем — процесс сверки обнаруженных устройств с существующими с last known good

Запись там идёт только после успешного логина + задержка, что и свидетельствует об успешной загрузке.
Я уже было решился спросить у человека какие именно технические детали позволяют ему с таким апломбом утверждать о самовосстановлении регистра

Зачем восстанавливать то, то не упало? Механизмы записи в реестр сделаны для поддерживания его консистентного состояния при обрыве записи, а транзакционные механизмы NTFS не дают сработать и им.
0
BCD хранит свои конфиги в кусте реестра. Хотя правда не в курсе, он только читает или ещё и пишет?
-3
До этого — сколько угодно.

Не соглашусь. На своей XP я никогда не видел разрушение реестра. Хотя и вырубал и во время загрузки, и во время выключения.
+2
На вкус и на цвет все фломастеры разные — может у вас контроллер диска какой дружелюбный. То, что молния никогда в вас не попадала, вовсе не значит, что она не попадала в других людей.
0
Я использовал весьма разное оборудование. Видимо, я везунчик.
0

Возможно дело в том, что раньше можно было ставить систему на FAT32 раздел со всеми вытекающими ;-)

0
на NTFS оно точно также в капусту билось, но как правило очень невоспроизводимо. какой-нить race condition при записи в глубине дискового стека, совпадающий с зависанием/вырубанием системы.
+1
Аналогично. Сколько ни отрубай «жестко». Ни на XP, ни на 2к.
0
А зачем там регулярка, там же фиксированный набор полей? Тот же GAWK в таких случаях (простые текстовые файлы с фиксированным набором полей) вообще рвет всех. Причем даже на гигабайтных простынях данных.
+30
Про существование зомби-процессов все говорят: «It's for design».

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

Обычном kill'ом зомби не убиваются

Убиваются, конечно же, только целиться надо в родителя. Пример: kill $(ps -A -ostat,ppid | awk '/[zZ]/{print $2}')

Долгие и пространные рассуждения про shell забавны в своей надуманности, но хотелось бы отметить, что сравнивать его возможности надо не с возможностями php, а с возможностями cmd.
+1
Если есть зомби, то с родителем не всё в порядке, т.е. он уже не нужен.
+8
А если там критичные данные? Например ваша зарплата за год.
-7
Вы сейчас о чём говорите, какие критичные данные, какая зп?

Если есть зомби, то скорее всего родителя уже нет. Просто нет. Нет, от слова совсем. Со всеми данными.
+4
Все понятно. В следующий раз рекомендую высказываться на тему в которой хоть немного разбираетесь.
+8
Если есть зомби, то скорее всего родителя уже нет. Просто нет. Нет, от слова совсем. Со всеми данными.

Зомби-процесс — это дочерний процесс, родитель которого не удосужился получить код завершения через wait. Если родитель умирает, то зомби наследуется init, который его без сожалений убивает.


То есть, наличие зомби говорит о том, что родитель как раз есть. Другое дело, что в нём баг, но процесс есть.


Не понимаю, за что заминусовали tgz.

+1
Не в качестве несогласия с вашим комментарием, а как небольшая поправка. Когда родитель умирает дочерний процесс определенно наследуется каким-то другим процессом, но это совсем не обязательно именно init.
0

Да, согласен. Просто осиротевшего зомби в *NIX усыновляет процесс с PID=1, а его по инерции часто init называют. Хотя, конечно, всё может быть и по-другому.

+7
Опять же не совсем верно. Кто наследует дочерний процесс после смерти родителя «implementation defined», т. е. это не обязательно init или процесс с pid=1. Более того в linux вообще может быть несколько процессов, которые собирают осиротевших детей (смотрите man prctl ту часть где описывается PR_SET_CHILD_SUBREAPER).
+2

Ага, спасибо! Просто у Стивенса и Раго именно про PID=1 написано. Ну, теперь буду знать. :)

0

Это как-то подтверждает ваши слова, что наличие зомби свидетельствует о смерти родителя? Или что вы хотели сказать?

-1
Или что вы хотели сказать?


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

Зомби жив, пока родитель через wait состояние не получит. Единственное разумное, почему родитель этого не делает (я не беру в расчет отсутствие в коде этой возможности) — родителя уже нет или он не в состоянии нормально работать.
0
А если у родителя просто нужный тред заблокировался на IO, а все остальное хорошо и в порядке?
-1
Просто хипстеры не умеют так:
29755 pts/0 Ss 0:01 \_ /bin/zsh
6123 pts/0 S+ 0:00 | \_ ./zombie
6124 pts/0 Z+ 0:00 | \_ [zombie]

[some magic]

29755 pts/0 Ss 0:01 \_ /bin/zsh
6123 pts/0 S+ 0:00 | \_ ./zombie


И зомби умер. Без убивания папы.
UFO landed and left these words here
+1
А если RAM сдохнет? Или контроллер? Или питание вырубится?

Если ваша зарплата за год имеется только в оперативной памяти одного сервера, валить надо из такой конторы.
+1
Следуя этой логике можно сделать rm -rf /, а объяснить все тем, что мог ведь и контроллер сдохнуть. В маразм не впадайте. Ваша зарплата зависит от ваших действий, а не от того что лежит в памяти конкретного сервера.
0
Нет, следуя этой логике, нельзя сделать rm, потому что логика в том, чтобы не хранить критически важные данные только в оперативной памяти одного процесса на одном сервере.
0
Маразм все же побеждает. Перечитайте изначальный пост, вопрос был не про зарплату. По существу есть что сказать?
+1
да что вы обычная черная бухгалтерия… все на RAM диске и бекап в крипте в облако в Зимбабве…
+4
Если родитель нужен, то вполне может быть, что этому родителю нужна информация о том, как скончался его ребенок (код возврата, короче), так что какую-то информацию о завершившемся процессе все равно придется сохранть. Zombie процесс — просто способ сохранить эту информацию до тех пор, пока ее не запросит родитель.

Но если вам это не нужно, то вы можете просто поправить обработчик SIGCHLD и вот вам автоматическая сборка этих Zombie. Это всего одна строка кода, так что не супер тяжелая задача.
-2
Как вставить 1 строчку кода в уже запущенный бинарник?
+3
Если процесс не собирает своих детей, то значит они ему нужны и значит Zombie процессы должны быть, либо это просто недосмотр со стороны программиста(ов), который написали программу. Странно винить Unix за недосмотр программистов.
+1
Ок нигде. Тогда что к обсуждению должен был добавить ваш вопрос про то, как вставить 1 строчку кода в уже запущенный бинарник?
0
Наверно понимание того что вставить строчку нельзя по условию задачи.
0
Какой задачи? Избавиться от zombie? Так вроде как я вам выше объяснил, что zombie либо может быть нужен родителю и от него не нужно избавляться, либо родитель содержит ошибку — и это уже совсем другая история, исправлять ошибку в программе позволяя небезопасное действие странно.
0
А если зомби не нужен?
Вот прямо сейчас на ноуте:
20157 ? Ssl 0:09 gvim
20163 ? Z 0:00 \_ [python3]
Зомби мне не нужен, а vim содержит несохраненные данные.
+4
Операционная система не знает ничего о логике приложения, она просто не может узнать, что zombie больше не нужен. Zombie будет удален тогда, когда гарантированно известно, что он не нужен и не раньше.

Если программа порождает дочерние процессы и не собирает их, хотя они ей не нужны — это бага в программе. Ее нужно фиксить в программе.
0
Ну так кроме ОС у нас еще есть админ. А у админа есть некоторые инструменты.
+2
То что админ есть, не значит, что ОС должна разрешать потенциально небезопасные действия (а убийство дочернего процесса, без разрешения родительского процесса — потенциально опасное действие, потому что логика родительского процесса может быть к этому не готова). Давайте все программы будут лазить друг к другу в память — админ же есть, он всех хулиганов накажет.
0
kill -9 потенциально небезопасен, но ОС же позволяет это делать, не так ли?
0
Так, а еще kill позволяет избавиться от zombie убив родителя, не так ли? И если родитель не собирает своих детей, хотя должен — то убивать нужно именно его, а не уже мертвый процесс, который ни в чем не виноват. Но как и всегда с kill -9 вы делаете это на свой страх и риск и не жалутесь на то, что в приложении могут быть несохраненные данные. Так что строго говоря, у администратора, который сам себе придумывает несуществующую проблему zombie процессов, все таки есть средство, чтобы с ними побороться.
0
Средство есть, только это совсем не kill -9 для папы.
0

То есть вы утверждает, что где-то в стандарте posix описывается способ удаления zombie, который не сводится к вызову wait со стороны процесса родителя и гарантированно работает? Поделитесь выдержкой из Posix или SUS.

-2
А с чего это должно быть написано в стандарте? У вас есть стандарт как ложку ко рту подносить? Нет? А кушаете как?
kill -9 ppid в посиксе описан?
+1
У вас такая бурная реакция на все стандарты или только на те, что вам не нравятся? Касательно вашего вопроса, нет у меня нет стандарта как подносить ложку ко рту, но ложку ко рту я подношу себе сам, а не прошу это делать за меня какого-нибудь дядю. С другой стороны еда, которую я покупаю в магазине чтобы есть, стандартам соответствовать должна — потому как я не делаю ее сам.

Но возвращаясь к делу, стандарт — это форма описания гарантий. После всей той драмы, которую вы тут развели про зарплату, было бы странно если бы ваше решение не предоставляло разумных гарантий надежности. И под гарантииями надежности я имею ввиду что-то сильнее чем «я попробовал и у меня работает». А теперь вы можете сказать что-нибудь по существу?
-2
У меня? Бурная реакция? Мы точно один сайт сейчас читаем? Драму какую-то нашли.
И в словарик загляните на букву С, что бы понимать что такое стандарт.
+2
То есть не можете. Спасибо за время потраченое зря время.
0
Если родитель нужен, пробуем ему послать SIGCHILD, но скорее всего это не поможет. Тогда цепляемся к родителю через gdb, и от родителя уже запускаем waitpid() на pid зомби-процесса:
# gdb
(gdb) attach 19595
(gdb) call waitpid(19698,0,0)
$1 = 19698
(gdb) detach
+3
А зачем сравнивать шелл с возможностями cmd? Не, ну серьезно? Зачем выбирать какое-то другое древнее дерьмо мамонта и сравнивать с ним?

Если мне что-то нужно автоматизировать в windows — я возьму вовсе не cmd.
+9

Ну так и на линуксе народ автоматизацию на питоне сейчас каком-нибудь пишет.

+1
Я вам больше скажу — у JavaEE контейнера Weblogic внутри тоже jython. И это удобно.

Разница в том, что для управления чем-то при помощи скриптов изнутри есть API, а не предлагается вызывать команды, которые вернут неструктурированный поток байтов типа stdin.

Ну т.е. нормальная современная полноценная автоматизация — это вовсе не шелл, в его оригинальном виде. Ну и не cmd конечно же.
+8

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

+7
Очень похоже на выдержки из Unix Haters Handbook. Прочитать эту книгу для общего развития нужно, но в работе использовать не стоит :)
+13

К сожалению, их более новые и продуманные системы, где решены многие из упомянутых проблем — OS Plan9, OS Inferno — не взлетели. Не нужны народу элегантные системы, в которых нет этих костылей — наверное, скучно без них. Я много лет работал с OS Inferno, и это буквально "открыло глаза" на многие проблемы *NIX. Пока радует только рост популярности Go, может хоть одна из их попыток хоть немного исправить сверх-популярные UNIX и C спустя 40 лет окажется относительно успешной.

+9
К сожалению, какой бы хорошей не была система, она скорее всего не взлетит. Нужно пробить огромную инертную массу в виде существующих и как-то работающих технологий, решений, знаний и специалистов. Это зачастую гораздо сложнее чем придумать что-то новое и гениальное.
+5
Нужно пробить огромную инертную массу в виде существующих и как-то работающих технологий, решений, знаний и специалистов.

ЕМНИП, создатели Plan9 именно так и говорили. Поэтому и не взлетело.
+1
Не нужны народу элегантные системы

Думаю, проблема немного не в этом. Проблема кроется в бизнесе, где хотят минимальной жертвой получить как можно больше.
+24
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют.


Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.

И да, есть такое дело, «отвергаешь — предлагай». Более удобный GUI, сравнимый по производительности с Shell, новые GUI-утилиты, способные склеиваться выводом-вводом (да хоть TermKit) — и без copy-paste, так как я не хочу повторять свои «макросы» Mega-GUI-Shell руками, да еще и параметры хочу.

Что касается C… вас кто-то уговаривает на нём писать? Make кстати вчистую уже тоже давно никто не использует. Можно продолжать, но зачем, «скажите спасибо что» прокомментировал.
+7
>Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.

Вы правы. Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу...» — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.

Хотя наверное не в таком стиле, все таки — а именно предлагая что-то взамен.
+5
> Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.

Seriously? Многие аспекты системы до сих пор представляют собой кучи шелл-скриптов различной степени упоротости. Sysvinit, всякие утилиты для упаковки-распаковки пакетов и т.д. Я даже утилиты для работы с ФС на шелле видел. Паковали когда-нибудь свои приложения? debscripts? rpmbuild? Ага, можно взять fpm и не париться! Но как же post/pre install/uninstall хуки? Я уж не говорю, что сами по себе обертки это часто тоже скрипты. Сейчас правда модно стало говнокодить на питоне, а не на шелле.
+4
Sysvinit
Его таки начали закапывать, хотя, не всем это нравится (но не будем разводить ту холивар на тему Sysvinit vs systemd).
+8

Вот именно что обернуты а не выкинуты. В этом и суть костылей. ..

0
Ну статья написана в ответ на статью «в винде в дате драйверов есть кривое легаси, которое ни на что не влияет но оно кривое». Вполне адекватный ответ, в UNIX-подобных тоже есть кривое легаси.
+15
man hier

/usr/local — хранит локально собранное ПО, которое не управляется пакетным менеджером и не входит в первоначальный состав системы.

/opt — обычно для самодостаточного ПО, которое упаковано не по файловому стандарту *nix. Я например туда Oracle JDK всегда распаковываю.

+18
надеюсь, что автор только в статье создаёт себе сложные препятствия, которые героически преодолевает. иначе могу только посочувстовать.
0
Все распространенные операционные системы (возможно, кроме некоторых негражданских и риалтайм систем) фактически основаны на ОС UNIX, содержат множество подпрограмм, подсистем, разработанных на/для этой системы или заимствуют идеи созданные, как ни крути, силами академической науки и в рамках Unix.
Почти все писалось на unix

А то, что за 50 лет основная концепция системы не устарела, а обросла лишь множеством надстроек/возможностей (и продолжает) работать во множестве сфер — все это говорит, скорее, в пользу системы.

+2
Все распространенные операционные системы (возможно, кроме некоторых негражданских и риалтайм систем) фактически основаны на ОС UNIX

Windows? POSIX там только сбоку прикручен.
+2
Будете удивлены, но «И ты… Брут!». Современная Windows NT писалась совместно с IBM как раз таки на базе UNIX, в итоге после развала сотрудничества родилось две системы — Windows NT и OS/2. Которая умерла, если мне не изменяет память в 2012 году в связи со снятием с тех. поддержки, а до тех пор успешно использовалась в банкоматах. К слову файловая система HPFS поддерживалась вплоть до NT4.
Именно из юникса у ядра NT очень много корней и Legacy наследия, которое сначала выпиливали, теперь возвращают. Фактически уникальность NT — это универсальное ядро, поверх которого работала подсистема Windows и Unix, а сейчас Windows и Linux.
+5
Я может плох в истории, но один из, так сказать, главных дизайнеров Windows NT Дейв Катлер является одним из самых известных хейтеров Unix, и как раз делал все по-другому. Можно каких-то подробностей по Unix legacy в ядре NT?
+7
Начнем с самого простого и очевидного (то что на виду), любое устройство является файлом, для доступа к устройствам используется виртуальная файловая система, драйверы рабоатют либо на уровне ядра (порты ввода вывода, DMA), люо в юзерспейсе как драйверы-фильтры (с хендлером файла устройства).
Второе как следствие — драйверы фильтры, работающие с файловой системой.
Третье — буквы дисков являются абстракцией и/или фикцией, точки монтирования маппятся как буквы дисков или прямо в файловую систему. При большом желании сейчас так можно маппить даже сетевые шары (экспериментально, но...)
Символические и жесткие ссылки в ФС перепиливались и видоизменялись, но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).
Дальше — это организация архитектуры процессов и… Обработки сигналов. Да, я знаю что исторически в Windows используются сообщения, но часть сигналов осталась на уровне ядра, в юзерспейсе они регистрируются отдельными вызовами API, такие как Ctrl+Break или Ctrl+C.

На самом деле действительно очень многие вещи были переписаны и в мире Unix на тот момент некоторых реализаций не существовало, того же автоматического пересканирования шины и так называемого autohotplug (подключение устройств на горячую — USB, PCMCIA, IEEE1394 и т.д.).

Тема обширная, и каие то вещи рядовому разработчику сейчас не встречаются, чаще с этим имеют дело только разработчики драйверов устройств, или специализированного ПО.

Кстати, DNS в Windows Server это таки незначительно переписанный ISC Bind 9.
0
Я вот про буквы дисков и точки монтиования не понял. Точки монтирования позволяют примонтировать ФС где мне угодно, т. е. я контроллирую под каким именем будет известна та или иная партиция диска или та или иная виртуальная файловая система. В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?

Я не думаю что пользователь — это Unix специфичное расширение. Понятие пользователя было до Unix-а и нет ничего удивительно в том, что NTFS их хранит, аналогичная история с режимом доступа. Более того VFS — теперь совершенно привычная вещь для Unix, для Windows не совсем. Так что я бы не сказал, что Windows ФС это Unix legacy.

Про архиетктуру процессов — слишком абстрактно, так что не могу никак прокомментировать. Само понятие процесса существовало и до Unix, интереснее что специфично от Unix-а взято.
+1
> В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)
0
Ну ссылка которую вы привели тоже не на самый первый NT ссылается (и не могу найти в статье информации о версиях NT, в которых эта фича поддерживается), так что нельзя утверждать что это Unix legacy. Вполне могу представить, что они это потом впили, дабы угодить особенно привередливым клиентам. Есть ли что-нибудь постарше?
+1
В командной строке есть утилита diskpart, и в управлении компьютером — оснастка «Управление дисками». Windows Server 2012 (на базе исходников LVM, как указала MS) привносит Storage Spaces — запустите и откроете для себя много нового.
Ссылка ниже показывает впервые появившуюся команду в юзерспейсе для монтирования дисков.

Я имею в виду запись вида user:group , ну к примеру 0:0 7777 (root:root rwt,rwS,rws). В двоичном виде это три шестнадцатеричных слова.

Можно я не буду вдаваться в особенности межзадачного взаимодействия в первых ядрах NT? :)
Материал довольно большой, да и освящен довольно неплохо в книгах для разработчиков.
0
Ну скажем так, LVM, даже если забыть про Windows, я бы не назвал Legacy — он не такой уж старый (1998, это уже linux 2.4, да и windows nt повяился несколько раньше, если мне не изменяет память) и не настолько уж типичный для Unix-ов в целом.

Какая разница как выглядит запись? Я например редко пользуюсь такой записью, хоть и сижу на Linux (предпочитаю буквенные обозначения). Это всего лишь форма представления — не самая существенная часть.

Меня интересует не интерфейс. Многие концепции на самом деле не специфичны именно для Unix-а и существовали до него. Меня как раз интересует то, что внутри, т. е. как они реализованы. Чтобы можно было ткнуть пальцем и сказать — вот это вы ребята сперли из BSD (как, например, некоторые считают про сетевой стек BSD). Не так уж много книг, которые покрывают эти части.
0

Откройте в винде (XP или 7) "Управление компьютером", далее "Управление дисками", выберите какой-нибудь раздел и там "Сменить имя диска или путь к диску". Там можно удалить букву диска и назначить ему вместо этого путь, куда надо монтировать. Далее в винде есть ключ/ветка реестра MountedDevices, я вот тут писал: https://geektimes.ru/post/156749/

+2
но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).


Это не так. Собственное в NTFS нет как таковых фиксированных аттрибутов, вместо этого есть понятие альтернативных потоков файла. В основном потоке данных содержится собственно содержимое файла, в альтернативных — все что угодно. Это могут быть разрешения (DACL), информация для аудита (SACL), сведения об источнике файла (например что файл загружен через Интернет) и вообще все, что угодно, включая POSIX-совместимые аттрибуты. Набор альтернативных потоков у каждого файла может быть свой.
P.S. и ИМХО это очень красивый подход.
-1
Собственное в NTFS нет как таковых фиксированных аттрибутов

Только для чтения, скрытый, системный, архивный, сжатый, разрежённый, индексируемый, зашифрованный. Это как минимум, и это атрибуты, а не альтернативные файловые потоки.
P.S. и ИМХО это очень красивый подход.

И не используется. В десятке используются костыли отдельная база данных с разрешениями POSIX.
К тому же в этом подходе есть проблемы- все потоки теряются при копировании на ФС без их поддержки, например, FAT. Досталось это при обеспечении совместимости с OS/2 в стародавние времена. Ну и у EXT3 и некоторых других ФС Linux есть похожие механизмы.
0
>К тому же в этом подходе есть проблемы- все потоки теряются при копировании на ФС без их поддержки, например, FAT.

А при копировании с ext4 на fat сохраняются атрибуты?
+5
Не совсем так. Тут есть определенная путаница с терминами. В NTFS термин «аттрибут» используется для записи с данными, в этом плане данные файла и альтернативные потоки тоже являются аттрибутами. Указанные вами аттрибуты хранятся как часть аттрибута $STANDARD_INFORMATION, т.е. $STANDARD_INFORMATION от альтернативного потока отличает только тип аттрибута, альтернативные потоки имеют тип $DATA.
-2
Начнем с самого простого и очевидного (то что на виду), любое устройство является файлом,

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

но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).

ACL в NTFS были изначально, ещё до того, как появились эти самые «расширения UNIX», и до того юниксоидам приходилось извращаться с политикой доступа через rwxrwxrwx, что намного менее гибко. И причём тут символические и жёсткие ссылки?

Дальше — это организация архитектуры процессов и…

Да-да, вот тут тоже интересно, треды были в NT опять таки изначально, а более-менее стандартное NPTL в юниксах появилось сильно позже. До этого считалось, что дискретизации шедулера на уровне процессов и так всем хватит, ибо нефиг.
+2
ACL в NTFS были изначально, ещё до того, как появились эти самые «расширения UNIX», и до того юниксоидам приходилось извращаться с политикой доступа через rwxrwxrwx, что намного менее гибко. И причём тут символические и жёсткие ссылки?

Верно. ACL привнесли ребята из DEC/ VMS команд, ACL были в RSX-11 на PDP.
+4
Ко всему описанному добавлю: современные исполняемые файлы под NT (Portable Executable) основаны на COFF (даже заголовок его наследуют).
+3
Я давно говорю, нет, я кричу сделайте в школе и вузах хоть краткий курс истории науки.
Новые поколения считают, что все новое появляется вдруг, само по себе. А старое было плохо и т.д., и т.д.
Но мои слова летят в пустоту, все хотят прикладных знаний и быстрых прорывов.
+3
Современная Windows NT писалась совместно с IBM как раз таки на базе UNIX

Вообще-то там корни идут совсем в другую сторону.
Фактически уникальность NT — это универсальное ядро, поверх которого работала подсистема Windows и Unix

Там может работать что угодно, была бы нужная подсистема. Изначально вообще никакой win подсистемы там не было, её впилили потом, как и поддержку архитектуры семейства i386.
+1
По первому проясните подробнее, где я заблуждаюсь?

По второму пункту согласен полностью. Хоть историческую статью всем Хабром пиши. С миру по нитке — общая картинка в целом.
+2
По первому проясните подробнее, где я заблуждаюсь?

Основным разработчиком NT был Дэвид Катлер, который перешёл из DEC, где пилил VAX и VMS. Из-за этого даже судились.
Хоть историческую статью всем Хабром пиши

Да уже есть, нужно просто погуглить.
+2
Вобще-то нет, Катлер и его команда пилили VMS в Digital, поэтому в первых НТ было всё-таки больше от неё, чем от чего-то позиксного.
+3
Или некий аналог реестра

gconf/dconf, разве нет? Да и транзакционную sqlite некоторые приложения используют. А благодаря тому что конфиги отдельной программы потенциально находятся во вполне определённых директориях становится воможным ПОЛНОЕ удаление приложения так, что система вернется к состоянию когда приложение не было установлено (в Windows большинство приложений не могут собственную папку удалить из Program Files при деинсталляции, не говоря уже о жести с происходящим в реестре).

+3
Необязательно же делать как в винде. И, как мне кажется, ничто не мешает пакетному менеджеру заниматься не только файлами, но и реестром. Тогда после удаления софта ничего не останется.
В винде проблема с удалением именно в том, что у каждой программы свой деинсталятор, а разработчики деинсталятора забивают на качество его работы.
По парсеру на конфиг — действительно проблема и излишние сложности, множество поводов выстрелить себе в ногу.
Реестр же позволяет все данные хранить в унифицированном виде, что несомненно хорошо, тут я полностью согласен с автором.
0
К сожалению, кое-что мешает пакетному менеджеру заниматься конфигами. Пакетный менеджер знает только то, что ему дано в описании «пакета» (программы), т. е. если программа динамически создает конфиги (например, отдельный конфиг для каждого user-а в /home) и никак не сообщает о них пакетному менеджеру, то и удалить эти конфиги он не может. Т. е. фактически проблема сводится к тому, что для программы должен быть сделан средствами ее создателей адекватный деинсталятор — и пакетный менеджер сам по себе эту проблему решить не может.

Но как лирическое отступление, например, пакетный менеджер apt (Ubuntu/Debian/etc) поддерживает команду purge, которая пытается удалять программу вместе с ее конфигами. Так что по мере возможностей, некоторые более или менее популярные пакетные менеджеры, по крайней мере в Linux, пытаются заниматься конфигами.
0

Не пытаются, а успешно занимаются. Но как вы правильно заметили, только системными, которые устанавливались с пакетами и, возможно, менялись пользователем. Но я ни разу не видел приложения, которые удаляют конфиги из домашней папки. К счастью есть всего несколько папок и несколько веток в dconf где с 99% вероятности будут конфиги приложения. Почистить это совсем не сложно.
Хотя (в теории) можно повесить хук на удаление и подчищать даже пользовательские конфиги, но, повторюсь, ни разу такого не видел.

+9
В домашней директории пользователей лежат не конфиги, а файлы пользователей. Да, это может быть какой-нить .softname/config, но это файл пользователя, который пользователь или явно написал сам, или натыкал в графическом меню программы softname(есть конечно вариант что он «автосгенерировался» при первом запуске). И пользователь может сделать что-то типа «apt remove softname && apt-add-repository… && apt update && apt install softname» и ожидает увидеть новую версию softname, поставленную из «правильного» ppa, но со своим старым конфигом (я например уже лет 10 таскаю ~/.purple/, ~/.mozilla/ и ~/.thunderbird/ по разным ноутбукам, дискам и ОСям).
И я считаю что трогать данные пользователя никогда не нужно. Пользователь может потом захотеть снова поставить тот же софт, может захотеть перенести конфиг на другую машину или просто сохранить конфиг в какой-нить git на всякий случай).
-1
В домашней директории пользователей лежат не конфиги, а файлы пользователей.


Э?
А что лежит в ~/.config?
+1
файл пользователя, который пользователь или явно написал сам, или натыкал в графическом меню программы softname
0
Но как лирическое отступление, например, пакетный менеджер apt (Ubuntu/Debian/etc) поддерживает команду purge, которая пытается удалять программу вместе с ее конфигами. Так что по мере возможностей, некоторые более или менее популярные пакетные менеджеры, по крайней мере в Linux, пытаются заниматься конфигами.

Он удаляет только те конфиги, что были созданы на этапе установки пакета, зачастую это дефолтные конфиги в том же /etc или /etc/default, которые есть в описании пакета. Это делается для случаев, когда дефолтные конфиги были изменены юзером, затем сама програма была remove, а потом вдруг понадобилась обратно.
За динамически генерируемым конфигами, например в том же /home/.config apt не следит.
0
Я ровно это и написал. Что ваш комментарий добавляет к моему или оспаривает в нем?
0
Часть про purge довольно скомканная и после описания проблемы динамических конфигов выше создаётся впечатление, что purge — панацея и умеет в удаление и их, а не только системных.
0
Часть выше части про purge вполне подробно и даже с примером (абсолютно эквивалентным вашему) объясняет почему пакетный менеджер не может впринципе следить за всеми конфигами. А часть про purge содержит слова «пытается» и «по мере возможностей» — очень не похоже на описание панацеи.
0

В том-то и дело, что программа не должна лезть куда-либо за пределы своей песочницы. Пусть пишет в свои ./user/ и ./local/ а система уже разберётся что в эти директории примонтировать.

+1
Вы предлагаете пакетному менджеру еще и в качестве песочинциы для всех программ выступать или что? Я не понимаю, как то, что программа «не должна», относится к пакетному менджеру и его возможности/невозможности удалять конфиги? Он что может как-то заставить программу не делать, то что она делать не должна?
0

Он должен контролировать что и где ей позволено делать и изолировать результаты её деятельности от других установленных приложений, если иное явно не разрешено пользователем.

+2
Т. е. не только пакетный менеджер но еще и пеочница, которая для каждого приложения отслеживает, что оно в runtime-е делает? Вам не кажется, что вы слишком многого хотите от пакетного менеджера?

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

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

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

+4
1. Я не зацикливаюсь на термене. Разговор был изначально о пакетных менеджерах и о том, что они могут делать с конфигами — я просто придерживаюсь темы разговора, чтобы не вводить никого в заблуждение.
2. Docker — это не ОС.
3. Docker образ содержит образ ОС. Этот образ все еще содержит кучу конфигов, которые нужно настраивать и править.
4. Docker ничего не контроллирует, он пользуется средствами ОС (контейнеры и cgroups).
5. Делать для каждого отдельного приложения свой контейнер — это просто overkill. Представьте что вы git, g++, make/CMake/Scons/etc все поставили в различные контейнеры — как этим вообще пользоваться?
+3
Не поверю чему? Я знаю об этом проекте, что из сказанного мной этот проект опровергает?
-1

Что не OS, что оверкилл, что ничего не контролирет и пр. Или за ОС вы только ядро считаете?

+3
1. Обратите внимание там написано RancherOS, а не Docker. Docker — это часть RancherOS.
2. С чего вы взяли, что не оверкилл? Более того, вы можете заметить, что Rancher OS не использует отдельный контейнер для каждого приложения.
3. Docker не контроллирует, он просит ядро ОС контроллировать (ядро — один компонент ОС, Docker — другой).
4. Нет я не считаю только ядро за ОС, как и не считаю только Docker за ОС, на что и пытаюсь вам указать.
-4

Думаете суть бы изменилась, если бы её назвали DockerOS? Или если бы функционал докера перенесли в ядро?


А судя по картинке — использует.


image

+1
1. Дело не в названии, а в том, что Docker сам по себе работать не может — ему нужно ядро с определенными сервисами. Есть Docker и есть ядро — это разные компоненты, с разными обязанностами.
2. Если бы функционал Docker-а перенесли в ядро, то все баги Docker-а стали бы исполняться в привелигированном режиме, в дополнение к багам самого ядра — как минимум пострадало бы качество (разделение на сравнительно независимые части — довольно фундаментальный инженерный принцип).
3. А вы не по картинкам смотрите, а запустите ее у себя. Вы увидите, что стандратные утилиты (cat, grep и тд и тп) — самые обычные процессы, а не контейнеры.
+4

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

0
Я не очень понял как это относится к моему комментарию непосредственно. Но вообще программы, модули, конфиги и библиотеки уже сейчас можно хранить с версионированием, но не в БД, а в подходящей файловой системе (Btrfs и ZFS поддерживают дешевые snapshot-ы — перед изменением/установкой/удалением создаете snapshot и, если что-то пошло не так, просто откатываетесь к этому snapshot-у). Для версионирования конкретно конфигов можно просто использовать git/svn/etc, но это, скорее, для конфигов, которые мы пишем сами.

Но даже с учетом всего выше сказанного, не понятно, каким образом версионирование позволит пакетному менеджеру узнать о конфигах, о которых ему никто ничего не сообщал и удалить их?
+3
В винде проблема с удалением именно в том, что у каждой программы свой деинсталятор, а разработчики деинсталятора забивают на качество его работы.
Такие люди и на качество самого приложения обычно тоже забивают. Например, положат в виндовом реестре в HKLM то, что должно лежать в HKCU, а потом ещё пишут свой собственный велосипед для реализации HKCU внутри узла из HKLM.

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

Это не в винде проблема, это в криворуких программистах, которые не могут в MSI.
+2

Если бы у этого MSI было чуть-чуть по-больше документации… Потому что сейчас "не могут в MSI" даже сами Microsoft.


Посмотрите на те же VC redistributable packages. Хоть одна доступна в формате MSI?


PS Привет пакету, кажется, от 2008, который при установке выдавал ошибку если он был уже установлен в системе :)

+1
у 2008 была другая более мерзкая проблема — он срал не в %TEMP%, а в корень самого свободного диска — то есть во-1х, кто тебя, сволочь, просил? а во-вторых, если у тебя например MacDrive или аналогичная приблуда, с дисков которой НЕЛЬЗЯ запустить бинарники — то всё, приплыли.
+2

Да бардак с конфигами и линуксе и в винде. Где-то sqlite (читай — у каждого приложения свой формат в виде схемы БД), где-то gconf, где-то ini, где-то xml.


Разрабатывал программы (под windows), где одновременно используется 3-4 вида конфигов. Привести их к единому реестроподобному формату, кстати, не получилось. Файлы конфигов, конечно, можно удалять, но этот зоопарк всё-таки не выглядит "чисто".

+7

Мне как пользователю совершенно не важно какой там конфиг. Главное чтобы я мог его очень легко найти в совершенно конкретном месте и удалить при желании (чтобы сбросить настройки или после удаления приложения). В Windows у меня этого никогда не получалось. Начиная с рядовых приложений разного калибра, и заканчивая компонентами с обновлениями самой ОС. Система постоянно патологически накапливает мусор.

0
gconf/dconf, разве нет?

Единственное, еще бы договорились, который из них оставить. Вот в упор не понимаю, зачем их ДВА.

+1

Dconf вроде как более новый (на диске данные в бинарном формате хранит), а gconf это legacy (там данные хранятся в xml файлах). Все новые приложения используют именно dconf.

0
в Windows большинство приложений не могут собственную папку удалить из Program Files при деинсталляции

У меня вот на сервере болтается в etc каталог Apache2. Сам апач давно удалён, и этот каталог удалялся, но он восстанавливается при обновлении php7.0-fpm.
Логика? Нет, не слышал.
+3

Установили php7.0-fpm, в папку apache2 скопировался его конфиг для этого веб-сервера. Удалите пакет — удалится и директория. Всё под контролем менеджера пакетов. Да, кривовато слегка, но всё вполне логично.

-1
Ну а посмотреть, что никакого апача нету, и конфиг для него- просто мусор, apt конечно не может.
+1

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

0
Вот решение этого через хуки- это и есть «кривовато». Почему бы не сделать в пакетном менеджере поддержку опциональных зависимостей со своим деревом файлов, которое нужно копировать, когда оно есть, и не нужно, когда эта зависимость не установлена? Заодно эту зависимость можно разрешить в ситуации после установки основного пакета, когда ставится опционально зависимый, чего не сделаешь через хуки.
+2

Так есть опциональные зависимости, кто вам сказал что их нет:) Всё зависит от того, как мейнтейнер соберет пакет. Ваш пакет собрал таким образом. Кривовато, но ничего страшного.

+2
а если вы сделаете «apt install php7.0-fpm; apt install apache2»? первая команда видит что апача нет и конфиг дня него не кладет, вторая команда ставит апач, а конфига для php7-fpm нет, тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов» и после установки апача вызывать что-то типа «перераскладывания примеров конфигов для php7-fpm и всех остальных, у кого могли быть примеры конфигов для апача» при этом попутно решая что делать с «вручную исправленными конфигами». К тоже же кмк идеологически неверно при установке апача как-то реконфигурировать совершенно другой пакет. Да и к тому же не очень понятно чем вам мешает лишняя директория в /etc. Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.
+1
тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов»

Выше отписали, что подобное уже есть.
Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.

Вообще- то замедление ОС из-за реестра является мифом. Так как реестр по сути является базой данных, то его объём никак не влияет на скорость его работы.
+1
Не мешайте людям раз за разом использовать «Чистильщики реестра» и «Ускорители компьютера», чтобы потом жаловаться, что ничего не работает. Это их выбор
0
Конечно это их выбор, но они носятся с утверждением «Винда глючит и тормозит, я каждые два месяца её вынужден переставлять, реестр загажен».
0

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


В Windows это делается через панель управления, в UNIX-системах — через менеджер пакетов либо (если собирали из сорцов) с помощью make uninstall.


Другое дело, если разработчик накосячил с удалением. Тогда уже для винды нужно использовать всякие там full remover, а в случае с UNIX — всякие там checkinstall и пр.


И в случае обоих систем (Windows и UNIX-подобное) если вам нужна абсолютная гарантия полного удаления пакета — восстанавливайте ОС из бекапа. (Замечу, что NixOS [как минимум в теории] поддерживает абсолютное удаление; так, как если бы система была восстановлена из бекапа; потому что там состояние всей ОС определяется всего небольшим количеством конфигов)

-1
не видел ни одного приложения под win, которое удаляется ПОЛНОСТЬЮ, не оставляя файлов/записей в реестре.
0
Наоборот, на мой взгляд, редкость, когда что-то остается. Это очень субъективно, зависит от набора используемых программ.
+9
Теперь я примерно представляю как мог размышлять Поттеринг создавая свои решения. Вот это все «надо везде использовать JSON, XML и бинарные форматы, а потом просто их дополнительной программкой в человеческом виде выводить».
+8
Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками. Не пришлось бы парсить вывод самостоятельно
-4

Лучше всё же формат Tree, он и машиной и человеком легко читается, чего не скажешь о JSON и XML.

+1
Не лучше, т.к. JSON в любом языке есть, а Tree где-то брать надо
+1

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


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

0
Эти структурированые текстовые форматы суть одно и тоже, плюс-минус «множество восхитительных функций»(с) сверху. Смысла менять одно на другое особого нет. Есть структура и хорошо. Впринципе (для вышеописанной задачи) и ini сгодится. Но JSON популярней. Еще можно XML — он тоже есть почти везде.

Кстати, насчет ini… Мне лично очень понравился toml. Тоже человекочитаемый. Но, в отличие от, реально используется, хоть и в узкой нише (конфиг менеджера пакетов Cargo)
0

Что значит "менять"? Сейчас приложения выдают плоский текст без какой-либо структуры. Так что вкручивать любой формат одинаково сложно и выбирать нужно не по принципу "для какого там формата есть либы для большего числа языков" (ответ — XML, но слишком громоздкий во всех смыслах), а по принципу "какой формат лучше подойдёт", а либы под разные языки быстро появятся, если формат не такой сложный, как YAML, последней версии которого, до сих пор почти нигде нет.

UFO landed and left these words here
0

А зачем вам обновлять машину, которая 10 лет работает и у вас все хорошо? Ну и не трогайте ее, никто вас не заставляет, но пожалуйста, не тормозите тех, кому все эти костыли осточертели.

+1
Tree выглядит интересно, но как сказал Jaromir, его надо где-то брать. Можно, конечно, поставить конвертер по дороге, но это уже костыль.

В нашем мире существует неимоверное количество различного легаси и заставить что-то переписать под новый формат потому что он лучше просто не выгодно экономически.

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

Я все это говорю к тому, что переход на новое возможет только тогда, когда возможности старого абсолютно исчерпаны и написание костыля обойдется дороже, чем просто взять и написать заново.
0
Неужели в IT всё оценивается чисто экономически? А как же красивый код, идеальная архитектура, тяга к прекрасному, и прочая ерунда)
+1
Это тоже имеет экономические последствия на большом отрезке времени
0
Неужели в IT всё оценивается чисто экономически?

Это загнивающий капитализм )
А как же красивый код, идеальная архитектура, тяга к прекрасному, и прочая ерунда)

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

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


Меня вот это удивило. Грамотный системный архитектор так ведь делать не станет. А заранее продумает всё так, чтобы было хорошо и красиво. А если уже продумано неправильно, и поезд ушёл — исправит ошибку как можно скорее, а не дожидаясь того момента, когда «всё, катастрофа, поддерживать это не реально». Имхо
0

Исправить ошибку как можно скорее можно только когда поезд еще не ушел.

0
Грамотный системный архитектор так ведь делать не станет. А заранее продумает всё так, чтобы было хорошо и красиво. А если уже продумано неправильно, и поезд ушёл — исправит ошибку как можно скорее, а не дожидаясь того момента, когда «всё, катастрофа, поддерживать это не реально». Имхо

Если это стартап, то ситуация может быть следующая:


  1. Быстро нужно дэмо, чтобы показать концепцию инвесторам
  2. Инвесторов не волнует насколько стремно будет написан код — пусть уже начнет деньги приносить
  3. Код пишется поверх дэмо без какого-либо дизайна
  4. Для новых фич пишутся костыли, потому что дэмо этого не предусматривало
  5. Дизайна все еще нет, так же как и архитектора, который бы этот дизайн написал
  6. Количество костылей превышает критическую массу и добавление фич больше невозможно
  7. Частично пишется дизайн каких-то модулей и куча говнокода приводится к нему
  8. Добавляются новые фичи и костыли для них до очередного витка переделок

Отдельным пунктом, если стартап нанимает аутсорсинг, желая сэкономить на расходах, добавляется возможное отсутствие ТЗ как такового либо наличие очень сильно чернового и неполного варианта. Не забудем что на нормальное тестирование у стартапа денег тоже нет и тестирование многих фич происходит на основании неполного ТЗ самими аутсорсерами в сжатые сроки.


З.Ы. Добро пожаловать в мой мир

0
А что мешает потратить неделю-две на дизайн до пункта 2?.. Там-то никто не гонит :)

Если проект очень сложный — может, займёт и дольше, но мы же про относительно простые стартапы, верно?

Ну или как вариант — заморозить виток новых фич, и недели 2-4 заниматься только рефакторингом и устранением костылей, а пользователи типа переживут. Всё-таки стабильность дороже :) А то начнёт всё падать из-за багов — клиенты точно разбегутся.
0
А что мешает потратить неделю-две на дизайн до пункта 2?.. Там-то никто не гонит :)

Ничего, кроме торопливости начальства и ТЗ с детализацией уровня "как-то так должно работать".


Если проект очень сложный — может, займёт и дольше, но мы же про относительно простые стартапы, верно?

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


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

0
Я почему-то думал, что в стартапе разработчики — сами себе начальство. Ну и кто-то один главный. Так только в кино бывает? :)

Потому и писал, что к пункту 2 времени в теории — неограниченное количество, если конечно нет конкурентов с той же идеей.
0
Я почему-то думал, что в стартапе разработчики — сами себе начальство. Ну и кто-то один главный. Так только в кино бывает? :)

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


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

А как же теория спелых яблок?

0
Кратко — «куй железо, пока горячо». Или «седлай волну, пока не ушла».
0
Гугл про такую ничего не знает)) А что не знает Гугл, то я не могу знать тем более. Какие тут шутки…
0

Странно, что гугл не знает этого.


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


Собственно, если есть новая идея, то вероятно кто-то уже над ней работает.

+2
> Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками.
И сильно увеличило бы время на парсинг/генерацию этого самого JSONа. Я не говорю, что текст, это всегда хорошо, но да, я действительно предпочту текст, когда мне нужно распарсить текстовый файл на 500 МБ, написав скрипт для этого всего за 10 минут.
Пример из недавнего прошлого: Задача сводилась к поиску нескольких тысяч ключей по несортированному дампу с порядка 8 млн записей. К слову grep (вызов в цикле из bash скрипта) позволял делать порядка 10 проходов в секунду (!), файл лежал в горячем кеше после первого прохода.
Другие языки (пробовал на php7 и python) с задачей справляются в 3 раза медленнее, даже если предварительно прочитать файл в RAM, и только специализированная БД (redis в моем случае) позволила увеличить скорость в 10 раз.
0

А в этих "других языках" вы использовали какие-то индексные структуры? По-хорошему этот дамп нужно впихнуть в любую БД, построить индексы и искать по ним. В redis, наверно, так и получилось. sqlite, думаю, тоже подойдёт (да хоть MS Access, бывало и такое).


grep использует всякие продвинутые алгоритмы строкового поиска, которые вряд ли есть в стандартных библиотеках php/python/etc. Вручную быстрее вряд ли напишете.

0
Не использовал, опять таки, не было задачи. Про продвинутые алгоритмы в grep вы правы, но первоначальная идея была в том, что он все-равно читает файл каждый раз последовательно и всегда до конца, но полученная скорость grep меня поразила.
+33
Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом.

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

+7
Вот прямо с языка сняли. Меня всегда удивляли авторы, которые выискивают неведомые редкие кейсы, жалуются на сложность( но не невозможность) их решения, а потом поносят систему в целом. Да в никсах можно вообще все сломать командой из нескольких символов ( привет gitlab) и что ж теперь? Реестры писать? Да ну нахрен!
+1
На самом деле подобная хрень может возникнуть :) Как-то раз мне в руки попал роутер с каким-то очень обрезанным линуксом на борту и там не было даже улитилы dd, не говоря уже о такой замудреной вещи как find.
+3

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

0
И вы конечно же сделали вывод что все unix системы полный отстой и куча костылей? Я надеюсь нет.
+1

Однажды постучался я по ssh на девайс, ввожу find . -iname "*.jpg" -exec cp {} ./ \;, а он мне такой: а нету тут find-а!

+12
Судя по контексту статьи и постоянным переходам на личности, автор считает всех идиотами, а себя видимо самым умным. Поэтому даже не дочитал. Подача материала на 2.

Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал.

Спасибо, не пиши больше.
+17
Статья написана вполне нормально. Для тех кто реально понимает и на практике с этим сталкивался, все понятно и знакомо.
А если писать более подробно, то будет не статья а многотомное собрание сочинений.
-1
особенно словечки sic! Бугога и т.д., реально на практике часто сталкиваюсь, все понятно и знакомо.
Тьфу!
0

@DexterHD, nightvision, стиль статьи, слова "бугога" и пр. — это типичное явление в американских блогах, в том числе в переводах статей из американских блогов на Хабре, почитайте их (хотя у меня не перевод). Особый стиль нужен, что "встормошить" читателя, который и вправду фанатеет от UNIX. Сказать ему, так сказать: "Проснись, UNIX давно устарел!"

0
А, так вот почему всю статью было впечатление, что это чей-то перевод…
-1

Посмотрите мой коммент выше, DexterHD (я не уверен, что парсер Хабра вас с первого раза пинганул)

UFO landed and left these words here
0

@basilbasilbasil, kirillaristov, сарказм, отсылка к философии UNIX? Что? А, вон оно что! :) В общем, нет, я об этом не подумал, это было сказано в прямом смысле

0
сарказм, отсылка к философии UNIX? Что? А, вон оно что! :)

Так и рождаются «синие занавески»
Скрытый текст
image
+11
Полностью согласен с автором. Я не такой спец по юниксам, но сталкиваться приходилось достаточно. Кривизна make и shell сразу бросается в глаза. Кривизна препроцессора С/С++ и отсутствие в них модульности — тоже (хотя пишу на С/С++ как основном языке уже много лет).
С другой стороны многие концепции в юниксе очень удачны и даже гениальны. Есть фундаментальные вещи из линукса которых очень не хватает в винде. И наоборот.

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

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

Так, вместо make давно бы уже перешли на qbs. Что мешает корпорациям, осуществляющим основной вклад в разработку того же линуса, перейти на эту технологию? Если там чего не хватает — ну так оно и выяснится, сформировали бы консорциум, подумали бы все вместе. И постепенно вытеснили бы make. Но нет — оно же «и так работает»… печально все это.
+2

Назовите хоть одну вещь из Windows, которой не хватает в нынешних *NIX?


Also есть scons.

+2

ACL? Из-за них, кстати, файлы WSL из-под винды трогать не надо.

+1
Есть Posix ACL. Можно подробнее что в Window-ых ACL есть, чего не хватает в Posix ACL?
0

И в какие популярные дистрибутивы он входит «из коробки»?


Такие доводы напоминают Джаббер: там тоже есть 100500 расширений, только все нестандартные и разной степени костыльности. И где этот джаббер? Все сидят в Вотсапе или Телеграме.

0
В ubuntu они есть по-умолчанию, другое дело, что чтобы они начали работать их нужно настроить (но простите, настройка ACL по-умолчанию — это какой-то странный зверь, что он и кому будет разрешат/запрещать?).
0

И сколько процентов пользователей пользуются там Posix ACL? А сколько утилит его поддерживают?

+3
Пользуются те кому Posix ACL нужен, не пользуются все остальные. Какое отношение сколько утилит его поддерживают имеет к делу? Хранением ACL занимается ФС, проверкой ядро, редактирование ACL делается через специальную утилиту — какие еще утилиты вам нужны?

Вы не могли бы отвечать по существу, что такого в Windows ACL есть, чего нет в Posix ACL? Ато разговор очень странный получается, вы вопросы задаете, ответы получаете, но сами пока ни на один вопрос не ответили.
0
nested ACLs? наличие более точной настройки чем rwx? на NTFS 13 разных разрешений, например (или 14, если считать Full Control за еще одно).
+4
nested ACL и в NTFS на самом деле просто рекурсивный обход с установкой дочерних аклов равным родительским по дефолту, так что в линуховых аклах с этим легко справляется setfacl -Rd
А вот с более точной настройкой, чем rwx тут конечно да, но, с другой стороны, довольно сложно придумать ситуацию, когда, скажем, надо дать группе разрешение создать каталоги, но не разрешать их удалять или создавать в них файлы… NTFS такое позволяет, но, как бы… зачем? :)
0

Как вы еще разрешите всем пользователям компьютера создавать папки в корне диска, но запретите им "залезать" в чужие?

0
Легко. Выдать каждому свой корень, тот же %USERPROFILE% или /home/$username и в нём хоть обсоздавайся. А в истинном корне юзерский срач разводить — это признак плохой архитектуры.

И кстати, по-моему это и с общим корнем можно сделать без ACL. Какое-нибудь chmod go-rwx и всё.
+3
В юниксах довольно давно есть фича, делающая именно то, что вы сказали. Т. е. установить специальный бит на папку так, чтобы в этой папке все могли создавать, но при этом нельзя было лезть в папки, созданные другими. Этот бит стоит по дефолту на /tmp в GNU/Linux, т. к. именно для /tmp такая функциональность обычно и нужна.
0
nested ACL и в NTFS на самом деле просто рекурсивный обход с установкой дочерних аклов равным родительским по дефолту

Это если разрешено наследование, а так да.
+1
под nested acl я имел в виду возможность наследования групп — то есть у тебя допустим папка «файлопомойка», в которую могут писать «отдел 1», «отдел 2» и «отдел 3». в каждой из этих групп — подгруппы, типа «менеджеры отдела Х», «начальство отдела Х» итд. в posix ACL тебе придется все эти группы прописывать вручную, что очень быстро выльется в нечитаемый зоопарк.

хотя щас что-то интересно стало, насколько это сидит в NTFS, а насколько раскрывается средствами домена/AD.

а расширеные права хороши для файлопомоек тех же — создавать write-only каталоги, чтоб никто ничего случайно лишнего не грохнул или не перенес в 20й уровень вложенности.
0
хотя щас что-то интересно стало, насколько это сидит в NTFS, а насколько раскрывается средствами домена/AD.

Поясните тут, я тоже сейчас задумался, возможно ли такое реализовать стандартными средствами на обычном ПК без АДа.
+1
Да, возможно.
В NTFS в ACL указываются только токены SIDов, а их семантику определяет либо локальный SAM либо сетевой AD — какой SID обозначает аккаунт, какой группу, и членами каких групп являются известные группы и аккаунты.
Поэтому на уровне разрешений ФС нет принципиальной разницы между SAM и AD.
-1
Поэтому на уровне разрешений ФС нет принципиальной разницы между SAM и AD.

А на уровне интерфейса нащёлкать такое можно?
0

На уровне интерфейса нет принципиальной разницы между пользователем и группой. Composite во всей красе.

+1

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

0
У меня такое ощущение, что вы даже не пробовали залезть в штатный виндовый (гуёвый!) редактор ACL. Попробуйте, там всё достаточно интуитивно.
0

Это nested groups, а не nested acl. Данная фича относится к модели безопасности системы, а файловая система работает с группами пользователя как с данностью.


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

-1

Лол, по-моему все новомодние FS включают настолько всего много, что ACL там есть по дефолту.


Кстати ACL были в UFS с 2005, а acl nfs уровня с 2009, бородато. Не знаю насчет EXT но другие ФС поддерживают это давно.


ZFS это включает из коробки почти с рождения, если мне не изменяет память.


Конечно если жить во времена FreeBSD 4, когда мелгкомягкие перли все у всех для своей новой Win NT, тогда да, NTFS был крупным апгрейдом.


А сейчас когда я могу делать мгновенные снапшоты для 250 ZFS датасетов в одну секунду, делать ограничения на разных уровнях, иметь файловый доступ к снапшотам без маунтинга, возможность атомарного восстановления, компрессии разного рода, дедубликации, возможности дописывать метки и кастомные метаданные к датасетам (для конфигурирования бекапа например).


Все это с резервированием разного уровня и главное возможностью репликации по сети только изменений!


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

0
Таймлайн свой поправь. FreeBSD4 существенно моложе NT

А ZFS в продакшн пошла так вообще недавно по таким меркам
-1

Нет таймлайн корректен. FreeBSD 4 была all the rage back then, т.к. Linux был bleeding edge. Однако ФС была хоть и стабильной, но достаточно устаревшей на момент релиза. Windows NT 4 был all the rage, 3.1 3.5 не так известны, но несли в себе красивую NTFS.


ZFS в релизе с 7ки, с 8ки уже сплит пошел. С 7ки уже 9 лет прошло...

0
Все это с резервированием разного уровня и главное возможностью репликации по сети только изменений!

DFS и differential replication в виндах что-то около 15 лет как минимум.
+2

Смайлик, конечно, классный аргумент, но не могли бы вы поделиться с нами, почему упоминание powershell вызывает у вас истеричный смех?

-3

Без проблем, я не буду искать статьи в бложиках, напишу отсебятину.


Powershell, конечно, отличная замена CMD, однако это по сути "у нас 13 стандартов… теперь 14". Шеллы конечно не прелести, но powershell кажется чем-то вроде интерпретатора, в котором случаем прикручена консоль и атрибуты командных ключей.


В итоге часто не ясно, команда это или шелл вызов или же .NET вызов.


В шелле *nix всегда ясно, что пайп, а что нет, ясность многое дает, когда необходимо делать дела быстро.

+3

Вы можете сходу сказать что из этого команда, шелл вызов и c-вызов: ls, cd, printf? Если нет, то почему вас это не волнует, а в случае powershell, внезапно, имеет критическое значение?

+3
«Прочел статью, что powershell плох, Windows плох, Unix и bash прекрасны, и поверил»
+1

powershell имеет проблемы с запуском внешних утилит даже на винде. Точнее, с разбором их вывода.


Во-первых, любой вывод в stdout парсится как строка в текущей консольной кодировке. Если кодировка не совпадает — исходные байты восстановить может уже не получиться.


Во-вторых, любой вывод в stderr рассматривается как ошибка. Правильнее было бы вовсе не перенаправлять этот поток — но powershell так не умеет.


В-третьих (хотя на линуксе этот пункт будет неактуален) — задать кодировку консоли довольно сложно. Особенно при запуске через WinRM...

0

Если собираетесь сделать проект свободного ПО, не юзайте scons. Сам я ничего про него не знаю, но в debian upstream guide не рекомендуют: https://wiki.debian.org/UpstreamGuide. Во всех остальных случаях, т. е. если это просто некий проект, не предназначенный для выкладывания на публику в виде сорцов, то, видимо, можно

+3
Вы так говорите про переход с make на что-нибудь другое, как-будто под Unix-ами законом запрещено использовать что-то кроме make. Какую систему сборки использовать для своей программы решает ее автор — это не ограничение Unix.

Если под линуксом вы имеете ввиду ядро линукса, то разработчики ядра сделали себе свою собственную систему сборки (которая опирается на make, но не является просто make-ом), которая удовлетворяет их нуждам, что очень логично — разработчики пользуются теми средствами разработки, которые им удобны.
0

Возможно дело в том, что "самое удобное средство из доступных" никуда не годится?

+1
1. Где в этой фразе упоминается make? И что он самый удобный из доступных?
2. Фраза выдрана из контекста, в котором говорится о том, что разработчики ядра Linux (вполне себе конкретная группа разработчиков), сделали для себя свою собственную систему сборки, которая им удобна (именно им, а не всем подряд), и кроме того эта система сборки не make, а Kbuild.
-2

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

0
Это иллюстрирует только тезис о том, что make не подходит для разработки ядра Linux — что совсем не то же самое, что и «никуда не годится». Кроме того пожалуйста потрудитесь проиллюстрировать оставшиеся части, а именно: «make — самое удобное стредство из доступных».

Так же обращу внимание, что они не только отказались от make, но и от всех остальных систем сборки в том числе, коих не мало. Что замечательно иллюстрирует тезис о том, что разработчики пользуются тем, что им удобно, и, в частности, если достаточно удобного средства нет создают свое. И обратите внимание, в утверждении нигдже не упоминается Unix. Почему? Потому что Unix тут совершенно непричем, а система сборки не ограничение навязанное Unix идеологией.
+1
Ага, то, что вы в ферарри можете загрузить только 5 мешков картошки, а не тонну, говорит о том, что феррари гавно машина и никуда не годится. linux как раз отличается тем, что никто не заставляет вообще использовать make. Если у вас простой проект, можете вообще под него отдельно написать скрипт. Да хоть на перле, хоть на go.
+6
Так, вместо make давно бы уже перешли на qbs.

Может быть потому, что make — это ровно один исполняемый файл в ~200КБ и одной зависимостью (stdlib), а не часть Qt-комбайна?
+2

qbs хорош, но кажется он рип, сам Qt не будет на него переходить, а будет переходить на cmake, а так аналог qbs, но без зависимости от Qt и с умением докачивать и собирать зависимости был бы неплох.
В принципе на замену make есть ninja, где все, вроде бы, сделано по уму, и на него таки потихоньку переползают.

0
идеи, на которых основан qbs, хороши и практичны. Но во-первых, qbs еще на этапе становления (не так уж и редко выходят breaking changes), во-вторых, комьюнити — два с половиной калеки (вплоть до того, что на все мои вопросы по qbs на so ответил один и тот же человек). Из-за этого по сути 90% информации, которую вообще можно найти в сети по qbs — официальная документация. Она хороша, но скорее в виде справочника, нежели подробного пособия.
+3
Сочный вброс. Ждем овер 9000 комментов «у меня все нормально, чяднт?»
+5
Заловок конечно слишком жёлтый, зашёл посмотреть на крах, а про него почти ничего и не сказано:
> авторы UNIX фактически придумали для каждого системного конфига… свой формат

и при чём тут философия? она разве запрещает все конфиги сделать в YAML?
также и с выводом

> Но ведь у UNIX shell полно других недостатков. Нужно выкинуть его вовсе и заменить на некий другой язык

да, что-то питоноподобное было бы в тему, но это снова не о философии, шеллов много всяких пытаются сделать и философию это не отменяет

С моей точки зрения главный принцип философии юникс это декомпозиция на небольшие программы которые делают что-то одно и ему альтернатив не видать.
0
> и при чём тут философия? она разве запрещает все конфиги сделать в YAML?
Запрещает legacy, у чужой программы на YAML конфиг не переделать. Ну или пилите полностью свой дистр с блекджеком и yamlами, только он никому не нужен будет.
0
Только легаси это легаси, а не философия, не надо в кучу смешивать.
+5
Я думаю автор имел ввиду, что философия не запрещала, но и не форсировала какой-то хороший подход. В итоге имеем тонны легаси, с которыми почти ничего не сделать.
0
и при чём тут философия? она разве запрещает все конфиги сделать в YAML?

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

У yaml все с отступами странно, можно огрести неплохих проблем с непривычки.

0
YAML это лишь пример, а привычка это дело привычки — если бы ямл был стандартом то все бы привыкли
+1
С моей точки зрения главный принцип философии юникс это декомпозиция на небольшие программы которые делают что-то одно и ему альтернатив не видать.

Если считать философией UNIX именно это (без отсылки к UNIX shell и пайпам), то ничего против такой философии я не имею (с оговоркой, что иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше). Проблема в том, что многие люди начинают относить к философии UNIX её конфиги, многие особенности написания скриптов на shell

0
> большие и сложные программы типа Photoshop или [о боже!] Microsoft Office

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

> иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше

например когда?
+1
они вполне могут соответствовать философии юникс, например быть гуём ко множеству утилит, философия гуй не запрещает

Не запрещает, да.
Но когда средства документооборота и допечатной подготовки начинают разрабатываться в русле этой философии, то получается в лучшем случае latex с его эзотерическими сообщениями об ошибках, которые устраняются далеко не там, где возникли, с его взаимоисключающими зависимостями в документах, которые почему-то прекрасно собираются тем же latex'ом на другом дистре, и где «в случае ошибки запустите этот же шаг повторно 2-3 раза» (и это реально помогает, см. bibtex). Конечно, потратив месяцы вдумчивого курения мануалов, гугла и экспериментов, на latex'е можно творить чудеса, почти недосягаемые для поклонников мс-ворда. Я на нём свою докторскую диссертацию написал, например. При всём этом, именно эта философия жутко гетерогенного пайплайна в продакшне заставляет меня нервно дёргаться каждый раз, когда невинная текстовая правка начинает бросать overfull hbox'ы в неожиданных местах, а уж как там таблицы рисовать — это просто пиндец по сравнению с тем же вордом.
Всё же интегрированный инструментарий имеет свою нишу, в которой философия юникса сосёт не нагибаясь.
0
Проблемы латеха не означают что дело в философии, никто не мешает авторам ворда выделить ядро в отдельный инструмент, хуже оно от этого работать не станет, а будет более философски.
+2
Именно в ней и дело. Мешает то, что философия гетерогенных инструментов в пайплайне приводит к появлению легаси на стыках этих инструментов. Устранение этого легаси вызывает лютый баттхерт у юзеров, которые рассчитывали на обратную совместимость, а оставление этого легаси вызывает такой же баттхерт у разрабов, эффективность которых снижается из-за необходимости его поддержки (в результате чего получится ещё один клон того же латеха).
Интегрированный инструмент свободен от этих недостатков — разрабы вольны как угодно менять внутреннюю архитектуру, так как юзер ожидает лишь совместимости форматов хранения данных и не более — в этом и проявляется главный недостаток т.н. «философии юникс».
0
Да, есть неудобство, при смене API желательно делать обратную совместимость и возможно какие-то ключи для вывода в новом формате, но как-то софт уже десятки лет развивается — решают эти проблемы.
0
Так и решают, как я описал. Латех в своей нише с юниксовой философией, интегрированные офисные продукты — в своей нише, с облаками ажуров, эксченджей и прочим корпоративным буллшитом.
Так что нет, философия юникс — не универсальный ответ.
0

Когда я делал очень большие документы в Word, там было не меньше проблем. Только эти проблемы в принципе устранить было нельзя. Если в latex можно еще раз перечитать мануал, попытаться что-то переделать, в крайнем случае, залезть в исходники, то если что-то не работает в Word, чаще всего нет никакого выхода. И latex все-таки работает по четко описанной логике. А в Word если 10 раз накликал мышкой новую строку в таблицу, а на 11 раз вся таблица исчезла или сморщилась, никакой логики нет — просто проявление очередного бага, и даже если удастся найти workaround, это не дает никакого бонуса — работать дальше не станет легче.


Правда в последний раз работал и с тем и с другим очень давно, более 10 лет назад. Надеюсь, что с тех пор качество Word поднялось.

0
Не знаю, как в последних офисах, но, к примеру, в 2010-м всё так же колонтитулы первой страницы применяются к страницам, на которых меняется формат или ориентация. Более того, изменить формат или ориентацию одной страницы стало ещё более нетривиально, чем в 2003 офисе.
0
"иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше"
например когда?

Представьте себе workflow некоего сотрудника. Это может быть программист, художник, писатель, кто угодно. Если workflow уже "устаканился", т. е. уже известно, что, в общем-то нужно будет делать сегодня, завтра и так далее, то всякие интегрированные среды, всякие IDE, фотошопы, офисы подходят лучше. Потому что там нужно сделать меньше телодвижений для выполнения действий. Там всё "просто работает".


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


А если ещё не "устаканился" и нужно постоянно решать новые непредусмотренные задачи, то типичный UNIX environment подходит лучше. Там можно вообще всё, если захотеть.


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


Но даже программистам работать во всяких IDE обычно проще. Просто если ты разрабатываешь нечто совсем новое, скажем, новую ОС, тут уже IDE подход даёт сбой, т. к. там такого не предусмотрено. Тут уже берёшь в руки vim, emacs и прочее

+4

Честно говоря, какой-то сырой текст, пытающийся разжечь холивор, но без изюминки. Вроде лет 25 назад написали The Unix Haters Handbook, по-моему, большинство вашей критики взято еще из этой книги, но все войны по ее содержанию уже лет 15 как отгремели, даже скучно уже ввязываться.


Первую треть еще как-то прочитал. Особенно насмешило про «недостаток» текстового формата /etc/passwd. Дальше уже было сложно заставить себя тратить время на текст, который сам автор признает сырым.


Осталось еще два соображения. Как это такая плохая система существует уже более 40 лет, пережила уже и многих критиков, и волны различных hype, адаптировалась и к gui, и к мейнфремам, и к маленьким компьютерам, переход на Unicode и многое другое, и все это без значительных усилий? Неужели это признак плохой продуманности?


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

+5
ВАЗ 2107 тоже много чего пережил, видать дофига продуманная машина :)
+4
Ну вообще-то, продуманная. Просто, при определённых вводных. Оптимизация UNIX по памяти — тоже не из пустого места выросла.
0
Двигатель внутреннего сгорания много чего пережил. Несмотря на legacy и костыли внутри.
+1

Вы, наверно, не поверите, но с ВАЗом все обстоит именно так, как вы сказали. Просто классический жигуль разрабатывался для страны и людей, которых уже нет. Другое время, другие запросы.

0

Возможно, автору стоило бы отвести душу издав продолжение "The Unix Haters Handbook". Но, разумеется, уровень критики должен быть выше — ведь за прошедшие годы и *никсы подросли и задачи их и уровень ответственности ОС и видение её достоинств и недостатков, требований одновременно изменилось и прошло проверку временем.

-1
Оффтоп: а что — модераторы хабра модерируют посты? Или автор разжигает срачик не только на этом ресурсе?
UFO landed and left these words here
0
Ещё бы «щасы» и прочие «я д`Артаньян, между прочим» фиксили, дабы ослабить кровотечения из глаз у читателей…
0

Предложите что-нибудь на замену. К сожалению, 99% нынешних систем набиты костылями под завязку — даже перечислять не буду.

+6

О, господи, ну и маразм с тем что все в файлах. Интерфейс у UNIX текстовый, соответственно хранить конфиги в тексте намного проще и понятнее человеку.
Разбирать не хуманизированный JSON или не дай бог XML глазками врагу не пожелаешь. INI или же банальные конфиги намного проще. Да сейчас есть YAML, но тогда его не было, а сейчас менять все на YAML поломает легаси.


Использовать реестр — вообще дурость, зачем нужна БД если есть кеш файлов? Реестр виндовый все равно не достаточно оптимизирован. Прелесть текстового формата в том, что ты открыл его и прочел, СРАЗУ осознав всю информацию, совершил необходимые манипуляции и закрыл его.


Да при 1000 юзеров уже надо использовать какую-то БД, однако утилиты для работы и так присутствуют так что этот вопрос тоже решен.


Человек что писал эти комментарии явно не понимает что UNIX использует KISS потому что необходимо понять и разобраться на месте, а не звонить Microsoft Support и ждать человека на следующей неделе если Вы не льете миллионы долларов в карманы мелгкомягких.

+5
а сейчас менять все на YAML поломает легаси.

На мой взгляд — основная проблема как раз в поломке этой возведенной в абсолют и обожествляемой legacy. Да, все признают, что напрямую его не используют, все через обертки, костыли, подпорки, но вот взять и выкинуть все это подгнившее нутро и заменить внутри на что-то более современное — не-е-е-е, это ж legacy, а вдруг у какого Васи Пупкина две с половиной программы сломаются? Так и живем.


А ведь стоило бы начать хотя бы с давно уже предлагаемых ключиках к стандартным программам для структурированного вывода в JSON. Даже просто как JSON-текст выдавать в пайп (а не как уже готовый JSON-объект) — все лучше, чем современный бардак.

+2

Так большинство конфигов не нужно далее CSV или KV хранилищей. Так оно и есть.
passwd это CSV без экранирования и с: в качестве разделителя. Остальные конфиги либо все K=V хранилища, либо уже в своем языке программирования тоже K=V хранилища, либо же на крайний случай INI, где вместо комментариев используют секции (что конечно же дурость микрософтовская, но что поделать).


Даже на винде большинство программ используют реестр только для регистрации ибо corruption реестра известная проблема издревле. Реестр Windows — это полнейший failure и очередной костыль.


Я даже написал администрирование и установку почтового сервера полностью БЕЗ использования БД ибо это намного проще в работе и с новыми ФС (ZFS) в частности желательно ИХ использовать как БД (где возможно). Ибо БД по сути костыль для древних систем, то самое легаси (соединительное между ФС и памятью). Сейчас набегут архитекторы SQL и будут меня разносить, на что я отвечу что перенести SQL язык в ФС проще, чем ФС в БД. В итоге меньше возможных точек поломок, меньшее количество администрирования, проще дебаггинг, стабильность со 99,99% годовым аптаймом. Со второй системой или отдельным закрытым ФС сервером можно аптайм до 100% поднять.


KISS в UNIX не от того что все дибилы, а от того что усложнение систем к стабильности не приводит.

+3
> passwd это CSV без экранирования и с: в качестве разделителя
DSV (delimiter-separated values), CSV это частный случай именно с запятыми.
+2
Эм, вы о чём?..

Не стоит мешать тёплое с мягким. База данных — это логическое понятие, и она не привязана к конкретному железу или файловой системе (но привязана конкретная реализация под платформу).
ФС — тоже логическое понятие, но у неё другие задачи, и она уже как раз ориентирована на непосредственное взаимодействие с физическим носителем (CDFS, FAT/NTFS/UFS/EXT/...).

База данных имеет свой язык запросов (как правило, это какие-то вариации SQL) и механизмы хранения. То есть типы таблиц и движки для их обработки. Таблицы как правило размещаются на носителе (допустим, это жёсткий диск). При этом ФС на этом диске может быть любой.

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

А доступ к файлам уже операционная система осуществляет, и на используемую ФС мы не завязаны и никак от неё не зависим (то есть для нас файл — это такой абстрактный блок из N байт, и как он там на самом деле хранится, нас не волнует).

И вы предлагаете отказаться от БД, серьёзно? И как тогда данные будем хранить?

Набор плоских файлов? Но всё равно кто-то должен делать поиск по ним согласно запросам. Вы, я так понял, хотите сделать такую ФС, которая возьмёт это на себя. Окей, но как быть с внутренним форматом этих файлов? Тогда тот модуль ФС, что будет выполнять функции движка, должен знать как минимум о структуре наших таблиц и их количестве. Где всё это указать? Как указать, что определённый файл или набор файлов содержит базу данных? Задать расширением — можно, но интерпретация расширений файлов — это прерогатива ОС, файловой системе всё равно, что за расширение у файла, она об этом «ничего не знает». Да и поиск по такому специализированному файлу тогда какой-то компонент ОС должен делать (и это уже видимо не будет относиться к реализации ФС, потому что общий процент таких файлов будет очень мал, логичнее в отдельный модуль такое вынести).

В итоге получаем просто встроенную в ОС СУБД на файлах. Так стойте, уже же для такого есть SQLite :D

И в чём смысл всего этого.
0
А например в случае JSON, для того же ls -R, как выводить: в виде единого массива с именами файлов, содержащих частичные пути, или в виде древовидной структуре, где массивы файлов подкаталогов доступны как значение объекта соответствующего записи родительского каталога. А если делаем ls -R tmp/…, то в JSON-
аналоге выдачи «tmp/..» разбивать элементы пути на компоненты? И давать ли JSON инфу про каталог, которому соответствует ".."? Уже получается 3 дополнительных опции.

Куда как проще использовать скриптовой язык, как и предлагает Пайк. :-D
0

Я думаю реализовать это так.


вызываем sub получаем список дочерних объектов:


/www/ sub

\demo
\index.html
\index.js

Хотим вывести не всё — фильтруем:


/www/
    sub
    filter type \file

\index.html
\index.js

Хотим конкретную инфу — дёргаем соответствующие инструкции для каждого объекта:


/www/
    sub
    filter type \file
    map type
        name
        created
        subCount
            sub
            count

file
    name \index.html
    created \2016-01-01T00:01:02Z
    subCount 0
file
    name \index.js
    created \2016-01-01T00:01:02Z
    subCount 0

Хотим вывода в виде таблички — используем table:


/www/
    sub
    filter type \file
    map type
        name
        created
    table

| type | name       | created
|------|------------|---------------------
| file | index.html | 2016-01-01T00:01:02Z
| file | index.js   | 2016-01-01T00:01:02Z
0

Из предложенных вами вариантов можно выбрать какой-нибудь один, не сильно важно, какой именно. Это будет уже лучше, чем просто текст. Далее, опция -R вообще не свойственна ls. Здесь я согласен со старой статьёй Пайка, которая "cat -v considered harmful". -R не свойствена ls, как и -v не свойствена cat. Вместо ls -R нужно использовать find или find -ls. А вообще, да, вместо shell нужно использовать какой-нибудь другой скриптовый язык. :)

0
-R

Вот это как раз меня больше всего бесит в консоли Linux: некоторые команды воспринимают ключ рекурсивного обхода в заглавном виде, другие в прописном. Ну почему?!
+1

Окей, конфиги кешируются. Но парсить их нужно всё равно каждый раз

0
Человек что писал эти комментарии явно не понимает что UNIX использует KISS потому что необходимо понять и разобраться на месте, а не звонить Microsoft Support и ждать человека на следующей неделе если Вы не льете миллионы долларов в карманы мелгкомягких.

Так против KISS я ничего не имею. Я говорил про другие аспекты философии UNIX, читайте внимательно

+2

Как сейчас модно говорить, у автора разорвало пукан!


Когда я только перешёл работать на linux (лет 10 назад) с windows у меня тоже было подобное настроение. Всё было неудобно, нелогично и убого. Вони было побольше, чем у автора. Но спустя пару лет я вдруг понял насколько проще работать и разрабатывать под Linux. На венду меня теперь не загнать. 25 лет пишу софт. Уж поверьте. :)


Так вот. Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз. И это огромная сила unix. В итоге, для настройки системы достаточно текстового редактора и интеллекта!


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


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


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


По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?


Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.


Про printf вообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.


Ну и так далее...


И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.

+2
Конфиги имеют может и примитивный, но не единый формат. А нередко конфиги имеют еще и скрипты внутри… Вот недавно была статья про GRUB. Там есть grub.cfg. Вроде и расширение «cfg» — но нет, куча скриптового кода на каком-то шелл-подобном языке (кстати, на каком? а понятия не имею, расширение же не «sh»… да и может ли быть «шелл» когда еще ОС не загружена?..)
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.

Далее. XML конечно тяжеловат, а JSON вполне нормален. Особенно предложенный JSON5. Это должна быть не замена «простым текстовым» конфигам (которые просто ключ-значение), а вариант для сложных конфигов, имеющих иерархическую внутреннюю структуру (а большинство таки имеет ее). Собственно, на этом форматами конфигов можно и ограничиться. И еще, одна вещь которая хороша в винде и не свойственна линуксу: расширения. Они должны быть стандартизированы, и для конфигов тоже. Это важно в том числе и для GUI -утилит, которые могли бы просканировать директорию с конфигами и предоставить пользователю унифицированные средства настройки системы из GUI.

Далее, бинарные утилиты. Ну так для текста тоже нужны специальные утилиты — текстовые редакторы. Нужно просто разработать простой и понятный бинарный формат и написать сначала стандарт, а потом и утилиты.

Далее, по языку С (и С++). 15 лет на них пишу, и главная проблема — именно отсутствие модульности и механизм инклудов. Нужно просто принять стандарты С 2.0 и С++ 2.0 в которых выкинуть (да, именно выкинуть, без оглядки на легаси совмесимость) весь этот ужас, и развивать дальше только их. Любые изменения в старый С и С++ заморозить на уровне комитета по стандартизации. Все новые вкусные плюшки добавлять только в 2.0. И все перейдут как миленькие. И легаси код перепишут — благо, в целом языки останутся очень похожими. Заодно в процессе переписывания и кучу багов исправят, т.к. некоторые вещи связанные с типизацией стоит сделать строже.

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

Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.
+5

Конфиги у нетривиального софта могут иметь еще и логику (если-то-иначе), и циклы, и много чего еще. Это не описать JSON. Теоретически годится XML, но XML — это ужас-ужас. Как вспомню XSLT.


Мне кажется, проблема высосана из пальца. Почти никогда не испытывал проблем с конфигами. Да, они часто очень разные, но так и программы разные, с разными требованиями. Никому не приходится работать с конфигами всех программ каждый день. Необходимый минимум легко запоминается по мере работы, в случае затруднений можно посмотреть man.


Например, я уже лет 5 или больше не трогал конфигурацию grub. Не было надобности. Если понадобится, разберусь с форматом конфига, и он мне еще 5-10 лет не понадобится.

+2
Это НЕ конфиги, а внешние скрипты. И они должны быть отдельно от конфигов.
+1
Это неоднозначный теологический вопрос. Например «конфиги» сети, почты, АТС по сути несут в себе сценарии инициализации оборудования и/или обработки данных.
+3

Третьему питону уже почти 10 лет, а до сих пор куча проектов на втором, а с/с++ намного сложнее и следует еще учесть что там нету одного стандартизованного компилятора, как CPython, на который ориентируются остальные интерпретаторы Python

0

У grub реально есть свой CLI. Так что всё логично. :)


Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.


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


Большие и жирные программы могут и в JSON хранить, если им так удобнее. Но ведь не хранят. Почему? Может простые форматы эффективнее для их решения?


Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман. За как будто ясным API скрывается ужас реализации с колоссальным дублированием кода и потреблением ресурсов. Я в 90-ых годах фанател от C++ и думал, что ООП очень помогает эффективности. Но когда познакомился с реальностью был в ужасе. Люди не умеют пользоваться ООП.


Лично мне в C не хватает строгой типизации и объявления функций в функциях с доступом к локальным переменным. Но даже имеющийся С годен. Достаточно просто делать продуманные API.


И кстати, про C 2.0 согласен. Можно было бы сделать :) Просто чуточку выправить. Но как грузить модули динамически со статической типизацией без извратов?


В целом спор бесполезен пока мы не договоримся о целях и приоритетах. Кто-то пишет компактно и эффективно, а кто-то пишет без оглядки на ресурсы, но с как бы комфортом. Отсюда и вкусы разные.

0
Я в курсе и про printf (то что существует printf это следствие отсутствия в Си синтаксических макросов, которые бы могли распарсить форматную строку на этапе компиляции, да еще и типы аргументов проверить...). Я в курсе как работает strcmp. И про json тоже.
Я не против SAX-подобной идеологии для конфигов (т.е. без «DOM», без хеш-таблиц и деревьев в памяти), и да — в большинстве случаев простого текстового файла типа «ключ-значение» будет достаточно. Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.

А что такое «грузить модули динамически со статической типизацией»? Модульность на этапе компиляции лишь означает, что никаких инклудов, а вместо них в проект подключаются модули (файлы в специальном формате — по сути сериализованные синтаксические деревья кода на С/С++), которые компилятор сразу все загружает в единое синтаксическое дерево, а не парсит один инклуд по 100500 раз для каждого *.c и *.cpp файла (precompiled headers это тоже костыли).
0

Я про модули не понял. Он же по сути состоит из двух частей: объявления и непосредственно кода. Объявления подгружаются с помощью include ибо они не должны быть большими(у разумных людей). А код уже скомпилированный в виде архива/объектника/библиотеки.


В объявлениях могут быть макросы коие никак не представляются в коде. Т.е. заголовки модулей не могут обладать всей мощью include. Следовательно модуль придётся упростить до набора внешних функций, переменных или констант.


Где-то в исходнике модуля надо ввести аттрибут 'extern' из которого в неявном виде будет выделяться объявление(такой уже есть).


Текстовые include вы не хотите, но всё равно придётся вводить директиву подключения модуля. Что-то вроде #import <stdio>. Оно чем-то принципиально лучше #include?

0
Я же написал — принципиальные отличия будут в работе компилятора. Почитайте как это устроено в C#, Java, в любом другом языке программирования. Модули это самая ожидаемая фича С++, кто об этом только не пишет.
Сейчас С/С++ работает так. Есть c(pp) файл — в нем в начале десяток инклудов, каждый из которых еще нередко тянет за собой кучу других инклудов. Компилятор рекурсивно раскрывает все эти инклуды и делает в памяти один большой файл, в котором включен код всех инклудов и в конце код собственно с(pp) файла. И все это колмпилирует.
Затем компилятор переходит к другому файлу. А там такая же ситуация (возможно набор инклудов немного другой). Итого, каждый раз(!) компилятор формирует в памяти огромные файлы с кучей всего и их компилирует.
И ладно в Си, там инклуды всего лишь объявления функций и структур. А С++ с его бешеными шаблонами? Когда огромные объемы кода (именно настоящего кода, а не объявлений) приходится держать в заголовочных файлах?
При модульности эта операция делается один раз для всего проекта. Да, разумеется единицей трансляции станет не файл, а проект — но что в этом плохого? Сами по себе концепции пофайловой компиляции и линковки тоже устарели, и их тоже давно пора пересмотреть.
0
Небольшое замечание. Я сталкивался с проектом на C++ (одна библиотека с не самым малым количеством шаблонов, она даже частично освещалась на хабре), так вот я не мог ее собрать, потому что компилятору просто нехватало памяти (8 Гб всего в системе) — при неудачном стечении обстоятельств, когда процессы (собирал 2-мя процессами) одновременно брались компилировать особенно страшные файлы все это дело фактически останаваливало систему целиком.

Суть истории в том, что в некоторых ситуациях делать целый проект единицей компиляции может быть не самой удачной идеей, потому что компиляция и линкова могут стать слишком требовательными к ресурсам. Прелесть модулей как раз в том, что их можно собрать один раз и потом просто использовать. Но с шаблонами C++ и необходимостью объявления перед использованием не очень очевидно как этого добиться. Лучшее что мне известно на данный момент — это прекомпилированные заголовочные файлы (некоторые компиляторы поддерживают такую фичу).
0
Прекомпилированные заголовочные файлы это костыль. А с модульностью все было бы очень просто: модули (в том числе и с шаблонами) хранились бы в двоичном виде (в виде синтаксического дерева) и весь процесс компиляции (и линковки заодно) состоял бы в загрузке модулей в память в единое синтаксическое дерево и генерации целевого кода из этого единого дерева.
Проблема шаблонов в том, что кому-то очень умному пришла в голову мысль писать на них программы как на функциональном языке (в результате шаблоны раскрываются рекурсивно в какие-то другие шаблоны, что и сжирает всю память); ну так это решается введением нормальных синтакических макросов — как только они появятся, у подавляющего большинства быстро отпадет желание писать метапрограммы на шаблонах.
0
1. Прекомпилированные заголовочные файлы — хранят в каком-то виде описание структуры содержимого этих файлов после препроцессинга, парсинга и прочего. Т. е. фактически ваши модули. И нет это, все равно, не просто в C++.
2. Та библиотека, о которой я говорил, использовала шаблоны в их сравнительно какноничном виде — для организации generic контейнеров. Сами контейнеры были довольно сложными, но винить шаблоны в данном конкретном случае нельзя.
3. Чем принципиально синтаксические макросы отличаются от шаблонов? Другим синтаксисом? Они будут принципиально экономичнее или что? В чем суть синтаксического макроса, что делает препроцессинг (не всмысле стандартный препроцессор C/C++, а в общем преобразование структуры программы) синтаксическим макросом?
0
Прекомпилированные файлы работают зачастую криво. Или вот еще — если есть группа связанных проектов («solution» в терминах VC++) и у них есть общие заголовочные файлы, то для каждого проекта из группы придется генерировать свой precompiled header.

Синтаксический же макрос это просто нормальная человеческая реализация того, что на шаблонах С++ реализовано так как оно реализовано. Если мне надо цикл, то я и напишу цикл (и он будет выполнен внутренним интерпретатором компилятора как обычный цикл), а не рекурсивно сгенерирую шаблон из шаблона с отжиранием гигабайтов памяти.
0
1. То что прекомпилированные фалы работают криво — это бага. Баги нужно исправлять. Или вы думаете, что модули по-умолчанию будут bug-free?
2. Т. е. вам не нравится по сути функциональность и синтаксис, вам нужен императив? В таком случае я скажу, что это ваше предпочтение, но не объективный недостаток шаблонов. Впрочем, я тоже не супер фанат синтксиса шаблонов (но это мое личное предпочтение).
0
1. Бага в коде для обхода костылей исправляется сложнее:) Чем чище и прозрачнее архитектура решаемой задачи, тем меньше там возможностей допустить ошибки.
2. Да, мне не нравится синтаксис; мне не нравится то, что шаблоны используются для того, для его они изначально не были спроектированы. Я не против функционального программирования, а когда оно интегрировано с императивным это вообще супер. А то что мы имеем с шаблонами это не проктировалось а было открыто случайно… поэтому сами понимаете о какой архитектуре там может идти речь. Ни о какой.
Все взаимосвязано. Простота и ясность синтаксиса языка приводят к простоте и ясности кода компилятора, значит в нем будет меньше ошибок, он будет потреблять меньше памяти и работать быстрее. И наоборот, когда в синтаксисе языка черт ногу сломит, в коде компилятора будет то же самое.
0
Чистая архитектура определенно упрощает жизнь, но проблема в том, что из вашего описания я все еще не понял, какой должна быть архитектура такой фичи как модули (то, что вы описали по сути уже имеется в виде прекомпилированных заголовков, и то что они реализованы бажно, ничего не говорит о том, что если переименовать их в модули, все станет лучше), и почему эта архитектура обязательно должна стать чистой, в отличие от того, что есть.
0
Я бы и сам не отказался от хорошей статьи (возможно на английском) по правильному объяснению модулей. Может другие хабровчане подкинут ссылок?
Я как-то набрался информации из разных источников, в голове она сложилась в более-менее единую картинку, но раз вы не поняли то значит я не могу нормально объяснить:)
0

Может, Вам будет интересно это:
Gustedt "Modular C"
Gregor "Modules"
Хотя я бы тоже хотел почитать про модули понятным языком и без Паскаля.

0

А как вы хотели генерировать общий precompiled header для разных проектов с разными настройками компиляции, разными инклюдами и прочим?


Если же все это у них — общее, то я не понимаю почему вы не смогли создать для них общий precompiled header.

0

Ну, если вспомнить Turbo Pascal… Там тоже заголовок модуля прекомпилирован. Но, как правильно замечено в следующем комментарии, шаблоны C++, некий аналог макросов, очень сложно прекомпилировать.


Но самой главное препятствие — препроцессор. Модули возможно ввести только когда отказаться от него, а это полная перестройка всех исходников. Это будет другой язык.

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

В итоге это будут не модули, а нечто жутко не простое. С++ уже сам по себе перегруженный язык и с такими модулями он вообще станет сложнее windows. ;)


Честно скажу, мне нравятся простые и лаконичные языки. C хорош своей простотой. А C++… — Бьёрна явно слишком занесло.

+3
Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.

Просто я хочу чтобы всё штаны были зелёные а шорты красные и чтобы тогда уж ничего перекрашивать было нельзя.
+3
Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр.

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


Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман.

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

+1
Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.

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


Ну или хотя бы придумайте единый формат под названием "таблица" для таких вот файлов как passwd и fstab. Чтоб не нужно было иметь для passwd один парсер, а для fstab — другой.

-1
Чтоб не нужно было иметь для passwd один парсер, а для fstab — другой

Если следовать вашей логике, то возникает вопрос: парсер для файлов, редактировать которые требуется обычно один раз при установке системы? Не много чести для конфигов — отдельный формат, отдельный парсер-клиент, для изменения пары строчек?
0

Ну так я про это и говорю. В текущей ситуации каждый конфиг имеет свой формат. И для каждого нужен свой код для парсинга. А я предлагаю для всех конфигов сделать единый формат, ну или для всех конфигов вида "таблица", таких как fstab и passwd сделать некий единый табличный формат

+2
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.

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

Нужно просто принять

Так вперед! Продвигайте и реализуйте прогрессивные идеи. Сообщество Unix-подобных систем не на столько закостенело — постоянно появляются новые разработки. Что-то приживается, что-то отмирает.
+1
По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?

Проблема в том, что apt-get это внешняя зависимость, не контролируемая программистом. Какая там будет версия, будет ли она совместима с программой? А с npm, composer или любым другим пакетным менеджером для языка программирования всё ясно и предсказуемо.
0

И реально никто не сделал такого для C? Там ведь тоже можно сделать что-то вроде package.json и придумать общую схему для подсасывания зависимостей и сбора include папки из пакетов.

+6

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

0

А потом приложения будут таскать всё с собой и весить под две-три сотни мегабайт, если не больше. Зато ясно и предсказуемо, ага.

0
Ну да, тут нужен компромисс между размером и независимостью. Включение в код приложения нужно для редких фич, которые не факт что будут в каждой используемой ОС, а включать в каждое приложение свою реализацию SSL или там zip нет смысла. И то, что в C нет никаких средств для модулей- его совсем не красит.
0
Хорошо показывает фразу выше, мол человек ко всякой кривизне привыкает, дай только время.
Идеала нет, и много зависит только от привычек.
+1

Я для кого объяснял? Я в своей статье разрушил аргументы типичных фанатиков UNIX, а вы тут опять с ними лезете. Объясню по пунктам что ли.


Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз

У них у всех разные форматы. И многие используют свои правила эскейпинга специальных символов (тот же fstab). То есть просто в тупую парсить fstab регексами, read'ом, cut'ом нельзя, нужно учитывать эти правила эскейпинга. Иначе вылезут баги, вплоть до багов с безопасностью. Поэтому у них должен быть один формат. JSON, YAML, что угодно. Который парсится стандартными библиотеками с гарантированной правильной работой с эскейпингом. И это не говоря попросту о том, что тогда не надо будет для каждого файла писать свой парсер.


В итоге, для настройки системы достаточно текстового редактора и интеллекта!

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


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

JSON и XML (особенно JSON) достаточно хорошо пишутся и читаются человеком. Они требуют написания всего одного парсера для каждого языка программирования. Да, JSON можно попортить, как и, скажем, passwd и fstab.


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

Б@#, добавьте новый столбец во fstab! Вы этим поломаете кучу скриптов. А если бы использовался JSON или некий универсальный JSON-подобный бинарный формат, то почти ничего бы не сломалось. Просто в JSON-хеше появилось бы новое поле.


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


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

Я для кого тут объяснял? Я не придираюсь к арифметике указателей, отсутствию сборщика мусора и т. д. Всё это так и должно быть, для того язык и задумывался. Но у C есть куча реальных недостатков. Которые теоретически можно исправить, оставив язык при этом "кроссплатформенным ассемблером". Ужасный препроцессор вместо нормальных гигиенических макросов, отсутствие даже опциональной проверки границ массива неким единым и стандартным способом, отсутствие нормальной работы со строками (последние два пункта приводят к постоянным проблемам с безопасностью), отсутствие удобных инструментов без legacy (мультиплатформенный менеджер пакетов, система сборки).


По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?

Нет. Потому что npm работает на UNIX-подобных системах и Windows. А apt-get — только в системах, основанных на Debian. Хочется иметь стандартный популярный обкатанный менеджер пакетов C для большого числа ОС, как минимум UNIX и Windows.


Понятное дело, сами пакеты необязательно будут мультиплатформенны. Но некоторые из них, хотя бы даже curl — будут. И сам менеджер пакетов будет мультиплатформенным.


Ещё в C нет namespace'ов.


Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.

А я с этим не спорю.


Про printf вообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.

Я с самого начала понимал, как она работает. И знал, что printf парсит строку формата в рантайме. Но я думал, что так и надо, что раз так сделано, значит, это занимает не так уж и много времени. Потому что писали какие-то умные дядьки. А потом (когда увидел тесты от H2O) понял, что это не так. Что printf, как и многое в C и UNIX — это тупо кем-то оставленный костыль. Ну вот этой моей находкой я и делюсь.


И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.

Возможно. Тут я тоже не спорю.


И я не предлагаю всё переделать в UNIX'е. Я просто хочу, чтобы люди кое-что про него знали.

+2
Автор неплохо проехался по C/C++, хочется уточнить
Вообще язык C разрабатывался одновременно с UNIX, поэтому критикуя UNIX, нужно покритиковать и C тоже

Немного кривая аргументация
Скажу лишь вот что. В C до сих пор не научились удобно работать со строками

Да, это плохо, что где-то не научились удобно работать со строками, но вообще да, строки там не очень удобные. В C++ из коробки std::string, это лучше.
И это не говоря об отсутствии простой, удобной и мультиплатформенной системы сборки <...> стандартного менеджера пакетов

Менеджер пакетов и системы сборки есть, и некоторые отличные, даже удобные и мультиплатформенные, но нет и не могло быть раньше официально признанного, так как всю свою историю C/C++ не был «монолитом». Сайта официального нет, тем более с модной минималистической CMS-кой, но от этого он не стал хуже, правда.
В реально больших проектах, таких как Gnome, Firefox — свои системы сборки и зависимостей. Они создавались, когда никакого гитхаба и маркдауна в документации не было, а ждать очередной модный мега-язык как Rust было невтерпежь.
void (*signal(int sig, void (*func)(int)))(int)

Какой ужасный язык, у меня уровень сахара в крови упал!
0
холиварный пост, и php гавно (да когда то было, но придание до сих пор живо как я понял), и С. Пока ~90% серверов работает на gnu linux/unix системах ваши доводы можно трактовать как «ребята вы все дураки что используете это и зарабатываете деньги, давайте я вас научу как работать неучей. „
+6
Нет. Это можно трактовать как то, что бизнесу пофиг на Совершенство, Безупречность и Гармонию, ему «работает и ладно, лишь бы бабло капало».
0
вы говорите про недостижимые вещи, все равно где то будут компромиссы. И через 10 лет этих компромиссов накопится на подобную статью.
+1
бизнесу не нужно «работает и ладно», бизнесу нужно «что бы работало не хуже чем у конкурентов, а если даже лучше, то вообще замечательно», но почти все конкурируют друг с другом почему то на линуксах, виндусах и иногда бздях, а план9, инферно и остальные не очень распространенные ОС занимают свою небольшую нишу и пока что не претендуют на «ОС общего назначения»
0
Бизнесу надо в основном «быстрее чем у конкурентов». Лучше там или не лучше — в определенных пределах пофиг; главное ввязаться, заявить о себе, а пипл все равно схвавает.
То есть конечно откровенно не работающие программы в продакшен не попадают, но вот ради перфекционизма и внутренней архитектурной красоты никто заморачиваться не будет.
0
Ну да. Потому что при перепроектировании и переделке люди обязательно наделают ещё и своих багов (и кодовых, и архитектурных), лет 15 будут их героически устранять, а потом придёт новый сноб, скажет, что всё это legacy… и так по кругу.
0
Годный наброс! Надеюсь, те, кто заразится этим отношением к legacy Un*x, будут рекламировать свои поделия не в качестве его наследника.

> У них, видимо, был только ассемблер и текстовый редактор.

Ассемблер с редактором Томпсон тоже сам написал, на GECOS системе.
+2
Рассуждения о «кривизне» того что было реализовано 40 лет назад, с точки зрения текущих реалий — благодатная тема для срача)
+3

Ну, это ж универсальный рецепт вброса — критика legacy. :)

0
Понятное дело — все старики неряшливые, неухоженные с кучей приобретенных болячек, не говоря о наступающей деменции
+2
Статья интересная просто потому, что много всякого разного собрано в одном месте, но:
Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал

это, простите, что?
+2
Было бы лучше, если бы утилиты выдавали вывод в виде XML, JSON, некоего бинарного формата или ещё чего-нибудь.

Чего?
Я еще спрашивать буду?
Уважаемый, не нравится командная строка(как вы написали bash/sh/ksh) — ваша, блин, проблема!
А, вы про реестр…
Я мышь терпеть не могу!
Так что, высказались, будьте довольны!
+1
Я конечно не спорю, в статье есть много достаточно правдивого. Но реально некоторые вещи притянуты за уши…

Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом. Как это сделать?

Вот допустим, нужно забить гвоздь. Да, я знаю, что такое надо делать молотком. Но давайте предположим, что это нужно сделать непременно микроскопом. Как это сделать?
Я не закончил про UNIX shell. Рассмотрим ещё раз пример кода на shell, который я уже приводил: find foo -print0 | while IFS="" read -rd "" A; do touch — "$A"; done. Здесь в цикле вызывается touch (да, я знаю, что этот код можно переписать на xargs, причём так, чтобы touch вызывался только один раз; но давайте пока забьём на это, хорошо?).
А почему не find foo -exec touch {} \;?

Код на любом другом языке программирования будет работать быстрее этого. Просто на момент появления UNIX shell он был одним из немногих языков, которые позволяют написать это действие в одну строчку.

Код на любом языке можно написать так, чтобы он работал быстрее этого. В том числе и на shell. Более того, на любом языке можно написать код, который будет медленнее этого…
-3
Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом. Как это сделать?

Каталог не бывает менее 4Кб
Я не закончил про UNIX shell. Рассмотрим ещё раз пример кода на shell, который я уже приводил: find foo -print0 | while IFS="" read -rd "" A; do touch — "$A"; done.

grep -i же
Более того, на любом языке можно написать код, который будет медленнее этого…

Напишите на Python!!!

Уважаемый, Ваше негативное отно…
… да не буду писать!
+5

Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.


Теперь к самой сути статьи.
Очевидно, что идеальная программа/система, написанная за бесконечное количество времени и денег никому не нужна.
Людям нужно нечто достаточно хорошее, способное решать задачи прямо сейчас.
Поэтому победил UNIX, несмотря на все его недостатки.
Поэтому никто не готов "ломать весь мир" и переписывать все программы, переходя на Plan 9 или что-нибудь ещё, проще вставить костыль в UNIX, чтобы оно работало прямо сейчас.


Что с этим делать? Ничего. Мир жесток, несправедлив и совсем не идеален. Нужно просто научиться жить с этим дальше. Научиться решать реальные задачи, обходя подводные камни.


А вообще, спасибо за статью, очень много интересных исторических и технических фактов. О многих из них я раньше не знал, но теперь почитаю про них подробнее.

0
Перфекционизм в предельной стадии — зло, соглашусь. И идеальных систем не бывает в реальном мире, тем более, чтобы все считали систему идеальной.

Но вот этот прагматизм слегка добивает… Зачем здесь и сейчас, если можно придумать что-то новое, лучшее, что будет работать когда-то потом и приносить пользу? Я бы с радостью занялся изучением Plan 9 и портированием некоторого софта на неё, будь у меня несколько больше знаний в этом вопросе. Мне кажется, это довольно интересно и познавательно. Как и вообще освоение чего-то нового.
0
Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.

Ну да. Всё правильно. Просто есть на свете люди, которые этого не понимают. И которые считают Rust посягательством на святой неприкосновенный C. Вот для них и предназначена моя статья. И вообще со всем вашим комментом я согласен. :)

0
Что с этим делать? Ничего.

Почему ничего? Ломать костыли. Исправлять. Проблема лишь в том, что пока груз поддержки легаси не превышает выгод от его избавления. Что лучше — один раз поломать написанное плохо и написать лучше и потом все оставшееся время получать профит или и дальше продолжать жевать кактус, накапливая ненависть? Когда-то чаша переполнится и костыли сломают. Будут новые костыли, более прямые и долговечные :) Но мне кажется, многие этого не понимают и цепляются за старое. Думаю, именно их автор назвал фанатиками.


Вообще говоря, какие-то подвижки вроде начинаются уже. Тот же systemv. Есть какое-то понимание проблемы и это хорошо, кто бы что ни говорил.

0
Что лучше — один раз поломать написанное плохо и написать лучше и потом все оставшееся время получать профит или и дальше продолжать жевать кактус, накапливая ненависть?
Всегда есть некий баланс — но он гораздо ниже, чем многим бы хотелось. В узких нишах можно позволить себе отбрасывать костыли лет через 5-10 (MacOS, к примру достаточно давно не поддерживает на MacOS Classic приложений, ни даже приложений для PowerPC!), в более широких — это занимает десятилетия (пример: MS-DOS 1.x использовала для работы с файлами FCB, а появившайся через 2 года MS DOS 2.x — уже прогрессивные handleы… ещё через 18 поддержка FCB в DOS приложениях была выпилена — в Windows XP).
0

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

0
Ок, весь софт — дерьмо, жизнь — дерьмо, мир — дерьмо. А чем пользоваться — то? :D
UFO landed and left these words here
+1

Как минимум на C++ или D переписать не так уж и сложно. D так вообще бинарную совместимость обеспечит.

UFO landed and left these words here
0
Отвечать на статью, где в явном виде нет сравнения с виндой, гневной тирадой про винду — это уже паталогия какая-то по-моему.

Чего там, паравиртуализацию во FreeBSD уже завезли? Как с поддержкой аппаратного ускорения современных видеокарт? А юникод в консоль без костылей завезли?
UFO landed and left these words here
0
Венда одна и всё позиционирование — сплошные искусственные ограничения.

Я спорил? Просто по большей части всё это реально не нужно.
Ну и домашние сборки весят меньше и меньше занимают памяти, так как в них нет приблуд, которыми мало кто пользуется. Но в стране пиратов привыкли везде ставить ультимейт.
UFO landed and left these words here
0
В оперативе — так нужно отключать лишние сервисы, их и в обычных домашних/про более чем надо.

Сначала ставим лишнее, потом отключаем. И жалуемся на разжиревшие дистрибутивы и ОС. Л — Логика.
UFO landed and left these words here
+1
С этими претензиями к микрософту.

Почему? Это именно вы ставите неподходящие редакции ОС и выпиливаете из них «ненужное».
UFO landed and left these words here
+1
Не, логика еще проще. Есть инструмент — делаешь. Нет инструмента — не делаешь. Все оборудование без проблем завелось в Linux и работает до сих пор. FreeBSD тогда таким похвастаться не мог. Проще взять другой инструмент, чем мучаться с непригодным.
0
мс сливает килотонны говна в апдейтах именно хоямчкам, в том числе и всякие ненужны средства борьбы с активациями

Обновления одни по сути.
нет никаких идиотских ограничений

Я уже писал, что ограничений по сути нет. Обычные пользователи не покупают материнские платы с 4 процессорами и более чем 128ГБ оперативной.
можно было спокойно сидеть на 2к3х64, и ещё пару лет после смерти ХР

Или ставить те же обновления на XP x64, а на x32 до сих пор прилетают.
0
У вас неправильная логика. Все оборудование было IBM eSeries или IBM Bladecenter, с очень серьезной поддержкой со стороны вендора. Itanium также был в IBM-овском сервере, но уходил на списание. К сожалению вдохнуть новую жизнь фряхой не удалось. Не думаю что закупка ЦОД — дело импульсивное.
0
Все это конечно хорошо, что сейчас многое появилось. Но в 2009, когда мы поднимали кластер с Infiniband, фряха его не поддерживала. Надо было наверное сказать, что пацаны погодите, пускай железо постоит пока, там пацаны из фряхи еще драйвер не написали.
Учитывая нынешнюю копроэкономику, поддержка древних устройств никак в не помогает ОС продавать себя, рынку нужна поддержка всего самого свежего и сейчас, а не через пару лет.
А так, конечно фряха ставилась везде, но не везде взлетали нужные устройства. Хотя вру, на Intel Itanium дальше Boot Logo продвинуться не удалось, пришлось ставить SUSE.
То что FreeBSD нельзя использовать как основу гипервизора в нынешних реалиях печально. Даже винду можно.
+4
2 Incidence
Я в курсе, и всего то на 18 лет. Это к свежести вопроса про utf в консоле. Мне лично он там никогда актуален не был.

Больше.
Уже ядро NT3.1 было насквозь юникодным в UCS2, а это 1993 год, то есть 24 года назад.
И ещё долгие годы линуксоиды страдали прикручиванием костылей koi8-r в систему, вот так же, как вы уверяя всех, что БНОПНЯ ВХРЮК лично их вполне устраивает.
0
А в венде юникод появился?) Или надо руками ставить unicow.dll ?)

Если это такая шутка, то она опоздала лет на 25, как минимум.
UFO landed and left these words here
0
Речь шла о поддержке ядром ОС именованных объектов.
А не о том, какие востребованные в 0.01% случаев свистоперделки можно прикрутить к терминалу через ANSI-коды и прочие не относящиеся к обработке строк вещи.
0
> Хз, мне виртуалбоха хватает.
Облака тоже на виртуалбоксах пилить будете? Xen0 до недавнего времени не поддерживался. bhyve is not a fully production hypervisor yet. Поддержка FreeBSD в качестве гипервизора в популярных платформах виртуализации? Извините.

Широкий выбор распределенных сетевых ФС у нас по-прежнему заканчивается на nfs?

> Замечательно, только на днях выкатили новый хорг. Но перед покупкой видюхи нужно посмотреть в вики на предмет поддержки.

Отлично, по-прежнему чтобы пользоваться ОС надо не просто купить устройство и пользоваться, как сейчас уже даже в Linux стало, а по-прежнему шерстить вики, форумы, и подбирать популярное и не самое свежее, но зато рабочее железо. Сколько драйвер nvidia на amd64 ждали напомнить?

> А в венде юникод появился?) Или надо руками ставить unicow.dll ?)

Как минимум с NT5 (1999-й год), может раньше. unicow.dll для Windows 98 ставили. В debian чтобы нормально на юникодовские буковки смотреть в системной консоли (не терминале в иксах) особых заморочек не надо (dpkg-reconfigure console-setup?). С фряхой последний раз в 9-ке крутил консоль, возможности вывода ограничены глифами из vesa bios, чтобы увидеть юникод надо было очень много плясок с бубном, всякие jfbterm собирать и т.п.

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

Мне изначально очень нравилась FreeBSD, гораздо больше чем Linux. Там как бы порядка что ли больше. А система портов вообще одно из самых замечательных изобретений, я даже на работе аналог внедрял для собственного софта.

Но к сожалению FreeBSD мне не удалось нормально поюзать ни в энтерпрайзе, ни дома. В энтерпрайзе потому что не поддерживает нужное железо, например Inifiband (от написания собственных дров еще никто не умирал, да?), не поддерживает нужный софт, например те же платформы облачной виртуализации. Максимум что придумалось поюзать роутером/файерволом, потому что там тип netgraph крутой. Дома не взлетело опять же из-за поддержки железа — nvidia amd64 нет, ТВ тюнер хоть и с аппаратным кодеком, тоже нет и т.д.
0
Поди создай зеркало на домашней венде

Зеркало дома? Зачем?
Пользователя завести и то проблема.

Нет никакой проблемы.
10 одновременных соединений к шаре.

Потому что это домашняя ОС.
Дальше ты медленно умираешь

Ужас какой-то пророчите.
Софт рос, менялся, но тот же гном2, хфце до сих пор живы

Только по умолчанию в популярных дитсрах совсем другое. И при обновлении гном заменился бы на унити, который в первых ипостасях хуже Вин8.
0
Чистить это не возможно.

И не нужно. Нет, вас действительно смущает пара десятков мегабайт ключей?
Кучи идиотских ограничений, как будто у мс не она венда а штуки две совершенно разных: для юзеров и для серверов

Например? Мне хватает моих 128 ГБ оперативной памяти и кажется двух физических сокетов под процессоры. И это старушка XP x64. Какому пользователю нужно больше?
0
С одной стороны, нельзя не признать, но, с другой стороны, невозможно не отметить.
+6

Примерно половина доводов в статье как всегда — просто раздувание слона из мухи, или просто непонимание каких-то моментов реальности. Но остальная половина, конечно, является доводом в определённой степени. В общем, главное — не бросаться из крайности в крайность. UNIX писали обычные люди. И вполне логично, что у него есть и недостатки. Но некорректно говорить, что это полностью плохая идеология.


И это не говоря уж о том, что критичные файлы UNIX (такие как /etc/passwd), который читаются при каждом (!) вызове, скажем, ls -l, записаны в виде простого текста. И эти файлы надо заново читать и заново парсить при каждом вызове ls -l!

А кеширование данных на уровне файловой системы на что было сделано? Не раздувайте слона из мухи, это вообще не проблема.


Вообще, конкретные обстоятельства, возникшие во время разработки оригинальной UNIX, сильно оказали на неё влияние. Скажем, читал где-то, что команда cp названа именно так, а не copy, потому что UNIX разрабатывали с использованием терминалов, которые очень медленно выдавали буквы

Это является каким-то минусом UNIX идеологии? Вроде как в целом мне и самому удобнее писать cp, а не copy.


Терминал в UNIX — жуткое legacy

Хрен его знает, чего в этом плохого, но я лично с большим удовольствием пользуюсь энтим самым легаси терминалом, подключаясь к своим серверам по ssh, будучи в какой-нибудь маршрутке, через 3G соединение своего мобильного телефона, который расшаривает на мой ноут Wi-Fi. Короче, опять муху из слона раздуваете, господин автор поста.


UNIX shell хуже PHP!

Да вы запарили со своими загонами в сторону PHP. PHP успешно используется в гигантских проектах, постоянно развивается и имеет некоторые особенности, дающие повод на то, чтобы указывать его как более правильный выбор чем тот же хвалёный Ruby On Rails. Это тоже, наверное, тоже о чём-то говорит.


«А? Что? Lisp? Что за Lisp?» Интересно, да?

Извините, но если честно — не особо. Я бы вполне мог и PHP для подобной задачи использовать, благо он умеет подключаться к серверам по SSH и даже управлять файлами на удалённых серверах, если это необходимо.


Да, так можно. Но часто photoshop'ом или gimp'ом всё-таки лучше. Хоть это и большие, интегрированные программы

Опять перекос непонятно куда. Если речь идёт об одной картинке — да, гимпом и фотошопом удобнее. Когда речь идёт и миллионах картинок и их пакетной обработке — тогда и возникает вся польза идеологии UNIX.

+1
Да, терминал в UNIX жуткое легаси. Смотрите, возьмём например поддержку цветов текста. Терминал/эмулятор терминала может поддерживать разное количество цветов/эффектов (мигание, подчёркивание etc). Программа, которая выводит текст в терминал, должна знать, какие возможности она может использовать. Придумали использовать для этого переменную окружения $TERM, которая должна содержать название терминала (эмулятора терминала). Проходит время, разных терминалов развелось сотни. Что по-хорошему должна делать программа, чтобы понять, может ли она использовать цветовую схему с 256 цветов? Нужно проконсультироваться с базой, в которой записано какой терминал что может. Такая база есть и поддеживается в составе ncurses… Что делать программе, если она не хочет зависеть от ncurses? GNU coreutils содержат в своём составе статически вкомпиленный короткий список терминалов с их возможностями.

Окей, как это выглядело для меня, пока я не раскопал: хочу 256 цветную тему в vim. Ага, это определяется переменной окружения TERM. Сейчас у меня konsole при запуске выставляет TERM=konsole. Ставим в .bashrc konsole-256color и в vim всё хорошо раскрашивается, но не через некоторое время понимаю, что ls, grep и т.д. перестали быть цветными…

Сейчас у меня в .bashrc такой кусок кода
#Add more colors if proper TERM was not exported
if [[ $TERM != *-256* ]] && [[ $TERM != screen* ]]; then
    #Workaround for Konsole setting TERM=xterm by default (https://bugs.kde.org/show_bug.cgi?id=212145)

    #konsole-256color ломает цвета для ls -l, т.к. dircolors такого не знает, можно вылечить задав непустой $COLORTERM,
    #в vim ломается переход между вкладками по Ctrl-PgUP/PgDown
    [ -n "$KONSOLE_PROFILE_NAME" ] && export TERM=xterm-256color
    [ "$COLORTERM" = 'xfce4-terminal' ] && export TERM=xterm-256color
fi

Он более-менее работает в большинстве случаев. И мне вообще страшно смотреть в его сторону.

Или вот ещё, заходишь на солярку по ssh и почему-то backspace не стирает символ, а дописывает абракадабру. del работает (или наоборот было?).

Короче, вы просто не лезли в хоть чуть-чуть нетривиальные случаи.
0

Окей, конфиги кешируются. Но парсить их нужно всё равно каждый раз

0

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


В общем, всё равно это не является причиной для довода против идеологии UNIX. Тем более это не является доводом в пользу того, что только из-за этого надо теперь брать и внедрять везде реестр. Тем более это не является доводом в пользу того, что система на подобии реестра решит эту проблему и не добавит никаких других проблем.

-2

Я говорил про ls -l. Он читает конфиг каждый раз. Так что что-то по-любому нужно сделать: или поместить passwd в бинарный вид, в БД или в реестр, или фиксить ls, чтобы он по-другому работал. Ни то, ни другое в дефолтных поставках дистров gnu/linux, к сожалению, делать не собираются.


А аргументом в пользу реестра является та ситуация с ext4.

0
А аргументом в пользу реестра является та ситуация с ext4.

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

0

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

0

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

0
Как touch'нуть все файлы в папке foo

man find | grep exec

Дочитал пока до этого места имхо — посыл всё плохо. Но сравнения с чем то ещё не проводится за редким исключением.

+2
Собственно, комментарии в очередной раз доказывают то, что и так известно давно: фанатики — они на то и фанатики, чтоб не слушать логичные доводы. Все аргументы в комментариях сводятся к «а в винде ещё хуже» (блин, кто вообще с виндой-то сравнивал?), и к «а вот в пятом пункте третьей строке вы притянули за уши, значит неправда ВСЁ!».
+1
К списку недостатков фанатиков — они очень любят обобщать — прочитали один комментарий с такими аргументами, значит ВСЕ комментарии такие.
0
Да, возможно что со словом «все» я несколько перегнул палку, ведь под это понятие попадают и контраргументы, и даже мой комментарий. Но если вы намекаете, что я фанатик — то позвольте поинтересоваться, фанатик чего?
0
Нет, я не намекаю на то, что вы фанатик, я предлагаю вам всего лишь следить за собой и не делать странных обощений и навешивать на других людей незаслуженные ярлыки. Если вы не согласны с каким-то конкретным мнением, то вы можете его оспорить с тем, кто его выразил.
0
Вы знаете, я считаю что спорить с фанатиками — это верный способ развести холивар, и только. А разводить холивар совершенно не в моих интересах, судя по всему здесь и без меня справятся.
+1

Ну, говорить что всё плохо но не говорить как надо, имхо всё равно что светить на солнце.
Движение есть, прогресса нет (с).


И про венду/qnx/bugu|freertos/systemi/plan9/*dos и слова не было. Если вы, кроме unix-like, posix-совместимых и windows ничего не видели, то это не значит, что кто-то фанатик чего-то.

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

И назад к IT. Возьмём простую вещь: обозначение новой строки в тексте. Есть unix, mac и win стили, причём про эту особенность нужно быть в курсе. Разные технологии требуют по-разному оформленного текста. Я видел 1-2 раза, как человек готовил shell скрипт в какому-нибудь блокноте на win, и после копирования файла скрипта на linux систему скрипт не запускался. При запуске ОС искала интерпретатор не какой-нибудь /bin/bash, а /bin/bash\r потому что ожидает \n в качестве конца строки, а строки в скрипте были разделены байтами \r\n.

В предыдущем абзаце сломалось из-за использования \r\n вместо \n. Встречал и обратную ситуацию: пытаются продать некий клиент, общающийся с сервером по надстройке на HTTP. Привозят заказчику, включают, натравливают на их сервер — не работает. Разбирательство показало, что их кастомный сервер в HTTP ответах разделял заголовки только байтом \n, хотя по стандарту должна быть комбинация \r\n. Многие реализации HTTP протокола написаны принимать любую комбинацию из \r\n и \n в качестве конца строки HTTP заголовка, но не продаваемый клиент.

В идеальном мире, в котором IT просто служит человеку и помогает работать с информацией, не должно быть необходимости помнить и отслеживать, где какой конец строки используется.
-1
Эту проблема не Unix, а как раз таки искусственно создана MS в качестве вендорлока.
+2
Какие же они evil!!!
Unix пришел с «больших» машин, терминалы которых имели раздельные клавиши ВК и ПС (CR и LF). Физически разные кнопки. И еще со времен телетайпов окончание ввода обозначалось нажатием на клавишу «Возврат каретки».
А MS развивался на рынке ПЭВМ, где была одна клавиша «Enter», и была необходимость генерировать оба символа сразу при нажатии одной кнопки, поскольку эти операции не разделялись, и автономная «возврат каретки» была не нужна — ее роль по сути выполняла клавиша Home.
+2
Тема не раскрыта. В статье приводится набор частных недоработок, не совсем удачных или устаревших решений, личной вкусовщины. Никакого общего ядра у этого списка претензий нет, никакого «краха философии» из них не следует.
+2
Ну, дьявол, как известно, в деталях. Да автор и сам пишет, что «Есть идеи в UNIX, которые мне реально нравятся». Идеи Юникс в целом прекрасны и замечательны, а вот все проблемы именно в частных недоработках. Причем эти частные недоработки расползлись и размазались тонким слоем по всему Юниксу, так что иногда даже сформулировать бывает сложно… но автор попытался, за что ему честь и хвала, я бы так не смог (хотя наталкивался на все это тоже).
0
Тогда статья должна называться «Проблемы в современных реализациях Юникса»
0
С табуляцией в make решение неудачное, но хорошей замены этому инструменту я не нашел. В sbt, cabal, cargo очень тяжело сказать системе, что "'эти файлы, несмотря на расширение, не трогая", а «этот надо сгенерировать, запустив такую программу».
Плохо не то, что в Unix накопились баги, плохо то, что их толком ни где не исправили.
+1
Я вообще считаю, что если возникает такая потребность как «эти файлы несмотря на расширение не трогай» то тут что-то не то. Да и генерить файлы… ну не всегда это нужно. Я писал проекты с тысячами файлов исходного кода, и нигде такое не требовалось. Хотя я понимаю что это может быть необходимо в каких-то случаях.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.
+3
Среди различных Unix-овых (да и не только) утилит есть несколько таких, которые при сборке генерируют файлы. Например, те что используют lex/bison/yacc. Их, конечно, можно сгенерировать заранее и добавить в проект и потом просто ручками перегенрировать при изменениях и обновлять, но это не выглядит как удачное решение (в основном потому что ручками). Так что это не такая уж и супер редкая задача. И вместо того чтобы что-то отгораживать лучше озадачиться возможностью скриптования системы сборки (более или менее разумные системы сборки эту возможность обычно имеют).

Касательно make файлов, make-файлы достаточно декларативны. За исключением того, что кроме опций и файлов иногда нужно описать шаблон команды, который после подстановки имен файлов превратит эти файлы в исполнямый файл/пакет/etc. То есть, ИМХО, обвинять make за отсутствие декларативности не совсем честно. Вот, например, один из make-файлов для одного из учебных проектов:

CC ?= gcc
LD ?= ld

CFLAGS := -g -m64 -mno-red-zone -mno-mmx -mno-sse -mno-sse2 -ffreestanding \
        -mcmodel=kernel -Wall -Wextra -Werror -pedantic -std=c99 \
        -Wframe-larger-than=1024 -Wstack-usage=1024 \
        -Wno-unknown-warning-option $(if $(DEBUG),-DDEBUG)
LFLAGS := -nostdlib -z max-page-size=0x1000

INC := ./inc
SRC := ./src

C_SOURCES := $(wildcard $(SRC)/*.c)
C_OBJECTS := $(C_SOURCES:.c=.o)
C_DEPS := $(C_SOURCES:.c=.d)
S_SOURCES := $(filter-out $(SRC)/entry.S, $(wildcard $(SRC)/*.S)) $(SRC)/entry.S
S_OBJECTS := $(S_SOURCES:.S=.o)
S_DEPS := $(S_SOURCES:.S=.d)

OBJ := $(C_OBJECTS) $(S_OBJECTS)
DEP := $(C_DEPS) $(S_DEPS)

all: kernel

kernel: $(OBJ) kernel.ld
        $(LD) $(LFLAGS) -T kernel.ld -o $@ $(OBJ)

$(S_OBJECTS): %.o: %.S
        $(CC) -D__ASM_FILE__ -I$(INC) -g -MMD -c $< -o $@

$(C_OBJECTS): %.o: %.c
        $(CC) $(CFLAGS) -I$(INC) -g -MMD -c $< -o $@

$(SRC)/entry.S: gen_entries.py
        python3 gen_entries.py > $@

-include $(DEP)

.PHONY: clean
clean:
        rm -f kernel $(SRC)/entry.S $(OBJ) $(DEP)


Синтаксис конечно дуратский с этой кучей пунктуаторов, но, по сути, что в этом файле есть: тулы для сборки, опции для этих тулов, список имен файлов для сборки (получается автоматически просмотром каталогов), и шаблоны команд для сборки (для каждого шаблона рядом дается ограничение, для каких файлов его применять). Все что захардкожено прямо в шаблоны команд это linker-скрипт (не супер часто его приходится указывать явно) и имя автоматически генерируемого файла и скрипт для его генерации. Я бы не назвал это не декларативным.
+2
Эта потребность вполне естественна, если не считать себя ограниченным мейнстримовыми технологиями. Так в makefile я бы легко мог декларативно описать необходимость сгенерировать .js файлы из .elm в веб-приложении на Scala, в то время как в sbt мне приходится для этого писать императивный код.
Для разработки своих языков, даже DSL, постоянно требуется компилировать свою библиотеку только что собранным компилятором. В make это делается элементарно.
Использование дополнительных препроцессоров, даже классических lex и yacc, не говоря уже о редких NJ Machine-code Toolkit и noweb, в проектах не на make становится приключением для эксперта в конкретной системе сборки.
Вообще, желание сделать наиболее популярное использование до предела простым тормозит развитие технологий. Нужен компромис, который в make был более-менее достигнут, если закрыть глаза на извращенное решение с табуляцией. Другие системы не декларативны, а более императивны, просто обладают неестественным интеллектом, позволяющим им распознать популярные случаи использования.
0

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

+1
У gcc есть опция построение зависимостей. Ее не сложно использовать из makefile.
Другие системы сборки выводят зависимости по каким-то своим соображениям, и указать другие зависимости бывает очень не просто.
+1

Особенно удобно ее использовать когда один из заголовочных файлов — автогенерируемый, и имеет внутри свои инклюды :)

+1
Это как раз один из тех случаев, когда популярные тулзы не справятся, и приятно иметь удобный способ указать зависимости явно.
+1

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


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


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


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

0
Большая часть примеров рассказывает об общих для всех систем костылях. В частности все, что касается работы с файлами, содержащими в имени символы, имеющие в командном интерпретаторе специальное значение (одни пробел со слэшем доставляют "удовольствие" в любой системе). Соответственно непонятно, причем тут вообще "философия UNIX"?

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


И, кстати, о make,
Разве эта утилита является частью ОС? Разве она не работает на всех ОС абсолютно одинаково?

make — один из столпов UNIX. Это одна из основных UNIX-программ. В Windows же make используется как "пришелец из мира никсов".

UFO landed and left these words here
+1
А дело в том, что printf, как и сама UNIX в целом, был придуман не для оптимизации времени, а для оптимизации памяти. printf каждый раз парсит в рантайме строку формата.

Назовите язык, в котором это не так.
-1
Сама по себе эта претензия абсурдна. Любой программер знает что есть два противоположных подхода-оптимизация времени или памяти. Хочешь быстродействия-денормализуй БД. Возможно эта функция написана когда HDD были по 40ГБ. Не нравится-напиши свою. Это и есть UNIX-way. А поругать чужое, чтобы поменьше замечали твои недостатки-это видимо Windows-way.
-1

Строка формата всё равно парсится в рантайме. Вот такой код выдаст исключение, например:


Console.WriteLine($"{DateTime.UtcNow:{{}");
0

Например, в D это может быть не так. Конкретно printf на эту тему не оптимизировался, так как разбор шаблона — капля в море по сравнению с выводом в консоль, но вот регулярки, например, могут быть скомпилированы на этапе компиляции:


import std.stdio;
import std.regex;

void main()
{
    auto number = ctRegex!`\d+(?:\.\d+)?`;
    writeln( "1.2,34.56".matchAll( number ) ); // [["1.2"], ["34.56"]]
}
0
Пусть автор в Windows попробует создать файл с простым именем prn (Этот артефакт ещё с доса тянется)…
А вообще надо не забывать, что часто недостатки, являются продолжением достоинств.
(Ушёл с винды ещё в 2006 году(и перевёл всех своих клиентов с винды)… что я тоже делаю не так???)
0
Да, в принципе, запросто. И даже Symbolic link удалять не надо.
0
Скорее всего, это сетевая шара на самбе или типа того, где ни одно из этих имён не является зарезервированным.
+2

Бгг, распаковал под Windows 7 32 бита с помощью 7-zip 9.20. Работает. Про замену не спросил. Выглядит именно так, как на скриншоте в архиве (его можно посмотреть прямо в интернете, ничего для этого скачивать не надо). Есть оба слеша в именах файлов. Но это сделано с помощью специальной фичи оболочки Windows (т. е. Windows Explorer, ну или Windows Shell, короче говоря та оболочка, которая показывает вам всякие там "Мой компьютер" и "Панель управления", хотя таких папок на самом деле нет), которая позволяет показывать не те имена файлов, которые реально есть в файловой системе. Т. е. на самом деле эти файлы и папки называются по-нормальному, просто имена не те отображаются. Принцип тот же, из-за которого называются папки в C:\Users\User по-английски, а отображаются в проводнике по-русски

0

Простите. Я, конечно, понимаю. Авторский стиль, острый вопрос, какашки, вентилятор и вот это вот все.


Но можно воспользоваться катом?

0
Предлагаю автору написать аналогичную статью про OpenVMS.
0

У OpenVMS нет кучи фанатиков, которые всерьёз считают её лучшей ОС

+4
Я твой UNIX-дом труба шатал, shell-калитка тряс, философия-огород топтал, язык С кэпка на х… вертел!
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют. Мой текст обращён скорее к фанатикам UNIX и GNU/Linux. Провокационный тон просто чтобы привлечь ваше внимание.
-3
У автора типичное пацанское представление «поколения интернет» — только что вылупившись из яйца и ничего еще сам не понял и не сделал, но уже клеймит позором «костыли и философию UNIX». Будь эффективнее — сделай свое и не трать время на подобные клеймящие «статьи».
-4
Ох уж этот юношеский максимализм, вчера из пеленок выпрыгнул а сегодня говорит что мир не правильно устроен… Сделай что нить свое и поддерживай его в актуальном состоянии лет 10, вот потом будешь иметь право использовать такие слова в заголовках.
-3
Как-то несерьёзно это всё. Конечно у Linux есть недостатки. Но сравнивать бесплатно и платное ПО как-то не принято в мире. Не нравится-покупай и ставь Windows, Linux никто не навязывает.
Про реестр идея интересная конечно. Если бы это было грамотно реализовано. Но ведь RegCleaner'ы для чего-то существуют. А значит реализация подкачала.
Ну и сравнивать linux-shell и php вообще нонсенс.
+2
Но ведь RegCleaner'ы для чего-то существуют.

Для заработка создателей RegCleaner'ов?
0
Во-первых есть бесплатные. Во-вторых опыт показывает что regcleaner размер реестра иногда значительно уменьшает. А значит не всё так уж хорошо с реестром.
+1
Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие. И ничего плохого в этих «лишних» записях нет, и с реестром всё в порядке, даже когда он весит под сотню мегабайт. В Win2000 общее ограничение на реестр было что-то около 400 мегабайт, в WinXP общее ограничение снято, есть только ограничение в 200мб на размер куста SYSTEM из-за особенностей загрузки. Уверен, в новых ОС даже этих ограничений нет. На моей ОС, установленной более 5 лет назад, куст SYSTEM весит 7,5мб, а самый большой куст SOFTWARE- 40. Как видите, размеры по современным меркам просто смешные, и далеки до каких либо ограничений.
Зато вот нахвататься глюков с ними легко. Я свою ОС не чищу, и у меня ни реестр не ломается, ни глюков нет, а BSOD видел только по причине своей криворукости жадности, когда выставил неверные тайминги оперативной памяти.
0
«Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие.»
Это ваше личное мнение? Доказать-обосновать как-то можете?
А я вот думаю что влияет. Впрочем не вижу смысла спорить.
+1
Моё мнение основано на знании алгоритма работы реестра, полученного путём чтения литературы типа «Внутреннее устройство Microsoft Windows» и статей в интернете. А ваше на чём основано?
0
Оригинально, как читая одну и туже литературу, можно придти к совершенно противоположным выводам.
0
у Linux есть недостатки. Но сравнивать бесплатно и платное ПО

Прошу прощения, насколько мне известно, UNIX — это далеко не только Linux. Точнее даже, Linux — не совсем UNIX.
И что там с бесплатностью у (Sun)^W Oracle Solaris? Или у macOS, фанаты которой хвалятся тем, что она «настоящая UNIX»? О более редких коммерческих версиях можно не вспоминать.
0
"«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX»."
Вот оно что! Оказывается философия UNIX — всё есть текст. Интересно, а философия Windows тогда — всё есть ОКНО.
0
Статья о наболевшем — это понятно и стиль статьи тоже принимается, но после прочтения возникает только одна мысль: — «Что же мне делать? Как быть то сыну простого крестьянина? Пишущему классы для работы с периферийными устройствами и разрабатывающему ПО АСУ ТП ???»
Но теперь я знаю что!!! — Поднять руку, левую или правую, и резко опустить со словами: -«Ну и… с ним!!!»
А про себя подумать: — «Делай что должен! И будь что будет!» :-)
+5
Кстати, в заголовке явно не хватает фразы "… Программисты всего мира в шоке..."
+5
Вообще то с философией юникса ассоциируют именно эти три вещи и именно в этом порядке.
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.

И это действительно могущественный вывод на опыте создания програмных систем. Который постоянно вплывает в разные контекстах и эпохах. Сейчас к примеру это микросервисы.

+3
  • В самом начале make был программой, которую один человек написал для себя и нескольких своих знакомых. Тогда он, недолго думая, сделал так, что командами воспринимаются строки, которые начинаются с Tab. Т. е. Tab воспринимался отлично от пробела, что крайне некрасиво и нетипично ни для UNIX, ни за его пределами. Он так сделал, потому что не думал, что make будет ещё кто-то использовать кроме этой небольшой группы. Потом появилась мысль, что make — хорошая вещь и неплохо бы включить его в стандартный комплект UNIX. И тогда чтобы не сломать уже написанные мейкфайлы, т. е. написанные вот этими вот десятью людьми, он не стал ничего менять. Ну вот так и живём… Из-за тех десятерых страдаем мы все.

Перефразируя классика:
  Мы все страдали понемногу
  О чем-нибудь и как-нибудь,
  Так что незнаньем мануалов, к сожаленью,
  У нас немудрено блеснуть.

$ info make

2.1 What a Rule Looks Like
==========================

A simple makefile consists of "rules" with the following shape:

     TARGET ... : PREREQUISITES ...
             RECIPE
             ...
             ...

   A "recipe" is an action that 'make' carries out.  A recipe may have
more than one command, either on the same line or each on its own line.
*Please note:* you need to put a tab character at the beginning of every
recipe line!  This is an obscurity that catches the unwary.  If you
prefer to prefix your recipes with a character other than tab, you can
set the '.RECIPEPREFIX' variable to an alternate character (*note
Special Variables::).


  • Вообще, названия утилит UNIX — это отдельная история. Скажем, название grep идёт от командй g/re/p в текстовом редакторе ed. (Ну а cat — от concatenation, я надеюсь, это все и так знали. :) Ну и для кучи: vmlinuz — Linux with Virtual Memory support gZipped.)


  • Когда Кена Томпсона, автора UNIX (вместе с Деннисом Ритчи) спросили, что бы он поменял в UNIX, он сказал, что назвал бы функцию creat (sic!) как create. UPD от 2017-02-12: источников полно, например: en.wikiquote.org/wiki/Ken_Thompson. No comments. Замечу, что позже этот же Кен Томпсон вместе с другими разработчиками оригинальной UNIX создал систему Plan 9, исправляющую многие недостатки UNIX. И в ней эта функция называется create. :) Он смог. :)

И что? Ужас, утилиты и функции названы не так? Задето чувство прекрасного? Возмутительно, как после всего этого с этими cp и creat (sic!) эти UNIX-подобные системы можно использовать?! Так это ещё цветочки, вот вообще трэш — «О срезании углов»
:-)))
0
Вот, как надо комментировать подобные потоки сознания. Спасибо!
-1