Linux *

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

Уважаемые хабравчане, предлагаю вашему вниманию перевод оставшихся глав спецификации D-Bus. Полный pdf-документ можно скачать по адресу.

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

Спасибо за внимание.

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

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

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

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

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

Возникла задача получить из SDI сигнала трансляцию с субтитрами и отдать её на CDN в формате RTMP потока. Пару недель мучения и мытарств изложу в кратком содержании всех серий для коллекции. Возможно, кому пригодится.

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

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

Уже лет десять моим основным медиаплеером на компьютере является MPD, Music Player Daemon — фоновый сервис, воспроизводящий музыку.

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

Предлагаю вашему вниманию краткий обзор (сравнительно) нового MPD-клиента для Linux/GTK под названием Ymuse, версию 0.16 которого я недавно выпустил.

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

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

Возможно я бы собрался силой воли, помучился бы недельку, сделал бы все стандартными однострочниками+notepad+excel, но тут внезапно у меня случился больничный отпуск, а когда температура меня попустила, а на работу еще можно было не выходить. И я случайно вспомнил, что считаю себя спецом по bash.

И пусть я не хватаю лавры автора PIUPIU, но тем не менее встречайте:

35+ кбайт двух-панельного keystore manager на Linux shell

Создание меню на BASH — задача сама по себе не сложная: "case тебе в руки и echo в спину". Решая её в очередной раз, мне захотелось добавить возможность отображать текст на других языках. Осталось решить, как сделать сам процесс локализации меню более удобным. Если оно большое, то решение "в лоб" превратит его в громоздкую копипасту. Здесь я хотел бы поделиться тем, как решил эту проблему для себя. Надеюсь, для кого то это будет небезынтересным.

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

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

Реализация будет состоять из:

• буквенного кода языка
• массива слов
• преобразователя косвенных ссылок для обращения к массиву
• обращения к элементам массива
• создания меню

Теперь рассмотрим подробнее