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

Среди внесённых изменений: отделение высокоуровнневых заголовочных файлов друг от друга, исключение связывающих заголовочные файлы inline-функций, выделение заголовочных файлов для типов и API, обеспечение обособленной сборки заголовочных файлов (около 80 файлов имели мешающие сборке непрямые зависимости, выставляемые через другие заголовочные файлы), автоматическое добавление зависимостей к файлам .h и .c, пошаговая оптимизация заголовочных файлов, использование режима CONFIG_KALLSYMS_FAST=y, выборочная консолидация Си-файлов в сборочные блоки для снижения числа объектных файлов.

В итоге, проделанная работа позволила на 1-2 порядка сократить размер заголовочных файлов, обрабатываемых на стадии постпроцессинга. Например, до оптимизации использование заголовочного файла linux/gfp.h приводило к добавлению 13543 строк кода и подключения 303 зависимых заголовочных файлов, а после оптимизации размер сократился до 181 строк и 26 зависимых файлов. Или другой пример: при препроцессинге файла kernel/pid.c без патча подключается 94 тысяч строк кода, большая часть которого не используется в pid.c. Разделение заголовочных файлов позволило снизить объем обрабатываемого кода в три раза, сократив число обрабатываемых строк до 36 тысяч.

При полной пересборке ядра командой make -j96 vmlinux на тестовой системе применение патчей показало сокращение времени сборки ветки v5.16-rc7 с 231.34 до 129.97 секунд, а также повысило эффективность использования ядер CPU во время сборки. При инкрементальной сборке эффект от оптимизации ещё более заметен — время повторной пересборки ядра после внесения изменений в заголовочные файлы сократилось в разы (от 112% до 173% в зависимости от изменяемого заголовочного файла). Оптимизации пока доступны только для архитектур ARM64, MIPS, Sparc и x86 (32- и 64-бит).

Из возможностей ksmbd выделяется улучшенная поддержка технологии распределённого кэширования файлов (SMB leases) на локальных системах, которая позволяет существенно сократить трафик. В дальнейшем планируется добавление новых возможностей, таких как поддержка RDMA («smbdirect»), а также расширений протокола, связанных с усилением надёжности шифрования и верификацией по цифровым подписям. Отмечается, что подобные расширения гораздо проще реализовать в компактном и хорошо оптимизированном сервере, работающем на уровне ядра, чем в пакете Samba.

При этом ksmbd не претендует на роль полной замены пакета Samba, который не ограничивается возможностями файлового сервера и предоставляет инструментарий, охватывающей сервисы для обеспечения безопасности, LDAP и контроллер домена. Реализация файлового сервера в Samba является кросс-платформенной и рассчитанной на более широкие области применения, что затрудняет оптимизацию для некоторых Linux-окружений, таких как прошивки для устройств с ограниченными ресурсами.

Ksmbd рассматривается не как отдельный продукт, а скорее как высокопроизводительное и готовое для применения на встраиваемых устройствах расширение к Samba, при необходимости интегрируемое с инструментами и библиотеками Samba. Например, с разработчиками Samba уже согласован вопрос использования в ksmbd совместимых с smbd файлов конфигурации и расширенных атрибутов (xattrs), что упростит переход с smbd на ksmbd и наоборот.

Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией. Впоследствии, когда Linux стал известным проектом, недоброжелатели пытались обвинить Линуса в прямом копировании кода некоторых подсистем MINIX. Нападение отразил Эндрю Таненбаум, автор MINIX, который поручил одному из студентов провести детальное сравнение кода Minix и первых публичных версий Linux. Результаты исследования показали наличие только четырёх несущественных совпадений блоков кода, обусловленных требованиями POSIX и ANSI C.

Первоначально Линус задумал назвать ядро Freax, от слов «free», «freak» и X (Unix). Но имя «Linux» ядро получило с лёгкой руки Ари Лемке (Ari Lemmke), который по просьбе Линуса разместил ядро на FTP-сервере университета, назвав директорию с архивом не «freax», как просил Торвальдс, а «linux». Примечательно, что предприимчивый делец Вильям Делло Крок (William Della Croce) сумел зарегистрировать торговую марку Linux и хотел со временем собирать отчисления, но позднее передумал и передал все права на торговую марку Линусу. Официальный талисман Linux-ядра, пингвин Tux, был выбран в результате соревнования, состоявшегося в 1996 году. Имя Tux расшифровывается как Torvalds UniX.

Динамика роста кодовой базы (количество строк исходного кода) ядра:

0.0.1 — сентябрь 1991, 10 тыс. строк кода;
1.0.0 — март 1994, 176 тыс. строк кода;
1.2.0 — март 1995, 311 тыс. строк кода;
2.0.0 — июнь 1996, 778 тыс. строк кода;
2.2.0 — январь 1999, 1.8 млн. строк кода;
2.4.0 — январь 2001, 3.4 млн. строк кода;
2.6.0 — декабрь 2003, 5.9 млн. строк кода;
2.6.28 — декабрь 2008, 10.2 млн. строк кода;
2.6.35 — август 2010, 13.4 млн. строк кода;
3.0 — август 2011, 14.6 млн. строк кода.
3.5 — июль 2012, 15.5 млн. строк кода.
3.10 — июль 2013, 15.8 млн. строк кода;
3.16 — август 2014, 17.5 млн. строк кода;
4.1 — июнь 2015, 19.5 млн. строк кода;
4.7 — июль 2016, 21.7 млн. строк кода;
4.12 — июль 2017, 24.1 млн. строк кода;
4.18 — август 2018, 25.3 млн. строк кода.
5.2 — июль 2019, 26.55 млн. строк кода.
5.8 — август 2020, 28.4 млн. строк кода.
5.13 — июнь 2021, 29.2 млн. строк кода.

Прогресс развития ядра:

Linux 0.0.1 — сентябрь 1991, первый публичный выпуск, поддерживающий только CPU i386 и загружающийся с дискеты;
Linux 0.12 — январь 1992, код начал распространяться под лицензией GPLv2;
Linux 0.95 — март 1992, обеспечена возможность запуска X Window System, реализована поддержка виртуальной памяти и раздела подкачки.
Linux 0.96-0.99 — 1992-1993, началась работа над сетевым стеком. Представлена файловая система Ext2, добавлена поддержка формата файлов ELF, представлены драйверы для звуковых карт и контроллеров SCSI, реализована загрузка модулей ядра и файловой системы /proc.
В 1992 году появились первые дистрибутивы SLS и Yggdrasil. Летом 1993 года были основаны проекты Slackware и Debian.
Linux 1.0 — март 1994, первый официально стабильный релиз;
Linux 1.2 — март 1995, существенное увеличение числа драйверов, поддержка платформ Alpha, MIPS и SPARC, расширение возможностей сетевого стека, появление пакетного фильтра, поддержка NFS;
Linux 2.0 — июнь 1996 года, поддержка многопроцессорных систем;
Март 1997: основан LKML, список рассылки разработчиков ядра Linux;
1998 год: запущен первый попавший в список Top500 кластер на базе Linux, состоящий из 68 узлов с CPU Alpha;
Linux 2.2 — январь 1999, увеличена эффективность системы управления памятью, добавлена поддержка IPv6, реализован новый межсетевой экран, представлена новая звуковая подсистема;
Linux 2.4 — февраль 2001, обеспечена поддержка 8-процессорных систем и 64 Гб ОЗУ, файловая система Ext3, поддержка USB, ACPI;
Linux 2.6 — декабрь 2003, поддержка SELinux, средства автоматического тюнинга параметров ядра, sysfs, переработанная система управления памятью;
В 2005 году представлен гипервизор Xen, который открыл эру виртуализации;
В сентябре 2008 года сформирован первый релиз платформы Android, основанной на ядре Linux;
В июле 2011 года после 10 лет развития ветки 2.6.x осуществлён переход к нумерации 3.x. Число объектов в Git-репозитории достигло 2 млн;
В 2015 году состоялся выпуск ядра Linux 4.0. Число git-объектов в репозитории достигло 4 млн;
В апреле 2018 года преодолён рубеж в 6 млн git-объектов в репозитории ядра.
В январе 2019 года сформирована ветка ядра Linux 5.0. Репозиторий достиг уровня 6.5 млн git-объектов.
Опубликованное в августе 2020 года ядро 5.8 стало самым крупным по числу изменений из всех ядер за всё время существования проекта.
В ядре 5.13 был поставлен рекорд по числу разработчиков (2150), изменения от которых вошли в состав ядра.
В 2021 году в ветку ядра Linux-next добавлен код для разработки драйверов на языке Rust. Ведётся работа по включению компонентов для поддержки Rust в основной состав ядра.
68% всех изменений в ядро внесены 20 наиболее активными компаниями. Например, при разработке ядра 5.13 10% всех изменений подготовлено компанией Intel, 6.5% — Huawei, 5.9% — Red Hat, 5.7% — Linaro, 4.9% — Google, 4.8% — AMD, 3.1% — NVIDIA, 2.8% — Facebook, 2.3% — SUSE, 2.1% — IBM, 1.9% — Oracle, 1.5% — ARM, 1.4% — Canonical. 13.2% изменений подготовлены независимым участниками или разработчиками, явно не заявившим о своей работе на определённые компании. 1.3% изменений подготовлены студентами, аспирантами и представителями учебных заведений. По числу добавленных в ядро 5.13 строк кода лидирует компания AMD, доля которой составила 20.2% (драйвер amdgpu насчитывает около 3 млн строк кода, что примерно 10% от общего размера ядра — 2.4 млн строк приходится на сгенерированные автоматически заголовочные файлы с данными для регистров GPU).

Делал в  Debian 10 ’Buster’. Готового пакета нет, поэтому по мануалу скачал с Sourceforge файл winexe-1.00.tar.gz (в дальнейшем он не пригодился). Понаставил кучу пакетов (сразу скажу, что, возможно, половина тут — лишнее):

sudo aptitude install build-essential autoconf checkinstall python python-all python-dev python-all-dev python-setuptools libdcerpc-dev
sudo aptitude install gcc-mingw-w64 comerr-dev libpopt-dev libbsd-dev zlib1g-dev libc6-dev
sudo aptitude install comerr-dev libpopt-dev libbsd-dev zlib1g-dev libc6-dev python-dev
sudo aptitude install git python2.7 libpango1.0-0 libacl1-dev libldap2-dev libpam-dev libtevent-dev python2.7-dev python3.7 samba-dev libgnutls28-dev libgpgme11-dev libjansson-dev libarchive-dev
sudo aptitude install acl attr bind9utils bison debhelper dnsutils flex gdb krb5-user libaio-dev libblkid-dev libcap-dev libcups2-dev libjson-perl libncurses5-dev libreadline-dev nettle-dev perl-modules python-all-dev python-crypto python-dbg python-dnspython python3-dnspython python-markdown python3-markdown python3-dev xsltproc zlib1g-dev liblmdb-dev lmdb-utils

Выполняю

tar xzvf winexe-1.00.tar.gz
cd winexe-1.00/source4
./autogen.sh
/configure
make basics bin/winexe

На последней команде получаю ошибку:

Creating heimdal/lib/asn1/der-protos.h
syntax error at heimdal/cf/make-proto.pl line 15, near "do Getopts("
Execution of heimdal/cf/make-proto.pl aborted due to compilation errors.
make: *** [data.mk:197: heimdal/lib/asn1/der-protos.h] Ошибка 255

Подхожу у кроблеме с другой стороны. Клонирую гитом самбу и всё делаю в ейных исходниках (для этого и установил кучу пакетов):

cd ~
git clone git://git.samba.org/samba.git ~/samba
cd ~/samba
./configure
make bin/winexe

В ~/samba/bin/default/examples/winexe/ скомпилился бинарник winexe, использую его по назначению:

winexe -U <домен>/<логин>%<пароль> //<windows-хост> "команда"

Очздорова! Показать

P. S. Проблему с кодировкой думаю решить с помощью установки кодовой страницы по умолчанию по этому мануалу и использования перекодировщика luit из пакета x11-utils. У себя попробовал — работает: Показать

Источники:
https://wiki.samba.org/index.php/Package_Dependencies_Required_to_Build_Samba
https://www.aldeid.com/wiki/Winexe
https://ru.stackoverflow.com/questions/339012/Как-подружить-luit-и-cp866
https://superuser.com/questions/269818/change-default-code-page-of-windows-console-to-utf-8
https://superuser.com/questions/387569/how-do-i-permantly-set-the-command-prompt-codepage-in-windows-7

Параметры также могут включать дополнительные сведения, такие как ключи для SSH, данные для биометрической аутентификации, изображение, email, адрес, часовой пояс, язык, лимиты на число процессов и память, дополнительные флаги монтирования (nodev, noexec, nosuid), данные о применяемых пользователем серверах IMAP/SMTP, информация о включении родительского контроля, параметры резервного копирования и т. п. Для запроса и разбора параметров предоставляется API Varlink.

Назначение и обработка UID/GID производится динамически в каждой локальной системе, к которой подключается домашний каталог. При помощи предложенной системы пользователь может держать свой домашний каталог при себе, например на Flash-накопителе, и получать рабочее окружение на любом компьютере без явного заведения на нём учётной записи (наличие файла с образом домашнего каталога приводит к синтезу пользователя).

Для шифрования данных предлагается использовать подсистему LUKS2, но systemd-homed также позволяет использовать и другие бэкенды, например, для незашифрованных каталогов, Btrfs, Fscrypt и сетевых разделов CIFS. Для управления переносимыми каталогами предложена утилита homectl, которая позволяет создавать и активировать образы домашних каталогов, а также изменять их размер и задавать пароль.

На уровне системы работа обеспечивается следующими компонентами:
systemd-homed.service — управляет домашним каталогом и встраивает JSON-записи напрямую в образы домашнего каталога;
– pam_systemd — обрабатывает параметры из JSON-профиля при входе пользователя и применяет их в контексте активируемого сеанса (проводит аутентификацию, настраивает переменные окружения и т. п.);
– systemd-logind.service — обрабатывает параметры из JSON-профиля при входе пользователя, применяет различные настройки управления ресурсами и выставляет лимиты;
– nss-systemd — модуль NSS для glibc, синтезирует классические записи NSS на основе JSON-профиля, предоставляя обратную совместимость с UNIX API для обработки пользователей (/etc/password);
– PID 1 — динамически создаёт пользователей (синтезирует по аналогии с применением директивы DynamicUser в unit-ах) и делает их видимыми для остальной системы;
– systemd-userdbd.service — транслирует учётные записи UNIX/glibc NSS в записи JSON и предоставляет унифицированный API Varlink для запроса и перебора записей.

Из достоинств предложенной системы отмечается возможность управления пользователями при монтировании каталога /etc в режиме только для чтения, отсутствие необходимости синхронизации идентификаторов (UID/GID) между системами, независимость пользователя от конкретного компьютера, блокировка данных пользователя во время перехода в спящий режим, применение шифрования и современных методов аутентификации. Systemd-homed планируется включить в основной состав systemd в выпуске 244 или 245.

Видео

На Опёнке сразу забурлили, вот несколько комментариев с противоположными мнениями: Показать