Знаете, я только сейчас понял сакральный смысл празднования дней рождения.
Когда тебе 18, говорят:
- Наконец ты вырос, теперь станешь большой, самостоятельный и не будешь сидеть на шее у родителей!
И все радуются.
А когда тебе 35, тебе говорят:
- Ну и что ты здесь нюни развесил? Не унывай, дед, пойдем, хряпнем коньячку, которого мы тебе принесли!
Ты идешь, хряпаешь, и все снова радуются.
Поэтому дни рождения нужны в любом возрасте.
Давненько я ничего не писал, но тут на меня снизошло желание сделать пост. Ну ладно.
Думаю, среди тех, кто недавно перешел на Linux, часто возникает потребность использовать Wine. Я и сам, каюсь, иногда его использую. Сейчас я расскажу, как держать на компьютере его разные версии и разные префиксы просто в одной папке, да еще так, что это все будет очень красиво (наверное) логически организовано.
Необходимое предисловие - возможно, вам следует почитать про каскадно-объединенное монтирование. Его принцип - использование различных файловых систем как слоев в матрешке.
Каждый следующий слой представляет разницу с предыдущим. Таким образом реализуется принцип CopyOnWrite, иными словами, нижний слой может быть ReadOnly, а во второй мы будем записывать разницу. Зачем это нужно - будет понятно по тексту.
Саму установку Wine можно разделить на 3 части - бинарники, префикс (аналог диска C:) и, собственно, ваши приложения. Вот мы и разделим.
Основной принцип таков - разделить все на сжатые squashfs файлы (их будет два, один с Wine, а второй с пустым префиксом) и папку, в которой будут ваши настройки и приложения. Посмотрите, что выйдет. Главный принцип - все манипуляции, кроме установки нужных пакетов, будут от юзера.
Сначала надо скачать нужные бинари Wine. Советую для простоты взять отседова:
https://www.playonlinux.com/wine/binaries/phoenicis/
Распаковывам архив, получаем папку с Wine, в ней должны содержаться стандартные для приложения папки - bin, lib, share, и т.д.
Теперь создадим пустой префикс. Сделаем скрипт (назовем его wine5, он нам еще пригодится):
#!/bin/bash
root=`pwd`
cd ./папка_с_вайном/bin
env WINEPREFIX=$root/test_prefix LD_LIBRARY_PATH=$root/папка_с_вайном ./wine "$*"
Запустим этот скрипт папке с папкой Wine и получим пустой префикс в папке test_prefix:
./wine5 winecfg
Теперь запакуем Wine и пустой префикс в squashfs файлы:
mksquashfs ./папка_с_вайном wine_compressed.sqsh -comp lzo
mksquashfs ./test_frefix clear_prefix.sqsh -comp lzo
Почему lzo? Потому-что жмет почти как zip, а на распаковке дает до 1.5 ГБ/с. Такое сжатие может даже ускорить работу на HDD. Приятный бонус - размер бинарей вайна и префикса сократится в 2-3 раза.
В итоге получим все два файла, которые, в сущности, и есть весь Wine. Теперь надо написать скрипт(можете начинать), который их монтирует и размонтирует.
Для начала надо поставить такие вещи, как squashfuse и unionfs-fuse. Это зависит от вашего пакетного менеджера. Допустим, пакеты вы поставили.
Сначала смонтируем squashfs:
squashfuse wine_compressed.sqsh ./wine_mountpoint
squashfuse clear_prefix.sqsh ./prefix_mount_ro
Потом создадим директории prefix_rw(сюда будут записываться ваши приложения) и prefix_merged(полная версия) и соберем матрешку префикса:
unionfs-fuse -o cow ./prefix_rw=RW:./prefix_mount_ro=RO ./merged
Теперь поправим в вашем скрипте пути, пропишем в WINEPREFIX путь к merged, а папку с вайном заменим на wine_mountpoint.
Все можно пользоваться! Размонтировать это дело можно с помощью fusermount -u (добавьте в свой скрипт или сделайте отдельный, по вкусу), опять же, полностью от юзера.
Кроме того, обратите внимание на пути.
Что это дает?
1. А то, что монтировать unionfs можно сколько угодно раз, единожды примонтировав wine и пустой префикс. Таким образом, можно создавать префиксы - для простоты - пустые установки Windows, которые почти ничего не весят, как контейнеры. Кроме того, слоев в матрешке может быть сколько угодно. Можно упаковать и приложения. Можно даже запаковать целую игру, в rw будут писаться только сохранения и настройки. Так что применение зависит только от вашей фантазии и целей.
2. Значительное сокращение размера.
3. Все это внутри одной папки и не требует софта кроме тонких оберток типа squashfuse и unionfs-fuse, которые во многих дистрибутивах есть по дефолту.
Послесловие или FAQ.
Вопрос: Это все известно и используется в контейнерах и LiveCD, зачем ты это пишешь?
Ответ: Потому-что могу и хочу.
Вопрос: Почему не использовать более современную aufs?
Ответ: Она не умеет в FUSE.
Вопрос: Ничего не понял, нафига мне это красноглазие? Я сижу на Windows и прекрасно себя чувствую.
Ответ: Вот и сидите дальше, что вы здесь забыли?
Может быть, что-то упустил.
Разработчики проекта OpenXRay сообщили о готовности альфа-выпуска порта движка под Linux. Само портирование уже завершено, однако многое ещё не готово и проходит стадию доработки, но уже сейчас движок запускается и работает. Исходные коды можно скомпилировать с помощью CMake и GCC 7. Для работы под Linux используются библиотеки SDL2 и OpenGL. Исходные коды проекта доступны на GitHub.
В рамках проекта OpenXRay происходит развитие движка X-Ray версии 1.6.02, используемого в игре "S.T.A.L.K.E.R.: Зов Припяти". Проект основан после утечки исходных кодов движка и ставит перед собой цель исправления всех оригинальных недочётов и введения новых возможностей как для обычных пользователей, так и для разработчиков модификаций. Разработчики приглашают всех желающих присоединиться к разработке проекта.
Парочку скринов:
От себя хочу отметить, что, к сожалению, код лицензионно не чист и используется с устного разрешения Григоровича, о чем разработчики честно предупреждают.
Ссылки на опеннет и первоисточник:
Гвидо ван Россум (Guido van Rossum) поставил точку в споре, возникшем среди разработчиков языка Python из-за изменений, предложенных Виктором Штиннером (Victor Stinner), работающим в Red Hat и входящим с число ключевых разработчиков Python. Виктор предложил вычистить код Python от упоминания слов "master" и "slave", так как их использование является неполиткорректным и ассоциируется с рабством и неравноправием. Несколько лет назад некоторые открытые проекты уже затронула череда подобных переименований, например, в Drupal термины "master" и "slave" были заменены на "primary" и "replica", а в Django и CouchDB на "leader" и "follower".
Соответствующие патчи приняты в состав выпуска 3.8.
Источник : opennet
По сведениям издания Business Insider, полученным из неофициальных источников, Microsoft и GitHub обсуждают возможность продажи сервиса. Отмечается, что последние годы представители Microsoft и GitHub уже безуспешно общались по вопросам продажи, но несколько недель назад начались более серьёзные переговоры. В качестве ориентировочной стоимости упоминается сумма в 5 миллиардов долларов (в 2015 году GitHub оценивался в 2 миллиарда) и пока не ясно, согласится ли на такую цену Microsoft.
Первые фото микропроцессора:
Думаю, многие неофиты мира GNU/Linux слышали модное нынче словцо - Docker.
Опять же, постараюсь кратко и доходчиво объяснить, что это, с чем его едят и для чего это может быть нужно неспециалисту вроде меня. И да, это не руководство для новичка, ибо их полно.
Для начала немного о контейнерной виртуализации. В ядре Linux есть технология разделения ресурсов под названием cgroups. Она может управлять доступом приложения к ресурсам - памяти, процессору, дискам. Несколько контор и просто неравнодушных ребят собрались и запилили LXC - систему управления контейнерами. Так же как в случае с chroot, это лишь виртуальное окружение - но без ядра. Сама по себе система LXC - мощная вещь, но и того оказалось мало.
Но это все присказка. На основе этого добра ребята из Docker Inc сделали сделали свой продукт.
Только вот сам по себе Docker - это не система виртуализации, как многие считают, а система объектно-ориентированной доставки софта. Т.е. изначально оно ориентированно на то, чтобы "поднять настроенный апач одной строкой в терминале".
А теперь простой пример. Скачаем образ Ubuntu Bionic (это бетка) и запустим его.
username$: sudo docker pull ubuntu:bionic
bionic: Pulling from library/ubuntu
c5cc0d8681c1: Pull complete
25992ae88689: Pull complete
92b293e28b63: Pull complete
5e97fb8c1b1b: Pull complete
e89d6de98e44: Pull complete
Digest: sha256:4decfd6e336e1cf246127151753d2a24a3185b5f667b91b925e8b38e7ea903a0
Status: Downloaded newer image for ubuntu:bionic
Образ выкачался. Проверим.
username$: sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu bionic 02f9d6707661 5 weeks ago 88.3 MB
Ну так как-то. Форматирование текста с консоли тут едет, так что немного не наглядно.
Сказать сразу - образов в репозитории море, но об этом позже.
А теперь самое интересное - стартанем его:
username$: sudo docker run -it --rm --name temp_ubuntu -v /home/user/test1:/home/ ubuntu:bionic /bin/bash
И нас выплюнет в консольку контейнера с этой убунтой.
Отсюда поподробнее: -it - это интерактивный(i) терминал(t), --rm - удалить контейнер после останова, -v - проброс "внутрь" папки с хоста.
Можно что-то протестировать, собрать, а потом тормознуть контейнер через Control-D - и все чисто как в аптеке.
Но вообще, откровенно говоря, Docker нужен не для этого.
Так вот, о чем я - Docker позволяет "упаковать" какой либо сервак со всеми потрахами внутрь готового образа, и переносимость от хоста к хосту будет почти стопроцентная. Можно push-нуть уже готовый образ в репозиторий, и потом его так-же играючи обратно залить.
В результате в репозиториях уже можно найти огромное количество универсальных рецептов.
Но есть и более специализированный вариант - сборка образа с помощью Dockerfile.
Если просто - это такой сценарий, что нужно сделать и что запустить. Есть у меня один, которым я иногда пользуюсь - это Jupyter (сервер с IPython, блекджеком и шлюхами для научных расчетов). Так выглядит Dockerfile:
FROM debian:sid
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && apt-get install -y python3 python3-pip python3-fann2
RUN pip3 install --upgrade pip && pip3 install jupyter sympy numpy scipy matplotlib pandas networkx
EXPOSE 8888
CMD jupyter notebook --allow-root --ip 0.0.0.0 --no-browser --notebook-dir=/home
Что он, чьорт побьери, делает?
Ну Debian Sid - это понятно, надеюсь.
ENV DEBIAN_FRONTEND noninteractive - переменная, чтобы apt не спрашивал да/нет у бездушной машины.
Далее идут команды установки всего и вся через RUN. Да, их следует делать поменьше раз, поэтому команды длинные.
EXPOSE "выпячивает" порт наружу.
Ну и CMD - конечная команда запуска.
Также стоит отметить, что обычно лучше юзать ENTRYPOINT, но это вам гуглить самим.
Теперь собираем образок:
username$: sudo docker build -f /path/to/dockerfile -t name_of_image
Этот образ можно переносить с машины на машину, а можно просто отправить dockerfile через вконтактик))
Еще какие бонусы?
Так как Docker использует OverlayFS (ранее был aufs) - а это про copy-on-write - он не создает контейнеры с нуля, а только послойно записывает разницу между контейнером и изначальным образом. Так что таких контейнеров можно поднять с десяток при сравнительно небольших накладных затратах.
В общем, писать про это можно очень много и долго, но надобности за обилием написанных мануалов нет. Если интересно - просто попробуйте.
