Русский
Русский
English
Статистика
Реклама

*nix

Перевод Заметки о Unix два сценария работы с конвейерами

13.01.2021 12:17:24 | Автор: admin
Мне встречалось множество рекомендаций о повышении безопасности использования shell-скриптов в Bash путём включения опции pipefail (например это рекомендуется в данном материале 2015 года). Это, с одной стороны, хорошая рекомендация. Но включение pipefail может привести к конфликту. В одном из двух сценариев использования конвейеров эта опция показывает себя замечательно, а вот в другом то, к чему приводит её включение, выглядит просто ужасно.



Для того чтобы понять суть этой проблемы давайте сначала разберёмся с тем, за что именно отвечает опция Bash pipefail. Обратимся к документации:

Статусом выхода из конвейера, в том случае, если не включена опция pipefail, служит статус завершения последней команды конвейера. Если опция pipefail включена статус выхода из конвейера является значением последней (самой правой) команды, завершённой с ненулевым статусом, или ноль если работа всех команд завершена успешно.

Причина использования pipefail заключается в том, что иначе команда, неожиданно завершившаяся с ошибкой и находящаяся где-нибудь в середине конвейера, обычно остаётся незамеченной. Она, если использовалась опция set -e, не приведёт к аварийному завершению скрипта. Можно пойти другим путём и тщательно проверять всё с использованием $PIPESTATUS, но это означает необходимость выполнения больших объёмов дополнительной работы.

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

generate --thing | sed 1000q | gronkulate

Команда sed, после получения 1000 строк, завершит работу и закроет конвейер, в который пишет данные generate. А generate получит сигнал SIGPIPE и, по умолчанию, остановится. Статус выхода команды будет отличаться от нуля, а это значит, что с использованием pipefail работа всего конвейера завершится с ошибкой (а с использованием set -e скрипт нормально завершит работу).

(В некоторых случаях то, что происходит, может, от запуска к запуску, меняться. Причина этого в системе планирования выполнения процессов. Это может зависеть и от того, какой объём данных производят процессы, находящиеся ближе к началу конвейера, и как он соотносится с тем, что фильтруют процессы, расположенные ближе к концу конвейера. Так, если в нашем примере generate создаст 1000 строк или меньше sed примет все эти данные.)

Это ведёт к двум шаблонам использования конвейеров командной оболочки. При использовании первого конвейер потребляет все входные данные, действуя так в тех случаях, если всё работает без сбоев. Так как подобным образом работают все процессы ни у одного процесса никогда не должно возникнуть необходимости выполнять запись в закрытый конвейер. А значит никогда не появится и сигнал SIGPIPE. Второй шаблон использования конвейеров предусматривает ситуацию, когда хотя бы один процесс завершает обработку входных данных раньше, чем обычно. Часто подобные процессы специально помещают в конвейер для остановки обработки данных в определённый момент (как sed в вышеприведённом примере). Подобные конвейеры иногда или даже всегда генерируют сигналы SIGPIPE, некоторые процессы в них завершаются с ненулевым кодом.

Конечно, пользоваться подобными конвейерами можно и в окружении, где применяется pipefail, и даже с set -e. Например, можно сделать так, чтобы один из шагов конвейера всегда сообщал бы об успешном завершении:

(generate --thing || true) | sed 1000q | gronkulate

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

(Кроме того, очень хорошо было бы игнорировать только ошибки, связанные с SIGPIPE, но не другие ошибки. Если generate завершится с ошибкой по причинам, не связанным с SIGPIPE, то нам хотелось бы, чтобы весь конвейер выглядел бы так, как если бы он завершился с ошибкой.)

Чутьё подсказывает мне, что шаблон использования конвейеров, основанный на полном потреблении всех входных данных, распространён гораздо сильнее, чем шаблон, когда работа конвейера завершается раньше, чем обычно. Правда, я не пытался оценить свои скрипты на предмет особенностей использования в них конвейеров. Это, определённо, совершенно естественный шаблон использования конвейеров, когда в них выполняется фильтрация, трансформация или исследование всех сущностей из некоего набора (например для того чтобы их посчитать или вывести некие сводные данные по ним).

Подробнее..

Перевод Заметки о Unix система управления заданиями и использование SIGCHLD в (BSD) Unix

22.01.2021 12:16:53 | Автор: admin
Недавно мы опубликовали перевод статьи о конвейерах в Unix, у автора которой есть ещё немало подобных материалов. В той публикации мы устроили опрос о целесообразности перевода других статей того же автора. Большинство принявших участие в опросе эту идею поддержало. Поэтому сегодня мы предлагаем вашему вниманию перевод ещё одного материала о Unix, который посвящён SIGCHLD.



В современных версиях Unix сигнал SIGCHLD отправляется процессу в том случае, если один из его дочерних процессов завершается, а так же при других изменениях состояния дочернего процесса. Перехват SIGCHLD позволяет реализовать удобный способ выяснения момента завершения работы дочерних процессов в то время когда программа занимается другими делами, а его игнорирование приводит к исчезновению этих процессов, а не к превращению их в процессы-зомби. Несмотря на все эти полезности SIGCHLD отсутствовал в V7 Unix. Он был добавлен в 4.2 BSD, и, независимо, в System III (как SIGCLD).

В V7 программы, вроде командной оболочки, обладали достаточно простой системой обработки завершения работы дочерних процессов. Всё это обычно работало в синхронном режиме. Когда эти программы что-то запускали (или когда запускался встроенный механизм оболочки wait), они вызывали wait() до тех пор, пока либо не возвращался код ошибки, либо не возвращался ID процесса, появления которого они ожидали. Если нужно было это прервать, использовалось сочетание клавиш ^C, а обработчик сигнала SIGINT оболочки делал всё что нужно. В V7 этого было достаточно, так как оболочке V7, на самом деле, не нужно было знать об изменениях состояния дочерних процессов, за исключением тех случаев, когда эти сведения запрашивал у неё программист.

Когда в BSD появилась система управления заданиями (job control), там это тоже было реализовано, в результате фоновые задания, которые пытались писать в терминал или читать из него, могли быть автоматически приостановлены. Это нужно в том случае, когда задания могут менять состояние, становясь то фоновыми задачами, то задачами переднего плана. Программу можно запустить в виде задачи переднего плана, а потом, если на её работу нужно слишком много времени, перевести её в фоновый режим. Когда же она готова будет вывести результаты своей деятельности, её снова можно сделать задачей переднего плана. Но реализация подобных возможностей означает, что оболочка, поддерживающая систему управления заданиями, теперь нуждается в сведениях об изменениях состояния процессов, поступающих к ней в асинхронном режиме. Если оболочка ожидает от вас ввода очередной команды (то есть читает данные из самого терминала и заблокирована в read()), а фоновая программа приостановлена после попытки доступа к терминалу, то вам, вероятно, хотелось бы, чтобы оболочка тут же вам об этом сообщила, не дожидаясь того момента, пока вы что-то введёте в терминал. Для того чтобы получать немедленные уведомления о событиях такого рода, нужен сигнал, который отправляется родительскому процессу тогда, когда меняется состояние дочернего процесса, в том числе тогда, когда он приостанавливается вышеописанным образом. Это сигнал SIGCHLD.

Если в общих чертах описать SIGCHLD, то можно сказать, что этот сигнал позволяет программам реагировать на завершение работы дочерних процессов даже в ситуациях, когда эти программы заняты другими делами. Это, в целом, полезная возможность. Видимо, именно поэтому в System III добавили собственную версию этого сигнала, несмотря даже на отсутствие там системы управления заданиями.

(Командные оболочки, использующие системы управления заданиями, не обязаны немедленно реагировать на изменение состояния дочерних процессов. И некоторые из них работают именно так. Поведение оболочки может даже зависеть от её настроек, что вполне разумно, так как некоторым пользователям не понравилось бы, если бы их отвлекали бы сообщения оболочки в те моменты, когда они вводят команды или размышляют. Такие пользователи предпочли бы просто нажать на клавишу Return в тот момент, когда им нужно взглянуть на подобные сообщения.)

P.S. В 4.2 BSD, кроме того, появился вызов wait3(). Он, что произошло впервые, позволил процессам проверять состояние дочерних процессов без блокировки. Это механизм, который можно использовать в командной оболочке в том случае, если нужно лишь проверить состояние завершённых и приостановленных процессов непосредственно перед продолжением работы.

Пользуетесь ли вы сигналом SIGCHLD?

Подробнее..

FOSS News 49 дайджест материалов о свободном и открытом ПО за 28 декабря 2020 года 3 января 2021 года

03.01.2021 18:23:42 | Автор: admin


Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. 20 лет проекту Sisyphus; компания Mozilla работает над новым оформлением Firefox; оценка предпочтений пользователей Linux в выборе оборудования; 5 вещей, которые мы выучили за 2020 год по версии opensource.com, и многое другое.


P.S.: В ближайшие дни также будет спецвыпуск FOSS News с итогами прошедшего года.


Оглавление


  1. Главное
    1. 20 лет проекту Sisyphus
    2. Компания Mozilla работает над новым оформлением Firefox
    3. Оценка предпочтений пользователей Linux в выборе оборудования
    4. 5 вещей, которые мы выучили за 2020 год по версии opensource.com
  2. Короткой строкой
    1. Новости
      1. Открытие кода и данных
      2. Новости FOSS организаций
      3. Ядро и дистрибутивы
      4. Системное
      5. Web
      6. Пользовательское
    2. Статьи
      1. DIY
      2. Ядро и дистрибутивы
      3. Системное
      4. Специальное
      5. Базы данных
      6. Мобильные
      7. DevOps
      8. AI & Data Science
      9. Web
      10. Для разработчиков
      11. Пользовательское
      12. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Обучение
      5. Мультимедиа
      6. Web
      7. Для разработчиков
      8. Игры
      9. Разное
  3. Что ещё посмотреть
  4. Заключение

Главное


20 лет проекту Sisyphus


Категория: Новости/Новости FOSS организаций




OpenNET пишет: Непрерывно обновляемому репозиторию свободных программ Sisyphus, используемому для формирования дистрибутивов ALT, исполнилось 20 лет. За прошедшие два десятилетия работа над сизифом привела к существенной доработке базовых rpm и apt-rpm, созданию оригинальной сборочной инфраструктуры (hasher, gear, girar), выработке подходов к формированию стабильных репозиториев и подготовке выпусков на их (и сизифа!) основе. В настоящее время в репозитории присутствует около 18 тыс. пакетов, поддержкой которых занимается более 250 участников проекта. Многие люди пришли принять участие в команде; многие из них уже покинули её по тем или иным причинам, но всё-таки оставили свой след в этом живом памятнике трудам русских хакеров. А когда вдруг понадобились отечественные продукты как минимум один из них уже был готов и способен идти дальше самостоятельно.


Подробности []

Компания Mozilla работает над новым оформлением Firefox


Категория: Новости/Web




OpenNET пишет: Компания Mozilla приступила к работе по модернизации интерфейса Firefox. Обновлённое оформление развивается в рамках проекта Proton и охватывает внешний вид таких элементов, как адресная строка, диалоги, панель вкладок, основное и контекстные меню. Новый интерфейс планируется реализовать в выпуске Firefox 89, намеченном на 18 мая. Из находящихся в разработке изменений выделяется новое оформление вкладок и всплывающих подсказок, в которых начнут показываться эскизы сайтов и отформатированный текст. Наборы вкладок (контейнеры) будут сгруппированы и представлены на панели в виде отдельного виджета, выглядящего как одна вкладка. Изменится наименование элементов меню заглавные буквы будут оставлены только для первого слова (например, вместо Other Bookmarks будет Other bookmarks). Кроме того, как минимум, появится компактный режим и будут переработаны модальные диалоги с предупреждениями, подтверждениями и запросами.


Подробности []

Оценка предпочтений пользователей Linux в выборе оборудования


Категория: Новости/Железо




OpenNET пишет: Проект Linux-Hardware.org проанализировал какое оборудование выбирали пользователи Linux в 2020 году и как изменились их предпочтения за прошедший год. Отчёт основан на пробах оборудования 47 тысяч компьютеров, отправленных Linux-пользователями в 2020 году. Подробности и отчёты по конкретным дистрибутивам Linux доступны в GitHub-репозитории.


Основные выводы:


  1. Доля пользователей i686 резко сократилась.
  2. Доля пользователей ПК продолжает падать. Доля пользователей ноутбуков продолжает расти.
  3. Только 30% респондентов обновили оборудование в 2020 году. Половина из них купили новое оборудование, а остальные прошлогоднее оборудование произведенное в 2019 году.
  4. Доля компьютеров с включенным SecureBoot продолжает медленно расти.
  5. Доля компьютеров без CD-ROM впервые превысила количество компьютеров с CD-ROM. Компакт-диски уходят в прошлое.
  6. Доля компьютеров только с WiFi (без порта Ethernet) продолжает расти.
  7. ASUSTek сдаёт позиции в пользу HP, Lenovo, Dell, Acer и MSI. Gigabyte стагнирует.
  8. Доля моделей ThinkPad и IdeaPad от Lenovo и Latitude от Dell продолжает расти.
  9. Доля SSD и NVMe по итогам года обогнала HDD.
  10. Самый популярный HDD Seagate показывает медленный рост, остальные стагнируют.
  11. Самый популярный SSD Samsung показывает медленный рост. Crucial и WDC демонстрируют относительно быстрый рост.
  12. Доля мониторов Full HD в этом году резко увеличилась и сейчас занимает половину от общего количества мониторов. Доля 4K-мониторов тоже продолжает расти.
  13. Доля видеокарт Intel и AMD продолжает медленно расти. Доля пользователей NVIDIA продолжает медленно падать.
  14. Доля процессоров AMD начала расти. Доля процессоров Intel начала падать.
  15. Доля WiFi чипов от Intel быстро растет, остальные стагнируют.
  16. Чипы Realtek Ethernet сдают позиции в пользу Intel.
  17. Доля Bluetooth чипов от Intel продолжает быстро расти, остальные стагнируют.

Подробности []

5 вещей, которые мы выучили за 2020 год по версии opensource.com


Категория: Статьи/Разное




Джен Уайк Хугер из Red Hat побеседовал с несколькими представителями Open Source сообщества и вот какие есть взгляды на прошедший год:


  1. Спрос на облачные технологии, оборудование и решения с открытым исходным кодом для удаленной работы рос с астрономической скоростью.
  2. Мы все почувствовали боль, которую опытные удалённые сотрудники испытывали годами, и мы нашли способы справляться.
  3. Несмотря на отсутствие тесного контакта, такие инструменты, как Google Meet, Jitsi и Zoom, позволяют нам поддерживать связь с помощью эффективных и гибких способов.
  4. Развитие программных технологий превосходит самые смелые мечты сторонников подхода точно в срок.
  5. Это был трудный год для всех нас, но есть и светлая сторона. Я видел своих друзей и семью чаще в 2020 году, чем в прошлые годы.

Подробности [(en)]


Короткой строкой


Новости


Открытие кода и данных


  1. Представлена открытая плата управления ракетой Cygnus-X1 []
  2. Microsoft опубликовал заголовочные файлы DirectX под лицензией MIT []

Новости FOSS организаций


  1. LibreOffice удалил интеграцию с VLC и остается с GStreamer []
  2. Джои Хесс бросает поддерживать github-backup []
  3. Нарушена работа поиска пакетов по Python-репозиторию PIP []
  4. Еженедельник OSM 544 []
  5. В преддверии праздника участники KDE подводят итоги прошедшего года. Что запомнилось им больше всего? []

Ядро и дистрибутивы


Работа DNF/RPM в Fedora 34 будет ускорена []

Системное


  1. Прозрачное сжатие Btrfs при помощи Zstd по умолчанию в Fedora 34 []
  2. Из Mesa удалён драйвер программной отрисовки swrast []

Web


TabFS FUSE-модуль с файловой системой для работы со вкладками браузера []

Пользовательское


  1. На этой неделе в KDE: все дела! []
  2. На этой неделе в KDE: kio-fuse и NeoChat []

Статьи


DIY


Безумный дом []

Ядро и дистрибутивы


  1. Установка Kodachi Linux []
  2. Легкие дистрибутивы Linux для Intel Atom []

Системное


  1. Western Digital разработала новую файловую систему для Linux-систем []
  2. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0 []
  3. Systemd для продолжающих. Part 1 Запуск юнитов по временным событиям []

Специальное


Об исследовании космоса с помощью KStars[(en)]


Базы данных


  1. Заряжай Patroni. Тестируем Patroni + Zookeeper кластер (Часть вторая) []
  2. Мониторинг Tarantool: логи, метрики и их обработка []
  3. Аварии как опыт #1. Как сломать два кластера ClickHouse, не уточнив один нюанс []

Мобильные


Let's Encrypt решил проблему с продолжением работы сертификатов на старых Android-устройствах []

DevOps


  1. Практический взгляд на хранение в Kafka []
  2. Выводы Grofers после двух лет Kubernetes в production []
  3. Go-приложение с бессерверной архитектурой на Kubernetes с Knative []
  4. Как подключиться к контейнеру Docker []
  5. Написание Dockerfile. Лучшие практики []
  6. Ускоряем CI/CD-пайплайн с помощью Kubernetes в Docker (KinD) []
  7. 4 соображения для того чтобы начать внедрять CI/CD в 2021 [(en)]

AI & Data Science


DVC vs GIT. Почему GIT'а недостаточно в проектах машинного обучения []

Web


Rocket.Chat: отличная Open Source альтернатива для Slack [(en)]


Для разработчиков


  1. Практика программирования на C++ через написание простой игры [(en)]
  2. Изучение Python через написание простой игры [(en)]
  3. Топ 10 ошибок в проектах Java за 2020 год []
  4. Простое и удобное журналирование ошибок для сайтов на .NET Core []
  5. Отображение прогресса в Python приложениях с tqdm [(en)]
  6. Бранч-стратегии при разработке в Git []
  7. Карантин для динамической памяти ядра Linux []
  8. 10 примеров использования Python в 2020 [(en)]
  9. Изучение Lua через написание игры угадай число [(en)]
  10. Создание собственного текстого редактора на Java [(en)]
  11. 10 вещей за которые стоит любить Git [(en)]
  12. Решение типичной проблемы организации поставок с помощью языка программирования Julia [(en)]

Пользовательское


  1. О записи своих идей с помощью текстового редактора KJots[(en)]
  2. Как использовать текстовый редактор JOE в Linux [(en)]
  3. Что такое LTS []
  4. Как вернуть старый MacBook к жизни с помощьюLinux [(en)]
  5. Об опыте использования текстового редактора Pe [(en)]
  6. Об использовании редактора Markdown в Nextcloud [(en)]

Разное


  1. 9 инсайтов от переключения на удалённую работу в 2020 [(en)]
  2. Исполняемые PNG: запускаем изображения как программы []

Релизы


Ядро и дистрибутивы


  1. Redox OS 0.6.0 []
  2. Выпуск дистрибутива Deepin 20.1, развивающего собственное графическое окружение []
  3. Embox v0.5.1 Released []
  4. Выпуск дистрибутива Slackel 7.4 []

Системное


Новая версия утилит для работы со SMART-информацией Smartmontools 7.2 []

Специальное


  1. Stellarium 0.20.4 []
  2. lsFusion 4 []
  3. Релиз минималистичного набора системных утилит BusyBox 1.33 []
  4. Виртуальный планетарий Stellarium 0.20.4. Что нового []

Обучение


Выпуск программы для детского рисования Tux Paint 0.9.25 []

Мультимедиа


  1. Второй предварительный выпуск графического редактора GIMP 3.0 []
  2. Darktable 3.4.0. Большое обновление программы для работы с фотографиями []
  3. Релиз медиа-проигрывателя Parole 4.15.0. Новый плейлист, улучшена поддержка DVD []
  4. mtpaint 3.50 []

Web


  1. Выпуск http-сервера Lighttpd 1.4.58 []
  2. Выпуск web-браузера Otter 1.0.2 с интерфейсом в стиле Opera 12 []
  3. Выпуск GNU Wget 1.21 []

Для разработчиков


  1. Ruby 3.0.0 []
  2. Cosmopolitan стандартная Си-библиотека и формат кроссплатформенных исполняемых файлов []
  3. RESTinio-0.6.13: последний большой релиз RESTinio в 2020 и, вероятно, последний в ветке 0.6 []
  4. Выпуск распределенной системы управления исходными текстами Git 2.30 [ 1, 2]
  5. CIDER 1.0 []
  6. Что есть что в CMake 3.10+ и как это использовать []
  7. Выпуск библиотеки GNU libmicrohttpd 0.9.72 []
  8. Выпуск языка программирования Rust 1.49 [ 1, 2, 3]

Игры


Игра Bubble Chains перевыпущена (ретро пазл-аркада) []

Разное


Buttplug 1.0 []

Что ещё посмотреть


Видео: IT новости #33 Xfce 4.16 что нового. Приставка на Ubuntu. Darktable, Kdenlive, Q4OS []

Заключение


На этом всё, до следующего воскресенья!


Высказываю большое спасибо редакции и авторам OpenNET [], много новостных материалов и сообщений о новых релизах взято у них.


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


Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.


[] Предыдущий выпуск

Подробнее..

Спецвыпуск FOSS News 50 главное за 2020 год

09.01.2021 08:12:32 | Автор: admin

Всех с наступившим!


Новогодняя суета (почти) прошла, самое время подвести итоги года в поле FOSS новостей и других материалов, вышедших за нелёгкий 2020 год.


Кратко:


  1. Сообщества свободных и открытых проектов приняли активное участие в противодействии COVID-19 и пострадали от них тоже как многие другие. Показательно, что принципы, на которых строились международные FOSS сообщества, оказались очень полезны во время пандемии. Ну и навыками удалённой работы смогли поделиться.
  2. В России набирают обороты внедрения отечественных GNU/Linux дистрибутивов. Силовики, РЖД, атомщики, администрации первые в этом деле. Технологии использованы, пингвинов стало больше. Приняты ли принципы FOSS? Вопрос открытый.
  3. В мире местами продолжаются попытки массового внедрения GNU/Linux для десктопов, ну а в прочих приложениях он понятно повсеместен. Прочий FOSS софт тоже весьма популярен. Сложно говорить о динамике, метрик недостаточно. Но многие эксперты говорят о всё большей важности открытых технологии и, более того, об их фундаментальном значении.
  4. Взаимоотношения FOSS и бизнеса сложно назвать благополучными. Всё больше сообществ жалуются на односторонний характер партнёрства и пытаются найти выход из этой ситуации.
  5. Было много примеров открытия кода и данных.
  6. Открытых железных проектов было немало, ещё больше проектов с предустановленным GNU/Linux.
  7. Удалось собрать немаленькую подборку материалов как для начинающих так и для опытных FOSS разработчиков собственно о самом подходе к разработке софта и о связанных с этим вещах.
  8. Ещё есть несколько подборок альтернатив проприетарного софта, в том числе аналогов Zoom и Slack, особо актуальных в последнее время.
  9. Две отдельные категории лучшая серия статей и (не)холивар года. Не пропустите, там интересно ;)
  10. Разные важные материалы, не попавшие в категории выше.

Под катом приведены полные списки материалов по каждой категории.


Оглавление


  1. Противостояние c COVID-19
  2. Импортозамещение ПО в России
  3. Значимые внедрения FOSS в мире
  4. FOSS и бизнес
  5. Открытие кода и данных
  6. Открытое железо и железо с предустановленным GNU/Linux
  7. Для FOSS разработчиков
  8. Внутренние дела FOSS проектов
  9. Альтернативы
  10. Лучшая серия статей
  11. (Не)холивар года
  12. Разное
  13. Заключение

Противостояние c COVID-19


  1. 10.03.2020 Методы Open Source сообщества для противодействия COVID-19 [ 1(en), 2(en)]
  2. 09.03.2020 Отменённые или перенесённые в онлайн из-за COVID-19 GNU/Linux и Open Source конференции [(en)]
  3. 19.03.2020 Советы разработчиков Linux об удалённой работе [ 1(en), 2(en)]
  4. 17.03.2020 Как Open Source ПО помогает в борьбе с COVID-19 [(en)]
  5. 19.03.2020 Open Source проект аппарата ИВЛ был сделан за одну неделю [ 1(en), 2(en)]
  6. 25.03.2020 Open Source против COVID-19: как разработчики могут помочь в борьбе с вирусом [(en)]
  7. 25.03.2020 SUSE предлагает помощь в борьбе с COVID-19 [(en)]
  8. 26.03.2020 Open Source разработки аппарата ИВЛ [ 1(en), 2(en), 3(en)]
  9. 30.03.2020 Линус Торвальдс рекомендует ставить здоровье выше необходимости релизов [(en)]
  10. 31.03.2020 Mozilla запускает фонд по борьбе с COVID-19 [(en)]
  11. 05.04.2020 Разработчики отвечают на угрозу COVID-19 Open Source проектами и хакатонами []
  12. 09.04.2020 Open Source ИИ для помощи в идентификации коронавируса [(en)]
  13. 13-19.04.2020 Сводки с полей FOSS борьбы с коронавирусом []
  14. 20-26.04.2020 Сводки с полей FOSS борьбы с коронавирусом []
  15. 27.04-03.05.2020 Сводки с полей FOSS борьбы с коронавирусом []
  16. 4-10.05.2020 Сводки с полей FOSS борьбы с коронавирусом []
  17. 15.05.2020 Внезапно на удалёнке: чему Open Source сообщество может научить? [(en)]
  18. 25.09.2020 Rosetta@home: Помощь в борьбе против COVID-19 с помощью вашей Linux системы [(en)]

Импортозамещение ПО в России


  1. 17.01.2020 Российский Alt Linux установили на 12 тыс. ПК в школах и вузах России примерно в 600 российских школах, вузах, профучилищах и учреждения допобразования []
  2. 21.01.2020 РЖД готовятся закупить тысячи ПК с Windows и российским дистрибутивом Linux (3820 компьютеров на 392,9 млн руб.) []
  3. 24.01.2020 МВД провело крупнейшую закупку ОС Astra Linux (31 000 лицензий на 1,4 млрд руб) []
  4. 25.05.2020 Об отношениях реестра отечественного ПО и свободного ПО [ 1, 2]
  5. 11.06.2020 Свободное или отечественное ПО. Стандартное или свободное обучение []
  6. 25.06.2020 В ядро Linux добавлена поддержка российских процессоров Baikal T1 []
  7. 30.06.2020 США запретили продавать Windows и iPhone российским военным и полиции []
  8. 05.08.2020 TAdviser протестировал операционную систему Astra Linux. Экспертный обзор продукта []
  9. 11.08.2020 Большая поставка Эльбрусов и Байкалов с Альтами в РЖД []
  10. 09.09.2020 Группа компаний Astra Linux намерена инвестировать 3 млрд руб. в экосистему Linux []
  11. 05.11.2020 MTC введёт в строй облачную инфраструктуру на базе Ubuntu и OpenStack []
  12. 02.11.2020 Росатом потратит 820 млн руб. на внедрение Astra Linux []
  13. 12.11.2020 Госорганы России начали переход на Astra Linux []
  14. 22.12.2020 Ростелеком переводит свои серверы на российский GNU/Linux дистрибутив Ред ОС []

Значимые внедрения FOSS в мире


  1. 01.02.2020 CERN перешёл с Facebook Workplace на открытые платформы Mattermost и Discourse []
  2. 10.02.2020 Правительство Южной Кореи исследует вопрос перехода с Windows на GNU/Linux [(en)]
  3. 24.02.2020 Еврокомиссия выбрала свободный мессенджер Signal из соображений безопасности [ 1(en), 2(en)]
  4. 25.03.2020 Китай готовится заменить Windows на GNU/Linux [(en)]
  5. 31.03.2020 IEEE запускает платформу совместной работы [(en)]
  6. 01.04.2020 Технологические гиганты объединяют усилия для запуска инструмента управления 5G инфраструктурой с открытым исходным кодом [ 1(en), 2(en)]
  7. 04.04.2020 Завоюют ли Open Source решения рынок беспилотников? [(en)]
  8. 15.05.2020 Мюнхен отказывается от Microsoft и переходит на Open Source. Снова [ 1, 2(en)]
  9. 19.05.2020 Парламент ЕС настоятельно рекомендует разрабатывать и использовать программное обеспечение с открытым исходным кодом [(en)]
  10. 03.06.2020 SpaceX использует Linux и обычные x86-процессоры в Falcon 9 []
  11. 07.06.2020 В Мюнхене и Гамбурге согласован перевод госучреждений с продуктов Microsoft на открытое ПО []
  12. 25.07.2020 Как Европа переходит на открытое ПО для госучреждений []
  13. 31.08.2020 Как правительство одного муниципалитета в Турции переехало на Open Source [(en)]
  14. 03.10.2020 Рочестерский технологический институт создал Open@RIT, университетскую инициативу поддержки, сотрудничества и исследований проектов с открытым исходным кодом [(en)]
  15. 21.11.2020 Переведут ли госсофт на open source технологии возможности для развития этого тренда в США []

FOSS и бизнес


  1. 04.02.2020 Ведущий японский hardware вендор подключается к Open Invention Network [(en)]
  2. 06.02.2020 В чём венчурный капитал видит привлекательность Open Source [ 1(en), 2(en)]
  3. 04.02.2020 CTO IBM Watson заявил о критической необходимости Open Source для динамически растущей области периферийных вычислений [(en)]
  4. 20.02.2020 Исследование RedHat: Open Source вытесняет проприетарное ПО из корпоративного сегмента []
  5. 18.02.2020 О сложных отношениях между Amazon и Open Source [(en)]
  6. 17.02.2020 Какую роль Open Source играет в формировании 5G [(en)]
  7. 19.02.2020 Как Kubernetes стал стандартом в сфере построения вычислительных ресурсов [(en)]
  8. 03.03.2020 3 причины почему системные интеграторы должны использовать Open Source системы [(en)]
  9. 03.03.2020 Проект Zephyr от Linux Foundation открывая новые горизонты в мире IoT [(en)]
  10. 27.03.2020 InnerSource: Как лучшие практики Open Source помогают корпоративным командам разработки [(en)]
  11. 15.04.2020 4 больших инновации, которым мы обязаны Open Source [(en)]
  12. 22.04.2020 Главные барьеры и преимущества для малого бизнеса, использующего Open Source [(en)]
  13. 15.05.2020 Как избежать ошибок выбора лицензии при работе с Open Source и подобным софтом? [(en)]
  14. 12.05.2020 Open Source модели ведения бизнеса на основе подписки станут более популярными по мнению Red Hat [(en)]
  15. 18.05.2020 Microsoft переходит на светлую сторону силы или бойтесь данайцев, дары приносящих? В Microsoft признали, что были неправы относительно open source []
  16. 26.05.2020 Бывший руководитель Windows подразделения: почему Microsoft вела войну с Open Source? [(en)]
  17. 15.07.2020 Больше не user friendly: как интернет-монополии убивают конкуренцию и превращают пользователей в товар []
  18. 08.09.2020 Аналитический материал TODO Group: почему Open Source важен для вашей компании [(en)]
  19. 24.09.2020 Как программное обеспечение с открытым исходным кодом изменило деловой мир? [(en)]
  20. 07.10.2020 Телеком отрасль: от чёрных ящиков к открытому коду [(en)]
  21. 09.10.2020 Open Source вносит определяющий вклад в развитие всего связанного с программным обеспечением [(en)]
  22. 23.10.2020 Почему важно чтобы облачные технологии были открытыми [(en)]

Открытие кода и данных


  1. 22.01.2020 Открыт исходный код приложений ProtonVPN []
  2. 07.02.2020 Открыт исходный код платформы контроля за промышленным интернетом вещей [(en)]
  3. 10.02.2020 Facebook выпускает Open Source библиотеку для 3D глубокого обучения PyTorch3D [(en)]
  4. 13.02.2020 IVPN открывает исходники клиентских приложений [(en)]
  5. 26.02.2020 Смитсоновский институт перевёл 2.8 миллионов изображений в общественное достояние []
  6. 17.03.2020 Uber открывает код Piranha, инструмента автоматического удаления устаревшего кода [(en)]
  7. 20.03.2020 RBK.money выпустила первый в мире open-source платежный процессинг []
  8. 20.03.2020 ING открывает Lion, библиотеку производительных, доступных и гибких веб-компонентов []
  9. 25.03.2020 Megvii открывает китайскую ИИ платформу [(en)]
  10. 30.03.2020 Huawei открывает ИИ фреймворк MindSpore [(en)]
  11. 11.04.2020 Google опубликовал данные и модель машинного обучения для разделения звуков []
  12. 10.04.2020 Пакет для Windows контейнеризации Sandboxie переведён в разряд свободного ПО и передан сообществу []
  13. 21.05.2020 Electronic Arts откроет код новой редакции игр Command & Conquer: Tiberian Dawn и Red Alert []
  14. 08.12.2020 Google делает Fuchsia более открытой, позволив участвовать в разработке не только сотрудникам но и сообществу []

Открытое железо и железо с предустановленным GNU/Linux


  1. 22.01.2020 Kubuntu начинает распространение ноутбука Kubuntu Focus []
  2. 05.02.2020 Dell анонсировал новую версию топового ультрабука на Ubuntu [(en)]
  3. 19.03.2020 Purism Librem Mini: основанный на Linux Mini PC с особым вниманием к приватности [(en)]
  4. 19.03.2020 Pinebook Pro, ноутбук за 199$, получил обновлённую версию с Manjaro KDE на борту [ 1, 2(en)]
  5. 25.03.2020 System76 выпускает новый ноутбук Lemur Pro [(en)]
  6. 02.04.2020 5G Linux смартфон в форм-факторе миниатюрного ноутбука собрал средства через краудфандинг []
  7. 02.04.2020 Доступен для заказа смартфон PinePhone, поставляемый с UBports []
  8. 27.04.2020 Lenovo переведет три флагманских ноутбука на Linux []
  9. 07.05.2020 Дегуглифицированный смартфон от Fairphone с /e/OS доступен к заказу [(en)]
  10. 24.05.2020 TUXEDO Computers представила первый в мире AMD-ноутбук с предустановленной ОС Linux []
  11. 07.06.2020 Lenovo обеспечит поставку Ubuntu и RHEL на всех моделях ThinkStation и ThinkPad P []
  12. 10.06.2020 Доступен для заказа планшет PineTab, поставляемый с Ubuntu Touch []
  13. 26.06.2020 Начались продажи сверхмощного ноутбука System76 Oryx Pro на Linux Ubuntu []
  14. 23.06.2020 Представлен ноутбук Dell XPS 13 Developer Edition с предустановленным Ubuntu 20.04 []
  15. 16.07.2020 Для недорогого ноутбука Star Lite Mk III доступны на выбор шесть дистрибутивов Linux []
  16. 22.07.2020 Проект KDE представил третье поколение ноутбуков KDE Slimbook []
  17. 21.07.2020 В ноутбуке Tuxedo Pulse 15 соседствуют чип AMD Ryzen и ОС Linux []
  18. 27.08.2020 Инженеры Intel создали открытый проект робота на базе смартфона []
  19. 05.11.2020 Open Book: проект по сборке свободного eReader с паяльником в руках []
  20. 16.11.2020 Представлен cмартфон PinePhone с KDE Plasma Mobile, который можно использовать как десктоп []
  21. 19.11.2020 Смартфон Librem 5 перешёл на стадию массового производства []
  22. 20.11.2020 Кампания по сбору средств для производства Pro1 X, смартфона с выдвижной клавиатурой, совместимого с Ubuntu Touch и Android []
  23. 23.11.2020 DevTerm портативный open-source компьютер с модульным дизайном в стиле ретро и с кучей возможностей []

Для FOSS разработчиков


  1. 23.01.2020 Keep calm and make FOSS (о тяжести бремени бескорыстной поддержки проектов) []
  2. 19.02.2020 Инструкция по запуску проекта с открытым исходником []
  3. 19.02.2020 Коммерциализация доработок свободного ПО []
  4. 24.02.2020 FOSS лицензии: какую выбрать и почему [(en)]
  5. 27.02.2020 Каково это, вести 100% Open Source бизнес? [(en)]
  6. 01.03.2020 Наиболее частые проблемы с безопасностью при работе с FOSS [(en)]
  7. 25.02.2020 Фонд СПО планирует запустить новую платформу совместной разработки и хостинга кода []
  8. 12.03.2020 Open Group представляет новую платформу для улучшенной разработки Open Source ПО [(en)]
  9. 20.03.2020 Проект Debian анонсировал сервисы Debian Social []
  10. 25.03.2020 Mozilla тестирует сервис финансирования сайтов, продвигаемый как альтернатива рекламе []
  11. 30.03.2020 Как программному обеспечению с открытым исходным кодом достичь успеха [(en)]
  12. 07.04.2020 Разбор главных FOSS лицензий [ 1(en), 2(en)]
  13. 19.05.2020 Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx) []
  14. 21.09.2020 Как поучаствовать в Open Source проекте? 8 ответов новичку []
  15. 07.10.2020 8 советов о том, как не надо делать Open Source [(en)]
  16. 22.10.2020 Как популяризовать использование Open Source [(en)]
  17. 16.11.2020 Как монетизируется Open Source []

Внутренние дела FOSS проектов


  1. 28.02.2020 FreeBSD: гораздо лучше GNU/Linux [ 1, 2]
  2. 03.03.2020 Удаление Эрика Рэймонда из списков рассылки OSI и этические вопросы в открытых лицензиях []
  3. 03.03.2020 Open Source становится больше и богаче, заявляет SUSE [(en)]
  4. 03.03.2020 Будущее Open Source лицензий меняется [(en)]
  5. 05.03.2020 Linux Foundation заключил соглашение с OSTIF для проведения аудита безопасности []
  6. 13.03.2020 Ошибки с открытым исходным кодом: количество обнаруженных уязвимостей выросло почти на 50% благодаря людям, которые действительно их ищут [(en)]
  7. 15.03.2020 Фонд СПО объявил обладателей ежегодной премии за вклад в развитие свободного ПО []
  8. 17.03.2020 Micrоsoft покупает NPM и будет развивать его вместе с GitHub []
  9. 02.04.2020 Компания Huawei присоединилась к инициативе по защите Linux от патентных претензий []
  10. 08.04.2020 Конкурс проектов по продвижению FOSS [ 1(en), 2(en)]
  11. 08.04.2020 О всё более развивающемся положении открытого исходного кода в Азиатско-Тихоокеанском регионе [(en)]
  12. 15.04.2020 Open Source зарекомендовал себя как ведущий способ разработки программного обеспечения [(en)]
  13. 30.04.2020 Компания Canonical вышла на самообеспечение [ 1, 2]
  14. 20.05.2020 Многие Open Source сообщества столкнулись с серьёзными проблемами из-за пандемии [ 1(en), 2(en)]
  15. 29.05.2020 Каков ты, русский опен сорс? KaiCode, Open Source инкубатор от Huawei []
  16. 11.06.2020 Мир Open Source: преимущества и недостатки по мнению рядового участника []
  17. 01.07.2020 Baidu присоединился к инициативе по защите Linux от патентных претензий []
  18. 09.07.2020 Google учредил организацию для управления торговыми марками открытых проектов []
  19. 03.08.2020 Учреждён проект OpenSSF, сфокусированный на повышении безопасности открытого ПО []
  20. 11.08.2020 Компания Mozilla объявила об увольнении 250 сотрудников и ищет новые пути развития []
  21. 18.08.2020 Mozilla прекрасная IT-компания, которую мы теряем []
  22. 6.11.2020 История Open Source кратко: от калькулятора до миллиардных сделок []
  23. 08.12.2020 Red Hat прекращает разработку CentOS 8 в пользу тестового CentOS Stream []
  24. 11.12.2020 Google представил рейтинг критически важных открытых проектов []
  25. 14.12.2020 Встречайте Creative Commons Legal Database []
  26. 17.12.20 Результаты демографического опроса разработчиков ПО с FOSS от OpenSSF []

Альтернативы


  1. 14.01.2020 Прекращена поддержка Windows 7, имевшей около четверти доли рынка []
    1. 08.01.2020 Сообщество KDE опубликовало обращение к разработчикам с призывом переходить с Windows 7 на Plasma [ 1(en), 2(en)]
    2. 14.01.2020 Canonical опубликовала список причин для перехода с Windows 7 на Ubuntu [(en)]
    3. 26.01.2020 Фонд СПО предложил Microsoft передать Windows 7 сообществу []
    4. 29.01.2020 Выпуск руководства по переходу с Windows 7 на Ubuntu от Canonical []
  2. 26.02.2020 5 лучших Open Source альтернатив Slack для командного общения [(en)]
  3. 07.03.2020 Избавленный от Google форк Android добился хороших результатов [(en)]
  4. 19.03.2020 Open Source продолжает становиться мэйнстримом. Как традиции безвозмездного обмена формируют будущее музыки [(en)]
  5. 01.04.2020 Сегодня GNU/Linux как никогда открыт для геймеров [(en)]
  6. 31.03.2020 Выпуск Eclipse Theia 1.0, альтернативы редактору кода Visual Studio Code []
  7. 10.04.2020 Альтернативы проприетарной системы видеосвязи Zoom [ 1(en), 2]
  8. 21.05.2020 Взгляд на Jitsi как открытую и безопасную альтернативу Zoom [(en)]
  9. 08.07.2020 5 опенсорсных альтернатив Slack для группового чата []
  10. 25.08.2020 Дивный новый мир: что такое Fediverse и как стать его частью []
  11. 27.09.2020 Как может выглядеть глобальная открытая организация? [(en)]
  12. 21.12.2020 Вышел подкаст Полная история Fediverse []

Лучшая серия статей


  1. 25.02.2020 Полная домашняя автоматизация в новостройке []
  2. 10.03.2020 Полная домашняя автоматизация в новостройке. Продолжение []
  3. 01.06.2020 Умная хрущёвка на максималках []
  4. 15.06.2020 Умная хрущёвка на максималках. Продолжение []

(Не)холивар года


  1. 14.02.2020 Семь причин, почему Линукс []
  2. 8.04.2020 Главная причина, почему не Linux []
  3. 30.04.2020 Главная причина, почему все-таки Linux []
  4. 4.05.2020 Mein Linux []
  5. 14.05.2020 Пользователю все это не нужно! Хватит пропагандировать Линукс []

Разное


  1. 12.10.2020 Ядро Linux 5.9 поддерживает 99% популярного PCI-оборудования на рынке []
  2. 26.02.2020 Программист и музыкант алгоритмически сгенерировали все возможные мелодии и сделали их общественным достоянием [ 1, 2]
  3. 20.04.2020 Завершающий выпуск ветки Python 2 []
  4. 26.04.2020 Усложнение команд консоли, 19792020 []
  5. 18.06.2020 Monolinux однофайловый дистрибутив, загружающийся за 0.37 секунд []
  6. 22.07.2020 Школьный Linux клуб восстанавливает старые компьютеры чтобы помочь нуждающимся обучаться дистанционно [(en)]
  7. 21.10.2020 Как вносить вклад в Open Source просто делая свою работу [(en)]
  8. 28.10.2020 Перевод книги Время UNIX. A History and a Memoir []
  9. 03.11.2020 Ричард Столлман и будущее инноваций в ПО []
  10. 08.11.2020 Открытые окружения это места, где процветают инновационные идеи [(en)]

Заключение


На этом всё, до скорого!


Высказываю большое спасибо редакции и авторам OpenNET [] много новостных материалов и сообщений о новых релизах взято у них.


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


Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.


[] Предыдущий выпуск

Подробнее..

FOSS News 51 дайджест материалов о свободном и открытом ПО за 4-10 января 2021 года

10.01.2021 18:10:27 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. Наиболее важные события 2020 года по версии OpenNET; проект портирования Linux на Mac с M1 обзавёлся названием и сайтом; утраченный потенциал подсистемы Windows для Linux (WSL); open-source ПК Dragonbox Pyra начали отгружать покупателям после четырех лет разработки; lsFusion vis 1С; о взломе игры Ball Sort Puzzle и многое другое.


Оглавление


  1. Главное
    1. Наиболее важные события 2020 года по версии OpenNET
    2. Проект портирования Linux на Mac с M1 обзавёлся названием и сайтом
    3. Утраченный потенциал подсистемы Windows для Linux (WSL)
    4. Open-source ПК Dragonbox Pyra начали отгружать покупателям после четырех лет разработки
    5. lsFusion vis 1С
    6. О взломеигры Ball Sort Puzzle
  2. Короткой строкой
    1. Новости
      1. Новости FOSS организаций
      2. Юридические вопросы
      3. Ядро и дистрибутивы
      4. Безопасность
      5. Web
      6. Для разработчиков
      7. Пользовательское
      8. Железо
      9. Разное
    2. Статьи
      1. Мероприятия
      2. DIY
      3. Системное
      4. Специальное
      5. DevOps
      6. Для разработчиков
      7. История
      8. Менеджмент
      9. Пользовательское
      10. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Мультимедиа
      4. DevOps
      5. Web
      6. Для разработчиков
      7. Менеджмент
      8. Пользовательское
  3. Заключение

Главное


Наиболее важные события 2020 года по версии OpenNET


Категория: Статьи/Разное

OpenNET опубликовал список главных новостей прошедшего года. Важные релизы, новые звёзды на небосклоне FOSS, организационные и юридические новости, обнаруженные баги и уязвимости, новинки железа и многое другое.


Подробности []


Наши итоги 2020 []


Проект портирования Linux на Mac с M1 обзавёлся названием и сайтом


Категория: Новости/Ядро и дистрибутивы

denis-19 пишет в разделе Новости на Хабре: 5 января 2021 года разработчик Гектор Мартин сообщил о том, что у краудфандингового проекта Linux для Maс на M1 появился свой сайт и название Asahi Linux. Продолжается развиваться сообщество разработчиков проекта. Мартин рассказал, что в конце прошлого года к проекту Asahi Linux присоединилась разработчик Алисса Розенцвейг. Розенцвейг уже опубликовала на GitHub первые наработки по этому проекту. Также она описана первые результаты реверс-инжиниринга драйверов для GPU чипа Apple M1 в своем блоге. Розенцвейг известна тем, что возглавляет разработку свободного драйвера Panfrost, у нее есть большой опыт реверс-инжинирингаоригинальных драйверов от компании ARM


Подробности []


Утраченный потенциал подсистемы Windows для Linux (WSL)


Категория: Статьи/Ядро и дистрибутивы

Компания VDSina публикует в своём блоге на Хабре статью с разбором WSL 1 и WSL 2 и анализирует возможности заявленные изначально и полученные в итоге: Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука. Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE. К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с родными инструментами Windows. А ведь изначально всё задумывалось совсем иначе, пишет Джулио Мерино (Julio Merino), автор блога для разработчиков jmmv.dev. Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле. Чтобы понять причины этого провала, нужно сначала понять различия между WSL 1 и WSL 2 и как переход на WSL 2 закрыл некоторые интересные перспективы.


Подробности []


Open-source ПК Dragonbox Pyra начали отгружать покупателям после четырех лет разработки


Категория: Новости/Железо

Компания Selectel пишет в своём блоге на Хабре: DragonBox Pyra карманный (в буквальном смысле слова) компьютер с 5-дюймовым дисплеем, процессором TI OMAP 5 и QWERTY-клавиатурой. В нее же встроены два стика и D-pad. Устройство разрабатывалось в качестве легко модифицируемой открытой платформы. Поставляется гаджет с Debian Linux, но поддерживаются и многие другие ОС, так что ПК можно использовать в качестве десктопного или игрового. О DragonBox Pyra известно уже давно, но только сейчас его начали отгружать покупателям. К слову, предзаказы на девайс стали принимать еще четыре года назад.


Подробности []


lsFusion vis 1С


Категория: Статьи/Специальное

1C программист с 20-летним опытом работы fixin опубликовал в блоге на Хабре обзор lsFusion, белорусской разработки на Java, и постарался ответить на вопрос годится ли она на роль убийцы 1С. Рассмотрены архитектура, интерфейс, разработка дополнительного функционала, генерация отчётов, интеграции, лицензия, сообщество и многое другое.


Подробности []


О взломеигры Ball Sort Puzzle


Категория: Статьи/Для разработчиков

ErhoSen написал на Хабре о своём опыте взлома игры Ball Sort Puzzle: Ball Sort Puzzle это популярная мобильная игра на IOS/Android. Суть её заключается в перестановке шариков до тех пор, пока в колбах не будут шарики одного цвета. При этом шарик можно перетаскивать либо в пустую колбу, либо на такой же шарик. Так случилось, что я в неё залип. Очнулся примерно через месяц, на 725 уровне. Он мне никак не давался насколько бы глубоко я не пытался продумать свою стратегию. В итоге с этим вопросом я вышел в интернет, и заодно выяснил несколько интересных особенностей головоломки. Во-первых, игра бесконечна почти бесконечна. По крайней мере уже сейчас на YouTube есть прохождения всех уровней вплоть до 5350, а в телеграмме гуляют скриншоты 10к+ уровней. Вторая особенность, и вот это уже некрасиво, не у всех уровней есть решение. Ну это ни в какие ворота против нас играет коварный ИИ. Нужно действовать соответственно!.


В итоге автор сделал:


  1. алгоритм, решающий головоломку (Python);
  2. парсер скриншота игры, чтобы скармливать алгоритму задачки (OpenCV);
  3. Telegram бот, который принимает скриншоты и возвращает решения;
  4. CI/CD через GitHub Actions и бот на Яндекс.Функциях.

Подробности []


Короткой строкой


Новости


Новости FOSS организаций


  1. GitHub снял ограничения для разработчиков из Ирана []
  2. Еженедельник OSM 545 []

Юридические вопросы


Лицензия сканера безопасности NMAP признана несовместимой с Fedora []


Ядро и дистрибутивы


Компания Apple открыла ядро и системные компоненты macOS 11.0 Big Sur []


Безопасность


Gentoo прекращает поддержку LibreSSL в пользу OpenSSL и LibreTLS []


Web


  1. В адресной строке Chrome по умолчанию начнёт применяться HTTPS []
  2. Firefox 85 перейдёт на ECH для скрытия домена в HTTPS-трафике []

Для разработчиков


  1. Выход электронной книги: Common Open Source Practices in Developing Cloud Native Applications [(en)]
  2. Компания Qt Company ограничила доступ к исходному коду LTS-ветки Qt 5.15 []
  3. Ограничен доступ к исходникам Qt 5.15 []
  4. Интригующие возможности С++ 20 для разработчиков встраиваемых систем []

Пользовательское


Дорожная карта KDE на 2021 []


Железо


Крошечный неттоп ECS Liva Q1A использует ОС Ubuntu [(en)]


Разное


Директором по информационным технологиям в Белом доме назначен известный разработчик СПО []


Статьи


Мероприятия


7 интересных выступлений с All Things Open 2020 [(en)]


DIY


  1. Настройка голосового ассистента под себя и использование нестандартного голоса[(en)]
  2. Перчатка Mark gauntlet v4.2 []
  3. Radxa sata hat для raspberry pi 4: домашний сервер с НАС, облаком и торрентокачалкой через впн в докере []
  4. Делаем из старого усилителя многофункциональный медиа сервер с помощью Raspberry pi []

Системное


Как пользоваться dmesg []


Специальное


  1. Установка NTP сервера для включения его в pool.ntp.org []
  2. Homura: основанная на WINE программа для запуска игр на BSD [(en)]
  3. Выбираем self-hosted замену IFTTT []

DevOps


  1. 10 способов использовать Ansible [(en)]
  2. 8 инсайтов о Kubernetes для 2021 [(en)]
  3. 4 строки кода для более эффективного использования Ansible [(en)]
  4. Создание современных процессов CI/CD для бессерверных приложений с Red Hat OpenShift Pipelines и Argo CD. Часть 1 []
  5. Xудшие практики для Ansible. Георгий Шуклин []
  6. Apache Kafka в вопросах и ответах []
  7. Ansible идемпотентный. Алексей Соколов []
  8. Практическое руководство по HashiCorp Consul Часть 2 []

Для разработчиков


  1. ИзучениеFortran через написание игры угадай число [(en)]
  2. Пишем драйвер фреймбуфера для Raspberry Pi с LCD []
  3. Профилирование в облаке и не только []
  4. ИзучениеC через написание простой игры [(en)]
  5. Руководство по использованию gdb [(en)]
  6. Русификация баша []
  7. 10 способов повысить свои знания по JavaScript в 2021 [(en)]

История


История Nokia MeeGo []


Менеджмент


Perfomance-менеджмент через оценки от идеи до бета тестирования []


Пользовательское


  1. QuiteRSS: свободная десктопная RSS читалка для Linux [(en)]
  2. Лучшие темы для Grub []
  3. 3 лучших приложения для повышения продуктивности [(en)]
  4. Подробное руководство по настройке системного дока в Ubuntu [(en)]
  5. Почему может понравиться консольный редактор FED (работает в Linux, Windows, DOS) [(en)]
  6. Настройка сетевого интерфейса Linux []

Разное


  1. Как принципы открытости влияют на будущее работы[(en)]
  2. Названы победители 27 конкурса по написанию запутанного кода на языке Си []
  3. О томкак опытный разработчик в сфере безопасности присоединился к Open Source сообществу [(en)]
  4. 8 шпаргалок для Open Source софта для работы в 2021 [(en)]
  5. 3 serverless стратегий, которые стоит рассмотреть для работы в 2021 [(en)]
  6. На случай если пропустили записи с 4 важных онлайн событий 2020 [(en)]
  7. Кто такой open source евангелист? [(en)]

Релизы


Ядро и дистрибутивы


  1. Релиз дистрибутива Deepin 20.1. Много обновлений. Собственный браузер и другие []
  2. Релиз дистрибутива Slacko Puppy 7.0 []
  3. Релиз дистрибутива Linux Mint 20.1 []

Системное


  1. Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD []
  2. Выпуск проприетарного драйвера NVIDIA 460.32 []

Мультимедиа


Рисовалка для детей TuxPaint 0.9.25. Создание анимированных GIF []


DevOps


Выпуск Bastille 0.8, системы управления контейнерами на основе FreeBSD Jail []


Web


  1. Релиз консольной утилиты для загрузки файлов wget 1.21 []
  2. Wasmer 1.0, инструментарий для платформонезависимых приложений на базе WebAssembly [ 1, 2]
  3. Обновление Firefox 84.0.2 с устранением уязвимости []
  4. Обновление Chrome 87.0.4280.141 с исправлением уязвимостей []
  5. Релиз твиттер-клиента Cawbird 1.3. Поддержка загрузки видео []
  6. Выпуск платформы PeerTube 3.0 с поддержкой децентрализованного потокового вещания [ 1, 2]
  7. Изменение модели формирования релизов DNS-сервера BIND. BIND 9.18 отложен на следующий год []

Для разработчиков


  1. Выпуск Tcl/Tk 8.6.11 []
  2. Выпуск стандартной Си-библиотеки PicoLibc 1.5 []
  3. Доступен выпуск KDE Frameworks 5.78 []

Менеджмент


Вышла RunaWFE Free 4.4.1 российская система управления бизнес-процессами предприятия []


Пользовательское


  1. Корректирующий релиз KDE Plasma 5.20.5 []
  2. Релиз GNU tar 1.33 []
  3. Релиз KDE Applications 20.12.1 []
  4. Менеджер заметок CherryTree 0.99.19-29. Что нового []

Заключение


На этом всё, до следующего воскресенья!


Высказываю большое спасибо редакции и авторам OpenNET [] много новостных материалов и сообщений о новых релизах взято у них.


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


Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.


[] Предыдущий выпуск

Подробнее..

FOSS News 52 дайджест материалов о свободном и открытом ПО за 11-17 января 2021 года

17.01.2021 20:13:46 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. Разработчики ядра Linux обсуждают проведение чистки устаревших платформ; компания CloudLinux выпускает альтернативу CentOS 8 под именем AlmaLinux; заметка о человеке, который связывает большие информационные системы и Data Science; разговор с техническим директором RISC-V Марком Химельштейном; проект Elasticsearch переходит на несвободную лицензию SSPL; перспективы Open Source в 2021 и многое другое.


Оглавление


  1. Главное
    1. Разработчики ядра Linux обсуждают проведение чистки устаревших платформ
    2. Компания CloudLinux выпускает альтернативу CentOS 8 под именем AlmaLinux
    3. О человеке, который связывает большие информационные системы и Data Science
    4. Разговор с техническим директором RISC-V Марком Химельштейном
    5. Проект Elasticsearch переходит на несвободную лицензию SSPL
    6. Перспективы Open Source в 2021
  2. Короткой строкой
    1. Новости
      1. Внедрения
      2. Открытие кода и данных
      3. Новости FOSS организаций
      4. Ядро и дистрибутивы
      5. Обучение
      6. Системное
      7. Безопасность
      8. AI & Data Science
      9. Web
      10. Пользовательское
      11. Разное
    2. Статьи
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Базы данных
      5. Мультимедиа
      6. Безопасность
      7. DevOps
      8. AI & Data Science
      9. Web
      10. Для разработчиков
      11. Пользовательское
      12. Железо
      13. Разное
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Базы данных
      5. Мультимедиа
      6. Мобильные
      7. Web
      8. Для разработчиков
      9. Игры
      10. Разное
  3. Что ещё посмотреть
  4. Заключение

Главное


Разработчики ядра Linux обсуждают проведение чистки устаревших платформ


Категория: Новости/Ядро и дистрибутивы

OpenNET пишет: Арнд Бергман (Arnd Bergmann), отвечающий за пакеты с ядром в SUSE, предложил провести значительную чистку кода ядра от поддержки устаревших платформ и процессоров. В качестве претендентов на удаление называются платформы, для которых с 2015 года не зафиксировано активности сопровождающих и пользователей. В случае удаления платформы будут исключены из будущих выпусков ядра Linux, но для них можно будет использовать LTS-ядро Linux 5.10, поддержка которого продлится до декабря 2026 года.


Подробности [ 1, 2]


Компания CloudLinux выпускает альтернативу CentOS 8 под именем AlmaLinux


Категория: Новости/Ядро и дистрибутивы

OpenNET пишет: Компания CloudLinux сообщила об утверждении имени AlmaLinux для своего дистрибутива, продолжающего развитие ветки CentOS 8. Первый выпуск дистрибутива обещают сформировать в течение первого квартала 2021 года. Как и классический CentOS 8 дистрибутив будет базироваться на пакетной базе Red Hat Enterprise Linux 8 и будет полностью бинарно совместим с RHEL. Пользователи смогут использовать AlmaLinux в качестве прозрачной замены CentOS 8, миграция будет предельно упрощена. Обновления для ветки дистрибутива AlmaLinux, основанной на пакетной базе RHEL 8, будут выпускаться до 2029 года. Основным спонсором разработки выступает компания CloudLinux, которая предоставит проекту ресурсы и разработчиков. В общем виде планируется тратить на развитие проекта миллион долларов в год, при том, что дистрибутив будет абсолютно бесплатен для всех категорий пользователей и принадлежать сообществу, которому будут делегированы функции принятия решений. Модель управления и взаимодействия в сообществе AlmaLinux будет построена по аналогии с проектом Fedora. Все наработки будут публиковаться под свободными лицензиями.


Подробности [ 1, 2, 3(en), 4(en)]


О человеке, который связывает большие информационные системы и Data Science


Категория: Статьи/AI & Data Science

На Хабре в блоге компании ИТЭЛМА опубликован перевод материала об Уэсе МакКинни, авторе самого известного и функционального пакета для обработки данных Pandas: Уэс МакКинни, о котором писали в Quartz как о человеке, создавшем наиболее важный инструмент в области Data Science (речь о пакете для анализе данных Pandas), отправляется в новое плавание он запускает стартап под названием Ursa Computing. По словам МакКинни, стартап будет заниматься разработкой продуктов и предоставлением услуг для ускорения работы с данными, машинным обучением и искусственным интеллектом для предприятий. МакКинни и его компании получили 4,9 миллиона долларов в рамках первого этапа финансирования, проведенного GV. Ursa Computing сосредоточится на корпоративном рынке и будет стремиться к широкому распространению Apache Arrow независимой от языка программной платформы для разработки приложений для анализа данных. Компания будет продолжать разработку проектов в области Data Science с открытым исходным кодом, изначально созданных Ursa Labs (некоммерческая независимая лаборатория разработки, также созданная МакКинни).


Подробности []


Разговор с техническим директором RISC-V Марком Химельштейном


Категория: Статьи/Новости FOSS организаций

И снова перевод в блоге компании ИТЭЛМА: Летом 2020 RISC-V International (организация-член группы RISC-V) объявила о назначении 16 членов правления в новую компанию с штаб-квартирой в Швейцарии в связи с упразднением старого подразделения RISC-V Foundation. В июне 2020 года в компанию пришел новый CTO Марк Химельштейн. Мы взяли у него онлайн-интервью, в котором поговорили о его роли в компании, проблемах (если они имеются) внедрения RISC-V и влиянии геополитики на различные процессы. В интервью были обсуждены бэкграунд Марка, перспективы RISC-V, преимущества платформы и проблемы при разработке, развитие экосистемы, сотрудничество с другими организациями и влиянии геополитики на бизнес.


Подробности []


Проект Elasticsearch переходит на несвободную лицензию SSPL


Категория: Новости/Специальное

OpenNET пишет: Компания Elasticsearch B.V. анонсировала изменение лицензии на платформу поиска, анализа и хранения данных Elasticsearch, а также на web-интерфейс Kibana. Начиная с выпуска Elasticsearch 7.11 проект будет переведён с лицензии Apache 2.0 на лицензию SSPL (Server Side Public License), в которой добавлены дополнительные требования по использованию для обеспечения работы облачных сервисов. Для тех, кого не устраивают условия лицензии SSPL, предоставлена коммерческая лицензия Elastic License. Клиентские библиотеки продолжат поставляться под лицензией Apache 2.0. Лицензия SSPL уже используется проектом MongoDB и предоставляет возможность модификации и распространения кода, но не прошла рецензирование организацией OSI (Open Source Initiative), занимающейся проверкой соответствия лицензий критериям Open Source. Лицензия SSPL сформулирована так, что на практике приложения под данной лицензией невозможно использовать в облачных сервисах без покупки коммерческой лицензии, так как иначе придётся перелицензировать под SSPL код всех компонентов, вовлечённых в работу облачного сервиса, в том числе и сторонних.


Подробности []


В статье уже была упомянута подобная ситуация с MongoDB, но проблема шире и в прошлом году уже было несколько материалов о сложностях в отношениях Open Source проектов и коммерческих организаций. Вот одна из них о сложных отношениях между Amazon и Open Source []


Перспективы Open Source в 2021


Категория: Статьи/Разное

Стоят внимания два материала с взглядами на будущее Open Source в 2021.


Первый статья Майка Милинковича, исполнительного директора Eclipse Foundation. Например, он пишет: Давайте начнём с достаточно общего прогноза, но критически важного: Open Source модель для совместной работы над инновациями будет продолжать расти, особенно в корпоративном секторе. Open Source уже стал доминирующей моделью для взаимодействия для IT и технологических компаний. Но он становится мейнстримом и для вообще любой компании, работающей над стратегией информатизации. Темпы инноваций и уровень взаимодействия, которые предоставляет Open Source, несравнимы ни с чем. В статье по ссылке есть его мнения и по более частным вопросам [(en)].


Ещё одно мнение от Microsoft (внезапно). Вот кратко об извлечённых ими уроках:


  1. работа с Open Source позволяет получать различные взгляды на ситуацию и обратную связь от других членов сообщества;
  2. особое внимание необходимо уделять безопасности, так как отслеживание безопасности каждого элемента в цепочке Open Source зависимостей становится всё более сложной задачей и в том числе для решения этой проблемы Microsoft, GitHub, Google, IBM и другие объединились в Open Source Security Foundation;
  3. эффективная коммуникация становится всё более ключевым элементом успеха проектов и этому должно быть уделено особое внимание.

Подробности [(en)].


Кроме того, может быть интересно то, как прошёл год для крупнейшей Open Source организации мира Linux Foundation, по ссылке их отчёт за 2020 год [(en)].


Короткой строкой


Новости


Внедрения


Deutsche Telekom открыл для своих клиентов возможность разворачивать приватныеNextcloud [(en)]


Открытие кода и данных


  1. Мы опубликовали современный Voice Activity Detector и не только []
  2. Релиз bladeRF-wiphy []

Новости FOSS организаций


  1. Запуск man.archlinux.org []
  2. GCC фронтенд для Rust получил новое финансирования [(en)]
  3. Стоимость GitLab поднялась до рекордных 6 миллиардов долларов [(en)]
  4. GitLab сотрудничает с IBM Cloud для улучшения взаимодействия в сфере DevOps [(en)]
  5. Dent представляет высококлассный сетевой стэк для современных распределённых корпоративных решений на основе Linux [(en)]
  6. Tessia, HCL Technologies и Red Hat присоединяются к экосистеме Open Mainframe [(en)]
  7. Centaurus Infrastructure Project присоединяется к Linux Foundation для улучшения облачной инфраструктуры [(en)]
  8. EdgeX Foundry, ведущий IoT Open Source фреймворк, упрощает деплой в своём последним релизом, открывая новые сценарии использования и улучшая экосистему [(en)]
  9. Новый отчёт об участниках Open Source проектов от Linux Foundation и Гарварда показывает мотивацию и возможности для улучшения безопасности приложений [(en)]
  10. Janssen Project работает с самыми важными вызовами цифровой безопасности [(en)]
  11. Open Source веб движок Servo присоединяется к Linux Foundation [(en)]
  12. FINOS запускает Open Regtech Initiative после получения рекордного вклада от Open Source контрибьюторов [(en)]
  13. Еженедельник OSM 546 []

Ядро и дистрибутивы


  1. Дистрибутив Tails перейдёт использование на Wayland []
  2. В Fedora 34 намечен перевод FreeType на HarfBuzz для улучшения хинтинга []
  3. В Ubuntu 21.04 будет ограничен доступ посторонних к домашним каталогам []
  4. Debian и Fedora пытаются справиться с проблемой мелких зависимостей []
  5. Первая стадия заморозки Debian 11 и движение по прекращению поддержки i386 в Debian 12 []

Обучение


Linux Foundation открывает набор курсов по менеджменту и стратегии развития Open Source проектов[(en)]


Системное


В драйвере Panfrost обеспечена поддержка OpenGL 3.1 для GPU Mali []


Безопасность


  1. В Mozilla VPN появилась поддержка Linux и macOS []
  2. Уязвимость, позволяющая обойти блокировку экрана в дистрибутивах с рабочим столом Cinnamon [ 1, 2(en)]
  3. ProtonVPN запускает новый важный инструмент обеспечения приватности [(en)]

AI & Data Science


О попытках воспроизвести и открыть для сообщества GPT-3, разработанный OpenAI [(en)]


Web


  1. В Firefox 85 будет активировано аппаратное ускорение отрисовки для GNOME на базе Wayland []
  2. Google запретил использование Google API в сторонних браузерах на основе Chromium []

Пользовательское


  1. Представлены обои рабочего стола для KDE Plasma 5.21 []
  2. В Kontact за прошедшие два месяца подготовлено около 1200 изменений []
  3. На этой неделе в KDE: обновление KWin, новое меню и визуализация громкости! []
  4. С обновлением KDE Frameworks 5.78 добавлены новые цветовые схемы []

Разное


  1. Джордан Вальке, создатель ReactJS уходит из Facebook для созданий собственной компании[(en)]
  2. Энтузиасту удалось запустить Ubuntu 20.04 на iPhone 7 []

Статьи


Ядро и дистрибутивы


  1. Об ElementaryOS, легковесном и быстром десктоп окружении[(en)]
  2. Oracle cloud: превращаем ubuntu 20.04 в gentoo []
  3. О планах поддержки Linux на Apple M1[ 1(en), 2(en)]

Системное


  1. 7 руководств по Bash для улучшения ваших навыков работы с командной строкой [(en)]
  2. Обход ограничений терминала []
  3. JuiceFS новая открытая ФС для объектных хранилищ []
  4. Заметки о Unix: два сценария работы с конвейерами []
  5. Systemd для продолжающих. Part 2 Триггеры на различные события []
  6. Что такое Inode []

Специальное


  1. Лучшие RDP клиенты для Linux []
  2. Ошибка no bootable medium found VirtualBox []
  3. Linux=Terminal? []
  4. Как установить SSL сертификат на Onlyoffice docker сборки []
  5. CRUD для NMAPа: решение для мониторинга открытых портов на хостах []

Базы данных


  1. Преобразование текстовых запросов в SQL []
  2. Когда-то я внедрял ClickHouse в стартапе, где даже алерты мониторили индийцы это был Дикий Запад []

Мультимедиа


Создание HiFi музыкальной системы на основе Raspberry Pi [(en)]


Безопасность


  1. Что лучше выбрать: Wireguard или OpenVPN? Любимый VPN Линуса Торвальдса []
  2. Linux exploits []
  3. Быстрый туториал по установке и эксплуатации системы фильтрации IP-адресов CrowdSec v.1.0.x []

DevOps


  1. Как настроить мониторинг любых бизнес-процессов, в БД Oracle + построение графиков, используя бесплатную версию Grafana []
  2. Безопасное использование секретов: шаблон для использования HashiCorp Vault []
  3. ДеплойCeph на Raspberry Pi кластере [(en)]
  4. Проверка ролей Ansible через делегированный драйвер Molecule []
  5. Эксплуатация Ceph: что такое Scrub и как им управлять []
  6. Periskop инструмент мониторинга исключений []
  7. Автоматизация ручных действий с GitHub Actions []
  8. АнализKubernetes файлов на ошибки с KubeLinter [(en)]
  9. Kubernetes или с чего начать, чтобы понять что это и зачем он нужен []
  10. Как управлять многоступенчатым окружением с помощью Ansible []
  11. Лучшие практики при написании безопасного Dockerfile []
  12. Сервер Prometheus и TLS []
  13. Об открытых стандартах и развитии Kubernetes [(en)]

AI & Data Science


Как обучать огромные модели машинного обучения на случайных GPU []


Web


  1. 9 децентрализованных, P2P и Open Source альтернатив мейнстримным социальным платформам, таким как Twitter, Facebook, YouTube и Reddit [(en)]
  2. Какое шифрование лучше: Signal или Telegram? []
  3. Signal открытая и уделяющая повышенное внимание приватности альтернатива WhatsApp [(en)]
  4. 5 альтернатив WhatsApp с большим вниманием к приватности [(en)]
  5. Расширяем возможности миграций Laravel за счет Postgres []
  6. Интервью с Капилом Тангавелу, создателем Cloud Custodian и Stacklet [(en)]
  7. Беспристрастный анализ отчёта CNCF за 2020 год [(en)]

Для разработчиков


  1. Клиент-серверный IPC на Python multiprocessing []
  2. Микрохирургия ELF'а или А что, так можно было?! []
  3. Поддержание аккуратной истории в Git с помощью интерактивного rebase []
  4. 15 лучших руководств по программированию по версии opensource.com [(en)]
  5. Давайте напишем командную оболочку Linux []
  6. Учимся писать информативные комментарии к GIT-коммитам используя общепринятую семантику []
  7. Кросс-компиляция стала проще вместе с Golang [(en)]
  8. 5 вещей, которые мы узнали о Java в 2020 по версии opensource.com [(en)]

Пользовательское


  1. Super Productivity Open Source To-Do приложение с GitHub интеграцией [(en)]
  2. 8 советов по работе с командной строкой Linux [(en)]
  3. Лучшие консольные браузеры для Linux []
  4. 3 инструментов для работы с plain text [(en)]
  5. Изучение aws программируя простую игру отгадай число [(en)]
  6. Об использовании KDE набора приложенийKontact [(en)]

Железо


О повышении безопасностиEmbedded/IoT устройств, используя Open Source [(en)]


Разное


Как Open Source обеспечивает доверие [(en)]


Релизы


Ядро и дистрибутивы


  1. Представлен дистрибутив Linux Mint 20.11 Ulyssa [ 1, 2, 3, 4(en)]
  2. Alpine Linux 3.13.0 []
  3. Релиз минималистичного дистрибутива Alpine Linux 3.12 []
  4. Представлен Fedora Kinoite, аналог Fedora Silverblue с рабочим столом KDE []

Системное


  1. Выпуск механизма управления теневыми паролями tcb 1.2 []
  2. Обновление sudo 1.9.5 с устранением уязвимостей []
  3. Первый публичный выпуск распределённой файловой системы JuiceFS []
  4. Выпуск пакетных фильтров nftables 0.9.8 и iptables 1.8.7 []

Специальное


  1. lsFusion 5, 6: больше асинхронности, агрегация / расширение / пользовательская настройка форм, новые представления []
  2. Стабильный релиз Wine 6.0 [ 1, 2, 3]
  3. Выпуск Proton 5.13-5 и Wine staging 6.0 []
  4. Релиз платформы разработки информационных систем lsFusion 4.0 []
  5. Релиз программы для очистки системы BleachBit 4.2. Новые клинеры. Поддержка Fedora 33 и Ubuntu 20.04/20.10 []

Базы данных


Опубликована библиотека urm для Python []


Мультимедиа


AviSynth+ 3.7.0 []


Мобильные


Представлена редакция смартфона PinePhone с дистрибутивом Mobian []


Web


Релиз децентрализованной коммуникационной платформы Hubzilla 5.2 []


Для разработчиков


  1. Опубликован GTK 4.0.1 с улучшением поддержки мультимедиа []
  2. Вышел релиз GitLab 13.7 с проверяющими для мерж-реквестов и автоматическим откатом при сбое []

Игры


Релиз игрового клиента Lutris 0.5.8. Что нового []


Разное


Вышел xVA-Synth []


Что ещё посмотреть


Видео: IT новости #34 Deepin 20.1 продолжает удивлять. Cawbird, wget, TuxPaint, Parole []


KDE Apps 20.12.1, январское обновление. Neochat 1.0, KIO Fuse, новые программы []


Изучаем Bash путем написания интерактивой игры, создаем культуру DevOps, а также шпаргалка по MariaDB и MySQL []


Заключение


На этом всё, до следующего воскресенья!


Высказываю большое спасибо редакции и авторам OpenNET [] много новостных материалов и сообщений о новых релизах взято у них.


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


Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.


[] Предыдущий выпуск

Подробнее..

FOSS News 53 дайджест материалов о свободном и открытом ПО за 18-24 января 2021 года

24.01.2021 22:23:01 | Автор: admin

Всем привет!


Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире. Red Hat представил бесплатные варианты Red Hat Enterprise Linux; китайцы выпустили GNU/Linux дистрибутив UOS в качестве полноценной замены Windows 7 для госсектора; компания Corellium адаптировала GNU/Linux для работы на компьютерах с чипом Apple M1; Flipper Zero план по производству и доставке; Arch Linux, Fedora, Debian, Slackware и openSUSE могут отказаться от поставки Chromium; как законтрибьютить в опенсорс, чтобы не сгореть со стыда; готов ли ваш Open Source проект к внедрению в корпорации; сегодня большинство Windows-игр отлично запускаются под GNU/Linux благодаря Proton и многое другое.


Оглавление


  1. Главное
    1. Red Hat представил бесплатные варианты Red Hat Enterprise Linux
    2. Китайцы выпустили GNU/Linux дистрибутив UOS в качестве полноценной замены Windows 7 для госсектора
    3. Компания Corellium адаптировала GNU/Linux для работы на компьютерах с чипом Apple M1
    4. Flipper Zero план по производству и доставке
    5. Arch Linux, Fedora, Debian, Slackware и openSUSE могут отказаться от поставки Chromium
    6. Как законтрибьютить в опенсорс, чтобы не сгореть со стыда
    7. Готов ли ваш Open Source проект к внедрению в корпоративной среде?
    8. Сегодня большинство Windows-игр отлично запускаются под GNU/Linux. Спасибо, Proton
  2. Короткой строкой
    1. Новости
      1. Внедрения
      2. Новости FOSS организаций
      3. Юридические вопросы
      4. Ядро и дистрибутивы
      5. Системное
      6. Специальное
      7. Обучение
      8. Мобильные
      9. Безопасность
      10. DevOps
      11. Web
      12. Для разработчиков
      13. Пользовательское
      14. Железо
      15. Разное
    2. Статьи
      1. Внедрения
      2. DIY
      3. Ядро и дистрибутивы
      4. Системное
      5. Специальное
      6. Обучение
      7. Базы данных
      8. Мультимедиа
      9. Мобильные
      10. Безопасность
      11. DevOps
      12. AI & Data Science
      13. Web
      14. Для разработчиков
      15. Пользовательское
      16. Железо
    3. Релизы
      1. Ядро и дистрибутивы
      2. Системное
      3. Специальное
      4. Мультимедиа
      5. Безопасность
      6. DevOps
      7. Web
      8. Для разработчиков
      9. Пользовательское
  3. Что ещё посмотреть
  4. Заключение

Главное


Red Hat представил бесплатные варианты Red Hat Enterprise Linux


Категория: Новости/Ядро и дистрибутивы

OpenNET пишет: Компания Red Hat объявила о расширении программы Red Hat Developer, определяющей области бесплатного использования дистрибутива Red Hat Enterprise Linux. Новые варианты нацелены на удовлетворение потребности в стабильном бесплатном дистрибутиве, возникшей после трансформации проекта CentOS в CentOS Stream. Изначально программа Red Hat Developer позволяла бесплатно использовать штатные сборки Red Hat Enterprise Linux для решения задач, возникающих в процессе разработки. Использование для рабочих внедрений, для сборки финальных продуктов, для тестирования с участием нескольких участников или для обеспечения систем непрерывной интеграции требовало оформления платной подписки. Представленные изменения отменяют привязку программы Red Hat Developer к одному разработчику и разрешают использование предоставляемых бесплатных сборок командами разработчиков, а также на серверах и в рабочих внедрениях (production), насчитывающих до 16 систем.


Подробности [ 1, 2, 3, 4(en), 5(en)]


Китайцы выпустили GNU/Linux дистрибутив UOS в качестве полноценной замены Windows 7 для госсектора


Категория: Новости/Ядро и дистрибутивы

CNews сообщает о том, что, по словам разработчиков китайского дистрибутива Linux UOS (Unity Operating System), система достаточно готова чтобы заменить Microsoft Windows 7 в стране. Создание UOS было инициировано властями Китая в рамках постепенного отказа от иностранного ПО. UOS поддерживает все необходимые аппаратные платформы и обладает обширной экосистемой приложений. Глава Union Tech, разработчика UOS, отметил, что по состоянию на конец 2020 г. компания поставила более миллиона лицензий на UOS. Основу UOS составляет Deepin.


Подробности []


Компания Corellium адаптировала GNU/Linux для работы на компьютерах с чипом Apple M1


Категория: Новости/Ядро и дистрибутивы

OpenNET пишет: Компания Corellium, в рамках проекта Sandcastle занимающаяся портированием Linux и Android для iPhone, представила сборку Linux, адаптированную для работы на новых компьютерах Apple, оснащённых чипом M1. Вариант ядра Linux с поддержкой чипа Apple M1 опубликован под лицензией GPLv2, а патчи переданы для включения в основной состав ядра. Для загрузки на компьютере Mac Mini M1 с чипом Apple M1 подготовлен готовый образ rootfs, построенный на базе сборки Ubuntu Linux для Raspberry Pi. Разработчики из Corellium опередили проект Asahi Linux, основанный Гектором Мартином (Hector Martin) для портирования Linux на системы с чипом Apple M1, который пока ограничился проведением обратного инжиниринга и экспериментами с загрузчиком. Тем не менее, ключевой целью Asahi Linux является не просто загрузка Linux, а обеспечение полноценной поддержки механизмов управления питанием и задействование возможностей GPU Apple M1, в котором применяется специфичный набор инструкций.


Подробности [ 1, 2, 3(en), 4(en), 5(en)]


Flipper Zero план по производству и доставке


Категория: Статьи/Специальное

Компания Flipper Devices Inc. в своём блоге на Хабре сообщила о текущем статусе проекта Flipper Zero (карманного мультитула для хакеров в формфакторе тамагочи), задачах и проблемах, грядущем производстве и доступе в pledge manager. Кратко:


  1. поставки заказчикам будут производиться с января (ранние версии с возможными проблемами) до августа (серийные отлаженные образцы);
  2. железо почти готов, это главное;
  3. софт в разработке, ещё многое предстоит сделать, это не так страшно, прошивку можно обновить;
  4. сертификация важная и сложная задача, но без неё никак;
  5. большинство деталей серийные компоненты, но есть и уникальные, производимые под заказ;
  6. финальная версия корпуса согласуется с производителем;
  7. разработчики очень беспокоятся из-за задержек, но они делают всё возможное, проект для них очень важен.

Напомним, проект предполагается сделать полностью открытым.


Подробности []


Arch Linux, Fedora, Debian, Slackware и openSUSE могут отказаться от поставки Chromium


Категория: Новости/Web

OpenNET сообщает: Разработчик, поддерживающий пакеты с Chromium для Arch Linux, заявил, что откажется от сопровождения Chromium и выступит за удаление данного браузера из репозиториев в случае, если не удастся найти выход по поддержанию в Chromium синхронизации данных. Напомним, что компания Google решила с 15 марта ограничить в Chromium доступ к внутренним API, привязанным к сервисам Google. Изменение приведёт к невозможности использования в Chromium синхронизации закладок, паролей и истории посещений. Том Каллауэй (Tom Callaway), сопровождающий пакет Chromium в Fedora и EPEL, также начал обсуждение вопроса дальнейших действий в случае прекращения доступа к API Google. Эрик Гамелерс (Eric Hameleers), сопровождающий пакет в Slackware, упомянул, что не видит смысла в продолжении компиляции и создания пакетов с Chromium для Slackware, если Google не откажется от вводимых ограничений. Разработчики Debian ещё с октября прошлого года рассматривают вопрос прекращения поставки Chromium из-за проблем со свободным временем и ресурсами у сопровождающих.


Подробности []


Из-за чего все проблемы Google закрывает сторонний доступ к Chrome Sync API []


Как законтрибьютить в опенсорс, чтобы не сгореть со стыда


Категория: Статьи/Для разработчиков

На Хабре вышла статья с подробным руководством о том, как правильно принимать участие в Open Source проектах. На осеннем TechTrain Андрей Солнцев и Артем Ерошенко показали на примере Allure и Selenide, как справиться с техническими и психологическими трудностями. Прямо во время доклада они сделали изменения в опенсорсных проектах. В статье расшифровка их доклада и видео с фестиваля. Разобраны вопросы: зачем поддерживать, как поддержать и как поменять код. Также приведена практическая часть.


Подробности []


Готов ли ваш Open Source проект к внедрению в корпоративной среде?


Категория: Статьи/Менеджмент

На сайте TFIR опубликована запись интервью с Дирком Хонделем, вицепрезидентом и ответственным за Open Source разработки в VMware. Тема диалога подготовка Open Source проектах к использованию в корпоративной среде. Вот некоторые из рассмотренных тем:


  1. Несмотря на открытый исходный код, ПО тоже должно соответствовать всем предъявляемым критериям. Итак, что значит быть достаточно хорошим, чтобы подходить для использования на предприятии?
  2. Как гарантировать, что за выбранным вами проектом стоит здоровое сообщество и усилия по развитию?
  3. Кто еще пользуется проектом?
  4. Стоит ли вам заботиться о лицензии, под которой выпущен проект?
  5. Стоит ли смотреть на проект, для которого предлагается поддержка поставщиком, поскольку собственное обслуживание со временем может стать более дорогостоящим?
  6. У открытого исходного кода есть много конкурирующих проектов, которые делают одно и то же как выбрать подходящий для вас?

Подробности [(en)]


Сегодня большинство Windows-игр отлично запускаются под GNU/Linux. Спасибо, Proton


Категория: Статьи/Игры

На Хабре вышла статья, описывающая положение дел в области, являющейся предметом бесконечных споров игры в GNU/Linux. Приведя во введении пример игры Cyberpunk 2077, в которую пользователи GNU/Linux смогли играть с самого релиза, автор переходит к рассказу о том, что такое Proton (разработанная Valve Software) и ProtonDB, каково состояние VR в GNU/Linux и почему поддержка игр важна для любой ОС. В статье также есть примеры топовых игр и их совместимость с GNU/Linux.


Подробности []


Короткой строкой


Новости


Внедрения


Планшеты на Авроре закупят для врачей и учителей []


Новости FOSS организаций


  1. 50 лучших авторов Opensource.com [(en)]
  2. Компания Open Source Security спонсирует разработку gccrs []
  3. Взлом форума проекта OpenWRT []
  4. Microsoft: пришло время для всех компаний принять участие в Open Source [(en)]
  5. AWS хочет убедить клиентов перейти на Linux [(en)]
  6. Отчёт о развитии FreeBSD за четвёртый квартал 2020 года []
  7. Еженедельник OSM 547 []
  8. Сизифу исполнилось 20 лет! Российский репозиторий свободного программного обеспечения отмечает юбилей []

Юридические вопросы


Нарушение авторского права в хранителе экрана GNOME и производных проектах []


Ядро и дистрибутивы


В Ubuntu 21.04 решено не переходить на GTK4 и GNOME 40 []


Системное


Ошибка в патчах FreeNAS, вызывающая скрытое повреждение данных в ZFS []


Специальное


  1. ЗапускWindows приложений Linux существенно ускорен [(en)]
  2. Amazon и Logz.io объявили о создании форков Elasticsearch [ 1, 2, 3(en)]

Обучение


Linux Foundation и Blacks In Technology вкладывают $100,000 в обучение и сертификацию [(en)]


Мобильные


  1. О гибернации приложений в Android 12 [(en)]
  2. Смартфон PinePhone теперь и на Debian Linux []
  3. В Android 12 ожидается улучшенная многозадачность [(en)]
  4. Похоже что в Android 12 будет добавлена одна из лучших возможностей iOS шаринг доступа к Wi-Fi сетям [(en)]
  5. Android смартфоны дешевеют в два раза быстрее чем iPhone [(en)]
  6. Redmi Note 9 серия получит обновление до Android 11 [(en)]
  7. Дата выхода Android 12, слухи и ожидания [(en)]
  8. Android портирован для плат на архитектуре RISC-V []
  9. Android 12 может получить поддержку скрытой функции двойного тапа по сканеру отпечатков пальцев для выполнения специальных действий, убранной из Android 11 [(en)]

Безопасность


  1. Критический баг вWordPress плагине [(en)]
  2. Новый ботнет FreakOut угрожает Linux системам с необновлённым ПО [ 1(en), 2(en)]
  3. Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS [ 1, 2, 3(en), 4(en)]
  4. pfSense добавляет поддержку WireGuard VPN [(en)]

DevOps


В Debian разрешено встраивание зависимостей в пакет Kubernetes []


Web


  1. В браузер Brave встроена поддержка распределённой сети IPFS []
  2. Упрощение установки дополнений к мобильной версии Firefox [(en)]

Для разработчиков


  1. PHP 8 продолжает развитие опенсорсного языка программирования []
  2. Новость для авторов тем Plasma: в версии 5.21 появились настраиваемые зоны отступа []

Пользовательское


  1. На этой неделе в KDE: перекомпоновка текста в Konsole []
  2. В текстовом редакторе Kate был обновлён диалог Быстрый переход []

Железо


  1. Проект Raspberry Pi представил плату Pico на основе собственного микроконтроллера [ 1, 2, 3(en), 4(en), 5(en), 6(en)]
  2. Торвальдс критикует Intel за то, что в потребительских устройствах не используется память с ECC [(en)]

Разное


Из-за патентов поддержка H.263 в Ruffle, эмуляторе Flash Player, остаётся под вопросом []


Статьи


Внедрения


Подготовка к импортозамещению, или Куда бежать, на что смотреть и к кому обратиться за помощью []


DIY


3 идеи сетевого проекта для Raspberry Pi [(en)]


Ядро и дистрибутивы


UbuntuDDE: замечательный гибрид []


Системное


Заметки о Unix: система управления заданиями и использование SIGCHLD в (BSD) Unix []


Специальное


  1. ExpressLRS: RC Open Source протокол с низкой латентностью и высокой дальностью [(en)]
  2. Как установить Oracle VM VirtualBox Extension Pack []
  3. Nextcloud открытая альтернатива целому ряду облачных приложений для совместной работы и управления задачами [(en)]
  4. Немного о производительности снапшотов QEMU []
  5. Изучаем ELK. Часть I Установка Elasticsearch []

Обучение


4 больших урока из Open Source интернства [(en)]


Базы данных


Поточное резервирование базы данных, передача по сети и восстановление с конвертацией из FB 2.5 в FB 3.0 []


Мультимедиа


  1. Haruna Video Player: открытый фронтенд к MPV на основе Qt для Linux [(en)]
  2. Лучшие видеоплееры для Linux []

Мобильные


ЛучшиеAndroid планшеты в 2021: какой выбрать? [(en)]


Безопасность


  1. О защите приватности с помощью ProtonVPN [(en)]
  2. О защите Linux сервера с помощью Crowdsec REST API [(en)]

DevOps


  1. Как сократить время сборки образов Docker в GitLab CI []
  2. Прогресс shell-operator и addon-operator: хуки как admission webhooks, Helm 3, OpenAPI, хуки на Go и многое другое []
  3. Знакомство с типичными примерами использования встроенных функций Terraform []
  4. Григорий Кошелев А вы Кафку пробовали []
  5. РасцветSRE и автоматизации: прогнозы на 2021 от Puppet [(en)]
  6. Как установить файл конфигурации в .Net Core Console app для нескольких сред разработки при запуске Docker-контейнера []
  7. НастройкаLinux облака на голом железе [(en)]
  8. Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS []
  9. Тонкости настройки CI/CD: как работает GitLab runner, когда использовать Docker-in-Docker и где пригодится Argo CD []
  10. Идеи Docker проектов, которые стоит попробовать сделать [(en)]
  11. Режим высокой доступности HashiCorp Vault (HA) []
  12. Представляем Quarkus на Red Hat OpenShift []
  13. Неужели нельзя обойтись без кафок и рэббитов, когда принимаешь 10 000 ивентов в секунду []
  14. О наборе инструментов дляDevOps инженера [(en)]
  15. О KubeEdge, фреймворке для граничных (edge) вычислений [(en)]
  16. Функции Terraform []
  17. Хранение данных в Docker []
  18. Как я сдавал Certified Kubernetes Security []

AI & Data Science


  1. Нападения на полицейских в США: статистический обзор []
  2. 10 лучших статей о Data Science по версии Opensource.com [(en)]
  3. Руководство по MLflow платформе для управления жизненным циклом машинного обучения [(en)]
  4. Технологии, стоящие за моделями машинного обучения для прогнозирования COVID от Facebook [(en)]
  5. Open Source проект недели по версии SD Times: Apache Superset [(en)]
  6. Руководство по TadGAN (с Python кодом) [(en)]

Web


Об обеспечении совместимости Firefox с новыми ARM процессорами от Apple [(en)]


Для разработчиков


  1. git-ssb децентрализованный хостинг git-репозиториев []
  2. Как пересчитать электронную таблицу []
  3. 10 статей о том как начать участвовать в Open Sourece в 2021 [(en)]
  4. Проект arataga: реальный пример использования SObjectizer и RESTinio для работы с большим количеством HTTP-соединений []
  5. КакGitHub Actions улучшают процесс разработки и экспертизы ПО [(en)]
  6. Перехват и обработка событий в файловой системе Linux []
  7. Изучение JavaScript через написание игры [(en)]
  8. GIT-ветвление и попытка не запутаться []
  9. Maple Tree новая структура данных для ядра Linux, решающая сложные проблемы [(en)]
  10. Как PVS-Studio ELKI в январе проверяли []
  11. CLR vs JVM: сводки с полей боёв [(en)]
  12. Об обеспечении безопасности Java приложений [(en)]

Пользовательское


  1. Кунг-фу стиля Linux: запуск команд []
  2. Руководство по кастомизации KDE: 11 способов как изменить вид GNU/Linux десктопа [(en)]
  3. Настройка минимального сервера на Raspberry Pi [(en)]
  4. Выделенный текст не виден в тёмной теме в gedit? Чиним это [(en)]
  5. О приложениях для ведения дневника [(en)]
  6. Как удалять приложения из Ubuntu Linux [(en)]
  7. Перенос Windows в виртуальную машину на GNU/Linux [(en)]
  8. Настройка XFCE4 Linux десктопа через командную строку [(en)]
  9. Команда stat в Linux []
  10. Открытые программы для планирования встреч[(en)]

Железо


Raspberry Pi 4 теперь используется для целых умных домов [(en)]


Релизы


Ядро и дистрибутивы


  1. Новая версия российского дистрибутива Astra Linux Common Edition 2.12.40 [ 1, 2]
  2. Выпуск GhostBSD 21.01.15 []
  3. Видео обзор Linux Mint 20.1. Что нового []
  4. Обновление OPNsense 20.7.8 с новым плагином телеметрии os-hw-probe []
  5. Обновление OpenWrt 19.07.6 []
  6. Релиз дистрибутива Alpine Linux 3.13 []

Системное


Релиз системы самодостаточных пакетов Flatpak 1.10.0 [ 1, 2, 3, 4]


Специальное


  1. Выпуск Venus 0.9, реализации платформы хранения FileCoin []
  2. Выпуск GNU Radio 3.9.0 []
  3. Выпуск VirtualBox 6.1.18 []

Мультимедиа


  1. Выпуск редактора векторной графики Inkscape 1.0.2 и начало тестирования Inkscape 1.1 []
  2. Krita 4.4.2. Mesh градиенты и преобразования. Что нового []
  3. Релиз медиа-проигрывателя VLC 3.0.12. Поддержка Apple M1 []

Безопасность


  1. Релиз системы обнаружения атак Snort 3 [ 1, 2(en)]
  2. Выпуск криптографической библиотеки Libgcrypt 1.9.0 []

DevOps


Что нового добавилось в Terraform v0.13 []


Web


  1. Релиз Chrome 88 [ 1, 2(en), 3(en)]
  2. Выпуск интегрированного набора интернет-приложений SeaMonkey 2.53.6 []

Для разработчиков


  1. Релиз goredo 1.0.0, реализации системы сборки redo, предложенной DJB []
  2. Выпуск среды разработки PascalABC.NET 3.7.2 []
  3. Обновление редактора кода CudaText 1.122.5 []

Пользовательское


  1. Архиватор GNU tar 1.33. Релиз спустя 2 года []
  2. Argos Translate программа для машинного перевода с поддержкой русского языка []
  3. GNU nano 5.5 []
  4. Выпуск файлового менеджера Midnight Commander 4.8.26 []
  5. Доступна бета-версия KDE Plasma 5.21 []

Что ещё посмотреть


Подборка новостей за январь 2021 от Linux Foundation: распродажа курсов по облачным технологиям (закончилась :(), анализ атак типа SolarWinds Orion, новые Kubernetes & WebAssembly курсы, серии вебинаров LFX [(en)]


Заключение


На этом всё, до следующего воскресенья!


Высказываю большое спасибо редакции и авторам OpenNET [] много новостных материалов и сообщений о новых релизах взято у них.


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


Подписывайтесь на наш Telegram канал, группу ВКонтакте или RSS чтобы не пропустить новые выпуски FOSS News.


[] Предыдущий выпуск

Подробнее..

Русификация баша

08.01.2021 06:09:33 | Автор: admin

Чтож... Начну с откашливаний - я не писака ( в хорошем смысле этого слова, писать " на поток" это надо уметь), хоть и немного писатель. И даже не очень уверен в том, что я хочу вам сегодня поведать.
Но моей Прокрастинации нет границ, так что пристёгивайте ремни, это будет ухабистая поездка!)

Вступление

Началось всё с комментария моего хорошего знакомого @Oxyd, который меня заинтересовал.
Я уже до этого успел с ним подискутировать на тему русского в програмировании ( безответно) ), и не мог пропустить такой шанс. Да и интересно стало) Поэтому появился первый сферический прототип в вакууме:

Из $1 выбрать  Демон) запустить $скрипт/демон.об;;  Аминь) запустить $скрипт/демон.об очистка;;ГотовоЕсли [ $2 ]; тогда  вывести "| $ном_проц | $путь_окр |"илсе# Местная подсветка синтаксиса совершенно не понимает что твориться :D

Это было забавно и интересно, но как-то... синтетически, что ли.
Поэтому я остался недоволен и, вспомнив что в моём любимом баше есть alias-ы (синонимы для команд), решил переписать целый скрипт на русский bash.

Русифицированный bash

Мой выбор пал на другой шуточный проект, window slicer. Он был вдохновлён не менее шуточным проектом с reddit, предназначенным для другого оконного менеджера.
Вкратце, этот скрипт разделяет окно надвое на основе координат курсора и заданного направления. Если привязать его к любому демону "мышиных" жестов, то можно сыграть в забавный аналог известной игры Fruct Ninja, только с окнами вместо фруктов)

Несколько тестов в оболочке спустя я был готов к переписыванию, только уже на zsh - аналог bash. Почему, спрашивается, ведь в названии статьи указан баш?
Ответ прост - bash не понимает переменных на кириллице. Увы)
Но разница между ними незаметна для нашей темы, поэтому будем считать что мы просто работаем с оболочкой.
Всё равно слово "баш" время от времени используют для её обозначения.

И вот, собственно, что получилось:

#! /bin/zsh# Магия, не подглядывай!ТЕРМИНАЛ=$TERMalias если="if" \      тогда="then" \      илсе="fi" \      из="case" \      выбрать="in" \      готово="done" \      вывод="echo" \      оценить="eval" \      пока="until" \      делаем="do" \      спим="sleep" \      иначе="else" \      иначе_если="elif"# Собственно программа# Объявляем переменныеX=0Y=0x_окна=0y_окна=0ширину_окна=2высоту_окна=2приложение=$ТЕРМИНАЛ# Количество окон до старта. Костыль \_()_/кол_окон=$(i3-msg -t get_tree | jq -r '.. | .nodes?[]? | select(.window_type == "normal") | .name' | wc -l)# Получаем координаты курсораоценить $(xdotool getmouselocation --shell)# Получаем параметры окна от i3wmоценить $( i3-msg -t get_tree | jq -r '..|try select(.focused == true)| "x_окна=\(.rect.x)\ny_окна=\(.rect.y)\nширину_окна=\(.rect.width)\nвысоту_окна=\(.rect.height)\nприложение=\(.window_properties.instance)"' )ждём(){    пока [ $кол_окон -lt $нов_кол_окон ];    делаем        нов_кол_окон=$(i3-msg -t get_tree | jq -r '.. | .nodes?[]? | select(.window_type == "normal") | .name' | wc -l)        спим 0.1    готово}рубим(){    разница=$(( $1 / 2 - ($2 - $3) )) # количество пикселей от от центра окна до места "рубки"    i3-msg split "$5" && $приложение & disown && ждём    # Подтягиваем новое окно до нужного размера    если [ $разница -gt 0 ]; тогда        i3-msg resize grow "$4" "$разница"    иначе        разница=$(( разница * - 1 ))        i3-msg resize shrink "$4" "$разница"    илсе}если [ "$1" = "гор" ]; тогда рубим $высоту_окна $Y $y_окна height vиначе_если [ "$1" = "вер" ]; тогда рубим $ширину_окна $X $x_окна width hилсе

Для удобства и домашнего насилия изучения есть ссылка на gist

Анализ

Честно говоря, я отделался лёгким испугом.Оказывается 13 алиасов и переменных на русском с головой достаточно для полной трансформации кода. Я был готов расписать весь скрипт чуть ли не побуквенно, но после очередного прочтения и добавления пары коментариев это оказалось просто не нужно.
Небольшой хитростью было оставить все обращения к "внешним" программам нетронутыми, но это можно назвать вынужденной мерой - реализация полного перевода явно выходит за рамки проекта just for fun. Так же пришлось притянуть за уши слово "оценить", потому как в русском нету красивого слова со значением "одарить/придать/задать/дать значение/цену" - аналога evaluate.
Тем не менее, результат уже на лицо и любой не знающий английского IT-шник (есть такие, интересно?) мгновенно поймёт функцию скрипта и даже его структуру, с поправкой на неведомый механизм добычи переменных (коментарии помогут).
Искать ошибки проще, делиться тоже, казалось бы, всё прекрасно, но не тут то было!

Писать этот код было ужасно неудобно. Вот совсем. Отчасти в этом виноват мой editor-of-choise, vim, который не дружит с русской раскладкой для хоткеев. Но даже если убрать его из уравнения, в русской раскладке просто нету нужных символов!
Все необычные скобки, доллар, амперсант и всё что я не вспомнил приходилось писать на английской расскладке. А уж ошибок из-за привычек привязанных к раскладками ( как примеры написание точек, запятых и кавычек) просто не счесть.

Можно ли считать это большой проблемой? По хорошему да. У нас нету нужных клавиатур, нету нужных символов под рукой, нету нужных привычек...
Но этот вопрос я оставлю для статьи с которой всё это началось, О русском языке в програмировании.

Моё мнение

  1. Это действительно удобно для понимания кода. Можно советовать новичкам, а то и вовсе написать транслятор, который будет выводить привычный код в "читабельном" виде. Наверняка пригодится на обсуждениях логики работы.

  2. Писать это неудобно. Может разработкой языка заточеного под русскую раскладку и решаться некоторые проблемы, но таких маловато. ( и я не пробовал )
    Так же возможно поможет IDE, но это надо проверять.

  3. Лично я этим пользоваться не буду. Я свободно владею английским и потому в моей голове происходит ровно то же проговаривание, при чём без перевода. А вот людям не знающим английского свободно посоветую хотя бы попробовать.

И в общем-то на этом всё. Не так страшен чёрт как его рисуют)

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

Подробнее..

Systemd для продолжающих. Part 1 Запуск юнитов по временным событиям

02.01.2021 20:04:09 | Автор: admin

Всем привет! В последнее время я вплотную занимаюсь исследованием возможностей systemd и решил поделиться результатом исследований с сообществом, в виде небольшого (или большого, как пойдёт ;-) цикла статей. Итак первым (уже нет) номером нашей программы будет запуск юнитов по различным событиям происходящим во время работы ОС. В качестве исследовательской платформы будет выступать Manjaro Linux c systemd v247.2. И... да. Некоторые события, вынудили меня написать внеочередную статью, которая взлетела на вершину хит-парада, а опрос показал, что тема актуальна и вызывает интерес, так что погнали!

Пролог

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

pacman -Ql $(pacman -Qsq systemd|xargs)|egrep '^systemd\s|^systemd-sysvcompat\s'|egrep "man/man[1|5|8]/[[:print:]]*\.gz"|wc -l278

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

pacman -Ql $(pacman -Qsq systemd|xargs)|egrep '^systemd\s|^systemd-sysvcompat\s'|wc -l1852

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

Disclamer: Хоть в официальной документации и манах почти не используется такое понятие как триггеры (хотя и используется triggered by), но все те штуки которые описаны в этой и следующей статье, по сути, именно ими и являются. Это сущности которые срабатывают по каким-либо событиям, поэтому не удивляйтесь, если я, авторским произволом, буду использовать этот термин.

Часть первая, очевидная. Таймеры.

Все мы знаем старый, добрый cron, во всех его проявлениях. Созданный ещё в 80-х, он, в том или ином виде, дожил до нашего времени облачных сервисов. Так-же мы все знаем его ограничения. Например одной строчкой невозможно заставить крон запускать произвольный бинарник/скрипт раз в полтора часа, начная с часа ночи, приходится описывать такое событие двумя строчками. Что-бы обойти ограничения классического крона, в systemd были придуманы такие триггеры как таймеры (юниты с окончанием *.timer) умеющие запускать произвольные сервисы или группы сервисов (*.target) периодически; по наступлении какого-либо времени; по выходу системы из спящего режима; по календарному событию (наподобие того как это делает другой ветеран Unix утилит, команда at), а так-же по другим событиям, не связанными, напрямую, со временем.

Для начала что запускаем. Возьмём, для примера, таймер man-db.timer из комплекта поставки одноимённого пакета:

$ cat /usr/lib/systemd/system/man-db.timer[Unit]Description=Daily man-db regenerationDocumentation=man:mandb(8)[Timer]OnCalendar=dailyAccuracySec=12hPersistent=true[Install]WantedBy=timers.target

Простой, коротенький таймер. Но в чём-же дело, почему не указано что мы запускаем? Всё нормально! По умолчанию, если в секции [Timer] отсутствует параметр Unit=, с указанием запускаемого юнита, systemd будет искать одноимённый *.service юнит. Проверяем!

$ cat /usr/lib/systemd/system/man-db.service[Unit]Description=Daily man-db regenerationDocumentation=man:mandb(8)ConditionACPower=true[Service]Type=oneshot# Recover from deletion, per FHS.ExecStart=+/usr/bin/install -d -o root -g root -m 0755 /var/cache/man# Expunge old catman pages which have not been read in a week.ExecStart=/usr/bin/find /var/cache/man -type f -name *.gz -atime +6 -delete# Regenerate man database.ExecStart=/usr/bin/mandb --quietUser=rootNice=19IOSchedulingClass=idleIOSchedulingPriority=7

Да, вот он сервис который ежедневно пересоздаёт базу данных страниц руководства. Сервис стартует начиная с 00:00 (OnCalendar=daily) , с точностью 12 часов (AccuracySec=12h), то-есть он может сработать в любой момент между полуночью и полднем, в зависимости от загрузки системы:

$ systemctl status man-db.timer  man-db.timer - Daily man-db regeneration     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled)     Active: active (waiting) since Thu 2020-12-31 23:18:59 MSK; 1 day 19h ago    Trigger: Sun 2021-01-03 00:00:00 MSK; 5h 30min left   Triggers:  man-db.service       Docs: man:mandb(8)дек 31 23:18:59 dell-lnx systemd[1]: Started Daily man-db regeneration.

Минимальная точность у параметра AccuracySec= 1us! Чем больше этот параметр, тем меньше нагрузка на систему. Если параметр отсутствует, то по умолчанию (указано в /etc/systemd/system.conf: DefaultTimerAccuracySec=) он равен одной минуте. Ладно, это всё лирика, давайте быстренько пробежимся по другим возможным параметрам секции [Timer], а на сладкое оставим параметры задания времени в OnCalendar= и других временнх параметрах.

Монотонные таймеры, для периодических событий

  • OnBootSec= Таймер сработает через указанное время после старта системы.

  • OnStartupSec= Для системных таймеров действие аналогично предыдущему, для пользовательских таймеров, это время после первого логина пользователя в систему.

  • OnActiveSec= Один из параметров для периодического запуска. Через какое время, после реального времени срабатывания таймера, запускать юнит.

  • OnUnitActiveSec= Триггер будет ориентироваться на время последнего запуска целевого юнита.

  • OnUnitInactiveSec= Триггер будет ориентироваться на последнее время завершения работы целевого юнита. Хорошо для долгоиграющих сервисов. Бэкапы и вот это вот всё. Все эти таймеры можно комбинировать между собой и с таймером OnCalendar=.

Прочие параметры

  • RandomizedDelaySec= Этакий рандомный джиттер. Перед срабатыванием добавляется случайный таймаут от нуля, до заданного значения. По умолчанию -- отключено.

  • OnClockChange=, OnTimezoneChange= Булевые параметры, определяющие будет-ли таймер реагировать на перевод системных часов или смену временной зоны. По умолчанию, оба параметра, false.

  • Persistent= Записывать-ли на диск состояние таймера сразу после запуска юнита. Актуально для параметра OnCalendar=. По умолчанию false.

  • WakeSystem= Ещё один логический параметр. Действует на монотонные таймеры. По умолчанию отключён. Логика следующая. При отключённом параметре все монотонные таймеры запоминают своё состояние, перед уходом системы в спящий режим и встают на паузу. После выхода системы из спящего режима, отсчёт продолжается с того момента с которого система ушла в спячку. Если-же параметр поставить в true, то таймеры продолжают работать и в спящем режиме (должно поддерживаться и железом) и по наступлении события выводят систему из спячки и запускают юнит.

  • RemainAfterElapse= Последняя крутилка, по умолчанию true Смысл этого параметра примерно следующий, После срабатывания таймера он остаётся загруженным, но если поставить false, то после срабатывания таймер выгружается и перестаёт отслеживать время. Хорошо для одноразовых юнитов (Transient Units) о которых мы поговорим в одной из следующих статей. Или для таймеров которые должны сработать один раз, как это делают задания старой, доброй at.

Таймстампы, диапазоны, тестирование, примеры

Ну и наконец зачем это всё. Чем хороши таймеры, так это тем, что всяческие сложные временные метки задаются гораздо проще чем в cron и задача запуска сервиса раз в полтора часа, начиная с часа ночи, выглядит куда приятнее. В самом простом случае она будет выглядеть так:

[Unit]Description=Test timer[Timer]OnCalendar=01:00OnActiveSec=1.5h

Ну это слишком просто. Например мы хотим что-б наш юнит запускался каждую пятницу 13-е OnCalendar=Fri *-*-13 12:00:00 Полный формат календарной формы выглядит так: Mon 2025-12-01 00:00:00.000000 Europe/Moscow Поэтому мы можем запускать таймер по времени другого часового пояса (по умолчанию текущий) Например хотим что-б таймер прислал нам уведомление, что Камчатка уже отпраздновала Новый год: OnCalendar=yearly Asia/Kamchatka Нормализованная форма будет выглядеть так(эти строчки указывают на одно и то-же время):
OnCalendar=*-01-01 00:00:00 Asia/Kamchatka Алиасы (и их эквиваленты в нормализованной форме) могут быть такими:

                       minutely  *-*-* *:*:00                         hourly  *-*-* *:00:00                          daily  *-*-* 00:00:00                        monthly  *-*-01 00:00:00                         weekly  Mon *-*-* 00:00:00                         yearly  *-01-01 00:00:00                      quarterly  *-01,04,07,10-01 00:00:00                                                                         semiannually  *-01,07-01 00:00:00

Примеры валидных таймстампов:

таймстамп с @ epoch time
        Fri 2012-11-23 11:12:13  Fri 2012-11-23 11:12:13            2012-11-23 11:12:13  Fri 2012-11-23 11:12:13        2012-11-23 11:12:13 UTC  Fri 2012-11-23 19:12:13                     2012-11-23  Fri 2012-11-23 00:00:00                       12-11-23  Fri 2012-11-23 00:00:00                       11:12:13  Fri 2012-11-23 11:12:13                          11:12  Fri 2012-11-23 11:12:00                            now  Fri 2012-11-23 18:15:22                          today  Fri 2012-11-23 00:00:00                      today UTC  Fri 2012-11-23 16:00:00                      yesterday  Fri 2012-11-22 00:00:00                       tomorrow  Fri 2012-11-24 00:00:00      tomorrow Pacific/Auckland  Thu 2012-11-23 19:00:00                       +3h30min  Fri 2012-11-23 21:45:22                            -5s  Fri 2012-11-23 18:15:17                      11min ago  Fri 2012-11-23 18:04:22                    @1395716396  Tue 2014-03-25 03:59:56

Здесь представлены таймстампы как для OnCalendar=, так и для монотонных таймеров.

Перечисления и диапазоны:

Боольшой список примеров
      Sat,Thu,Mon..Wed,Sat..Sun  Mon..Thu,Sat,Sun *-*-* 00:00:00          Mon,Sun 12-*-* 2,1:23  Mon,Sun 2012-*-* 01,02:23:00                        Wed *-1  Wed *-*-01 00:00:00               Wed..Wed,Wed *-1  Wed *-*-01 00:00:00                     Wed, 17:48  Wed *-*-* 17:48:00    Wed..Sat,Tue 12-10-15 1:2:3  Tue..Sat 2012-10-15 01:02:03                    *-*-7 0:0:0  *-*-07 00:00:00                          10-15  *-10-15 00:00:00            monday *-12-* 17:00  Mon *-12-* 17:00:00      Mon,Fri *-*-3,1,2 *:30:45  Mon,Fri *-*-01,02,03 *:30:45           12,14,13,12:20,10,30  *-*-* 12,13,14:10,20,30:00                12..14:10,20,30  *-*-* 12..14:10,20,30:00      mon,fri *-1/2-1,3 *:30:45  Mon,Fri *-01/2-01,03 *:30:45                 03-05 08:05:40  *-03-05 08:05:40                       08:05:40  *-*-* 08:05:40                          05:40  *-*-* 05:40:00         Sat,Sun 12-05 08:05:40  Sat,Sun *-12-05 08:05:40               Sat,Sun 08:05:40  Sat,Sun *-*-* 08:05:40               2003-03-05 05:40  2003-03-05 05:40:00     05:40:23.4200004/3.1700005  *-*-* 05:40:23.420000/3.170001                 2003-02..04-05  2003-02..04-05 00:00:00           2003-03-05 05:40 UTC  2003-03-05 05:40:00 UTC                     2003-03-05  2003-03-05 00:00:00                          03-05  *-03-05 00:00:00                         hourly  *-*-* *:00:00                          daily  *-*-* 00:00:00                      daily UTC  *-*-* 00:00:00 UTC                        monthly  *-*-01 00:00:00                         weekly  Mon *-*-* 00:00:00        weekly Pacific/Auckland  Mon *-*-* 00:00:00 Pacific/Auckland                         yearly  *-01-01 00:00:00                       annually  *-01-01 00:00:00                          *:2/3  *-*-* *:02/3:00

Да. Микро и наносекунды тоже поддерживаются, а ещё очень удобная функция конца месяца и счётчик:

  • *-*~01 Первый день с конца каждого месяца (он-же последний день месяца).

  • *-05~05 27-e мая каждого года (31-5).

  • Mon *-12~07/1 Последний понедельник декабря.

  • Mon *-12-01/3 Третий понедельник декабря.

Проверять таймстампы на валидность можно при помощи утилиты systemd-analyze:

$ systemd-analyze calendar 'Mon *-12-01/1'  Original form: Mon *-12-01/1              Normalized form: Mon *-12-01/1 00:00:00         Next elapse: Mon 2021-12-06 00:00:00 MSK       (in UTC): Sun 2021-12-05 21:00:00 UTC       From now: 11 months 2 days left$ systemd-analyze timespan 1.5hOriginal: 1.5h            s: 5400000000   Human: 1h 30min$ systemd-analyze timestamp 01:00:30.9999  Original form: 01:00:30.9999              Normalized form: Sat 2021-01-02 01:00:30 MSK       (in UTC): Fri 2021-01-01 22:00:30 UTC   UNIX seconds: @1609538430.999900                From now: 18h ago 

Вот так, в принципе, всё просто, логично и красиво. И разумеется напочитать:

man systemd.timerman systemd.timeman systemd-system.confman systemd-analyzeman tzselect

Список статей серии

  1. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

  2. Systemd для продолжающих. Part 1 Запуск юнитов по временным событиям

Подробнее..

Systemd для продолжающих. Part 2 Триггеры на различные события

14.01.2021 10:07:09 | Автор: admin

Продолжаем цикл популярного балета, под названием Systemd для продолжающих. В этой части, являющейся логическим продолжением предыдущей, поговорим о различных триггерах не связанных со временем. Эта часть будет не такой объёмной, но, не менее интересной. Вперёд!

Systemd.path триггер на события в файловой системе

Как известно, linux имеет большое количество системных вызовов, среди которых имеется замечательный вызов inotify() , позволяющий вешать обработчики на события в файловой системе на создание, удаление, изменение etc, файлов и каталогов. Наиболее распространёнными утилитами, использующими inotify() являются утилиты inotifywait и inotifywatch из пакета inotify-tools, которые хорошо использовать в скриптах, а так-же проект incron cron для файловой системы, о котором уже писали на Хабре. Systemd тоже имеет специальные юниты, которые хоть и ограничены по функционалу (я надеюсь пока), по сравнению с incron и тем более с inotify-tools , но зато умеют запускать юниты systemd.

Практическое применение systemd.path

Вот такой триггер пришлось ваять одному товарищу, когда он захотел использовать дискретную видеокарту, в качестве основной, на своём ноутбуке (предвидя вопрос... Нет, параметра ядра для этой фигувины нет):

$ cat /etc/systemd/system/enable-radeon.path[Unit]Description=Enable radeon path[Path]PathExists=/sys/kernel/debug/vgaswitcheroo/switch[Install]WantedBy=multi-user.target

Всё то-же самое, как и в случае с таймерами. Если в основной секции, в данном случае [Path], не указана директива Unit=, ищем и запускаем одноимённый *.service:

$ cat /etc/systemd/system/enable-radeon.service[Unit]Description=Enable radeon service[Service]Type=oneshotRemainAfterExit=yesExecStart=/usr/bin/sh -c "echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch"[Install]WantedBy=multi-user.target

Итак всё просто. Энейблим *.path sudo systemctl enable enable-radeon.path и, во время загрузки, как только в дереве файловой системы появляется файл (PathExists=) /sys/kernel/debug/vgaswitcheroo/switch, запускаем соответствующий сервис.

Возможные директивы слежения для systemd.path

К сожалению их мало, но базовые потребности для старта каких-либо юнитов они, в принципе, покрывают:

  • PathExists= Триггерится на появление файла или директории, в файловой системе.

  • PathExistsGlob= То же самое что и предыдущая директива, но можно использовать файлы / каталоги по маске.

  • PathChanged= Если в файле или каталоге произошли изменения, при этом он не будет реагировать на каждый вызов write(), а сработает только после первого close()

  • PathModified= Подобно предыдущему, только в этом случае не ждём close(), а сразу реагируем на первый попавшийся write().

  • DirectoryNotEmpty= Как понятно из названия срабатывает только в отношении директорий, когда в директории появляется хотя-бы один файл.

Все эти директивы можно комбинировать между собой в одном юните, в том числе можно в одном юните следить за разными файлами и каталогами. Внимание! Если в каком-либо из этих параметров указана пустая строка, остальные параметры сбросятся и ваш *.path никогда не сработает.

Дополнительные параметры

  • Unit= Юнит для запуска. Важное замечание, о котором я забыл в предыдущей статье. В параметре Unit= не обязательно может быть *.service, но и любой другой (кроме *.path) юнит. Например *.mount.

  • MakeDirectory= Булевый параметр. Создавать-ли каталоги слежения. По умолчанию false.

  • DirectoryMode= Связанный с предыдущим параметром параметр раздачи прав на создаваемую директорию. По умолчанию 0755.

Сравнение функционала systemd.path c incron и inotify-tools

В таблице пропущено парочка специфичных для incron параметров.

Функция

systemd.path

inotify-tools

incron

read

access

IN_ACCESS

write

PathModified=

modify

IN_MODIFY

attrib

attrib

IN_ATTRIB

close & write

PathChanged=

close_write

IN_CLOSE_WRITE

close

close_nowrite

IN_CLOSE_NOWRITE

open

open

IN_OPEN

moved to watched

moved_to

IN_MOVED_TO

moved from watched

moved_from

IN_MOVED_FROM

moved self

moved_self

IN_MOVE_SELF

create

PathExist= PathExistGlob= DirectoryNotEmpty=

create

IN_CREATE

delete

delete

IN_DELETE

delete self

delete_self

IN_DELETE_SELF

unmount

unmount

systemd support

yes

И да, чуть не забыл. Все утилиты использующие inotify() работают только и исключительно на локальных файловых системах. То-есть, например, на SMB / NFS они работать не будут, но при этом спокойно будут работать в /run, /sys, /proc!

Systemd.automount триггеры автомонтирования ФС

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

Практика

Сразу два примера. Для автомонтирования локальной и удалённой файловой системы. Два *.automount и два *.mount юнита к ним в пару. В отличие от *.timer и *.path юнитов в случае автомаунта отсутствует директива Unit=, поэтому используется или одноимённый persistent *.mount, что предпочтительнее, либо *.mount автоматически сгенерированный из содержимого /etc/fstab.

Первый пример: Локальная файловая система, смонтированная в /boot. По большому счёту, содержимое каталога /boot практически не нужно при работе системы. Исключение обновление ядра и соответственно обновление initrd образов и конфигурации загрузчика, что бывает, не сказать что-бы часто. Поэтому, мы спокойно можем выслать раздел /boot в автомонтирование.

$ cat /etc/systemd/system/boot.automount[Unit]Description=Automount boot partition when needed.[Automount]Where=/boot## Time to automatic umount of inactivityTimeoutIdleSec=120[Install]WantedBy=multi-user.target

И в пару к нему одноимённый *.mount файл:

$ cat /etc/systemd/system/boot.mount[Unit]Description=Boot partition (running by automount) /dev/sda1Documentation=man:systemd.mount(5)After=blockdev@dev-disk-by\x2duuid-ea65285a\x2d01da\x2d451c\x2da93a\x2d4b155c46aeeb.target[Mount]Where=/bootWhat=/dev/disk/by-uuid/ea65285a-01da-451c-a93a-4b155c46aeebType=ext4Options=rw,relatimeDirectoryMode=0755

Всё практически как в fstab, только раскидано по нескольким строчкам. Что происходит в автомаунте: Когда какой-либо процесс пытается прочитать/записать что-то в каталоге /boot или получить его листинг, автомаунт запускает одноимённый юнит *.mount и начинает мониторить обращения к /boot. Через 2 минуты после последнего обращения (TimeoutIdleSec=), раздел будет автоматически отмонтирован.

И второй пример, который я всё никак не соберусь перевести на rclone автомонтирование облака яндекса, когда я к нему обращаюсь.

$ cat /etc/systemd/system/home-oxyd-Clouds-yadisk.automount[Unit]Description=Automount yandex disc when needed.[Automount]Where=/home/oxyd/Clouds/yadiskDirectoryMode=0777## Time to automatic umount of inactivityTimeoutIdleSec=300[Install]WantedBy=multi-user.target

И ответочка к нему:

$ cat /etc/systemd/system/home-oxyd-Clouds-yadisk.mount[Unit]Description=Yandex disk automounted driveDocumentation=man:systemd.mount(8) [Mount]Where=/home/oxyd/Clouds/yadiskWhat=https://webdav.yandex.ru/Type=davfsOptions=noauto,user

Тут тоже всё прозрачно, единственно добавлен параметр раздачи прав для создания директории, если таковой не окажется на законном месте. Да у автомаунта ровно три параметра:

  • Where= Путь который мониторим.

  • TimeoutIdleSec= Таймаут перед автоотмонтированием, если параметр отсутствует, или равен 0 (по умолчанию) раздел не автоотмонтируется.

  • DirectoryMode= права на создание каталога для мониторинга, по умолчанию 0755.

Вот, вкратце, как-то примерно так. И, как всегда, какие маны почитать:

man systemd.pathman 7 inotifyman inotifywaitman inotifywatchman systemd.automountman systemd.mountman systemd-mountman 5 fstabman systemd.time

Список статей серии

  1. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

  2. Systemd для продолжающих. Part 1 Запуск юнитов по временным событиям

  3. Systemd для продолжающих. Part 2 Триггеры на различные события

Ресурсы

  • systemd.io Статьи по внутренней кухне systemd. Частенько упоминается в манах.

  • systemd @ freedesktop.org Основная страница с манами, документацией, видео, блогами и прочими ссылками на ресурсы.

  • @ru_systemd Русскоязычный чат в Telegram. У нас тепло и лампово.

Подробнее..

Как установить SSL сертификат на Onlyoffice docker сборки

14.01.2021 14:20:31 | Автор: admin

Поставив и настроив комьюнити версию этого пакета я столкнулся с тем что нет официальных рекомендаций как сгенерировать и запустить работу этого комплекса по защищенному протоколу используя сертификат от Letsencrypt. Этот короткий туториал поможет вам получить сертификат в течении 5-10 минут без сложных телодвижений.

Итак, поехали по шагам.

Я все делал на системе Ubuntu 18.04 запущенной в режиме ВМ на хост машине Proxmox. Данная ВМ была не единой в пуле этого хоста потому, если кому то понадобится, могу дать свой конфиг работающего решения для реверс прокси HAPROXY

Остановим все контейнеры одной командой docker stop $(docker ps -a -q)

Удалим из системы certbot (если он у вас есть, хотя если вы ставите Onlyoffice на чистую систему его там быть не должно в принципе)

Зайдем на официальный сайт https://certbot.eff.org/ и в выпадающем меню выставим нужные параметры как на скриншоте:

3.1 Кому лень или он не разобрался переходим сразу на готовый линк https://certbot.eff.org/lets-encrypt/ubuntubionic-other Выполняем инструкции с шага 1 по шаг 7 на этой странице. Напомню, в процессе по ссылке - вы должны будете установить пакет snapd, без него не заработает. Просто сделайте и все будет работать без лишних слов.

Запустим в консоли от рута certbot certonly standalone sitename.ru (вместо sitename.ru укажите тот домен на котором будет виден из интернета ваш офисный сервер)

4.1 Если все пройдет Ок - вы получите сообщение что сертификаты сгенерированы и лежат на вашем сервере по адресу: /etc/letsencrypt/live/sitename.ru/fullchain.pem /etc/letsencrypt/live/sitename.ru/privkey.pem

4.2 Далее, переименуем и перенесем в нужный каталог полученные сертификаты

cp /etc/letsencrypt/live/sitename.ru/fullchain.pem app/onlyoffice/CommunityServer/data/certs/onlyoffice.crt

cp /etc/letsencrypt/live/sitename.ru/privkey.pem /app/onlyoffice/CommunityServer/data/certs/onlyoffice.key

Перезагрузим сервер с офисом командой shutdown -r now Так будет надежней и наверняка все сервисы запустятся сами, т.к. сам пакет весьма большой и завязан на связанные между собой сервисы лучше его перезапустить целиком а не стартовать докер контейнеры по одному, так меньше шансов что какой то не запустился.

В принципе всё. Теперь зайдя по адресу sitename.ru вы должны попасть на корректно работающий портал документооборота.

На последок крайне желательно зайти в админку офиса и проверить:

Система подцепила ваш домен:

В настройках вы прописали доменное имя sitename.ru - в противном случае в письмах этого пакета будет некорректный адрес типа https://iuyhgi8798ygiknqwq - такой адрес или вымышленный или присваивается по имени докер контейнера - таким образом ни зайти на сайт, ни скачать документов - ничего. Вот такой вот капризный пакет.

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

На этом всё, позвольте откланяться.

Подробнее..

Автоматическая очистка корзины Yandex.Disk без участия человека

18.01.2021 22:06:54 | Автор: admin

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


Выбора особо нет да и у меня есть халявный Яндекс Диск на котором со всеми бонусами у меня аж 63 Гб, грех не воспользоваться.


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


Давайте потратим минут 10-15 и на год забудем о проблеме, поехали.


Вводные данные на чем у меня все работает:


Ubuntu 18.04Yandex.Disk консольный клиент для одноименного дистрибутива

  1. Зайдем под тем логином из по которого работает ваш ЯД по адресу https://oauth.yandex.ru/ и нажмем кнопочку Зарегистрировать новое приложение



  2. Заполняем поля как указано на скриншоте



  3. В пункте Доступы выберите Яндекс Диск REST API и поставьте галочки как на скриншоте



  4. Спускаемся в самый низ страницы и жмем кнопку Создать приложение



  5. В полученной странице есть все необходимые нам данные, обязательно сохраните их (PS мои реальные данные я удалил но сохранил вам на скрине для наглядности, у вас они будут другие)



  6. Получим токен, зайдем браузером по адресу https://oauth.yandex.ru/authorize?response_type=token&display=popup&client_id=ВАШid где в самом конце укажем ID полученный в шаге 5


  7. На этой странице жмем Разрешить



  8. На этой странице увидим выданный токен, обязательно сохраните его!



  9. Зайдем в консоль вашего сервера под рутом и создадим скрипт


    nano /root/yadisk.sh
    

    В котором пропишем следующие команды


    #!/bin/sh/usr/bin/curl -s -H "Authorization: OAuth ваш_токен" -X "DELETE" https://cloud-api.yandex.net/v1/disk/trash/resources/?path=
    

    где на месте ваш_токен внесем данные из шага 8


  10. Сохраним скрипт и сделаем его исполняемым


    chmod 700 /root/yadisk.sh
    

  11. Дадим команду crontab -e
    в открывшемся окне напишем


    0 3 * * * /root/yadisk.sh > /dev/null 2>&1
    

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



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


Если хотите убедиться что вы все сделали правильно то можете просто запустить эту команду в консоли


/usr/bin/curl -s -H "Authorization: OAuth ваш_токен" -X "DELETE" https://cloud-api.yandex.net/v1/disk/trash/resources/?path=

(не забудьте в эту строку внести ваш_токен)
и убедиться что корзина вашего аккаунта пуста.


На этом разрешите откланяться.

Подробнее..

Утраченный потенциал подсистемы Windows для Linux (WSL)

06.01.2021 10:12:06 | Автор: admin


Если вы несколько лет вообще не следили за Windows 10 и не знаете, что происходит, то пропустили одну вещь очень горячей темой для разработчиков стала подсистема Windows для Linux, она же WSL. Среди программистов очень часто её обсуждают. Действительно, потрясающе интересная штука.

Наконец-то у нас появилась возможность запустить свой инструментарий Linux на Windows наравне с виндовыми программами. А это значит, что больше не нужно изучать странный PowerShell или пользоваться архаичной консолью CMD.EXE.

К сожалению, не всё так радужно. WSL по-прежнему является неким инородным элементом, который отделён от родной среды Windows. В частности, не может взаимодействовать с родными инструментами Windows.

А ведь изначально всё задумывалось совсем иначе, пишет Джулио Мерино (Julio Merino), автор блога для разработчиков jmmv.dev. Подсистема должна была стать совсем другой, но фактически вышел провал, в каком-то смысле.

Чтобы понять причины этого провала, нужно сначала понять различия между WSL 1 и WSL 2 и как переход на WSL 2 закрыл некоторые интересные перспективы.

Обзор архитектуры WSL 1


Давайте сначала взглянем на WSL 1, и первым делом на её странное название. Почему эта функция называется подсистемой Windows для Linux? Разве не наоборот? Это же не подсистема в Linux, которая делает что-то связанное с Windows, а именно наоборот! То есть грамотно она должна называться Подсистема с функциональностью Linux для Windows или Подсистема Linux для Windows или LSW. Откуда путаница?

Есть мнение, что Microsoft была вынуждена выбрать название наоборот, чтобы избежать упоминания чужих торговых марок. Вот слова Рича Тёрнера (Rich Turner), проект-менеджера WSL:


Что ж с другой стороны, такое странное название технически можно считать корректным, если внимательно изучить архитектуру ядра Windows NT. На странице Архитектура Windows NT в Википедии мы находим следующее:



Пользовательский режим Windows NT состоит из подсистем, передающих запросы ввода-вывода соответствующему драйверу режима ядра посредством менеджера ввода-вывода. Есть две подсистемы на уровне пользователя: подсистемы окружения (запускают приложения, написанные для разных операционных систем) и интегрированные или внутренние подсистемы (управляет особыми системными функциями от имени подсистемы окружения). Режим ядра имеет полный доступ к аппаратной части и системным ресурсам компьютера.

Windows NT разработана с нуля для поддержки процессов, запущенных из множества операционных систем, а Win32 был просто одной из этих подсистем окружения. На такой платформе WSL 1 предоставляет новую подсистему окружения, подсистему Linux, для запуска бинарников Linux поверх ядра Windows NT. У подсистем окружения Win32 и Linux должна быть одна общая интегральная подсистема.

Что всё это на самом деле значит?

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

Способ, которым процесс выполняет системные вызовы, и семантика этих системных вызовов специфичны для операционной системы. Например, на старых х86 это выглядит так: открытие файла в системе Win32 системный вызов 17h, который инициируется через прерывание INT 2EH, а при открытии файла в системе Linux это системный вызов 5h, который инициируется через прерывание INT 80х.

Но концептуально открытие файла это открытие файла, верно? Нам особенно не интересно, что номера системных вызовов или номера прерываний отличаются друг от друга. И в этом заключается ключевой аспект дизайна WSL 1: подсистема Linux в ядре NT это, проще говоря, реализация уровня системных вызовов Linux перед ядром NT. Эти системные вызовы позже делегируются примитивам NT, а не вызовам Win32. Самое главное: нет никакого перевода с системных вызовов Linux на системные вызовы Win32.

В каком-то смысле это подвиг архитектурной мысли и реальной программной разработки, учитывая в целом хорошую поддержку Linux-приложений под WSL 1 и помня о множестве реальных внутренних отличий NT от Unix, когда Windows вообще нативно не воспринимает стандартную юниксовую логику forkexec.

Истинная красота этой конструкции заключается в том, что на машине работает одно ядро, и это ядро имеет целостное представление обо всех процессах под ним. Ядро знает всё о процессах Win32 и Linux. И все эти процессы взаимодействуют с общими ресурсами, такими как единый сетевой стек, единый менеджер памяти и единый планировщик процессов.

Причины для создания WSL 2


Если WSL 1 так крут, то зачем нужен WSL 2? Здесь две причины:

  • WSL 1 должен, по сути, реализовать все двоичные интерфейсы приложений (ABI) ядра Linux, как говорится, бит к биту. Если в интерфейсе есть ошибка, WSL 1 должен её воспроизвести. А если есть функция, которую трудно представить в ядре NT, то она либо не может быть реализована, либо нуждается в дополнительной логике ядра (и поэтому становится медленнее).


    Уровни и интерфейсы между ними: API и ABI. Высокоуровневое сравнение

  • Подсистема Linux в WSL 1 должна соблюдать любые ограничения и внутренние различия, существующие между ядром NT и традиционным дизайном Unix. Наиболее очевидным отличием является файловая система NTFS и её семантика, а также то, как эти различия вредят производительности бинарных файлов Linux. Низкая производительность файловой системы, видимо, была распространённой жалобой при использовании WSL 1.

WSL 2 выбрасывает всю часть подсистемы Linux и заменяет её полноценной (но очень хорошо скрытой и быстрой) виртуальной машиной. Затем виртуальная машина внутри себя запускает обычное ядро Linux, правильную файловую систему Linux и стандартный сетевой стек Linux. Всё это работает внутри VM.

Это означает, что красота дизайна WSL 1 исчезла: ядро Windows NT больше не видит ничего в мире Linux. Просто большой чёрный ящик, который делает что-то неизвестное внутри себя. Ядро Windows NT видит только точки подключения VMENTER и VMEXIT для виртуальной машины и запросы чтения/записи на уровне блоков на виртуальном диске. Это самое ядро NT теперь ничего не знает о процессах Linux и доступе к файлам. Точно так же работающее ядро Linux ничего не знает об NT.

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

Потерянный потенциал


С точки зрения пользователя, подсистема WSL 2 выглядит лучше: действительно, приложения Linux теперь работают намного быстрее, потому что не проходят через неудобную эмуляцию системных вызовов Linux в ядре NT. Если NTFS трудно использовать с семантикой Linux, то теперь такой проблемы нет, потому что теперь окружение Linux использует ext4 на своём виртуальном диске. И поддержка приложений Linux может быть гораздо более полной, потому что ну, потому что WSL 2 это и есть полноценный Linux.

Но подумайте, за счёт чего достигнуто это удобство? Чего мы лишились?

Какой должна была стать WSL, если бы всё работало так, как задумано:

  • Представьте, как здорово набрать ps или top в сеансе WSL и увидеть рядом процессы Linux и Windows, причём любой из них можно убить командой kill?
  • Представьте, как здорово манипулировать службами Windows из сеанса WSL?
  • Как здорово использовать ifconfig (аналог ipconfig из Windows, хотя есть ещё ip) в рамках сеанса WSL для проверки и изменения сетевых интерфейсов компьютера?


  • По сути, можете представить выполнение абсолютно всех задач системного администрирования в Windows из линуксовой консоли WSL? Это же сказка!

Хотя такого никогда не существовало, такой мир вполне можно себе представить и это могла обеспечить только архитектура WSL 1. И это вовсе не фантазии, потому что именно такую модель использует macOS (хотя это немного читерство, ведь macOS, по сути, является Unix).

Вот что бесит сильнее всего, пишет Джулио Мерино: Хотя я могу установить WSL на свою машину разработки для Azure, но никак не могу его использовать вообще ни для чего. По-прежнему приходится работать в CMD.EXE, поскольку здесь происходит взаимодействие с нативными процессами и ресурсами Windows, а инструменты, с которыми я имею дело, предназначены только для Windows.

На странице вопросов и ответов написано, что WSL 1 не будет заброшен, то есть можно запускать дистрибутивы WSL 1 и WSL 2 вместе, проапгрейдить любой дистрибутив на WSL 2 в любое время или вернуться на WSL 1. И если посмотреть на строгую приверженность к обратной совместимости Microsoft, из-за которой мы до сих пор вынуждены пользоваться архаичными инструментами и протоколами, это может быть правдой. Но поддержка WSL 1 колоссальное усилие, потому что придётся отслеживать и соответствовать всем изменениям Linux. Как бы то ни было, будем надеяться, что WSL 1 продолжит своё существование. И кто знает, вдруг когда-нибудь всё-таки воплотится в жизнь тот волшебный мир, который мы представляем?

Уровень совместимости в BSD


Интересно, что семейство операционных систем BSD ( FreeBSD, OpenBSD, NetBSD, MidnightBSD, GhostBSD, Darwin, DragonFly BSD) всегда отставали от Linux и других коммерческих операционных систем. Но у них очень давно была реализована эта совместимость на бинарном уровне, о которой мы говорим. Джулио Мерино говорит, что совместимость с Linux в ядре NetBSD была реализована ещё в 1995 году, то есть четверть века назад и за 21 год до рождения WSL 1.

И самое замечательное, эта совместимость не ограничивается только Linux. На протяжении многих лет NetBSD поддерживала эмуляцию различных операционных систем. Поддержка SVR4 появилась в 1994 году, и в течение короткого периода времени NetBSD даже поддерживала бинарные файлы PE/COFF да, правильно, это бинарные файлы Win32! Таким образом, в некотором смысле NetBSD реализовала модель WSL 1 наоборот: она позволяла запускать бинарные файлы Win32 поверх ядра NetBSD ещё в 2002 году. Вот так вот.



На правах рекламы


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

Подробнее..

Перехват и обработка событий в файловой системе Linux

20.01.2021 10:13:24 | Автор: admin

Введение

В предыдущей статье мы рассмотрели сборку и установку пакета на Linux системах, в которой упомянули про Linux Kernel Module (LKM) и обещали раскрыть позднее подробности о пути к нему и его создании. Ну что ж, настало его время. LKM мы выбираем тебя.

Необходимость реализации

"Windows драйвер мы заменили на Linux Kernel Module LKM" итак, вернёмся мысленно к самому началу пути. Мы имеем Windows драйвер, который обеспечивает отслеживание и перехват событий обращения к файлу. Как его перенести или чем заменить в Linux системах? Покопавшись в архитектуре, почитав про перехват и реализацию подобных технологий в Linux мы поняли, что задача абсолютно нетривиальная, содержащая кучу подводных камней.

Inotify

Закинув удочки на пару форумов, посоветовавшись с коллегами, было принято решение копать в сторону Inotify. Inotify файловый монитор, который логирует события в системе уже после того, как они произошли. Но у него есть брат fanotify. В нём мы можем добавить ограничение доступности на события открытия, копирования файла. Но нам необходимо иметь такую же возможность и для событий удаления, переименования, перемещения, а, следовательно, fanotify нам в этом не поможет. Хочу заметить, что fanotify это userspace утилита, соответственно при её использовании нет проблем с платформопереносимостью.

Virtual File System

Следующим этапом изучения стала возможность реализации перехвата обращений при помощи VFS.

После анализа VFS на основе Dtrace, eBPF и bcc, стало понятно, что при использовании данной технологии возможно выполнять мониторинг событий, происходящих в системе. В данном случае, перехват осуществляется через LKM. В рамках изучения реализации различных модулей под разные ядра выявлено следующее: перехват не всегда позволяет отследить полный путь к файлу; при перехвате обращения к файлу через открытое приложение, а не из проводника, отсутствует путь к файлу в аргументах; для каждого ядра необходима своя реализация.

Janus, SElinux и AppArmor

В ходе исследования, была найдена статья по расширению функциональности системы безопасности ядра Linux. Отсюда следует, что на рынке существует достаточное количество решений. Самым легко реализуемым является Janus. Минусом решения выступает отсутствие поддержки свежих ядер и все вышеописанные проблемы LKM хука. Реализация SELinux и AppArmor представляет квинтэссенцию всего описанного и изученного ранее. Модуль SELinux включает в себя основные компоненты: сервер безопасности; кэш вектора доступа (англ. Access Vector Cache, AVC); таблицы сетевых интерфейсов; код сигнала сетевого уведомления; свою виртуальную файловую систему (selinuxfs) и реализацию функций-перехватчиков.

Долгожданное решение

После всех этих бесконечных но, на помощь нам пришёл Хабр! Наткнувшись на статью, стало ясно, что это наш случай.

Обработка перехвата

Изучив предложенные данные по ftrace и реализации из самой статьи, сделали аналогичный LKM модуль на базе ftrace. Данная утилита, в свою очередь, работает на базе файловой системы debugfs, которая в большинстве современных дистрибутивов Linux смонтирована по умолчанию. Hook'и добавили на события к уже имеющимся clone и open: openat, rename, unlink, unlinkat. Таким образом, удалось обработать открытие, переименование, перемещение, копирование, удаление файла.

Взаимодействие

Теперь нам нужно реализовать связь между модулем ядра и приложением userspace. Для решения данной задачи существуют разные подходы, но в основном выделяют два: socket между kernel и userspace; запись/чтение в системной директории в файл.

В итоге, мы выбрали netlink socket, так как в Windows мы используем аналогичный интерфейс - FltSendMessage. Можно было использовать inet socket, но это наименее защищённое решение. Также столкнулись с такой проблемой, что на .Net Core, на которой реализовано userspace приложение, отсутствует реализация netlink.

Поэтому пришлось реализовывать динамическую библиотеку с реализацией netlink и уже её подключать в проект.

int open_netlink_connection(void){    //initialize our variables    int sock;    struct sockaddr_nl addr;    int group = NETLINK_GROUP;    //open a new socket connection    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_USERSOCK);    //if the socket failed to open,    if (sock < 0)     {        //inform the user        printf("Socket failed to initialize.\n");        //return the error value        return sock;    }    //initialize our addr structure by filling it with zeros    memset((void *) &addr, 0, sizeof(addr));    //specify the protocol family    addr.nl_family = AF_NETLINK;    //set the process id to the current process id    addr.nl_pid = getpid();    //bind the address to the socket created, and if it failed,    if (bind(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0)     {        //inform the user        printf("bind < 0.\n");        //return the function with a symbolic error code        return -1;    }    //set the option so that we can receive packets whose destination    //is the group address specified (so that we can receive the message broadcasted by the kernel)    if (setsockopt(sock, 270, NETLINK_ADD_MEMBERSHIP, &group, sizeof(group)) < 0)     {        //if it failed, inform the user        printf("setsockopt < 0\n");        //return the function with a symbolic error code        return -1;    }    //if we got thus far, then everything    //went fine. Return our socket.    return sock;}char* read_kernel_message(int sock){    //initialize the variables    //that we are going to need    struct sockaddr_nl nladdr;    struct msghdr msg;    struct iovec iov;    char* buffer[CHUNK_SIZE];    char* kernelMessage;    int ret;    memset(&msg, 0, CMSG_SPACE(MAX_PAYLOAD));    memset(&nladdr, 0, sizeof(nladdr));    memset(&iov, 0, sizeof(iov));    //specify the buffer to save the message    iov.iov_base = (void *) &buffer;    //specify the length of our buffer    iov.iov_len = sizeof(buffer);    //pass the pointer of our sockaddr structure    //that will save the source IP and port of the connection    msg.msg_name = (void *) &(dest_addr);    //give the size of our structure    msg.msg_namelen = sizeof(dest_addr);    //pass our scatter/gather I/O structure pointer    msg.msg_iov = &iov;    //we will pass only one buffer array,    //therefore we will specify that here    msg.msg_iovlen = 1;    //listen/wait for new data    ret = recvmsg(sock, &msg, 0);    //if message was received successfully,    if(ret >= 0)    {        //get the string data and save them to a local variable        char* buf = NLMSG_DATA((struct nlmsghdr *) &buffer);        //allocate memory for our kernel message        kernelMessage = (char*)malloc(CHUNK_SIZE);        //copy the kernel data to our allocated space        strcpy(kernelMessage, buf);        //return the pointer that points to the kernel data        return kernelMessage;    }        //if we got that far, reading the message failed,    //so we inform the user and return a NULL pointer    printf("Message could not received.\n");    return NULL;}int send_kernel_message(int sock, char* kernelMessage){    //initialize the variables    //that we are going to need    struct msghdr msg;    struct iovec iov;    char* buffer[CHUNK_SIZE];        int ret;    memset(&msg, 0, CMSG_SPACE(MAX_PAYLOAD));    memset(&iov, 0, sizeof(iov));    nlh = (struct nlmsghdr *)malloc(NLMSG_SPACE(MAX_PAYLOAD));    memset(nlh, 0, NLMSG_SPACE(MAX_PAYLOAD));    nlh->nlmsg_len = NLMSG_SPACE(MAX_PAYLOAD);    nlh->nlmsg_pid = getpid();    nlh->nlmsg_flags = 0;    char buff[160];    snprintf(buff, sizeof(buff), "From:DSSAgent;Action:return;Message:%s;", kernelMessage);    strcpy(NLMSG_DATA(nlh), buff);    iov.iov_base = (void *)nlh;    iov.iov_len = nlh->nlmsg_len;    //pass the pointer of our sockaddr structure    //that will save the source IP and port of the connection    msg.msg_name = (void *) &(dest_addr);    //give the size of our structure    msg.msg_namelen = sizeof(dest_addr);    msg.msg_iov = &iov;    msg.msg_iovlen = 1;    printf("Sending message to kernel (%s)\n",(char *)NLMSG_DATA(nlh));    ret = sendmsg(sock, &msg, 0);    return ret;}int sock_netlink_connection(){sock_fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_USER);    if (sock_fd < 0)        return -1;    memset(&src_addr, 0, sizeof(src_addr));    src_addr.nl_family = AF_NETLINK;    src_addr.nl_pid = getpid(); /* self pid */    bind(sock_fd, (struct sockaddr *)&src_addr, sizeof(src_addr));    memset(&dest_addr, 0, sizeof(dest_addr));    dest_addr.nl_family = AF_NETLINK;    dest_addr.nl_pid = 0; /* For Linux Kernel */    dest_addr.nl_groups = 0; /* unicast */    nlh = (struct nlmsghdr *)malloc(NLMSG_SPACE(MAX_PAYLOAD));    memset(nlh, 0, NLMSG_SPACE(MAX_PAYLOAD));    nlh->nlmsg_len = NLMSG_SPACE(MAX_PAYLOAD);    nlh->nlmsg_pid = getpid();    nlh->nlmsg_flags = 0;    strcpy(NLMSG_DATA(nlh), "From:DSSAgent;Action:hello;");    iov.iov_base = (void *)nlh;    iov.iov_len = nlh->nlmsg_len;    msg.msg_name = (void *)&dest_addr;    msg.msg_namelen = sizeof(dest_addr);    msg.msg_iov = &iov;    msg.msg_iovlen = 1;    printf("Sending message to kernel\n");    sendmsg(sock_fd, &msg, 0);    printf("Waiting for message from kernel\n");    /* Read message from kernel */    recvmsg(sock_fd, &msg, 0);    printf("Received message payload: %s\n", (char *)NLMSG_DATA(nlh));return sock_fd;}void sock_netlink_disconnection(int sock){close(sock);    free(nlh);}

Также, в дальнейшем оказалось, что некоторые функции отсутствуют в Net.Core например поиск по pid процесса имени пользователя, которому принадлежит этот процесс. Примеров данной реализации оказалась масса, но, в рамках нашего приложения, не удалось их реализовать. Поэтому реализовали в той же библиотеке свою функцию нахождения uid пользователя, по которому используя системные функции можно найти имя.

char* get_username_by_pid(int pid){   register struct passwd *pw;  register uid_t uid;  int c;  FILE *fp;  char filename[255];  sprintf(filename, "/proc/%d/loginuid", pid);  char cc[8];    // чтение из файла  if((fp= fopen(filename, "r"))==NULL)    {        perror("Error occured while opening file");        return "";    }  // считываем, пока не дойдем до конца  while((fgets(cc, 8, fp))!=NULL) {}       fclose(fp);    uid = atoi(cc);  pw = getpwuid (uid);  if (pw)  {      return pw->pw_name;  }  else  {      return "";  }}

Доработка модуля

По итогу добавили соединение по netlink в инициализацию LKM.

static int fh_init(void){    int err;struct netlink_kernel_cfg cfg ={#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 6, 0).groups = 1,#endif.input = nl_recv_msg,};#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 36)nl_sk = netlink_kernel_create(&init_net, NETLINK_USER, &cfg);#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 32)nl_sk = netlink_kernel_create(&init_net, NETLINK_USER, 0, nl_recv_msg, NULL, THIS_MODULE);#elsenl_sk = netlink_kernel_create(NETLINK_USER, 0, nl_recv_msg, THIS_MODULE);#endifif (!nl_sk){printk(KERN_ERR "%s Could not create netlink socket\n", __func__);return 1;}err = fh_install_hooks(hooks, ARRAY_SIZE(hooks));if (err)return err;p_list_hook_files = (tNode *)kmalloc(sizeof(tNode), GFP_KERNEL);p_list_hook_files->next = NULL;p_list_hook_files->value = 0;pr_info("module loaded\n");return 0;}module_init(fh_init);static void fh_exit(void){delete_list(p_list_hook_files);fh_remove_hooks(hooks, ARRAY_SIZE(hooks));netlink_kernel_release(nl_sk);pr_info("module unloaded\n");}module_exit(fh_exit);

Socket ожидает перехвата события обращения к файлу. Модуль, перехватывая событие, передаёт имя файла, pid и имя процесса. Userspace приложение, получая данную информацию, обрабатывает её и отвечает, что делать с файлом (блокировать или разрешать доступ). Впоследствии модуль возвращает соответствующий системный вызов.

static void send_msg_to_user(const char *msgText){int msgLen = strlen(msgText);struct sk_buff *skb = nlmsg_new(NLMSG_ALIGN(msgLen), GFP_KERNEL);if (!skb){printk(KERN_ERR "%s Allocation skb failure.\n", __func__);return;}struct nlmsghdr *nlh = nlmsg_put(skb, 0, 1, NLMSG_DONE, msgLen, 0);if (!nlh){printk(KERN_ERR "%s Create nlh failure.\n", __func__);nlmsg_free(skb);return;}NETLINK_CB(skb).dst_group = 0;strncpy(nlmsg_data(nlh), msgText, msgLen);int errorVal = nlmsg_unicast(nl_sk, skb, pid);if (errorVal < 0)printk(KERN_ERR "%s nlmsg_unicast() error: %d\n", __func__, errorVal);}static void return_msg_to_user(struct nlmsghdr *nlh){pid = nlh->nlmsg_pid;const char *msg = "Init socket from kernel";const int msg_size = strlen(msg);struct sk_buff *skb = nlmsg_new(msg_size, 0);if (!skb){printk(KERN_ERR "%s Failed to allocate new skb\n", __func__);return;}nlh = nlmsg_put(skb, 0, 0, NLMSG_DONE, msg_size, 0);NETLINK_CB(skb).dst_group = 0;strncpy(nlmsg_data(nlh), msg, msg_size);int res = nlmsg_unicast(nl_sk, skb, pid);if (res < 0)printk(KERN_ERR "%s Error while sending back to user (%i)\n", __func__, res);}

Позднее, для работы другого приложения в данный модуль, добавили возможность блокирования доступа к определённому файлу (по его полному пути) для всех процессов, кроме определённого (определяем по pid процесса).

static void parse_return_from_user(char *return_msg){char *msg = np_extract_value(return_msg, "Message", ';');const char *file_name = strsep(&msg, "|");printk(KERN_INFO "%s Name:(%s) Permiss:(%s)\n", __func__, file_name, msg);if (strstr(msg, "Deny"))reload_name_list(p_list_hook_files, file_name, Deny);elsereload_name_list(p_list_hook_files, file_name, Allow);}static void free_guards(void){// Possibly unpredictable behavior during cleaningmemset(&guards, 0, sizeof(struct process_guards));}static void change_guards(char *msg){char *path = np_extract_value(msg, "Path", ';');char *count_str = np_extract_value(msg, "Count", ';');if (path && strlen(path) && count_str && strlen(count_str)){int i, found = -1;for (i = 0; i < guards.count; ++i)if (guards.process[i].file_path && !strcmp(path, guards.process[i].file_path))found = i;guards.is_busy = 1;int count;kstrtoint(count_str, 10, &count);if (count > 0){if (found == -1){strcpy(guards.process[guards.count].file_path, path);found = guards.count;guards.count++;}for (i = 0; i < count; ++i){char buff[8];snprintf(buff, sizeof(buff), "Pid%d", i + 1);char *pid = np_extract_value(msg, buff, ';');if (pid && strlen(pid))kstrtoint(pid, 10, &guards.process[found].allow_pids[i]);elseguards.process[found].allow_pids[i] = 0;}guards.process[found].allow_pids[count] = 0;}else{if (found >= 0){for (i = found; i < guards.count - 1; ++i)guards.process[i] = guards.process[i + 1];guards.count--;}}guards.is_busy = 0;}}// Example message is "From:CryptoCli;Action:clear;" or "From:DSSAgent;Action:init;"static void nl_recv_msg(struct sk_buff *skb){printk(KERN_INFO "%s <--\n", __func__);struct nlmsghdr *nlh = (struct nlmsghdr *)skb->data;printk(KERN_INFO "%s Netlink received msg payload:%s\n", __func__, (char *)nlmsg_data(nlh));char *msg = (char *)nlmsg_data(nlh);if (msg && strlen(msg)){char *from = np_extract_value(msg, "From", ';');char *action = np_extract_value(msg, "Action", ';');if (from && strlen(from) && action && strlen(action)){if (!strcmp(from, "DSSAgent")){if (!strcmp(action, "init")){return_msg_to_user(nlh);}else if (!strcmp(action, "return")){parse_return_from_user(msg);}else{printk(KERN_ERR "%s Failed msg, \"From\" is %s and \"Action\" is %s\n", __func__, from, action);}}else if (!strcmp(from, "CryptoCli")){if (!strcmp(action, "clear")){free_guards();}else if (!strcmp(action, "change")){change_guards(msg);}else{printk(KERN_ERR "%s Failed msg, \"From\" is %s and \"Action\" is %s\n", __func__, from, action);}}else{printk(KERN_ERR "%s Failed msg, \"From\" is %s and \"Action\" is %s\n", __func__, from, action);}}else{printk(KERN_ERR "%s Failed parse msg, don`t found \"From\" and \"Action\" (%s)\n", __func__, msg);}}else{printk(KERN_ERR "%s Failed parse struct nlmsg_data, msg is empty\n", __func__);}printk(KERN_INFO "%s -->\n", __func__);}static bool check_file_access(char *fname, int processPid){if (fname && strlen(fname)){int i;for (i = 0; i < guards.count; ++i){if (!strcmp(fname, guards.process[i].file_path) && guards.process[i].allow_pids[0] != 0){int j;for (j = 0; guards.process[i].allow_pids[j] != 0; ++j)if (processPid == guards.process[i].allow_pids[j])return true;return false;}}// Not found filename in guardsif (strstr(fname, filetype)){char *processName = current->comm;printk(KERN_INFO "%s service pid = %d\n", __func__, pid);printk(KERN_INFO "%s file name = %s, process pid: %d, , process name = %s\n", __func__, fname, processPid, processName);if (processPid == pid){return true;}else{add_list(p_list_hook_files, processPid, fname, None);char *buffer = kmalloc(4096, GFP_KERNEL);sprintf(buffer, "%s|%s|%d", fname, processName, processPid);send_msg_to_user(buffer);kfree(buffer);ssleep(5);bool ret = true;if (find_list(p_list_hook_files, fname) == Deny)ret = false;delete_node(p_list_hook_files, fname);return ret;}}}return true;}

Интеграция в процесс установки

Так как первые два минуса LKM удалось преодолеть через реализацию ftrace, третий никто не отменял. Мало того, что под каждое ядро нужна сборка модуля, уже в процессе использования он может протухнуть. Было принято решение добавить его пересборку перед каждым запуском userspace приложения. В статье по сборке Linux пакетов было описано, что службу, для которой мы реализовываем обработку перехвата обращения к файлу, мы демонизировали путём добавления в system. Поэтому для демона.service добавляем два дополнительных пункта, помимо ExecStart и ExecStop будут:

ExecStartPre=/bin/sh /путь_до_расположения/prestart.shExecStopPost=/sbin/rmmod имя_модуля.ko

а в сам prestart.sh:

#!/bin/shMOD_VAL=$(lsmod | grep имя_модуля | wc -l)cd /путь_до_расположения_модуляmake cleanmake allif [ $MOD_VAL = 1 ]then    for proc in $(ps aux | grep DSS.Agent | awk '{print $2}'); do kill -9 $proc; doneelse    /sbin/insmod / путь_до_расположения_модуля/имя_модуля.kofi

Заключение

В завершение, хочется отметить: возможно, путь, по которому мы пошли, не самый красивый и элегантный, но, он содержит отработанную и проверенную логику работы на ОС Windows. Было бы полезно услышать в комментариях мнение читателей статьи. Возможно, есть более разумное решение задачи. Например, наш DevOps, в тот момент, когда мы автоматизировали сборку пакета Linux и обрабатывали/добавляли LKM, предложил реализовать логику с использованием Access Control List (ACL). Скорее всего, в дальнейшем мы займёмся переработкой нашего продукта под Linux. И, да, скоро будет новая статья, о том, как мы переносили MS Forms на Avalonia и его интеграции в Linux.

Ссылки которые нам помогли

Подробнее..

Автоматизация публикации приложения в Google Play при помощи Jenkins

26.01.2021 20:09:19 | Автор: admin

Для этого нам понадобится

  1. Действующий account Google Play Developer

  2. Сервер Linux с предустановленным Docker, в моём случае это Ubuntu 16.04

  3. Установленный Android SDK

  4. Jenkins - в данном случае развернём его при помощи Docker

  5. Gitea - Удобная служба для собственного Git-репозитория (это не обязательно можно использовать и GItHub) её мы подымем также на базе Docker контейнера

Настройка Google Play Account

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

  1. Авторизуйтесь в Google Cloud Platform, если еще не создан проект то создаём его

  2. В разделе IAM и администрирование - Сервисные аккаунты жмём Создать сервисный аккаунт

  3. После заполнения соответствующих полей он будет создан и появится в списке, жмём на три точки с права и выбираем создать ключ, выбираем JSON, сохраните его он нам понадобится для настройки Jenkins

  4. Авторизуйтесь в Gooogle Play Developer Console

  5. В разделе Пользователи и разрешения нажимаем пригласить пользователя сервисного аккаунта по сгенерированному email , выставляем ему роль Релиз менеджер (при необходимости можете настроить права этого пользователя более детально)

  6. Я предполагаю что Сертификат для ключа подписи приложения, и Сертификат ключа загрузки у вас уже настроен и это не требует пояснений.

Установка Android SDK

# Install latest JDKsudo apt install default-jdksudo apt install android-sdk

Добавьте Android SDK в свой PATH, откройте~/.bashrcв редакторе и скопируйте следующие строки

# Export the Android SDK path export ANDROID_HOME=$HOME/android-sdkexport PATH=$PATH:$ANDROID_HOME/tools/binexport PATH=$PATH:$ANDROID_HOME/platform-tools# Fixes sdkmanager error with java versions higher than java 8export JAVA_OPTS='-XX:+IgnoreUnrecognizedVMOptions --add-modules java.se.ee'

Для проверки запустите

source ~/.bashrc

Для того что бы просмотреть все доступные инструменты сборки выполните команду

sdkmanager --list

По аналогии с выполните установку интересующих вас версий инструментов для нужных платформ

sdkmanager "platform-tools" "platforms;android-28"

На этом установка Android SDK может считаться завершённой, и в дальнейшем нам понадобится лишь путь к установленным инструментам, в моём случае это выглядит как то так

Установка Gitea

Этот шаг является опциональным и совсем не обязательным если вы предпочитаете использовать git репозитарии такие как GitHub и им подобные и его можно пропустить, это малой степени повлияет на конечный результат. (На базе gitea в дальнейшем будет обсуждаться тема создания Telegram Bot`a для оповещения о публикациях)

Подробно по установке и настройке написано на оф сайте https://docs.gitea.io/en-us/install-with-docker/

По факту установка сводится к выполнению 2х действий

1) Перейдите на официальный репозитарий Gitea , на Docker HUB и скопируйте то что там написано в предварительно созданный файл

version: '2'services:  web:    image: gitea/gitea:1.12.4    volumes:      - ./data:/data    ports:      - "3000:3000"      - "22:22"    depends_on:      - db    restart: always  db:    image: mariadb:10    restart: always    environment:      - MYSQL_ROOT_PASSWORD=changeme      - MYSQL_DATABASE=gitea      - MYSQL_USER=gitea      - MYSQL_PASSWORD=changeme    volumes:      - ./db/:/var/lib/mysql

2) Сохраните и запустите команду docker-compose you_filename

3) Gitea установлена и доступна по URL http://you_IP:3000/

4) Создайте пользователя, репозитарий, сделайте PUSH исходного кода вашего проекта, и в моём случае для упрощения процесса публикации приложения все необходимые ключи для его подписи и деплоя я храню в месте с исходным кодом в системе контроля версий (да знаю это не совсем верно и вы вольны делать так как считаете нужным, к примеру создать отдельный volume для ключей и пробрасывать их jenkins для дальнейшего их использования gradle при подписании приложения, описание этого лишь раздует статью и потому не будет рассматриваться)

Предварительная настройка проекта

Для подписания нашего apk файла в автоматическом режиме на стороне сервера, нам нужен файл нашего keystore и правильно настроенный скрипт gradle , для этого добавим в него несколько секций

// Load keystoredef keystorePropertiesFile = rootProject.file("keystore.properties")def keystoreProperties = new Properties()keystoreProperties.load(new FileInputStream(keystorePropertiesFile))// GenerateNameVersiondef getVersionNameTimestamp() {    return new Date().format('yy.MM.ddHHmm')}// GenerateVersionCodedef getVersionCodeTimestamp() {    def date = new Date()    def formattedDate = date.format('yyMMddHHmm')    def code = formattedDate.toInteger()    println sprintf("VersionCode: %d", code)    return code}......android {    signingConfigs {        config {            keyAlias keystoreProperties['keyAlias']            keyPassword keystoreProperties['keyPassword']            storeFile file(keystoreProperties['storeFile'])            storePassword keystoreProperties['storePassword']        }    }......    defaultConfig {        versionCode getVersionCodeTimestamp()        versionName "${getVersionNameTimestamp()}"

Содержимое файла keystore.properties

storePassword=you_password_keystorekeyPassword=you_password_keykeyAlias=you_key_namestoreFile=path_to_keystore_file
  • Я храню как файл с keystore.properties так и сам keystore в системе контроля версий, что не совсем правильно и не безопасно при публикации исходного кода в открытом виде к примеру на GitHub, по этому я не рекомендую использовать данный подход если у вас OpenSource проект , храните и подтягивайте их из отдельной папки.

  • Для публикации в Google Play требуется уникальная версия сборки, и я генерирую её скриптом Gradle на основании текущей даты и времени, и как вы понимаете это исключает использование каких либо вразумительных номеров версий и если вам это важно , то вам придётся придумать некий другой механизм автоматизации версионирования, я же остановился на этом варианте - потому как хотел что бы deploy происходил по нажатию одной лишь кнопки (PUSH)

Установка Jenkins

Его мы развернём используя Docker , я применяю уже настроенный образ с нужными мне инструментами из своего репозитария, вы же вольны использовать официальный, принципиально ни чего не измениться

docker run -it -d -v jenkins_home:/var/jenkins_home -v /usr/lib/android-sdk:/usr/lib/android-sdk -p 8080:8080 -p 50000:50000 --env JENKINS_OPTS="--prefix=/jenkins" --restart always leganas/ls_repository:jenkins

пробрасываем в качестве volumes в в наш контейнер папку с установленным Android SDK

Теперь он запущен и доступен по адресу http://you_IP:8080/jenkins/

После не хитрых манипуляций по заданию пароля Jenkins готов к работе, и теперь нам предстоит его настроить

1) Для начала нам нужно настроить окружение , заходим System Configuration - Глобальные настройки , и добавляем Environment variables (возможно ваши пути будут отличатся)

2) В разделе Настройки - Конфигурация глобальных инструментов проверяем настройки Git и Gradle (по факту обычно там всё уже настроено)

3) Заходим Настройки - Управление пользователями , выбираем пользователя и его настройки, ищем строку API Token , создаём новый и сохраняем его , он нам понадобится.

4) В разделе управления плагинами проверяем и если нужно устанавливаем плагины Git, Git client, Google OAuth Credentials plugin, Google Play Android Publisher

5) Заходим Настройки - Manage Credentials Configure credentials -Store - Jenkins - Global credentials (unrestricted)- и создаём там 2 ключа доступа |

  • для доступа к Git репозитарию

    в моём случае т.к. я использую Gitea я создаю обычную пару login/password , для GitHub есть специальный плагин и инструмент для авторизации

  • для публикации приложения в Google Play Market

    создаём ключ используя JSON файл который создали в первом разделе данной инструкции

6) Теперь создайте проект вашего приложения в Jenkins и настройте его

  • Управление исходным кодом - установите Git , укажите Repository URL и Credentials (которые создали на прошлом этапе)

  • Триггеры сборки - выставите Trigger builds remotely (e.g., from scripts), в поле ввода введите любой случайный текст (он нам понадобится для удалённой активизации процесса сборки) при помощи GIt huck

  • Добавьте шаг сборки Invoke Gradle script , и После сборочные операции - публикацию

Обратите внимание на поле Release traack , оно указывает то как будет опубликовано ваше приложение , в моём случае это "Внутреннее тестирование"

7) Запустите проект в ручную использую Web интерфейс Jenkins и посмотрите на результат в истории сборок - Вывод консоли Если вы всё сделали верно то ваше приложение должно быть подтянуто из Git репозитария до актуальной версии ветки /master , собрано , подписано и опубликовано на Google Play.

Автоматизация запуска сборки

Если мы всё сделали правильно и проект удачно был опубликован на Google Play , можно перейти к настройке его автоматического deploy по Git событию PUSH в /master ветку

1) Если вы используете Gitea как я то зайдите в репозитарий вашего проекта - Настройки - Git хуки, и в post-receive нажмите редактировать, и добавьте нечто этого рода

#!/bin/bashwhile read oldrev newrev refnamedo    branch=$(git rev-parse --symbolic --abbrev-ref $refname)    if [ "master" = "$branch" ]; then       curl --user you_user_name:you_user_token http://you_url_jenkins/job/you_project/build?token=you_tocken_build    fidone
  • you_user_name - Имя пользователя от лица которого jenkins будет производить сборку

  • you_user_token - Токен который был сгенерирован в настройках пользователя

  • you_url_jenkins и вообще весь путь до хука можно посмотреть на странице настройки проекта Jenkins и будет выглядеть он примерно так :

После проведения такого рода манипуляций сборка проекта Jenkins будет начинаться автоматически после PUSH события в master вашего репозитария.

PS. Если же вы используете для хранения вашего кода другую Git систему то этот же код вы можете поместить руками в .git\hooks\post-update

Заключение

В случае положительного фидбэка от статьи, в следующей части я расскажу как написать Telegram бота для оповещения ваших тестировщиков о наличии обновления приложения на Google Play.

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

Подробнее..

Профилирование в облаке и не только

05.01.2021 12:12:21 | Автор: admin

Приложение, оптимально использующее вычислительные ресурсы, это всегда хорошо и приятно. А если такое приложение работает в облаке, то ещё и выгодно. Порой очень выгодно. Просто потому, что в один квант оплаченного облачного вычислительного ресурса влезает, например, больше показанных в браузере котиков вместе с рекламой или платёжных транзакций за подписки на тех же котиков. И если с профилированием Go приложений всё более или менее понятно, то для приложений, написанных на C или C++, всё гораздо интереснее.


Так как большинство проблем с производительностью материализуются, как правило, в продакшене, то нас будут интересовать те инструменты, которые не требуют инструментализации кода и, следовательно, остановки и перезапуска рабочих процессов. Кроме того, я не буду упоминать профилировщики, которые анализируют работу кода на уровне микроархитектуры процессора типа vTune. Во-первых, на эту тему статей и так хватает. Во-вторых, я ошибочно полагаю, что вопросы микроархитектуры больше актуальны для разработчиков middleware типа серверов баз данных или библиотек, которые настолько круты, что Хабр не читают. Итак.


До недавнего времени одним из таких инструментов были Google perftools. Они включают два профилировщика: для CPU и для оперативной памяти. Начнём с первого.


Чтобы ваша программа стала профилируемой, её необходимо слинковать вместе с профилировщиком. Можно статически, можно динамически или же вообще подгрузить при помощи LD_PRELOAD. Его размер составляет около 60k, и он более никак не нагружает систему, когда не используется. Так что всегда линковаться с ним на боевых серверах будет не слишком накладно. Активируется он установкой переменной окружения CPUPROFILE:


$ CPUPROFILE=/tmp/envoy.prof envoy --concurrency 1 -c /path/to/config.yaml

В этом случае статистика начинает собираться с момента запуска исполняемого файла. Если дополнительно установить CPUPROFILESIGNAL=12, то активация будет включаться и выключаться по пользовательскому сигналу 12 (SIGUSR2).


Принцип работы CPU-профилировщика заключается в том, что он периодически (период тоже можно изменить) делает снимок текущих стеков процесса и сохраняет их файл, который можно проанализировать утилитой pprof. Например, чтобы быстро оценить, какие функции больше других или, точнее сказать, чаще других нагружают процессор, достаточно ввести


$ pprof -text /tmp/envoy.profFile: envoy-staticType: cpuShowing nodes accounting for 17.74s, 86.75% of 20.45s totalDropped 900 nodes (cum <= 0.10s)      flat  flat%   sum%        cum   cum%     5.19s 25.38% 25.38%     17.02s 83.23%  deflate_fast     4.04s 19.76% 45.13%      4.04s 19.76%  longest_match     3.92s 19.17% 64.30%      3.92s 19.17%  compress_block     3.04s 14.87% 79.17%      3.04s 14.87%  slide_hash     0.62s  3.03% 82.20%      0.63s  3.08%  crc32_z     0.18s  0.88% 83.08%      0.18s  0.88%  writev     0.12s  0.59% 83.67%      0.12s  0.59%  readv     0.11s  0.54% 84.21%      0.11s  0.54%  close     0.08s  0.39% 84.60%      0.17s  0.83%  std::__uniq_ptr_impl::_M_ptr     0.06s  0.29% 84.89%      0.16s  0.78%  std::get     0.06s  0.29% 85.18%      0.18s  0.88%  std::unique_ptr::get     0.04s   0.2% 85.38%     18.54s 90.66%  http_parser_execute     0.03s  0.15% 85.53%      0.33s  1.61%  Envoy::Router::Filter::decodeHeaders     0.03s  0.15% 85.67%      0.26s  1.27%  absl::container_internal::raw_hash_set::find     0.02s 0.098% 85.77%     17.16s 83.91%  Envoy::Http::Http1::ClientConnectionImpl::onBody     0.01s 0.049% 85.82%      0.12s  0.59%  Envoy::Event::DispatcherImpl::clearDeferredDeleteList     0.01s 0.049% 85.87%     20.03s 97.95%  Envoy::Event::FileEventImpl::mergeInjectedEventsAndRunCb     0.01s 0.049% 85.92%     17.06s 83.42%  Envoy::Extensions::Compression::Gzip::Compressor::ZlibCompressorImpl::process     0.01s 0.049% 85.97%      0.13s  0.64%  Envoy::Http::ConnectionManagerImpl::ActiveStream::encodeData     0.01s 0.049% 86.01%      0.11s  0.54%  Envoy::Http::HeaderString::HeaderString     0.01s 0.049% 86.06%      0.32s  1.56%  Envoy::Http::Http1::ClientConnectionImpl::onHeadersComplete     0.01s 0.049% 86.11%     17.18s 84.01%  Envoy::Http::Http1::ConnectionImpl::dispatchBufferedBody     0.01s 0.049% 86.16%     19.14s 93.59%  Envoy::Network::ConnectionImpl::onReadReady     0.01s 0.049% 86.21%      0.24s  1.17%  Envoy::Network::ConnectionImpl::onWriteReady     0.01s 0.049% 86.26%      0.20s  0.98%  Envoy::Network::IoSocketHandleImpl::read     0.01s 0.049% 86.31%      0.21s  1.03%  Envoy::Network::RawBufferSocket::doRead...

Для более детального анализа можно воспользоваться довольно удобным web-интерфейсом, который предоставляет тот же pprof:


$ pprof -http=localhost:8080 /tmp/envoy.prof

Теперь по адресу http://localhost:8080 можно взглянуть на красивый граф вызовов функции (callgraph)


callgraph


и на flamegraph


flamegraph


С анализом же расхода памяти всё несколько сложнее, покуда профилировщик кучи является органической частью tcmalloc (thread caching malloc) альтернативного менеджера памяти от gperftools минимизирующего количество системных вызовов за счет предварительного выделения памяти сверх необходимого. То есть, чтобы иметь возможность профилировать память на боевой системе, необходимо отказаться от стандартных реализаций malloc() и new и всегда линковаться с tcmalloc. И хоть tcmalloc считается быстрее и эффективнее особенно в многопоточных программах, не все готовы его использовать хотя бы из-за немного большего расхода памяти. Тем не менее профилировать память с ним так же просто как и CPU:


$ HEAPPROFILE=/tmp/envoyhprof envoy --concurrency 1 -c /path/to/config.yamlDumping heap profile to /tmp/envoyhprof.0001.heap (1024 MB allocated cumulatively, 6 MB currently in use)Dumping heap profile to /tmp/envoyhprof.0002.heap (2048 MB allocated cumulatively, 6 MB currently in use)Dumping heap profile to /tmp/envoyhprof.0003.heap (3072 MB allocated cumulatively, 6 MB currently in use)Dumping heap profile to /tmp/envoyhprof.0004.heap (4096 MB allocated cumulatively, 6 MB currently in use)Dumping heap profile to /tmp/envoyhprof.0005.heap (5120 MB allocated cumulatively, 6 MB currently in use)^CDumping heap profile to /tmp/envoyhprof.0006.heap (Exiting, 5 MB in use)

Теперь, чтобы узнать какие функции больше всего выделяли память на куче, надо снова воспользоваться pprof:


$ pprof -text -sample_index=alloc_space /tmp/envoyhprof.0005.heapFile: envoy-staticType: alloc_spaceShowing nodes accounting for 1558.99MB, 98.71% of 1579.32MB totalDropped 1117 nodes (cum <= 7.90MB)      flat  flat%   sum%        cum   cum% 1043.23MB 66.06% 66.06%  1043.23MB 66.06%  zcalloc  240.73MB 15.24% 81.30%   240.73MB 15.24%  Envoy::Zlib::Base::Base  150.71MB  9.54% 90.84%   406.68MB 25.75%  std::make_unique   79.15MB  5.01% 95.85%    79.15MB  5.01%  std::allocator_traits::allocate   18.68MB  1.18% 97.04%    26.62MB  1.69%  Envoy::Http::ConnectionManagerImpl::newStream   15.18MB  0.96% 98.00%    15.18MB  0.96%  Envoy::InlineStorage::operator new    8.39MB  0.53% 98.53%     8.39MB  0.53%  std::__cxx11::basic_string::basic_string    1.98MB  0.13% 98.65%    31.99MB  2.03%  Envoy::Http::Http1::allocateConnPool(Envoy::Event::Dispatcher&, Envoy::Random::RandomGenerator&, std::shared_ptr, Envoy::Upstream::ResourcePriority, std::shared_ptr const&, std::shared_ptr const&, Envoy::Upstream::ClusterConnectivityState&)::$_1::operator()    0.93MB 0.059% 98.71%    38.29MB  2.42%  Envoy::Server::ConnectionHandlerImpl::ActiveTcpListener::newConnection         0     0% 98.71%    59.54MB  3.77%  Envoy::Buffer::WatermarkBufferFactory::create         0     0% 98.71%    73.55MB  4.66%  Envoy::ConnectionPool::ConnPoolImplBase::newStream...

Как следует из таблицы, больше всего памяти выделяла zcalloc() из zlib, что совсем не удивительно, поскольку во время профилирования приложение сжимало прокачиваемый через себя трафик.


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


$ pprof -text -sample_index=inuse_space /tmp/envoyhprof.0005.heapFile: envoy-staticType: inuse_spaceShowing nodes accounting for 6199.96kB, 96.84% of 6402.51kB totalDropped 1016 nodes (cum <= 32.01kB)      flat  flat%   sum%        cum   cum% 2237.76kB 34.95% 34.95%  3232.51kB 50.49%  std::make_unique 2041.45kB 31.89% 66.84%  2041.45kB 31.89%  std::allocator_traits::allocate  375.03kB  5.86% 72.69%   753.26kB 11.77%  google::protobuf::DescriptorPool::Tables::AllocateString[abi:cxx11]  267.78kB  4.18% 76.88%   267.78kB  4.18%  std::__cxx11::basic_string::_M_mutate  201.61kB  3.15% 80.03%   201.61kB  3.15%  zalloc_with_calloc  160.43kB  2.51% 82.53%   160.43kB  2.51%  google::protobuf::Arena::CreateMessageInternal (inline)  146.74kB  2.29% 84.82%   146.74kB  2.29%  std::__cxx11::basic_string::_M_construct  141.38kB  2.21% 87.03%   157.38kB  2.46%  google::protobuf::DescriptorPool::Tables::AllocateMessage  139.88kB  2.18% 89.22%   139.88kB  2.18%  google::protobuf::DescriptorPool::Tables::AllocateEmptyString[abi:cxx11]   88.04kB  1.38% 90.59%   113.12kB  1.77%  google::protobuf::DescriptorPool::Tables::AllocateFileTables   72.52kB  1.13% 91.72%    72.90kB  1.14%  ares_init_options      71kB  1.11% 92.83%       71kB  1.11%  _GLOBAL__sub_I_eh_alloc.cc   69.81kB  1.09% 93.92%    69.81kB  1.09%  zcalloc   51.16kB   0.8% 94.72%    51.16kB   0.8%  google::protobuf::Arena::CreateArray (inline)   46.81kB  0.73% 95.45%    60.41kB  0.94%  google::protobuf::Arena::CreateInternal (inline)   37.23kB  0.58% 96.03%    37.23kB  0.58%  re2::PODArray::PODArray   33.53kB  0.52% 96.56%    33.53kB  0.52%  std::__cxx11::basic_string::_M_assign   11.50kB  0.18% 96.74%  2213.77kB 34.58%  Envoy::ConstSingleton::get    6.06kB 0.095% 96.83%    38.85kB  0.61%  google::protobuf::internal::ArenaStringPtr::Set    0.24kB 0.0038% 96.84%  2590.71kB 40.46%  Envoy::Server::InstanceImpl::InstanceImpl         0     0% 96.84%    79.56kB  1.24%  Envoy::(anonymous namespace)::jsonConvertInternal         0     0% 96.84%    84.48kB  1.32%  Envoy::(anonymous namespace)::tryWithApiBoosting         0     0% 96.84%   726.42kB 11.35%  Envoy::Config::ApiTypeOracle::getEarlierVersionDescriptor         0     0% 96.84%    77.22kB  1.21%  Envoy::Config::Utility::createTagProducer         0     0% 96.84%   706.72kB 11.04%  Envoy::Config::Utility::getAndCheckFactory         0     0% 96.84%   707.38kB 11.05%  Envoy::Config::Utility::getFactoryByType...

Ожидаемо, большую часть памяти держит std::make_unique(). И вообще внутри кода Envoy оптимизировать особо нечего главные потребители находятся в сторонних библиотеках. Однако если взглянуть на callgraph или flamegraph, то можно узнать, например, на какие функции обратить внимание, чтобы пореже звать std::make_unique(). Web-интерфейс в этом случае наиболее удобен


$ pprof -http=localhost:8080 /tmp/envoyhprof.0005.heap

В браузере вы увидите что-то вроде


Heap callgraph


и


Heap flamegraph


Можно также проверить, не течет ли память. Вычтем из результата самую первую часть дампа, где происходит инициализация программы:


$ pprof -text -sample_index=inuse_space --base=/tmp/envoyhprof.0001.heap /tmp/envoyhprof.0005.heapFile: envoy-staticType: inuse_spaceShowing nodes accounting for 1460B, 10.38% of 14060B total      flat  flat%   sum%        cum   cum%     1460B 10.38% 10.38%      1460B 10.38%  hist_accumulate         0     0% 10.38%      1460B 10.38%  Envoy::Event::DispatcherImpl::DispatcherImpl(std::__cxx11::basic_string const&, Envoy::Api::Api&, Envoy::Event::TimeSystem&, std::shared_ptr const&)::$_1::operator()         0     0% 10.38%      1460B 10.38%  Envoy::Event::DispatcherImpl::run         0     0% 10.38%      1460B 10.38%  Envoy::Event::DispatcherImpl::runPostCallbacks         0     0% 10.38%      1460B 10.38%  Envoy::Event::LibeventScheduler::run         0     0% 10.38%      1460B 10.38%  Envoy::Event::SchedulableCallbackImpl::SchedulableCallbackImpl(Envoy::CSmartPtr&, std::function)::$_0::__invoke         0     0% 10.38%      1460B 10.38%  Envoy::Event::SchedulableCallbackImpl::SchedulableCallbackImpl(Envoy::CSmartPtr&, std::function)::$_0::operator()         0     0% 10.38%      1460B 10.38%  Envoy::MainCommon::main         0     0% 10.38%      1460B 10.38%  Envoy::MainCommon::run         0     0% 10.38%      1460B 10.38%  Envoy::MainCommonBase::run         0     0% 10.38%      1460B 10.38%  Envoy::Server::InstanceImpl::run         0     0% 10.38%      1460B 10.38%  Envoy::Stats::ParentHistogramImpl::merge         0     0% 10.38%       730B  5.19%  Envoy::Stats::ThreadLocalHistogramImpl::merge         0     0% 10.38%      1460B 10.38%  Envoy::Stats::ThreadLocalStoreImpl::mergeHistograms(std::function)::$_2::operator()         0     0% 10.38%      1460B 10.38%  Envoy::Stats::ThreadLocalStoreImpl::mergeInternal         0     0% 10.38%      1460B 10.38%  __libc_start_main         0     0% 10.38%      1460B 10.38%  event_base_loop         0     0% 10.38%      1460B 10.38%  event_process_active         0     0% 10.38%      1460B 10.38%  event_process_active_single_queue         0     0% 10.38%      1460B 10.38%  main         0     0% 10.38%      1460B 10.38%  std::_Function_handler::_M_invoke         0     0% 10.38%      1460B 10.38%  std::function::operator()

Всё выглядит неплохо, память весьма умеренно тратится только на хранение накопленной статистики.


По закону жанра на этом месте должны начаться проблемы. Заключаются они в том, что не так давно Google выложил в своём аккаунте на GitHub новый, улучшенный tcmalloc. В котором, кэши памяти создаются не для потоков, как в оригинальной версии, а для ядер процессора. В задачах, создающих большое количество потоков, это может заметно улучшить производительность и снизить расход памяти.


Плохая же новость в том, что в новом tcmalloc отсутствует профилировщик. Однако же он теперь не особенно-то и нужен. В частности для профилирования CPU теперь вполне достаточно утилиты perf. Чтобы ею воспользоваться даже не нужно ни с чем линковаться. Всё нужное уже есть в ядре Linux:


$ perf record -g -F 99 -p `pgrep envoy`^C[ perf record: Woken up 1 times to write data ][ perf record: Captured and wrote 0.694 MB perf.data (1532 samples) ]

Результат сохраняется в файл perf.data, формат которого понятен pprof (начиная с некоторой версии):


$ pprof -http=localhost:8080 perf.data

То есть результат совершенно идентичен варианту с использованием gperftools.


Однако имеются подозрения, что perf.data содержит даже больше полезных данных, чем pprof позволяет отобразить. В частности я не смог найти, как сделать разбивку стеков по потокам. Если кто-то знает, напишите, пожалуйста, в комментариях. Такая разбивка может быть полезна для обнаружения узких мест, когда несколько потоков делегируют какую-то работу одному единственному потоку и перегружают его. Пока что для меня незаменимым инструментом для таких случаев служит набор скриптов Брендана Грегга: https://github.com/brendangregg/FlameGraph. Если их применить к имеющемуся файлу perf.data, то получим flamegraph, в котором можно различить три потока один главный и два рабочих.


$ perf script --input=perf.data | ./FlameGraph/stackcollapse-perf.pl > out.perf-folded$ ./FlameGraph/flamegraph.pl out.perf-folded > perf.svg


Впрочем, глядя на такой flamegraph, далеко не всегда мы можем догадаться, что имеем дело с блокировками на перегруженном потоке. Полезнее может оказаться картинка с неработающими потоками, то есть ожидающими снятия какой-нибудь блокировки. Опять же, всё нужное для этого есть в ядре Linux речь идёт о eBPF. Инструментализация кода не требуется. Только убедитесь, что в вашей системе установлен пакет с инструментами для BPF Compiler Collection. В Fedora он называется bcc-tools.


$ /usr/share/bcc/tools/offcputime -df -p `pgrep envoy` 30 > out.stacks$ ./FlameGraph/flamegraph.pl --color=io --title='Off-CPU Time Flame Graph' < out.stacks > off-cpu.svg

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


Это 4 потока
4 workers


Это 9 потоков
9 workers


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


А вот с профилированием памяти не всё так радужно, хотя и тут можно кое-чего добиться полагаясь только на eBPF и на утилиту stackcount из bcc-tools. Для того, чтобы получить flamegraph в стиле pprof, надо сделать следующее


$ sudo /usr/share/bcc/tools/stackcount -p `pgrep envoy`  -U "/full/path/to/envoy:_Znwm" > out.stack$ ./FlameGraph/stackcollapse.pl < out.stacks | ./FlameGraph/flamegraph.pl --color=mem --title="operator new(std::size_t) Flame Graph" --countname="calls" > out.svg

stackcount группирует вызовы к некоторой функции по идентичным стекам вызовов к ней (stack traces) и суммирует их. Обратите внимание на странно выглядящий параметр -U "/full/path/to/envoy:_Znwm". Он указывает на некоторую функцию в пространстве пользователя (в противоположность параметру -K, который может указать на функцию в пространстве ядра). В общем случае он задаётся как -U lib:func, где lib это имя библиотеки, а func имя функции в том виде, как оно выглядит выводе objdump -tT /path/to/lib. В нашем случае _Znwm это не что иное как void* operator new(std::size_t). А путь к исполняемому файлу вместо имени библиотеки указан потому, что есть нюанс Envoy статически слинкован с tcmalloc. К сожалению, из документации вы не узнаете о таких мелочах.


Чтобы понять как C++ компилятор видоизменит (mangle) нужную вам функцию, воспользуйтесь вот таким однострочником


$ echo -e "#include <new>\n void* operator new(std::size_t) {} " | g++ -x c++ -S - -o- 2> /dev/null        .file   ""        .text        .globl  _Znwm        .type   _Znwm, @function_Znwm:.LFB73:        .cfi_startproc        pushq   %rbp        .cfi_def_cfa_offset 16        .cfi_offset 6, -16        movq    %rsp, %rbp        .cfi_def_cfa_register 6        movq    %rdi, -8(%rbp)        nop        popq    %rbp        .cfi_def_cfa 7, 8        ret        .cfi_endproc.LFE73:        .size   _Znwm, .-_Znwm        .ident  "GCC: (GNU) 10.2.1 20201016 (Red Hat 10.2.1-6)"        .section        .note.GNU-stack,"",@progbits

Обратите внимание, что имя функции будет разным на 32 и 64 разрядных платформах из-за разного размера size_t. Кроме того void* operator new[](std::size_t) это отдельная функция. Как, впрочем, и malloc() с calloc(), которые будучи C-функциями свои имена не меняют.


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


Чтобы ответить на вопрос сколько, нужен инструмент, который будет суммировать аргументы вызовов malloc() или new, а лучше все сразу. То есть что-то вроде этого. В идеале хотелось бы, чтобы во внимание принимались ещё free() и delete, но это уже из области магии. Если кто-то уже реализовал такое на eBPF, отпишитесь, пожалуйста, в комментариях.


В качестве заключения хочу порекомендовать всем, кого интересует тема производительности и оптимизации внимательно изучить блог Брендана Грегга. Там бездна полезной информации.

Подробнее..

История Nokia MeeGo

06.01.2021 16:04:08 | Автор: admin

Вступление от переводчика: Эта статья на английском была опубликована в далеком 2012 году. Тогда еще были свежи воспоминания о смене стратегии Nokia, отказе от разработки собственных ОС. А переход на Windows Phone только случился и подавал множество надежд. Сейчас все произошедшее в феврале 2011 года видится исторической вехой на рынке смартфонов и мобильных ОС, которая изменила его раз и навсегда. Я давно положил глаз на этот материал и лелеял надежду на его перевод. Перевод так никто и не сделал, и вот я наконец-то осилил это дело. Не знаю как вам, а мне грустно, что Maemo, MeeGo и даже Windows Phone (куда уж без него) канули в Лету. Без той самой старой Nokia на рыке стало скучно и однообразно. Но тут уж что сделано, то сделано. Я не стал править текст исходя из современных реалий, все описанное положение дел представлено по состоянию на осень 2012 года.

Свои ремарки далее по тексту я буду {выделять курсивом в фигурных скобках}.


11 февраля 2011 года Nokia опубликовала новую стратегию и заключила соглашение о сотрудничестве с Microsoft. Операционная система Windows Phone была выбрана в качестве новой платформы для смартфонов Nokia. MeeGo стал проектом мобильной операционной системы с открытым исходным кодом, который в долгосрочной перспективе будет использоваться для исследования рынка устройств, платформ следующего поколения и взаимодействия с пользователем.

Стратегическое партнерство с Microsoft практически решило судьбу компании Nokia и ОС MeeGo, которая разрабатывалась совместно с Intel с начала 2010 года. Новая стратегия включала отказ от MeeGo и выпуск только одного устройства в двухлетней перспективе.

За неделю до выхода новой стратегии Nokia в Сеть просочилась заметка Стивена Элопа сотрудникам Nokia. В своей записке о горящей платформе Элоп описал проблемы Symbian и MeeGo, а также плохое состояние конкурентоспособности компании по сравнению с экосистемами Apple и Google.

На самом деле, ситуация в Nokia и в разработке MeeGo была настолько дезорганизована за последние пару лет, что публикация новой стратегии вполне могла стать решающим фактором для завершения работы над N9. Команда MeeGo и другие сотрудники Nokia были задеты за живое, и у них была только одна цель закончить продукт на основе MeeGo и отправить его на полки магазинов в течение 2011 года.

Nokia не очень много распространялась о разработке MeeGo. Снимки, просочившиеся в интернет, демонстрируют модель N9 с QWERTY-клавиатурой. Он, как ожидалось, вернет Nokia на вершину рынка смартфонов.

В результате партнерства с Nokia и Microsoft и стратегии с Windows Phone, команда MeeGo была распущена после выпуска N9 и нескольких обновлений прошивки. На это ушло чуть больше года. В конце концов также была похоронена операционная система Meltemi на базе Linux, предназначенная для более дешевых мобильных телефонов, и теперь все доступные ресурсы направлены на Windows Phone. На TaskuMuro.com мы активно следим за разработкой смартфонов Nokia, а также за разработкой операционных систем Maemo и MeeGo на базе Linux. Поскольку в открытом доступе так мало информации об истории MeeGo, мы оставили сообщение на нашем форуме MuroBBS летом 2012 года. В сообщении мы попросили людей, вовлеченных в разработку MeeGo, поделиться своими историями.

Мы получили многочисленные отклики от бывших и нынешних сотрудников Nokia, которые попросили сохранить анонимность. Всего по этой статье было опрошено 10 человек. И большая головоломка под названием Nokia MeeGo начала принимать некую финальную форму. Эта статья в значительной степени основана на информации и интервью из анонимных источников. Мы сделали все возможное, чтобы сравнить информацию, полученную из этих различных источников, и объединить ее с информацией, просочившейся в Интернет за прошедшие годы. Читатели должны понимать, что интервьюируемые работали над проектами, которые были заброшены после нескольких лет разработки. В их словах много обиды, сожалении о потерянном времени, поскольку в прошлом году в Финляндии было уволено около 5000 сотрудников Nokia.

Об авторе

История Nokia MeeGo написана Сампса Курри, который основал технологический сайт Muropaketti в 1999 году. В настоящее время Muropaketti принадлежит Otavamedia. Курри получил степень магистра в Технологическом университете Тампере. В настоящее время Курри производит контент и помогает в разработке сайта через основанную им компанию io-media Ltd. Отзывы о статье могут быть отправлены на sampsa.kurri [a] https://muropaketti.com.

Автор статьи не владеет акциями какой-либо из компаний, упомянутых в статье.

Английский перевод статьи был сделан с помощью активных людей с наших форумов MuroBBS. Отдельное спасибо Алекси Ванттинену.

Nokia до MeeGo: OSSO и Maemo

Nokia 770Nokia 770

С 2005 года очень небольшая группа людей с ограниченными ресурсами в Nokia разрабатывала операционную систему Maemo на базе Linux и устройства на ее основе. Команда была известна как OSSO (Open Source Software Operations), и, по словам одного из членов команды, который работал там с самого начала, целью было создание продукта, который изменит мир. Команда OSSO была переименована в команду Maemo в 2007 году. А в результате партнерства Nokia и Intel в 2010 году она была переименована в команду MeeGo. С самого начала группу возглавлял Ари Якси, который ушел из Nokia в октябре 2010 года и перешел в HP для разработки операционной системы WebOS.

Nokia N800Nokia N800

Первыми двумя устройствами были 770, выпущенный в 2005 году, и его последователь, N800, выпущенный в 2007 году. Оба были разработаны с очень небольшими ресурсами. Поскольку команда была небольшой, всего несколько десятков сотрудников, разработка программного обеспечения была быстрой и очень быстрой.

Не было никакой бюрократии, чтобы замедлить продвижение, и сотрудники описали разработку продукта как игровую площадку. Конечный продукт в основном производился через аутсорсинг без большой помпы и поддержки со стороны топ-менеджмента. Никто не вмешивался в процесс, и это привело к проблемам с качеством готовой продукции. Принимая во внимание небольшие ресурсы и работу с подрядчиками, самая низкая цена всегда была первым приоритетом при выборе компонентов, а остальные требования были на вторых позициях. Низкая производительность оборудования была исправлена последующей оптимизацией программного обеспечения. Сокращение расходов на разработку программного обеспечения не было особо мотивирующим фактором. Учитывая, что экономия была достигнута за счет менее качественных компонентов {насколько я понял речь идет о максимально дешевых компонентах, но не о какой-то отбраковке и прочем прим. перев.}, это затем означало дополнительные усилия в течение следующих нескольких недель при оптимизации производительности.

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

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

В то же время размер команды вырос, а вместе с ней и бюрократия. Это привело к снижению гибкости и к замедлению в разработке программного обеспечения. Особенно трудно было принять предложения по улучшению, которые поступили от разработчиков команды MeeGo, и многие из-за этих предложений так и не увидели свет. В качестве одного из примеров стоит упомянуть был жест смахивания вверх-вниз в пользовательском интерфейсе Swipe, который закрывает текущее приложение. Предложение было сразу же отвергнуто, но разработчик не сдался, поделившись примером функциональности для тестирования другими. В результате во внутренней системе Bugzilla, используемой сотрудниками Nokia для обработки ошибок, появилась цепочка длиной в несколько сотен сообщений, где руководство и разработчики спорили друг с другом по поводу этой функции. Наконец, эта функция была сделана, и в обновлении PR 1.1 она использовалась по умолчанию.

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

Nokia N810Nokia N810

По словам члена команды Maemo, с которым мы беседовали, руководство Symbian боялось возможной конкуренции между N810 и смартфонами на базе Symbian. Уже в 2005 и 2006 годах для некоторых было очевидно, что Symbian устаревшая и древняя платформа. Добавление интерфейса с поддержкой сенсорного экрана в Symbian было сложной задачей. Это положило начало внутреннему соревнованию между командами Symbian и Maemo.

Nokia N900Nokia N900

После анонса устройства N810 команда Maemo начала думать о концепции смартфона, ориентированного на массового потребителя. Первоначально планировалось просто добавить телефонные возможности к N810, но в конечном итоге он сменился на совершенно новое устройство под кодовым названием Rover, так известного как N900. Он был создан с использованием в основном тех же методов, что и с прежними устройствами Maemo, используя аутсорсинг большую часть времени. Создание концепции проекта было более сложным, поскольку она создавалась шаг за шагом без общего знания того, сколько времени было доступно. При этом команда смогла располагать бОльшими ресурсами человеческими и финансовыми.

В N900 использовалась ОС Maemo 5 под кодовым названием Fremantle. Ее интерфейс Hildon UI был написан на GTK+. Параллельно с N900 была начата разработка Maemo 6 под кодовым названием Harmattan. Его пользовательский интерфейс должен быть полностью переписан на Qt.

Nokia продолжала разрабатывать Symbian и Maemo для смартфонов с сенсорным экраном, поскольку Symbian по-прежнему продавалась хорошо, и никто не догадывался, насколько быстро телефоны на базе iOS и Android перекроят рынок смартфонов. Внутри Nokia участники команды Maemo понимали, что менеджмент команды Symbian боится за свои места, и использует свои позиции в компании, чтобы любым способом замедлить развитие Maemo.

Nokia Maemo + Intel Moblin = MeeGo

На MWC в Барселоне в феврале 2010 года Nokia и Intel объявили, что объединят свои разрабатываемые операционные системы на базе Linux в новый совместный проект под названием MeeGo.

Тогда Nokia занималась разработкой операционной системы Maemo 6, которая была преемницей Maemo 5, использованной в 2009 году в смартфоне Nokia N900. Intel разрабатывает свою операционную систему Moblin (Mobile Linux) с 2007 года, и последняя версия Moblin 2 была специально разработана для работы в нетбуках с процессорами Atom с архитектурой Intel x86. MeeGo использовал среду разработки Qt и ядро от Moblin.

Nokia и Intel полагали, что производители устройств, операторы, производители чипов, разработчики программного обеспечения и приложений смогут широко использовать MeeGo. В пресс-релизе было указано, что Nokia и другие производители представят устройства на базе MeeGo в течение 2010 года.

Nokia намеревалась повысить доверие к Maemo, сформировав альянс с Intel, но объединение команд разработчиков двух огромных корпораций было сложной задачей, привело к путанице и еще больше замедлило процесс разработки.

Harmattan

Nokia приступила к разработке операционной системы Maemo 6 еще в 2008 году, и Nokia и Intel решили объединить Maemo и Moblin в MeeGo. Nokia решила продолжить разработку Maemo 6 под кодовым названием Harmattan и сделать его максимально совместимым с MeeGo. Nokia назвала свои версии операционной системы Maemo разными ветрами. Например, харматан это название пассата в Западной Африке.

Предполагалось, что Harmattan станет мостом между Maemo и MeeGo, который разрабатывался в сотрудничестве с Intel. Harmattan был разработан с использованием API совместимого с MeeGo версии 1.2. APT от Debian должен быть использован в качестве системы пакетов для приложений, тогда как в MeeGo пакетным менеджером был RPM (Red Hat Package Manager).

Проблемы с инструментами разработки пользовательского интерфейса

Примерно в то же время, в 2008 году Nokia купила инструментарий Qt у норвежской компании Trolltech. Qt является кроссплатформенной средой разработки программного обеспечения и пользовательских интерфейсов с поддержкой C++. После приобретения Qt, команды Symbian и Maemo начали работу над собственными инструментами для создания пользовательского интерфейса ОС для смартфонов на основе Qt QGraphicsView. Инструмент разработки команды Symbian был известен как Orbit, а инструмент от Maemo был известен как libdui (Direct UI Library). Сотни людей работали над этими проектами в Nokia, и многие понимали, что в этом нет никакого смысла.

Вскоре при разработке libdui было обнаружено, что QGraphicsView был откровенно сырым. Были обнаружены новые проблемы и в самом Qt. В QGraphicsView не было никакой поддержки виджетов, поэтому ее нужно было разрабатывать поверх QGraphicsView. Постоянно меняющиеся требования к разработке пользовательского интерфейса вызывали внутренние проблемы в команде разработчиков, а приложения уже создавались поверх libdui, хотя его разработка еще не была закончена.

Orbit от команды Symbian очень похож на libdui. Тем не менее, команды никак не обменивались наработками. Ходили слухи, что в какой-то момент даже решили, что Orbit должна заменить libdui, что повлечет за собой полное переписывание слоя пользовательского интерфейса Harmattan. В конце концов, от этой идеи отказались и несколько месяцев работы пошли прахом.

Пользовательский интерфейс Harmattan был написан с помощью libdui, имя которого позже было изменено на libmeegotouch. В дополнение к этому началась разработка Qt Components набора виджетов с использованием QML на основе JavaScript (Qt Meta-object Language). Qt Components должны были наконец объединить разработку пользовательского интерфейса MeeGo и Symbian, и приложения, написанные на QML, будут работать в обеих операционных системах.

Концепция пользовательского интерфейса Maemo 6

На мероприятии Maemo Summit в октябре 2009 года, состоявшегося еще до начала сотрудничества между Intel и MeeGo, Nokia продемонстрировала концепт интерфейса Maemo 6, разработанного с помощью Qt. В Maemo 6 было обещано объединить стандартный пользовательский опыт и онлайн-составляющую под одной визуальной крышей. Рабочий стол пользовательского интерфейса состоял из нескольких областей (принцип холста) и был заполнен апплетами, виджетами и значками запуска приложений.

Поддержка мультитач для емкостных сенсорных экранов планировалась для Maemo 6 как для альбомной, так и для портретной ориентации. Nokia раньше не поддерживала портретную ориентацию в своих устройствах Maemo, поэтому это было большим изменением.

UMPC Portal, Maemo 6 Early Info. (Slides and info direct from the MaemoSummit)

Интерфейс Harmattan

Оригинальная концепция

Изначально интерфейс Harmattan основывался на принципе Теории деятельности, ориентированной на изучении человеческого поведения и рабочих процессов. Ее задача понять общество, личность и, самое главное, как это все взаимодействует. Первоначально теория была разработана русским психологом Выготским.

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

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

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

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

Первые прототипы интерфейса Harmattan UI на основе Flash были созданы весной 2009 года. Вначале идея заключалась в том, что в них будет только несколько экранов и небольшое количество виджетов.

Первая версия интерфейса Harmattan

Из-за проблем во внутренней коммуникации в команде Maemo первоначальная концепция значительно усложнилась. Результатом стала осовремененная версия пользовательского интерфейса Symbian. Первые реализованные концепции включали домашний экран, на который можно добавлять виджеты, переключатель приложений, область уведомлений и панель запуска приложений.

Оригинальный пользовательский интерфейс Harmattan, изображение предоставлено Tech CrunchОригинальный пользовательский интерфейс Harmattan, изображение предоставлено Tech Crunch

В течение 2009 года оригинальная концепция и теории, стоящие за ней, были пересмотрены из-за коммуникативных проблем в команде разработчиков и ее расширения. Вместо нескольких холстов на экране появилось много элементов с обширным набором виджетов внутри. Требований стало больше, и количество домашних экранов пришлось увеличить до нескольких. Пользовательский интерфейс становился дезорганизованным и сложным, особенно для разработчиков, но отзывы от пользовательских тестов были лучше, чем когда-либо прежде. Идея была в том, чтобы вложиться в графику интерфейса Harmattan, но эти усилия не были видны в первых реальных версиях интерфейса. Он отличался и из-за излишней сложности было мало общего с оригинальными психологическими теориями. Между тем крайний срок выпуска первого устройства Harmattan от Nokia под кодовым названием Columbus прошел, и разочарование разработчиков возросло.

Интерфейс Simple Dali

Интерфейс Simple Dali, изображение предоставлено: EngadgetИнтерфейс Simple Dali, изображение предоставлено: Engadget

Люди, которые стали руководителями по дизайну пользовательского интерфейса в конце 2009 года, не поняли всей концепции Harmattan UI. И в итоге она была заброшена. В конце декабря 2009 года началась разработка нового интерфейса названием Simple Dali. С его совершенно другой идеей последние остатки оригинальной теории деятельности были отброшены.

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

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

Simple Dali изначально планировался к релизу в июле 2010 года, то есть через шесть месяцев. Его идея была Dali как ваше основное устройство. По плану все компоненты программного обеспечения должны быть на той стадии, которая позволяет использовать устройство в качестве основного и каждый день. И хотя эта цель была достигнута и это был почти готовый интерфейс, задачи в очередной раз изменились.

Весной 2010 года возникли опасения, что концепция Simple Dali не будет достаточно конкурентоспособной. Многозадачность сама по себе не может создать хорошего фона, достаточного для продажи устройств. Разработчиками были сделаны новые улучшения для пользовательского интерфейса и некоторые ранние идеи были снова возвращены к жизни.

Swipe UI

В августе 2010 года началась разработка третьей версии интерфейса для Harmattan. Первый рабочий прототип интерфейса под кодовым названием Seattle был закончен через пару дней. Из первых концептуальных изображений стало очевидно, что этот интерфейс был, вероятно, лучшим из когда-либо существовавших в смартфонах. В Seattle было явно видно сколько усилий было вложено в дизайн. Также к жизни вернулись некоторые из основных принципов первоначального пользовательского интерфейса Harmattan, которые были проигнорированы в Dali.

По словам многих из опрошенных нами людей, концепт Seattle UI или Swipe UI был разработан дизайнерской студией 8020 из Нью-Йорка, в которой работают несколько бывших сотрудников Apple и Adobe. Логотип Nokia виден на странице ссылок на веб-сайте компании {сейчас он недоступен прим. перев.}, но изображения Swipe UI не найдены. Несмотря на то, что концепция исходила от внешнего аутсорсера, остальные элементы дизайна были созданы силами Nokia.

Интерфейс Swipe в сочетании с новым устройством под кодовым названием Lankku получил обширную поддержку в команде MeeGo. Все знали, что этот продукт будет лучшим. Осталось только сделать его доступным для потребителей вместе с последующими проектами.

Устройства Harmattan и MeeGo, разработанные Nokia

По словам сотрудника, который с самого начала работал в командах OSSO, Maemo и MeeGo, оригинальной стратегией MeeGo Кая Остямо (управляющего подразделением Nokia Devices с 2007 по 2010 год) была разработка одного флагманского телефона на рынке в год по аналогии с Apple. По крайней мере, в этой стратегии не планировалось одновременно выводить на рынок множество устройств на базе MeeGo. Ведь даже разработка одного устройства требовала огромных затрат, что уж говорить о нескольких.

Columbus (RM-581)

Первое устройство Nokia на Harmattan получило кодовое имя Columbus и должно быть выпущено в первой половине 2010 года. То есть, всего через несколько месяцев после объявления о сотрудничестве по разработке MeeGo между Nokia и Intel. Тем не менее, путаница и задержки в разработке интерфейса Harmattan привела к отставанию по сравнению с первоначальным графиком выпуска. Релиз Columbus был отменен в конце 2009 года, когда была начата разработка интерфейса Simple Dali для нового устройства под кодовым названием Dali.

Дизайн Columbus похож на Nokia N8 на базе Symbian^3, который увидел свет осенью 2010 года. После отказа от Columbus было решено использовать его дизайн в телефонах Symbian. Это вызвало восхищение у команды Maemo.

На сайте My Nokia Blog опубликован набор изображений устройства Columbus, из которого видно, что устройство предназначалось для использования в альбомной ориентации. Этот вывод можно сделать на основе положения логотипа на окантовке экрана. На снимках отсутствует нижняя заглушка.

На задней стороне находится 12-мегапиксельная камера с автофокусом и оптикой Carl Zeiss, скорее всего та же, что и в N8.

Источник: My Nokia Blog, Exclusive: Leaked Images of RM-581 ColumbusHarmattan Prototype

N9-00 Dali (RM-680)

После задержек в разработке пользовательского интерфейса Harmattan и отмены Columbus в качестве устройства для разработки использовался смартфон под кодовым названием Dali с клавиатурой QWERTY. Весной 2010 года он был платформой разработки для интерфейса Simple Dali замену оригинального интерфейса для Harmattan, который был отменен в конце 2009 года.

Dali должен был выпущен на рынок под индексом N9-00. Тем не менее, выпуск было решено отменить, потому что его посчитали устаревшим к моменту поступления в продажу. Некоторый объем устройств (92 000 штук) уже был изготовлен, поэтому Dali был выпущен одновременно с N9 как устройство только для разработчиков под названием N950. Его нельзя было купить, но Nokia распространяла его среди разработчиков.

Корпус Dali был сделан из алюминия и имел 4-дюймовый ЖК-дисплей с разрешением 854480. Сердцем устройства был чипсет Texas Instruments OMAP 3630 (ARM Cortex A8), графический чип PowerVR SGX530 и 1 ГБ ОЗУ. Телефон также был оснащен модулем камеры на 12 мегапикселей.

Engadget, Nokias QWERTY-slidin N9 shows up in the wilds of China

N9-01 Lankku (RM-696)

21 июня 2011 года Nokia выпустила N9, который проходил под кодовым названием Lankku. Он использовал операционную систему MeeGo 1.2 Harmattan. Вместо того, чтобы рекламировать его как телефон на MeeGo, его фишками были дизайн и интерфейс Swipe. Корпус N9 изготавливается путем фрезерования крышки из единого куска поликарбоната, сверху было изогнутое защитное стекло. Позже Nokia использовала дизайн N9 в своих телефонах Lumia на Windows и выиграла множество дизайнерских премий. Элементы из Swipe UI использовались в доступных телефонах Asha от Nokia.

Lankku должен был появиться на рынке с индексом N9-01. После того, как Nokia объявила о своей новой стратегии на рынке смартфонов в апреле 2011 года выпуск модели N9-00 с QWERTY-клавиатурой (кодовое название Dali) было решено отменить, именно Lankku был выбран для разработки готового продукта и получил название N9.

N9 имеет те же характеристики, что и Dali. Это SoC Texas Instruments OMAP 3630 (ARM Cortex A8), работающим на частоте 1 ГГц, графическим процессором PowerVR SGX530 и гигабайтом оперативной памяти. В задней части находится 8-мегапиксельная камера с оптикой Carl Zeiss и двойная светодиодная вспышка.

N9 появился в рознице в сентябре 2011 года, и для него было выпущено несколько обновлений программного обеспечения. Последнее из которых PR 1.3, стало доступно в июле 2012 года. Пару дней спустя многие члены команды MeeGo покинули компанию, включая менеджера Сотириса Макриганниса.

Lauta (RM-742)

Nokia собиралась выпустить телефон под кодовым названием Lauta с клавиатурой QWERTY сразу после Lankku в конце 2011 года. Корпус телефона был, как и у N9 сделан из поликарбоната. Единственное отличие выдвижная клавиатура QWERTY. Внутри Lauta использован тот же OMAP 3630 от TI, что и в N9.

Это был бы преемник N900, которого так ждали многие, но он никогда не видел свет как готовый продукт. Nokia обычно давала официальный индекс модели в последнюю минуту перед выпуском, а индекс Lauta не известен. И не факт, что он вообще когда-либо существовал.

Источник: My Nokia Blog, Leaked Prototype: Nokia Lauta RM-742 Cancelled Immediate N9 Successor

Soiro (Intel MeeGo)

Так же Nokia разработала устройство на основе SoC Intel Atom и архитектуры x86 под кодовым названием Soiro. Имеется весьма скудное количество информации об этом устройстве, но оно точно использует тот же дизайн, что и Lauta. Это означало наличие выдвижной QWERTY-клавиатуры.

Вместо Harmattan в Soiro использовалась платформа Ilmatar _{которую назвали в честь богини воздуха Ильматар, в финской мифологии участвовашей в создании мира прим. перев.}_, что означало применение пакетного менеджера RPM и адаптацию платформы под аппаратное обеспечение Intel. По словам разработчиков программного обеспечения, с которыми мы беседовали, работа с платформой Ilmatar и оборудованием Intel была чрезвычайно сложной задачей.

Интерфейс Ilmatar должен был использовать другой подход, целью которого было выяснить, какая информация будет получена от пользователя. Для этого использовались современные технологии, которые определяли как эта информация может быть представлена в самом интерфейсе. Новый интерфейс, отличался от того, что было ранее. Интерфейс Ilmatar должен был стать одним из преимуществ устройства Intel-MeeGo от Nokia.

Планшет Senna

Engadget, Nokia collects design patent for a tablet

Многие бывшие работники Nokia, с которыми мы беседовали, подтвердили, что дизайн планшета под кодовым названием Senna до этого засветился в патентах компании. Senna был похож на гигантский N9, и был основан на платформе ST-Ericsson NovaThor U8500. Он поддерживал видеосъемку с разрешением 1080p. Senna использовал настоящую MeeGo вместо Harmattan, но пользовательский интерфейс и приложения были такими же, как в N9.

U8500 состоит из двух ядер ARM Cortex A9, графического процессора ARM Mali 400 и имеет модем HSPA +, интегрированный в один и тот же чип.

Рабочий прототип планшета с дизайном N9 был также представлен в конце 2010 года генеральному директору Стивену Элопу, который похвалил устройство. Однако, немного позже Senna навсегда канул в Лету вместе с отказом от стратегии MeeGo.

Engadget, Is this Nokias tablet-shaped MeeGo device?

Fonearena, Nokia MeeGo Device Based on ST Ericsson U8500 Platform

Сотрудничество Nokia и Intel

В времена руководства Олли-Пекки Калласвуо компания Nokia активно работала за пределами США. Особенно активна она была в конце эпохи его правления. Nokia полностью провалилась в Северной Америке, ситуация была катастрофической. iPhone от Apple и Android от Google обеспечили более простой пользовательский опыт, чем Symbian. Поэтому, Nokia могла продавать только продукты, представленные глобально. Их предлагали только мобильным операторам и клиентам из Америки, которые явно об этом просили.

В начале 2010 года стало ясно, что на североамериканском рынке будут доминировать сети LTE и телефоны с поддержкой LTE. В то же время Nokia приняла критические решения относительно железа, которое будет использоваться в будущих устройствах MeeGo.

В октябре 2008 года Texas Instruments объявила, что прекратит развивать направление модемов для смартфонов и начала поиск покупателя на этот бизнес. Будучи в весьма затруднительном финансовом положении, TI намеревалась сэкономить около 200 миллионов долларов и сосредоточиться исключительно на разработке процессора OMAP 4.

Для Nokia это означало конец использования TI OMAP на смартфонах с MeeGo. А все, потому что ранее Nokia решила покупать чипсеты для смартфонов, то есть процессор и модем у одного и того же производителя. Nokia использовала SoC OMAP от TI во всех своих ранних устройствах на Maemo, а также разрабатывала свои устройства Harmattan на основе TI OMAP 3640.

  • N770: OMAP 1710

  • N800: OMAP 2420 (330 МГц)

  • N810: OMAP 2420 (400 МГц)

  • N900: OMAP 3430

  • N950, N9 и Lauta: OMAP 3640

Альтернативами линейкам SoC OMAP 3 от TI были Qualcomm и Intel. Nokia отдала предпочтение Intel. Qualcomm могли бы предложить выполнение адаптации аппаратного обеспечения, низкоуровневой прослойки ПО, объединяющего операционную систему с чипсетом. Однако она не помогла бы в разработке операционной системы, то есть Harmattan или MeeGo. У Intel была скороспелая MeeGo и возможность сотрудничества в этом направлении.

Один из собеседников назвал решение относительно Intel катастрофическим. Однако для Qualcomm, MeeGo не была бы слишком приоритетной разработкой по сравнению с Android и Windows Phone. Выбор Intel как поставщика, полностью игнорировал рынок Северной Америки, поскольку у Intel не было значительных планов по поддержки CDMA-сетей, которые широко используются в США.

Nokia и Intel также вложили значительные средства в разработку сетевой технологии четвертого поколения WiMAX, которая параллельно конкурировала с LTE. Среди конкурентов по 4G первое появление WiMAX состоялось, когда Sprint построил сеть 4G в США с использованием технологии WiMAX. Однако, развертывание сети было медленным, и на практике скорости передачи данных в сети были далеки от теоретических максимальных скоростей.

Предлагаемые LTE лучшая совместимость, надежность и фактические скорости передачи, сделали эту технологию предпочтительной для операторов сетей при построении сетей 4G. Когда Nokia делала свой будущий выбор аппаратного обеспечения после OMAP от TI, у Intel не было осмысленного плана или графика реализации поддержки LTE.

Даже сегодня, по прошествии 2,5 лет, Intel не предлагает интегрированную поддержку LTE в своем последнем SoC Atom Medfield. Она только объявила о начале поставок тестовых версий своего модема Intel XMM 7160 к концу года, а также о доступности этих чипов в 2013.

TechCruch, Intel Confirms Medfield x86 Chips Dont Support LTE Yet

Переговоры с Qualcomm были, по-видимому, возобновлены позже, и планировалось выпустить устройство MeeGo на основе Snapdragon от Qualcomm после выпуска аппарата на базе Intel MeeGo.

Дополнение: После публикации материала мы получили информацию, что Nokia в начале 2011 года разрабатывала версию N9 с Qualcomm Snapdragon для рынка США (скорее всего, RM-716). Это дало возможность выбрать Nokia новую стратегию. так как Windows Phone был создан на аналогичной платформе. Прототип Sea Ray (Lumia 800) с дизайном, идентичным N9, демонстрировался сразу после запуска N9.

Платформы Intel для смартфонов: Moorestown и Medfeild

В дополнение к отсутствию поддержки LTE, другой разработчик MeeGo рассказал, что Intel пыталась со своей стороны замедлить развитие MeeGo. MeeGo был разработан с поддержкой архитектур x86 и ARM, а набор из чипсета Intel Atom и ОС MeeGo, который получил кодовое название Ilmatar еще не был готов. Intel боялась, что она будет не самой сильной стороной с ее чипами на x86, и многие вещи, связанные с разработкой операционной системы, были полностью свалены на Nokia.

Весной 2010 года Intel представила на рынке платформу для смартфонов под кодовым названием Moorestown, которая состояла из процессора под кодовым названием Lincroft, изготовленного по техпроцессу 45 нм, чипа периферии Langwell (65 нм) и модема. Семейство чипсетов Atom Z6xx работало на тактовой частоте 1,2-1,9 ГГц, имело одно ядро процессора и графический процессор Intel GMA 600. Платформа Moorestown так и не была выпущена на рынок смартфонов и была заброшена Intel.

В начале 2011 года Intel показала платформу Medfield, изготовленной по техпроцесссу 32 нм, в которой все функции сведены в один SoC под кодовым названием Penwell. Платформа Penwell оснащена процессором Atom с тактовой частотой 1-2 ГГц с поддержкой Hyper-Threading, графическим процессором PowerVR SGX 540, 512 КБ кэш-памяти второго уровня и контроллером памяти LPDDR2.

В течение 2012 года было выпущено несколько телефонов Android на базе Medfield, таких как Lenovo K800 и Orange San Diego. RAZR i от Motorola самый продвинутый смартфон на базе Intel, в котором используется платформа чип Atom Z2460 (Medfield) с частотой 2 ГГц.

Стивен Элоп как генеральный директор Nokia

Главным изменением, когда Стивен Элоп занял кресло генерального директора Nokia стал фокус на рынок Северной Америки. Согласно взглядам Элопа, тенденции, которые берут свое начало в США, будут доминировать по всему миру. Это доказали iPhone и Android. Вот почему Nokia должна была быть конкурентоспособной на сложном американском рынке, чтобы добиться успеха во всем мире.

Вскоре после начала работы в Nokia Элоп начал работу над проектом Sea Eagle, целью которого было разобраться и проанализировать альтернативы стратегии Nokia на рынке смартфонов. В дополнение к десяткам сотрудников внутри компании, были наняты консультанты извне. В результате было принято решение, что комбинация Symbian и MeeGo была недостаточна для успешной долгосрочной стратегии.

В США AT&T согласилась бы продавать N9, хотя аппаратно он считался устаревшим по сравнению с конкурентами Android. Видимо, еще одна версия N9 была в разработке для Verizon под кодовым названием RM-716 {как раз та самая версия на Snapdragon, см. выше прим. перев.}. Даже если бы N9 был выпущен в Северной Америке в 2011 году, у Nokia не было преемника с поддержкой LTE, который можно было бы продавать в долгосрочной перспективе на динамичном рынке смартфонов.

В записке, которую Элоп, разослал своим сотрудникам, было отмечено, что к концу 2011 года Nokia может поставить на рынок только один телефон на MeeGo. По ходу анализа ситуации, выяснилось, что у команды MeeGo не было ни одного устройства, которое можно было бы показать Элопу или правлению Nokia. А ведь эти устройства должны были появится к праздникам конца 2010 года.

Устройства на основе OMAP 3630, примененного в N9, могли бы появиться на рынке в сжатые сроки, но экосистему для конкуренции с Apple и Google, пришлось бы строить вокруг чипа без LTE и поддержки североамериканских операторов. Так же по ходу сотрудничества с Intel не было бы чипсета среднего класса, который позволил создать конкурента с более дешевыми телефонами Android. Symbian для этого более не подходил.

Летом 2011 года работа над Nokia N9 была завершена, и он был готов к релизу. Поставки в магазины начались осенью этого же года, так как у Nokia наконец-то был четкий план по разработке. Это был прямой результат стратегии Windows Phone принятой Nokia и Microsoft. Компания дала полномочия команде принимать решения, над проектом работало меньше людей, внутреннее и внешнее соперничество в Nokia наконец-то прекратилось. Все сосредоточились на завершении продукта.

В итоге MeeGo не привлекла других производителей. Nokia была лидером рынка, и другие считали, что Nokia занимает слишком много места в проекте MeeGo. В конце 2010 года были проведены переговоры с Samsung, LG и Sony Ericsson, но никто из них не решился на сотрудничество с Nokia для развития экосистемы MeeGo. Кроме того, крупные европейские операторы одновременно отказались от инвестиций в проект.

Горящая платформа и новая стратегия смартфонов Nokia (февраль 2011 г.)

В начале февраля 2011 года генеральный директор Стивен Элоп направил сотрудникам компании записку, в которой подчеркивалось текущее состояние компании, проблемы и перспективы на будущее.

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

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

Элоп написал, что все последние месяцы он обсуждал ситуацию с акционерами, операторами, разработчиками, поставщиками и сотрудниками, и сказал, что Nokia также стояла на краю горящей платформы. Под платформой Элоп подразумевал мобильные телефоны Nokia, смартфоны, операционные системы MeeGo и Symbian. На этой платформе, однако произошел, не один взрыв. Их было много. При этом он ссылался на агрессивных конкурентов, таких как Apple iPhone, Google Android и дешевые мобильные телефоны как грибы после дождя, появляющиеся на рынке Китая. По словам Элопа, на 2011 год у Nokia не было продукта, который был бы даже близок к пользовательскому опыту iPhone выпущенному в 2007 году. А Android за прошедшие два года уже обогнал Symbian.

Ожидалось, что MeeGo позволит укрепить позиции на рынке смартфонов высокого класса, однако, по словам Элопа, в обозримой перспективе у Nokia будет только одно устройство MeeGo к концу 2011 года.

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

Nokia + Microsoft = Lumia + Windows Phone

В соответствии с новой стратегией Nokia, объявленной 11 февраля 2011 года, компания договорилась о стратегическом партнерстве с Microsoft для создания глобальной мобильной экосистемы. ОС Windows Phone 7 от Microsoft, выпущенная осенью 2010 года, и ее последующие версии станут новой основной платформой для смартфонов Nokia. Nokia объявила о разработке новых функций для системы в тех областях, где компания является лидером на рынке, например, в области цифровых изображений.

С вновь объявленным партнерством Nokia внесет свой вклад в будущее платформы Microsoft Windows Phone. Nokia предоставит экспертные знания в области проектирования аппаратного обеспечения, языковой поддержки и локализации программного обеспечения и поможет вывести Windows Phone в новые ценовые сегменты, области рынка, новые регионы.

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

Nokia и Microsoft объединят свои силы для создания экосистемы с невероятными глобальными масштабами. Теперь мы как тройка удалая, продолжил Элоп.

Nokia Lumia 700 и 800Nokia Lumia 700 и 800

Nokia выпустила свои первые телефоны Lumia 710 и 800 на базе Windows Phone 7.5 в сентябре 2011 года, которые представли накануне на мероприятии Nokia World.

Jolla продолжает разработку MeeGo от Nokia

Финская компания Jolla Ltd., основанная бывшими разработчиками MeeGo из Nokia, вышла в свет через Twitter в июле 2012 года. Компания, в которой на данный момент работает около 60 человек, продолжает разработку операционной системы и смартфонов MeeGo, где ранее остановилась Nokia.

Операционная система на базе MeeGo, использующая пакетный менеджер RPM, получила название Sailfish. Jolla запустит лицензирование Sailfish для производителей устройств весной 2013 года. Sailfish строится на основе проекта с открытым исходным кодом Qt и Mer Core и масштабируема для использования в смартфонах, планшетах и телевизорах, и других устройствах.

Jolla представит интерфейс системы, который она разработала, на мероприятии Slush, которое состоится 21-22 ноября. Там же Jolla также собирается анонсировать SDK для ОС Sailfish. Кроме того, Jolla намерена раскрыть информацию о своем устройстве на Sailfish до Рождества.

Согласно пресс-релизу Jolla, они объединили партнеров, включая производителей чипов, OEM и ODM, операторов и розничных продавцов. Они также собрали около 200 миллионов евро на создание экосистемы вокруг операционной системы Sailfish. Эти операции будут управляться из Гонконга, так как компания полагает, что следующие большие изменения на рынке мобильной связи должны произойти в Китае.

Заключение

Практически все нынешние и бывшие сотрудники Nokia, у которых я брал интервью, высоко оценили работу команд Maemo и MeeGo, хотя в процессе было набито много шишек. Состав команды был очень многонациональными, а задачи были очень интересными, и все участники по-настоящему радели за общее дело. Многие заявили, что гордятся N9.

Организация, однако, стала ахиллесовой пятой проекта. Под конец отдельные разработчики не имели права голоса или, что еще хуже, не знали о решениях и изменениях, которые произошли за их спиной. Многие сотрудники Nokia, с которыми мы беседовали, были в то время сосредоточены на своей конкретной задаче и не знали об общей картине развития MeeGo. Система создавалась в различных командах, которые не контактировали друг с другом. Никто не убедился, что кусочки головоломки в итоге совмещаются.

Оглядываясь назад, можно легко указать на факторы, которые привели к падению MeeGo. Nokia создавала Harmattan и MeeGo вместе с Symbian. Ресурсы тратились впустую, когда обе команды разрабатывали свои собственные инструменты проектирования пользовательского интерфейса на основе Qt. Приложения создавались с использованием незавершенных инструментов разработки. Кроме того, отсутствовала коммуникация внутри команды Maemo. Развитие Harmattan началось вместе с Fremantle или Maemo 5, но между соответствующими командами не было обмена информацией. Ошибки развития, допущенные с Fremantle, повторялись при разработке Harmattan.

С Harmattan не было четкого представления о том, что это будет за продукт. У разных менеджеров по продукту было совершенно разное представление о том, что должно получится в итоге. Не было ни одного ответственного человека, принимающего решения на уровне продукта. Многие аутсорсеры и целые команды были привлечены, даже не зная, что они должны делать. Структура организации разрасталась как снежный ком.

Интерфейс Harmattan был разработан без понимания того, в каком устройстве он будет применен. В конечном итоге интерфейс был переработан дважды, и это заняло почти два года. Во время разработки были похоронены два устройства Columbus и Dali. Возможно, Swipe UI и N9, была бы успешной комбинацией, но платформа OMAP 3 от TI считалась устаревшей на момент выпуска N9. Не было речи и о поддержке LTE.

MeeGo стал новым Symbian в начале 2009 года. Все доступные ресурсы и персонал были брошены на MeeGo. У новых сотрудников могло не быть какой-либо конкретной задачи, потребовалось много времени, чтобы найти для них какие-то подходящее место в структуре. Появлялось все больше руководящих должностей, что в итоге не помогало двигать проект вперед и вести его к завершению. Каждый в Nokia имел свое мнение о MeeGo, и команда MeeGo слушала всех.

Выбор Intel в качестве партнера по разработке ОС и предоставлению железа был самой большой ошибкой. Intel годами разработала мобильный чипы на базе Atom x86, но только в этом году первые смартфоны на базе x86 были поступили в продажу. Даже сейчас у Intel нет модема для сетей LTE, и эта ситуация продлится до 2013 года. Более того, у Intel не было чипа для устройств начального и среднего уровня. А это было необходимо, чтобы конкурировать с недорогими смартфонами Android.

Пока Nokia погружалась в пучину разработки Harmattan и MeeGo, ее злейшие конкуренты Apple и Google успешно создали работающие экосистемы вокруг своих операционных систем и захватили рынок Северной Америки. Nokia попыталась привлечь других производителей к разработке экосистемы MeeGo. Однако заинтересованных сторон не было, и Nokia осталась одна. Без поддержки LTE, а также без надежных партнеров в войне экосистем прорыв на рынок США был бы едва ли выполним.

iOS от Apple закрытая платформа, а Google не позволил бы Nokia иметь какие-либо преференции при присоединении к платформе Android. Nokia выбрала Windows Phone в качестве своей новой стратегии для смартфонов под руководством Стивена Элопа и начала стратегическое сотрудничество с Microsoft. Теперь у Nokia есть Windows Phone 8 и полный карт-бланш на все.

В этой статье мы в основном брали интервью у финских сотрудников Nokia. Если у вас есть более подробная информация, чтобы поделиться анонимно, пожалуйста, свяжитесь с sampsa.kurri [a] https://muropaketti.com. Особенно приветствуется вся информация о железе от Intel, Lauta, Soiro и Qualcomm.

Подробнее..
Категории: *nix , Гаджеты , История it , Meego , Maemo , Nokia n900

Опубликован стабильный релиз самодостаточных пакетов Flatpak 1.10.0

18.01.2021 14:21:57 | Автор: admin

Отличные новости в понедельник, %username%. На днях была опубликована стабильная ветка инструментария Flatpak 1.10. Она предназначена для сборки самодостаточных пакетов, которые не привязаны к конкретным дистрибутивам Linux и выполняются в специальном контейнере, изолирующем приложение от системы.

Flatpack-пакеты гарантированно работают для Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux и Ubuntu. Они также входят в репозиторий Fedora и поддерживаются штатным софтом управления приложениями GNOME. Под катом подробнее о новинке и ее возможностях.

Что такое Flatpak?


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

Инструментарий обеспечивает и высокий уровень информационной безопасности, позволяя выполнить сомнительное приложение в изолированном контейнере. В этом случае доступ предоставляется лишь для сетевых функций и файлов пользователя, которые связаны с приложением. Плюс ко всему, с Flatpak можно устанавливать самые свежие выпуски приложений без необходимости вносить изменения в систему. Так, Flatpak-пакеты готовятся для LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio и десятков других приложений.

Чтобы снизить размер пакета, разработчики включили лишь специфичные для приложения зависимости. А вот все основные библиотеки оформлены в виде подключаемых runtime-приложений. У Flatpack есть ключевое отличие от Snap последний использует компоненты окружения системы и изоляцию на основе фильтрации системных вызовов. А вот Flatpack создает отдельный от системы контейнер, оперируя крупными runtime-наборами, так что в качестве зависимостей предоставляются не пакеты, а типовые системные окружения. Это могут быть любые библиотеки, которые нужны для работы программ GNOME/KDE.

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

В одной системе может быть установлено несколько различных runtime или несколько версий одного runtime. Контейнер с приложением в качестве зависимости использует привязку к определенному runtime без учета отдельных пакетов, из которых состоит runtime. Недостающие элементы упаковываются вместе с приложением. При формировании контейнера содержимое runtime монтируется как раздел /usr, а bundle монтируется в директорию /app.

Начинка runtime и контейнеров приложений формируется с использованием технологии OSTree. В этом случае образ обновляется из Git-подобного хранилища. Это сделано для того, чтобы можно было применять методы версионного контроля к компонентам дистрибутива. Например, пользователь может откатить систему к предыдущему состоянию. Стоит выделить и то, что RPM-пакеты транслируются в репозиторий OSTree при помощи специальной прослойки rpm-ostree.

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

Изолированное окружение не зависит от используемого дистрибутива. Так что при соответствующих настройках пакета у окружения нет доступа к файлам и процессам пользователя или основной системы. Также окружение не может напрямую обращаться к оборудованию и сетевой подсистеме. Для вывода графики и ввода применяется протокол Wayland и проброс сокета X11. Взаимодействие с внешней средой построено на основе системы обмена сообщениями DBus и специального API Portals.

Для изоляции используется прослойка Bubblewrap и стандартные технологии контейнерной виртуализации. Их основа cgroups, пространства имен (namespaces), Seccomp и SELinux. Звук выводится при помощи PulseAudio. Изоляция может быть и отключена, если это необходимо.

Что нового?


  • Добавлена поддержка нового формата репозитория, который дает возможность ускорить доставку объявлений, сократив размер загружаемых данных. Этот репозиторий основывается на технологии OSTree. В ней для идентификации содержимого используется индексный файл, обновляющийся при каждом изменении. Его размер напрямую зависит как от количества пакетов, так и от числа поддерживаемых архитектур. В новой версии применили инкрементальные обновления, что, по словам разработчиков, в 100 раз сократило трафик. Кроме того, теперь во Flatpack нет дополнительных архитектур. Так, общий размер индекса сейчас составляет 6.6 МБ (1.8 МБ сжатый), вариант для архитектуры x86-64 2.7 МБ (554 КБ сжатый). При обновлении с прошлой версии потребуется загрузка всего 20 КБ.
  • Появилась команда flatpak pin для закрепления runtime. По умолчанию закрепление применяется для runtime, установленных явно, а не загруженных автоматически.
  • При общем обновлении или удалении отдельных приложений неиспользуемые runtime удаляются автоматически ( если они не закреплены и имеют истекшее время жизни).
  • Определение похожих путей приложений, например, "/org/gnome/sound-juicer", сопоставляется с org.gnome.SoundJuicer.
  • Добавлена поддержка нового стандарта на оформление файлов в os-release в контейнерах.
  • Добавлен профиль для командной оболочки tcsh.
  • В ходе поиска зависимостей репозиторий устанавливаемого приложения теперь имеет более высокий приоритет, чем другие репозитории.
  • Увеличена эффективность кэширования индекса репозитория в памяти.
  • Добавлено несколько новых API, включая flatpak_installation_list_pinned_refs, flatpak_transaction_set_disable_auto_pin, flatpak_transaction_set_include_unused_uninstall_ops, flatpak_transaction_operation_get_subpaths, flatpak_transaction_operation_get_requires_authentication.
  • Обеспечена совместимость с находящимися еще в разработке GCC 11.
  • Оптимизировано определение сокетов PulseAudio в нетиповых конфигурациях.
  • Теперь при обновлении в самом начале устанавливается новая версия приложения, а затем удаляется старая. Соответственно, если что-то идет не так, то приложение не пропадает.
  • Пользователю root можно обходить ограничения родительского контроля.

Подробнее..

Основы Bash-скриптинга для непрограммистов

24.01.2021 20:20:26 | Автор: admin

Статья рассчитана на тех, кто не имеет или имеет мало опыта работы с командной строкой Unix/Linux, но желает научиться с ней эффективно взаимодействовать и разрабатывать скрипты для выполнения своих задач. Приведенные примеры справедливы для выполнения в командной оболочке bash операционной системы Ubuntu/Debian, но могут быть использованы и в других оболочках и ОС с учетом их специфики.

1. Командные оболочки

Существует множество дистрибутивов(форков) операционных систем(ОС) семейства Linux, наиболее известные среди них: Ubuntu, Debian, CentOS, Red Hat, Fedora, SuSE, FreeBSD, Mint.

Здесь есть большая схема со всеми форками Linux.

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

Feature

Bourne

C

TC

Korn

Bash

Псевдонимы (синонимы)

Нет

Да

Да

Да

Да

Редактор командной строки

Нет

Нет

Да

Да

Да

Расширенные шаблоны файлов

Нет

Нет

Нет

Да

Да

Автозавершение имени файла

Нет

Да

Да

Да

Да

Стеки директорий (pushd and popd)

Нет

Да

Да

Нет

Да

История

Нет

Да

Да

Да

Да

Функции

Да

Нет

Нет

Да

Да

Горячие клавиши

Нет

Нет

Да

Нет

Да

Управление заданиями

Нет

Да

Да

Да

Да

Исправление ошибок в командах

Нет

Нет

Да

Нет

Да

Формат приглашения командной строки

Нет

Нет

Да

Нет

Да

Список доступных командных оболочек можно получить командой

cat /etc/shells

При необходимости можно установить нужную командную оболочку командой sudo apt install <имя_оболочки>. Например, для установки ksh нужно выполнить

sudo apt install ksh

2. Настройка тестовой среды

Если у вас уже есть виртуальная/реальная машина с установленным Linux, или вы знаете, как её настроить, то можно пропустить информацию из спойлера ниже. Если есть доступ по ssh к какому-либо серверу, то Вы также можете использовать его shell для тренировок. Используйте имеющийся доступ с осторожностью, не тренируйтесь на продуктовых(промышленных) серверах и других критичных окружениях. Если вы не хотите развертывать виртуальную машину(ВМ), то для тестов можно воспользоваться онлайн-терминалами, но нужно знать и учитывать их особенности и ограничения. Примеры онлайн-терминалов:
https://cocalc.com/app?anonymous=terminal
https://www.tutorialspoint.com/execute_bash_online.php
https://rextester.com/l/bash_online_compiler

Развертывание виртуальной машины

VirtualBox ПО для виртуализации, позволяющее запускать одну ОС внутри другой. Разумеется, существуют и другие способы развертывания ВМ, здесь мы рассмотрим лишь один из них. В данном случае, предполагается, что у вас ПК под управлением Windows или Mac. Для начала нужно скачать VirtualBox отсюда и установить его.

Также нужно скачать образ ВМ с установленной ОС Ubuntu отсюда. Качайте самую новую версию, убедитесь, что скачиваемый образ имеет формат VirtualBox (VDI).

Создадим виртуальную машину. Сначала создаем на локальном диске папку для размещения в ней ВМ и их файлов (у меня C:\vmachines). Распакуем скачанный образ диска ВМ в созданную папку:

Для распаковки потребуется архиватор 7zip или другой, поддерживающий формат .7z. Далее запускаем VirtualBox и выбираем меню Машина -> Создать:

В открывшемся окне указываем имя ВМ (тип и версия в большинстве случаев подтягиваются автоматически, если это понятно из имени), а также созданную нами папку. Объем оперативной памяти устанавливается автоматически, 1Гб достаточно для выполнения тестов. Выбираем Использовать существующий виртуальный жесткий диск, нажимаем значок выбора образа жесткого диска, в открывшемся окне нажимаем Добавить, выбираем распакованный ранее файл образом ВМ и нажимаем Открыть:

Нажимаем Выбрать:

И нажимаем Создать:

Выбираем в списке созданную ВМ и нажимаем Запустить:

После запуска ВМ появится окно для входа в ОС:

Выбираем учетную запись osboxes.org и вводим пароль osboxes.org. После входа в систему нажимаем Ctrl+Alt+T, у нас откроется окно терминала, в котором можно выполнять тесты:

Для удобства можно развернуть окно виртуальной машины на весь экран, окно терминала также будет развернуто. Для того, чтобы можно было вставлять данные из буфера в терминал ВМ и копировать их, можно включить в настройках ВМ общий буфер обмена в меню Устройства -> Общий буфер обмена -> Двунаправленный:

Создадим тестового пользователя.

Для создания пользователя нам понадобятся права суперпользователя (root). Для их получения выполним команду sudo su -, указав пароль текущего пользователя (osboxes.org). Далее создадим пользователя test командой adduser test. Также выдадим пользователю test права на повышение привилегий при необходимости, выполнив команду usermod -aG sudo test:

osboxes@osboxes:~$ sudo su -[sudo] password for osboxes:root@osboxes:~# adduser testAdding user `test' ...Adding new group `test' (1001) ...Adding new user `test' (1001) with group `test' ...The home directory `/home/test' already exists.  Not copying from `/etc/skel'.New password:Retype new password:passwd: password updated successfullyChanging the user information for testEnter the new value, or press ENTER for the default        Full Name []:        Room Number []:        Work Phone []:        Home Phone []:        Other []:Is the information correct? [Y/n]root@osboxes:~# usermod -aG sudo testroot@osboxes:~#

На данном этапе уже можно использовать тестовую среду, выполняя команды в терминале (Ctrl+Alt+T). Дополнительно можно настроить подключение по ssh клиентом (например, PuTTY), мы рассмотрим это отдельно.

3. Первые команды

Итак, мы подключились к терминалу и находимся в shell. Давайте сориентируемся в пространстве.Чтобы узнать имя машины(сервера), на которой мы находимся, введем hostname и нажмем Enter:

test@osboxes:~$ hostnameosboxes

Имя пользователя, под которым мы подключены, как правило отображается в приглашении командной строки (test@osboxes:~$). Если имя текущего пользователя не отображается (например, если задан другой формат приглашения), то его можно получить командой whoami, или id (также отображает группы пользователя):

test@osboxes:~$ whoamitesttest@osboxes:~$ iduid=1001(test) gid=1001(test) groups=1001(test),27(sudo)

Чтобы узнать, в какой оболочке мы находимся, нужно выполнить команду echo $SHELL:

test@osboxes:~$ echo $SHELL/bin/bash

Разберем, что произошло. Команда echo выводит значение параметра, переданного ей, в нашем случае мы передали $SHELL. Знак $ означает, что мы обращаемся к переменной, т.е. $SHELL возвращает значение переменной SHELL, заданной в окружении. Список значений всех переменных можно получить командой env. Таким образом, отобразив значение переменной, мы видим, что мы находимся в оболочке bash. Оболочка конкретного пользователя указана в файле /etc/passwd, содержимое которого можно получить так:

test@osboxes:~$ cat /etc/passwdroot:x:0:0:root:/root:/bin/bash...test:x:1001:1001:,,,:/home/test:/bin/dash

Команда cat выводит содержимое файла (часть строк в приведенном выводе пропущена и заменена на ). Из файла видим, что для пользователя test указана оболочка /bin/dash. Изменить оболочку текущего пользователя, которая будет загружаться по умолчанию, можно следующей командой(chsh сокращенное от change shell):

test@osboxes:~$ chsh -s /bin/bashPassword:

Теперь давайте проверим, в каком каталоге мы находимся, для этого выполним команду pwd:

test@osboxes:~$ pwd/home/test

Для получения списка файлов текущей директории используем команду ls. По соглашению, скрытые файлы начинаются с точки. Для отображения их с помощью команды ls нужно добавить ключ a. Чтобы отобразить список в расширенном формате, добавим ключ l. Таким образом команда и её вывод будут выглядеть так:

test@osboxes:~$ ls -altotal 36drwxr-xr-x 5 test test 4096 Nov  9 01:05 .drwxr-xr-x 5 root root 4096 Nov  8 11:39 ..-rw------- 1 test test    9 Nov  8 12:28 .bash_history-rw-r--r-- 1 test test  220 Nov  8 11:39 .bash_logout-rw-r--r-- 1 test test 3771 Nov  8 11:39 .bashrcdrwxr-xr-x 4 test test 4096 Nov  8 11:40 .cachedrwxr-xr-x 4 test test 4096 Nov  8 11:40 .configdrwxr-xr-x 3 test test 4096 Nov  8 11:40 .local-rw-r--r-- 1 test test  807 Nov  8 11:39 .profile-rw-r--r-- 1 test test    0 Nov  9 01:05 .sudo_as_admin_successfultest@osboxes:~$

Для команды ls с параметрами может быть задан синоним (alias), что упрощает её ввод. Список уже заданных синонимов можно получить командой alias:

test@osboxes:~$ aliasalias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'alias egrep='egrep --color=auto'alias fgrep='fgrep --color=auto'alias grep='grep --color=auto'alias l='ls -CF'alias la='ls -A'alias ll='ls -alF'alias ls='ls --color=auto'

Видим, что команда ll является синонимом команды ls -alF. Синонимы могут ссылаться на другие синонимы. Так, в приведенном выше примере команда ll выполняет команду ls -alF, в которой ls в свою очередь также является синонимом команды ls --color=auto. Для любой команды с целью упрощения её ввода при частом использовании можно задать синоним. В синонимах также можно использовать переменные среды. Например, чтобы иметь возможность из любой директории получить список файлов домашней директории, можно задать синоним командой alias lshome='ls -alF $HOME', таким образом, можно выполнить:

test@osboxes:~$ cd /tmptest@osboxes:/tmp$ lshometotal 40drwxr-xr-x 5 test test 4096 Nov  9 02:29 ./drwxr-xr-x 5 root root 4096 Nov  8 11:39 ../-rw------- 1 test test   47 Nov  9 02:36 .bash_history-rw-r--r-- 1 test test  220 Nov  8 11:39 .bash_logout-rw-r--r-- 1 test test 3771 Nov  8 11:39 .bashrcdrwxr-xr-x 5 test test 4096 Nov  9 02:29 .cache/drwxr-xr-x 5 test test 4096 Nov  9 02:29 .config/drwxr-xr-x 3 test test 4096 Nov  8 11:40 .local/-rw-r--r-- 1 test test  807 Nov  8 11:39 .profile-rw-rw-r-- 1 test test   72 Nov  9 02:29 .selected_editor-rw-r--r-- 1 test test    0 Nov  9 01:05 .sudo_as_admin_successful

Здесь командой cd /tmp мы перешли в директорию /tmp, и, находясь в ней, выполнили команду lshome, которая вывела список файлов директории /home/test. При этом в синониме мы ссылаемся на переменную $HOME, в которой содержится путь к домашней директории текущего пользователя.

Алиасы задаются в файле ~/.bash_aliases. Тильда (~) означает домашнюю директорию пользователя. В нашем случае /home/test. Также можно задать их в файле ~/.bashrc. Здесь нужно сказать пару слов об этих файлах.

При запуске bash в качестве оболочки, сначала выполняется файлы (в случае их наличия), в которых могут быть заданы различные настройки профиля и выполнены различные действия в процессе входа до появления командной строки: сначала выполняется файл /etc/profile, далее bash последовательно ищет и выполняет первый из найденных файлов в следующем порядке: ~/.bash_profile, ~/.bash_login, ~/.profile. Из указанных файлов могут вызываться и другие.

Так, например, из файла ~./profile вызывается файл ~/.bashrc, из которого, в свою очередь, в числе прочих, вызывается файл .bash_aliases при его наличии. А файл /etc/profile выполняет также все файлы .sh, находящиеся в директории etc/profile.d.

В bash существуют внутренние команды, их список можно получить командой help. Помощь по конкретной внутренней команде можно получить с помощью команды help <имя_команды>, например:

test@osboxes:~$ help pwdpwd: pwd [-LP]    Print the name of the current working directory.    Options:      -L        print the value of $PWD if it names the current working                directory      -P        print the physical directory, without any symbolic links    By default, `pwd' behaves as if `-L' were specified.    Exit Status:    Returns 0 unless an invalid option is given or the current directory    cannot be read.

Некоторые внутренние команды bash дублированы в виде исполняемых файлов. Это сделано, чтобы скрипты можно было корректно выполнять в оболочках, в которых не реализованы эти команды. Например, существует исполняемый файл /usr/bin/echo, который реализует функционал внутренней команды echo. Команда help echo выведет справку по внутренней команде, а команда /usr/bin/echo help выведет справку для соответствующего исполняемого файла. Вывод справки для этих команд отличается, но в целом они реализуют идентичный функционал.

Таким образом, если в оболочке не реализована внутренняя команда echo, скрипт, содержащий вызов echo, сможет успешно выполниться, т.к. для обработки вызова будет использован исполняемый файл /usr/bin/echo. Для поиска выполненных ранее команд можно использовать клавиши Вверх и Вниз, команды из истории можно редактировать и повторно выполнять. В конце статьи приведен список полезных команд.

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

Подробнее..
Категории: *nix , Linux , Unix , Ubuntu , Bash , Bash scripting , Ssh , Virtualbox , Debian , Shells

Как приручить консоль, или 5 шагов к жизни с командной строкой

25.01.2021 16:17:27 | Автор: admin

Всем привет! Меня зовут Осип, я Android-разработчик в Redmadrobot и я люблю автоматизировать всё, что автоматизируется. В этом мне помогает консоль, поэтому решил поделиться опытом, как настроить командную оболочку так, чтобы в ней было приятно работать и она ежедневно помогала вам решать задачи.

Статья для тех, кто использует Linux или macOS. Если у вас Windows, вы можете использовать WSL (приравнивается к Ubuntu).

Есть задачи, которые проще выполнить в командном интерфейсе, а не в графическом, к примеру:

  • посчитать количество строк кода в проекте,

  • скопировать все файлы с расширением .png из одной папки в другую,

  • постучаться API и посмотреть какой ответ он выдаёт.

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

Поверьте, стоит один раз настроить командную оболочку и разобраться, как в ней работать, и рабочее окружение начнёт помогать вам как хорошая IDE.

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


Статья только началась, а по тексту уже встречались и командная строка, и командная оболочка. Чем отличаются консоль, терминал, командная оболочка и командная строка?

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

Термины консоль и терминал в статье используются как синонимы и обозначают программу для ввода и вывода информации. В терминале запускается командная оболочка.

Подробнее о различиях можно почитать на Ask Ubuntu: What is the difference between Terminal, Console, Shell, and Command Line?

В статье будут встречаться примеры команд. Если по ходу прочтения вы не понимаете, что делает консольная команда, скопируйте её и вставьте в ExplainShell. Благо Роскомнадзор перестал его блокировать после разблокировки Telegram.

Зачем вообще использовать командную строку

Дисклеймер: Я не призываю использовать только командную строку и отказаться от графического интерфейса. Нужно просто учитывать командную строку при выборе инструмента для решения задачи.

Когда хотят рассказать чем же хорош CLI, выделяют разные преимущества перед GUI:

  • Доступность. Командная строка доступна везде. Внутри Android Studio есть вкладка с командной строкой. Можно и вовсе настроить drop-down терминал (ещё его называют quake style), который будет появляться поверх всех приложений по нажатию сочетания клавиш.

  • Многофункциональность. Одна точка доступа к любым утилитам.

  • Простота. Простой командный интерфейс может заменить сложный графический интерфейс. Сделать графический интерфейс который позволит ввести, например, пять параметров может быть довольно нетривиальной задачей, а сделать то же самое с командным интерфейсом просто.

  • Легковесность. Как правило, CLI утилиты используют меньше ресурсов.

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

Пишите программы, которые делают одну вещь и делают её хорошо.


Пишите программы, которые бы работали вместе.


Пишите программы, которые поддерживают текстовые потоки, потому что это универсальный интерфейс.

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

Примеры из жизни

Я задал вопрос коллегам-роботам: Для чего вы чаще всего открываете терминал? Получился такой ТОП-5:

  1. Работа с Git там, где не хватает графического интерфейса.

  2. Установка пакетов и управление зависимостями (подробнее про менеджер пакетов поговорим в разделе Устанавливаем менеджер пакетов).

  3. Работа с SSH.

  4. Проверка API с помощью curl.

  5. Когда нужно грохнуть процесс.

Есть и менее очевидные применения:

  1. Скачать видео из YouTube поможет youtube-dl. Качаете подкаст и нужна только аудио-дорожка? Добавьте к команде флаг --audio. Хотите скачать весь плейлист или даже весь канал? Подставляйте ссылку на канал и готовьте побольше свободного места.

  2. Хотите посмотреть отличия между файлами? Выполните команду diff и укажите пути до файлов, которые надо сравнить.

Шаг 1: Открываем терминал

Не терминал, а эмулятор терминала. (c) Департамент зануд

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

cool-retro-terminalcool-retro-terminal

Выбор терминала это тема для отдельной статьи. Кратко: если у вас Linux, начните с этого списка. На macOS популярен iTerm2, но я его не использовал, поэтому не могу ни поругать, ни похвалить.

Для меня важно чтобы и на компьютере с Linux, и на рабочем ноутбуке с macOS был один и тот же терминал с одинаковыми настройками. Я выбирал среди кроссплатформенных и остановился на kitty.

Шаг 2: Устанавливаем менеджер пакетов

Мы оказались в терминале. Первое, с чем нужно разобраться, менеджер пакетов.

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

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

Менеджеры пакетов в Linux

В дистрибутивах Linux менеджер пакетов есть по умолчанию. В Ubuntu, Debian и Mint это apt-get, а в Manjaro и ArchLinux pacman.

Чтобы установить пакет достаточно в терминале написать apt-get install [package]. Если у вас pacman, то pacman -S [package]. Может понадобиться sudo в начале, чтобы выполнить команду с правами root.

Чтобы обновить все пакеты с помощью apt-get введите команду apt-get update && apt-get upgrade. В pacman pacman -Syu.

В pacman много флагов и сложно сразу запомнить нужные. Ещё одно неудобство он не поддерживает установку пакетов из репозитория AUR. Это репозиторий, в который могут загружать пакеты любые пользователи. Исправить минусы помогут утилиты, которые упрощают работу с pacman. Рекомендую попробовать yay.

Менеджеры пакетов в macOS

В macOS придется установить пакетный менеджер. Самые популярные Homebrew и MacPorts. Homebrew активнее поддерживается сообществом, а пакеты в нём обновляются чаще, поэтому лучше использовать его. Для установки скопируйте актуальную команду установки c официального сайта. Эта команда скачает скрипт установки и запустит его.

Может понадобиться установка XCode Command Line Tools. Это базовый набор консольных инструментов clang, git, make и других. Он не зависит от XCode, а называется так, потому что необходим XCode для компиляции.

Теперь, чтобы установить пакет, достаточно в терминале написать brew install [package].

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

Шаг 3: Устанавливаем командную оболочку

Чтобы было проще работать, командная оболочка должна вам помогать. В ней должен быть поиск по введённым ранее командам, а ещё должно работать автодополнение. Здорово, если будут подсказки, которые учитывают, какие команды вы используете чаще других. Не помешает подсветка синтаксиса и ошибок при вводе команд.

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

Чтобы узнать, какая оболочка используется по умолчанию у вас, выполните команду echo $SHELL. Скорее всего, команда выведет /env/bash или /env/zsh это самые популярные оболочки. Если хотите сравнить возможности bash, zsh и fish, посмотрите эту таблицу.

Установим fish c помощью менеджера пакетов:

# Если pacmansudo pacman -S fish# Если apt-getsudo apt-get install fish# Если brewbrew install fish

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

Fish установлен. Запускаем его командой fish:

osip@homepc ~ % fishWelcome to fish, the friendly interactive shellType `help` for instructions on how to use fishosip@homepc ~>

Теперь можно настроить внешний вид. Команда fish_config откроет в браузере страницу настроек. Здесь можно настроить цветовую схему, приглашение командной строки (prompt), посмотреть список функций, переменные окружения, историю команд и список горячих клавиш. Здесь же можно добавлять, редактировать и удалять аббревиатуры команд. Про аббревиатуры поговорим чуть позже.

Fish по умолчанию

Закройте терминал и откройте его заново. Вы окажетесь не в fish, а в командной оболочке по умолчанию. Есть два варианта, как сделать так, чтобы открывался fish:

  1. Назначить fish командной оболочкой по умолчанию.

    Нужно учитывать, что скрипты инициализации текущей командной оболочки не будут выполняться. Команды и переменные окружения из .bashrc, .bash_profile, .zshrc и т.д, нужно переместить в .config/fish/fish.config , а затем адаптировать под синтаксис fish.

  2. Использовать fish только как интерактивную оболочку.

    Это более безболезненный способ, потому что не нужно мигрировать скрипты и переменные окружения. В конце скрипта инициализации текущей командной оболочки нужно запустить fish. Добавьте строку exec fish в файл .bash_profile, если у вас bash или в .zshrc, если zsh. Эти файлы находятся в корневой директории пользователя.

    На ArchWIki есть более подробное описание этого и еще нескольких способов.

Поиск по истории

Давайте-ка посмотрим, что умеет fish. Если еще не установили, можно попробовать в браузере. Я изменил только цвета и prompt, больше ничего не настраивал.

Когда вы начинаете набирать команду, fish подсказывает команды и аргументы, которые вы использовали раньше. Чтобы применить подсказку нажмите . Подставить одно слово из подсказки Ctrl+.

sample_command это демонстрационная функция. Она принимает любые параметры и ничего не возвращает.

Чтобы ввести предыдущую команду, нажмите клавишу . С помощью клавиш и можно перемещаться по истории команд. Если командная строка пуста, команды будут листаться по очереди. Если в командной строке есть текст, то история будет фильтроваться по нему.

Автодополнение

Начните писать любую команду и нажмите Tab, не дописывая её до конца. Попробуйте с командой git config:

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

Если утилита не поддерживает автодополнение, fish умеет создавать дополнения из документации man. Для этого нужно выполнить команду fish_update_completions.

А что с путями? Например, хотим перейти в папку dev/tools/jarjar/:

Дополнение путей тоже работает на Tab. Для перехода по пути не обязательно писать команду cd в начале. А еще работает дополнение, если написать первую букву имени каждой папки в пути. Если указан несуществующий путь, он подсвечивается красным.

Сложно запомнить все нужные флаги у команд. Хочу вывести дерево файлов, но не помню, как ограничить его глубину и сделать так, чтобы вывод был цветным. Для такого случая есть Shift+Tab дополнение с поиском:

Автодополнение может сработать в самых неожиданных местах, например, так работает автодополнение для команды kill:

Убийство Android Studio на глазах у studentdУбийство Android Studio на глазах у studentd

Wildcards

В fish, как и в bash, есть поддержка wildcards. Wildcards позволяют выполнить команду для нескольких файлов.

Выводим все файлы с расширением .md в текущей папкеВыводим все файлы с расширением .md в текущей папке

* соответствует любой строке
** соответствует любой иерархии папок, то есть рекурсивно заходит во вложенные папки

Применим wildcard, чтобы скопировать все файлы apk после сборки в папку output:

  • cp build/*.apk output/ скопирует все apk из папки build.

  • cp build/**.apk output/ скопирует все apk из папки build и из всех вложенных папок. То, что надо.

Функции, алиасы и аббревиатуры

Большиство команд fish это функции. Можно писать и свои функции. Синтаксис такой:

funcion [название]    [тело функции]end

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

Для часто используемых команд можно создать более короткие синонимы алиасы. В fish команда alias создаёт однострочную функцию.

Как выглядит alias?

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

Другой вариант сокращения команд аббревиатуры. Они настраиваются командой abbr или в fish_config во вкладке Abbreviations.

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

Аббревиатуры подставляются на лету, когда вы нажимаете Space или Enter. В отличие от алиасов, аббревиатуры не являются функциями.

И па и gf превращается в git fetchИ па и gf превращается в git fetch

Шаг 4: Изучаем арсенал

Командная оболочка есть, теперь нужны команды.

Консольные утилиты могут быть с CLI и TUI. Command Line Interface (CLI) программа принимает команды через командную строку. Так работает большинство утилит. Text User Interface (TUI) интерфейс рисуется псевдографикой и по нему можно кликать мышкой как по GUI.

TUI для SpotifyTUI для Spotify

CLI не нужно бояться. На замену старым утилитам появляются новые с улучшенным UX, ориентированные на человека, а не на скрипты.

Например, многие старые утилиты, которые выводят размер файла, по умолчанию выводят его в байтах. А утилита df вообще выводит свободное место на диске в количестве блоков по 512 байт.

Чтобы выводились понятные человеку размерности, нужно добавить флаг -h (human readable). Цветной вывод удобнее читать, но он тоже по умолчанию обычно отключен и включается добавлением флага, чаще всего -C. В современных же утилитах по умолчанию включен цветной человекопонятный вывод.

Стандартные команды

Чтобы пользоваться командной строкой, нужно знать несколько стандартных команд:

  • cd [сhange directory] команда для навигации по файловой системе. Если запустить её без аргументов, вы окажетесь в домашней папке;

  • cp [copy], mv [move], rm [remove] команды для копирования, перемещения и удаления файлов, соответственно;

  • mkdir [make directory] команда для создания папки;

  • echo выводит строку, которую ей передали.

Если команда долго работает и вы не хотите дожидаться её завершения, прервите её выполнение сочетанием клавиш Ctrl + C.

Помощь: man, help, tldr

Есть несколько способов получить справку по команде.

man выводит полную справку:

  • описание команды,

  • список аргументов и описание каждого из них,

  • какие переменные окружения использует утилита и для чего,

  • известные баги,

  • советы и примеры использования,

  • другая информация, которую посчитал полезной разработчик.

Если ввести man man, вы получите справку по команде man, где всё это подробно описано.

man это утилита с TUI, в ней есть горячие клавиши. Для поиска нажмите /, а для выхода q. / и q стандартные клавиши для поиска и выхода, они работают во многих TUI утилитах. Ещё один стандартная клавиша ?, она открывает справку.

Можно выполнить команду из man для этого нажмите ! и введите команду. Хотите открыть man для другой команды внутри man или сразу попробовать выполнить команду, следуя документации? Легко.

Страницы в man пишут разработчики утилит. Если разработчик не написал справку, man выдаст No manual entry for [command]. Но даже если нет страницы в man можно вывести краткую справку с помощью флага --help. Попробуйте написать man --help.

Для команд fish можно открыть справку в браузере командой help <command>.

Если читать мануалы некогда, то поможет утилита tldr. Она отображает типичные случаи использования команд:

tldr tldrtldr tldr

Объединяем команды

Помните, в самом начале я говорил, что консольные команды как кирпичики и их можно объединять, чтобы решить более сложную задачу? Сейчас мы этим и займёмся.

Чтобы направить вывод одной команды на вход другой, используется оператор |. Он называется pipe, а на русский его переводят как конвейер. Если мы хотим подать вывод команды find_bone на вход команде eat, нужно между этими командами поставить трубу (pipe):

$ find_bone | eat

Синтаксис понятен, но таких команд не существует и запустить их у себя в консоли не получится. Давайте посмотрим на более реальный пример:

$ echo -e "spot\\nhandle\\npick\\natlas" > robots.txt$ cat robots.txt | sortatlashandlepickspot

Оператор | нам уже знаком, но что делает >? Этот оператор направляет вывод команды в файл. После этого командой cat мы достаём содержимое файла и с помощью оператора | отдаём на сортировку.

Современные утилиты

Просмотр списка файлов: ls, tree exa

Для просмотра списка файлов в папке обычно используют стандартную команду ls, а для просмотра иерархии папках tree. Обе эти утилиты можно заменить более дружелюбной утилитой exa.

В exa по умолчанию включен цветной вывод и человекопонятные размеры файлов, есть поддержка широких экранов, отображается статус файлов в Git, если использовать команду в репозитории. Подробнее обо всех фичах читайте на сайте утилиты.

Скриншоты. Сравнение ls, tree и exa.
Сравнение вывода ls и exaСравнение вывода ls и exaСравнение вывода tree и exaСравнение вывода tree и exa

Бонус: В exa можно совместить два режима вывода.

Просмотр запущенных процессов: top htop

top и htop. Обе утилиты выводят список запущенных процессов, но htop делает это гораздо приятнее.

В htop можно сортировать процессы по разным столбцам, нажимая на них. Кнопки в нижнем меню тоже нажимаются. Столбцы и информационные блоки в шапке настраиваются можно убрать лишнее и добавить нужное.

А как выглядит top?

Работа с JSON: jq

jq незаменимая утилита, если вы работаете с JSON. Проще показать на примерах что умеет делать jq.

Валидируем json:

$ echo '{"model": spot}' | jq typeparse error: Invalid numeric literal at line 1, column 15$ echo '{"model": "spot"}' | jq type"object"

Форматируем json:

$ echo '{"model":"spot"," type":"robodog"}' | jq{  "model": "spot",  "type": "robodog"}

Выкусываем из json'а только то, что нужно:

$ set json '[{"model": "spot", "type": "robodog"}, {"model": "atlas", "type": "humanoid"}]'$ echo $json | jq 'map(.model)' --compact-output["spot","atlas"]$ echo $json | jq .[0].model"spot"# А теперь пример посложнее$ echo $json | jq 'map({(.model): .type}) | add'{  "spot": "robodog",  "atlas": "humanoid"}

Это только малая часть возможностей. Все возможности смотрите в доке.

Другие утилиты

Чтобы этот раздел не раздулся, остальные утилиты я спрятал под спойлеры. При первом прочтении их можно пропустить и позже использовать этот раздел как справочник.

Консольный HTTP клиент: curl, wget httpie

httpie делает то же что curl отправляет запросы в сеть. Но посмотрите как отличается синтаксис и оформление вывода в curl и httpie.

На фотографии слева направо: curl и httpieНа фотографии слева направо: curl и httpie
Отображение содержимого файла: cat bat

cat и bat выводят содержимое файла, но bat подсвечивает синтаксис и отображает изменения из гита.

Поиск по содержимому файлов: grep ripgrep

ripgrep более быстрая версия grep. Сравнение скорости работы показывает, что ripgrep быстрее всех :)

Поиск файлов: find fd, fzf

Для поиска файлов можно использовать стандартную утилиту find. Для неё есть альтернатива fd. Она работает быстрее, поддерживает цветной вывод, по умолчанию игнорирует скрытые файлы и файлы из .gitignore. Посмотрите на гифку, которая демонстрирует работу fd.

Ещё одна утилита для поиска fzf [fuzzy finder]. Это утилита с TUI для интерактивного поиска файлов с использованием нечёткого поиска по названиям.

Ещё из приятного есть предпросмотр содержимого.

Подсчёт количества строк кода: wc tokei

Стандартная утилита wc [word count] считает количество слов, символов и строк в файлах, но чтобы с помощью неё посчитать количество строк кода в проекте, придётся написать что-то такое:

$ fd -g '*.kt' | xargs wc -l

У такой команды есть сразу несколько недостатков:

  • считаются все строки, включая комментарии и пустые строки,

  • ищутся только файлы с расширением .kt, для поиска других придётся менять команду,

  • сгенерированные файлы и остальные файлы, которые заигнорены в гите, тоже попадут в статистику,

  • такую команду долго писать.

Утилита tokei лишена перечисленных недостатков. Вот пример вывода tokei на одном из наших проектов:

Упс, файлы proguard засчитались в пользу PrologУпс, файлы proguard засчитались в пользу Prolog
Свободное место на диске: du ncdu

Ещё один пример разницы CLI и TUI. В отличие от du, ncdu это TUI. Тут же можно перейти внутрь папки или удалить ненужное нажав d.

Хм, накопилось много врапперов и кэшей Gradle. Можно почистить.Хм, накопилось много врапперов и кэшей Gradle. Можно почистить.
Сравнение файлов: diff delta

Отличная замена старому-доброму diff - delta. Можно использовать режим отображения side-by-side, если больше нравится, включить отображение номеров строк. Даже без дополнительных настроек диффы выглядят приятно:

Измерение времени работы программы: time hyperfine

Не верьте на слово, если я говорю, что одна утилита работает быстрее другой. Лучше проверьте.

Можно измерить время выполнения команды с помощью time (в macOS gtime). Эта утилита не предназначена для бенчмарков нет возможности прогрева, команда выполняется один раз. hyperfine подойдёт лучше, потому что изначально разработан для бенчмарков.

Попробуем замерить время выполнения команды tree:

Вывод команды tree перенаправлен в пустоту (/dev/null), потому что здесь не важен вывод команды, важно только время её выполнения. С hyperfine этого делать не нужно, он сам отбрасывает вывод команды.

Hyperfine умеет отслеживать признаки неправильного бенчмарка. Вот некоторые подсказки:

  • если во время замера есть выбросы, hyperfine посоветует закрыть другие программы, потому что они могут влиять на бенчмарк,

  • если первый запуск команды дольше остальных, hyperfine посоветует сделать прогрев, задав параметр --warmup N. Перед бенчмарком программа выполнится N раз.

Можно сравнивать скорость выполнения нескольких команд. Для этого нужно написать команды друг за другом, заключив их в кавычки:

$ hyperfine 'command_one' 'command_two' 'command_three'

Шаг 5: Сохраняем настройки

Чтобы не настраивать каждый раз все программы заново, нужно где-то сохранять настройки.

Конфиги это файлы. Обычно они хранятся в корневой директории пользователя вместе со скриптами инициализации командной оболочки, например, в папке .config/. Если вы установили fish, то найдёте папку .config/fish/ и в ней файлы с настройками. Самый простой способ сохранить конфиги сохранить их в Git-репозиторий.

Имена файлов и папок с настройками обычно начинаются с точки, поэтому одним словом их называют dotfiles. На момент написания статьи на GitHub опубликовано 138 425 репозиториев с именем dotfiles есть куда подсмотреть.

На странице awesome-dotfiles вы найдёте много информации про dotfiles. Там же есть ссылки на инструменты, которые помогают управлять dotfiles.

Я использую yadm. Мне важна кроссплатформенность, поэтому пригождается его возможность создавать альтернативные версии файлов для разных ОС.

Заключение

В консоли может быть сложно работать, если ее не приручить. Но если выбрать удобную для себя командную оболочку и один раз ее настроить, то она будет постоянно помогать вам.

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

На замену старым утилитам приходят новые, нацеленные на пользователя, а не на скрипты. Используйте их и ищите новые! Если вам кажется, что утилита слишком сложная, возможно, вы такой не один и кто-то уже написал более простой в использовании аналог.

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

Если будут вопросы или вам понадобится помощь с освоением консоли, пишите мне в Telegram@osipxd. Ещё я иногда пишу в канал @rareilly заметки про Android и вообще про всё интересное, что нахожу. Спасибо за внимание!

Что ещё почитать

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru