Из мана:

FbTerm supports xterm's 256 color mode extension.

пробую:

TERM=fbterm colortest-256

P.S. Debian Wheezy, Fbterm 1.7

В очередной раз возникает ситуация, когда руки заняты/грязные, а не раз выручавшую в сходных ситуациях резиновую клавиатуру некуда приткнуть/есть большая вероятность её повредить.

Я так подумал, было бы замечательно иметь надеваемую беспроводную клавиатуру. Ремень на запястье, 5-6 больших кнопок. В особо тяжёлых случаях (руки в гсм, краске, эпоксидке, кислоте, щёлочи и т.д.) можно развернуть на внутреннюю сторону руки и нажимать носом.

Может кто-нибудь видел подобные устройства?

Что-то меня моё гугл-фу подводит: сплошные рекламные статьи и неинформативные мнения.

Кто-нибудь пользуется? В чём разница с обычной щёткой? Какова вообще область применения?
Склоняюсь к мнению, что ерунда.

// Обладатель отличных зубов и пользователь мягких щёток.

Дисклеймер: дропнул ATI в непомню-каком-году (HD3650 была последней, кажется). Блоб на тот момент вешал систему намертво по любому поводу и без, для профилактики. OSS дрова могли в 2D.

Сейчас у родственников приставился GeForce GT210, возможно стоит рассмотреть предложения от ATI/AMD?

Требования:
* низкая цена
* аппаратное ускорение воспроизведения видео
* базовое 3D (kwin, GoogleEarth, supertuxkart)
* пассивное охлаждение
* всё это на изкоробочных драйверах из debian wheezy (не важно, свободных или блобе)

Для примера, вот вариант, который я собираюсь порекомендовать:
http://market.yandex.ua/model.xml?modelid=8264189&hid=91031

Просто предупреждение:
В бекпортах сейчас лежит фирмварь iwlwifi-6000g2a-6.ucode, после установки которой, адаптер «Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)» больше ~200 кб/с выжать не может.

Откат на стабильную прошивку решает проблему.

Debian Wheezy, все компоненты из репозитория. Пытаюсь интегрировать guile в emacs аналогично python: возможность отправлять куски кода или целые модули в repl, автодополнение в repl и т.д.

Связка guile-2.0 и geiser практически неработоспособна: например после смены контекста интерпретатора на текущий модуль (C-c C-a), вызов функции из модуля заканчивается так:

scheme@(guile-user) [188]> (abs x)
;;; <stdin>:198:0: warning: possibly unbound variable `x'
<unnamed port>:198:0: In procedure #<procedure 3c2df80 at <current input>:198:0 ()>:
<unnamed port>:198:0: In procedure module-lookup: Unbound variable: x

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [189]>

Doesn't work for everyone or just me.com?

P.S. Ещё сейчас заметил, что guile съел уже 80Мб ОЗУ.

Вот и настала моя очередь добавить тред на платиновую тему проблем с этой проприетарщиной.

Debian 7 i386, skype 4.1.0.20-1, ao: alsa.

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

Звук во время звонков нормальный, проблема только с уведомлениями.
Как ни странно, на amd64 инсталляциях воспроизвести не могу, отсюда тег i386.

Есть ли здесь люди с аналогичной проблемой (или системой, просьба протестировать)?

Система: Debian Wheezy

Зарегистрировался на gogo6/freenet6, поставил из main gogoc. Настроил, подключился.

Вроде заработало:

aidaho@aidaho-laptop:~$ ping6 ipv6.google.com
PING ipv6.google.com(bud02s02-in-x11.1e100.net) 56 data bytes
64 bytes from bud02s02-in-x11.1e100.net: icmp_seq=1 ttl=54 time=84.4 ms
64 bytes from bud02s02-in-x11.1e100.net: icmp_seq=2 ttl=54 time=187 ms
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2002ms
rtt min/avg/max/mdev = 84.459/135.790/187.122/51.332 ms

В чём может быть проблема?

С помощью какого инструмента можно визуализировать картину наследования классов? Интерактивная привязка к коду, пожалуй, не нужна, достаточно статической диаграммы с минимумом информации: методы, атрибуты.

Прелюдия: некоторое время назад заметил, что диски на домашней файлопомойке больше не останавливаются после часового периода простоя, как предписано в /etc/hdparm.conf. Проблема решилась быстро путём увеличения poll interval до 60 минут у smartd и уменьшением времени простоя до остановки до 30 минут.

Однако один из винчестеров рестартует сразу после остановки, но если остановить вручную, то продолжает спать. Как понять, что его раскручивает? Изменённых файлов на нём нет.

Используется редко, в принципе является белой вороной: последний ata-винт, единственный с ext4. Но раньше точно без проблем останавливался.

/etc/hdparm.conf:
...
/dev/disk/by-id/scsi-SATA_WDC_WD800JB-00FWD-WMAJ93715938 {
        spindown_time = 241
#        keep_features_over_reset = on
}

/etc/fstab:
...
# /mnt/western was on /dev/sda1 during installation
UUID=6db59787-cffa-4b88-aa02-55611d876a38 /mnt/western    ext4 noexec,nosuid,nodev,relatime,barrier=1,errors=remount-ro        0       2

As you may know Dan Vrátil and I are working in a brand new screen manager that will solve most of the issues that we currently have on the desktop, making the configuration of monitors either auto-magical or super simple.
>We are trying be as smart as possible adapting the behavior of it to each use case making the configuration of monitors as simple as plugging them to your computer.
http://www.afiestas.org/screen-management-got-magic/comment-page-1/

tl/dr: появилась надежда на юзабельную поддержку нескольких видеовыходов одного видеоадаптера с хотплагом и минимумом телодвижений. Смотрите видео.

Слава пингвинам!

Заметил в логах необычное:

Nov  3 16:09:55 aidaho-desktop smartd[2820]: Device: /dev/sdc [SAT], starting scheduled Long Self-Test.
...
Nov  3 16:39:53 aidaho-desktop smartd[2820]: Device: /dev/sdc [SAT], self-test in progress, 90% remaining

Extended offline    Self-test routine in progress 90%     11659         -

Есть тут владельцы

Model Family:     Seagate Barracuda 7200.10 family
Device Model:     ST3250620AS
Serial Number:    9RT03DFM
Firmware Version: 3.AAJ
User Capacity:    250.058.268.160 bytes

Хочется узнать, это проблема конкретного винта/серии/прошивки или чудит именно этот экземпляр?

Тихо и незаметно готовится к выходу багфикс-релиз за номером 3.5.13.1, но мы то знаем!

В настоящее время апдейт растаскивается по зеркалам, пока не обновляйтесь, ждите официального объявления.

Некоторые из пофикшенных багов:

• Много изменений в блокировке экрана, к примеру теперь она прячет все дисплеи;
  
• krandrtray переключает выводы ещё быстрее;
  
• kickoff разучился падать;
  
• kdm_greet больше не ест 100% цпу;
  
• sftp kio_slave теперь работает и со свежим openssh;
  
• tdesu теперь может запоминать пароль
  
• настройки будут корректно подхватываться, даже если в пути к домашней директории есть пробелы (признавайтесь, у кого хомяк с пробелом?);
  
• частично решена проблема с долгим (7-15 сек.) завершением сеанса;
  
• пофикшены какие-то проблемы с utf8 на webdav (у меня всё работало);
  
• на konqueror наложен пролежавший 7 лет в багзилле kde патч, который фиксит отсутствие обновления панелей в соотвестствии с изменениями в файловой системе в некоторых ситуациях;
  
• файлы в директориях XDG AUTOSTART больше не смогут стартовать несколько раз;
  

Так же перетасовано меню, KControl, какие-то фиксы/изменения в копыте, kdepim и прочей ерунде, которая меня не интересует. Полный список здесь:
http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13_1_C...

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

Последние полгода, после освоения слепой печати, плавно движусь в сторону keyboard-only десктопа маршрутом kwin на хоткеях, emacs, opera+elinks на унифицированных хоткеях. Наверняка многие уже эволюционировали в этом направлении, хочу послушать истории успеха.

Технический вопрос: хочу избавиться от стрелок, emacs-like навигация немилосердна к рукам, вимовский hjkl выглядит лучше. Можно ли зафорсить этот вариант на уровне иксов, чтобы работало во всех текстовых полях?
man readline намекает, что добиться желаемого в консоли проще простого.

Посоветуйте англоязычное ололотехническое сообщество (с регистрацией, без смс, кармы и рейтингов) с традициями правописания и минимумом форчрнгосленга.
Технический формат не важен (jabber, irc, mailing list etc.).

В общем-то я уже прикрутил к tmux почти всё, что у меня было в screen, за исключением нескольких вещей.

Не могу разобраться, как заставить в выражении new-window command интерпретировать command с помощью bash, а не sh, который в debian указывает на dash, который в свою очередь показывает вывод, пропущенный через пайп, только после того, как завершатся все процессы, соединённые через пайп.
На $SHELL он не смотрит.

Одна из совершенно непонятных фич tmux: при перечитывании конфига он пытается повторно выполнить все команды new-window (это нормально), те из них, для которых задан номер окна -t n, который уже занят, ругаются на это и... тоже выполняются без создания видимого окна в какой-либо из сессий.
Как объяснить (и отключить) такое поведение? Если отрапортовал об ошибке, то зачем выполнять команду? Если таки решил выполнять, то где моё окно? Просто висят процессы в памяти и всё.

Дистр: Debian Squeeze.

Машина с работающим dmix, с выводом звука из нескольких источников никаких проблем.
За исключением mpd: когда начинается воспроизведение, он намертво хватает устройства вывода и больше звука нет нигде. Mplayer, например, жалуется:

[AO_ALSA] alsa-lib: pcm_hw.c:1293:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' failed (-16): Device or resource busy
[AO_ALSA] alsa-lib: pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
[AO_ALSA] Playback open error: Device or resource busy
Failed to initialize audio driver 'alsa'
Could not open/initialize audio device -> no sound.
Audio: no sound

audio_output {
        type            "alsa"
        name            "ALSA Device"
        device          "hw:0,0" 
}

audio_output {
        type            "alsa"
        name            "ALSA Device"
}

Давно хотелось поднять тему того, как священные принципы Unix гниют и разлагаются под тяжестью новых сущностей в виде протоколов, api и прочего мусора.
Но написать больше и лучше, чем Tonnerre Lombard, вряд ли получится, поэтому предлагаю почитать оригинал.

The destructive desktop — Linux in trouble?

Linux on the desktop has come a long way. The Gnome and KDE communities have built themselves a big, very powerful set of tools to build on. And using these tools, they created an enormous amount of software for a large number of different purposes.

Then they discovered that there is a lack of formality in the RPC mechanisms available under UNIX like operating systems. The Shared Memory IPC provides just shared memory and a little flow control, which is tedious. The sysvmsg API is still very inconvenient when communicating between various different processes, especially if they're arbitrary. Sockets work much better in that respect and have a well-defined API, but it is still relatively hard to exchange data over them.

http://blog.ngas.ch/archives/2011/12/13/the_destructive_desktop__mdash_linux_...

С моей точки зрения Поттеринг и другие товарищи, которых он затмил своей славой, сейчас выступают в роли змия, искушающего променять целостную инженерную философию на сиюминутные фантики. В долгосрочной перспективе ими вымощена дорога в ад, но многие, судя по всему, на это согласны.

Разбавлю УГ и просто дефолт на базе Trinity своим рабочим столом.
В текущем виде окружение без изменений существует около полугода, после окончания вялотекущего романа с четвертокедами, закончившегося фейлом.

DE всячески заточено под 9" экрана Asus Eee PC 901:

• Всё управление окнами — на хоткеях.
• Размер и положение окон прописаны в правилах для kwin. Поведение по умолчанию для неизвестных главных и диалоговых окон — максимизациия.
• Приложения, по возможности, так или иначе допилены в сторону более эффективного использования экранного пространства. На скриншоте видна недоделанная тема для Opera и всякое, по мелочи. Видоизменённых приложений море, все не вспомнишь и не покажешь. Пара основных принципов:
  • Выбросить все распространённые элементы и повсесить их на унифицированные хоткеи.
  • Меню не нужно.
• Запуск приложений с помощью Katapult. Рабочие столы — пустые. Кнопочка меню на панели в качестве fallback.
  
• Вместо традиционной для kde жирной панели — минималистичная в связке с интенсивным использованием рабочих столов.
  
• Терминал — yakuake, консольный wm — screen. http://ompldr.org/vYnVnYQ/console.png
  

Визуальные элементы:

• Стиль — Plastik
• Декорации окон — Crystal
• Тема иконок — Milky
• Цветовая тема — Keramik Emerald
• Шревты по большей части от MS.
• На скриншоте представлены qt3, qt4 и gtk2 приложения.

Обоина на каждом десктопе своя:
http://www.vladstudio.com/wallpaper/?airlines2
http://www.vladstudio.com/wallpaper/?worldinversed
http://www.vladstudio.com/ru/wallpaper/?googledatacenter
http://www.vladstudio.com/wallpaper/?solarsystem

Дискасс.

Я не особо разбираюсь в сетях, натолкнулся на странное поведение и пытаюсь понять, в чём дело.
Подключился к беспроводной сети с WPA2 шифрованием, кроме скайпа ничего не работает.

Пинги идут.

aidaho@aidaho-laptop:~$ ping www.google.com.ua
PING www.l.google.com (209.85.148.99) 56(84) bytes of data.
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=1 ttl=55 time=58.5 ms
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=2 ttl=55 time=57.4 ms
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=3 ttl=55 time=58.6 ms
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=4 ttl=55 time=58.0 ms
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=5 ttl=55 time=153 ms
64 bytes from fra07s07-in-f99.1e100.net (209.85.148.99): icmp_req=6 ttl=55 time=57.5 ms
^C
--- www.l.google.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 57.477/73.877/153.018/35.396 ms

aidaho@aidaho-laptop:~$ telnet 209.85.148.99 80
Trying 209.85.148.99...
telnet: Unable to connect to remote host: Connection timed out

traceroute -m 255 google.com.ua
traceroute to google.com.ua (209.85.148.106), 255 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
...
 255 * * *