Установка локальных пакетов с помощью 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

ChatGPT

Самый бесподобный инструмент для изучения чего-либо! Это лучшее, что я видел за всю свою карьеру в IT. Вы можете задать самые глупые вопросы, и он ответит! Вау. Описать в ярких красках нудную документацию из ядра? Запросто. Перевести какой-то абзац? Легко. Он может очень многое. На самом деле, изначально я не доверял ChatGPT, потому что было время, когда он дезинформировал или писал чушь, но потом стало всё лучше и лучше. Сейчас же он ошибается в редких случаях. Я использую в работе https://news.1rj.ru/str/chatgpt_elite_bot и вам советую.

Например, я не люблю регулярные выражения и sed, ну не могу я их запомнить/выучить... хотя использую в работе довольно часто =)

- Мне нужно убрать первый символ в файле, как это сделать? (sed, ответь коротко)
- ChatGPT

$ sed -i '1s/^.//' <file>

Это же прекрасно! А раньше приходилось втыкать в мануал или искать в интернете, как же изменилось время.

Ещё очень яркий пример, когда мне помог ChatGPT: я писал программный модуль на Си для Linux Capabilities (было их расширение), и чтобы понять логику, мне нужно было изучить их работу, что было непросто, потому что man 7 capabilities написан довольно поверхностно (описание привилегий короткое). И тут ChatGPT меня спас! Он рассказал мне всё в красках и с подробностями, это было круто. А без него я бы облысел тогда.

#thoughts

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

Однажды я разговаривал с одной HR около 10 минут о зарплатной вилке. Она до последнего не хотела говорить, сколько я буду получать, а я не хотел говорить, сколько мне действительно нужно. Я вообще не понимаю, почему я должен что-то говорить как соискатель. Ведь все равно я буду получать столько, сколько даст компания, не больше и не меньше, и плевать они хотели на мои зарплатные ожидания. HR должны сообщать, сколько компания может/будет платить и не делать мозги.

Расскажу, как происходит процесс поиска инженеров. Допустим, есть директор департамента разработки, он говорит HR: "Нам нужно еще 2-3 инженера, начинай поиски, на каждую позицию выделено по 200 тысяч рублей." HR начинает искать. Все легко и просто.

В чем проблема сразу сказать об этом соискателю? У нас на данную позицию до 200 тысяч рублей зарплата, вам подходит такое? Но такого они не говорят. В 99% случаев начинаются торги: кто первый назвал цифру, тот и проиграл. Я ненавижу эти игры... просто ненавижу. Все это занимает много сил и времени.

Просто я не понимаю, на что они надеются. Что я назову цифру в 150 тысяч рублей? (хотя на самом деле они могут платить 200). Потом всё равно узнается реальная вилка через будущих коллег. И что будет? Сильное разочарование и просьба повысить зарплату до 200 и выше, потому что у коллег столько, а они ничем не лучше. Все равно их попытка сэкономить провалится, и вот опять же, для чего весь этот HR цирк?

Как-то недавно мне позвонила HR и сказала прямо (без лишних слов), что в нашей компании Junior инженеры получают до 150 тысяч, Middle - до 250 тысяч, а Senior - до 400 и выше. Я был готов ее расцеловать, потому что она сэкономила мне нервы и время. Мне не пришлось вытягивать информацию, торговаться и участвовать в этих фальшивых играх, переговариваться, спорить.

#thoughts

Бизнес и Open Source

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

Коммерческие компании никоим образом не нацелены на улучшение или создание качественного продукта. Их мотивация - получение прибыли, им плевать на пользователя, на качество и на будущее. Главное - выкатить релиз, получить прибыль и убежать скорее праздновать. По крайней мере, это то, что я наблюдаю на рынке в РФ уже около пяти лет (в сфере разработки Linux-дистрибутивов и импортозамещения операционных систем). Это часто вызывало у меня грусть. Решением всех моих проблем стало уход в Open Source, не бросая при этом работу.

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

Я выбрал дистрибутив Debian и активно вношу вклад в пакетирование, документацию, переводы и тестирование. Я отправляю свои патчи сопровождающим пакетов или в upstream и надеюсь, что когда-то получу роль DM в проекте.

Итого:
- Бизнес: Основная цель коммерческих компаний - получение прибыли. Они разрабатывают программное обеспечение, чтобы продавать лицензии, подписки или услуги, связанные с использованием их продуктов.
- Open Source: Цель open source проектов - создание и распространение программного обеспечения, доступного для всех. Мотивы могут включать желание улучшить технологию, сотрудничество и обмен знаниями.

#thoughts

pkg-config

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

Выводит список всех установленных пакетов/библиотек и их метаданных:

$ pkg-config --list-all

Все чаще библиотеки поставляются с файлами .pc, которые обычно находятся в директории /usr/lib/x86_64-linux-gnu/pkgconfig/* (может различаться в зависимости от системы). Эти файлы позволяют с помощью утилиты pkg-config получить информацию о необходимых флагах компилятора и компоновщика для использования библиотеки.

Возьмем для примера библиотеку ncurses.

Версия библиотеки:

$ pkg-config ncurses --modversion

...

Показывает флаги компоновщика данной библиотеки:

$ pkg-config ncurses --libs

-lncurses -ltinfo

Показывает флаги препроцессора и компилятора:

$ pkg-config ncurses --cflags

-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600

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

$ gcc my.c $(pkg-config ncurses --libs)

#utils #build