Здравствуйте,

Меня зовут Александр Певзнер, и я программирую на Си и Go. Go обычно ассоциируется с бакендом, микросервисами и вот этим вот всем. Но я использую его необычным образом: я пишу на нём системное ПО.

Почему я это делаю именно на Go? Этот язык привлекает меня своей простотой, лаконичностью, ясной семантикой, прекрасной документацией и великолепной стандартной библиотекой.

Одна из моих программ, ipp-usb, написанная на Go, входит во все дистрибутивы Linux и *BSD и делает возможным использование принтеров и сканеров, которые подключаются к USB и поддерживают IPP over USB протокол - т.е., примерно всех современных.

А еще я член OpenPrinting - небольшой, но очень плодотворной группы людей, которая ответственна за печать и, отчасти, сканирование на всех UNIX-like OS и за формирование индустриальных стандартов в этой области.

Это всё начиналось для меня, как хобби, но сейчас это - часть моей оплачиваемой работы.

В силу особенностей моей работы меня не очень интересуют такие вещи, как поддержка миллиона запросов в секунду и прочий high load (это не значит, что мои программы тормозные. Но никто не дёргает системный принтер миллион раз в секунду). Но зато приходится разбираться с некоторыми другими непростыми штуками.

Об одной из таких штук и пойдёт речь в этой статье.

Понадобился мне для одного проекта на Go встроенный скриптинг. Ну т.е., чтобы программа могла всосать в себя скрипт, который определяет некоторые аспекты её поведения.

Размышляя о том, на каком языке программа должна скриптоваться, в выбирал между JS, Lua и Python.

Однако, JS и Lua - слишком нишевые языки. JS ассоциируется у всех с вебом а Lua - с разработкой игр. Таким образом, выбор естественным образом пал на Python. Этот язык знают все, а я испытываю некоторую надежду, что скрипты для моей программы буду писать не только я. Хотя сам я, должен признаться, Python не знаю и не люблю :)

Таким образом, осталось только придумать, как встроить интерпретатор Python-а в программу на Go.

Эта заметка будет очень короткой. Но надеюсь, она кому-то спасёт несколько часов жизни.

У меня был код. К счастью, это было в тесте, а не в боевом коде, поэтому никто не пострадал.

Код создавал http.Server, запускал две гороутинки для обслуживания входящих соединений:

go func() {srvr.Serve(p)}()

go func() {srvr.ServeTLS(e, "", "")}()

Ну и дальше создавал клиента, делал к серверу обращения (HTTP GET) попеременно используя http и https ну и чего-то там проверял.

Всё прекрасно работало. До обновления с go1.23.8 до go1.24.2, пришедшего с 42-й Федорой.

А потом перестало. Стало время от времени (но отнюдь не всегда) вываливать разнообразные ошибки. Например, вот такие: Get "https://127.0.0.1:46167/": unexpected EOF. Или такие: Get "https://127.0.0.1:34757/": write tcp 127.0.0.1:54770->127.0.0.1:34757: write: connection reset by peer. Или даже вот такие, совсем загадочные: Get "https://127.0.0.1:42447/": http2: client conn could not be establish. HTTP/2 там, разумеется никто не включал и не собирался. А иногда всё работало и тест проходил правильно.

Самое поганое, что ошибка была плавающей.

В общем, не буду грузить подробностями, как я эту ошибку ловил. Но итог такой. Хотя это нигде и не документировано, но одновременно использовать http.Server.Serve и http.Server.ServeTLS на одном и том же экземпляре сервера нельзя. Тот из них, кто успеет прокрутиться первым, чего-то там инициализирует внутри сервера, прежде, чем уйти в accept loop, и второй после этого ломается. Ломается всегда ServeTLS, не-TLS-овскому Serve вроде как пофигу.

Так что будьте осторожны, и надеюсь, что эта заметка сохранила вам несколько часов жизни :)

Зачем программисту алгоритмы?

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

Однако сами программисты нередко удивляются, зачем всё это? Действительно, работа наших коллег часто заключается в поиске и устранении ошибок в залежах legacy кода. Какие уж там алгоритмы? Даже те, кому посчастливилось участвовать в новом проекте знают, что зачастую новый проект состоит на 80% из чужого, уже кем-то написанного и найденного на просторах гитхаба кода, а новый код - это, по сути, клей и обёртки, которые позволяют склеить эти уже готовые запчасти между собой, чтобы получить заданный продукт.

Сегодня я прочитал на Хабре статью о подготовке к алгоритмическому собеседованию в Яндексе. Видно, что ребята относятся к делу всерьёз. Однако на вопрос, зачем всё таки это нужно, статья отвечает в том духе, что алгоритмическая подготовка показывает полезную готовность кандидата поотжиматься (отмечу при этом, что это не мнение Яндекса, а личное мнение человека, получившего этот опыт с обеих сторон - и кандидата и интервьювера).

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

Multicast DNS и DNS-SD являются ключевой составной частью стека Zero-configuration networking (zeroconf) и отвечают в нем за службу имен и автоматический поиск устройств в пределах локальной сети.

Технология zeroconf, позволяющая собрать работающую локальную сеть с нулевыми усилиями по администрированию и конфигурации, известна уже давно. Еще в 1980-х AppleTalk, локальная сеть для компьютеров и устройств Apple, позволяла просто соединить устройства проводами и сразу начать работать.

AppleTalk не выдержал конкуренцию с TCP/IP в эпоху Интернета, но идея сети, которая работает сама, не умерла. В мире TCP/IP Apple продвигает ее под именем Bonjour (ранее Rendezvous).

mDNS/DNS-SD являются одними из ключевых технологий в устройстве современного стека печати и сканирования. Кроме того, они могут использоваться в "облаке", позволяя отдельным компонентам облачного сервиса найти друг друга при условии, что они подключены к одной локальной сети, реальной или виртуальной.

В этой статье я расскажу, как вся эта конструкция устроена под капотом. Эта информация может быть полезна системным и сетевым программистам, которым приходится работать с соответствующими API, администраторам сетей да и просто для лучшего понимания того, как устроены современные сети.

Всем нам нравится писать в строке бровсера https://habr.com/. Никому не
захотелось бы писать там https://178.248.237.68/. К тому же, IP-адрес может
измениться, если Хабр решит перейти на другой хостинг.

Служба Интернета, которая превращает удобные всем имена в IP-адреса,
называется DNS, Domain Name System, "система доменных имен".

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

Эта статья не является введением в DNS для начинающих. Скорее, моя
предполагаемая аудитория - это ИТ-профессионалы разной специализации,
которые хотят получше разобраться в анатомии сети Интернет.

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

Я - автор двух пакетов, входящих более-менее во все дистрибутивы Linux: sane-airscan и ipp-usb.

Кроме того, sane-airscan входит во все основные дистрибутивы BSD (FreeBSD, NetBSD и OpenBSD) и в ChromeOS. ipp-usb в ChromeOS не взяли потому, что он написан на Go, а у них там очень жестко с размером исполняемых файлов, вместо этого они написали свое на Rust, но предпочли бы взять моё изделие, если бы могли. Совсем недавно появился порт ipp-usb на FreeBSD, вероятно, другие BSD тоже скоро подтянутся.

Вместе эти два пакета образуют стек "бездрайверного" сканирования документов для Linux и *BSD, а в перспективе нескольких лет, когда старые сканеры, наконец, вымрут, вероятно других драйверов и не останется.

Кроме того, ipp-usb делает возможным "бездрайверную" печать на USB-устройствах.

Здесь я хочу рассказать, каково оно, быть автором популярных OpenSource пакетов. Хоть эта работа и не принесла мне особых денег (на что я, впрочем, особо и не рассчитывал), она принесла мне бесценный опыт.

В целом, я полагаю, продвижение OpenSource пакетов структурно близко к продвижению на рынок программных продуктов. Занимаясь этой деятельностью, очень хорошо начинаешь понимать разницу между (1) написать программу, которая работает для меня (2) написать программу, которую можно назвать продуктом (3) вывести продукт на рынок.

Первое занимает гораздо меньше времени, чем второе. Второе - гораздо меньше времени, чем третье.