Тема периодически всплывает, и тонет в упрощении. Наверное, хорошие люди, это которые стараются не делать другим плохо, в кратко-, средне- и долгосрочной перспективе. И весь их разум направлен на такую вот цель. Соотв., в обществе подобных..существ взаимопомощь вполне работает, а не как сейчас - ты делаешь кому-то хорошо, потом ещё кому-то, потом ещё кому-то..а в ответ ..хорошо если тишина. Но как таких людей делать? В реале наверное два основных фактора играют роль - отсутствие силы воли (признать свои ошибки, указать на ошибку друга...и остаться при этом друзьями, но исправив ошибку) это раз, а два...давление среды (или внутренее) которое никакой силой воли не поправить. наверное, именно из-за второго один современный писатель рекомендовал за попытку создания такой структуры подавления - ВМГС ((анти)утопии про Меганезию). С первым фактором ещё кажется можно что-то поделать..но..это требует неожиданно неожиданного упорства на протяжении ..ну как минимум пока дети вырастут (лет 15, не меньше). Причём во многих областях жизни, а не только в 1-2-х. Ну и вообще по большей части не понятно, что такое хорошо. Ещё недавно под «хорошо» понимали нечто, что я сейчас иначе чем махровым антропоцентризмом и назвать не могу. Так что моральный (? может лучше эмпатический или как-то так) прогресс по ходу необходим, как и реальная широта (х глубина) мышления. Причем с этическим (добрым) уклоном, когда этика боолее важна, чем скорость результата. Без внутренней честности ничего не получится, а у нас похоже умеют только выдрессировывать внешние признаки. Хорошие книги-мультики-фильмы это хорошо, но если вокруг - пц, нисколько не похожий на то, как должны жить люди - все это не поможет. Не думаю, что на ЛОРе кто-то любит задумываться поглубже на такие темы - но пусть будет ..в толксах.

Вот пара ссылок, из относительно недавнего:

https://theanarchistlibrary.org/library/the-anarchist-faq-editorial-collectiv...

http://rethinking-our-reality.blogspot.ru/2014/03/mobilizing-green-imaginatio...

http://www.derrickjensen.org/endgame/

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

Наткнулся тут на эту парочку, в ходе разборок чем же таким сдвинуть обычный спектр человеческой речи «наверх» по частоте. На моей 32-bit Slackware компилится и что-то делает, но Pi нету сейчас. Тут вроде пара товарищей всяким радио- и около того любительством занимаются - не подскажите, работает эта штука на низких (30-40 килогерц) частотах? В readme одно, в help'е другое, в коде вроде спецпроверок нет...

https://github.com/simonyiszk/csdr

https://github.com/F5OEO/rpitx

«rpitx is a radio transmitter for Raspberry Pi (B, B+, PI2, PI3 and PI zero) that transmits RF directly to GPIO. It can handle frequencies from 5 KHz up to 500 MHz.»

------

~/botva/src/rpitx$ rpitx

rpitx -0.2
Usage:
rpitx [-i File Input][-m ModeInput] [-f frequency output] [-s Samplerate] [-l] [-p ppm] [-h]
-m            {IQ(FileInput is a Stereo Wav contains I on left Channel, Q on right channel)}
              {IQFLOAT(FileInput is a Raw float interlaced I,Q)}
              {RF(FileInput is a (double)Frequency,Time in nanoseconds}
              {RFA(FileInput is a (double)Frequency,(int)Time in nanoseconds,(float)Amplitude}
              {VFO (constant frequency)}
-i            path to File Input
-f float      frequency to output on GPIO_18 pin 12 in khz : (130 kHz to 750 MHz),

Потому как konqueror из кде 3.5.10 отвалился, пришлось патчить:

https://git.trinitydesktop.org/cgit/tdelibs/commit/?id=45cf7d13

Из плюсов - заработали (т.е. стали видны) сайты типа https://makefx.wordpress.com/ и https://base-n.de/webm/VP9 Sample.html (видео на них тут не работает, но хоть текст виден).

Ура ЛОР! ты заставил меня снова пересобрать kdelibs :}

Итак, собрался я попробовать новый qemu с virgl
много всего собрал

Ядро - 4.5.0-rc3 под x86_64 с overlayfs и squashfs
Месу - commit 0bba5ca468cdcd1f6f9bb6736c8a75e43fbe0cd5 (OpenGL version string: 3.0 Mesa 11.2.0-devel (git-0bba5ca))
libepoxy 1.3.1 из слакбилда
virglrenderer - commit 7b776ec86658d1efeff8b92956a2f4b19c54e58c
qemu - commit a5af12871fd4601c44f08d9e49131e9ca13ef102 (Configured with: './configure' '--prefix=/usr' '--disable-gtk' '--enable-virglrenderer' '--enable-sdl' '--with-sdlabi=2.0' '--audio-drv-list=alsa,oss' '--host-cc=/opt/gcc49/bin/gcc' '--enable-opengl' '--extra-cflags=-O3 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized' - а при arch i486 оно не линковалось!)

SDL2 2.0.4 - из слакбилда.

И ..всё это НЕ заработало, крашилось!

Оказалось, нужно X server новее моего 1.12.x, видимо с поддержкой GLX_ARB_create_context, GLX_ARB_create_context_profile , а иначе все крашилось при попытке qemu начать использовать видеоадаптер даже в консоли (при загрузке в госте соотв. drm драйвера). Собрал новый Х-сервер, 1.18.1 Запускаю, уже не крашится, но и внутри что-то не работает. Оказалось, для гостя нужно Х сервер с поддержкой glamor для драйвера (встроенного) modesetting, а при сборке по умолчанию этого не происходило. Добавил --enable-glamor при конфигурации X server'а , закинул получившийся сервер на liveDVD, и наконец-то!

./x86_64-softmmu/qemu-system-x86_64 -cdrom /home/admin/slaxdvd-4.5.0-x64-test.iso -m 512 -display sdl,gl=on -enable-kvm -soundhw es1370 -usb -vga virtio -usbdevice mouse -cpu host

Заработало! Мышка правда почему-то внутри гостя бесилась, пока не указал usb mouse. И ещё, если на /dev/shm юзер, от которого делали startx и запускали сессию и проги не имеет прав записи - всё, связанное с dri3 (!) будет сегфолтится. Сам Х-сервер в моём случае видимо выживал за счет suid-бита. Это всё без systemd и прочих - на сильно проапгрейженой Слаквари.

Но увы, не работает пока это на nouveau/nv50 толком. Колёсики glxgears крутятся, а вот та же seamonkey превращается в мешанину из текста и артефактов.

http://ibin.co/2XCIj5vhR9l8

при LIBGL_ALWAYS_SOFTWARE=1 перед стартом qemu - всё становится медленно-медленно, зато без артефактов.

Для начала на gcc-4.8 оно вываливалось с недостатком памяти для компилятора:

http://mail-index.netbsd.org/pkgsrc-users/2015/05/01/msg021500.html http://lists.opensuse.org/archive/opensuse-bugs/2013-10/msg00261.html

реальный параметр -fno-diagnostics-show-caret - добавил его в CXXFLAGS

Потом наткнулся на ошибку компиляции в глубине kopete: https://forums.gentoo.org/viewtopic-t-888996-start-0.html

оттуда был выдран патч, и приведён к такому виду:

diff -u a/kopete/libkopete/avdevice/videodevice.h b/kopete/libkopete/avdevice/videodevice.h
--- a/kopete/libkopete/avdevice/videodevice.h   2012-04-03 22:50:35.000000000 +0200
+++ b/kopete/libkopete/avdevice/videodevice.h   2012-04-03 22:46:25.000000000 +0200
@@ -52,7 +52,7 @@

 #include <linux/fs.h>
 #include <linux/kernel.h>
-#include <linux/videodev.h>
+#include <libv4l1-videodev.h>
 #define VIDEO_MODE_PAL_Nc  3
 #define VIDEO_MODE_PAL_M   4
 #define VIDEO_MODE_PAL_N   5
--

Да, видать не пользовался я совсем утилитками этими - такой баг пропустил!

Bug: https://bugs.kde.org/show_bug.cgi?id=172706

Оригинальный патч от АЛЬТ'а (для kdeutils 3.5.8) не накладывается, обошёлся таким минимумом:

--- ark/sevenzip.cpp.orig       2007-01-15 14:25:37.000000000 +0300
+++ ark/sevenzip.cpp    2015-09-13 12:38:50.821528560 +0300
@@ -40,6 +40,8 @@
 #include "arkutils.h"
 #include "filelistview.h"

+#include <qtextcodec.h>
+
 SevenZipArch::SevenZipArch( ArkWidget *gui, const QString &filename )
   : Arch( gui, filename ), m_nameColumnPos( -1 )
 {
@@ -241,14 +243,17 @@
   }
 }

-bool SevenZipArch::processLine( const QCString& _line )
+bool SevenZipArch::processLine( const QCString &_line )
 {
-  QCString line( _line );
+  QString line;
   QString columns[ 11 ];
   unsigned int pos = 0;
   int strpos, len;

-  columns[ 0 ] = line.right( line.length() - m_nameColumnPos +1);
+  QTextCodec *codec = QTextCodec::codecForLocale();
+  line = codec->toUnicode( _line );
+
+  columns[ 0 ] = line.right( line.length() - m_nameColumnPos);
   line.truncate( m_nameColumnPos );

   // Go through our columns, try to pick out data, return silently on failure
@@ -275,6 +280,8 @@
     columns[ curCol->colRef ] = line.mid( strpos, len );
   }

+  // Separated directories pass
+  if(columns[4].length() && columns[4][0] == 'D') return true;

   if ( m_dateCol >= 0 )
   {

Источник дополнительного вдохновения: https://git.trinitydesktop.org/cgit/tdeutils/commit/ark/sevenzip.cpp?id=1c849...

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

Запустил 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

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

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

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

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

Стоит у меня Слакварь на винте, и ещё из одной я собрался 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)

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

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 поможет.