Здравствуйте!
Пишет Вам spinore, более известный в юникс-кругах как "spinore с linux.org.ru" или просто Олег Пилявец. Сейчас я аспирант ФИАН, закончил небезызвестный Физтех.
Я ещё давно Вам хотел написать, но всё не доходили как-то руки.
Два года назад решил освоить по-хорошему операционную систему. У моего знакомого, жившего в общежитии со мной в комнате, одно время на старом компе стояла FreeBSD 4-й ветки, что, так сказать, и запало в душу мне и ещё одному нашему соседу (впоследствии тот поставил FreeBSD и до сих пор она у него является десктопной системой). В итоге в качестве целевой системы для изучения была выбрана именно FreeBSD. К этому моенту я практически ничего не умел делать в *nix'ах и пользовался Windows 2000. К счастью, мне попалась Ваша книга "FreeBSD: установка, настройка, использование",
которая и была тщательно прочитана в течении свободного времени за несколько месяцев
Я выражаю вас искренню благодарность за Ваш труд, что Вы привнесли в мир open source, и много поспособствовали для адаптации новичков в мире UNIX/Linux. Благодаря вашей книге я и сам благополучно перешёл сразу с Windows на FreeBSD, и даже, можно сказать, OpenBSD (хотя мне помогали несколько).
которая и была тщательно прочитана в течении свободного времени за несколько месяцев
Я выражаю вас искренню благодарность за Ваш труд, что Вы привнесли в мир open source, и много поспособствовали для адаптации новичков в мире UNIX/Linux. Благодаря вашей книге я и сам благополучно перешёл сразу с Windows на FreeBSD, и даже, можно сказать, OpenBSD (хотя мне помогали несколько).На самом деле развитие шло приблизительно так: я благополучно поставил себе FreeBSD 5.2.1 (на тот момент самую новую версию), но возникли проблемы с видеокартой, благодаря чему иксы могли идти только в VGA-режиме. Поразбиравшись с xf86config вместе с напарником мы решили попробовать поставить OpenBSD. В итоге я сразу получил нормально работающие иксы в OpenBSD и, де-факто, "перешёл с windows сразу на OpenBSD" (квалификации после прочтения Вашей вышеупомянутой книги для этого хватило, ещё раз Вам спасибо).
Просидев пол года на OpenBSD я пользовался тем, что рекомендовал сосед (на тот момент - аськой, kde и т.п.). Нормальных "user-friendly" клиентов icq типа licq или sim под OpenBSD тогда не было, и мы пытались их с соседом "портировать", что не получилось (сейчас есть предположение, что этого не получилось из-за слишком староой версии gcc, которрая на тот момент в OpenBSD была умолчальной). Промучавшись с очень неудобной интерфейсной аськой (про джаббер я тогда не знал) я вконец опечалился (к тому времени уже пол года использовал OpenBSD и у меня даже был работающий матлаб 6.5) и снова вернулся на FreeBSD, для которой теперь уже была новая версия - 5.3 - она без проблем устанавливалась, и иксы с моей видеокартой работали корректно. После, используя FreeBSD 5.3 в течении полутора лет я постепенно ушел от user-frienfy-программ в сторону консольных приложений (предпочитая true консольные приложения даже интерфейсу на curces) и легковесных менеджеров. Параллельно я начал осозновать, что мне будет одинаково комфортно теперь в любой юникс-системе и решил начать использовать что-то более "профессиональное" и как бы "лучшее" (более надёжное). Изначально тогда я хотел вернуться на OpenBSD, но меня сразил некий интерес к неизведанному и загадочному, а также система cgd в NetBSD. В итоге ныне я уже около двух месяцев использую NetBSD 3.0., хотя изначально ставил эту систему только для того, чтобы посмотреть. В целом меня NetBSD устраивает на данный момент, но, когда-нибудь, возможно, всё же я вернусь на OpenBSD
(Соответствующие заметки того времени были оставлены здесь: http://www.linux.org.ru/profile/spinore/vi...p?msgid=1376281 О некоторых проблемах и их решении я ещё писал здесь:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1382354). Cерьёзного cмысла перехода на Linux на десктопе, окромя как любопытства, пока не вижу. Среди тех дистрибутивов, которые видел со стороны, больше всего нравится Gentoo (что-то наподобие bsd-like Linux), благо интернет траффик у меня бесплатный уже 3 года.
(Соответствующие заметки того времени были оставлены здесь: http://www.linux.org.ru/profile/spinore/vi...p?msgid=1376281 О некоторых проблемах и их решении я ещё писал здесь:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1382354). Cерьёзного cмысла перехода на Linux на десктопе, окромя как любопытства, пока не вижу. Среди тех дистрибутивов, которые видел со стороны, больше всего нравится Gentoo (что-то наподобие bsd-like Linux), благо интернет траффик у меня бесплатный уже 3 года.
Пройдя указанный путь от обычного пользователя до BSD-юзера, хотел бы поделиться с Вами некоторыми замечаниями по поводу указанной книги и вообще идеологии (надеюсь, Вам это будет интересно).
В книге было хорошо сказано про преимущества оконных менеджеров по сравнению с интегрированными графическими средами стиля kde, gnome и xfce. Очень понравился blackbox. Долго время его использовал (с тех времён даже скриншот остался: http://www.linux.org.ru/profile/spinore/vi...p?msgid=1283695). В рамках описания blackbox, по моему мению, Вам следовало бы сказать, что не следует загромождать десктоп таками искусственными программами как bbrun. Всё что нужно, пользователь запускать должен с хоткейсов, которые прописаны в ~/.bbkeysrc (его новейшая версия поддерживает даже keychain'ы, что очень удобно, и чего нет в fluxbox (хотя можно использовать bbkeys и c fluxbox)). В случае же потребности запустить что-то особенное, всегда можно открыть терминал и написать "nohup нечто &". Такие впечатления остались у меня от примерно годовой работы в blackbox.
Позже я случано встретил фразу стиля "настоящие хакеры используют ... OpenBSD, BadWM, ratpoison, ion...". Ради интереса я поставил себе ratpoison чтобы посмотреть на него, а вышло так, что и по сей день им пользуюсьм. Возвращаясь иногда к blackbox я чувствую как мне становится крайне неудобно. Дело же здесь вот в чём. kde является "реконструкцией" windows-подобного интерфейса. Blackbox же, всвою лчередь, не так далеко ушёл от этого самого интерфейса, если его рассмотреть очень внимательно. Кто нам сказал, что "все приложения должны иметь отдельные окна, которые могут перкрываться, у каждого окна должна быть декорация из 3-х квадратиков, щёлкая мышкой на которым можно что-то делать"(?). И уж тем более, кто сказал, что это "самая правильная идеология организации интерфейса, и самая удобная"? (К слову сказать, именно под такую идеологию создавались великие и могучие иксы). Неоптимальность оконного интерфейса прявляется при возрастанрии числа окон (когда их число начинает превышать 10-15). Я придумывал разные ухищрения, как побороть эту неоптимальность. Поясню более конкретно, о чём идёт речь.
Итак, будем реалистичными. У меня запущено 13 разных окон одновременно (консольный curces-based icq-клиент и jabber через centericq (2 окна), vim (1 окно), links (1 окно), opera (1 окно)), обычный терминал для выполнения команд (1 окно), рутовый терминал (1 окно), терминал с запущенным в нём MatLab'ом (1 окно) а также ещё несколько терминалов, в которых происходит редактирование в vim'е чего-нибудь, или браузеры типа firefox. Для удобной работы нужно иметь открытыми сразу все указанные приложения, чтобы в случае чего (а это нужно делать часто) время тратилось только на переключение между окнами а не на открытие приложений. Итак, мне приходится постоянно и часто переключаться между указанными окнами. Если бы использовался только один рабочий стол, я бы устал по 10 раз нажимать Alt-Tab и Alt-Shift-Tab (например) в blackbox. Естественным кажется желание упростить переключение: разбить эти окна на классы - сиречь "рабочие столы". Это всё так, но метод "раскидывания окон по столам" приводит только к кажущемуся решению проблемы. Почему? - Потому, что в нагрузку к хоткеям переключения между окнами добавляются хоткеи для переключения между столами. А на каком столе у нас что находится? Нужно помнить? Да. А можно воспользоваться пейджером - загрмоздить часть стола маленькими скриншотиками всех существущих столов (представляю снизу мысленно 13 микроскриншотов, на котрые я смотрю в надежде понять что же и где у меня открыто). Сам я никогда пейджерами не пользовался, а делал по-другому: на каждый рабочий стол помещал только одно окно, в итоге у меня обычно использовался только хоткей на переключение рабочего стола для того, чтобы сделать активным некоторое приложение. А куда переключаться? Чтобы не мучиться с этим, я старался располагать каждое приложение каждый раз на одном и том же, своём, уникальном столе. Однако, это не работало очень гладко, так как приложений много, и рано или поздно часть из них всё равно начинает находиться неизвестно где. А потому приходится периодически вызывать из меню список всех окон и просматривать все рабочие столы со всеми окнами на них (очень времязатратная операция). Учту (упомяну) ещё 2 очень важных момента в работе с так организованными системами: a) фокус может располагаться на самом root-image на активном рабочем столе, то есть не принадлежать ни какому, отрытому на нём, окну - это создаёт потребность даже при использовании системы "на каждый стол по одному окну" использовать лишние хоткеи для перемещения фокуса на это "одно-единственное" окно; б) есть переключение фокусов в одну сторону (например, альт-таб) и в другую сторону (альт-шифт-таб): предположим, что в итоге у нас на рабочем столе образовалось в какой-то момент 4-5 открытых окон и требуется переключиться не на последнее, бывшее активным, окно; как следствие, мы не знаем какую их комбинаций (альт-таб или альт-шифт-таб) использовать. Это приводит к тому, что вместо одного-двух применеий данного хоткея я должен нажимать его много раз, если начну переключать окна в не правильном порядке (не угадал если ). Все эти проблемы заставляют меня обвинить данный интерфейс и назвать его неоптимальным и неудобным, равно как и все менеджеры, его использующие и пропогандирующие (про необходимость тянуться к мышке для ресайза окна или переключения на другое окно я уже даже не упоминаю, хотя в blackbox можно обойтись и без этого). Идею рабочих столов и пейджеров я теперь считаю "костылями", которые люди вынуждены приделывать к оконному менеджеру, использующему не правильный дизайн интерфейса.
). Все эти проблемы заставляют меня обвинить данный интерфейс и назвать его неоптимальным и неудобным, равно как и все менеджеры, его использующие и пропогандирующие (про необходимость тянуться к мышке для ресайза окна или переключения на другое окно я уже даже не упоминаю, хотя в blackbox можно обойтись и без этого). Идею рабочих столов и пейджеров я теперь считаю "костылями", которые люди вынуждены приделывать к оконному менеджеру, использующему не правильный дизайн интерфейса.Теперь о том, как легко и свободно решаются все указанные проблемы в frame-ориентированных менеджерах (рассмотрю для примера ratpoison). Рабочих столов здесь нет в обычном понимании этого слова. Переключаться между фреймами и окнами можно только с помощью хоткеев (я использую keychain'ы, благо ratpoison это позволяет). Сначала я задал геометрию фреймов: разбил окно на непересекающиеся прямоугольники - фреймы. По душе мне пришлось всего 2 геометрии фреймов: 1) на full-screen открыт один frame, и 2) экран бьётся вертикально на 2 части - образуется 2 фрейма, причём фрейм справа делается в меру узким, и окна в нём гасятся - на нём виден только кусок root-image. На фрейме справа запускается какя-нибудь программа в стиле torsmo или conky (можно использовать ещё root-tail и osd_cat). Можно включить раличные системные мониторы по желанию пользователя, а можно и не включать. Основное - это вывод на root-image списка всех открытых окон с их названиями (урезанными) и номерами (для этого я и освободил справа место и сделал root-image видимым). Скриншот того, как это выглядит, прилагается в ссылках:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1424357
Это - лучшее, что я сделал за все 2 года (лучший скрин по моему мнению):
http://slil.ru/22878768
Почти современный конфиг для ratpoison приведён здесь:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1465937
Если я пользуюсь 2-й геометрией фреймов - у меня всегда активен левый фрейм и окна появляются только в нём при их активации в ratpoison. Если я пользуюсь 1-й геометрией фреймов - fullscreen, то все окна всегда полностью максимизированы. Мне не нужно поочерёдно переключаться между активациями окон в текущем фрейме для получения нужного мне окна: посмотрев в список справа на номер окна я набираю, например, альт-8 и я уже на 8-м окне(!). Конечно, забирая все лучшие наработки с blackbox, я и здесь теперь стараюсь держать номера окон различных приложений уникальными (для этого достаточно запускать после логина приложения в нужном порядке или назначать вручную номер вновь открывшемуся окну, что делается легко с клавиатуры средставми ratpoison). Также, мне не нужно помнить теперь что выбирать: "аль-таб" или "альт-шифт-таб" для переключения на какое-то окно с с номером, далёким от номера текущего (активного в данном фрейме) окна: один взгляд на список... и это становится сразу ясным. Также, ratpoison позволяет легко ресайзить фреймы, пользуясь только хоткейсами. Таким образом, я получаю нужную мне масштабируемость при возрастании числа открытых окон: порописав верхний ряд клавиш (1,2,...=,\) для переключения окон (активации соответствующих окон по их номерам) я, нажимая только 2 клавиши (аль+нужная_клавиша_с_верхнего_ряда), получаю моментальный доступ к любому из 13(!) окон. В крайнем случае, я могу воспользоваться и обращением к окнам по встроенным хоткеям ratpoison или обращением к окнам по первым именам заголовков (что также встроено в ratpoison). Пользуясь систематически ratpoison'ом, и установкой окнам нужных номеров после их старта можно, в действительности, заглядывать в список всех открытых приложений справа очень редко. Подчеркну, что список я делаю собственными руками, заставляя стороннюю программу (например, torsmo, периодически обращаться к ratpoison и запрашивать это список (в действительности, это вывод команды ratpoison -c windows)).
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1424357
Это - лучшее, что я сделал за все 2 года (лучший скрин по моему мнению):
http://slil.ru/22878768
Почти современный конфиг для ratpoison приведён здесь:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1465937
Если я пользуюсь 2-й геометрией фреймов - у меня всегда активен левый фрейм и окна появляются только в нём при их активации в ratpoison. Если я пользуюсь 1-й геометрией фреймов - fullscreen, то все окна всегда полностью максимизированы. Мне не нужно поочерёдно переключаться между активациями окон в текущем фрейме для получения нужного мне окна: посмотрев в список справа на номер окна я набираю, например, альт-8 и я уже на 8-м окне(!). Конечно, забирая все лучшие наработки с blackbox, я и здесь теперь стараюсь держать номера окон различных приложений уникальными (для этого достаточно запускать после логина приложения в нужном порядке или назначать вручную номер вновь открывшемуся окну, что делается легко с клавиатуры средставми ratpoison). Также, мне не нужно помнить теперь что выбирать: "аль-таб" или "альт-шифт-таб" для переключения на какое-то окно с с номером, далёким от номера текущего (активного в данном фрейме) окна: один взгляд на список... и это становится сразу ясным. Также, ratpoison позволяет легко ресайзить фреймы, пользуясь только хоткейсами. Таким образом, я получаю нужную мне масштабируемость при возрастании числа открытых окон: порописав верхний ряд клавиш (1,2,...=,\) для переключения окон (активации соответствующих окон по их номерам) я, нажимая только 2 клавиши (аль+нужная_клавиша_с_верхнего_ряда), получаю моментальный доступ к любому из 13(!) окон. В крайнем случае, я могу воспользоваться и обращением к окнам по встроенным хоткеям ratpoison или обращением к окнам по первым именам заголовков (что также встроено в ratpoison). Пользуясь систематически ratpoison'ом, и установкой окнам нужных номеров после их старта можно, в действительности, заглядывать в список всех открытых приложений справа очень редко. Подчеркну, что список я делаю собственными руками, заставляя стороннюю программу (например, torsmo, периодически обращаться к ratpoison и запрашивать это список (в действительности, это вывод команды ratpoison -c windows)).
Ответ на возможные трудности работы с ratpoison:
1) "У меня есть список окон, которые я хочу видеть объединенными. А также, чтобы геометрия фреймов при обращении к любому окну из данного списка самовосстанавливалась, показывая в каждом фрейме определённое окно. При попытке же активации окна из некоторого другого списка восстанавливалась бы, аналогично, связанная с ним его система фреймов и активированных в них окон". Ответ: a) для большинства возможных работ в каждый момент времени достаточно иметь активным только одно окно, и почти на full-screen (судя по собственному опыту). Необходимость в привязке системы фреймов к активным на данный момент приложениям возникает только, когда нужно постоянно (фактически, ежесекундно) смотреть в оба окна одновременно. Такое бывает. B) для реализации данной возможности можно директивно менять геометрию, потом активный фрейм, и хатем активировать в нём нужное окно (аналогично, для остальных фреймов). Изменение геометрии имеющихся фреймов "налету" можно привязать опять же к хоткеям (у меня сделано именно так). Должен признать, что в ratpoison первична именно геометрия фреймов, а не сами окна, котрые в этих фреймах активируются. Можно спорить с данной идеологией. По моему мнению, она более подходит для одних задач и не очень для других. При прочих равных мне не кажется этот вопрос очень принципиальным. К слову сказать, появился в данный момент скрипт, позволяющий делать привязку геометрии фреймов к приложениям более явно в ratpoison, но он написан на bash и работает медленно, в связи с чем я его не использую.
2) "Почему у окон в ratpoison нет декораций"? Ответ: они нужны, если у меня есть список окон с номерами и их заголовками, всегда висящий справа (если только не используется full-screen-геометрия фреймов). Хочу также заметить, что при прочих равных восприятие приложения лучше, если оно занимает весь экран, а не его маленький клочок. Жертвовать размером окна имеет смысл, только если действительно нужно одновременно видеть несколько окон на одном и том же экране - только в этом случае разбитие экрана на большое число фреймов оказывается оправданным.
3) "Почему нет поддержки мыши"? Ответ: поддержка мыши отсутствует, чтобы не поощрять пользователя пользоваться неудобными инструментами для решения задач при работе с ratpoison. Мышь должна использоваться в тех приложениях и только тех, где она жизненно необходима. Идея в минимализме: "если я могу спокойно управлять системой с клавиатуры, то зачем мне "пятая нога" в виде дополнительной убогой поддержки управления с помощью неудобных и неэффективных инструментов? Это оправдано для новичков, обживающихся в мире юникса, но не оправдано для людей, разбирающихся в приложениях, и уже успевших не по одному разу прочитать документацию на тот же ratpoison от начала и до конца".
О других фрейм-ориентированных менеджерах: самым популярным, пожалуй, является из них ion. Лично меня, как стремящемуся к оптимуму между минимализмом и функциональностью, оттолкнула поддержка мыши, жёстко добавленная в ion и наличие декорации окон по умолчанию. Я не считаю это хорошим признаком. Хотя в целом, по рассказам, ion предоставляет большую гибкость и возможности, чем ratpoison. К тому же, лично мне для моих целей в данный момент хватает ratpoison (использование интернета, просмотр аудио-, видео- и графических файлов, работа в vim с TeX-файлами, программирование в matlab и т. п.) Также, меня можно спросить про удобство работы с gimp в ratpoison, на что я могу ответить двояко: 1) при необходимости иногда пользоваться gimp'ом можно столь же иногда запускать тот же blackbox; 2) никто не мешает изучить другие фрейм-ориентированные оконные менеджеры наподобие иона, которые уже позволяют удобно работать с gimp'ом: я не преследовал пропаганду ratpoison как такового, я только указал на ряд существенных недостатков в интерфейсе не фрейм-ориентированных менеджеров (конечно, приведённую систему управления можно реализовать на любом продвинутом оконном менеджере и повесить список где-либо на экране список окон, а также настроить нужные хоткейсы... но возникает вопрос: "зачем тогда нужна эта 'толстость' оконного менеджера и обилие других возможностей, которые не будут никогда использоваться"?).
Закончив рассмотрение оконных менеджеров, расскажу о других впечатлениях.
Счиатю очень удачным то, что Вы порекомендовали использовать возможнсти командной строки вместо оболочек-визуализаторов напободие mc. Прошло 2 года моего пребывания в юникс-системах, и я не пользовался mc никогда для своих нужд, причём считаю это идеологически правильным. Также, использование kde, blackbox и т. п. "мышовых" интерфейсных программ хорошо для первого освоения но не для постоянного использования.
Меня очень порадовал акцент в сторону использования zsh, а не bash. Наше общество пока не знает о zsh и живёт вчерашним днём, извиняюсь за грубость (я не вижу никаких премуществ bash перед zsh на данный момент окромя большей распространённости первого).
К слову о редакторах: для человека, разобравшегося с vim'ом (emacs'ом) никакие другие редактры не нужны (nedit, kwrite, gedit и т. п.). Возможно, Вам бы следовало бы столь же явно, как для mc и kde подчеркнуть, что использование альтернативных vim'у и emacs'у редакторов может быть обосновано только большими трудозатратами быстрого изучения первых.
Для конечного пользователя не последнюю роль играет возможность шифрования информации, работа с gpg, openssl, а также работа к ключами и сертификатами в различных приложениях (например, в почтовой программе и джаббере). Почему-то считается правилом хорошего тона ничего не упоминать о таких возможностях в стандартных книгах по юниксу. У меня на полке лежит 3 книги по FreeBSD и ни в одной из этих книг ничего не сказано о шифровании дисков. Возможно, этому следовало бы уделить некоторое внимание.
Общепризнанно лучшей почтовой программой признан mutt (смотрим официальную документацию на Gentoo Linux или NetBSD). В книгах не любят, тем не менее, описывать тонкости работы fetchmail/procmail/msmtp/mutt и, думаю, очень даже зря: ведь почтой пользуются все. Жалко, что во всех известных мне книгах нет нормальной документации по указанным программам за исключением слов "это выходит за рамки данной книги".
Есть такая полезная программа - screen, и многие пользователи уже сейчас не представляют себе работу без использования этой программы. ratpoison написан по мотивам именно screen. Однако, о существовании таких хороших программ можно узнать только случайно с некоторых форумов. То же самое следует сказать и о программах tor+privoxy.
Существут браузеры наподобие w3m с чудесными возможностями: истиная графика в исках в консоли! Но о таких программах также можно узнать только случайно. Хорошо было бы упомянуть о w3m в Вашей книге.
С удовольствием я читал Ваши заметки и по другим BSD-системам. У меня возникал вопрос: почему до сих пор все отмалчиваются, и никто из профессионалов не решится взять и написать разгромную статью по сравнению хотя бы Linux/Solaris/FreeBSD/OpenBSD/NetBSD? Это никому не выгодно, может быть, ибо покажет пользователям массу слабых сторон и кучу костылей и ошибок в дизайне этих систем (а это есть!)?
Обычно не описывают никогда процедуру make world со списокм всех возможных нюансов и неожиданных аварийных ситуаций в книгах по BSD 
На данный момент, насколько мне известно, нет других гибких способов устранить ошибки в базовой системе.
На данный момент, насколько мне известно, нет других гибких способов устранить ошибки в базовой системе.Принято не писать о плохих сторонах BSD и Linux. Может быть, где-то официально нужно написать о кривости portupgrade? И это система, рекомендуемая самими разработчиками для управления системой портов. Gentoo Linux команда - молодцы - они сделали хорошую систему работы с портами, опираясь на ошибки предшественников.
Удобно использовать centericq и mpd+mpc для работы, соответственно, с джаббером и аськой. Я могу запустить centericq в бэкграунде, после чего давая определённые команды в любом(!) терминале принимать и отправлять сообщения. Аналогично, работа протекает и с музыкой. Также, активно используются хоткейсы для работы с mpd+mpc под иксами. Это хорошая идея, почему же тогда на каждом углу пропогандируют именно xmms? centericq и mpd работают по клиент-серверному механизму, что является очень удобным. Даже зайдя по ssh через некоторое время на свою домашнюю машину удалённо я могу продолжать как ни в чём не бывало управлять музыкой и джаббером (icq). Хотел бы очень услышать Ваше мнение на этот счёт. Я привёл в качестве системы управления музыкой mpd (music player daemon), так как мне не известны другие программы с клиент-серверной реализацией, работающие с музыкой. Также, centericq я привёл, так как это, насколько мне известно, единственная консольная программа, которая после некоторой доводки начинает работать в клиент-серверном режиме и при этом поддерживает шифрование на осонове персональных ключей (gpg).
Мне кажется, что следует упомянуть, что при прочих равных лучше отказаться от использования samba вообще в пользу других систем, ибо это очень не безопасно.
Насколько я понимаю, любой пользователь вскоре после установки BSD сталкивается со следующими проблемами:
1) Нужно обновить базовую систему (не до current, а только исправить ошибки в stable-ветке), но это не просто. В книгах об этом писать не принято.
2) Лучшие программы в своём роде и общая идеология (о многих программх, которые я использую я узнал чисто случано).
3) Как нормально работать с системой портов (упомяну, что fluxspace тянет за собой php и apache во FreeBSD согласно дефолтным флагам зависимостей). Как просмотреть список всех возможных опций для данного порта? Если я подключу или выключу те или иные опции в порте, то каков будет список всех зависимостей, раскрученных рекурсивно от устанавливаемого порта? И на забываем, что это не emerge. Можно писать свои скрипты, можно руками ходить по дереву портов и смотреть... Но как по уму? Именно как предполагалось разработчиками интересно было бы знать.
Обычно в книгах не упоминается об объёме проблем и ошибок того или иного ПО (операционной системы). А ведь можно было бы очень подробно описать с чем обычно приходится сталкиваться в реальной жизни и как это исправляется (это было бы антирекламой всего open-source и я бы мог по этому поводу написать ещё одно такое "письмо", подробно описывая всё, начиная от coredump'ов иксов и мёртвого зависания системы из-за софтварных ошибок, и кончая вечными падениями оконных менеджеров - всё что было за последние 2 года в моей практике, вплоть до ссылок на багрепорты).
Теперь напишу о грустном. К сожалению, консольные программы, хоть и консольные, потребляют зачастую огромную долю ресурсов, сколько не потребляют даже графические user-friendly-программы. Cвязано это, если не кривить душой, с тем, что многие программы, портированные в BSD- и Linux-системы, пишутся обычными энтузиастами, являющимися низкоквалифицированными программистами. В действительности, человек только думает, что знание одного синтаксиса языка си делает его квалифицированным программистом, способным написать что-то очень хорошее. Рассмотрим пресловутую centericq. На слабых компьютерах (в данный момент у меня, например, 233МГц) видно, как она подвисает в момент прихода сообщений. Видна задержка невооружённым глазом. Об этом же свидетельствует и top. Вопрос: что же потребляет ресурсы?? У меня centericq, запущенная в консоли, использует 8 мегабайт памяти(!) и заметную долю CPU. Бегло сделанный моим напарником анализ исходника centericq даёт ответ: эта программа циклически опрашивает оборудование: в итоге, время тратится на холостые циклы. Уже давно стало ясно, что программируют эти циклы не в самой программе (если по уму), а поручают данную функцию ядру системы: оно умное и догадывается вызвать centericq только тогда, когда прийдёт новое сообщение, пока же не пришло - centericq будет мирно покоиться оставив ресурсы системы другим программам. Я не удивлюсь, что доводка до ума centericq может привести к тому, что эта программа будет использовать в 10 раз меньше cpu и много менньший объём оперативной памяти. Аналогично, могу сказать и про mpd: он открывает массу локальных портов, которые потом долго не закрываются (вывод netstat), возможно, это происходит из-за того, что mpd слишком жёстко рвёт локальные соединения. Как итог, также потребляется большая часть памяти и cpu. В связи с упомянутыми проблемами мне всегда было интересно: что же используют сами разработчики для прослушивания музыки, для jabber'а и т.д.?
В виду всего вышесказанного добавлю, что я почти отказался от ВСЕХ gtk и qt приложений: из тех приложений, которые всё же используют qtk или qt на моей машине могу назвать только gimp, оперу и w3m. Со временем, предполагается, что и эти qt и gtk-based программы будут удалены.
Как видите, начав с чтения Вашей книги, я несколько удалился от исходной стези во всевозможные дебри и тонкости, но начало и основы идеологии были положены именно Вами (получается, являюсь Вашим учеником, таким образом ). Было бы интересно услышать Ваше мнение по поводу того что я здесь напсал в этом "открытом письме".
spinore
). Было бы интересно услышать Ваше мнение по поводу того что я здесь напсал в этом "открытом письме".spinore
P.S: по профессии занимаюсь квантовой механикой, более конкретно - квантовой томографией. Будучи уже под BSD-системами на своём компьютере, напсиал 2 научных статьи, магистерскую диссертацию (с использованием ТеХ, vim, ratpoison и NetBSD:
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1394944) и выполнил ряд расчётов на MatLab (maxima и octave являются достойной альтернативной - собираюсь их изучить). Ещё раз спасибо Вам за Вашу ценную книгу!
http://www.linux.org.ru/profile/spinore/vi...p?msgid=1394944) и выполнил ряд расчётов на MatLab (maxima и octave являются достойной альтернативной - собираюсь их изучить). Ещё раз спасибо Вам за Вашу ценную книгу!
. Шутю.
