gladilov.org.ru gladilov.org.ua

50 заметок с тегом

Linux

Запланированные проблемы

На странице «События» сайта Группы пользователей Linux в Зеландии и в Сконе (Skåne Sjælland Linux User Group, SSLUG) нашёл забавное запланированное событие. На 19 января 2038 года они собираются участвовать в событии «Паника, хаос и разрушение».

15 сентября   Linux   досуг   интересное   интернет   юмор

Для ядра Linux предложена реализация SMB-сервера

Для включение в состав следующего выпуска ядра Linux предложена новая реализация файлового сервера, использующего протокол SMB3. Сервер оформлен в виде модуля ядра ksmbd и дополняет ранее доступный код клиента SMB. Отмечается, что в отличие от SMB-сервера, работающего в пространстве пользователя, реализация на уровне ядра более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра. Основным разработчиком ksmbd является Стив Френч (Steve French) из компании Microsoft (ранее много лет работал в IBM), мэйнтейнер подсистем CIFS/SMB2/SMB3 в ядре Linux и давний участник команды разработчиков Samba, внёсший значительный вклад в реализацию поддержки протоколов SMB/CIFS в Samba и Linux.

Показать

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

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

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

Источники:
Список рассылки
Опёнок

День рождения ядра Linux

25 августа 1991 года после пяти месяцев разработки 21-летний студент Линус Торвальдс объявил в телеконференции comp.os.minix о создании рабочего прототипа новой операционной системы Linux, для которой было отмечено завершение портирования bash 1.08 и gcc 1.40. Первый публичный выпуск ядра Linux был представлен 17 сентября. Ядро 0.0.1 имело размер 62 Кб в сжатом виде и содержало около 10 тысяч строк исходного кода. Современное ядро Linux насчитывает более 28 млн строк кода. По данным исследования, проведённого в 2010 году по заказу Евросоюза, приблизительная стоимость разработки с нуля проекта, аналогичного современному ядру Linux, составила бы более миллиарда долларов США (расчёт производился, когда в ядре было 13 млн строк кода), по другим оценкам — более 3 миллиардов.

Показать

Ядро 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).

История
Подходящая картинка к новости

Опубликованы тестовые ядра Linux 4.4.256 и 4.9.256

Грег Кроа-Хартман (Greg Kroah-Hartman) опубликовал выпуски ядра Linux 4.4.256 и 4.9.256, которые сформированы специально для проверки корректности обработки составных частей номера версии, не укладывающихся в однобайтовое значение. Изменения в опубликованных выпусках ограничиваются только увеличением номера версии в Makefile для того, чтобы проверить, не возникнет ли проблем в пространстве пользователя.

Изначально под счётчик номера версии в ядре было выделено 8-битовое значение, что делает вызов макроса KERNEL_VERSION(4, 4, 256) эквивалентным KERNEL_VERSION(4, 5, 0). Значение макроса KERNEL_VERSION, вычисляется так:

((a) << 16) + ((b) << 8) + (c))

затем экспортируется в пространство пользователя в форме константы LINUX_VERSION_CODE, которая используется при проверке текущей версии ядра. Для ядра подобное переполнение не вызывает проблем, но значение LINUX_VERSION_CODE проверяется и некоторыми компонентами в пространстве пользователя, такими как GCC и Glibc, что потенциально может привести к непредсказуемым проблемам.

Изначально разработчики ядра планировали перейти на 16-разрядный счётчик вместо 8-разрядного, но это оказалось невозможным так как константа LINUX_VERSION_CODE, вычисляемая с использованием 8-битного значения, экспортируется в пространство пользователя и замена типа приведёт к нарушению ABI. Поэтому решено оставить переполнение и посмотреть, как это отразится на пространстве пользователя. Разработчикам дистрибутивов предлагается сформировать тестовые сборки для проверки появления возможных проблем в пространстве пользователя при полной пересборке.

Ссылки:
http://kroah.com/log/blog/2021/02/05/8-bits-are-enough-for-a-version-number-dot-dot-dot/
https://www.opennet.ru/opennews/art.shtml?num=54544

Из консоли ядра Linux удалена поддержка прокрутки текста

Из поставляемой в составе ядра Linux реализации текстовой консоли удалён код, обеспечивающий возможность прокрутки текста назад (CONFIG_VGACON_SOFT_SCROLLBACK). Код удалён в связи с наличием ошибок, которых оказалось некому устранить из-за отсутствия мэйнтейнера, курирующего разработку vgacon.

Летом в vgacon была выявлена и устранена уязвимость (CVE-2020-14331), способная привести к переполнению буфера из-за отсутствия должных проверок наличия доступной памяти в буфере прокрутки. Уязвимость привлекла внимание разработчиков, который организовали fuzzing-тестирование кода vgacon в syzbot.

Показать

Дополнительные проверки выявили ещё несколько похожих проблем в коде vgacon, а также проблемы в программной реализации прокрутки в драйвере fbcon. К сожалению, проблемный код давно остаётся без сопровождения, предположительно из-за того, что разработчики перешли на использование графических консолей и текстовые консоли вышли из обихода (люди продолжают пользоваться консолями vgacon и fbcon, но они уже десятилетия не являются основным интерфейсом ядра и такие расширенные возможности, как встроенная в драйвер прокрутка (Shift+PageUp/PageDown), предположительно, мало востребованы).

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

Источник

Intel выпустила собственную ОСь mOS

Intel выпустила собственную операционную систему mOS, предназначенную для суперкомпьютеров и масштабируемых систем. Пока что она находится в стадии пре-альфы, но её уже можно использовать на некоторых суперкомпьютерах, таких как ASCI Red, IBM Blue Gene и других. В следующем году Intel рассчитывает выпустить уже полноценную версию для суперкомпьютера Aurora.

В основе mOS лежит модифицированная версия ядра Linux с облегчёнными ядрами (lightweight kernels; LWK) для высокопроизводительных вычислений. Последняя версия mOS базируется на ядре Linux 5.4 LTS.

Источник:
https://www.phoronix.com/scan.php?page=news_item&px=Intel-mOS-Multi-OS-Linux

Проверка раздела в образе диска

Часто сталкиваюсь с ситуацией, когда при попытке запуска в  QEMU виртуалки с образа диска (в основном IMG) возникает ошибка Kernel panic — not syncing: Attempted to kill init!: Показать

Пример ошибки:

sd 0:0:0:0: [sda] Attached SCSI disk
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@fluxnic.net>
eth0: SMC91C11xFD (rev 1) at d089a000 IRQ 25 [nowait]
eth0: Ethernet addr: 52:54:00:12:34:56
mousedev: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
input: AT Raw Set 2 keyboard as /devices/fpga:06/serio0/input/input0
input: ImExPS/2 Generic Explorer Mouse as /devices/fpga:07/serio1/input/input1
EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (244)
EXT4-fs (sda2): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda2): recovery complete
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 8:2.
devtmpfs: mounted
Freeing init memory: 120K
Kernel panic - not syncing: Attempted to kill init!
[<c0032bec>] (unwind_backtrace+0x0/0xf0) from [<c03064dc>] (panic+0x58/0x170)
[<c03064dc>] (panic+0x58/0x170) from [<c0044054>] (do_exit+0x5d0/0x68c)
[<c0044054>] (do_exit+0x5d0/0x68c) from [<c004435c>] (do_group_exit+0x40/0xb0)
[<c004435c>] (do_group_exit+0x40/0xb0) from [<c004ed48>] (get_signal_to_deliver+0x1a8/0x378)
[<c004ed48>] (get_signal_to_deliver+0x1a8/0x378) from [<c002f124>] (do_signal+0x90/0x518)
[<c002f124>] (do_signal+0x90/0x518) from [<c002fa64>] (do_notify_resume+0x48/0x54)
[<c002fa64>] (do_notify_resume+0x48/0x54) from [<c002cc38>] (work_pending+0x24/0x28)

Вероятно, эта ошибка возникает при отсутствии флага проверки файловой системы (возможно, в корне ФС лежит пустой файл с именем /forcefsck). Борюсь с этим так. Командой fdisk получаю сектор начала ФС (допустим — 217156), умножаю его на размер сектора (обычно 512 байт) и получаю смещение (в данном примере — 111183872 байт). С этим смещением монтирую на спецдевайс /dev/loop0 IMG-файл. Провожу проверку с лечением возможных повреждений ФС, затем убираю монтирование спецдевайса.

sudo fdisk -l <имя образа>.img
sudo losetup -o <смещение * 512> /dev/loop0 <имя образа>.img
sudo fsck -fv /dev/loop0
sudo losetup -d /dev/loop0

Источники:
http://web.archive.org/web/20161224011451/http://blog.3mdeb.com/2015/12/30/emulate-rapberry-pi-2-in-qemu/
https://raspberrypi.stackexchange.com/questions/40854/kernel-panic-not-syncing-vfs-unable-to-mount-root-fs-on-unknown-block179-6

Запуск виндовых команд из консоли posix-систем

Недавно возникла необходимость в том, чтобы рулить виндовым сервером в домене удалённо прямо из консоли Linux-сервера. Гугляж выдал варианты типа xfreerdp, ssh-сервера для Windows, rdesktop’а, psexec’а и winexe. Мне захотелось попробовать прикрутить winexe.

Процесс: Показать

Делал в  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

Леннарт ’мать его’ Поттеринг представил systemd-homed

Леннарт Поттеринг (Lennart Poettering) на конференции All Systems Go 2019 представил новый компонент системного менеджера systemd — systemd-homed, нацеленный на обеспечение переносимости домашних каталогов пользователей и их отделения от системных настроек. Основная идея проекта в создании самодостаточных окружений для данных пользователя, которые можно переносить между разными системами, не заботясь о синхронизации идентификаторов и конфиденциальности.

Окружение домашнего каталога поставляется в форме монтируемого файла-образа, данные в котором зашифрованы. Параметры учётных данных пользователя привязаны к домашнему каталогу, а не к системным настройкам — вместо /etc/passwd и /etc/shadow используется профиль в формате JSON, хранимый в каталоге ~/.identity. В профиле указаны параметры, необходимые для работы пользователя, включая данные об имени, хэше пароля, ключах для шифрования, квотах и предоставляемых ресурсах. Профиль может быть заверен цифровой подписью, хранимой на внешнем токене Yubikey.

Показать

Параметры также могут включать дополнительные сведения, такие как ключи для 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.

Видео

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



Объясните недалёкому, для чего нужен systemd-homed?


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


– Потому что это только в убогой винде все настройки лежат кучкой, в папке c:\windows\system32\config и ещё шести файлах профиля, которые суммарно составляют «реестр Windows». В гениальной же Linux настройки равномерно размазаны тонким слоем по всей системе. И если пользователь захочет просто скопировать окружение на другой комп, он затрахается собирать конфиги по всему диску, ибо где только они не разбросаны... Разве что в своп-разделе нет, и то ещё не уверен — не удивлюсь, если есть и такие компоненты системы, которые их даже там хранят.
Вот для того, чтоб прошерстить весь диск и собрать всё это барахло в единую кучку, и предназначена данная штука.


– что бы когда будет нужно (уже не в столь далёком будущем), отправить «товарищу майору» (или сэру мэйджору?) всё, что можно найти в «домике». Естественно, предварительно открыв канал через уже придуманный systemd. А кто не согласится — отключим газ. Ну или комп. Или хотя бы домик — что бы доказуху не потёрли.
Чует моё сердце, что этот sd довром не кончится — нас ждут весёлые времена и масса открытий. И, возможно, в самое ближайшее время.

Источник

Инициатива Microsoft по включению поддержки exFAT в ядро Linux

Компания Microsoft опубликовала технические спецификации на файловую систему exFAT и выразила готовность передать права на использование всех связанных с exFAT патентов для безвозмездного использования в Linux. Отмечается, что опубликованной документации достаточно для создания переносимой реализации exFAT, полностью совместимой с продуктами Microsoft. Конечной целью инициативы является добавление поддержки exFAT в основной состав ядра Linux.

Показать

Участники организации Open Invention Network (OIN), в число которых входит и Microsoft, обязуются не предъявлять судебных претензий за использование своих технологий в компонентах «системы Linux» («Linux System»). Но exFAT не входит в их число, поэтому на данную технологию не распространяются обязательства Microsoft в области предоставления возможности использования своих патентов. Для снятия угрозы патентных претензий компания Microsoft планирует добиться включение драйвера exFAT в число компонентов, входящих в следующую редакцию определения «системы Linux». Таким образом, связанные с exFAT патенты попадут в область действия соглашения, заключённого между участниками OIN.

Примечательно, что раньше патенты на exFAT были ключевым звеном в большинстве претензий Microsoft, затрагивающих предустановку решений на базе Linux. Драйвер с реализацией exFAT шесть лет назад был открыт компанией Samsung под лицензией GPLv2, но он до сих пор остаётся не включён в основной состав ядра Linux из-за опасности предъявления компанией Microsoft иска о нарушении патентов. На сайте Microsoft до сих пор остаётся страница с информацией о необходимости получения лицензии на использование exFAT.

Файловая система exFAT была создана Microsoft для устранения ограничений FAT32 при использовании на Flash-накопителях большого объема. Поддержка файловой системы exFAT появилась в Windows Vista Service Pack 1 и Windows XP с Service Pack 2. Максимальный размер файла по сравнению с FAT32 был расширен с 4 Гб до 16 эксабайт, устранено ограничение на максимальный размер раздела в 32 Гб, для уменьшения фрагментации и увеличения скорости введена битовая карта свободных блоков, ограничение на число файлов в одной директории поднято до 65 тыс., предусмотрена возможность хранения ACL.

Источник

Ранее Ctrl + ↓
Наверх