Technologique
https://www.youtube.com/watch?v=QZ05o0RPwUQ
Конец проектов Unity, Mir, Ubuntu Phone (Ubuntu Personal) и конвергенции интерфейсов оболочек для десктопных и мобильных платформ (Unity 8, Convergence) - Canonical сфокусируется на дистрибутивах для облачных платформ (Ubuntu Cloud Core), встроенных систем и IoT (Snappy Ubuntu Core).
С версии Ubuntu 18.04 LTS дистрибутив будет переведён на использование окружения GNOME и оконного сервера Wayland.
https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/
Одна из ошибок Canonical - ограниченная доступность Unity и Mir только для дистрибутива Ubuntu. То же самое происходит с Pantheon в Elementary. Разработчики дистрибутива Mint, в свою очередь, поступили очень правильно, сделав Cinnamon доступным для многих дистрибутивов и открытым для разработки.
Печально, но закономерно - мобильный рынок проприетарен и закрыт (благодаря Google и Mobile Handset Alliance), закрытость драйверов для SoC мешала продвижению открытых дистрибутивов Linux для мобильных платформ, в свою очередь рынок Cloud платформ показывает непрерывный рост уже в течение нескольких лет, а рынок IoT очень бурно растёт последние полгода-год и Canonical с дистрибутивом Ubuntu имеет на этом рынке очень сильные позиции не только благодаря самим дистрибутивам, но и благодаря успешным продуктам - MAAS, Juju, Snappy/Snap/Snapcraft.io, LXC/LXD, BootStack.
https://t.me/technologique/711
#linux
#ubuntu
#breakingnews
#sadnews
С версии Ubuntu 18.04 LTS дистрибутив будет переведён на использование окружения GNOME и оконного сервера Wayland.
https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/
Одна из ошибок Canonical - ограниченная доступность Unity и Mir только для дистрибутива Ubuntu. То же самое происходит с Pantheon в Elementary. Разработчики дистрибутива Mint, в свою очередь, поступили очень правильно, сделав Cinnamon доступным для многих дистрибутивов и открытым для разработки.
Печально, но закономерно - мобильный рынок проприетарен и закрыт (благодаря Google и Mobile Handset Alliance), закрытость драйверов для SoC мешала продвижению открытых дистрибутивов Linux для мобильных платформ, в свою очередь рынок Cloud платформ показывает непрерывный рост уже в течение нескольких лет, а рынок IoT очень бурно растёт последние полгода-год и Canonical с дистрибутивом Ubuntu имеет на этом рынке очень сильные позиции не только благодаря самим дистрибутивам, но и благодаря успешным продуктам - MAAS, Juju, Snappy/Snap/Snapcraft.io, LXC/LXD, BootStack.
https://t.me/technologique/711
#linux
#ubuntu
#breakingnews
#sadnews
Ubuntu Insights
Growing Ubuntu for cloud and IoT, rather than phone and convergence
This is a post by Mark Shuttleworth, Founder of Ubuntu and Canonical We are wrapping up an excellent quarter and an excellent year for the company, with performance in many teams and products that we can be proud of. As we head into the new fiscal year, it’s…
Technologique
OOMd - user space daemon for killing processes by out of memory exception raises. И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов…
Daemonization for JVM
Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.
То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.
На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.
На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.
В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).
Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.
Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.
Благо по системам инициализации есть прекрасная документация.
http://upstart.ubuntu.com/cookbook/#stanzas-by-category
http://upstart.ubuntu.com/cookbook/#initctl-commands-summary
http://upstart.ubuntu.com/cookbook/#expect
http://upstart.ubuntu.com/cookbook/#run-a-java-application
http://upstart.ubuntu.com/cookbook/#alternative-method
https://wiki.ubuntu.com/Upstart
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference
#Linux
#Ubuntu
#Upstart
#systemd
Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.
То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.
На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.
На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.
В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).
Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.
Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.
Благо по системам инициализации есть прекрасная документация.
http://upstart.ubuntu.com/cookbook/#stanzas-by-category
http://upstart.ubuntu.com/cookbook/#initctl-commands-summary
http://upstart.ubuntu.com/cookbook/#expect
http://upstart.ubuntu.com/cookbook/#run-a-java-application
http://upstart.ubuntu.com/cookbook/#alternative-method
https://wiki.ubuntu.com/Upstart
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference
#Linux
#Ubuntu
#Upstart
#systemd