X11 это тот механизм на чем работает весь графический интерфейс Unix подобных ОС.

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

А протокол в своей сути прекрасен. Он лаконичен и почти совершенен.

В Интернете есть полная документация по протоколу. Но дело в том, что эта документация большая, написана не совсем ясным языком и, по сути, является просто спецификацией. Важные моменты никак не обозначены, а как использовать – тоже оставлено на фантазию читателя.

А все книги и статьи по использованию X11 описывают это через библиотеки прокладки типа XLib и XCB, и даже, что хуже, GTK или Qt.

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

Как бы то ни было, если кому-то интересно как все работает на самом деле, пожалуйста под кат.

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

Уже больше года в информационном пространстве появляется компания «Веб-Сервер», разрабатывающая отечественный открытый веб-сервер Angie и его коммерческую версию Angie PRO. Информационная служба Хабра пообщалась с руководителем отдела разработки «Веб-Сервера» Валентином Бартеневым. Узнали историю компании, детали разработки, планы по развитию и готовы поделиться этим.

В этой статье рассмотрим как подключиться к консоли Repka Pi 3 через UART.

Repka Pi как и другие компьютеры аналогичного семейства имеет Debug UART выведенный на 40 пиновый разъем платы.

Для начала работы нам потребуется программа PuTTY и USB to TTL конвертер с кабелем.

Скачиваем и устанавливаем программу текущую версию PuTTY с официального сайта https://www.putty.org/. На момент написание статьи версия PuTTY 0.78.

Вот так выглядит PuTTY после установки.

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

Когда я вижу у недавнего выпускника в резюме какой-то из протоколов в котором используется valid/ready, например AXI или AHB, я прошу его спроектировать блок, у которого на входе два числа A и B, а на выходе их сумма. Разумеется не просто написать SUM=A+B, а еще и поставить valid/ready сигналы на каждый из A, B, SUM, чтобы A и B могли приходить в разное время, а также чтобы блок ждал, если SUM не может быть передана другому блоку сразу.

Некоторые не справляются. Грустно смотреть на человека, который потратил 6 лет своей жизни (4 года в бакалавриате и 2 года в магистратуре) и океан денег на образование - и не может сложить два числа и бьется как угорь на сковородке. То блок не работает когда числа приходят в разное время, то создатель забывает снять valid, и блок на 2+2 выдает не 4, а 4-4-4-4-4-4-4... То числа складываются не попарно, а просто записываются в регистры и на выход идет их текущая сумма, хотя количество аргументов A и B не совпадает. То не отрабатывается backpressure и результаты теряются, то (после того как кандидат написал страницу кода на верилоге) блок работает на половинной производительности, то есть не может принимать поток чисел подряд, а ожидает между ними пропуски (gaps). Короче ведет себя как ChatGPT.

В этом тексте я написал про особенности интерфейса I2S и про то как можно тестировать и отлаживать интерфейс I2S.

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

Однако при принятии решения о необходимости миграции возникает множество вопросов: как вы определяете границы услуги? Как вы проверяете свойства самовосстановления архитектуры микросервиса?

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

Совсем недавно, 25 января 2022 года вышел новый релиз Nginx - 1.21.6, в котором исправлена проблема неравномерного распределения входящих соединений между несколькими worker процессами в дефолтной конфигурации на Linux системах. Если конкретнее - use epoll, accept_mutex off, reuseport выключен.

В данной конфигурации при определенном характере нагрузки большинство входящих в Nginx соединений обрабатывается лишь одним worker процессом. 

Насколько я понимаю, эта проблема существует уже более пяти лет и берет начало в версии 1.11.3 (Jul 2016), когда в Nginx по умолчанию отключили accept_mutex, а вместо него стали полагаться на флаг EPOLLEXCLUSIVE, появившийся в ядре Linux 4.5.

Стоит заметить, что проблема балансировки входящих соединений при использовании механизма epoll и флага EPOLLEXCLUSIVE более глобальна и касается не только Nginx, а любых сетевых приложений, работающих по аналогичной схеме.

В этой статье мы посмотрим на историю и причины появления данной проблемы, а также рассмотрим код ее решения в новом релизе Nginx.

В интернете есть много статей с описанием алгоритма градиентного спуска. Здесь будет еще одна.

8 июля 1958 года The New York Times писала: «Психолог показывает эмбрион компьютера, разработанного, чтобы читать и становиться мудрее. Разработанный ВМФ… стоивший 2 миллиона долларов компьютер "704", обучился различать левое и правое после пятидесяти попыток… По утверждению ВМФ, они используют этот принцип, чтобы построить первую мыслящую машину класса "Перцептрон", которая сможет читать и писать; разработку планируется завершить через год, с общей стоимостью $100 000… Ученые предсказывают, что позже Перцептроны смогут распознавать людей и называть их по имени, мгновенно переводить устную и письменную речь с одного языка на другой. Мистер Розенблатт сказал, что в принципе возможно построить "мозги", которые смогут воспроизводить самих себя на конвейере и которые будут осознавать свое собственное существование» (цитата и перевод из книги С. Николенко, «Глубокое обучение, погружение в мир нейронный сетей»).

Ах уж эти журналисты, умеют заинтриговать. Очень интересно разобраться, что на самом деле представляет из себя мыслящая машина класса «Перцептрон».

• рассматриваем «сложный» сценарий компоновки GNU ld;
• учимся использовать прерывания;
• наконец добираемся до hello world!

• ARM-ы для самых маленьких
• ARM-ы для самых маленьких: который час?
• ARM-ы для самых маленьких: тонкости компиляции и компоновщик

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

volatile unsigned long int incremented;