Причём добавили очень оперативно, буквально в тот же день когда в мэйл-листе обсуждали нужность этой фичи в свете редактирования 4k на не самых мощных машинах. Т.е. никаких чудес - фича была в Cinelerra-6 - так что это был «просто» порт ... Но скорость реакции разработчика(ов) (иногда их там аж 3) радует.

Да, и ещё я хвастаюсь новым подаренным монитором - всего 5700 руб и

[   325.453] (II) NOUVEAU(0): EDID for output DVI-I-1
[   325.453] (II) NOUVEAU(0): Manufacturer: GSM  Model: 5b01  Serial#: 5886
[   325.453] (II) NOUVEAU(0): Year: 2017  Week: 5

Наткнулся тут на эту парочку, в ходе разборок чем же таким сдвинуть обычный спектр человеческой речи «наверх» по частоте. На моей 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 :}

Собрал вот gImageReader 3.2.1 под свою Слаку. Раньше пользовался оным же через wine (!), ибо пересобирать tesseract было лень. В принципе slackbuild'ы нашлись для всего, кроме gtkspellmm3. Его пришлось собирать руками ....

setarch i486 ./configure --prefix=/usr CXX=«g++ -std=c++11»

потому как 64-битное ядро на 32-битной системе, и gcc пересобран до 4.8.4

Поскольку gtk3 приложений у меня до сего момента считай не было (тестовые сборки seamonkey вынудили поставить gtk3) - то я долго не мог понять, почему в окне проги отсутствуют иконки..оказалось, надо было ставить adwaita-icon-theme.

Итак, собрался я попробовать новый 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...

Раз уж появился скриншот с 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 мб оперативы - это ОЧЕНЬ медленно)