Мы с Linux уже 7 лет :)

Только что осознал, что 7 лет назад купил на горбушке два двд с довольно-таки устаревшим на тот момент срезом Debian Sid и снес винду. И с тех пор вот как-то постоянно с Linux в контакте нахожусь. Не скажу, что это сильно отразилось на профессионализме, гг, ну да, я их админю, поддерживаю, иногда ковыряюсь глубоко внутри, много опыта, но все равно не оставляет чувство, что в нем еще огромное количество белых пятен, касающихся его применения в быту и на производстве, так сказать. Это оказало потрясающее влияние, надо сказать. Например, мне очень не хочется сталкиваться с чем-то другим, особенно Windows, потому что привычно и удобно работать все-таки в *nix системах. Нравится сама идеология и философия.
Linux сильно изменился за эти годы. XFree86 ушел, пришел Xorg, научился делать и определять почти все сам, и почти всегда делает это правильно. Появились KDE4, Gnome3, Unity, которые до сих пор не вписываются в старые привычки, PulseAudio и NetworkManager. Долгое время была привычка отрицать наличие этого всего, но постепенно понимаешь, что это все-таки прикольно, юзабельно и удобно. Появился Ubuntu, который я тоже яростно отрицал, пока не попробовал, и вот уже Debian отошел на второй план, а в IRC я узнал про много других интересных дистрибутивов. И не могу сказать что какой-то лучше другого (ну, есть такие, которые я презираю в принципе, потому что не вижу им применения), все они хороши для определенного круга задач. Так что не холиворьте, у всех свои вкусы и пожелания. Все растут, понимают больше и, я уверен, у всех ощущение что "дистрибутивов должно быть много" будет иметь место, особенно если Linux это не только OS для десктопа.
Ну и за эти 7 лет я таки прихожу к мнению что Linux готов для дескопа. Не среднестатистического, но готов. И Windows для этого же самого не среднестатистического десктопа не готов совсем. :)

Загрузка SeaTools for DOS с флешки

У Seagate есть фирменная утилита для тестирования жестких дисков и ремаппинга бед секторов. Распространяется она в виде .iso, так что подразумевается что вы будете загружать ее с CD. Но так уж вышло, что у меня вовсе отстутсвует такой девайс в десктопе (есть только пара IDE-приводов, а IDE-контроллера в материнке нету :)). Так что единственным выходом было как-то в Linux создать загрузочную флешку с этой программой. Как обычно, решение нашлось, и оно называется Syslinux.
Она входит в большинство дистрибутивов, так что ее просто нужно установить через пакетный менеджер. :) Далее, адаптируя для своего дистрибутива (пути к файлам syslinux могут отличаться), делаем примерно следующее:
1. Переразмечаем флешку, создавая только один раздел с типом fat, используя любимый редактор разделов (fdisk или что там у вас).
2. Делаем этот раздел активным (boot) с помощью того же редактора разделов (раздел в fdisk помечается звездочкой в колонке Boot, а флаг переключается командой "а").
3. Копируем на флешку загрузочный раздел syslinux:

# dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdb

(будьте внимательны и не копипастьте эту команду в консоль - здесь нужно указать правильное устройство :))
4. Теперь устанавливаем syslinux в этот единственный раздел на флешке:

# syslinux /dev/sdb1

5. Теперь флешку можно смонтировать:

# mkdir /media/SEATOOLS ; mount -t vfat /dev/sdb1 /media/SEATOOLS

6. Для загрузки ISO нам потребуется memdisk из комплекта syslinux:

# cp /usr/lib/syslinux/memdisk /media/SEATOOLS

7. Теперь скопируем образ SeaTools на флешку.
8. В финале в корне флешки создается конфигурационный файл syslinux.cfg с примерно таким содержанием:

DEFAULT SeaTools
LABEL SeaTools
LINUX memdisk
INITRD SeaToolsDOS220EURO.144.ISO
APPEND iso

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

Про эти надоедливые локализации

У меня есть только одна позиция насчет иных локализаций интерфейсов, кроме английской, и я теперь ее намерен озвучить.
Начну с главного - нет ничего плохого для простых пользователей в том что они видят систему и приложения на родном, не английском, языке. Это славно и нужно. Но подчастую эта локализация настолько потрясает своим качеством исполнения, что на несколько секунд накатывает желание покалечить, или даже убить того кто их делает. Может тогда не стоит локализовать приложения совсем? Пользователи хотя-бы чуть-чуть станут полиглотами :).
Итак, проблемы по пунктам:
1. Орфография. В свое время я репортил проблемы с локализацией KeePassX, в которой были допущены вопиющие орфографические ошибки типа слова "пороли". Я так полагаю, что авторы явно не проверяют локализацию, как и майнтейнеры пакетов, которые, возможно, включают это вне зависимости от апстрима. В любом случае, баги поправили. Вот только не помню кто - я сам пошел и поправил или эти ребята таки меня услышали. В багрепорт ответили где можно это исправить.
2. Искажение смысла. Конкретного примера не приведу уже, не помню, но думаю, что все встречали какой-то такой странный перевод, что догадаться что кокретная функция делает именно то что нужно было нереально. (Хотя вот вы все думаете что "Пуск" в Windows это очевидный перевод. На самом деле я еще помню людей, которые впервые видели Windows 98, тыкали иконку на рабочем столе и пытались запусть ее кнопкой "Пуск". Ведь тогда подсказки, пролетающей по таскбару, с текстом "Нажмите тут чтобы начать работу" уже не было.)
3. Локализация добавляет эпичный баг, который делает софт неюзабельным. Вот пример, который я репортил, и который был куда-то подвинут в сторну прогресса только спустя годы: https://bugs.launchpad.net/ubuntu/+source/gtypist/+bug/281946. Т.е. локализаторы, судя по всему, не смотрят что случилось с приложением после локализации.
4. Просто убийственно - если какой-то системный инструмент после буквального перевода всем понятных терминов с английского языка вызывает громкий смех. Например, в какой-то версии 9.х Ubuntu кто-то решил локализовать вывод ifconfig и iproute2. Все получили чудесное "ВВЕРХ BROADCAST RUNNING MULTICAST" вместо "UP BROADCAST..." и "Диапазон: ссылка" вместо "Scope:Link". Но это скорее к пункту 2, наверное.
5. Иметь счастье искать по локализованному сообщению по ошибке решение проблемы в поисковиках почти не имеет смысла.
6. Иногда вы имеете сообщение об ошибке в консоли в неправильной кодировке и даже не можете его разобрать. Например, когда соединились с сервером с архаичной локалью в koi8-r с современного десктопа с UTF-8. Да, это решаемо, но лишними движениями. Оно мне надо?
7. Недавно на Хабре увидел скрины локализованного Netbeans. Сразу возникла мысль "И что, это правда можно вот так пользовать?". Смотрите сами: "Refactoring" заменено на "Реорганизация кода", хотя "рефакторинг" 99% программистам уже давно известное слово. "Участок текста" вместо "Text field". Это вообще искажение смысла. "Поле ввода" было бы куда понятнее, не так ли? Я уж не говорю что JTextField куда проще связать с Text Field нежели с "Участок текста". Т.е. названия компонентов в оригинале намного проще связать с классами компонентов. (Чорт, может им стоило еще и классы и синтаксис Java локализовать? А что, язык это позволяет...). Продолжаем глумиться - "Версии API-интерфеса". Версии МСМасла-Масла - Мягкого Сливочного Масла-Масла. "Построить" вместо "Build" не умиляет?

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

CFLAGS, CXXFLAGS и стоит ли так увлекаться их изменением?

Пользуясь случаем, даю ссылку на свой топик на WeLinux
В нем я немножко травлю тех пользователей (не всех!) Gentoo или Funtoo, которые бездумно меняют флаги компиляторов, ничего не тестируя и не сравнивая и потом пишут, что:  "Собрання под мой процессор система в стопицот раз круче чем любая другая! Я вот собираю с этими (20 флагов) и весь софт летает!".

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

Почему я начал? Да просто вот на примере FireFox5, описанном в топике, очевидно, что компилятор влияет, иногда аж на 20%, на производительность софта. Возможно, есть софт, который выигрывает (или проигрывает) даже сильнее. Поэтому интересно узнать, кто еще что тестировал и чего добился. Интересует любой действительно важный для пользователя софт (Например, браузер, офисный пакет или что еще в таком духе), либо демон/сервис, для которого производительность реально важна - это например, SQL БД, http-сервер или, скажем, proxy, mail и что угодно еще, что удалось разогнать на 20 и более %.

Про реагирование на OutOfMemoryException в Java

Есть такая неприятная ситуация, когда память в куче заканчивается, и сборщик мусора тратит все больше и больше времени, пытаясь ее безрезультатно освободить, потому что объекты еще используется. Когда на это тратится почти 100% процессорноного времени, JVM может внезапно выбросить OutOfMemoryException в треде, который попытался выделить еще память. Как правило, это означает полную смерть треда, а может и всего приложения. Что еще неприятнее, отловить эту ситуацию изнутри практически нереально.
Но, как оказалось, можно хотя-бы сообщить об этом наружу, что можно использовать чтобы послать, скажем, письмецо с сервера о том что сервис помер, или даже убить и перезапустить его.

Делается это опцией для JVM:
java ... -XX:OnOutOfMemoryError="shell command; ..."

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

Наслаждаясь Clojure

После месяцев троллинга в IRC по поводу Clojure, я, наконец, достал книжечку по этой теме и решил почитать, надеясь что простыми и понятными описаниями что, куда и как, как-то понять как писать на этом языке программирования какие-то полезные применимые в реальности программы, решающие реальные задачи. Книжечка эта - Joy Of Clojure, на английском языке, и я уже прочел 13 страниц из примерно 300 (что, как это нетрудно посчитать, является 4% от всего объема, что немного). Но я так ничего толком и не понял из того что там написано. В общем смысл пока такой - Clojure это реально классный и полезный язык и его делали реально классным и полезным языком для написания полезных программ, а не для изучения каких-то аспектов программирования, поэтому все просто обязаны его попробовать, потому что он позволит программистам увидеть бога. Пока что информация была предоставлена для тех, кто еще не имеет никакого понимания функционального программирования совсем (а таких людей большинство). Я помолчу о том, что я узнал много новых интересных слов английского языка, которые раньше я даже не встречал (несмотря на то что часто читаю техническую литературу, в том числе и по программированию, не используя словарей и переводчиков), и то что они там, в общем-то, никакого специального места не имеют. Это были не новые термины из математики или области компьютерных наук. Просто используется такой язык.. :)

Была и парочка примеров коротких программ, делающих простые вещи. Но смысл этой мешанины сокращенных слов, скобочек и двоеточий пока понять не удалось. Ну, то есть можно догадываться, что это делает, обозревая вывод программы, но никак не понять место всех этих символов. Сомневаюсь, что такое вообще кому-то без спецподготовки будет понятно, а с учетом того что смысл этого не был разъяснен, вообще с трудом угадывается место этих примеров в книге. Такое чувство, что она была написана только с одной целью - чтобы не очень глупые люди чувствовали себя полными идиотами. Но надеюсь, это чувство пропадет у меня по мере того как я снова и снова перечитаю эти 13 страниц, составлю конспект и схему этих непонятных понятий. Еще есть надежда, что я не стану таким же обфускатором, как автор этой книги (а может и автор языка - я не сомневаюсь, что это именно Clojure повлиял на автора книги таким причудливым образом).

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

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

И да, им очень нужны новые адепты.

Админское чутье

Есть некоторые вещи, которые админам приписывают. Пляски с бубном, какую-то непостижимую магию или еще чего. Да, это реально существует. Все зависит от количества мидихлориан и умения админа пользоваться Силой.
Вот было у меня много таких случаев. Скажем, было время ложиться спать, но ворочаешься, жарко, спать не можешь. Берешь и открываешь почту, смотришь, а там как раз недавнее сообщение от системы мониторинга что все плохо и что-то нужно и важное отвалилось. Идешь и чинишь. Или, бывало, раннее утро, но ты внезапно просыпаешься, хотя не было никакого шума или звонка будильника. И не можешь уснуть. И оказывается, да, прямо сейчас, несколько минут назад у тебя в почте появилось письмо про отвалившийся сервис. Такие дела.

На самом деле можно было бы долго верить в эти феномены, мистику и прочие непостижимые вещи, но у всего этого простое объяснение. Лето. Жара. Спится плохо. Да я очень часто просыпаюсь раньше обычного. И так уж вышло, что пару раз на этот момент выпало какое-то такое событие, которое я хорошо запомнил. Поэтому кажется, что есть какая-то связь, которой нету. То есть, нет магии, мидихлориан и Силы, которая движет админами.

О мифических профитах tmpfs при компиляции

Возвращаясь к "бенчмарку" сборкой ядра, табличка на результаты которого будет чуть ниже, прошу обратить внимание на выделенные зеленым строчки. Это ничто иное как попытка увидеть профит от размещения исходников и каталога для сборки на tmpfs, который целиком влазит в оперативу. Как видим, профит ничтожно мал и составил 18 секунд от 678, то есть всего около 2.6%. Если при этом учесть еще что tmpfs зажирает место, которое могло использоваться всей системой под кеш (ну, ведь гентушники же не подключают /var/tmp/portage перед каждой сборкой?), я думаю что это можно смело называть непонятно откуда взятым мифом. :)

Тут-то и сами результаты

Штирлиц получил новую шифровку из Центра

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

echo some text | perl -Mbigint -pe 'map{($s<<=8)|=$_}unpack"C*";$_="dc -e ${s}P\n"'

на выходе получается готовая команда для запуска dc, которая печатает some text. Этот окончательный вариант принадлежит перу ams, так что можете считать его perl-гуру. Другой гуру - ramok, он же komar, тоже приложился к этому делу.
Конечно, это не имеет никакой практической ценности, но является само по себе забавной вещью.

rlwrap - используем readline в приложениях, в которых его нет

rlwrap позволяет обернуть ввод в приложение, снабдив его функциями редактирования строки от readline. То есть, мы запускаем через rlwrap любую программу, которая просто читает ввод с терминала, например cat, telnet, netcat и получаем историю ввода, передвижение по строке курсорными клавишами, редактирование строки и прочие плюшки нормального, удобного ввода.
Устанавливается rlwrap в виде отдельного одноименного пакета и есть в репозиториях большинства дистрибутивов.

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

$ rlwrap netcat localhost 25

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

Как скопировать файлы из другой ветки репозитория git

Кросспост из ЛинСовета

Что же делать, если нужно скопировать файлик из одной ветки git в другую? Браться за голову и делать это руками? Совсем нет. :)


Достаточно сделать в нашей ветке, где файла нет вот такое действие:

$ git checkout другая_ветка путь_к_файлу

и файл магически скопируется из другая_ветка. Останется добавить его и закоммитить.

XPRA - "screen" для X-клиентов

xpra, или X Persistent Remote Applications - это приложение, которое позволит подключаться к запускаемым с его использованием X-клиентам (графическим программам) удаленно или локально, не опасаясь обрыва связи или смерти X-сервера. Эдакий “screen” для графических приложений, который и правда чем-то напоминает обычный screen для терминала.

Итак, как это работает?

1. Устанавливаем xpra. (свежие ебилды, репозитории со свежачком)
2. Запускаем xpra на каком-либо свободном дисплее:
   

   xpra start :1

   xpra list - показывает активные дисплеи xpra
3. Запускаем наше приложение:
   

   DISPLAY=:1 someguiapp

4. Идем на удаленную машину... запускаем ssh с X-forwarding:
   

   ssh -X username@hostname

5. Делаем xpra attach:
   

   xpra attach

6. Видим свое приложение и работаем с ним.

После этого можно повторять шаги 4-6 с любой машины (включая ту, на которой мы запустили xpra, правда для этого не нужно никуда подключаться по ssh).


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

Узнать время в другом часовом поясе

Кросспост с ЛинСовет

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

$ date
Fri Feb 18 10:22:53 EET 2011
 
$ TZ="America/Chicago" date 
Fri Feb 18 02:22:53 CST 2011

Узнать название зоны поточнее всегда можно в каталоге /usr/share/zoneinfo.

Немного "бенчмарков"

Как-то недавно я задался желанием купить свежий быстрый процессор от Intel и в преддверии этого искал и читал кучу бенчмарков. Появилось и желание проделать свой собственный, но так как мы, линуксоиды, не владеем кучей стандартных бенчмарков я вспомнил, как быстро компилилось 2.6.9 на одном из серверов, когда хотелось проверить стабильность системы. Так что я решил взять одну и ту же версию ядра и собрать ее с make allmodconfig на самых разных системах.
И вот что получилось:

https://spreadsheets.google.com/ccc?key=0AprkJoujHYK8dERmZF9aLTI4SFhTWjBWd2J5LWlTVEE&hl=en#gid=0

Выводов пока немного. :)
1. Благодаря наличию в i7 2600 технологии HyperThreading мне удалось протестировать процессор и с ней и без нее. Разница в убывании времени компиляции довольно значительна - около 20%, что, безусловно, совсем не мало, так что, пожалуй, если вы часто собираете ядро, вам Hyperthreading пригодится.
2. Чем "боянистее" процессор, тем он медленнее. Это хорошо заметно по убыванию времени компиляции по сравнению с временем выхода процессоров в свет. Вплоть до 20 раз между 2003 и 2011 годом :). Также можно найти тест одного из товарищей на мобильном i7 720QM, который даже на меньших частотах обгоняет старенький XP 2200+ не в ожидаемые 4-8 раз (по числу ядер и потоков), а в целых 10.
3. Частота процессора и шин может влиять на время компиляции значительно. Это стало ясно после разгона XP2200+ с 1800 до 2025 МГц по шине (с 133 до 150 Мгц), а именно на 12%, отчего время компиляции снизилось на целых полчаса (~16%). Частота памяти же тут ничем не влияла, хотя и была попытка переключать DDR266 в DDR400, благо такая возможность была в чипсете nForce2). Но, несмотря на это, разогнанный до 4.2 ГГц Core i7 не дал лучших результатов, возможно, пропускной способности одноканальной памяти не хватило.
4. В разных ядрах/компиляторах результаты разные. Так получилось, что тест на T7250 проводился сначала в Funtoo (64-битный), а потом с Live CD Ubuntu 10.04 (32 бита), просто из интереса, дает ли прирост 64-битная архитектура при компиляции ядер. Так как результат оказался в 5 минут в пользу 32-битной системы было заподозрено неладное - и 64-битный LiveCD Ubuntu 10.04 тоже оказался быстрее на те же 5 минут.
5. Не всегда больше ядер - быстрее сборка. :) Opteron 8220 при вдвое меньшем числе ядер серьезно обставил 4 Xeon E7340 (хотя, ну может быть, дело в RT-ядре на последнем). Влияет "качество" ядер и частоты.

Немного справки:
Ядро было 2.6.36.3.
Компилировалось тестируемой архитектурой под нее же.
Конфигурация ядра получалась командой make allmodconfig
Памяти было достаточно чтобы пренебречь дисковыми тормозами.
Каждый тест проводился после чистой распаковки ядерного тарболла.
Учитывалось только время компиляции.

Если кому-то захотелось тоже прогнать компиляцию и поделиться результатом, скрипт примерно такой:

#!/bin/bash

KERNEL_TAR=kernel.tar.gz
KERNEL_URL=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.3.tar.bz2
KERNEL_DIR="linux-2.6.36.3"

CPU_CNT=`grep -c processor /proc/cpuinfo`
# Here you can change number of jobs
JOBS=$CPU_CNT 
#JOBS=$(( $CPU_CNT * 2 )) 
echo "Running test usung $CPU_CNT processors and $JOBS jobs"

if [ ! -e "$KERNEL_TAR" ] ; then
    wget "$KERNEL_URL" -O"$KERNEL_TAR"
fi

if [ -e "$KERNEL_DIR" ] ; then
    rm -rf "$KERNEL_DIR"
fi

tar xf "$KERNEL_TAR" && cd $KERNEL_DIR && 
make allmodconfig &&
time (make -j "$JOBS" > ../build.log 2>&1) 
if [ $? -eq 0 ] ; then  
 cd .. &&
 rm -rf "$KERNEL_DIR" 
 echo Include this data to report too: 
 gcc --version
 uname -a
 grep "model name" /proc/cpuinfo | head -1
 echo $CPU_CNT threads
else  
 cd ..
 echo build failed. You can look into build.log to find cause.
fi

Требуется наличие подключения к интернету, около 4 ГБ свободного места на диске, make, компилятор и другие программы для сборки ядра.

И если решите запускать через sh "xxxx.sh", убедитесь, что ваш /bin/sh - bash, иначе результаты time будут отличаться от тех, которые публикую я.