И еще про новый ноутбук

Ethernet-карта Atheros в сочетании с ядром из wheezy это круто. 55Гб бэкапа Ириного ${HOME} перекачались меньше чем за час. Это при том, что в качестве свитча использовалась всего-то DLink DIR-300, за которой я раньше таких способностей не подозревал. Создавался этот бэкап на старом ноутбуке часов 6. Через ту же DLink-у и тот же патчкорд.

И наконец появился в доме ноутбук с аппаратной поддержкой виртуализации. Поскольку Ире вирутальная винда периодически бывает нужна - работающий kvm это большой прогресс.

А вот wheezy меня жестоко обидел тем, что из него выпилили libpam-ssh. Как-то привык уже вводить пароль/пассфразу при логине ОДИН раз. Зато ssh там научился ecdsa. В общем-то пора бы уже.
Интересно, сколько времени пройдет, прежде чем я смогу позволить себе использовать ecdsa пользовательские ключи (то есть sshd c поддержкой ecdsa появится ВЕЗДЕ, куда мне приходится ходить по ssh. (Ага, включая ASUS WL-500Gold). Еще они извели cdrecord. Он окончательно стал называться wodim, в том числе и в командной строке.
Это - "что-то вроде сюрприза", то есть засада. Я и так пишу сидюки примерно раза два в год, и каждый раз вспоминать как называется команда?!!

В общем проблема установки тестинга на ноутбук сводится к тому, что нельзя тупо накатить selections от старого ноутбука, сказать apt-get dselect-upgrade и накатит бэкап /etc. Приходится вдумчиво разбираться со списком пакетов и с настройками. Правда, в процессе вычистилась куча мусора, вроде остатков от установленного в /usr/local madwifi не помню от какого ядра.

Upd Они еще laptop-net выпилили. Что теперь вместо него? Чем отслеживать втыкание-выдергивание эзернета?

Про pam-ssh

Тут с удивлением выяснил что пакет libpam-ssh не пользуется популярноностью в Debian, что и послужило одной из причин его удаления.

Меня это как-то сильно удивляет - удобная же штука.

Этот pam-модуль позволяет, логинясь в систему интерактивно сразу получить ssh-агент с загруженным ключом, введя пароль/пассфразу один раз. (для этого, правда, требуется совпадение пароля в /etc/shadow и пассфразы на ключ).

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

С.П. Капица умер

Оба брата - Сергей и Андрей были наглядным опровержением поговорки "на детях гениев природа отдыхает".

Интерфейсы будущего. III Первые итоги дискуссии

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

Но вот rainbow_beast просветил меня по поводу разницы между mind maps и concept maps.

Хотя я не уверен, что термин mind mapping не подходит, но все же в названии "Концептуальный интерфейс" что-то есть. Постмодерном попахивает.

На самом деле интерфейс должен быть в первую очередь самообучающим. Не самообучающимся хотя это тоже не повредит, а именно обучающим - self-tutoring или self-сouching. Причем обучать он должен в первую очередь именно конецпциям, лежащим в основе той или иной деятельности за компьютером.

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

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

Есть еще контекст текущей активности. Который тоже может выходить за пределы текущей сессии. Например активность "диалог в чате с другим человеком" явно захватывает кусочек сессии второго собеседника.

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

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

Кстати о безопасности, Систему следует планировать исходя из того, что любая из компонент может содержать если не злонамеренный код, то опасные ошибки. И везде где возможно использовать разграничения доступа к памяти, ограничения доступа к файловой системе и т.д. В качестве образца мы имеем по крайней мере две модели - классическую модель Unix и неклассическую Android с контрактами приложений. Там, правда, очень плохо сделано разграничение доступа к файловой системе. Можно еще посмотреть на остерхутовскую модель из SafeTcl.

В общем, получается такая картина - имеются tiled окна. Их немного. Даже на современном экране много tiled окон не расположешь. У окон может иметься довольно широкая рамка, куда выводятся тем или иным способом связанные с основным содержимым окна штуковины. Например, меню - это частный случай набора ассоциирующихся с содержимым окна объектов - команд, которые к этому окну можно применить.

Вокруг области tiled окон имеется рамка экрана. Где показываются какие-то объекты, связанные с сессией в целом или компьютером в целом.

У окна четыре стороны и можно их закрепить за разными типами связей.

Возможно, стоит позаимствовать из Ashton Tate Framework концепцию "изнанки фрейма". Там на изнанке фрейма можно было писать скрипт, генерирующий содержимое фрейма. Здесь более логичным является наличие на изнанке пояснительного (гипер)текста про то что можно с этим фреймом делать. Скрипт там тоже может быть, на то еcть literate programming.

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

Идеями Раскина насчет полностью modeless интерфейса злоупотреблять не стоит. Смена взгляда на один и тот же информационный объект иногда вполне оправдана. Но только надо оформить смену режима как переход по ссылке в concepts map. Вот до сих пор это у нас был текст, который мы набирали, и ассоциировался он с набором инструментов для работы с содержимым, а сейчас это стал верстаемый документ, и набор инструментов стал совсем другой.