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

basilbasilbasil 12 фев 2017 в 15:21

это ж сарказм, замешанный на философии UNIX

ximaera 12 фев 2017 в 22:57

Зашел в профиль посмотреть другие посты автора. Опа!

NotSure 13 фев 2017 в 13:29

И?

dipsy 12 фев 2017 в 07:19

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

S_A 12 фев 2017 в 08:33

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

NeoCode 12 фев 2017 в 11:09

Проблема в том что для системного программирования кроме С и С++ пока к сожалению ничего нет (ну вот появился Rust но он еще мало распространен… да и с синтаксисом некоторые вопросы к интуитивности, в тех же же C# или Java все гораздо более понятно, причем сходу, без необходимости погружаться в нюансы языка).

dipsy 12 фев 2017 в 18:58

Ну так большая разница же, с и с++, я про что и пытался сказать. С++ рулит, в отличие от.

safinaskar 12 фев 2017 в 21:29

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

Antervis 13 фев 2017 в 05:19

Настоящая причина использовать Си вместо С++ в 90% случаев куда тривиальнее: отсутствие компилятора С++ для конкретного устройства. Никто же не заставляет использовать все эти «монструозные» вещи типа буста, можно даже писать большую часть кода на общем подмножестве.

dipsy 13 фев 2017 в 12:43

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

safinaskar 14 фев 2017 в 01:22

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

Antervis 14 фев 2017 в 06:18

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

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

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

напомнило

saterenko 13 фев 2017 в 10:49

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

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

НЛО прилетело и опубликовало эту надпись здесь

MacIn 14 фев 2017 в 18:27

BF вообще замечательный, его лаконичность потрясает. А если вам не нравится, то вы просто школотроны, единственно на что способные — кнопки по формам расставлять. Fixed for ya.

saterenko 14 фев 2017 в 21:04

Именно! Все языки по-своему прекрасны и у каждого найдутся приверженцы.

kekekeks 12 фев 2017 в 13:07

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

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

dipsy 12 фев 2017 в 19:06

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

kekekeks 12 фев 2017 в 19:28

4ГБ

У нас 32КБ

НЛО прилетело и опубликовало эту надпись здесь

kekekeks 13 фев 2017 в 01:16

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

neit_kas 13 фев 2017 в 04:17

А вы вкурсе, что есть ОС (стоит отметить, *nix ОС) под всякие встраиваемые системы и МК? Там такая память только в очень сладких снах может сниться.

dipsy 13 фев 2017 в 11:32

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

kekekeks 13 фев 2017 в 14:11

можно взять запас до 64 КБ

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

billyevans 13 фев 2017 в 02:51

Так не нужно использовать std от C++. Это чудовищное поделие. Там из полезного только exceptions, но я думаю их как-нить можно вынуть оттуда, не таща с собой весь остальной хлам.
А сам С++ с RAII и остальным весьма крут, хотя сильно больше нюансов, чем в голом С.

dipsy 13 фев 2017 в 12:37

<сарказм>
Не оскорбляйте святое. Люди привыкли писать на голом С, это развивает внимательность, аккуратность. Сделал, как говорится, fopen, не забудь про fclose, да и код получается длинный, солидный. А все эти ваши гейские RAII — не нужны и не влазят в 8 кБ памяти, особенно если boost весь ещё заинклюдить.
</сарказм>

Antervis 13 фев 2017 в 19:06

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

billyevans 13 фев 2017 в 19:19

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

poxvuibr 14 фев 2017 в 01:00

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

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

On their face, the benefits of using exceptions outweigh the costs, especially in new projects.

Antervis 14 фев 2017 в 06:20

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

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

mayorovp 14 фев 2017 в 08:51

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

khim 16 фев 2017 в 22:42

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

Вот тут подробнее.

billyevans 14 фев 2017 в 11:23

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

Siemargl 14 фев 2017 в 13:35

В нынешний век интерпретаторов и П-кода это не то чтобы просадка, это погрешность измерений =)

Там расходы были — пяток лишних ассемблерных инструкций.

MacIn 14 фев 2017 в 18:06

Нет, ну overhead есть даже если нет исключений. Скажем, в Windows надо для каждого try, в том числе скрытого, создать элемент SEH, а в конце — удалить его. Да, это мизер.

Antervis 13 фев 2017 в 05:22

-static-libstdc++ не отрабатывает?

Tujh 13 фев 2017 в 07:41

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

Давно, если честно, не смотрел, но были же проекты uclibc++ и подобные, все умерли?

Hellsy22 12 фев 2017 в 07:33

И эти файлы надо заново читать и заново парсить при каждом вызове ls -l! Было бы гораздо лучше использовать бинарный формат. Или БД. Или некий аналог реестра. Как минимум для вот таких вот критичных для производительности ОС файлов.

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

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

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

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

Lsh 12 фев 2017 в 12:14

Собственно, какая вам разница, будет ли конец строки обозначать символ \0 или символ \n?

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

poxvuibr 15 фев 2017 в 16:25

Скорее, в случае с БД, она ничем заканчиваться не будет, будет указан её размер.

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

fshp 20 фев 2017 в 17:06

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

rPman 12 фев 2017 в 12:22

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

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 12 фев 2017 в 22:02

https://habrahabr.ru/post/321652/#comment_10066432

safinaskar 12 фев 2017 в 21:41

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

xtotec 12 фев 2017 в 21:45

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

НЛО прилетело и опубликовало эту надпись здесь

Jef239 12 фев 2017 в 23:41

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

xtotec 13 фев 2017 в 00:01

Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно. До этого — сколько угодно.
Тем не менее — если регистр повреждён (да даже действиями пользователя) до степени незагужаемости системы, это требует специфических инструментов для ремонта, в отличии от текстовых конфигов.
С точки зрения производительности системы, можно хранить в памяти результат чтения текстовых конфигов и обращаться к нему (рано или поздно вся эта концепция systemd к такому и приведёт).

tmnhy 13 фев 2017 в 00:28

Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно.

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

НЛО прилетело и опубликовало эту надпись здесь

tmnhy 13 фев 2017 в 01:37

На каком?

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

aikixd 13 фев 2017 в 16:18

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

tmnhy 13 фев 2017 в 16:29

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

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

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

MacIn 13 фев 2017 в 16:45

Это ооооооочень пространное указание точки времени. Там мягко говоря много всего в этот момент происходит.

tmnhy 13 фев 2017 в 16:54

Суть то одна, пропадание питания в этот момент и как результат битый software.

stickerov 15 фев 2017 в 18:40

В чём проблема воспользоваться резервной копией? По-умолчанию в винде включены опции по созданию точек восстановления и копий реестра…

НЛО прилетело и опубликовало эту надпись здесь

xtotec 13 фев 2017 в 01:05

Ну как зачем — процесс сверки обнаруженных устройств с существующими с last known good, например, или ещё какое-нибудь вуду. Регистр — он не для пользователя, по большому счёту, точнее у пользователя есть свой кусочек, в профиле, куда и начнут писАть, после того как он залогинится.
Я уже было решился спросить у человека какие именно технические детали позволяют ему с таким апломбом утверждать о самовосстановлении регистра (а вдруг?), а тут вы пришли и… разрушили мою веру в светлое бинарное завтра юникс-систем.

НЛО прилетело и опубликовало эту надпись здесь

neit_kas 13 фев 2017 в 04:24

BCD хранит свои конфиги в кусте реестра. Хотя правда не в курсе, он только читает или ещё и пишет?

НЛО прилетело и опубликовало эту надпись здесь

xtotec 13 фев 2017 в 01:08

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

НЛО прилетело и опубликовало эту надпись здесь

vintage 13 фев 2017 в 09:17

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

vorphalack 13 фев 2017 в 11:40

на NTFS оно точно также в капусту билось, но как правило очень невоспроизводимо. какой-нить race condition при записи в глубине дискового стека, совпадающий с зависанием/вырубанием системы.

MacIn 13 фев 2017 в 16:47

Аналогично. Сколько ни отрубай «жестко». Ни на XP, ни на 2к.

TrurlMcByte 20 фев 2017 в 19:31

А зачем там регулярка, там же фиксированный набор полей? Тот же GAWK в таких случаях (простые текстовые файлы с фиксированным набором полей) вообще рвет всех. Причем даже на гигабайтных простынях данных.

Hellsy22 12 фев 2017 в 07:54

Про существование зомби-процессов все говорят: «It's for design».

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

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

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

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

tgz 12 фев 2017 в 10:39

А если родитель еще нужен?

tmnhy 12 фев 2017 в 11:04

Если есть зомби, то с родителем не всё в порядке, т.е. он уже не нужен.

tgz 12 фев 2017 в 11:30

А если там критичные данные? Например ваша зарплата за год.

tmnhy 12 фев 2017 в 11:33

Вы сейчас о чём говорите, какие критичные данные, какая зп?

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

tgz 12 фев 2017 в 11:46

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

masai 12 фев 2017 в 15:04

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

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

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

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

kmu1990 12 фев 2017 в 15:07

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

masai 12 фев 2017 в 15:20

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

kmu1990 12 фев 2017 в 15:32

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

masai 12 фев 2017 в 15:48

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

tmnhy 12 фев 2017 в 15:20

Sic!

masai 12 фев 2017 в 15:23

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

tmnhy 12 фев 2017 в 15:35

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

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

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

masai 12 фев 2017 в 15:49

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

tgz 12 фев 2017 в 16:25

А если у родителя просто нужный тред заблокировался на IO, а все остальное хорошо и в порядке?

tgz 12 фев 2017 в 16:12

Просто хипстеры не умеют так:

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





И зомби умер. Без убивания папы.

НЛО прилетело и опубликовало эту надпись здесь

ximaera 12 фев 2017 в 22:51

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

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

tgz 12 фев 2017 в 23:23

Следуя этой логике можно сделать rm -rf /, а объяснить все тем, что мог ведь и контроллер сдохнуть. В маразм не впадайте. Ваша зарплата зависит от ваших действий, а не от того что лежит в памяти конкретного сервера.

ximaera 12 фев 2017 в 23:28

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

tgz 13 фев 2017 в 09:00

Маразм все же побеждает. Перечитайте изначальный пост, вопрос был не про зарплату. По существу есть что сказать?

Nordicx86 13 фев 2017 в 08:03

да что вы обычная черная бухгалтерия… все на RAM диске и бекап в крипте в облако в Зимбабве…

kmu1990 12 фев 2017 в 11:55

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

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

tgz 12 фев 2017 в 12:01

Как вставить 1 строчку кода в уже запущенный бинарник?

kmu1990 12 фев 2017 в 12:10

Если процесс не собирает своих детей, то значит они ему нужны и значит Zombie процессы должны быть, либо это просто недосмотр со стороны программиста(ов), который написали программу. Странно винить Unix за недосмотр программистов.

tgz 12 фев 2017 в 15:43

Где я винил unix?

kmu1990 12 фев 2017 в 15:45

Ок нигде. Тогда что к обсуждению должен был добавить ваш вопрос про то, как вставить 1 строчку кода в уже запущенный бинарник?

tgz 12 фев 2017 в 16:18

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

kmu1990 12 фев 2017 в 16:22

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

tgz 12 фев 2017 в 16:31

А если зомби не нужен?
Вот прямо сейчас на ноуте:

20157 ? Ssl 0:09 gvim

20163 ? Z 0:00 \_ [python3] 

Зомби мне не нужен, а vim содержит несохраненные данные.

kmu1990 12 фев 2017 в 16:33

Операционная система не знает ничего о логике приложения, она просто не может узнать, что zombie больше не нужен. Zombie будет удален тогда, когда гарантированно известно, что он не нужен и не раньше.

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

tgz 12 фев 2017 в 17:11

Ну так кроме ОС у нас еще есть админ. А у админа есть некоторые инструменты.

kmu1990 12 фев 2017 в 17:18

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

tgz 12 фев 2017 в 17:59

kill -9 потенциально небезопасен, но ОС же позволяет это делать, не так ли?

kmu1990 12 фев 2017 в 18:10

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

tgz 12 фев 2017 в 22:42

Средство есть, только это совсем не kill -9 для папы.

kmu1990 13 фев 2017 в 00:09

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

tgz 13 фев 2017 в 09:29

А с чего это должно быть написано в стандарте? У вас есть стандарт как ложку ко рту подносить? Нет? А кушаете как?
kill -9 ppid в посиксе описан?

kmu1990 13 фев 2017 в 10:24

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

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

tgz 13 фев 2017 в 10:32

У меня? Бурная реакция? Мы точно один сайт сейчас читаем? Драму какую-то нашли.
И в словарик загляните на букву С, что бы понимать что такое стандарт.

kmu1990 13 фев 2017 в 10:36

То есть не можете. Спасибо за время потраченое зря время.

tgz 13 фев 2017 в 12:14

Не хочу.

eagr 15 фев 2017 в 18:40

Если родитель нужен, пробуем ему послать SIGCHILD, но скорее всего это не поможет. Тогда цепляемся к родителю через gdb, и от родителя уже запускаем waitpid() на pid зомби-процесса:

# gdb
(gdb) attach 19595
(gdb) call waitpid(19698,0,0)
$1 = 19698
(gdb) detach

sshikov 12 фев 2017 в 10:51

А зачем сравнивать шелл с возможностями cmd? Не, ну серьезно? Зачем выбирать какое-то другое древнее дерьмо мамонта и сравнивать с ним?

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

kekekeks 12 фев 2017 в 13:17

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

sshikov 14 фев 2017 в 09:24

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

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

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

avost 12 фев 2017 в 13:50

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

volkanin 12 фев 2017 в 08:03

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

powerman 12 фев 2017 в 08:25

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

tgz 12 фев 2017 в 10:45

Возможно redox взлетит…

NeoCode 12 фев 2017 в 11:35

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

tgz 12 фев 2017 в 11:53

Вода камень точит…

Lsh 12 фев 2017 в 12:17

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

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

neit_kas 13 фев 2017 в 04:36

Не нужны народу элегантные системы

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

S_A 12 фев 2017 в 08:30

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

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

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

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

sshikov 12 фев 2017 в 10:54

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

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

Хотя наверное не в таком стиле, все таки — а именно предлагая что-то взамен.

divanikus 12 фев 2017 в 12:33

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

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

dartraiden 12 фев 2017 в 14:45

Sysvinit

Его таки начали закапывать, хотя, не всем это нравится (но не будем разводить ту холивар на тему Sysvinit vs systemd).

НЛО прилетело и опубликовало эту надпись здесь

NeoCode 12 фев 2017 в 13:38

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

EviGL 13 фев 2017 в 21:44

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

MzMz 12 фев 2017 в 09:21

man hier

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

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

kelevra 12 фев 2017 в 09:58

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

dcc0 12 фев 2017 в 10:18

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

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

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 12 фев 2017 в 19:38

Я может плох в истории, но один из, так сказать, главных дизайнеров Windows NT Дейв Катлер является одним из самых известных хейтеров Unix, и как раз делал все по-другому. Можно каких-то подробностей по Unix legacy в ядре NT?

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 12 фев 2017 в 20:34

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

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

Про архиетктуру процессов — слишком абстрактно, так что не могу никак прокомментировать. Само понятие процесса существовало и до Unix, интереснее что специфично от Unix-а взято.

TaHKucT 12 фев 2017 в 20:49

> В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)

kmu1990 12 фев 2017 в 20:58

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

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 12 фев 2017 в 21:23

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

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

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

mayorovp 13 фев 2017 в 08:57

safinaskar 14 фев 2017 в 02:32

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

z3apa3a 12 фев 2017 в 23:36

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

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

НЛО прилетело и опубликовало эту надпись здесь

daggert 13 фев 2017 в 01:34

>К тому же в этом подходе есть проблемы- все потоки теряются при копировании на ФС без их поддержки, например, FAT.

А при копировании с ext4 на fat сохраняются атрибуты?

НЛО прилетело и опубликовало эту надпись здесь

z3apa3a 13 фев 2017 в 01:49

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

DreamingKitten 14 фев 2017 в 11:23

Начнем с самого простого и очевидного (то что на виду), любое устройство является файлом,

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

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

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

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

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

MacIn 14 фев 2017 в 18:10

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

Верно. ACL привнесли ребята из DEC/ VMS команд, ACL были в RSX-11 на PDP.

neit_kas 13 фев 2017 в 04:43

Ко всему описанному добавлю: современные исполняемые файлы под NT (Portable Executable) основаны на COFF (даже заголовок его наследуют).

dcc0 12 фев 2017 в 20:22

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

НЛО прилетело и опубликовало эту надпись здесь

DreamingKitten 14 фев 2017 в 11:14

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

nazarpc 12 фев 2017 в 10:38

Или некий аналог реестра

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

Lsh 12 фев 2017 в 12:10

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

kmu1990 12 фев 2017 в 12:20

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

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

nazarpc 12 фев 2017 в 12:46

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

TaHKucT 12 фев 2017 в 19:39

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

aso 13 фев 2017 в 11:03

В домашней директории пользователей лежат не конфиги, а файлы пользователей.

Э?
А что лежит в ~/.config?

mayorovp 13 фев 2017 в 11:22

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

aso 13 фев 2017 в 12:25

Нет, это дефолтное место для XDG-конфигов пользователя.
Причём, в принципе — могут порождаться программами — или ставиться из пакета по-умолчанию.

Daytar 12 фев 2017 в 12:51

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

Он удаляет только те конфиги, что были созданы на этапе установки пакета, зачастую это дефолтные конфиги в том же /etc или /etc/default, которые есть в описании пакета. Это делается для случаев, когда дефолтные конфиги были изменены юзером, затем сама програма была remove, а потом вдруг понадобилась обратно.
За динамически генерируемым конфигами, например в том же /home/.config apt не следит.

kmu1990 12 фев 2017 в 12:53

Я ровно это и написал. Что ваш комментарий добавляет к моему или оспаривает в нем?

Daytar 12 фев 2017 в 12:57

Часть про purge довольно скомканная и после описания проблемы динамических конфигов выше создаётся впечатление, что purge — панацея и умеет в удаление и их, а не только системных.

kmu1990 12 фев 2017 в 13:00

Часть выше части про purge вполне подробно и даже с примером (абсолютно эквивалентным вашему) объясняет почему пакетный менеджер не может впринципе следить за всеми конфигами. А часть про purge содержит слова «пытается» и «по мере возможностей» — очень не похоже на описание панацеи.

vintage 12 фев 2017 в 14:53

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

kmu1990 12 фев 2017 в 14:58

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

vintage 12 фев 2017 в 15:59

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

kmu1990 12 фев 2017 в 16:09

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

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

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

vintage 12 фев 2017 в 16:49

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

kmu1990 12 фев 2017 в 16:58

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

vintage 12 фев 2017 в 18:25

Вы не поверите: http://rancher.com/rancher-os/

kmu1990 12 фев 2017 в 18:29

Не поверю чему? Я знаю об этом проекте, что из сказанного мной этот проект опровергает?

vintage 12 фев 2017 в 18:37

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

kmu1990 12 фев 2017 в 18:43

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

vintage 12 фев 2017 в 18:54

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

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

kmu1990 12 фев 2017 в 19:01

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

Vjatcheslav3345 12 фев 2017 в 19:18

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

kmu1990 12 фев 2017 в 19:29

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

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

Aldrog 15 фев 2017 в 18:40

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

Elandor 12 фев 2017 в 12:29

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

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

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

DreamingKitten 14 фев 2017 в 11:30

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

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

mayorovp 14 фев 2017 в 12:03

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

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

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

vorphalack 14 фев 2017 в 21:19

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

Akon32 12 фев 2017 в 12:49

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

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

nazarpc 12 фев 2017 в 12:51

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

Mingun 12 фев 2017 в 13:33

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

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

nazarpc 12 фев 2017 в 15:15

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

Psychopompe 15 фев 2017 в 02:03

А разве это не фича Гнома?

НЛО прилетело и опубликовало эту надпись здесь

nazarpc 12 фев 2017 в 16:31

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

НЛО прилетело и опубликовало эту надпись здесь

nazarpc 12 фев 2017 в 16:36

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

НЛО прилетело и опубликовало эту надпись здесь

nazarpc 12 фев 2017 в 16:49

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

TaHKucT 12 фев 2017 в 19:48

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

НЛО прилетело и опубликовало эту надпись здесь

Ritan 13 фев 2017 в 23:11

Не мешайте людям раз за разом использовать «Чистильщики реестра» и «Ускорители компьютера», чтобы потом жаловаться, что ничего не работает. Это их выбор

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 14 фев 2017 в 02:41

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

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

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

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

Antervis 14 фев 2017 в 06:21

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

mayorovp 14 фев 2017 в 08:52

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

MacIn 14 фев 2017 в 18:11

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

Hatifnatt 12 фев 2017 в 10:42

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

Jaromir 12 фев 2017 в 12:00

Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками. Не пришлось бы парсить вывод самостоятельно

vintage 12 фев 2017 в 15:00

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

Jaromir 12 фев 2017 в 15:06

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

vintage 12 фев 2017 в 16:31

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

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

Jaromir 12 фев 2017 в 16:38

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

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

vintage 12 фев 2017 в 16:58

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

Jaromir 12 фев 2017 в 16:59

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

vintage 12 фев 2017 в 17:02

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

НЛО прилетело и опубликовало эту надпись здесь

Mingun 20 фев 2017 в 19:52

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

DrLivesey 12 фев 2017 в 15:38

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

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

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

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

popov654 14 фев 2017 в 13:08

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

vbif 14 фев 2017 в 13:16

Это тоже имеет экономические последствия на большом отрезке времени

DrLivesey 14 фев 2017 в 13:56

Неужели в IT всё оценивается чисто экономически?

Это загнивающий капитализм )

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

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

popov654 14 фев 2017 в 15:12

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

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

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

mayorovp 14 фев 2017 в 15:27

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

DrLivesey 14 фев 2017 в 15:41

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

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

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

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

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

popov654 14 фев 2017 в 18:51

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

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

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

DrLivesey 14 фев 2017 в 20:19

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

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

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

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

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

popov654 14 фев 2017 в 20:57

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

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

DrLivesey 15 фев 2017 в 12:32

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

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

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

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

popov654 17 фев 2017 в 05:11

А что это?) Не слышал про такую.

FieryVortex 17 фев 2017 в 12:49

Кратко — «куй железо, пока горячо». Или «седлай волну, пока не ушла».

DrLivesey 20 фев 2017 в 15:36

Мне казалось, что popov654 шутит...

popov654 12 мар 2017 в 08:57

Гугл про такую ничего не знает)) А что не знает Гугл, то я не могу знать тем более. Какие тут шутки…

DrLivesey 12 мар 2017 в 10:55

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

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

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

lomalkin 12 фев 2017 в 21:42

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

Akon32 13 фев 2017 в 17:03

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

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

lomalkin 14 фев 2017 в 18:19

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

ookami_kb 12 фев 2017 в 10:55

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

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

cjbars 12 фев 2017 в 11:03

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

MooNDeaR 12 фев 2017 в 11:24

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

ookami_kb 12 фев 2017 в 11:43

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

cjbars 12 фев 2017 в 21:45

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

silvansky 13 фев 2017 в 13:07

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

Tiendil 12 фев 2017 в 11:00

Как это развидеть?

Sburn 12 фев 2017 в 11:04

Спасибо, не дочитал.

DexterHD 12 фев 2017 в 11:16

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

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

Спасибо, не пиши больше.

NeoCode 12 фев 2017 в 12:21

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

nightvision 12 фев 2017 в 21:46

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

safinaskar 12 фев 2017 в 21:49

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

Massacre 13 фев 2017 в 15:53

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

safinaskar 14 фев 2017 в 16:41

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

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 12 фев 2017 в 21:52

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

jetexe 13 фев 2017 в 15:58

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

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

Скрытый текст

safinaskar 14 фев 2017 в 16:42

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

basilbasilbasil 14 фев 2017 в 18:19

safinaskar, ок, главное — легло по смыслу как полагается.

NeoCode 12 фев 2017 в 11:25

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

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

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

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

equand 12 фев 2017 в 14:05

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

Also есть scons.

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 12 фев 2017 в 18:34

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

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 12 фев 2017 в 21:01

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

mayorovp 13 фев 2017 в 09:18

Э… Debian wheezy? :)

НЛО прилетело и опубликовало эту надпись здесь

kmu1990 13 фев 2017 в 10:34

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

Вы не могли бы отвечать по существу, что такого в Windows ACL есть, чего нет в Posix ACL? Ато разговор очень странный получается, вы вопросы задаете, ответы получаете, но сами пока ни на один вопрос не ответили.

vorphalack 13 фев 2017 в 12:00

nested ACLs? наличие более точной настройки чем rwx? на NTFS 13 разных разрешений, например (или 14, если считать Full Control за еще одно).

DreamingKitten 14 фев 2017 в 11:42

nested ACL и в NTFS на самом деле просто рекурсивный обход с установкой дочерних аклов равным родительским по дефолту, так что в линуховых аклах с этим легко справляется setfacl -Rd
А вот с более точной настройкой, чем rwx тут конечно да, но, с другой стороны, довольно сложно придумать ситуацию, когда, скажем, надо дать группе разрешение создать каталоги, но не разрешать их удалять или создавать в них файлы… NTFS такое позволяет, но, как бы… зачем? :)

mayorovp 14 фев 2017 в 12:05

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

DreamingKitten 14 фев 2017 в 13:35

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

И кстати, по-моему это и с общим корнем можно сделать без ACL. Какое-нибудь chmod go-rwx и всё.

safinaskar 17 фев 2017 в 09:09

В юниксах довольно давно есть фича, делающая именно то, что вы сказали. Т. е. установить специальный бит на папку так, чтобы в этой папке все могли создавать, но при этом нельзя было лезть в папки, созданные другими. Этот бит стоит по дефолту на /tmp в GNU/Linux, т. к. именно для /tmp такая функциональность обычно и нужна.

НЛО прилетело и опубликовало эту надпись здесь

vorphalack 14 фев 2017 в 21:26

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

DreamingKitten 15 фев 2017 в 01:03

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

НЛО прилетело и опубликовало эту надпись здесь

mayorovp 15 фев 2017 в 16:30

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

НЛО прилетело и опубликовало эту надпись здесь

mayorovp 15 фев 2017 в 16:47

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

НЛО прилетело и опубликовало эту надпись здесь

DreamingKitten 15 фев 2017 в 23:50

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

mayorovp 15 фев 2017 в 08:57

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

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

equand 12 фев 2017 в 21:46

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

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

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

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

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

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

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

Siemargl 12 фев 2017 в 23:02

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

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

equand 13 фев 2017 в 02:31

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

DreamingKitten 14 фев 2017 в 11:44

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

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

vintage 12 фев 2017 в 18:34

powershell?

equand 12 фев 2017 в 21:34

Thanks but no thanks :D

vintage 12 фев 2017 в 23:00

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

equand 13 фев 2017 в 02:41

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

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

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

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

vintage 13 фев 2017 в 09:29

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

xerxes 13 фев 2017 в 10:38

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

mayorovp 13 фев 2017 в 10:47

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

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

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

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

RussianNeuroMancer 13 фев 2017 в 09:30

Есть PowerShell: https://github.com/PowerShell/PowerShell/releases

Psychopompe 15 фев 2017 в 02:13

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

safinaskar 18 фев 2017 в 15:00

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

kmu1990 12 фев 2017 в 14:19

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

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

vintage 12 фев 2017 в 15:25

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

kmu1990 12 фев 2017 в 15:33

Кто сказал что make самое удобное средство из доступных?

vintage 12 фев 2017 в 17:00

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

kmu1990 12 фев 2017 в 17:04

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

vintage 12 фев 2017 в 18:41

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

kmu1990 12 фев 2017 в 18:50

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

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

arheops 12 фев 2017 в 19:21

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

Yukarin 12 фев 2017 в 21:52

Так, вместо make давно бы уже перешли на qbs.

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

Gorthauer87 13 фев 2017 в 15:48

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

Antervis 13 фев 2017 в 19:43

идеи, на которых основан qbs, хороши и практичны. Но во-первых, qbs еще на этапе становления (не так уж и редко выходят breaking changes), во-вторых, комьюнити — два с половиной калеки (вплоть до того, что на все мои вопросы по qbs на so ответил один и тот же человек). Из-за этого по сути 90% информации, которую вообще можно найти в сети по qbs — официальная документация. Она хороша, но скорее в виде справочника, нежели подробного пособия.

dom1n1k 12 фев 2017 в 11:27

Сочный вброс. Ждем овер 9000 комментов «у меня все нормально, чяднт?»

justhabrauser 12 фев 2017 в 12:20

Заголовок особенно сочный.
Походу рождается новый ализар.

worldmind 12 фев 2017 в 12:33

Заловок конечно слишком жёлтый, зашёл посмотреть на крах, а про него почти ничего и не сказано:
> авторы UNIX фактически придумали для каждого системного конфига… свой формат

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

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

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

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

divanikus 12 фев 2017 в 12:36

> и при чём тут философия? она разве запрещает все конфиги сделать в YAML?
Запрещает legacy, у чужой программы на YAML конфиг не переделать. Ну или пилите полностью свой дистр с блекджеком и yamlами, только он никому не нужен будет.

worldmind 12 фев 2017 в 12:39

Только легаси это легаси, а не философия, не надо в кучу смешивать.

divanikus 12 фев 2017 в 13:04

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

НЛО прилетело и опубликовало эту надпись здесь

worldmind 12 фев 2017 в 20:43

YAML это тоже текст

Gorthauer87 13 фев 2017 в 15:51

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

worldmind 13 фев 2017 в 17:15

YAML это лишь пример, а привычка это дело привычки — если бы ямл был стандартом то все бы привыкли

safinaskar 14 фев 2017 в 17:26

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

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

worldmind 14 фев 2017 в 18:36

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

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

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

например когда?

DreamingKitten 14 фев 2017 в 19:07

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

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

worldmind 14 фев 2017 в 19:12

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

DreamingKitten 14 фев 2017 в 20:44

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

worldmind 14 фев 2017 в 21:01

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

DreamingKitten 15 фев 2017 в 01:08

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

safinaskar 17 фев 2017 в 14:27

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

safinaskar 17 фев 2017 в 14:37

del

Psychopompe 15 фев 2017 в 02:18

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

immaculate 15 фев 2017 в 09:59

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

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

vbif 15 фев 2017 в 10:16

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

safinaskar 17 фев 2017 в 13:54

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

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

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

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

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

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

immaculate 12 фев 2017 в 13:00

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

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

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

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

divanikus 12 фев 2017 в 13:06

ВАЗ 2107 тоже много чего пережил, видать дофига продуманная машина :)

shogunkub 12 фев 2017 в 14:26

Ну вообще-то, продуманная. Просто, при определённых вводных. Оптимизация UNIX по памяти — тоже не из пустого места выросла.

iig 12 фев 2017 в 21:52

Двигатель внутреннего сгорания много чего пережил. Несмотря на legacy и костыли внутри.

stigory 13 фев 2017 в 03:40

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

Vjatcheslav3345 17 фев 2017 в 20:28

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

entze 12 фев 2017 в 13:24

Оффтоп: а что — модераторы хабра модерируют посты? Или автор разжигает срачик не только на этом ресурсе?

НЛО прилетело и опубликовало эту надпись здесь

dartraiden 12 фев 2017 в 14:48

Не только ошибки, впрочем.

ky0 12 фев 2017 в 15:29

Ещё бы «щасы» и прочие «я д`Артаньян, между прочим» фиксили, дабы ослабить кровотечения из глаз у читателей…

TargetSan 12 фев 2017 в 13:34

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

equand 12 фев 2017 в 13:39

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

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

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

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

Mingun 12 фев 2017 в 13:48

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

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

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

equand 12 фев 2017 в 14:01

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

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

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

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

divanikus 12 фев 2017 в 23:42

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

popov654 14 фев 2017 в 17:03

Эм, вы о чём?..

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

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

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

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

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

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

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

И в чём смысл всего этого.

allter 12 фев 2017 в 14:56

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

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

vintage 12 фев 2017 в 17:51

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

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

safinaskar 14 фев 2017 в 17:52

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

НЛО прилетело и опубликовало эту надпись здесь

serg_p 12 фев 2017 в 14:29

Зачем БД если есть…

safinaskar 14 фев 2017 в 17:36

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

safinaskar 14 фев 2017 в 17:40

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

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

Holix 12 фев 2017 в 14:24

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

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

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

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

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

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

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

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

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

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

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

NeoCode 12 фев 2017 в 15:32

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

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

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

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

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

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

immaculate 12 фев 2017 в 16:06

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

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

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

NeoCode 12 фев 2017 в 16:12

Это НЕ конфиги, а внешние скрипты. И они должны быть отдельно от конфигов.

Busla 15 фев 2017 в 11:12

Это неоднозначный теологический вопрос. Например «конфиги» сети, почты, АТС по сути несут в себе сценарии инициализации оборудования и/или обработки данных.

НЛО прилетело и опубликовало эту надпись здесь

Holix 12 фев 2017 в 16:19

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

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

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

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

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

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

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

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

NeoCode 12 фев 2017 в 17:05

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

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

Holix 12 фев 2017 в 17:28

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

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

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

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

NeoCode 12 фев 2017 в 17:50

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

kmu1990 12 фев 2017 в 18:04

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

Суть истории в том, что в некоторых ситуациях делать целый проект единицей компиляции может быть не самой удачной идеей, потому что компиляция и линкова могут стать слишком требовательными к ресурсам. Прелесть модулей как раз в том, что их можно собрать один раз и потом просто использовать. Но с шаблонами C++ и необходимостью объявления перед использованием не очень очевидно как этого добиться. Лучшее что мне известно на данный момент — это прекомпилированные заголовочные файлы (некоторые компиляторы поддерживают такую фичу).

NeoCode 12 фев 2017 в 18:20

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

kmu1990 12 фев 2017 в 18:28

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

NeoCode 12 фев 2017 в 18:37

Прекомпилированные файлы работают зачастую криво. Или вот еще — если есть группа связанных проектов («solution» в терминах VC++) и у них есть общие заголовочные файлы, то для каждого проекта из группы придется генерировать свой precompiled header.

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

kmu1990 12 фев 2017 в 18:53

1. То что прекомпилированные фалы работают криво — это бага. Баги нужно исправлять. Или вы думаете, что модули по-умолчанию будут bug-free?
2. Т. е. вам не нравится по сути функциональность и синтаксис, вам нужен императив? В таком случае я скажу, что это ваше предпочтение, но не объективный недостаток шаблонов. Впрочем, я тоже не супер фанат синтксиса шаблонов (но это мое личное предпочтение).

NeoCode 12 фев 2017 в 19:03

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

kmu1990 12 фев 2017 в 19:09

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

NeoCode 12 фев 2017 в 19:31

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

Gryphon88 13 фев 2017 в 16:08

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

mayorovp 13 фев 2017 в 09:44

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

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

Holix 12 фев 2017 в 18:17

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

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

NeoCode 12 фев 2017 в 18:25

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

Holix 12 фев 2017 в 19:04

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

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

zhigalin 13 фев 2017 в 14:24

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

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

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 14 фев 2017 в 21:42

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

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

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

tmnhy 14 фев 2017 в 21:53

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

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

safinaskar 18 фев 2017 в 12:54

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

borisxm 12 фев 2017 в 21:53

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Holix 12 фев 2017 в 16:57

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

vintage 12 фев 2017 в 18:05

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

mayorovp 13 фев 2017 в 09:46

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

kekekeks 12 фев 2017 в 19:39

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

НЛО прилетело и опубликовало эту надпись здесь

Alexsandr_SE 12 фев 2017 в 20:02

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

safinaskar 14 фев 2017 в 21:18

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

vbif 14 фев 2017 в 23:05

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

(^_^;)

Izaron 12 фев 2017 в 14:25

Автор неплохо проехался по C/C++, хочется уточнить

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

Немного кривая аргументация

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

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

И это не говоря об отсутствии простой, удобной и мультиплатформенной системы сборки <...> стандартного менеджера пакетов

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

void (*signal(int sig, void (*func)(int)))(int)

Какой ужасный язык, у меня уровень сахара в крови упал!

Sad_Bro 12 фев 2017 в 14:37

холиварный пост, и php гавно (да когда то было, но придание до сих пор живо как я понял), и С. Пока ~90% серверов работает на gnu linux/unix системах ваши доводы можно трактовать как «ребята вы все дураки что используете это и зарабатываете деньги, давайте я вас научу как работать неучей. „

NeoCode 12 фев 2017 в 15:08

Нет. Это можно трактовать как то, что бизнесу пофиг на Совершенство, Безупречность и Гармонию, ему «работает и ладно, лишь бы бабло капало».

Sad_Bro 12 фев 2017 в 15:37

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

TaHKucT 12 фев 2017 в 20:03

бизнесу не нужно «работает и ладно», бизнесу нужно «что бы работало не хуже чем у конкурентов, а если даже лучше, то вообще замечательно», но почти все конкурируют друг с другом почему то на линуксах, виндусах и иногда бздях, а план9, инферно и остальные не очень распространенные ОС занимают свою небольшую нишу и пока что не претендуют на «ОС общего назначения»

NeoCode 12 фев 2017 в 23:22

Бизнесу надо в основном «быстрее чем у конкурентов». Лучше там или не лучше — в определенных пределах пофиг; главное ввязаться, заявить о себе, а пипл все равно схвавает.
То есть конечно откровенно не работающие программы в продакшен не попадают, но вот ради перфекционизма и внутренней архитектурной красоты никто заморачиваться не будет.

lubezniy 13 фев 2017 в 00:59

Ну да. Потому что при перепроектировании и переделке люди обязательно наделают ещё и своих багов (и кодовых, и архитектурных), лет 15 будут их героически устранять, а потом придёт новый сноб, скажет, что всё это legacy… и так по кругу.

allter 12 фев 2017 в 14:41

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

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

Ассемблер с редактором Томпсон тоже сам написал, на GECOS системе.

Alesh 12 фев 2017 в 15:23

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

masai 12 фев 2017 в 15:26

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

sbnur 12 фев 2017 в 15:38

Понятное дело — все старики неряшливые, неухоженные с кучей приобретенных болячек, не говоря о наступающей деменции

Alesh 12 фев 2017 в 17:14

Ага вот только часто их заменить некем)

DrLivesey 12 фев 2017 в 15:52

Статья интересная просто потому, что много всякого разного собрано в одном месте, но:

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

это, простите, что?

Error1024 12 фев 2017 в 18:45

Это сарказм, на тему статьи.

safinaskar 14 фев 2017 в 22:56

Это не сарказм

delvin-fil 12 фев 2017 в 15:54

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

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

dion 12 фев 2017 в 15:59

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

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

delvin-fil 12 фев 2017 в 16:37

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

Каталог не бывает менее 4Кб

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

grep -i же

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

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

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

safinaskar 18 фев 2017 в 18:11

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

VovanZ 12 фев 2017 в 16:30

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

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

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

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

delvin-fil 12 фев 2017 в 16:44

Вот и я говорю — придумывают костыли, а потом жалуются!

popov654 14 фев 2017 в 15:08

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

Но вот этот прагматизм слегка добивает… Зачем здесь и сейчас, если можно придумать что-то новое, лучшее, что будет работать когда-то потом и приносить пользу? Я бы с радостью занялся изучением Plan 9 и портированием некоторого софта на неё, будь у меня несколько больше знаний в этом вопросе. Мне кажется, это довольно интересно и познавательно. Как и вообще освоение чего-то нового.

safinaskar 14 фев 2017 в 23:31

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

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

Mingun 15 фев 2017 в 23:16

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

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

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

khim 16 фев 2017 в 22:25

Что лучше — один раз поломать написанное плохо и написать лучше и потом все оставшееся время получать профит или и дальше продолжать жевать кактус, накапливая ненависть?

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

immaculate 12 фев 2017 в 17:16

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

safinaskar 12 фев 2017 в 18:00

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

Krypt 12 фев 2017 в 18:15

Ок, весь софт — дерьмо, жизнь — дерьмо, мир — дерьмо. А чем пользоваться — то? :D

Dessloch 14 фев 2017 в 11:31

виндой конечно, видимо это автор хотел сказать.

Krypt 14 фев 2017 в 16:54

Так винда тоже дерьмо :(

НЛО прилетело и опубликовало эту надпись здесь

vintage 12 фев 2017 в 18:47

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

НЛО прилетело и опубликовало эту надпись здесь

divanikus 14 фев 2017 в 01:48

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

Чего там, паравиртуализацию во FreeBSD уже завезли? Как с поддержкой аппаратного ускорения современных видеокарт? А юникод в консоль без костылей завезли?

НЛО прилетело и опубликовало эту надпись здесь

divanikus 20 фев 2017 в 04:41

Не, логика еще проще. Есть инструмент — делаешь. Нет инструмента — не делаешь. Все оборудование без проблем завелось в Linux и работает до сих пор. FreeBSD тогда таким похвастаться не мог. Проще взять другой инструмент, чем мучаться с непригодным.

НЛО прилетело и опубликовало эту надпись здесь

divanikus 18 фев 2017 в 14:48

У вас неправильная логика. Все оборудование было IBM eSeries или IBM Bladecenter, с очень серьезной поддержкой со стороны вендора. Itanium также был в IBM-овском сервере, но уходил на списание. К сожалению вдохнуть новую жизнь фряхой не удалось. Не думаю что закупка ЦОД — дело импульсивное.

divanikus 17 фев 2017 в 15:21

Все это конечно хорошо, что сейчас многое появилось. Но в 2009, когда мы поднимали кластер с Infiniband, фряха его не поддерживала. Надо было наверное сказать, что пацаны погодите, пускай железо постоит пока, там пацаны из фряхи еще драйвер не написали.
Учитывая нынешнюю копроэкономику, поддержка древних устройств никак в не помогает ОС продавать себя, рынку нужна поддержка всего самого свежего и сейчас, а не через пару лет.
А так, конечно фряха ставилась везде, но не везде взлетали нужные устройства. Хотя вру, на Intel Itanium дальше Boot Logo продвинуться не удалось, пришлось ставить SUSE.
То что FreeBSD нельзя использовать как основу гипервизора в нынешних реалиях печально. Даже винду можно.

DreamingKitten 17 фев 2017 в 23:26

2 Incidence
Я в курсе, и всего то на 18 лет. Это к свежести вопроса про utf в консоле. Мне лично он там никогда актуален не был.

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

DreamingKitten 15 фев 2017 в 01:11

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

Если это такая шутка, то она опоздала лет на 25, как минимум.

НЛО прилетело и опубликовало эту надпись здесь

DreamingKitten 18 фев 2017 в 10:22

Речь шла о поддержке ядром ОС именованных объектов.
А не о том, какие востребованные в 0.01% случаев свистоперделки можно прикрутить к терминалу через ANSI-коды и прочие не относящиеся к обработке строк вещи.

divanikus 15 фев 2017 в 01:29

> Хз, мне виртуалбоха хватает.
Облака тоже на виртуалбоксах пилить будете? 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 нет, ТВ тюнер хоть и с аппаратным кодеком, тоже нет и т.д.

vintage 14 фев 2017 в 09:11

Тут написано нахрена: https://habrahabr.ru/post/276227/

НЛО прилетело и опубликовало эту надпись здесь

GarryC 12 фев 2017 в 19:36

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

saggid 12 фев 2017 в 19:53

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

Self_Perfection 12 фев 2017 в 20:32

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

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

safinaskar 14 фев 2017 в 17:36

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

saggid 15 фев 2017 в 04:10

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

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

safinaskar 18 фев 2017 в 15:05

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

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

geher 18 фев 2017 в 16:33

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

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

geher 18 фев 2017 в 16:39

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

geher 18 фев 2017 в 16:46

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

maydjin 12 фев 2017 в 19:55

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

man find | grep exec

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

Jogger 12 фев 2017 в 19:57

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

kmu1990 12 фев 2017 в 20:40

К списку недостатков фанатиков — они очень любят обобщать — прочитали один комментарий с такими аргументами, значит ВСЕ комментарии такие.

Jogger 12 фев 2017 в 21:05

Да, возможно что со словом «все» я несколько перегнул палку, ведь под это понятие попадают и контраргументы, и даже мой комментарий. Но если вы намекаете, что я фанатик — то позвольте поинтересоваться, фанатик чего?

kmu1990 12 фев 2017 в 21:28

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

Jogger 12 фев 2017 в 22:08

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

maydjin 12 фев 2017 в 21:13

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

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

Self_Perfection 12 фев 2017 в 20:05

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

И назад к 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 просто служит человеку и помогает работать с информацией, не должно быть необходимости помнить и отслеживать, где какой конец строки используется.

FoxCanFly 13 фев 2017 в 18:12

Эту проблема не Unix, а как раз таки искусственно создана MS в качестве вендорлока.

MacIn 13 фев 2017 в 18:55

Какие же они evil!!!
Unix пришел с «больших» машин, терминалы которых имели раздельные клавиши ВК и ПС (CR и LF). Физически разные кнопки. И еще со времен телетайпов окончание ввода обозначалось нажатием на клавишу «Возврат каретки».
А MS развивался на рынке ПЭВМ, где была одна клавиша «Enter», и была необходимость генерировать оба символа сразу при нажатии одной кнопки, поскольку эти операции не разделялись, и автономная «возврат каретки» была не нужна — ее роль по сути выполняла клавиша Home.

НЛО прилетело и опубликовало эту надпись здесь

gatoazul 12 фев 2017 в 20:47

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

NeoCode 12 фев 2017 в 23:46

Ну, дьявол, как известно, в деталях. Да автор и сам пишет, что «Есть идеи в UNIX, которые мне реально нравятся». Идеи Юникс в целом прекрасны и замечательны, а вот все проблемы именно в частных недоработках. Причем эти частные недоработки расползлись и размазались тонким слоем по всему Юниксу, так что иногда даже сформулировать бывает сложно… но автор попытался, за что ему честь и хвала, я бы так не смог (хотя наталкивался на все это тоже).

gatoazul 13 фев 2017 в 12:39

Тогда статья должна называться «Проблемы в современных реализациях Юникса»

potan 12 фев 2017 в 20:56

С табуляцией в make решение неудачное, но хорошей замены этому инструменту я не нашел. В sbt, cabal, cargo очень тяжело сказать системе, что "'эти файлы, несмотря на расширение, не трогая", а «этот надо сгенерировать, запустив такую программу».
Плохо не то, что в Unix накопились баги, плохо то, что их толком ни где не исправили.

NeoCode 12 фев 2017 в 23:54

Я вообще считаю, что если возникает такая потребность как «эти файлы несмотря на расширение не трогай» то тут что-то не то. Да и генерить файлы… ну не всегда это нужно. Я писал проекты с тысячами файлов исходного кода, и нигде такое не требовалось. Хотя я понимаю что это может быть необходимо в каких-то случаях.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.

kmu1990 13 фев 2017 в 11:12

Среди различных 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-скрипт (не супер часто его приходится указывать явно) и имя автоматически генерируемого файла и скрипт для его генерации. Я бы не назвал это не декларативным.

potan 13 фев 2017 в 12:19

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

mayorovp 13 фев 2017 в 12:32

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

potan 13 фев 2017 в 12:42

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

mayorovp 13 фев 2017 в 13:26

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

potan 13 фев 2017 в 13:34

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

olku 12 фев 2017 в 21:02

Я один заметил скрытую рекламу никсов? :)

geher 12 фев 2017 в 21:44

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

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

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

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

safinaskar 15 фев 2017 в 00:24

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

selgjos 12 фев 2017 в 21:53

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

Назовите язык, в котором это не так.

Dessloch 14 фев 2017 в 11:29

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

mayorovp 14 фев 2017 в 12:08

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

kekekeks 14 фев 2017 в 13:00

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

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

selgjos 14 фев 2017 в 15:35

Доказательства есть? Хотя ниже уже ответили.

vintage 14 фев 2017 в 18:43

Например, в 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"]]
}

xFFFF 12 фев 2017 в 21:53

Вот по этому я и не пользуюсь *nix.))

RussianNeuroMancer 13 фев 2017 в 09:46

Чем пользуетесь-то, где костылей меньше? Plan9 или Inferno?

vbif 13 фев 2017 в 18:02

По какому?

irbis_al 12 фев 2017 в 21:53

Пусть автор в Windows попробует создать файл с простым именем prn (Этот артефакт ещё с доса тянется)…
А вообще надо не забывать, что часто недостатки, являются продолжением достоинств.
(Ушёл с винды ещё в 2006 году(и перевёл всех своих клиентов с винды)… что я тоже делаю не так???)

MacIn 13 фев 2017 в 20:29

Да, в принципе, запросто. И даже Symbolic link удалять не надо.

u007 15 фев 2017 в 08:30

safinaskar 18 фев 2017 в 15:10

Как это вы так? :) Фотошоп? :)

DreamingKitten 18 фев 2017 в 21:40

Скорее всего, это сетевая шара на самбе или типа того, где ни одно из этих имён не является зарезервированным.

u007 19 фев 2017 в 13:46

Зачем же фотошоп) Вот, распакуйте: https://yadi.sk/d/4ZhozKC43EFm4k
Если спросит про замену — «да для всех».

daggert 19 фев 2017 в 14:09

Не работает

safinaskar 19 фев 2017 в 14:41

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

Thero 12 фев 2017 в 21:53

пришло время переписать unix на расте…

НЛО прилетело и опубликовало эту надпись здесь

LLE 12 фев 2017 в 21:53

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

safinaskar 15 фев 2017 в 00:28

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

mikeus 12 фев 2017 в 21:55

Я твой UNIX-дом труба шатал, shell-калитка тряс, философия-огород топтал, язык С кэпка на х… вертел!

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

xby 12 фев 2017 в 21:55

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

n-krd 12 фев 2017 в 21:55

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

Dessloch 12 фев 2017 в 21:55

Как-то несерьёзно это всё. Конечно у Linux есть недостатки. Но сравнивать бесплатно и платное ПО как-то не принято в мире. Не нравится-покупай и ставь Windows, Linux никто не навязывает.
Про реестр идея интересная конечно. Если бы это было грамотно реализовано. Но ведь RegCleaner'ы для чего-то существуют. А значит реализация подкачала.
Ну и сравнивать linux-shell и php вообще нонсенс.

НЛО прилетело и опубликовало эту надпись здесь

Dessloch 13 фев 2017 в 18:17

Во-первых есть бесплатные. Во-вторых опыт показывает что regcleaner размер реестра иногда значительно уменьшает. А значит не всё так уж хорошо с реестром.

НЛО прилетело и опубликовало эту надпись здесь

Dessloch 14 фев 2017 в 11:25

«Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие.»
Это ваше личное мнение? Доказать-обосновать как-то можете?
А я вот думаю что влияет. Впрочем не вижу смысла спорить.

НЛО прилетело и опубликовало эту надпись здесь

Dessloch 15 фев 2017 в 20:05

На том же самом.

НЛО прилетело и опубликовало эту надпись здесь

FieryVortex 15 фев 2017 в 18:40

у Linux есть недостатки. Но сравнивать бесплатно и платное ПО

Прошу прощения, насколько мне известно, UNIX — это далеко не только Linux. Точнее даже, Linux — не совсем UNIX.
И что там с бесплатностью у (Sun)^W Oracle Solaris? Или у macOS, фанаты которой хвалятся тем, что она «настоящая UNIX»? О более редких коммерческих версиях можно не вспоминать.

dunaich75 12 фев 2017 в 21:55

Статья скорее говорит за UNIX, чем против него.

NickCave 12 фев 2017 в 21:55

"«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX»."
Вот оно что! Оказывается философия UNIX — всё есть текст. Интересно, а философия Windows тогда — всё есть ОКНО.

ben-postman 12 фев 2017 в 21:56

Статья о наболевшем — это понятно и стиль статьи тоже принимается, но после прочтения возникает только одна мысль: — «Что же мне делать? Как быть то сыну простого крестьянина? Пишущему классы для работы с периферийными устройствами и разрабатывающему ПО АСУ ТП ???»
Но теперь я знаю что!!! — Поднять руку, левую или правую, и резко опустить со словами: -«Ну и… с ним!!!»
А про себя подумать: — «Делай что должен! И будь что будет!» :-)

GarryC 12 фев 2017 в 21:59

Кстати, в заголовке явно не хватает фразы "… Программисты всего мира в шоке..."

shuron 12 фев 2017 в 22:42

Вообще то с философией юникса ассоциируют именно эти три вещи и именно в этом порядке.

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.

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

mikeus 13 фев 2017 в 00:27

В самом начале 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-подобные системы можно использовать?! Так это ещё цветочки, вот вообще трэш — «О срезании углов»
:-)))

ky0 13 фев 2017 в 01:37

Вот, как надо комментировать подобные потоки сознания. Спасибо!

itxs 13 фев 2017 в 01:27

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

safinaskar 15 фев 2017 в 10:38

Статью надо переделать, убрав все провокационное, и оставив только конструктив

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

itxs 15 фев 2017 в 12:56

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

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

Vkuvaev 13 фев 2017 в 02:20

Господи, а cp rm и иже с ними за что? Руками их набивать быстрее, спутать невозможно, сплошной профит.
Или copy и remove что-то исправят?
Ну так пропишите себе алиас и не парьтесь:). Видимо вы в sh скорее гость, чем завсегдатай.

tyderh 13 фев 2017 в 02:28

Я не закончил про 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, но это было бы не так эффектно

Блин, так это еще и специально? КГ/АМ

degs 13 фев 2017 в 02:43

Прочитал все комментарии, по-моему все что нужно уже сказали. Поэтому выскажусь чисто по философски:

Поняли, фанатики, да? Ваш кумир отказался от своей же философии. Можете расходиться по домам.

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

Skler0z 13 фев 2017 в 03:28

Статья подняла настроение. А про GIT в том же стиле сможете написать? :)

safinaskar 14 фев 2017 в 02:02

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

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

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

vbif 14 фев 2017 в 11:45

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

kekekeks 14 фев 2017 в 13:02

Чтоб папки были всё-таки бинарными объектами сразу.

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

НЛО прилетело и опубликовало эту надпись здесь

MacIn 14 фев 2017 в 18:16

Про GIT писать не надо — уже написано полно.

3aicheg 13 фев 2017 в 03:32

Чё-то хрень какая-то (вроде бы, дальше первых двух абзацев читать было лень, скажите спасибо, что откомментил).

Antervis 13 фев 2017 в 05:32

Критика — это хорошо, если она конструктивна. Критика в статье не предлагает альтернатив.

exce1 13 фев 2017 в 10:44

От статьи был бы толк, если бы Винда под конец жизни не продалась дъяволу. И её перспективы теперь, увы, туманны. Разве что, геймеры продолжат за неё цепляться.

virgin_unix_fan 13 фев 2017 в 10:44

Прочитал Ваш поток сознания и болезненный хипстерский крик души и даже специально зарегистрировался, чтобы ответить. Штуковина, которую вы пытаетесь критиковать де-факто обслуживает весь интернет в мире последние лет 50 и никакого краха там нет и не предвидится. От того что вы составляете списки костылей в ней, забиваете гвозди микроскопом, туннелируете через 4(четыре Карл!) хоста ради одного файла и почему-то по умолчанию считаете каждого первого встречного её фанатиком в этом мире совсем ничего не изменится. Такие дела. Чао.

9660 13 фев 2017 в 10:44

«Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем.»

Может логичнее сказать «у нее полно особенностей»? Потому что, к примеру, большинство из описанного, для меня лично, недостатками не является.

KiloLeo 13 фев 2017 в 10:44

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

msts2017 13 фев 2017 в 13:03

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

augur 13 фев 2017 в 14:09

UNIX – наихудшая операционная система, если не считать всех остальных.

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

Denkenmacht 13 фев 2017 в 23:12

Наверное для таких глобальных суждений, как в статье, все-таки нужно вводить возрастной ценз, или хотя бы по опыту работы. А то любой может об… ать труд двух поколений людей, обозвав всех фанатами и кичась своими фрагментарными знаниями чего-либо. Просто есть и будут вещи, которые устаревают, а есть вещи, которые нет, как топор. UNIX — топор, который будет продолжать рубить еще долго, не смотря на то, что будут говорить отдельные «знатоки».

MacIn 14 фев 2017 в 18:17

Признать, что вещь устарела, а какая-то концепция является костылем — да, тут нужно мужество, не каждому по плечу.

Denkenmacht 14 фев 2017 в 18:51

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

popov654 14 фев 2017 в 19:02

и эффективной замены пока что нет

А Inferno не вариант? Я сам в этом не очень разбираюсь, но слышал о ней очень позитивные отзывы, в том числе и на Хабре были статьи.

Denkenmacht 14 фев 2017 в 19:24

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

popov654 14 фев 2017 в 19:31

1C и МС Офис и на Линуксах не пойдут)

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

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

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

Denkenmacht 14 фев 2017 в 19:42

1C и МС Офис и на Линуксах не пойдут)

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

popov654 14 фев 2017 в 21:00

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

RussianNeuroMancer 22 фев 2017 в 00:22

Когда 1С перестал «идти на Линуксах»?

НЛО прилетело и опубликовало эту надпись здесь

RussianNeuroMancer 26 фев 2017 в 18:39

И?

НЛО прилетело и опубликовало эту надпись здесь

RussianNeuroMancer 27 фев 2017 в 02:18

И что, действительно не пашет?

НЛО прилетело и опубликовало эту надпись здесь

RussianNeuroMancer 27 фев 2017 в 11:29

Мы все-таки на ИТ-ресурсе, а то что вы описываете это уровень бабок у подъезда.

khim 27 фев 2017 в 17:22

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

mayorovp 27 фев 2017 в 19:15

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

MacIn 14 фев 2017 в 19:07

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

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

Я сказал «вещь устарела», а не «UNIX системы устарели».

Denkenmacht 14 фев 2017 в 19:33

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

MacIn 14 фев 2017 в 19:37

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

Denkenmacht 14 фев 2017 в 19:50

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

НЛО прилетело и опубликовало эту надпись здесь

Chelyuk 13 фев 2017 в 23:12

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

Dessloch 14 фев 2017 в 11:21

Мне больше интересно другое. Ну не нравится тебе что-то-не пользуйся. Работай на Windows. К чему эти холивары?

Fluorescent 13 фев 2017 в 23:12

Статья повеселила. Покажите мне номерной маздай с переводом строки в имени файла на NTFS и парсинг этого файла PowerShello'м :))

leocat33 13 фев 2017 в 23:13

NTFS никакого отношения к *nix не имеет. Вообще. Это урезанный клон Files-11 от DEC.
Попытка реализовать DEC RMS у мелкомягких с треском провалилась ( Longhorn )
Попытка сделать нормальную ОСь, как то клон VMS: http://www.freevms.net не нашла должного количества волонтеров и находится многие годы в состоянии ни жив, ни мертв.
Так и живем, с Линуксом…

MacIn 14 фев 2017 в 18:20

NT и есть переработанная VMS, а уж сколько всего там от Files-11, начиная от ACL и кончая альтернативными потоками…

НЛО прилетело и опубликовало эту надпись здесь

MacIn 14 фев 2017 в 19:08

Мда. А в HPFS они откуда?

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 14 фев 2017 в 02:05

Hellsy22,Dessloch

UPD от 2017-02-14: комментаторы указывают, что сравнивать UNIX shell с PHP некорректно. Конечно, некорректно! Потому что UNIX shell не претендует на то, чтобы быть полноценным языком программирования, он предназначен для скриптинга системы. Вот только я в одно время этого не знал. И вдобавок считал UNIX shell прекрасным. Вот для людей в таком же положении я всё это и говорю. Ещё как минимум один комментатор говорит, что сравнивать UNIX shell нужно с cmd. Я бы сказал, что сравнивать надо с Windows Powershell. Последний, как я уже говорил, в чём-то превосходит UNIX shell.

Dessloch 15 фев 2017 в 20:15

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

mayorovp 15 фев 2017 в 20:32

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

safinaskar 14 фев 2017 в 02:25

UPD от 2017-02-14: мне понравился вот этот коммент от sshikov ( https://habrahabr.ru/post/321652/#comment_10065532 ):

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

Да, в этом-то и всё дело! Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат. А использовать-то UNIX можно.

Fluorescent 14 фев 2017 в 03:23

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

vintage 14 фев 2017 в 09:49

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

daggert 14 фев 2017 в 10:46

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

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

mayorovp 14 фев 2017 в 12:10

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

daggert 14 фев 2017 в 12:46

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

DreamingKitten 14 фев 2017 в 13:46

а в чём проблема с кириллицей в зипе?

vbif 14 фев 2017 в 14:13

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

DreamingKitten 14 фев 2017 в 14:25

Тот архив, что на моём скрине выше, был создан штатным zip-архиватором винды из контекстного меню эксплорера, Send to -> Compressed Folder или как его там. Внутри ZIP-файла кириллическое имя оказалось записано в CP866, но zip/unzip со включённым natspec'ом его воспринял корректно. Хотя KDEшный Ark и GNOMEовский File-Roller обломались и показывали "????????" вместо имени, я всё же не думаю, что это проблема именно Линукса.

vbif 14 фев 2017 в 14:27

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

Siemargl 14 фев 2017 в 17:58

Нет там проблемы давно. В zip-формате есть дополнительное поле для utf-8 имени. Это проблема старых архиваторов.

Fluorescent 17 мар 2017 в 23:05

нужно правильный линух использовать, вот FreeBSD — правильный линух ))

daggert 17 мар 2017 в 23:33

Фряха у меня на серверах стоит (:

MacIn 14 фев 2017 в 18:22

А можно вопрос — маздай тут при чем? Статья про Unix.

EvilFox 17 фев 2017 в 04:13

кто распакует в маздае, тот имеет право гнать на 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 (калечные права доступа, аудит… и много всего другого) могу, но времени да и желания в данный момент нет.

Fluorescent 17 мар 2017 в 23:12

адское заклинание или костыль? Костыль версус костыль, чей костыль лучше? )) Это никуда не годится, в Unix костыли более эргономические.

Fluorescent 17 мар 2017 в 23:30

Не может маздай то, чего в Unix'e с полпинка взлетает… раздел более 256 Терабайт не, никак (а уже скоро...), а файлов более 2 в 32 на раздел, тоже никак? Но зато всё красиво, это да… но за деньги. )
На работе сервак FreeBSD оцифровывает две вэб камеры на пне 2.8Ггц, одно ядро, 512 ОЗУ DDR, нагрузка около 100%. И маздай выполняет ту же задачу — вынь 7, две камеры, нагрузка 100%, но на четырёхядерном QX6800, 2 Гб ОЗУ. Мне как-бы ехать нужно, а не заклинания писать ))

daggert 17 мар 2017 в 23:39

У меня тут в организации винда 2000 работает на видеонаблюдении с 8 каналами аналоговыми, с 256 оперативкой и на третьем пне (: Я даже не заглядывал туда, только проц давеча поменяли на tualatin (джаст фо фан). Выводит все на телевизор через матрокс, ну и записывает на IDE диск. Умели раньше делать, не то что сейчас.

Fluorescent 19 июн 2017 в 11:43

в оптических мышах тоже камера работает с разрешением 32 пиксела на 32 пиксела ч\б. То, что работает на третьем пне, под маздаем, поедет на первом пне под фряхой…

daggert 19 июн 2017 в 12:22

Вы извините, но вы пишите глупости. Вы выше привели пример сами про 2 веб-камеры и весьма такой нехилый конфиг. У меня 8 (восемь) аналоговых камер и конфиг слабее на порядок, нагрузка 40-50%.

Сейчас ставлю рабочую машинку для IP камер под виндою 7, с слабеньким celeron'ом (на матплате впаянный) + 2 гига оперативки, SSD под систему и 4TB под записи. Вы готовы настроить на нем фряху так, чтоб он тянул 18 камер 24х7?

Fluorescent 19 июн 2017 в 13:23

FreeBSD всегда будет эффективнее при прочих равных условиях.
Разрешение, частота кадров, кодек? в данный момент у меня кодек h264+h265. 720p. Четыре камеры.
Маздай 24х7х365 не умеет по определению…
Слабенький целерон под виндой может и вытянет 120х240 без кодирования. Смотрел я такие видео, на них невозможно даже определить мужчина или женщина, так — силуэты движутся.
В Сони дураки сидят, да? https://habrahabr.ru/post/184426/ PS4 под фрёй работает, интересно, почему не на маздае 2000? ))

НЛО прилетело и опубликовало эту надпись здесь

daggert 19 июн 2017 в 14:31

>Разрешение, частота кадров, кодек? в данный момент у меня кодек 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 взять.

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

Подсказываю: Матрокс там для вывода на телевизоры, а не для сжатия.

Fluorescent 20 июн 2017 в 12:01

частота кадров? ))

daggert 20 июн 2017 в 12:49

Fluorescent 20 июн 2017 в 16:22

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

daggert 20 июн 2017 в 17:00

Вы неисправимы (: Вашу-бы энергию да в мирное-бы русло.

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

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

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

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

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

А зачем вы маздай юзаете? Я вот использую windows, причем приходится иметь дело с 2003+ на серверах и они вполне знаете-ли ничего, выполняют свою работу без нареканий.

Fluorescent 21 июн 2017 в 10:28

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

daggert 21 июн 2017 в 16:09

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

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

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

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

Вы вообще с аналоговыми тюнерами работали? Тем более во фряхе? Или я говорю просто с упрямым человеком? Вы в живую это проворачивали?

Fluorescent 22 июн 2017 в 11:01

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

DreamingKitten 22 июн 2017 в 11:39

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

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

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

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

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

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

daggert 22 июн 2017 в 13:25

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

Я не специалист по видеонблюдению, мне можно использовать любые удобные для себя термины. Могу использовать термин «плата видеозахвата с аппаратным декодированием», если он вам так нравится. И нет, вы не правы — хоть и декодирование до 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 украл наши знания…

По себе судите? (:

Fluorescent 19 июн 2017 в 13:28

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

Fluorescent 19 июн 2017 в 11:48

https://habrahabr.ru/post/184426/

НЛО прилетело и опубликовало эту надпись здесь

Fluorescent 19 июн 2017 в 11:39

ещё раз повторяю: на раздел. файлов в разделе. мне нужен один раздел и куча файлов в нём — маздай не может.

НЛО прилетело и опубликовало эту надпись здесь

Fluorescent 19 июн 2017 в 11:50

«Никому не понадобится большее 637 Кб оперативной памяти для персонального компьютера. 640 Кб должно хватить всем.» — © Билл Гейтс

https://habrahabr.ru/company/ruvds/blog/322138/

Saffron 14 фев 2017 в 11:12

Полностью разделяю ваше негодование молчаливым редактированием статей. Право на распространение модифицированных копий не означает право подписывать их вашим именем. Написали, допустим, вы «Гитлер убивал евреев. Фу таким быть», а вам последнее предложение поправили на «Всё правильно сделал». И никаких меток о правке — только ваше имя под публикацией. К кому, как вы думаете, ночью постучатся некомпетентные органы, кому будут предъявлять пропаганду фашизма? Да и просто общественная репутация будет подорвана.

Dessloch 14 фев 2017 в 11:18

Рискую навлечь на себя гнев фанатов Windows, не очень меня это беспокоит вобщем-то.
Вот ещё статейка в тему
https://habrahabr.ru/post/321696
слабо такое из под винды сделать?

divanikus 14 фев 2017 в 12:18

Вам пишут про недостатки у вас дома, а вы все разговор переводите в русло «а вот у соседа», «живи тогда у соседа». Смешно.

vbif 14 фев 2017 в 12:27

Как-бы, наоборот…

divanikus 14 фев 2017 в 13:14

Я вот всю статью еще раз пролистал, нигде не говорится прямо «а вот на винде!», разве что за исключением реестра и упоминания вскользь NTFS. Все остальные аргументы вообще не привязаны к другим системам и рассматривают проблемы именно UNIX. А тут часть товарищей все равно пытается свести все аргументы к «а вот на винде!»

MacIn 14 фев 2017 в 18:23

Как бы где?

vbif 14 фев 2017 в 18:51

Я просто неправильно понял реплику divanikus

mayorovp 14 фев 2017 в 12:28

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

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

daggert 14 фев 2017 в 12:51

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

saipr 14 фев 2017 в 15:46

Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат.

Зря вы так, даже в Советском Союзе ставили на UNIX.

Операционные системы: зачем они инженеру

saipr 14 фев 2017 в 15:59

safinaskar 14 фев 2017 в 20:11

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 дальше, просто не считайте его идеалом.

Holix 22 фев 2017 в 23:43

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

mayorovp 23 фев 2017 в 09:33

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

geher 14 фев 2017 в 20:55

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

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

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

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

safinaskar 15 фев 2017 в 17:24

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

Dessloch 15 фев 2017 в 17:58

Не надо никого ПОбеждать. Пишите в IDE, много и хорошо. Своим примером и Убедите.

Dessloch 15 фев 2017 в 07:07

Вот кстати статейка про лицензирование Windows в тему.
https://habrahabr.ru/post/321708/
Там речь идёт о миллионных суммах. А я поднял несколько корпоративных серверов-гейтов на Ubuntu
в небольших фирмах, у которых миллионов не было в бюджете.
О чём холивар, господа?)

u007 15 фев 2017 в 07:52

Статью можно не причёсывать, прям так в Microsoft отсылать. Отличное резюме на должность powershell-евангелиста :)

Dessloch 15 фев 2017 в 18:00

Вопрос приоритета Windoows-Linux может и спорный, но вот судя по минусам с чувством юмора у виндузятников явно не так хорошо как с продажами)

saintbyte 15 фев 2017 в 18:40

Назовите меня сектантом но никсы — это лучший из костылей который существует.

Shoooberoni 15 фев 2017 в 18:41

И еще одна задачка, которую с ходу не решить. В папке все текстовые файлы, и надо их разом переименовать например в 1.txt 2.txt и т.д. В графике Винды — за щелчок, в shell пришлось попотеть.

mayorovp 15 фев 2017 в 20:33

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

НЛО прилетело и опубликовало эту надпись здесь

Hellsy22 15 фев 2017 в 22:49

Минута на скрипт.

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

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

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

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

divanikus 16 фев 2017 в 02:39

Про prename из пакет perl не слышали?

safinaskar 15 фев 2017 в 19:54

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.

safinaskar 16 фев 2017 в 03:05

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…

tyderh 16 фев 2017 в 03:12

И он запускает новые программы на каждый чих.

Нет, не на каждый. man builtins. Например, даже в том идиотском примере никаких сотен процессов touch все равно не будет — touch как раз одна из этих встроенных функций.

Это не отменяет того, что в shell'е постоянно возникают проблемы со специальными символами.

Какими-же?

НЛО прилетело и опубликовало эту надпись здесь

tyderh 16 фев 2017 в 19:20

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

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

safinaskar 18 фев 2017 в 18:16

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

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

Denkenmacht 16 фев 2017 в 08:37

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

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

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

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

Antervis 16 фев 2017 в 09:14

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

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

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

aGGre55or 16 фев 2017 в 18:14

Собственно, bash слабей не только PHP, но даже и Бейсика из ПЗУ ZX Spectrum образца 1982 года.

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

tyderh 16 фев 2017 в 18:57

Теплое с мягким сравниваете, товарищ, надеюсь, вы не серьёзно.

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

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

aGGre55or 3 мар 2017 в 02:12

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

safinaskar 17 фев 2017 в 14:38

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

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

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

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

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

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

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

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

mayorovp 17 фев 2017 в 14:54

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

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

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

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

Free_ze 17 фев 2017 в 16:29

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

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

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

mayorovp 17 фев 2017 в 16:34

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

Free_ze 17 фев 2017 в 18:59

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

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

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

vintage 17 фев 2017 в 23:42

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

НЛО прилетело и опубликовало эту надпись здесь

vintage 18 фев 2017 в 00:00

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

Free_ze 18 фев 2017 в 11:41

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

Лейауты, подстраивающиеся под размеры содержимого.

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

Кроссплатформенность.

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

Ленивая подгрузка модулей.

Это тоже не уникальная возможность.

Крутейший отладочный инструментарий.

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

worldmind 17 фев 2017 в 23:31

> Веб, node.js и javascript — это шаг назад.

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

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

vintage 17 фев 2017 в 23:56

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

worldmind 18 фев 2017 в 00:17

Всё может быть, но поддержка юникода это вроде не того уровня проблема, да и в php как понимаю не было юникода от рождения

НЛО прилетело и опубликовало эту надпись здесь

vintage 18 фев 2017 в 11:39

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

НЛО прилетело и опубликовало эту надпись здесь

vintage 18 фев 2017 в 20:41

'E̋'.length // 2 OLOLO

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

НЛО прилетело и опубликовало эту надпись здесь

vintage 18 фев 2017 в 23:34

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

( "E"+"̋" ).length

НЛО прилетело и опубликовало эту надпись здесь

vintage 19 фев 2017 в 11:00

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

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

НЛО прилетело и опубликовало эту надпись здесь

safinaskar 19 фев 2017 в 14:43

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

vintage 19 фев 2017 в 16:38

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

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

safinaskar 19 фев 2017 в 19:15

. 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), должен уметь:

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

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

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

. vintage

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

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

. mayorovp

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

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

НЛО прилетело и опубликовало эту надпись здесь

mayorovp 19 фев 2017 в 15:38

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

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

возможность создавать юникодовые строковые литералы;
возможность вводить юникодовые строки при помощи стандартных средств;
возможность выводить юникодовые строки при помощи стандартных средств;
базовые операции над строками должны сохранять их корректными;
не-юникодовые строк в языке быть не должно.

safinaskar 18 фев 2017 в 18:13

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.

cjbars 18 фев 2017 в 19:22

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

safinaskar 18 фев 2017 в 19:52

Речь шла (как видно из кода) о замене файла на строки в нём, которые содержат bar. А не о дописывании этих строки

cjbars 19 фев 2017 в 08:49

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

safinaskar 19 фев 2017 в 13:04

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

cjbars 19 фев 2017 в 16:57

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

safinaskar 19 фев 2017 в 19:18

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

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

cjbars 20 фев 2017 в 06:48

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

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

#!/bin/bash
# script.sh
filename="$1"
echo "Действие 1 над файлом $1"
echo "Действие 2 над файлом $1"

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

Вполне себе переваривает «кривые» названия файлов. В чем крах и костылизм?

cjbars 20 фев 2017 в 07:50

сорри косякнул со скриптом, но сути это не меняет

#!/bin/bash
# script.sh
filename="$1"
echo "Действие 1 над файлом ${filename}"
echo "Действие 2 над файлом ${filename}"

safinaskar 20 фев 2017 в 19:02

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

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

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

dion 19 фев 2017 в 02:28

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? Покажите решение с удалением всех файлов определенного размера и сравните количество кода.

safinaskar 19 фев 2017 в 12:54

Почему-то в списках 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'а, да ещё и являющаяся полноценным языком программирования.

Mingun 19 фев 2017 в 13:08

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

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

maydjin 20 фев 2017 в 15:25

info sed | grep 'delete'

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

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

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

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

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

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

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

EvilFox 19 фев 2017 в 23:13

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

safinaskar 20 фев 2017 в 18:53

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

safinaskar 4 мар 2017 в 23:10

UPD от 2017-03-04: кто-то выполнил английский перевод. Обсуждение на Hacker News.

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

safinaskar 1 авг 2017 в 00:52

UPD от 2017-08-01.

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

И даже для этой цели echo использовать можно не всегда. Недавно прочитал, что в интерактивном старом bash нельзя писать echo "Hello, world!". Вот несколько абзацев текста, объясняющих суть проблемы и пути обхода. В новых bash такого нет, на моей системе не воспроизводится.

safinaskar 31 мая 2018 в 14:31

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

UNIX-подобные системы содержат кучу костылей. Крах «философии UNIX»

Комментарии 700

Публикации

Истории