Понизить ядро Linux и решить проблемы с драйверами

Наверно попробовать вытащить из минт 17.3, если там всё ок. Только не факт, что оно запустится. Лучше поставить рабочий дистрибутив (в данном случае минт 17.3).

В смысле скопировать ядро и рамдиск из папки boot? А драйвер прямо в ядре разве находится? Он же наверное в каком-то модуле спрятан.

Переставлять систему - самый последний вариант. У меня нет времени сначала ставить все программы. Хотя конечно в чём-то KDE 4 мне нравился больше, чем KDE 5...

глюк-то в чём?

пакеты ядра установи все от 17.3

возьми старый модуль

В смысле скопировать ядро и рамдиск из папки boot?

Ну, я так понимаю, что ты это уже сделал, судя по цитате:

Увидел, что там ядро 3.19 и решил поставить такое же в установленную у меня LM 18

Впрочем, xmikex правильно советует установить пакеты, а не просто переписать, если, конечно, они есть в репозитории. Может поможет.

А драйвер прямо в ядре разве находится?

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

Он же наверное в каком-то модуле спрятан.

Да, в модуле с расширением *.ko. Посмотреть список загруженных модулей можно командой lsmod. Можно, конечно, вытащить нужные модули из mint 17.3 и запихнуть в mint 18 на место более новых. Может повезёт, и всё заведётся. Но вероятность невелика, т. к. там может быть очень много зависимостей, и одно тянет другое. Поэтому думаю, что самое простое, это переустановить систему, поставив заведомо работающую версию.

А сам глюк-то опишешь? А то он не только от ядра может зависеть.

И ты можешь просто перейти на Mint 17.3, он ещё поддерживается.

4.8 - очень глючное ядро. Лучше сидеть на чем-то типа 4.5 и ждать стабилизации.

Я не из минта ядро выковыривал, а ставил deb пакеты, как написано по ссылке из моего первого поста.

Ок, попробую поковырять модули...

Глюк в том, что как только температура процессора доходит до 67 градусов, всё намертво виснет. Даже курсор мыши останавливается. Ничего кроме вырубания питания не помогает. Я предполагаю, что это паника ядра.

На другом компьютере тоже есть глюк, появившийся начиная с какой-то аерсии ядра, но вроде ещё в ветке 3.x и оставшийся даже в последнем ядре 4.x. Там по идее мне предстоит то же самое сделать, если вдруг надоест сидеть на установленной 17.3, где можно без проблем понизить ядро прямо из GUI. Глюк заключается в том, что когда не воспроизводится никаких звуков, динамики противно пищат, причём громкость пищания не зависит от текущей громкости. Как только вопроизводится какой-то звук, раздаётся щелчок и пищание пропадает на несколько секунд. Затем снова щелчок, и снова пищит. Вообще это в принципе пищащий ноутбук. Когда он работает, изнутри него доносится высокочастотный писк.

Я не из минта ядро выковыривал, а ставил deb пакеты, как написано по ссылке из моего первого поста.

Ок, попробую поковырять модули...

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

Глюк в том, что как только температура процессора доходит до 67 градусов, всё намертво виснет.

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

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

Это не похоже на проблемы с ядром и вообще проблемы с софтом. Думаю, это железо. Но можно проверить, загрузив с live-cd/usb «хорошую» по твоему мнению ось с поддержкой звука и погоняв её некоторое время без установки.

Я наверное попробую ввковырять модули. Если система умрёт, поставлю 17.3 тогда.

Нет, не занижает. До 67 градусов с полной загрузкой всех ядер на максимальной частоте с любым ядром температура доходит за 45 секунд. С новым ядром при этом зависает, а со старым работает дальше и температура поднимается выше. Держал его загруженным 20 минут, температура дошла до 78, но ничего не зависло. А вентиляционных отверстий у меня нет, как и вентиляторов вообще. Да ещё и корпус пластиковый, плохо тепло проводит. В игрушках из-за этого тротлинг и супер тормоза, а в остальном до тротлинга не доходит и всё нормально работает.

В смысле не похоже? Что динамики громко пищат? Как минимум её как-то решают в Windows и на старых ядрах. А то, что при работе ноута у него изнутри доносится писк, я уже давно смирился - он не зависит от ОС и его не слышно, если не прислушиваться.

вентиляционных отверстий у меня нет, как и вентиляторов вообще

Их и вентилятора не может не быть. Отверстия обычно подо дном ноута, иногда ещё по бокам, а кулер внутри над радиатором или где-то рядом. Впрочем, если в других ОС нагревается сильнее, и всё ок, — дело, скорее всего, действительно не в этом.

Я наверное попробую ввковырять модули. Если система умрёт, поставлю 17.3 тогда.

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

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

SSD очень недолговечны при интенсивной записи, что неизбежно на рабочей системе. Или надо убирать своп, а /tmp и /var/tmp монтировать в tmpfs или в ramfs. /tmp, правда, и так в /tmpfs монтируют, но при работающем свопе. А /var/tmp не рекомендуют. В общем, не советую. Но если всё-таки поменяешь, то минимизируй запись на диск. В частности, в /etc/fstab можно прописать опцию relatime для уменьшения числа записей на диск. И вообще использовать нежурналируемую ext2, — она менее надёжна, но и на диск нагрузка меньше. Но всё это только слегка улучшит ситуацию, а не исправит её кардинально.

Я большей части этих советов придерживаюсь, причём даже на HDD, чтобы им не шуршать лишний раз. И раздел подкачки даже не создаю. На Linux 4 ГБ вполне хватает, но планирую поставить 8 ГБ, потому что на винде 4 ГБ не хватает.

Я думаю, что недолговечность всё же преувеличена. Либо надо вообще писать на диск огромные объёмы, не задумываясь, чтобы истратить ресурс. У меня на основном ноуте SSD стоит уже больше года. И всего SMART показывает 103 максимально и 33 в среднем перезаписей. Даже если вдруг у меня маленький ресурс, например 3000 циклов, этого хватит как минимум на 40 лет при том же режиме использования. Правда там винда, а не линукс, и ещё там есть HDD, на котором я держу крупные файлы, некритичные к производительности. А временные файлы, которые у меня генерируются гигабайтами в день, я кладу на рамдиск.

надо вообще писать на диск огромные объёмы, не задумываясь, чтобы истратить ресурс

Запросто. Про своп, /tmp/ и /var/tmp/ я уже говорил. Плюс /var/log/ и другие логи, которые могут писаться куда-то ещё вопреки рекомендациям (например, в /home/user/.programdir/log/). Плюс кэширование web-страниц браузерами. Плюс /var/lock/. Конечно, lock-файлы обычно пустые или максимум содержат pid-процесса, создавшего их, но не надо забывать, что, при записи на SSD-диск, сколько бы байт ты ни записывал, физически будет записано 4 или 8 Кб. (если объём записываемых данных меньше). Причём сначала стёрто и только потом записано. Ну и, возможно, ещё какие-то интенсивно записываемые в фоновом режиме файлы, я мог забыть. Можно, конечно, создать unionfs, примонтировав в неё SSD в режиме r/o и какую-нибудь tmpfs в режиме r/w. Но в этом случае

1. Никакая информация не будет физически сохраняться, только до выключения либо на внешнем носителе.

2. Чтобы установить или обновить ПО, придётся загружаться с внешнего носителя и временно прописывать в fstab монтирование в режиме r/w.

Даже если вдруг у меня маленький ресурс, например 3000 циклов, этого хватит как минимум на 40 лет

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

У меня на основном ноуте SSD стоит уже больше года. И всего SMART показывает 103 максимально и 33 в среднем перезаписей.

Впрочем, если есть личный положимтельный опыт, то он ценнее любых умозрительных советов.

/var/lock то наверное тоже можно как tmpfs монтировать. Они же вроде не должны сохраняться между перезагрузками? SSD видимо в основном летят не из-за перезаписей, а контроллер умирает. Из-за кончившихся циклов перезаписи по идее данные не должны теряться. Ну и в принципе все важные данные у меня дублируются в облаке или в github/bitbucket. Остальное - это лишь установленные программы и ОС, которые придётся ставить снова, потратив время и деньги на новый SSD.

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

Операционка наверное всё равно кеширует всё в дисковом кеше и пишет на диск более крупными блоками. А ещё у меня Linux стоит на разделе с ФС btrfs. Я вроде читал, что она неплохо дружит с SSD и мелкими файлами. Но уже давно про неё читал и не помню подробностей.

Вообще, если я поставлю SSD и больше оперативки, то я наверное буду сидеть на винде. Это я сейчас в качестве эксперимента решил перейти на Linux, потому что он летает там, где винда подтормаживает.

/var/lock то наверное тоже можно как tmpfs монтировать. Они же вроде не должны сохраняться между перезагрузками?

Да.

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

Вот этого не знаю. Но летят как раз те, которые интенсивно используются в режиме записи. У меня флешки не летят, но я на них и не пишу интенсивно.

Операционка наверное всё равно кеширует всё в дисковом кеше и пишет на диск более крупными блоками.

В целом да. Но, во-первых, процесс может принудительно сбросить на диск какую-то важную информацию. А во-вторых, буферы всё равно по умолчанию сбрасываются каждые 5 сек.

Linux стоит на разделе с ФС btrfs. Я вроде читал, что она неплохо дружит с SSD и мелкими файлами.

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

Вообще, если я поставлю SSD и больше оперативки, то я наверное буду сидеть на винде.

Это дело вкуса. По мне так Линукс намного удобнее, и даже не потому, что летает. WinXP летает похлеще любого современного десктопного (т. е. с графикой) Линукса, а всё равно хуже.

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

Если бэкапа не было, значит, данные не были важными :) А сам SSD можно по гарантии сдать.

SSD можно по гарантии сдать

Сейчас обычно гарантия на всё максимум год. Если полетит через год и 1 день, то по гарантии уже не получится. :-)

Сейчас обычно гарантия на всё максимум год.

Бред не пори. Пять лет на SSD, вполне сейчас распространённая гарантия. А что бы не бздеть за объём записанных данных, так SSDшник надо правильно выбирать и не жмотить.

И всё чики пок будет. Быстро и тихо. Надёжно и долговечно и на гарантии.

Но про бэкапы всё равно забывать не стоит.

А что, в Mint 18 из «Менеджера Обновлений - Вид» исчез пункт «Обновление ядра Linux», где можно было выбрать для установки версию ядра? Или там подходящего нет?

Пять лет на SSD, вполне сейчас распространённая гарантия

Ну не знаю, не знаю. Сейчас посмотрел на я.маркете несколько объявлений от балды, в основном 3 года, иногда год, 1 раз увидел 10 лет, но у др. магазина на ту же модель уже год.

Так что по поводу года относительно ssd беру свои слова обратно, но 5 лет, имхо, перебор. Т. е. может такое и бывает, но вряд ли распространено.

Я так понял, что ТС поставил подходящее ядро, но после этого у него не запустились иксы.

Вот так вот, хотел понизить ядро, а в результате ядро понизило ТСа

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

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

Но в целом линукс мне нравится, поэтому я ищу повод попробовать его поиспользовать какое-то как основную систему.

Он не исчез, но выбор сократился только до версий ветки 4.4.x.

Винда реже ломается

Я уже давно не пользуюсь виндой, если не считать установить/починить кому-нибудь ну и время от времени проверить, как работает под цигвином один проект. Последняя версия, которую я активно юзал, был хрюшка. И по моим наблюдениям лицензионная полностью настроенная хрюшка при регулярном обновлении через некоторое время начинает дико тормозить, при том, что ничего не доустанавливалось, кроме обновлений безопасности. И её надо откатывать назад. А если не обновлять, то она становится дырявой. И, как я слышал, сейчас в этом плане ситуация не изменилась. Разве что лицензионная десятка теперь, говорят, обновляется вообще не спрашивая, и отменить такое положение невозможно (ну только если в Интернете самого себя забанить). В Debian'е же, которым я пользуюсь, такого не происходит, если всё правильно делать (т. е. не ставить непонятно откуда из исходников и не рушить принудительно зависимости опцией --force-yes в команде apt-get). Правда, Debian (если пользоваться стабильной веткой, на сегодня это Jessie) — один из самых стабильных дистрибутивов. Тот же Mint (точнее LMDE) мне в своё время понравился куда меньше. Он использует нестабильную (testing) ветку Debian-репозиториев.

проще найти, как починить - тупо в силу её распространённости

Думаю, скорее в силу привычки и лучшего знания окон. Информации по линукс на самом деле куда больше в силу его открытости.

вендоры лучше затачивают свои драйвера под винду

Вот это действительно имеет место быть.

некоторые программы, которые я использую на винде, в линукс недоступны и даже через wine не запустятся

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

линукс мне нравится, поэтому я ищу повод попробовать его поиспользовать какое-то как основную систему.

Можно поставить мультизагрузку. Кстати, в Паутину из Линукса выходить безопаснее.

Иксы может и запустились, просто ничего на экране не видно было. В общем, я решил не заморачиваться уже. Всё снёс и поставил 17.3. 18 с новой плазмой всё равно какая-то недопиленная пока что. Пусть пару лет, пока поддержка идёт, пусть стоит 17.3. А там можно будет посмотреть, исправят ли ошибку в ядре. Если да, то может пересяду на 18.x или 19.

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

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

У меня это Visual Studio 2015. Наиболее удобный аналог для меня - Eclipse. Но там непонятно как отладчик настраивать, чтобы он нормально мои типы отображал. Но как-то можно, надо разобраться. У меня и есть дуалбут.

А насчёт debian'а учту, может как-нибудь и его попробую. Но наверное KDE на него самому ставить придётся, и GTK приложения небось там без напильника будут выглядеть как на винде 95.

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

Пусть пару лет, пока поддержка идёт, пусть стоит 17.3.

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

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

Спасибо за информацию. Лично мне оно без разницы, но пацанам передам.

У меня это Visual Studio 2015. Наиболее удобный аналог для меня - Eclipse. Но там непонятно как отладчик настраивать

Имхо, самое удобное — это gdb без каких либо графических надстроек. Там, правда, надо немного подучить команды дебагера, зато потом очень удобно отлаживать.

А насчёт debian'а учту, может как-нибудь и его попробую. Но наверное KDE на него самому ставить придётся, и GTK приложения небось там без напильника будут выглядеть как на винде 95.

Всё там выглядит нормально, как везде. KDE можно выбрать при установке или выбрать kde-live-dvd, как и везде. Но и потом доустановить несложно из synaptic'а.

Единственно, в Debian очень строго подходят к критерию свободы ПО, поэтому из коробки разные проприетарные дрова не заводятся. Обычно это касается wi-fi модулей, которые надо ставить вручную из секции non-free. Это часто отпугивает новичков, хотя ничего сложного в этом нет.

Ну и софт и ядра в стабильном репозитории не самые свежие, зато не глючат и без дыр, т. к. к обновлениям безопасности в дебиан относятся серьёзно. Но если очень нужна последняя версия какой-то программки, всегда можно найти бакпорт из testing или даже из expetrimental либо самому бакпортировать. Только делать это надо, если действительно нужно, а не просто так, т. к. там программы более сырые (особенно в experimental) и уязвимости звкрываются не так оперативно.

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

В старых версиях дистрибутива в репозиториях многие программы старые. Например GCC 4.8 - самая последняя версия, доступная в стандартном репозитории Ubuntu 14.04/Mint 17. Ей уже 3.5 года и она не поддерживает кучу возможностей языка C++, появившихся за последние 5 лет. Если нужна новая версия, приходится для каждой программы искать PPA. А в новых дистрибутивах большинство нужных мне программ уже свежие. В 16.04\18 уже стоит GCC 5.2, что намного лучше. Хотя в принципе 4.8 - это самый минимум, который меня устраивает. Более старые версии уже не компилируют мой код, а этот пока компилирует.

Имхо, самое удобное — это gdb без каких либо графических надстроек. Там, правда, надо немного подучить команды дебагера, зато потом очень удобно отлаживать.

И как это может быть удобным? Каждый раз, когда я хочу посмотреть значение переменной, нужно будет вводить команду? Или как-то по-другому? В IDE можно просто навести мышью или повесить всплывающее окошко со значением переменной. Ещё надо разобраться, как заставить GDB удобно визуализировать свои собственные типы. Например, если я сделал свой контейнер, я хочу видеть не его кишки с указателями, а сами его элементы, как это показывает std::vector. В Visual Studio я для этого использую *.natvis-файлы, а как это делается в GDB, я пока не знаю. Как-то через python что ли визуализаторы делаются...

Всё там выглядит нормально, как везде.

Просто как-то пару лет назад в минте такая проблема встречалась. Долго возился, чтобы её исправить. А в последнее время всё из коробки нормально.

GCC 4.8 - самая последняя версия, доступная в стандартном репозитории Ubuntu 14.04/Mint 17. Ей уже 3.5 года и она не поддерживает кучу возможностей языка C++

Так я ж говорю, используй бакпорты ( https://wiki.debian.org/ru/Backports ). Благо, для Дебиан их полно, а если чего-то нет, то обычно и самостоятельно бакпортировать несложно. Только ознакомиться предварительно с https://debian-handbook.info/browse/ru-RU/stable/debian-packaging.html и с https://www.debian.org/doc/manuals/maint-guide/ . И злоупотреблять ими не надо без особой на то нужды. Кстати, бакпортировать можно не только в Дебиан, но и в любой deb-системе. Да и в rpm-дистрах тоже, только там из-за внутренних зависимостей эта процедура сложнее.

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

Ну да, как-то так. :-) Зато максимальная гибкость и лёгкость и минимум глюков.

В IDE можно просто навести мышью или повесить всплывающее окошко со значением переменной.

Тогда можно посмотреть графические и консольные надстройки, имя которым — легеон! Например ddd для иксов, или nemiver для гнома, или cgdb под ncurses в консоли... Но из этого ничего рекомендовать не буду, т. к. сам не использую.

GCC 4.8 - самая последняя версия, доступная в стандартном репозитории Ubuntu 14.04/Mint 17. Ей уже 3.5 года и она не поддерживает кучу возможностей языка C++

Так я ж говорю, используй бакпорты

Только я сейчас подумал, что бакпорт gcc потребует бакпорта glibc и, возможно, ещё кучи либов, что, в свою очередь, повлияет на всю систему и необязательно в лучшую сторону. Поэтому ставить такой бакпорт лучше в окружении chroot (можно быстро создать командой debootstrap) и запускать оттуда же.

Ну вот и приходим к костылям с чрутом, когда проще поставить PPA или может даже самому из исходников собрать. Хотя я не смотрел, прокатит ли там простая связка configure/make/make install. А я и этого рад был бы не делать, используя новый дистрибутив. Кстати, старые дистрибутивы имеют свойство разваливаться и даже LTS не везде помогает. Сегодня обнаружил, что минт 17.3 KDE разучился качать оформления окон в настройках. Пришлось вспоминать название темы, которая мне нравилась, гуглить её, качать файл и распаковывать непонятно куда. В итоге завелось, но не в 3 клика как раньше. Видимо это просто глюк KDE4 и его серверов, и минт за него не отвечает. Ну и соответственно с любым дистрибутивом с KDE4 будет та же проблема.

По мне так в отладке ничего удобнее IDE нет. Те неудобства, про которые я говорил, когда сравнивал Eclipse со студией, скорее относились к самому gdb, чем к конкретной IDE. Точнее даже не к gdb, а к тому, что я пока не разобрался, как настроитьотображение типов. А в студии уже давно разобрался, хотя там это было тоже не так уж просто.

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

Так какая разница, официальный бакпорт (если он есть), твой собственный бакпорт, ppa или ./configure && make && make install? Т. е. разница конечно есть, т. к. официальный бакпорт (при его наличии) всё-таки удовлетворяет каким-то минимальным требованиям по надёжности, за свой бакпорт ты отвечаешь сам, ppa — это кот в мешке, за который вообще никто не отвечает (не призовёшь же ты к ответу анонимного Васю Пупкина, создавшего кривой бакпорт в личном ppa, который по ошибке рекурсивно удаляет корневую директорию), ну а make install — это гарантированная помойка. Так что первые 2 варианта однозначно лучше.

Я говорил о том, что если для более новой версии gcc потребуется, например, и более новая glibc, то замещать ею glibc из основного репозитория, имхо, опасно, т. к. на эту библиотеку прямо или косвенно завязан абсолютно весь софт в твоей системе. Если повезёт, — всё пройдёт гладко, а нет — всё может быть, вплоть до краха системы. Но то же самое относится и к gcc, скачанному из ppa или откуда-то ещё. Если же новая версия gcc спокойно работает с текущей glibc и не тянет её (и др. системные библиотеки) из backports, то и chroot никакой не нужен.

Кстати, старые дистрибутивы имеют свойство разваливаться и даже LTS не везде помогает.

Я бы уточнил: кривые старые дистрибутивы. К Debian это точно не относится. И, кстати, Jessie - не старый, а актуальный дистрибутив. Просто в Debian придают большое значение надёжности, для чего всё очень долго тестируют и не гонятся за новинками, исходя из принципа «старый друг лучше новых двух». Поэтому в актуальной текущей стабильной версии софт у них слегка устаревший. Хотя, думаю, что и в поддерживаемой oldstable версии, — сейчас это wheezy, — всё ништяк, разве что версии ПО ещё более ранние.

Видимо это просто глюк KDE4 и его серверов, и минт за него не отвечает. Ну и соответственно с любым дистрибутивом с KDE4 будет та же проблема.

Т. е. как не отвечает? Ты ведь качаешь из минтовского репозитория, а не непосредственно с серверов KDE.

в генах, как обычно.

GCC из PPA вроде ничего не замещал и не удалял. Даже если ему и нужно было несколько версий glibc, он бы наверное мог просто поставить отдельно другую версию. Но наверное не нужно, в PPA видимо не просто так свои пакеты для каждой версии дистрибутива. А make install - не помойка, если ставить в отдельную папку в /opt например. Не понимаю, почему вообще в линукс так все программы не ставятся. А то они распределяются по куче папок и только менеджер пакетов может это разрулить, если ничего в нём не сломается.

В Jessie наверное как раз старые версии уровня убунты 14.04/минта 17.

Т. е. как не отвечает? Ты ведь качаешь из минтовского репозитория, а не непосредственно с серверов KDE.

Я как-то сомневаюсь, что они будут форкать KDE и исправлять ошибки за них, а потом ставить это пользователем через обновление. А во всех старых версиях оно сломалось - судя по всему сервер поменялся. Причём это произошло уже после выхода минта 17.3.

Просто в Debian придают большое значение надёжности

опять дебианоклоуны камедиклаб устраивают

GCC из PPA вроде ничего не замещал и не удалял.

Тогда всё Ok. Я просто сказал, что на это стоит обращать внимание до установки, т. к. после — может оказаться поздно. Но если что, то всегда есть безопасное окружение chroot.

Даже если ему и нужно было несколько версий glibc, он бы наверное мог просто поставить отдельно другую версию.

М. б., но не уверен на 100%. Впрочем, при установке пакетов apt-get обычно предупреждает, какие пакеты подтянутся, какие будут обновлены, какие заменены, а какие удалены. Главное — не использовать в таких случаях опций -y и -qq.

в PPA видимо не просто так свои пакеты для каждой версии дистрибутива

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

А make install - не помойка, если ставить в отдельную папку в /opt например.

Всё равно настройки попадут в /etc/, логи — в /var/log/, либы — в /lib*, да ещё какой-нибудь скрытый подкаталог в домашнем каталоге создастся.

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

Тогда тебе нужен GoboLinux :-) ( https://ru.wikipedia.org/wiki/GoboLinux ).

В Jessie наверное как раз старые версии уровня убунты 14.04/минта 17.

Наверно примерно так, хотя вряд ли версии всех программ в точности совпадают с той или иной версией дистра. Ядро 3.16.0, gcc 4.9.2.

Т. е. как не отвечает? Ты ведь качаешь из минтовского репозитория, а не непосредственно с серверов KDE.

Я как-то сомневаюсь, что они будут форкать KDE и исправлять ошибки за них, а потом ставить это пользователем через обновление. А во всех старых версиях оно сломалось

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

Просто в Debian придают большое значение надёжности

опять дебианоклоуны камедиклаб устраивают

Это конечно очень информативное замечание, но хотелось бы услышать более конкретную критику надёжности Дебиана в сравнении с большинством других дистрибутивов.

Вот в Debian почему-то ничего не ломается. И думаю потому, что проверяют и сломанного в стабильные репозитории не загружают.

Попробуй KDE4, там оформления из интернета качаются или как у меня виснет? Речь не о новых версиях, а наоборот о старых. Сервер поменяли, а старая версия не в курсе. Вот и сломалось.

Если честно, то кедами я не пользуюсь. Т. е. либы ставлю ради нескольких приложений, типа kwrite, okular и кое-чего ещё, но не рабочий стол. Но, насколько я знаю, всё качается из репозиториев (если только ты сам не устанавливаешь из исходников, скачанных с сайта разработчика). И обычно всё работает (говорю «обычно» не потому, что были прецеденты, когда не работало, а потому что что-то просто не использую, в т. ч. рабочий стол KDE). Не случайно ведь они годами тестируют и отлаживают новые версии, а в стабильные дистры включают относительно старые, но такие, где всё корректно взаимодействует. И не важно, что там делают на сайте разработчика. У Debian своя стабильная копия в репозитории, и пока новая версия у разраба не начнёт стабильно работать (включая взаимодействие разных модулей), они её в свой стабильный выпуск не включат. А те, кто гонется за последними версиями, толком даже не проверяя их, получают то, что ты описал. Но если интересно, — попробуй в виртуалке. У меня просто нет места на системном разделе для полной KDE.

Прошло какое-то время и оказалось, что Linux Mint 17.3 тоже иногда виснет намертво. Только теперь непонятно, почему. Было пока такое раза три и вроде бы тоже при нагрузке - два раза это было, когда я пользовался Хромом и что-то гуглил. Так что видимо придётся всё-таки на винду возвращаться и поскорее ставить SSD и больше оперативки. А то на ней тормоза невыносимые - диск всегда загружен на 90% и выше, даже если ничего не делать. И оперативки для запуска тяжёлых программ не остаётся.