K - #Kernel
L - #Linux

http://turnoff.us/image/en/sql-server-on-linux.png

http://turnoff.us/geek/sql-server-on-linux/

Кодовые имена текущих и будущих дистрибутивов Debian:

Debian 8 "Jessie" - текущий Stable

https://wiki.debian.org/DebianJessie

Debian 9 "Stretch" - текущий Testing

https://wiki.debian.org/DebianStretch

Debian 10 "Buster" - имя будущего дистрибутива Debian Linux

https://wiki.debian.org/DebianBuster

#Debian
#Linux

Конец проектов 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

zRAM - swapped your memory from zipped swap partition, placed right into the same RAM memory, and getting more memory!

Подкачиваешь оперативку прямо из сжатого раздела подкачки в оперативке и получаешь больше памяти! ©

Модуль ядра Linux zRAM полезен для "современных" ультрабуков со "стандартными" 8 ГиБ RAM, когда памяти недостаточно и конфигурация не поддерживает апгрейд (память нерасширяема, нет слотов, впаяна в матплату - on-board soldered RAM), для серверов при использовании виртуализации, для серверов приложений (для апплетов экосистемы Java), при тестировании массивных Java приложений и GC на многогигабайтных кучах (heap), а также для систем сборки и поставки проектов (процессов CI/CD в DevOps практике), для компиляторных ферм, используемых для сборки очень крупных проектов, требующих для процесса компиляции и сборки много памяти и процессорного времени, в этом случае zRAM будет полезен для мэйнтейнеров пакетов различных дистрибутивов и любителей компилировать и собирать source-based дистрибутивы (Gentoo и другие) и пакеты для них, создавать локальные зеркала скомпилированных и собраных пакетов (ebuild для Gentoo) для подобных дистрибутивов, на серверной площадке компании или проекта, и т.д.

https://www.kernel.org/doc/Documentation/blockdev/zram.txt

Установка и настройка zRAM в Gentoo, ArchLinux и Debian.

https://habrahabr.ru/post/172137/ - давняя статья Дмитрия Петрашко (@darkdimius, к слову одного из основных авторов компилятора Dotty с системой зависимых типов для Scala 3)

#Linux

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

Линус Торвальдс, Дэвид Даймонд. Just for Fun. Рассказ нечаянного революционера.

🎂 И да, сегодня 25 августа - день рождения Linux, камрады. Всех, кто так или иначе причастен, или причисляет себя к сообществу - с праздником!

#linux

ThinkPads and ThinkStations now has a first class support of Linux desktop distributions - drivers for devices will be included to the Linux kernel device tree

https://ubuntu.com/blog/lenovo-expand-enterprise-desktop-range-preinstalled-with-ubuntu

#ThinkPad
#ThinkStation
#Lenovo
#Linux

eBPF: Unlocking the Kernel

Documentary about the development process of #eBPF subsystem for #Linux by the Linux kernel hackers all over the world - the executor (#VM and #JIT compiler) of extended #BPF bytecode to run system programs safely in a kernel space and use Linux kernel API and system calls (including #POSIX).

This simplified the development of programs integrated with the Linux kernel in a better way, so cloud native landscape with cloud infrastructure development has been changed forever!

https://youtu.be/Wb_vD3XZYOA

BTW, #Rust compiler has a eBPF backend, already proved for production grade programming and compilation, and has a bunch of good frameworks for developing for the Linux kernel using eBPF VM host functions interfaces.

#Rust
#RustLang
#Linux

Expansion of Rust language application in aerospace sphere.

Rust already widely applied for hard real-time systems - DAW (digital audio workstation), HFT (high frequency trading), industrial system, but also for automotive and aerospace vehicle systems, like autopilots, space orientation and telemetry. In such systems a stable latency and reaction time should be provided, which means every operation should take only exact amount of time.

And now the new hard real-time subsystem (with more wide abilities than Linux RT patch-set) for Linux, RROS, which working along with Linux kernel, is used for running real-time software for on-board systems on the new recently launched China satellite.

'Cause Rust gives a system access level to work with the hardware, same as C language provides, but also powerful yet simple abstractions and smart-pointers, as C++ language provides.

https://bupt-os.github.io/website/news/2023_12_9/satellite_launch/

https://github.com/BUPT-OS/RROS

https://github.com/BUPT-OS/RROS/tree/main/rust

Other post on this topic in my blog in Telegram:

https://t.me/technologique/1540

https://t.me/technologique/1512

https://t.me/technologique/1524

#Rust
#Linux
#RTOS
#aerospace
#automotive

The new Qualcomm Snapdragon X Elite and X Plus chips already supported by Linux kernel, Debian and Fedora distros, the work on CPU support was performed before official release of these chips, many thanks to the Linaro efforts for made such meaningful contribution and brings support of new ARM chips to the Linux world! This will be the huge shifting and game changer in PC platforms!

https://www.youtube.com/watch?v=rEaGyCAS9fY

#CPU
#Linux
#Qualcomm
#Snapdragon

Good scheme for retrieving encryption key from TPM2.0 device and bypass LUKS encryption for disk partitions:

https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/

#Linux
#LUKS
#TPM

The drama around Rust drivers inclusion into Linux kernel became worser and even worser.

Old kernel maintainer against of Rust code inclusion into DMA for drivers.
Asahi Linux maintainer resigned from Linux kernel maintainers.

The question is - what is better, maintain two languages and handle this complexity, one of it, Rust, provided memory safety, when usafe blocks are strictly located and controlled, or, continue to maintain old (and new) error prone code in C language with all that memory safety issues, as it was before, for many years, without accepting new approaches to develop safe system software, drivers and kernel modules.

Overall, that's the problem of old minded people, who doesn't want to put the efforts to accept something new, which can be better than old approach.

I've got only one question - if there are so much resistance from old minded people, kernel maintainers, for what the Rust for Linux subsystem was even included into the kernel, what old kernel maintainers and Linus himself expected when they've done that, i.e. introduction of Rust subsystem into kernel? They want to keeping it in cage of just subsystem for drivers development, when the problem is the whole old approach to memory management?

If this situation will be progressing (and it will!) many new wave kernel maintainers and kernel developers will leave and resign from Linux kernel. And that's not good for Linux, as maintainers became older and older and it's became tremendously hard to involve new generation of system developers into kernel development and maintenance.
Many new wouldn't even join Linux kernel, because of such toxic environment in conversations, and the better option here for new wave system developeers is to consolidate common efforts on some alternative kernel, like RedoxOS microkernel for example, which is a Unix POSIX compatible kernel, fully written in Rust, and someday, in 10-20 years from now, when Linux gets old and cost of maintenance of old error prone C code will be high (same as with assembly language kernels in previous age), Redox will became a Linux alternative, same as BSD kernels and distros, but better.

https://lore.kernel.org/lkml/20250207-rm-maint-v1-1-10f069a24f3d@marcan.st/

https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/

https://www.theregister.com/2025/02/07/linus_torvalds_rust_driver/

#Rust
#RustLang
#Linux
#kernel

The final of the story.

How's it started:
https://lore.kernel.org/lkml/20250108122825.136021-1-abdiel.janulgue@gmail.com/

How's it going:
https://lore.kernel.org/lkml/20250224-configfs-v4-0-9af9b5e611f6@kernel.org/

How's it ended:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/MAINTAINERS?id=815291c11acda54515f1af5ce6fe307490de9127

Moral:
Don't resist to positive valuable changes and don't be a brake for others and for progress.

Rust to the Linux! 🐧
Rust to the Moon! 🚀

#Rust
#RustLang
#Linux

That's huge!
3FS (Fire-Flyer File System), a high performance distributed FS for distributed training (ML/DML) and inference just released! 🙌

https://github.com/deepseek-ai/3FS

#AI
#AGI
#LLM
#FS
#CPP
#Rust
#RustLang
#Linux

Whoa! We need to update our kernels!

https://hoefler.dev/articles/vsock.html

https://security-tracker.debian.org/tracker/CVE-2025-21756

#kernel
#Linux
#VSock