Пользователи различных дистрибутивов Linux, у которых применяется планировщик ввода/вывода BFQ, после обновления ядра Linux до выпуска 5.14.7 столкнулись с проблемой, приводящей к краху ядра в течение нескольких часов после загрузки. Проблема также продолжает проявляться в ядре 5.14.8. Причиной стало перенесённое из тестовой ветки 5.15 регрессивное изменение в планировщике ввода/вывода BFQ (Budget Fair Queueing), которое пока устранено только в виде патча...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55886
Видимо придётся весь парк ЭВМ и ПЭВМ переводить на ОС FreeBSD, OpenBSD и NetBSD. Там бага 12309 нет и проблем с планировщиками тоже.
А зачем их с венды куда-то там переводить? В ней никакого 12309 нет.
В виду недосказанности вы меня неправильно поняли. Прошу прощения за такой просчёт. Переход конечно с ОС Linux на семейство ОС BSD.
Эскобар чота ржот...
Прав
В винде с 8рки завезли 12309, до сих пор в наличии
С висты если быть точнее. Там объём прокачиваемых данных такой, что про блины можно забыть. Только ссд.
> А зачем их с венды куда-то там переводить? В ней никакого 12309 нет.А в венде уже можно работать а не только обновлятся сутками? А ctrl+insert, shift+insert уже починили? А интерфейс нормальный сделали?
Не, точно нельзя. И не починили (потому что и не ломалось ничего). Не, не сделали. Ни вафлянда нормального нет, ни десяти прослоек чтоб иксовые программы запускать, и в них dialog.Вообще жизни там нет. Сказочки впопеннетчиков. На ночь лучше не читать.
Не наброса ради, а просто наблюдение.Недавно копировал со 128Гб флэшки большое видео и несколько десятков фото на Win10 (лицензия, последние обновы, всё такое). Так у интерфейса были такие тормоза, что вспомнил 12309 сразу. На этом же компе на Gentoo с KDE ничего подобного нет и не было уже много лет. Обе системы на одном и том же быстром NVMe SSD стоят.
Шутки шутками, но это фиаско и абсолютный провал. Мне всегда говорили, что только Винда может накрыться после обновления, а оно вон оно как.
шутки шутками, но наличие идиотов на техническом форуме, сравнивающих ядро с дистрибутивом ОС, просто зашкаливает.
В его словах есть логика: то, будут ли вообще работать дистрибутивы без шаманства, напрямую зависит от ядра.
Мейтейнеры дистров свежачок-ядра без тестирования в базу не включают, как бы.
Manjaro Linux вполне себе успешно выпадает в черный экран без возможности ввода, после установки на голый метал применения обновлений.
После нескольких лет использования арча понимаешь, что манжаро не нужно...
Винда без наворотов в виде телеметрии и индусокода на новой UWP очень даже ничего.
> Мне всегда говорили, что только Винда может накрыться после обновлениявас обманули.
но: только Винда может отказаться принимать обновления (показанные в интерфейсе как необходимые !) либо откатывать их взад по неизвестно каким причинам.
в последнее время я думаю над быстрой принудительной установкой всей пачки за один проход (семерка, 2008 r2). типа самодельного SP2. "sfc /scannow" при этом накроется, да и черт бы с ним.
>Шутки шутками, но это фиаско и абсолютный провал.в каких дастрах по дефолту BFQ? в арче смотрю - mq-deadline
>>Шутки шутками, но это фиаско и абсолютный провал.
> в каких дастрах по дефолту BFQ? в арче смотрю - mq-deadlineпри дефолтном mq-deadline на арче при копировании файла (с HDD) на флешку все начинает жутко тормозить и фризиться. После переключения на BFQ стало получше! Где-то читал, что mq-deadline и kyber больше подходят для SSD.
Зачем в конторе используешь не LTS?
Похоже, он Linux вообще не использует.
От чего такие выводы? Я как раз от этого бага страдаю в нагрузке. GUI начинает намертво виснуть. Спасал лишь BFQ и Kyber. На mq-deadline тормоза графики.
Смешно видеть, как минусуют просто потому, что не верят. Ну что же, отрицание – одна из стадий принятия.
нет б..ять, на техническом форуме должны на слово верить какому-то мамкиному анониму. сиди дальше щёчки надувай.
Ну так откати ядро/накати патч и живи спокойно
Потому что никто в продакшн последнее ядро не тянет. И практически никто - не тянет напрямую с kernel.org, пользуются дистрибутивным.
> переводить на ОС FreeBSD, OpenBSD и NetBSDВот на все 3 сразу и переводи, чо. Зато отпишешься что из железа не завелось, какого софта нет.
Перепись нелинуксойдов на опеннете объявляется открытой.
Записываем всех нытиков, потому что до реальных линуксойдов это ядро либо не доехало, либо они понимали что делали когда (вручную) ставили свежатину и не ноют, а просто откатились/накатили патч.
А какая там последняя версия ядра работает на i386?
ты, часом, форумом не ошибся, счетовод? чай, не на ЛОРе.
12309 вечен, как можно банальным копированием загружать ryzen 3600 даже на 10% в уме не укладывается, и чем медленнее диск тем сильнее загрузка процессора, при копировании система так же лагает, как и 10 лет назад, на винде ничего не лагало, даже на пентиумах третих можно было копировать в фоне и работать не замечая ничего.
Ох уж эти свидетели 12309... Иеговисты нервно курят в сторонке.
Так может и тут не к тому таймеру присосались?
>Видимо придётся весь парк ЭВМ и ПЭВМ переводить на ОС FreeBSD, OpenBSD и NetBSD. Там бага 12309 нет и проблем с планировщиками тоже.Не надо забывать про illumos.
https://ru.wikipedia.org/wiki/Illumos
http://www.dilos.org/
https://ru.wikipedia.org/wiki/OpenIndiana
> Не надо забывать про illumos.Расскажи это мэйнтейнерам иллюмоса для начала. Ну и сам попробуй на неё со своего вантуза перейти. Хоть на неделю.
Я свой дистрибутив делать планирую. А в чем проблемы?
Денис Попов, срочно перелогиньтесь.
Вся суть анонимов. По сути пояснить нечего, сразу переход на личности.
Шото ты сам не залогинен...
Я же говорю, стрелки переводить и ни слова по существу.
"планирую", LOL
Солярка как была на голову выше пингвина в 2005-ом, так и остаётся. Пингвин с тех пор раздулся на порядки но в ширину, а не в высоту.
у админа нет цели, есть только путь
и это, чтобы потом не переделывать сразу все сетапте, потом просто другое запустите и норм.
Раньше думал что 12309 это миф и криворукость. А потом вылезло на одной из машин амуде.
забиваешь оперативку на 98-99% и система встает колом.
Линуксоиды: да оффтопик после обновления может накрыться! А вот Линукс может годами работать!
Те же линуксоиды: крах ядра в течение нескольких часов после загрузки из-за обновления.
Тычешь reset - и еще несколько часов ведро - как новое! Годами можно ТАК работать. Это тебе не виндовос поганый, от которого мышами воняет!
Не, так сейчас не модно.
Я раньше в COM порт писал с определенной периодичностью. Если по истечении этого времени не дергался порт, то железяка замыкала reset. Вот такая не хитрая автоматизация была.
И во многих стабильных дистрибутивах 5.14?????
> И во многих стабильных дистрибутивах 5.14?????В Fedora давно в репах. Но ты сейчас скажешь, что "это другое" и Fedora-то она нестабильная и вообще не Linux. Этот позор лежит на ядре, а не на дистрибутиве - используется ли эта версия в "стабильных" дистрибутивах - не важно, я свободен скачать ядро и скомпилировать его сам и не хочу, чтобы система крашилась через час.
Ну, вообще-то да, внезапно какой-нибудь Ubuntu LTS -- это действительно не Fedora. И использование Fedora -- это личный выбор людей, которым нравятся как дела делаются в Fedora. То есть, да, это другое.
> Ну, вообще-то да, внезапно какой-нибудь Ubuntu LTS -- это действительно не Fedora.
> И использование Fedora -- это личный выбор людей, которым нравятся как
> дела делаются в Fedora. То есть, да, это другое.Окей. Допустим, я под Убунточкой сам скачал борцы, собрал ядро из _стабильной_ ветки и система накрывается. Как это оправдывает мейнтейнеров?
Моргни если тебя заставляют это делать.
Это не оправдание. Мейнтейнеры Линукса действительно обложались, не должен пойнт релиз стабильной ветки ломать всё к чертям. Мне лень уж чекать номерок того анонимуса, что тут про Убунту говорил, но тем не менее: на кой чёрт ты сюда её приплёл? Про неё речи вообще не былокапча 07239, держу в курсе
Вы взяли среди атрибут воле ядро, сами нахимичили и получили панику? По мне это вполне нормально. Знаете что такое canary в вопросах landing/deploying? Вот вы решили canary версию развернуть у себя вопреки отсутвию её в репозитории, а виновата Ubuntu? Да, можно было бы спрятать исходные тексты нетестированной в prod версии, в мире Linux все априори считаются достаточно взрослыми, чтобы понимать что и как использовать.
s/атрибут/своей/ (чёртова автозамена)
> В Fedora давно в репахВ каких? В моих репах для 34 федоры пока еще 5.13
В репах-то, оно в репах... Вот только с пометкой candidate, то есть, без дополнительных телодвижений 5.14.7 даже в Федору не поставишь. Что, что, а ядро в Федоре таки тестируют перед сменой версии.
> В Fedora давно в репах.Нет, в основной репе сейчас только 5.13.19. 5.14 есть в бете 35, а также у тех, кто накатил билды из Koji для тестов (что суть та же ручная установка).
Да, в Fedora в репах для релиза Fedora 35. На релизе Fedora 35 большими синими буквами написано «Beta». И да, это другое, погугли, что такое «бета».> Этот позор лежит на ядре, а не на дистрибутиве - используется ли эта версия в "стабильных" дистрибутивах - не важно, я свободен скачать ядро и скомпилировать его сам и не хочу, чтобы система крашилась через час.
Ты скачал тестовую версию ядра, не предназначенную для постоянной работы, не рекомендованную твоим дистрибутивом и неоттестированную майнтейнерами твоего дистрибутива.
Она сломалась. Странно. Удивительно.
А у меня билд 11-й винды падает. Этот позор лежит на Microsoft.
В Убунту тестовую даже, 21.04, не решились добавить.
У маньяры, как раз 5.14.7.
Но штука в том, что нет bfq в приличных репозиториях.
Есть, оно компилиться с ядром, просто не включено по умолчанию.
У маньяры, как раз 5.14.7.
Но штука в том, что не bfq в привичных девайсах.
Ну... В системде, справедливости ради, и более серьёзные баги были. Просто поверь. И ничё, исправили(этим машинам недавно 666 дней аптайма стукнуло). А тут - бага ядра, даже не дошедшая до лонгтерм-ветки.
И мы снова возвращаемся к разговору, что какие-то ядра "правильные", а какие-то нет. Умора! Слово "stable" на kernel.org, очевидно, ничего не значит.Особенно мило это будет для новых пользователей ОС - вы не должны (!!!) доверять kernel.org и основным (!!!) kernel maintainers, только hardcore, только RHEL.
Ничего, что ядро RHEL не поддерживает новые GPU от AMD - "ой, вы знаете, давайте лучше Ubuntu LTS" - и пошло поехало. Что и ядро Ubuntu LTS не всё поддерживает, "ой, я не знаю".
// b.
> И мы снова возвращаемся к разговору, что какие-то ядра "правильные", а какие-то нет. Умора! Слово
> "stable" на kernel.org, очевидно, ничего не значит.абсолютно. Мне лет двадцать назад один очень уважаемый (и было за что) человек популярно объяснял - "stable означает что это стабильно для разработчиков, и в этой ветке _апи_ сильно ломать уже не будут".
Сам догадайся, что бы оно могло означать сегодня, когда от разработчикво строго настрого требуется поклоняться только linux-next и никаких унылых патчей для немодных версий кроме исправляющих подобные вот ошибки - не присылать даже в мыслях.
> один очень уважаемый (и было за что) человек популярно объяснял"Какой-то Васян мне что-то сказал и я поверил. А вот главным разрабам ядра с десятилетиеми опыта системного программирования, которые и пишут код, я не верю".
Это всё, что нужно знать о фанатах свободы.
Это не фанат свободы, а поросший мохом бздшник, спятивший от застарелой злобы, .
Заспорил фанат о фанатизми...)
Главные разрабы ядра с десятилетиеми опыта системного программирования, включая САМОГО, _везде_ говорят об предпочтительном использовании ядер из дистрибутивов, и использовании ядер из kernel.org, только если пользователь знае зачем это делает.
Это относится и к самостоятельному компилированию ядра.
Используйте ЛТС ядра из дистрибутивов, или иное, в случае если знаете что делаете.
Проблема вот в том, что можно ложно предположить, что знаешь без RTFM.
> Главные разрабы ядра с десятилетиеми опыта системного программирования, включая САМОГО,
> _везде_ говорят об предпочтительном использовании ядер из дистрибутивов, и использовании
> ядер из kernel.org, только если пользователь знае зачем это делает.
> Это относится и к самостоятельному компилированию ядра.
> Используйте ЛТС ядра из дистрибутивов, или иное, в случае если знаете что
> делаете.
> Проблема вот в том, что можно ложно предположить, что знаешь без RTFM.
> _везде_ говорятПро вот этот Piздец, пожалуйста, по-подробнее, потому что ничего такого нет ни на kernel.org, ни в LKML.
Ты вы Piздите и не краснеете.
Потому что только дятлы могут сравнивать ядро с дистрибутивом ОС. В дистрибутивах линукса этого ядра в стабильных репозиториях ещё нет, только в тестовых.
Наличие ошибок никто, между прочим, не отменял. Даже в линуксе, как в ядре.
так воспроизводится тольк с btrfs?
Bfq – планировщик для всех носителей, а не для какой-то конкретной ФС.
Но воспроизводится ведь только с BTFS?
И кто-то после этого будет продолжать удивляться, что на электростанциях и вообще критичных к стабильности производствах не используется Linux?
А что там используется, умник?
> А что там используется, умник?два линукса же ж! Пока у одного ведро перезагружается, второй работаит.
Рубильник, неонка и электрик дядя Вася
Исправил: Разъединитель, указатель напряжения и оперативник Вася :)
OpenBSD, конечно же.
И самого Тэо в качестве оператора! Вотъ!
> А что там используется, умник?На, выбирай: https://en.wikipedia.org/wiki/Comparison_of_real-time_operat...
>На, выбирайДело за малым: узнать для чего именно применяются rtosба где их применение неуместно.
Почившую ныне QNX заменяют на VxWorx, а тем временем развивается https://www.cip-project.org/
> https://www.cip-project.org/Нагромоздить на Debian "set of industrial-grade core open source software components, tools and methods" - это, конечно, будет киллер всех индустриальных RTOS.
Естественно, будет. Ведь за де6иллиан не надо денег никому платить! Шва.... БЕСПЛАТНОЕ! Взять-взять-взять!
Сильно подозреваю, что дело не столько в стоимости самого софта, а в стоимости разработки. Сишник, умеющий грамотно писать реалтаймовый софт под реалтаймовую ось, стОит гораздо более других денег, чем питонист или жабаскрптер.
аврал !
в несерверной и не присутствующей в стандартной поставке ни одного дистрибутива ветке ядра, фактически в тестовой, обнаружили ошибку.
все срочно сваливаем куда-нибудь !
🤔
>фактически в тестовойНет. Эта ветка находится в ветке stable, и для Fedora, например, уже лежит в репах, так что да, это действительно фиаско и крах репутации мейнтейнеров ядра и самого ядра. Никакими отмазками в духе "ой, да это же почти фактически тестовая версия" тут не помочь.
> для Fedora, например, уже лежит в репахДля текущих поддерживаемых версий, она лежит в testing-e. В стабильных репах — ничего не сломалось.
https://bodhi.fedoraproject.org/updates/?packages=kernel
>> для Fedora, например, уже лежит в репах
> Для текущих поддерживаемых версий, она лежит в testing-e. В стабильных репах —
> ничего не сломалось.
> https://bodhi.fedoraproject.org/updates/?packages=kernelИ что? Я хочу использовать самое свежее _стабильное_ ядро. Я его поставил из реп. Что не так?
Ты поставил его из тестируемой ветки и со всеми рисками такого поступка должен быть знаком.
Какова ныне доля пользователей именно bfq — тоже интересный вопрос. Я думал, что он уж больше 10 лет никому особо не нужен.
Чтооооооооооо?Он по default в большинстве дистров, включая RHEL.
// b.
cat /sys/block/xvdc/queue/scheduler
[mq-deadline] kyber bfq noneOEL и UEK, можно спать спокойно.
Для nvme по дефолту используеться none. Так что зацепит только тех, кто вручную сделал. А таких мало, бо bfq уфастный.
при чем тут nvme?задеты любые локальные блочные устройства.
Нет, задеты только пользователи bfq, включившие его самостоятельно. Но я, как бубунтовец - даже этого сделать не могу, ибо:
$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none
для этого надо специально собрать новое ведро, чтобы специально напороться на багу.
modprobe bfq
Но зачем? Ради воспроизведения баги?
Чтобы обидеться на неправильный линукс.
> Нет, задеты только пользователи bfq, включившие его самостоятельно. Но я, как бубунтовец
> - даже этого сделать не могу, ибо:
> $ cat /sys/block/sda/queue/scheduler
> [mq-deadline] none
> для этого надо специально собрать новое ведро, чтобы специально напороться на багу.сейчас под рукой линукса нет, там, помнится, udev правилом это прописывалось?
> сейчас под рукой линукса нетВот этим можешь и закончить. А лучше - и вообще не начинать.
не обижайся на безрукого
не знаю как там в Убунте но в том же Арче по дефолту
$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfqда и в самой арчвики по этому поводу:
The process to change I/O scheduler, depending on whether the disk is rotating or not can be automated and persist across reboots. For example the udev rule below sets the scheduler to none for NVMe, mq-deadline for SSD/eMMC, and bfq for rotational drives:
/etc/udev/rules.d/60-ioschedulers.rules
# set scheduler for NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
# set scheduler for SSD and eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# set scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"то есть bfq ненавязчиво рекомендуют использовать разве что на HDD
А ты с планировщиком процессов BFS от Коливаса не путаешь?
Нет.
С распространением SATA-дисков (и NCQ) варианты none и deadline стали становились всё более популярными.
UDEV-овские правила, правда, предлагают BFQ для HDD (но не для SSD и NVMe).
> Нет.
> С распространением SATA-дисков (и NCQ)с распространением 12309. Причем бы тут - ncq? Это просто способ разгрузить процессор, она неглубокая и не может ничем особо помочь при массовой записи.
deadline позволял немного нивелировать последствия 12309 на _сервере_ (которому не надо повышать приоритет foreground tasks). Всё.
Никакие другие причины, приведшие сперва к cfq а потом к заменившему его модному bfq потому что никто не мог уже понять, как вообще этот cfq работает и как его переписать на модные апи, проще показалось переписать с нуля - никуда не девались, rotating disks по прежнему требуют перегруппировки операций записи для эффективной работы.
> UDEV-овские правила, правда, предлагают BFQ для HDD (но не для SSD и
естествено.
Ну я вижу впопеннетовцы давно неиспользуют немодные вращающиеся ржавчины, да и куда бы оно в их макпуке поместилось бы, действительно.
>с распространением 12309А существовал ли вообще этот самый 12309 иначе как в виде мема? Насколько помню, к 12309 относили ворох самых разных багов, вызывающих снижение отзывчивости системы и/или скорости копирования при нагрузке на дисковую подсистему. Проявлялось это далеко не всегда, не у всех, часто при каких-то комбинациях контроллеров матплаты, моделей дисков, количества дисков и т.д. Почему, собственно, так долго не могли и починить — один баг починят, так второй проявляется, второй починят, так третий. Подозреваю, что какую-то часть и вовсе не починили, просто неактуально стало в связи со снятием с производства «проблемных» дисков и матплат.
Я лично вот этот самый 12309 видел далеко не на всех компах с линуксом того времени. И сталкивался именно с вариантом «сейчас всё хорошо» и «добавили винт, и всё стало плохо; убрали этот винт, добавили другой — получше; переставили плохую пару винтов на другую матплату — опять хорошо».
>Причем бы тут - ncq?
Что-то мне такое вспоминается, что совместная работа ncq + cfq давала в итоге меньшую скорость/отзывчивость, чем ncq + none/deadline/anticipatory. Причём именно на десктопе. Не замерял, особой разницы тоже не замечал. Вроде как они могли мешать друг другу. Как там с более-менее новыми планировщиками — уже не интересовался.
> А существовал ли вообще этот самый 12309существовал.
> Насколько помню, к 12309 относили ворох самых разных багов,
все эти баги волшебным образом исчезали при откате ведра на три-восемь версий назад (поскольку появлялось не сразу, никто не знал точно, в какой именно) на том же самом железе.
Объем внесенных изменений был явно ограничен и вполне человекопознаваем.Но это были кого надо изменения, поэтому о том чтобы откатить их нахрен никто и не заикнулся.
Проще было рассказывать про ворох разных багов и "у меня не воспроизводится". А потом дважды баг закрыть как "исправленый", но потом на всякий случай еще и запретить доступ к нему.
> Вроде как они могли мешать друг другу.
запросто, потому что в cfq нагородили такого, что никто не мог сказать внятно, как оно вообще работает-то. "Вроде что-то улучшает". По этой же причине его проще оказалось выкинуть чем переделать. Ну, теперь никто толком не понимает, как работает bfq ;-)
Критическая ошибка в двух подряд "стабильных" релизах ядра. И, да, оно уже есть в Arch, Gentoo и Fedora testing. А что, теперь фанаты Линукса будут нести, что только "серверные" ядра правильные, о остальные - нет? Тьфу ты!Признаться, что никакой "стабильности" в Линуксе нет, и что QA/QC в Open Source - это матерные слова у вас храбрости не будет.
И последнее: 5.13 уже deprecated (!!!!), 5.14 - убогое говно, которое приводит к потере данных. Вся суть Линукса. Ошибка известна уже несколько дней - где fix на kernel.org?! Всем глубоко наплевать.
А потом удивляемся про 2%. Скажите спасибо за 2%, ибо с таким отношением вы даже 0.2% не заслужили.
// b.
Этот аноним порвался. Несите следующего
Геть из нашего стана! Аноним он легион. Единый и неделимый.
Не вникайте. В ядре критический баг: "Ой, да это всё равно тестовая версия".
Но нет, это стабильная ветка: "Ой, да ведь ни в одном дистре нет".
Но нет, уже есть, как минимум, в Fedora: "Ой, да кто Федорой-то пользуется?".
Окей, а если я сам скачаю и скомпилирую эту "стабильную" версию ядра сам? "Ой, да кто последние-то версии ставит себе, ядру надо настояться! ССЗБ!"
Но зачем тогда выкладывать заведомо нестабильное ядро? "Ой, а в Винде зато раскладка переключается не с первого раза!"
> “Ой, да кто последние-то версии ставит себе, ядру надо настояться! ССЗБ!”Продолжу, а если моё новое оборудование поддерживается только в последней версии ядра?
“Ой, да кто новое оборудование ставит себе, железу надо настояться (лет 10)! ССЗБ!”
> Но зачем тогда выкладывать заведомо нестабильное ядро?А тестировать кто будет?
Ну и да, весь серьёзный бызнес к 5.14 ещё и не подходил.
О, этот новый дивный аргумент, что какие-то ядра реально "стабильные", на kernel.org слово "stable" ничего не значит. В этом обсуждении его уже повторяли раз 30. От этого валидным он не стал.И какие конкретно enterprisise ядра, уважаемый? Назовите весь список, пожалуйста! А ещё расскажите как обычный пользователь должен об этом был узнать.
Т.е. по вашим словам Linux = это RHEL, а остальные дистры это как бы гумно, так?
Классно. Т.е. 99.9% дистрибутивов Линукса небезопасны и пользоваться ими нельзя.
Отличная картина вырисовывается.
> enterprisiseВ Ubuntu нет 5.14 и ждать ещё долго.
В Oracle Linux нет 5.14 и ждать ещё долго.Ну всё.
Ну если используется связка bfq+самое последнее ядро, то действительно риски есть. Никто и не спорит. Но в подобных не самых стандартных условиях великой стабильности никто и не обещал. Больше всего тестируется то, что используется массово.
BFQ в 2008 году выпущен, ало. А ядро стабильное.
Да прекрасно что он выпущен в 2008 году. Ну вот и стоит задавать вопросы его мантейнерам в ядре. Но дело в том, что на отказоустойчивость такое решение как bfq+последнее ядро никто не тестирует. Там где важна надежность такая связка в принципе не используется. А для любителей экзотики всегда есть вариант перезагрузиться и откатить версию ядра. Но они точно ни с чем критически важным дела не имеют.
> никто не тестирует.Всё, что нужно знать о QA/QC и качестве ядра.
Иногда фанаты свободы начинают в такие дебри логики уходить, чтобы оправдать помойку, что они нечаянно раскрывают суть движения.
> Иногда фанаты свободы начинают в такие дебри логики уходить, чтобы оправдать помойку,
> что они нечаянно раскрывают суть движения.подрыв пуканов минусующих зачотен! Продолжай.
1. Я вижу у тебя знатно горит, но в основном перед тем как накатить новое ядро у тебя в запасе есть старое + снапшот или полный бэк машины и у нормального пользователя "потеря данных из-за обновлений" не будет.
2. Даже танки ломаются и самолёты падают, прикинь есть фактор такой везде причем в роутерах годами дыры но ими же пользуются, за окна вообще молчу.
3. По поводу движения открытого кода, ты катишь бочку на разрабов и тех кто проверяет обновы и орёшь "КАЧЕСТВО УЩЕРБНОЕ ВСЕ УШЕРБНОЕ И Я ХОЧУ ПЛАТИТЬ БАБКИ И ПУСКАТЬ Слюни" прости, если грубо но со стороны это так, так вот многие юзвери да будут орать, что вот опять косяк и снова геморой , но любой прогер если будет желание может просто взять и исправит эту ошибку , а ещё, если тебе не нравится сам можешь собрать ядро, а вот тут и прелесть открытого кода что не сидишь и ждёшь, а если есть знания то и сам можешь сделать и улучшить и да linux хоть и стал более " ламповый" со всякими граф окружения и Аля MacOs, но все же требуется технические знания и навыки.
4. А если для Вас это ой какое тяжёлое бремя, есть Windows/Windows server, как говорится любой каприз за ваши деньги.
Убогий ты наш - Microsoft за 28 лет (!) существования ядра NT себе такого не позволяла, но вот в Линуксе на моей памяти это уже 5 раз, когда ядра приводят к потере данных, но у тебя понос, вместо аргументов. И я ничего такого не помню ни у IBM, ни у Sun, ни у Oracle и ни у одной серьёзной корпорации, которые поставляет проприетарные решения. Только удивительный замечательный Линукс, развиваемый силами сообщества, продолжает серьёзно гадить и проводить к потере данных.
Критических ошибок в Windows, приводящих к краху системы и потере данных, было море. Хватит тут заниматься дешевой демагогией.
> Критических ошибок в Windows, приводящих к краху системы и потере данных, было море. Хватит тут заниматься дешевой демагогией.Ссылки в студию, убогий врун.
Я так понимаю вместо ссылок и доказательств будут только минусы.Как типично для Open Source фанатов.
Даже искать не пришлось
https://www.windowslatest.com/2020/10/18/windows-10-kb457931.../
Ни слова про ошибки в ntfs.sys, ntoskrnl.exe, system crashes или data loss. Windows Updates отвалились - это уже лет 10 как, это никого не волнует.Продолжайте искать. Только для начала выучите английский.
Ахахаахха
Ваши доказательства - не доказательства. В принципе от демагога такой ход предсказуем.
https://www.ixbt.com/news/2018/10/04/svezhee-obnovlenie-wind...
Помойка ixbt.com?А есть Press Release на microsoft.com или хотя бы Knowledge Base Article на тему? А, ничего нет? Проблема поди касается 10 пользователей, которые пользовались какой-нибудь софтиной, которая и грохнула файлы?
Продолжайте искать.
Демагогию можно не уточнять термином «дешёвая». На то она и демагогия.
>Windows serverВот попробуйте ответить, каким будет Windows Server на основе Windows 11?
конченым, как и все что МС делает последние 10 лет
> снапшот или полный бэк машины и у нормального пользователя
> 95% пользователей не делают backup от слова никогда.
> танки ломаются и самолёты падают, прикинь есть фактор такой везде причем в роутерах годами дыры но ими же пользуются, за окна вообще молчу.Коммерческие ОС такого себе не позволяют, в Линуксе во все щели - но перенесём разговор на танки. За умение пользоваться logical fallacies, конкретно whataboutism, вам пять. По теме обсуждения - вам кол.
> По поводу движения открытого кода, ты катишь бочку на разрабов и тех кто проверяет обновы и орёшь
Я никого не заставлял писать "stable" на kernel.org. Орёте пока только вы.
> А если для Вас это ой какое тяжёлое бремя, есть Windows/Windows server, как говорится любой каприз за ваши деньги.
И снова logical fallacy, whataboutism.
Супер - 4 пункта, ноль аргументов.
> Коммерческие ОС такого себе не позволяютнапоминаю: в некоторой шибко коммерческой ОС RCE в подсистеме печати исправляли сколько месяцев ? и с какой попытки исправили ? то-то же.
>> Коммерческие ОС такого себе не позволяют
> напоминаю: в некоторой шибко коммерческой ОС RCE в подсистеме печати исправляли сколько
> месяцев ? и с какой попытки исправили ? то-то же.Это похе рило данные?
то-то же
> Это похе рило данные?а неизвестно.
мало кто будет позориться, рассказывая о самоходных программах в своей сети.
Всё так. А до этого была проблема с графикой Intel, которая несколько месяцев была сломана в нескольких «стабильных» версиях ядра. Вообще идея запихивать драйвера в ядро - отвратительная.
Когда интерфейсы ядра нестабильные (Stable API nonsense), по-другому не получится.Фанаты свободы жрут, давятся, но зато open source! Есть исходники!! Без них нет жизни!!!
Ну логично - пить исходники немного ненормально.
Для сравнения:
сабж: никого не затронуло, кроме экспериментаторов, легко обходится, легко фиксится, легко откатывается.
винда: чёрный экран после обновления на всем энтерпрайзе, сделать ничего нельзя кроме перестановки системы, единственная рекомендация от разработчика (которому напомню заплатили мешок денег) не обновляться (притом что до этого совет был противоположным), патч через 2 недели (не чинит уже сломанное).
Вот и решай.
А, что?Windows 10 развёрнута на сотнях миллионов компьютеров и workstations.
Расскажете у кого в enterprise были чёрные экраны массово?
Что-то я ничего не слышал ни разу.
Сказочники Open Source.
Чёрные экраны были, да, у тех убогих, которые ставят 100500 софтин, которые приводят к конфликтам ядра, например, такое запросто можно схватить, установив 2 антивируса одновременно. В Линуксе антивирусов нет по сути, так что, конечно, и проблемы нет. Линукс тупо данные х ерит, прямо сам, без ваших действий.
> Расскажете у кого в enterprise были чёрные экраны массово?я вот на прошлой неделе захожу - а там все сплошь в чорных-пречорных экранах.
В пятницу потому что нехрен в офис заходить, когда всем разрешили удаленку.
Г-н пох. - большой сказочник и врёт, не останавливаясь.
Ты гонишь, у 10 постоянно то бсоды, то удаление файлов из хомяка из-за штатных секьюрити апдейтов. И что-то на бизнес ветку тоже просачивается.
Последний раз я видел BSOD на Windows примерно так в 2002 году, и вызван он был кривыми драйверами от ATI.На Windows Vista, 7, 8, 8.1, 10 не было ни разу ни у меня, ни в моей организации с ~200 рабочими станциями, ни у моих знакомых в количестве не меньше 30 человек.
У школьников, которые страдают варезом и кряками - возможно, но это не проблема Windows, а проблема школьников, которые убивают систему в хлам.
Убивать Линукс даже не надо - разрабы сами вам помогут.
У школьников, которые обновляют систему вовремя? Ну да, ну да. Отличное решение полгодика посидеть с известными дырами, а через полгодика проблемные апдейты авось и отзовут.
> Последний раз я видел BSOD на Windowsгод назад, стабильно, воспроизводимо:
1) смена режима контроллера диска в BIOS с "IDE-совместимый" (в котором дебил-предшественник ставил винду) на "AHCI". загрузка -> BSOD.
2) попытка клонирования через Clonezilla (а что, как-то иначе надо было ? а почему linux такое переживает ?). загрузка -> BSOD.
> У школьников, которые страдают варезом и кряками
абсолютно легальная копия (с точностью до md5sum) легального дистрибутива win7sp1.
в обоих пунктах.
> абсолютно легальная копия (с точностью до md5sum) легального дистрибутива win7sp1.вот он:
3074519040 May 21 2012 SW_DVD5_Win_Pro_7w_SP1_64BIT_Russian_-2_MLF_X17-59431.ISO
1cdc2ca6f6e236abed3ce872b66e2dc9 *SW_DVD5_Win_Pro_7w_SP1_64BIT_Russian_-2_MLF_X17-59431.ISO
кто рискнет сказать что это васян-сборка ?
>> Последний раз я видел BSOD на Windows
> год назад, стабильно, воспроизводимо:
> 1) смена режима контроллера диска в BIOS с "IDE-совместимый" (в котором дебил-предшественник
> ставил винду) на "AHCI". загрузка -> BSOD.Е6aть, вы у Windows отобрали железо - ей не с чего грузиться, вам что спасибо сказать? Linux тупо скажет init не найдет и в панику.
> 2) попытка клонирования через Clonezilla (а что, как-то иначе надо было ?
> а почему linux такое переживает ?). загрузка -> BSOD.Той же оперы, причём, видимо, кривыми руками сделано.
>> У школьников, которые страдают варезом и кряками
> абсолютно легальная копия (с точностью до md5sum) легального дистрибутива win7sp1.
> в обоих пунктах.
> Linux тупо скажет init не найдет и в панику.спорим что нет ?
я могу отклонировать установленный antix linux с PATA на SATA, включить
режим AHCI если еще не включен, и будет нормальная загрузка.
и наоборот - тоже.
ядро хоть "стандартное" из дистрибутива, хоть мое самодельное.> Той же оперы, причём, видимо, кривыми руками сделано.
не "кривыми руками", а "заshita от контрафактного программного обеспечения".
вы даже этого не поняли, а в дискуссию лезете.ps: школьник что ли ? нормальный адепт MS начал бы демагогию про sysprep и RIS сервера,
а не ругался матом на то, чего не понимает.
>> Linux тупо скажет init не найдет и в панику.
> спорим что нет ?
> я могу отклонировать установленный antix linux с PATA на SATA, включитьспорим что нет - если я запущу пару команд - даже ведро менять не буду. Просто выкину лишние драйверы из initrd.
> ядро хоть "стандартное" из дистрибутива, хоть мое самодельное.
за счет какого мусора работает и как - васяну знать не надо, васян т-пой.
>> Той же оперы, причём, видимо, кривыми руками сделано.
> не "кривыми руками", а "заshita от контрафактного программного обеспечения".нет, дурачок. Именно твоими кривыми руками, не имеющими над ними головы, способной прочитать документацию прежде чем косячить. Так получилось, что радиус кривизны с твоим анитшитом совпал - он вот для таких как ты др-ров такими же др-рами и сделан, и они о себе позаботились, а разработчики винды - делали для нормальных админов, у которых перестановки на несовместимое железо не являются основной работой за деньги.
> вы даже этого не поняли, а в дискуссию лезете.
Сколько платишь за ремонт такой системы? Я тебе попутно объясню, где у нее настоящая защита, как срабатывает, и почему не имеет ничего общего с проблемой загрузки без драйверов загрузочного устройства. Ну а что она при этом и сработает - это меня не волнует, ты ж не мелкий воришка, у тебя же есть серийник с голографической этикеточки?
У васяна дешевле, но он не заинтересован тебе рассказывать правду - ему удобнее убедить тебя в сказочке про "защиту", заодно свой зверьэдишн тебе поставит.
P.S. ну т-пые...
> если я запущу пару командодна из которых sudo rm -rf /
хитрый кокой.> а разработчики винды - делали для нормальных админов
короче "умных послали к умным, а меня к тебе".
скажи еще "система обновлений сделана для нормальных админов".> загрузки без драйверов загрузочного устройства.
драйвера все нужные уже есть ! они не проходят probe. или проходят не в том порядке. или проходят, но делают BSOD в процессе. мне разбираться лень, я вижу результат, я описываю результат как я его вижу.
> радиус кривизны с твоим анитшитом совпал
я попросил бы не выражаться.
> скажи еще "система обновлений сделана для нормальных админов".в том числе. Но поскольку ты к ним не относишься - для тебя сделана другая, чтоб тебе лоб не морщить и лишнего не уметь.
> мне разбираться леньтебе и не надо. Обратись к системному администратору.
> тебе и не надо. Обратись к системному администратору.ну и что он мне предложит кроме "переустановки уиндоуз" ? с вероятностью 90% - ничего.
> > скажи еще "система обновлений сделана для нормальных админов".
> в том числе.окей. скажи еще что диагностика ошибок установки обновлений абсолютно понятна,
коды ошибок и их возможные причины разжеваны в документации, ошибки
легко исправляются станлдартными средствами. хехехе.
> 1) смена режима контроллера диска в BIOS с "IDE-совместимый" (в котором дебил-предшественник
> ставил винду) на "AHCI". загрузка -> BSOD.Не то что бы я считал Винду оплотом стабильности, но этот конкретный БСОД устраняется правкой двух ключей в реестре.
> Не то что бы я считал Винду оплотом стабильности, но этот конкретный
> БСОД устраняется правкой двух ключей в реестре.да знаю я. это "пох" меня за лоха держит, и все боится выдать
конкретную инфу ("пару команд" он введет, ага).
для висты, семерки и их серверов:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci]
"Start"=dword:00000000для 8.1 и 10 что-то другое, надо будет - узнаю.
по весне при печати с определенных принтеров и при запуске той же 1С система вываливалась в бсод из-за криво слепленного слепыми индусами из МС обновления
При печати на принтеры киосков такое было. Лечилось откатом или установкой xps драйверов.
Киосера
до краха не доходило, но блокировки периодически возникают...
В Fedora 35 вроде всё работает. Но осадок остался, ждём обновления.
у меня че то все зависает случайно, без логов просто тупо виснет , reset тыкаю после перзагрузки ничего нет в логах. Железо недавно поменял думал из за него. Надеюсь к релизу ядро пропатчат.
А у меня краха не было ещё (linux-tkg, scsi_mod.use_blk_mq=1).
$ uname -a
Linux arzeth-pc 5.14.7-202-tkg-pds #1 TKG SMP PREEMPT Wed, 22 Sep 2021 21:37:57 +0000 x86_64 GNU/Linux
$ uptime -p
up 1 day, 12 hours, 52 minutes
$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq
/, /usr/, /var/, часть /home/ пока что на HDD (sda). /usr/share на XFS (не LUKS), остальное — ext4 (LUKS) и NTFS3.Может крах только если BFQ используется на NVMe или любом SSD?
Пофиг, у меня 5.14.3, ещё не emerg'ил апдейтов, и, пожалуй, пока подожду.
Зачем нужен BFQ, используйте стандартный скедулер
> Зачем нужен BFQ, используйте стандартный скедулерПопроси свой дистр отказаться от BFQ.
А ещё скажи почему пользователи Линукс вообще должны думать об этом? Нигде ничего не подгорело? Пользователи хотят работать - им наплевать полностью на IO scheduler в ядре.
Я пользователь, ничего не подгорело, мне не плевать на шедулер, хватит за меня решать на что мне плевать, а на что нет. Я не макака, сам разберусь. В конце концов техника всегда так работала - не разбираешься в устройстве инструмента - страдаешь. Что на велосипеде, что на моцике, что на автомобиле, что с хлебопечкой, что с электрочайником и уж тем более с компьютером. На любой системе, только на пролприетарщине у тебя даже нет шанса взяться за паяльник или цепь натянуть. Если совсем не бум-бум, а срочно нужно, то найми админа который будет следить за авто за тебя, периодически менять масло и в случае аварии подрихтует крыло.
> Я не макака, сам разберусь.Так и запишем: для использования Linux на desktop нужен технический склад ума, знания в IT и владение C/ASM.
Мне казалось тут кто-то заливал про альтернативу Windows/Mac OS - не, это точно плохая шутка.
>Попроси свой дистр отказаться от BFQ.О, старый классический троллинг тупостью, никогда не устаревает!
Ни один хоть сколько-нибудь крупный дистр не использует BFQ в качестве дефолтного шедулера. Для /dev/sd* используется mq-deadline, для NVMe и вовсе никакого шедулера не используется.
> Ни один хоть сколько-нибудь крупный дистр не использует BFQ в качестве дефолтного шедулераFedora смотрит на тебя, как на идиота.
У меня в Fedora для NVMe none стоит по умолчанию.
Это который?
Везде, где я видел, стоит mq-deadline для блочных и none для NVMe.
в федоре bfq, нас зацепило, странные зависания компа на ровном месте без сообщений. Неприятно но паники нет, ядро уже в koji компилируется, сегодня-завтра во всех update-testing страны.
Не понимаю, почему пишут что в течении нескольких часов.Исходя из того кода, что прикреплен к новости проблема может проявиться через случайное время - и это время зависит от некоторых условий, время из которых просто дает условиям сойтись. Могут сразу сойтись.
Если не сложно - опишите, почему через несколько часов - мне непонятно.
Если событие может произойти, может не произойти — проще сказать, что всё останется как было.
> Если не сложно - опишите, почему через несколько часов - мне непонятно.Всё очень просто.
Но сначала, на всякий случай, ликбез теорвера. Если мы допустим, что вероятность краха на протяжении секунды неизменна, или, иными словами, любая секунда работы, может равновероятно привести к краху, то можно взять и нарисовать распределение вероятности времени, сколько система отработает. Ты получишь распределение Пуассона, если затем ты продифференцируешь и нарисуешь плотность распределения (условно говоря -- вероятность в заданный момент времени получить крах), то ты увидишь кривую, которая будет расти от нуля до какого-то значения, а потом падать. И если правильно подобрать параметры распределения пуассона, вполне можно получить ситуацию, когда, скажем, с вероятностью 90% крах произойдёт в промежуток времени от 2 до 7 часов после включения.
А теперь, собственно к сообщению о проблеме. Есть симптомы проблемы, а есть механизм проблемы, их не надо путать. Симптомы полезно знать для диагностики, и именно с симптомами исходно сталкиваются пользователи, и именно с симптомов разработчики начинают искать проблему. "Через несколько часов" -- это вполне себе описание симптома. Можно было бы описать лучше, задав матожидание времени краха и стандартное отклонение. Можно было описать ещё лучше, задав распределение вероятности. Но с этими лучшими описаниями, я подозреваю, есть проблема, что надо дополнительно провести измерения, как часто это случается, эта частота может зависеть от локальных особенностей железа или способа использования компьютера. Учесть эти нюансы в измерениях сложно, если вообще возможно, потому та точность, которую даёт описание "через несколько часов" оказывается самой удачной: она лучше всего отражает накопленные знания об этой проблеме.Когда же мы начинаем говорить о механизме, то мы можем вообще потерять вероятности, и получить детерминистическое описание проблемы. Но описание механизма не нужно пользователю -- может быть ему любопытно, но не нужно, -- пользователю нужно знать симптомы, чтобы понять, что то, что он наблюдает и есть та самая проблема. Поэтому описание симптома отдельно, описание механизма отдельно. Здесь, в данной новости, вообще механизм не описан, описан лишь симптом, источник проблемы (ссылка на регрессивное изменение) и способы лечения (патч и настройки).
Вероятность растёт с течением времени и достигает 1 за несколько часов.Учи матан.
У меня почему-то только на -zen воспроизводится. Причем упасть может и через несколько минут после старта. Менять планировщик не пробовал
Ниче.
А вы заметили, что когда выходит новость об очередной поломке винды, то виндузятники начинают во всё горло орать, что это всё "враньё" и "нету такого" и вообще "это выдумки линуксоидов", а когда выходит аналогичная новость о какой-то поломке в Linux (неважно, в дистрибутиве или ядре), то они начинают ликовать?P.S.: Я сам пользователь Windows, но за таких (особенно который Аноним 68 здесь) клоунов мне просто стыдно
После таких я ещё больше убеждаюсь что токсики это не линуксоиды, а как раз те, кто выдумал это. Вот ни разу я не замечал чтобы линуксоиды гадили под топиками о винде, зато много раз видел как фанатики винды в топиках о линуксе гадят
А почему вы думаете, что если не линуксоид, то обязательно виндузятник?
> если не линуксоид, то обязательно виндузятник?Надо, надо
Твёрдый дать ответ:
Кто ты? Человек гоpода в тумане? Кто ты?
>Кто ты? Человек гоpода в тумане? Кто ты?Цитата со стиха покойного Децла - Кто ты? АйПони вырос на читках Децла. Йо, братан! Макось говно.
Ты чо йо, там вечеринко: пепси, пейджыр, мтиви...
Писмо покойного, цитата: "Я хочу найти сама себя
Я хочу разобраться, в чем дело" (ц).
Процесс затянулся.
А вообще мы всегда говорили: слушай реп - кушай ...Павер металл, рок форева!
> Надо, надо
> Твёрдый дать ответ:децл - плагиатор ? да-да-да
слушать русский рэп ? нет-нет-нет.
> А вы заметили, что когда выходит новость об очередной поломке винды"и что эта новость делает на впопеннете?!"
И вот линуксоиды не ходят на виндовые форумы, чтобы погадить там. Зато виндузоиды очень любят на том же Опеннете погадить. Их как магнитом сюда тянет.
Покажете где и как они орут особенно на opennet.ru?Покажете хоть одну проблему в Windows NT за последние ~30 лет, которая бы приводила к порче данных?
Перепись фанатов open source, которым нечего возразить на чудовищные проблемы с качеством кода ядра и безумно слабому QA/QC, продолжается.
> Покажете где и как они орут особенно на opennet.ru?Да вот хотя бы половина этого обсуждения
> Покажете хоть одну проблему в Windows NT за последние ~30 лет, которая
> бы приводила к порче данных?1) file://C:\:$i30:$bitmap
2) \\.\globalroot\device\condrv\kernelconnectИз недавнего. Вообще ни разу не было. Угу.
Как и MFT corruption никто ну вообще ни разу не видел.> чудовищные проблемы с качеством кода ядра
Поверь на слово (ну или не верь, мы не в церкви), качество кода в любых проектах таких размеров не сильно лучше.
> безумно слабому QA/QC
В Виндах с недавних пор вообще тестеров нет. Хомяки за тестеров. Ну и инициативные хомяки с Insider Preview для самых жёстких багов.
>> Покажете где и как они орут особенно на opennet.ru?
> Да вот хотя бы половина этого обсужденияВижу только фанатов свободы.
>> Покажете хоть одну проблему в Windows NT за последние ~30 лет, которая
>> бы приводила к порче данных?
> 1) file://C:\:$i30:$bitmap
> 2) \\.\globalroot\device\condrv\kernelconnectЯ в лине могу так же сделать cat /dev/zero > /dev/sda и что? В нормальной жизни ваши примеры запускали только идиоты по случайности.
> Из недавнего. Вообще ни разу не было. Угу.
> Как и MFT corruption никто ну вообще ни разу не видел.Не было ни разу ни у кого, кого я знаю - больше 300 человек. Опять мифы и легенды.
>> чудовищные проблемы с качеством кода ядра
> Поверь на слово (ну или не верь, мы не в церкви), качество
> кода в любых проектах таких размеров не сильно лучше.У Microsoft/Google и других корпораций regression testing на 2 порядка лучше. Они репутацией дорожат, пока тут вопят, что правильное ядро только в RHEL.
>> безумно слабому QA/QC
> В Виндах с недавних пор вообще тестеров нет. Хомяки за тестеров. Ну
> и инициативные хомяки с Insider Preview для самых жёстких багов.И это неправда. Да, они сократили отдел по тестированию, но тестировщики остались в большом количестве.
> В нормальной жизни ваши примеры запускали только идиоты по случайности.это какая-то очень несчастливая случайность - "случайно" взять и открыть $i30:$bitmap.
Нет, качество разработки ms тоже безумно снизилось за последние десять лет - ну так других разработчиков больше не делают. Но такого п-ца как в шва6одных системах, когда не знаешь, куда вообще от этого потока г-на бежать на всех уровнях, все же еще не наступило.
А когда наступит (неизбежно) - линyпсь снова пробьет дно первым.
>> В нормальной жизни ваши примеры запускали только идиоты по случайности.
> это какая-то очень несчастливая случайность - "случайно" взять и открыть $i30:$bitmap.
> Нет, качество разработки ms тоже безумно снизилось за последние десять лет -
> ну так других разработчиков больше не делают. Но такого п-ца как
> в шва6одных системах, когда не знаешь, куда вообще от этого потока
> г-на бежать на всех уровнях, все же еще не наступило.
> А когда наступит (неизбежно) - линyпсь снова пробьет дно первым.<img src="file:///C:/con/con"> сто лет в обед - баги раньше были круче и веселее.
Нет, код NTFS и планировщиков IO в Windows уже вылизан до упора - баги у них в основном в GUI.
А где тут баг? Ты бы еще /dev/sda открыл и потом плакал.
> Вижу только фанатов свободы.К окулисту сходить не помешает, в таком случае (да и в принципе никогда не мешает, в общем-то)
> Я в лине могу так же сделать cat /dev/zero > /dev/sda и что?
"Это другое" (с). Просил примеры - подвезли примеры, чем ты недоволен?
> Не было ни разу ни у кого, кого я знаю - больше 300 человек. Опять мифы и легенды.
А я никого не знаю, у кого BFQ (не самый популярный планировщик, надо сказать) с новым ядром. Это означает, что такой проблемы никогда не было. Ну ок, значит, новость не существует. Всё замечательно.
> У Microsoft/Google и других корпораций regression testing на 2 порядка лучше.
Да хоть на 22, а баги как были так и есть. Везде, разные и в избытке. Фирма с репутацией тут уже стабильно через пару апдейтов работу принтеров ломает (и сейчас сетевые не работают), недавно в синяк падало на япошках, но так всё норм. Тесты там, ага.
> Они репутацией дорожат, пока тут вопят, что правильное ядро только в RHEL.
В EULA а писан такой же "as is" как и для любого софта. Никто, нигде и никому ничего не должен. Ты заплатил за продукт, продукт сделал плохо - это as is и твои проблемы.
> И это неправда. Да, они сократили отдел по тестированию, но тестировщики остались в большом количестве.
У RH и в тимах тоже тестеры есть. Но я уже понял - "Это другое"(с).
Не буду ни с чем спорить - аргументы хорошие, но такого песеца с потерей данных из коробки от обычного пользования системой в NT не было на моей памяти ни разу.Причём это уже не первый, а, наверное, 5 раз, когда в ядре Линукса подобные проблемы.
> Не буду ни с чем спорить - аргументы хорошие, но такого песеца
> с потерей данных из коробки от обычного пользования системой в NT
> не было на моей памяти ни разу.Я изредка видел, особенно у тех, кто "забыл" данные вынести на отдельный физический том. Однако же с тем, что NTFS сама по себе штука достаточно стрессоустойчивая (хоть и местами оверинжернутая и местами лютый тормоз) - это я не спорю.
Тем не менее, от глюков и багов никто не застрахован. У МС, насколько я в курсе, одна из серьёзных проблем - сильная связность компонентов внутри системы. Одно протекает в другое и хрен его знает, как и куда может ударить ошибка в одной подсистеме при определённом условии.
Вот как второй пример, казалось бы баг в драйвере виртуальной косоли ядра ConDrv (NULL pointer dereference вроде там получался), а бил он по ФС (система считала, что ФС попорчена и её срочно надо восстанавливать, транзакция там грязно завршалась или что, я уже не помню).> Причём это уже не первый, а, наверное, 5 раз, когда в ядре Линукса подобные проблемы.
Ну так тут проблема в самом понимании Линукса. Все остальные актуальные на сегодня ОС - это конкреный продукт ОДНОЙ корпорации, которая имеет ПОЛНЫЙ контроль над проектом, строит и развивает его согласно своим представленям о прекрасном, КАК ЦЕЛЬНОЕ ЗАКОНЧЕННОЕ РЕШЕНИЕ, и не стремится пускать всяких излишне активных пользователей в тайны работы всяких io-scheduler-ов (вы вообще в курсе, какой он в Win и как устроен, кто об этом кроме какого-нибудь Русиновича вообще скажет).
Linux (и ядро тоже) - контруктор, который каждый (хоть RH/Google/Canonical хоть любой левый Вася) собирает как хочет (ванильное вообще довольно редко кто юзает). Естественно, вариантов конечной системы в таком случае - достаточно большое множество (+ ещё и дистроспецифичные и прочие патчи). Каждый отвечает за свои варианты, т.е., по сути за СВОЙ конечный ЗАКОНЧЕНЫЙ продукт, который сделан на общей базе наработок.
bfq, кстати, нигде и не был включён (как и btrfs в сочетании с которой баг и выплыл), именно потому что "ну его нафиг от греха подальне, когда есть простой и понятный deadline и вообще это частный проект какого-то шизанутого Paolo Valente из Linaro", кроме Fedora, которая и так дистр для beta-тестеров.
$i30
Неправда. Виндузятники сидят себе тихо-мирно. Это линуксоиды сектанты.капта 37771, держу в курсе
> А вы заметили, что когда выходит новость об очередной поломке винды, то виндузятники начинают во всё горло орать, что это всё "враньё" и "нету такого" и вообще "это выдумки линуксоидов", а когда выходит аналогичная новость о какой-то поломке в Linux (неважно, в дистрибутиве или ядре), то они начинают ликовать?Нет, я не замечаю. Всё что я вижу -- толпы оголодавших троллей, которые по поводу любого бага начинают набрасывать лопатой. Как тебе удаётся отличать вендузоидов от линуксоидов я не знаю. Тролли, по-моему, с какой стороны не посмотри -- везде зелёные, вне зависимости от того, какой ОСью они пользуются.
три чая этому господинукапча 57888, держу в курсе
>Тролли, по-моему, с какой стороны не посмотри -- везде зелёные, вне зависимости от того, какой ОСью они пользуютсяМожет ты и прав, но на этом сайте в основном виндузятники-то и начинают ликовать, когда появится новость об обновлении Wine, Proton, Steam Deck, новость о какой-либо уязвимости или баги в Linux (включая какой-то конкретный дистрибутив). Я таких же неоднократно вижу и на 3dnews, ixbt, да в общем-то много где
ЧСХ и те и другие ничо не под линкус ни под винду не пишут, не говоря уж ессно про ядра того и другого, простые юзеры, которые тешат ЧСВ.
В треде нашествие белок-истеричек. 🤷🏻♂️
Вышел 5.14.9 _без_ фикса - это всё, что нужно знать о Линуксе.
> Вышел 5.14.9 _без_ фикса - это всё, что нужно знать о Линуксе.Фикс еще недостаточно протестирован!
К тому же еще не получил одобрения комьюнити (там colour не с той буквы в комментариях!) Неправильно подан - в ЗЕМЛЮ кланяться надо, а не в пояс же!
И вообще, пользователи бубунточки в домике...ой...докере. Им ничего не грозит.
Ты читать умеешь?Это не фикс - это _revert_. Он не может привести к багам, потому что возвращает старое оттестированное уже несколько лет поведение.
Почему 100% твоих комментариев - это facepalm.jpg или просто ложь?
>возвращает староеА зачем его убрали? Случайно?
Или "оттестированное уже несколько лет поведение" чему-то мешало?
Откуда взялся "_revert_"?
Ты почти прав. Но вот ведь незадача. Ядро 4.19 ну очень стабильно и никто не заставляет с него переезжать. 5.14 нужно далеко не всем, хотя на нем и работает в wayland ускорение декодирования видео на Intel без зависаний. Может только пользователи exFAT страдают и могут пострадать на другом планировщике. В общем отставить нытье! Когда есть рабочие варианты это глупая затея пытаться принизить Linux. Это в шинде нечем заменить сломавшийся компонент, а в линуксе как правило полно вариантов.
> а в линуксе как правило полно вариантов.и вся жизнь его фанатиков проходит в поисках костыльного набора, подпирающего "полно вариантов" в той единственной позе, в которой их удается заставить делать что нужно, а не что получилось. Каждый день нового.
"Другой планировщик", "без exfat" - ну что это за страдание, так, мелкое неудобство, они ж привыкли, "видео виснет" - зачем в wsl какое-то видео и вообще надо было выбирать другое (какое - никто не знает потому что каждый день поломано) и так далее.
В общем, отставить нытье - улыбаемся и машем.
Желательно только - с безопасного расстояния.
[i]Вышел 5.14.9 _без_ фикса - это всё, что нужно знать о Линуксе[/i] - Родина им дала патч — применяй! Применяй патч, *****! Не хочу, хочу на опеннете ныть! Что такое? Это аноним?! Это аноним?!
А о существовании патча и вообще наличии проблемы - родина им из каждого утюга сообщает?> Не хочу
Не хочу выуживать патчи к "шта6ильному" ведру из впопеннетов и прочих неведомых задниц.
Хочу чтобы стабильное просто можно было взять и пользоваться - ровно в тот момент, когда понадобилось что-то новее чем нате-на-лопате. Не, много хочу, конечно.
"Стабильное ведро - в вашем дистрибутиве!" (c) Божок-с-пальцем на подсосе у Rhbm. Откуда у тех берется стабильное ведро - вам знать необязательно. Несите денежки, за вас все пропатчат. Есть, конечно, тоже за вас будут, ну как обычно.
> [i]Вышел 5.14.9 _без_ фикса - это всё, что нужно знать о Линуксе[/i]
> - Родина им дала патч — применяй! Применяй патч, *****! Не
> хочу, хочу на опеннете ныть! Что такое? Это аноним?! Это аноним?!Пользователей, которые смогут применить его сами - единицы. Я его уже накатил и сижу на 5.14.9 через 2 часа появления его на kernel.org.
А если вы хотите пользоваться Secure Boot, то вообще почти никак (MOK ключи загонять в BIOS - это от силы 100 человек в мире делает).
Это всё, что нужно знать о Линуксе.
> MOK ключи загонять в BIOS - это от силы 100 человек в мире делаетсмеешься? Да в любом дурдоме больше койкомест.
Ну и в принципе - если ты хотишь пользоваться секурбутом и при этом собираешь себе необычные ядра - вероятно ты БУДЕШЬ добавлять свои ключи и повыкидываешь все остальные. Просто потому что можешь, а наличие чужих ключей в изрядной степени нивелирует пользу от само по себе неплохой защиты.
Ну по чесноку - в современных материнках добавлять свои ключи стало на порядок проще, есть для этого соответствующий гуй. Другой вопрос что надо это мало кому.
Эта бага с каким-то специфичным железом?
Ядро в Манджаре 5.14.7 несколько дней, проблема не проявляется, uptime c момента обновления ядра
до конца не понятно, у меня зависает, пару часов где-то ждать пока зависнет, в основном когда длинные ролики на ютубе в фаерфоксе смотрел. После перехода на с bfq на mq до сих пор "ни одного разрыва", 4 часа. Официально что тот там мутно все, откатили изменения последние но причину настоящую так и не поняли.
Придется вечно оставаться на 5.12 ) с 5.13 начали все ломать, куча до сих пор не исправленных регрессий даже с таким важным как nfs, mdraid.
А что с mdraid?
например, убили напрочь статистику для /dev/md*
люто плюсую, сам офигел когда зашел в iostatа еще я ловиле buffer overflow
но загрузился со старого ядра 5.11.x и все работает как часы ))
собираю 5.10.* с kernel.org по мере выхода, жду следующего LTS.
что я делаю не так ?
Как вообще можно выпускать такие подверсии "stable" ядра? Люди потом пойдут на Рач гнать, когда надо бы на Торвальдса (или кто там, Кроа-Хартман?). Повезло, что сижу на mq-deadline.капча 97397, держу в курсе
Brain Fuckkk Quiie
у меня bfq и 5.14.7, чяднт ?...
uname -a
Linux Shiva 5.14.7-051407-lowlatency #202109221210 SMP PREEMPT Fri Sep 24 09:27:21 EEST 2021 x86_64 x86_64 x86_64 GNU/Linux
xxx@Shiva:~$ w
22:17:44 up 6 days, 12:24, 1 user, load average: 1,29, 1,16, 1,05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
rus :0 :0 24сен21 ?xdm? 19:53m 0.00s /usr/lib/gdm3/gdm-x-session --run-script env GNOME_SHELL_SESSION_MODE=ubuntu /usr/bin/gnome-session --systemd --session=ubuntu
...
держи в курсекапча 88653, держу в курсе
> чяднтНе юзаешь btrfs? Вроде как в комплекте с ней всплыло.
btrfs ? лучше уже себе в ногу выстрелить
У меня btrfs бзается в контейнерах. Ни одного зависания не было с момента обновления на ядро 5.14.7
> У меня btrfs бзается в контейнерах. Ни одного зависания не было с момента обновления на ядро 5.14.7И scheduler там bfq? Проблема всплыла в bfq в сочетании с использованием btrfs (как-минимум пока только с ней). Читаю то, что есть в багзилле.
BFQ - "никогда такого не было и вот опять". (с)
Кац предлагал сдаться!
God, bless FreeBSD
Юниттесты не нужны, ага
В Fedora 35 уже 5.14.9. Всё хорошо. За дистрибом таки должен стоять гигантский корпораст, иначе получается поделие для баловства, а не для работы.
В нем ошибка не исправлена. Все хорошо, все хорошо...> За дистрибом таки должен стоять гигантский корпораст
а зачем нам еще одна windows только всем хуже? Одна-то уже есть.
Ты балабол. Не пиши больше комментарии.
А мне нраицца! Пусть пишет!
и в 34 и в 35 эта ошибка есть и не исправленна, система зависает намертво. вообще в федоре за релиз ломается неимоверное количество вещей, в основном редхетовских же, пихают "новинки" и не парятся, кстати там реально за это робот а не человек отвечает, просто собирает и пихает сразу вам в зад. ПС. можно конечно же сидеть на релиз назад
https://liquorix.net
человек построил - человек разрушит