Вопрос опытным пользователям этих ваших линуксов

Представьте себе, что коллега, не очень разбирающийся в этих ваших линуксах, спрашивает, какой текстовый редактор использовать в консоли. Что вы посоветуете? vim? emacs? F4 из Midnight Commander? GNU nano? ed? cat > file.txt?

И второй вопрос — как вы отнесетесь к совету «используй ed, он по стандарту есть во всех юниксообразных системах»?

Учимся программировать под ноотропами

Хотя если вам нужна дополнительная стимуляция для того, чтобы осилить детскую книжку Петцольда — может, не надо?

Вышка нинужна

Вот еще один маленький спойлер к планируемой матерной простыни про образование — довольно узкоспециальное, но занятное наблюдение за юными программистами (жизнь свела меня с выпускниками бакалавриата одного в прошлом считавшегося неплохим ВУЗа). «Высшее айтишное» образование у нас, как выясняется, предполагает довольно мало программирования — допустим, курс по «операционным системам» читается в режиме «сухого плавания». Я интереса ради прикинул, сколько строк кода нужно написать, чтобы получить диплом по специальности 09.03.01 «Информатика и вычислительная техника» — получилось даже меньше, чем, скажем, на мехмате (который вовсе не программистов готовит!).

В результате свежий выпускник во многих узкоспециальных вопросах не то что «плавает» — барахтается и тонет. Скажем, представление о многозадачности/многопоточности у многих попросту отсутствует, и выпускник не готов толком ни к работе в «народном хозяйстве» («напиши программку с графическим интерфейсом, выполняющую какие-то расчеты, только чтобы этот интерфейс не тормозил»), ни к продолжению образования и какой-то «научной» деятельности («полистай CSP Book и распиши, используя формальную запись оттуда, как взаимодействуют потоки в этой программе»).

Но студенты же сами не дураки — они прекрасно умеют пользоваться поиском по headhunter и понимают, что с одними только плохими знаниями C и прекрасными навыками тыкания мышкой в LabView их никуда толком не возьмут! На помощь приходит среднеспециальное программистское образование в виде всяких курсов типа «Java с блекджеком и шлюхами», «Петухон за три дня», «Готовим фронтендеров из домохозяек» (и нет, речь идет не о компиляторном фронтенде). В результате весь жизненный опыт начинающего программиста просто кричит о бесполезности высшего образования — и не могу с ними в этом не согласиться, такое образование действительно довольно бессмысленно.

Еще один сложный момент — выпускники экспресс-курсов в интернетах крайне плохо знают «классику Computer science» — и всякие там «проблемы обедающих философов» им вообще незнакомы, а разговор, скажем, об особенностях реализации сортировок вообще выносит мозг (да, вузовскую программу «оптимизировали» настолько, что курсу по алгоритмам и структурам данных места не нашлось). В результате — первокурсник магистратуры в плане знаний по предмету равен примерно второкурснику нормального (идеального?) вуза, на наличие каких-то специальных знаний расчитывать не приходится. Зато о той же многопоточности они могут рассуждать в терминах питоновско-джаваскриптовского async/await — и пожалуй, придется в дальнейшем учитывать такого рода особенности нынешнего айтишного «образования».

Собственно, выше описан практически портрет начинающего комментатора хабра, пришедшего высраться на тему «вышка нинужна». Когда спорите с таким — не забывайте, образования у него на самом деле — три класса и коридор.

А вот это прямо огонь

https://habr.com/ru/company/gaijin/blog/533380/

Чуваки скомпилировали под «Эльбрус» вполне себе современные игрушки и они на этом эльбрусе довольно-таки нормально работали.

А вот про американское законодательство немножко

В твиттерном треде мужик рассказывает, что при разводе супруга программиста или супруг программистки (да, давайте использовать феминитивы, это смешно) может потребовать ПАЛАВИНУ от написанного в браке опенсорсного кода:

https://twitter.com/richgel999/status/1335957390869532682

Вот к чему приводит наивное представление об «интеллектуальной собственности«!

И как художник художникам

Хочу поделиться маленькой, но приятной находкой из книжки Питера ван дер Линдена Expert C Programming: Deep C Secrets. Вот такой набор макросов позволяет буквально «рисовать» черно-белые картинки прямо в коде:

#define X )*2+1
#define _ )*2
#define s ((((((((0 /* For building glyphs 8 bits wide */

Например, вот так выглядит символ 8*8 для какого-нибудь знакогенератора:

const uint8_t letter[] = {
/* 0xB8 */
s _ X _ X _ _ _ _,
s _ _ _ _ _ _ _ _,
s _ X X X _ _ _ _,
s X _ _ _ X _ _ _,
s X X X X X _ _ _,
s X _ _ _ _ _ _ _,
s _ X X X _ _ _ _,
s _ _ _ _ _ _ _ _,
};

Про сети и симуляторы

Интересует меня, кстати, один вопрос — довольно узкоспециальный, но надо записать, чтобы не забыть. Вот есть такой довольно популярный среди исследователей сетевой симулятор NS-3 — в котором есть реализации TCP/IP стека, MAC и PHY уровня Ethernet, WiFi и вообще черта лысого. Есть, опять же, ставшее в последнее время популярным направление исследований — сети на основе LoRaWAN. Исследования там самые разные — от прикидок уровня «карандашом на бумажке» до изучения работы сети с использованием симуляционной модели — в том самом NS-3:

https://github.com/signetlabdei/lorawan

Так вот, для построения этой модели нужно, фактически, реализовать довольно нетривиальный «сетевой сервер» — и это в LoRaWAN, полное описание которого — где-то 70 страниц текста. И вот возникает вопрос — не офигевал ли кто-то от того, что нужно дважды проделать одну и ту же работу, сначала сделав ее в симуляторе (с его довольно оригинальной моделью программирования), а потом повторив это в «железе» — точнее, в прошивке устройства. Прямо вот интересно, можно ли сделать какой-то промежуточный слой между какой-нибудь встраиваемой операционкой и моделями сетевых устройств из NS-3, например, или наоборот — впилить в NS-3 полноценную реализацию сетевого стека откуда-то еще (применительно к LoRaWAN можно было бы взять хотя бы «официальный» LoRaMAC-Node).

Делайте ставки, господа

Продолжаю тут развлекаться с LoRaWAN, и нашел просто невъебеннейшую ошибку в RIOT — точнее, в промежуточном слое между операционкой и «эталонной» LoRaMAC-Node. Ошибка там пряталась довольно давно, но то ли никто не обращал внимания, то ли списывали на «редкие разовые глюки» — в конце концов, возникала она только при довольно активном обмене в сети (хотя в принципе возможна и «на столе»).

Дело в том, что в одной из функций этого промежуточного слоя никто не обратил внимания на то, что драйвер трансивера SX1276/77/78 иногда может вернуть при вызове recv() отрицательное значение, сигнализирующее об ошибке — и радостно записывали то, что он возвращает, в переменную типа size_t — а дальше при попытке прочитать почти 4 гигабайта все радостно валилось с затиранием немалой части памяти и невнятным сообщением об ошибке.

Видимо, по «закону парных случаев» кто-то увидел такое поведение два месяца назад — но все эти два месяца разработчики «линукса для интернета вещей» мяли сиськи:

https://github.com/RIOT-OS/RIOT/issues/14962

Я, в отличие от них, был прямо заинтересован в исправлении ошибки — и сделал это, поправив буквально пару строк кода:

https://github.com/RIOT-OS/RIOT/pull/15355

Ошибка, тем временем, довольно критичная — она может полностью вывести из строя любое устройство, использующее встроенную в RIOT реализацию LoRaWAN. Вдвойне критично то, что альтернативного варианта стека LoRaWAN в RIOT не было примерно до конца прошлого года — и то назвать его полностью пригодным к работе сложно, скажем, полноценной поддержки «региональных параметров» там в официальной версии пока не просматривается. В сухом итоге — негодяю-хакеру достаточно просто послать вашему устройству в нужный момент специально сформированный пакет (подозреваю, что соорудить его можно практически штатными средствами), чтобы оно выпало в HardFault.

С другой стороны, зная отношение авторов RIOT к присылаемым им багфиксам — вангую те же два месяца жевания соплей до каких-то осмысленных телодвижений в отношении моего pull-request. Впрочем, я со своей стороны все необходимое сделал, и даже поправил строчечку, чтобы не ругалась их система Continuous Integration. Буду дальше следить за происходящим.

А вы как думаете — примут или замнут? И не стоит ли закинуть в окрестностях FU Berlin и HAW Hamburg пару девайсиков, срущих в эфир пакетами с битой CRC?

Кризис к нам приходит

Кстати, очень удивляло в марте-апреле кукареканье айтишников всех мастей о том, что их профессия выживет в разгар коронакризиса и они единственные смогут работать на удаленочке, рефлексируя на диване со Светой и Леной. Сейчас оно сменилось соловьиным пением о величайшей сложности решаемых задач («добавить на морду сайта еще одну кнопку»):

https://habr.com/ru/company/avito/blog/525384/

А тем временем рыночек порешал и первыми на мороз пойдут… кто бы вы думали?

https://www.kommersant.ru/doc/4539560

Дальше будет еще хуже.

Мир опенсорса интересен и разнообразен

Можете себе представить, что проверка криптографической контрольной суммы в серьезном проекте написана буквально «на коленке» непонятно кем, неизвестно как работает и снабжена комментариями на странном языке (испанский?):

https://github.com/Lora-net/LoRaMac-node/blob/v4.4.1/src/system/crypto/cmac.c

Теперь можете.

xkcd-dependency

В этой картинке с xkcd все как всегда серьезно.

ООП нужно запретить

Нет, я не про Организацию Освобождения Палестины, я про объектно-ориентированное программирование, которое наносит смертельный ущерб неокрепшим мозгам:

Ну как-то, прочитав книгу Гради Буча, в которой он описывает ООП на аналогии с объектами реального мира, я теперь наоборот, рассматриваю реальный мир по аналогии с ООП.

https://habr.com/ru/post/524718/#comment_22221036

А Гради Буча и его книги следует предать аутодафе по всем правилам испанской инквизиции. Но разумеется, не просто так, а после положенного богословского диспута о Святой Троице, с рисованием UML-диаграмм.

Про время

В январе 2038 года «закончится» 32-битный Unix time, а в ноябре того же года нас ожидает очередной GPS week rollover. Какое событие окажется более, так сказать, разрушительным?

Ну и да, job security нынешнему поколению айтишников обеспечена. Программисты-эмбеддеры вообще должны скинуться и поставить памятник разработчикам GPS, заложившим в систему счетчик, переполняющийся раз в 1024 недели.

Нам не всем пиздец

Вот [info]mbr посмотрел ролик про то, как нейросетка пишет код на питоне лучше выпускника трехмесячных экспресс-курсов, и предрекает всем программистам погибель и замену нейросеточками.

На самом деле, конечно же, нет. Во-первых — каких-то принципиальных отличий от классического процесса программирования я не увидел. В ролике показан просто еще один язык программирования, похожий на естественный, не имеющий формальной спецификации и транслирующийся в Python. Собственно, идея программирования на естественном или похожем на естественный язык не нова, всякие там SQL-и с этого и начинались, схожие чувства меня иногда посещали при чтении SICP — некоторые несложные примеры оттуда выглядели почти как связный текст на английском. С другой стороны, «индустрия» с 80-х не сделала ни одного серьезного шага в этом направлении.

Во-вторых — автоматизируется просто механическая работа по набиванию кода, а ведь кроме этого, в этой вашей айтишечке есть много других задач — от трансляции хотелок заказчика в пункты ТЗ до проверки готового «продукта» на соответствие этим хотелкам, и здесь как раз всегда будет важна «человеческая» составляющая (да, можно автоматизировать тестирование на соответствие формальным спецификациям — но окончательное решение все равно будет принимать человек). Вот умеющим только выполнять простые действия типа «взял тикет — накодил — отдал на код-ревью» выпускникам ускоренных курсов можно будет только посочувствовать.

А вообще — все это немного напоминает переход к CAD-ам в проектировании микросхем. Вплоть до начала-середины 80-х это был процесс с массой ручной работы, топология рисовалась практически вручную, вручную же и проверялась — вот в этом видео Боб Супник, занимавшийся проектированием микропроцессоров в DEC, вспоминает о том, как это было организовано (на 1:28:16):

So in, sort of, the last summer that I was there, we had an army of summer students and volunteers crawl over our paper schematics, and we hand transcribed them into a netlist. And then, we used the netlist for layout verification, and it worked. It worked. Because in comparison, T11 had done its layout verification the old fashioned way, which is to print out these monster plots. And then, we all crawled all over it with colored pencils and rulers, measuring things and seeing that they went from point «A» to point «B» correctly. It took us 3 months with 12 people to verify 12,000 transistors.

https://www.computerhistory.org/collections/catalog/102738263

Примерно о том же пишет Юрий Отрохов (один из разработчиков микропроцессорного комплекта 1801/1806/1836 серии, советского одночипового PDP-11) в теме о советских микропроцессорах на ixbt-шном форуме:

Да, как помнится, была такая система с названием Кулон в которой девочки-топологини на компьютерах послойно рисовали топологию на основе заданной электрической схемы прошедшей моделирование в АСКТ. По программе ПАСС моделировали только критические по быстродействию узлы схемы даже с учётом получающихся при рисовании параметров топологии. Потом эта топология, совмещённая по слоям, разными цветами прорисовыалась на листах майларовой плёнки, которые склеивались для проверки глазками соответствия топологии электрической схеме. Т.е. ни какого автоматизированного синтеза топологии по схеме, ни автоматизированной верификации топологии на соответствие схеме тогда ещё не было.

https://forum.ixbt.com/topic.cgi?id=64:3394:1596#1596

Что же случилось ближе к началу 90-х? Мощность компьютеров позволила делать и автоматический синтез топологии, и проверку ее на соответствие схеме. По воспоминаниям Отрохова из той же темы на форуме, в начале 2000-х из попытки перевести 1806 на более современный техпроцесс, «родилась» 1836 серия — уже полностью автоматически синтезированная по схемам от 1806, безо всякого ручного труда и рисования топологии на полу.

Вопрос: что же случилось с профессией тополога? Она умерла, замененная всякими CAD-ами (хотя до сих пор умные люди оптимизируют, скажем, алгоритмы раскладки элементов в ПЛИС, пытаясь добиться еще лучшего результата — только работают они в конторах, которые делают эти самые CAD-ы). А разработка микросхем в целом? Вовсе нет, сейчас она стала проще в разы и доступна, скажем, студентам профильных ВУЗов (через программы вроде Europractice) или совсем небольшим fabless-компаниям.

А если вы боитесь, что вас заменят CAD-ом — у меня для вас, действительно, плохие новости!

Егор Бугаенко, Elegant Objects/Элегантные объекты

Полистал книжку, где рассказывается, что ООП в том его изводе, которому учат немецких студентов — страшное зло, все надо делать совсем не так. Изложенные идеи красивые, правильные и даже, можно сказать, элегантные в математическом смысле — и это, конечно, мне очень понравилось. Потом взглянул на код реального проекта и загрустил.

Не читайте, если не хотите погрузиться в глубокую депрессию.

PS Впрочем, есть одно средство от депрессии — идите в embedded, пишите на голом Си, это весело и даже может сопровождаться красочными спецэффектами.

Enterprise Quality Coding

Пару месяцев назад, обсуждая некий программный продукт с партнерами (это такой полу-опенсорс, чуваки допиливают его, мы используем и тоже допиливаем) упомянул, что хорошо было бы разделить один их god object на части, и вынести часть функциональности вообще на другие уровни. Партнеры закивали головами — «да-да, мы и сами это хотим!», а на днях выкатили новую версию — где действительно распилили этот god object, но попутно сделали еще несколько штук более мелких со странными зависимостями друг от друга.

Короче, FizzBuzz Enterprise Edition — это не шутка, а жестокая реальность.

Надо бы тоже поворчать

Вот есть такая операционная система для микроконтроллеров всяких под названием RIOT, «дружелюбная операционная система для Интернета Вещей»:

https://www.riot-os.org/

И вроде бы она достаточно хороша, поддерживает хуеву тучу микроконтроллеров, отладочных плат, внешних датчиков и кучку сетевых устройств. И вроде бы все красиво и хорошо, проект развивается, в каждом каталоге последние коммиты имеют давность в два-три месяца и кажется, что все прекрасно.

Но вот попался мне в руки какой-то датчик температуры и влажности из серии DHT (популярной среди ардуинщиков) — и нет бы сказать человеку «брось каку»! Нет, я как дурак взялся помочь запустить этот датчик в RIOT-е. Как можно понять из истории этого всего, драйвер писали три немецких программиста:

https://github.com/RIOT-OS/RIOT/commits/master/drivers/dht

С момента, когда код драйвера попал в эту помойку каталог с драйверами внешних устройств RIOT-а, и вплоть до самого недавнего времени, драйвер был абсолютно непригоден для какого-либо нормального использования. Я не шучу — с 29 мая 2015 года вплоть до 19 июля 2019 в коде драйвера присутствовал бесконечный цикл, в который мы попадали, если датчик решал заглючить или отвалиться. Ну вы представляете себе «умную теплицу» в исполнении типичного ардуинщика? Китайские датчики с алиэкспресса, гнилые провода, повышенная температура и влажность, …

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

Ну и скажите теперь, можно ли пользоваться системой, в которой четыре года (!) живет вот такой драйвер, которым попросту нельзя пользоваться (вопрос о том, можно ли пользоваться купленными на алиэкспрессе датчиками, отложим на потом)?

Большой айтишный пузырь

Вот почитал тут про фронтендера, который за 280 тысяч в месяц рефлексировал со Светой и Леной на диване — а там рядышком есть аналогичная статья про программиста-эмбеддера из Иваново, который за впятеро меньшие деньги вынужден обходиться без Светы, и даже с диваном некоторая напряженка:

https://journal.tinkoff.ru/electronic-engineer/

Так вот, у наивных людей иногда возникает вопрос — откуда и почему такая несправедливость, почему долбоеб-фронтендер рефлексирует на диване со Светой и получает за это 300кк/сек, а эмбеддер, которому и знать надо больше, и ответственность выше на порядок, перебивается с хлеба на воду? Ответ прост и понятен — если попытаться разобраться, «откуда берутся деньги».

В программировании для встраиваемых систем, в принципе, все просто и понятно — вот есть «железка», она продается за N рублей (где N примерно определяется тупо из стоимости деталей), есть примерный ее тираж — из этого определяется сумма, которую в принципе можно потратить на ее разработку. И нет, это не только зарплата инженеров и программистов — это и прототипирование, и недешевое оборудование, и еще куча других статей расходов. В результате получается, что «стоимость» эмбеддера ограничена сверху — и с учетом общей унылости российской электроники, ограничена довольно скромной суммой.

Что же касается веба, оперденей и прочего «дорогостоящего» айти — тут ситуация в корне другая! Во-первых, уже программист уровня «не ссыт под себя», в принципе, способен работать на иностранных заказчиков на всякого рода фриланс-биржах — так что зарплатные ожидания сравниваются с почасовым рейтом «там». Во-вторых, даже джуниора в обоссаннных штанишках можно «продать» через бодишоп тем же иностранцам, за доллары, естественно (и зарплата тоже очевидным образом привязывается к доллару; даже с учетом прибыли «галеры» обычному гребцу хватает). В третьих — есть довольно много заказчиков, в принципе не считающих затраты «на айти», или не сравнивающих их с чем-то простым и очевидным. Вот взять тот же несчастный фронтенд — как посчитать «вклад» конкретного разработчика в поддержание работоспособности фирменного сайта? Я уж не говорю про этакий айтишный шантаж уровня «Да вы что, не знаете, что в однобортном сейчас уже никто не воюет?» — а ведь так примерно и выглядит со стороны постоянное желание переходить на новые фреймворки и все такое прочее.

Говоря проще — не связанное с производством чего-то материального «айти» всеми способами стремится «набить себе цену» — и пока что это у программистов неплохо получается, надо сказать. Хотя первые звоночки, вроде нашумевшей статьи про LinguaLeo, уже пошли!

PS «Надеюсь, вы уже поняли, какую ошибку совершили, выбрав программирование микроконтроллеров в качестве своей основной специальности»

Однажды я смотрел фильм, который начинался так же

Света знакомится с Леной, которая и пригласила нас к себе в гости. Мы будем жить с ней втроем. Лежу на диване.

https://journal.tinkoff.ru/diary-frontender-moscow/

Дальше тема Светы, Лены и дивана не раскрыта. Одно слово — фронтендер:

Света приобняла меня, и мы немного порефлексировали о моей обиде на то, что пользователи ведут себя не так, как я задумываю, — это я был расстроен по результатам UX-исследования пользовательского поведения по работе.

Бесит, сука

Очередные талантливые программисты не осилили пересчет из int16 во что-то более им подходящее. В следующий раз сделаю вывод данных в формате binary coded decimal, а то достали.

Хотя нет — напишут что-то вроде Float(x.toString(16)) и будут считать себя неибаццо гениями. Подскажите, в каком формате выводить числа, чтобы на той стороне с гарантией охуели?

Программисты не нужны

Наблюдал сегодня подгорание жепп всевозможных «бекендеров», прочитавших вот эту статеечку на хабре:

https://habr.com/ru/company/lingualeo/blog/515530/

Краткий пересказ: в LinguaLeo взяли Chief Technical Officer-ом некоего чувака, хорошо знавшего PostgreSQL — даже слишком хорошо, настолько, что он переписал на хранимые процедуры существенную часть бекенда. Результаты, например, по одной из задач говорят сами за себя:

Было Стало
Строк кода 10 000 300
Запросов к БД 12 1
Время выполнения, мс 600 20

Попутно были выставлены на мороз все веб-макаки, поддерживавшие то поделие:

Когда мы поделились планами с разработчиками, стало понятно, что команда не готова к изменениям. Большинство людей покинули компанию: остались только те, кто пришёл совсем недавно.

Читатели почуяли, что их ценный навык переписывания JSON-ов на PHP стремительно теряет ценность и начали кидаться на автора, мол, ни черта он не понимает в разработке уеб-приложений. Обязательно зайдите в комменты, там феерично.