/*
Omnia vanitas
...
начнём с простого:
Q: "сколько браузеров должно быть в системе?"
> A(fanatic): "$NAME - рулит! все остальные - сосут! $NAME! $NAME! $NAME!"
> A(experiment): "...ну, как бы мне хватает и $NAME/($NAME1, ... $NAMEn), но если есть что попробовать ещё..."
> A(indifferent): "...собсно пох. чё-то стоит, обновляется, меня устраивает..."
все прочие варианты ответов сводятся к этим трём, вне зависимости от операрационной системы, тулкитов и раскладов карт "таро". дальнейшее - IMHO.
сначала хотел накатать что-то типа глобального обзора с выводом в таблицу итоговых результатов. слишком долго. и вряд-ли кому-то нужно. поэтому "прокатимся" по-быстрому. есть смысл ввести две большие категории:
1) консольные браузеры ("text based", не требуют GUI и/или Xserver-а)
самые "яркие" и "известные" представители (так сказать "для широкого круга пользователей"):
w3m
elinks
links
links2
lynx
и т.п..
2) "всё остальное" - браузеры, требующие для своей работы Xserver и какой-либо тулкит/(тулкиты):
2a) "лёгкие" браузеры - категория относительна. многое из того, что начинается как "лёгкое", потом обрастает "рюшечками" и превращается в "тормоз перестройки" (пример - дерево исходников того же WebKit-а уже распухло свыше 1Gb и требует зачастую специфичных kde/(прочих) приблуд. ещё один пример из разряда "классики": xfce-3.* была хороша, xfce-4.* - то ли "гном", то ли "девочка", то ли...)
2b) "монстры рока" - наши "чемпионы", любимцы публики, выбор колхозников, доярок и механизаторов
"пиарить" вторую категорию смысле нет. имя им - "легион". единственное замечание - отсутствие приложений/(аналогичного функционала) типа "AdBlock Plus", "NoScript", "No Squint", "Greasemonkey" и прочих ставит крест на использовании того или иного браузера, как бы круто и хорошо он себя не вёл. ибо реклама, скрипты, "д'ебзайн" некоторых сайтов и прочие "шалости" надоели.
предпочтения и вкусы конечно же со временим меняются. но некоторые вещи остаются "как есть" достаточно длительное время, чтобы говорить или о личных пристрастиях индивидуума, или же о достаточной универсальности тех или иных решений.
из "консольных" w3m заслуживает внимания. ибо "могёт" при желании и картинки показать и стремится отобразить страничку "без вранья". поддерживает "табы", имеет внятный синтаксис конфигурационного файла. НО! "нельзя быть красивым таким!" к сожалению "w3m" не поддерживает JavaScript и это очень жирный минус. другими словами, если есть желание заглянуть на тот же gmail.com - то извольте пользовать links2. абзац. тем не менее энтузиасты могут таки "поднять" один из вариантов проекта по прикрутке JS/ECMA к "w3m". начали, как говорится, во здравие - кончили как обычно. links2
"лёгкие" браузеры - самая интересная "ниша". принцип: вам надо по-быренькому без шума и пыли (хруста и скрежета винтов, завывания вентиляторов, скачков напряжения на процессоре при "засасывании" в память недостающих библиотек тулкита и т.п.) просмотреть какие-то странички, может пробежаться по сохранённым страницам на винте. для меня - это в первую очередь чтение документации (преимущественно offline) с возможностью при необходимости сунуться в сеть. кто только сюда не прётся со своим свиным рылом... тут и "отец всех народов" - непотопляемый Dillo, и Arora, "медведь" которого без стеснения трахает наш "шарик" (как у них язык поворачивается назвать QtWebKit лёгким...), и Midori, что до сих пор не может импортировать "букмарки", тянет вагон зависимостей и сыпется на ровном месте... и прочая и прочая и прочая...
посему альтернатив H3v нет и ближайшем будущем не предвидится. выбирать не из чего. при использовании "Tk-8.5.*" и выше нет проблем с рендерингом шрифтов. в остальном - конфета. ребята из команды Tcl.Tk - умнички! огромный им почёт и уважение! делают нужное и важное дело. H3v несмотря на более чем скромный вид, практически проходит acid2 test. правда с acid3 пока не всё гладко, но оно явно стартует и шевелится до определённого момента. большего пока и не нужно.
вот мы и подошли к нашим "толстым котикам"... котики конкретные, раскормленные, с ордой фанатов и разработчиков, и ни разу не бедные, да... тут "йайтса сгорят в тёплых лучах ненависти и костерке холивара" за любое неосторожное слово... поэтому промолчу. только дам ссылочку:
Seamonkey-2.0
плюсы:
* "инкрементальное" обновление установленной версии (т.е. тащит только дельты обновляемых компонентов. установка не требует рутовых привилегий и дополнительных пакетов/зависимостей)
* ! IMHO ! - лучшая оптимизация, чем у "старшего братца". субъективно - очень быстрый, с хорошим скроллингом и старой доброй системой настроек.
* SUITE: т.е. "Browser" + "Mail & News" + "Composer" + "Address Book" + "IRC Chat". плюс шикарнейшие "Web Development" tools "из коробки"
* поддержка плагинов и расширений (а-ля FF)
* 93 балла в Acid3
* старый оригинальный дизайн "Нетшкафа" (привычка?). управление "профилями"/(User Profiles) до сих пор работает великолепно
минусы:
* плагинов и расширений не так много, как хотелось бы. но основные есть
* маловато визуальных тем, хотя, кроме 2-ух (default и modern, идут "в коробке") и не нужно ничего. default "подтаскивает" виджеты текущей темы gtk2. modern - это классика.
* RSS "запихан" в "Mail & News". для версий 1.* прикрутили тонну читалок ньюса (как и для FF), для 2.* - ждём-с...
в общем это эдакий "дедушка" (который помнит первую фразу "Да будет Свет!" ), что идёт в своём неспешном развитии "правильным путём" по заветам старика Мао. явно не для современного generation XYU (хотя, кто знает...)
мдэ... перечитал... хз кому это пригодится, посему теги соответствующие.
удачи!
P.S. Мысли, что не вошли в первоначальную статью...
/или о том, что чудес не бывает.../
как бы ни были хороши с эстетической точки зрения "консольные" браузеры - у них есть чётко очерченный "потолок": поддержка ограниченного количества стандартов/(технологий), используемых в современном www. то же самое применимо и к так называемой когорте "лёгких" браузеров. "лёгким" браузер может быть только по одной простой причине - он поддерживает ограниченное количество стандартов www. основной козырь "лёгкого" браузера - он должен отлично делать то, на что претендует по спецификации. плюс он должен отличаться охренительной оптимизацией как в используемом тулките для собственного UI, так и в своём "маленьком, но гордом" движке рендеринга страниц.
эталонным примером в этом вопросе может служить эволюция Dillo. уход от GTK1 на FLTK позволил более чем в два! (2) раза уменьшить потребление ОЗУ и снизить нагрузку на систему в целом! это что же тогда из себя gtk2 представляет? а будет gtk3 скоро... и, блядь, наши новые Quad Core CPU paired with XXXGb of RAM тогда точно покажут такую охуенную производидельность на десктопе, что Top500 придётся пересматривать каждый Божий день.
H3v (Tk/Tcl) в этом плане - просто супер! я не знаю КАК, но он "дрючит" Dillo по всем статьям и в хвост и в гланды. причём если собирать его на целевой машине (под целевую архитектуру), то значительно возрастает стабильность. поэтому ему и только ему сегодня мои наилучшие и здравицы.
а вот "Arora", "Midori", "Epiphany+WebKit" и прочие именно что лезут "со свиным рылом в калашный ряд" "лёгких". тут разворачивается нешуточная борьба платформ/(движков рендеринга): "молодой" WebKit против всех. напомню, что до сих пор единственным по-настоящему эталонным браузером на Webkit является Apple Safari причём сугубо в своём родном окружении (Mac OS). после сокрушительного удара от Firefox (выпустившего сборку для Mac OS, основательно проредившую ряды сторонников Safari), Apple "отдала" WebKit и, потирая лапки, мечтала о реванше. в эту пасторальную картину нежданно-негаданно "впёрся" Google Chrome, нагнув в "позу пьющего оленя" многострадальный IE. виден явный прицел "обкатать" технологию на Linux, а потом ещё раз "проехаться на белом коне" по пользователям Mac OS. выпуск Safari для Microsoft Windows по сути ничего не изменил. назревает очередная конкретная веселуха. на этом празднике жизни симпатии сугубо на стороне Mozilla, ибо на моих глазах Господа из MS и AOL резали Netscape. наконец-то "кровь смоет их грехи...". "it's payback time, honey!"
поэтому определённый интерес конечно же представлял бы глубокий "разбор" H3v<->Arora<->Midori с подробными выкладками, тестами и т.п.. но смысла нет. H3v чётко держит стандарты, что в него заложены, не выходя за их рамки, и прочим тут ловить абсолютно нечего. противостояние же Arora<->Midori неизбежно сведётся к очередному Qt<->GTK холивару. оно нам надо? ни тот ни другой пока не способны стать "нумеро уно" на все случаи жизни.
P.P.S. в моём репо для openSUSE-11.1 скоро появится последняя стабильная версия midori-0.1.9 . пользуйте!
*/
пятница, 21 августа 2009 г.
2Be Experimental
/*
... and this is wrong!
I dunno what and how,
but this wrong by default!
...
Ladies and Gents,
we issued an experimental release of our "2Be" themes:
download page
and will be pleased to hear your comments! the changes are mostly to the way EFM displays the information about files in a "grid mode".
thanks!
*/
... and this is wrong!
I dunno what and how,
but this wrong by default!
...
Ladies and Gents,
we issued an experimental release of our "2Be" themes:
download page
and will be pleased to hear your comments! the changes are mostly to the way EFM displays the information about files in a "grid mode".
thanks!
*/
вторник, 18 августа 2009 г.
К вопросу о update/upgrade
/*
... если Ваша программа таки
заработала - то это просто СЧАСТЬЕ...
/Linus Torvalds, вольный перевод/
на сей опус подвигли многочисленные заявления о сокращении сроков поддержки релизов и т.п.. плохо это или хорошо - не мне судить, но ключевой выбор openSUSE/SuSE/SLE* как платформы для изучения/использования/экспериментов в основном обусловлен КАЧЕСТВОМ самого дистрибутива и схемой поддержки (включая латание дыр и т.п.).
на кону у нас очередной "multiple guess question": - "а стоит ли переползать на грядущую openSUSE-11.2?" imho - настоящие джедаи делают "zypper dup" только после kernel upgrade-а в новой версии, или же спустя 2-3 месяца после выхода (да и то по обстоятельствам). о том, каково оно - "переход на новую версию" - писал ранее.
на данный момент в openSUSE-11.1 (oS-11.1) используется стабильная версия ядра 2.6.27.* и для многих пользователей "фишки" новых ядер представляются более предпочтительными. "не вопрос!" с недавних пор в OBS появились новые чудные репо:
Moblin Base
Moblin
где предлагают Вашему вниманию довольно сырой и нестабильный интерфейс, основанный на clutter. это собсно прообраз gnome-3.* и до выхода релиза пользовать его не рекомендуется (ессно для незаинтересованных граждан).
по сути своей интерфейс Moblin очень напоминает "illume" модуль Enlightenment-DR17 по заложенным концепциям. по крайней мере все принципы построения интерфейса "честно" слизаны с illume, что не может не радовать. после добавления указанных выше репо есть возможность поставить себе kernel-2.6.30.5 (последний стабильный релиз) и попробовать его как основу для своей системы. есть пара-тройка моментов, не более. теперь по-порядку:
1) для сукесфули (successfully) ребута в "/etc/modprobe.d/*" все файлы должны иметь расширение "*.conf" (тупенько ручками пририсуем к имени файла это расширение...).
2) убедиться, что поставили "полный фарш":
kernel-default-2.6.30.5-16.1
kernel-default-base-2.6.30.5-16.1
kernel-default-devel-2.6.30.5-16.1
kernel-default-extra-2.6.30.5-16.1
kernel-firmware-20090421.1-5.1
kernel-source-2.6.30.5-16.1
kernel-syms-2.6.30.5-16.1
3) поддержка reiserfs4 чарующе элегантна (как обычно впрочем...):
> wget http://download.opensuse.org/repositories/home:/jeff_mahoney/openSUSE_Factory/src/reiser4-0.1-29.2.src.rpm
> rpmbuild --rebuild ./reiser4-0.1-29.2.src.rpm
> sudo rpm -Uhv /usr/src/packages/RPMS/$ARCH/reiser4-kmp-default-0.1_2.6.30.5_16-29.2.i586.rpm
4) крайне желательно проапгрейдить "e2fsprogs":
> rm /usr/src/packages/RPMS/$ARCH/e2fsprogs*
> wget http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.41.8.tar.gz
> tar xfm ./e2fsprogs-1.41.8.tar.gz
> cd ./e2fsprogs-1.41.8 && ./configure && cd ../
> ln -s "`pwd`"/e2fsprogs-1.41.8.tar.gz /usr/src/packages/SOURCES/
> cd ./e2fsprogs-1.41.8 && rpmbuild -bb ./e2fsprogs.spec
> sudo rpm -Uhv --force /usr/src/packages/RPMS/$ARCH/e2fsprogs*.rpm
последняя операция проходит "грязно" (с ключём --force) поскольку возможен банальный конфликт базовых утилит. не страшно.
5) зато с "btrfs" у нас "просто Праздник какой-то"!
> zcat /proc/config.gz | grep -i btr
CONFIG_IPV6_SUBTREES=y
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
6) также надо учесть, что конфиг ядра отличается чуток от "канонического". некоторые модули тупо вкомпилены в ядро. например:
'processor', 'thermal', 'fan', 'jbd', 'ext3', 'sd_mod', 'usbcore', 'ohci_hcd', 'uhci-hcd', 'ehci_hcd', 'usbhid' (может что-то ещё, список не полный, только очевидные вещи).
эт всё к тому, что не забудьте (при желании ессно) отрихтовать "/etc/sysconfig/kernel" на придмет "initrd" и всего, что с этим связано. это совершенно не критично, но, если вы конвертнули ext2/3 в ext4 - то пропишите модулёк. udev конечно придумали трусы, но мало ли. не помешает. ессно, что после подобных телодвижений стоит набрать (как минимум):
> sudo mkinitrd
7) NVIDIA-Linux-x86-185.18.31-pkg1.run прекрасно работает с нашим новым ядром (2.6.30.5)
8) AppArmor не портирован (пока).
9) стоит также помнить, что ALSA в новых ядрах "своя". не пугайтесь, если звук пропадёт и "alsaconf" пошлёт вас в известном направлении. откройте "alsamixer" с выводом всех "регуляторов" и пройдитесь по всем "ползункам". например, в случае "via82xx" помогают "*DXS*" и т.д. и т.п..
10) кроме ядра из указанный репо у вас должно пройти обновление до gtk2-2.16, что не может не радовать.
теперь со спокойной душой и чистой совестью можно понаблюдать за "хомячками" и их плясками с openSUSE-11.2.
N.B. если у вас всё работает и вы просто желаете "развлечься", то стоит оставить возможность загрузки системы с её "родных" ядер. для этого скачайте "kernel*2.6.30.5*.rpm" в локальную директорию и проведите команду установки тупо в лоб:
> rpm -i ./kernel*.rpm
так вы сохраните в системе ядра версии 2.6.27.*
удачи.
*/
... если Ваша программа таки
заработала - то это просто СЧАСТЬЕ...
/Linus Torvalds, вольный перевод/
на сей опус подвигли многочисленные заявления о сокращении сроков поддержки релизов и т.п.. плохо это или хорошо - не мне судить, но ключевой выбор openSUSE/SuSE/SLE* как платформы для изучения/использования/экспериментов в основном обусловлен КАЧЕСТВОМ самого дистрибутива и схемой поддержки (включая латание дыр и т.п.).
на кону у нас очередной "multiple guess question": - "а стоит ли переползать на грядущую openSUSE-11.2?" imho - настоящие джедаи делают "zypper dup" только после kernel upgrade-а в новой версии, или же спустя 2-3 месяца после выхода (да и то по обстоятельствам). о том, каково оно - "переход на новую версию" - писал ранее.
на данный момент в openSUSE-11.1 (oS-11.1) используется стабильная версия ядра 2.6.27.* и для многих пользователей "фишки" новых ядер представляются более предпочтительными. "не вопрос!" с недавних пор в OBS появились новые чудные репо:
Moblin Base
Moblin
где предлагают Вашему вниманию довольно сырой и нестабильный интерфейс, основанный на clutter. это собсно прообраз gnome-3.* и до выхода релиза пользовать его не рекомендуется (ессно для незаинтересованных граждан).
по сути своей интерфейс Moblin очень напоминает "illume" модуль Enlightenment-DR17 по заложенным концепциям. по крайней мере все принципы построения интерфейса "честно" слизаны с illume, что не может не радовать. после добавления указанных выше репо есть возможность поставить себе kernel-2.6.30.5 (последний стабильный релиз) и попробовать его как основу для своей системы. есть пара-тройка моментов, не более. теперь по-порядку:
1) для сукесфули (successfully) ребута в "/etc/modprobe.d/*" все файлы должны иметь расширение "*.conf" (тупенько ручками пририсуем к имени файла это расширение...).
2) убедиться, что поставили "полный фарш":
kernel-default-2.6.30.5-16.1
kernel-default-base-2.6.30.5-16.1
kernel-default-devel-2.6.30.5-16.1
kernel-default-extra-2.6.30.5-16.1
kernel-firmware-20090421.1-5.1
kernel-source-2.6.30.5-16.1
kernel-syms-2.6.30.5-16.1
3) поддержка reiserfs4 чарующе элегантна (как обычно впрочем...):
> wget http://download.opensuse.org/repositories/home:/jeff_mahoney/openSUSE_Factory/src/reiser4-0.1-29.2.src.rpm
> rpmbuild --rebuild ./reiser4-0.1-29.2.src.rpm
> sudo rpm -Uhv /usr/src/packages/RPMS/$ARCH/reiser4-kmp-default-0.1_2.6.30.5_16-29.2.i586.rpm
4) крайне желательно проапгрейдить "e2fsprogs":
> rm /usr/src/packages/RPMS/$ARCH/e2fsprogs*
> wget http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.41.8.tar.gz
> tar xfm ./e2fsprogs-1.41.8.tar.gz
> cd ./e2fsprogs-1.41.8 && ./configure && cd ../
> ln -s "`pwd`"/e2fsprogs-1.41.8.tar.gz /usr/src/packages/SOURCES/
> cd ./e2fsprogs-1.41.8 && rpmbuild -bb ./e2fsprogs.spec
> sudo rpm -Uhv --force /usr/src/packages/RPMS/$ARCH/e2fsprogs*.rpm
последняя операция проходит "грязно" (с ключём --force) поскольку возможен банальный конфликт базовых утилит. не страшно.
5) зато с "btrfs" у нас "просто Праздник какой-то"!
> zcat /proc/config.gz | grep -i btr
CONFIG_IPV6_SUBTREES=y
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
6) также надо учесть, что конфиг ядра отличается чуток от "канонического". некоторые модули тупо вкомпилены в ядро. например:
'processor', 'thermal', 'fan', 'jbd', 'ext3', 'sd_mod', 'usbcore', 'ohci_hcd', 'uhci-hcd', 'ehci_hcd', 'usbhid' (может что-то ещё, список не полный, только очевидные вещи).
эт всё к тому, что не забудьте (при желании ессно) отрихтовать "/etc/sysconfig/kernel" на придмет "initrd" и всего, что с этим связано. это совершенно не критично, но, если вы конвертнули ext2/3 в ext4 - то пропишите модулёк. udev конечно придумали трусы, но мало ли. не помешает. ессно, что после подобных телодвижений стоит набрать (как минимум):
> sudo mkinitrd
7) NVIDIA-Linux-x86-185.18.31-pkg1.run прекрасно работает с нашим новым ядром (2.6.30.5)
8) AppArmor не портирован (пока).
9) стоит также помнить, что ALSA в новых ядрах "своя". не пугайтесь, если звук пропадёт и "alsaconf" пошлёт вас в известном направлении. откройте "alsamixer" с выводом всех "регуляторов" и пройдитесь по всем "ползункам". например, в случае "via82xx" помогают "*DXS*" и т.д. и т.п..
10) кроме ядра из указанный репо у вас должно пройти обновление до gtk2-2.16, что не может не радовать.
теперь со спокойной душой и чистой совестью можно понаблюдать за "хомячками" и их плясками с openSUSE-11.2.
N.B. если у вас всё работает и вы просто желаете "развлечься", то стоит оставить возможность загрузки системы с её "родных" ядер. для этого скачайте "kernel*2.6.30.5*.rpm" в локальную директорию и проведите команду установки тупо в лоб:
> rpm -i ./kernel*.rpm
так вы сохраните в системе ядра версии 2.6.27.*
удачи.
*/
понедельник, 10 августа 2009 г.
Version 3.2.0 is out.
/*
Ladies and Gents,
we're glad to announce that SOAD Linux 3.2.0 is out and available for download.
Please examine the documentation before you consider to download the images:
General documentation
USB-stick readme
The EFL is compiled from official 3-rd pre-release sources and pretty stable here.
Software is updated and several nice utilities added as well. This time we even tried to create some modest GUI customizations/presets and hope that you like them.
Our TODO list is to fix all errors with "Ecomorph" and provide it for LiveCD and USB systems.
We wish to say "HUGE THANKS!" to "cyberorg" (Jigish Gohil) and "schaefi" (Marcus Schaefer) for their help with this release.
Have fun!
Regards,
SOAD Team
P.S. active mirrors:
GWDG.DE
Yandex.ru
Господа и Дамы,
версия 3.2.0 SOAD Linux увидела свет в прошедшие выходные и доступна для скачивания по адресу в заголовке этой заметки.
Пожалуйста, изучите документацию прежде чем что-то качать:
Общая документация
Инструкция по установке системы на USB-stick (на флешку)
Документация должна помочь понять стоит ли SOAD Вашего внимания. Если тяжко с английским - попробуйте Google Translate. Файл "Welcome.pdf" содержит множество картинок (эт если и с Google Translate не заладилось...).
Планируем в ближайшее время "разобраться" с "Ecomorph". С благодарностью рассмотрим любые варианты помощи/поддержки.
Огромная благодарность господам "cyberorg" (Jigish Gohil) и "schaefi" (Marcus Schaefer) за помощь в подготовке этого релиза!
Удачи!
С наилучшими пожеланиями,
SOAD Team
P.S. зеркала проекта:
GWDG.DE
Yandex.ru
*/
Ladies and Gents,
we're glad to announce that SOAD Linux 3.2.0 is out and available for download.
Please examine the documentation before you consider to download the images:
General documentation
USB-stick readme
The EFL is compiled from official 3-rd pre-release sources and pretty stable here.
Software is updated and several nice utilities added as well. This time we even tried to create some modest GUI customizations/presets and hope that you like them.
Our TODO list is to fix all errors with "Ecomorph" and provide it for LiveCD and USB systems.
We wish to say "HUGE THANKS!" to "cyberorg" (Jigish Gohil) and "schaefi" (Marcus Schaefer) for their help with this release.
Have fun!
Regards,
SOAD Team
P.S. active mirrors:
GWDG.DE
Yandex.ru
*******************************************************************************
Господа и Дамы,
версия 3.2.0 SOAD Linux увидела свет в прошедшие выходные и доступна для скачивания по адресу в заголовке этой заметки.
Пожалуйста, изучите документацию прежде чем что-то качать:
Общая документация
Инструкция по установке системы на USB-stick (на флешку)
Документация должна помочь понять стоит ли SOAD Вашего внимания. Если тяжко с английским - попробуйте Google Translate. Файл "Welcome.pdf" содержит множество картинок (эт если и с Google Translate не заладилось...).
Планируем в ближайшее время "разобраться" с "Ecomorph". С благодарностью рассмотрим любые варианты помощи/поддержки.
Огромная благодарность господам "cyberorg" (Jigish Gohil) и "schaefi" (Marcus Schaefer) за помощь в подготовке этого релиза!
Удачи!
С наилучшими пожеланиями,
SOAD Team
P.S. зеркала проекта:
GWDG.DE
Yandex.ru
*/
суббота, 1 августа 2009 г.
Good Old Rock'n'Roll...
/*
It was twenty years ago today,
Sgt. Pepper taught the band to play...
/The Beatles/
yet another (stupid?) work to eliminate all UTF-8 related issues for some of the E-DR16 themes. the hyperlink is in the headline of this note. you're welcome to download the slightly modified themes and send me your feedback.
if you wish the similar modifications to be done for other themes - let me know, can't promise but who knows...
all you need is to set the symlinks for normal (normal.ttf) and bold (bold.ttf) standard fonts properly.
regards.
*******************************************
как и обещал - чуток модифицированные темки для E-DR16-го с полной поддержкой UTF-8 если вы перебъёте симлинки
/usr/share/e16/fonts/bold.ttf
и
/usr/share/e16/fonts/normal.ttf
с дефолтного ужаса (Vera fonts family) на DejaVu например. отпишитесь о результатах если не трудно.
удачи.
*/
It was twenty years ago today,
Sgt. Pepper taught the band to play...
/The Beatles/
yet another (stupid?) work to eliminate all UTF-8 related issues for some of the E-DR16 themes. the hyperlink is in the headline of this note. you're welcome to download the slightly modified themes and send me your feedback.
if you wish the similar modifications to be done for other themes - let me know, can't promise but who knows...
all you need is to set the symlinks for normal (normal.ttf) and bold (bold.ttf) standard fonts properly.
regards.
*******************************************
как и обещал - чуток модифицированные темки для E-DR16-го с полной поддержкой UTF-8 если вы перебъёте симлинки
/usr/share/e16/fonts/bold.ttf
и
/usr/share/e16/fonts/normal.ttf
с дефолтного ужаса (Vera fonts family) на DejaVu например. отпишитесь о результатах если не трудно.
удачи.
*/
воскресенье, 14 июня 2009 г.
Way Down
/*
простите за качество, это в спешке накатал, чтобы хоть "идея" сохранилась. "лопату" в руки год не брал, поэтому ляпов многовато, не вылизывал. линк в заголовке.
*/
простите за качество, это в спешке накатал, чтобы хоть "идея" сохранилась. "лопату" в руки год не брал, поэтому ляпов многовато, не вылизывал. линк в заголовке.
*/
понедельник, 4 мая 2009 г.
qemu - работа с сетью
/*
материалов на данную тему в сети - море. эта заметка не претендует на оригинальность. пригодится - хорошо, а нет - так ещё лучше. по сути рассматривается частный случай создания виртуальных сетей с использованием qemu, где все "клиенты" друг друга видят, умеют общаться, делиться ресурсами и т.п.
терминология:
"гостевая" система - система, загруженная с использованием qemu/(под управлением qemu) (GUEST)
"домашняя" система - localhost (HOST)
проект qemu не стоит на месте, многие вещи меняются от версии к версии. нетерпеливые энтузиасты собирают эмулятор самостоятельно. шаблончик для сборки на Linux приведён ниже (для версии 0.10.3):
./configure --prefix=/usr --enable-system --enable-linux-user \
--audio-drv-list="oss alsa sdl esd" \
--audio-card-list="ac97 sb16 es1370" \
--enable-mixemu
make
sudo checkinstall
checkinstall генерит корректный пакет (спасибо всем, кто написал хороший Makefile).
ссылки на документацию о работе qemu с сетью:
официальное руководство. читать.
подробная инструкция от товарища "радиста" - может рассматриваться как некая общая "вводная".
осилив материал, можно узнать пару интересных вещей: slirp и vde (Virtual Distributed Ethernet). в теории vde должен упростить процедуру, изложенную ниже, путём соединения гостевой системы с сокетом, автосозданием "tap" интерфейса и установкой корректного FORWARD между всеми гостевыми системами. к сожалению готовых "рецептов" с использованием vde выдать пока не могу, ибо... если у кого работает эта схема - отпишитесь в комментариях или киньте ссылку на более подробные инструкции. использование же slirp не представляется целесообразным.
задача:
поднять несколько виртуальных машин с qemu и обеспечить не только их взаимодействие по "виртуальной сети" между собой, но и открыть им доступ к локальным сетевым ресурсам (интернет в том числе).
для её решения подойдёт практически любой дистрибутив Linux с установленными пакетами: iptables, qemu, kqemu, tunctl и bridge-utils. если вы долго и упорно настраивали iptables - то идея построения "моста" вам явно не понравится.
грузим необходимые модули ядра:
sudo modprobe -v tun
sudo modprobe -v kqemu
sudo chmod 666 /dev/net/tun
sudo chown `whoami` /dev/kqemu
последние две строки дают нам возможность не использовать рута для старта самого qemu, что кажется более логичным, чем "Запускать нужно от root'а, потому что иначе могут возникнуть проблемы с доступом к устройству /dev/net/tun ." угу, всё бросили и запустили от рута, хотя кому-то может так и легче.
запуск виртуальных машин довольно прост. стоит только запомнить, что каждой машине нужен отдельный "tap" интерфейс, соответственно имеет смысл помещать их в разные "подсети". например ("интерфейс tap" -> "локальный eth0, что мы потом поднимем в qemu"):
192.168.4.1 -> 192.168.4.100
192.168.5.1 -> 192.168.5.100
192.168.6.1 -> 192.168.6.100
использовать "глобальные" скрипты (/etc/qemu*) - не рекомендую, но это imho. каждый волен сам решать. если у вас не происходит присваивание уникальных MAC адресов "на лету" - то можете задать их вручную или поменять позже. простейший скриптец старта qemu:
#!/bin/sh
iface="tap0"
iface_addr="192.168.4.1"
user="`whoami`"
sudo modprobe tun
sudo modprobe kqemu
sleep 2
sudo chown $user /dev/kqemu
sudo tunctl -u $user -t $iface
sudo ifconfig $iface $iface_addr up
##sudo ifconfig $iface $iface_addr promisc up ## только для использования в "мостике" !!!
qemu -cdrom ./image.iso -boot d -hda ./disk.img -m 256 -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0,ifname=$iface,script=no
sudo ifconfig $iface down
#EOF
приказ отдохнуть пару секунд после загрузки модуля kqemu (если он ещё не загружен) для вас может быть излишним. маска сети 255.255.255.0 пойдёт автоматом. в "гостевой" системе необходимо и достаточно поднять сетевой интерфейс с номером в пределах заданного сегмента и проставить дефолтный шлюз, равный $iface_addr. для примера с "tap0" некие шаблонные действа в "гостевой" системе:
ifconfig eth0 down
ifconfig eth0 192.168.4.100 up
route add default gw 192.168.4.1
echo 'nameserver 192.168.4.1' >> /etc/resolv.conf
echo 'nameserver ВАШ_ЛОКАЛЬНЫЙ_ДНС' >> /etc/resolv.conf
echo 'nameserver BACKUP_ДНС' >> /etc/resolv.conf
для того, чтобы открыть гостевым машинам доступ в локальную сеть можно воспользоваться "маскарадом". допустим, что ваш локальный сетевой интерфейс - eth0. если интернет идёт по интерфейсам типа dsl0, ppp0 - то "маскарадить" надо и их (если хочется выйти в сеть из qemu плюс ко всему придётся подправить правила для FORWARD). имеем три интерфейса для qemu - tap0, tap1 и tap2. шаблон ниже не предполагает использование "brctl" - "мостиков". мы культурно разрешаем обмен пакетами (FORWARD) между всеми участниками праздничного шоу (используем 2 цепочки - forward_int и forward_ext).
su -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -t filter -I INPUT 1 -i tap0 -j input_int
sudo iptables -t filter -I INPUT 1 -i tap1 -j input_int
sudo iptables -t filter -I INPUT 1 -i tap2 -j input_int
sudo iptables -t filter -A input_int -j ACCEPT
sudo iptables -t filter -I FORWARD 2 -i eth0 -j forward_ext
sudo iptables -t filter -I FORWARD 2 -i tap0 -j forward_int
sudo iptables -t filter -I FORWARD 2 -i tap1 -j forward_int
sudo iptables -t filter -I FORWARD 2 -i tap2 -j forward_int
sudo iptables -t filter -A forward_int -i tap0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap0 -o tap1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap0 -o tap2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o tap0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o tap2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o tap1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o tap0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap2 -m state --state RELATED,ESTABLISHED -j ACCEPT
почему мы создаём FORWARD с номера 2? - потому, что первым правилом абсолютно корректно выставлять автоподстройку величины пакетов:
sudo iptables -t filter -I FORWARD 1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
теперь, когда у нас всё работает, все друг друга видят и пользуют ресурсы друг друга, настало время поиграть с "мостиками". идея крайне проста - "собирайтесь девки в кучу, я вам чучу отчебучу...". шаблонные действия примерно таковы: раскомментируем строку "sudo ifconfig $iface $iface_addr promisc up" (в скрипте вызова qemu) и закомментируем то, что было ранее. выгрузим все правила iptables, ибо основным интерфейсом становится бридж, и оне (енти правила) автоматом идуть далёко...
sudo ifconfig eth0 down
sudo ifconfig eth0 0.0.0.0 promisc up
sudo brctl addbr br0
sudo brctl addif br0 eth0 tap0 tap1 tap2
sudo brctl show
sudo dhclient br0 ## (или ручками настраиваем br0 как раньше был настроен eth0)
тихо матерясь переписываем правила всяких забавных софтинок типа "netams" для работы с "br0" и рихтуем iptables.
зачем нам это надо? чтобы где-то в два раза поднять пропускную способность сети для qemu. скорость аплоада в vsftpd доходила до 2.5 Mb/sec - это неплохо (у вас могут быть совершенно другие цифры!). да и возни в итоге поменьше, плюс получаем новую "игрушку" - brctl. а уж если vconfig ещё валяется рядом - то "гуляйте, Маша, воля ваша".
частный случай - объединить "мостиком" только "tap*" интерфейсы - в этом случае присваиваем руками адрес для "br0" и используем его вместо "tap*" для рихтовки таблиц маршрутизации.
P.S. не забываем о "командном" режиме работы (Ctl+Alt+2). могут пригодиться "host_net_add", "host_net_remove", "system_reset", "q"/"system_powerdown" и т.п.
*/
материалов на данную тему в сети - море. эта заметка не претендует на оригинальность. пригодится - хорошо, а нет - так ещё лучше. по сути рассматривается частный случай создания виртуальных сетей с использованием qemu, где все "клиенты" друг друга видят, умеют общаться, делиться ресурсами и т.п.
терминология:
"гостевая" система - система, загруженная с использованием qemu/(под управлением qemu) (GUEST)
"домашняя" система - localhost (HOST)
проект qemu не стоит на месте, многие вещи меняются от версии к версии. нетерпеливые энтузиасты собирают эмулятор самостоятельно. шаблончик для сборки на Linux приведён ниже (для версии 0.10.3):
./configure --prefix=/usr --enable-system --enable-linux-user \
--audio-drv-list="oss alsa sdl esd" \
--audio-card-list="ac97 sb16 es1370" \
--enable-mixemu
make
sudo checkinstall
checkinstall генерит корректный пакет (спасибо всем, кто написал хороший Makefile).
ссылки на документацию о работе qemu с сетью:
официальное руководство. читать.
подробная инструкция от товарища "радиста" - может рассматриваться как некая общая "вводная".
осилив материал, можно узнать пару интересных вещей: slirp и vde (Virtual Distributed Ethernet). в теории vde должен упростить процедуру, изложенную ниже, путём соединения гостевой системы с сокетом, автосозданием "tap" интерфейса и установкой корректного FORWARD между всеми гостевыми системами. к сожалению готовых "рецептов" с использованием vde выдать пока не могу, ибо... если у кого работает эта схема - отпишитесь в комментариях или киньте ссылку на более подробные инструкции. использование же slirp не представляется целесообразным.
задача:
поднять несколько виртуальных машин с qemu и обеспечить не только их взаимодействие по "виртуальной сети" между собой, но и открыть им доступ к локальным сетевым ресурсам (интернет в том числе).
для её решения подойдёт практически любой дистрибутив Linux с установленными пакетами: iptables, qemu, kqemu, tunctl и bridge-utils. если вы долго и упорно настраивали iptables - то идея построения "моста" вам явно не понравится.
грузим необходимые модули ядра:
sudo modprobe -v tun
sudo modprobe -v kqemu
sudo chmod 666 /dev/net/tun
sudo chown `whoami` /dev/kqemu
последние две строки дают нам возможность не использовать рута для старта самого qemu, что кажется более логичным, чем "Запускать нужно от root'а, потому что иначе могут возникнуть проблемы с доступом к устройству /dev/net/tun ." угу, всё бросили и запустили от рута, хотя кому-то может так и легче.
запуск виртуальных машин довольно прост. стоит только запомнить, что каждой машине нужен отдельный "tap" интерфейс, соответственно имеет смысл помещать их в разные "подсети". например ("интерфейс tap" -> "локальный eth0, что мы потом поднимем в qemu"):
192.168.4.1 -> 192.168.4.100
192.168.5.1 -> 192.168.5.100
192.168.6.1 -> 192.168.6.100
использовать "глобальные" скрипты (/etc/qemu*) - не рекомендую, но это imho. каждый волен сам решать. если у вас не происходит присваивание уникальных MAC адресов "на лету" - то можете задать их вручную или поменять позже. простейший скриптец старта qemu:
#!/bin/sh
iface="tap0"
iface_addr="192.168.4.1"
user="`whoami`"
sudo modprobe tun
sudo modprobe kqemu
sleep 2
sudo chown $user /dev/kqemu
sudo tunctl -u $user -t $iface
sudo ifconfig $iface $iface_addr up
##sudo ifconfig $iface $iface_addr promisc up ## только для использования в "мостике" !!!
qemu -cdrom ./image.iso -boot d -hda ./disk.img -m 256 -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0,ifname=$iface,script=no
sudo ifconfig $iface down
#EOF
приказ отдохнуть пару секунд после загрузки модуля kqemu (если он ещё не загружен) для вас может быть излишним. маска сети 255.255.255.0 пойдёт автоматом. в "гостевой" системе необходимо и достаточно поднять сетевой интерфейс с номером в пределах заданного сегмента и проставить дефолтный шлюз, равный $iface_addr. для примера с "tap0" некие шаблонные действа в "гостевой" системе:
ifconfig eth0 down
ifconfig eth0 192.168.4.100 up
route add default gw 192.168.4.1
echo 'nameserver 192.168.4.1' >> /etc/resolv.conf
echo 'nameserver ВАШ_ЛОКАЛЬНЫЙ_ДНС' >> /etc/resolv.conf
echo 'nameserver BACKUP_ДНС' >> /etc/resolv.conf
для того, чтобы открыть гостевым машинам доступ в локальную сеть можно воспользоваться "маскарадом". допустим, что ваш локальный сетевой интерфейс - eth0. если интернет идёт по интерфейсам типа dsl0, ppp0 - то "маскарадить" надо и их (если хочется выйти в сеть из qemu плюс ко всему придётся подправить правила для FORWARD). имеем три интерфейса для qemu - tap0, tap1 и tap2. шаблон ниже не предполагает использование "brctl" - "мостиков". мы культурно разрешаем обмен пакетами (FORWARD) между всеми участниками праздничного шоу (используем 2 цепочки - forward_int и forward_ext).
su -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -t filter -I INPUT 1 -i tap0 -j input_int
sudo iptables -t filter -I INPUT 1 -i tap1 -j input_int
sudo iptables -t filter -I INPUT 1 -i tap2 -j input_int
sudo iptables -t filter -A input_int -j ACCEPT
sudo iptables -t filter -I FORWARD 2 -i eth0 -j forward_ext
sudo iptables -t filter -I FORWARD 2 -i tap0 -j forward_int
sudo iptables -t filter -I FORWARD 2 -i tap1 -j forward_int
sudo iptables -t filter -I FORWARD 2 -i tap2 -j forward_int
sudo iptables -t filter -A forward_int -i tap0 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap0 -o tap1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap0 -o tap2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o tap0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap1 -o tap2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o tap1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_int -i tap2 -o tap0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t filter -A forward_ext -i eth0 -o tap2 -m state --state RELATED,ESTABLISHED -j ACCEPT
почему мы создаём FORWARD с номера 2? - потому, что первым правилом абсолютно корректно выставлять автоподстройку величины пакетов:
sudo iptables -t filter -I FORWARD 1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
теперь, когда у нас всё работает, все друг друга видят и пользуют ресурсы друг друга, настало время поиграть с "мостиками". идея крайне проста - "собирайтесь девки в кучу, я вам чучу отчебучу...". шаблонные действия примерно таковы: раскомментируем строку "sudo ifconfig $iface $iface_addr promisc up" (в скрипте вызова qemu) и закомментируем то, что было ранее. выгрузим все правила iptables, ибо основным интерфейсом становится бридж, и оне (енти правила) автоматом идуть далёко...
sudo ifconfig eth0 down
sudo ifconfig eth0 0.0.0.0 promisc up
sudo brctl addbr br0
sudo brctl addif br0 eth0 tap0 tap1 tap2
sudo brctl show
sudo dhclient br0 ## (или ручками настраиваем br0 как раньше был настроен eth0)
тихо матерясь переписываем правила всяких забавных софтинок типа "netams" для работы с "br0" и рихтуем iptables.
зачем нам это надо? чтобы где-то в два раза поднять пропускную способность сети для qemu. скорость аплоада в vsftpd доходила до 2.5 Mb/sec - это неплохо (у вас могут быть совершенно другие цифры!). да и возни в итоге поменьше, плюс получаем новую "игрушку" - brctl. а уж если vconfig ещё валяется рядом - то "гуляйте, Маша, воля ваша".
частный случай - объединить "мостиком" только "tap*" интерфейсы - в этом случае присваиваем руками адрес для "br0" и используем его вместо "tap*" для рихтовки таблиц маршрутизации.
P.S. не забываем о "командном" режиме работы (Ctl+Alt+2). могут пригодиться "host_net_add", "host_net_remove", "system_reset", "q"/"system_powerdown" и т.п.
*/
Подписаться на:
Сообщения (Atom)
