uk
Feedback
GNU/Linux | Notes

GNU/Linux | Notes

Відкрити в Telegram

Open Source, GNU/Linux, Debian/Ubuntu, Dotfiles, Software, Scripts, Notes, Terminal, Shell, Tools, Games, Fun, Misc, Music, Geek, Free Software Movement. Почта: krekhov.dev@gmail.com Кто я: https://t.me/krxnotes/246 GitHub: https://github.com/krekhovx

Показати більше
2 233
Підписники
Немає даних24 години
-27 днів
-330 днів
Архів дописів
Встроенные и загружаемые модули ядра Встроенные модули - это те, которые встроены в ядро на этапе его сборки. Загружаемые модули - обычно от сторонних поставщиков, могут существовать только отдельно и загружаться в память на этапе исполнения. Показывает загружаемые модули:
$ lsmod
Показывает встроенные модули:
$ cat /lib/modules/$(uname -r)/modules.builtin
Показывает как встроенные так и загружаемые модули:
$ ls /sys/module
Встроенные модули отмечаются как: CONFIG_SCSI=y (встроенная в ядро функциональность), а загружаемые как CONFIG_SCSI=m (отдельные .ko файлы, которые запускает kmod при необходимости). CONFIG_SCSI взят для примера. Некоторые модули не видны в выводе lsmod, но видны в modinfo потому что они являются (builtin). ——— @krxnotes

Найм на работу в IT (часть 1) Зачем в IT нужен HR ? Почему сфера HR никак не развивается ? Почему в современных реалиях я до сих пор слышу вопрос "Расскажите о себе" (когда все данные открыты) ? Зачем проводить более одного этапа собеседования ? Почему до сих пор не автоматизировали процесс найма инженеров ? Почему не избавляются от старой, вонючей методички найма, по которой работают большинство компаний ? Все это мне непонятно. Когда я ищу новую работу в IT, у меня начинается дикий приступ тошноты и агрессии. Почему ? Да потому что все одно и то же, все крайне примитивно и глупо. Очень много времени отнимают бесполезные HR со своими вопросиками, работающие по одной и той же методичке уже 200 лет. Я заметил, что половину информации работодатели/директора/HR вообще не дочитывают из резюме. И я слышу вопросы, ответы на которые уже есть в моем резюме. Я повторяюсь по много раз и меня это раздражает. Хотя в свою сторону они требуют, чтобы соискатель был ИДЕАЛЬНО готов, знал все ответы на все вопросы, мог решить все задачи в мире, знал все алгоритмы, мог программировать на всех языках, не спрашивал лишнего, был не слишком веселым и не слишком грустным, интересовался судьбой компании, и был вообще отличным рабом! Я часто указывал ссылки на портфолио, проекты, коммиты, решённые задачки из CodeWars и т.д., но в какой-то момент я просто перестал это делать, потому что это всё просто-напросто никто не смотрит при найме, и мне всё равно зададут кучу тупорылых вопросов, которые можно было изучить до собеседования со мной (просмотрев мои ссылочки). Они просто не готовятся к собеседованию (и так сойдет), это меня удивляет, хотя я почему-то готовлюсь. Очень странная позиция. Я не понимаю, почему в 2024 году процесс найма IT инженеров до сих пор не автоматизировали. Можно избежать кучу рутинных, повторяющихся процессов, и сэкономить большое количество времени. Но нет ... они упрямо не хотят расставаться с методичкой. Должен же быть какой-то автоматический отбор резюме и тестирования кандидатов с помощью заданий ? Чтобы я мог не выходя из дома зайти в браузер, пройти какой-нибудь тест на знания или сделать задание, исправить баг, написать модуль, отправить это в виде патча. Я устраиваюсь только в те компании, которые в процессе собеседования дают интересные задания на дом (и не **** мозги), например, в компании 'A' мне дали задание закрыть незакрытое CVE в openssl, я отлаживал, узнавал много нового, писал код, по итогу справился за неделю и меня взяли (без лишних и тупых вопросов). А в компании 'Б' задание было прикреплено к Хабр статье с указанием "если исправишь это в ядре, отправляй патч нам на почту и мы тебя берем" и все! Ничего лишнего. Я естественно прошел. На мой взгляд очень полезный вид собеседования, чем пустой треп в 3 и более этапов. ——— @krxnotes

Что такое linux-headers ? Это заголовочные файлы, являющиеся частью исходного кода ядра. Они содержат описания внешних интерфейсов, структур данных и макросов. Эти файлы необходимы для сборки модулей ядра, обеспечивая актуальность данных для бинарной совместимости. Пользовательские программы обращаются к /usr/include заголовкам. Модули ядра обращаются к /usr/src/linux-headers-$(uname -r) заголовкам. ——— @krxnotes

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

GitHub vs Bitbucket vs 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. ——— @krxnotes

Merge Request и Pull Request, в чем разница ? Pull Request (относится к Open Source продуктам, на открытой платформе типа GitHub). -> Я вот тут ваш продукт усовершенствовал, заберите-ка то, чего я наделал. Merge Request (внутри компании, на закрытой платформе типа GitLab). -> Я вот сделал правки, хочу свою ветку залить к вам в основную (master / main). ——— @krxnotes

Отправка своих пачтей в upstream, что нужно учесть ? 1. Качество патча. Патч должен быть хорошо написан, протестирован и документирован. 2. Спрос и полезность. Разработчики рассмотрят, насколько полезной будет эта функциональность для широкой аудитории. 3. Совместимость и поддержка. Патч не должен ломать существующий функционал или мешать текущим пользователям. 4. Обратная связь от сообщества. Если вы предоставите патч и получите положительные отзывы от сообщества пользователей, это может положительно повлиять на решение разработчиков. Мои патчи им нужны ? Это зависит от того, насколько разработчики и сообщество ПО сочтут ваш патч полезным и востребованным. Чтобы узнать об их интересе, можно сначала обсудить идею на форумах или в списках рассылки проекта (Mailing List). ——— @krxnotes

Установка локальных пакетов с помощью dpkg или apt (различие)
$ dpkg -i <./pkg>
Устанавливает пакет из указанного файла, но не обрабатывает зависимости. Если пакет, который вы устанавливаете, зависит от других пакетов, вам нужно будет установить их вручную.
$ apt install <./pkg>
Обрабатывает зависимости автоматически. Установит пакет из указанного файла и попытается установить все необходимые зависимости, а также рекомендуемые и предлагаемые пакеты, если они указаны. Таким образом, использование apt install предпочтительнее, если вы хотите, чтобы все зависимости (Depends / Recommends) были установлены автоматически. ——— @krxnotes

Midnight Commander (MC) - это текстовый файловый менеджер для Unix-подобных систем и Windows. Он работает в режиме консоли и
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 свои патчи/улучшения, нужно зарегистрироваться на сайте и создать тикет. Мне кажется, это хороший проект для начинающих вкладчиков. ——— @krxnotes

Цвета используемые в логотипе Debian (HEX) Современный логотип Debian использует следующие вариации красного цвета: #CE0056 и
Цвета используемые в логотипе Debian (HEX) Современный логотип Debian использует следующие вариации красного цвета: #CE0056 или #CE0058 или #D70A53 На фоне используется белый цвет: #FFFFFF Для букв используется черный цвет с шрифтом Poppl Laudatio Condensed: #000000 И получается красота =) ——— @krxnotes

In Memory of Ian Murdock Иэн Мердок ушел из жизни в 2015 году в возрасте 42 лет. После его смерти проектом Debian продолжает
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 ——— @krxnotes

Aptitude - это текстовый интерфейс для управления пакетами в Debian. Мейнтейнеры используют его для: 1. Установки и удаления
Aptitude - это текстовый интерфейс для управления пакетами в Debian. Мейнтейнеры используют его для: 1. Установки и удаления пакетов. 2. Обновления системы. 3. Управления зависимостями. 4. Поиска и просмотра информации о пакетах. 5. Удобного интерактивного управления пакетами. Он помогает эффективно поддерживать систему в актуальном состоянии. Например, в моем ~/.bashrc прописан алиас для удобства:
alias a='sudo aptitude'
Ссылка на исходный код aptitude: https://salsa.debian.org/apt-team/aptitude ——— @krxnotes

Debra + Ian Debian - это операционная система с открытым исходным кодом, основанная на ядре Linux. Она была создана Иэном Мер
Debra + Ian Debian - это операционная система с открытым исходным кодом, основанная на ядре Linux. Она была создана Иэном Мердоком (Ian Murdock) в 1993 году. Название Debian произошло от комбинации имен Иэна Мердока и его тогдашней подруги (впоследствии жены) Дебры Линн (Debra Lynn). Deb + Ian, получилось Debian. Иэн Мердок родился в 1973 году и окончил Университет Пердью в 1996 году. Он был не только создателем Debian, но и активным участником в развитии свободного программного обеспечения. Иэн написал Debian Manifesto, в котором изложил видение и цели проекта. Его работа повлияла на многие аспекты развития свободного программного обеспечения и открытых стандартов. Debian известен своей приверженностью к свободному программному обеспечению, а также своим демократическим процессом разработки, в котором участвуют тысячи добровольцев по всему миру. ——— @krxnotes

Сколько людей трудится над Debian ? Точное количество людей, работающих над Debian, может варьироваться, так как проект являе
Сколько людей трудится над Debian ? Точное количество людей, работающих над Debian, может варьироваться, так как проект является полностью открытым и добровольным. В Debian участвуют как официальные разработчики, так и множество добровольцев со всего мира. По состоянию на 2023 год, в проекте участвует более 1000 официальных разработчиков, но если учитывать всех участников, включая тех, кто вносит свой вклад в виде пакетов, документации, тестирования и поддержки, то общее количество людей может быть значительно выше. Для того чтобы начать делать вклад в Debian необязательно быть каким-то гением программирования, можно начать с простого, например, делать вклад в документацию, переводы, тестирование или пакеты. Кстати, про пакеты: в Debian насчитывается около 30.000 пакетов. Это очень круто 🥳 ——— @krxnotes

Откуда ноги растут Возможно, вам будет интересно узнать, откуда я беру информацию/идеи для постов. Ссылка на репозиторий с моими многочисленными Linux заметками: https://github.com/iikrllx/notes Там хранятся текстовые файлы, которые я составляю многие годы. Мне лень постоянно обращаться к документации/мануалам, поэтому я делаю короткие записи в этом репозитории (на будущее). Информация в файлах взята из книг/статей/документаций, либо я что-то исследовал и решил это записать. Данный канал является более упрощенной и красивой версией этих заметок =) Буду рад если вы поддержите репозиторий ⭐️ звездой. Спасибо. ——— @krxnotes

Создание временного файла или директории (mktemp) Раньше для создания временного файла я писал:
t=$(cat /dev/urandom | tr -dc 'a-z0-9' | head -c 8)
touch "/tmp/$t"
Узнал, что существует mktemp. Например, создание временного файла:
tmpdir=$(mktemp)
Появится файл: /tmp/tmp.iFRIpUv0xt После работы с файлом не забудьте его удалить. Создать временную директорию:
tmpdir=$(mktemp -d)
Появится директория: /tmp/tmp.MUsZJ1cc0C После работы с директорией не забудьте ее удалить. ——— @krxnotes

Получить информацию о пользователе (getent passwd). Получить информацию 1000 uid:
$ getent passwd 1000
kory:x:1000:1000:kory,,,:/home/kory:/bin/bash Получить только имя пользователя 1000 uid:
$ getent passwd 1000 | cut -d ':' -f1
kory Получить имена пользователей от 1000 до 2000 uid:
$ getent passwd {1000..2000} | cut -d: -f1
kory resu gvan ——— @krxnotes

Удаленное исполнение скрипта/команд по SSH (способы). 1. Исполнить команды на удаленном сервере:
$ ssh <user>@<ip> 'команда1; команда2; команда3'
2. Исполнить скрипт на удаленном сервере:
$ ssh <user>@<ip> bash -s < script.sh
Осуществляется перенаправление сценария script.sh с машины А на машину Б через сокет. bash -s считывает из стандартного ввода. 3. Исполнить скрипт на удаленном сервере:
$ scp script.sh <user>@<ip>:/path/to/destination/
$ ssh <user>@<ip> 'bash /path/to/destination/script.sh'
——— @krxnotes

dirname и basename. Удалить последний компонент из имени файла:
$ dirname /usr/local/bin/file
/usr/local/bin Удалить каталог и суффикс из имени файла:
$ basename /usr/local/bin/file
file ——— @krxnotes

——— @krxnotes
——— @krxnotes