Раз уж появился скриншот с GNOME 2.30 - то и я решил выложить результат своей «работы». Почему-то все нынешние Live-образы уже не лезут на 700Мб болванку, да и в память лишние сотни мегабайт заталкивать не всегда хочется. Вот и собрал в своё время КДЕ 3.5.10 - под Slackware 13.37 + куча всего пересобрано - работает. А вот под Slackware 14.0/14.1 - вылетает конк при попытке подключится по https. Пересобирать ещё раз - лень, покамест. Ещё из неприятного - падает kompare. В образ влезла Мозилла - но она на 156 мб в виртуалке совсем неповоротливая (с zram). Закатал на маленькую (1 Гб) флэшку, но с немного более старым ядром. Всё-таки нынешние hybrid iso/usb образы не очень удобны - по-быстрому закинуть пару модулей, а то и просто всякое файло на флэшку не выйдет.

Единственное, чем замечателен LiveCD - это самосборным 3.19 с патченой overlayfs (на тот момент в ней ещё не было поддержки нескольких «нижних» уровней - патчики вошли в 4.0). Ну и linux-live-scripts под это дело были немного похаканы.

Надо будет посмотреть, заработает ли на ноуте старый kdebluetooth - раньше работал, а потом я обновил пакет с bluez (до 4.100+), и всё.

Читал про солнечно-парусный фэйл. Решил показать, что Линукс (ядро + юзерспэйс) вполне работают вообще без доступа на запись в единственную корневую ФС.

Запустил qemu-system-x86_64 -initrd /boot/initrd-319-x64.gz -kernel /boot/bzImage-3.19-x64 -m 32 -append «init=/bin/ash»

и.... оно не сработало. Т.е. сам-то рамдиск выплюнул меня в ash, но там уже всё в rw перемонтировано, и другое ненужное мне сделано.

Собственноручно созданный рамдиск нормально съел параметр, дал шелл. Полез разбираться. Кажется, что если идёт загрузка из initrd/initramfs то первым выполняется дефолтный /init, а уж затем - проверяется пользовательский вариант (и если тот не сработал - несколько запасных).

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c

Даже не знаю, баг это или фича.

Поставил NetBSD/sparc32 6.1.4 вовнутрь qemu из git. Работает, правда не в SMP-режиме. Для графики (Х сервер) пришлось добавить " -g 1024x768x24" в параметры запуска qemu.

В SMP-режме падает сам qemu:

guest@slax:~$ qemu-system-sparc  -hda /mnt/sdb2/QEMU-KVM_IMG/SPARC32-netbsd-6-4gb.img -boot c -m 512 -g 1024x768x24 -M SS-10 -smp 2
qemu: fatal: Trap 0x29 while interrupts disabled, Error state
pc: 00000000  npc: 00000004
%g0-7: 00000000 00001011 00000011 00000001 00000000 1fffff08 f0006000 00000001
%o0-7: f0002000 00000000 00000000 00000000 00000000 00000000 f9f13ef0 f004f2a8
%l0-7: 400010c7 f0009f80 f0009f84 00000000 00000000 00000001 f0002000 00000000
%i0-7: f9f12000 00000000 00000000 00000000 00000000 00000000 f9f13f50 f0009f6c
%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
psr: 400010c7 (icc: ---- SPE: SP-) wim: 00000002
fsr: 00000000 y: 00000000

Аварийный останов
guest@slax:~$

Ветка форума со скриншотом:
http://www.nextcomputers.org/forums/viewtopic.php?t=2642&start=270

код:
http://sourceforge.net/p/previous/code/HEAD/tree/

Приглашаются разработчики (там ещё в FPU баги видимо есть, нет эмуляции мыши и звукового ДМА..и много чего ещё нету. Но прогресс уже на мониторе!).

Решил посмотреть, что случится если в относительно старую Слакварь попробовать поставить (скомпилировать) что-то относительно свежее и ресурсоёмкое, типа MPlayer'а с его libavcodecs.

Обкусал 11-ю Слаку до примерно 700 Мб, еле влезло со всякими разработческими штуками и Х. Далее попробовал скомпилировать MPlayer-0.90 - облом на стадии линковки. Добавил ещё виртуальный диск, 250 Мб - и там распаковал MPlayer-1.0rc4. Он-то и собрался за 21 час. На 16 метрах. gcc 3.4.6, kernel 3.8 (! на хост-машине скомпилировал), glibc 2.3.6, X 6.9.0 . Конечно, на время компиляции ничего лишнего на машине не крутилось. Однако - с 50+ метрами виртуального свопа оно пережило и configure и make. Я был приятно удивлён.

Скриншот немного фэйковый - указанное видео на неускоренном qemu с хост-процессором вида Селерон-1ГГц конечно не играется иначе как слайдшоу. Но mencoder вполне позволяет перекодировать его в нечто играбельное, пусть даже 160*120*12 fps, ASV1/pcm (Со своих экспериментов с 486 запомнил параметры).

Всё дефолтное, кроме естественно MPlayer'а и невидимого героя - gcc. Под ядром 3.8 оно тоже играется, только старт иксовых приложений почему-то заметно медленнее.

Тот же MPlayer играет 320Kbps mp3 через libmad декодер с нагрузкой гостя примерно в 34-36%, а хоста - в 52-54%. Стандартная mp3lib тормозит и скипает звук - потому как softfloat никогда не бывает достаточно быстрым (старые версии qemu пропускали плавучку насквозь в режиме x86-on-x86, новые, типа этого 1.5.50 - эмулируют).

Стоит у меня Слакварь на винте, и ещё из одной я собрался liveCD делать (ибо основную сиcтему довёл до того, что она на CD не влезает, только на DVD). Решил воспользоваться документированной возможностью:

pkgtool --target_dir /mnt/hdd3/admin/cdrom_build/root

И ничего не произошло. Совсем. Полез в код, а там вроде как процессинг аргументов в if (arg) then (присваиваем значения) else основной блок кода. Т.е. без аргументов оно запускается, а с ними - только парсит, не запуская ничего?! Поправил:

--- pkgtool_orig/sbin/pkgtool   2011-03-07 18:14:54.000000000 +0000
+++ /sbin/pkgtool       2011-11-11 20:02:22.151645177 +0000
@@ -200,15 +200,16 @@
   -source_dir | --source_dir)
    SOURCE_DIR=$2 ; shift 2 ;;
   -target_dir | --target_dir)
-   TARGET_DIR=$2
-   ADM_DIR=$TARGET_DIR/var/log
+   TARGET_DIR=$2
+   ADM_DIR=$TARGET_DIR/var/log
    shift 2 ;;
   -source_device | --source_device)
    SOURCE_DEVICE=$2 ; shift 2 ;;
   esac
  done
-else  # there were no arguments, so we'll get the needed information from the
+#else  # there were no arguments, so we'll get the needed information from the
       # user and then go on.
+fi
  CMD_START="true"
  rm -f $TMP/SeT*
  while [ 0 ]; do

Там только пробелы лишние, их можно игнорировать. Вроде заработало?

У кого Слакварь - проверьте пожалуйста поведение оригинального pkgtool и патченного.

Однако phoronix запостил совершенно на первый взгляд первоапрельскую новость, про новую супер-быструю архитектуру ускорения на intel-овском драйвере.

Заглянул в xf86-video-intel - действительно, 53 килострочек с полотенцем описания. Обещают прирост скорости во многих операциях до 2 - 4 раз, (патологический случай - до 14 раз быстрее!) хотя есть и регрессии. И даже в 3d почему-то скорость поднялась (?)

World of Padman:
gen3 (800x600): 57.5 -> 96.2
gen4 (800x600): 47.8 -> 74.6

Суть - делать больше операций через 3-D hardware, а не через старый блиттер-интерфейс, который на сандибридж стал требовать всё больших затрат на синхронизацию. Второе новшество - основная работа по рендеренгу ведётся на CPU, и только в случае когда драйвер _абсолютно_ уверен в возможности аппартной акселерации на GPU (DRI and RENDER pixmaps) указанный GEM-объект переносится в видеопамять. Ещё там есть хитрый механизм подключения на лету пользовательских страниц, vmap - но он как я понимаю только на новых сандибридж-ах и работает. а вот остальное должно работать начиная с gen2 - i830

Коммит с описанием (требует патчей на Х сервер, их я пока не выудил):
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bcef98af5...

sna: Introduce a new acceleration model.

PS: This depends upon the Xorg patchset «Remove the cacheing of the last scratch PixmapRec»

Upd:
http://www.mail-archive.com/xorg-devel@lists.x.org/msg21428.html

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a9c85944427e3c4355bce67d7f6...

author   Alexander Strange
Thu, 2 Jun 2011 17:15:58

У кого cpu > 1 - проверьте, быстрее стал ?

Поставил вот ubuntu 10.04 на старый комп, ещё в AT-шном корпусе - cel-400Mhz/256Mb ram/10 GB hdd/TNT2 Vanta 8Mb.

Запускалось ОК.

Скомпилировал ядро 2.6.38 (с небольшой коррекцией для nouveau, на 8 мб дефолтный 1280x1024x32 фрэймбуффер съедал слишком много памяти - убавил для консоли глубину цвета до 8 бит) - пришлось добавлять параметр acpi=force в загрузчик.

Обновил libdrm/mesa/xf86-video-nouveau до версий из git (предварительно обновил X-овые пакеты до максимума, который был в https://launchpad.net/~xorg-edgers/+archive/ppa) . Обновил xserver до 1.9-branch (Сам скомпилял и забил поверх пакетного 1.8)

И вдруг понял, что у меня отвалился вентилятор на процессоре. Т.е. при старте машины он есть, а после запуска ядра - останавливается. С перегревом машины и её ребутом или подвисанием.

Ох, ши .... сказал я, полез в дебри /sys , нашёл там решение:

echo 1 > /sys/devices/LNXSYSTM\:00/subsystem/drivers/fan/PNP0C0B\:00/thermal_cooling/cur_state

Крутится теперь ....забил строчку в /etc/rc.local

Однако, Ubuntu не очень любит, когда я поверх работающих Х-ов начал новые ставить ... gdm перезапустился. Но в целом вроде работает, правда система уже слегка поломана моим checkinstall, нормальное заворачивание в deb со всеми зависимостями я пока не осилил.

Картинки оно не достойно, ибо дефолтный IceWM.

PS: а вот ещё ppa: https://launchpad.net/~lucid-bleed/+archive/ppa Всё-таки особо тяжелые пакеты лучше компилять на чём-нибуть побыстрее.

Я вот тут сижу и билдю .....

/mnt/test/deli-0.7.x-ports/ports/ap/sox/sox-12.17.9-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/rexima/rexima-1.4-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/ghostscript/ghostscript-7.07.1-i386-4.tgz
/mnt/test/deli-0.7.x-ports/ports/ap/nano/nano-2.0.6-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/base/tcp_wrappers/tcp_wrappers-7.6-i386-7.tgz
/mnt/test/deli-0.7.x-ports/ports/devel/libtool/libtool-1.5.22-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/net/links2/links-2.1pre28-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/dillo/dillo-i18n-0.8.6-i386-4.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/dillo/dillo-i18n-0.8.6-i386-5.tgz
/mnt/test/deli-0.7.x-ports/ports/xap/xchat/xchat-1.8.11-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/unrar/unrar-4.0.3-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/eject/eject-2.1.5-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/imagemagick/imagemagick-6.6.5-10-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/python/python-2.7.1-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/texinfo/texinfo-4.13a-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/apr/apr-1.4.2-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/opt/neon/neon-0.29.5-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libpcre/libpcre-8.11-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/readline/readline-6.1.2-i386-2.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libgmp/libgmp-5.0.1-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libmpfr/libmpfr-3.0.0-p8-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/libmpc/libmpc-0.8.2-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/make/make-3.82-i386-1.tgz
/mnt/test/deli-0.7.x-ports/ports/core/db/db-4.8.30-i386-1.tgz

И куда бы это всё залить, чтобы добро не пропадало? (всё под Deli 0.7.2)

Поставил вот на стол «четвёрку», в неё - винт с Deli Linux 0.7.2 (старая версия, там в основном gtk1 используется). После долговременного (месяц) отсутствия интернета оплатил-таки счета и теперь могу наконец попробовать это дело в сети. Пока работает, не быстро, но mp3 с пониженным качеством слушать можно, да и картинка через isa-шный trident 9000i не настолько плоха, правда некоторые приложения gtk1 серьёзно страдают от недостатка цветов в палитре (256 всего)

Машина в целом работает, даже вот links2 скомпилировался прямо на гигабайтном винте, с шестнадцатью метрами оперативки и пятьюдесятью - свопа. Осталось настроить почту. И самое смешное - mplayer может играть пережатые до 160x120 видеоролики, с 15 кадрами в секунду и 22050 hz (частота дискретизации) стерео звуком в pcm! Для звука стоит pci-ный sb live, опять же на pci сетевой контроллер, винт даёт на чтение прмерно 3 мб/c , но dma насколько я понял на этой материнке для ide устройств просто нет. Так что нагрузка на процессор гораздо выше, чем в идеальном случае.

Поиск по ЛОРу показал наличие тем с данной машиной , но вот этого кажется ещё не было:

http://www.phantom.sannata.ru/forum/index.php?t=4189&a=stdforum_view&o=&st=60

Один московский товарищ запустил на этой штуке портированный Linux 2.0.36

который (с сырцами) тут (до сих пор): http://ftp.stu.neva.ru/besta/linux-src/

в общем далее по ветке всплыла идея организовать сайт про этот самый (к сожалению, полностью на иностранных комплектующих, как выясняется) советский компьютер, где в качестве сервера будет одна из двух «Бест». Может кто-то с ЛОРа (Мск) захочет заглянуть на огонёк к ретрокомпютерщикам? А предполагаемому положительному результату мы все порадуемся... Кстати, в недрах staging насколько помню как раз есть (пилится) поддержка шины VME, может действительно кто-то на 2.6 портирует все наработки? Особенно весело было бы fb драйвер сделать, описание программирования видеоконтроллера (даже двух) вроде бы есть ....

Решил вот запостить скриншот своей «новой» четвёрочки, которая на удивление неплохо справилась с компиляцией браузера из набора портов для Deli Linux 0.7.2 (dillo-i18n-0.8.6-i386-4). ЛОР слегка непрвычный в 640x480x256 , но читать можно. А вот как поместить картинку - загадка (для меня). Сейчас соберём links2, может оттуда получится (огнелис на 16 мб оперативы - это ОЧЕНЬ медленно)

http://lkml.org/lkml/2010/11/12/344

Насколько я понял, эта версия не самая оптимальная, но скорость чтения поднимает в 1.4 раза на четырёхядерном процессоре, скорость записи - до 2-х с лишним раз быстрее. Поддерживаются шифрованные разделы поверх шифрованных разделов. Да, тест в сообщении был с CFQ, говорят для dm-crypt сейчас это не самый оптимальный шедулер ввода-вывода.

Что-то не везёт мне с udev-ом. Собрал самую новую версию, из git (http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=560de575148b7efda3... - Use ata_id, not scsi_id, on ATAPI devices), через немного подпиленный SlackBuild - всё равно при старте не было правильной группы на /dev/hda (cd-dvd-rw привод). Путём манипуляций с копированием 50-udev-default.rules, 60-cdrom_id.rules в /etc/udev/rules.d и псоледующим редактированием на предмет замены sr* на hd* там где было что-то про cdrom, плюс добавил в 50-udev-default.rules ATTRS{media}==«cdrom» в соответствующее правило:

--- /lib/udev/rules.d/50-udev-default.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/50-udev-default.rules 2010-11-06 02:42:53.000000000 +0300
@@ -75,7 +75,7 @@
SUBSYSTEM==«block», KERNEL==«fd[0-9]», GROUP=«floppy»

# cdrom
-SUBSYSTEM==«block», KERNEL==«sr[0-9]*», SYMLINK+=«scd%n», GROUP=«cdrom»
+SUBSYSTEM==«ide», KERNEL==«hd[0-9]*», ATTRS{media}==«cdrom», SYMLINK+=«cdrom%n», GROUP=«cdrom»
SUBSYSTEM==«scsi_generic», SUBSYSTEMS==«scsi», ATTRS{type}==«4|5», GROUP=«cdrom»
KERNEL==«pktcdvd[0-9]*», GROUP=«cdrom»
KERNEL==«pktcdvd», GROUP=«cdrom»


--- /lib/udev/rules.d/60-cdrom_id.rules 2010-11-05 23:35:57.000000000 +0300
+++ /etc/udev/rules.d/60-cdrom_id.rules 2010-11-06 02:04:21.000000000 +0300
@@ -2,10 +2,10 @@

ACTION==«remove», GOTO=«cdrom_end»
SUBSYSTEM!=«block», GOTO=«cdrom_end»
-KERNEL!=«sr[0-9]*|xvd*», GOTO=«cdrom_end»
+KERNEL!=«hd*|xvd*», GOTO=«cdrom_end»
ENV{DEVTYPE}!=«disk», GOTO=«cdrom_end»

-KERNEL==«sr[0-9]*», ENV{ID_CDROM}=«1»
+KERNEL==«hd*», ENV{ID_CDROM}=«1»
IMPORT{program}=«cdrom_id --export $tempnode»

LABEL=«cdrom_end»


Но после этого /etc/rc.d/rc.udev reload не помогло, а вот после запуска udevadm test /devices/pci0000:00/0000:00:11.1/ide0/0.0/block/hda (путь был найден запуском udevadm info -q path -n /dev/hda) всё нужные симлинки появились, группа для /dev/hda - «cdrom», не дефолтный «disk». Соответственно k3b работает.


Кто-нибудь может проверить, дефолтный udev-164 (или лучше - git-версия) на ядре с old deprecated ATA drivers тоже имеет косяки с ide cd-rom/rw ?

http://blog.martin-graesslin.com/blog/2010/10/optimization-in-kwin-4-6/

Обещают ускорение работы фильтра Lanczos, который сильно усложняет жизнь пользователям в 4.5 (фильтр не будет фильтровать все окна на экране, а только те, которые нужно). Обещают ускорение работы этой прыгающей анимации «приложение сейчас, вот-вот, ещё-чуть-чуть, запусти-и-ится». (которая с какого-то перепугу раньше превращалась в RGB окно без альфа-канала). Из общего есть (ну, или должно быть в trunk) кэширование текстур и геометрических данных, использование TFP (texture-from-pixmap, блин, а раньше-то они через что делали?! ЭТо TFP уже четыре года как известно .....) что должно избавить от медленных преобразований между QPixmap/QImage. Эффекты трансформации _одного_ окна вызывали перерисовку _всего_ экрана. Должно быть «фиксед», в новой версии. Правда, все плагины придется переделать, один за одним, чтобы получить желаемый эффект.

Тема «ускорить blur-эффект» оставлена примерно до 4.7

Итак, продолжая злостные эксперименты, собрал udev-153 с патчем

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=665ee17def2caa6811...

«udevd: always try to find an idle worker instead of forking a new one»

(на новый удав - новые грабли наступать пока не охота)

Но это не помогло - на моём достаточно модульном конфиге сразу после старта udev всё замирает, с mem=32m. С mem=36m - идет до текстового логина, как и положено. Workaround с ранним подключением физического своп-файла не очень хочу использовать, ибо тормоза, а виртуально-сжатый через zram не очень-то и помогает, на таких малых объемах памяти. Отсюда вопрос: а что делает ваша система, если попытаться её загрузить с такими же параметрами: mem=32m ?

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

Кажется, в логике работы с чипами, где vram < pci bar size была ошибка, приводящая к этим подвисаниям. У меня карточка с такими же параметрами (64 vram, 128 PCI BAR) - но вроде особых подвисаний за пару дней не видел. Кто хочет - может потестить последний патч, https://bugs.freedesktop.org/attachment.cgi?id=39651 а я пока подумаю, как бы подвесить свою машину, м.б. agpmode=-1 поможет.

http://www.liveinternet.ru/users/ilya_chernykh/post129345101/

Выглядит оно конечно хорошо, но есть вопросы:

1. Оно же на qt2. Патчи по безопасности на это вроде уже никто не делает, как и на сам KDE2 ?

2. Управление оборудованием: xrandr 1.2, энергосбережение, управление частотой процессора .... ? Из GUI, имеется в виду. Кто-то эту функциональность добавляет, как для Trinity ?

3. Автоопределение подключаемых устройств, удобное задание опций монтирования? (на КДЕ3 на это дело патч был, не принятый в свое время в основную ветку. Ибо слишком много элементов управления добавлял, для stable это считалось неприемлемо.)

4. Эпичные баги ? :}

После собственноручного обрушения бОльшей часть КДЕ-шных прог - пересобрал их заново на своей (почти) -current Slackware.

Среди прочего был k3b 1.0.5

Он с некоторых пор повадился подвисать при проверке DVD проекта. Вот баг. http://bugs.kde.org/156684

В нём , в комментарии 30 есть патч. Но я его не использовал, а использовал другой, отсюда:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-cdr/k3b/files/?hi...

k3b-1.0.5-eject_186173.patch

Вроде бы маленький проект записал и проверил нормально. Если кто-то ещё использует старый k3b для KDE3 - отпишитесь, какой из патчей у вас работает лучше?

Там ffmpeg патчи ещё есть, для них я запускал autoconf, а для нового autoconf-2.64+ оказывается нужен патч, примерно как тут:

http://developer.berlios.de/bugs/?func=detailbug&bug_id=16635&group_id=4482

http://git.altlinux.org/people/drool/packages/?p=sim.git;a=blob;f=sim-0.9.5-f...

На самом деле сейчас этот патч уже в svn репозитарии sim-im (я побаивался оттуда обновляться - но там к счастью оставили старый код для КДЕ3, не выкорчёвывая его поддержку, а всё новое переехало куда-то на mercurial )

ПС: придётся-таки через какое-то время переезжать на КДЕ4 проги, сам-то кде3 в виде ТДЕ продолжает развитие, как я смотрю, но вот все дополнительные внешние проги (k3b, digikam, нелинейный видеоредактор ) - всё уехало на qt4/kdelibs4 :/ А оно и места ест больше, и компилируется дольше, и внешний вид не в моём вкусе, по крайней мере дефолтный.