Публикации с меткой «nix»

Задача: проводить манипуляции с файлами формата netCDF, в том числе осреднение и выборку по различным осям, установку временной оси, интерполяцию полей, объединение и разделение файлов.
Инструмент: CDO (Climate Data Operators)

Причина, по которой я так долго тянул с постом о cdo, наверное в том, что они настолько незаметны и настолько часто мной используются, что я практически забываю об их существовании, воспринимая больше просто как некие обычные команды шела. Однако без них жизнь человека работающего с netCDF (а также GRIB) файлами становится гораздо неуютнее. На сегодняшний день существует около 400 операторов, позволяющих проводить первичную обработку файлов. Как бы я не любил Python, поручить ему обработку террабайтов информации значит обречь себя на очень долгое ожидание, тогда как cdo, написанные на C++, справляются с крупномасштабными задачами сравнительно быстро, при этом обладают очень простым для понимания синтаксисом.

В посте я расскажу об установке CDO под Ububtu 10.04 и Windows (да, они есть и под винду) покажу как пользоваться несколькими наиболее популярными их функциями.

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

Инструменты: VirtualBox

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

и получить желаемый результат. Более того, зачастую даже для немного продвинутого в *nix системах человека правильно поставить некоторый океанологический софт представляется задачей нетривиальной. Он даже может после пары часов (в лучшем случае дней) плюнуть на это дело. Если же человек сидит на Виндоуз, то от него потребуются и вовсе титанические усилия, связанные с дополнительными трудностями перехода на новую систему.

Чтобы хотя бы частично избавиться от вопросов типа "почему у меня PyNGL на новой Убунте не устанавливается?" и "что прописать в .bashrc чтобы заработал Ferret" я решил создать образ системы в которой все основные программы о которых рассказывается на koldunov.net были бы уже установлены и работали.

За основу был взят LTS дистрибутив Ubuntu 8.04 . Программы были проинсталированы и более-менее проверены на работоспособность. В результате получился образ системы для VirtualBox, который вы можете развернуть как под Линукс, так и под Виндоуз.

Задача: отобразить наши данные на Google Earth
Инструменты: Python, PyNGL, convert

Я почему-то всегда думал что создание карт для Google Earth это занятие для избранных. С такой помпой очередной институт всегда анонсировал что его данные теперь и на Google Eatrh, что мне казалось группа программистов денно и ношно трудилась над этой непростой задачей год и вот теперь, наконец, долгожданный .kml файл увидел свет.

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

Собственно создание карты будет проводиться при помощи PyNGL, питоновского модуля позволяющего отображать двумерные данные на карте. Основы работы с этим модулем описаны в данном блоге и могут быть найдены по тегу PyNGL.
После мы обрежем карту при помощи convert и создадим простейший .kml файл, который и "натянет" наше изображение на Google Earth.

Поехали.

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

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде... Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии "одна утилита для одной задачи" (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git'e... читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git'а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

• http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
• http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git'ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но... интерфейс, это интерфейс...

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

Продвигаемся вперёд по плану гнобления¹: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь - в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда можно сделать алиасы) st, ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

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

К завершению подойду полупинком (почему "полу" - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

• hg fetch (который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.
• tip стоит не на основной ветке, а на последнем коммите.
• hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
• hg push определяет создание нескольких "голов²" только для текущей ветки.

Почему это полупинок? По двум причинам:

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

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

В принципе, замечания по поводу "это лучше, а это хуже" - приветствуются, особенно личные и субьективные (субьективные не в плане "я щетаю шо субверсион рулед и капец!" ;). Ссылки на статьи... я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)

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

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде... Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии "одна утилита для одной задачи" (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git'e... читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git'а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

• http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
• http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git'ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но... интерфейс, это интерфейс...

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

Продвигаемся вперёд по плану гнобления¹: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь - в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда можно сделать алиасы) st, ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

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

К завершению подойду полупинком (почему "полу" - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

• hg fetch (который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.
• tip стоит не на основной ветке, а на последнем коммите.
• hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
• hg push определяет создание нескольких "голов²" только для текущей ветки.

Почему это полупинок? По двум причинам:

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

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

В принципе, замечания по поводу "это лучше, а это хуже" - приветствуются, особенно личные и субьективные (субьективные не в плане "я щетаю шо субверсион рулед и капец!" ;). Ссылки на статьи... я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)

Давненько я ничего не писал, хотя причины вполне объективные - всю вторую половину января я усиленно делал диплом и готовился к запуску сайта, и потому начало февраля выдалось очень продуктивным - 2 февраля таки запустился наш проект, а 6 я сдал диплом и теперь наконец-то не студент! ;-) А остальное время я просто очухивался от этого - надеюсь, начну теперь писать больше. :)

Написать в блог меня заставил пост Дейва - делюсь тем, без чего не могу работать:

1. Emacs - куда же без него? Редактор, почтовый клиент, IRC-клиент, последнюю неделю изучаю возможность вести TODO (бтв, практически аналог изысков Ивана, только с кучей заточек редактора для этого) и подумываю об использовании jabber-клиента.
2. Firefox 2 - второй, потому что в дистрибутиве. Файрфокс, потому что conkeror пока не готов стать основным рабочим инструментом - не хватает всяких мелочей, хотя надежда на их появление высока.
3. Mercurial - после его использования svn выглядит кошмарным сном. Жду не дождусь, когда наш проект на него переедет (а всё к тому идёт). Не git просто потому, что нормально работает под виндой и имеет куда более удобную морду (проще как пользоваться, так и публиковать).
4. xmonad - открыл для себя мозаичные менеджеры окон в октябре и с тех пор просто получаю удовольствие: сеансы работы с обычными менеджерами просто раздражают.
5. foobar2000 - на этом месте более органичным было бы поставить python или zsh, но почувствовав, насколько мне не хватает удобства и функциональности фубара под линуксом, можно с уверенностью назвать его одним из основных моих инструментов. :-)

Правильным бы ходом тут было назвать тем, кому придётся такой пост писать, но... Скажем так - продолжайте! ;-)

Давненько я ничего не писал, хотя причины вполне объективные - всю вторую половину января я усиленно делал диплом и готовился к запуску сайта, и потому начало февраля выдалось очень продуктивным - 2 февраля таки запустился наш проект, а 6 я сдал диплом и теперь наконец-то не студент! ;-) А остальное время я просто очухивался от этого - надеюсь, начну теперь писать больше. :)

Написать в блог меня заставил пост Дейва - делюсь тем, без чего не могу работать:

1. Emacs - куда же без него? Редактор, почтовый клиент, IRC-клиент, последнюю неделю изучаю возможность вести TODO (бтв, практически аналог изысков Ивана, только с кучей заточек редактора для этого) и подумываю об использовании jabber-клиента.
2. Firefox 2 - второй, потому что в дистрибутиве. Файрфокс, потому что conkeror пока не готов стать основным рабочим инструментом - не хватает всяких мелочей, хотя надежда на их появление высока.
3. Mercurial - после его использования svn выглядит кошмарным сном. Жду не дождусь, когда наш проект на него переедет (а всё к тому идёт). Не git просто потому, что нормально работает под виндой и имеет куда более удобную морду (проще как пользоваться, так и публиковать).
4. xmonad - открыл для себя мозаичные менеджеры окон в октябре и с тех пор просто получаю удовольствие: сеансы работы с обычными менеджерами просто раздражают.
5. foobar2000 - на этом месте более органичным было бы поставить python или zsh, но почувствовав, насколько мне не хватает удобства и функциональности фубара под линуксом, можно с уверенностью назвать его одним из основных моих инструментов. :-)

Правильным бы ходом тут было назвать тем, кому придётся такой пост писать, но... Скажем так - продолжайте! ;-)

Настраивал себе локально чтение почты (кое-какие потоки почты забираю вместо перенаправления на гмейл, проще жить выходит :-), ну и сортировку соответственно. Так как я не слишком люблю клиенты типа Тандербёрда или Сильфид, то основным способ у меня всегда был procmail. Но его правила порядочно раздражают: читаешь доки, читаешь, проходит три месяца - и всё забывается. :-) Ещё, пока читал почту Gnus'ом, фильтровал его внутренними правилами, которые конечно поинтереснее прокмейловых, но... привязаны к Гнусу.

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

Пересмотрел порядка десятка программ и наткнулся на очень интересную штуку - maildirproc. Самое большое её достоинство: она написана на питоне и правила раскидывания - тоже самый обычный питон, можно творить всё, что душе угодно. Кроме того, есть одна особенность - в отличии от MDA типа procmail'а и maildrop'а, эта штука ориентирована сугубо на сортировку почты для одного человека. Потому просто указывается место, где появляется почта (типа /var/mail/piranha), и программа делает с каждым пришедшим письмом разные непотребности в полном соответствии правилам (есть однократный запуск, когда раскидывается вся текущая почта, и постоянный, когда "почтовые места" проверяются ежесекундно).

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

Настраивал себе локально чтение почты (кое-какие потоки почты забираю вместо перенаправления на гмейл, проще жить выходит :-), ну и сортировку соответственно. Так как я не слишком люблю клиенты типа Тандербёрда или Сильфид, то основным способ у меня всегда был procmail. Но его правила порядочно раздражают: читаешь доки, читаешь, проходит три месяца - и всё забывается. :-) Ещё, пока читал почту Gnus'ом, фильтровал его внутренними правилами, которые конечно поинтереснее прокмейловых, но... привязаны к Гнусу.

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

Пересмотрел порядка десятка программ и наткнулся на очень интересную штуку - maildirproc. Самое большое её достоинство: она написана на питоне и правила раскидывания - тоже самый обычный питон, можно творить всё, что душе угодно. Кроме того, есть одна особенность - в отличии от MDA типа procmail'а и maildrop'а, эта штука ориентирована сугубо на сортировку почты для одного человека. Потому просто указывается место, где появляется почта (типа /var/mail/piranha), и программа делает с каждым пришедшим письмом разные непотребности в полном соответствии правилам (есть однократный запуск, когда раскидывается вся текущая почта, и постоянный, когда "почтовые места" проверяются ежесекундно).

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

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

И поставил себе ALT Linux. О самом дистрибутиве - впечатления сугубо положительные. Если не считать отсутствие dpkg'шных возможностей по расставлению приоритетов для разных репозиториев (которыми я пользовался сугубо из-за устаревания testing, не то что stable), то все прелести apt на месте. Отличная система конфигурации сетевых интерфейсов (до этого мне дебиановская казалась лучшим вариантом, но теперь я знаю правду ;), етц, етц. Я в принципе не люблю sysconfig (она в FC/RHEL неадекватно загажена тоннами несортированых файликов настроек), но в Альте он подобен /etc/default Деба - всё достаточно простенько и ненапряжно. Разбиение на пакеты - отличное, бьют достаточно мелко; делать свои - одно удовольствие: рпм заметно проще деба пишется, а в альте ещё и немалое количество макросов, облегчающих жизнь и убивающих рутину. :)

В общем, понравился мне дистр. :)

Но из минусов - даже в нестабильной ветке сейчас идёт всё ещё ядро 2.6.18. В принципе, меня это никак не напрягало бы, но из-за этого не работал нормально hibernate/suspend и 3D. Но я бы на это дело даже забил, невелика потеря, если бы не питон. А в Альте он есть только 2.4 без вариантов. :( Я подёргался и написал письмо в рассылку, результатом которого явилось решение, что будет абсолютный переход на 2.5 (без сохранения 2.4), но не раньше Нового Года. Компилить питон руками мне никак не улыбалось, и я решил перейти на что-то более свежее.

На самом деле выбора особо и не было - я поставил свежую Убунту (прошлая версия которой наотрез отказывалась работать на моём ноуте ;). В ней, естественно, питон2.5, работает хибернейт и 3д рендеринг, и вообще всё отлично относительно большинства других вариантов. Если бы не одно но - шрифты. Я потратил суммарно часов 5-6 времени, заставив их выглядеть заметно лучше, чем они были в начале. И всё равно мой блог выглядит в винде на порядок лучше (особенно код). Да, я могу подправить дизайн своего блога, но я не могу подправить дизайн ещё целого ряда других сайтов.

Из чего следует печальный вывод, что видать я останусь на винде. :( Если, конечно, не случится чуда и шрифты вдруг не улучшатся. :)

Однако я хотел поделиться одной штукой - я за время этих экспериментов попробовал tiling wm'ы, и это просто невероятная штука! :) В конце-концов по совокупности фич и удобству (а также идеологическим соображениям ;) я остановился на xmonad. Вся идея заключается в том, что окна никогда не перекрываются (т.е., есть специальный слой для плавающих окошек - типа контакт листа или xmms'а какого, но это исключение и вообще на помойку такие окошки ;). Их можно туда-сюда совать, увеличивать и уменьшать размер относительно друг друга, расставлять в разные лейауты (мозаика, сетка, табы) и т.д.

В общем, рекомендую. Хотя бы попробовать. Мой конфиг можно найти тут (Config.hs).

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

И поставил себе ALT Linux. О самом дистрибутиве - впечатления сугубо положительные. Если не считать отсутствие dpkg'шных возможностей по расставлению приоритетов для разных репозиториев (которыми я пользовался сугубо из-за устаревания testing, не то что stable), то все прелести apt на месте. Отличная система конфигурации сетевых интерфейсов (до этого мне дебиановская казалась лучшим вариантом, но теперь я знаю правду ;), етц, етц. Я в принципе не люблю sysconfig (она в FC/RHEL неадекватно загажена тоннами несортированых файликов настроек), но в Альте он подобен /etc/default Деба - всё достаточно простенько и ненапряжно. Разбиение на пакеты - отличное, бьют достаточно мелко; делать свои - одно удовольствие: рпм заметно проще деба пишется, а в альте ещё и немалое количество макросов, облегчающих жизнь и убивающих рутину. :)

В общем, понравился мне дистр. :)

Но из минусов - даже в нестабильной ветке сейчас идёт всё ещё ядро 2.6.18. В принципе, меня это никак не напрягало бы, но из-за этого не работал нормально hibernate/suspend и 3D. Но я бы на это дело даже забил, невелика потеря, если бы не питон. А в Альте он есть только 2.4 без вариантов. :( Я подёргался и написал письмо в рассылку, результатом которого явилось решение, что будет абсолютный переход на 2.5 (без сохранения 2.4), но не раньше Нового Года. Компилить питон руками мне никак не улыбалось, и я решил перейти на что-то более свежее.

На самом деле выбора особо и не было - я поставил свежую Убунту (прошлая версия которой наотрез отказывалась работать на моём ноуте ;). В ней, естественно, питон2.5, работает хибернейт и 3д рендеринг, и вообще всё отлично относительно большинства других вариантов. Если бы не одно но - шрифты. Я потратил суммарно часов 5-6 времени, заставив их выглядеть заметно лучше, чем они были в начале. И всё равно мой блог выглядит в винде на порядок лучше (особенно код). Да, я могу подправить дизайн своего блога, но я не могу подправить дизайн ещё целого ряда других сайтов.

Из чего следует печальный вывод, что видать я останусь на винде. :( Если, конечно, не случится чуда и шрифты вдруг не улучшатся. :)

Однако я хотел поделиться одной штукой - я за время этих экспериментов попробовал tiling wm'ы, и это просто невероятная штука! :) В конце-концов по совокупности фич и удобству (а также идеологическим соображениям ;) я остановился на xmonad. Вся идея заключается в том, что окна никогда не перекрываются (т.е., есть специальный слой для плавающих окошек - типа контакт листа или xmms'а какого, но это исключение и вообще на помойку такие окошки ;). Их можно туда-сюда совать, увеличивать и уменьшать размер относительно друг друга, расставлять в разные лейауты (мозаика, сетка, табы) и т.д.

В общем, рекомендую. Хотя бы попробовать. Мой конфиг можно найти тут (Config.hs).