Комментарии 118
Однако, каждый раз, когда я пытался разобраться в этой чертовщине, то всему находилось вполне логичное объяснение, и обычно выходило, что я сам не прав.
Затрудняюсь сказать, что именно у вас там происходит, но вероятно, вы не правы.
Ядро Linux очень стабильное и очень правильное.
Я даже скорее допущу, что баг в вашей клавиатуре и ее саму нужно чинить.
У вас есть аппаратный USB анализатор? Вот им бы посмотреть что на самом деле происходит…
Если у устройства нет данных для ответа на токен IN, то оно все равно должно ответить DATA пакетом, даже пустым. Тогда контроллер вам пришлет ACK.
Насколько я помню, должно быть так:
SETUP
->Setup
<-Data0
->Ack
IN
->In
<-Data1 (no data)
->Ack
OUT
->Out
->Data0 (no data)
<-Ack
На токен In клавиатура имеет право ответить только пакетом Data0/Data1 и ни в коем случает не Ack. Аck пошлет клавиатуре хост, если принятые им данные Data корректные по CRC
Если логика USB у устройства не верная, то чего ожидать от Линукса?
Возможно, то, что вызывает у вас такое негодование на самом деле сделано умышленно, для сохранения жизнеспособности системы при обнаружении устройства с багом в протоколе USB.
А с багованным устройством можно поступать, как захочет хост, в том числе отключать его и с этой точки зрения к Л претензий никаких нет и быть не может.
Владелец уранового лома предъявляет претензии производителям унитазов в вагонах РЖД.
Ашотакова?
- Про стандарты (POSIX, например) лучше в техподдержку Microsoft написать. Можно узнать много нового.
- Про "не страшны" — это к ОС РВ (ОС Реального Времени).
- Не стоит натягивать
сову на глобусповедение отдельно взятой подсистемы отдельно взятой реализации ОС с отдельно взятой железкой на качество самой ОС.
Ну, например, когда неудачно выбранный видеодрайвер валит ОС в BSOD, откуда оно уже никогда не возвращается. Потому что работа с графикой глубоко впаяна в ядро.
Или, например, когда неудачный веб-браузер (IE) технически невозможно выпилить из ОС даже силами самих разработчиков. Потому что он глубоко впаян в ОС.
Это — неудачная ОС, потому что сама архитектура неудачная. И изменить это невозможно.
А удачная ОС состоит из кубиков. Которые вы можете сложить так, как посчитаете нужным (если захотите). И если один кубик поломается всё здание не сложится.
Вы же кернел паник не поймали? Дисковая подсистема продолжает работать? Буквы на экране бегают?
А если что не нравится — пересоберите под себя, ради бога. Вам даже за нарушение лицензии никто не предъявит.
Монолитное ядро — это у вас кубики?
Рискну быть заминусированым, но если так рассуждать то добавления дров от мыши 2004 года в ядро в 2020 — тоже неудачная архитектура.
Кроме того, вы реально можете сконфигурировать и собрать свое ядро из нужных вам кубиков.
Для перфекционистов есть Debian+Hurd.
На другом конце — можете хоть кеды в загрузочный образ вкомпилить.
Можете вкомпилить дрова в ядро — можете загрузить как модуль — можете вообще не загружать.
У вас есть выбор.
PS. я буду читать камменты
И да — какие претензии к мышу 2004 года? Что за расизм?
Я вот сейчас пишу с машины с процессором выпуска Q1'04 (P4 3.0GHz). Мне застрелиться?
del
Исходя из адреса файлика для строчки, предположу что ещё и ядро пересобоать, но в любом случае это лучше чем ничего.
Другое дело, что возможно, можно было бы заложить вероятность такого бага в устройстве, что возможно, и сделали в МС.
Одна точка зрения — запустить устройство во чтобы то ни стало, лишь бы хоть как-то заработало. Вторая точка зрения — если есть подозрение, что в устройстве баг, то заблокировать его и не использовать от греха подальше.
Обе точки зрения имеют право на существование, но что более правильно?
Исходя из того что написано в статье, выходит что оно не отключается, а подвешивает систему, если это действительно так то это самый неудачный вариант, на мой взгляд.
Я вот думаю, что видимо они сами делают свою кастомную клавиатуру и что-то там намудрили со своей реализацией USB, а признавать свои ошибки не хотят — грешат на Линукс.
А вот вторая часть — целиком и полностью на совести Л, поскольку анализатор шины показывает, что состояния обоих клавиатур прочитаны, значит, теряется отжание клавиши в недрах ОС.
В общем беспредметный разговор…
- на конкретном примере X я обнаружил, что поведение системы Y не соответствует моим ожиданиям, а поведение системы Z меня устраивает;
- как будут вести себя эти системы на другом конкретном примере N, я даже не задумываюсь и в расчет не беру;
- то, что поведение системы Y можно изменить, приложив определенные усилия, а поведение системы Z — нельзя, тоже в расчет не беру;
- несмотря на эти мои «в расчет не беру», я считаю, что система Y —
говноплохая, а система Z —конфеткахорошая; - невзирая на пункт в правилах «не следует путать хабр с жалобной книгой», свои переживания и выводы я изложил в статье
1б. Система У ведет себя правильно, значит реализовать правильное поведение возможно.
2. Другие конкретные примеры можно не рассматривать, ошибка уже имеет место быть.
3. Поведение системы Х, может быть, удастся изменить, хотя процесс не так прост, как нам говорят, поведение системы У в данном случае в коррекции не нуждается.
4. Делаю вывод (на мой взгляд, обоснованный), что система Х в данном конкретном аспекте не столь хороша, как система У.
5. Нисколько не предполагая, что Хабр внимательно читают контайнеры системы Х, ни в коем мере не рассматриваю свой пост, как жалобу, но скорее склонен предполагать, что это предостережение тем читателям, которые считают систему Х абсолютно надежной.
Я пожалуй повторюсь — Linux очень хорош, если что-то не работает — ищите ошибку в своей программе, врядли ошибка в ОС.
если бы Вы написали не просто какой-то Linux, а например AstraLinux, то реакция Ваших оппонентов вероятно была бы другой
Разные диструбутивы Linux по разному работают с оборудованием(как стандартным так и не стандартным). Прежде чем обижать бесплатное программное обеспечение после неудачного опыта подключения к нему нестандартного оборудования(слепленного на коленке «абы як») нужно просто подумать о ком то кто может все это настроить(всего один раз). И практика показывает что после этого Linux работает много много лет без сбоев, в отличие от поделки БГ. не могу писать чаще раза в сутки, но да, я знаю где ваша ошибка.
Я никак не против Линукса, но не все так просто…
В случае с виндой это был бы тупик.
callidus77:
Помница в нашей сетке монтажники подключали абонента. Пришли, воткнули сетевуху, а у него Фря и дров нету. Почесали головы и ушли. Чел через три недели наконец-то коннектится.
Грят: «Долго ж ты искал дрова.»
Он: «Я не искал. Я их сам написал.»
Отсюда. О чём ваш пост мне непонятно. Если вы нашли проблему в ядре, так исправьте её. Что ныть?
Ха, а у меня как-то давно была ровно такая же ситуация, как в той цитате с башорга — FreeBSD и новенькая модель интеловой сетевухи.
Я, правда, всего-навсего добавил PCI ID в список поддерживаемых драйвером em, на ближайшую модель, и все заработало.
Вы, вообще то, пробовали что-либо исправлять в ядре Л, смотрели исходные коды? Я — смотрел, и с тех пор на фразу «Так исправьте ядро» смотрю с большой настороженностью.
Вы, вообще то, пробовали что-либо исправлять в ядре Л, смотрели исходные коды?Посмотрите мои публикации, и после этого задавайте вопросы. Вёл курс по модулям ядра.
Ваша статья бесполезна, вместо того, чтобы создать баг, если у вас нет опыта, желания и возможности исправить, хотя бы написали бы в рассылку. Но вы вместо этого накатали статью и начали ныть, попутно обливая грязью инструмент, которым вы не умеете пользоваться.
Тем не менее, открыть файл MAINTAINERS и написать в linux-usb@vger.kernel.org описание проблемы — не так уж и сложно. Тем более, что вы в принципе уже разобрались с проблемой.
И вообще, раз уж ваше устройство ведет себя некорректно — добавьте соответствующий quirk как писали выше. Естественно, что разработчики ядра ничего не могут знать об «особенностях» вашей конкретной железяки.
В конце концов, можно в исходниках поправить и собрать "для себя любимого" уникальное ядро без этого бага
Не царское это дело — багрепорты писать.
Тем более бесплатно (даже плюсвкарму не дадут).
Не повод, но увы, другого художника небыло, спасибо тому кто написал хоть так (даже если на з.п. от какой-то крупной компании), и спасибо вам что подробно описали проблему, даже если вы не зарепортите баг, кто-то может прочитав статью сделать это, а возможно кто-то и исправит.
так как сценарий не стандартный
На самом деле достаточно стандартный. Ниже писал, как некоторые клавиатурные производители боролись с проблемой множества нажатых клавиш на USB клавиатуре, представлясь сразу несколькими клавиатурами. Моя механика так делала, но в Linux работала отменно.
Кстати, не настолько нестандартный: когда делают самопальные педали их обычно в дескрипторе описывают как клавиатуру.
Собственно и в платном софте почти так.
Так с Шиндоус вы вообще заявите "я вам деньги заплатил, так что даже подробностей вам не скажу, но хочу, чтобы прям сейчас всё работало, как надо"?
Я правильно понимаю, что вы нашли багофичу в ядре и на основании одной багофичи делаете вывод о всей ОС?
Скажите, а если бы вы за проприетарную ОС заплатили, в ней не было бы багов?
И да, Вы таки правы, количество багов в ОС совсем не однозначно определяется ее стоимостью, но тенденция к их уменьшению по мере роста стоимости, скорее всего, должна иметь место.
Цена на ПО определяется не его качеством, а тем, сколько за него можно попросить. Многие $многомиллионные (за копию) продукты такие вырвиглазные и багованные, что только ой. Почему? Потому что компания платит деньги за фичи, а не за удобство. Компаний мало, цена гигантская, а пользователи потерпят (так как цена гигантская, потратить месяц на обучение сотрудника как тривиальную вещь в ней сделать — ерунда).
Да, вы сделали вывод о всей ОС.
Цитирую:
"Ну, вообще то, я никогда не испытывал к нему столь сильных чувств, просто начинаю лучше понимать, за что фирма, производящая Окна, берет деньги. И становится яснее, почему потребители предпочитают платить Биллу (тут, конечно, есть варианты, ну Вы поняли), вместо того, чтобы воспользоваться бесплатной («то есть даром») альтернативой."
"К вопросу о Linux (Л)"
…
Я сделал вывод о всей ОС? Не заметил.
Ну как Вам сказать...
Можно, конечно.
Проблема в излишнем обобщении поведения отдельно взятого кривого железа до "кривой ОС".
Вот прямо до тотальной кривизны прямо всей ОС.
Как может отреагировать хост под управлением вменяемой ОС в случае подключения к нему подобного неправильного устройства?
И как же прореагирует Windows? :-)
Необычайно оригинальное решение, но это (оригинальность) его единственное достоинство.
Talk is cheap. Show me the code. Если серьёзно, не хватает ссылки на отчёт об ошибке.
предложили пересобрать ядро с последними патчами, это вообще в Л сообществе универсальный ответ на любое сообщение о возможной ошибке
Серьёзно??? Я только на заре знакомства с Linux этим баловался, годах в 1999-2002. Да по работе, когда нужно дополнительные драйвера
включить или подтюнить что-то (embedded). Да, совет проверить на более новой или старой версии ядра возможен (например, для Ubuntu, но только для проверки!), но пересобирать...
в данном случае сообщение об отпускании кнопки.
Хммм… Нет там события на отпускание кнопки. Передаётся только текущее состояние нажатых клавиш. Хост, сравнивая новую и предыдущую посылку считает дельту и делает заключение, какие новые кнопки были нажаты, а какие были отпущены и уже после генерирует аналоги KeyUp/KeyRelease.
Окнах7 данный дефект не наблюдался на протяжении по меньшей мере 100 нажатий
См ссылку выше )))
И, кстати, по ходу, из-за косяка в Windows XP или около того, которые работали с HID клавиатурой только в режиме BOOT протокола, появилась проблема с максимальным количеством нажатых клавиш в 6 штук (посылка 8 байт, но, пишу по памяти, один байт на состояние клавиш типа CTRL/SHIFT/ALT, а второй — не помню). Диктовалось это тем, в таком режиме можно не заморачиваться разбором Report'ов. При том, что даже через EP0, можно посылку передать до 64 байт, если устройство определить как high-speed и ограничиться 8 байт только для low-speed режима. Да, есть ограничение на максимальный размер, но… сможете единовременно нажать ~60 клавиш?
В результате появлялись монстры, представлявшиеся как композитные устройства из нескольких HID клавиатур. Которые слали каждый свою порцию данных. Спасибо Виндосу за это.
Или просто взять драйвера. USB3 ощутимо стабильнее и производительнее работает на Linux. По крайней мере в части UVC.
Если что, утверждения не голословный, накушался много и на Винде и на Маке и на Линухе, пока делал это, это, это и это.
А вообще, тема BadUSB обширна, и Linux там не в лидерах.
Я выпад про "не знает" выпилил, вы уж извините. Нервишки :)
и про максимум 6 нажатых клавиш, это прямо прописано в стандарте, не знал, что Винда к этому причастна
Нет, вы меня не поняли. Стандарт HID регламентирет два режима работы, который распространяется на мышь и клавиатуру, это Boot и Report.
Первый режим был затеян с той целью, что бы облегчить реализацию поддержки USB клавиатур в BIOS, иными словами он позволяет игнорировать дескрипторы, которые описывают формат посылки и накладывают жёсткое ограничение на размер посылки в 8 байт, как минимально возможный для Low Speed. Формат этой посылки также чётко определён. Т.е. хост:
- может позволить себе не разбирать HID дескрипторы
- не переводить клавиатуру/мышь из Boot (по умолчанию) в Report режим
- всегда рассчитывать на посылку в 8 байт с чётко определённым форматом
Но вы ограничены при этом в 6 символах за посылку.
Report режим позволяет вам самим описать HID дескрипторами то, что будет в посылке от клавиатуры и размер оного. Хост, если перевёл устройство в Report режим (и, естественно, если устройство согласно на это), обязан следовать вашим декларациям и обрабатывать соответственно. По крайней мере я смеха ради делал посылки 60 клавиш на Linux, работало :) На SS режиме, можете вообще до 1024 байт передать, т.е. ВСЕ клавиши сразу, и ещё несколько раз постольку же сверху.
Т.е. моё утверждение выше основано на том, что реализация поддержки USB/HID клавиатур в Windows была сделана и оставалась долгое время крайне топорной, работая с клавиатурой только в режиме Boot протокола, что вызвало появление проблемы, по сути, на ровном месте. И серию мужественных решений оной. Сейчас, вроде, Windows может разобрать дескрипторы и нормально интерпретировать более 6 клавиш в посылке. Но не уверен.
Статья должна называться "К вопросу о новой бензопиле и суровых сибирских мужиках".
На минуточку — минусовали (не хейтили — именно минусовли) статью, а не автора.
Это типа "я не согласен с мнением автора в данном вопросе" (там даже и причины указать можно).
А вот самого автора (его карму) не трогали, насколько я успел заметить. Стоит, как у молодого.
Ну или почти не трогали (придурки везде есть).
То есть к автору претензий нет — есть оценка данного конкретного его высказывания. Он сказал "фэ" линуху — линухоиды сказали "фэ" его "фэ" (ограничился бы одной подсистемой USB — глядишь и прокатило).
Что не так? )
PS. а вот за камменты против мнения автора может и в карму прилететь. Инфа — 146%. Вот это уже хейтинг.
Но основная часть комментариев, в общем-то, не с этим спорит, а с тем, что автор в чересчур эмоциональной манере делает чересчур далекоидущие выводы только потому, что в этом микроскопическом случае ОС ведёт себя не так, как ему хотелось бы.
Более того — вместо того, чтобы, разобравшись в проблеме, отправить патч (а судя по статье — технических знаний у него для этого вполне достаточно) — он садится на попу ровно и начинает высказывать претензии. Очень конструктивно, что сказать…
Во второй части поста я об этом думал написать, но только когда смогу найти дефект и предложить метод его устранения. Вот тогда я смогу высказать все, что думаю по поводу исходных текстов Л, поскольку мнение это не слишком понравится большинству комментаторов.
Почему то мне кажется, что подавляющее большинство предлагающих «исправить ошибку» исходники Л не открывали, не в обиду будь сказано.
Помню делал я дллку с реализацией эвент хуков, это такой милый способ легально через винапи пристроить свой кусочек кода ко всем процессам в системе. И с кривым кодом длл система периодически уходила в бсод, хотя казалось бы длл ка эта живёт в юзерспейсе.
Мы исходим из того, что вы получаете полноценную операционную систему, сразу полностью за все заплатив.Но ведь это ложь. Что может голая винда? Да ничего почти. Скачивая сборку какого-нибудь минта/убунты вы получаете полноценную систему из коробки. С офисным пакетом, проигрывателем и тонной утилит. Ей уже можно пользоваться. А если чего-то не хватает. Ну как пример, из нового LM выпилили GIMP. Мне понадобилось ровно 50 (пятьдесят) секунд что бы его получить. ALT+F2 -> sudo apt install gimp. На винде это так не работает.
И да, заголовок никак не коррелирует с смыслом статьи. Подключая нерабочую клавиатуру которую необходимо либо поменять по гарантии либо выкинут, автор сетует на Linux. Странная логика. Очень.
let the srach begin!
Статья, кмк, откровенно плоха для хабра. Такое прокатило бы в lor/talks, но здесь было бы правильным показать кусочки исходников, приложить пару картинок с диаграммой взаимодействия, добавить ссылки на используемую спеку USB или развёрнутые цитаты из неё.
И ещё крайне желательно собрать всё это в кучу и послать баг-репорт автору подсистемы, просто потому что так устроено OSS-сообщество.
А ТС — простая истеричка, у которой руки не оттуда растут!
1. Линукс точится преимущественно для серверов. Поддержка игровых контроллеров вообще за энтузиастами.
2. Когда какой-то разработчик устройства сталкивается с проблемой, то он пишет разработчику ОС. Чем больше разработчиков или чем они значительней (багрепорт от интел будет рассмотрен в первую очередь) пишет, тем быстрее проблема решается. Как думаете, под какую ос делают больше устройств?
Итак, производители игровых контроллеров в первую очередь пишут дрова для окон. Для линукса они их не пишут, за редким исключением. Поэтому, баги системы так и остаются неисправленными.
Что вам следует сделать:
1. зайти сюда bugzilla.kernel.org и написать баги по каждому случаю, предоставив логи ядра и прочую информацию. Когда начнется переписка, то активно ее поддерживать.
2. исправить самостоятельно, отправить патч в багзиллу или в почтовую рассылку. Этот метод быстрее.
Ой, та ладно, я больше чем уверен что, подавляющему большенству не нужно сразу две клавиатуры на одном компе, мне трудно даже представить для чего такая необходимость нужна, и этот "глюк" на Linux, по сравнению со всеми багами на Windows, ни что. Компилирует винда, допустим, Python, в разы медленнее чем Linux, а о стабильности и говорить не стоит…
После установки и перезагрузки (ядро тоже обновилось) БД не запустилась. В своих логах вообще пусто, в системных — «Aborted». Это в, казалось бы, эпоху journalctl.
Легко гуглится статья в доках MariaDB: «Что делать, если эта хрень не запускается?». Подробно рассказано, как найти файлы логов. Разобрано несколько случаев. Отдельно выделена глава для пользователей systemd (лично ничего против этого тулкита не имею).
Ничего похожего на мой случай. На «СтэкОверфло» советуют сделать «apt purge mariadb*». Серьёзно. И, что противоречит логике, переустановка чего либо очень часто решает проблему. Но меня такой подход не устраивает.
Ладно, ход поиска решения понятен.
Пробую запустить без старых файлов данных (mv /var/lib/mysql /var/lib/mysql.bak) — без результата.
Печально, у меня сильно кастомный конфиг, долго придётся искать несовместимость (хотя откуда она могла взяться?).
Пробую запустить Марию вообще без кастомных конфигов (кстати, концепция conf.d/ очень удобна, спасибо) — успешно стартует. Методом исключения по методу Монте-Карло нахожу какую бы вы думали проблемную опцию?
Я ставил на нестандартный порт из непривелигированных, параметры буфера и кэша InnoDB, увеличение лимита на количество открываемых файлов (в конфигах systemd тоже было в отдельном файлике установлено нужное значение параметра, которое ещё в интеренетах настоятельно рекомендуют не ставить в значение «nolimit», т.к. в каких-то версиях systemd это воспринималось как «65 тысяч сколько-то»).
Оказалось, дело в «lc_messages = ru_RU». Ну вы поняли.
Но всё равно, виндовый сервер считаю плохой идеей. BSD? Ну, за примерно год администрирования FreeBSD всякое случалось. «Из коробки» удобно не многое.
К вопросу о Linux (Л)