Первое за 18 лет обновление dmesg(1)

> Ну и причем тут вообще UNIX-way когда у вас пробелы в развитии личности?

Анонимус поставил мне диагноз. Пойду порыдаю и впаду в депрессию.

>Помню в 1999 я приделал к своему 486 звуковую карту, и мог слушать в винде 98 музыку и играть со звуком ОДНОВРЕМЕННО. Я слышал взрывы ракет в кваке, и музыку

То ли толщина тролля зашкаливает, то ли это был первый в мире трехъядерный 486.

Не троллинга ради, а токмо во развитие кругозора:
А где именно в посикс? Если можно конкретную ссылку (а то я не нашёл).

>>Помню в 1999 я приделал к своему 486 звуковую карту, и мог слушать в винде 98 музыку и играть со звуком ОДНОВРЕМЕННО. Я слышал взрывы ракет в кваке, и музыку

То ли толщина тролля зашкаливает, то ли это был первый в мире трехъядерный 486.

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

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

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

Да дело даже не только в этом: на P-60 квака шла в режиме слайд-шоу. Так что запускать параллельно с ней ещё музыку было бы мазохизмом.

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

> А где именно в посикс?

Нет там этого, похоже

> В идеале я должен скопировать любые файлы с музыкой на диск и должно записаться то что я хочу - хочу mp3 а кидаю wma - на выходе должно быть mp3. Хочу WMA а кидаю ogg - пусть пишет в wma.

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

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

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

ээ, перелистал сейчас SUSv4, нет там такого, был не прав. но я точно где-то его видел....

Возможно с LSB спутал:

http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic...

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

Потюнить и настроить нормально хоть винду хоть линукс, но винда искаропки более годна уже лет 10 как, а в линуксе некоторые проблемы вызывают удивление. Хотя да, постепенно решаются.

Сам он троленуб. ls|awk не правильное решение, а правильное было со stat, но это чит. Кроме того stat и ls дублируют функционал друг друга на 100%, что недопустимо с точки зрения unix way.

q1 работал на 386 еще :))

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

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

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

LSB - стандарт реализации. Его пилит красношляпа под свой красношляп-линукс. Вкрутят новый dmesg - поменяют стандарт.

>> Small is beautiful. Make each program do one thing well.

Жирнота — это красота. Каждая программа должна делать не одну вещь и не хорошо.

Немного толстовато. Этот принцип появился когда ещё не было разделяемых библиотек.
А вообще — даёшь холивар на тему Worse is Better (который есть UNIX-way) против the Right Thing?
Некоторые десктопные вещи невозможно сделать простыми. В принципе. Например, рендеринг шрифтов. Те, кто не знают об этом, до сих пор могут (и используют) X Core Fonts, которые крайне просты и способны работать в 100% случаев для разработчика (обычно американца или европейца).

> Некоторые десктопные вещи невозможно сделать простыми. В принципе. Например, рендеринг шрифтов.

Рендеринг шрифтов инкапсулирован внутри конкретных бибилиотек. Наружу торчит API, довольно простой. В чем проблема?

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

Даже Дюк не шел на 386, хотя у него движок более простой, псевдо-3д, тогда как квейк уже имел полноценное 3д. С думом не путаем?

>Рендеринг шрифтов инкапсулирован внутри конкретных бибилиотек. Наружу торчит API, довольно простой. В чем проблема?

библиотек

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

>А в качестве обратного примера можно привести практически любой GUIшный текстовый редактор «с панельками», где разработчики заново (частично или полностью) велосипедят недофайловый менеджер, недосписок недавних документов, недовстроенный терминал и т.п.
emacs? Думаю, что там далеко не «недо».

> Разделяемые библиотеки — прямое нарушение UNIX-way.

Омг. Ссылку на пруф-то можно? :D

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

Разделяемые библиотеки — всего лишь способ линковки объектных модулей. А вот когда они начинают использоваться как средство модуляризации задачи на подзадачи — вот тогда пиши «пропало». Итоге обязательно получится KDE^Wкакой-то монстр с зависимостями на половину дистрибутива.

«Рендеринг шрифтов» — это само по себе не задача. Точно так же, как printf — не задача.

А вот в текстовом редакторе можно выделить типовые задачи, которые имеют свое отдельное UI, свое поведение, которые нужны не только в текстовом редакторе, для которых имеет смысл написать спецификацию протокола и вынести в отдельную программу: файловый менеджер, терминал, средство хранения информации о «недавних файлах» и т.п.

emacs?

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

>Омг. Ссылку на пруф-то можно? :D
http://harmful.cat-v.org/software/dynamic-linking/
Ресурс юмористический, но в ссылках видно сложность динамической линковки. А UNIX-way ставит простоту выше всего.

> пруф

Ресурс юмористический

/0

А UNIX-way ставит простоту выше всего.

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

>Ты хочешь оспорить то, что для для рендеринга шрифтов линковка с рендерящей библиотекой является самым простым решением?
Нет. Самое простое решение — передать рендеринг серверу (например, Xorg). А Worse is Better прямо говорит, что простое решение лучше правильного.

А Worse is Better прямо говорит, что простое решение лучше правильного.

У тебя эпичная каша в голове, раз ты пытаешься так прямолинейно применить эти принципы. Суть Worse is better в том, что «простая» система быстрее пишется, быстрее распространяется, быстрее захватывает экологические ниши, и, следовательно, быстрее эволюционирует. И эволюционируя, она превращается в «правильную» систему. Собственно, что мы и наблюдаем постоянно в мире Unix-подобных систем и ПО для них.

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

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

Поэтому да — между двумя «почти правильными» решениями следует выбирать более простое.

>И эволюционируя, она превращается в «правильную» систему.
Ни разу.

Собственно, что мы и наблюдаем постоянно в мире Unix-подобных систем и ПО для них.

Не наблюдаем. Точнее, эволюция есть, но ни разу не быстрее. legacy в unix-подобных системах ни разу не меньше, чем в прочих, к примеру.

> Ни разу.

Аргументировал — как отрезал.

Не наблюдаем. Точнее, эволюция есть, но ни разу не быстрее. legacy в unix-подобных системах ни разу не меньше, чем в прочих, к примеру.

Дык. Это универсальный принцип, просто обсуждаем мы его в контексте юникса.

Взять ту же линейку DOS -> Win16 -> Win32 -> Win32 over NT. MS всегда выбирала по возможности самые тупые^Wпростые решения, и сразу же получала профит. Усложнялась система только необходимости, под давлением новых факторов среды.

Тупой Unix — выжил, умный MULTICS — нет. Винда выжила, OS/2 — нет. Монолитные ядра процветают, технологически более перспективные микроядра существуют только в отдельных нишах.

Тут два универсальных принципа:

1. Кто первый встал, того и тапки.

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

Собственно, всё это ортогонально к unix-way, это «два разных человека».

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

Тем не менее, большинству людей нужен гуишный текстовый редактор, а не vim или emacs.

Похоже и правда с думами/хексенами попутал.

Собственно старые винды куда проще решали задачу создания десктоп-системы, чем юниксы. Я думаю даже код систем Windows 3.11 был меньше чем код иксов. ВСЕГДА проще написать какую-то систему не модульной и монолитной, потому что не надо продумывать интерфейсы, протоколы, и тратиться на их поддержание. По этому worse is better вообще полностью противоречит идее модульности. Собственно динамические библиотеки именно по этому и пошли: они сразу становятся неотъемлемой частью твоей программы, и работать с ними также, как со своим кодом.

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

Тем не менее, большинству людей нужен гуишный текстовый редактор, а не vim или emacs.

Ты написал две фразы, никак не относящиеся к теме моего разговора с x3al. Комментируешь ради самого процесса?

Unix - не выжил. Немного пережил, но не выжил. Gnu is Not Unix. Кто у нас остался из юниксов? соляру вот недавно похоронили, чпуксы и аиксы потихоньку прекращают продаваться, и меняются на линукс. Собственно линукс и шевелится благодаря всяким не-юниксвейным штукам: оopenoffice (вместо vim+latex+dvi2pdf+pdfviewer), браузер вмест (wget+html2plaintext), любая_DE вместо оконного менеджера+панелек+vim для настройки всего этого. Да что уж там, половину кореутилз вкомпиливают в баш, это юниксвей чтоли, когда одна программа умеет и cat и ls?

> Собственно старые винды куда проще решали задачу создания десктоп-системы, чем юниксы.

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

Я думаю даже код систем Windows 3.11 был меньше чем код иксов.

Ты в курсе, что _современный_ дистрибутив Tiny Core занимает 20 что ли там (или 30 ли, не помню) мегабайт? Да, с иксами, файловым менеджером, полноценным набором консольных утилит, выходом в сеть и т.п.

ВСЕГДА проще написать какую-то систему не модульной и монолитной, потому что не надо продумывать интерфейсы, протоколы, и тратиться на их поддержание.

Капитаны в треде. Но есть одно но. Написать — проще. Развивать и поддерживать — нет.

По этому worse is better вообще полностью противоречит идее модульности.

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

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

Ну так что, worse is better — это юниксвей или не юниксвей? *.so — юниксвей или нет? Вы определитесь с x3al относительно точки зрения на, прежде чем фанбойски кидаться в юниксвей какашками в мою строну. Потому как ваши взгляды на сабж, кардинально расходятся, друг с другом вам, пожалуй, будет гораздо интереснее посраться, чем со мной.

в win3.11 можно было поставить мсоффис, была поддержка сетевых папок, были графические редакторы, игры. Так что это был десктоп. И это было до того, как на линукс удалось портировать иксы. Так что вин-десктоп встал в тапки намного раньше, чем линукс.

и занимала вся система с офисом мегабайт 30 как раз.

Зачем поддерживать, если можно раз в 5 лет переписывать с учетом новых идей и технологий?

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

Я например считаю, что разработчик dmesg вменяем, а использование awk и perl чтобы склеить одну программу с другой - доведение идеи до крайности.

worse is better - раз уж отцы постулируют - то это юниксвей. so - это не юниксвей, потому что поддержка динамических библиотек - это не эволюционное решение. Это сложная система, которую должен был кто-то сделать. Кроме того so - это не текстовый протокол, а бинарный, что противоречит unix-way.

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

> skype? audacity? sip-телефоны? раздельная регулировка громкости каждого приложения? блютуз, усб гарнитуры? наверняка что-нибудь из этого работает плохо.

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

Потюнить и настроить нормально хоть винду хоть линукс, но винда искаропки более годна уже лет 10 как, а в линуксе некоторые проблемы вызывают удивление. Хотя да, постепенно решаются.

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

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

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

Unix - не выжил. Немного пережил, но не выжил. Gnu is Not Unix.

А еще LAME Ain't an MP3 Encoder, YAML Ain't Markup Language, WINE Is Not Emulator — да, я тоже в курсе, что такое рекурсивный акроним.

Мне в подобные моменты неизменно вспоминается из Стругацких:

     - Слушайте, Яков, - сказал Комов. - никто не знает, на
что способен  человек  в  критических условиях. И особенно
женщина. Вспомните историю Марты Пристли. Вспомните историю
Колесниченко. И вспомните вообще историю, Яков.
     Наступило  молчание. Вандерхузе  сидел  с  несчастным
видом и безжалостно таскал себя за бакенбарды.

Вот вам я бы тоже посоветовал вспомнить историю. Мы будем делать глубокомысленные выводы на основе забавного названия проекта GNU или мы вспомним историю и почитаем что-нибудь по теме? Раз уж вы упомянули про coreutils, можно начать прямо с их мануала — глава 29, Opening the Software Toolbox. Полагаю, для вас будет полезно.

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

О том, что GNU/Linux — сам по себе плоть от плоти unix-подобная система, вы предпочли умолчать.

Да что уж там, половину кореутилз вкомпиливают в баш, это юниксвей чтоли, когда одна программа умеет и cat и ls?

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

в win3.11 можно было поставить мсоффис, была поддержка сетевых папок, были графические редакторы, игры. Так что это был десктоп. И это было до того, как на линукс удалось портировать иксы. Так что вин-десктоп встал в тапки намного раньше, чем линукс.

Ну и? Вы этот абзац написали просто так или какую-то мысль донести хотели?

Зачем поддерживать, если можно раз в 5 лет переписывать с учетом новых идей и технологий?

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

Я например считаю, что разработчик dmesg вменяем, а использование awk и perl чтобы склеить одну программу с другой - доведение идеи до крайности.

Я тоже считаю, что разработчик dmesg вменяем, а вот однострочники на awk — отличный инструмент для быстрого анализа/трансформации/форматирования каких-нибудь несложных текстовых данных. А для более сложной автоматизации обработки текста у меня есть Ruby.

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

А какое? Linux вот — тоже сложная система, которую должен был кто-то сделать. Разве можно в современном Linux узнать тот самый Linux 0.01? Подобные рассуждения напоминают «аргументы» креационистов о том, что глаз не мог сформироваться сам по себе. Скажите, вы креационист?

Кроме того so - это не текстовый протокол, а бинарный, что противоречит unix-way.

А вызов функций libc тоже что ли противоречит unix-way? Динамическая линковка — это как молоток. Им можно гвозди забивать, а можно дать себе по пальцу. Некоторые очень любят бить себя по пальцам, ну что уж с этим поделать.

Ну не возникает реально такой выкоуровневой задачи — «отрисовать глиф буквы А шрифтом таким-то». Соответственно, нет и программы, которая решала бы эту задачу. Поэтому можно freetype или pango хоть под микроскопом рассматривать, но нарушения принципов unix там не найти. А вот задача «посчитать md5 от содержимого файла» — реально возникает. И (совсем не внезапно) вот есть и программа для этого.

worse is better - раз уж отцы постулируют - то это юниксвей.

А головой подумать? Worse is better — это подход к процессу разработки ПО. При чем, применимый не ко всему ПО и не всегда. Чтобы он работал, нужна такая среда, которая определит направление эволюции для продукта. При том, этот подход ничего нам не говорит о том, что представляет собой сам продукт, и какими принципами руководствуются разработчики при разработке его архитектуры. Возьмем, например, принципы проектирования ПО, о которых пишет Эрик Рэймонд:

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.[4]
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for "one true way".
Rule of Extensibility: Design for the future, because it will be here sooner than you think. 

Вы считаете, что эти принципы:
* ведут к разработке некачественного ПО?
* неприменимы на практике?
* неактуальны в современных условиях?
* неверно выражают концепцию unix?
* что-то еще?

Аргументированно, пожалуйста, а не в виде подобного потока сознания:

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

> Омфг. Винду изкаропки использовать невозможно наверное ни для кого вообще.

Это самоубеждение. Вы считаете что прописать пару репозиториев, апт-гетнуть пару программ, поправить конфиги, ткнуть правильный вывод - это искаропки, а запустить несколько setup.exe - нет. Я использую win7 искаропки, ставлю только браузер, мсофис, путти, и игрушки.

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

Хреново они появляются, честно вам скажу. Сколько к emacs не приделывай ctags - вижак не получится.

вы не согласны что баш содержит stat, cp, ls, time и уйму всего другого? Погуглите bash built-in.

> вы не согласны что баш содержит stat, cp, ls, time и уйму всего другого?

Вам достаточно было сделать man bash | egrep '(stat|cp|ls)[^a-z]' , прежде чем начать пороть чушь. Но вы предпочли спороть чушь.

Погуглите bash built-in.

А вы сами гуглили? Не поделитесь результатами?

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

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

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


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

Собственно это плохо документировано - я жестко нарвался на это когда писал скрипт с использованием time - оказывается есть программа, и есть часть баша. на счет остального - наберите в баше help и увидите, что

cd,echo,true,false,pwd,kill,wait,time и многие другие - это и программы (проверьте which echo) и билтины.

> Собственно проблема цитирования реймонда в том, что его книга вышла в 2003 году - принципы модульности были уже понятны даже последнему быдлокодеру. Эти принципы не имеют никакого отношения к UNIX

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

Собственно это плохо документировано

Перевожу на русский: «я не читал документацию».

я жестко нарвался на это когда писал скрипт с использованием time

Перевожу на русский: «я не читал документацию для bash, но пытался на нём писать и получил закономерный fail».

оказывается есть программа

Нэт программа. Савсэм нэт программа, панымаэшь?

~$ which time
which: no time in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/java/jre/bin:/usr/bin/core_perl)

и есть часть баша

time — не встроенная команда. time — часть синтаксиса пайпов. Если бы вы осилили набрать man bash, вы бы знали.

на счет остального - наберите в баше help и увидите, что
cd,echo,true,false,pwd,kill,wait,time и многие другие - это и программы (проверьте which echo) и билтины.

Я просто процитирую:

вы не согласны что баш содержит stat, cp, ls, time и уйму всего другого? Погуглите bash built-in.

Шлангование не пройдёт.

Если вы полагаете, что не читая документацию, сумеете выродить из астрала работающую программу, у меня для вас плохие новости. Вот мы наконец и выяснили, что unixway совершенно ни при чем. Плохому танцору постоянно что-нибудь мешает.

which time /usr/bin/time

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

По поводу документации - можно процитировать реймонда :

Rule of Least Surprise: In interface design, always do the least surprising thing.

у меня в дебиане time находится в отдельном пакете.

Ну так и? Так что там насчёт запиливания команд из coreutils? То, что time — не встроенная команда в bash-е мы уже выяснили, теперь вот узнаём, что «внешняя» time к coreutils отношения не имеет.

time - НЕ часть синтаксиса пайпов

Так, ну оказывается, я был излишне оптимистичен, что выяснили насчёт bash-а. Вы всё еще не открывали man bash, это очень печально. :(

Я вам помогу:

Pipelines

A pipeline is a sequence of one or more commands separated by one of the control operators | or |&. The format for a pipeline is:

[time [-p]] [ ! ] command [ [|⎪|&] command2 ... ]

The standard output of command is connected via a pipe to the standard input of command2. This connection is performed before any redirections specified by the command (see REDIRECTION below). If |& is used, the standard error of command is connected to command2's standard input through the pipe; it is shorthand for 2>&1 |. This implicit redirection of the standard error is performed after any redirections specified by the com‐ mand.

The return status of a pipeline is the exit status of the last command, unless the pipefail option is enabled. If pipefail is enabled, the pipe‐ line's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully. If the reserved word ! precedes a pipeline, the exit status of that pipeline is the logical negation of the exit status as described above. The shell waits for all commands in the pipeline to terminate before returning a value.

If the time reserved word precedes a pipeline, the elapsed as well as user and system time consumed by its execution are reported when the pipe‐ line terminates. The -p option changes the output format to that specified by POSIX. When the shell is in posix mode, it does not recognize time as a reserved word if the next token begins with a `-'. The TIMEFORMAT variable may be set to a format string that specifies how the timing information should be displayed; see the description of TIMEFORMAT under Shell Variables below.

И можете не благодарить.

это была отдельная программа, которую башевцы втолкнули внутрь баша.

Ох эти злые башевцы, впилили ни в чем неповинную команду, а потом еще заставили разработчиков csh и zsh поступить так же! Те сопротивлялись, но куда ж им против башевцев. :( Просто ужасы какие-то творятся в этом линуксе.

По поводу документации - можно процитировать реймонда :

Rule of Least Surprise: In interface design, always do the least surprising thing.

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

> Это самоубеждение. Вы считаете что прописать пару репозиториев, апт-гетнуть пару программ, поправить конфиги, ткнуть правильный вывод - это искаропки, а запустить несколько setup.exe - нет.

Репозитории не прописываю, конфигурацию можно считать одинаковой. А дальше различия — на мой apt-get (yum, но неважно) я потрачу 5 секунд, остальное компьютер сделает сам. Сколько на винде займет скачать (с офсайтов) и поставить пару десятков свеженьких программ, дров и т.д.? У вас их 3-5, ок, а у кого-то сотня. И это еще без кряков. Или денег :) Кроме того, apt-get для кого-то будет и не обязателен. В случае винды — фиг там.

Хреново они появляются, честно вам скажу.

программам для пользователя

emacs

Очень смешно.

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

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

Веселее того, time не является частью стандарта shell. Shell, в отличие от dmesg стандартизирован в POSIX, и именно из-за отсутствия в нем синтаксиса time была сделана отдельная утилита time. Всеже bash - самый популярный шелл, а zsh - самый навороченный, они не могли не втолкнуть кучу всего внутрь.

>Сколько на винде займет скачать (с офсайтов) и поставить пару десятков свеженьких программ
1. Качается http://sourceforge.net/projects/mingw-w64/
2. Делается mingw-get install whatever
При желании заменяется cygwin'ом.

дров

Давно качаются автоматически. Кроме экзотического железа, но его не так много и в линуксе с ним хуже.

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