Aptitude - это текстовый интерфейс для управления пакетами в Debian. Мейнтейнеры используют его для:

1. Установки и удаления пакетов.
2. Обновления системы.
3. Управления зависимостями.
4. Поиска и просмотра информации о пакетах.
5. Удобного интерактивного управления пакетами.

Он помогает эффективно поддерживать систему в актуальном состоянии.

Например, можно создать алиас:

$ alias a='sudo aptitude'

> Salsa

#software #opensource #utils

In Memory of Ian Murdock

Иэн Мердок ушел из жизни в 2015 году в возрасте 42 лет. После его смерти проектом Debian продолжает управлять сообщество разработчиков. В Debian нет постоянного единоличного лидера, вместо этого ежегодно избирается Debian Project Leader (DPL).

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

Debian скорбит о смерти Иэна: https://bits.debian.org/2015/12/mourning-ian-murdock-ru.html

#debian #people

Цвета используемые в логотипе Debian (HEX)

Современный логотип Debian использует следующие вариации красного цвета:
#CE0056
или
#CE0058
или
#D70A53

На фоне используется белый цвет:
#FFFFFF

Для букв используется черный цвет с шрифтом Poppl Laudatio Condensed:
#000000

И получается красота =)

#debian

Midnight Commander (MC) - это текстовый файловый менеджер для Unix-подобных систем и Windows. Он работает в режиме консоли и предоставляет удобный интерфейс для управления файлами. Основные функции MC включают копирование, перемещение, удаление файлов, просмотр содержимого файлов и архивов, а также работу с FTP-серверами. Благодаря своему двухпанельному интерфейсу и множеству горячих клавиш, Midnight Commander значительно облегчает навигацию и управление файлами в командной строке.

Ссылка на репозиторий с исходным кодом: https://github.com/MidnightCommander/mc

Ссылка на сайт: https://midnight-commander.org/

Разработчики MC не принимают Pull Requests в репозиторий на GitHub, но зато активно мониторят тикеты на сайте (смотреть "View Tickets"), если вы обнаружили баг или хотите предложить для MC свои патчи/улучшения, нужно зарегистрироваться на сайте и создать тикет.

Мне кажется, это хороший проект для начинающих вкладчиков.

#software #opensource #utils

Установка локальных пакетов с помощью dpkg или apt (различие)

$ dpkg -i <./pkg>

Устанавливает пакет из указанного файла, но не обрабатывает зависимости. Если пакет, который вы устанавливаете, зависит от других пакетов, вам нужно будет установить их вручную.

$ apt install <./pkg>

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

Таким образом, использование apt install предпочтительнее, если вы хотите, чтобы все зависимости (Depends / Recommends) были установлены автоматически.

#debian #utils

Отправка своих патчей в upstream, что нужно учесть?

1. Качество патча.
Патч должен быть хорошо написан, протестирован и документирован.

2. Спрос и полезность.
Разработчики рассмотрят, насколько полезной будет эта функциональность для широкой аудитории.

3. Совместимость и поддержка.
Патч не должен ломать существующий функционал или мешать текущим пользователям.

4. Обратная связь от сообщества.
Если вы предоставите патч и получите положительные отзывы от сообщества пользователей, это может положительно повлиять на решение разработчиков.

Мои патчи им нужны? Это зависит от того, насколько разработчики и сообщество ПО сочтут ваш патч полезным и востребованным. Чтобы узнать об их интересе, можно сначала обсудить идею на форумах или в списках рассылки проекта (Mailing List).

#opensource

Merge Request и Pull Request, в чем разница?

Pull Request (относится к Open Source продуктам, на открытой платформе типа GitHub).
-> Я вот тут ваш продукт усовершенствовал, заберите-ка то, чего я наделал.

Merge Request (внутри компании, на закрытой платформе типа GitLab).
-> Я вот сделал правки, хочу свою ветку залить к вам в основную (master / main).

#git

GitHub / Bitbucket / GitLab в чем разница?

Все это +- одно и тоже, но есть небольшие различия.

GitHub - Open Source инструмент, есть так же закрытые репозитории, но в основном стал популярен из-за Open Source проектов.

Bitbucket - очень редко используется для Open Source, и часто для закрытых проектов, используется разными закрытыми компаниями вместе с Jira.

GitLab - тоже самое, есть CI/CD, многие компании берут его и разворачивает у себя в локальной сети для закрытого использования.

Процесс разработки программного обеспечения:
GitHub: Code -> Review.
GitLab: Code -> Review -> Build -> Test -> Plan.
Bitbucket: Code -> Review -> Build -> Test -> Plan.

#git

Права доступа файлов в GIT

Git не сохраняет права доступа файлов. После клонирования права доступа будут установлены в соответствии с umask пользователя.

В Git сохраняется только бит исполнения (x) для файлов. Остальные права доступа (чтение, запись) — нет, они выставляются согласно umask пользователя.

#git

Что такое linux-headers?

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

Пользовательские программы обращаются к /usr/include заголовкам.
Модули ядра обращаются к /usr/src/linux-headers-$(uname -r) заголовкам.

#kernel #theory

Найм на работу в IT (часть 1)

Зачем в IT нужен HR ? Почему сфера HR никак не развивается ? Почему в современных реалиях я до сих пор слышу вопрос "Расскажите о себе" (когда все данные открыты) ? Зачем проводить более одного этапа собеседования ? Почему до сих пор не автоматизировали процесс найма инженеров ? Почему не избавляются от старой, вонючей методички найма, по которой работают большинство компаний ? Все это мне непонятно.

Когда я ищу новую работу в IT, у меня начинается дикий приступ тошноты и агрессии. Почему ? Да потому что все одно и то же, все крайне примитивно и глупо. Очень много времени отнимают бесполезные HR со своими вопросиками, работающие по одной и той же методичке уже 200 лет.

Я заметил, что половину информации работодатели/директора/HR вообще не дочитывают из резюме. И я слышу вопросы, ответы на которые уже есть в моем резюме. Я повторяюсь по много раз и меня это раздражает.

Хотя в свою сторону они требуют, чтобы соискатель был ИДЕАЛЬНО готов, знал все ответы на все вопросы, мог решить все задачи в мире, знал все алгоритмы, мог программировать на всех языках, не спрашивал лишнего, был не слишком веселым и не слишком грустным, интересовался судьбой компании, и был вообще отличным рабом!

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

Я не понимаю, почему в 2024 году процесс найма IT инженеров до сих пор не автоматизировали. Можно избежать кучу рутинных, повторяющихся процессов, и сэкономить большое количество времени. Но нет ... они упрямо не хотят расставаться с методичкой. Должен же быть какой-то автоматический отбор резюме и тестирования кандидатов с помощью заданий ? Чтобы я мог не выходя из дома зайти в браузер, пройти какой-нибудь тест на знания или сделать задание, исправить баг, написать модуль, отправить это в виде патча.

Я устраиваюсь только в те компании, которые в процессе собеседования дают интересные задания на дом (и не **** мозги), например, в компании 'A' мне дали задание закрыть незакрытое CVE в openssl, я отлаживал, узнавал много нового, писал код, по итогу справился за неделю и меня взяли (без лишних и тупых вопросов). А в компании 'Б' задание было прикреплено к Хабр статье с указанием "если исправишь это в ядре, отправляй патч нам на почту и мы тебя берем" и все! Ничего лишнего. Я естественно прошел. На мой взгляд очень полезный вид собеседования, чем пустой треп в 3 и более этапов.

#thoughts

Встроенные и загружаемые модули ядра

Встроенные модули - это те, которые встроены в ядро на этапе его сборки.

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

Показывает загружаемые модули:

$ lsmod

Показывает встроенные модули:

$ cat /lib/modules/$(uname -r)/modules.builtin

Показывает как встроенные так и загружаемые модули:

$ ls /sys/module

Встроенные модули отмечаются как: CONFIG_SCSI=y (встроенная в ядро функциональность), а загружаемые как CONFIG_SCSI=m (отдельные .ko файлы, которые запускает kmod при необходимости).

CONFIG_SCSI взят для примера.

Некоторые модули не видны в выводе lsmod, но видны в modinfo потому что они являются (builtin).

#kernel #utils

Найм на работу в IT (часть 2)

Больше всего я не понимаю, когда на техническом собеседовании спрашивают о технологиях, которые компания не использует. Это частая практика - задавать очень сложные вопросы не по теме, чтобы кандидат не прошел. Почему они так делают? Может, не понравился кандидат или запах от него плохой, не знаю. Но практикуют это часто. А потом ты как-то с горем пополам устраиваешься к ним, со слезами и соплями (через полгодика или через другого интервьюера), и узнаешь, что эту технологию/инструмент никто не использует из инженеров в компании, а столько шума было...

Вообще часто возникает ситуация (ожидание / реальность), когда на собеседовании рассказывают о "технологическом прорыве компании", как они круто развиваются, растет количество сотрудников и клиентов, какие они современные и умные. Но потом все меняется, когда я получаю доступ к внутреннему GitLab компании (коду, проектам, скриптам). Вещи, которые я видел, просто не передать словами ... один legacy и костыли, 0 автоматизации, 0 современных подходов, 0 документации (лучше иди спроси у Васи). Компаний, работающих по такому принципу, очень много в РФ (как в других странах - не знаю). Будьте осторожны, друзья, никакие деньги не оправдают подобной головной боли.

Я не говорю, что все IT-компании в РФ плохие (нет), но большинство из них - это мусор. Задача соискателя - найти в этом мусоре что-то адекватное.

Я встречал довольно мало приятных технических интервьюеров, которые не выпендриваются своими знаниями. Большинство из них высокомерные и токсичные, думают, что они умные, и зачем-то принижают кандидата (видимо, чтобы сбить его рыночную стоимость, скомпрометировать). Мне нравится, как технические интервьюеры меняются в лице, когда начинаешь собеседовать их и спрашивать что-то отдельное от их списка вопросов. Да-да, они сыпятся как маленькие девочки .. и к чему весь этот цирк? Мне непонятно. С таких собеседований я ухожу довольно быстро.

Вернемся к HR: Павел Дуров рассказал в интервью Такеру Карлсону, что у него в Telegram нет HR. Чтобы отобрать самых лучших специалистов, Дуров регулярно проводит на отдельной платформе конкурсы для разработчиков. Это называется современный подход, вызывает уважение. Берите пример, что ли...

#thoughts

Удаление директории

Для примера создать скелет:

$ mkdir dir/
$ dd if=/dev/zero of=dir/{a,b} bs=8000 count=1

Удаление директории со всеми ее файлами:

$ rm -r dir/

Удаление директории:

$ rmdir dir/

rmdir: failed to remove 'dir/': Directory not empty

Приглушить вывод ошибки:

$ rmdir --ignore-fail-on-non-empty dir/

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

Иногда в скриптах полезно использовать rmdir, эта утилита удаляет только пустые директории.

#shell #utils

Книга по Computer Science (часть 1)

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

#books #theory

Книга по Computer Science (часть 2)

А здесь неплохо описана база сетевой теории в первых главах.

#books #theory

Замена системных вызовов с помощью модулей ядра

Из книги https://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf:
You can even write modules to replace the kernel's system calls, which we'll do shortly. Crackers often make use of this sort of thing for backdoors or trojans, but you can write your own modules to do more benign things, like have the kernel write Tee hee, that tickles! everytime someone tries to delete a file on your system.

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

#kernel #books

Debian LTS (Debian Long Term Support)

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

Таблицу LTS поддержки можно увидеть здесь: https://wiki.debian.org/LTS

#debian

Вы только посмотрите, какая красота стала! Теперь вывод apt можно разглядеть =)

В Debian Sid (unstable) утилита apt получила улучшенный интерфейс вывода информации при работе с пакетами. Эти изменения направлены на то, чтобы сделать процесс более прозрачным и удобным для пользователей.

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

#debian #software #utils

Реклама

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

Например, недавно у меня появилась потребность почитать про различные DevOps инструменты. Мой знакомый коллега порекомендовал мне некоторые DevOps-каналы. Что я там увидел? Реклама, реклама, реклама, мемы, курсы, реклама и еще раз реклама. Про DevOps я так ничего и не узнал (либо очень поверхностно). В этом во всем очень сложно найти что-то ценное, и меня это раздражает. Такие каналы забирают кучу времени и сил, а взамен ничего не дают. Поэтому я не хочу, чтобы мой канал превратился в похожую помойку.

С другой стороны, если бы не реклама, вы бы не узнали об этом канале. Забавно, не правда ли?

#thoughts

Знаете ли вы, что GitLab Debian, salsa.debian.org, имеет около 15500 пользователей, 79000 проектов, 750 групп, 31000 форков, 14600 задач и 64000 запросов на слияние? Мы активно работаем!

https://micronews.debian.org/2024/1724368366.html

#debian