Pull to refresh

Comments 700

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

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

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

Я считаю, у 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

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

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

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

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

Голый C прекрасен, просто он не всем подходит.
UFO just landed and posted this here
BF вообще замечательный, его лаконичность потрясает. А если вам не нравится, то вы просто школотроны, единственно на что способные — кнопки по формам расставлять. Fixed for ya.
Именно! Все языки по-своему прекрасны и у каждого найдутся приверженцы.
Уже лет 20 нет ни одной причины не использовать вместо него си с плюсами, даже для системных вещей, тем более что в с-стиле можно и на плюсах прекрасно писать.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Предполагается что у баз данных есть индексы и самое главное контроль целостности до записи(имеется в виду завершение транзакции), чего нет у идеологии 'все есть текст', т.е. в случае с /etc/passd об ошибке скорее всего узнаем по факту использования.
UFO just landed and posted this here
Форматируемый вывод оказывается не самый быстрый вывод! Я прямо-таки потрясен этим откровением. А нет, не потрясен. Это все написано в любой книге по С.

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


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

UFO just landed and posted this here
Особенно умиляет твердокаменная уверенность в том, что при крахе системы у бинарной конфигурации больше шансов выжить, чем у текстовой.
Оставляя за скобками такой важный нюанс, что текстовую конфигурацию, при повреждении, куда легче и быстрее восстановить вручную, чем бинарную без дополнительного специфического инструментария
UFO just landed and posted this here
юзеры ещё не то могут убить… Приходилось чинить. Там не все в двух копиях, вообще-то.
Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно. До этого — сколько угодно.
Тем не менее — если регистр повреждён (да даже действиями пользователя) до степени незагужаемости системы, это требует специфических инструментов для ремонта, в отличии от текстовых конфигов.
С точки зрения производительности системы, можно хранить в памяти результат чтения текстовых конфигов и обращаться к нему (рано или поздно вся эта концепция systemd к такому и приведёт).
Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно.

Отключение питания на этапе загрузки убивает реестр и на 7. Никогда не понимал логики, зачем надо писать в реестр до логина пользователя.
UFO just landed and posted this here

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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

Вы недооцениваете вероятность наличия багов. :)

А если у родителя просто нужный тред заблокировался на IO, а все остальное хорошо и в порядке?
Просто хипстеры не умеют так:
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 just landed and posted this here
А если RAM сдохнет? Или контроллер? Или питание вырубится?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

UFO just landed and posted this here
UFO just landed and posted this here
Я может плох в истории, но один из, так сказать, главных дизайнеров Windows NT Дейв Катлер является одним из самых известных хейтеров Unix, и как раз делал все по-другому. Можно каких-то подробностей по Unix legacy в ядре NT?
UFO just landed and posted this here
Я вот про буквы дисков и точки монтиования не понял. Точки монтирования позволяют примонтировать ФС где мне угодно, т. е. я контроллирую под каким именем будет известна та или иная партиция диска или та или иная виртуальная файловая система. В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?

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

Про архиетктуру процессов — слишком абстрактно, так что не могу никак прокомментировать. Само понятие процесса существовало и до Unix, интереснее что специфично от Unix-а взято.
> В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)
Ну ссылка которую вы привели тоже не на самый первый NT ссылается (и не могу найти в статье информации о версиях NT, в которых эта фича поддерживается), так что нельзя утверждать что это Unix legacy. Вполне могу представить, что они это потом впили, дабы угодить особенно привередливым клиентам. Есть ли что-нибудь постарше?
UFO just landed and posted this here
UFO just landed and posted this here
Ну скажем так, LVM, даже если забыть про Windows, я бы не назвал Legacy — он не такой уж старый (1998, это уже linux 2.4, да и windows nt повяился несколько раньше, если мне не изменяет память) и не настолько уж типичный для Unix-ов в целом.

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

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

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

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


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

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

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

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

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

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

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

Верно. ACL привнесли ребята из DEC/ VMS команд, ACL были в RSX-11 на PDP.
Ко всему описанному добавлю: современные исполняемые файлы под NT (Portable Executable) основаны на COFF (даже заголовок его наследуют).
Я давно говорю, нет, я кричу сделайте в школе и вузах хоть краткий курс истории науки.
Новые поколения считают, что все новое появляется вдруг, само по себе. А старое было плохо и т.д., и т.д.
Но мои слова летят в пустоту, все хотят прикладных знаний и быстрых прорывов.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Вобще-то нет, Катлер и его команда пилили VMS в Digital, поэтому в первых НТ было всё-таки больше от неё, чем от чего-то позиксного.
Или некий аналог реестра

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


image

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

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

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

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

Советую почитать о flatpak и snap

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

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

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

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


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


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

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

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


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

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

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

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

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

UFO just landed and posted this here

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

а если вы сделаете «apt install php7.0-fpm; apt install apache2»? первая команда видит что апача нет и конфиг дня него не кладет, вторая команда ставит апач, а конфига для php7-fpm нет, тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов» и после установки апача вызывать что-то типа «перераскладывания примеров конфигов для php7-fpm и всех остальных, у кого могли быть примеры конфигов для апача» при этом попутно решая что делать с «вручную исправленными конфигами». К тоже же кмк идеологически неверно при установке апача как-то реконфигурировать совершенно другой пакет. Да и к тому же не очень понятно чем вам мешает лишняя директория в /etc. Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.
UFO just landed and posted this here
Не мешайте людям раз за разом использовать «Чистильщики реестра» и «Ускорители компьютера», чтобы потом жаловаться, что ничего не работает. Это их выбор
UFO just landed and posted this here

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


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


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


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

не видел ни одного приложения под win, которое удаляется ПОЛНОСТЬЮ, не оставляя файлов/записей в реестре.

А я сопровождаю четыре таких, и еще два пишу :)

Наоборот, на мой взгляд, редкость, когда что-то остается. Это очень субъективно, зависит от набора используемых программ.
Теперь я примерно представляю как мог размышлять Поттеринг создавая свои решения. Вот это все «надо везде использовать JSON, XML и бинарные форматы, а потом просто их дополнительной программкой в человеческом виде выводить».
Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками. Не пришлось бы парсить вывод самостоятельно

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

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

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


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

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

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

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

> Что значит «менять»?
Менять JSON на Tree

С каким ключом вызывать ls чтобы получить JSON?

UFO just landed and posted this here

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

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

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


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

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


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

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

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

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


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

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

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

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


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

А, так вот почему всю статью было впечатление, что это чей-то перевод…
UFO just landed and posted this here

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

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

Так и рождаются «синие занавески»
Скрытый текст
image

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

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

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

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

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

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


Also есть scons.

UFO just landed and posted this here
Есть Posix ACL. Можно подробнее что в Window-ых ACL есть, чего не хватает в Posix ACL?
UFO just landed and posted this here
В ubuntu они есть по-умолчанию, другое дело, что чтобы они начали работать их нужно настроить (но простите, настройка ACL по-умолчанию — это какой-то странный зверь, что он и кому будет разрешат/запрещать?).
UFO just landed and posted this here
Пользуются те кому Posix ACL нужен, не пользуются все остальные. Какое отношение сколько утилит его поддерживают имеет к делу? Хранением ACL занимается ФС, проверкой ядро, редактирование ACL делается через специальную утилиту — какие еще утилиты вам нужны?

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

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

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

И кстати, по-моему это и с общим корнем можно сделать без ACL. Какое-нибудь chmod go-rwx и всё.
В юниксах довольно давно есть фича, делающая именно то, что вы сказали. Т. е. установить специальный бит на папку так, чтобы в этой папке все могли создавать, но при этом нельзя было лезть в папки, созданные другими. Этот бит стоит по дефолту на /tmp в GNU/Linux, т. к. именно для /tmp такая функциональность обычно и нужна.
UFO just landed and posted this here
под nested acl я имел в виду возможность наследования групп — то есть у тебя допустим папка «файлопомойка», в которую могут писать «отдел 1», «отдел 2» и «отдел 3». в каждой из этих групп — подгруппы, типа «менеджеры отдела Х», «начальство отдела Х» итд. в posix ACL тебе придется все эти группы прописывать вручную, что очень быстро выльется в нечитаемый зоопарк.

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

а расширеные права хороши для файлопомоек тех же — создавать write-only каталоги, чтоб никто ничего случайно лишнего не грохнул или не перенес в 20й уровень вложенности.
UFO just landed and posted this here
Да, возможно.
В NTFS в ACL указываются только токены SIDов, а их семантику определяет либо локальный SAM либо сетевой AD — какой SID обозначает аккаунт, какой группу, и членами каких групп являются известные группы и аккаунты.
Поэтому на уровне разрешений ФС нет принципиальной разницы между SAM и AD.
UFO just landed and posted this here

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

UFO just landed and posted this here

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

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

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


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

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


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


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


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


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


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


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

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

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

Нет таймлайн корректен. 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 лет прошло...

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

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

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

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


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


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


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

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

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

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


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


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


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

Кстати, scons хорош? Я вот думаю освоить для проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@worldmind предлагает сделать ворд более философским :)

Но для таблиц же есть замечательный плагин под офис.

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


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

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

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


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


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


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


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

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


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


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


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

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

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

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

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

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

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


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


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


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

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

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


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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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


вызываем 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

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

UFO just landed and posted this here

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

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

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

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


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


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


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


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


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


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


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


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


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


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

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

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

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

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

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

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

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


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


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

Это НЕ конфиги, а внешние скрипты. И они должны быть отдельно от конфигов.
Это неоднозначный теологический вопрос. Например «конфиги» сети, почты, АТС по сути несут в себе сценарии инициализации оборудования и/или обработки данных.
UFO just landed and posted this here

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


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


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


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


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


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


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


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

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

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

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


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


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


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

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

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

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

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

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


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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

Так вперед! Продвигайте и реализуйте прогрессивные идеи. Сообщество Unix-подобных систем не на столько закостенело — постоянно появляются новые разработки. Что-то приживается, что-то отмирает.
UFO just landed and posted this here

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

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

Почему — не сделал? Visual Studio использует nuget...

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

UFO just landed and posted this here
Хорошо показывает фразу выше, мол человек ко всякой кривизне привыкает, дай только время.
Идеала нет, и много зависит только от привычек.

Я для кого объяснял? Я в своей статье разрушил аргументы типичных фанатиков 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'е. Я просто хочу, чтобы люди кое-что про него знали.

xml… достаточно хорошо читается человеком

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я имел в виду, как удалить файлы, большие 1 кб, в текущей папке

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


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


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


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

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

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

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

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

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


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

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

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

Поставил источники на многие факты в статье

Ок, весь софт — дерьмо, жизнь — дерьмо, мир — дерьмо. А чем пользоваться — то? :D
виндой конечно, видимо это автор хотел сказать.
Так винда тоже дерьмо :(
UFO just landed and posted this here

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

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

Чего там, паравиртуализацию во FreeBSD уже завезли? Как с поддержкой аппаратного ускорения современных видеокарт? А юникод в консоль без костылей завезли?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Не, логика еще проще. Есть инструмент — делаешь. Нет инструмента — не делаешь. Все оборудование без проблем завелось в Linux и работает до сих пор. FreeBSD тогда таким похвастаться не мог. Проще взять другой инструмент, чем мучаться с непригодным.
UFO just landed and posted this here
У вас неправильная логика. Все оборудование было IBM eSeries или IBM Bladecenter, с очень серьезной поддержкой со стороны вендора. Itanium также был в IBM-овском сервере, но уходил на списание. К сожалению вдохнуть новую жизнь фряхой не удалось. Не думаю что закупка ЦОД — дело импульсивное.
Все это конечно хорошо, что сейчас многое появилось. Но в 2009, когда мы поднимали кластер с Infiniband, фряха его не поддерживала. Надо было наверное сказать, что пацаны погодите, пускай железо постоит пока, там пацаны из фряхи еще драйвер не написали.
Учитывая нынешнюю копроэкономику, поддержка древних устройств никак в не помогает ОС продавать себя, рынку нужна поддержка всего самого свежего и сейчас, а не через пару лет.
А так, конечно фряха ставилась везде, но не везде взлетали нужные устройства. Хотя вру, на Intel Itanium дальше Boot Logo продвинуться не удалось, пришлось ставить SUSE.
То что FreeBSD нельзя использовать как основу гипервизора в нынешних реалиях печально. Даже винду можно.
2 Incidence
Я в курсе, и всего то на 18 лет. Это к свежести вопроса про utf в консоле. Мне лично он там никогда актуален не был.

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

Если это такая шутка, то она опоздала лет на 25, как минимум.
UFO just landed and posted this here
Речь шла о поддержке ядром ОС именованных объектов.
А не о том, какие востребованные в 0.01% случаев свистоперделки можно прикрутить к терминалу через ANSI-коды и прочие не относящиеся к обработке строк вещи.
> Хз, мне виртуалбоха хватает.
Облака тоже на виртуалбоксах пилить будете? 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 нет, ТВ тюнер хоть и с аппаратным кодеком, тоже нет и т.д.
UFO just landed and posted this here
UFO just landed and posted this here
С одной стороны, нельзя не признать, но, с другой стороны, невозможно не отметить.

Примерно половина доводов в статье как всегда — просто раздувание слона из мухи, или просто непонимание каких-то моментов реальности. Но остальная половина, конечно, является доводом в определённой степени. В общем, главное — не бросаться из крайности в крайность. 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.

Да, терминал в 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 работает (или наоборот было?).

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

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

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


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

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


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

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

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

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

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

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

man find | grep exec

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

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

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


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

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

И назад к 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 просто служит человеку и помогает работать с информацией, не должно быть необходимости помнить и отслеживать, где какой конец строки используется.
Эту проблема не Unix, а как раз таки искусственно создана MS в качестве вендорлока.
Какие же они evil!!!
Unix пришел с «больших» машин, терминалы которых имели раздельные клавиши ВК и ПС (CR и LF). Физически разные кнопки. И еще со времен телетайпов окончание ввода обозначалось нажатием на клавишу «Возврат каретки».
А MS развивался на рынке ПЭВМ, где была одна клавиша «Enter», и была необходимость генерировать оба символа сразу при нажатии одной кнопки, поскольку эти операции не разделялись, и автономная «возврат каретки» была не нужна — ее роль по сути выполняла клавиша Home.
UFO just landed and posted this here
Тема не раскрыта. В статье приводится набор частных недоработок, не совсем удачных или устаревших решений, личной вкусовщины. Никакого общего ядра у этого списка претензий нет, никакого «краха философии» из них не следует.
Ну, дьявол, как известно, в деталях. Да автор и сам пишет, что «Есть идеи в UNIX, которые мне реально нравятся». Идеи Юникс в целом прекрасны и замечательны, а вот все проблемы именно в частных недоработках. Причем эти частные недоработки расползлись и размазались тонким слоем по всему Юниксу, так что иногда даже сформулировать бывает сложно… но автор попытался, за что ему честь и хвала, я бы так не смог (хотя наталкивался на все это тоже).
Тогда статья должна называться «Проблемы в современных реализациях Юникса»
С табуляцией в make решение неудачное, но хорошей замены этому инструменту я не нашел. В sbt, cabal, cargo очень тяжело сказать системе, что "'эти файлы, несмотря на расширение, не трогая", а «этот надо сгенерировать, запустив такую программу».
Плохо не то, что в Unix накопились баги, плохо то, что их толком ни где не исправили.
Я вообще считаю, что если возникает такая потребность как «эти файлы несмотря на расширение не трогай» то тут что-то не то. Да и генерить файлы… ну не всегда это нужно. Я писал проекты с тысячами файлов исходного кода, и нигде такое не требовалось. Хотя я понимаю что это может быть необходимо в каких-то случаях.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.
Среди различных 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-скрипт (не супер часто его приходится указывать явно) и имя автоматически генерируемого файла и скрипт для его генерации. Я бы не назвал это не декларативным.
Эта потребность вполне естественна, если не считать себя ограниченным мейнстримовыми технологиями. Так в makefile я бы легко мог декларативно описать необходимость сгенерировать .js файлы из .elm в веб-приложении на Scala, в то время как в sbt мне приходится для этого писать императивный код.
Для разработки своих языков, даже DSL, постоянно требуется компилировать свою библиотеку только что собранным компилятором. В make это делается элементарно.
Использование дополнительных препроцессоров, даже классических lex и yacc, не говоря уже о редких NJ Machine-code Toolkit и noweb, в проектах не на make становится приключением для эксперта в конкретной системе сборки.
Вообще, желание сделать наиболее популярное использование до предела простым тормозит развитие технологий. Нужен компромис, который в make был более-менее достигнут, если закрыть глаза на извращенное решение с табуляцией. Другие системы не декларативны, а более императивны, просто обладают неестественным интеллектом, позволяющим им распознать популярные случаи использования.

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

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

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

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

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


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


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


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

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

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


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

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

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

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

C# и его интерполяция строк...

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


Console.WriteLine($"{DateTime.UtcNow:{{}");
Доказательства есть? Хотя ниже уже ответили.

Например, в 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"]]
}
Вот по этому я и не пользуюсь *nix.))
Чем пользуетесь-то, где костылей меньше? Plan9 или Inferno?
Пусть автор в Windows попробует создать файл с простым именем prn (Этот артефакт ещё с доса тянется)…
А вообще надо не забывать, что часто недостатки, являются продолжением достоинств.
(Ушёл с винды ещё в 2006 году(и перевёл всех своих клиентов с винды)… что я тоже делаю не так???)
Да, в принципе, запросто. И даже Symbolic link удалять не надо.
Скорее всего, это сетевая шара на самбе или типа того, где ни одно из этих имён не является зарезервированным.

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

пришло время переписать unix на расте…
UFO just landed and posted this here
UFO just landed and posted this here
Предлагаю автору написать аналогичную статью про OpenVMS.

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

Я твой UNIX-дом труба шатал, shell-калитка тряс, философия-огород топтал, язык С кэпка на х… вертел!
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют. Мой текст обращён скорее к фанатикам UNIX и GNU/Linux. Провокационный тон просто чтобы привлечь ваше внимание.
У автора типичное пацанское представление «поколения интернет» — только что вылупившись из яйца и ничего еще сам не понял и не сделал, но уже клеймит позором «костыли и философию UNIX». Будь эффективнее — сделай свое и не трать время на подобные клеймящие «статьи».
Ох уж этот юношеский максимализм, вчера из пеленок выпрыгнул а сегодня говорит что мир не правильно устроен… Сделай что нить свое и поддерживай его в актуальном состоянии лет 10, вот потом будешь иметь право использовать такие слова в заголовках.
Как-то несерьёзно это всё. Конечно у Linux есть недостатки. Но сравнивать бесплатно и платное ПО как-то не принято в мире. Не нравится-покупай и ставь Windows, Linux никто не навязывает.
Про реестр идея интересная конечно. Если бы это было грамотно реализовано. Но ведь RegCleaner'ы для чего-то существуют. А значит реализация подкачала.
Ну и сравнивать linux-shell и php вообще нонсенс.
UFO just landed and posted this here
Во-первых есть бесплатные. Во-вторых опыт показывает что regcleaner размер реестра иногда значительно уменьшает. А значит не всё так уж хорошо с реестром.
UFO just landed and posted this here
«Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие.»
Это ваше личное мнение? Доказать-обосновать как-то можете?
А я вот думаю что влияет. Впрочем не вижу смысла спорить.
UFO just landed and posted this here
UFO just landed and posted this here
у Linux есть недостатки. Но сравнивать бесплатно и платное ПО

Прошу прощения, насколько мне известно, UNIX — это далеко не только Linux. Точнее даже, Linux — не совсем UNIX.
И что там с бесплатностью у (Sun)^W Oracle Solaris? Или у macOS, фанаты которой хвалятся тем, что она «настоящая UNIX»? О более редких коммерческих версиях можно не вспоминать.
Статья скорее говорит за UNIX, чем против него.
"«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX»."
Вот оно что! Оказывается философия UNIX — всё есть текст. Интересно, а философия Windows тогда — всё есть ОКНО.
Статья о наболевшем — это понятно и стиль статьи тоже принимается, но после прочтения возникает только одна мысль: — «Что же мне делать? Как быть то сыну простого крестьянина? Пишущему классы для работы с периферийными устройствами и разрабатывающему ПО АСУ ТП ???»
Но теперь я знаю что!!! — Поднять руку, левую или правую, и резко опустить со словами: -«Ну и… с ним!!!»
А про себя подумать: — «Делай что должен! И будь что будет!» :-)
Кстати, в заголовке явно не хватает фразы "… Программисты всего мира в шоке..."
Вообще то с философией юникса ассоциируют именно эти три вещи и именно в этом порядке.
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.

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

  • В самом начале 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-подобные системы можно использовать?! Так это ещё цветочки, вот вообще трэш — «О срезании углов»
:-)))
Вот, как надо комментировать подобные потоки сознания. Спасибо!
Так, что за оскорбления, фанатики мол. Может автор статьи и причисляет себя к фанатикам, но я — себя нет. Разве в UNIX так называемой философии говорится о полном отсутствии костылей? Статью надо переделать, убрав все провокационное, и оставив только конструктив. Странно и грубо эксплуатировать эмоциональную привязанность людей к неким системам, если «наболело» — да быть такого не может что наболело, кто обязан выслушивать ваш крик души? Вы исключительный? Вы капризный псих, с которым никто не общается? Идите успокойтесь самостоятельно и без ущерба для других людей, и внесения уродливого хаоса в мысли публики. Смутьян нашелся.
Статью надо переделать, убрав все провокационное, и оставив только конструктив

Цель статьи в том, чтобы покритиковать, ничего не предлагая. Я обращаю внимание на то, какой же всё-таки legacy этот UNIX. Чтобы не было больше вот этих горящих глаз "Ах, UNIX, UNIX!" А использовать его и дальше можно. Если кому-то нужны альтернативы, посмотрите Plan 9 и прочие новые ОС. Но и сам UNIX не плох. Он стабилен и популярен. А провокационный стиль нужен был, чтобы встормошить читателя.

— Чтобы не было больше вот этих горящих глаз «Ах, UNIX, UNIX!»

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

Писать говнокод @ жаловаться на то, что он говнокод. Следите за пальцами:

find foo -print0 | xargs -0 touch --


Более того, оно не будет запускать на каждый файл по процессу, а если файлов слишком много для одного touch — все равно отработает хорошо. Чудесная простота и эффективность.

В данном примере для демонстрации я использовал решение с пайпом и циклом. Можно было использовать решение с -exec или xargs, но это было бы не так эффектно

Блин, так это еще и специально? КГ/АМ
Прочитал все комментарии, по-моему все что нужно уже сказали. Поэтому выскажусь чисто по философски:
Поняли, фанатики, да? Ваш кумир отказался от своей же философии. Можете расходиться по домам.

Мы не фанатики, и кумиров у нас нет, и это тоже часть филосфии Unix. Поэтому расходиться нет никакой совершенно надобности.
Статья подняла настроение. А про GIT в том же стиле сможете написать? :)

Git написали за неделю на коленке. (Да, да, почитайте историю гита.) Далее, гит на самом деле очень тупо "лобовым" способом устроен внутри. Вон, почитайте: https://www.opennet.ru/base/dev/git_guts.txt.html. Там тупо считаются хеши от файлов, затем эти хеши складываются в текстовые (!) файлы (в этом я не совсем уверен), от них считаются ещё хеши, от них ещё хеши и т. д. А можно было как-нибудь умнее сделать. Чтоб папки были всё-таки бинарными объектами сразу. А не текстовыми файлами захешированными.


Ладно, я выдохся. В общем гит настолько прекрасен, что его покритиковать сложно. Если серьёзно, то гит прекрасен. В отличие от юникс, который реально плох :)


Ах да, в гите многие команды реализованы на б-гмерзком шеле :)

А через X времени появится статья «гит — не так прекрасен, как все думают! конец эпохи систем контроля версий!»
Чтоб папки были всё-таки бинарными объектами сразу.

Git игнорирует существование директорий как отдельного класса объектов. Вы не можете взять и добавить в репозиторий директорию без файлов.

UFO just landed and posted this here
Про GIT писать не надо — уже написано полно.
Чё-то хрень какая-то (вроде бы, дальше первых двух абзацев читать было лень, скажите спасибо, что откомментил).
Критика — это хорошо, если она конструктивна. Критика в статье не предлагает альтернатив.
От статьи был бы толк, если бы Винда под конец жизни не продалась дъяволу. И её перспективы теперь, увы, туманны. Разве что, геймеры продолжат за неё цепляться.
Прочитал Ваш поток сознания и болезненный хипстерский крик души и даже специально зарегистрировался, чтобы ответить. Штуковина, которую вы пытаетесь критиковать де-факто обслуживает весь интернет в мире последние лет 50 и никакого краха там нет и не предвидится. От того что вы составляете списки костылей в ней, забиваете гвозди микроскопом, туннелируете через 4(четыре Карл!) хоста ради одного файла и почему-то по умолчанию считаете каждого первого встречного её фанатиком в этом мире совсем ничего не изменится. Такие дела. Чао.
«Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем.»

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

(ц) почти Уинстон Черчилль

Наверное для таких глобальных суждений, как в статье, все-таки нужно вводить возрастной ценз, или хотя бы по опыту работы. А то любой может об… ать труд двух поколений людей, обозвав всех фанатами и кичась своими фрагментарными знаниями чего-либо. Просто есть и будут вещи, которые устаревают, а есть вещи, которые нет, как топор. UNIX — топор, который будет продолжать рубить еще долго, не смотря на то, что будут говорить отдельные «знатоки».
Признать, что вещь устарела, а какая-то концепция является костылем — да, тут нужно мужество, не каждому по плечу.
Вы забыли суть понятий, о которых говорите. Костыль — это приспособление для передвижения с учетом действующих ограничений, при учете имеющихся ресурсов. Нужно понимать понятие эффективности как отношение результата к вложениям, при котором костыль в большинстве случаев эффективнее 4 человек, которые могли бы вас носить.
Так вот, устаревшая вещь — это вещь, потерявшая эффективность. С UNIX системами этого еще не произошло, при относительной бесплатности они работают, и эффективной замены пока что нет. Это то же самое, что сказать, что топор устарел, ведь есть лазер, им можно нарубить дров на даче.
Дело не в мужестве, которым вы, судя по всему, с избытком обладаете, а в эффективности. Как только затраты на костыли превысят затраты на написание/поддерживание новой системы, произойдет смена парадигды и как следствие — платформы.
Что-либо устаревает только тогда, когда затраты времени и денег (в конечном счете — денег) становятся существенно больше, чем у аналога.
и эффективной замены пока что нет


А Inferno не вариант? Я сам в этом не очень разбираюсь, но слышал о ней очень позитивные отзывы, в том числе и на Хабре были статьи.
Почему не вариант, вариант. Просто видите как, популярность оси — понятие сложное. Тут в осях для телефонов-то тяжело разобраться, почему одна распространеннее другой, а третья и другие вымирают.
Вы просто представьте себе процесс самого выбора этой оси для серверов — это же не так, что решили вы поставить нечто, выучили и работаете. Для этого вся компания должна принять решение, переучить/набрать новых людей, чтобы это админить — это ведь все расходы, деньги. Регламенты написать, возможно железо частично заменить. Надо объяснить дяде-собственнику и дяде-инвестору, что эта ось выгоднее старой, потому что… что? Старая некрасивая и неудобная? — Ну так не целоваться с ней просят. Устаревшая? См. мой предыдущий коммент. Костыли в ней и их много? Ну и что. Единственными аргументами могут быть параметры работы (скорость, безопасность, стабильность, стоимость лицензии и проч. — тут грамотные люди лучше меня подскажут) и стоимость персонала, который новую ось будет обслуживать. На анальные боли админов, их комплексы и стенания почти всегда всем начхать, кроме как если админы эти начинают совсем все увольнятся (т.е. финансовый вопрос встает). Даже в небольшом банке это довольно сложный выбор (я такое видел), и как правило побеждает мнение — что если что-то работает — нефиг это трогать. А то потом кто будет отвечать за то, что у тебя вместе с новой осью легла АБС банка и банк сколько-то денег потерял, потому что весь не мог работать — мужественный смелый парень, который предложил это сделать? С него и взять-то нечего. Я к тому, что есть еще понятие «риски», и когда это понятие люди рассматривают применительно к своим деньгам, а не так, пофилософствовать, то вся смелость куда-то пропадает, а берутся проверенные решения, работающие годами. Чтобы наплевать на риски, надо ситуацию загнать в такой угол, что все равно уже терять нечего, «давайте попробуем новую дешевую систему», либо если это стартап. Ну так чтобы стартапы, использующие Инферно, выросли и показали эффективность этой оси, нужно время, а оно еще не прошло.
Если же говорить о частных делах, то существенный фактор — поддерживает ли платформу нужное ПО, без которого никак.
Запустите на Инферно 1С Бухгалтерию, МС Офис и большинство комп. игр без виртуалки — и тогда возможно люди задумаются.
1C и МС Офис и на Линуксах не пойдут)

Единственными аргументами могут быть параметры работы

Может такое быть в идеальном мире, что сам собственник решит поэкспериментировать (он ведь может быть ещё и айтишником, любящим инновации). Хотя конечно если бы я планировал открыть банк, я бы рисковать не стал. А вот для стартапа — да, очень даже можно.

Кстати, именно крупные проекты типа того же Facebook делают популярными разработки, которые они сделали сами (либо допилили), но о которых никто бы даже и не узнал, не будь у компании такого имени. HHVM например можно вспомнить, Nginx, движок V8.
1C и МС Офис и на Линуксах не пойдут)

Все же с натяжкой можно сказать, что офис на мак ос портирован, т.е. подвижки есть.
Я в данном случае про ПК говорю — то есть там, где частное лицо решение принимает — мы с вами на своих компах.
Собственник бизнеса не хочет экспериментировать в большинстве своем, он хочет заработать деньги, притом на том, что он понимает. Соответственно экспериментировать может либо государство, либо софтверная компания.
Да возможно вы правы, когда нибудь какая-нибуль крупная компания, выросшая из стартапа, напишет свою ось для своего железа, и отдаст/продаст это миру. Андроид же родился почти так?
Ну Андроид-то был не для «своего железа», а просто чтобы был конкурент iOS :) Я вообще толком не знаю, с какой целью создавалась эта ОС, надо будет почитать. Может, уже держали в голове монетизацию через маркет приложений, может, рассчитывали поиск свой продвинуть в мобайл сегменте. В итоге все задачи были решены более чем успешно.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Мы все-таки на ИТ-ресурсе, а то что вы описываете это уровень бабок у подъезда.
К сожалению 90% всех решений мы принимаем именно на этом уровне. Даже люди, которые верят (и небезосновательно!) в то, что у них хорошие мозги стараются включать их пореже. Защитный механизм — чтобы «процессор» не сгорел от перегрева и батарейка раньше времени не кончилась.

Принимайте решения как угодно — но в диспуте надо приводить аргументы, а не эмоции.

Вы забыли о факторе времени. О том, что некий tradeoff по эффективности не вечен, а костыль из этого самого некогда баланса превращается в legacy, от которого просто уже нельзя отказаться.

С UNIX системами этого еще не произошло

Я сказал «вещь устарела», а не «UNIX системы устарели».
Так вы про топоры пришли написать, или про UNIX?
Если про топоры, то отказ от них произойдет не по причине их собственной неэффективности, а по причине неэффективности дровяного отопления. UNIX — отказ от нее произойдет не по причине ее неэффективности, а по причине смены парадигм программирования, либо коренного изменения архитектуры железа. И сколько времени пройдет в первом случае, а сколько во втором (если вообще пройдет) — я лично гадать не берусь. От того, что лично вы перестанете рубить дрова топором, мало что поменяется.
Никчемная аналогия. Статья — о некоторых аспектах операционной системы. Забудем про желтый заголовок данной статьи.
Не сочтите за грубость, но ловите обратно — никчемное замечание.
Статья не о некоторых аспектах оси, а о самой сути этой оси, о ее философии, как ее понял автор. И как раз некоторыми аспектами автор статьи пытается изменить сущность оси.
Заголовок как раз соответствует трактовке особенностей оси с целью подвести ось под общую неэффективность с помощью подмены этого понятия понятием «устареваемости», которого на самом деле не существует, и заранее навесить клише «фанатов» на тех, кто попытается возражать.
UFO just landed and posted this here

Никогда не понимал за что ругают популярные системы/продукты? Мир не идеален и в нем нет ничего идеального, все может только стремиться. Пока Unix/Linux имеет столь огромое сообщество это доказывает, что дохрена людей считают ее лучшим выбором из существующих. Кто считает таковой Windows, кто-то MacOS. Люди сделали свой выбор в пользу той или иной системы по совокупности качеств и характеристик. Не нравиться конкретно Вам, ну не используйте. Вклад Unix и ее производных в развитие технологий неоспорим, если бы не она. Сейчас был бы совсем другой мир. Не все решения в ней идеальны, но если их перенимают другие системы это доказывает их целесообразность.

Мне больше интересно другое. Ну не нравится тебе что-то-не пользуйся. Работай на Windows. К чему эти холивары?
Статья повеселила. Покажите мне номерной маздай с переводом строки в имени файла на NTFS и парсинг этого файла PowerShello'м :))
NTFS никакого отношения к *nix не имеет. Вообще. Это урезанный клон Files-11 от DEC.
Попытка реализовать DEC RMS у мелкомягких с треском провалилась ( Longhorn )
Попытка сделать нормальную ОСь, как то клон VMS: http://www.freevms.net не нашла должного количества волонтеров и находится многие годы в состоянии ни жив, ни мертв.
Так и живем, с Линуксом…
NT и есть переработанная VMS, а уж сколько всего там от Files-11, начиная от ACL и кончая альтернативными потоками…
UFO just landed and posted this here
Мда. А в HPFS они откуда?
UFO just landed and posted this here
Hellsy22,Dessloch

UPD от 2017-02-14: комментаторы указывают, что сравнивать UNIX shell с PHP некорректно. Конечно, некорректно! Потому что UNIX shell не претендует на то, чтобы быть полноценным языком программирования, он предназначен для скриптинга системы. Вот только я в одно время этого не знал. И вдобавок считал UNIX shell прекрасным. Вот для людей в таком же положении я всё это и говорю. Ещё как минимум один комментатор говорит, что сравнивать UNIX shell нужно с cmd. Я бы сказал, что сравнивать надо с Windows Powershell. Последний, как я уже говорил, в чём-то превосходит UNIX shell.
Во-первых PowerShell появился много позже UNIXshell. Лично у меня нет сомнения что Микрософт и разрабатывал его потому что у линуксоидов был вполне удобный шелл, а в Windows батниками ничего толком сделать было нельзя, кроме как файлы скопировать-удалить.
Во-вторых, давайте уж сравним Powershell хотя бы с zsh, который тоже появился позже. Хотя особого смысла в этом нет. Линуксоиды ещё… дцать лет назад могли получить информацию о CPU просто сделав «cat /proc/cpuinfo», а в винде это стало возможно только с появлением Powershell.
А в бизнесе часто бывает так-кто первый предложил качественную услугу-товар тот и захватил рынок. Невооружённым взглядом видно что Микрософт всё время дышит в затылок кому-то. Линуксу, Гуглу, Sony. Всё время пытается либо купить чей-то уже успешный бизнес(Visio, Axapta), либо повторить(Windows-mobile, Azure). И получается пока не очень.
Хотя в десктопных/домашних PC они бесспорно первые.

Какая разница с кем сравнивать powershell — с bash или zsh?

UPD от 2017-02-14: мне понравился вот этот коммент от sshikov ( https://habrahabr.ru/post/321652/#comment_10065532 ):
Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу...» — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.

Да, в этом-то и всё дело! Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат. А использовать-то UNIX можно.
Ну народ… предлагаю cжать zipом файл с именем ?.txt и вручать его всем любителям маздая и powershell, кто распакует в маздае, тот имеет право гнать на UNIX ) Если нет… ждите 20-й версии поделки Билла, может там всё получится. А мы пока на «костылях», потихонечку пойдём дальше...)))

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

Прям сидим и плачем от того что нельзя поставить кучу левых символов в название файла (: 20 с лишним лет это никого не парит (даже сейчас в пользовательских требованиях к MS'у этого нет) и теперь прям станет нужно (:

Ну а вам предлагаю сжать тогда zip'ом файлы с русскими именами и открыть их на линуксе. Уже лет 10 проблема есть. Подожду пока исправят, мб потом перейду.

Ну, это же на самом деле проблема формата zip, а не винды и не линукса.

Везде есть свои минусы, плюсы, свои нюансы. Знак вопроса в названии файла, как и вообще спецсимволы, никого толком не трогают. Интересуют дела насущные — форматирование флешки в fat без ввода пароля, проблемы с железом, корявое кроссплатформенное отображение имен. Вот это проблемы. Ограничения которым 20 лет это уже стабильность, которую ты ожидаешь и держишь в голове при разработке.
Может быть в том, что некоторые архиваторы под виндой используют виндовую кодировку
Тот архив, что на моём скрине выше, был создан штатным zip-архиватором винды из контекстного меню эксплорера, Send to -> Compressed Folder или как его там. Внутри ZIP-файла кириллическое имя оказалось записано в CP866, но zip/unzip со включённым natspec'ом его воспринял корректно. Хотя KDEшный Ark и GNOMEовский File-Roller обломались и показывали "????????" вместо имени, я всё же не думаю, что это проблема именно Линукса.
Естественно, проблема не именно линукса, но пользователю от этого не легче.
Нет там проблемы давно. В zip-формате есть дополнительное поле для utf-8 имени. Это проблема старых архиваторов.
нужно правильный линух использовать, вот FreeBSD — правильный линух ))
Фряха у меня на серверах стоит (:
А можно вопрос — маздай тут при чем? Статья про Unix.
кто распакует в маздае, тот имеет право гнать на UNIX

Ну…
Add-Type -Assembly System.IO.Compression.FileSystem
$zip = [IO.Compression.ZipFile]::OpenRead("R:\test.zip")
$zip.Entries | where {$_.Name -like '?.txt'} | foreach {[System.IO.Compression.ZipFileExtensions]::ExtractToFile($_, "R:\%3F.txt", $true)}
$zip.Dispose()

Я не про в повершелле, просто нагуглил и немного подправил под задачу решение.

А пообсирать баш (приоритеты логики в условиях, арифметические сравнения, [-костыль, кривой парсер синтаксиса), базовые команды (калечность rm, cp, mv) и в целом Linux (калечные права доступа, аудит… и много всего другого) могу, но времени да и желания в данный момент нет.
адское заклинание или костыль? Костыль версус костыль, чей костыль лучше? )) Это никуда не годится, в Unix костыли более эргономические.
Не может маздай то, чего в Unix'e с полпинка взлетает… раздел более 256 Терабайт не, никак (а уже скоро...), а файлов более 2 в 32 на раздел, тоже никак? Но зато всё красиво, это да… но за деньги. )
На работе сервак FreeBSD оцифровывает две вэб камеры на пне 2.8Ггц, одно ядро, 512 ОЗУ DDR, нагрузка около 100%. И маздай выполняет ту же задачу — вынь 7, две камеры, нагрузка 100%, но на четырёхядерном QX6800, 2 Гб ОЗУ. Мне как-бы ехать нужно, а не заклинания писать ))
У меня тут в организации винда 2000 работает на видеонаблюдении с 8 каналами аналоговыми, с 256 оперативкой и на третьем пне (: Я даже не заглядывал туда, только проц давеча поменяли на tualatin (джаст фо фан). Выводит все на телевизор через матрокс, ну и записывает на IDE диск. Умели раньше делать, не то что сейчас.
в оптических мышах тоже камера работает с разрешением 32 пиксела на 32 пиксела ч\б. То, что работает на третьем пне, под маздаем, поедет на первом пне под фряхой…
Вы извините, но вы пишите глупости. Вы выше привели пример сами про 2 веб-камеры и весьма такой нехилый конфиг. У меня 8 (восемь) аналоговых камер и конфиг слабее на порядок, нагрузка 40-50%.

Сейчас ставлю рабочую машинку для IP камер под виндою 7, с слабеньким celeron'ом (на матплате впаянный) + 2 гига оперативки, SSD под систему и 4TB под записи. Вы готовы настроить на нем фряху так, чтоб он тянул 18 камер 24х7?
FreeBSD всегда будет эффективнее при прочих равных условиях.
Разрешение, частота кадров, кодек? в данный момент у меня кодек h264+h265. 720p. Четыре камеры.
Маздай 24х7х365 не умеет по определению…
Слабенький целерон под виндой может и вытянет 120х240 без кодирования. Смотрел я такие видео, на них невозможно даже определить мужчина или женщина, так — силуэты движутся.
В Сони дураки сидят, да? https://habrahabr.ru/post/184426/ PS4 под фрёй работает, интересно, почему не на маздае 2000? ))
UFO just landed and posted this here
>Разрешение, частота кадров, кодек? в данный момент у меня кодек h264+h265. 720p. Четыре камеры.

AHD, 1.3MPx, 1280x960, H264

>Маздай 24х7х365 не умеет по определению…

Бред. У меня тут под боком порядка 70 серверов от разных организаций и примерно половина на винде, аптайм 1в1 — от сервиса до сервиса (раз в год, на рождество), когда заменяется батарея ИБП. Что-то перезагружается для установки обнов, что-то нет. Самый старый сервер — почтовый, уже 20 лет без умолку на винде живет, без переустановки и с остановкой только на сервис.

>Слабенький целерон под виндой может и вытянет 120х240 без кодирования.

Вы долго этот бред будете писать? У меня камеры 960p и 1080p есть, по этим видео уже был найден не один нужный человек.

>В Сони дураки сидят, да? https://habrahabr.ru/post/184426/ PS4 под фрёй работает, интересно, почему не на маздае 2000? ))

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

Пиление сырцоы одной ОС под ОДНО железо — тут знаете можно хоть win98 взять.

>а, матрокс!.. ну вы сравнили тёплое с пушистым. Фряха с матроксом заткнёт за пояс ваш маздай. Без аппаратной поддержки покодируй на винде, на целероне )))

Подсказываю: Матрокс там для вывода на телевизоры, а не для сжатия.
Вот, узнал про AHD, в чём-то польза.
Вот камеры AHD куда подключаются? В DVR, правильно? А c DVR выход ethernet и файлы пуляются на компьютер c маздаем. Т.е. у вас целерон на маздае 2000, как файловый сервер работает, ничего он не кодирует, кодирование идёт в ящике DVR аппаратными средствами. Поэтому то, что у вас 40% нагрузка под виндой, это 1-2% под FreeBSD.
Со времён NT4 мало что изменилось и маздай неизлечимо болен «падючей».
Вы неисправимы (: Вашу-бы энергию да в мирное-бы русло.

Камеры подключены через карту видеонаблюдения (8 каналов). Модель точно не скажу, ибо комп собирал не сам, но карта эта по сути обычный тюнер. DVR не участвует (его нет) в данной сборке, ибо не нужно. Далее проц гонит 5 камер на экран через матрац (4 на одном и одна на второй моник) и 8 через обычный sata контроллер пишет на ЖД.
Это аналоговый пример.

Цифровой пример немного другой: В сети компьютер играет роль регистратора для IP камер, куда через пару свитчей подрублены куча камер 720/1080. обработки нет, поток h264 с камеры + CIF на моник, однако все 16+ камер пишутся на жесткий диск. Связка эта, бюджетная, работает уже второй год без нареканий. Ну ок — основной диск ССД, ибо за компом еще и касса.

> Поэтому то, что у вас 40% нагрузка под виндой, это 1-2% под FreeBSD.

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

> Со времён NT4 мало что изменилось и маздай неизлечимо болен «падючей».

А зачем вы маздай юзаете? Я вот использую windows, причем приходится иметь дело с 2003+ на серверах и они вполне знаете-ли ничего, выполняют свою работу без нареканий.
вот об чём речь и идёт: кодирование у вас в любом случае выполняется аппаратными средствами и мне всё равно чем, хоть DVR, хоть тюнером. Вычислительной мощности целерона 3 не хватит для кодирования даже одной камеры. Так что с чем вы сравниваете? У меня нет ни тюнера ни матрокса, только RTSP потоки с разных частей города и всё успешно пишется на любом железе. И не нужно особо переживать, если что-то выйдет из строя т.к. в течении часа всё пересобирается с нуля. Если умрёт ваш тюнер или матрокс, наверное не легко будет найти ему замену? Таким образом: сравнение целерона 3, который не занимается реальной обработкой видео, а работает как файловый сервер с нагрузкой 40%, вообще неуместно. Как файловый сервер, приведённая мною конфигурация работает с нагрузкой менее 1%. Если вам нравится номерной маздай-виндоувз, это ваше право его использовать. Как говорится, кто на что учился.
Тюнер декодирует сигнал антенный, но записью занимается процессор.

Если умрет не мой тюнер — я хз куда я буду втыкать коаксиалы, скорей всего поставят из запасов еще один или найдут на барахолке по нормальной цене. Если умрет не мой матрокс — охранник не будет на мониторе что происходит, но это не критично — переключу на quadro 440 или банальный MX4 (ну ок, 6600GT AGP) и буду выводить все на один монитор, а не на два, не умрет.

> Если вам нравится номерной маздай-виндоувз, это ваше право его использовать. Как говорится, кто на что учился.

Мне нравится рабочая система и мне по сути… с высокой колокольни на какой ОС оно работает, ибо оно работает. Рассказывать про 1% загрузки вы можете людям которые не касались этих вещей, а не тому кто по юношеству админил сервера игровые и сейчас вынужденно админит парочку на организации. Ну и да — я не учился на это и знания одинаковые — google.

Вы вообще с аналоговыми тюнерами работали? Тем более во фряхе? Или я говорю просто с упрямым человеком? Вы в живую это проворачивали?
Ну наконец-то мы поняли, что работа по обработке и кодированию видеосигнала проделывается не центральным процессором НЕ вашего компьютера, а аппаратной частью в «тюнере антенном»! Это такой профессиональный термин, да? ))
Так, ещё раз, какой конфиг с каким конфигом вы сравниваете? о каком «порядке конфигурации» речь вообще? Тёплое и пушистое нельзя сравнить.
>> записью занимается процессор
А как он это делает?! Ну да ладно. )) Таким образом, таки файловый сервер под управлением MS Windows 2000. Хорошо, что мы во всём разобрались.
И вы утверждаете, что маздай эффективнее NIXов, в качестве файлового сервера? А сколько NASов было выпущено и работает под виндой? Почему производители так не любят выньдовз (ну кроме Micro$oft конечно же), прямо заговор какой-то. А бедные индусы, выходит, за всех отдуваются! ))
Выньдовз администратор игровых серверов. Это что вообще такое? CS запускать нужно было, что-ли? Боже мой, google украл наши знания… ))
И вы утверждаете, что маздай эффективнее NIXов, в качестве файлового сервера?

В чём вы меряете эффективность? В каких попугаях?

А сколько NASов было выпущено и работает под виндой? Почему производители так не любят выньдовз (ну кроме Micro$oft конечно же), прямо заговор какой-то.

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

что работа по обработке и кодированию видеосигнала проделывается не центральным процессором НЕ вашего компьютера, а аппаратной частью в «тюнере антенном»! Это такой профессиональный термин, да? ))

Как работавший с аналоговыми тюнерами, я подскажу — товарищ daggert под «антенным тюнером» имел в виду тракт АЦП, который конвертирует аналоговый сигнал из всяких там пал-секамов в цифровой фреймбуффер. Никакого продвинутого сжатия там не происходит, максимум — конвертирование цветового пространства из rgb в yuv. В лоу-енд решениях от тех же аверов, максимум, что может быть — аппаратный энкодер мпег1, но х264\х265 там нет точно, и этим всё же занимается ЦПУ.
Далее, код самого энкодера это просто числодробилка, она абстрагирована от ОС и не занимается никакими системными вызовами, так что даже в теории не должно быть никакой разницы между производительностью энкодирования в разных ОС, за исключением издержек на планировщик.
> Ну наконец-то мы поняли, что работа по обработке и кодированию видеосигнала проделывается не центральным процессором НЕ вашего компьютера, а аппаратной частью в «тюнере антенном»! Это такой профессиональный термин, да? ))

Я не специалист по видеонблюдению, мне можно использовать любые удобные для себя термины. Могу использовать термин «плата видеозахвата с аппаратным декодированием», если он вам так нравится. И нет, вы не правы — хоть и декодирование до mpeg2 происходит на плате, далее его все равно обрабатывает процессор для вывода на экран и в H264 для записи на ЖД.

> Так, ещё раз, какой конфиг с каким конфигом вы сравниваете? о каком «порядке конфигурации» речь вообще? Тёплое и пушистое нельзя сравнить.

P-III + 256MB RAM + SATA HDD + 8 каналов против вашего

> На работе сервак FreeBSD оцифровывает две вэб камеры на пне 2.8Ггц, одно ядро, 512 ОЗУ DDR, нагрузка около 100%.

> А как он это делает?! Ну да ладно. ))

Святым духом наверное? Или вы считаете что плата напрямую пишет на ЖД, не трогая проц?

> Таким образом, таки файловый сервер под управлением MS Windows 2000. Хорошо, что мы во всём разобрались.

Хорошо что вы так ничего и не поняли.

> И вы утверждаете, что маздай эффективнее NIXов, в качестве файлового сервера?

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

> Почему производители так не любят выньдовз (ну кроме Micro$oft конечно же), прямо заговор какой-то. А бедные индусы, выходит, за всех отдуваются! ))

Наверное по тому что бабло? Вот у нас закуплены были давно еще сервера файловые (для AD) на винде — на 10к дороже вышли, при такой-же комплектации.

> Выньдовз администратор игровых серверов. Это что вообще такое? CS запускать нужно было, что-ли? Боже мой, google украл наши знания…

По себе судите? (:
а, матрокс!.. ну вы сравнили тёплое с пушистым. Фряха с матроксом заткнёт за пояс ваш маздай. Без аппаратной поддержки покодируй на винде, на целероне )))
UFO just landed and posted this here
ещё раз повторяю: на раздел. файлов в разделе. мне нужен один раздел и куча файлов в нём — маздай не может.
UFO just landed and posted this here
«Никому не понадобится большее 637 Кб оперативной памяти для персонального компьютера. 640 Кб должно хватить всем.» — © Билл Гейтс

https://habrahabr.ru/company/ruvds/blog/322138/
Полностью разделяю ваше негодование молчаливым редактированием статей. Право на распространение модифицированных копий не означает право подписывать их вашим именем. Написали, допустим, вы «Гитлер убивал евреев. Фу таким быть», а вам последнее предложение поправили на «Всё правильно сделал». И никаких меток о правке — только ваше имя под публикацией. К кому, как вы думаете, ночью постучатся некомпетентные органы, кому будут предъявлять пропаганду фашизма? Да и просто общественная репутация будет подорвана.
Рискую навлечь на себя гнев фанатов Windows, не очень меня это беспокоит вобщем-то.
Вот ещё статейка в тему
https://habrahabr.ru/post/321696
слабо такое из под винды сделать?
Вам пишут про недостатки у вас дома, а вы все разговор переводите в русло «а вот у соседа», «живи тогда у соседа». Смешно.
Как-бы, наоборот…
Я вот всю статью еще раз пролистал, нигде не говорится прямо «а вот на винде!», разве что за исключением реестра и упоминания вскользь NTFS. Все остальные аргументы вообще не привязаны к другим системам и рассматривают проблемы именно UNIX. А тут часть товарищей все равно пытается свести все аргументы к «а вот на винде!»
Я просто неправильно понял реплику divanikus

Ну, поскольку существует WinPE, который умеет грузиться по сети (а значит. умеет работать вовсе без диска) — нет никаких непреодолимых препятствий чтобы проделать подобную удаленную переустановку системы.


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

В бытность мою админом был такой замечательная флешка у меня, которая была огрызком от винды. Когда ты ее вставлял в комп, там был простой авторан, который копировал некоторые файлы себе и перезагружал компьютер почти со всеми настройками, и там можно было и диск порубать, и файлы сохранить. Что самое удивительное, в то время была работа с сетью через прокси и всякие спецпрограммы доступа к интернету, дык этот образ подхватывал это дело и запускал рабочую систему с rdp включенным. Я так сервер battlefield 2 админил, переставляя систему по RDP через флешку. Пару раз ошибался, не спорю, приходилось сисадмина напрягать на переустановку, но два раза я обновлял систему именно так.
Holix

UPD от 2017-02-14: как минимум один комментатор сказал, что пересел с Windows на UNIX-подобные ОС и счастилив. Что поначалу он плевался от UNIX, но потом решил, что программировать под UNIX гораздо проще, чем под Windows. Так вот, я тоже сперва использовал и программировал на Windows. Потом пересел на UNIX. И сперва, конечно, было очень непривычно. Потом прочувствовал «философию UNIX», ощутил всю её мощь. Программировать под UNIX стало легко. Но позже пришло ещё одно озарение. Что UNIX неидеальна, а «философия UNIX» неабсолютна. Что программирование на «голом UNIX», с использованием C и Shell сильно уступает, скажем, Web-программированию. И далеко не только потому, что в Web-программировании используются языки, в которых трудно выстрелить себе в ногу, в отличие от C (тут языку C предъявить нечего, он намеренно является низкоуровневым). Но ещё и из-за всех этих quirks мейкфайлов, шела, языка C. Отсутствия удобных инструментов, систем сборки, менеджеров пакетов. Всё это, в принципе, можно было бы исправить. Вот я написал эту статью, чтобы открыть на это глаза тем, кто об этом не знает. У Windows тоже полно недостатков (я разве где-то говорил, что Windows лучше UNIX?). Но в чём-то Windows лучше UNIX (как минимум в некоторых особенностях Powershell). Сейчас я продолжаю использовать и программировать под UNIX. UNIX меня устраивает, мне достаточно удобно, хотя теперь уже я вижу многие его недостатки. Я не призываю бросать UNIX. Используйте UNIX дальше, просто не считайте его идеалом.

Абсолютно согласен. Именно из-за лютого ручного make, адского autotools или чудного cmake на C писать не особо комфортно. Все те же проблемы ассемблера, только теперь кроссплатформенные.
Лично для себя я пишу утилиты на node.js, а для production, учитывая специфику embedded, т.е. когда требуется быстродействие и компактность, пишу на си. И иной раз без подключения стандартной библиотеки. :)
В windows писать для консоли вообще не принято. Из-за чего приходится лепить окошки и тратить время на свистелки. Но окошки там красивее :)

Кто запретил в винде писать для консоли?

Что программирование на «голом UNIX», с использованием C и Shell

В таком случае C рассматривать не стоит. Компилятор является не частью системы, а всего лишь дополнительной программой, которая устанавливается в систему.
А если мы рассматриваем С, то придется и про C++ вспомнить, и про Python, и даже про Fortran c Perl. А кое где в мире ...nix и Object Pascal встречается, и go, да и все "передовое и современное" тоже.


Но ещё и из-за всех этих quirks мейкфайлов, шела, языка C. Отсутствия удобных инструментов, систем сборки, менеджеров пакетов.

Ни разу не пришлось создавать руками make файл. А порой его даже физически на диске не создавалось. Альтернативные среды разработки разной удобности тоже имеются в изобилии от достаточно примитивных (вроде codeblocks), до универсальных (вроде Eсlipse)

Я критикую "подход UNIX". Использование C и мейкфайлов является частью этого подхода. Есть армия фанатов, которая считает, что нужно прогать на C и с мейкфайлами. А всякие IDE — не труъ. Вот их я пытаюсь победить

Не надо никого ПОбеждать. Пишите в IDE, много и хорошо. Своим примером и Убедите.
Вот кстати статейка про лицензирование Windows в тему.
https://habrahabr.ru/post/321708/
Там речь идёт о миллионных суммах. А я поднял несколько корпоративных серверов-гейтов на Ubuntu
в небольших фирмах, у которых миллионов не было в бюджете.
О чём холивар, господа?)
Статью можно не причёсывать, прям так в Microsoft отсылать. Отличное резюме на должность powershell-евангелиста :)
Вопрос приоритета Windoows-Linux может и спорный, но вот судя по минусам с чувством юмора у виндузятников явно не так хорошо как с продажами)
Назовите меня сектантом но никсы — это лучший из костылей который существует.
И еще одна задачка, которую с ходу не решить. В папке все текстовые файлы, и надо их разом переименовать например в 1.txt 2.txt и т.д. В графике Винды — за щелчок, в shell пришлось попотеть.

Да ладно?.. И где вы этот "за щелчок" сделали?

UFO just landed and posted this here
Минута на скрипт.

perl -e '$i=0; for (<*.txt>) { do {$i++} while (-e "${i}.txt"); print `mv $_ ${i}.txt`;}'


Если файлы понадобится отсортировать по оригинальному имени, размеру или времени создания, то потребуется лишь дописать sort {...} перед <*.txt>

А у вас сколько уйдет времени на переименование полусотни файлов?

P.S.: Да, могут возникнуть проблемы с файлами, чье имя разделено пробелами. Решается через добавление кавычек или простенькое регулярное выражение.
Про prename из пакет perl не слышали?
UPD от 2017-02-15: https://habrahabr.ru/post/321652/#comment_10070776.

UPD от 2017-02-15: https://habrahabr.ru/post/321652/#comment_10071096.

Antervis
UPD от 2017-02-15: https://habrahabr.ru/post/321652/#comment_10071714.
UPD от 2017-02-16: понравился этот коммент: https://habrahabr.ru/post/321652/#comment_10066240.

dcc0, immaculate, Sad_Bro, virgin_unix_fan, Denkenmacht, Chelyuk, Dessloch
UPD от 2017-02-16: многие комментаторы рассказывают, как же полезны и удобны UNIX системы. Что они есть уже десятки лет, на них работает весь интернет. Что они стабильны и прекрасно справляются с возложенными на них задачами. И даже удалённо переустановить GNU/Linux можно. :) А я и не спорю. Я не призываю отказываться от UNIX. Я просто хочу, чтобы вы видели недостатки UNIX. UNIX работает, используйте его. Процитирую James Hague, на которого я уже ссылался:

Enough time has passed since the silly days of crazed Linux advocacy that I'm comfortable pointing out the three reasons Unix makes sense:

1. It works.
2. It's reliable.
3. It stays constant.

But don't--do not--ever, make the mistake of those benefits being a reason to use Unix as a basis for your technical or design aesthetic. Yes, there are some textbook cases where pipelining commands together is impressive, but that's a minor point. Yes, having a small tool for a specific job sometimes works, but it just as often doesn't.

Одно время я тоже, как и многие из вас, повёлся на эту «философию UNIX». Думал, что она прекрасна. А потом понял, что это не так. И вот этим своим открытием я хочу с вами поделиться. Мои мысли не новы. Они уже есть в приведённых мною ссылках. Я просто хочу сообщить эти мысли аудитории Хабра. Мой пост написан наскоро, ночью. Читайте скорее не его, а ссылки, которые я привожу. В первую очередь две презентации Пайка, в которых он «отменяет философию UNIX» и два поста от James Hague. Мой пост фактически написан, чтобы привлечь внимание к этим ссылкам.

Как минимум один из комментаторов сказал, что многие из названных мной «недостатков» UNIX недостатками не являются. Например, слишком короткие имена команд. Ну да. Это не недостаток. Но это пример необдуманного решения. Сиюминутного решения, принятого под влиянием обстоятельств, имевших важность тогда. Как и с тем примером с /usr или make. Я показываю, что UNIX была непродумана. Да и вообще, вглядитесь в историю UNIX! Сотрудникам Bell Labs не понравилась сложность проекта Multics. Они сказали: «Да ну этот Multics, давайте по-быстрому напишем свою ОС, запростецкую». И написали. Понимаете? ОС получилась довольно хорошей. Но не идеальной. UNIX — это хак. Успешный хак, который выполнил свою миссию и продолжает её выполнять.

В комментариях была мысль, что заголовок поста не соответствует содержанию, и что я критикую не самую суть, философию UNIX, а просто привожу некий список недостатков. Возможно даже не всего класса UNIX-подобных систем, а конкретных реализаций. Так вот, это не так. Да, статья начинается с перечисления мелких недостатков. Этим я обращаю внимание на то, что в UNIX полно костылей, как и в других системах. В том числе очень старых, оставшихся во всех UNIX системах и попавших во все стандарты. Но я критикую и саму философию UNIX. Основные принципы (но не все!). Язык C, UNIX shell, идею конвееров, «всё есть текст». Замечу, что компилятор C и make, хоть и являются по идее отдельными программами, всегда рассматриваются как неотъемлемая часть экосистемы UNIX. И входят в POSIX. Некоторые комментаторы пишут: «А я сижу в IDE и не использую этот ваш make». Ну окей, хорошо, мой пост предназначен скорее как раз для тех фанатиков, которые считают, что всякие IDE — это не труъ и что программировать нужно непременно используя голый C, make и shell.

И я не говорю, что философия UNIX (даже в тех местах, которые мне не нравятся) всегда не верна. Часто конвееры и shell-скрипты — это именно то, что нужно. Но не всегда.

Некоторые комментаторы указывают, что голый shell, make и прочее часто скрыты от глаз юзера всякими обёртками, всякими IDE, сложными системами сборки, GUI-интерфейсами и пр. Ну да. Так ведь это и есть признак кривости системы. :) Когда что-то уродское покрывают слоем красоты. А ещё абстракции протекают. А потому использовать, скажем, autotools ещё сложнее, чем голый make. Потому что чтобы использовать autotools, нужно знать ещё и m4, make и shell. Да, да, всю эту цепочку языков, используемых при генерации окончательного мейкфайла.

shuron

Один комментатор приводит следующие принципы UNIX:

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.

С первыми двумя я согласен при условии, что они понимаются в отрыве от UNIX shell и конвееров. Их можно перенести даже на новомодные микросервисы, общающиеся с помощью REST. С третьим я не согласен (как я понимаю, подразумевается именно придумываение простого кастомного текстового формата для каждого случая вместо единого формата наподобие JSON). Часто текст — это именно то, что нужно. Но пихать его везде как universal interface глупо. На эту роль скорее претендует JSON или XML. Или, может, какой-нибудь формат для структуированных данных, который ещё не изобрели.

tyderh
Многие указали на искусственность некоторых примеров на shell. Ну да, я знаю, что их можно было бы переписать на find -exec или xargs. Ну что вы хотите, наскоро написанная статья. Можно было привести примеры получше, просто мне не хотелось. Это не отменяет того, что в shell'е постоянно возникают проблемы со специальными символами. Которые нужно по-особому обходить. И вообще у shell'а полно quirks, которые нужно постоянно держать в голове. И он запускает новые программы на каждый чих.

Я вам ещё покушать принёс. Вот вам цитата от безусловно ещё одного вашего кумира Линуса Торвальдса:

iTWire: Systemd seems to depart to a large extent from the original idea of simplicity that was a hallmark of UNIX systems. Would you agree? And is this a good or a bad thing?

Linus Torvalds: So I think many of the «original ideals» of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.

There's still value in understanding the traditional UNIX «do one thing and do it well» model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.

It might describe some particular case, though, and I do think it's a useful teaching tool. People obviously still do those traditional pipelines of processes and file descriptors that UNIX is perhaps associated with, but there's a *lot* of cases where you have big complex unified systems.

And systemd is in no way the piece that breaks with old UNIX legacy. Graphical applications seldom worked that way (there are certainly _echoes_ of it in things like «LyX», but I think it's the exception rather than the rule), and then there's obviously the traditional counter-example of GNU emacs, where it really was not about the «simple UNIX model», but a whole new big infrastructure thing. Like systemd.

Now, I'm still old-fashioned enough that I like my log-files in text, not binary, so I think sometimes systemd hasn't necessarily had the best of taste, but hey, details…
И он запускает новые программы на каждый чих.

Нет, не на каждый. man builtins. Например, даже в том идиотском примере никаких сотен процессов touch все равно не будет — touch как раз одна из этих встроенных функций.
Это не отменяет того, что в shell'е постоянно возникают проблемы со специальными символами.

Какими-же?
UFO just landed and posted this here
Можно ли считать builtins отхождением от юникс-вея, кстати? Ну, что каждая программа делает одну задачу и делает её хорошо.


builtins — хорошая и красивая оптимизация медленного места. Можете считать отхождением, разрешаю. Однако, задача у баша не «существовать согласно юниксвею и KISS», а «делать свои дела и делать их хорошо и быстро»

?!?!?! Эээ, а слабо самому почитать тот ман, на который вы ссылаетесь? touch — не builtin баша. Как минимум потому, что его нет упомянутом man builtins. Во всяком случае в моей версии баша (4.4-2 из дебиана).


А про специальные символы уже рассказано подробно в моей статье. Про эти 5 хаков, которые нужно запихнуть в цикл, чтобы он работал нормально со специальными символами. См. также UPD от 2017-02-18

Оскорбить не хочу тоном своим, но все-таки не удержусь.

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

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

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

Мне, как не сильно умудренному пользователю линукса нравится в нем то, что он создавался программистами для программистов. Пакетный менеджер, централизованность утилит и библиотек в системе, update-alternatives. А даже если что-то где-то вдруг не так, всегда есть возможность подправить какой-нибудь конфиг и исправить. В винде, по моему опыту, любая нетривиальная задача настройки системы уводит в дикие дебри гугла, реестра и никогда не факт, что всё отработает.

А всё то о чем вы говорите мне, как пользователю, безразлично. Более того, найдутся аргументы в пользу раскритикованных вами решений (их тут зачитайся).
Собственно, bash слабей не только PHP, но даже и Бейсика из ПЗУ ZX Spectrum образца 1982 года.

Вот всего лишь три факта: 1) Бейсик работает с трёхмерными массивами, bash — только с одномерными. 2) Бейсик умеет вещественную математику (причём до 14 знаков после запятой), bash (сам, без посторонних утилит) только целочисленную. 3) Бейсик в ПЗУ Spectrum занимает 16K. du -sh /bin/bash на CentOS 6.8 даёт нам 888K.
Теплое с мягким сравниваете, товарищ, надеюсь, вы не серьёзно.

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

У каждого языка есть свои цели, задачи, для которых он сделан и подходит. Баш, например, не создан без работы без посторонних утилит, наоборот, он — исскуство их композиции, позволяющее максимально эффективно переиспользовать уже написанный код.
Я работал во многих ОС и в каждой был свой «bash». Их вполне можно сравнивать, никакого искусства в запуске сторонних утилит нет и быть не может. Задача всех этих (макро)языков от 80-х и по сей день — автоматизация связи между приложениями. Когда мы говорим о такой связи, речь идёт об управлении потоками данных, для чего разумеется нужны: 1) простой, развитый и однозначный ЯП; 2) универсальные, развитые способы связывания любых приложений с любыми приложениями; Строго говоря для Windows и Linux макроязыков отвечающих обоим целям вообще не существует, что обусловлено архитектурно, исторически сложилось и т.д. Вместо этого используется каша из инструментов появлявшихся на разных этапах эволюции *nix. Что тоже ни для кого не является секретом. Поэтому я надеялся что сравнение с Basic, типично использовавшимся в качестве встроенного макроязыка для домашних микрокомпьютерах Вас позабавит. Оно полностью оправдано и отвечает тем же целям.

Знаете, что я ещё скажу? Веб, node.js и javascript — это шаг назад.


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


В десктоп приложениях такой проблемы нет.


Не надо все приложения переносить в веб. Веб — для публикации инфы. :) Просто разрабатывать приложения в вебе дешевле и эффективнее с точки зрения бизнеса, чем для десктопа, вот всё и пихают в веб.


А на деле получаем, что эти веб приложения тормознутее, меньше интегрированы с ОС.


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


Почитайте историю node.js. Какие-то чуваки оказались в нужное время в нужном месте. Скрестили ежа с ужом. Сделали кашу из топора. Взяли libuv (ну или сами его написали, но это не так уж и много работы), добавили V8 и готово. Т. е. тупо взяли несколько технологий и соединили и готово. Типичный стартаперский подход. Написали, раскрутили, хайп, все дела. Proof of concept (PoC). И на этом PoC так и живём. Вместо нормальных продуманных технологий. Они просто перечеркнули многолетнюю историю действительно продуманных языков программирования и фреймворков, а их полно. Perl, python, haskell. И вместо этого пишем как можно быстрее как можно больше быдлокода и побыстрее сразу выкладываем в продакшн или в npm.


Я выговорился. Написал сюда. Решил новую статью не писать :)

И когда я в одной вкладке удалил письмо, в другой вкладке оно всё ещё видно во входящих.

В десктоп приложениях такой проблемы нет.

Да ладно? Тут на ru.SO регулярно появляются вопросы "я заполнил переменную на форме 1 — а на форме 2 она пустая ПОЧЕМУ?". Не уметь программировать можно на любом языке программирования :)


А javascript и node.js, в том числе, сформулированную вами проблему решают. "Шагом назад" оказался только веб, а javascript и node.js — это шаг обратно вперед.

Не уметь программировать можно на любом языке программирования :)

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

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

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

там многие вещи делаются проще

Какие, если не секрет?

Главное преимущество веба с моей точки зрения — это система дистрибуции, которая не требует установки чего-либо на компьютер клиента. Ну и социалочки в свое время здорово подстегнули эту любовь.

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

UFO just landed and posted this here

Меняем "width:100px" на "flex: 1 1 100px" и о чудо.

Работа с текстом — да, возможности из коробки, это плюс, который можно упоминать дважды для весомости) Остальное же…
Лейауты, подстраивающиеся под размеры содержимого.

Сейчас где-то иначе? Сто лет назад был WPF, JavaFX, Qt, даже Android SDK умеет в это.
Кроссплатформенность.

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

Это тоже не уникальная возможность.
Крутейший отладочный инструментарий.

Чем же он крут? Бэкендная отладка мало, чем отличается от десктопного аналога, а отлаживание фронта — это боль. Если код еще и транслируется из другого языка, то боль в квадрате. Вы, конечно, об инструментарии, но разве он делает этот процесс приятнее?
> Веб, node.js и javascript — это шаг назад.

поддерживаю, по каким-то печальным причинам самые кривые, плохо спроектированные технологии становятся популярными — js, php, node.js. А реально крутые технологии вроде Python и Haskell отстают или вообще неизвестны, почему в браузера используется не нормально спроектированный язык вроде питона, а что-то странное что создавалось для выведения alert окошка?

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

Может потому, что у JS с самого рождения было всё хорошо с юникодом в отличие от "крутых, правильно спроектированных языков"?

Всё может быть, но поддержка юникода это вроде не того уровня проблема, да и в php как понимаю не было юникода от рождения
UFO just landed and posted this here

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

UFO just landed and posted this here
'E̋'.length // 2 OLOLO

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

UFO just landed and posted this here

То есть вы считаете нормальным, что конкатенация двух односимвольных строк даст не двухсимвольную строку, а односимвольную, и разделить её обратно на две односимвольные уже не получится?


( "E"+"̋" ).length
UFO just landed and posted this here

Значит я ненормальный, раз для меня это выглядит противоестественным. Всё же length на мой взгляд должен выдавать число кодовых точек. То, что комбинация нескольких точек даёт на экране один символ, а некоторые — ни одного, — это особенности отображения. Учитывать их тоже иногда полезно, поэтому тут лучше было бы ввести отдельный метод "countOfVisibleCharacters".


Но касательно вашего примера, да, суррогатная пара фактически кодирует одну кодовую точку, но большинство реализаций JS хранит строки внутри в UCS2 кодировке, игнорирующую такие пары. Однако спецификация JS не ограничивает от использования UCS4 или UTF* кодировок.

UFO just landed and posted this here
UFO just landed and posted this here

Ну да, в этом-то и всё дело. Javascript — это просто язык для скриптинга браузера. А не новый язык, который щас убьёт все остальные

Вот с чего начинался этот тред. Когда язык считает, что строка «Ö» — длины два, это значит у языка с юникодом все плохо, потому что это противоречит правилам работы с юникодом, предписываемым консорциумом.

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

. vintage, am-amotion-city, mayorovp
Давайте я что ли выскажусь по поводу этого вашего юникода.


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


  • Один видимый символ может состоять из нескольких кодовых позиций (например, какая-нибудь буква с диактическим знаком [она видна как один символ] может кодироваться двумя кодовыми позициями)
  • Ну а одна кодовая позиция, в свою очередь, может кодироваться (если речь идёт о кодировке UTF-16) суррогатной парой, т. е. кодироваться двумя парами байт, а не одной парой байт, как это происходит с наиболее ходовыми кодовыми позициями юникода в кодировке UTF-16

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


Второе обстоятельство имеет в себе исключительно исторические причины. И оно проявляется лишь при работе с UTF-16. Было бы здорово, если бы люди сразу придумали UTF-16, без предварительного придумывания UCS-2 (ну а лучше, чтобы вообще никогда не придумывали ни UTF-16, ни UCS-2, а использовали лишь UTF-8). Тогда проблемы под названием "одни программы не поддерживают суррогатные пары, а другие поддерживают" не было бы.


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


Так вот, любой язык, декларирующий возможность работы с юникодом (в том числе UTF-16), должен уметь:


  1. Считать число видимых символов в строке
  2. Считать число кодовых позиций в строке
  3. Считать число байт в строке

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


Какую именно из этих операций нужно назвать length — это вопрос вкуса. Суть в том, что все эти операции язык должен уметь. И документация должна предупреждать о том, какой length что делает. Она должна предупреждать, что, скажем, "вот это length возвращает число видимых символов, а потому конкатенация двух строк с length один может дать строку с length один"


. vintage


Может потому, что у JS с самого рождения было всё хорошо с юникодом в отличие от "крутых, правильно спроектированных языков"?

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


. mayorovp


не-юникодовые строк в языке быть не должно

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

UFO just landed and posted this here

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


А реально от поддержки юникода требуется следующее:


  1. возможность создавать юникодовые строковые литералы;
  2. возможность вводить юникодовые строки при помощи стандартных средств;
  3. возможность выводить юникодовые строки при помощи стандартных средств;
  4. базовые операции над строками должны сохранять их корректными;
  5. не-юникодовые строк в языке быть не должно.
tyderh,ookami_kb, cjbars, dion, maydjin

UPD от 2017-02-18: ещё по поводу надуманных примеров на shell. Вы говорите, примеры надуманные, что можно сделать find -exec или xargs. Да, можно. Но как минимум сам факт того, что нужно постоянно держать в голове, что, мол, цикл нельзя и нужен -exec и xargs — это уже костыль. Проистекающий из принципа «всё есть текст», ну или из слишком тупой реализации этого принципа в UNIX shell.

Итак, сейчас я приведу такую задачу, в которой любое решение будет уродским, даже с использованием find -exec и xargs.

Вернёмся к моему примеру с touch'ем. «Как touch'нуть все файлы в папке foo (и во вложенных)?» Допустим, что нужно не touch'нуть их, а grep'нуть из них все строки со словом bar и положить результат туда же. Т. е. для каждого файла file сделать grep bar file > tmp; mv tmp file. Как быть? Если делать решение с циклом, то мы упираемся в те пять хаков, которые нужно сделать, чтобы не выстрелить себе в ногу. Результат будет таким, со всеми пятью хаками:
find foo -print0 | while IFS="" read -rd "" A; do
	grep -- bar "$A" > tmp
	mv -- tmp "$A"
done


Ладно, хорошо, мы знаем, что имя файла начинается на foo, а потому не может начинаться с дефиса и пробела. Но оно может заканчиваться на пробел, а потому тот трюк с IFS всё равно нужен. Так что единственный хак, от которого можно избавиться, зная, что имя начинается с foo — это написание --. Но даже от этого хака я бы не советовал избавляться, т. к. постоянное использование -- даёт понять читающему: «Да, я подумал об этом». Это как условия Йоды.

Окей, можно ли этот пример написать проще с использованием xargs или find -exec? Если бы каждый файл нужно было всего лишь touch'нуть, то да, можно было бы написать существенно проще. Но если нужно выполнить два действия: grep и переименование, то существенного упрощения мы уже не получим. Два действия означают, что нам уже нужно запихивать эти два действия в вызов shell'а, в sh -c. Как будет выглядеть результат? Может быть, так?
find foo -exec sh -c "grep -- bar '{}' > tmp; mv -- tmp '{}'" ';'


Нет, неправильно! Это не будет работать, если имя содержит одинарную кавычку. Правильный вариант таков:
find foo -exec sh -c 'grep -- bar "$1" > tmp; mv -- tmp "$1"' dummy '{}' ';'


Видите? Опять хак. Нам пришлось передать имя файла через $1. И по-прежнему нужно помнить, что нам нужны двойные кавычки вокруг $1. То же самое было бы с xargs. Опять нужен sh -c и опять нужно передавать аргументы через $1.

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

Теперь по поводу другого примера. Где нужно удалить все файлы определённого размера. Да, всё это можно сделать одним вызовом find. Там есть опции и для проверки размера, и для удаления. Да. Вот только я вижу здесь хак. Хак в том, что find имеет фактически в себе целый sublanguage, подъязык. Язык вот этих вот опций. Почитайте хорошенько ман find'а. Вы узнаете, что, оказывается, порядок опций find'а имеет значение. Что каждая опция имеет truth value, т. е. булевское значение. Что можно по-хитрому комбинировать эти опции. Что в зависимости от порядка опции, от их truth value find принимает решение, в какой момент нужно остановить обработку опций для данного файла и нужно ли descend в данный каталог (т. е. нужно ли искать внутри этого этого каталога).

Я помню, как однажды жутко оплошался, не зная этих тонкостей. Я набрал find -delete -name '*~' вместо find -name '*~' -delete или что-то такое. Ну подумаешь, думал я, опции не в том порядке. Смысл же тот же. И find удалил всё. И снёс свои важные файлы. Потом восстановил из бекапа, так что всё ок. Это потом уже я понял, что -name имеет truth value true в случае, если файл соответствует маске. И если -name вернул true, то обработка опций продолжается.

Что тут плохого? Плохо то, что find имеет свой sublanguage. Что это ещё один язык в дополнение к shell. (А sed, кстати говоря — это ещё один язык, а awk — это ещё один язык и так далее, авторы UNIX'а любили создавать по языку на каждый чих.) Нужно было вместо этого сделать так, чтобы find только умел искать файлы. А всю остальную функциональность нужно вынести из него. Проверки на размер файла должны быть снаружи. А если find'у нужно принять решение, нужно ли descend в данный каталог, то он должен вызывать внешний callback. Да, в UNIX shell так вряд ли получится. На то он и UNIX shell.
Если вы мне расскажете кейс при котором надо дописать в файл строку уже содержащуюся в нем, тогда я начну думать о решении. А пока выгладит опять как выдумывание способов поставить систему раком используя странную задачу.
Речь шла (как видно из кода) о замене файла на строки в нём, которые содержат bar. А не о дописывании этих строки
Я просто еще раз попрошу вас написать зачем нужно прроизводить замену файлов по их содержимому?
Я просто пытаюсь понять какую задачу вы решаете, реальную или синтетическую.

Синтетическую. :) Но подобные задачи возникали в реале, могу поискать в реальном коде, надо?

Да, это было бы очень интересно. Если вам не сложно.
Идеально было бы увидеть кусок кода, и цель, которую решает данный код.

Вам именно пример, где нужно сделать find, и для каждого результата find'а выполнить больше одного действия?


Или пример на любую другую особенность shell, обозначенную в моей статье, не обязательно именно ту с find'ом и sh -c?

Ну допустим вам нужно над найденным файлом сделать несколько действий.
Тоесть не просто выполнить какое-то действие над файлом, а именно несколько действий.
Что такое последовательность действий? Правильно! Последовательность действий есть скрипт.

Таким образом пишите скрипт для выполнения последовательности действий, и вызываете этот скрипт для каждого найденного файла.
#!/bin/bash
# script.sh
filename="$1"
echo "Действие 1 над файлом $1"
echo "Действие 2 над файлом $1"


find . -type f -exec ./script.sh {} \;


Вполне себе переваривает «кривые» названия файлов. В чем крах и костылизм?
сорри косякнул со скриптом, но сути это не меняет
#!/bin/bash
# script.sh
filename="$1"
echo "Действие 1 над файлом ${filename}"
echo "Действие 2 над файлом ${filename}"

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


Вообще, скажу ещё раз. Выполнение нескольких действий с файлом можно сделать разными способами. Цикл, -exec sh -c, xargs sh -c, отдельный скрипт. Суть в том, что самый лобовой спобов даёт сбой, нужно держать в голове разные особенности. И так в shell везде.


К shell применимы те же аргументы, которые приводят обычно против PHP. Мол, костыль на костыле, нужно всё время помнить то, помнить это, и всё это без всякой логики, везде кривость дизайна. И с shell то же самое. Ладно, окей, shell не до такой степени плох. Просто я пытаюсь в своей статье разубедить тех, кто считает, что якобы shell прекрасен. Я и сам так думал до определённого момента. Я чётко помню свою недавнюю реплику (несколько лет назад) в канал #linux на руснете: "sh прекрасен и отражает суть unix. Единственные проблемы sh в неинтуитивных названиях закрывающих ключевых слов (if — fi, for — done) и в том, что в POSIX sh не хватает фич bash"

UPD от 2017-02-18: ещё по поводу надуманных примеров на shell. Вы говорите, примеры надуманные, что можно сделать find -exec или xargs. Да, можно. Но как минимум сам факт того, что нужно постоянно держать в голове, что, мол, цикл нельзя и нужен -exec и xargs — это уже костыль. Проистекающий из принципа «всё есть текст», ну или из слишком тупой реализации этого принципа в UNIX shell.

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


  • Почему-то в списках aka std::list (или LinkedList) доступ по индексу не сильно быстрый, а в vector добавление "тормозит"
  • В C++ нельзя кидать исключение из деструктора
  • В Objective C нельзя nil засунуть в NSArray
  • В Java hashCode и equals зачем-то бывает нужно переопределять. Да еще и как попало написать нельзя.

Я не спорю, что можно придумать задачу, которая тяжело решается используя unix shell. Особенно в интерактивном режиме (в смысле из интерактивного шелла). При чем более приближенных к реальности, чем 'положить в файл результат grep-а по нему же'. И да, таких задач очень много. Вы предложили изначально задачу с touch-ем, я показал решение в 1 элементарную строчку. shell идеально подошел для её решения.


Если задача становится слишком сложной для shell, то я просто возьму python/perl или что-нибудь еще. Вплоть до того что буду прям из кода на python вызывать command-line утилиты используя subprocess.check_output, если так проще/быстрей.


Я помню, как однажды жутко оплошался, не зная этих тонкостей. Я набрал find -delete -name '*~' вместо find -name '*~' -delete или что-то такое. Ну подумаешь, думал я, опции не в том порядке. Смысл же тот же. И find удалил всё. И снёс свои важные файлы.

А если кто-то случайно сделает cp old_file new_file вместо cp new_file old_file и начнет писать "подумаешь, опции не в том порядке", то виноват тоже будет shell? А если я, наконец, нож возьму не той стороной и вместо того чтобы колбасу отрезать, руку порежу?


Нужно было вместо этого сделать так, чтобы find только умел искать файлы. А всю остальную функциональность нужно вынести из него. Проверки на размер файла должны быть снаружи.

Эээ. А -type тоже оттуда уберем? И вообще, вас кто-то заставляет пользоваться "встроенной" проверкой на размер? Проверяйте снаружи, если так удобнее. Только для простых случаев кода так будет больше заметно. В этом же и всё удобство шелла, что часть задач легко решается в одну строку вроде find ~/tmp -mtime +5 -delete практически не задумываясь.


Чем вы предлагаете shell заменить? perl/python? Покажите решение с удалением всех файлов определенного размера и сравните количество кода.

Почему-то в списках aka std::list (или LinkedList) доступ по индексу не сильно быстрый, а в vector добавление "тормозит"

Это объяснимо


В C++ нельзя кидать исключение из деструктора

Это тоже объяснимо. Да, можно придумать язык, в котором исключения из деструктора кидать можно, но это уже нетривиально. Так что здесь действительно it's for design.


В Objective C нельзя nil засунуть в NSArray
В Java hashCode и equals зачем-то бывает нужно переопределять. Да еще и как попало написать нельзя.

Не знаю Objective C и Java.


В первых двух примерах речь идёт о вполне объяснимых, оправданных вещах. Чего нельзя сказать о моих претензиях к shell. У shell'а тупо недостатки, вызванные кривостью дизайна. Их могло бы не быть, но они есть.


Эээ. А -type тоже оттуда уберем?

Да. :) Потому что в shell уже есть свои методы проверки типа инода (test -f и прочие). А find дублирует эту функциональность. Во всяком случае так нужно сделать в некоей идеальной гипотетической замене shell'а.


Вообще, я не предлагаю исправить shell. Я просто объясняю, что можно теоретически представить себе нечто лучшее. Ну как у того ветерана программирования, "If you put it [UNIX] up on a pedestal as a thing of beauty, you lose all hope of breaking away from a sadly outdated programmer aesthetic". А в shell'е в его текущем виде, конечно, все эти -type у find'а сидят на месте.


Чем вы предлагаете shell заменить? perl/python? Покажите решение с удалением всех файлов определенного размера и сравните количество кода.

Нужно заменить на некий полноценный скриптовый язык (например, perl или python) и добавить в этот язык некие средства для быстрого выполнения типичных shell'овых задач, например, запуск команд и пайпов. В языки программирования же добавляют средства для удобного исполнения SQL-запросов? Чтоб невозможно было случайно не заэскейпить SQL-запрос и получить SQL-инъекцию? Вот точно так же нужно в perl или python добавить специальные средства для удобного запуска команд, пайпов и прочего. Чтобы shell был вообще не нужен.


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

А если кто-то случайно сделает cp old_file new_file вместо cp new_file old_file и начнет писать "подумаешь, опции не в том порядке", то виноват тоже будет shell?

Этот пример некорректен. Опции без дефиса в начале не зря называются позиционными. Опции с дефисом таковыми не являются (во всяком случае, это такое соглашение, которого придерживаются практически все программы. Можно конечно плевать на эти соглашения, что find и делает, но глупо при этом возмущаться тем, что кто-то считает это неочевидным поведением. Оно таковым и является).

info sed | grep 'delete'

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


Я не считаю себя большим специалистом по unix[-like] shell однако, большинство практических задач находят достаточно простое и изящное решение даже в моих неумелых руках. Особенно при анализе слабо структурированных данных.


Сама концепция всё есть текст не идеальна, но, хороша для своего класса задач: выборка по неструктурированным/слабо структурированным данным. Для итерации по более структурированным данным, несомненно нужны более точные инструменты, для fs таким является find.


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


авторы UNIX'а любили создавать по языку на каждый чих

Собственно суть unix-way, dsl/утилита для каждой отдельной задачи, иначе, всё можно было бы на перфокартах до сих пор в пакетном режиме шедулить:)


Кстати, для примера, есть ещё концепция всё есть запись в БД, используемая в systemi. И она накладывает определённый уровень ограничений — например максимальная вложенность файловой системы есть 3, так же как и даёт определённый ряд преимуществ.

О, спасибо. Согласен с идеей. Между прочим, в Linux видимо перетащили /proc из Plan 9. Так что даже в Plan 9 ошиблись

UPD от 2017-08-01.

echo вроде как предназначен, чтобы печатать на экран строки. Вот только использовать его для этой цели, если строчка чуть сложнее, чем «Hello, world!», нельзя.

И даже для этой цели echo использовать можно не всегда. Недавно прочитал, что в интерактивном старом bash нельзя писать echo "Hello, world!". Вот несколько абзацев текста, объясняющих суть проблемы и пути обхода. В новых bash такого нет, на моей системе не воспроизводится.
UPD от 2018-05-31. Возвращаясь к тем пяти хакам. Сейчас вдруг дошло, что есть ещё один хак: имя файла может быть ⟦-⟧, этот случай нужно учитывать отдельно. К счастью, в примерах выше это не проявляется, т. к. путь всё равно начинается с foo

Articles