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

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

Оно внутри 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 чтобы поиметь возможность что-то там монтировать. В итоге кто угодно может монтировать (и отмонтировать) что угодно, создавать папки от рута, запускать от рута что угодно.

Just so this is perfectly clear: what's happening in this bug report right now is a perfect example of how *not* to do security response. When faced with two people who clearly know a few things about secure coding, rather than taking their advice and actually fixing the root cause of the problem (or abandon it as a hopeless situation, which is probably the more appropriate response), you've chosen to waste our time by demanding that we write weaponized exploits to exploit what most people already know to be exploitable. To top it off, when shown repeatedly how your half-baked «fixes» don't actually fix anything, rather than taking our advice you just add another small hurdle that can be trivially bypassed. It would be sad if it weren't so funny.

Сабж.

тык

Для тех, кто в танке: 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. Это дословно.

If you have an affected motherboard to the ASPM power regression in the Linux kernel and it's from Gigabyte, don't expect a BIOS update from them to correct the ASPM semantics in the BIOS. Gigabyte recommends you just use Microsoft Windows.

[тык]

Цитата от Gigabyte:

Thank you for your kindly mail and inquiry. About the issue you mentioned, since our products only support Windows OS, we do not receive proper driver from chipset vender, we cannot guarantee Linux to work on our system. We suggest you to install Windows OS to prevent having problems. If you install the Windows OS and still have any problems, please provide the error message screenshot for us, so we can try to see how to help. Sorry for the inconvenience.

Да, я знаю про 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 независимо. Я, собственно, раньше так и делал.

Именно так будет называться семнадцатая шляпа.

[тык | тык]

Что видел сам в версии, собранной из git-а:

• В теме по умолчанию убрали фон у трея. Теперь иконки/виджеты в трее и рядом с ним выглядят одинаково (и одного размера).
• Новая логика у области уведомлений (трея). Теперь по умолчанию будет видимо только то, что требует внимания (или должно быть активно постоянно), остальное будет скрыто (скрытые иконки появляются после нажатия на стрелку). Например, иконка уведомлений (буква «i») скрывается, когда уведомлений нет, иконка батареи не показывается в состоянии 100% заряда при работе от сети, а kopete показывается только когда пришло сообщение. Это касается только поведения в режиме «Видимость: Автоматически» (по умолчанию), любую иконку можно навсегда закрепить или скрыть по желанию. Было обсужения насчёт скрытия иконки громкости, когда ничего не играет и не записывает звук, но пока что ни к чему не пришли.
• Тетрис перестал тормозить на четырёхядернике.
• Telepathy-KDE становится вменяемым, хранение паролей в kwallet заработало, больше никаких gnome keyring и gtk-шных диалогов. Из базовой нереализованной функциональности я вижу только отсутствие истории сообщений. Как сделают — можно будет заменять kopete. Вообще, telepathy-kde выглядит очень многообещающе.
• В теме по умолчанию в трее иконкам звука и вай-фая добавили неактивные стеклянные полоски. Теперь белые полоски не появляются на пустом месте, а заполняют стеклянные. Как следствие — поправили позиционирование иконки звука, когда звука нет.
• Dolphin-а наконец отпустило, теперь он больше не выглядит обрубком. Что работало в старой версии — работает (кроме фильтра и выделения плюсиками). Выглядит немного непривычно, но сносно (пилят ещё). Шустр. В режиме таблицы (детали) вернулись заголовки столбцов с сортировкой и нормальной шириной. Пользоваться можно, оставляет небольшое ощущение недоделанности.
• Kate стал няшнее. Например, он подсвечивает (небросающийся в глаза, очень удобный) индикатор рядом с новыми и изменёнными строчками (до сохранения). Сворачивание блоков переделали, работает хорошо.
• Что-то добавили в Marble, не вникал.

Что обещают:

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

Так и не понял, когда, наконец, убьют knotify.

«Вкус еды, а не масла» — «наше безвкусное масло очищено лучшими растворителями».

«В каждом литре сока Добрый — более килограмма яблок» — («килограмм… литр… никак из килограмма яблок литра сока не выйдет») «наш „cок“ бодяжат из говна и воды».

И т.д.

Это антиреклама получается, имхо.

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

X Screensavers будут отправлены в ад. Новые скринсейверы можно будет тянуть по GHNS с сайта kde-look.org.

В 4.8 ещё останется fallback-режим с поддержкой X Screensavers, он будет полностью выпилен к 4.9.

В связи с чем, опрос (детали для !Ъ там же).

!Ъ: тык

Ъ:

Старый вариант останется доступен.

Новый вариант разрешается на этапе компиляции (а не исполнения), и работает не со строками.

Было:

connect(sender, SIGNAL(valueChanged(QString,QString)), receiver, SLOT(updateValue(QString)));

Стало:

connect(sender, &Sender::valueChanged, receiver, &Receiver::updateValue );

Можно так:

connect(sender, &Sender::valueChanged, 
    tr1::bind(receiver, &Receiver::updateValue, "senderValue", tr1::placeholder::_1) );

Или так:

connect(sender, &Sender::valueChanged, [=](const QString &newValue) {
        receiver->updateValue("senderValue", newValue);
    });

Можно писать код прямо в коннектах:

void doYourStuff(const QByteArray &page)
{
    QTcpSocket *socket = new QTcpSocket;
    socket->connectToHost("qt.nokia.com", 80);
    QObject::connect(socket, &QTcpSocket::connected, [socket, page] () {
        socket->write(QByteArray("GET " + page + "\r\n"));
    });
    QObject::connect(socket, &QTcpSocket::readyRead, [socket] () {
        qDebug()<< "GOT DATA "<< socket->readAll();
    });
    QObject::connect(socket, &QTcpSocket::disconnected, [socket] () {
        qDebug()<< "DISCONNECTED ";
        socket->deleteLater();
    });
 
    QObject::connect(socket, static_cast<void (QTcpSocket::*)(QAbstractSocket::SocketError)>(&QAbstractSocket::error), [socket] (QAbstractSocket::SocketError) {
        qDebug()<< "ERROR " << socket->errorString();
        socket->deleteLater();
    });
}