Стал у меня в начале (склероз: не этого, прошлого) года сбоить EVO870 на терабайт. Заметил по периодическим сбоям на ровном месте, оказывается — ошибки чтения. На нём была только сама ОС и игры, так что заменил без особых потерь. Симптомы простые — в нескольких местах на диске обнаружились локации, откуда ничего не читалось без ошибки. Т.е. никаких этих вот «ssd сбоит, но даёт прочитать хотя бы» — нет, тупо битые файлы, копирование виснет, а «187 Reported_Uncorrect» растёт как на дрожжах. Часть этих зон пришлась на файлы с играми, а некоторые на содержимое /usr. Но поскольку ничего ключевого затронуто не было, то я долго думал, что просто Steam лажает, например.

Если посмотреть SMART, то было примерно так:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9136
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1995
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       3
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       14609
190 Airflow_Temperature_Cel 0x0032   064   055   000    Old_age   Always       -       36
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       14609
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       9
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       4293672984

Error 14609 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 90 69 47 40

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  e1 00 0f 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ef 03 46 00 00 00 40 00      01:22:44.593  SET FEATURES [Set transfer mode]
  ef 02 00 00 00 00 40 00      01:22:44.593  SET FEATURES [Enable write cache]
  e1 00 02 00 00 00 40 00      01:22:44.593  IDLE IMMEDIATE
  ec 00 01 00 00 00 40 00      01:22:44.593  IDENTIFY DEVICE

Error 14608 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 01 10 00 00 00  Error:  at LBA = 0x00000010 = 16

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 00 90 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 88 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 80 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 78 69 47 00 00      01:22:44.005  READ FPDMA QUEUED
  60 08 00 70 69 47 00 00      01:22:44.005  READ FPDMA QUEUED

Error 14607 occurred at disk power-on lifetime: 9135 hours (380 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 51 08 00 6a 47 40  Error:  at LBA = 0x00476a00 = 4680192

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 00 00 69 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 08 00 68 47 40 01      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 67 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 66 47 40 00      01:22:11.833  READ FPDMA QUEUED
  60 00 00 00 65 47 40 00      01:22:11.833  READ FPDMA QUEUED

Self-test execution status:      ( 121)	The previous self-test completed having
					the read element of the test failed.

...

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       80%      9137         10544288
# 2  Extended offline    Completed: read failure       90%      9137         10544288
# 3  Extended offline    Completed: read failure       90%      9136         10544288
# 4  Short offline       Completed: read failure       80%      9136         10544288
# 5  Short offline       Completed: read failure       80%      9136         10544288

smacker@Ideapad510 ~ $ sudo badblocks -v /dev/sdc
Checking blocks 0 to 976762583
Checking for bad blocks (read-only test): 5272132
5272144
5272145
5272146
5272147
5274296
5274297
5274298
5274299
5274516
5274517
5274518
5274519
5276096
5276097
5276098
5276099
5279436
...

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9139         -
# 2  Short offline       Completed without error       00%      9138         -
# 3  Short offline       Completed: read failure       80%      9137         10544288
# 4  Short offline       Completed: read failure       80%      9137         10544288
# 5  Extended offline    Completed: read failure       90%      9137         10544288
# 6  Extended offline    Completed: read failure       90%      9136         10544288
# 7  Short offline       Completed: read failure       80%      9136         10544288
# 8  Short offline       Completed: read failure       80%      9136         10544288

Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   045   045   010    Pre-fail  Always       -       606
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9139
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1996
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       4
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   045   045   010    Pre-fail  Always       -       606
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   045   045   010    Pre-fail  Always       -       606
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       15972
190 Airflow_Temperature_Cel 0x0032   070   047   000    Old_age   Always       -       30
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       15972
199 UDMA_CRC_Error_Count    0x003e   099   099   000    Old_age   Always       -       3
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       10
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       6251131313

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

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

https://youtu.be/FIEwcTKUFCA

Попался мне в руки маленький свитч на гигабит, Mercusys MS105GS. Ну вот захотелось. И на третий день мне стало скучно и решил я посмотреть «что у ей внутре». Неонки не обнаружил, а обнаружил зато 5 нераспаянных пятачков в ряд на плате под интригующим обозначением J4. Вот так: https://imgur.com/a/MmTKwRT

Помню, у adsl-модема DSL-2500U я такие уже видел, и там к ним можно было подлючаться для доступа к консоли. И в целом раза три я пины на всяких девайсах от тп-линка под это распаивал. Но у меня-то в руках неуправляемый свитч, и там рулить-то нечем. Более того, на моделях типа SG1005D, где с помощью разных грязных хаков и тонкого паяльника таки можно внедрить управляемость, нет никаких разъёмов для консоли. А тут вот вроде как есть.

Что думаете?

Вот какие замечательные новости дошли до меня сегодня. Дуалбутчики всего мира были в августе осчастливлены мелкомятыми очередным «обновлением безопасности» (KB5041571 OS Build 26100.1457), которое поломало им загрузку линукса.

https://www.bleepingcomputer.com/news/microsoft/august-windows-security-updat...

https://forums.linuxmint.com/viewtopic.php?t=427297

https://askubuntu.com/questions/1523683/bootloading-ubuntu-24-04-iso-error-sb...

Arstechnica утверждает, что на разработку патчка было 2 (два, Карл!) года: https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-prep...

И вроде как мелкомятые утверждают, что именно дуал бут ломаться не должен, но отзывы благодарных пользователей говорят об обратном. А простой набор из бритвы Оккама и классического вопроса «что делать» «cui prodest» вполне очевидно подталкивают нас к выводу, что это не баг обновления, а самая настоящая фича. Мы, конечно, давно знали, что все эти secure boot и tpm не нужны, но всё-таки как-то неприятно получилось.

«Совпадение? Не думаю.»

На старости лет открыл для себя контейнеры. Конкретно — LXC, конкретнее — совсем ванильный LXC, безо всякого LXD (ибо snap). И возник вопрос: а как по науке организовывать взаимодействие контейнеров со внешним миром, учитывая ограниченность «ванильного» решения? Для LXD, а тем более proxmox/docker/incus советов навалом, а про ванильные контейнеры как-то не особо.

Пока что мне на ум приходит только фиксирование IP за конкретными контейнерами через настройки LXC и создание правил файрволла для маршрутизации на основе тех же номеров портов средствами штатного файрволла системы, но тогда всё равно придётся дублировать порт-форвардинг на маршрутизаторе нормальной сети. Другой вариант — выставить контейнеры наружу через реальный физический интерфейс и сетевой мост, и всю переадресацию повесить уже на маршрутизатор сети, который им же и адреса назначит, и всё что нужно. Варианты с проксированием и macvlan — это уже из LXD.

По идее, даже в локальном применении правил файрволла нет ничего криминального, если принять аксиоматически, что контейнеры создаются с серьёзными целями: скажем, один и вполне конкретный — будет веб сервером, другой — торренты обслуживать, третий ещё что-то конкретное делать. И тогда нет проблем их всех «прибить гвоздями» через правила файрволла и статические ip в собственной локальной сетке, создаваемой LXC. Но всё-таки как-то гложет сомнение. А как «идеологически правильно» это сделать, в условиях, опять-таки, применения сугубо средств LXC и штатных средств ОС?

В общем, лорчик, суть такова: я осознал, что страдаю манией опингвинивать слабые компы. Вот прямо хочется взять какой-нибудь мини-пк на алике, или слабенький ноут по нижнему прайсу, и поставить на него линукс, чтобы смотреть и радоваться — как же хорошо получилось! Как же славно работает! На винде он бы помер, а под линуксом жив-живёхонек и сто лет проживёт! Смотрю уценку DNSа на предмет того, не попадётся ли там по дешёвке днищенское железо, а то руки чешутся что-то опингвинить. Вот недавно взял себе таким макаром 14 дюймовый недобук и опингвинил. Долго радовался. Сначала объяснял это себе, что мне нужен резервный ноутбук, который ничего особо не должен делать, кроме как помещаться в маленькую сумку и работать в течение часов 6-8. А сейчас понял, что хочу ещё. Как бороться с этой навязчивой идеей?

Пока мы помышляем о мировом господстве и ждём, со дня на день, пришествия обетованного Года Линукса на Десктопе, надо бы заиметь торжественную музыку на этот случай. Моё скромное предложение:

https://www.dropbox.com/scl/fi/mgu4ba5sa1m4c2qy092q1/Wenn-die-Pingvinen.mp3?r...

Ото кака фигня, малята: https://mathstodon.xyz/@bremner/112615591101488528

systemd-tmpfiles, deleting /home

TIL (thankfully second hand) that running «systemd-tmpfiles --purge» will delete /home in systemd 256 [1]. Apparently if you think linux is mainly for running cloud services, this seems reasonable to you. Or something.

[1] tested with systemd-tmpfiles --dry-run --purge on debian. I guess it _could_ be a Debian addition, but I'm guessing not.

Как сообщает блог It's FOSS, в свежей долгоиграющей Убунте обнаружилась странная особенность: как будто по недосмотру, в рамках DE пакеты DEB перестали быть по умолчанию ассоциированы с какой-либо программой для их установки. При этом даже если выбрать «открыть в App Center» (а ничего другого подходящего там и нет) через контекстное меню, App Center просто зависает и не позволяет ничего сделать с пакетом.

И это не первая ласточка: начиная с 20.04 действием по умолчанию для DEB пакетов оказалось открытие в менеджере архивов, каковое положение вещей сохраняется и по сию пору по крайней мере в режиме Live OS (см. скриншот). А аналогичная нынешней ситуация воспроизводилась ещё в 23.10, но только сейчас оказалсь «канонизирована» в рамках релиза LTS, хотя вопрос был поднят в виде баг-репорта к 23.10 уже более полугода назад. Но с точки зрения Canonical, это вопрос крайне неприоритетный, и в рамках релиза LTS 24.04 решать они его не собираются. «Живите теперь с этим» фактически является официальной позицией — как пояснил один из разработчиков, к решению этой «фундаментальной проблемы» они обратятся только «в следующем цикле» в силу якобы нехватки ресурсов для её решения прямо сейчас.

Возникает логичное объяснение случившемуся: это ничто иное как очередное свидетельство того, что Canonical взяли курс на отказ от построения системы вокруг DEB пакетов в пользу Snap. И делая установку DEB пакетов ещё несколько более муторной для пользователя (само собой, можно поставить ту же gdebi и привязать к ней действие по умолчанию для DEB пакетов — но это нужно делать специально; ну и, конечно, установка через apt в терминале по-прежнему работает), они постепенно «отучают» пользователей от использования DEB, создавая искусственные неудобства с ними на пустом месте.

Скриншот: www.linux.org.ru/images/21237/original.png

Подробности на It's FOSS: https://news.itsfoss.com/ubuntu-24-04-disappointment/

Подробности на «It's FOSS»


Перемещено hobbit из ubuntu

Чота я запарился искать такую штуковину. Мне б в файлопомойку на атоме не помешало добавить USB 3 (раз уж eSATA/eSATAp склеили ласты), но все контроллеры на PCIe, а там как раз один слот обычного PCI. А специального идентификатора для «обычного» PCI просто нет, так что при поиске никак не отделить зёрна от плевел, а агнцев от козлищ, и на том же али меня заваливает контроллерами на PCIe, если там и есть что на PCI, так мне этого никак не раскопать. А они вообще есть? Может, я зря ищу-то?

Настал момент такой, что надо бы поменять термопасту в паре мест. И вроде как есть остатки MX-4, который умудрился не засохнуть за 10 лет, так что по идее могу и на дедовских запасах, так сказать, прожить. Но решил почитать, что нонча пишуть в антернетах. И к каждой второй, если не первой, термопасте постоянно претензии — густая, плохо липнет, трудно намазывается и т.д. и т.п.
А я, стало быть, от жизни-то отстал. Не знаю, как оно чё нынче. Чем таперича принято мазать бутерброд проц? Нормально ли (и правда ли), что все через одну термопасты нынче густые, и даже MX-5 уже не торт?

К текстовому редактору (конечно же, vim) или imagemagick-у в консоли все привыкли, этим никого особо не удивишь. Аналогично, moc или calcurse тоже, наверное, нельзя назвать неожиданным поворотом мысли. А вот какие программы приходят вам на ум, если нужно называть самые необычные/неожиданные/удивительные варианты? В духе «вот уж не ожидал, что кто-то такое всерьёз напишет, а потом этим ещё и можно будет пользоваться»?

У меня это sc-im (vim-подобные электронные таблицы) и visidata (верный друг дата-сайентолога).

Хочу странного: определить концептуальный тип накопителя, подключенного по USB (флешка, карта памяти, внешний жёсткий диск, внешний ssd, оптический привод). Уповал на ROTA в lsblk для разделения внешних жёстких и флешек, но он, подлец, рапортует «1» для всех USB устройств, и т.о. работает только для локальных SATA/PATA приводов. Можно в lsblk задетектить rom через тип устройства, и т.о. определить оптический привод, но неизвестно, насколько надёжно, но пока пусть будет так. Остальные устройства друг от друга ничем вроде бы не отличаются. Идея угадывать (читай: регекспами) по названию девайса мне кажется изначально порочной. Есть какой-нибудь способ это сделать по-человечески (и без привилегий рута)?

UPD: отличать оптику/hdd/ssd можно через специфические записи в выводе udevadm info. С флешками и картами памяти в кард-ридерах сложнее. Кроме того, lsblk помечает внешние usb диски как несъёмные, так что нужно ориентироваться на HOTPLUG.

Балусь тут со старым нетбуком (нашлась планка памяти в ящике стола, оказалось — подходит). Но всё равно там только 2 Гб, так что решил настроить icewm для экономии (-300 мб после загрузки получилось). Потихоньку сделал его более привлекательным визуально, чем дуга электросварки. Однако по части переключения раскладки я чота п. Ман учит нас, что есть две опции для ~/.icewm/preferences, одна задаёт список раскладок, другая клавиши для переключения. Написал:

KeyboardLayouts="us","ru"
KeySysKeyboardNext="Ctrl+Shift"

Тут такая интересная инфа просочилась в инфополе. Оказывается, у IBM и Red Hat в ходу корпоративные расистские тренинги. Ну, вернее, они подаются как «прогрессивные анти-расистские», конечно, но так и Северная Корея себя называет «демократической республикой». А на самом-то деле всё совсем наоборот. Так и тут.

Вот тут можно полюбопытствовать, что же утекло: https://conservativenerds.locals.com/post/4996525/ibm-red-hat-whistleblower-l...

Материалы есть презанятнейшие. Кроме утверждений, что «только белые люди могут быть расистами» (от создателей «только ситхи всё возводят в абсолют»), там есть такие перлы, как «древние греки ездили в Африку учиться наукам, потому что там уже всё было». Ну и не хочется чрезмерно цитировать, чтоб не дай бог не показалось чего-то не того, но всё вращается вокруг откровенного расизма в классическом смысле и странных заявлений. Я бы даже сказал, это уже клиническая зацикленность на расовой теме, граничащая с параноидальными идеями.

Такие дела, котаны. А мы-то думаем, почему они везде пихают вяленого, выпиливают функции из гнома, щемят CentOS и закрывают сорцы. Мне теперь вполне стало ясно, какие там настроения владеют умами... жалко, что до линукса и опен-сорса докатилась эта корпоративная «прогрессивная» чума.

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


И вот, http://www.seoded.com/2023/11/28-devternity.html

Есть такая мера качества нынче — представленность женщин. Хитрые орги конференции во имя ПОВЕСТОЧКИ стали плодить фейковых спикерок (спикересс? спикерынь?), которые само собой будучи зявленными в программе не появлялись на мероприятии, но были снабжены некоторым фейковым присутствием в соцсетях. Но не долго музыка играла, не долго фраер танцевал — спалили. Теперь все осуждают и от конференции отказываются. Мол, не по-людски. Хотя как по мне так как раз по-айтишному.

🤡🌏

А вы сталкивались с таким?

Такие дела — вдруг, практически откуда ни возьмись, со вчерашнего вечера стало каждые несколько минут отваливаться проводное соединение (r8169, 5.15.0-78/76). В dmesg:

[  251.118395] r8169 0000:01:00.0 enp1s0: Link is Down
[  253.694702] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  254.052888] r8169 0000:01:00.0 enp1s0: Link is Down
[  256.796432] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  269.570727] r8169 0000:01:00.0 enp1s0: Link is Down
[  272.252308] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  302.297242] r8169 0000:01:00.0 enp1s0: Link is Down
[  304.894322] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  309.748182] r8169 0000:01:00.0 enp1s0: Link is Down
[  312.387393] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  313.071430] r8169 0000:01:00.0 enp1s0: Link is Down
[  315.857187] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  320.375260] r8169 0000:01:00.0 enp1s0: Link is Down
[  322.983243] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
[  330.535909] r8169 0000:01:00.0 enp1s0: Link is Down
[  333.206734] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx

ethtool --set-eee enp1s0 eee off

smacker@Ideapad510 ~ $ ethtool --show-eee enp1s0 
EEE Settings for enp1s0:
	EEE status: disabled
	Tx LPI: disabled
	Supported EEE link modes:  100baseT/Full 
	                           1000baseT/Full 
	Advertised EEE link modes:  Not reported
	Link partner advertised EEE link modes:  100baseT/Full

Есть у меня ноутбук маленький (Mint 20, Mate, 5.8.0-38), у которого на клавиатуре нет PgUp/PgDn/Home/End на стрелочках (т.е., конечно, не в гравировке дело — обычный Fn+стрелочки не работает). Ну, дело-то нехитрое вроде бы: сделать правый Alt клавишей Mode_switch и добавить сочетания клавиш:

/usr/bin/xmodmap -e "keycode 108 = Mode_switch"
/usr/bin/xmodmap -e "keycode 113 = Left NoSymbol Home"
/usr/bin/xmodmap -e "keycode 114 = Right NoSymbol End"
/usr/bin/xmodmap -e "keycode 111 = Up NoSymbol Prior"
/usr/bin/xmodmap -e "keycode 116 = Down NoSymbol Next"
/usr/bin/xmodmap -e "keycode 119 = Delete NoSymbol Insert"

Но оказывается, что при переключении раскладки с английской на русскую, клавиша Mode_switch считается нажатой, и стрелочки начинают работать как PgUp/PgDn и т.д., и нажимать левый Alt нужно уже для того, чтобы они работали как стрелочки.

У меня теперь два вопроса: можно ли как-то отвязать поведение Mode_switch от переключения раскладок, и может есть какой-то более вменяемый способ добиться желаемого?

Сегодня оглядел свой ростер — тишина... и только мёртвые с косами стоят. Куча народу с 404, ряд товарищей с упразднивших xmpp gmail/yandex, ряд просто не появляющихся. В общем, на полсотни контактов не набирается и десяти активных.

Учитывая, что у меня большинство людей не с форумов любителей вязания, а программисты/линуксоиды, возникает вопрос: чем же все теперь пользуются, да и пользуются ли в принципе. Как-то не верится, что линуксоиды коллективно отринули XMPP и пересели на какой-нибудь телеграм...

Имею ideapad i510, третий день наблюдаю сбои в работе suspend-а: ноутбук выключался при попытке его разбудить. Стал разбираться, и понял, что проблема не в suspend и не в hibernate — результаты одинаковые — после пробуждения ноутбук мигает подсветкой, немного шуршит диском и отключается (где-то секунды за 2-3). После повторного нажатия кнопки включения всё работает и загружается нормально.

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

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

Биос не обновлял, ядро обновлял (обычное от Mint из репозиториев, сейчас 4.10.0, но и с 4.8 и 4.4 та же петрушка). Не знаю, то ли за новым зарядником идти, то ли целиком надо в ремонт сдавать, то ли всё-таки проблема программная каким-то образом.