Вот: www.linux.org.ru/forum/linux-org-ru/7050917

Как можно было это воспринять за чистую монету? Большая часть отписавшихся восприняла (см. кучи гневных отзывов). Это я так убедительно вбросил? Или это ЛОР после введения +1 ожидает любой подставы?

Когда, наконец, будут сделаны статусы в профилях пользователей?

Очень часто разговариваешь с кем-то, он уходит и перестаёт отвечать, а ты про это не знаешь и ждёшь ответа. Статусы нужны, потому что в таком случае собеседник поставит статус «ушёл есть», и всё будет ясно и понятно.

Мы уже сутки ждём. Ну же!

У меня такое предложение, в свете начавшейся наконец модернизации на ЛОР.

Весь Talks (который предназначался для нетехнических разговоров о GNU/Linux) выродился, там сейчас все пишут только интересные узкому кругу невменяемых ЖЖ-подобные темы. Я даже ссылок приводить не буду — достаточно зайти в Talks и посмотреть каждую первую тему.

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

Остальные разделы, в принципе, можно закрыть и заменить тэгами. Тогда стоит по умолчанию ввести подсказки с тэгами, совпадающими с текущими названиями разделов, и сделать разделы просто выборками по соотвествующему тэгу (изменения интерфейса минимальные). То есть тема, таким образом, сможет попадать одновременно в Security и Development.

С виду в обоих случаях всё останется как есть: вместо разделов — выборка по тэгам (для сохранения привычного разделения), вместо Talks — просто аггрегация всех тем (постов в блогах), которые не попадают в остальные разделы.

Только система станет гораздо более простой и гибкой.

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

P.S. Совсем забыл: надо ещё сделать внизу под каждой темой (или между темой и ответами) блок «похожие темы». Он должен так же показываться при предпросмотре. Это очень поможет при задавании вопросов и описании проблем — можно сразу увидеть похожие темы с решениями, если они были. Не все хотят помнить про поиск.

Diaspora* — фигня. Да, там есть интересные идеи. Но там опять же чёртовы серверы! Зачем делать полумеры? Почему это преподносится как лучшее из возможных решений?

Ту же самую функциональность можно построить поверх распределённой одноранговой сети, хранящей (шифрованные) rdf данные о пользователях, с возможностью передачи произвольных файлов и проброса потоков. Сеть даже можно поднять поверх обычного интернета, с десктопным клиентом.

Почему так ещё не делают? Вообще, такая сеть может быть чем угодно: заменой почты, IM-сообщений, группового видеочата, блогов, друзей и контактов, аспектов из диаспоры (см мой предыдущий топик), телефонных разговоров. И всё это без серверов вообще!

P.S. Про Netsukuku я знаю, сейчас разговор про соцсети.

P.P.S. Да. Текущие социальные сети, джаббер, почта, сервера, телефонные сети, провайдеры, DNS — всё должно умереть.

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

1. чтобы она читалась только первым
2. чтобы она читалась только вторым
3. чтобы она читалась обоими

Я понимаю, что так можно сделать, если увеличить объём сообщения в третьем случае в два раза. Вопрос в том, как (и можно ли) сделать, чтобы избыточность была не такая?

С двумя людьми и тремя вариантами — это просто пример, в общем случае надо N людей и 2^N-1 вариантов. Хочется, чтобы объём выкладываемых данных не рос линейно от количества людей, которым он предназначен.

Небольшое пояснение, на всякий случай: ключи надо распределить до того, как станет ясно, кому надо раздавать информацию. Распределять 2^N-1 пар ключей на все варианты не хочется.

https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3...

Для Ъ всё в заголовке.

Оно внутри systemd и прибито к нему гвоздями.

http://www.ime.usp.br/~weiss/algorithm.pdf
http://www.ime.usp.br/~weiss/peqnp-11-05-30.pdf

Где отзывы? Или это совсем бред?

https://bugs.launchpad.net/calibre/ bug/885027

Для Ъ: он доказывает, что дыра — это не дыра, а фича. Дыра (а вернее, дыры) — в суидном бинарнике, который ставит эта сраная Calibre чтобы поиметь возможность что-то там монтировать. В итоге кто угодно может монтировать (и отмонтировать) что угодно, создавать папки от рута, запускать от рута что угодно.

Сабж.

тык

Для тех, кто в танке: llvmpipe — новый софтварный рендерер opengl (в mesa), использующий llvm и архитектуру gallium. Призван, наконец, нормально реализовать поддержку OpenGL там, где его нет (старое/не поддерживаемое оборудование, виртуальные машины, etc.). В игры на нём не особо поиграешь (хотя, говорят, на хорошем процессоре openarena сносно работает). И версия поддерживаемого OpenGL не такая дохлая, как в старом софтварном рендеринге, а соотвествует поддерживаемой Mesa.

В идеале он даст возможность забить на всё и при написании программ рассчитывать на то, что OpenGL есть везде.

Например, compositing в kwin, compiz, и т.д. (Кстати, имхо, всё идёт к тому, что kwin со временем тоже будет требовать OpenGL ES и режим без него убьют).

Ещё (оправдывая тэг [Qt5]), в Qt всеръёз раздумывают над тем, чтобы в Qt 5 оставить только OpenGL ES для отрисовки (выкинуть raster), чтобы не плодить свой растеризатор, а использовать унифицированный OpenGL ES. В llvmpipe куча оптимизаций (есть и планируется), так что можно ожидать, что даже на софтварном рендеринге OpenGL ES через llvmpipe отрисовка в итоге будет всё равно быстрее, чем на собственном растеризаторе Qt.

Кто не понял, повторюсь: llvmpipe — быстр. Намного быстрее простой софтварной растеризации «в лоб». Как вы думаете, если вы на простой софтварной растеризации того же Qt напишите что-то вроде OpenArena, оно вообще заработает со сносной скоростью хоть на одном десктопе? Так что даже с софтварным рендерингом OpenGL всё будет быстрее, чем сейчас.

P.S. И да, с отрисовкой всего на свете через OpenGL ES, надеюсь, исчезнут вопли про нужность тормознутого и древнего как говно мамонта протокола отрисовки иксов (используемого в Qt native engine). Кому надо — прогонит OpenGL по сети и будет счастлив.

P.P.S. WebGL — OpenGL ES 2.0. Да-да. Может, когда всё созреет, кому придёт в голову написать на основе этого удалённый отрисовщик окон прямо в браузере клиента.

По мотивам этой темы.

Теперь в арче в [testing] есть Qt 4.8.rc1, QtWebKit 2.2.0 (со включенным WebGL), и kwebkitpart пересобрали, чтобы он нашёл QtWebKit 2.2.0 и подцепил WebGL.

Konqueror набирает 303+14 баллов.

Повторюсь: аудио есть, видео есть, WebGL есть, вебсокеты есть. Кому интересные детали — могут сами поставить.

Всё вышеописанное работает из официальных бинарных пакетов (собранных из Qt 4.8.rc1, QtWebKit 2.2.0, kwebkitpart 1.2.0), без патчей.

rekonq для поддержки WebGL надо чуть патчить (две строчки, см прошлую тему), но в гите ведётся работа, скоро сами добавят. При этом он с WebGL даёт 308+14, а без (непатченный) — 293+14.

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

Старые драйвера r300с и r600c выкинули окончательно, остались только основанные на Gallium.

Попутно выкинут компилятор шейдеров, который использовался в r300c, и прочая фигня. Из r200 выкинута поддержка DRI1.

Этим удалено примерно 80 тысяч строк кода.

тык

Чуть раньше я и Behem0th уже про это писали, но тогда это были только планы, а сейчас — свершившийся факт.

Да, чтобы избежать FUD: плохо от этого будет только бсдунам, которые там у себя ещё не осилили доделать графическую подсистему. Если посидят на старой месе, никто не умрёт.

Почему все билд-скрипты (например, PKGBUILD-ы в арче) тянут себе весь git-репозиторий, а не просто последнюю/нужную ревизию?

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

Для примера: снапшот WebKit-а весит около гига, а репозиторий — все четыре.

Да, я понимаю, что в гите экспорт делается нетривиально, но это не повод. Кстати — почему нету алиаса вроде «git export репозиторий коммит|тэг|ветка»?

Кто в танке, сама команда вот:

git archive --format=tar --remote=git://example.org/my-super-project master | tar -xf -

Оно работает со всем, в т.ч. bare-репозиториями.

Сообщение в списке рассылки и вниз по ветке. Все поддерживают идею выкинуть DRI1, r300c, r600c.

Вначале предложили убрать DRI1 и подчистить всё, где он используется, а потом в обсуждении предложили выкинуть r300c и r600c вообще. Пока что единогласно.

[phoronix]

DRI1 упокоится с миром, а из не-Gallium3D драйверов останется только intel.

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

В двух словах: поддержка Gigabyte сказала, что их материнки поддерживают только Windows, ставьте Windows. Это дословно.

[тык]

Цитата от Gigabyte:

Да, я знаю про OpenID, разговор не про то.

Основные пункты мысли:

• Брелки:
  • Приватный ключ храним на usb-брелке с невозможностью доставания (нет, не в фс), (про него все знают, см Rutoken и eToken), такие под линуксом работают. Пока что такие используются банками.
  • Брелки должны появится в свободной продаже (справки не наводил).
  • Брелки должны иметь встроенный флэш-диск хотя бы метров на 128 (копейки), дальше — от желания пользователя. Такие есть, пример: Rutoken Flash, eToken Flash, в Linux работают.
  • Доступ к встроенному диску может быть защищён паролем (или можно, введя пароль к данным, подписывать компьютеры на право доступа к данным без пароля).
• Пользователи:
  • Вход в систему осуществляется автоматически через PAM при вставлении нового ключа. Предупреждение выхода — при вытаскивании. Для этого надо допилить все/какие-то из DM на предмет логина через PAM.
  • При вставлении нового ключа при уже имеющемся — спрашиваем, хотим ли мы их объединить (принимать второй в качестве авторизации альтернативно/вместе).Для этого нужно допилить DE, или сделать какой-то универсальный user-демон.
  • Диск служит хранилищем настроек, сеансов, и некоторых из папкок с данными в домашнем разделе. Грубо говоря — хомяк синхронизируется с диском, при этом на папках должна быть иконка синхронизирован/нет. Настройки становятся синхронизироваными автоматически, папки с данными отмечаются как таковые при запросу, кэш не синхронизируем никогда. Для этого надо допилить приложения на предмет соответсвия последнему XDG. И опять же, DE или демон.
  • Система может быть настроена так (галка на видном месте), что при вставлении неизвестного брелка создавался новый пользователь (логин и настройки хранятся на том же встроенном в брелок диске). После вытаскивания брелка — удалять пользователя по желанию пользователя или принудительно (в зависимости от настроек системы). Это позволит сидеть со своего окружения из гостей, без разных уходов в облака. Нужно допилить DM с добавлением пользователей. Тут вопрос по поводу доверия данных конкретной систему, на этот случай можно заводить два брелка: публичный (для шастания по библиотекам и отелям) и личный (для дома, друзей, и близких родственников). Можно ключи совместить в одну железку с выбором/вводом разных паролей.
  • Если какие-то программы или выбранный пользователем DE не стоят — проблема не критична, это опять же проблемы настроек компьютера.
• Сайты, сервисы, аккаунты.
  • Да, пароли можно хранить в бумажнике на встроенном диске, но это — очень плохой выход, особенно если таскаться с ним по библиотекам.
  • Тут мы вспоминаем, что наш брелок — ключ. Встраиваем в браузеры механизм авторизации с использованием ключа и мастер-пароля, которым ключ подписывается. (См. он-лайн системы банков). Эта система должна быть альтернативной к обычному входу (как OpenID), и, если сайт, браузер, и компьютер поддерживают, а брелок вставлен — должна работать вместо обычной авторизации.
  • Такая же система с почтовыми, IM-клиентами и всем остальным. Тоже нужна поддержка в приложениях.
• DE, помимо описанного выше.
  • Должна быть возможность таскать сеансы. Это может быть реализовано через уже имеющееся сохранение сеанса при выходе (настройки-то с собой).

Можно разделить внутренние ключи в железке по группам: хомяк/аккаунты/банки, тогда будет три разных пароля. Для получения данных хомяка — надо ввести пароль от зашифрованного раздела. Для авторизации из банков нужно ввести пароль, чтобы подписать ключ токена. Совсем без пароля хранятся только публичные настройки окружения.

Выгоды очевидны. Критикуйте.

Portable OpenCL позволит разрабатывать и запускать программы, использующие OpenCL, на его свободной платформонезависимой реализации (до этого существовали SDK, предоставляемые вендорами аппаратуры).

Это свободная (MIT-лицензия), основанная на LLVM реализация стандарта OpenCL, которая может быть легко приспособлена для новых целевых платформ. Одна из задач проекта — улучшение «переносимости производительности» программ на OpenCL, избегая нужды в ручной оптимизации, зависящей от целевой платформы. Цель «native» включена, что позволяет запускать ядра OpenCL на CPU.

Также ведётся работа над реализацией OpenCL поверх драйверов видеокарт из Gallium3D (Clover state tracker), в котором можно отметить некоторый прогресс за лето, произошедший в рамках GSoC.

Сайт проекта: https://launchpad.net/pocl

>>> Подробности

тык

Ъ всё поймут по адресу ссылки.

За сим констатирую, что после последних обновлений Kwin тормоза блура у меня исчезли.

Как проверить тормоза блура: ставите тему плазмы по умолчанию, в kwin включаете блур и график производительности. Смотрите на FPS. В плазме создаёте три панели максимального размера (по толщине тоже!) по бокам и сверху (пустые, не четыре просто чтобы легко вернуть было). Смотрите на FPS. Это просто тестовый случай, но на самом деле производительность проседала от любого использования блура.

Ну, или просто поставьте oxygen-transparent.

В 4.8, наконец-то, починили.

Скриншот.

Для этого нужен QtWebKit 2.2 (войдёт в состав Qt 4.8) и свежий rekonq.

Внутри video (youtube работает), audio, webgl, и т.д.

По поводу поддержки WebGL — на скриншоте она есть, но вопрос в флагах компиляции QtWebKit (которые не факт что будут включены в Qt 4.8), и для rekonq нужен патч на две строчки (который очень скоро включат).

Без WebGL — 293+14. В konqeror и arora — 288+14.

В Qt 4.8 WebKit обновлён с древнего QtWebKit 2.0 (которому больше года) до QtWebKit 2.2.

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

html5test: 293+14 (rekonq), 288+14 (konqueror, arora). Разница в localStorage.

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

По сравнению с тем, что было до этого — просто праздник.

P.S. Да, Qt 4.8 можно было не ждать, а обновлять QtWebKit независимо. Я, собственно, раньше так и делал.