Как хакнуть что угодно с помощью GNU Guix -4


Мариус Бакке (Marius Bakke) несколько лет занимается разработкой Guix и недавно начал вести свой блог. Мы решили перевести рассказ о том, почему Мариус увлёкся разработкой собственной операционной системы и как с её помощью можно вносить правки в код любых программ.

Почему Guix

Друзья часто спрашивали, почему я трачу столько свободного времени на разработку Guix? Я не всегда находил, что ответить, но спустя шесть лет могу сформулировать несколько причин.

Прежде всего, это весело. Прикольно делать свою собственную операционную систему. Я могу спроектировать её именно так, как хочу: от внутреннего устройства до пользовательского интерфейса.

Это приносит удовлетворение. Хотя в последнее время обновления выходят не так активно, как хотелось бы, я испытываю чувство благоговения и удовлетворения, когда помогаю новым участникам, как новичкам, так и «профессионалам». Это что-то вроде прилива дофамина, который даёт силы для новых свершений: перехода на новый компилятор C или обновления версии Python (это больше напоминает зависимость, чем хобби).

Моя работа кажется важной. Guix занимает пустующую нишу на рынке операционных систем. Она предлагает полную воспроизводимость, прозрачность и исходники каждого пакета и каждого поколения ОС. Он также включает удобный язык сценариев, с помощью которого вы можете объединить любой пакет в один определённый сценарий. Это можно представить, как сценарии оболочки, где каждая команда лениво создаётся менеджером пакетов по запросу. Вам даже не нужно использовать Scheme, вы можете писать на любимом языке и запускать это в guix shell. Если вы отметите версию Guix (как указано в guix describe), вы можете использовать guix time-machine для воспроизведения точно такой же среды в будущем.

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

Но самое главное, Guix спас мне жизнь. Когда я впервые начал работать с ним, у меня не было направления в жизни, никакого чувства цели или принадлежности к чему-то важному. Долгое время я использовал GNU/Linux, был «опытным пользователем» Debian, Gentoo и NixOS, но не внёс большого вклада в них, потому что упаковка данных требовала слишком много работы, или мне не нравилось сообщество, или стандарты упаковки данных были слишком "низкими". С Guix я, наконец, почувствовал себя как дома, он отвечал всем требованиям, с ним приятно работать (хотя поначалу он казался странным), и он также отчаянно нуждался в разработчиках.

Я знаю, что некоторые разочарованы тем, что я предпочитаю хобби «обычным» вещам. Что не гонюсь за карьерным ростом, не развиваю свою социальную сеть. Но без Guix я бы до сих пор был бестолковым алкоголиком, валяющимся на диване. Теперь я работаю с Guix дольше, чем на какой-либо другой работе, и наконец-то чувствую некоторую стабильность в жизни. Чувствую желание изучить другие творческие направления, такие как ведение блога, кулинарию, ведение здорового образа жизни (скалолазание и катание на лыжах).

Все это было бы невозможно без Guix и поддержки (иногда неохотной) моих замечательных друзей и семьи. 

Взлом с помощью Guix

Одна из моих любимых функций Guix — guix shell. Это один из тех инструментов, без которых сложно обойтись. Даже если вы не готовы использовать Guix в качестве пакетного менеджера (или дистрибутива), guix shell сам по себе может стать причиной для установки Guix.

Почему?

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

Затем вы обнаружите, что для сборки требуется гора зависимостей и что версии, предоставляемые вашей операционной системой, слишком старые или доступны только при совместном использовании PyPI, CPAN и других случайных репозиториев. Даже если ваш обычный менеджер пакетов имеет все доступные зависимости, вам вряд ли захочется устанавливать всё перечисленное.

Запустите guix shell. Если вам повезёт, то проект, который вы хотите взломать, уже доступен в Guix среди других 21000+ пакетов. Затем вы можете просто клонировать репозиторий, перейти к проекту в терминале и запустить:

guix shell --development the-package

Вот и все. Guix загрузит всё необходимое для сборки этого пакета из исходника, для запуска тестов и т. д. также он сделает их доступными только для текущего сеанса оболочки. Затем вы делаете makepytest или что вам нужно, чтобы попробовать этот патч. PYTHONPATH, CPATH, и т. д. — всё настроено и готово к работе.

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

Что делать, если пакет находится не в Guix, а в его зависимостях? Вы можете создавать произвольные среды с помощью:

guix shell package1 package2 packageN

Или объединить:

guix shell -D the-package package1 package2 -D package3

( -D – это сокращение от --development)

Но что, если вы не хотите, чтобы  пакетные менеджеры или сборочные системы засоряли ваши файлы $HOME, крали ваши пароли и стирали ваши данные? Guix shell вас прикроет:

guix shell --container [...]

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

В guix shell скрываются и другие функции, но вышеописанные я использую чаще всего. У меня даже нет доступного на PATH питона, каждый раз, когда мне нужна оболочка, я просто создаю новую, адаптированную к проекту, который я хочу взломать.

Кстати, этот блог с гордостью работает на guix shell -m manifest.scm -- haunt build.

Удачного взлома!


Что ещё интересного есть в блоге Cloud4Y

→ Как открыть сейф с помощью ручки

→ OpenCat — создай своего робокотика

→ Как распечатать цветной механический телевизор на 3D-принтере

→ WD-40: средство, которое может почти всё

→ Nmap — голливудская звезда

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.




Комментарии (3):

  1. pvp
    /#24775664 / +7

    Смею заметить, что "hacking" -- это, в данном контексте, вовсе не "взлом".

  2. fire64
    /#24775704 / +3

    Хм...

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

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

  3. martin74ua
    /#24776144 / +2

    увольте переводчика