Костыли в UNIX начали возникать ещё с момента появления UNIX, а это было ещё раньше появления не только Windows, но даже вроде бы Microsoft DOS (вроде бы, мне лень проверять, проверяйте сами). Если лень читать, хотя бы просмотрите все пункты, что-нибудь интересное найдёте. Это далеко не полный список, это просто те косяки, который я захотел упомянуть.
- В самом начале make был программой, которую один человек написал для себя и нескольких своих знакомых. Тогда он, недолго думая, сделал так, что командами воспринимаются строки, которые начинаются с Tab. Т. е. Tab воспринимался отлично от пробела, что крайне некрасиво и нетипично ни для UNIX, ни за его пределами. Он так сделал, потому что не думал, что make будет ещё кто-то использовать кроме этой небольшой группы. Потом появилась мысль, что make — хорошая вещь и неплохо бы включить его в стандартный комплект UNIX. И тогда чтобы не сломать уже написанные мейкфайлы, т. е. написанные вот этими вот десятью людьми, он не стал ничего менять. Ну вот так и живём… Из-за тех десятерых страдаем мы все.
- Почти в самом начале в UNIX не было папки /usr. Все бинарники размещались в /bin и /sbin. Но потом вся инфа перестала помещаться на тот диск, который был в распоряжении авторов UNIX (Томпсон, Ритчи). Поэтому они достали ещё один диск, создали папку /usr, а в ней — ещё один bin и ещё один sbin. И смонтировали новый диск в /usr. Оттуда и пошло. Так появилась «вторая иерархия» /usr, а потом в какой-то момент ещё и «третья иерархия» /usr/local, а потом ещё и /opt. Как пишет рассказчик этой истории: «Не удивлюсь, если когда-нибудь ещё появится /opt/local». UPD от 2017-02-12: я нашёл ссылку, где я почерпнул эту историю. Читайте, там более точная версия произошедшего.
- sbin изначально означало «static bin», а не «superuser bin», как можно было бы подумать. И содержал sbin статические бинарники. Но потом sbin стал содержать динамические бинарники, его название потеряло смысл.
- Windows часто ругают за наличие реестра и сообщают при этом, что подход UNIX-подобных систем (куча конфигов) якобы лучше. А между прочим однажды в ext4 появилась особенность (является ли это багом, вопрос спорный), из-за которой при резком выключении компа Gnome потерял все свои конфиги в рабочей папке юзера. И разработчик этой ext4 сказал в обсуждении баг репорта, что Gnome'у надо было использовать что-то вроде реестра для хранения инфы.
UPD от 2017-02-12: источники: раз и два. Имя отписавшегося maintainer'а ext4: Theodore Ts'o. Вот его слова:
If you really care about making sure something is on disk, you have to use fsync or fdatasync. If you are about the performance overhead of fsync(), fdatasync() is much less heavyweight, if you can arrange to make sure that the size of the file doesn't change often. You can do that via a binary database, that is grown in chunks, and rarely truncated.
I'll note that I use the GNOME desktop (which means the gnome panel, but I'm not a very major desktop user), and «find .[a-zA-Z]* -mtime 0» doesn't show a large number of files. I'm guessing it's certain badly written applications which are creating the «hundreds of dot files» that people are reporting become zero lengh, and if they are seeing it happen a lot, it must be because the dot files are getting updated very frequently. I don't know what the bad applications are, but the people who complained about large number of state files disappearing should check into which application were involved, and try to figure out how often they are getting modified. As I said, if large number of files are getting frequently modified, it's going to be bad for SSD's as well, there are multiple reasons to fix badly written applications, even if 2.6.30 will have a fix for the most common cases. (Although some server folks may mount with a flag to disable it, since it will cost performance.)
И это не говоря уж о том, что критичные файлы UNIX (такие как /etc/passwd), который читаются при каждом (!) вызове, скажем,ls -l, записаны в виде простого текста. И эти файлы надо заново читать и заново парсить при каждом вызовеls -l! Было бы гораздо лучше использовать бинарный формат. Или БД. Или некий аналог реестра. Как минимум, для вот таких вот критичных для производительности ОС файлов.
Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called «PC loser-ing» because the PC is being coerced into «loser mode,» where «loser» is the affectionate name for «user» at MIT.
The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.
— The Rise of «Worse is Better» By Richard Gabriel
Если кратко и своими словами, то в начале разработки UNIX авторы UNIX решили попросту выдавать ошибку из ядра пользовательской программе, если пользовательская программа прервана по сигналу, и на этот сигнал повешен обработчик. Иными словами, если вы перехватили Ctrl-C (т. е. поставили на него обработчик) в своей программе, а юзер за терминалом нажал этот самый Ctrl-C, то ОС выполнит обработчик, а потом вместо простого продолжения того сисвызова, который выполнялся в момент Ctrl-C, просто прервёт его, вернув из ядра в пользовательскую программу EINTR. В результате программисту, пишущему эту программу придётся эту EINTR предусмотреть. А это усложняет этот userspace код. Ценой упрощения кода ядра. Да, нужно было сделать по-другому. Усложнить код ядра и упростить userspace код, который придётся писать всем программистам. Но тому человеку из Беркли из цитаты выше было пофигу. Он фактически сказал: «Да мне пофиг, что все будут страдать, главное, чтоб код ядра попроще был».
Дальше — больше. Позже в UNIX-системах всё же пофиксили упомянутую особенность, добавив так называемый SA_RESTART. То есть вместо того, чтобы просто всё пофиксить, они добавили специальный флаг. Так мало того, что они это сделали, этот SA_RESTART ещё и не всегда работает! В частности, в GNU/Linux select, poll, nanosleep и др. не продолжают свою работу после перехваченного прерывания даже в случае SA_RESTART!
- Вообще, конкретные обстоятельства, возникшие во время разработки оригинальной UNIX, сильно оказали на неё влияние. Скажем, читал где-то, что команда cp названа именно так, а не copy, потому что UNIX разрабатывали с использованием терминалов, которые очень медленно выдавали буквы. А потому набрать cp было быстрее, чем copy. UPD от 2017-02-12: найти именно ту ссылку, которую я видел когда-то давно, и в которой приводился пример с cp и copy, мне не удалось. Но есть, например, вот эта ссылка.
Commands — Are These Real Words?
The basic AIX commands (and all UNIX system commands) are, for the most
part, very short, cryptic, two-letter command names. Imagine back years ago,
when computers had only very slow teletype keyboards and paper “displays.”
(Some of us aren’t imagining, we’re remembering!) Imagine also, people who
didn’t like typing long commands because there was such a long delay between
commands and the computer response. If there were any mistakes, the user had
to retype the whole thing (especially aggravating for folks that type with only
two fingers!).
Also, some UNIX commands came from university students and researchers who
weren’t bound by usability standards (no rules, merely peer pressure). They
could write a very useful, clever command and name it anything—their own initials,
for example (awk by Aho, Weinberger, and Kernighan), or an acronym
(yacc, Yet Another Compiler-Compiler).
- Вообще, названия утилит UNIX — это отдельная история. Скажем, название grep идёт от командй g/re/p в текстовом редакторе ed. (Ну а cat — от concatenation, я надеюсь, это все и так знали :) Ну и для кучи: vmlinuz — gZipped LINUx with Virtual Memory support).
- printf внезапно является далеко не самым быстрым способом вывода информации на экран или в файл. Не знали, да? А дело в том, что printf, как и сама UNIX в целом, был придуман не для оптимизации времени, а для оптимизации памяти. printf каждый раз парсит в рантайме строку формата. Именно поэтому в веб сервере H2O был придуман специальный препроцессор, который переносит парсинг строки формата на этап компиляции.
UPD от 2017-02-12: источник.
- Когда Кена Томпсона, автора UNIX (вместе с Деннисом Ритчи) спросили, что бы он поменял в UNIX, он сказал, что назвал бы функцию creat (sic!) как create. UPD от 2017-02-12: источников полно, например этот. No comments. Замечу, что позже этот же Кен Томпсон вместе с другими разработчиками оригинальной UNIX создал систему Plan 9, исправляющую многие недостатки UNIX. И в ней эта функция называется create :) Он смог :)
- Ещё одна цитата:
A child which dies but is never waited for is not really gone in that it still consumes disk swap and system table space. This can make it impossible to create new processes. The bug can be noticed whenseveral & separators are given to the shell not followed by ancommand without an ampersand. Ordinarily things clean themselves upwhen an ordinary command is typed, but it is possible to get into asituation in which no commands are accepted, so no waits are done;the system is then hung.The fix, probably, is to have a new kind of fork which creates aprocess for which no wait is necessary (or possible); also to limit the number of active or inactive descendants allowed to a process.
— Источник
Это цитата из очень раннего манула UNIX. Уже тогда существование зомби-процессов признавалось багом. Но потом на этот баг попросту забили. Понятное дело, что гораздо позже эта проблема всё же была решена. Т. е. в современном GNU/Linux инструменты для убивания зомби-процессов всё же существуют. Но о них мало кто знает. Обычном kill'ом зомби не убиваются. Про существование зомби-процессов все говорят: «It's for design».
- Ещё немного про уже упомянутый язык C. Вообще язык C разрабатывался одновременно с UNIX, поэтому критикуя UNIX, нужно покритиковать и C тоже. То, что C очень плох, написано много, я не буду повторять все эти аргументы. Там, синтаксис типов плохой, препроцессор ужасен, легко выстрелить себе в ногу, всякие
4["string"], всякиеsizeof ('a') != sizeof (char)(в C, не в C++!), всякиеi++ + ++i, всякиеwhile (*p++ = *q++) ;(пример из Страуструпа, второе дополненное издание) и так далее и тому подобное.
Скажу лишь вот что. В C до сих пор не научились удобно работать со строками. Неудобство работы со строками постоянно приводит к разнообразным проблемам безопасности. И эту проблему до сих пор не решили! Вот относительно свежий документ от комитета C. В нём обсуждается весьма сомнительный способ решения проблемы со строками. И делается вывод, что этот способ плох. Год публикации: 2015. То есть даже к 2015-му году окончательного решения ещё нет!
И это не говоря об отсутствии простой, удобной и мультиплатформенной системы сборки (а не этого монстра autotools, который ещё и не поддерживает винду, и другого монстра cmake, который поддерживает винду, но всё равно монстр), стандартного менеджера пакетов, удобного как npm (js) или carge (rust), нормальной portability library, с помощью которой можно было кроссплатформенно хотя бы прочитать содержимое папки и хотя бы даже главного сайта C, который был бы главной точкой входа для всех новичков и содержал бы в себе не только документацию, но и краткую инструкцию по установке инструментов C на любую платформу, по созданию простого проекта на C, а также содержал бы удобный поиск по пакетам C (которые должны быть размещены в стандартном репозитории) и, главное, был бы точкой сбора user community. Я даже зарегал домен c-language.org в надежде, что когда-нибудь я создам там такой сайт. Эх, мечты, мечты. (У меня ещё cpp-language.org заныкан, бугога :)) Но всего этого нет. Хоть это и есть у всех популярных языков, кроме C и C++. И даже у Haskell всё это есть. И у Rust.
У Rust, у этого выскочки, который, кстати говоря, метит в ту же нишу, что и C. Есть единый конфиг, который одновременно является конфигом проекта, конфигом сборки и конфигом для менеджера пакетов (собственно, cargo — это менеджер проектов и система сборки одновременно). Есть возможность указания в качестве зависимости для данного пакета другого пакета, размещённого где-то в *GIT*, в том числе указание в качестве зависимости напрямую программы на *GITHUB*. Генерация из коробки документации из сорцов, записанной в комментах на *MARKDOWN*. И пакетный менеджер, использующий для версий *SEMVER*. Итак, *GIT*, *GITHUB*, *MARKDOWN*, *SEMVER*, короче говоря *BUZZWORDS*, *BUZZWORDS* и ещё раз *HIPSTERS' BUZZWORDS*. И всё сразу из коробки. Прямо вот заходишь на их главный сайт, и вот на тебе на блюдечке с голубой каёмочкой. И работает всё одинаково на всех платформах. Несмотря на то, что Rust — это вроде как язык системного программирования, а не какой-нибудь там javascript. Несмотря на то, что в Rust можно байты гонять. И арифметика указателей там есть. Так почему же у них, у этих выскочек-растовцев, эти хипстерские баззворды есть, а у нас, сишников, их нет? Обыдно.
Я помню, один знакомый спрашивает у меня, где посмотреть список пакетов для C/C++. Пришлось сказать ему, что такого единого места нет. Он: «Программисты на C/C++ должны страдать?» Мне нечего было ему ответить.
Ах да, забыл ещё одну вещь. Посмотрите, пожалуйста, на прототип функции signal в том виде, в котором он дан в стандарте C:void (*signal(int sig, void (*func)(int)))(int);и попытайтесь его понять.
- Терминал в UNIX — жуткое legacy.
- Имена файлов в файловых системах UNIX (ext2 и пр.) есть просто поток байтов без кодировки. В какой кодировке они будут интерпретированы, зависит от локали. То есть если создать файл на ОС в одной локали, а потом пытаться посмотреть его имя в ОС в другой локали, будет плохо. В виндовом NTFS такой проблемы нет.
- UNIX shell хуже PHP! Да, да, а вы что, не знали? Сейчас модно ругать PHP. Но ведь UNIX shell ещё хуже :) Особенно плохим он становиться, если пытаться на нём программировать, ведь полноценным языком программирования он не является. Но даже для своей ниши (скриптинг типичных задач по администрированию) он годится плохо. Виной тому примитивность shell, непродуманность, legacy, куча частных случаев, костылей, бардак с кавычками, бекслешами, специальными символами и повёрнутость shell'а (как и всего UNIX) на простом тексте.
- Начнём с затравки. Как рекурсивно найти в папке
fooвсе файлы с именем\? Правильный ответ таков:find foo -name '\\'. Ну или так:find foo -name \\\\. Последний вариант вызовет особенно много вопросов. Попробуйте объяснить человеку, плохо разбираемущемуся в UNIX shell, почему здесь нужно именно четыре бекслеша, а не два и не восемь (грамотеи, подскажите, как правильно написать это предложение, пишите в личку). А написать здесь нужно четыре бекслеша, потому что UNIX shell делает backslash expanding, и find тоже его делает.
- Как touch'нуть все файлы в папке foo (и во вложенных)? На первый взгляд, один из способ таков:
find foo | while read A; do touch $A; done. Ну, на первый взгляд. На самом деле здесь можно придумать аж 5 нюансов, которые могут испортить нам малину (и привести к проблемам с безопасностью):
- Имя файла может содержать бекслеш, поэтому нужно писать не
read A, аread -r A. - Имя файла может содержать пробел, поэтому нужно писать не
touch $A, аtouch "$A". - Имя файла может не только содержать пробел, но и начинаться с пробела, поэтому нужно писать не
read -r A, аIFS="" read -r A. - Имя файла может содержать перевод строки, поэтому вместо
find fooнужно использоватьfind foo -print0, а вместоIFS="" read -r Aнужно использоватьIFS="" read -rd "" A(тут я не совсем уверен). - Имя файла может начинаться с дефиса, поэтому вместо
touch "$A"нужно писатьtouch -- "$A".
Итоговый вариант выглядит так:find foo -print0 | while IFS="" read -rd "" A; do touch -- "$A"; done. Круто, да? И здесь мы, кстати, не учли, что POSIX не гарантирует (я не совсем в этом уверен), что touch поддерживает опцию--. Если учитывать ещё и это, то придётся для каждого файла проверять, что он начинается с дефиса (или что не начинается со слеша) и добавлять в начало./. Теперь вы поняли, почему скрипты configure, генерируемые autoconf'ом такие большие и трудночитаемые? Потому что этому configure нужно учитывать всю эту муть, включая совместимость с разными shell'ами. (В данном примере для демонстрации я использовал решение с пайпом и циклом. Можно было использовать решение с -exec или xargs, но это было бы не так эффектно). (Ладно, хорошо, мы знаем, что имя файла начинается с foo, поэтому оно не может начинаться с пробела или дефиса).
- Имя файла может содержать бекслеш, поэтому нужно писать не
- В переменной A лежит имя файла, нужно удалить его на хосте a@a. Как это сделать? Может быть так:
ssh a@a rm -- "$A"(как вы уже заметили, мы тут уже учли, что имя файла может содержать пробелы и начинаться с дефиса)? Ни в коем случае! ssh — это вам не chroot, не setsid, не nohup, не sudo и не какая-нибудь ещё команда, которая получает exec-команду (т. е. команду для непосредственной передачи сисвызовам семейства execve). ssh (как и su) принимает shell-команду, т. е. команду для обработки shell'ом (термины exec-команда и shell-команда — мои). ssh соединяет все аргументы в строку, передаёт строку на удалённую сторону и там выполняет shell'ом. Окей, может быть так:ssh a@a 'rm -- "$A"'? Нет, эта команда попытается найти переменную A на удалённой стороне. А её там нет, потому что переменные через ssh не передаются. Может, так:ssh a@a "rm -- '$A'"? Нет, это не сработает, если имя файла содержит одинарную кавычку. В общем, не буду вас мучать, правильный ответ таков:ssh a@a "rm -- $(printf '%q\n' "$A")". Согласитесь, удобно?
- Как зайти на хост a@a, с него — на b@b, с него — на c@c, с него — на d@d, а с него удалить файл /foo? Ну, это легко:
ssh a@a "ssh b@b \"ssh c@c \\\"ssh d@d \\\\\\\"rm /foo\\\\\\\"\\\"\""
Слишком много бекслешей, да? Ну, не нравится так, давайте чередовать одинарные и двойные кавычки, будет не так скучно:
ssh a@a 'ssh b@b "ssh c@c '\''ssh d@d \"rm /foo\"'\''"'
А между прочим, если бы вместо shell'а был Lisp, и там функция ssh передавала бы на удалённую сторону не строку (вот она, повёрнутось UNIX на тексте!), а уже распарсенный AST (abstract syntax tree), то такого ада бекслешей не было бы:
(ssh "a@a" '(ssh "b@b" '(ssh "c@c" '(ssh "d@d" '(rm "foo")))))
«А? Что? Lisp? Что за Lisp?» Интересно, да? На, читайте. И другие статьи Грэма. На русском тоже можно найти.
- Совместим предыдущие два пункта. Имя файла лежит в переменной A. Нужно зайти на a@a, с него — на b@b, далее на c@c, d@d и удалить файл, лежащий в переменной A. Это я оставляю вам в качестве упражнения :) (Сам я не знаю, как это сделать :) Ну, может, придумаю, если подумаю).
- echo вроде как предназначен, чтобы печатать на экран строки. Вот только использовать его для этой цели, если строчка чуть сложнее, чем «Hello, world!», нельзя. Единственно верный способ вывести произвольную строку (скажем, из переменной A) таков:
printf '%s\n' "$A".
- Допустим, нужно направить stdout и stderr команды cmd в /dev/null. Загадка: какие из этих шести команд выполняют поставленную задачу, а какие — нет?
cmd > /dev/null 2>&1 cmd 2>&1 > /dev/null { cmd > /dev/null; } 2>&1 { cmd 2>&1; } > /dev/null ( cmd > /dev/null ) 2>&1 ( cmd 2>&1 ) > /dev/null
Оказывается, правильный ответ — 1-я, 4-я и 6-я выполняют, 2-я, 3-я и 5-я — не выполняют. Опять-таки, выяснение причин этого оставляется в качестве упражения :)
- Начнём с затравки. Как рекурсивно найти в папке
- Вообще, этот пост появился в ответ на вот этот пост. Там говорилось, мол, в винде специальная дата используется как метка драйвера от Microsoft. Вместо ввода специального аттрибута или проверки производителя. Особенностей такого рода в UNIX полно. Является ли файл скрытым, выясняется на основе наличия точки в начале файла вместо специального аттрибута. Когда я сам впервые об этом узнал (да, да, в те далёкие времена, когда я впервые поставил Ubuntu), я был шокирован. Я подумал, вот идиоты. А сейчас привык. Но если вдуматься, это жуткий костыль. Далее, shell выясняет, является ли он login shell'ом на основе дефиса, переданного первым символом в
argv[0](?!). Это abuses (ну или misuses, неправильно использует, не знаю, как по-русски сказать)argv[0].argv[0]не для этого предназначен. Вместо какого-нибудь другого способа. Любой другой способ был бы красивее. Как угодно, любым другим аргументом, переменной окружения.
- В BSD sockets юзер вынужден сам менять порядок байт у номера порта. А всё потому, что когда-то давно кто-то допустил в коде ядра UNIX ошибку, не предусмотрев смену порядка байт. И в качестве временного хака исправил user space код вместо кода ядра. Так и живём. Оттуда это и в Windows перешло (вместе с файлом
/etc/hosts, он жеC:\windows\system32\drivers\etc\hosts).
UPD от 2017-02-12: источник.
«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX». Так вот, как вы уже начали догадываться, это не совсем так. Давайте разберём эту «философию UNIX» по пунктам. Сразу скажу: я не хочу сказать, что все пункты нужно отменить, просто я указываю на их неуниверсальность.
- «Всё есть текст». Как мы с вами уже выяснили на примере /etc/passwd, повсеместное использование простого текста может привести к проблемам с производительностью. И вообще, авторы UNIX фактически придумали для каждого системного конфига (passwd, fstab и так далее) свой формат. Со своими правилами экранирования специальных символов. Да, а вы что думали? /etc/fstab использует пробелы и переносы строк как разделители. Но что если имена папок содержат, скажем, пробелы? На этот случай формат fstab'а предусматривает специальное экранирование имён папок. Так что любой скрипт, читающий fstab, оказывается, должен это экранирование интерпретировать. Например, с помощью специально предназначенной для этого утилиты fstab-decode (запускать от рута). Не знали, да? Идите исправляйте свои скрипты :) В результате для каждого системного конфига нужен свой парсер. И было бы гораздо проще, если бы для системных конфигов использовался вместо этого какой-нибудь JSON или XML. А может быть даже некий бинарный формат. Особенно для тех конфигов, которые постоянно читаются разными программами. И для которых, как следствие, нужна хорошая скорость чтения (а у бинарных форматов она выше).
Я не закончил по поводу «всё есть текст». Стандартные утилиты выдают вывод в виде простого текста. Для каждой утилиты фактически нужен свой парсер. Часто приходится парсить вывод той или иной утилиты при помощи sed, grep, awk и т. д. У каждой утилиты свои опции для того, чтобы установить, какие именно столбцы нужно выдавать, по каким столбцам нужно сортировать вывод и т. д. Было бы лучше, если бы утилиты выдавали вывод в виде XML, JSON, некоего бинарного формата или ещё чего-нибудь. А для удобного вывода этой информации на экран и для дальнейшей работы с ней можно было бы пайпить результат в дополнительные утилиты, которые убирают те или иные столбцы, сортируют по тому или иному столбцу, выбирают нужные строки и т. д. И либо выводят результат в виде красивой таблички на экран, либо передают его куда-то дальше. И всё это универсальным способом, не зависящим от исходной утилиты, которая сгенерировала вывод. И без необходимости парсить что-либо регексами. Да, UNIX shell плохо работает с JSON и XML. Но ведь у UNIX shell полно других недостатков. Нужно выкинуть его вовсе и заменить на некий другой язык, который помимо всего прочего может удобно работать со всякими JSON.
Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом (и без xargs). Как это сделать? Вот так:LC_ALL=C ls -l | while read -r MODE LINKS USER GROUP SIZE M D Y FILE; do if [ "$SIZE" -gt 1024 ]; then rm -- "$FILE"; fi; done. (LC_ALL здесь нужен был, чтобы быть уверенным, что дата будет занимать именно три слова в выводе ls). Мало того, что это решение выглядит некрасиво, оно ещё страдает рядом недостатков. Во-первых, оно не будет работать, если имя файла содержит перевод строки или начинается с пробела. Далее, нам нужно явно перечислить названия всех столбцов ls, ну или как минимум помнить, на каком месте находятся интересующие нас (т. е. SIZE и FILE). Если мы ошибёмся в порядке столбцов, то ошибка выяснится лишь на этапе выполнения. Когда мы удалим не те файлы :)
А как бы выглядело решение в идеальном мире, который я предлагаю? Как-то так:ls | grep 'size > 1kb' | rm. Кратко, а главное смысл виден из кода, и невозможно ошибиться. Смотрите.lsв моём мире всегда выдаёт всю инфу. Специальня опция -l для этого не нужна. Если нужно убрать все столбцы и оставить только имя файла, то это делается специальной утилитой, в которую нужно направить вывод ls. Итак, ls выдаёт список файлов. В некоем структуированном виде, скажем, JSON. Это представление «знает» названия столбцов и их типы, т. е. что это, строка, число или что-то ещё. Далее этот вывод направляется в grep, который в моём мире выбирает нужные строки из этого JSON. JSON «знает» названия полей, поэтому grep «понимает», что здесь означает «size». Более того, JSON содержит инфу о типе поля size. Он содержит инфу о том, что это число, и даже что это не просто число, а размер файла. Поэтому можно сравнить его с1kb. Далее grep направляет вывод в rm. rm «видит», что он получил файлы. Да, да, JSON ещё и хранит инфу о типе этих строк, о том, что это — файлы. И rm их удаляет. А ещё JSON отвечает за правильное экранирование специальных символов. Поэтому файлы со спецсимволами «просто работают». Круто? Идею я взял отсюда (там ещё есть ссылка на более подробный английский оригинал), посмотрите. Ещё замечу, что в Windows Powershell реализовано как раз что-то похожее на эту идею.
- UNIX shell. Ещё одна базовая идея UNIX. Причём о мелких недостатках UNIX shell я уже поговорил в первой части статьи. Сейчас будут крупные. В чём «крутость» UNIX shell? В том, что на момент своего появления (это было очень давно) UNIX shell был гораздо мощнее командных интерпретаторов, встроенных в другие ОС. И позволял писать более мощные скрипты. Да и вообще, на момент своего появления UNIX shell был, видимо, самым мощным из скриптовых языков вообще. Потому что нормальных скриптовых языков, т. е. таких, которые бы позволяли полноценное программирование, а не только скриптинг, тогда, видимо, вообще не существовало. Это потом уже в один прекрасный день один программист по имени Larry Wall заметил, что UNIX shell всё-таки недостаёт до нормального языка программирования. И он захотел соединить краткость UNIX shell'а с возможностью полноценного программирования из C. И создал Perl. Да, Perl и другие последующие скриптовые языки программирования фактически заменили UNIX shell. Это константирует даже Роб Пайк, один из авторов (как я считаю) той самой «философии UNIX» (про него мы ещё поговорим). Вот здесь на вопрос об «одной утилите для одной вещи» он сказал: «Those days are dead and gone and the eulogy was delivered by Perl». Причём я считаю, что эта его фраза относилась к типичному использованию UNIX shell, т. е. к ситуации связывания большого количества маленьких утилит в shell-скрипте. Нет, говорит Пайк, просто используйте Perl.
Я не закончил про UNIX shell. Рассмотрим ещё раз пример кода на shell, который я уже приводил:find foo -print0 | while IFS="" read -rd "" A; do touch -- "$A"; done. Здесь в цикле вызывается touch (да, я знаю, что этот код можно переписать на xargs, причём так, чтобы touch вызывался только один раз; но давайте пока забьём на это, хорошо?). В цикле вызывается touch! То есть для каждого файла будет запущен новый процесс! Это нереально неэффективно. Код на любом другом языке программирования будет работать быстрее этого. Просто на момент появления UNIX shell он был одним из немногих языков, которые позволяют написать это действие в одну строчку.
Короче говоря, вместо UNIX shell нужно использовать любой другой скриптовый язык программирования. Который подходит не только для скриптинга, но и для реального программирования. Который не запускает новый процесс каждый раз, когда нужно «touch'нуть» файл. Возможно, понадобится «доложить» в этот скриптовый язык средства для простого выполнения вещей, которые есть в shell, скажем, для создания пайпов.
- Простота. Здесь я говорю не конкретно про shell и про связывание кучи простых утилит из shell'а (про это был предыдущий пункт), а про простоту вообще. Использование простых инструментов. Скажем, редактирование картинки sed'ом. Да, да. Конвертим jpg в ppm при помощи командной строки. Затем при помощи графического редактора, grep, sed и такой-то матери редактируем картинку. А потом обратно в jpg. Да, так можно. Но часто photoshop'ом или gimp'ом всё-таки лучше. Хоть это и большие, интегрированные программы. Не в стиле UNIX.
На этом я закончу эти пункты. Да, хватит. Есть идеи в UNIX, которые мне реально нравятся. Скажем, «программа должна делать одну вещь и делать её хорошо». Но не в контексте shell. Вы уже поняли, что я не люблю shell. (Ещё раз повторю, я считаю, что в приведённом выше интервью Пайка он воспринял принцип «программа должна делать одну вещь и делать её хорошо» именно в контексте shell и потому отверг его). Нет, я говорю про этот принцип в своей сути. Скажем, консольный почтовый клиент не должен иметь встроенный текстовый редактор, он должен просто запустить некий внешний редактор. Или вот принцип, по которому нужно писать консольное ядро для программы и потом графическую оболочку для этого ядра.
Теперь общая картина. Однажды появился UNIX. На момент появления он был прорывом. И он был во многом лучше своих конкурентов. UNIX имел много идей. И, как и любая ОС, UNIX требовал от программистов соблюдения некоторых принципов при написании прикладных программ. Идеи, лежащие в основе UNIX, стали называться «философией UNIX». Одним из тех людей, которые сформулировали философию UNIX, был уже упомянутый Роб Пайк. Он это сделал в своей презентации «UNIX Style, or cat -v Considered Harmful». После презентации он вместе с Керниганом опубликовал статью по мотивам презентации. В ней авторы рассказали о том, что, скажем, предназначение cat — это только конкатенация и ничего больше (ну то есть «склеивание» файлов, мы с вами помним, как расшифровывается cat, так ведь?). Возможно, что это Пайк как раз и придумал «философию UNIX». В честь этой презентации был назван сайт cat-v.org, почитайте его, очень интересный сайт.
Но потом, через много лет, этот же Пайк сделал ещё две презентации, в которых, как я считаю, отменил свою философию обратно. Поняли, фанатики, да? Ваш кумир отказался от своей же философии. Можете расходиться по домам. В первой презентации «Systems Software Research is Irrelevant» Пайк сетует на то, что никто больше не пишет новых ОС. А даже если и пишут, то просто ещё один UNIX (который подразумевается в этой презентации уже чем-то неинтересным): «New operating systems today tend to be just ways of reimplementing Unix. If they have a novel architecture — and some do — the first thing to build is the Unix emulation layer. How can operating systems research be relevant when the resulting operating systems are all indistinguishable?»
Вторую презентацию Пайк прямо называет: «The Good, the Bad, and the Ugly: The Unix Legacy». Пайк говорит, что простой текст не универсален, он хорош, но работает не всегда: «What makes the system good at what it's good at is also what makes it bad at what it's bad at. Its strengths are also its weaknesses. A simple example: flat text files. Amazing expressive power, huge convenience, but serious problems in pushing past a prototype level of performance or packaging. Compare the famous spell pipeline with an interactive spell-checker». Далее: «C hasn't changed much since the 1970s… And — let's face it — it's ugly». Дальше Пайк признаёт ограниченность пайпов, соединяющих простые утилиты, ограниченность регексов.
UNIX был гениальным на момент своего появления. Особенно, если учесть, какие инструменты были в распоряжении у авторов UNIX. У них не было уже готового UNIX, чтобы на нём можно было разрабатывать UNIX. У них не было IDE. И программировали они вообще на ассемблере изначально. У них, видимо, был только ассемблер и текстовый редактор.
Люди, стоящие у истоков UNIX, в определённый момент начали писать новую ОС: Plan 9. В том числе упомянутые Томпсон, Ритчи и Пайк. Учитывая многие ошибки UNIX. Но и Plan 9 никто не возводит в абсолют. В «Systems Software Research is Irrelevant» Пайк упоминает Plan 9, но несмотря на это всё равно призывает писать новые ОС.
James Hague, ветеран программирования (занимается программированием с восьмидесятых) пишет: «What I was trying to get across is that if you romanticize Unix, if you view it as a thing of perfection, then you lose your ability to imagine better alternatives and become blind to potentially dramatic shifts in thinking» (ссылка). Прочитайте эту статью и его же статью «Free Your Technical Aesthetic from the 1970s», на которую он ссылается. (Вообще, если вам понравилась моя статья, то и его блог тоже, наверное, понравится, погуляйте там по ссылкам).
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют. Мой текст обращён скорее к фанатикам UNIX и GNU/Linux. Провокационный тон просто чтобы привлечь ваше внимание.
UPD от 2017-02-14: комментаторы указывают, что сравнивать UNIX shell с PHP некорректно. Конечно, некорректно! Потому что UNIX shell не претендует на то, чтобы быть полноценным языком программирования, он предназначен для скриптинга системы. Вот только я в одно время этого не знал. И вдобавок считал UNIX shell прекрасным. Вот для людей в таком же положении я всё это и говорю. Ещё как минимум один комментатор говорит, что сравнивать UNIX shell нужно с cmd. Я бы сказал, что сравнивать надо с Windows Powershell. Последний, как я уже говорил, в чём-то превосходит UNIX shell.
UPD от 2017-02-14: мне понравился вот этот коммент от sshikov:
Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу...» — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.
Да, в этом-то и всё дело! Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат. А использовать-то UNIX можно.
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 дальше, просто не считайте его идеалом.
UPD от 2017-02-15: habrahabr.ru/post/321652/#comment_10070776.
UPD от 2017-02-15: habrahabr.ru/post/321652/#comment_10071096.
UPD от 2017-02-15: habrahabr.ru/post/321652/#comment_10071714.
UPD от 2017-02-16: понравился этот коммент: habrahabr.ru/post/321652/#comment_10066240.
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. Да, да, всю эту цепочку языков, используемых при генерации окончательного мейкфайла.
Один комментатор приводит следующие принципы 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. Или, может, какой-нибудь формат для структуированных данных, который ещё не изобрели.
Многие указали на искусственность некоторых примеров на 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…
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.
Комментарии (660)
dipsy
12.02.2017 07:19-16Да, всё так. Я бы ещё проехался по любимому языку юниксоидов — голым сям, Уже лет 20 нет ни одной причины не использовать вместо него си с плюсами, даже для системных вещей, тем более что в с-стиле можно и на плюсах прекрасно писать.
А вообще проблема не в юникс, не в прочих ос или инструментах, проблема в людях. Из любой достаточно долгоживущей и сложной системы, над которой работает масса людей, по факту получается свой клубок костылей с велосипедами, можно даже никакие статьи с критикой не читать. Панацеи тут быть не может, поэтому просто надо набираться опыта и самому делать хорошо. Получится не сразу, а когда начнет получаться, будет уже поздно. Выхода нет, смиритесь.S_A
12.02.2017 08:33-4На работе всегда говорю, «ошибки не в людях, а в сервисах». Люди не ошибаются, они делают не всегда то что от них кому-то хочется. А вот сервисы уже предназначены для того, чтобы делать то, что хочется его владельцу, поэтому если делают не то — ошибаются.
NeoCode
12.02.2017 11:09+3Проблема в том что для системного программирования кроме С и С++ пока к сожалению ничего нет (ну вот появился Rust но он еще мало распространен… да и с синтаксисом некоторые вопросы к интуитивности, в тех же же C# или Java все гораздо более понятно, причем сходу, без необходимости погружаться в нюансы языка).
dipsy
12.02.2017 18:58-6Ну так большая разница же, с и с++, я про что и пытался сказать. С++ рулит, в отличие от.
safinaskar
12.02.2017 21:29+13C++ — это такой ужасный монстр. И иногда вместо C++ нужно использовать C. Чтобы вместо вот этого монстра использовать монстрика поменьше
Antervis
13.02.2017 05:19Настоящая причина использовать Си вместо С++ в 90% случаев куда тривиальнее: отсутствие компилятора С++ для конкретного устройства. Никто же не заставляет использовать все эти «монструозные» вещи типа буста, можно даже писать большую часть кода на общем подмножестве.
dipsy
13.02.2017 12:43+5Монстры только у людей в головах. Ничего же не мешает вам писать на ++ в стиле си и аккуратно использовать некоторые полезные плюшки, тот же RAII, но без фанатизма, без буста, без лямбд.
А вот в голом си приходится изголяться, дефайны, goto, MyObject_DoSomething(MyObject* self) и прочие радости.safinaskar
14.02.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.02.2017 06:18+3Потом выясняется, что нужно либо запретить копирование для этого объекта, либо реализовать в конструкторе копирования dup. И не зависимо от выбранного варианта нам нужно уметь возвращать наш объект из функции, а для этого уже нужен конструктор перемещения, а это уже C++11
Ох уж эта аргументация. Ну напишете вы около 8 строчек кода, не облысеете. Зато потом не придется перебирать все точки возврата из всех функций работающих с файлом, все обработчики ошибок и т.д. чтобы нигде не забыть закрыть этот хендлер.
https://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus
напомнило
saterenko
13.02.2017 10:49+3Я раза 3-4 порывался перейти с C на C++, даже в некоторых больших проектах на плюсах принимал участие, но не прёт меня от них, всегда возвращался к голому C. Единственное, чего мне не хватает на «голом» по сравнению с плюсами — это libslave (скоро допишу свою на сях), нормальной библиотеки под протобуф и RapidJSON (тоже можно пережить).
Голый C прекрасен, просто он не всем подходит.
0xd34df00d
14.02.2017 18:25+3Так это про любой язык можно сказать, что он прекрасен, просто не всем подходит.
MacIn
14.02.2017 18:27+4BF вообще замечательный, его лаконичность потрясает. А если вам не нравится, то вы просто школотроны, единственно на что способные — кнопки по формам расставлять. Fixed for ya.
kekekeks
12.02.2017 13:07+13Уже лет 20 нет ни одной причины не использовать вместо него си с плюсами, даже для системных вещей, тем более что в с-стиле можно и на плюсах прекрасно писать.
Есть. libstdc++ во флешу не пролазит. Толстая слишком.
dipsy
12.02.2017 19:06-23А вот эта вся экономия на копеечных флэшах она как правило боком выходит рано или поздно. Должен быть запас минимум в 2 раза, если планируется хоть какое-то минимальное развитие продукта. У нас тоже в свое время в одном из продуктов лет 12 назад наэкономили, поставили 4ГБ, и рамки впритык. Потом через 2-3 года сразу в 8 раз запас сделали, экономия сильно убыточная вышла по факту.
kekekeks
12.02.2017 19:28+414ГБ
У нас 32КБ
0xd34df00d
12.02.2017 20:49+4На attiny младших ещё меньше, и ничего, на плюсах писать вполне можно. Без экзепшонов и rtti, конечно, но плюсы ими не ограничиваются.
kekekeks
13.02.2017 01:16Ну я их в итоге завёл там без стандартной библиотеки путём выключения лишнего во флагах компиляции и написанием заглушек под хлам типа
__verbose_terminate_handler. Что не отменяет упитанности libstdc++.
neit_kas
13.02.2017 04:17+2А вы вкурсе, что есть ОС (стоит отметить, *nix ОС) под всякие встраиваемые системы и МК? Там такая память только в очень сладких снах может сниться.
dipsy
13.02.2017 11:32-3Я где-то говорил что предлагаю всем 4 гига ставить? Это пример был, из личного опыта. Если у Вас 32 КБ (это наверное что-то космическое суперотказоустойчивое), то можно взять запас до 64 КБ, да в конце концов, из любого правила есть и исключения, пишите в этом случае на си, на здоровье, не надо же все советы так буквально воспринимать, а то я смотрю народ прям переволновался. Под 32 кб можно и на асме написать.
kekekeks
13.02.2017 14:11можно взять запас до 64 КБ
У меня не получалось упихнуть libstdc++ и в 64 кб. Говорю же, толстая слишком. А без неё запас неплохой есть, да.
billyevans
13.02.2017 02:51+1Так не нужно использовать std от C++. Это чудовищное поделие. Там из полезного только exceptions, но я думаю их как-нить можно вынуть оттуда, не таща с собой весь остальной хлам.
А сам С++ с RAII и остальным весьма крут, хотя сильно больше нюансов, чем в голом С.dipsy
13.02.2017 12:37-3<сарказм>
Не оскорбляйте святое. Люди привыкли писать на голом С, это развивает внимательность, аккуратность. Сделал, как говорится, fopen, не забудь про fclose, да и код получается длинный, солидный. А все эти ваши гейские RAII — не нужны и не влазят в 8 кБ памяти, особенно если boost весь ещё заинклюдить.
</сарказм>
Antervis
13.02.2017 19:06-1Механизм исключений без RAII бесполезен. Плюс, очень удивительно, что вы выделяете самую запрещаемую в проектах фичу языка как его основное преимущество
billyevans
13.02.2017 19:19+1Ну так я и говорю, что нужно RAII + exceptions. Но их реализация находится в райтайме С++. Хз кем и где она запрещена. Везде, где писал на С++ все использовали исключения и RAII как самое базовое, что С++ предоставляет по сравнению с голым С.
То, что это в публичном стайлайде гугла написано, так это сильно не так внутри и сильно зависит от команд и наличия легаси кода. А изначально это пошло из-за плохой реализации исключений в старых компилярах с точки зрения производительности.
poxvuibr
14.02.2017 01:00+2То, что это в публичном стайлайде гугла написано, так это сильно не так внутри и сильно зависит от команд и наличия легаси кода
Вот что написано в публичном стайлгайде гугла.
On their face, the benefits of using exceptions outweigh the costs, especially in new projects.
Antervis
14.02.2017 06:20+1А изначально это пошло из-за плохой реализации исключений в старых компилярах с точки зрения производительности.
никогда не понимал и не пойму, какая разница, насколько шустро отрабатывается исключительная ситуацияmayorovp
14.02.2017 08:51Так в том-то и дело, что, по слухам, раньше включенная поддержка исключений замедляла программу даже в неисключительных ситуациях.
billyevans
14.02.2017 11:23Верно, но старая реализация исключений просаживала производительность просто от куска try-catch. То есть даже той ветви, которая успешная.
На хабре где-то было про реализацию исключений статья.
Siemargl
14.02.2017 13:35В нынешний век интерпретаторов и П-кода это не то чтобы просадка, это погрешность измерений =)
Там расходы были — пяток лишних ассемблерных инструкций.
MacIn
14.02.2017 18:06Нет, ну overhead есть даже если нет исключений. Скажем, в Windows надо для каждого try, в том числе скрытого, создать элемент SEH, а в конце — удалить его. Да, это мизер.
Tujh
13.02.2017 07:41+1libstdc++ во флешу не пролазит. Толстая слишком.
Давно, если честно, не смотрел, но были же проекты uclibc++ и подобные, все умерли?
Hellsy22
12.02.2017 07:33+43И эти файлы надо заново читать и заново парсить при каждом вызове ls -l! Было бы гораздо лучше использовать бинарный формат. Или БД. Или некий аналог реестра. Как минимум для вот таких вот критичных для производительности ОС файлов.
Не стоит недооценивать производительность текстовых файлов.
Собственно, какая вам разница, будет ли конец строки обозначать символ \0 или символ \n?
SQLite/Berkley или на таких размерах проиграют по производительности.
Полагаю, что чтение и парсинг /etc/passwords выиграет по скорости у чтения из реестра на порядки. Но это все в целом не важно, потому что роль идет даже не о миллисекундах — я набросал простенький скрипт на perl, он с парсит /etc/passwd с помощью регулярного выражения 100 тысяч раз за ~3s.
printf внезапно является далеко не самым быстрым способ вывода информации на экран или в файл
Форматируемый вывод оказывается не самый быстрый вывод! Я прямо-таки потрясен этим откровением. А нет, не потрясен. Это все написано в любой книге по С.
Lsh
12.02.2017 12:14+2Собственно, какая вам разница, будет ли конец строки обозначать символ \0 или символ \n?
Скорее, в случае с БД, она ничем заканчиваться не будет, будет указан её размер.
/etc/passwords маленький файл для примера. А вот с большим файлом, со сложным форматом (вложенные секции, например), выигрыш будет на стороне БД. Файл не надо будет разбирать на строки, и эти строки парсить в дерево.poxvuibr
15.02.2017 16:25Скорее, в случае с БД, она ничем заканчиваться не будет, будет указан её размер.
В postgresql, например, безразмерные строки будут незначительно быстрее строк с фиксированным размером.
fshp
20.02.2017 17:06+1Вы путаете "fixed size strings" и "pascal strings".
"Безразмерные" строки в postrgesql как раз паскалевские и хранят свой размер (каламбур).
rPman
12.02.2017 12:22+2Предполагается что у баз данных есть индексы и самое главное контроль целостности до записи(имеется в виду завершение транзакции), чего нет у идеологии 'все есть текст', т.е. в случае с /etc/passd об ошибке скорее всего узнаем по факту использования.
0xd34df00d
12.02.2017 21:26+4Форматируемый вывод оказывается не самый быстрый вывод!
Дело не в этом, а в том, что строка формата разбирается каждый раз во время выполнения.
Поэтому, например, иногда оказывается, что пресловутые ужасные iostreams из плюсов быстрее — там эта информация в виде инструкций в исходном коде закодирована, ничего в рантайме разбирать не надо.
safinaskar
12.02.2017 21:41-1Форматируемый вывод оказывается не самый быстрый вывод! Я прямо-таки потрясен этим откровением. А нет, не потрясен. Это все написано в любой книге по С.
Окей, может быть вы это уже знали. А я это в своё время не знал. Я и подумать не мог, что, оказывается, вот этот вот дефолтный момент в C неэффективен. Я думал, что не могли же умные дядьки ошибиться и какую-то ерунду мне подсунуть. Естественно, в какой-то момент я начал догадываться, что форматный вывод неэффективен. Но опять-таки, я подумал, что раз C делали умные дядьки, то, видимо, он не до такой степени медленный. Но нет, как я выяснил от автора H20, форматный вывод таки существенно медленнее неформатного. Ну вот я сейчас этим откровением с Хабром делюсь.
Вдобавок, во многих реализациях стандартной библиотеки C++ (как минимум до недавнего времени) потоки ввода-вывода были реализованы поверх форматных функций C! (Facepalm!) То есть в API C++ строк формата уже нет, внутри всё можно реализовать без них. Но эти идиоты всё равно внутри пихают форматные строки. Чтоб медленнее было. Я-то думал, что программисты умные. Что реализуют всё всегда как надо. Как бы не так! Есть ли этот баг по-прежнему в основных реализациях стандартной библиотеки C++, я не знаю. Вполне мог остаться
0xd34df00d
12.02.2017 22:23Там, где мне, наверное, единожды за последние года три это было важно, istream был быстрее scanf.
Ну а самым быстрым вариантом был mmap + парсер на boost::spirit + boost::string_view. Но это так, заодно к слову о монстрах C++ vs C.
xtotec
12.02.2017 21:45+18Особенно умиляет твердокаменная уверенность в том, что при крахе системы у бинарной конфигурации больше шансов выжить, чем у текстовой.
Оставляя за скобками такой важный нюанс, что текстовую конфигурацию, при повреждении, куда легче и быстрее восстановить вручную, чем бинарную без дополнительного специфического инструментария
sumanai
12.02.2017 22:32-7Бинарные сами следят за своей целостностью. Убить реестр внезапным ребутом почти не реально.
Jef239
12.02.2017 23:41+5юзеры ещё не то могут убить… Приходилось чинить. Там не все в двух копиях, вообще-то.
xtotec
13.02.2017 00:01Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно. До этого — сколько угодно.
Тем не менее — если регистр повреждён (да даже действиями пользователя) до степени незагужаемости системы, это требует специфических инструментов для ремонта, в отличии от текстовых конфигов.
С точки зрения производительности системы, можно хранить в памяти результат чтения текстовых конфигов и обращаться к нему (рано или поздно вся эта концепция systemd к такому и приведёт).tmnhy
13.02.2017 00:28Согласен — начиная с 7ки, угрохать регистр падением системы стало практически невозможно.
Отключение питания на этапе загрузки убивает реестр и на 7. Никогда не понимал логики, зачем надо писать в реестр до логина пользователя.sumanai
13.02.2017 01:01На каком? Как минимум до этапа chkdsk ОС точно ничего на диск не пишет.
tmnhy
13.02.2017 01:37На каком?
Где-то в районе анимированного бут-лого или сразу за ним.aikixd
13.02.2017 16:18У меня есть многострадальный комп, которым мне лень заниматься. Для кино и всякого. У него что-то с железом, что он часто ресетится. Иногда не включается. Но проводом подергал и завелось. Пару раз вис и не загружалась винда из за одного диска. Я его и сам не жалею. Долго выключается — ресет, долго думает — ресет, долго не включается — ресет. Винде по барабану. Живет не тужится.
tmnhy
13.02.2017 16:29Долго выключается — ресет, долго думает — ресет, долго не включается — ресет
В вашем опыте ключевое слово «долго», т.е. весь io уже закончился.
В моём опыте, всё внезапно и с железом всё нормально — старт системы, потеря питания, «убитый» реестр.
Показательно, что это не единичные случаи, несколько раз восстанавливал юзерские, когда в нервах ресет жмут на загрузке. И у себя словил 2 раза, чистой воды невезение, один раз аккум ноута в 0 ушёл на загрузке, второй раз электросети «уронили» десктоп.
xtotec
13.02.2017 01:05Ну как зачем — процесс сверки обнаруженных устройств с существующими с last known good, например, или ещё какое-нибудь вуду. Регистр — он не для пользователя, по большому счёту, точнее у пользователя есть свой кусочек, в профиле, куда и начнут писАть, после того как он залогинится.
Я уже было решился спросить у человека какие именно технические детали позволяют ему с таким апломбом утверждать о самовосстановлении регистра (а вдруг?), а тут вы пришли и… разрушили мою веру в светлое бинарное завтра юникс-систем.sumanai
13.02.2017 01:10Ну как зачем — процесс сверки обнаруженных устройств с существующими с last known good
Запись там идёт только после успешного логина + задержка, что и свидетельствует об успешной загрузке.
Я уже было решился спросить у человека какие именно технические детали позволяют ему с таким апломбом утверждать о самовосстановлении регистра
Зачем восстанавливать то, то не упало? Механизмы записи в реестр сделаны для поддерживания его консистентного состояния при обрыве записи, а транзакционные механизмы NTFS не дают сработать и им.
neit_kas
13.02.2017 04:24BCD хранит свои конфиги в кусте реестра. Хотя правда не в курсе, он только читает или ещё и пишет?
sumanai
13.02.2017 01:00-3До этого — сколько угодно.
Не соглашусь. На своей XP я никогда не видел разрушение реестра. Хотя и вырубал и во время загрузки, и во время выключения.xtotec
13.02.2017 01:08+2На вкус и на цвет все фломастеры разные — может у вас контроллер диска какой дружелюбный. То, что молния никогда в вас не попадала, вовсе не значит, что она не попадала в других людей.
sumanai
13.02.2017 01:10Я использовал весьма разное оборудование. Видимо, я везунчик.
vintage
13.02.2017 09:17Возможно дело в том, что раньше можно было ставить систему на FAT32 раздел со всеми вытекающими ;-)
vorphalack
13.02.2017 11:40на NTFS оно точно также в капусту билось, но как правило очень невоспроизводимо. какой-нить race condition при записи в глубине дискового стека, совпадающий с зависанием/вырубанием системы.
TrurlMcByte
20.02.2017 19:31А зачем там регулярка, там же фиксированный набор полей? Тот же GAWK в таких случаях (простые текстовые файлы с фиксированным набором полей) вообще рвет всех. Причем даже на гигабайтных простынях данных.
Hellsy22
12.02.2017 07:54+30Про существование зомби-процессов все говорят: «It's for design».
Зомби-процесс — это завершенный дочерний процесс, который не «похоронен» родителем — по сути, от процесса остается минимальная запись в таблице процессов, содержимое буферов обмена и код завершения.
Обычном kill'ом зомби не убиваются
Убиваются, конечно же, только целиться надо в родителя. Пример: kill $(ps -A -ostat,ppid | awk '/[zZ]/{print $2}')
Долгие и пространные рассуждения про shell забавны в своей надуманности, но хотелось бы отметить, что сравнивать его возможности надо не с возможностями php, а с возможностями cmd.tgz
12.02.2017 10:39+3А если родитель еще нужен?
tmnhy
12.02.2017 11:04+1Если есть зомби, то с родителем не всё в порядке, т.е. он уже не нужен.
tgz
12.02.2017 11:30+8А если там критичные данные? Например ваша зарплата за год.
tmnhy
12.02.2017 11:33-7Вы сейчас о чём говорите, какие критичные данные, какая зп?
Если есть зомби, то скорее всего родителя уже нет. Просто нет. Нет, от слова совсем. Со всеми данными.tgz
12.02.2017 11:46+4Все понятно. В следующий раз рекомендую высказываться на тему в которой хоть немного разбираетесь.
masai
12.02.2017 15:04+8Если есть зомби, то скорее всего родителя уже нет. Просто нет. Нет, от слова совсем. Со всеми данными.
Зомби-процесс — это дочерний процесс, родитель которого не удосужился получить код завершения через wait. Если родитель умирает, то зомби наследуется init, который его без сожалений убивает.
То есть, наличие зомби говорит о том, что родитель как раз есть. Другое дело, что в нём баг, но процесс есть.
Не понимаю, за что заминусовали tgz.
kmu1990
12.02.2017 15:07+1Не в качестве несогласия с вашим комментарием, а как небольшая поправка. Когда родитель умирает дочерний процесс определенно наследуется каким-то другим процессом, но это совсем не обязательно именно init.
masai
12.02.2017 15:20Да, согласен. Просто осиротевшего зомби в *NIX усыновляет процесс с PID=1, а его по инерции часто init называют. Хотя, конечно, всё может быть и по-другому.
kmu1990
12.02.2017 15:32+7Опять же не совсем верно. Кто наследует дочерний процесс после смерти родителя «implementation defined», т. е. это не обязательно init или процесс с pid=1. Более того в linux вообще может быть несколько процессов, которые собирают осиротевших детей (смотрите man prctl ту часть где описывается PR_SET_CHILD_SUBREAPER).
masai
12.02.2017 15:48+2Ага, спасибо! Просто у Стивенса и Раго именно про PID=1 написано. Ну, теперь буду знать. :)
tmnhy
12.02.2017 15:20Sic!
masai
12.02.2017 15:23Это как-то подтверждает ваши слова, что наличие зомби свидетельствует о смерти родителя? Или что вы хотели сказать?
tmnhy
12.02.2017 15:35-1Или что вы хотели сказать?
К сожалению я не могу голосовать за комментарии, приходится выделять тот, который поддерживаю так как могу.
Зомби жив, пока родитель через wait состояние не получит. Единственное разумное, почему родитель этого не делает (я не беру в расчет отсутствие в коде этой возможности) — родителя уже нет или он не в состоянии нормально работать.tgz
12.02.2017 16:25А если у родителя просто нужный тред заблокировался на IO, а все остальное хорошо и в порядке?
tgz
12.02.2017 16:12-1Просто хипстеры не умеют так:
29755 pts/0 Ss 0:01 \_ /bin/zsh
6123 pts/0 S+ 0:00 | \_ ./zombie
6124 pts/0 Z+ 0:00 | \_ [zombie]
[some magic]
29755 pts/0 Ss 0:01 \_ /bin/zsh
6123 pts/0 S+ 0:00 | \_ ./zombie
И зомби умер. Без убивания папы.
ximaera
12.02.2017 22:51+1А если RAM сдохнет? Или контроллер? Или питание вырубится?
Если ваша зарплата за год имеется только в оперативной памяти одного сервера, валить надо из такой конторы.tgz
12.02.2017 23:23+1Следуя этой логике можно сделать rm -rf /, а объяснить все тем, что мог ведь и контроллер сдохнуть. В маразм не впадайте. Ваша зарплата зависит от ваших действий, а не от того что лежит в памяти конкретного сервера.
ximaera
12.02.2017 23:28Нет, следуя этой логике, нельзя сделать rm, потому что логика в том, чтобы не хранить критически важные данные только в оперативной памяти одного процесса на одном сервере.
tgz
13.02.2017 09:00Маразм все же побеждает. Перечитайте изначальный пост, вопрос был не про зарплату. По существу есть что сказать?
Nordicx86
13.02.2017 08:03+1да что вы обычная черная бухгалтерия… все на RAM диске и бекап в крипте в облако в Зимбабве…
kmu1990
12.02.2017 11:55+4Если родитель нужен, то вполне может быть, что этому родителю нужна информация о том, как скончался его ребенок (код возврата, короче), так что какую-то информацию о завершившемся процессе все равно придется сохранть. Zombie процесс — просто способ сохранить эту информацию до тех пор, пока ее не запросит родитель.
Но если вам это не нужно, то вы можете просто поправить обработчик SIGCHLD и вот вам автоматическая сборка этих Zombie. Это всего одна строка кода, так что не супер тяжелая задача.tgz
12.02.2017 12:01-2Как вставить 1 строчку кода в уже запущенный бинарник?
kmu1990
12.02.2017 12:10+3Если процесс не собирает своих детей, то значит они ему нужны и значит Zombie процессы должны быть, либо это просто недосмотр со стороны программиста(ов), который написали программу. Странно винить Unix за недосмотр программистов.
tgz
12.02.2017 15:43-2Где я винил unix?
kmu1990
12.02.2017 15:45+1Ок нигде. Тогда что к обсуждению должен был добавить ваш вопрос про то, как вставить 1 строчку кода в уже запущенный бинарник?
tgz
12.02.2017 16:18Наверно понимание того что вставить строчку нельзя по условию задачи.
kmu1990
12.02.2017 16:22Какой задачи? Избавиться от zombie? Так вроде как я вам выше объяснил, что zombie либо может быть нужен родителю и от него не нужно избавляться, либо родитель содержит ошибку — и это уже совсем другая история, исправлять ошибку в программе позволяя небезопасное действие странно.
tgz
12.02.2017 16:31А если зомби не нужен?
Вот прямо сейчас на ноуте:
20157 ? Ssl 0:09 gvim
20163 ? Z 0:00 \_ [python3]
Зомби мне не нужен, а vim содержит несохраненные данные.kmu1990
12.02.2017 16:33+4Операционная система не знает ничего о логике приложения, она просто не может узнать, что zombie больше не нужен. Zombie будет удален тогда, когда гарантированно известно, что он не нужен и не раньше.
Если программа порождает дочерние процессы и не собирает их, хотя они ей не нужны — это бага в программе. Ее нужно фиксить в программе.tgz
12.02.2017 17:11Ну так кроме ОС у нас еще есть админ. А у админа есть некоторые инструменты.
kmu1990
12.02.2017 17:18+2То что админ есть, не значит, что ОС должна разрешать потенциально небезопасные действия (а убийство дочернего процесса, без разрешения родительского процесса — потенциально опасное действие, потому что логика родительского процесса может быть к этому не готова). Давайте все программы будут лазить друг к другу в память — админ же есть, он всех хулиганов накажет.
tgz
12.02.2017 17:59kill -9 потенциально небезопасен, но ОС же позволяет это делать, не так ли?
kmu1990
12.02.2017 18:10Так, а еще kill позволяет избавиться от zombie убив родителя, не так ли? И если родитель не собирает своих детей, хотя должен — то убивать нужно именно его, а не уже мертвый процесс, который ни в чем не виноват. Но как и всегда с kill -9 вы делаете это на свой страх и риск и не жалутесь на то, что в приложении могут быть несохраненные данные. Так что строго говоря, у администратора, который сам себе придумывает несуществующую проблему zombie процессов, все таки есть средство, чтобы с ними побороться.
tgz
12.02.2017 22:42Средство есть, только это совсем не kill -9 для папы.
kmu1990
13.02.2017 00:09То есть вы утверждает, что где-то в стандарте posix описывается способ удаления zombie, который не сводится к вызову wait со стороны процесса родителя и гарантированно работает? Поделитесь выдержкой из Posix или SUS.
tgz
13.02.2017 09:29-2А с чего это должно быть написано в стандарте? У вас есть стандарт как ложку ко рту подносить? Нет? А кушаете как?
kill -9 ppid в посиксе описан?kmu1990
13.02.2017 10:24+1У вас такая бурная реакция на все стандарты или только на те, что вам не нравятся? Касательно вашего вопроса, нет у меня нет стандарта как подносить ложку ко рту, но ложку ко рту я подношу себе сам, а не прошу это делать за меня какого-нибудь дядю. С другой стороны еда, которую я покупаю в магазине чтобы есть, стандартам соответствовать должна — потому как я не делаю ее сам.
Но возвращаясь к делу, стандарт — это форма описания гарантий. После всей той драмы, которую вы тут развели про зарплату, было бы странно если бы ваше решение не предоставляло разумных гарантий надежности. И под гарантииями надежности я имею ввиду что-то сильнее чем «я попробовал и у меня работает». А теперь вы можете сказать что-нибудь по существу?
eagr
15.02.2017 18:40Если родитель нужен, пробуем ему послать SIGCHILD, но скорее всего это не поможет. Тогда цепляемся к родителю через gdb, и от родителя уже запускаем waitpid() на pid зомби-процесса:
# gdb (gdb) attach 19595 (gdb) call waitpid(19698,0,0) $1 = 19698 (gdb) detach
sshikov
12.02.2017 10:51+3А зачем сравнивать шелл с возможностями cmd? Не, ну серьезно? Зачем выбирать какое-то другое древнее дерьмо мамонта и сравнивать с ним?
Если мне что-то нужно автоматизировать в windows — я возьму вовсе не cmd.kekekeks
12.02.2017 13:17+9Ну так и на линуксе народ автоматизацию на питоне сейчас каком-нибудь пишет.
sshikov
14.02.2017 09:24+1Я вам больше скажу — у JavaEE контейнера Weblogic внутри тоже jython. И это удобно.
Разница в том, что для управления чем-то при помощи скриптов изнутри есть API, а не предлагается вызывать команды, которые вернут неструктурированный поток байтов типа stdin.
Ну т.е. нормальная современная полноценная автоматизация — это вовсе не шелл, в его оригинальном виде. Ну и не cmd конечно же.
avost
12.02.2017 13:50+8Ну, а если вам надо что-то автоматизировать в юниксах, то вы можете взять даже шелл. А можете любой вариант из десятков других. Но в простейш4м варианте даже на шелл можно что-то делать вменяемое.
volkanin
12.02.2017 08:03+7Очень похоже на выдержки из Unix Haters Handbook. Прочитать эту книгу для общего развития нужно, но в работе использовать не стоит :)
powerman
12.02.2017 08:25+13К сожалению, их более новые и продуманные системы, где решены многие из упомянутых проблем — OS Plan9, OS Inferno — не взлетели. Не нужны народу элегантные системы, в которых нет этих костылей — наверное, скучно без них. Я много лет работал с OS Inferno, и это буквально "открыло глаза" на многие проблемы *NIX. Пока радует только рост популярности Go, может хоть одна из их попыток хоть немного исправить сверх-популярные UNIX и C спустя 40 лет окажется относительно успешной.
tgz
12.02.2017 10:45+2Возможно redox взлетит…
NeoCode
12.02.2017 11:35+9К сожалению, какой бы хорошей не была система, она скорее всего не взлетит. Нужно пробить огромную инертную массу в виде существующих и как-то работающих технологий, решений, знаний и специалистов. Это зачастую гораздо сложнее чем придумать что-то новое и гениальное.
Lsh
12.02.2017 12:17+5Нужно пробить огромную инертную массу в виде существующих и как-то работающих технологий, решений, знаний и специалистов.
ЕМНИП, создатели Plan9 именно так и говорили. Поэтому и не взлетело.
neit_kas
13.02.2017 04:36+1Не нужны народу элегантные системы
Думаю, проблема немного не в этом. Проблема кроется в бизнесе, где хотят минимальной жертвой получить как можно больше.
S_A
12.02.2017 08:30+24Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют.
Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.
И да, есть такое дело, «отвергаешь — предлагай». Более удобный GUI, сравнимый по производительности с Shell, новые GUI-утилиты, способные склеиваться выводом-вводом (да хоть TermKit) — и без copy-paste, так как я не хочу повторять свои «макросы» Mega-GUI-Shell руками, да еще и параметры хочу.
Что касается C… вас кто-то уговаривает на нём писать? Make кстати вчистую уже тоже давно никто не использует. Можно продолжать, но зачем, «скажите спасибо что» прокомментировал.sshikov
12.02.2017 10:54+7>Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.
Вы правы. Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу...» — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.
Хотя наверное не в таком стиле, все таки — а именно предлагая что-то взамен.
divanikus
12.02.2017 12:33+5> Вы критикуете недостатки полувековой давности, которые в повседневной работе уже давно обернуты современными инструментами.
Seriously? Многие аспекты системы до сих пор представляют собой кучи шелл-скриптов различной степени упоротости. Sysvinit, всякие утилиты для упаковки-распаковки пакетов и т.д. Я даже утилиты для работы с ФС на шелле видел. Паковали когда-нибудь свои приложения? debscripts? rpmbuild? Ага, можно взять fpm и не париться! Но как же post/pre install/uninstall хуки? Я уж не говорю, что сами по себе обертки это часто тоже скрипты. Сейчас правда модно стало говнокодить на питоне, а не на шелле.
dartraiden
12.02.2017 14:45+4Sysvinit
Его таки начали закапывать, хотя, не всем это нравится (но не будем разводить ту холивар на тему Sysvinit vs systemd).
EviGL
13.02.2017 21:44Ну статья написана в ответ на статью «в винде в дате драйверов есть кривое легаси, которое ни на что не влияет но оно кривое». Вполне адекватный ответ, в UNIX-подобных тоже есть кривое легаси.
MzMz
12.02.2017 09:21+15man hier
/usr/local — хранит локально собранное ПО, которое не управляется пакетным менеджером и не входит в первоначальный состав системы.
/opt — обычно для самодостаточного ПО, которое упаковано не по файловому стандарту *nix. Я например туда Oracle JDK всегда распаковываю.
kelevra
12.02.2017 09:58+18надеюсь, что автор только в статье создаёт себе сложные препятствия, которые героически преодолевает. иначе могу только посочувстовать.
NLO
12.02.2017 10:18НЛО прилетело и опубликовало эту надпись здесь
sumanai
12.02.2017 16:21+2Все распространенные операционные системы (возможно, кроме некоторых негражданских и риалтайм систем) фактически основаны на ОС UNIX
Windows? POSIX там только сбоку прикручен.
Lirein
12.02.2017 19:32+2Будете удивлены, но «И ты… Брут!». Современная Windows NT писалась совместно с IBM как раз таки на базе UNIX, в итоге после развала сотрудничества родилось две системы — Windows NT и OS/2. Которая умерла, если мне не изменяет память в 2012 году в связи со снятием с тех. поддержки, а до тех пор успешно использовалась в банкоматах. К слову файловая система HPFS поддерживалась вплоть до NT4.
Именно из юникса у ядра NT очень много корней и Legacy наследия, которое сначала выпиливали, теперь возвращают. Фактически уникальность NT — это универсальное ядро, поверх которого работала подсистема Windows и Unix, а сейчас Windows и Linux.kmu1990
12.02.2017 19:38+5Я может плох в истории, но один из, так сказать, главных дизайнеров Windows NT Дейв Катлер является одним из самых известных хейтеров Unix, и как раз делал все по-другому. Можно каких-то подробностей по Unix legacy в ядре NT?
Lirein
12.02.2017 20:00+7Начнем с самого простого и очевидного (то что на виду), любое устройство является файлом, для доступа к устройствам используется виртуальная файловая система, драйверы рабоатют либо на уровне ядра (порты ввода вывода, DMA), люо в юзерспейсе как драйверы-фильтры (с хендлером файла устройства).
Второе как следствие — драйверы фильтры, работающие с файловой системой.
Третье — буквы дисков являются абстракцией и/или фикцией, точки монтирования маппятся как буквы дисков или прямо в файловую систему. При большом желании сейчас так можно маппить даже сетевые шары (экспериментально, но...)
Символические и жесткие ссылки в ФС перепиливались и видоизменялись, но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).
Дальше — это организация архитектуры процессов и… Обработки сигналов. Да, я знаю что исторически в Windows используются сообщения, но часть сигналов осталась на уровне ядра, в юзерспейсе они регистрируются отдельными вызовами API, такие как Ctrl+Break или Ctrl+C.
На самом деле действительно очень многие вещи были переписаны и в мире Unix на тот момент некоторых реализаций не существовало, того же автоматического пересканирования шины и так называемого autohotplug (подключение устройств на горячую — USB, PCMCIA, IEEE1394 и т.д.).
Тема обширная, и каие то вещи рядовому разработчику сейчас не встречаются, чаще с этим имеют дело только разработчики драйверов устройств, или специализированного ПО.
Кстати, DNS в Windows Server это таки незначительно переписанный ISC Bind 9.kmu1990
12.02.2017 20:34Я вот про буквы дисков и точки монтиования не понял. Точки монтирования позволяют примонтировать ФС где мне угодно, т. е. я контроллирую под каким именем будет известна та или иная партиция диска или та или иная виртуальная файловая система. В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Я не думаю что пользователь — это Unix специфичное расширение. Понятие пользователя было до Unix-а и нет ничего удивительно в том, что NTFS их хранит, аналогичная история с режимом доступа. Более того VFS — теперь совершенно привычная вещь для Unix, для Windows не совсем. Так что я бы не сказал, что Windows ФС это Unix legacy.
Про архиетктуру процессов — слишком абстрактно, так что не могу никак прокомментировать. Само понятие процесса существовало и до Unix, интереснее что специфично от Unix-а взято.
TaHKucT
12.02.2017 20:49+1> В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)kmu1990
12.02.2017 20:58Ну ссылка которую вы привели тоже не на самый первый NT ссылается (и не могу найти в статье информации о версиях NT, в которых эта фича поддерживается), так что нельзя утверждать что это Unix legacy. Вполне могу представить, что они это потом впили, дабы угодить особенно привередливым клиентам. Есть ли что-нибудь постарше?
Lirein
12.02.2017 21:05+1В командной строке есть утилита diskpart, и в управлении компьютером — оснастка «Управление дисками». Windows Server 2012 (на базе исходников LVM, как указала MS) привносит Storage Spaces — запустите и откроете для себя много нового.
Ссылка ниже показывает впервые появившуюся команду в юзерспейсе для монтирования дисков.
Я имею в виду запись вида user:group , ну к примеру 0:0 7777 (root:root rwt,rwS,rws). В двоичном виде это три шестнадцатеричных слова.
Можно я не буду вдаваться в особенности межзадачного взаимодействия в первых ядрах NT? :)
Материал довольно большой, да и освящен довольно неплохо в книгах для разработчиков.kmu1990
12.02.2017 21:23Ну скажем так, LVM, даже если забыть про Windows, я бы не назвал Legacy — он не такой уж старый (1998, это уже linux 2.4, да и windows nt повяился несколько раньше, если мне не изменяет память) и не настолько уж типичный для Unix-ов в целом.
Какая разница как выглядит запись? Я например редко пользуюсь такой записью, хоть и сижу на Linux (предпочитаю буквенные обозначения). Это всего лишь форма представления — не самая существенная часть.
Меня интересует не интерфейс. Многие концепции на самом деле не специфичны именно для Unix-а и существовали до него. Меня как раз интересует то, что внутри, т. е. как они реализованы. Чтобы можно было ткнуть пальцем и сказать — вот это вы ребята сперли из BSD (как, например, некоторые считают про сетевой стек BSD). Не так уж много книг, которые покрывают эти части.
safinaskar
14.02.2017 02:32Откройте в винде (XP или 7) "Управление компьютером", далее "Управление дисками", выберите какой-нибудь раздел и там "Сменить имя диска или путь к диску". Там можно удалить букву диска и назначить ему вместо этого путь, куда надо монтировать. Далее в винде есть ключ/ветка реестра MountedDevices, я вот тут писал: https://geektimes.ru/post/156749/
z3apa3a
12.02.2017 23:36+2но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).
Это не так. Собственное в NTFS нет как таковых фиксированных аттрибутов, вместо этого есть понятие альтернативных потоков файла. В основном потоке данных содержится собственно содержимое файла, в альтернативных — все что угодно. Это могут быть разрешения (DACL), информация для аудита (SACL), сведения об источнике файла (например что файл загружен через Интернет) и вообще все, что угодно, включая POSIX-совместимые аттрибуты. Набор альтернативных потоков у каждого файла может быть свой.
P.S. и ИМХО это очень красивый подход.sumanai
13.02.2017 01:06-1Собственное в NTFS нет как таковых фиксированных аттрибутов
Только для чтения, скрытый, системный, архивный, сжатый, разрежённый, индексируемый, зашифрованный. Это как минимум, и это атрибуты, а не альтернативные файловые потоки.
P.S. и ИМХО это очень красивый подход.
И не используется. В десятке используютсякостылиотдельная база данных с разрешениями POSIX.
К тому же в этом подходе есть проблемы- все потоки теряются при копировании на ФС без их поддержки, например, FAT. Досталось это при обеспечении совместимости с OS/2 в стародавние времена. Ну и у EXT3 и некоторых других ФС Linux есть похожие механизмы.z3apa3a
13.02.2017 01:49+5Не совсем так. Тут есть определенная путаница с терминами. В NTFS термин «аттрибут» используется для записи с данными, в этом плане данные файла и альтернативные потоки тоже являются аттрибутами. Указанные вами аттрибуты хранятся как часть аттрибута $STANDARD_INFORMATION, т.е. $STANDARD_INFORMATION от альтернативного потока отличает только тип аттрибута, альтернативные потоки имеют тип $DATA.
Incidence
14.02.2017 11:23-2Начнем с самого простого и очевидного (то что на виду), любое устройство является файлом,
С точки зрения программиста юзерспейса, любое устройство является таки хэндлом, а не файлом. И даже не только устройство, а ещё всякие там мютексы, события и прочее. То, что этому хендлу где-то там внутри соответствует ядерное имя объекта, используется в ограниченном круге задач очень низкого уровня.
но если мы посмотрим на атрибуты файловой системы NTFS мы увидим расширения UNIX, такие как пользователь, группа и режим доступа (они есть, на самом деле).
ACL в NTFS были изначально, ещё до того, как появились эти самые «расширения UNIX», и до того юниксоидам приходилось извращаться с политикой доступа через rwxrwxrwx, что намного менее гибко. И причём тут символические и жёсткие ссылки?
Дальше — это организация архитектуры процессов и…
Да-да, вот тут тоже интересно, треды были в NT опять таки изначально, а более-менее стандартное NPTL в юниксах появилось сильно позже. До этого считалось, что дискретизации шедулера на уровне процессов и так всем хватит, ибо нефиг.MacIn
14.02.2017 18:10+2ACL в NTFS были изначально, ещё до того, как появились эти самые «расширения UNIX», и до того юниксоидам приходилось извращаться с политикой доступа через rwxrwxrwx, что намного менее гибко. И причём тут символические и жёсткие ссылки?
Верно. ACL привнесли ребята из DEC/ VMS команд, ACL были в RSX-11 на PDP.
neit_kas
13.02.2017 04:43+4Ко всему описанному добавлю: современные исполняемые файлы под NT (Portable Executable) основаны на COFF (даже заголовок его наследуют).
sumanai
12.02.2017 21:01+3Современная Windows NT писалась совместно с IBM как раз таки на базе UNIX
Вообще-то там корни идут совсем в другую сторону.
Фактически уникальность NT — это универсальное ядро, поверх которого работала подсистема Windows и Unix
Там может работать что угодно, была бы нужная подсистема. Изначально вообще никакой win подсистемы там не было, её впилили потом, как и поддержку архитектуры семейства i386.Lirein
12.02.2017 21:08+1По первому проясните подробнее, где я заблуждаюсь?
По второму пункту согласен полностью. Хоть историческую статью всем Хабром пиши. С миру по нитке — общая картинка в целом.sumanai
12.02.2017 21:13+2По первому проясните подробнее, где я заблуждаюсь?
Основным разработчиком NT был Дэвид Катлер, который перешёл из DEC, где пилил VAX и VMS. Из-за этого даже судились.
Хоть историческую статью всем Хабром пиши
Да уже есть, нужно просто погуглить.
Incidence
14.02.2017 11:14+2Вобще-то нет, Катлер и его команда пилили VMS в Digital, поэтому в первых НТ было всё-таки больше от неё, чем от чего-то позиксного.
nazarpc
12.02.2017 10:38+3Или некий аналог реестра
gconf/dconf, разве нет? Да и транзакционную sqlite некоторые приложения используют. А благодаря тому что конфиги отдельной программы потенциально находятся во вполне определённых директориях становится воможным ПОЛНОЕ удаление приложения так, что система вернется к состоянию когда приложение не было установлено (в Windows большинство приложений не могут собственную папку удалить из Program Files при деинсталляции, не говоря уже о жести с происходящим в реестре).
Lsh
12.02.2017 12:10+3Необязательно же делать как в винде. И, как мне кажется, ничто не мешает пакетному менеджеру заниматься не только файлами, но и реестром. Тогда после удаления софта ничего не останется.
В винде проблема с удалением именно в том, что у каждой программы свой деинсталятор, а разработчики деинсталятора забивают на качество его работы.
По парсеру на конфиг — действительно проблема и излишние сложности, множество поводов выстрелить себе в ногу.
Реестр же позволяет все данные хранить в унифицированном виде, что несомненно хорошо, тут я полностью согласен с автором.kmu1990
12.02.2017 12:20К сожалению, кое-что мешает пакетному менеджеру заниматься конфигами. Пакетный менеджер знает только то, что ему дано в описании «пакета» (программы), т. е. если программа динамически создает конфиги (например, отдельный конфиг для каждого user-а в /home) и никак не сообщает о них пакетному менеджеру, то и удалить эти конфиги он не может. Т. е. фактически проблема сводится к тому, что для программы должен быть сделан средствами ее создателей адекватный деинсталятор — и пакетный менеджер сам по себе эту проблему решить не может.
Но как лирическое отступление, например, пакетный менеджер apt (Ubuntu/Debian/etc) поддерживает команду purge, которая пытается удалять программу вместе с ее конфигами. Так что по мере возможностей, некоторые более или менее популярные пакетные менеджеры, по крайней мере в Linux, пытаются заниматься конфигами.nazarpc
12.02.2017 12:46Не пытаются, а успешно занимаются. Но как вы правильно заметили, только системными, которые устанавливались с пакетами и, возможно, менялись пользователем. Но я ни разу не видел приложения, которые удаляют конфиги из домашней папки. К счастью есть всего несколько папок и несколько веток в dconf где с 99% вероятности будут конфиги приложения. Почистить это совсем не сложно.
Хотя (в теории) можно повесить хук на удаление и подчищать даже пользовательские конфиги, но, повторюсь, ни разу такого не видел.TaHKucT
12.02.2017 19:39+9В домашней директории пользователей лежат не конфиги, а файлы пользователей. Да, это может быть какой-нить .softname/config, но это файл пользователя, который пользователь или явно написал сам, или натыкал в графическом меню программы softname(есть конечно вариант что он «автосгенерировался» при первом запуске). И пользователь может сделать что-то типа «apt remove softname && apt-add-repository… && apt update && apt install softname» и ожидает увидеть новую версию softname, поставленную из «правильного» ppa, но со своим старым конфигом (я например уже лет 10 таскаю ~/.purple/, ~/.mozilla/ и ~/.thunderbird/ по разным ноутбукам, дискам и ОСям).
И я считаю что трогать данные пользователя никогда не нужно. Пользователь может потом захотеть снова поставить тот же софт, может захотеть перенести конфиг на другую машину или просто сохранить конфиг в какой-нить git на всякий случай).aso
13.02.2017 11:03-1В домашней директории пользователей лежат не конфиги, а файлы пользователей.
Э?
А что лежит в ~/.config?mayorovp
13.02.2017 11:22+1файл пользователя, который пользователь или явно написал сам, или натыкал в графическом меню программы softname
aso
13.02.2017 12:25Нет, это дефолтное место для XDG-конфигов пользователя.
Причём, в принципе — могут порождаться программами — или ставиться из пакета по-умолчанию.
Daytar
12.02.2017 12:51Но как лирическое отступление, например, пакетный менеджер apt (Ubuntu/Debian/etc) поддерживает команду purge, которая пытается удалять программу вместе с ее конфигами. Так что по мере возможностей, некоторые более или менее популярные пакетные менеджеры, по крайней мере в Linux, пытаются заниматься конфигами.
Он удаляет только те конфиги, что были созданы на этапе установки пакета, зачастую это дефолтные конфиги в том же /etc или /etc/default, которые есть в описании пакета. Это делается для случаев, когда дефолтные конфиги были изменены юзером, затем сама програма была remove, а потом вдруг понадобилась обратно.
За динамически генерируемым конфигами, например в том же /home/.config apt не следит.kmu1990
12.02.2017 12:53Я ровно это и написал. Что ваш комментарий добавляет к моему или оспаривает в нем?
Daytar
12.02.2017 12:57Часть про purge довольно скомканная и после описания проблемы динамических конфигов выше создаётся впечатление, что purge — панацея и умеет в удаление и их, а не только системных.
kmu1990
12.02.2017 13:00Часть выше части про purge вполне подробно и даже с примером (абсолютно эквивалентным вашему) объясняет почему пакетный менеджер не может впринципе следить за всеми конфигами. А часть про purge содержит слова «пытается» и «по мере возможностей» — очень не похоже на описание панацеи.
vintage
12.02.2017 14:53В том-то и дело, что программа не должна лезть куда-либо за пределы своей песочницы. Пусть пишет в свои ./user/ и ./local/ а система уже разберётся что в эти директории примонтировать.
kmu1990
12.02.2017 14:58+1Вы предлагаете пакетному менджеру еще и в качестве песочинциы для всех программ выступать или что? Я не понимаю, как то, что программа «не должна», относится к пакетному менджеру и его возможности/невозможности удалять конфиги? Он что может как-то заставить программу не делать, то что она делать не должна?
vintage
12.02.2017 15:59Он должен контролировать что и где ей позволено делать и изолировать результаты её деятельности от других установленных приложений, если иное явно не разрешено пользователем.
kmu1990
12.02.2017 16:09+2Т. е. не только пакетный менеджер но еще и пеочница, которая для каждого приложения отслеживает, что оно в runtime-е делает? Вам не кажется, что вы слишком многого хотите от пакетного менеджера?
Пакетный менеджер может спросить у пользователя готов ли он предоставить приложению определенные права, но возлагать обязанность по проверке не вышло ли приложение за рамки дозволенного во время работы на пакетный менеджер — это слишком много. Получится монстр, который просто за все уже отвечает.
Более того, я не думаю, что у пакетного менджера (предполагая что это просто приложение, а не часть ядра) будет достаточно возможностей, чтобы выполнять все необходимые проверки эффективно.vintage
12.02.2017 16:49-3Не зацикливайтесь на термине "пакетный менеджер". Почитайте, например, про докер, который и скачает, и поставит, и соединит, и проконтролирует, и сбалансирует, и изолирует, и залогирует, и заверсионирует. И для этого не надо править сотню конфигов в десятках мест. Именно так должны выглядить OS в 2017.
kmu1990
12.02.2017 16:58+41. Я не зацикливаюсь на термене. Разговор был изначально о пакетных менеджерах и о том, что они могут делать с конфигами — я просто придерживаюсь темы разговора, чтобы не вводить никого в заблуждение.
2. Docker — это не ОС.
3. Docker образ содержит образ ОС. Этот образ все еще содержит кучу конфигов, которые нужно настраивать и править.
4. Docker ничего не контроллирует, он пользуется средствами ОС (контейнеры и cgroups).
5. Делать для каждого отдельного приложения свой контейнер — это просто overkill. Представьте что вы git, g++, make/CMake/Scons/etc все поставили в различные контейнеры — как этим вообще пользоваться?vintage
12.02.2017 18:25-4Вы не поверите: http://rancher.com/rancher-os/
kmu1990
12.02.2017 18:29+3Не поверю чему? Я знаю об этом проекте, что из сказанного мной этот проект опровергает?
vintage
12.02.2017 18:37-1Что не OS, что оверкилл, что ничего не контролирет и пр. Или за ОС вы только ядро считаете?
kmu1990
12.02.2017 18:43+31. Обратите внимание там написано RancherOS, а не Docker. Docker — это часть RancherOS.
2. С чего вы взяли, что не оверкилл? Более того, вы можете заметить, что Rancher OS не использует отдельный контейнер для каждого приложения.
3. Docker не контроллирует, он просит ядро ОС контроллировать (ядро — один компонент ОС, Docker — другой).
4. Нет я не считаю только ядро за ОС, как и не считаю только Docker за ОС, на что и пытаюсь вам указать.vintage
12.02.2017 18:54-4Думаете суть бы изменилась, если бы её назвали DockerOS? Или если бы функционал докера перенесли в ядро?
А судя по картинке — использует.
kmu1990
12.02.2017 19:01+11. Дело не в названии, а в том, что Docker сам по себе работать не может — ему нужно ядро с определенными сервисами. Есть Docker и есть ядро — это разные компоненты, с разными обязанностами.
2. Если бы функционал Docker-а перенесли в ядро, то все баги Docker-а стали бы исполняться в привелигированном режиме, в дополнение к багам самого ядра — как минимум пострадало бы качество (разделение на сравнительно независимые части — довольно фундаментальный инженерный принцип).
3. А вы не по картинкам смотрите, а запустите ее у себя. Вы увидите, что стандратные утилиты (cat, grep и тд и тп) — самые обычные процессы, а не контейнеры.
Vjatcheslav3345
12.02.2017 19:18+4Может — вообще имело смысл хранить все программы их модули, конфиги и библиотеки, в базе данных с версионированием, зависимостями, горячей заменой в памяти и прочими полезными вещами.
Но, во времена создания юникса всё это можно было реализовывать только в мечтах — по причине недостаточного технического и научного уровня тех лет. А без исходного кривого юникса не было бы современной идеи свободного ПО и самого ПО.
Поэтому в историческом плане юникс с потомками и язык С — все таки вещи положительные.
И, самое главное, опыт их применения и собранные грабли дают понимание того, как не надо в будущем делать и использовать ОС и языки — особенно, огромными группами разных людей и организаций, с разными целями и возможностями, никогда не пересекающихся между собой в пространстве и времени, расходясь на тысячи километров и десятилетия.
Ни один язык программирования или иная технология пока даже не пытается взвалить на себя такую неподъёмную задачу, но, сделать это все равно кому то когда то придётся — хотя бы для того, чтобы попытаться перестать терять деньги от замены дублирования старого кода.
А, так как отправить на пенсию существующие технологии пока не получается, то, наверное, значит, что предел их прочности ещё не достигнут.kmu1990
12.02.2017 19:29Я не очень понял как это относится к моему комментарию непосредственно. Но вообще программы, модули, конфиги и библиотеки уже сейчас можно хранить с версионированием, но не в БД, а в подходящей файловой системе (Btrfs и ZFS поддерживают дешевые snapshot-ы — перед изменением/установкой/удалением создаете snapshot и, если что-то пошло не так, просто откатываетесь к этому snapshot-у). Для версионирования конкретно конфигов можно просто использовать git/svn/etc, но это, скорее, для конфигов, которые мы пишем сами.
Но даже с учетом всего выше сказанного, не понятно, каким образом версионирование позволит пакетному менеджеру узнать о конфигах, о которых ему никто ничего не сообщал и удалить их?
Elandor
12.02.2017 12:29+3В винде проблема с удалением именно в том, что у каждой программы свой деинсталятор, а разработчики деинсталятора забивают на качество его работы.
Такие люди и на качество самого приложения обычно тоже забивают. Например, положат в виндовом реестре в HKLM то, что должно лежать в HKCU, а потом ещё пишут свой собственный велосипед для реализации HKCU внутри узла из HKLM.
Бардака нет только там, где он концептуально невозможен. И даже в таких системах кто-нибудь обязательно изловчится по шву чем-нибудь аккуратно мазнуть по незнанию или простой дурости.
Incidence
14.02.2017 11:30В винде проблема с удалением именно в том, что у каждой программы свой деинсталятор, а разработчики деинсталятора забивают на качество его работы.
Это не в винде проблема, это в криворуких программистах, которые не могут в MSI.mayorovp
14.02.2017 12:03+2Если бы у этого MSI было чуть-чуть по-больше документации… Потому что сейчас "не могут в MSI" даже сами Microsoft.
Посмотрите на те же VC redistributable packages. Хоть одна доступна в формате MSI?
PS Привет пакету, кажется, от 2008, который при установке выдавал ошибку если он был уже установлен в системе :)
vorphalack
14.02.2017 21:19+1у 2008 была другая более мерзкая проблема — он срал не в %TEMP%, а в корень самого свободного диска — то есть во-1х, кто тебя, сволочь, просил? а во-вторых, если у тебя например MacDrive или аналогичная приблуда, с дисков которой НЕЛЬЗЯ запустить бинарники — то всё, приплыли.
Akon32
12.02.2017 12:49+2Да бардак с конфигами и линуксе и в винде. Где-то sqlite (читай — у каждого приложения свой формат в виде схемы БД), где-то gconf, где-то ini, где-то xml.
Разрабатывал программы (под windows), где одновременно используется 3-4 вида конфигов. Привести их к единому реестроподобному формату, кстати, не получилось. Файлы конфигов, конечно, можно удалять, но этот зоопарк всё-таки не выглядит "чисто".
nazarpc
12.02.2017 12:51+7Мне как пользователю совершенно не важно какой там конфиг. Главное чтобы я мог его очень легко найти в совершенно конкретном месте и удалить при желании (чтобы сбросить настройки или после удаления приложения). В Windows у меня этого никогда не получалось. Начиная с рядовых приложений разного калибра, и заканчивая компонентами с обновлениями самой ОС. Система постоянно патологически накапливает мусор.
Mingun
12.02.2017 13:33gconf/dconf, разве нет?
Единственное, еще бы договорились, который из них оставить. Вот в упор не понимаю, зачем их ДВА.
nazarpc
12.02.2017 15:15+1Dconf вроде как более новый (на диске данные в бинарном формате хранит), а gconf это legacy (там данные хранятся в xml файлах). Все новые приложения используют именно dconf.
sumanai
12.02.2017 16:28в Windows большинство приложений не могут собственную папку удалить из Program Files при деинсталляции
У меня вот на сервере болтается в etc каталог Apache2. Сам апач давно удалён, и этот каталог удалялся, но он восстанавливается при обновлении php7.0-fpm.
Логика? Нет, не слышал.nazarpc
12.02.2017 16:31+3Установили php7.0-fpm, в папку apache2 скопировался его конфиг для этого веб-сервера. Удалите пакет — удалится и директория. Всё под контролем менеджера пакетов. Да, кривовато слегка, но всё вполне логично.
sumanai
12.02.2017 16:33-1Ну а посмотреть, что никакого апача нету, и конфиг для него- просто мусор, apt конечно не может.
nazarpc
12.02.2017 16:36+1И не должен. Есть пакет, в котором прописано его содержимое и куда это содержимое должно быть установлено, и откуда после удаления должно быть удалено. Да, сам пакет мог бы иметь соответствующие хуки, но мейнтейнеры пакета, видимо, не стали заморачиваться.
sumanai
12.02.2017 16:45Вот решение этого через хуки- это и есть «кривовато». Почему бы не сделать в пакетном менеджере поддержку опциональных зависимостей со своим деревом файлов, которое нужно копировать, когда оно есть, и не нужно, когда эта зависимость не установлена? Заодно эту зависимость можно разрешить в ситуации после установки основного пакета, когда ставится опционально зависимый, чего не сделаешь через хуки.
nazarpc
12.02.2017 16:49+2Так есть опциональные зависимости, кто вам сказал что их нет:) Всё зависит от того, как мейнтейнер соберет пакет. Ваш пакет собрал таким образом. Кривовато, но ничего страшного.
TaHKucT
12.02.2017 19:48+2а если вы сделаете «apt install php7.0-fpm; apt install apache2»? первая команда видит что апача нет и конфиг дня него не кладет, вторая команда ставит апач, а конфига для php7-fpm нет, тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов» и после установки апача вызывать что-то типа «перераскладывания примеров конфигов для php7-fpm и всех остальных, у кого могли быть примеры конфигов для апача» при этом попутно решая что делать с «вручную исправленными конфигами». К тоже же кмк идеологически неверно при установке апача как-то реконфигурировать совершенно другой пакет. Да и к тому же не очень понятно чем вам мешает лишняя директория в /etc. Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.
sumanai
12.02.2017 21:09+1тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов»
Выше отписали, что подобное уже есть.
Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.
Вообще- то замедление ОС из-за реестра является мифом. Так как реестр по сути является базой данных, то его объём никак не влияет на скорость его работы.
Ritan
13.02.2017 23:11+1Не мешайте людям раз за разом использовать «Чистильщики реестра» и «Ускорители компьютера», чтобы потом жаловаться, что ничего не работает. Это их выбор
sumanai
14.02.2017 16:54Конечно это их выбор, но они носятся с утверждением «Винда глючит и тормозит, я каждые два месяца её вынужден переставлять, реестр загажен».
safinaskar
14.02.2017 02:41Как в Windows, так и в UNIX-системах можно полностью удалить любое приложение. При условии, что разработчик позаботился о корректном удалении. И зачастую при условии, что этим приложением пользовался только один юзер (иначе придётся во всех юзерских папках потом вручную удалять ошмётки).
В Windows это делается через панель управления, в UNIX-системах — через менеджер пакетов либо (если собирали из сорцов) с помощью make uninstall.
Другое дело, если разработчик накосячил с удалением. Тогда уже для винды нужно использовать всякие там full remover, а в случае с UNIX — всякие там checkinstall и пр.
И в случае обоих систем (Windows и UNIX-подобное) если вам нужна абсолютная гарантия полного удаления пакета — восстанавливайте ОС из бекапа. (Замечу, что NixOS [как минимум в теории] поддерживает абсолютное удаление; так, как если бы система была восстановлена из бекапа; потому что там состояние всей ОС определяется всего небольшим количеством конфигов)
Hatifnatt
12.02.2017 10:42+9Теперь я примерно представляю как мог размышлять Поттеринг создавая свои решения. Вот это все «надо везде использовать JSON, XML и бинарные форматы, а потом просто их дополнительной программкой в человеческом виде выводить».
Jaromir
12.02.2017 12:00+8Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками. Не пришлось бы парсить вывод самостоятельно
vintage
12.02.2017 15:00-4Лучше всё же формат Tree, он и машиной и человеком легко читается, чего не скажешь о JSON и XML.
Jaromir
12.02.2017 15:06+1Не лучше, т.к. JSON в любом языке есть, а Tree где-то брать надо
vintage
12.02.2017 16:31+1Вы так говорите, будто написание тривиального парсера/сериализатора — это самая существенная проблема при переписывании всех этих текстовых утилит на структурированную выдачу.
Может именно поэтому линукс и утопает в легаси и не способен выбраться из этой трясины? Вместо стремления к стройности и простоте, во главу угла ставится совместимость с древними костылями, которые все ненавидят, но продолжают плакать, но есть.
Jaromir
12.02.2017 16:38Эти структурированые текстовые форматы суть одно и тоже, плюс-минус «множество восхитительных функций»(с) сверху. Смысла менять одно на другое особого нет. Есть структура и хорошо. Впринципе (для вышеописанной задачи) и ini сгодится. Но JSON популярней. Еще можно XML — он тоже есть почти везде.
Кстати, насчет ini… Мне лично очень понравился toml. Тоже человекочитаемый. Но, в отличие от, реально используется, хоть и в узкой нише (конфиг менеджера пакетов Cargo)vintage
12.02.2017 16:58Что значит "менять"? Сейчас приложения выдают плоский текст без какой-либо структуры. Так что вкручивать любой формат одинаково сложно и выбирать нужно не по принципу "для какого там формата есть либы для большего числа языков" (ответ — XML, но слишком громоздкий во всех смыслах), а по принципу "какой формат лучше подойдёт", а либы под разные языки быстро появятся, если формат не такой сложный, как YAML, последней версии которого, до сих пор почти нигде нет.
am-amotion-city
15.02.2017 18:24+3Может именно поэтому линукс и утопает в легаси и не способен выбраться из этой трясины? Вместо стремления к стройности и простоте, во главу угла ставится совместимость с древними костылями, которые все ненавидят, но продолжают плакать, но есть.
Обычно этот комментарий появляется в ветках про «почему Windows круче всех крутых», ведь энтерпрайзы не могут себе позволить выбросить в мусорное ведро свои развернутые инфраструктуры ради какой-то эфемерной, радостной только бородатому разработчику, «стройности и простоты».
Мне лично совершенно все равно, JSON там внутри, Tree, или даже Chetyre. Что мне не все равно, так это вдруг сломанные при апгрейде системы скрипты запуска какого-нибудь моего древнего мамонта, который уже десять лет что-нибудь откуда-нибудь потихоньку получает и
в redisна файловую систему складывает. Потому что, понимаете, нет ни времени, ни желания, переписывать его на модный хаскел. Ему и на баше неплохо.
Вы рассуждаете как типичный диванный эксперт по «как надо в мире розовых фей и воздушных единорогов». Суровый реальный мир подразумевает, что написанное вчера не сломается завтра просто потому, что у кого-то из архитекторов снесло крышу от избытка хайпов на единицу времени.
И да, нам нравится это легаси, потому что мы писали его и оно все еще прекрасно справляется со своей задачей, позволяя нам не переписывать его по сто раз в год на новом хайп-диалекте очередного киллер-все-живое-языка, а начинать новые проекты на современном стеке. Который спустя десять лет окажется таким же легаси, но мы надеемся, что его по-прежнему можно быдет собрать и запустить одной командой, которая за это десятилетие не изменится.
Mingun
20.02.2017 19:52А зачем вам обновлять машину, которая 10 лет работает и у вас все хорошо? Ну и не трогайте ее, никто вас не заставляет, но пожалуйста, не тормозите тех, кому все эти костыли осточертели.
DrLivesey
12.02.2017 15:38+1Tree выглядит интересно, но как сказал Jaromir, его надо где-то брать. Можно, конечно, поставить конвертер по дороге, но это уже костыль.
В нашем мире существует неимоверное количество различного легаси и заставить что-то переписать под новый формат потому что он лучше просто не выгодно экономически.
Проект, над которым я сейчас работаю, рефакторится исключительно когда мы упираемся в предел текущей реализации и новую фичу добавить просто нельзя, но очень сильно надо.
Я все это говорю к тому, что переход на новое возможет только тогда, когда возможности старого абсолютно исчерпаны и написание костыля обойдется дороже, чем просто взять и написать заново.
popov654
14.02.2017 13:08Неужели в IT всё оценивается чисто экономически? А как же красивый код, идеальная архитектура, тяга к прекрасному, и прочая ерунда)
DrLivesey
14.02.2017 13:56Неужели в IT всё оценивается чисто экономически?
Это загнивающий капитализм )
А как же красивый код, идеальная архитектура, тяга к прекрасному, и прочая ерунда)
Все это может быть выгодно экономически, но нередко живет за счет этнузиазма или лени мучаться с костылями к первоначальному говнокоду.popov654
14.02.2017 15:12+1Я скорее имел в виду что-то другое. Понятное дело, что фирме надо продавать софт, чтобы существовать, а программистам хотелось бы получать зарплату, чтобы питаться не святым духом. Но можно же совмещать необходимое с приятным. Писать хороший код, не юзать костыли, и т. п.)
Я все это говорю к тому, что переход на новое возможет только тогда, когда возможности старого абсолютно исчерпаны и написание костыля обойдется дороже, чем просто взять и написать заново.
Меня вот это удивило. Грамотный системный архитектор так ведь делать не станет. А заранее продумает всё так, чтобы было хорошо и красиво. А если уже продумано неправильно, и поезд ушёл — исправит ошибку как можно скорее, а не дожидаясь того момента, когда «всё, катастрофа, поддерживать это не реально». ИмхоDrLivesey
14.02.2017 15:41Грамотный системный архитектор так ведь делать не станет. А заранее продумает всё так, чтобы было хорошо и красиво. А если уже продумано неправильно, и поезд ушёл — исправит ошибку как можно скорее, а не дожидаясь того момента, когда «всё, катастрофа, поддерживать это не реально». Имхо
Если это стартап, то ситуация может быть следующая:
- Быстро нужно дэмо, чтобы показать концепцию инвесторам
- Инвесторов не волнует насколько стремно будет написан код — пусть уже начнет деньги приносить
- Код пишется поверх дэмо без какого-либо дизайна
- Для новых фич пишутся костыли, потому что дэмо этого не предусматривало
- Дизайна все еще нет, так же как и архитектора, который бы этот дизайн написал
- Количество костылей превышает критическую массу и добавление фич больше невозможно
- Частично пишется дизайн каких-то модулей и куча говнокода приводится к нему
- Добавляются новые фичи и костыли для них до очередного витка переделок
Отдельным пунктом, если стартап нанимает аутсорсинг, желая сэкономить на расходах, добавляется возможное отсутствие ТЗ как такового либо наличие очень сильно чернового и неполного варианта. Не забудем что на нормальное тестирование у стартапа денег тоже нет и тестирование многих фич происходит на основании неполного ТЗ самими аутсорсерами в сжатые сроки.
З.Ы. Добро пожаловать в мой мир
popov654
14.02.2017 18:51А что мешает потратить неделю-две на дизайн до пункта 2?.. Там-то никто не гонит :)
Если проект очень сложный — может, займёт и дольше, но мы же про относительно простые стартапы, верно?
Ну или как вариант — заморозить виток новых фич, и недели 2-4 заниматься только рефакторингом и устранением костылей, а пользователи типа переживут. Всё-таки стабильность дороже :) А то начнёт всё падать из-за багов — клиенты точно разбегутся.DrLivesey
14.02.2017 20:19А что мешает потратить неделю-две на дизайн до пункта 2?.. Там-то никто не гонит :)
Ничего, кроме торопливости начальства и ТЗ с детализацией уровня "как-то так должно работать".
Если проект очень сложный — может, займёт и дольше, но мы же про относительно простые стартапы, верно?
Ну, в том случае о котором я говорю, проект с огромным количеством разного функционала. Не назвал бы его простым.
З.Ы. Я говорю со стороны аутсорса и, будь моя воля, закончил бы отношения с этим стартапом уже через месяц. Все более или меннее нормализуется только на 3й год разработки после длительного хождения по одним и тем-же граблям, которые заказчик сам себе заботливо перекладывает вперед.
popov654
14.02.2017 20:57Я почему-то думал, что в стартапе разработчики — сами себе начальство. Ну и кто-то один главный. Так только в кино бывает? :)
Потому и писал, что к пункту 2 времени в теории — неограниченное количество, если конечно нет конкурентов с той же идеей.DrLivesey
15.02.2017 12:32Я почему-то думал, что в стартапе разработчики — сами себе начальство. Ну и кто-то один главный. Так только в кино бывает? :)
Ну, по-началу, оно может так и есть, но со временем количество людей растет и появляются начальники и стартап становится нормальной компанией. Правда бывают стартапы-переростки: начальники есть, а порядка нет. Тогда-то и начинается беда.
Потому и писал, что к пункту 2 времени в теории — неограниченное количество, если конечно нет конкурентов с той же идеей.
А как же теория спелых яблок?
popov654
17.02.2017 05:11А что это?) Не слышал про такую.
lomalkin
12.02.2017 21:42+2> Добавление в основные утилиты ввод/вывод JSON сильно бы упростило использование этих утилит со скриптовыми языками.
И сильно увеличило бы время на парсинг/генерацию этого самого JSONа. Я не говорю, что текст, это всегда хорошо, но да, я действительно предпочту текст, когда мне нужно распарсить текстовый файл на 500 МБ, написав скрипт для этого всего за 10 минут.
Пример из недавнего прошлого: Задача сводилась к поиску нескольких тысяч ключей по несортированному дампу с порядка 8 млн записей. К слову grep (вызов в цикле из bash скрипта) позволял делать порядка 10 проходов в секунду (!), файл лежал в горячем кеше после первого прохода.
Другие языки (пробовал на php7 и python) с задачей справляются в 3 раза медленнее, даже если предварительно прочитать файл в RAM, и только специализированная БД (redis в моем случае) позволила увеличить скорость в 10 раз.Akon32
13.02.2017 17:03А в этих "других языках" вы использовали какие-то индексные структуры? По-хорошему этот дамп нужно впихнуть в любую БД, построить индексы и искать по ним. В redis, наверно, так и получилось. sqlite, думаю, тоже подойдёт (да хоть MS Access, бывало и такое).
grep использует всякие продвинутые алгоритмы строкового поиска, которые вряд ли есть в стандартных библиотеках php/python/etc. Вручную быстрее вряд ли напишете.
lomalkin
14.02.2017 18:19Не использовал, опять таки, не было задачи. Про продвинутые алгоритмы в grep вы правы, но первоначальная идея была в том, что он все-равно читает файл каждый раз последовательно и всегда до конца, но полученная скорость grep меня поразила.
ookami_kb
12.02.2017 10:55+33Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом.
Вот допустим, нужно забить гвоздь. Да, я знаю, что такое надо делать молотком. Но давайте предположим, что это нужно сделать непременно микроскопом...
cjbars
12.02.2017 11:03+7Вот прямо с языка сняли. Меня всегда удивляли авторы, которые выискивают неведомые редкие кейсы, жалуются на сложность( но не невозможность) их решения, а потом поносят систему в целом. Да в никсах можно вообще все сломать командой из нескольких символов ( привет gitlab) и что ж теперь? Реестры писать? Да ну нахрен!
MooNDeaR
12.02.2017 11:24+1На самом деле подобная хрень может возникнуть :) Как-то раз мне в руки попал роутер с каким-то очень обрезанным линуксом на борту и там не было даже улитилы dd, не говоря уже о такой замудреной вещи как find.
ookami_kb
12.02.2017 11:43+3Так в данном случае это как раз прекрасно, что система позволяет забить гвоздь микроскопом (если очень хочется, или религия не позволяет молоток использовать, или старшина приказал). Но тут уж не стоит удивляться тому, что сделать это сложнее, чем молотком.
cjbars
12.02.2017 21:45И вы конечно же сделали вывод что все unix системы полный отстой и куча костылей? Я надеюсь нет.
silvansky
13.02.2017 13:07+1Однажды постучался я по ssh на девайс, ввожу
find . -iname "*.jpg" -exec cp {} ./ \;, а он мне такой: а нету тутfind-а!
DexterHD
12.02.2017 11:16+12Судя по контексту статьи и постоянным переходам на личности, автор считает всех идиотами, а себя видимо самым умным. Поэтому даже не дочитал. Подача материала на 2.
Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал.
Спасибо, не пиши больше.NeoCode
12.02.2017 12:21+17Статья написана вполне нормально. Для тех кто реально понимает и на практике с этим сталкивался, все понятно и знакомо.
А если писать более подробно, то будет не статья а многотомное собрание сочинений.
nightvision
12.02.2017 21:46-1особенно словечки sic! Бугога и т.д., реально на практике часто сталкиваюсь, все понятно и знакомо.
Тьфу!
safinaskar
12.02.2017 21:49@DexterHD, nightvision, стиль статьи, слова "бугога" и пр. — это типичное явление в американских блогах, в том числе в переводах статей из американских блогов на Хабре, почитайте их (хотя у меня не перевод). Особый стиль нужен, что "встормошить" читателя, который и вправду фанатеет от UNIX. Сказать ему, так сказать: "Проснись, UNIX давно устарел!"
safinaskar
14.02.2017 16:41-1Посмотрите мой коммент выше, DexterHD (я не уверен, что парсер Хабра вас с первого раза пинганул)
kirillaristov
12.02.2017 21:49+2автор считает всех идиотами
А что, наш социум логичен и рационален everytime?
Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал.
Это тонкий сарказм, отсылка к философии unix, а не к статье.safinaskar
12.02.2017 21:52@basilbasilbasil, kirillaristov, сарказм, отсылка к философии UNIX? Что? А, вон оно что! :) В общем, нет, я об этом не подумал, это было сказано в прямом смысле
jetexe
13.02.2017 15:58сарказм, отсылка к философии UNIX? Что? А, вон оно что! :)
Так и рождаются «синие занавески»
Скрытый текст
safinaskar
14.02.2017 16:42-1Посмотрите мой коммент выше, basilbasilbasil, я не уверен, что парсер Хабра вас пинганул
NeoCode
12.02.2017 11:25+11Полностью согласен с автором. Я не такой спец по юниксам, но сталкиваться приходилось достаточно. Кривизна make и shell сразу бросается в глаза. Кривизна препроцессора С/С++ и отсутствие в них модульности — тоже (хотя пишу на С/С++ как основном языке уже много лет).
С другой стороны многие концепции в юниксе очень удачны и даже гениальны. Есть фундаментальные вещи из линукса которых очень не хватает в винде. И наоборот.
А проблема — в инертности мышления, да и в инертности общества вообще.
Разработали — работает как-то — а зачем трогать и улучшать? Мозг-то привыкает к любым костылям.
И в результате может и есть где-то системы, лучшие (или хотя-бы потенциально лучшие) чем Unix (да и чем Windows, чего уж там) — но кто о них знает? А проект сдавать завтра, а инфы по этим новым системам кот наплакал — зато по линуксу и винде гигабайты статей и обсуждений на разнообразных сайтах и форумах, куча специалистов в совершенстве знающих любые костыли и готовых помочь…
Увы. Тут нужна какая-то централизация. По идее ветеранам Unix нужно больше прислушиваться к мнениям людей с незамыленным взглядом. Не совсем новичков, но и не тех кто уже привык и не замечает всей этой кривизны. В сообществе должно быть понимание того, что гениально а что костыли. Должны вырабатываться какие-то совместные дорожные карты. Планы по вытеснению и замене кривых и морально устаревших возможностей на новые. Стандартизация всего этого.
Так, вместо make давно бы уже перешли на qbs. Что мешает корпорациям, осуществляющим основной вклад в разработку того же линуса, перейти на эту технологию? Если там чего не хватает — ну так оно и выяснится, сформировали бы консорциум, подумали бы все вместе. И постепенно вытеснили бы make. Но нет — оно же «и так работает»… печально все это.equand
12.02.2017 14:05+2Назовите хоть одну вещь из Windows, которой не хватает в нынешних *NIX?
Also есть scons.
Aingis
12.02.2017 18:27+2ACL? Из-за них, кстати, файлы WSL из-под винды трогать не надо.
kmu1990
12.02.2017 18:34+1Есть Posix ACL. Можно подробнее что в Window-ых ACL есть, чего не хватает в Posix ACL?
Aingis
12.02.2017 20:56И в какие популярные дистрибутивы он входит «из коробки»?
Такие доводы напоминают Джаббер: там тоже есть 100500 расширений, только все нестандартные и разной степени костыльности. И где этот джаббер? Все сидят в Вотсапе или Телеграме.
kmu1990
12.02.2017 21:01В ubuntu они есть по-умолчанию, другое дело, что чтобы они начали работать их нужно настроить (но простите, настройка ACL по-умолчанию — это какой-то странный зверь, что он и кому будет разрешат/запрещать?).
mayorovp
13.02.2017 09:18Э… Debian wheezy? :)
Aingis
13.02.2017 09:42И сколько процентов пользователей пользуются там Posix ACL? А сколько утилит его поддерживают?
kmu1990
13.02.2017 10:34+3Пользуются те кому Posix ACL нужен, не пользуются все остальные. Какое отношение сколько утилит его поддерживают имеет к делу? Хранением ACL занимается ФС, проверкой ядро, редактирование ACL делается через специальную утилиту — какие еще утилиты вам нужны?
Вы не могли бы отвечать по существу, что такого в Windows ACL есть, чего нет в Posix ACL? Ато разговор очень странный получается, вы вопросы задаете, ответы получаете, но сами пока ни на один вопрос не ответили.vorphalack
13.02.2017 12:00nested ACLs? наличие более точной настройки чем rwx? на NTFS 13 разных разрешений, например (или 14, если считать Full Control за еще одно).
Incidence
14.02.2017 11:42+4nested ACL и в NTFS на самом деле просто рекурсивный обход с установкой дочерних аклов равным родительским по дефолту, так что в линуховых аклах с этим легко справляется setfacl -Rd
А вот с более точной настройкой, чем rwx тут конечно да, но, с другой стороны, довольно сложно придумать ситуацию, когда, скажем, надо дать группе разрешение создать каталоги, но не разрешать их удалять или создавать в них файлы… NTFS такое позволяет, но, как бы… зачем? :)mayorovp
14.02.2017 12:05Как вы еще разрешите всем пользователям компьютера создавать папки в корне диска, но запретите им "залезать" в чужие?
Incidence
14.02.2017 13:35Легко. Выдать каждому свой корень, тот же %USERPROFILE% или /home/$username и в нём хоть обсоздавайся. А в истинном корне юзерский срач разводить — это признак плохой архитектуры.
И кстати, по-моему это и с общим корнем можно сделать без ACL. Какое-нибудь chmod go-rwx и всё.
safinaskar
17.02.2017 09:09+3В юниксах довольно давно есть фича, делающая именно то, что вы сказали. Т. е. установить специальный бит на папку так, чтобы в этой папке все могли создавать, но при этом нельзя было лезть в папки, созданные другими. Этот бит стоит по дефолту на /tmp в GNU/Linux, т. к. именно для /tmp такая функциональность обычно и нужна.
sumanai
14.02.2017 16:57nested ACL и в NTFS на самом деле просто рекурсивный обход с установкой дочерних аклов равным родительским по дефолту
Это если разрешено наследование, а так да.
vorphalack
14.02.2017 21:26+1под nested acl я имел в виду возможность наследования групп — то есть у тебя допустим папка «файлопомойка», в которую могут писать «отдел 1», «отдел 2» и «отдел 3». в каждой из этих групп — подгруппы, типа «менеджеры отдела Х», «начальство отдела Х» итд. в posix ACL тебе придется все эти группы прописывать вручную, что очень быстро выльется в нечитаемый зоопарк.
хотя щас что-то интересно стало, насколько это сидит в NTFS, а насколько раскрывается средствами домена/AD.
а расширеные права хороши для файлопомоек тех же — создавать write-only каталоги, чтоб никто ничего случайно лишнего не грохнул или не перенес в 20й уровень вложенности.sumanai
14.02.2017 23:51хотя щас что-то интересно стало, насколько это сидит в NTFS, а насколько раскрывается средствами домена/AD.
Поясните тут, я тоже сейчас задумался, возможно ли такое реализовать стандартными средствами на обычном ПК без АДа.Incidence
15.02.2017 01:03+1Да, возможно.
В NTFS в ACL указываются только токены SIDов, а их семантику определяет либо локальный SAM либо сетевой AD — какой SID обозначает аккаунт, какой группу, и членами каких групп являются известные группы и аккаунты.
Поэтому на уровне разрешений ФС нет принципиальной разницы между SAM и AD.sumanai
15.02.2017 16:22-1Поэтому на уровне разрешений ФС нет принципиальной разницы между SAM и AD.
А на уровне интерфейса нащёлкать такое можно?mayorovp
15.02.2017 16:30На уровне интерфейса нет принципиальной разницы между пользователем и группой. Composite во всей красе.
Incidence
15.02.2017 23:50У меня такое ощущение, что вы даже не пробовали залезть в штатный виндовый (гуёвый!) редактор ACL. Попробуйте, там всё достаточно интуитивно.
mayorovp
15.02.2017 08:57Это nested groups, а не nested acl. Данная фича относится к модели безопасности системы, а файловая система работает с группами пользователя как с данностью.
Добавьте в linux возможность одни группы включать в другие (если ее там еще нет) — и все файловые системы получат поддержку этих групп автоматически.
equand
12.02.2017 21:46-1Лол, по-моему все новомодние FS включают настолько всего много, что ACL там есть по дефолту.
Кстати ACL были в UFS с 2005, а acl nfs уровня с 2009, бородато. Не знаю насчет EXT но другие ФС поддерживают это давно.
ZFS это включает из коробки почти с рождения, если мне не изменяет память.
Конечно если жить во времена FreeBSD 4, когда мелгкомягкие перли все у всех для своей новой Win NT, тогда да, NTFS был крупным апгрейдом.
А сейчас когда я могу делать мгновенные снапшоты для 250 ZFS датасетов в одну секунду, делать ограничения на разных уровнях, иметь файловый доступ к снапшотам без маунтинга, возможность атомарного восстановления, компрессии разного рода, дедубликации, возможности дописывать метки и кастомные метаданные к датасетам (для конфигурирования бекапа например).
Все это с резервированием разного уровня и главное возможностью репликации по сети только изменений!
После этого NTFS выглядит древним мамонтом, который все ждут когда он вымрет.
Siemargl
12.02.2017 23:02Таймлайн свой поправь. FreeBSD4 существенно моложе NT
А ZFS в продакшн пошла так вообще недавно по таким меркамequand
13.02.2017 02:31-1Нет таймлайн корректен. FreeBSD 4 была all the rage back then, т.к. Linux был bleeding edge. Однако ФС была хоть и стабильной, но достаточно устаревшей на момент релиза. Windows NT 4 был all the rage, 3.1 3.5 не так известны, но несли в себе красивую NTFS.
ZFS в релизе с 7ки, с 8ки уже сплит пошел. С 7ки уже 9 лет прошло...
Incidence
14.02.2017 11:44Все это с резервированием разного уровня и главное возможностью репликации по сети только изменений!
DFS и differential replication в виндах что-то около 15 лет как минимум.
vintage
12.02.2017 18:34+1powershell?
equand
12.02.2017 21:34+3Thanks but no thanks :D
vintage
12.02.2017 23:00+2Смайлик, конечно, классный аргумент, но не могли бы вы поделиться с нами, почему упоминание powershell вызывает у вас истеричный смех?
equand
13.02.2017 02:41-3Без проблем, я не буду искать статьи в бложиках, напишу отсебятину.
Powershell, конечно, отличная замена CMD, однако это по сути "у нас 13 стандартов… теперь 14". Шеллы конечно не прелести, но powershell кажется чем-то вроде интерпретатора, в котором случаем прикручена консоль и атрибуты командных ключей.
В итоге часто не ясно, команда это или шелл вызов или же .NET вызов.
В шелле *nix всегда ясно, что пайп, а что нет, ясность многое дает, когда необходимо делать дела быстро.
vintage
13.02.2017 09:29+3Вы можете сходу сказать что из этого команда, шелл вызов и c-вызов: ls, cd, printf? Если нет, то почему вас это не волнует, а в случае powershell, внезапно, имеет критическое значение?
xerxes
13.02.2017 10:38+3«Прочел статью, что powershell плох, Windows плох, Unix и bash прекрасны, и поверил»
mayorovp
13.02.2017 10:47+1powershell имеет проблемы с запуском внешних утилит даже на винде. Точнее, с разбором их вывода.
Во-первых, любой вывод в stdout парсится как строка в текущей консольной кодировке. Если кодировка не совпадает — исходные байты восстановить может уже не получиться.
Во-вторых, любой вывод в stderr рассматривается как ошибка. Правильнее было бы вовсе не перенаправлять этот поток — но powershell так не умеет.
В-третьих (хотя на линуксе этот пункт будет неактуален) — задать кодировку консоли довольно сложно. Особенно при запуске через WinRM...
RussianNeuroMancer
13.02.2017 09:30Есть PowerShell: https://github.com/PowerShell/PowerShell/releases
Psychopompe
15.02.2017 02:13Кстати, scons хорош? Я вот думаю освоить для проекта.
safinaskar
18.02.2017 15:00Если собираетесь сделать проект свободного ПО, не юзайте scons. Сам я ничего про него не знаю, но в debian upstream guide не рекомендуют: https://wiki.debian.org/UpstreamGuide. Во всех остальных случаях, т. е. если это просто некий проект, не предназначенный для выкладывания на публику в виде сорцов, то, видимо, можно
kmu1990
12.02.2017 14:19+3Вы так говорите про переход с make на что-нибудь другое, как-будто под Unix-ами законом запрещено использовать что-то кроме make. Какую систему сборки использовать для своей программы решает ее автор — это не ограничение Unix.
Если под линуксом вы имеете ввиду ядро линукса, то разработчики ядра сделали себе свою собственную систему сборки (которая опирается на make, но не является просто make-ом), которая удовлетворяет их нуждам, что очень логично — разработчики пользуются теми средствами разработки, которые им удобны.vintage
12.02.2017 15:25Возможно дело в том, что "самое удобное средство из доступных" никуда не годится?
kmu1990
12.02.2017 15:33Кто сказал что make самое удобное средство из доступных?
vintage
12.02.2017 17:00-4kmu1990
12.02.2017 17:04+11. Где в этой фразе упоминается make? И что он самый удобный из доступных?
2. Фраза выдрана из контекста, в котором говорится о том, что разработчики ядра Linux (вполне себе конкретная группа разработчиков), сделали для себя свою собственную систему сборки, которая им удобна (именно им, а не всем подряд), и кроме того эта система сборки не make, а Kbuild.vintage
12.02.2017 18:41-2То, что им пришлось навелосипедить своих костылей вокруг — замечательно иллюстрирует тезис о "никуда не годится". И я тоже нигде не говорил, про "самую удобную для всех и каждого", не выдумывайте.
kmu1990
12.02.2017 18:50Это иллюстрирует только тезис о том, что make не подходит для разработки ядра Linux — что совсем не то же самое, что и «никуда не годится». Кроме того пожалуйста потрудитесь проиллюстрировать оставшиеся части, а именно: «make — самое удобное стредство из доступных».
Так же обращу внимание, что они не только отказались от make, но и от всех остальных систем сборки в том числе, коих не мало. Что замечательно иллюстрирует тезис о том, что разработчики пользуются тем, что им удобно, и, в частности, если достаточно удобного средства нет создают свое. И обратите внимание, в утверждении нигдже не упоминается Unix. Почему? Потому что Unix тут совершенно непричем, а система сборки не ограничение навязанное Unix идеологией.
arheops
12.02.2017 19:21+1Ага, то, что вы в ферарри можете загрузить только 5 мешков картошки, а не тонну, говорит о том, что феррари гавно машина и никуда не годится. linux как раз отличается тем, что никто не заставляет вообще использовать make. Если у вас простой проект, можете вообще под него отдельно написать скрипт. Да хоть на перле, хоть на go.
Yukarin
12.02.2017 21:52+6Так, вместо make давно бы уже перешли на qbs.
Может быть потому, что make — это ровно один исполняемый файл в ~200КБ и одной зависимостью (stdlib), а не часть Qt-комбайна?
Gorthauer87
13.02.2017 15:48+2qbs хорош, но кажется он рип, сам Qt не будет на него переходить, а будет переходить на cmake, а так аналог qbs, но без зависимости от Qt и с умением докачивать и собирать зависимости был бы неплох.
В принципе на замену make есть ninja, где все, вроде бы, сделано по уму, и на него таки потихоньку переползают.Antervis
13.02.2017 19:43идеи, на которых основан qbs, хороши и практичны. Но во-первых, qbs еще на этапе становления (не так уж и редко выходят breaking changes), во-вторых, комьюнити — два с половиной калеки (вплоть до того, что на все мои вопросы по qbs на so ответил один и тот же человек). Из-за этого по сути 90% информации, которую вообще можно найти в сети по qbs — официальная документация. Она хороша, но скорее в виде справочника, нежели подробного пособия.
worldmind
12.02.2017 12:33+5Заловок конечно слишком жёлтый, зашёл посмотреть на крах, а про него почти ничего и не сказано:
> авторы UNIX фактически придумали для каждого системного конфига… свой формат
и при чём тут философия? она разве запрещает все конфиги сделать в YAML?
также и с выводом
> Но ведь у UNIX shell полно других недостатков. Нужно выкинуть его вовсе и заменить на некий другой язык
да, что-то питоноподобное было бы в тему, но это снова не о философии, шеллов много всяких пытаются сделать и философию это не отменяет
С моей точки зрения главный принцип философии юникс это декомпозиция на небольшие программы которые делают что-то одно и ему альтернатив не видать.divanikus
12.02.2017 12:36> и при чём тут философия? она разве запрещает все конфиги сделать в YAML?
Запрещает legacy, у чужой программы на YAML конфиг не переделать. Ну или пилите полностью свой дистр с блекджеком и yamlами, только он никому не нужен будет.
Gorthauer87
13.02.2017 15:51+2У yaml все с отступами странно, можно огрести неплохих проблем с непривычки.
worldmind
13.02.2017 17:15YAML это лишь пример, а привычка это дело привычки — если бы ямл был стандартом то все бы привыкли
safinaskar
14.02.2017 17:26+1С моей точки зрения главный принцип философии юникс это декомпозиция на небольшие программы которые делают что-то одно и ему альтернатив не видать.
Если считать философией UNIX именно это (без отсылки к UNIX shell и пайпам), то ничего против такой философии я не имею (с оговоркой, что иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше). Проблема в том, что многие люди начинают относить к философии UNIX её конфиги, многие особенности написания скриптов на shell
worldmind
14.02.2017 18:36> большие и сложные программы типа Photoshop или [о боже!] Microsoft Office
они вполне могут соответствовать философии юникс, например быть гуём ко множеству утилит, философия гуй не запрещает
> иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше
например когда?Incidence
14.02.2017 19:07+1они вполне могут соответствовать философии юникс, например быть гуём ко множеству утилит, философия гуй не запрещает
Не запрещает, да.
Но когда средства документооборота и допечатной подготовки начинают разрабатываться в русле этой философии, то получается в лучшем случае latex с его эзотерическими сообщениями об ошибках, которые устраняются далеко не там, где возникли, с его взаимоисключающими зависимостями в документах, которые почему-то прекрасно собираются тем же latex'ом на другом дистре, и где «в случае ошибки запустите этот же шаг повторно 2-3 раза» (и это реально помогает, см. bibtex). Конечно, потратив месяцы вдумчивого курения мануалов, гугла и экспериментов, на latex'е можно творить чудеса, почти недосягаемые для поклонников мс-ворда. Я на нём свою докторскую диссертацию написал, например. При всём этом, именно эта философия жутко гетерогенного пайплайна в продакшне заставляет меня нервно дёргаться каждый раз, когда невинная текстовая правка начинает бросать overfull hbox'ы в неожиданных местах, а уж как там таблицы рисовать — это просто пиндец по сравнению с тем же вордом.
Всё же интегрированный инструментарий имеет свою нишу, в которой философия юникса сосёт не нагибаясь.worldmind
14.02.2017 19:12Проблемы латеха не означают что дело в философии, никто не мешает авторам ворда выделить ядро в отдельный инструмент, хуже оно от этого работать не станет, а будет более философски.
Incidence
14.02.2017 20:44+2Именно в ней и дело. Мешает то, что философия гетерогенных инструментов в пайплайне приводит к появлению легаси на стыках этих инструментов. Устранение этого легаси вызывает лютый баттхерт у юзеров, которые рассчитывали на обратную совместимость, а оставление этого легаси вызывает такой же баттхерт у разрабов, эффективность которых снижается из-за необходимости его поддержки (в результате чего получится ещё один клон того же латеха).
Интегрированный инструмент свободен от этих недостатков — разрабы вольны как угодно менять внутреннюю архитектуру, так как юзер ожидает лишь совместимости форматов хранения данных и не более — в этом и проявляется главный недостаток т.н. «философии юникс».worldmind
14.02.2017 21:01Да, есть неудобство, при смене API желательно делать обратную совместимость и возможно какие-то ключи для вывода в новом формате, но как-то софт уже десятки лет развивается — решают эти проблемы.
Incidence
15.02.2017 01:08Так и решают, как я описал. Латех в своей нише с юниксовой философией, интегрированные офисные продукты — в своей нише, с облаками ажуров, эксченджей и прочим корпоративным буллшитом.
Так что нет, философия юникс — не универсальный ответ.
immaculate
15.02.2017 09:59Когда я делал очень большие документы в Word, там было не меньше проблем. Только эти проблемы в принципе устранить было нельзя. Если в latex можно еще раз перечитать мануал, попытаться что-то переделать, в крайнем случае, залезть в исходники, то если что-то не работает в Word, чаще всего нет никакого выхода. И latex все-таки работает по четко описанной логике. А в Word если 10 раз накликал мышкой новую строку в таблицу, а на 11 раз вся таблица исчезла или сморщилась, никакой логики нет — просто проявление очередного бага, и даже если удастся найти workaround, это не дает никакого бонуса — работать дальше не станет легче.
Правда в последний раз работал и с тем и с другим очень давно, более 10 лет назад. Надеюсь, что с тех пор качество Word поднялось.
vbif
15.02.2017 10:16Не знаю, как в последних офисах, но, к примеру, в 2010-м всё так же колонтитулы первой страницы применяются к страницам, на которых меняется формат или ориентация. Более того, изменить формат или ориентацию одной страницы стало ещё более нетривиально, чем в 2003 офисе.
safinaskar
17.02.2017 13:54"иногда большие и сложные программы типа Photoshop или [о боже!] Microsoft Office всё же подходят лучше"
например когда?Представьте себе workflow некоего сотрудника. Это может быть программист, художник, писатель, кто угодно. Если workflow уже "устаканился", т. е. уже известно, что, в общем-то нужно будет делать сегодня, завтра и так далее, то всякие интегрированные среды, всякие IDE, фотошопы, офисы подходят лучше. Потому что там нужно сделать меньше телодвижений для выполнения действий. Там всё "просто работает".
Понимаете? Есть много видов деятельности, которые уже так сказать формализованы, чей workflow уже уложен в некую схему и разные интегрированные решения для этого workflow работают лучше.
А если ещё не "устаканился" и нужно постоянно решать новые непредусмотренные задачи, то типичный UNIX environment подходит лучше. Там можно вообще всё, если захотеть.
У программистов нужда в таком окружении происходит чаще, поскольку они чаще сталкиваются с разными нестандартными задачами. Поэтому программисты выбирают никсы чаще, чем художники, скажем.
Но даже программистам работать во всяких IDE обычно проще. Просто если ты разрабатываешь нечто совсем новое, скажем, новую ОС, тут уже IDE подход даёт сбой, т. к. там такого не предусмотрено. Тут уже берёшь в руки vim, emacs и прочее
immaculate
12.02.2017 13:00+4Честно говоря, какой-то сырой текст, пытающийся разжечь холивор, но без изюминки. Вроде лет 25 назад написали The Unix Haters Handbook, по-моему, большинство вашей критики взято еще из этой книги, но все войны по ее содержанию уже лет 15 как отгремели, даже скучно уже ввязываться.
Первую треть еще как-то прочитал. Особенно насмешило про «недостаток» текстового формата
/etc/passwd. Дальше уже было сложно заставить себя тратить время на текст, который сам автор признает сырым.
Осталось еще два соображения. Как это такая плохая система существует уже более 40 лет, пережила уже и многих критиков, и волны различных hype, адаптировалась и к gui, и к мейнфремам, и к маленьким компьютерам, переход на Unicode и многое другое, и все это без значительных усилий? Неужели это признак плохой продуманности?
Ну и раскритиковать можно что угодно, потому что любая вещь созданная людьми неидеальна.
divanikus
12.02.2017 13:06+5ВАЗ 2107 тоже много чего пережил, видать дофига продуманная машина :)
shogunkub
12.02.2017 14:26+4Ну вообще-то, продуманная. Просто, при определённых вводных. Оптимизация UNIX по памяти — тоже не из пустого места выросла.
iig
12.02.2017 21:52Двигатель внутреннего сгорания много чего пережил. Несмотря на legacy и костыли внутри.
stigory
13.02.2017 03:40+1Вы, наверно, не поверите, но с ВАЗом все обстоит именно так, как вы сказали. Просто классический жигуль разрабатывался для страны и людей, которых уже нет. Другое время, другие запросы.
Vjatcheslav3345
17.02.2017 20:28Возможно, автору стоило бы отвести душу издав продолжение "The Unix Haters Handbook". Но, разумеется, уровень критики должен быть выше — ведь за прошедшие годы и *никсы подросли и задачи их и уровень ответственности ОС и видение её достоинств и недостатков, требований одновременно изменилось и прошло проверку временем.
entze
12.02.2017 13:24-1Оффтоп: а что — модераторы хабра модерируют посты? Или автор разжигает срачик не только на этом ресурсе?
TargetSan
12.02.2017 13:34Предложите что-нибудь на замену. К сожалению, 99% нынешних систем набиты костылями под завязку — даже перечислять не буду.
equand
12.02.2017 13:39+6О, господи, ну и маразм с тем что все в файлах. Интерфейс у UNIX текстовый, соответственно хранить конфиги в тексте намного проще и понятнее человеку.
Разбирать не хуманизированный JSON или не дай бог XML глазками врагу не пожелаешь. INI или же банальные конфиги намного проще. Да сейчас есть YAML, но тогда его не было, а сейчас менять все на YAML поломает легаси.
Использовать реестр — вообще дурость, зачем нужна БД если есть кеш файлов? Реестр виндовый все равно не достаточно оптимизирован. Прелесть текстового формата в том, что ты открыл его и прочел, СРАЗУ осознав всю информацию, совершил необходимые манипуляции и закрыл его.
Да при 1000 юзеров уже надо использовать какую-то БД, однако утилиты для работы и так присутствуют так что этот вопрос тоже решен.
Человек что писал эти комментарии явно не понимает что UNIX использует KISS потому что необходимо понять и разобраться на месте, а не звонить Microsoft Support и ждать человека на следующей неделе если Вы не льете миллионы долларов в карманы мелгкомягких.
Mingun
12.02.2017 13:48+5а сейчас менять все на YAML поломает легаси.
На мой взгляд — основная проблема как раз в поломке этой возведенной в абсолют и обожествляемой legacy. Да, все признают, что напрямую его не используют, все через обертки, костыли, подпорки, но вот взять и выкинуть все это подгнившее нутро и заменить внутри на что-то более современное — не-е-е-е, это ж legacy, а вдруг у какого Васи Пупкина две с половиной программы сломаются? Так и живем.
А ведь стоило бы начать хотя бы с давно уже предлагаемых ключиках к стандартным программам для структурированного вывода в JSON. Даже просто как JSON-текст выдавать в пайп (а не как уже готовый JSON-объект) — все лучше, чем современный бардак.
equand
12.02.2017 14:01+2Так большинство конфигов не нужно далее CSV или KV хранилищей. Так оно и есть.
passwd это CSV без экранирования и с: в качестве разделителя. Остальные конфиги либо все K=V хранилища, либо уже в своем языке программирования тоже K=V хранилища, либо же на крайний случай INI, где вместо комментариев используют секции (что конечно же дурость микрософтовская, но что поделать).
Даже на винде большинство программ используют реестр только для регистрации ибо corruption реестра известная проблема издревле. Реестр Windows — это полнейший failure и очередной костыль.
Я даже написал администрирование и установку почтового сервера полностью БЕЗ использования БД ибо это намного проще в работе и с новыми ФС (ZFS) в частности желательно ИХ использовать как БД (где возможно). Ибо БД по сути костыль для древних систем, то самое легаси (соединительное между ФС и памятью). Сейчас набегут архитекторы SQL и будут меня разносить, на что я отвечу что перенести SQL язык в ФС проще, чем ФС в БД. В итоге меньше возможных точек поломок, меньшее количество администрирования, проще дебаггинг, стабильность со 99,99% годовым аптаймом. Со второй системой или отдельным закрытым ФС сервером можно аптайм до 100% поднять.
KISS в UNIX не от того что все дибилы, а от того что усложнение систем к стабильности не приводит.
divanikus
12.02.2017 23:42+3> passwd это CSV без экранирования и с: в качестве разделителя
DSV (delimiter-separated values), CSV это частный случай именно с запятыми.
popov654
14.02.2017 17:03+2Эм, вы о чём?..
Не стоит мешать тёплое с мягким. База данных — это логическое понятие, и она не привязана к конкретному железу или файловой системе (но привязана конкретная реализация под платформу).
ФС — тоже логическое понятие, но у неё другие задачи, и она уже как раз ориентирована на непосредственное взаимодействие с физическим носителем (CDFS, FAT/NTFS/UFS/EXT/...).
База данных имеет свой язык запросов (как правило, это какие-то вариации SQL) и механизмы хранения. То есть типы таблиц и движки для их обработки. Таблицы как правило размещаются на носителе (допустим, это жёсткий диск). При этом ФС на этом диске может быть любой.
Одна из главных задач движка — организовать хранение таблиц и колонок в них таким образом, чтобы обеспечить максимальную скорость доступа (ну и чтобы это не раздувалось по размеру до невменяемых значений, здесь обычно ищут некий компромисс). Организовать хранение индексов и поиск по ним. Индексы ещё разных типов бывают :)
А доступ к файлам уже операционная система осуществляет, и на используемую ФС мы не завязаны и никак от неё не зависим (то есть для нас файл — это такой абстрактный блок из N байт, и как он там на самом деле хранится, нас не волнует).
И вы предлагаете отказаться от БД, серьёзно? И как тогда данные будем хранить?
Набор плоских файлов? Но всё равно кто-то должен делать поиск по ним согласно запросам. Вы, я так понял, хотите сделать такую ФС, которая возьмёт это на себя. Окей, но как быть с внутренним форматом этих файлов? Тогда тот модуль ФС, что будет выполнять функции движка, должен знать как минимум о структуре наших таблиц и их количестве. Где всё это указать? Как указать, что определённый файл или набор файлов содержит базу данных? Задать расширением — можно, но интерпретация расширений файлов — это прерогатива ОС, файловой системе всё равно, что за расширение у файла, она об этом «ничего не знает». Да и поиск по такому специализированному файлу тогда какой-то компонент ОС должен делать (и это уже видимо не будет относиться к реализации ФС, потому что общий процент таких файлов будет очень мал, логичнее в отдельный модуль такое вынести).
В итоге получаем просто встроенную в ОС СУБД на файлах. Так стойте, уже же для такого есть SQLite :D
И в чём смысл всего этого.
allter
12.02.2017 14:56А например в случае JSON, для того же ls -R, как выводить: в виде единого массива с именами файлов, содержащих частичные пути, или в виде древовидной структуре, где массивы файлов подкаталогов доступны как значение объекта соответствующего записи родительского каталога. А если делаем ls -R tmp/…, то в JSON-
аналоге выдачи «tmp/..» разбивать элементы пути на компоненты? И давать ли JSON инфу про каталог, которому соответствует ".."? Уже получается 3 дополнительных опции.
Куда как проще использовать скриптовой язык, как и предлагает Пайк. :-Dvintage
12.02.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.02.2017 17:52Из предложенных вами вариантов можно выбрать какой-нибудь один, не сильно важно, какой именно. Это будет уже лучше, чем просто текст. Далее, опция -R вообще не свойственна ls. Здесь я согласен со старой статьёй Пайка, которая "cat -v considered harmful". -R не свойствена ls, как и -v не свойствена cat. Вместо ls -R нужно использовать find или find -ls. А вообще, да, вместо shell нужно использовать какой-нибудь другой скриптовый язык. :)
sumanai
14.02.2017 17:59-R
Вот это как раз меня больше всего бесит в консоли Linux: некоторые команды воспринимают ключ рекурсивного обхода в заглавном виде, другие в прописном. Ну почему?!
safinaskar
14.02.2017 17:40Человек что писал эти комментарии явно не понимает что UNIX использует KISS потому что необходимо понять и разобраться на месте, а не звонить Microsoft Support и ждать человека на следующей неделе если Вы не льете миллионы долларов в карманы мелгкомягких.
Так против KISS я ничего не имею. Я говорил про другие аспекты философии UNIX, читайте внимательно
Holix
12.02.2017 14:24+2Как сейчас модно говорить, у автора разорвало пукан!
Когда я только перешёл работать на linux (лет 10 назад) с windows у меня тоже было подобное настроение. Всё было неудобно, нелогично и убого. Вони было побольше, чем у автора. Но спустя пару лет я вдруг понял насколько проще работать и разрабатывать под Linux. На венду меня теперь не загнать. 25 лет пишу софт. Уж поверьте. :)
Так вот. Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз. И это огромная сила unix. В итоге, для настройки системы достаточно текстового редактора и интеллекта!
JSON и XML не годятся для человека. Они требуют сложного парсинга, трудно читаемы и их структуру легче поломать.
Для бинарных форматов вообще будут нужны специальные утилиты. И, если их форматы универсальны, так же требуют парсинга. В обратном случае хранимые бинарные структуры будут платформо-зависимы и требовать регулярного обновления при добавлении новых полей.
По поводу языка C тоже скажу. По сути это кроссплатформенный ассемблер. Он должен обеспечивать полный контроль над аппаратурой. Разве что он оффициально не подпускает к регистру состояния процессора со всякими там битами переноса, но во всём остальном он хорош. И если бы вы попробовали написать синтаксический парсер этого языка, то больше бы не докапывались до него. Я вообще считаю, что он во много просто гениален. Очень простой и при этом мощный.
По поводу модульности в C. Разве
sudo apt-get install libeventне похоже наnpm i libevent?
Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.
Про
printfвообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.
Ну и так далее...
И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.
NeoCode
12.02.2017 15:32+2Конфиги имеют может и примитивный, но не единый формат. А нередко конфиги имеют еще и скрипты внутри… Вот недавно была статья про GRUB. Там есть grub.cfg. Вроде и расширение «cfg» — но нет, куча скриптового кода на каком-то шелл-подобном языке (кстати, на каком? а понятия не имею, расширение же не «sh»… да и может ли быть «шелл» когда еще ОС не загружена?..)
В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.
Далее. XML конечно тяжеловат, а JSON вполне нормален. Особенно предложенный JSON5. Это должна быть не замена «простым текстовым» конфигам (которые просто ключ-значение), а вариант для сложных конфигов, имеющих иерархическую внутреннюю структуру (а большинство таки имеет ее). Собственно, на этом форматами конфигов можно и ограничиться. И еще, одна вещь которая хороша в винде и не свойственна линуксу: расширения. Они должны быть стандартизированы, и для конфигов тоже. Это важно в том числе и для GUI -утилит, которые могли бы просканировать директорию с конфигами и предоставить пользователю унифицированные средства настройки системы из GUI.
Далее, бинарные утилиты. Ну так для текста тоже нужны специальные утилиты — текстовые редакторы. Нужно просто разработать простой и понятный бинарный формат и написать сначала стандарт, а потом и утилиты.
Далее, по языку С (и С++). 15 лет на них пишу, и главная проблема — именно отсутствие модульности и механизм инклудов. Нужно просто принять стандарты С 2.0 и С++ 2.0 в которых выкинуть (да, именно выкинуть, без оглядки на легаси совмесимость) весь этот ужас, и развивать дальше только их. Любые изменения в старый С и С++ заморозить на уровне комитета по стандартизации. Все новые вкусные плюшки добавлять только в 2.0. И все перейдут как миленькие. И легаси код перепишут — благо, в целом языки останутся очень похожими. Заодно в процессе переписывания и кучу багов исправят, т.к. некоторые вещи связанные с типизацией стоит сделать строже.
Язык shell. Я например на нем и не пишу ничего, но приходится вносить изменения в существующие скрипты. И эти скрипты оказываются не такими уж и маленькими.
Винда тоже неидеальна. Некоторые вещи в винде вообще ужасны. Но пост-то не о винде, а о том как сделать юникс (главным образом линукс) лучше.immaculate
12.02.2017 16:06+5Конфиги у нетривиального софта могут иметь еще и логику (если-то-иначе), и циклы, и много чего еще. Это не описать JSON. Теоретически годится XML, но XML — это ужас-ужас. Как вспомню XSLT.
Мне кажется, проблема высосана из пальца. Почти никогда не испытывал проблем с конфигами. Да, они часто очень разные, но так и программы разные, с разными требованиями. Никому не приходится работать с конфигами всех программ каждый день. Необходимый минимум легко запоминается по мере работы, в случае затруднений можно посмотреть man.
Например, я уже лет 5 или больше не трогал конфигурацию grub. Не было надобности. Если понадобится, разберусь с форматом конфига, и он мне еще 5-10 лет не понадобится.
Crandel
12.02.2017 16:15+3Третьему питону уже почти 10 лет, а до сих пор куча проектов на втором, а с/с++ намного сложнее и следует еще учесть что там нету одного стандартизованного компилятора, как CPython, на который ориентируются остальные интерпретаторы Python
Holix
12.02.2017 16:19У grub реально есть свой CLI. Так что всё логично. :)
Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.
Для большинства маленьких утилит как раз достаточно пробежаться по строчкам и выделяя ключи распихать значения по статическим переменным. И никаких лишних зависимостей и динамических структур.
Большие и жирные программы могут и в JSON хранить, если им так удобнее. Но ведь не хранят. Почему? Может простые форматы эффективнее для их решения?
Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман. За как будто ясным API скрывается ужас реализации с колоссальным дублированием кода и потреблением ресурсов. Я в 90-ых годах фанател от C++ и думал, что ООП очень помогает эффективности. Но когда познакомился с реальностью был в ужасе. Люди не умеют пользоваться ООП.
Лично мне в C не хватает строгой типизации и объявления функций в функциях с доступом к локальным переменным. Но даже имеющийся С годен. Достаточно просто делать продуманные API.
И кстати, про C 2.0 согласен. Можно было бы сделать :) Просто чуточку выправить. Но как грузить модули динамически со статической типизацией без извратов?
В целом спор бесполезен пока мы не договоримся о целях и приоритетах. Кто-то пишет компактно и эффективно, а кто-то пишет без оглядки на ресурсы, но с как бы комфортом. Отсюда и вкусы разные.
NeoCode
12.02.2017 17:05Я в курсе и про printf (то что существует printf это следствие отсутствия в Си синтаксических макросов, которые бы могли распарсить форматную строку на этапе компиляции, да еще и типы аргументов проверить...). Я в курсе как работает strcmp. И про json тоже.
Я не против SAX-подобной идеологии для конфигов (т.е. без «DOM», без хеш-таблиц и деревьев в памяти), и да — в большинстве случаев простого текстового файла типа «ключ-значение» будет достаточно. Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.
А что такое «грузить модули динамически со статической типизацией»? Модульность на этапе компиляции лишь означает, что никаких инклудов, а вместо них в проект подключаются модули (файлы в специальном формате — по сути сериализованные синтаксические деревья кода на С/С++), которые компилятор сразу все загружает в единое синтаксическое дерево, а не парсит один инклуд по 100500 раз для каждого *.c и *.cpp файла (precompiled headers это тоже костыли).Holix
12.02.2017 17:28Я про модули не понял. Он же по сути состоит из двух частей: объявления и непосредственно кода. Объявления подгружаются с помощью include ибо они не должны быть большими(у разумных людей). А код уже скомпилированный в виде архива/объектника/библиотеки.
В объявлениях могут быть макросы коие никак не представляются в коде. Т.е. заголовки модулей не могут обладать всей мощью include. Следовательно модуль придётся упростить до набора внешних функций, переменных или констант.
Где-то в исходнике модуля надо ввести аттрибут 'extern' из которого в неявном виде будет выделяться объявление(такой уже есть).
Текстовые include вы не хотите, но всё равно придётся вводить директиву подключения модуля. Что-то вроде
#import <stdio>. Оно чем-то принципиально лучше#include?NeoCode
12.02.2017 17:50Я же написал — принципиальные отличия будут в работе компилятора. Почитайте как это устроено в C#, Java, в любом другом языке программирования. Модули это самая ожидаемая фича С++, кто об этом только не пишет.
Сейчас С/С++ работает так. Есть c(pp) файл — в нем в начале десяток инклудов, каждый из которых еще нередко тянет за собой кучу других инклудов. Компилятор рекурсивно раскрывает все эти инклуды и делает в памяти один большой файл, в котором включен код всех инклудов и в конце код собственно с(pp) файла. И все это колмпилирует.
Затем компилятор переходит к другому файлу. А там такая же ситуация (возможно набор инклудов немного другой). Итого, каждый раз(!) компилятор формирует в памяти огромные файлы с кучей всего и их компилирует.
И ладно в Си, там инклуды всего лишь объявления функций и структур. А С++ с его бешеными шаблонами? Когда огромные объемы кода (именно настоящего кода, а не объявлений) приходится держать в заголовочных файлах?
При модульности эта операция делается один раз для всего проекта. Да, разумеется единицей трансляции станет не файл, а проект — но что в этом плохого? Сами по себе концепции пофайловой компиляции и линковки тоже устарели, и их тоже давно пора пересмотреть.kmu1990
12.02.2017 18:04Небольшое замечание. Я сталкивался с проектом на C++ (одна библиотека с не самым малым количеством шаблонов, она даже частично освещалась на хабре), так вот я не мог ее собрать, потому что компилятору просто нехватало памяти (8 Гб всего в системе) — при неудачном стечении обстоятельств, когда процессы (собирал 2-мя процессами) одновременно брались компилировать особенно страшные файлы все это дело фактически останаваливало систему целиком.
Суть истории в том, что в некоторых ситуациях делать целый проект единицей компиляции может быть не самой удачной идеей, потому что компиляция и линкова могут стать слишком требовательными к ресурсам. Прелесть модулей как раз в том, что их можно собрать один раз и потом просто использовать. Но с шаблонами C++ и необходимостью объявления перед использованием не очень очевидно как этого добиться. Лучшее что мне известно на данный момент — это прекомпилированные заголовочные файлы (некоторые компиляторы поддерживают такую фичу).NeoCode
12.02.2017 18:20Прекомпилированные заголовочные файлы это костыль. А с модульностью все было бы очень просто: модули (в том числе и с шаблонами) хранились бы в двоичном виде (в виде синтаксического дерева) и весь процесс компиляции (и линковки заодно) состоял бы в загрузке модулей в память в единое синтаксическое дерево и генерации целевого кода из этого единого дерева.
Проблема шаблонов в том, что кому-то очень умному пришла в голову мысль писать на них программы как на функциональном языке (в результате шаблоны раскрываются рекурсивно в какие-то другие шаблоны, что и сжирает всю память); ну так это решается введением нормальных синтакических макросов — как только они появятся, у подавляющего большинства быстро отпадет желание писать метапрограммы на шаблонах.kmu1990
12.02.2017 18:281. Прекомпилированные заголовочные файлы — хранят в каком-то виде описание структуры содержимого этих файлов после препроцессинга, парсинга и прочего. Т. е. фактически ваши модули. И нет это, все равно, не просто в C++.
2. Та библиотека, о которой я говорил, использовала шаблоны в их сравнительно какноничном виде — для организации generic контейнеров. Сами контейнеры были довольно сложными, но винить шаблоны в данном конкретном случае нельзя.
3. Чем принципиально синтаксические макросы отличаются от шаблонов? Другим синтаксисом? Они будут принципиально экономичнее или что? В чем суть синтаксического макроса, что делает препроцессинг (не всмысле стандартный препроцессор C/C++, а в общем преобразование структуры программы) синтаксическим макросом?NeoCode
12.02.2017 18:37Прекомпилированные файлы работают зачастую криво. Или вот еще — если есть группа связанных проектов («solution» в терминах VC++) и у них есть общие заголовочные файлы, то для каждого проекта из группы придется генерировать свой precompiled header.
Синтаксический же макрос это просто нормальная человеческая реализация того, что на шаблонах С++ реализовано так как оно реализовано. Если мне надо цикл, то я и напишу цикл (и он будет выполнен внутренним интерпретатором компилятора как обычный цикл), а не рекурсивно сгенерирую шаблон из шаблона с отжиранием гигабайтов памяти.kmu1990
12.02.2017 18:531. То что прекомпилированные фалы работают криво — это бага. Баги нужно исправлять. Или вы думаете, что модули по-умолчанию будут bug-free?
2. Т. е. вам не нравится по сути функциональность и синтаксис, вам нужен императив? В таком случае я скажу, что это ваше предпочтение, но не объективный недостаток шаблонов. Впрочем, я тоже не супер фанат синтксиса шаблонов (но это мое личное предпочтение).NeoCode
12.02.2017 19:031. Бага в коде для обхода костылей исправляется сложнее:) Чем чище и прозрачнее архитектура решаемой задачи, тем меньше там возможностей допустить ошибки.
2. Да, мне не нравится синтаксис; мне не нравится то, что шаблоны используются для того, для его они изначально не были спроектированы. Я не против функционального программирования, а когда оно интегрировано с императивным это вообще супер. А то что мы имеем с шаблонами это не проктировалось а было открыто случайно… поэтому сами понимаете о какой архитектуре там может идти речь. Ни о какой.
Все взаимосвязано. Простота и ясность синтаксиса языка приводят к простоте и ясности кода компилятора, значит в нем будет меньше ошибок, он будет потреблять меньше памяти и работать быстрее. И наоборот, когда в синтаксисе языка черт ногу сломит, в коде компилятора будет то же самое.kmu1990
12.02.2017 19:09Чистая архитектура определенно упрощает жизнь, но проблема в том, что из вашего описания я все еще не понял, какой должна быть архитектура такой фичи как модули (то, что вы описали по сути уже имеется в виде прекомпилированных заголовков, и то что они реализованы бажно, ничего не говорит о том, что если переименовать их в модули, все станет лучше), и почему эта архитектура обязательно должна стать чистой, в отличие от того, что есть.
NeoCode
12.02.2017 19:31Я бы и сам не отказался от хорошей статьи (возможно на английском) по правильному объяснению модулей. Может другие хабровчане подкинут ссылок?
Я как-то набрался информации из разных источников, в голове она сложилась в более-менее единую картинку, но раз вы не поняли то значит я не могу нормально объяснить:)Gryphon88
13.02.2017 16:08Может, Вам будет интересно это:
Gustedt "Modular C"
Gregor "Modules"
Хотя я бы тоже хотел почитать про модули понятным языком и без Паскаля.
mayorovp
13.02.2017 09:44А как вы хотели генерировать общий precompiled header для разных проектов с разными настройками компиляции, разными инклюдами и прочим?
Если же все это у них — общее, то я не понимаю почему вы не смогли создать для них общий precompiled header.
Holix
12.02.2017 18:17Ну, если вспомнить Turbo Pascal… Там тоже заголовок модуля прекомпилирован. Но, как правильно замечено в следующем комментарии, шаблоны C++, некий аналог макросов, очень сложно прекомпилировать.
Но самой главное препятствие — препроцессор. Модули возможно ввести только когда отказаться от него, а это полная перестройка всех исходников. Это будет другой язык.
NeoCode
12.02.2017 18:25Все очень просто, и с препроцессором тоже (хотя этот препроцессор, т.к. лексические макросы — это не самое лучшее что может быть...). В двоичную структуру модуля точно так же можно ввести ноды условной компиляции, даже ноды циклов и т.п. Да, конечно это будет означать, что модуль внутри будет чем-то вроде кодогенерирующего скрипта, а не просто статической таблицы.
Holix
12.02.2017 19:04В итоге это будут не модули, а нечто жутко не простое. С++ уже сам по себе перегруженный язык и с такими модулями он вообще станет сложнее windows. ;)
Честно скажу, мне нравятся простые и лаконичные языки. C хорош своей простотой. А C++… — Бьёрна явно слишком занесло.
zhigalin
13.02.2017 14:24+3Просто я хочу чтобы этот формат был стандартизирован и унифицирован, и чтобы тогда уж ничего кроме «ключ-значение» в него вставлять было нельзя.
Просто я хочу чтобы всё штаны были зелёные а шорты красные и чтобы тогда уж ничего перекрашивать было нельзя.
0xd34df00d
12.02.2017 21:27+3Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр.
Не обязательно. Никто не мешает по структуре сделать парсер, который именно эту структуру будет заполнять без всякого динамического выделения памяти.
Кто-то там сверху писал про строки. В C++ std::string это кромешный ад и обман.
А в чём именно ад и обман? В чём колоссальное потребление ресурсов?
safinaskar
14.02.2017 21:42+1Внедряя JSON везде вы усложняете жизнь простым программам. Для хранения разобранного дерева надо использовать динамическую память, хеш таблицы, списки и пр. Это типичный подход прикладника. Зафигачить всё с помощью толстых библиотек, лишь бы не думать. :) Без обид. Но именно прикладники заблуждаются про стоимость printf и strcmp.
Минимальная библиотека для работы с JSON занимает не так уж и много места. А если вам так уж нужно эффективно читать файл, то читайте бинарный файл. Это быстрее текстового.
Ну или хотя бы придумайте единый формат под названием "таблица" для таких вот файлов как passwd и fstab. Чтоб не нужно было иметь для passwd один парсер, а для fstab — другой.
tmnhy
14.02.2017 21:53-1Чтоб не нужно было иметь для passwd один парсер, а для fstab — другой
Если следовать вашей логике, то возникает вопрос: парсер для файлов, редактировать которые требуется обычно один раз при установке системы? Не много чести для конфигов — отдельный формат, отдельный парсер-клиент, для изменения пары строчек?safinaskar
18.02.2017 12:54Ну так я про это и говорю. В текущей ситуации каждый конфиг имеет свой формат. И для каждого нужен свой код для парсинга. А я предлагаю для всех конфигов сделать единый формат, ну или для всех конфигов вида "таблица", таких как fstab и passwd сделать некий единый табличный формат
borisxm
12.02.2017 21:53+2В общем, хотите текстовые конфиги — пожалуйста, но они должны иметь единый, унифицированный и стандартизированный формат для всей ОС. «Ключ = Значение». Ну еще комментарии. Все, точка.
Очень категорично. Нынешний зоопарк файлов конфигурации проистекает из достаточно свободного и независимого развития отдельных подсистем. Где-то интерпретируемые вставки весь полезны, а где-то вредны. С unix'ами имею дело более 20 лет, и разнобой в файлах конфигурации, это последнее, что может меня раздражать.
Нужно просто принять
Так вперед! Продвигайте и реализуйте прогрессивные идеи. Сообщество Unix-подобных систем не на столько закостенело — постоянно появляются новые разработки. Что-то приживается, что-то отмирает.
sumanai
12.02.2017 16:41+1По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?
Проблема в том, что apt-get это внешняя зависимость, не контролируемая программистом. Какая там будет версия, будет ли она совместима с программой? А с npm, composer или любым другим пакетным менеджером для языка программирования всё ясно и предсказуемо.Holix
12.02.2017 16:57И реально никто не сделал такого для C? Там ведь тоже можно сделать что-то вроде package.json и придумать общую схему для подсасывания зависимостей и сбора include папки из пакетов.
vintage
12.02.2017 18:05+6Всякий, кто пытался это сделать — случайно изобретал новый язык программирования. :-D
kekekeks
12.02.2017 19:39А потом приложения будут таскать всё с собой и весить под две-три сотни мегабайт, если не больше. Зато ясно и предсказуемо, ага.
sumanai
12.02.2017 22:29Ну да, тут нужен компромисс между размером и независимостью. Включение в код приложения нужно для редких фич, которые не факт что будут в каждой используемой ОС, а включать в каждое приложение свою реализацию SSL или там zip нет смысла. И то, что в C нет никаких средств для модулей- его совсем не красит.
Alexsandr_SE
12.02.2017 20:02Хорошо показывает фразу выше, мол человек ко всякой кривизне привыкает, дай только время.
Идеала нет, и много зависит только от привычек.
safinaskar
14.02.2017 21:18+1Я для кого объяснял? Я в своей статье разрушил аргументы типичных фанатиков UNIX, а вы тут опять с ними лезете. Объясню по пунктам что ли.
Текстовые конфиги в большинстве своём имеют настолько примитивный формат, что парсятся на раз
У них у всех разные форматы. И многие используют свои правила эскейпинга специальных символов (тот же fstab). То есть просто в тупую парсить fstab регексами, read'ом, cut'ом нельзя, нужно учитывать эти правила эскейпинга. Иначе вылезут баги, вплоть до багов с безопасностью. Поэтому у них должен быть один формат. JSON, YAML, что угодно. Который парсится стандартными библиотеками с гарантированной правильной работой с эскейпингом. И это не говоря попросту о том, что тогда не надо будет для каждого файла писать свой парсер.
В итоге, для настройки системы достаточно текстового редактора и интеллекта!
Так тут я не спорю. Просто используем единый формат всех конфигов.
JSON и XML не годятся для человека. Они требуют сложного парсинга, трудно читаемы и их структуру легче поломать.
JSON и XML (особенно JSON) достаточно хорошо пишутся и читаются человеком. Они требуют написания всего одного парсера для каждого языка программирования. Да, JSON можно попортить, как и, скажем, passwd и fstab.
Для бинарных форматов вообще будут нужны специальные утилиты. И, если их форматы универсальны, так же требуют парсинга. В обратном случае хранимые бинарные структуры будут платформо-зависимы и требовать регулярного обновления при добавлении новых полей.
Б@#, добавьте новый столбец во fstab! Вы этим поломаете кучу скриптов. А если бы использовался JSON или некий универсальный JSON-подобный бинарный формат, то почти ничего бы не сломалось. Просто в JSON-хеше появилось бы новое поле.
Для критичных для производительности файлов, особенно если их будет править не только человек, но и машина, нужен бинарный формат, я уже объяснял в статье. Плюсы бинарного представления перевешивают минусы. Кто-нибудь здесь правил вручную passwd последние пару лет? passwd как пишется, так и читается обычно машиной. Так зачем ему тогда текстовое представление? Кому нужно подредактировать passwd, тот пускай подредактирует, используя специальные инструменты.
По поводу языка C тоже скажу. По сути это кроссплатформенный ассемблер. Он должен обеспечивать полный контроль над аппаратурой. Разве что он оффициально не подпускает к регистру состояния процессора со всякими там битами переноса, но во всём остальном он хорош. И если бы вы попробовали написать синтаксический парсер этого языка, то больше бы не докапывались до него. Я вообще считаю, что он во много просто гениален. Очень простой и при этом мощный.
Я для кого тут объяснял? Я не придираюсь к арифметике указателей, отсутствию сборщика мусора и т. д. Всё это так и должно быть, для того язык и задумывался. Но у C есть куча реальных недостатков. Которые теоретически можно исправить, оставив язык при этом "кроссплатформенным ассемблером". Ужасный препроцессор вместо нормальных гигиенических макросов, отсутствие даже опциональной проверки границ массива неким единым и стандартным способом, отсутствие нормальной работы со строками (последние два пункта приводят к постоянным проблемам с безопасностью), отсутствие удобных инструментов без legacy (мультиплатформенный менеджер пакетов, система сборки).
По поводу модульности в C. Разве sudo apt-get install libevent не похоже на npm i libevent?
Нет. Потому что npm работает на UNIX-подобных системах и Windows. А apt-get — только в системах, основанных на Debian. Хочется иметь стандартный популярный обкатанный менеджер пакетов C для большого числа ОС, как минимум UNIX и Windows.
Понятное дело, сами пакеты необязательно будут мультиплатформенны. Но некоторые из них, хотя бы даже curl — будут. И сам менеджер пакетов будет мультиплатформенным.
Ещё в C нет namespace'ов.
Язык Shell. Не стоит на нём писать что-то большое. Разбейте задачу на отдельные функции и сделайте их на подходящем для этого языке и только затем совместите их функционал в одном sh-сценарии. Это я пишу потому, что есть некоторые личности, которые пишут JSON парсеры/генераторы на Sh и потом жалуются.
А я с этим не спорю.
Про printf вообще смешно. Если вы не понимаете как работает эта функция, то согласитесь, что проблема не в ней.
Я с самого начала понимал, как она работает. И знал, что printf парсит строку формата в рантайме. Но я думал, что так и надо, что раз так сделано, значит, это занимает не так уж и много времени. Потому что писали какие-то умные дядьки. А потом (когда увидел тесты от H2O) понял, что это не так. Что printf, как и многое в C и UNIX — это тупо кем-то оставленный костыль. Ну вот этой моей находкой я и делюсь.
И кстати, я не говорю, что unix идеальна. Очень много бардака. Особенно там, где разработку вело много народа. И на мой взгляд, историческое наследие в виндовс на много тяжелее и буквально жирнее.
Возможно. Тут я тоже не спорю.
И я не предлагаю всё переделать в UNIX'е. Я просто хочу, чтобы люди кое-что про него знали.
Izaron
12.02.2017 14:25+2Автор неплохо проехался по C/C++, хочется уточнить
Вообще язык C разрабатывался одновременно с UNIX, поэтому критикуя UNIX, нужно покритиковать и C тоже
Немного кривая аргументация
Скажу лишь вот что. В C до сих пор не научились удобно работать со строками
Да, это плохо, что где-то не научились удобно работать со строками, но вообще да, строки там не очень удобные. В C++ из коробки std::string, это лучше.
И это не говоря об отсутствии простой, удобной и мультиплатформенной системы сборки <...> стандартного менеджера пакетов
Менеджер пакетов и системы сборки есть, и некоторые отличные, даже удобные и мультиплатформенные, но нет и не могло быть раньше официально признанного, так как всю свою историю C/C++ не был «монолитом». Сайта официального нет, тем более с модной минималистической CMS-кой, но от этого он не стал хуже, правда.
В реально больших проектах, таких как Gnome, Firefox — свои системы сборки и зависимостей. Они создавались, когда никакого гитхаба и маркдауна в документации не было, а ждать очередной модный мега-язык как Rust было невтерпежь.
void (*signal(int sig, void (*func)(int)))(int)
Какой ужасный язык, у меня уровень сахара в крови упал!
Sad_Bro
12.02.2017 14:37холиварный пост, и php гавно (да когда то было, но придание до сих пор живо как я понял), и С. Пока ~90% серверов работает на gnu linux/unix системах ваши доводы можно трактовать как «ребята вы все дураки что используете это и зарабатываете деньги, давайте я вас научу как работать неучей. „
NeoCode
12.02.2017 15:08+6Нет. Это можно трактовать как то, что бизнесу пофиг на Совершенство, Безупречность и Гармонию, ему «работает и ладно, лишь бы бабло капало».
Sad_Bro
12.02.2017 15:37вы говорите про недостижимые вещи, все равно где то будут компромиссы. И через 10 лет этих компромиссов накопится на подобную статью.
TaHKucT
12.02.2017 20:03+1бизнесу не нужно «работает и ладно», бизнесу нужно «что бы работало не хуже чем у конкурентов, а если даже лучше, то вообще замечательно», но почти все конкурируют друг с другом почему то на линуксах, виндусах и иногда бздях, а план9, инферно и остальные не очень распространенные ОС занимают свою небольшую нишу и пока что не претендуют на «ОС общего назначения»
NeoCode
12.02.2017 23:22Бизнесу надо в основном «быстрее чем у конкурентов». Лучше там или не лучше — в определенных пределах пофиг; главное ввязаться, заявить о себе, а пипл все равно схвавает.
То есть конечно откровенно не работающие программы в продакшен не попадают, но вот ради перфекционизма и внутренней архитектурной красоты никто заморачиваться не будет.lubezniy
13.02.2017 00:59Ну да. Потому что при перепроектировании и переделке люди обязательно наделают ещё и своих багов (и кодовых, и архитектурных), лет 15 будут их героически устранять, а потом придёт новый сноб, скажет, что всё это legacy… и так по кругу.
allter
12.02.2017 14:41Годный наброс! Надеюсь, те, кто заразится этим отношением к legacy Un*x, будут рекламировать свои поделия не в качестве его наследника.
> У них, видимо, был только ассемблер и текстовый редактор.
Ассемблер с редактором Томпсон тоже сам написал, на GECOS системе.
DrLivesey
12.02.2017 15:52+2Статья интересная просто потому, что много всякого разного собрано в одном месте, но:
Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал
это, простите, что?
delvin-fil
12.02.2017 15:54+2Было бы лучше, если бы утилиты выдавали вывод в виде XML, JSON, некоего бинарного формата или ещё чего-нибудь.
Чего?
Я еще спрашивать буду?
Уважаемый, не нравится командная строка(как вы написали bash/sh/ksh) — ваша, блин, проблема!
А, вы про реестр…
Я мышь терпеть не могу!
Так что, высказались, будьте довольны!
dion
12.02.2017 15:59+1Я конечно не спорю, в статье есть много достаточно правдивого. Но реально некоторые вещи притянуты за уши…
Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом. Как это сделать?
Вот допустим, нужно забить гвоздь. Да, я знаю, что такое надо делать молотком. Но давайте предположим, что это нужно сделать непременно микроскопом. Как это сделать?
Я не закончил про UNIX shell. Рассмотрим ещё раз пример кода на shell, который я уже приводил: find foo -print0 | while IFS="" read -rd "" A; do touch — "$A"; done. Здесь в цикле вызывается touch (да, я знаю, что этот код можно переписать на xargs, причём так, чтобы touch вызывался только один раз; но давайте пока забьём на это, хорошо?).
А почему не find foo -exec touch {} \;?
Код на любом другом языке программирования будет работать быстрее этого. Просто на момент появления UNIX shell он был одним из немногих языков, которые позволяют написать это действие в одну строчку.
Код на любом языке можно написать так, чтобы он работал быстрее этого. В том числе и на shell. Более того, на любом языке можно написать код, который будет медленнее этого…delvin-fil
12.02.2017 16:37-3Вы только представьте! Вот допустим, нужно удалить все файлы в текущей папке с размером, большим 1 килобайта. Да, я знаю, что такое надо делать find'ом. Но давайте предположим, что это нужно сделать непременно ls'ом. Как это сделать?
Каталог не бывает менее 4Кб
Я не закончил про UNIX shell. Рассмотрим ещё раз пример кода на shell, который я уже приводил: find foo -print0 | while IFS="" read -rd "" A; do touch — "$A"; done.
grep -i же
Более того, на любом языке можно написать код, который будет медленнее этого…
Напишите на Python!!!
Уважаемый, Ваше негативное отно…
… да не буду писать!
VovanZ
12.02.2017 16:30+5Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.
Теперь к самой сути статьи.
Очевидно, что идеальная программа/система, написанная за бесконечное количество времени и денег никому не нужна.
Людям нужно нечто достаточно хорошее, способное решать задачи прямо сейчас.
Поэтому победил UNIX, несмотря на все его недостатки.
Поэтому никто не готов "ломать весь мир" и переписывать все программы, переходя на Plan 9 или что-нибудь ещё, проще вставить костыль в UNIX, чтобы оно работало прямо сейчас.
Что с этим делать? Ничего. Мир жесток, несправедлив и совсем не идеален. Нужно просто научиться жить с этим дальше. Научиться решать реальные задачи, обходя подводные камни.
А вообще, спасибо за статью, очень много интересных исторических и технических фактов. О многих из них я раньше не знал, но теперь почитаю про них подробнее.
popov654
14.02.2017 15:08Перфекционизм в предельной стадии — зло, соглашусь. И идеальных систем не бывает в реальном мире, тем более, чтобы все считали систему идеальной.
Но вот этот прагматизм слегка добивает… Зачем здесь и сейчас, если можно придумать что-то новое, лучшее, что будет работать когда-то потом и приносить пользу? Я бы с радостью занялся изучением Plan 9 и портированием некоторого софта на неё, будь у меня несколько больше знаний в этом вопросе. Мне кажется, это довольно интересно и познавательно. Как и вообще освоение чего-то нового.
safinaskar
14.02.2017 23:31Начнём с того, что сравнивать C с Rust (Cargo) — это какое-то читерство :)
У авторов Rust/Cargo была возможность внимательно изучить все предыдущие подходы, взять из них всё самое лучшее и выкинуть всё плохое. Авторы C были первопроходцами, естественно они допускали ошибки.Ну да. Всё правильно. Просто есть на свете люди, которые этого не понимают. И которые считают Rust посягательством на святой неприкосновенный C. Вот для них и предназначена моя статья. И вообще со всем вашим комментом я согласен. :)
Mingun
15.02.2017 23:16Что с этим делать? Ничего.
Почему ничего? Ломать костыли. Исправлять. Проблема лишь в том, что пока груз поддержки легаси не превышает выгод от его избавления. Что лучше — один раз поломать написанное плохо и написать лучше и потом все оставшееся время получать профит или и дальше продолжать жевать кактус, накапливая ненависть? Когда-то чаша переполнится и костыли сломают. Будут новые костыли, более прямые и долговечные :) Но мне кажется, многие этого не понимают и цепляются за старое. Думаю, именно их автор назвал фанатиками.
Вообще говоря, какие-то подвижки вроде начинаются уже. Тот же systemv. Есть какое-то понимание проблемы и это хорошо, кто бы что ни говорил.
khim
16.02.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.02.2017 17:16Вообще, забавно. Автор на скорую руку сляпал пост, разжигающий священную войну, и ни разу не появился в комментариях. Судя по прошлым постам из профиля — похож на полупрофессионального тролля.
Ivan_83
12.02.2017 18:27-7Жир с троля-ламера так и стекает, видать по весне обострился голод :)
Подкину ещё хавки :)
Текст vs реестр/бд.
Текст удобнее для человеков. Отдельные файлы легко бэкапить и переносить.
Скорость парсинга для мелких файлов (до мегабайта) не отличить от бинарного формата даже под микроскопом.
Обычно по каждому есть документация.
В венде нихрена не документировано. Все гадят по реестру рандомным образом. Чистить это не возможно. В итоге оно разрастается до жутких размеров и вычистить всё можно только реинсталом системы.
Язык C vs остальные.
1. Язык годный. Простой, понятный, быстрый.
2. Поди перепиши на очередной хипстерский язык всё что понаписано.
3. Все кто не осилил — пусть и дальше ноют.
Виндовс системы сплошь состоят из костылей.
1. Совместимости с багами всех предыдущих систем которые смогли осилить разрабы.
2. Обновления хоть и типа бинарные но тормозят и ставятся так долго что у меня из исходников быстрее собирается всё приложение.
С обновами приезжает мусор против левых активаций, с принудительными апдетерами до новой венды и просто глючные обновления которые в лучшем случае просто не встают, а в худшем система потом не загружается.
3. Постоянно ломают привычки тех кто за всё это платит: в семёрке диалоги открытия/сохранения стали не удобными, в восьмёрке вообще всё стало отстойным и так и осталось…
4. Про реестр я уже написал.
Переносимости никакой. Не возможно/трудно взять и таскать за собой конфиг нужной софтины чтобы не настраивать в нуля на новой машине. Автор должен отдельно кодить импорт/экспорт настроек для этого. Почти никто это не делает.
5. Производители дров пишут как попало или откровенно зловредные дрова.
Дрова под DVB тюнера работают иногда, редко стабильно. А дрова для ft232 специально ломали «перацкие» usb-com шнурки.
6. В венде нельзя из коробки нескольким юзерам работать со своими клавами-мышками-мониторами одновременно, нужно каждому юзеру по своему системнику с вендой.
7. Венду банально перетащить на другое железо уже огромная проблема, так чтобы взять диск и воткнуть в другое железо — несбыточная мечта юзера и страшный сон мс.
8. Кучи идиотских ограничений, как будто у мс не она венда а штуки две совершенно разных: для юзеров и для серверов.
(В упор не понимаю людей которые ставят себе перацкую венду отличную от серверной на десктоп: всё тоже самое только в серверной лимитов меньше и дурацких апдейтов почти нет)vintage
12.02.2017 18:47+1Как минимум на C++ или D переписать не так уж и сложно. D так вообще бинарную совместимость обеспечит.
Ivan_83
13.02.2017 23:41-4Нахрена?
Вот мне лично вполне всё нравится в си, всё работает.
Плюсы это 800+ страниц описания/документации, чего ради?
Д — даже не смотрел что такое.
Руст мне отчасти понятен посыл: авторы хотели безопасный си компилятор с кучей проверок, более безопасный стандартные функции и тп. В целом в существующих компиляторах и так дохрена анализа и диагностик, проблемы с которыми борются авторы языка преувеличены. Ну и некоторые раньше пилили библиотеки, потом фреймворки, а теперь у них дошло до собственных языков.
В общем написать можно любой язык, но авторы их всех программисты и ни разу не думали о людях.
Все языки которыми пользуются люди относительно простые, никаких 800 страниц правил нигде нет, не было и не будет, ибо сложным языком никто не сможет пользоваться целиком сразу, неизбежно будут развиться диалекты которые будут активно использовать только отдельные части а всё остальное понимать не будут.
И не только си жив до сих из за простоты, бейсик, паскаль тоже весьма простые и от того были весьма популярными и используемыми.
Чем проще язык — тем больше людей его будут использовать, тем больше профита им будет от использования.
Взять тот же си — куча примеров для всего на свете на нём, книжки за все годы не выросли в толщине, специалисты есть даже с 30+ летним стажем.
При этом фундаментальных проблем в языке нет, всё зависит только от самого программиста.
2 sumanai
Поди создай зеркало на домашней венде, там тебе не дадут, придётся покупать «аппаратный» рейд контроллер за 20 уе. Пользователя завести и то проблема. 10 одновременных соединений к шаре. Рдп сервер сильно кастрирован.
Ну вот ты сидишь на ХР, она работает. Дальше ты медленно умираешь потому что всё больше приложений у тебя просто перестают запускаться и тебе нужно юзать старые приложения… которые перестают понимать современные форматы или новые особенности давно существующих форматов.
Примерно через 10 лет после списания 98 венды её адепты наконец то самоликвидировались, с ХР можно просидеть ещё лет 5, если сильно упёртый то 10-15, со всё возрастающим дискомфортом и ощущением что ты в цифровом гетто.
Вопрос только нахрена это делать?
При этом в параллельной вселенной бсд/линух никто себя в такой извращённой форме не насилует.
Ты просто пользуешься ОС, когда есть обновления софта — ставишь. Когда обновляется ОС то тебя это не сильно касается. Иногда нужно что то делать руками, но это зависит как от дистра/ос так и от особенностей использования.
Можно было все 15 лет (из того что я лично видел) использовать ОС без переустановок с настройкой всего с нуля, и в ближайшие лет 10-15 это не изменится. Единственное неудобство за все эти годы это переезд с х32 на х64, тут много где проще было поставить систему с нуля и перетащить конфиги софта.
Софт рос, менялся, но тот же гном2, хфце до сих пор живы и не сказать чтобы кардинально менялись за это время, те настроив один раз можно было только актуализировать настройки и таскать их за собой. И никакие привычки не ломались через колено потому что дизайнеры решили что так лучше.
Иными словами есть вселенная где ты один раз ставишь систему и софт а потом просто получаешь обновления. Любое приложение которое ты ставил штатными средствами можно проверить на предмет не потерялись или файлы или не изменились ли они и переустановить без рисков потери конфигов.
Поэтому тема захламления системы весьма актуальна когда у тебя время жизни системы и приложений ни чем не ограничено.
Тут нет эры: 9х, ХР, семёрки и далее.
Тут старые дрова продолжают работать если есть хоть кто то с железом для них.
Я как то ради интереса сделал очередную копию своего десктопа на фре и снёс все порты. Осталось порядка десятка файлов, и те файлы были конфигами которые я поменял. И пару пустых папок и пару фалов которые я не трогал.divanikus
14.02.2017 01:48Отвечать на статью, где в явном виде нет сравнения с виндой, гневной тирадой про винду — это уже паталогия какая-то по-моему.
Чего там, паравиртуализацию во FreeBSD уже завезли? Как с поддержкой аппаратного ускорения современных видеокарт? А юникод в консоль без костылей завезли?Ivan_83
15.02.2017 00:03-2Просто подкинул ещё хавки, пока она свежая. А то скоро о проблемах венды буду знать только из новостей, а там до сих пор пишут про драйвера к коврикам для мышки да безопасники страху нагоняют чтобы бабла срубить :)
Хз, мне виртуалбоха хватает.
Замечательно, только на днях выкатили новый хорг. Но перед покупкой видюхи нужно посмотреть в вики на предмет поддержки.
Не понимаю о чём вопрос :) А в венде юникод появился?) Или надо руками ставить unicow.dll ?)
Хотите больно тролить — поставьте и попользуйтесь, реальные проблемы они совсем не те о которых написано в инструкциях на лурке.
Проблемы человека который решил поставить посмотреть, ниасилил потому что не привычно или оно не работает или совсем по другому — сильно отличаются от тех кто на этом сидит.
2 vintage
Там написано как переходить но не зачем.
Я не собираюсь переписывать свой код или изучать этот язык и писать новый код на нём потому что не вижу в этом никакого смысла.
Мне интересно решать задачу а не задрачиватся на выборе языка и его языковых извратах.
2 sumanai
Зеркало — потому что так захотелось.
У домашней венде раньше не было нормальной оснаски для рулёжки юзерами. А ещё у меня есть зачотная софтина для этого, там все свойства юзера доступны как на серверной венде, вплоть до разрешённых часов входа.
Нет никакой домашней ОС. Очнись уже. Венда одна и всё позиционирование — сплошные искусственные ограничения.
Не знаю популярных дистров, всегда ставлю минимальную систему и собираю что нужно, поэтому никаких сюрпризов. Что касается остальных — так у них всегда есть возможность заменить один дистр другим и просто перенести свой профиль со всеми настройками и файлами, после чего всё станет как было.sumanai
15.02.2017 00:11Венда одна и всё позиционирование — сплошные искусственные ограничения.
Я спорил? Просто по большей части всё это реально не нужно.
Ну и домашние сборки весят меньше и меньше занимают памяти, так как в них нет приблуд, которыми мало кто пользуется. Но в стране пиратов привыкли везде ставить ультимейт.Ivan_83
16.02.2017 22:28Память на диске — нынче не дорогая.
В оперативе — так нужно отключать лишние сервисы, их и в обычных домашних/про более чем надо.
И да, ХР после старта жрала 100м оперативы, а семёрка 400-600, сколько её не крути.
2 Incidence
Я в курсе, и всего то на 18 лет. Это к свежести вопроса про utf в консоле. Мне лично он там никогда актуален не был.
2 divanikus
Нет гипервизора и не надо, будет вместо фри другая бсд или линух — мне лично пофик.
Не интересовался. У нас геом умеет по сети, но он не фс и ещё что то впили вроде с 11 релизом или раньше.
В линухе точно такие же заморочки. В фре видео стёк линуховый, бэкпортирование обычно отстаёт на кварталы…
Я драйвер нвидии ждал наверное минуты две, пока он там качался. Что было раньше уже не актуально.
В венде тоже всё плохо с дровами: какое старьё не возьми — дров почти всегда нет :)
Дрова для тюнеров — вечная боль с синими экранами. Во фре это вообще не проблема, у нас линуховые дрова юзби устройств засунуты в юзерспейсную прогу, которая работает и работает…
Не надо мне лекций по венде, я это и так прекрасно помню, то был встречно-неадекватный вопрос.
Во фре новый терминал vt с 10х, вместе с UEFI и прочим.
Инфинибанд уже есть.
нетграф обычный, крутизна определяется исключительно кривизной рук и мозгами.
Хз что у вас там за железо что фря не встала. У меня были проблемы только до появления UEFI загрузчика во фре, и то из за епанутости асусовских биосопейсателей (это у них традиция такая: железо хорошее а софт херовый, уже 15+ лет как) и моего упорства в виде не желания менять кавайную GPT разметку на старую MBR.
Дров для PCI тюнеров почти нет (в портах пара каких то есть), дрова для юзби — в принципе всё что в линухе, но скорее всего придётся немного поправить webcamd и пересобрать.
У меня получилось завести бехолдер, нотонлитв, патих дигитал и два китайских устройства для захвата. С бехолдером и китайскими свистками было достаточно поправить конфиг и закоментить пару строк. А с теми двумя пришлось мержить из линуха.
Будет время — напишу скрипт чтобы из линуха на автомате грабить дрова, скорее всего от крези кэта.sumanai
16.02.2017 23:11В оперативе — так нужно отключать лишние сервисы, их и в обычных домашних/про более чем надо.
Сначала ставим лишнее, потом отключаем. И жалуемся на разжиревшие дистрибутивы и ОС. Л — Логика.Ivan_83
17.02.2017 23:01-1С этими претензиями к микрософту.
Я у себя во фряшечке из ядра почти всё выкинул, и из мира порезал ненужного много.
2 divanikus
Ну и используйте.
Жужанье фри не терпит суеты. )
У меня мать проклятого асуса на АМ1 сокете так года два провалялась, пока во фре не запилили UEFI загрузчик.
Собственно если вам нужна фря на вашем экзотическом железе то нужно есть следующие варианты:
— покупать не экзотическое железо, которое уже поддерживается
— пилить нужное самостоятельно
— гундеть вендору в уши чтобы он запилил
— донатить железом и деньгами чтобы это сделал кто то из сообщества
— изобрести машину времени / портал времени и скачать нужное из будущего
Позиция: «мы тут купили какую то херню, почему фря/венда/линупс с этим не работае!?» — она не адекватна для сколь нибудь технического специалиста. Это домохозяйки совершают импульсные покупки.
Про гипервизор и итаниум тоже самое.
Нужно вам — делайте/платите и не гундите.
Free означает что вы бесплатно можете пользоваться и переделывать как хотите и даже продавать, а не то что вам всё будут делать на халяву.
В линухе тоже всё не из воздуха само появляется, просто там народу дохрена и вероятность что найдётся тот кто запилит и/или тот кто заплатит выше.
Само оно на деревьях не растёт.sumanai
17.02.2017 23:05+1С этими претензиями к микрософту.
Почему? Это именно вы ставите неподходящие редакции ОС и выпиливаете из них «ненужное».Ivan_83
20.02.2017 03:03За венду я уже объяснил: ператить на хомячковой версии венды — тупо:
1. мс сливает килотонны говна в апдейтах именно хоямчкам, в том числе и всякие ненужны средства борьбы с активациями
2. нет никаких идиотских ограничений
3. срок жизни ОС ощутимо больше
Пока все охали: «как же мы будем с ХР жить на новых компах где 4+гб озу и большие диски как цеплять? (MBR/GPT)», плевались от висты можно было спокойно сидеть на 2к3х64, и ещё пару лет после смерти ХР, когда уже был сп1 для семёрки)
И вот сейчас пользователи бугуртят как бы им по меньше да повкуснее сожрать говно-десятку, с теми же не отключаемыми апдейтами. Ставили бы серверную версию и не парились.
И количество служб активных из коробки примерно одно и тоже.
2 divanikus
Логика простая: ты или сам или нанимаешь.
Если ты сам не осилил запилить или запустить — твоя вина.
Если вендор не сделал — плохой вендор/мало бабла отвалил.divanikus
20.02.2017 04:41+1Не, логика еще проще. Есть инструмент — делаешь. Нет инструмента — не делаешь. Все оборудование без проблем завелось в Linux и работает до сих пор. FreeBSD тогда таким похвастаться не мог. Проще взять другой инструмент, чем мучаться с непригодным.
sumanai
20.02.2017 16:33мс сливает килотонны говна в апдейтах именно хоямчкам, в том числе и всякие ненужны средства борьбы с активациями
Обновления одни по сути.
нет никаких идиотских ограничений
Я уже писал, что ограничений по сути нет. Обычные пользователи не покупают материнские платы с 4 процессорами и более чем 128ГБ оперативной.
можно было спокойно сидеть на 2к3х64, и ещё пару лет после смерти ХР
Или ставить те же обновления на XP x64, а на x32 до сих пор прилетают.
divanikus
18.02.2017 14:48У вас неправильная логика. Все оборудование было IBM eSeries или IBM Bladecenter, с очень серьезной поддержкой со стороны вендора. Itanium также был в IBM-овском сервере, но уходил на списание. К сожалению вдохнуть новую жизнь фряхой не удалось. Не думаю что закупка ЦОД — дело импульсивное.
divanikus
17.02.2017 15:21Все это конечно хорошо, что сейчас многое появилось. Но в 2009, когда мы поднимали кластер с Infiniband, фряха его не поддерживала. Надо было наверное сказать, что пацаны погодите, пускай железо постоит пока, там пацаны из фряхи еще драйвер не написали.
Учитывая нынешнюю копроэкономику, поддержка древних устройств никак в не помогает ОС продавать себя, рынку нужна поддержка всего самого свежего и сейчас, а не через пару лет.
А так, конечно фряха ставилась везде, но не везде взлетали нужные устройства. Хотя вру, на Intel Itanium дальше Boot Logo продвинуться не удалось, пришлось ставить SUSE.
То что FreeBSD нельзя использовать как основу гипервизора в нынешних реалиях печально. Даже винду можно.
Incidence
17.02.2017 23:26+42 Incidence
Я в курсе, и всего то на 18 лет. Это к свежести вопроса про utf в консоле. Мне лично он там никогда актуален не был.
Больше.
Уже ядро NT3.1 было насквозь юникодным в UCS2, а это 1993 год, то есть 24 года назад.
И ещё долгие годы линуксоиды страдали прикручиванием костылей koi8-r в систему, вот так же, как вы уверяя всех, что БНОПНЯ ВХРЮК лично их вполне устраивает.
Incidence
15.02.2017 01:11А в венде юникод появился?) Или надо руками ставить unicow.dll ?)
Если это такая шутка, то она опоздала лет на 25, как минимум.am-amotion-city
18.02.2017 10:05-1Ну здрасьте. И эмотиконки к цвету подклеивать на лету умеем, и на plane2 не ломаемся, и в консоли можно алиас назвать «?», или, там «?» и приглашение командной строки вот такое (это копипаст моего):
am/proj ? ... ? d latest ? ? ruby-2.2.2 ? aleksei-envy
Да ведь, правда ведь, венда умеет в юникод?
Incidence
18.02.2017 10:22Речь шла о поддержке ядром ОС именованных объектов.
А не о том, какие востребованные в 0.01% случаев свистоперделки можно прикрутить к терминалу через ANSI-коды и прочие не относящиеся к обработке строк вещи.
divanikus
15.02.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 нет, ТВ тюнер хоть и с аппаратным кодеком, тоже нет и т.д.
sumanai
14.02.2017 17:03Поди создай зеркало на домашней венде
Зеркало дома? Зачем?
Пользователя завести и то проблема.
Нет никакой проблемы.
10 одновременных соединений к шаре.
Потому что это домашняя ОС.
Дальше ты медленно умираешь
Ужас какой-то пророчите.
Софт рос, менялся, но тот же гном2, хфце до сих пор живы
Только по умолчанию в популярных дитсрах совсем другое. И при обновлении гном заменился бы на унити, который в первых ипостасях хуже Вин8.
sumanai
12.02.2017 22:39Чистить это не возможно.
И не нужно. Нет, вас действительно смущает пара десятков мегабайт ключей?
Кучи идиотских ограничений, как будто у мс не она венда а штуки две совершенно разных: для юзеров и для серверов
Например? Мне хватает моих 128 ГБ оперативной памяти и кажется двух физических сокетов под процессоры. И это старушка XP x64. Какому пользователю нужно больше?
GarryC
12.02.2017 19:36С одной стороны, нельзя не признать, но, с другой стороны, невозможно не отметить.
saggid
12.02.2017 19:53+6Примерно половина доводов в статье как всегда — просто раздувание слона из мухи, или просто непонимание каких-то моментов реальности. Но остальная половина, конечно, является доводом в определённой степени. В общем, главное — не бросаться из крайности в крайность. UNIX писали обычные люди. И вполне логично, что у него есть и недостатки. Но некорректно говорить, что это полностью плохая идеология.
И это не говоря уж о том, что критичные файлы UNIX (такие как /etc/passwd), который читаются при каждом (!) вызове, скажем, ls -l, записаны в виде простого текста. И эти файлы надо заново читать и заново парсить при каждом вызове ls -l!
А кеширование данных на уровне файловой системы на что было сделано? Не раздувайте слона из мухи, это вообще не проблема.
Вообще, конкретные обстоятельства, возникшие во время разработки оригинальной UNIX, сильно оказали на неё влияние. Скажем, читал где-то, что команда cp названа именно так, а не copy, потому что UNIX разрабатывали с использованием терминалов, которые очень медленно выдавали буквы
Это является каким-то минусом UNIX идеологии? Вроде как в целом мне и самому удобнее писать
cp, а неcopy.
Терминал в UNIX — жуткое legacy
Хрен его знает, чего в этом плохого, но я лично с большим удовольствием пользуюсь энтим самым легаси терминалом, подключаясь к своим серверам по ssh, будучи в какой-нибудь маршрутке, через 3G соединение своего мобильного телефона, который расшаривает на мой ноут Wi-Fi. Короче, опять муху из слона раздуваете, господин автор поста.
UNIX shell хуже PHP!
Да вы запарили со своими загонами в сторону PHP. PHP успешно используется в гигантских проектах, постоянно развивается и имеет некоторые особенности, дающие повод на то, чтобы указывать его как более правильный выбор чем тот же хвалёный Ruby On Rails. Это тоже, наверное, тоже о чём-то говорит.
«А? Что? Lisp? Что за Lisp?» Интересно, да?
Извините, но если честно — не особо. Я бы вполне мог и PHP для подобной задачи использовать, благо он умеет подключаться к серверам по SSH и даже управлять файлами на удалённых серверах, если это необходимо.
Да, так можно. Но часто photoshop'ом или gimp'ом всё-таки лучше. Хоть это и большие, интегрированные программы
Опять перекос непонятно куда. Если речь идёт об одной картинке — да, гимпом и фотошопом удобнее. Когда речь идёт и миллионах картинок и их пакетной обработке — тогда и возникает вся польза идеологии UNIX.
Self_Perfection
12.02.2017 20:32+1Да, терминал в UNIX жуткое легаси. Смотрите, возьмём например поддержку цветов текста. Терминал/эмулятор терминала может поддерживать разное количество цветов/эффектов (мигание, подчёркивание etc). Программа, которая выводит текст в терминал, должна знать, какие возможности она может использовать. Придумали использовать для этого переменную окружения $TERM, которая должна содержать название терминала (эмулятора терминала). Проходит время, разных терминалов развелось сотни. Что по-хорошему должна делать программа, чтобы понять, может ли она использовать цветовую схему с 256 цветов? Нужно проконсультироваться с базой, в которой записано какой терминал что может. Такая база есть и поддеживается в составе ncurses… Что делать программе, если она не хочет зависеть от ncurses? GNU coreutils содержат в своём составе статически вкомпиленный короткий список терминалов с их возможностями.
Окей, как это выглядело для меня, пока я не раскопал: хочу 256 цветную тему в vim. Ага, это определяется переменной окружения TERM. Сейчас у меня konsole при запуске выставляет TERM=konsole. Ставим в .bashrc konsole-256color и в vim всё хорошо раскрашивается, но не через некоторое время понимаю, что ls, grep и т.д. перестали быть цветными…
Сейчас у меня в .bashrc такой кусок кода
#Add more colors if proper TERM was not exported if [[ $TERM != *-256* ]] && [[ $TERM != screen* ]]; then #Workaround for Konsole setting TERM=xterm by default (https://bugs.kde.org/show_bug.cgi?id=212145) #konsole-256color ломает цвета для ls -l, т.к. dircolors такого не знает, можно вылечить задав непустой $COLORTERM, #в vim ломается переход между вкладками по Ctrl-PgUP/PgDown [ -n "$KONSOLE_PROFILE_NAME" ] && export TERM=xterm-256color [ "$COLORTERM" = 'xfce4-terminal' ] && export TERM=xterm-256color fi
Он более-менее работает в большинстве случаев. И мне вообще страшно смотреть в его сторону.
Или вот ещё, заходишь на солярку по ssh и почему-то backspace не стирает символ, а дописывает абракадабру. del работает (или наоборот было?).
Короче, вы просто не лезли в хоть чуть-чуть нетривиальные случаи.
safinaskar
14.02.2017 17:36Окей, конфиги кешируются. Но парсить их нужно всё равно каждый раз
saggid
15.02.2017 04:10Конфиги большими не бывают. Для современных систем, распарсить пару тысяч строк — это ведь вообще мелочь. Тем более, парсинг конфига делается либо при запуске приложения, либо при конкретном вызове команды для обновления конфига.
В общем, всё равно это не является причиной для довода против идеологии UNIX. Тем более это не является доводом в пользу того, что только из-за этого надо теперь брать и внедрять везде реестр. Тем более это не является доводом в пользу того, что система на подобии реестра решит эту проблему и не добавит никаких других проблем.
safinaskar
18.02.2017 15:05-2Я говорил про ls -l. Он читает конфиг каждый раз. Так что что-то по-любому нужно сделать: или поместить passwd в бинарный вид, в БД или в реестр, или фиксить ls, чтобы он по-другому работал. Ни то, ни другое в дефолтных поставках дистров gnu/linux, к сожалению, делать не собираются.
А аргументом в пользу реестра является та ситуация с ext4.
geher
18.02.2017 16:33А аргументом в пользу реестра является та ситуация с ext4.
Это про момент с потерей гномьих конфигов при резком выключении системы?
На самом деле не аргумент. В такой ситуации реестр будет просто способом гарантированно в аналогичной ситуации потерять все настройки одним махом, в то время как при наличии множества файлов есть вероятность, что навернутся не все.
Ведь что есть реестр? А это всего лишь файл, который хранит все те же настройки неважно в каком виде. И при сбое, связанном с выключением в момент записи в этот файл, этот файл может исчезнуть точно так же, как и настройки в приведенном случае.
А спасти от такой проблемы может не реестр, а резервирование (возможно, многократное).
Если обратиться к опыту винды, то там как раз осуществляется резервирование реестра при помощи различных механизмов (рядом с оригиналом хранится копия реестра, плюс копии в "точках восстановления"). Если сбой не затрагивает все копии реестра, то какая-нибудь из них вполне может быть восстановлена в качестве рабочей (естественно, без гарантии сохранения самых последних правок).
Соответственно гномопользователю (или разработчикам гнома) дляпредотвращения случаев с потерей конфигов нужно было всего лишь озаботиться резервными копиями гномоконфигов и механизмом их быстрогого восстановления.
geher
18.02.2017 16:39Доводы разработчика, безусловно, понятны, но они говорят скорее о неправильной работе гнома с текстовыми конфигами, нежели о необходимости использовать реестр.
geher
18.02.2017 16:46В частности в приведенной цитате пишется про некорректно написанные приложения, которые слишком часто занимаются записью в большое количество файлов.
maydjin
12.02.2017 19:55Как touch'нуть все файлы в папке foo
man find | grep exec
Дочитал пока до этого места имхо — посыл всё плохо. Но сравнения с чем то ещё не проводится за редким исключением.
Jogger
12.02.2017 19:57+2Собственно, комментарии в очередной раз доказывают то, что и так известно давно: фанатики — они на то и фанатики, чтоб не слушать логичные доводы. Все аргументы в комментариях сводятся к «а в винде ещё хуже» (блин, кто вообще с виндой-то сравнивал?), и к «а вот в пятом пункте третьей строке вы притянули за уши, значит неправда ВСЁ!».
kmu1990
12.02.2017 20:40+1К списку недостатков фанатиков — они очень любят обобщать — прочитали один комментарий с такими аргументами, значит ВСЕ комментарии такие.
Jogger
12.02.2017 21:05Да, возможно что со словом «все» я несколько перегнул палку, ведь под это понятие попадают и контраргументы, и даже мой комментарий. Но если вы намекаете, что я фанатик — то позвольте поинтересоваться, фанатик чего?
kmu1990
12.02.2017 21:28Нет, я не намекаю на то, что вы фанатик, я предлагаю вам всего лишь следить за собой и не делать странных обощений и навешивать на других людей незаслуженные ярлыки. Если вы не согласны с каким-то конкретным мнением, то вы можете его оспорить с тем, кто его выразил.
Jogger
12.02.2017 22:08Вы знаете, я считаю что спорить с фанатиками — это верный способ развести холивар, и только. А разводить холивар совершенно не в моих интересах, судя по всему здесь и без меня справятся.
maydjin
12.02.2017 21:13+1Ну, говорить что всё плохо но не говорить как надо, имхо всё равно что светить на солнце.
Движение есть, прогресса нет (с).
И про венду/qnx/bugu|freertos/systemi/plan9/*dos и слова не было. Если вы, кроме unix-like, posix-совместимых и windows ничего не видели, то это не значит, что кто-то фанатик чего-то.
Self_Perfection
12.02.2017 20:05+4Не стоит набрасываться на некоторую натянутость примеров. В целом пост обращает внимание на существенную проблему, причём не ограничивающуюся в своих проявлениях только каким-то семейством операционных систем например. Во всех сферах новые технологии наслаиваются на уже получившие распространение. По прошествии времени может оказаться, что что-то там ближе к фундаменту, реализовано не очень хорошо, но механизмов собраться с духом, засучить рукава и решительно фундамент поправить не выработано. Может кто-нибудь вспомнить пример переделки/замены фундаментальных концепций более значимый, чем переход к метрической системе от имперской и переход к другому напряжению в бытовой электросети?
И назад к IT. Возьмём простую вещь: обозначение новой строки в тексте. Есть unix, mac и win стили, причём про эту особенность нужно быть в курсе. Разные технологии требуют по-разному оформленного текста. Я видел 1-2 раза, как человек готовил shell скрипт в какому-нибудь блокноте на win, и после копирования файла скрипта на linux систему скрипт не запускался. При запуске ОС искала интерпретатор не какой-нибудь /bin/bash, а /bin/bash\r потому что ожидает \n в качестве конца строки, а строки в скрипте были разделены байтами \r\n.
В предыдущем абзаце сломалось из-за использования \r\n вместо \n. Встречал и обратную ситуацию: пытаются продать некий клиент, общающийся с сервером по надстройке на HTTP. Привозят заказчику, включают, натравливают на их сервер — не работает. Разбирательство показало, что их кастомный сервер в HTTP ответах разделял заголовки только байтом \n, хотя по стандарту должна быть комбинация \r\n. Многие реализации HTTP протокола написаны принимать любую комбинацию из \r\n и \n в качестве конца строки HTTP заголовка, но не продаваемый клиент.
В идеальном мире, в котором IT просто служит человеку и помогает работать с информацией, не должно быть необходимости помнить и отслеживать, где какой конец строки используется.FoxCanFly
13.02.2017 18:12-1Эту проблема не Unix, а как раз таки искусственно создана MS в качестве вендорлока.
MacIn
13.02.2017 18:55+2Какие же они evil!!!
Unix пришел с «больших» машин, терминалы которых имели раздельные клавиши ВК и ПС (CR и LF). Физически разные кнопки. И еще со времен телетайпов окончание ввода обозначалось нажатием на клавишу «Возврат каретки».
А MS развивался на рынке ПЭВМ, где была одна клавиша «Enter», и была необходимость генерировать оба символа сразу при нажатии одной кнопки, поскольку эти операции не разделялись, и автономная «возврат каретки» была не нужна — ее роль по сути выполняла клавиша Home.
gatoazul
12.02.2017 20:47+2Тема не раскрыта. В статье приводится набор частных недоработок, не совсем удачных или устаревших решений, личной вкусовщины. Никакого общего ядра у этого списка претензий нет, никакого «краха философии» из них не следует.
NeoCode
12.02.2017 23:46+2Ну, дьявол, как известно, в деталях. Да автор и сам пишет, что «Есть идеи в UNIX, которые мне реально нравятся». Идеи Юникс в целом прекрасны и замечательны, а вот все проблемы именно в частных недоработках. Причем эти частные недоработки расползлись и размазались тонким слоем по всему Юниксу, так что иногда даже сформулировать бывает сложно… но автор попытался, за что ему честь и хвала, я бы так не смог (хотя наталкивался на все это тоже).
potan
12.02.2017 20:56С табуляцией в make решение неудачное, но хорошей замены этому инструменту я не нашел. В sbt, cabal, cargo очень тяжело сказать системе, что "'эти файлы, несмотря на расширение, не трогая", а «этот надо сгенерировать, запустив такую программу».
Плохо не то, что в Unix накопились баги, плохо то, что их толком ни где не исправили.NeoCode
12.02.2017 23:54+1Я вообще считаю, что если возникает такая потребность как «эти файлы несмотря на расширение не трогай» то тут что-то не то. Да и генерить файлы… ну не всегда это нужно. Я писал проекты с тысячами файлов исходного кода, и нигде такое не требовалось. Хотя я понимаю что это может быть необходимо в каких-то случаях.
Но вот сейчас я скажу такую вещь… 99% всех потребностей должны покрывать не make-файлы, а декларативные(!) файлы проектов. То есть просто файл с перечислением файлов исходников, опций компиляции проекта в целом (и возможно опций компиляции конкретных файлов)… и все! Да, те редкие случаи когда нужно запустить какую-то внешнюю программу, должны быть предусмотрены — но они должны быть тщательно огорожены и рассматриваться скорее как исключение, чем как правило.kmu1990
13.02.2017 11:12+3Среди различных Unix-овых (да и не только) утилит есть несколько таких, которые при сборке генерируют файлы. Например, те что используют lex/bison/yacc. Их, конечно, можно сгенерировать заранее и добавить в проект и потом просто ручками перегенрировать при изменениях и обновлять, но это не выглядит как удачное решение (в основном потому что ручками). Так что это не такая уж и супер редкая задача. И вместо того чтобы что-то отгораживать лучше озадачиться возможностью скриптования системы сборки (более или менее разумные системы сборки эту возможность обычно имеют).
Касательно make файлов, make-файлы достаточно декларативны. За исключением того, что кроме опций и файлов иногда нужно описать шаблон команды, который после подстановки имен файлов превратит эти файлы в исполнямый файл/пакет/etc. То есть, ИМХО, обвинять make за отсутствие декларативности не совсем честно. Вот, например, один из make-файлов для одного из учебных проектов:
CC ?= gcc LD ?= ld CFLAGS := -g -m64 -mno-red-zone -mno-mmx -mno-sse -mno-sse2 -ffreestanding -mcmodel=kernel -Wall -Wextra -Werror -pedantic -std=c99 -Wframe-larger-than=1024 -Wstack-usage=1024 -Wno-unknown-warning-option $(if $(DEBUG),-DDEBUG) LFLAGS := -nostdlib -z max-page-size=0x1000 INC := ./inc SRC := ./src C_SOURCES := $(wildcard $(SRC)/*.c) C_OBJECTS := $(C_SOURCES:.c=.o) C_DEPS := $(C_SOURCES:.c=.d) S_SOURCES := $(filter-out $(SRC)/entry.S, $(wildcard $(SRC)/*.S)) $(SRC)/entry.S S_OBJECTS := $(S_SOURCES:.S=.o) S_DEPS := $(S_SOURCES:.S=.d) OBJ := $(C_OBJECTS) $(S_OBJECTS) DEP := $(C_DEPS) $(S_DEPS) all: kernel kernel: $(OBJ) kernel.ld $(LD) $(LFLAGS) -T kernel.ld -o $@ $(OBJ) $(S_OBJECTS): %.o: %.S $(CC) -D__ASM_FILE__ -I$(INC) -g -MMD -c $< -o $@ $(C_OBJECTS): %.o: %.c $(CC) $(CFLAGS) -I$(INC) -g -MMD -c $< -o $@ $(SRC)/entry.S: gen_entries.py python3 gen_entries.py > $@ -include $(DEP) .PHONY: clean clean: rm -f kernel $(SRC)/entry.S $(OBJ) $(DEP)
Синтаксис конечно дуратский с этой кучей пунктуаторов, но, по сути, что в этом файле есть: тулы для сборки, опции для этих тулов, список имен файлов для сборки (получается автоматически просмотром каталогов), и шаблоны команд для сборки (для каждого шаблона рядом дается ограничение, для каких файлов его применять). Все что захардкожено прямо в шаблоны команд это linker-скрипт (не супер часто его приходится указывать явно) и имя автоматически генерируемого файла и скрипт для его генерации. Я бы не назвал это не декларативным.
potan
13.02.2017 12:19+2Эта потребность вполне естественна, если не считать себя ограниченным мейнстримовыми технологиями. Так в makefile я бы легко мог декларативно описать необходимость сгенерировать .js файлы из .elm в веб-приложении на Scala, в то время как в sbt мне приходится для этого писать императивный код.
Для разработки своих языков, даже DSL, постоянно требуется компилировать свою библиотеку только что собранным компилятором. В make это делается элементарно.
Использование дополнительных препроцессоров, даже классических lex и yacc, не говоря уже о редких NJ Machine-code Toolkit и noweb, в проектах не на make становится приключением для эксперта в конкретной системе сборки.
Вообще, желание сделать наиболее популярное использование до предела простым тормозит развитие технологий. Нужен компромис, который в make был более-менее достигнут, если закрыть глаза на извращенное решение с табуляцией. Другие системы не декларативны, а более императивны, просто обладают неестественным интеллектом, позволяющим им распознать популярные случаи использования.mayorovp
13.02.2017 12:32Вообще-то, на чистом make даже компиляция одного cpp-файла с учетом его зависимостей превращается в приключение и обрастает костылями...
potan
13.02.2017 12:42+1У gcc есть опция построение зависимостей. Ее не сложно использовать из makefile.
Другие системы сборки выводят зависимости по каким-то своим соображениям, и указать другие зависимости бывает очень не просто.
geher
12.02.2017 21:44+1Костыли есть в любой сколь-нибудь сложной системе. Среди прочего это часто связано с необходимостью в разумные сроки соединить результат творчества большого количества народа.
Но говорить на основании этого о крахе "философии UNIX" как минимум весьма странно. Тем более, что в статье об этом ни слова.
Большая часть примеров рассказывает об общих для всех систем костылях. В частности все, что касается работы с файлами, содержащими в имени символы, имеющие в командном интерпретаторе специальное значение (одни пробел со слэшем доставляют "удовольствие" в любой системе). Соответственно непонятно, причем тут вообще "философия UNIX"?
И, кстати, о make,
Разве эта утилита является частью ОС? Разве она не работает на всех ОС абсолютно одинаково?
Разве на всех ОС не существует систем сборки, в которых этот make вообще не используется (и еще больше тех, где он используется только после запуска сборки, получая на вход файл, созданный вообще без участия пользователя)?
Потеря данных при сбое системы вообще общая для всех систем тема, связанная с особенностями работы абсолютно любых файловых систем. Разве что журналируемые могут спасти от фатального полного разрушения всей ФС. И реестр тут не поможет. Поможет резервная копия поврежденного файла, будь то файл реестра или конфиг в /etc,
safinaskar
15.02.2017 00:24Большая часть примеров рассказывает об общих для всех систем костылях. В частности все, что касается работы с файлами, содержащими в имени символы, имеющие в командном интерпретаторе специальное значение (одни пробел со слэшем доставляют "удовольствие" в любой системе). Соответственно непонятно, причем тут вообще "философия UNIX"?
Файлы со спецсимволами в именах ломают много скриптов. Это проблема в UNIX. Да, в других системах такая проблема может быть. И я нигде не говорил, что это имеет прямое отношение к "философии". Это один из недостатков. Это моя попытка указать на то, что shell неидеален для тех, кто вдруг этого не знает.
И, кстати, о make,
Разве эта утилита является частью ОС? Разве она не работает на всех ОС абсолютно одинаково?make — один из столпов UNIX. Это одна из основных UNIX-программ. В Windows же make используется как "пришелец из мира никсов".
guai
12.02.2017 21:51С многим согласен. Писать команды в консоли уже пора бы так же, как прогать на современных статически типированных языках в современных IDE. Всего-то надо, чтоб программа могла отдать в стандартном формате список нужных ей параметров.
selgjos
12.02.2017 21:53+1А дело в том, что printf, как и сама UNIX в целом, был придуман не для оптимизации времени, а для оптимизации памяти. printf каждый раз парсит в рантайме строку формата.
Назовите язык, в котором это не так.Dessloch
14.02.2017 11:29-1Сама по себе эта претензия абсурдна. Любой программер знает что есть два противоположных подхода-оптимизация времени или памяти. Хочешь быстродействия-денормализуй БД. Возможно эта функция написана когда HDD были по 40ГБ. Не нравится-напиши свою. Это и есть UNIX-way. А поругать чужое, чтобы поменьше замечали твои недостатки-это видимо Windows-way.
vintage
14.02.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"]] }
irbis_al
12.02.2017 21:53Пусть автор в Windows попробует создать файл с простым именем prn (Этот артефакт ещё с доса тянется)…
А вообще надо не забывать, что часто недостатки, являются продолжением достоинств.
(Ушёл с винды ещё в 2006 году(и перевёл всех своих клиентов с винды)… что я тоже делаю не так???)
u007
15.02.2017 08:30+1
safinaskar
18.02.2017 15:10Как это вы так? :) Фотошоп? :)
Incidence
18.02.2017 21:40Скорее всего, это сетевая шара на самбе или типа того, где ни одно из этих имён не является зарезервированным.
u007
19.02.2017 13:46Зачем же фотошоп) Вот, распакуйте: https://yadi.sk/d/4ZhozKC43EFm4k
Если спросит про замену — «да для всех».safinaskar
19.02.2017 14:41+2Бгг, распаковал под Windows 7 32 бита с помощью 7-zip 9.20. Работает. Про замену не спросил. Выглядит именно так, как на скриншоте в архиве (его можно посмотреть прямо в интернете, ничего для этого скачивать не надо). Есть оба слеша в именах файлов. Но это сделано с помощью специальной фичи оболочки Windows (т. е. Windows Explorer, ну или Windows Shell, короче говоря та оболочка, которая показывает вам всякие там "Мой компьютер" и "Панель управления", хотя таких папок на самом деле нет), которая позволяет показывать не те имена файлов, которые реально есть в файловой системе. Т. е. на самом деле эти файлы и папки называются по-нормальному, просто имена не те отображаются. Принцип тот же, из-за которого называются папки в C:\Users\User по-английски, а отображаются в проводнике по-русски
bm13kk
12.02.2017 21:53Простите. Я, конечно, понимаю. Авторский стиль, острый вопрос, какашки, вентилятор и вот это вот все.
Но можно воспользоваться катом?
mikeus
12.02.2017 21:55+4Я твой UNIX-дом труба шатал, shell-калитка тряс, философия-огород топтал, язык С кэпка на х… вертел!
Итак, я не хочу сказать, что UNIX — плохая система. Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем. И «философию UNIX» я не отменяю, просто обращаю внимание, что она не абсолют. Мой текст обращён скорее к фанатикам UNIX и GNU/Linux. Провокационный тон просто чтобы привлечь ваше внимание.
xby
12.02.2017 21:55-3У автора типичное пацанское представление «поколения интернет» — только что вылупившись из яйца и ничего еще сам не понял и не сделал, но уже клеймит позором «костыли и философию UNIX». Будь эффективнее — сделай свое и не трать время на подобные клеймящие «статьи».
n-krd
12.02.2017 21:55-4Ох уж этот юношеский максимализм, вчера из пеленок выпрыгнул а сегодня говорит что мир не правильно устроен… Сделай что нить свое и поддерживай его в актуальном состоянии лет 10, вот потом будешь иметь право использовать такие слова в заголовках.
Dessloch
12.02.2017 21:55-3Как-то несерьёзно это всё. Конечно у Linux есть недостатки. Но сравнивать бесплатно и платное ПО как-то не принято в мире. Не нравится-покупай и ставь Windows, Linux никто не навязывает.
Про реестр идея интересная конечно. Если бы это было грамотно реализовано. Но ведь RegCleaner'ы для чего-то существуют. А значит реализация подкачала.
Ну и сравнивать linux-shell и php вообще нонсенс.sumanai
12.02.2017 23:25+2Но ведь RegCleaner'ы для чего-то существуют.
Для заработка создателей RegCleaner'ов?Dessloch
13.02.2017 18:17Во-первых есть бесплатные. Во-вторых опыт показывает что regcleaner размер реестра иногда значительно уменьшает. А значит не всё так уж хорошо с реестром.
sumanai
13.02.2017 20:08+1Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие. И ничего плохого в этих «лишних» записях нет, и с реестром всё в порядке, даже когда он весит под сотню мегабайт. В Win2000 общее ограничение на реестр было что-то около 400 мегабайт, в WinXP общее ограничение снято, есть только ограничение в 200мб на размер куста SYSTEM из-за особенностей загрузки. Уверен, в новых ОС даже этих ограничений нет. На моей ОС, установленной более 5 лет назад, куст SYSTEM весит 7,5мб, а самый большой куст SOFTWARE- 40. Как видите, размеры по современным меркам просто смешные, и далеки до каких либо ограничений.
Зато вот нахвататься глюков с ними легко. Я свою ОС не чищу, и у меня ни реестр не ломается, ни глюков нет, а BSOD видел только по причине своейкриворукостижадности, когда выставил неверные тайминги оперативной памяти.Dessloch
14.02.2017 11:25«Повторю сказанное в другом комментарии- размер реестра никак не влияет на его быстродействие.»
Это ваше личное мнение? Доказать-обосновать как-то можете?
А я вот думаю что влияет. Впрочем не вижу смысла спорить.sumanai
14.02.2017 17:17+1Моё мнение основано на знании алгоритма работы реестра, полученного путём чтения литературы типа «Внутреннее устройство Microsoft Windows» и статей в интернете. А ваше на чём основано?
FieryVortex
15.02.2017 18:40у Linux есть недостатки. Но сравнивать бесплатно и платное ПО
Прошу прощения, насколько мне известно, UNIX — это далеко не только Linux. Точнее даже, Linux — не совсем UNIX.
И что там с бесплатностью у (Sun)^W Oracle Solaris? Или у macOS, фанаты которой хвалятся тем, что она «настоящая UNIX»? О более редких коммерческих версиях можно не вспоминать.
NickCave
12.02.2017 21:55"«Философия UNIX». Есть мнение, что якобы UNIX прекрасна и идеальна. Что все её основные идеи («всё есть файл», «всё есть текст» и т. д.) прекрасны и составляют так называемую прекрасную «философию UNIX»."
Вот оно что! Оказывается философия UNIX — всё есть текст. Интересно, а философия Windows тогда — всё есть ОКНО.
ben-postman
12.02.2017 21:56Статья о наболевшем — это понятно и стиль статьи тоже принимается, но после прочтения возникает только одна мысль: — «Что же мне делать? Как быть то сыну простого крестьянина? Пишущему классы для работы с периферийными устройствами и разрабатывающему ПО АСУ ТП ???»
Но теперь я знаю что!!! — Поднять руку, левую или правую, и резко опустить со словами: -«Ну и… с ним!!!»
А про себя подумать: — «Делай что должен! И будь что будет!» :-)
GarryC
12.02.2017 21:59+5Кстати, в заголовке явно не хватает фразы "… Программисты всего мира в шоке..."
shuron
12.02.2017 22:42+5Вообще то с философией юникса ассоциируют именно эти три вещи и именно в этом порядке.
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
И это действительно могущественный вывод на опыте создания програмных систем. Который постоянно вплывает в разные контекстах и эпохах. Сейчас к примеру это микросервисы.
mikeus
13.02.2017 00:27+3- В самом начале make был программой, которую один человек написал для себя и нескольких своих знакомых. Тогда он, недолго думая, сделал так, что командами воспринимаются строки, которые начинаются с Tab. Т. е. Tab воспринимался отлично от пробела, что крайне некрасиво и нетипично ни для UNIX, ни за его пределами. Он так сделал, потому что не думал, что make будет ещё кто-то использовать кроме этой небольшой группы. Потом появилась мысль, что make — хорошая вещь и неплохо бы включить его в стандартный комплект UNIX. И тогда чтобы не сломать уже написанные мейкфайлы, т. е. написанные вот этими вот десятью людьми, он не стал ничего менять. Ну вот так и живём… Из-за тех десятерых страдаем мы все.
Перефразируя классика:
Мы все страдали понемногу О чем-нибудь и как-нибудь, Так что незнаньем мануалов, к сожаленью, У нас немудрено блеснуть.
$ info make
2.1 What a Rule Looks Like ========================== A simple makefile consists of "rules" with the following shape: TARGET ... : PREREQUISITES ... RECIPE ... ... A "recipe" is an action that 'make' carries out. A recipe may have more than one command, either on the same line or each on its own line. *Please note:* you need to put a tab character at the beginning of every recipe line! This is an obscurity that catches the unwary. If you prefer to prefix your recipes with a character other than tab, you can set the '.RECIPEPREFIX' variable to an alternate character (*note Special Variables::).
- Вообще, названия утилит UNIX — это отдельная история. Скажем, название grep идёт от командй g/re/p в текстовом редакторе ed. (Ну а cat — от concatenation, я надеюсь, это все и так знали. :) Ну и для кучи: vmlinuz — Linux with Virtual Memory support gZipped.)
…
- Когда Кена Томпсона, автора UNIX (вместе с Деннисом Ритчи) спросили, что бы он поменял в UNIX, он сказал, что назвал бы функцию creat (sic!) как create. UPD от 2017-02-12: источников полно, например: en.wikiquote.org/wiki/Ken_Thompson. No comments. Замечу, что позже этот же Кен Томпсон вместе с другими разработчиками оригинальной UNIX создал систему Plan 9, исправляющую многие недостатки UNIX. И в ней эта функция называется create. :) Он смог. :)
И что? Ужас, утилиты и функции названы не так? Задето чувство прекрасного? Возмутительно, как после всего этого с этими cp и creat (sic!) эти UNIX-подобные системы можно использовать?! Так это ещё цветочки, вот вообще трэш — «О срезании углов»
:-)))
itxs
13.02.2017 01:27-1Так, что за оскорбления, фанатики мол. Может автор статьи и причисляет себя к фанатикам, но я — себя нет. Разве в UNIX так называемой философии говорится о полном отсутствии костылей? Статью надо переделать, убрав все провокационное, и оставив только конструктив. Странно и грубо эксплуатировать эмоциональную привязанность людей к неким системам, если «наболело» — да быть такого не может что наболело, кто обязан выслушивать ваш крик души? Вы исключительный? Вы капризный псих, с которым никто не общается? Идите успокойтесь самостоятельно и без ущерба для других людей, и внесения уродливого хаоса в мысли публики. Смутьян нашелся.
safinaskar
15.02.2017 10:38Статью надо переделать, убрав все провокационное, и оставив только конструктив
Цель статьи в том, чтобы покритиковать, ничего не предлагая. Я обращаю внимание на то, какой же всё-таки legacy этот UNIX. Чтобы не было больше вот этих горящих глаз "Ах, UNIX, UNIX!" А использовать его и дальше можно. Если кому-то нужны альтернативы, посмотрите Plan 9 и прочие новые ОС. Но и сам UNIX не плох. Он стабилен и популярен. А провокационный стиль нужен был, чтобы встормошить читателя.
itxs
15.02.2017 12:56— Чтобы не было больше вот этих горящих глаз «Ах, UNIX, UNIX!»
Вы же не будете запрещать людям восторгаться? Кто вы такой чтоб это делать? Бог? Всемирный судья? Уж простите, но я буду смеяться над тем над чем хочу, восторгаться тем чем хочу и так далее.
Vkuvaev
13.02.2017 02:20+1Господи, а cp rm и иже с ними за что? Руками их набивать быстрее, спутать невозможно, сплошной профит.
Или copy и remove что-то исправят?
Ну так пропишите себе алиас и не парьтесь:). Видимо вы в sh скорее гость, чем завсегдатай.
tyderh
13.02.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.02.2017 02:43Прочитал все комментарии, по-моему все что нужно уже сказали. Поэтому выскажусь чисто по философски:
Поняли, фанатики, да? Ваш кумир отказался от своей же философии. Можете расходиться по домам.
Мы не фанатики, и кумиров у нас нет, и это тоже часть филосфии Unix. Поэтому расходиться нет никакой совершенно надобности.
Skler0z
13.02.2017 03:28+1Статья подняла настроение. А про GIT в том же стиле сможете написать? :)
safinaskar
14.02.2017 02:02Git написали за неделю на коленке. (Да, да, почитайте историю гита.) Далее, гит на самом деле очень тупо "лобовым" способом устроен внутри. Вон, почитайте: https://www.opennet.ru/base/dev/git_guts.txt.html. Там тупо считаются хеши от файлов, затем эти хеши складываются в текстовые (!) файлы (в этом я не совсем уверен), от них считаются ещё хеши, от них ещё хеши и т. д. А можно было как-нибудь умнее сделать. Чтоб папки были всё-таки бинарными объектами сразу. А не текстовыми файлами захешированными.
Ладно, я выдохся. В общем гит настолько прекрасен, что его покритиковать сложно. Если серьёзно, то гит прекрасен. В отличие от юникс, который реально плох :)
Ах да, в гите многие команды реализованы на б-гмерзком шеле :)
vbif
14.02.2017 11:45+1А через X времени появится статья «гит — не так прекрасен, как все думают! конец эпохи систем контроля версий!»
kekekeks
14.02.2017 13:02Чтоб папки были всё-таки бинарными объектами сразу.
Git игнорирует существование директорий как отдельного класса объектов. Вы не можете взять и добавить в репозиторий директорию без файлов.
sumanai
14.02.2017 17:18+1от них считаются ещё хеши, от них ещё хеши и т. д
Но ведь древовидное хеширование это прекрасно, и лежит в основе например биткоина.
3aicheg
13.02.2017 03:32+1Чё-то хрень какая-то (вроде бы, дальше первых двух абзацев читать было лень, скажите спасибо, что откомментил).
Antervis
13.02.2017 05:32+1Критика — это хорошо, если она конструктивна. Критика в статье не предлагает альтернатив.
exce1
13.02.2017 10:44-2От статьи был бы толк, если бы Винда под конец жизни не продалась дъяволу. И её перспективы теперь, увы, туманны. Разве что, геймеры продолжат за неё цепляться.
virgin_unix_fan
13.02.2017 10:44Прочитал Ваш поток сознания и болезненный хипстерский крик души и даже специально зарегистрировался, чтобы ответить. Штуковина, которую вы пытаетесь критиковать де-факто обслуживает весь интернет в мире последние лет 50 и никакого краха там нет и не предвидится. От того что вы составляете списки костылей в ней, забиваете гвозди микроскопом, туннелируете через 4(четыре Карл!) хоста ради одного файла и почему-то по умолчанию считаете каждого первого встречного её фанатиком в этом мире совсем ничего не изменится. Такие дела. Чао.
9660
13.02.2017 10:44«Просто обращаю ваше внимание на то, что у неё есть полно недостатков, как и у других систем.»
Может логичнее сказать «у нее полно особенностей»? Потому что, к примеру, большинство из описанного, для меня лично, недостатками не является.
KiloLeo
13.02.2017 10:44«Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал» — дальше можно не читать. Информационного мусора и так выше крыши. Если автору лень писать, зачем мне это читать?
msts2017
13.02.2017 13:03В кои веки заголовок статьи соответствует действительности.
UNIX-подобные системы содержат кучу костылей — оспаривать глупо
Крах «философии UNIX» — если под крахом понимать то что «философия UNIX» не смогла удержать программистов от плодения костылей — так и есть, чтобы идти вперед приходится нарушать «философию».
augur
13.02.2017 14:09+3UNIX – наихудшая операционная система, если не считать всех остальных.
(ц)почти Уинстон Черчилль
Denkenmacht
13.02.2017 23:12-2Наверное для таких глобальных суждений, как в статье, все-таки нужно вводить возрастной ценз, или хотя бы по опыту работы. А то любой может об… ать труд двух поколений людей, обозвав всех фанатами и кичась своими фрагментарными знаниями чего-либо. Просто есть и будут вещи, которые устаревают, а есть вещи, которые нет, как топор. UNIX — топор, который будет продолжать рубить еще долго, не смотря на то, что будут говорить отдельные «знатоки».
MacIn
14.02.2017 18:17Признать, что вещь устарела, а какая-то концепция является костылем — да, тут нужно мужество, не каждому по плечу.
Denkenmacht
14.02.2017 18:51-1Вы забыли суть понятий, о которых говорите. Костыль — это приспособление для передвижения с учетом действующих ограничений, при учете имеющихся ресурсов. Нужно понимать понятие эффективности как отношение результата к вложениям, при котором костыль в большинстве случаев эффективнее 4 человек, которые могли бы вас носить.
Так вот, устаревшая вещь — это вещь, потерявшая эффективность. С UNIX системами этого еще не произошло, при относительной бесплатности они работают, и эффективной замены пока что нет. Это то же самое, что сказать, что топор устарел, ведь есть лазер, им можно нарубить дров на даче.
Дело не в мужестве, которым вы, судя по всему, с избытком обладаете, а в эффективности. Как только затраты на костыли превысят затраты на написание/поддерживание новой системы, произойдет смена парадигды и как следствие — платформы.
Что-либо устаревает только тогда, когда затраты времени и денег (в конечном счете — денег) становятся существенно больше, чем у аналога.popov654
14.02.2017 19:02и эффективной замены пока что нет
А Inferno не вариант? Я сам в этом не очень разбираюсь, но слышал о ней очень позитивные отзывы, в том числе и на Хабре были статьи.Denkenmacht
14.02.2017 19:24Почему не вариант, вариант. Просто видите как, популярность оси — понятие сложное. Тут в осях для телефонов-то тяжело разобраться, почему одна распространеннее другой, а третья и другие вымирают.
Вы просто представьте себе процесс самого выбора этой оси для серверов — это же не так, что решили вы поставить нечто, выучили и работаете. Для этого вся компания должна принять решение, переучить/набрать новых людей, чтобы это админить — это ведь все расходы, деньги. Регламенты написать, возможно железо частично заменить. Надо объяснить дяде-собственнику и дяде-инвестору, что эта ось выгоднее старой, потому что… что? Старая некрасивая и неудобная? — Ну так не целоваться с ней просят. Устаревшая? См. мой предыдущий коммент. Костыли в ней и их много? Ну и что. Единственными аргументами могут быть параметры работы (скорость, безопасность, стабильность, стоимость лицензии и проч. — тут грамотные люди лучше меня подскажут) и стоимость персонала, который новую ось будет обслуживать. На анальные боли админов, их комплексы и стенания почти всегда всем начхать, кроме как если админы эти начинают совсем все увольнятся (т.е. финансовый вопрос встает). Даже в небольшом банке это довольно сложный выбор (я такое видел), и как правило побеждает мнение — что если что-то работает — нефиг это трогать. А то потом кто будет отвечать за то, что у тебя вместе с новой осью легла АБС банка и банк сколько-то денег потерял, потому что весь не мог работать — мужественный смелый парень, который предложил это сделать? С него и взять-то нечего. Я к тому, что есть еще понятие «риски», и когда это понятие люди рассматривают применительно к своим деньгам, а не так, пофилософствовать, то вся смелость куда-то пропадает, а берутся проверенные решения, работающие годами. Чтобы наплевать на риски, надо ситуацию загнать в такой угол, что все равно уже терять нечего, «давайте попробуем новую дешевую систему», либо если это стартап. Ну так чтобы стартапы, использующие Инферно, выросли и показали эффективность этой оси, нужно время, а оно еще не прошло.
Если же говорить о частных делах, то существенный фактор — поддерживает ли платформу нужное ПО, без которого никак.
Запустите на Инферно 1С Бухгалтерию, МС Офис и большинство комп. игр без виртуалки — и тогда возможно люди задумаются.popov654
14.02.2017 19:311C и МС Офис и на Линуксах не пойдут)
Единственными аргументами могут быть параметры работы
Может такое быть в идеальном мире, что сам собственник решит поэкспериментировать (он ведь может быть ещё и айтишником, любящим инновации). Хотя конечно если бы я планировал открыть банк, я бы рисковать не стал. А вот для стартапа — да, очень даже можно.
Кстати, именно крупные проекты типа того же Facebook делают популярными разработки, которые они сделали сами (либо допилили), но о которых никто бы даже и не узнал, не будь у компании такого имени. HHVM например можно вспомнить, Nginx, движок V8.Denkenmacht
14.02.2017 19:421C и МС Офис и на Линуксах не пойдут)
Все же с натяжкой можно сказать, что офис на мак ос портирован, т.е. подвижки есть.
Я в данном случае про ПК говорю — то есть там, где частное лицо решение принимает — мы с вами на своих компах.
Собственник бизнеса не хочет экспериментировать в большинстве своем, он хочет заработать деньги, притом на том, что он понимает. Соответственно экспериментировать может либо государство, либо софтверная компания.
Да возможно вы правы, когда нибудь какая-нибуль крупная компания, выросшая из стартапа, напишет свою ось для своего железа, и отдаст/продаст это миру. Андроид же родился почти так?popov654
14.02.2017 21:00Ну Андроид-то был не для «своего железа», а просто чтобы был конкурент iOS :) Я вообще толком не знаю, с какой целью создавалась эта ОС, надо будет почитать. Может, уже держали в голове монетизацию через маркет приложений, может, рассчитывали поиск свой продвинуть в мобайл сегменте. В итоге все задачи были решены более чем успешно.
MacIn
14.02.2017 19:07Вы забыли о факторе времени. О том, что некий tradeoff по эффективности не вечен, а костыль из этого самого некогда баланса превращается в legacy, от которого просто уже нельзя отказаться.
С UNIX системами этого еще не произошло
Я сказал «вещь устарела», а не «UNIX системы устарели».Denkenmacht
14.02.2017 19:33Так вы про топоры пришли написать, или про UNIX?
Если про топоры, то отказ от них произойдет не по причине их собственной неэффективности, а по причине неэффективности дровяного отопления. UNIX — отказ от нее произойдет не по причине ее неэффективности, а по причине смены парадигм программирования, либо коренного изменения архитектуры железа. И сколько времени пройдет в первом случае, а сколько во втором (если вообще пройдет) — я лично гадать не берусь. От того, что лично вы перестанете рубить дрова топором, мало что поменяется.MacIn
14.02.2017 19:37Никчемная аналогия. Статья — о некоторых аспектах операционной системы. Забудем про желтый заголовок данной статьи.
Denkenmacht
14.02.2017 19:50+1Не сочтите за грубость, но ловите обратно — никчемное замечание.
Статья не о некоторых аспектах оси, а о самой сути этой оси, о ее философии, как ее понял автор. И как раз некоторыми аспектами автор статьи пытается изменить сущность оси.
Заголовок как раз соответствует трактовке особенностей оси с целью подвести ось под общую неэффективность с помощью подмены этого понятия понятием «устареваемости», которого на самом деле не существует, и заранее навесить клише «фанатов» на тех, кто попытается возражать.
spear2
13.02.2017 23:12+1> Костыли в UNIX начали возникать ещё с момента появления UNIX, а это было ещё раньше появления не только
> Windows, но даже вроде бы Microsoft DOS (вроде бы, мне лень проверять, проверяйте сами).
То есть автор не не помнит толком, когда возник UNIX, и (вспоминается бессмертное) "… вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости"
Chelyuk
13.02.2017 23:12+1Никогда не понимал за что ругают популярные системы/продукты? Мир не идеален и в нем нет ничего идеального, все может только стремиться. Пока Unix/Linux имеет столь огромое сообщество это доказывает, что дохрена людей считают ее лучшим выбором из существующих. Кто считает таковой Windows, кто-то MacOS. Люди сделали свой выбор в пользу той или иной системы по совокупности качеств и характеристик. Не нравиться конкретно Вам, ну не используйте. Вклад Unix и ее производных в развитие технологий неоспорим, если бы не она. Сейчас был бы совсем другой мир. Не все решения в ней идеальны, но если их перенимают другие системы это доказывает их целесообразность.
Dessloch
14.02.2017 11:21Мне больше интересно другое. Ну не нравится тебе что-то-не пользуйся. Работай на Windows. К чему эти холивары?
Fluorescent
13.02.2017 23:12-3Статья повеселила. Покажите мне номерной маздай с переводом строки в имени файла на NTFS и парсинг этого файла PowerShello'м :))
leocat33
13.02.2017 23:13-4NTFS никакого отношения к *nix не имеет. Вообще. Это урезанный клон Files-11 от DEC.
Попытка реализовать DEC RMS у мелкомягких с треском провалилась ( Longhorn )
Попытка сделать нормальную ОСь, как то клон VMS: http://www.freevms.net не нашла должного количества волонтеров и находится многие годы в состоянии ни жив, ни мертв.
Так и живем, с Линуксом…MacIn
14.02.2017 18:20NT и есть переработанная VMS, а уж сколько всего там от Files-11, начиная от ACL и кончая альтернативными потоками…
safinaskar
14.02.2017 02:05-2Hellsy22,Dessloch
UPD от 2017-02-14: комментаторы указывают, что сравнивать UNIX shell с PHP некорректно. Конечно, некорректно! Потому что UNIX shell не претендует на то, чтобы быть полноценным языком программирования, он предназначен для скриптинга системы. Вот только я в одно время этого не знал. И вдобавок считал UNIX shell прекрасным. Вот для людей в таком же положении я всё это и говорю. Ещё как минимум один комментатор говорит, что сравнивать UNIX shell нужно с cmd. Я бы сказал, что сравнивать надо с Windows Powershell. Последний, как я уже говорил, в чём-то превосходит UNIX shell.Dessloch
15.02.2017 20:15-1Во-первых PowerShell появился много позже UNIXshell. Лично у меня нет сомнения что Микрософт и разрабатывал его потому что у линуксоидов был вполне удобный шелл, а в Windows батниками ничего толком сделать было нельзя, кроме как файлы скопировать-удалить.
Во-вторых, давайте уж сравним Powershell хотя бы с zsh, который тоже появился позже. Хотя особого смысла в этом нет. Линуксоиды ещё… дцать лет назад могли получить информацию о CPU просто сделав «cat /proc/cpuinfo», а в винде это стало возможно только с появлением Powershell.
А в бизнесе часто бывает так-кто первый предложил качественную услугу-товар тот и захватил рынок. Невооружённым взглядом видно что Микрософт всё время дышит в затылок кому-то. Линуксу, Гуглу, Sony. Всё время пытается либо купить чей-то уже успешный бизнес(Visio, Axapta), либо повторить(Windows-mobile, Azure). И получается пока не очень.
Хотя в десктопных/домашних PC они бесспорно первые.
safinaskar
14.02.2017 02:25-2UPD от 2017-02-14: мне понравился вот этот коммент от sshikov ( https://habrahabr.ru/post/321652/#comment_10065532 ):
Но я скажу за автора — к сожалению, прямо сегодня можно найти сколько угодно восторженных статей типа «А вот есть такая замечательная фигня, как bash, щас я вам про нее расскажу...» — где unix way откровенно перехваливается неофитами. Это не помешает иногда компенсировать долей скепсиса.
Да, в этом-то и всё дело! Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат. А использовать-то UNIX можно.
Fluorescent
14.02.2017 03:23+1Ну народ… предлагаю cжать zipом файл с именем ?.txt и вручать его всем любителям маздая и powershell, кто распакует в маздае, тот имеет право гнать на UNIX ) Если нет… ждите 20-й версии поделки Билла, может там всё получится. А мы пока на «костылях», потихонечку пойдём дальше...)))
vintage
14.02.2017 09:49-1Думаете было бы лучше, если бы система позволяла использовать в именах файлов спецсимволы, а для написания простой поисковой маски пришлось бы вместо простого "?.*" писать какое-то адское заклинание?
daggert
14.02.2017 10:46Прям сидим и плачем от того что нельзя поставить кучу левых символов в название файла (: 20 с лишним лет это никого не парит (даже сейчас в пользовательских требованиях к MS'у этого нет) и теперь прям станет нужно (:
Ну а вам предлагаю сжать тогда zip'ом файлы с русскими именами и открыть их на линуксе. Уже лет 10 проблема есть. Подожду пока исправят, мб потом перейду.mayorovp
14.02.2017 12:10+1Ну, это же на самом деле проблема формата zip, а не винды и не линукса.
daggert
14.02.2017 12:46-1Везде есть свои минусы, плюсы, свои нюансы. Знак вопроса в названии файла, как и вообще спецсимволы, никого толком не трогают. Интересуют дела насущные — форматирование флешки в fat без ввода пароля, проблемы с железом, корявое кроссплатформенное отображение имен. Вот это проблемы. Ограничения которым 20 лет это уже стабильность, которую ты ожидаешь и держишь в голове при разработке.
Incidence
14.02.2017 13:46+2а в чём проблема с кириллицей в зипе?
vbif
14.02.2017 14:13Может быть в том, что некоторые архиваторы под виндой используют виндовую кодировку
Incidence
14.02.2017 14:25+1Тот архив, что на моём скрине выше, был создан штатным zip-архиватором винды из контекстного меню эксплорера, Send to -> Compressed Folder или как его там. Внутри ZIP-файла кириллическое имя оказалось записано в CP866, но zip/unzip со включённым natspec'ом его воспринял корректно. Хотя KDEшный Ark и GNOMEовский File-Roller обломались и показывали "????????" вместо имени, я всё же не думаю, что это проблема именно Линукса.
EvilFox
17.02.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 (калечные права доступа, аудит… и много всего другого) могу, но времени да и желания в данный момент нет.
Saffron
14.02.2017 11:12+1Полностью разделяю ваше негодование молчаливым редактированием статей. Право на распространение модифицированных копий не означает право подписывать их вашим именем. Написали, допустим, вы «Гитлер убивал евреев. Фу таким быть», а вам последнее предложение поправили на «Всё правильно сделал». И никаких меток о правке — только ваше имя под публикацией. К кому, как вы думаете, ночью постучатся некомпетентные органы, кому будут предъявлять пропаганду фашизма? Да и просто общественная репутация будет подорвана.
Dessloch
14.02.2017 11:18Рискую навлечь на себя гнев фанатов Windows, не очень меня это беспокоит вобщем-то.
Вот ещё статейка в тему
https://habrahabr.ru/post/321696
слабо такое из под винды сделать?divanikus
14.02.2017 12:18Вам пишут про недостатки у вас дома, а вы все разговор переводите в русло «а вот у соседа», «живи тогда у соседа». Смешно.
vbif
14.02.2017 12:27Как-бы, наоборот…
divanikus
14.02.2017 13:14Я вот всю статью еще раз пролистал, нигде не говорится прямо «а вот на винде!», разве что за исключением реестра и упоминания вскользь NTFS. Все остальные аргументы вообще не привязаны к другим системам и рассматривают проблемы именно UNIX. А тут часть товарищей все равно пытается свести все аргументы к «а вот на винде!»
mayorovp
14.02.2017 12:28Ну, поскольку существует WinPE, который умеет грузиться по сети (а значит. умеет работать вовсе без диска) — нет никаких непреодолимых препятствий чтобы проделать подобную удаленную переустановку системы.
Но, конечно же. это будет намного сложнее. В основном — из-за всяких лицензионных ограничений.
daggert
14.02.2017 12:51В бытность мою админом был такой замечательная флешка у меня, которая была огрызком от винды. Когда ты ее вставлял в комп, там был простой авторан, который копировал некоторые файлы себе и перезагружал компьютер почти со всеми настройками, и там можно было и диск порубать, и файлы сохранить. Что самое удивительное, в то время была работа с сетью через прокси и всякие спецпрограммы доступа к интернету, дык этот образ подхватывал это дело и запускал рабочую систему с rdp включенным. Я так сервер battlefield 2 админил, переставляя систему по RDP через флешку. Пару раз ошибался, не спорю, приходилось сисадмина напрягать на переустановку, но два раза я обновлял систему именно так.
saipr
14.02.2017 15:46Достало, что хвалят UNIX way. Что считают UNIX красивым и ещё и других учат.
Зря вы так, даже в Советском Союзе ставили на UNIX.
Операционные системы: зачем они инженеру
safinaskar
14.02.2017 20:11Holix
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 дальше, просто не считайте его идеалом.
geher
14.02.2017 20:55-1Что программирование на «голом UNIX», с использованием C и Shell
В таком случае C рассматривать не стоит. Компилятор является не частью системы, а всего лишь дополнительной программой, которая устанавливается в систему.
А если мы рассматриваем С, то придется и про C++ вспомнить, и про Python, и даже про Fortran c Perl. А кое где в мире ...nix и Object Pascal встречается, и go, да и все "передовое и современное" тоже.
Но ещё и из-за всех этих quirks мейкфайлов, шела, языка C. Отсутствия удобных инструментов, систем сборки, менеджеров пакетов.
Ни разу не пришлось создавать руками make файл. А порой его даже физически на диске не создавалось. Альтернативные среды разработки разной удобности тоже имеются в изобилии от достаточно примитивных (вроде codeblocks), до универсальных (вроде Eсlipse)
safinaskar
15.02.2017 17:24-1Я критикую "подход UNIX". Использование C и мейкфайлов является частью этого подхода. Есть армия фанатов, которая считает, что нужно прогать на C и с мейкфайлами. А всякие IDE — не труъ. Вот их я пытаюсь победить
Dessloch
15.02.2017 17:58Не надо никого ПОбеждать. Пишите в IDE, много и хорошо. Своим примером и Убедите.
Dessloch
15.02.2017 07:07Вот кстати статейка про лицензирование Windows в тему.
https://habrahabr.ru/post/321708/
Там речь идёт о миллионных суммах. А я поднял несколько корпоративных серверов-гейтов на Ubuntu
в небольших фирмах, у которых миллионов не было в бюджете.
О чём холивар, господа?)
u007
15.02.2017 07:52-2Статью можно не причёсывать, прям так в Microsoft отсылать. Отличное резюме на должность powershell-евангелиста :)
Dessloch
15.02.2017 18:00Вопрос приоритета Windoows-Linux может и спорный, но вот судя по минусам с чувством юмора у виндузятников явно не так хорошо как с продажами)
saintbyte
15.02.2017 18:40-1Назовите меня сектантом но никсы — это лучший из костылей который существует.
Shoooberoni
15.02.2017 18:41-1И еще одна задачка, которую с ходу не решить. В папке все текстовые файлы, и надо их разом переименовать например в 1.txt 2.txt и т.д. В графике Винды — за щелчок, в shell пришлось попотеть.
Hellsy22
15.02.2017 22:49Минута на скрипт.
perl -e '$i=0; for (<*.txt>) { do {$i++} while (-e "${i}.txt"); print `mv $_ ${i}.txt`;}'
Если файлы понадобится отсортировать по оригинальному имени, размеру или времени создания, то потребуется лишь дописать sort {...} перед <*.txt>
А у вас сколько уйдет времени на переименование полусотни файлов?
P.S.: Да, могут возникнуть проблемы с файлами, чье имя разделено пробелами. Решается через добавление кавычек или простенькое регулярное выражение.
safinaskar
15.02.2017 19:54-2UPD от 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.02.2017 03:05-2UPD от 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.02.2017 03:12И он запускает новые программы на каждый чих.
Нет, не на каждый. man builtins. Например, даже в том идиотском примере никаких сотен процессов touch все равно не будет — touch как раз одна из этих встроенных функций.
Это не отменяет того, что в shell'е постоянно возникают проблемы со специальными символами.
Какими-же?0xd34df00d
16.02.2017 19:18+2Можно ли считать builtins отхождением от юникс-вея, кстати? Ну, что каждая программа делает одну задачу и делает её хорошо.
Обновлять время доступа к файлам, подсчитывать время выполнения программ и прочее счастье — это ведь не задача шелла, не так ли?tyderh
16.02.2017 19:20-1Можно ли считать builtins отхождением от юникс-вея, кстати? Ну, что каждая программа делает одну задачу и делает её хорошо.
builtins — хорошая и красивая оптимизация медленного места. Можете считать отхождением, разрешаю. Однако, задача у баша не «существовать согласно юниксвею и KISS», а «делать свои дела и делать их хорошо и быстро»
safinaskar
18.02.2017 18:16-1?!?!?! Эээ, а слабо самому почитать тот ман, на который вы ссылаетесь? touch — не builtin баша. Как минимум потому, что его нет упомянутом man builtins. Во всяком случае в моей версии баша (4.4-2 из дебиана).
А про специальные символы уже рассказано подробно в моей статье. Про эти 5 хаков, которые нужно запихнуть в цикл, чтобы он работал нормально со специальными символами. См. также UPD от 2017-02-18
Denkenmacht
16.02.2017 08:37+2Оскорбить не хочу тоном своим, но все-таки не удержусь.
Я бы все понял, если бы вы предложили какую-то альтернативу, или хотя бы наметили черты этой будующей альтернативы — красивой, бесплатной, неуродской, в которой даже школьник разберется (да еще и без особого знания английского), стабильной, работающей, простой и много какой еще.
Если бы это в конце вашей статьи это шло хотя бы в виде манифеста, то да — ваши аргументы можно было бы счесть в качестве подтверждающих какие-то принципиальные новые идеи и учесть при обсуждении этих идей.
Но раз уж вы начинаете оперировать человеческими понятиями по отношению к ОС или среде без предложения альтернативы, то эти сопли все на тему «я повелся, а она оказалась некрасивой», а «ваши кумиры» тоже считают что она не только некрасивая но и старая, бла-бла-бла — это все просто неконструктивная критика называется. Вам несколько человек говорят одно и то же, а вы все про красоту, старость и принципы системы несете.
Если рассуждать в широком смысле про уродство и красоту (раз уж вы замахнулись на такие понятия), то даже здесь ваши суждения находятся на низком уровне зрелости, потому что тогда вы бы знали, что иногда бывает неидеальная красота, с изюминкой, и что красота — это часто сочетание недостатков с преимуществами (и не всегда любят за последние, но часто и за первые) и часто внутренняя, а не внешняя. И вообще в данном случае, думаю, можно сказать, что Её многию любят и считают красивой потому, что она была у них первая.
Antervis
16.02.2017 09:14давайте воздержимся от громких и пустых слов аля «кумиры», «фанаты» и пр. Есть объективные причины использовать каждую ОС, есть субъективные.
Мне, как не сильно умудренному пользователю линукса нравится в нем то, что он создавался программистами для программистов. Пакетный менеджер, централизованность утилит и библиотек в системе, update-alternatives. А даже если что-то где-то вдруг не так, всегда есть возможность подправить какой-нибудь конфиг и исправить. В винде, по моему опыту, любая нетривиальная задача настройки системы уводит в дикие дебри гугла, реестра и никогда не факт, что всё отработает.
А всё то о чем вы говорите мне, как пользователю, безразлично. Более того, найдутся аргументы в пользу раскритикованных вами решений (их тут зачитайся).
aGGre55or
16.02.2017 18:14+1Собственно, bash слабей не только PHP, но даже и Бейсика из ПЗУ ZX Spectrum образца 1982 года.
Вот всего лишь три факта: 1) Бейсик работает с трёхмерными массивами, bash — только с одномерными. 2) Бейсик умеет вещественную математику (причём до 14 знаков после запятой), bash (сам, без посторонних утилит) только целочисленную. 3) Бейсик в ПЗУ Spectrum занимает 16K. du -sh /bin/bash на CentOS 6.8 даёт нам 888K.tyderh
16.02.2017 18:57Теплое с мягким сравниваете, товарищ, надеюсь, вы не серьёзно.
Видал я жонглирование курлом на php на тысячу-полторы строчек. Такое, что на баше уместилось бы на экран, если не в одну строчку.
У каждого языка есть свои цели, задачи, для которых он сделан и подходит. Баш, например, не создан без работы без посторонних утилит, наоборот, он — исскуство их композиции, позволяющее максимально эффективно переиспользовать уже написанный код.
safinaskar
17.02.2017 14:38+2Знаете, что я ещё скажу? Веб, 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.02.2017 14:54И когда я в одной вкладке удалил письмо, в другой вкладке оно всё ещё видно во входящих.
В десктоп приложениях такой проблемы нет.Да ладно? Тут на ru.SO регулярно появляются вопросы "я заполнил переменную на форме 1 — а на форме 2 она пустая ПОЧЕМУ?". Не уметь программировать можно на любом языке программирования :)
А javascript и node.js, в том числе, сформулированную вами проблему решают. "Шагом назад" оказался только веб, а javascript и node.js — это шаг обратно вперед.
Free_ze
17.02.2017 16:29Не уметь программировать можно на любом языке программирования :)
Кстати, вариации этой фразы появляются почти в каждом первом комментарии с позиции защиты веб-интерфейсов. Так вот универсальный ответ: на разных языках «уметь» — по-разному сложно. Веб — не самая приятная среда как для создания интерфейсов, так и для пользователя, не самая эффективная платформа с бесконечными лоадерами и спиннерами на простейших действиях. Работа с состоянием приложения действительно не регламентирована и десктопные игры в ассоциации здесь не прокатывают.
Как пользователь могу заметить, что веб-интерфейсы зачастую беднее десктопных и даже мобильных аналогов, хуже кастомизируются. Почему так происходит?mayorovp
17.02.2017 16:34А мой опыт говорит обратное. Всевозможные веб-приложения взлетели в том числе и потому, что там многие вещи делаются проще.
Free_ze
17.02.2017 18:59там многие вещи делаются проще
Какие, если не секрет?
Главное преимущество веба с моей точки зрения — это система дистрибуции, которая не требует установки чего-либо на компьютер клиента. Ну и социалочки в свое время здорово подстегнули эту любовь.vintage
17.02.2017 23:42-1Например, богатые возможности по управлению текстом. Лейауты, подстраивающиеся под размеры содержимого. Богатое редактирование текста. Кроссплатформенность. Ленивая подгрузка модулей. Крутейший отладочный инструментарий.
Free_ze
18.02.2017 11:41+1Работа с текстом — да, возможности из коробки, это плюс, который можно упоминать дважды для весомости) Остальное же…
Лейауты, подстраивающиеся под размеры содержимого.
Сейчас где-то иначе? Сто лет назад был WPF, JavaFX, Qt, даже Android SDK умеет в это.
Кроссплатформенность.
Ее нет де факто, отлаживать приходится везде.
Ленивая подгрузка модулей.
Это тоже не уникальная возможность.
Крутейший отладочный инструментарий.
Чем же он крут? Бэкендная отладка мало, чем отличается от десктопного аналога, а отлаживание фронта — это боль. Если код еще и транслируется из другого языка, то боль в квадрате. Вы, конечно, об инструментарии, но разве он делает этот процесс приятнее?
worldmind
17.02.2017 23:31+5> Веб, node.js и javascript — это шаг назад.
поддерживаю, по каким-то печальным причинам самые кривые, плохо спроектированные технологии становятся популярными — js, php, node.js. А реально крутые технологии вроде Python и Haskell отстают или вообще неизвестны, почему в браузера используется не нормально спроектированный язык вроде питона, а что-то странное что создавалось для выведения alert окошка?
А веб-технологии это же жуть — язык разметки гипертекста стал использоваться как язык разметки интерфейса, естественно это порождает кучу костылей и чехарду фреймворков.vintage
17.02.2017 23:56+2Может потому, что у JS с самого рождения было всё хорошо с юникодом в отличие от "крутых, правильно спроектированных языков"?
worldmind
18.02.2017 00:17+1Всё может быть, но поддержка юникода это вроде не того уровня проблема, да и в php как понимаю не было юникода от рождения
am-amotion-city
18.02.2017 11:06+2Бгг.
''.length; // 6 WTF [...''].length; // 3 OMG
Угадайте, это какой версии js в каком браузере и в какое время? С регулярками сами поиграетесь. Хуже, чем в js, нигде ничего не было, даже у php меньше родовых травм и архитектурных ошибок.
vintage
18.02.2017 11:39В обоих случаях будут нули, не выдумывайте.
am-amotion-city
18.02.2017 20:10https://twitter.com/_ericelliott/status/831851853902143489
Я не виноват же, что парсер маркдауна тут писали криворукие дегенераты.
vintage
18.02.2017 20:41+2'E?'.length // 2 OLOLO
Тут проблема не столько в JS, сколько в юникоде, где один символ может образовываться несколькими кодовыми точками.
am-amotion-city
18.02.2017 21:50+2Чего?
Тут проблема именно в JS. В нормальных языках при подсчете длины строки используется длина строки, а не какие-то кодовые точки. Длина строки «Angstrom» — 8 символов, а то, что недоязыки умеют насчитать там до десяти символов — это не проблема символов и не проблема юникода.
vintage
18.02.2017 23:34-2То есть вы считаете нормальным, что конкатенация двух односимвольных строк даст не двухсимвольную строку, а односимвольную, и разделить её обратно на две односимвольные уже не получится?
( "E"+"?" ).length
am-amotion-city
19.02.2017 09:15+3Операция определения длины и операция конкатенации не транзитивны. Это должно быть, в принципе, нормальному человеку очевидно из коробки, но если нет, консорциум это эксплицитно оговорил. Почитайте раздел про композицию и декомпозицию.
Разделить полученную строку обратно на односимвольные получится, называется декомпозиция.
Впрочем, все это не имеет никакого отношения к моему оригинальному примеру: там символов 3, хоть как посмотри, и ладно бы еще
lengthпросто отдавало шесть: нет, есть костыль с[...призванный подпереть и так непрочное здание очередным костылем.vintage
19.02.2017 11:00-2Значит я ненормальный, раз для меня это выглядит противоестественным. Всё же length на мой взгляд должен выдавать число кодовых точек. То, что комбинация нескольких точек даёт на экране один символ, а некоторые — ни одного, — это особенности отображения. Учитывать их тоже иногда полезно, поэтому тут лучше было бы ввести отдельный метод "countOfVisibleCharacters".
Но касательно вашего примера, да, суррогатная пара фактически кодирует одну кодовую точку, но большинство реализаций JS хранит строки внутри в UCS2 кодировке, игнорирующую такие пары. Однако спецификация JS не ограничивает от использования UCS4 или UTF* кодировок.
am-amotion-city
19.02.2017 11:55+2у JS с самого рождения было всё хорошо с юникодом
Вот с чего начинался этот тред. Когда язык считает, что строка «O?» — длины два, это значит у языка с юникодом все плохо, потому что это противоречит правилам работы с юникодом, предписываемым консорциумом.
Вам может быть удобно считать все, что угодно, и как угодно, но пока мы говорим про реализацию языком юникода, имеет смысл опираться не на ваши представления о прекрасном, а на спецификацию консорциума. Пицца из моего оригинального примера — один символ. И пляски с
[...чтобы добиться правильного возврата длины — тому подтверждение.
Вот и все. На сегодняшний день есть всего одна имплементация, которая адекватна: в Elixir’e. Язык при сборке качает файлы спецификаций с сайта консорциума и парсит их. Так достигается автоматическая поддержка всего, что консорциум наворотил с момента последней компиляции языка.
Ну а насчет кодовых точек, все тоже просто: вы путаете причину со следствием. Если программисту нужны кодовые точки, надо вручную декомпозицировать (простите :) символы и посчитать размер получившегося массива (массива! это не строка уже). Любые другие костыли приведут к тому, что
"o?".length !== "o".length, что, как вы, надеюсь, понимаете, далеко от определения «правильная работа со строками».sumanai
19.02.2017 14:20-1На сегодняшний день есть всего одна имплементация, которая адекватна: в Elixir’e.
Если только такое «великое множество» языков поддерживает юникод полностью, то какие претензии могут быть к скриптовому языку, выполняемому в браузере? Полная имплементация юникода убъёт производительность на корню.safinaskar
19.02.2017 14:43-2Ну да, в этом-то и всё дело. Javascript — это просто язык для скриптинга браузера. А не новый язык, который щас убьёт все остальные
vintage
19.02.2017 16:38-1Вот с чего начинался этот тред. Когда язык считает, что строка «O?» — длины два, это значит у языка с юникодом все плохо, потому что это противоречит правилам работы с юникодом, предписываемым консорциумом.
Вас не затруднит процитировать это правило? Особенно интересно, какую длинну они предписывают возвращать для строк, целиком и полностью состоящих из непечатаемых символов.
safinaskar
19.02.2017 19:15+2. 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
не-юникодовые строк в языке быть не должно
Просто с массивами байт язык всё-таки должен уметь работать. Да и со строками в неюникодных кодировках, я считаю, тоже
am-amotion-city
20.02.2017 10:08+3любой язык, декларирующий возможность работы с юникодом (в том числе UTF-16), должен уметь
Забыли очень важную штуку:
toUpperиtoLower, как ни назови сами функции, должны уметь не только банальные операции, но иtoUpper("istanbul", "tr") ? "Istanbul".
? vintage http://www.unicode.org/versions/Unicode9.0.0/ch05.pdf по «length» поищите. Вообще, удивительно: вместо того, чтобы поблагодарить и пойти самому раскапывать, вы чуть не требуете, чтобы я нашел цитату и принес на блюдечке. Ну да мне не трудно.
mayorovp
19.02.2017 15:38-1У вас какое-то странное понимание того что нужно программисту от поддержки юникода. Любая проверка длины строки ущербна сама по себе, просто из-за своего наличия. И никакое следование спецификациям тут ничего не изменит.
А реально от поддержки юникода требуется следующее:
- возможность создавать юникодовые строковые литералы;
- возможность вводить юникодовые строки при помощи стандартных средств;
- возможность выводить юникодовые строки при помощи стандартных средств;
- базовые операции над строками должны сохранять их корректными;
- не-юникодовые строк в языке быть не должно.
safinaskar
18.02.2017 18:13-2tyderh,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.02.2017 19:22Если вы мне расскажете кейс при котором надо дописать в файл строку уже содержащуюся в нем, тогда я начну думать о решении. А пока выгладит опять как выдумывание способов поставить систему раком используя странную задачу.
safinaskar
18.02.2017 19:52Речь шла (как видно из кода) о замене файла на строки в нём, которые содержат bar. А не о дописывании этих строки
cjbars
19.02.2017 08:49Я просто еще раз попрошу вас написать зачем нужно прроизводить замену файлов по их содержимому?
Я просто пытаюсь понять какую задачу вы решаете, реальную или синтетическую.safinaskar
19.02.2017 13:04Синтетическую. :) Но подобные задачи возникали в реале, могу поискать в реальном коде, надо?
cjbars
19.02.2017 16:57Да, это было бы очень интересно. Если вам не сложно.
Идеально было бы увидеть кусок кода, и цель, которую решает данный код.safinaskar
19.02.2017 19:18Вам именно пример, где нужно сделать find, и для каждого результата find'а выполнить больше одного действия?
Или пример на любую другую особенность shell, обозначенную в моей статье, не обязательно именно ту с find'ом и sh -c?
cjbars
20.02.2017 06:48Ну допустим вам нужно над найденным файлом сделать несколько действий.
Тоесть не просто выполнить какое-то действие над файлом, а именно несколько действий.
Что такое последовательность действий? Правильно! Последовательность действий есть скрипт.
Таким образом пишите скрипт для выполнения последовательности действий, и вызываете этот скрипт для каждого найденного файла.
#!/bin/bash # script.sh filename="$1" echo "Действие 1 над файлом $1" echo "Действие 2 над файлом $1"
find . -type f -exec ./script.sh {} \;
Вполне себе переваривает «кривые» названия файлов. В чем крах и костылизм?cjbars
20.02.2017 07:50сорри косякнул со скриптом, но сути это не меняет
#!/bin/bash # script.sh filename="$1" echo "Действие 1 над файлом ${filename}" echo "Действие 2 над файлом ${filename}"
safinaskar
20.02.2017 19:02-1Можно и так. Но тогда нужно ещё один скрипт создавать из-за запростецкой команды. В других языках программирования такое вообще почти не встречается, чтобы из-за какой-то ерунды нужно было новый файл с кодом создавать. Почти во всех языках можно всю огромную программу запихнуть в один файл.
Вообще, скажу ещё раз. Выполнение нескольких действий с файлом можно сделать разными способами. Цикл, -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.02.2017 02:28+2UPD от 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.02.2017 12:54+1Почему-то в списках 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.02.2017 13:08+1А если кто-то случайно сделает
cp old_file new_fileвместоcp new_file old_fileи начнет писать "подумаешь, опции не в том порядке", то виноват тоже будет shell?Этот пример некорректен. Опции без дефиса в начале не зря называются позиционными. Опции с дефисом таковыми не являются (во всяком случае, это такое соглашение, которого придерживаются практически все программы. Можно конечно плевать на эти соглашения, что find и делает, но глупо при этом возмущаться тем, что кто-то считает это неочевидным поведением. Оно таковым и является).
- Почему-то в списках aka
maydjin
20.02.2017 15:25info sed | grep 'delete'
Выбирая не самый изящный способ, конечно же, получается не самый изящный результат.
Я не считаю себя большим специалистом по unix[-like] shell однако, большинство практических задач находят достаточно простое и изящное решение даже в моих неумелых руках. Особенно при анализе слабо структурированных данных.
Сама концепция всё есть текст не идеальна, но, хороша для своего класса задач: выборка по неструктурированным/слабо структурированным данным. Для итерации по более структурированным данным, несомненно нужны более точные инструменты, для fs таким является find.
Концепция всё есть объект, тоже имеет право на жизнь, однако, требует сильной регулирующей организации а так же стандартизации. Учитывая период, который понадобился, что бы стандартизировать такой простой язык как C, сложно представить, сколько потребовалось бы на разработку стандарта такого уровня даже сейчас(далеко ходить не надо, достаточно взглянуть на python, который насколько я знаю, до сих пор не стандартизирован). А кому-то нужно (было и есть) ехать а не шашечки...
авторы UNIX'а любили создавать по языку на каждый чих
Собственно суть unix-way, dsl/утилита для каждой отдельной задачи, иначе, всё можно было бы на перфокартах до сих пор в пакетном режиме шедулить:)
Кстати, для примера, есть ещё концепция всё есть запись в БД, используемая в systemi. И она накладывает определённый уровень ограничений — например максимальная вложенность файловой системы есть 3, так же как и даёт определённый ряд преимуществ.
EvilFox
19.02.2017 23:13Кстати вспомнил тут про проблему текстовости, она есть в виртуальной фс которая отображает дерево процессов. Умные люди уже начали решать эту проблему.
safinaskar
20.02.2017 18:53О, спасибо. Согласен с идеей. Между прочим, в Linux видимо перетащили /proc из Plan 9. Так что даже в Plan 9 ошиблись
novoselov
«Статья написана наскоро, «полировать» дальше не хочу, скажите спасибо, что написал.»
Охренеть, одолжение сделал :)
GreyPhantom
Дюже странно, что карму еще не слили. Ну, хабр- он такой…
novoselov
Уже слили, не волнуйтесь
GreyPhantom
Ну, мне-то и сливать было нечего, но мир не без добрых людей- спасибо за минусы
GreyPhantom
кто-то оголтело лепит минус просто потому что сказанное идет вразрез с его убеждениями, а кто-то ставит плюс к статье за то что в ней есть котик. Скоро котировки валют на месяц вперед будет проще предсказать чем собственную карму/рейтинг на хабре.
basilbasilbasil
это ж сарказм, замешанный на философии UNIX
ximaera
Зашел в профиль посмотреть другие посты автора. Опа!
NotSure
И?