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

Первоначально, я писал их на Rust, но несмотря на годы опыта разработки на нем, приходилось повоевать. Со временем, я заставил мои клавиатуры работать, но это заняло неприличное количество времени и не приносило мне удовольствия.

После неоднократных предложений от моего более подкованного в Rust-и-вычислительной технике друга Джейми Брэндона, я переписал прошивку на Zig, и вышло очень удачно.

Я нашел это поразительным, учитывая, что я никогда не видел Zig раньше, и этот язык, еще даже не версии 1.0, созданный хипстером из Университета Портленда, и описывается, по сути, всего одной страницей документации.

Данная статья нацелена на тех, кто только недавно начал разрабатывать kernel-драйвера под ОС Windows. В 100-ый раз видишь ненавистную надпись IRQL_NOT_LESS_OR_EQUAL и этот грустный смайлик? Тогда прошу вас пройти под кат.

В этом руководстве мы кратко обсудим, как Helm может помочь упростить управление приложениями Kubernetes, и узнаем, как использовать Helm для создания базового чарта.

Управление приложениями — сложный аспект Kubernetes. Helm значительно упрощает его, предоставляя единый метод упаковки программного обеспечения, поддерживающий контроль версий. Helm устанавливает пакеты (называются Чартами в Helm) для Kubernetes и управляет ими, как это делают yum и apt.

В этом руководстве мы позволим Helm создать для нас базовый чарт. В этом руководстве предполагается, что у вас есть хотя бы базовое понимание того, что такое Helm. Если вы не знакомы с ним, я предлагаю вам ознакомиться с этим руководством, прежде чем приступить к статье: https://www.alibabacloud.com/help/doc-detail/86511.htm

Установка и управление Helm Charts может вызвать у вас некоторые сложности, с которыми вы, возможно, не сталкивались раньше.

Helm Charts упаковывает приложения для установки в кластеры Kubernetes. Установка Helm Chart немного похожа на запуск мастера установки, поэтому разработчики Helm Chart сталкиваются с некоторыми из тех же проблем, с которыми сталкиваются разработчики, производящие установщики:

• Какие предположения можно сделать об окружении, в которой выполняется установка?
• Может ли приложение взаимодействовать с другими приложениями?
• Какие конфигурации должны быть доступны пользователю и как их предлагать?

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

Но, "для нас нет ничего святого"(С), попробуем выяснить почему именно 4К, изменится ли что-то если сделать 8К, 64К... Зачем вообще фиксировать конкретный размер, почему не сделать страницы произвольной (в пределах разумного) длины.

Рабочая группа Rust 2021 Edition рада сообщить, что следующая редакция Rust — Rust 2021 — запланирована на этот год. Пока что формально описывающий её RFC остаётся открытым, но мы ожидаем, что в скором времени он будет принят. Планирование и подготовка уже начались, и мы идём по графику!

Если вам интересно, какие новшества появятся в Rust 2021 или когда эта редакция выйдет в стабильной версии, — читайте нашу статью!

Что входит в эту редакцию?

Конечный список нововведений, которые войдут в Rust 2021, ещё не определён до конца. В целом мы планируем, что выпуск Rust 2021 будет намного меньше, чем Rust 2018, по следующим причинам:

• Ритм выпусков стал регулярным Это значит, что мы будем активно использовать плюсы "цепочечной" модели на уровне редакций Rust.
• Редакция Rust 2018 выбилась из модели "минимального стресса" выпусков.
• Сейчас просто нужно меньше фундаментальных изменений, чтобы язык продолжал развиваться.

Более подробно о развитии концепции редакций вы можете почитать в RFC.

Решение, войдёт ли та или иная функциональность в Rust 2021, является частью процесса RFC — поэтому список ожидаемых функций может и будет меняться. Это будет происходить до самого момента выпуска, но тем не менее, уже сейчас мы можем рассмотреть список функций, которые, скорее всего, в неё войдут.

Добро пожаловать в очередной релиз Windows Terminal! В этом релизе основной Терминал Windows переносится в версию 1.6, которая включает в себя все функции из этого предыдущего поста в блоге, за исключением пользовательского интерфейса настроек. Windows Terminal Preview перейдет в версию 1.7, которая включает все функции, описанные ниже. Вы можете установить как Windows Terminal, так и Windows Terminal Preview из Microsoft Store или со страницы выпусков на GitHub.

Под катом рассказываем, что нового!

Основные идеи поста:

• Установка Kubernetes приложений это не сложно.
• Можно использовать легкий Kubernetes у себя на компьютере для быстрого развертывания приложений.
• Можно использовать ingress (nginx) локально используя metallb
• Все действия и команды похожи на реальные команды, которые вы будете делать в облаке.

MicroK8s — это CNCF-сертифицированное развертывание локального кластера Kubernetes, он предназначен для быстрой и легкой установки потока Kubernetes, изолированной от вашей локальной среды. В качестве оснастки он запускает все службы Kubernetes (т.е. без виртуальных машин), упаковывая при этом весь необходимый набор библиотек и файлов. Эта изоляция достигается за счет упаковки всех двоичных файлов для Kubernetes, Docker.io, iptables и CNI в единый пакет Snap.

Преимущества microk8s:

• использует только необходимые ему ресурсы
• кластеризация нескольких microk8s
• легкая и простая установка в Ubuntu через snap, хваленая изоляция snap пакетов, возможность легкого отката на предыдущую версию
• наличие аддонов

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

В этой заметке я расскажу о доменах, построенных на основе конечных автоматов, и распределенных транзакциях, реализованных при помощи таких доменов.

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

Создание пайплайнов CI с помощью Tekton (Часть 2/2)

В этой статье мы собираемся продолжить создание пайплайна CI с Tekton. В первой части мы установили Tekton на локальный кластер kind и определили нашу первую задачу, которая клонирует репозиторий GitHub и запускает тесты приложений для приложения Go (repo).

В этой части мы собираемся создать задачу, которая создаст образ Docker для нашего приложения Go и отправит его в DockerHub. После этого мы объединим наши задачи в пайплайн.

В этой статье мы собираемся создать пайплайн непрерывной интеграции (CI) с Tekton, фреймворком с открытым исходным кодом для создания конвейеров CI / CD в Kubernetes.

Мы собираемся подготовить локальный кластер Kubernetes через kind и установить на нем Tekton. После этого мы создадим пайплайн, состоящий из двух шагов, который будет запускать модульные тесты приложения, создавать образ Docker и отправлять его в DockerHub.

Это 1 из 2 частей, в которой мы установим Tekton и создадим задачу, запускающую тест нашего приложения. Вторая часть доступна здесь.

Объяснение легковесных потоков в 200 строк на Rust

Легковесные потоки (ligthweight threads, coroutines, корутины, green threads) являются очень мощным механизмом в современных языках программирования. В этой статье Carl Fredrik Samson попытался реализовать рантайм для легковесных потоков на Раст, попутно объясняя, как они устроены "под капотом".

Так же следует учесть, что статья не суперсвежая, так что для того, чтобы примеры заработали в современной ночной версии компилятора Раст, скорее всего понадобятся изменения, найти которые можно в репозитории кода для этой статьи.

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

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

При развертывании в кластере Kubernetes Tekton Pipelines предоставляет возможность определять и выполнять задачи сборки, входные и выходные данные в форме простых значений или сложных объектов, таких как образы Docker, и объединять эти ресурсы в конвейеры. Эти новые ресурсы Kubernetes и контроллеры, которые ими управляют, приводят к созданию автономной платформы CI / CD, размещенной в кластере Kubernetes.

В этом посте мы рассмотрим простой конвейер сборки, работающий на MicroK8S.

Это очередная статья из цикла «BPF для самых маленьких» (0, 1, 2) и первая из серии практических статей про трассировку Linux современными средствами.

Из нее вы узнаете о программе и языке bpftrace — самом простом способе погрузиться в мир BPF с практической точки зрения, даже если вы не знаете про BPF ровным счетом ничего. Утилита bpftrace позволяет при помощи простого языка прямо из командной строки создавать программы-обработчики и подсоединять их к огромному количеству событий ядра и пространства пользователя. Посмотрите на КПДВ ниже… поздравляю, вы уже умеете трейсить системные вызовы при помощи bpftrace!

В отличие от предыдущих статей серии, эта относительно короткая и ее основная часть написана в формате туториала, так что уже после пяти минут чтения вы сможете создавать обработчики и собирать статистику о любом событии в ядре Linux прямо из командной строки. В конце статьи рассказывается об альтернативах — ply и BCC. Минуты во фразе «после пяти минут чтения» подразумеваются меркурианские. Появление уникальных навыков после пяти минут чтения не гарантируется.

Это продолжение статьи Локализация своих скриптов на BASH. В ней мы используя массивы и косвенные ссылки, научились добавлять в свои скрипты дополнительные языки и переключаться между ними.

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