Настройка VSCode для разработки в Tauri

Как настроить VSCode для удобной работы с проектом Tauri. Установим пару плагинов и настроим launch.json и tasks.json.

Пишем под *nix

Как настроить VSCode для удобной работы с проектом Tauri. Установим пару плагинов и настроим launch.json и tasks.json.

Все приложения на сервере необходимо запускать под управлением какого-либо демона. Возможно, вы уже используете supervisord или systemd.
Эта статья покажет, как упростить вашу жизнь при помощи systemd, интегрировав его напрямую в ваше приложение через SPM-плагин.
Для начала давайте посмотрим, как мы обычно работаем с systemd и что нужно проделать для его настройки на работу с нашим приложением.

Один из разделов статьи Overview of cross-architecture portability problems я посвятил проблемам, возникающим из-за использования 32-битного типа time_t. Это архитектурное решение, до сих пор влияющее на использующие glibc системы с Gentoo, приведут к тому, что у 32-битных приложений в 2038 году начнут возникать ужасные сбои: они будут получать ошибку -1 вместо текущего времени и не смогут выполнять stat() файлов. Одним словом, возникнет полный хаос.
Считается, что решением будет переход на 64-битный тип time_t. Musl уже перешёл на него, а glibc поддерживает его как опцию. Многие другие дистрибутивы, например, Debian, совершили этот переход. К сожалению, дистрибутивам на основе исходников, например, Gentoo, сделать это не так просто. Поэтому мы по-прежнему обсуждаем эту проблему и экспериментируем, пытаясь понять, как пользователи максимально безопасно могли бы выполнить апгрейд.
К сожалению, это совершенно нетривиально. Во-первых, мы говорим о переломном изменении ABI — ситуация «всё ли ничего». Если в API библиотеки используется time_t, то всё связанное с ней должно использовать ту же ширину типа. В этом посте я бы хотел подробно рассмотреть этот вопрос: почему это плохо и что мы можем сделать, чтобы повысить безопасность.

В мире программирования создание собственных библиотек — это не просто возможность пополнения своего портфолио или способ структурировать код, а настоящий акт творческого самовыражения (и иногда велосипедостроения). Каждый разработчик иногда использовал в нескольких своих проектах однообразный код, который приходилось каждый раз перемещать. Да и хотя бы как упаковать свои идеи и знания в удобный и доступный формат, которым можно будет поделиться с сообществом.
Если вы ловили себя на мысли: «А почему мне бы не создать свою полноценную библиотеку?», то я рекомендую прочитать вам мою статью.
Эту статью вы можете использовать как шпаргалку для создания проектов, и не только библиотек.
Некоторые из вас могут подумать, что мы изобретаем велосипед. А я в ответ спрошу — сможете ли вы прямо сейчас, без подсказок, только по памяти, нарисовать велосипед без ошибок?
Добро пожаловать во вторую, скорее всего финальную часть статьи! Здесь мы окончательно допишем код, исправим некоторые ошибки.

30 октября в 19:00 инженеры из YADRO и локальной Linux User группы откроют серию совместных митапов. Они поделятся опытом точечного обновления ядра Linux с помощью livepatching, расскажут о поддержке архитектуры и расширений RISC-V и про устройство подсистемы DMA.
Регистрируйтесь, чтобы забронировать место на площадке, — количество мест ограничено. Но для тех, кто не успеет, будет доступна трансляция в VK, YouTube или Rutube (также по регистрации) и открыт лист записи на следующие Linux-митапы.

Несколько дней назад вышло обновление, устраняющее последние шероховатости UX, и мы рады представить вам долгожданный полноценно работающий Far Manager в составе LTS-версии Ubuntu 24.04! В этой статье я расскажу, как получить максимум удовольствия от его использования. Поехали!
sudo apt update
sudo apt install far2l
Представляю вашему вниманию третью (заключительную) часть перевода статьи A guide to inter-process communication in Linux.
Первая часть перевода была посвящена общему введению в курс дела и механизму разделяемого хранилища (shared storage). Во второй части были рассмотрены механизмы каналов (именованных и неименованных) и очереди сообщений. В третьей части автор статьи ставит перед собой цель рассказать вам о сокетах и сигналах; подводит общие итоги по межпроцессному взаимодействию в Linux.
Приятного чтения!

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

В этой статье мы хотим рассказать о том, как интегрировали сервисы Яндекса в ОС «МСВСфера АРМ» 9. А точнее — gnome‑online‑accounts и сопутствующие программы evolution, календарь и gvfs с Яндекс сервисами.

Всем привет! Меня зовут Михаил, и в своей предыдущей статье я кратко осветил цепочку прохождения логов в ОС Astra Linux SE. Продолжаем!
Любой человек, который регулярно сталкивается с темой логирования, рано или поздно задаётся вопросом: «А что ещё можно сделать с логами, помимо простого добавления записей в некоторый файл?». Поэтому сейчас поговорим о таком мощном инструменте обработки логов, как syslog-ng.

Привет, Хабр! Меня зовут Павел Панкратов, я ведущий инженер-программист в дивизионе искусственного интеллекта YADRO. Этим текстом я запускаю цикл статей — экскурс в особенности работы с SoC, комбинирующей в себе реализованные в «железе» аппаратные блоки (Hard IP’s) и программируемую логику (Soft IP’s). Основная задача, которая объединит все три статьи, — параллельный запуск встраиваемой операционной системы на двух различных по архитектуре процессорах, представленных в виде Hard и Soft IP-блоков.
Производители подобных систем, как правило, предоставляют окружение для разработки и документацию с примерами реализации универсальных решений. Но масса важных деталей от пользователя все же скрывается, что приводит к долгим исследованиям при попытках нетривиальной модификации. Эта и остальные статьи цикла — попытка раскрыть завуалированные тонкости, сделать их доступными и понятными.

Сегодня технологические компании стоят перед выбором без выбора: если перед нами не стоит узкоспециализированная задача, то мы по дефолту идем работать в Kubernetes. Эта система универсальна и проверена годами, поэтому обойтись без нее практически невозможно.
Привет! Меня зовут Игорь Титов, я Product Lead системных инженеров в Garage Eight. В этой статье расскажу, что такое контейнеризация, как с ней помогает Kubernetes и почему важно уметь правильно его готовить.

Фаззинг — очень популярная методика тестирования программного обеспечения случайными входными данными. В сети огромное количество материалов о том, как находить дефекты ПО с его помощью. При этом в публичном пространстве почти нет статей и выступлений о том, как искать уязвимости с помощью фаззинга. Возможно, исследователи безопасности не хотят делиться своими секретами. Тем интереснее рассмотреть эту тему в данной статье.

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

Небольшая статья по настройке серверной части для телеграм бота, на базе языка программирования С++ и библиотек TgBot и sqlite3.

Я решил недавно улучшить свой навык владения C, путем написания проектов. Самая первая мысль, которая пришла мне на ум — это командный интерпретатор, командная оболочка, shell проще говоря. А также я расскажу о системе сборки make, и о том, как правильно писать и документировать C-код.
В первой части мы задали базовую структуру кода, разобрались с чтением вывода и созданием процессов. А в этой части нашей задачи будет дойти с альфа-стадии на бета-стадию — то есть реализовать прочий важный функционал, такой как: минимальная поддержка плагинов; автодополнение; подсветка синтаксиса; переменные окружения, новые встроенные утилиты.
Да-да, мы превратим наш велосипед в мопед! Я вынес из прошлой статьи итоги, и попытался решить все проблемы и замечания. Продолжаем погружение в пучины разработки под Linux!

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

Опишу, как «поднять» SPI в Линуксе (Убунту), подключить экранчик 12 864 с контроллером ST7920 (бывают и другие варианты контроллеров) к ZYNQ-7010 и отобразить на нём текст, линию и прямоугольник, используя Питон.

Представляю вашему вниманию вторую часть перевода статьи A guide to inter-process communication in Linux.
Первая часть перевода была посвящена общему введению в курс дела и механизму разделяемого хранилища (shared storage). В этой части будут рассмотрены механизмы каналов (именованных и неименованных) и очереди сообщений.
Приятного чтения!