Linux. Мнение и сомнение

>только бесплатная и убогая как всё халявное.

Ну "убогая как все халявное" еще можно понять, но что бы значило "бесплатное как всё халявное"? :)

>Однако, когда за дело берётся критическая масса
>энтузазистов-одиночек, получается нечто вроде вихря вокруг телеги -
>медленно, архаично, но телега двигается!

Временами это бывает даже не медленно и не архаично. :)

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

Примерно так. Хотя к чему тут приплетено "стыдно" непонятно. Всегда думал, что для сервера важна работа(стоит ли там Linux, Windows или еще что), а не какой-то внешний лоск, для автора этого пафосного произведения это, похоже, не так.

>И всё бы ничего, и сидели бы отдельные админы-отщепенцы в командной
>строке, тщеславно медитируя над азбукой sendmail'а, но факты -
>упрямая вещь: графический интерфейс оказывается НАМНОГО более
>продуктивным, чем лазание по конфигам с vi.

Факты - упрямая вещь: даже в самом дружелюбном окружении (как, например, KDE) в большинстве нетривиальных случаев любой вменяемый человек сочтет более быстрым и удобным поправить то, что надо, с помощью vim/emacs. Кроме того, даже в том случае, когда само по себе конфигурирование удобнее и возможно из GUI, текстовые config файлы очень удобны для пакетной переконфигурации(в той же win через wsh это на порядок менее функционально и более затуманено), для переконфигурации из легких оболочек вроде secure shell(опять же оснастки вроде management console существуют далеко не для всего). Графический интерфейс стал развиваться, вопреки бредням анонимуса, вовсе не для облегчения администрирования Linux сервера, а для создания инфраструктуры для "пользователя". Никто никогда не возьмет админом человека, который не понимает как работает та или иная вещь внутри, даже если он профессионально тыкает на кнопки.

>И вот, некогда служивший "показывалкой нескольких терминалов", на
>сцене вновь возродился X Window.

Безграмотный анонимус не знает, что продукт называется X Window System, где "Window System" означает "оконная система", т.е. "оконная система X", а вовсе не "X Window" (что значит "X окно"), поскольку термин "X Window" относится к одному из базовых объектов упомянутой X Window System. Кроме того, X никогда не возрождался, поскольку никогда не умирал, во времена создания Linux графическая среда на базе CDE(и аналогов) активно использовалась в коммерческих UNIX. И сами Иксы были адаптированы для Linux, когда он стал "чем-то удобоваримым" в определении анонимуса.

>Стали появляться всякие графические библиотеки, "морды" к утилитам, а
> то и полностью графические прибамбасы (gimp, Mosaic). За графикой
>закономерно полезли игры, звук, офисные приложения...

Почти верно.

>Однако, чем дальше в лес, тем очевиднее становилось противоречие
>между изначальной концепцией "текстовых потоков" и нахлынувшими
>современными форматами

Отнюдь. sox и convert, к примеру, прекрасно интегрируются с coreutils.
С KDE приложениями и coreutils зачастую удобной связующей прослойкой служит DCOP. Как раз, как это не странно, классическая UNIX парадигма до сих пор живее живых.

>(вам это не напоминает аналогичный "мультимедиа"-идиотизм под
>названием HTML, разработанный пердунами из W3C?).

Парадоксально, но создатель HTML - не W3C, а CERN.

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

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

>Многие части ядра являются жёстко встроенными. Это создаёт помехи со >всех сторон.

>Такие задачи как добавление нового диска(с новой файловой системой)

Если "добавление нового диска" - это hotplug диска(как правило, USB Mass Storage), то это работает. В KDE это выглядит появлением новой иконки в storage media аплете в kicker, и появлением нового диска в media:/ в konqueror. Работает это на базе "архаичной и устаревшей" архитектуры Linux (hotplug+hal либо напрямую через hotplug с помощью contrib скриптов KDE), по-моему во всех современных дистрибутивах сразу из коробки(в FC точно). Драйверы дисковых устройств, как указано выше, прекрасно работают модулями(подгружаемыми через hotplug). Файловые системы так же работают модулями(подружаемыми через hotplug). Нет совершенно никаких проблем ни при добавлении внешнего драйвера дискового устройства или файловой системы.

>обновление графического драйвера

"Обновление графического драйвера" - это ,как правило , добавление ряда so(dix, mesa драйверы), переконфигурация X, выход из X, вход. В отличие от сверхсовременной операционной системы Windows даже не нужно перегружаться(sic!). Ускорение (поддержка AGP и direct rendering) уже переходит в плоскость ядра и имеет некоторые нюансы,но опять же, эти подсистемы полностью модульные и при загрузке новых модулей не требует ся перезагрузка.

>всевозможные "заплатки" на защиту, всё это не решается принципиально.

"Заплатки" на защиту - как раз элементарно. Их десятки и благодаря открытости Linux можно получить извращения совершенно немыслимого характера. Кроме того, на уровне интерфейсов ядра есть поддержка т.н. модулей безопасности(Linux security modules), которая позволяет вклиниваться и изменять поток исполнения во всех критичных местах ядра. Одним из примеров модуля безопасности является SELinux - подсистема, реализующая mandatory access control. Ничего подобного в ряде современных ОС вроде Windows нет и не может быть, поскольку подсистема безопасности в них жестко прошита.

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

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

>Архаичное нагромождение исходников не позволяет более продуктивно
>развивать ядро.

Исходники собраны весьма логично. Здесь Linux и, к примеру, NetBSD на очень высоком уровне структуризации исходного кода. При очень высоком уровне переносимости обоих код в отличие от Windows 2000 (практически непереносимой) почти нигде не содержит вставок в платформо-независимом коде вроде #ifdef X86 #ifdef IA64 #ifdef PPC.

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

У меня на знакомых пальцев не хватит. :)

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

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

>Загрузка системы происходит гораздо медленнее теоретического минимума
> (и быстрота в сравнении с загрузкой Windows - не самый большой повод
> для гордости).

Быстрота зависит от многих вещей:
1) от времени загрузки ядра
2) от количества собственно служб
3) от синхронности загрузки служб
4) от времени загрузки X/DM

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

>Повлиять на ход загрузки - невозможно

Букву I жмешь в RH-based дистрибутивах и контролируешь.
Интересно, как же это сделать в неархаичной винде?

>отследить какой модуль завалился (или с какими параметрами
>загрузился) - тоже не всегда реально.

Модуль всегда грузится с теми параметрами, которые прописаны в modprobe.conf, если ты его не вручную пускаешь(ядро - с параметрами из lilo). Отследить какой завалился модуль по определению зачастую невозможно(ни в Win ни в Lin, ни где-либо еще).

> Опять же, для РАБОТАЮЩЕЙ системы админу начхать что она там пишет,
>но прежде чем вы получите эту самую систему, пройдёт не одна неделя с
> напильником.

Как и везде.

>Система устройств /dev/* изжила саму себя, не будучи особо полезной и
> при жизни. Академический подход унификации, как видно, работает
>только там, где применён с умом.

Система устройств /dev/* (и аналогичные \??\ \Devices\ в винде) весьма активно используются, поэтому весьма полезны, неясно, что ты можешь предложить взамен.

По поводу падения модуля: при сборке ядра с frame pointers и отладочной информацией, oops покажет не только в каком модуле упали(eip), но и выплюнет все регистры, содержимое стека, попробует раскрутить stack trace. Если упали не совсем жестко, то можно раскрутить trace и без отладочной информации через ksymoops. Кроме того, есть такие удобные вещи, как network console и netdump, которые в винде доступны только по serial console.

>Графическая подсистема (X Window) тоже имеет устаревшую концепцию
>"глупых терминалов и умного сервера".

Нет, не имеет. X - тонкий клиент(Xlib), толстый сервер(X сервер).

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

Нет, не понятно. :) Более того, это весьма удачная архитектура распределенных приложений. Для локальных приложений это просто красивая и очень переносимая архитектура, хотя не самая производительная (для приложений, требующих производительности, в X есть различные расширения вроде DGA, Xv и др). Кстати, в той же винде, насколько я знаю, по такому принципу до сих пор функционирует csr сервер (который является сервером отрисовки консолей).

> * Совершенно непотребный способ конфигурирования: всякие тайминги
> развёртки, каталоги шрифтов, устройство мышки, мэппинг клавиш... ОНО
> МНЕ НАДО?

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

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

Да необязательно.
В той же Fedora Core есть system-config-display с аплетом а-ля Windows с выбором видео-карты, монитора, параметров вывода на два экрана и тому подобно дребедени. В других дистрибутивах это может выглядеть по-другому, но суть не меняется.

>Безобразная шрифтовая поддержка - как само отсутствие качественных >шрифтов, так и отображение существующих. Последнее время ситуацию >стал спасать модуль использования TTF шрифтов, но опять же ПОЧЕМУ ТО >выглядит эта ТТФня на порядок хуже стандартной виндовой. Кого будем
>бить?

freetype2, поддерживающий truetype и opentype, уже давно существует, а вовсе не "последнее время" и выглядят TT шрифты с antialiasing гораздо приятнее, чем стандартные _квадратные_ шрифты WinXP на моей TFT панели.

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

Что характерно, отсутствуют какие-либо сравнения по существу тех же QT/KDE(kwin) или GTK/GNOME с "пере-менеджерами" в других "неархаичных ОС". По-видимому, поддержка прозрачности, стандартные возможности конфигурирования кнопочек сверху окна, цветовых схем, кучи эффектов(геометрия, keep above, keep below, no border, skip task bar, skip pager, accept focus, closeable, focus stealing prevention, moving/resizing, window type, minimum size, maximum size и др.) на per window class базисе - это все не достоинства, а недостатки... или же автор о них забыл.

>но пользоваться которыми невозможно. Впрочем, последнее
>концептуальное замечание прослеживается во всех программах "под
>Линукс".

Последнее концептуальное замечание применимо и к 99% ПО для Windows.

>Аналогичная ситуация с библиотеками визуальных элементов - хоть GTk и
> Qt и подавили остальные по мощности, усилия продолжают распаляться.

Ну и прекрасно. У QT и GTK достаточно разработчиков. :)

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

У меня в ежедневно обновляемом KDE4/QT4 все нормально. :)
Да и до этого было неплохо.

>Уж не просим принципиально новый "концепт"

Он нахер никому не нужен.

>сделайте хотя бы нормальный дизайн!

Давно уже.

>Поддержка UNICODE ДО СИХ ПОР остаётся больной мозолью. То программа
>его не отображает, то отображает, но не вводит. Конфигурация Linux
>для поддержки UNICODE - это вообще отдельная песня, вплоть до
>перекомпилляции базовых библиотек и всех зависимых программ. И это в
>21 веке, когда компьютеры работают по всему миру...

Fedora Core 3/4. Все из коробки работает с Unicode, проблемы - с приложениями, которые можно пересчитать по пальцам.

В то же время, к примеру, в неархаичной винде попытка вывести в консоли директорию с именами файлов на 3-4 языках приведет лишь к порции вопросов. Кроме того, из-за неудачно выбранной кодировки (UTF-16) вместо UTF-8(которая используется в Linux) поддержка Unicode над legacy протоколами(вроде ftp) в винде попросту отсутствует, в то же время как два UTF-8 линукса прекрасно могут обмениваться по ftp файлами с именами в Unicode(даже не зная об этом).

>Инсталляция системы хоть и стала немного проще (кто-то даже скажет
>"попсóвее"), но она не избавила юзеров от необходимости владеть
>довольно специфическими знаниями железа и системы как таковой.
>Например, swap, HDD controller, partition, code page и т.п. И это
>только начало!

Не совсем верно. Как правило в инсталляторах Linux есть пункт "автоматическое разбиение диска", который сделает и swap и корень и все остальное.

При ручном разбиении:

swap - верно.
HDD controller - никогда не сталкивался, чтобы нужно было это знать.
Хотя, FC3 автоматически распознает мой Tekram 390U4W при инсталляции, а винда его вообще не видит(видимо, надо подсунуть дискету с драйвером или еще что-то :)).
partition и в винде нужно знать.
code page - тут ситуация в той же FC4 и в винде аналогична - нужно выбрать "язык".

>Впереди юзера ждёт ещё кошмар по выбору пакетов - десяток
>недо-клиентов почты, ещё десяток таких же менеджеров окон, пять
>"смотрелок" картинок, десяток интернет-пейджеров

Знаю 3 почтовых клиента - Thunderbird, Evolution, KMail. И все из них гораздо приличнее встроенного в вынь говна под названием Outlook Express. Что касается смотрелок картинок, пейджеров и т.д., то претензия странная. В винде они вообще никакие не устанавливаются, нужно самому изыскивать методом тыка, а если единожды изыскали или посоветовал кто, то в чем тут разница с Linux.. выберете при инсталляции самый лучший.

>и каждый из этих пакетов сопровождается гениальнейшим по лаконичности
> и описательности комментарием: "Лучший оконный менеджер", "Yet
>another client" и т.п. За ними следуют вообще сугубо программистские
>примочки: библиотеки, компиляторы, парсеры, оболочки... И весь этот
>хлам тоже нужно ставить! Потому что даже если вы и не программист, то
> ПЕРЕкомпилировать с десяток пакетов вам всё равно придётся - сборщик
> дистрибутива, видите ли, решил не включать NLS (поддержку
>национального языка).

Мне никогда не приходилось пересобирать приложения для поддержки языков. :) Первый раз слышу о такой проблеме. Да и NLS - это вообще совершенно из другой оперы - ядреная поддержка перекодировок с виндузячих файловых систем.

Кстати, вот чего бы в винде не помешало из GNU/Linux - это поддержки базовым набором приложений разных языков(а-ля KDE i18). А то, насколько мне известно, самое большое - это MUI на тот ничтожный набор приложений, который написан самим MS, и то только для корпоративной версии виндов.

>Так же вызывает нарекания инсталляция "базовой" системы - нет
>практически никакого выбора что и куда должно ставиться. Просто по
>умолчанию разворачивается один большой архив и вы должны в нём
>работать. Даже Windows и та предлагает папочку для инсталляции! :)

Ну и не фиг ли куда и что поставится? Ты ж сам реветь станешь, что анархия и все такое. :)

>Так же хочется раскритиковать те приложения, которыми так хвалятся
>"знатоки" Linux. Во-первых, как уже было отмечено, существует слишком
> много однотипных программ. Разумеется, каждый уважающий себя
>программист написал в своей жизни хотя бы одну графическую
>библиотеку. :) Но зачем же этот детский сад переносить и в Linux?! И
>если не библиотеку, то уж создать собственный e-mail клиент линуксоид
> считает просто своей святой обязанностью! Обращу внимание: УЖЕ
>существует некая программа. Ты пишешь её аналог. Зачем? Видимо,
>существующая слишком плоха. Тогда твоя "лучшая" программа должна
>просто "забить" первую и использоваться всеми линуксоидами! Но этого
>не происходит. Значит она тоже чем-то плоха. Тогда вывод один:
>"аффтар, выпей йаду!", ибо ты вместо помощи существующему проекту
>создал аналогичное убожество (по лени или скудоумию - уже неважно).
>Вот так и возникает в Linux'е "богатство выбора".

Во-первых, каждый имеет право написать e-mail клиент. Если ты считаешь, что это только право великой и могучей Microsoft, то езжай в Бобруйск. Во-вторых, e-mail клиентов сотни и под Linux и под Windows и в точности по одной и той же причине:"если можно, то почему бы и нет". В-третьих, какая на практике разница, сколько приложений под то или то? Важно, IMHO, сколько из них качественно и в полной мере выполняют требуемую функцию. Thunderbird умеет через socks брать почту - молодец, Outlook Express не умеет - в отстойник. Вот и все дела.

>Во-вторых, это уже понятно, даже лучшие в своём классе программы не
>дотягивают по мощности до коммерческих аналогов под другие системы.
>Gimp, Mozilla, Open Office, Glade, MySQL... всё это приятные поделки,
> но не более.

Обычно так. Но в очень многих случаях их функционала достаточно.

>Ещё более меня огорчают возможности Linux в плане программирования. И
> это при том, что создавали эту систему ТЫСЯЧИ программистов по всему
> миру! Библиотек-то и языков под Linux навалом, но вот использовать
>всё это можно либо для небольших "перделок" и не вылезая из vi, либо
>тратя сотни часов на перелопачивание документации, тыканье наобум в
>interface builder'е, тестируя по пять раз две строки кода и потом
>выпускать в свет очередное убожество, которое завалится при первом же
> переполнении буфера. Причин этому множество, опять попробуем
>сформулировать:

Учитесь, молодой человек, и у вас все получится. :)

>Так как Linux долгое время смотрел на мир сквозь убогие терминалы,
>для него не существовало сколь-нибудь удобной среды программирования
>(далее IDE). Vim да Emacs - вот и вся любовь!

Emacs - исключительно мощная среда программирования. Единственно, в нем не встроен gui builder, поэтому можно либо писать gui ручками, либо подключать внешний(qt designer, glade). В остальном недооценка Emacs происходит лишь от неумения работать с ним.

>Это потом уже пришли
>всякие Eclipse, Anjut'ы, Glade и т.п. Но даже они не могли (и не
>могут) сравниться с тем удобством и единой концептуальностью, которые
> предлагает, например, "виндовая" среда Delphi.

KDevelop, Anjuta - среды для начинающих. Минимум возможностей, попугаистость.

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

Дилетантской басней является то, что "чем проще - тем профессиональнее". Нужный инструмент для профессионала - это тот, с которым он качественно выполнит работу за минимальное время, а не тот, с которым чайник ее выполнит за минимальное время. :)

> Дилетантской басней является то, что "чем проще - тем профессиональнее".

Ага, это как если сопливый отморозок с цифромыльницей будет наезжать на профи с крутым Nikon-ом за $25000, что типа его аццтой слишком сложный, и потому непроффесиональный.

>Ещё одной причиной недоразвитости Linux я считаю Си. Сам по себе,
>этот язык неплох (и даёт хорошее понимание ЧТО ты делаешь с железом).
> Но "железная" часть системы - это 5%, остальное - высокоуровневые
>модули, сложные данные, "прикладуха" и т.п. И вот тут-то рождённый
>"летать" оказался хуже уверенно "ползающих": разрабатывать прикладные
> программы на Си было сложно и долго, код содержал кучи ошибок,
>которые выплывают до сих пор.

Опять же. Здесь есть некое непонимание.
Разрабатывать на C программы не сложно и не долго.
Все зависит от сложности, архитектуры, подходов. Можно использовать объектно-ориентированные подходы и в C коде, как это было сделано в GTK. В очень крупных продуктах, естественно, использовать плоский модульный подход не всегда удобно, там используются другие средства, подходы(и принято это далеко не вчера, сам по себе Linux не внес в это какой-либо особенности).

>Пришедший вовремя на подмогу, Си++ несколько оживил ряды
>разработчиков. Но, будучи как и старший брат "языком сам по себе", он
> не намного украсил программистские будни: тот же "низкоуровневый"
>подход, только теперь через "стрелочку" (->). Да и сама идеология ООП
> не могла перевернуть устоявшееся болото Linux - нужна была
>серьёзная, целенаправленная политика по развитию инструментов. Увы, в
> мире opensource такое - редкость. Одним из кандидатов на "высокий
>уровень", я считаю, мог бы быть язык Perl. Большинство криков по
>поводу его "недостатков" раздуто ламерами, не представляющими и 10% >возможностей языка. Будучи некогда "Practical Extraction and Report
>Language", Perl перерос в мощный, высокоуровневый язык. Слово
>"высокоуровневый", в отличии от С++, Perl носит заслуженно: одной
>строкой кода Perl читает данные из файла, разбирает их через
>регулярное выражение, подставляя в него динамически вычисленные
>подстроки и выводит результат на экран. Это я так, для примера. За
>всем этим стоит развитая система обработки списков, хэши,
>инвариантные типы, трудоёмкие операторы и т.п., взявшие на себя роль
>"движка" и дающих "рулить" программисту. Именно отсутствие подобных
>"движков" в С/С++ отворотило от Linux множество разработчиков.

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

>Опять же, плюс сюда безобразная информационная поддержка (примеры
>кода, документация, форумы и т.п.) Если в помойке типа MSDN рано или
>поздно можно что-то найти, то копаться в man'ах - вообще
>бессмысленное занятие. Кому помог писать сетевые приложения man по
>функции socket? Да хоть обчитайся, а пока не увидишь полного примера,
> ничего не напишешь. На форумах тоже сидят в лучшем случае -
>сертифицированные админы, а в целом - такие же программеры-кустари
>как ты сам, что-то когда-то писавшие и знающие предмет скорее из
>интуитивного опыта, чем из серьёзной обучающей процедуры.

MSDN - это и есть набор спецификации API, примеров, статей. В разрозненном виде ты все это можешь найти в Сети и для Linux(google, LDP в помощь). Разрозненность - это недостаток, но если ты умеешь пользоваться поиском, то не слишком большая.

>Система управления пакетами(программами) - это вообще песня! Если
>инсталляторы ещё как-то зажаты рамками требований системы, то уж на
>СУПе разработчики отыгрались сполна! Существует как минимум четыре
>варианта: RPM (от RedHat), DEB (от Debian), MDK (от
>Mandrake/Mandriva) и "просто сорсы" (sources).

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

>Правда, работу с последними существенно облегчает Portage из Gentoo
>(тоже отдельная СУП), но так или иначе весь этот зоопарк существует и
> совсем не обязательно пакет из Fedora будет работать (в абсолютно
>идентичной Linux-среде) Ubuntu.

И что с того? :) Кого это волнует? Ты мечтаешь поставить пакет из Fedora в Ubuntu? :) Ты хочешь об этом поговорить? :)

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

Давно заметил, что виндовозники - фанаты статической сборки. Поэтому любая виндовозная фигулина занимает мегабайты или десятки мегабайт. Обычный виндовозник имеет штук 20 проинсталлированных программ на 5 Гб и не догадывается, что можно иметь 500 на те же 5 Гб, с на порядок большим функционалом. Причем при обновлении(которое в винде нужно для каждого пакета делать индивидуально, поскольку упомянутый СУП там по существу отсутствует) обновление в zlib обновится 20 раз в каждом из виндовозных приложений, генерируя паразитный трафик и затрачивая лишние усилия пользователя.

>Конфигурация системы. Тут прослезится даже бывалый админ, ибо нет
>ничего веселее, чем бегать по /etc и редактировать загадочные
>переменные, попутно подглядывая в HOWTO (о них позже).

Бывалый админ знает, что можно посмотреть:
1) man
2) /usr/share (на предмет примеров)
3) /usr/share/doc (на предмет текстовой документации)
4) на сайте разработчиков
5) в исходном коде! :)

>Причём не факт, что результат будет достигнут - то файл какой
>отсутствует, то скомпилирован не так, а то вообще переменная не
>используется!

Кошмар какой. :) Надо будет с Linux админами поговорить. Неужто все так ужасно... :) Чего ж они все пиффко то пьют... с горя что ли? :)

>Косвенно с этой пересекается тема организации каталогов как таковых:
>/dev, /etc, /var, /usr, /opt, /usr/local... эта свалка запутает кого
>угодно! Конечно, со временем можно закрытыми глазами находить любые
>файлы, но зачем делать сложно, когда можно сделать нормально?

Если это свалка, то как же %systemroot%? Или documents and settings/user? Не впадаете в стресс при виде? :)

Для ясности в структуре директорий можете почитать LSB(столь нелюбимые вами стандарты).

>Документация. Это самое безобразнейшее, что можно было придумать в
>UNIX. Тонны бесполезных man'ов, они подобны букварю: буквы - есть, а
>СМЫСЛА - НЕТ! Плюньте в первого, кто скажет "RTFM" и будете правы. И
>именно ввиду полной бестолковости man'ов и были созданы общеизвестные в
> Linux HOWTO-документы - попытка знающих людей хоть как-то передавать
>"доброе и вечное" остальным бедолагам-линуксоидам. Причём забавно - ни
>один из этих документов не гарантирует достижения результата! Просто У
>АВТОРА руководства стоит ТАКАЯ-ТО система, он поковырял ТАКИЕ-ТО файлы
>и... о, чудо - система заработала! (и совсем не факт, что такой
>алгоритм был предусмотрен разработчиком программы - просто автор HOWTO
>таким образом достиг результата) Безусловно, бедный Linus(мужик, а не
>система!) не виноват в подобной безалаберности, но в его силах было
>изменить существующий подход к документации. /впрочем, я не уверен на
>счёт сил - вы вообще видели программистов, которые пишут help'ы? :) /

Никогда в жизни не читал HOWTO. :)
Источник знаний(частично повторю вышесказанное):
1) man
2) /usr/share
3) /usr/share/doc
4) info (особенно libc)
5) LDP, google, сайт разработчиков
6) исходный код
7) бумажные книги
8) LOR :)

P.S. Интересно, автор мне ответит хотя бы за то, что я потратил вечер на комментирование его бредней? :)

> P.S. Интересно, автор мне ответит хотя бы за то, что я потратил вечер на комментирование его бредней? :)

Ты ему каменты на мыло отправь. А его ответ тут публикани.

> Ты ему каменты на мыло отправь. А его ответ тут публикани.

я ему уже отправлял, он даже ответил, но на последующие письма решил не отвечать

А что ответил? В студию!

показывать личную переписку неприлично

ответил он такую же чушь как и в своей статье

Значит он больной мудак, и не фиг с ним мелочиться, за человека его считать. Раз уж он животное, то и не фиг - давай сюда мессагу.

JB:

Он ответил, что считает ниже своего достоинства отвечать личностям, не доросшим до Delphi и PERL? Как жаль... Хотя у меня есть смутная надежда, что он все-таки прочитает часть моих комментариев, поставит Linux и убедится, что все там далеко не так, как ему приснилось. :)

> Он ответил, что считает ниже своего достоинства отвечать личностям, не доросшим до Delphi и PERL?

нет, он ответил на каждый мой комментарий к его статье

выложу основные перлы из его письма

"Скажем, воткнули вы НОВУЮ магнитооптику в сервер (который не обновлялся сто лет). Драйвера, разумеется, там нет. [skip] С Линукс - скачать целое ядро, перекомпилировать, установить в /boot, ПЕРЕЗАГРУЗИТЬСЯ, и только потом появится девайс."

"А вот возьмите и напишите, например, модуль типа IP tables, но не заглядывая в его исходники."

"Не говоря уже про то, что конфигурировать систему через vi - всё равно что писать программы в hexedit."

"Кстати, тоже практики ради, действительно перенесите иксы в какой-нибудь /var/X и посмотрите сколько усилий понадобится, чтобы они снова заработали"

>>"Скажем, воткнули вы НОВУЮ магнитооптику в сервер (который не обновлялся сто лет). Драйвера, разумеется, там нет. [skip] С Линукс - скачать целое ядро, перекомпилировать, установить в /boot, ПЕРЕЗАГРУЗИТЬСЯ, и только потом появится девайс."

Обновить NT4, те скачать херову тучу мегов с патчами и драйвер на устр-во, а если оно новое, то не факт что на него есть вообще драйвера под NT

>>"А вот возьмите и напишите, например, модуль типа IP tables, но не заглядывая в его исходники."

на хера козе баян

>>"Не говоря уже про то, что конфигурировать систему через vi - всё равно что писать программы в hexedit."

в том серверном дистре от mandriva полно графики для этих целей, если он это имел это в виду

>>"Кстати, тоже практики ради, действительно перенесите иксы в какой-нибудь /var/X и посмотрите сколько усилий понадобится, чтобы они снова заработали"

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

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

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

Зачем в Perl были интегрированы конструкции, которые можно реализовать за счет runtime lib? Почему в Perl при добавлении к массиву нового элемента не надо заботится о выделении памяти? Для удобства. Удобство позволяет писать программы быстро и без тьмы кода не относящегося к логике программы, который зачастую содержит ошибки (выделение памяти). Компьютер должен работать, человек --- думать (с). Определение всего как функций библиотек --- идиология идеализма.

>Язык без идеологии

Основная идея идеология Perl --- есть больше чем один путь, чтобы что-то сделать. Идиология свободы. Делай как нравится. На Perl можно полностью эмулировать C с синтаксической точки зрения (т.е. программа будет выглядеть точно также). Можно вынести встоенные операторы и типы в отдельные библиотеки, можно использовать strict чтобы следить за инициализацией переменных, а можно так и не делать.

Как не странно возможность выбора не приводит к столпотворению. При разработке на Perl действительно используется ранее написанный код (CPAN). В правильном (скорее ограниченном C) такого не наблюдается.

>Да, PERL - это просто спасение... куда уж тут ООП. Perl и ООП совместимы. Пример --- тот-же CPAN, большинство модулей имеют ООП интерфейс. Да и главное в идеологии Perl ---

Perl is different. In a nutshell, Perl is designed to make the easy jobs easy, without making the hard jobs impossible. (c) Larry Wall.

>Почему в Perl при добавлении к массиву нового элемента не надо
>заботится о выделении памяти? Для удобства.

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

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

Это все верно, но не имеет отношения к PERL.

>Основная идея идеология Perl --- есть больше чем один путь, чтобы
>что-то сделать. Идиология свободы. Делай как нравится. На Perl можно
>полностью эмулировать C с синтаксической точки зрения (т.е. программа
>будет выглядеть точно также). Можно вынести встоенные операторы и типы
>в отдельные библиотеки, можно использовать strict чтобы следить за
>инициализацией переменных, а можно так и не делать.

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

>При разработке на Perl действительно используется ранее написанный
>код (CPAN).

Во всех языках есть средства повторного использования кода.

>В правильном (скорее ограниченном C) такого не наблюдается.

Неужели? А что же у тебя лежит в /lib и /usr/lib?

>Perl is different. In a nutshell, Perl is designed to make the easy
>jobs easy, without making the hard jobs impossible. (c) Larry Wall.

"Слова, слова, слова..." (c) Шекспир

> Основная идея идеология Perl --- есть больше чем один путь, чтобы что-то сделать. Идиология свободы. Делай как нравится.

И сравнивать эту пианерскую поделку с Лиспом, где у тебя на самом деле есть настоящая, полная свобода - просто нелепо. Отвратительно!

>И сравнивать эту пианерскую поделку с Лиспом, где у тебя на самом деле есть настоящая, полная свобода - просто нелепо. Отвратительно!

Есть одна проблема. Небольшая. На крутом лиспе почти никто не пишет. Самая известная широкой общественности сфера применения Lisp --- Emacs.

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

>Это не идеология свободы - это засраность статическими языковыми конструкциями. Правильный язык должен представлять минимальный(но гибкий, масштабируемый) набор конструкций для построения нужной архитектуры. В PERL нет идеологии, в нем нельзя построить нечто фундаментальное, это просто пустой набор конструкций, которые в определенных ситуациях могут несколько сократить код, как статический набор примитивных макросов.

Я ж говорю идеалист :) Особенно смешно следующее:

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

Машину Тьюринга в университете изучали? Вот где истинное изящество и минимализм ;) А между прочим на ней можно реализовать любой алгоритм.

Прикладное программирование --- инженерная задача, а не математическая абстракция.

> Машину Тьюринга в университете изучали? Вот где истинное изящество и минимализм ;) А между прочим на ней можно реализовать любой алгоритм.

Деточка, ты очень тупой, да?

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

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

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

> Есть одна проблема. Небольшая. На крутом лиспе почти никто не пишет.

Дык. Больше всего на VB пишут. Наверное, потому, что он крутой, да, урод?

> Прикладных библиотек из-за маленького коммунити мало.

Пососи, отморозок. Полно библиотек. И community пусть и не такое, как у выжуалвасика, но зато качественное - быдла в этом community нет, только крутые специалисты. Не чета тебе, выродку.

>Есть одна проблема. Небольшая. На крутом лиспе почти никто не пишет.
>Самая известная широкой общественности сфера применения Lisp --- Emacs.

На LISP написана по крайней мере MAXIMA. А есть ли что-то достойное, написанное на PERL?

>Машину Тьюринга в университете изучали? Вот где истинное изящество и
>минимализм ;) А между прочим на ней можно реализовать любой алгоритм.

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

Фактически "гибкость" PERL - это именно что статические макросы, которые можно разобрать собственным тривиальным препроцессором в тот же C.

>А есть ли что-то _достойное_, написанное на PERL

Первое что приходит в голову --- slashdot.org. MAXIMA --- ну очень узкая сфера применения. У CGI программирования она всяко побольше будет.

Или вот

grep -R '#!/usr/bin/perl' /usr/sbin | wc -l

38

вполне сопоставимо с

grep -R '#!/bin/sh' /usr/sbin | wc -l

56

У системного программирования тоже довольно широкая сфера применения.

>Фактически "гибкость" PERL - это именно что статические макросы, которые можно разобрать собственным тривиальным препроцессором в тот же C.

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

1) ($a,$b) = ($b,$a);

2) $a = "var"; $$a = "Hello world \n"; print "$var"; $b = "Hello world \n"; $var = \$b; print $$var;

3) @a = @b;

4) open(FL,"somefile.pl"); @code = <FL>; foreach (@code) { $str=$str.$_; } $str =~ s/old/new/; eval($code) or die "Critical exception!";

Еще раз повторю идеальных языков не бывает. К одним задачам лудше подходят одни языки, к другим --- другие. Языки которые пытаются уметь все подряд (c/c++) крайне неудобны в специализированных областях (мало кому приходит в голову писать веб-порталы на c).

PS perlcc --- вовсе не элементарный предпроцессор. И крайне неэффективный.

И почему-то нафик никому не нужный.

PPS

Совсем забавно то, что компилятор и линковщик превращает C в ассемблер.

Причем сравнительно быстро и эффективно.

>Фактически "гибкость" PERL - это именно что статические макросы, которые можно разобрать собственным тривиальным препроцессором в тот же C.

Фактически "гибкость" C - это именно что статические макросы, которые можно разобрать собственным тривиальным препроцессором в тот же ASM.

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

Содержательно, а главно доказательно. За базар отвечать надо, сам не поймешь, другие научат. Ногами.

>Пососи, отморозок. Полно библиотек. И community пусть и не такое, как у выжуалвасика, но зато качественное - быдла в этом community нет, только крутые специалисты. Не чета тебе, выродку.

Чей то я гляжу комунити у Lisp довольно маргинальное.

Если все специалисты там такие как ты и товарищ луговской, то у меня херовое мнение о таком сброде.