Знаете, сколько раз я на код-ревью получал ответ (от инициатора код-ревью) в духе "ну дык этож петон! Какие дженерики??"
Ну дык, автор отправляется читать книжку, PR откладывается пока автор занимается самопросвещением.
Конечно, мне наверное просто говорить, потому что я еще и мейнтейню бОльшую часть проектов где делаю код-ревью. Так что последнее слово в основном остается за мной.
Благо дело, на текущем проекте я как раз ответственное лицо за настройку/прикуручивание всяческих линтеров. Пускай неумехи страдают :))
В обсуждаемой статье речь про МК, и про ядро Linux ни слова. В чем связь?
Цитату про ядро я взял из статьи. Можете сами проверить.
В письме пишется, если я правильно понял, про FP-сопроцессор в x86:
Потому что Линус смотрит на вещи в основном с точки зрения x86. Но это относится и к другим архитектурам, например к ARM. FPU изредка используется для SIMD инструкций (например в коде raid6), но все такие места обложены kernel_fpu_begin для x86 или kernel_neon_begin для ARM.
EDIT: В том коде, который может потенциально компилироваться под ARM нет вообще ни одной double или float переменной. Я вообще не уверен что порт ядра на ARM умеет работать с FP в ядерном контексте.
Если кратко - сохранять FP контекст при переключении в режим ядра - очень дорого. FP контекст переключается только когда переключаются поток в user land. Это происходит куда реже чем прыжки между user mode и kernel mode.
Самый простой язык - это ассемблер. Там не то что объектов, классов и наследования нет, там даже строк (ну кроме древнего x86), структур и массивов нет.
Но без понимания большей картины - Roblox бесполезен.
Как ребенку научиться понимать большую картину? Прочитать учебник "основы понимания больших картин" издательства "минобразование"? Или может пробовать, экспериментировать, учиться на ошибках и т.д.?
Пусть начинает с чего-то простого. Не обязательно знать язык на 100% чтобы делать что-то.
Начинать с простых задач. Типа "я хочу создать кубик и чтобы он крутился на месте". Потом "а теперь пусть он двигается по квадратной траектории". Дальше - больше.
И to bang, to bash - имеют общий смысл "ударять со всей силы". Так что я бы скорее предположил что семантика bit banging - это типа как ударами молотком можно заставить железяку принять любую форму, так с помощью bit banging можно заставить GPIO работать как другой протокол.
Но на самом деле пытаться понять логику хакеров 1960-х - это еще та задачка. Jargon File например ничего не говорит про этимологию этого выражения.
Потому что смысл слова bang сильно зависит от контекста. Best bang for your buck - очень выгодное предложение, gangbang - груповуха, bang it with a hammer - постучи по нему молотком. Bang-bang - звукоподражание стрельбе.
Это не просто старая фанера и кусок пенопласта. Это особая радиопрозрачная фанена и кусок пенопласта. Непонятно как в эту концепцию вписываются металлические шпильки, но это уже отдельная тема.
Ага, а еще приколы с hard core и soft core тоже явно прошли мимо вас... В общем да, переводить такие тексты сложно. Это же текст, который маскируется под технический, но при этом техническим не является.
Bit banging - An abusive programming technique that has sent millions of bits into therapy.
"therapy" тут - это психотерапия. Вы кажется пропустили всю шутку. "Bit banging", "gang banging"... не?
Bugging - The part of programming that includes specification, design and coding, but that ends before any sort of testing starts. Primarily involves seeding defects into the code. See Debugging.
Как вы умудрились перевести "bugging" как "исправление ошибок"? Это ж "внесение ошибок". Но даже так, вся игра слов с debuggin/bugging теряется. Ну и соответственно вы совершенно запороли следующую шутку:
Отладка — удаление дефектов, внесенных во время отладки.
WTF?
Вообще переводить этот текст в лоб - занятие довольно бессмысленное, потому что надо хорошо понимать не только отдельные слова, но и культурный подтекст. А ваш перевод вообще ниже уровня плинтуса, ибо вы умудряетесь путать смысл слов.
Вот поэтому я и написал про "пошла я нахер". Я ж не спорю с вашими тезисами. Просто привлекаю внимание к нарушению лицензии. Еще одна монетка в копилочку, так сказать.
А если пересобрать исходники и сделать из них дистрибутив ГринОС? Ну понятно, что поддержки никакой не будет. Но кроме этого, какие проблемы еще могут быть?
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.
Она не запрещает коммерческий софт. Но она запрещает изменять лицензию. Грубо говоря, пользователь который получил исходники, может делать с ними что угодно - в том числе и распространять бесплатно.
Второй закон термодинамики не позволяет.
Ну дык, автор отправляется читать книжку, PR откладывается пока автор занимается самопросвещением.
Конечно, мне наверное просто говорить, потому что я еще и мейнтейню бОльшую часть проектов где делаю код-ревью. Так что последнее слово в основном остается за мной.
О да, линтеры спасают жизнь.
Такое должно безжалостно зарезаться на code review. А у автора потом спрашивать все ли у него хорошо в жизни....
Так то в C тоже можно кастить все указатели в
(void*)и потом в требуемый тип, а в какой-нибудь Java - вObjectи обратно.Цитату про ядро я взял из статьи. Можете сами проверить.
Потому что Линус смотрит на вещи в основном с точки зрения x86. Но это относится и к другим архитектурам, например к ARM. FPU изредка используется для SIMD инструкций (например в коде raid6), но все такие места обложены
kernel_fpu_beginдля x86 илиkernel_neon_beginдля ARM.EDIT: В том коде, который может потенциально компилироваться под ARM нет вообще ни одной double или float переменной. Я вообще не уверен что порт ядра на ARM умеет работать с FP в ядерном контексте.
Я это пише в применении к
https://yarchive.net/comp/linux/kernel_fp.html
Если кратко - сохранять FP контекст при переключении в режим ядра - очень дорого. FP контекст переключается только когда переключаются поток в user land. Это происходит куда реже чем прыжки между user mode и kernel mode.
... поэтому там никто не будет вычислять арктангенс в double.
Самый простой язык - это ассемблер. Там не то что объектов, классов и наследования нет, там даже строк (ну кроме древнего x86), структур и массивов нет.
Знаете что с вами сделают за попытку использовать floating point в ядре? Хинт: уж точно по головке не погладят.
Да и у многих МК нет аппаратной поддержки FP.
Как ребенку научиться понимать большую картину? Прочитать учебник "основы понимания больших картин" издательства "минобразование"? Или может пробовать, экспериментировать, учиться на ошибках и т.д.?
Пусть начинает с чего-то простого. Не обязательно знать язык на 100% чтобы делать что-то.
Начинать с простых задач. Типа "я хочу создать кубик и чтобы он крутился на месте". Потом "а теперь пусть он двигается по квадратной траектории". Дальше - больше.
Второе название bit banging - это bit bashing.
И to bang, to bash - имеют общий смысл "ударять со всей силы". Так что я бы скорее предположил что семантика bit banging - это типа как ударами молотком можно заставить железяку принять любую форму, так с помощью bit banging можно заставить GPIO работать как другой протокол.
Но на самом деле пытаться понять логику хакеров 1960-х - это еще та задачка. Jargon File например ничего не говорит про этимологию этого выражения.
Потому что смысл слова bang сильно зависит от контекста. Best bang for your buck - очень выгодное предложение, gangbang - груповуха, bang it with a hammer - постучи по нему молотком. Bang-bang - звукоподражание стрельбе.
Это не просто старая фанера и кусок пенопласта. Это особая радиопрозрачная фанена и кусок пенопласта. Непонятно как в эту концепцию вписываются металлические шпильки, но это уже отдельная тема.
Ага, а еще приколы с hard core и soft core тоже явно прошли мимо вас... В общем да, переводить такие тексты сложно. Это же текст, который маскируется под технический, но при этом техническим не является.
"therapy" тут - это психотерапия. Вы кажется пропустили всю шутку. "Bit banging", "gang banging"... не?
Как вы умудрились перевести "bugging" как "исправление ошибок"? Это ж "внесение ошибок". Но даже так, вся игра слов с debuggin/bugging теряется. Ну и соответственно вы совершенно запороли следующую шутку:
WTF?
Вообще переводить этот текст в лоб - занятие довольно бессмысленное, потому что надо хорошо понимать не только отдельные слова, но и культурный подтекст. А ваш перевод вообще ниже уровня плинтуса, ибо вы умудряетесь путать смысл слов.
Вот поэтому я и написал про "пошла я нахер". Я ж не спорю с вашими тезисами. Просто привлекаю внимание к нарушению лицензии. Еще одна монетка в копилочку, так сказать.
А если пересобрать исходники и сделать из них дистрибутив ГринОС? Ну понятно, что поддержки никакой не будет. Но кроме этого, какие проблемы еще могут быть?
Она не запрещает коммерческий софт. Но она запрещает изменять лицензию. Грубо говоря, пользователь который получил исходники, может делать с ними что угодно - в том числе и распространять бесплатно.