Десять ненавистных вещей в (U)nix'ax

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

Тоесть сначала ls должен генерировать xml, а затем zsh должен приводить его в человеческий вид? Зачем? Не лучше ли сделать как сейчас --- сразу по--нормальному?

P.S. Автор, напоминает наших кривозащитников, они борются с системой, маскируя это борьбой с недостатками системы. Автор говорит о недостатках юниксов, но на самом деле ему просто не нравится *никс.

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

А достоинство только одно - *nix ни смотря ни на что работает и делает свое дело, в то время как некоторые коммерческие системы тратят мощь процессора на отлов каких то непонятных вирусов, червей и троянов...

> И что - все теперь выкинуть, поскольку там кнопки некрасивые?

Нет, речь о том, что примитив типа "кнопка" запихать в протокол. А X-сервер будет, конечно, по-прежнему определять look-n-feel. За счет ресурсов.

> Если нет, то наверняка кто-то уже сделал кэширующую проксю для X-протокола.

lbx.

Обычный пиар. Или анти-пиар, что кому ближе. Юникс, конечно, не идеал, но далеко не такой отстой, как хочется некоторым. В любом случае, мир IT и науки много бы потерял, не будь его. Использую Юникс вот уже 10 лет. Недавно обзавёлся ноутбуком с установленной ОС Windows. Поюзал её, пописал программки кое-какие. Но, в общем, это не моё. Ощущение такое, что чего-то не хватает. Не можешь контролировать систему. Реестр навевает негативные воспоминания о Win95 и WinNT. Словом, убил Уиндоуз, впарил FreeBSD.

PS Вообще, писателей развелось тьма. Все пишут, пишут... Впрочем, на дворе такое время, когда в чести одни #%&@#болы и певцы...

> 9. Small Tools, Not Small Libraries > Пример "mv *.exe *.bin" очень даже выразительный. > Какие-то уроды тут вспомнили про krename... да не > в ренэйме дело, а в том, что если шелл раскрывает > wildcards, то у самой проги уже нет полной информации > об исходной команде, часть информации утерена. > Вследствии чего правельно отработать "mv *.exe *.bin" > нельзя в принципе, даже если бы захотели.

вызывающе неверная информация.

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

поэтому, есть мнение, что dos-like интерфейс а-ля `mv *.exe *.bin' немного неоптимален. лично я, когда писал свой хак а-ля rename (не то, чтобы их мало в природе -- просто решил, что мне легче будет написать свое, чем искать чужое оптимальное =) решил так:

1. нужны in- и out-выражения. параметры, почему нет. 2. нужен список файлов. мне показалось элегантнее давать его через stdin.

(инкарнацию этого безобразия на tcl можно посмотреть на http://deskpot.flexpro.ru/dotfiles/bin/ren, где-то была более древняя и менее изящная аналогичная перловая, но сходу не нашел.)

так вот. мне почему-то подобного хватает. =) мне вообще кажется, что проблема надумана.

---vk

> Тоесть сначала ls должен генерировать xml, а затем zsh должен приводить его в человеческий вид? Зачем? Не лучше ли сделать как сейчас --- сразу по--нормальному?

просто не надо забывать, что тот же xml -- это такая структура. а текст в общем смысле -- нечто позволяющее создать какую угодно структуру. (или xml не из буковок состоит? =)

вопрос -- на какой баянЪ нам надо убивать возможность иметь структуры для вывода информации кроме одной? особенно, учитывая то, что xml да-алеко не идеален, и попытки его внедрять это налево и направо показывают. =)

---vk

> на 64 метрах кеды не стартовали

стареешь ты как флеймер.

у меня на 64 метра на пне-200 3.0.4 запросто запускалась и работала год без нареканий

>Для нынешних кед и 256 метров мало.

ламерское вранье. я три года последних на 128 в кде сижу - все нормально. 3.4.3 вот недавно собрал

>Так что если кеды и рулят, то только резиновые

ламеры поколения пепси не умеющие настроить систему идут в /dev/null

>И что WM'ов получше K*

wm получше чем de? мальчик ты бы хоть маны почитал прежде чем такую чушь нести =)

>> Прямые апострофы и обратные слэши не пробовал?

Конечно пробовал - и с какой командой это работает?

С теми, которыми это необходимо - работает:) Например, find

> Анонимные пайпы ими можно заменить, но тогда это лишь костыль.

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

>Их надо будет стирать за собой (а если прогу покиляли?)

Стирать за собой всё равно придётся. Доя аварийного завершения программы (а это уже нештатная ситуация) есть cron - проверяй $TEMP на наличие "бесхозных" пайпов периодически и убивай. Вот это уже "костыль", но для "программ-инвалидов" без "костылей" никак не получается:)

>если несколько прог одновременно запустить, то использовать придётся случайные имена для fifo

man mktemp

>Можно, но криво.

Для меня дизель - очень криво (я в дизелях не разбираюсь):)

>и это даже не прокатит если нельзя вызываемой проге это имя как-либо передать

Почему нельзя??? Можно! разрешаю:)

>предполагается, что нельзя

:)))))))

>Одним словом, не вариант imho.

Последний раз я такую логику встречал, когда в детский сад ходил:)))

>Уж чья бы корова мычала, я кеды на своем ноуте 6 дней собирал, а они так не запустились, пришлось перейти на виндовс-98 - летает как чумовая.

486Dx2?

> Ну я же специально написал:

> (те, кто читал - не обижайтесь, это не вам)

lol, теперь уже мне шпилька. :)

> считающих, что знание десятка команд консоли - удел гениев

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

> а удобный

Он не удобный -- он навязчивый.

> дружественный к пользователю интерфейс

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

> не мешай людям получать удовольствие от комфорта KDE/Gnome

Получайте, сколько угодно -- я только за. Можете не только от K*/G*, можете еще чего-нибудь покурить или чем-нибудь уколоться -- лишь бы сдохли побыстрей.

> OpenOffice

Да Вы мало того что дурак, так еще и мазохист...

> Тоесть сначала ls должен генерировать xml, а затем zsh
> должен приводить его в человеческий вид? Зачем? Не
> лучше ли сделать как сейчас --- сразу
> по--нормальному?
Там приводится пример когда надо отсортировать
список файлов, возвращаемый ls, по размеру.
И говорится, что если ls будет строить этот список
в понятном для человека виде, т.е. 12K, 143M, 328 и тд,
то отсортировать его будет очень сложно, и придётся
просить ls вывести этот список в неудобном для
человека виде, т.е. всё только в байтах. Тогда
отсортируется легко, но потом придётся обратно в
нормальный вид приводить.
Если есть мета-информация, то эта проблема решается
стандартными средствами.
Это примерно то же, что предлагать для www только
plain-text использовать - всё равно ведь для человека
выводится инфа в конечном итоге, так почему бы
её сразу plain-textом и не хранить...

> Чувак, я же написал:
> ---
> Если бы все проги, выдающие текстовую инфу (а
> таких в юниксе пруд пруди) выдавали бы инфу...
> ---

А я, кажется, сказал, что человеку лучше выдавать текст, а между собой
общаться через нормальный API: сразу нужные структуры передавать, а не
их текстовое|S-exp представление. И никакой *ML для этого нафиг не нужен.

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

А что такое сигарета с фильтром?
Сначала выкуриваешь фильтр, а потом -- как у нас...

>> Нет, не могли. Тогда б bitmap'ы у клиента и сервера
>> быстренько б стали out of sync.
> Бред.

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

>> И что WM'ов получше K*
> wm получше чем de?

Formula-1 лучше, чем инвалидная коляска с кучей бесполезных рюшечек.

> Стирать за собой всё равно придётся.
Что, анонимные пайпы-то? Именованные - их да, придётся. Об том и речь.

> есть cron - проверяй $TEMP на наличие "бесхозных"
> пайпов периодически и убивай.
Ну-ну, продолжай рассказывать о том, как мне придётся
извращаться, чтобы перейти с анонимных на именованные
пайпы.

>> и это даже не прокатит если нельзя вызываемой проге
>> это имя как-либо передать
> Почему нельзя??? Можно! разрешаю:)
А что можно то? Когда анонимные пайпы на stdin/stdout
подсовываешь, проге ничего передавать не надо - она
будет работать так, как всегда. А вот с именованными,
тем более если с рандомными именами, ей надо уже
как-то передавать эти имена. А теперь назови
стандартный способ такой передачи, ась? Можно
сказать "-o", но это лишь для одного пайпа работает
(и то не везде), а если их больше? Тогда всё,
никакой универсальности - в отличии от анонимных.
Что не понятно то?

> Последний раз я такую логику встречал, когда в
> детский сад ходил:)))
Ну ходи дальше, что ж поделать.

> А я, кажется, сказал, что человеку лучше выдавать
> текст, а между собой общаться через нормальный API
Как две *проги* могут общаться через API?

> сразу нужные структуры передавать, а не
> их текстовое|S-exp представление. И никакой *ML для
> этого нафиг не нужен.
А универсальность? Если твои структуры специфичны
для каждой проги, то накуя они нужны? Текстовый
вывод от *любой* проги может быть передан на grep
или sort, но, как показано выше, без мета-инфы не
всё можно правильно отсортировать например.

> Сначала выкуриваешь фильтр, а потом -- как у нас...
Как я уже говорил, переведи www на plain-text тогда уж.

> Особо одаренным напоминаю, что X-клиент и X-сервер не
> обязательно работают на той же самой машине.
И? Развивай свою мысль, не стесняйся.

Понаписали-то!
Вставлю свои 5 копеек:
*NIX - система МОДУЛЬНАЯ. Как фанаты вендов этого понять не могут??? Надо тебе оконное API - ну возьми QT/GTK, в чем проблема-то?
Сколько раз можно объяснять, что задача ОС - быть прокладкой между железом и пользовательским приложением? Нет, блин! Аргументы фанатов вендов сводятся к тому, что в телевизор должен быть встроен пылесос. Модульность системы на уровне потоков ввода-вывода - огромный плюс! Это позволяет разработчику конкретной софтины не решать мировые проблемы совместимости/внутренней работы ОС/тупизны пользователя. А просто решить "на stdin я получаю такие-то данные, на stdout - вывожу такие-то" и, соответственно, заняться конкретно алгоритмом и кодом софтинки. ВСЁ! Захотел потом какой-то другой разработчик прикрутить графический интерфейс к такой софтине - никаких проблем: формат всех данных известен, алгоритм и код выверены многолетней эксплуатацией - надстраивай какие душе угодно красивости.
Вот и получаем цепочку: ядро - фронтенд к железу, libc - фронтенд к ядру, Х - графический фронтенд к ядру, QT/GTK - API-фронтенд к X, пользовательское приложение - одновременно фронтенд к ядру (на уровне libc) и фронтенд к QT/GTK (на уровне отрисовки графики); либо пользовательское приложение вообще из двух независимых частей: "консольная" программа и "графический интерфейс" к ней.
Плохо? Да нет же! Каждая команда разработчиков занимается своей частью системы. Главное - совместимость интерфейсов. Да, бывают смены интерфейсов. Но и в венде они постоянно меняются! Самая позорная смена интерфейсов была в W2K, когда их поменяли прямо перед релизом и железопроизводители были вынуждены переписывать драйверы.

Как тут правильно сказали, потоковая система производит некоторый оверхед, причина которого в том, что нужно парсить потоки. Ну а разве бесконечные варианты API от макросакса не есть чудовищный оверхид? Win32+MFC+COM+.NET+что_еще_там? И километровые структуры в программах, занимающие килобайты и десятки килобайт оперативной памяти? А на обработку всей этой радости тратятся огромные ресурсы процессора, при практически нулевой отдаче. Вот и причина тормозов и глючности вендов: абсолютное отсутствие гибкости программных интерфейсов как таковых, что вынуждает макросакс придумывать дополнительные программные интерфейсы (и, ессно, для совместимости оставлять старые), которые в сумме и выжирают львиные доли ресурсов компьютера.

Далее, реестр... У реестра 2 самых главных недостатка перед текстовыми конфигами:
1. Бинарное представление. Что делает невозможным "поправить" реестр руками при каком-нибудь сбое.
2. Поскольку реестр - целостная структура, венда вынуждена держать его в оперативке целиком. Что как минимум просто бесполезный груз (ну, типа, зачем держать в оперативке ключи реестре Word'а, если он в данный момент не запущен?), а как максимум понижает общую производительность системы (вновь запущенная или работающая программа тратит слишком много времени на поиск "своих" ключей реестра).
В этом отношении текстовые конфиги намного приятнее: в случае сбоя (например, железа) подправить/создать новый конфиг данной конкретной программы можно без проблем и без общего сбоя системы; каждая программа считывает нужный ей конфиг во время запуска и выгружает из оперативки при закрытии, что позволяет экономить ресурсы системы для других приложений.

Не растилайся!
Статья проплачена, афтар куплен! За что гореть ему в гиене огненой :)

>>действительно, походу автору надо срочно принять калия. желательно цианистого =)

>>автор написал что если представить фильтр который демультиплексирует поток на два потока аудио & видео, то лучшее (единственное возможное) это послать один поток на std error, плюнув на реальную возможность отрапортовать ошибку. Мораль - двух выходных потоков мало. С чем ты не согласен ?

средствами шела можно перенаправить любой дискриптор. Например так

<прога> &7> tmp

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

но ваще бред

читал комменты. долго. давайте ещё погавкаем! :)

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

>>Вообще в UNIX hidden файлы начинаются на точку...

>Теперь перечитай мой пост и подумай, к чему ты это сказал.

К тому что

>10.1 The UNIX file system doesn't even include a single bit to mark a file as hidden

>> не мешай людям получать удовольствие от комфорта KDE/Gnome

>Получайте, сколько угодно -- я только за. Можете не только от K*/G*, можете еще чего-нибудь покурить или чем-нибудь уколоться -- лишь бы сдохли побыстрей.

>> OpenOffice

>Да Вы мало того что дурак, так еще и мазохист...

Считаешь себя умнее других? ИМХО тебе просто не дают бабы, вот ты и бесишься мудила. Раз так, то сходи на#уй.

>Formula-1 лучше, чем инвалидная коляска с кучей бесполезных рюшечек

ага. а бреешься ты чиста газонокосилкой как "реальный пацан".

зы. и зачем ты влез в тред если не знаешь чем отличается wm от de? сравнивай с kwin\metacity (или что там у гнумеров) с конкретными притензиями "вот это ННН в таком то вм лучше чем в том вм", а не фанатскими быдловоплями

>10.1 The UNIX file system doesn't even include a single bit to mark a file as hidden

а какие именно фс? =)

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

>Наш ответ Чемберлену :-) Например, 5 вещей, которые я ненавижу в виндах! (хотя часть из них и в линуксе частично имеет место быть).
...
>5. Система жиреет и тупеет на глазах. Сколько занимала винда 3.1? А ведь я на ней даже в инет легко выходил в 94 году :-), да может не так комфортно, но моего времени это отнимало столько же сколько и сейчас... Сколько сейчас занимает, скажем, ХР - 370 мегов, а сервиспак к ней - целых 280 (это ж надо было _столько_ ошибок наделать, а?). Это и есть прогресс? Закон Парксинсона напомнить? Усложнение - есть разложение. То что я раньше делал на 486 теперь замечательно можно делать на П4... Короче говоря, неплохую вроде идею времен НТ 3.51 к моменту выхода 2003 сервера засрали довольно внушительно.


Есть разные замечания.

Сервис пак занимает так много, потому что он целиком заменяет файлы, а не накладывает патчи !
Например берем обычную XP без SP - ISO-ник весит 488 Mb
Берем XP+интегрированный SP2 - ISO-ник весит 584 Mb
Чего туда кроме нового firewall напихали - не знаю ;)

Система стала толстая в частности из-за того что добавлено много чего раньше не было. Например сразу присутствует IE, Windows Media Player и множество всякой другой всячины.
Кроме этого еще лежит каталог с КОПИЕЙ dll-ек.
А на Windows XP еще и System Restore включенный по умолчанию вносит свою лепту.


А в целом я по всем пунктам согласен.

>А чё это не модно? Прекрасно работает офис-97 и ие5 и аутлук экспресс. А что такого необычного могут дать новые кеды на немерянных мегагерцах и гигабайтах, по сравнению с этим набором?

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


Немного в тему.
Недавно вот у одного товарища полетела Windows 98 на компе. Поставили ему туда Windows 2000. Думали будет тормозить.
Я был удивлен когда он сказал, что система просто летает по сравнению с тем что было раньше.

>Далее, реестр... У реестра 2 самых главных недостатка перед текстовыми конфигами:
1. Бинарное представление. Что делает невозможным "поправить" реестр руками при каком-нибудь сбое.
2. Поскольку реестр - целостная структура, венда вынуждена держать его в оперативке целиком. Что как минимум просто бесполезный груз (ну, типа, зачем держать в оперативке ключи реестре Word'а, если он в данный момент не запущен?), а как максимум понижает общую производительность системы (вновь запущенная или работающая программа тратит слишком много времени на поиск "своих" ключей реестра).
В этом отношении текстовые конфиги намного приятнее: в случае сбоя (например, железа) подправить/создать новый конфиг данной конкретной программы можно без проблем и без общего сбоя системы; каждая программа считывает нужный ей конфиг во время запуска и выгружает из оперативки при закрытии, что позволяет экономить ресурсы системы для других приложений.


Бинарное - это большой минус.
Но IMHO еще больший минус - очень слабая документированность реестра.
Информацию приходится собирать по разным местам или методом тыка.


Реестр - не целостная структура :)
Во первых есть разные разделы - HKLM, HKCU и другие.
Кстати у каждого юзера свой HKCU.
Сами разделы имеют древовидную структуру.
Windows не держит весь реестр в оперативной памяти !!!
То есть он может быть весь в памяти, а может и не быть.

Да и не такой он большое - у меня на машине 55 Mb отведено под реестр.
Занято 44 Mb, сколько в данный момент из этого в памяти - не знаю.

Еще одна проблема реестра - это наличие permissions :)
То их нет там где надо, то всякие кривые программы пишут куда нельзя.


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


Насчет того что ты можешь руками создать конфиг любой программы - это ты зря. Например нарисуй мне с нуля конфиг squid или apache.
Ты скорее всего либо достанешь из backup этот конфиг, либо возъмешь оригинальный и подправишь в нем.

> и зачем ты влез в тред если не знаешь чем отличается wm от de?

DE --  куча хлама, которая мнит себя нянькой для пользователя;
мешок с дерьмом, которое изо всех щелей прет назойливо, самоуверенно,
и отчаянно воняет. 

>А он что, дюже развитый чтоль? Вы много написали игрушек на чистом ОпенГЛ? Как был "отрисовыватель треугольников", так и остался - ни тебе сцен, ни коллизий...

Бл%$юга ты тупая, ты вообще знаешь что такое OpenGL и для чего он нужен? Балин, ну откуда? Откуда берутся такие имбецилы? Чмо, убей себя пожалуйста апстену!

Да, с пермишенами и со слабой документированностью реестра согласен.
С тем, содержится ли реестр целиком в оперативке... Эм. Наверное, ты не так понял (да и я не четко выразился). Я имел в виду, что реестр целиком содержится в виртуальной памяти (оперативка+своп). То есть, его кусок может быть в свопе, но реестр ЦЕЛИКОМ содержится в памяти.

"в UNIX каждая программа будет подгружать себе одно и тоже"
Да, проги "подгружают" то, что им надо. Заходят они "просмотреть" чужой конфиг - нет проблем (если прав хватит).

"Ты скорее всего либо достанешь из backup этот конфиг, либо возъмешь оригинальный и подправишь в нем."
Конечно. Но разве это же можно сделать в вендах? Вот конкретный пример: у меня была старенькая 486-я в качестве файлопомойки домашней и у нее бедблок на /etc/smb.conf попал. Я перенес smb.conf в /tmp, а /etc/smb.conf восстановил ручками и дефолтного. Всех проблем. Ессно, даже перезагрузки не понадобились. Прикинь, что бы случилось с вендой в подобном случае! :-)