LINUX.ORG.RU

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


0

0

Достаточно противоречивая статья об общих недостатках всех, основанных на Unix, ОС (в т.ч. и Линуксе). Автору не нравятся следующие базовые концепции: всё - файл, всё - текст, сильно недоразвитый X11, не предоставляющий даже базового GUI API, стандартный ввод/вывод, синхронность системных вызовов, а также многое другое. В некоторых вещах с автором трудно не согласиться.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от Sun-ch

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

Саныч, ради бога, поставь себе Win98 в qemu и радуйся жизни!

int19h ★★★★
()

Откуда взялся этот FUD про то, что X'ы _ВСЕ_ гонят через сокеты? Уж BlueBook по крайней мере можно было прочитать? Практически все ресурсы создаются и хранятся на стороне x-сервера, приложение имеет только идентификатор ресурса (long int). При отрисовке по сокету передается только этот идентификатор + команда что с этим идентификатором нужно делать.
Концепция Х пережила несколько поколений графических систем, причем за это время в X удалось вписать OpenGL (с хардверным ускорением), которого на момент создания протокола еще и в проекте не было. И что - все теперь выкинуть, поскольку там кнопки некрасивые?

geekkoo
()
Ответ на: комментарий от Sun-ch

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

Хех, надо уточнять - какой. Разумеется, требования времён 2.2 уже не действительны. Однако говоря "нормальном" подоразумеваем - работает, не подтормаживает. А четверть гига - всего лишь 256 Мб. У меня столько минимально на рабочую станцию с Win2k поставлено, ибо на меньше чем 128 она сама тормозить начинает. Без приложений. Для XP - это 384.

А что касается Win98, да, она будет работать на 64 Мб. Правда без свапа она там одна будет работать. :) И ещё одна беда - наверное давно уже пора всяким линуксоненавистникам и критикам заучить, что сравнивать в Win98 не модно, т.к. ей сейчас можно только подтереться...

Atrus
()
Ответ на: комментарий от Atrus

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

Sun-ch
()
Ответ на: комментарий от Sun-ch

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

/dev/hand ? - хведору поставь. Там кеды собирать не нуно.

anonymous
()
Ответ на: комментарий от Atrus

Мне самому суся нравится больше других дистров, и на рабочем компе (П4-2400, 1Гб ОЗУ) тормозов не заметно, а вот на ноуте (Цел 2.0, 256Мб) кде с гномом тормозят еще так :(

ser_bur * (*) (07.11.2005 17:26:42)

Вот и люди тоже самое говорят, не один только я.

Sun-ch
()
Ответ на: комментарий от Sun-ch

> Blackbox что ли?

Можно и *box.

> Дык это для гиков и нердов всяких,

Ничего подобного. Это для нормальных людей. Для geek'ов -- sawfish и
fvwm.  А всякое K* и G* -- это для придурков, которым пальцы мешают в
дверь проходить. 

> я думаю что уже стоит избавится от иллюзий о нетребовательности
> линукса с ресурсам

Еще раз напоминаю, что WM -- это не Linux.

> что для нормальной работы в нормальном десктопе

Позвольте осведомиться, а что такое "нормальный десктоп"? Размалеванная
по@$ень a la m$?

> надо четверть гига, а лучше гиг памяти и могучий проц.

Ни одному _нормальному_ WM столько не надо.

Dselect ★★★
()
Ответ на: комментарий от Sun-ch

> А чё это не модно?

Поддержу - играться в 1С на одних и тех же мощностях под 98 куда приятней, чем под более грамотными, современными, правильными и модными системами.

anonymous
()
Ответ на: комментарий от Sun-ch

> что такого необычного могут дать новые кеды на немерянных мегагерцах и гигабайтах, по сравнению с этим набором?

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

anonymous
()
Ответ на: комментарий от Sun-ch

>Мне самому суся нравится больше других дистров, и на рабочем компе (П4-2400, 1Гб ОЗУ) тормозов не заметно, а вот на ноуте (Цел 2.0, 256Мб) кде с гномом тормозят еще так :(

Саныч, тебя реально как подменили. На работе (сижу сейчас): SUSE 9.3, KDE 3.4.0. Pentium IV-1800, 256Mb DDR PC2700. Работаю с KDE довольно плотно, обычно запущены kdevelop, konqueror, amarok, licq, всякая лабудень маленькая. Ужасных тормозов не наблюдаю, работает очень хорошо. Где вы это находите???

Ay49Mihas ★★★★
()
Ответ на: комментарий от Dselect

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

И я пожалуй соглашусь с этим.

Sun-ch
()
Ответ на: комментарий от Ay49Mihas

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

Sun-ch
()
Ответ на: комментарий от ogion

2 ogion (*) (07.11.2005 14:02:38)

> В современных компьютерах байт равен 8 битам.

Вот... Я этим и пользуюсь. (Эт, кстати, выдирка из той статьи в wikipedia, на которую Вы ссылку дали :-) )

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

Тах штаааа... (С). Если Вам трудно согласиться, что понятие "размер машинного слова" с успехом заменяет понятие "байт произвольного размера", то... ;-)

R_Valery ★★★
()
Ответ на: комментарий от voiD

Мой старый комп: Pentium I -133MHz 64MB. Ради прикола принес диск с Кноппиксом - загрузились 3-и кеды, долго правда, но загрузились...

Flogger_d
()
Ответ на: комментарий от anonymous

2 anonymous (*) (07.11.2005 14:49:29)

> байт - не константа.

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

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

И вообще, как я понял - для многих понятия "байт", "машинное слово" и "сингл" - практически стали синонимами. А жаль...

R_Valery ★★★
()
Ответ на: комментарий от R_Valery

> Тах штаааа... (С). Если Вам трудно согласиться, что понятие "размер машинного слова" с успехом заменяет понятие "байт произвольного размера", то... ;-)

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

А на счет скалярной величины равной 8 бит, так есть такая величина: octet.

ogion ★★
()

Понраволся пример с mv:

mv *.exe *.bin

Автор также явно не вьехал в "еxpanding wildcards" в униксах.

Автор просто ламо.

ansi ★★★★
()
Ответ на: комментарий от ogion

2 ogion (*) (07.11.2005 18:37:05)

> ...просто не надо утверждать в общем случае неверные вещи, выдавая их за истину.

Ну Бог, конечно, всегда с нами. :-) И истиной в последней инстанции я никогда свои слова не считал...

Просто, маленький пример. Некоторое время назад мы разрабатывали заказ на имобилайзер для одного ретро-авто. Не помню точно, но вроде Олдсмобил 1978 года. Один из сотрудников мучался с моделью, и сатанел от непонимания, почему ничего не выходит. После знакомства с кодом, причина стала ясна, как белый день. Просто он не инвертировал каждый ВТОРОЙ БАЙТ ДАННЫХ КОНТРОЛЛЕРА. Когда ему было указано на это, всё сразу стало с головы на ноги, система заработала. Невнимательность сотрудника оставим в стороне. НО!!! У меня в то время стоял двухголовый оптерон, у сотрудника - двухголовый пень, а "сердцем" контроллера был, кастрированный до немогу, аналог 8086. Сейчас вопрос. Ежели бы понятие "байт" равнялось половине машинного слова, как долго пришлось бы нам искать обший язык и уточнять, о чём конкретно говорит каждый ? ;-))

R_Valery ★★★
()
Ответ на: комментарий от Sun-ch

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

Taже петрушка и с гномом.

А слабо скрин с бидовс/98 запостить? Чтоб не голословно было.

Твой пропустят. Войдеш в аналы. ;)

ansi ★★★★
()
Ответ на: комментарий от Sun-ch

попробуй слаку 3,5 с FVWM95, она те ващще башню сорвет.

anonymous
()
Ответ на: комментарий от ansi

> Твой пропустят. Войдеш в аналы. ;)

Скорее, ЕМУ войдут в аналы. И не один раз :)

anonymous
()

Мдя ... тяжкая статья ... но IMHO доводы и аргументы автора какие то надуманные ... Человек пишуший книги про RedHat Linux и FC ... да ещё пишущий Jabber клиента ... изобретатель велосипедов. Пусть предложит что нить своё ...

robot12 ★★★★★
()
Ответ на: комментарий от Sun-ch

> Из прочитанных здесь тредов я понял, что 95% считают что нормальный
> десктоп это линукс+K* или гном.

Демагогия. Определение "нормального десктопа" -- в студию. А мнение 
95% процентов местных лам^W посетителей никого не интересует.

> И я пожалуй соглашусь с этим.

В топку. Маршрутный газенваген отправляется через полчаса.

Dselect ★★★
()

Ну мля, ЛОР во всей красе... Столько тут натявкали,
что уже и обсуждать противно. Статью никто не читал,
это понятно (те, кто читал - не обижайтесь, это не
вам), но накуя пи***ть то?
Не знаю для кого, но попробую вкратце разжевать
основные идеи статьи. На это сообщение можете не
отвечать, "ослам такое не понять" (с)реклама.

1. Everything Is a File (Unless It Isn't)
Здесь автор говорит, что нет смысла обобщать
принципиально несовместимые вещи и прятать их
под одну абстракцию (файл), т.к. это приведёт к
частичной потере функциональности. Он говорит,
что лучше иметь более высокоуровневый API.
Логика верна, хотя не знаю, чем его API будет лучше
того же ioctl. Подробностей он, к сожалению, не
изложил.

2. Everything Is Text
Здесь автор говорит, что plain text - не очень
хороший способ представления произвольной информации.
Если бы все проги, выдающие текстовую инфу (а
таких в юниксе пруд пруди) выдавали бы инфу не
в plain text, а в каком-небудь XML, то обрабатывать
её можно было бы гораздо эффективнее.
По-моему трудно не согласиться.

3. No Introspection
Хочет видеть стандартные пути получения мета-инфы
о файлах (не через file, а прямо на уровне ФС
наверное). И ещё что-то там мутное. Этот пункт
не берусь комментировать.

4. X11: Almost a GUI
X11 обвиняется в чрезмерной низкоуровневости и
непродуманности. Предлагается использовать более
высокоуровневые примитивы, PostScript-совместимую
систему команд отображения, возможность обработки
событий на стороне сервера (а не передавать их
по сети клиенту, чтобы он их обработал и вернул
новое изображение серверу) и тд.
Комментировать не берусь, однако меня самого
напрягает, например, тот момент, что если окно
моей проги "повреждено" окном другой проги, то
ИКСы просто сообщают мне "перерисуй-ка батенька
такой-то регион", в то время как сами бы могли
это легко за меня сделать и траффик сэкономить.

5. Standard Input, Standard Output
Да, каждый знает, как получать любое количество
файловых дескрипторов, хотя какой-то мудак тут
зачем-то про mkfifo 314здел. Однако попробуйте
соединиться с удалённой машиной через, скажем,
telnet, и посмотрю я как вы протянете в этом
соединении дополнительные каналы. Можно создать
дополнительные соединения, но все, кто знаком с
FTP-протоколом, знают, сколько для этого на практике
приходится выделывать. Автор наверное пытался
сказать, что модель tty с тремя дескрипторами
устарела. К сожалению конкретики приводится мало.

6. Synchronous System Calls
Детали реализации.

7. One-Way System Calls
Слишком мало механизмов передачи информации от
ядра к пользовательскому процессу. Message-passing
отсутствует, а сигналы несут не достаточно инфы
и не удобны в использовании. Приводится классический
пример о том, что после получения SIGIO от одного
из файловых дескрипторов, их приходится потом ещё
демультиплексировать вручную, так как нет информации
о том, от какого именно дескриптора пришёл SIGIO.
Трудно не согласиться.

8. C: Cross-Platform PDP Assembler
ОК, это флэйм. Без комментов.

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

Короче. Статья - не идеал. Далеко не. Слишком
мало конкретики, по некоторым пунктам её вообще нет.
Однако большинство претензий сами по себе справедливы,
а местная общественность, как обычно, лишь показала
свою ущербность, не сказав ни слова по делу.

anonymous
()
Ответ на: комментарий от anonymous

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

Если не умеешь пользоваться - тогда, да - "утеряна":)

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

Led ★★★☆☆
()
Ответ на: комментарий от anonymous

>нет смысла обобщать принципиально несовместимые вещи и прятать их под одну абстракцию (файл), т.к. это приведёт к частичной потере функциональности. Он говорит, что лучше иметь более высокоуровневый API.

И где противоречие между абстакцией (файл) и высокоуровневым API? Где "несовместимость". Почему не может быть и того, и другого? Почему файл-абстакция не может быть одним из вариантов API (пример - FUSE)

>5. Standard Input, Standard Output Да, каждый знает, как получать любое количество файловых дескрипторов

При чём тут дескрипторы, когда речь о пайпах? Не хватает StdOut+StdErr (а кто сказал, что должно хватать) - есть именованные потоки - пользуй:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

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

anonymous
()
Ответ на: комментарий от Led

> И где противоречие между абстакцией (файл) и
> высокоуровневым API?
Ты у меня спрашиваешь, или в принципе? Свои
комменты я отделял от того, что излагалось в
статье. По данному пункту я тоже, как и ты, не вижу
особой проблемы.

> При чём тут дескрипторы, когда речь о пайпах?
Да, наврное тут я его не правельно интерпретировал...

> есть именованные потоки - пользуй:)
Да не решение это. Анонимные пайпы ими можно заменить,
но тогда это лишь костыль. Их надо будет стирать за
собой (а если прогу покиляли?), потом ещё если
несколько прог одновременно запустить, то использовать
придётся случайные имена для fifo, чтобы не было
накладок, и тд. Можно, но криво.

anonymous
()
Ответ на: комментарий от anonymous

> потом ещё если
> несколько прог одновременно запустить, то использовать
> придётся случайные имена для fifo
... и это даже не прокатит если нельзя вызываемой
проге это имя как-либо передать (предполагается, что
нельзя). Одним словом, не вариант imho.

anonymous
()
Ответ на: комментарий от anonymous

> 2. Everything Is Text
> Здесь автор говорит, что plain text - не очень хороший способ
> представления произвольной информации.

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

> Если бы все проги, выдающие текстовую инфу (а таких в юниксе пруд
> пруди) выдавали бы инфу не в plain text, а в каком-небудь XML,

О, еще один #удак з ЗюМеЕл'ем свои сюда приполз. 

> то обрабатывать её можно было бы гораздо эффективнее.

Наглая ложь. Человеку, естественно, зюмель неудобен (как представлю себе,
что мне вдруг ls выдаст ЭТО... брр...), программе -- тоже: нафиг парсить
какую-то срань, если можно просто получить struct stat (или dirent, или 
чего там еще).

> По-моему трудно не согласиться.

А если подумать?

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

А как передавать? С помощью Силы?

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

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


Dselect ★★★
()
Ответ на: комментарий от Sun-ch

> А чё это не модно? Прекрасно работает офис-97 и ие5 и аутлук экспресс.

Собственно и всё. Дело даже не в игрушках, банальный TortoiseSVN доступен только древне-лохматой версии. И так весь остальной софт. Низкий поклон M$ за разный подход к поддержке unicode, за разные версии mfc... ;-)

atrus ★★★★★
()
Ответ на: комментарий от anonymous

> Ну мля, ЛОР во всей красе... Столько тут натявкали, что уже и обсуждать противно. Статью _никто_ не читал, это понятно

Ой ли, никто? Это другой случай - "камменты" не читаем... ;-)

http://www.linux.org.ru/profile/atrus/view-message.jsp?msgid=1145170#1145602

atrus ★★★★★
()
Ответ на: комментарий от anonymous_incognito

> Кстати, именно разработчики Plan-9 додумались до utf-8. Интересно прочитать их о том как они делали utf-8.

Спасибо за материал, только что-то я проглядел в нём. Ну так как сделать в utf-8 потоке, в позиции N, переход на символ N+M? ;-)

atrus ★★★★★
()
Ответ на: комментарий от suser

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

Наивный верующий в байки, а cmd.exe это что, а cygwin, а UNIX for NT или как его там набор утиля от мелксофта?

anonymous
()
Ответ на: комментарий от PashaKustov

>10.1 The UNIX file system doesn't even include a single bit to mark a file as hidden. ************ сколько я *****я, пока не додумался добавить hide files = /desktop.ini/ в smb.conf, чтобы roaming profiles нормально работали...

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

anonymous
()
Ответ на: комментарий от anonymous

>1. Непостоянство ОС.

В линукс еще хуже - перманентный слом интерфейсов ядра.

>2. Собственно система впитала в себя слишком много старых идей.

Linux азируется на старой концепции UNIX.

> Толковой технической документации на систему крайне мало и она как правило сторонних авторов (!)

А Windows Internals и прочее? А что насчет Microsoft Press?

>4. Отсутствие свободы выбора. Ну это я думаю многие знают: офисы, ИЕ, оутглюк, медиаплеер и пр. творения "намертво" встающие в систему по маркетинговым соображениям :-)

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

>5. Система жиреет и тупеет на глазах. Сколько занимала винда 3.1?

А Linux 1.0 сколько весил? А сейчас с кедами, опеноффисами, мозиллами и прочим сколько гигабайт? Да и всем собственно плевать на занимаемый размер, при нынешних ценах в 50центов за гигабайт и обычных винтах на 120, 160, 256 гигабайт.

anonymous
()
Ответ на: комментарий от Sun-ch

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

Открой для себя Gentoo, саныч! :)

anonymous
()
Ответ на: комментарий от Sun-ch

>Мне самому суся нравится больше других дистров, и на рабочем компе (П4-2400, 1Гб ОЗУ) тормозов не заметно, а вот на ноуте (Цел 2.0, 256Мб) кде с гномом тормозят еще так :(

На цедероне и винда задумывается время от времени.

anonymous
()
Ответ на: комментарий от Dselect

>Ничего подобного. Это для нормальных людей. Для geek'ов -- sawfish и fvwm. А всякое K* и G* -- это для придурков, которым пальцы мешают в дверь проходить.

Откуда ж вас столько плодится, красноглазых злобных и визгливых как болонки фанатиков, считающих, что знание десятка команд консоли - удел гениев, а удобный дружественный к пользователю интерфейс - происки m$? Очисти коммунити, бери пример у Томми. Или сиди себе в черной консоли, в lynx слушай mpg321 и не мешай людям получать удовольствие от комфорта KDE/Gnome, Opera/Firefox/Mozilla, OpenOffice, gmplayer/xine, tvtime, xmms/amarok, ...

anonymous
()
Ответ на: комментарий от Dselect

>А мнение 95% процентов местных лам^W посетителей никого не интересует.

Мнение самодовольных выродочных гиков, ставящих себя выше других, никого не интересует.

>В топку. Маршрутный газенваген отправляется через полчаса.

Вот-вот.

anonymous
()
Ответ на: комментарий от atrus

> Спасибо за материал, только что-то я проглядел в нём. Ну так как
> сделать в utf-8 потоке, в позиции N, переход на символ N+M? ;-)

M раз перейти к символу N+1, очевидно =)

А что, часто приходится по тексту прыгать? В бинарных данных я еще
понимаю смысл seek, но текст как правило и читается в потоковом режиме
- от начала и до EOF.

int19h ★★★★
()
Ответ на: комментарий от anonymous

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

Концепция работает. Подавляющему большинству команд просто не нужно
самим разворачивать wildcards, функциональность шелла там как раз к
месту. Тем, кому нужно, никто не мешает это делать самим, опять же,
таким образом, каким это эффективно (man glob, man rename).

int19h ★★★★
()
Ответ на: комментарий от Dselect

> > однако меня самого напрягает, например, тот момент, что если окно
> > моей проги "повреждено" окном другой проги, то ИКСы просто сообщают
> > мне "перерисуй-ка батенька такой-то регион", в то время как сами бы
> > могли это легко за меня сделать и траффик сэкономить.
>
> Нет, не могли. Тогда б bitmap'ы у клиента и сервера быстренько б стали
> out of sync.

Не вижу причин, почему бы умное кэширование привело к такому результату.

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

int19h ★★★★
()

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

gigabitto
()
Ответ на: комментарий от Dselect

> А _произвольную_ инфу никто и не представляет в
> текстовом виде. ELF binaries
Чувак, я же написал:
---
Если бы все проги, выдающие текстовую инфу (а
таких в юниксе пруд пруди) выдавали бы инфу...
---
ну и при чём тут ELF binaries?

> Наглая ложь. Человеку, естественно, зюмель неудобен
Я не собираюсь разжёвывать каждое слово. Ты статью-то
читал, умник? Там говорится, что для вывода на
экран мета-формат мог бы пре-парсить тот же шелл.

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

Слив защитан, до свидания.

anonymous
()
Ответ на: комментарий от atrus

>> Ну мля, ЛОР во всей красе... Столько тут натявкали,
>> что уже и обсуждать противно. Статью _никто_ не
>> читал, это понятно
> Ой ли, никто? Это другой случай - "камменты" не
> читаем... ;-)
Ну я же специально написал:
---
(те, кто читал - не обижайтесь, это не вам)
---
Ладно, в следующий раз напишу "никто кроме artus
статью не читал" :)

anonymous
()
Ответ на: комментарий от int19h

> месту. Тем, кому нужно, никто не мешает это делать
> самим, опять же, таким образом, каким это эффективно
> (man glob, man rename).
В принципе согласен. Гм, что же он тогда имел ввиду,
я пасс... :)

> Не вижу причин, почему бы умное кэширование привело к
> такому результату.
Да слушай ты больше этого Dselectа.

anonymous
()
Ответ на: комментарий от anonymous

>Почти ни с какой Читай \par man find \par Ламер, блин. \par

MS
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.