Kubuntu 15.10 Wily Werewolf Release

Подберите и пользуйтесь.

Есть подтверждение на счет "всех"?
На самом деле, они и два года назад так тормозили. Человеческая лень - безгранична =)

Если верить сайту launchpad.net..... В репе ppa:kubuntu-ppa/ppa версия плазмы 5.4.3.

а мне теперь не зайти в систему. уже подумываю о переустановке :(

Кстати да, у меня так же.
Еще kde-style-qtcurve-qt5 удалился и пока не ставиться, так же как и муон.

установился с обновлениями насколько я понял. когда я удалил kde-config-screenlocker который связан с libkscreenlocker5 , у меня в меню пуска пропали кнопки завершения работы\сеанса, перезагрузки и все остальные.

Наврал. В 5.4.2 тоже можно менять кнопки, но расположена эта настройка немного в другом месте чем в 5.5.3(уже проверил), и там и там непревычно, еле нашёл. Но что самое неприятное, поменять кнопки крайне трудно, перемещение срабатывает на 10 раз, плюс часто падет менеджер настроек…

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

Аппаратная проблема - это когда электроника ведет себя неадекватно. Иными словами, не выполняет ожидаемую логику на уровне схемы. В таком случае проявляться будет только на одной единственной машине или бракованной партии чипов. При массовом проявлении (от двух и более) на различном железе - это уже следствие ошибок в коде.
Выполнение кода - совершенно точный процесс, спонтанностей там быть не может, как реализовали - так и работает. Но код пишут люди, а им свойственны невнимательность и допущение ошибок.
Segmentation fault и последующее прибивание менеджером процессов ядра может иметь столько же причин, сколько в коде низкоуровневых операций, таких как обращение по указателю, когда невозможно выполнить проверку на этапе компиляции, а только во время выполнения.
Например, у нас есть структура, в которой хранятся имена процессов и их идентификаторы:
struct Process
{
    unsigned id;
    char name[50];
};
Чтобы работать с несколькими значениями (списком процессов), нужно создать массив данных структур, либо разместить из в контейнере (вектор, двусвязный список, очередь и т.д.) в зависимости от того, какие операции будут выполняться наиболее часто и какая структура данных будет при этом оптимальной.
Когда мы сталкиваемся с необходимостью передать этот массив в функцию - есть варианты. Можно передать по значению, но тогда будет создан временный объект, что влечет за собой лишние затраты по памяти и выполнены лишние операции. Наименее затратный способ - передать массив указателей на структуры.
Для простоты, функция, принимающая указатель на структуру будет выглядеть как-то так:
void ShowProcessId(struct Process *process)
{
    cout << process->id; //обращение через указатель
}
Если вызвать данную функцию с переданным ей в качестве аргумента указателем на существующую структуру Process - все будет хорошо, выведется идентификатор. Но если передать нулевой указатель (NULL), то программа грохнется на строке "cout << process->id;", ибо NULL->id - бред.
Избежать краша можно добавив проверку на этапе выполнения:
if (process != NULL) cout << process->id;
else cout << "передан нулевой указатель";

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

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

У Майка, судя по бэктрейсу и утверждениям о том, что крашит в момент открытия ссылок и переключению столов, происходила передача указателя на структуру с данными по процессам в функции, которые как-то эти данные обрабатывали. Вполне возможно, что какие-то персональные настройки KDE активизировали часть кода в этих функциях, которая пыталась обращаться к несуществующим полям структуры без проверок на NULL или что-то вроде того. К тому же, поскольку код портировался для работы с Qt5, вносилась куча изменений и что-то могли забыть поправить, остановившись на том, что в дефолтном случае все работает корректно. Такие ошибки отловить бывает сложно, но все равно возможно.
А по хорошему, работая с данными на С/С++ нужно проявлять больше аккуратности, применять подходящие паттерны и писать юнит-тесты.
Майку же остается злостно стучать о багах на kde.org, активно отвечая на вопросы о настройках и т.д., а не ждать, пока кто-то другой это сделает - тогда дело пойдет быстрее =)

Знают. За себя, во всяком случае, говорю. Просто вариантов "Не знаю" или "Не использую, а потому не могу сказать" в опросе не предусмотрено. Вот и "едим что дают" =) А четвертая плазма не падает. Чесна-чесна =))))

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

З.Ы. Я тоже на интеле, но у меня за последний месяц ни одного падения не было... В теме про падения был показан бэктрейс, где вина на mesa/intel - удостоверьтесь, что у вас более свежая, на всякий...

Из чьих именно рук?)
А если на 5.6 будут проблемы, к кому конкретно обращаться за гарантиями?

/usr/lib/update-notifier/apt-check, оно же ссылка на apt_check.py
Вот кто мешает, как всем приличным утилитам сделать проверку на запуск в единственном экземпляре через lock-файл, например?
Тогда вызывай хоть в бесконечном цикле, систему не доведет ни до свопа, ни до отказов интерфейса.

Ну, а кедовый нотифаер, безусловно вообще жжот.

Вы в курсе, что свои сообщения можно редактировать? Не надо так размножаться…

You installed plugins widget from libkdepim which provides addresslineedit which depends on akonadi.
so it's normal. Don't install it if you don't want it :)
Позволю себе усомниться. Такое поведение абсолютно излишне.