Комментарии 11
читатели получают качественный и проверенный контент
Категорически несогласен. Тут приведу свой комментарий цитату из вашего недавнего поста Создаём своё первое USB-устройство:
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Кроме того, я воспринимаю Linux как слой HAL. Если на микроконтроллере можно запустить Linux, то мы сможем удобно отображать все эти устройства, нам не придётся пользоваться неуклюжими библиотеками HAL и так далее.
Вот это попробуйте перевести на нормальный человеческий язык.
Добрый день! Благодарим, что поделились своим мнением. Статистика этого перевода положительная: всего 2 минуса при 26 плюсах. Но, конечно, вы всегда можете проголосовать и дать нам знать, если недовольны качеством перевода. Нам эта статья показалась интересной, как и другим 130 пользователям, которые добавили её в закладки.
При всем к вам уважении, ваш ответ эквивалентен выражению из анекдота, "это не дерьмо, а засахарилась". То что вы пишите, это показатель вашего отношения к аудитории, и вашего профессионализма. Говорить "пипл и так схавает", не вызывает никакого уважения. Существует такое понятие как профессиональная этика. Любой нормальный специалист никогда не позволит писать подобную дичь, именно так.
Да все мы люди, и ошибки допускаем. Но писать "неуклюжими библиотеками HAL", технически безграмотно, я не поверю что у вас, как минимум в штате, нет специалистов разбирающихся в архитектуре ОС и Linux. Мое предложение следующее, прежде чем взяться за пост, определяйте его маршрут.
Маршрут №1. Пост пишет автор на тему, в которой сам разбирается и готов как минимум ответить на 80% всех вопросов по данному посту (идеальный вариант).
Маршрут №2. Человек делает предварительную выборку интересных тем для переводов. Затем эта выборка передается специалистам для краткого анализа и исключения полной хрени еще до стадии перевода, помним правило информатики GIGO (Garbage in, garbage out). Далее, перевод желательно человеком, хоть отдаленно понимающий про что идет речь в оригинальном посте. Далее, профильный специалист из результата перевода вычищает дичь в стиле "неуклюжими библиотеками HAL".
PROFIT!
Мы считаем это корректным переводом фразы «wonky HAL libraries». Если у вас есть предложения, как это перевести по-другому, можете написать нам в личные сообщения. Мы всегда рады конструктивной критике. При всём уважении к читателям, критику в стиле «нормальный человеческий язык» и «убрать дичь» мы считаем неконструктивной.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "wonky HAL libraries", потому что специалист должен выражаться максимально технически грамотно. В противном случае, пусть пишет прозу, там это пожалуйста. Что такое HAL?
Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядра операционной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. Источник wiki.
Самое простое понимание, упрощенно, HAL это драйвера, это не какая то отдельная библиотека для всех компьютеров.
Короче говоря, автор не смог написать правильно, и итоге получился проводник который бегал по проводам.
Суть следующая, автор говорит что ему сложно и неудобно работать с уровнем HAL на МК потому что, это достаточно низкий уровень управления устройства. т.е. wonky необходимо понимать в контексте СЛОЖНОСТИ ПРОГРАММИРОВАНИЯ, а не дословного перевода. Необходима высокая техническая база для написания просто элементарного кода.
Далее, следующий проводник бегающий по проводам это "Linux API гораздо надёжнее и стандартизированнее". Никакого абстрактного "стандарта Linux API" в понимание RFC не существует, есть конкретные стандарты, мало того от версии к версии ядра этот API постоянно меняется. Именно поэтому на OPi4LTS в версии ядра Linux 5.10, Wi-Fi на 5 ГГц работает, а в версии 6.X нет. Но тогда про что идет речь? Речь идет о стандарте подхода программирования используя API, это разные вещи. Если смотреть как вы перевели, то API само по себе как субъект не может быть надежным или нет, понятие надежности применимо к работающим информационным системам, но не как API.
В данном случае, автор под понятием "Linux API гораздо надёжнее и стандартизированнее", подразумевает не наличие некого стандарта так такового, а стандарта подхода программирования на примере символьных устройств, например, ваш текст "то мы сможем удобно отображать все эти устройства", как раз таки об этом и говорит. Просто читателю непонятно, где и как отображать эти устройства и вообще про что идет речь.
Программный код написания USB устройств между разными МК крайне сложно перенести. В случае использования Linux API, код можно переносить практически без изменений, потому что есть возможность использовать более высокий уровень абстракции. В своих постах я писал про nanoFramework и microFramework. В частности в microFramework я сделал конвертор USB устройства Microsoft Xbox 360 Controller Gamepad в HID-устройство клавиатура. Это было сделать не сложно, потому что использовался высокий уровень абстракции на базе платформы .NET.
Вот что я хотел до вас донести, в случае "сложных" технических постов делайте техническую экспертизу.
P.S. С литературной точки зрения, вы все равно неправильно перевели "wonky HAL libraries" дословно переводится не как "пользоваться неуклюжими библиотеками HAL", а "шаткие библиотеки HAL". Ключевое слово шаткий, запомните, английский язык это функциональный язык. Шаткий это функция, означающая перемены, изменчивость. На русский язык, так напрямую переводить нельзя, потому что получается хрень.
т.е. автор говорит что в случае использования МК эти библиотеки HAL каждый раз будут другими от перехода от одного МК к другому, этим он и говорит что для него HAL библиотеки и неудобны.
В русском язык слово шаткий, скорее всего читатель воспримет в контексте неустойчивости, что-то не прочное. Например, шаткие доводы, как говорит Толковый словарь Ожегова. Именно поэтому такое нельзя переводить дословно, и как вы перевели. А нужно писать нормальное технические разъяснение.
P.S.S это наверное тот случай, когда в комментариях более понятно, чем в посте.
Добрый день! Спасибо за разъяснение, так гораздо понятнее, что вы имели в виду. Ваш вариант перевода фразы "wonky HAL libraries" принимаем, в статье поправим.
Но хотим пояснить, что за англоязычными авторами мы статьи при переводе не переделываем. Если есть какие-то неточности, всегда можно напрямую связаться с автором и предложить ему внести корректировки. Но додумывать за него и менять исходный текст считаем неправильным.
Добрый!
Но хотим пояснить, что за англоязычными авторами мы статьи при переводе не переделываем.
А зачем вы тогда делаете перевод? Тут ребята целые книги переводят с помощью ИИ, и у них перевод получается лучше, чем у вас. Я и то не сразу понял, что перевод книг машинный.
В этом случае вы можете просто написать небольшую аннотацию на русском языке и разместить ссылку.
Но додумывать за него и менять исходный текст считаем неправильным.
Я вам скажу, почему вы не хотите писать нормальные посты, потому что это надо тяжело работать, и работать головой, читать, проверять, консультироваться, делать вычитку. А хренак, хренак и в продакшен особого ума не надо. Зато любите почесать свою ЧСВ фразами "держим марку". Я думаю, администрации Хабра предложу для таких текстов дополнительную категорию: машинный перевод без понимания текста, вот туда и пишите свои переводы. С вашей помощью Хабр пробивает очередное дно качества материала. С другой стороны, пишите свои бездумные переводы, обязательно снова всплывет бегающий проводник по проводам.
И да, в этом году мы по-прежнему не написали ни одной статьи с отрицательным рейтингом. Работая столько лет с Хабром, мы научились считывать интересы аудитории и предлагать релевантный, интересный контент.
Коллектив авторов вашего блога всегда готов поддержать статью коллеги плюсиком, поэтому даже если кто-то сообща поставит -10 вашей статье, то коллектив авторов быстро исправит ситуацию на +5. Так что тут не совсем честно говорить о том, что отсутствие статей с отрицательным рейтингом у корпоративного блога, это умение считывать интересы аудитории. Это скорее работа с авторами и теми, кто готов поставить вам плюсик, а про не 100% попадание в интересы аудитории.
Эта статья вышла 1,5 дня назад и за это время собрала всего 6 добавлений в закладки и 6 комментариев, включая 2 комментария от меня, что говорит о том, что статья оказалась не интересной аудитории Хабра, т.е. нет никакого попадания в интересы читателей.
Но при этом у статьи 37 плюсиков. Так что очевидно, что высокий рейтинг статьи не всегда связан с её популярностью у читателей.
Даже если посмотреть Самые рейтинговые статьи блога RUVDS в 2024 году, то по ним прекрасно видно, что интересные статьи всегда вызывают много комментариев и добавлений в закладки.
Так что 37 плюсиков у текущей статьи - это аномалия и работа с авторами блога, а не повышенный интерес среди читателей. :)
За подборки спасибо.
- Самые рейтинговые статьи блога RUVDS в 2024 году
- Самые комментируемые статьи блога RUVDS в 2024 году
Будет, что почитать во время новогодних праздников.
Блог RUVDS 2024: держим марку