После двух с половиной месяцев разработки Линус Торвальдс представил (https://lkml.org/lkml/2018/1/28/173) релиз ядра Linux 4.15. Среди наиболее заметных изменений: защита от атак Meltdown и Spectre, поддержка архитектуры RISC-V, интеграция прослойки DC (Display Core) в драйвер amdgpu, контроллер ресурсов CPU для cgroup2, поддержка технологии AMD Secure Encrypted Virtualization, оптимизация энергопотребления на системах с SATA ALPM, поддержка протокола ThunderboltIP, удаление звуковой подсистемы OSS.
В новую версию принято около 15 тысяч исправлений от 1600 разработчиков, размер патча - 46 Мб (изменения затронули 13177 файлов, добавлено 611097 строк кода,
удалено 287446 строк). Около 51% всех представленных в 4.15
изменений связаны с драйверами устройств, примерно 16% изменений имеют
отношение к обновлению кода специфичного для аппаратных архитектур, 12%
связано с сетевым стеком, 4% - файловыми системами и 3% c внутренними
подсистемами ядра. 11.3% изменений внесено сотрудниками компании Intel, 10.7% изменений подготовлено сотрудниками AMD, 6.7% - Red Hat, 5.2% - Google, 3.4% - Linaro, 3.2% - IBM, 2.7% - Oracle, 2.2% - ARM, 2.1% - SUSE.Основные (http://kernelnewbies.org/Linux_4.15) новшества (https://lwn.net/Articles/740064/):
-
Виртуализация и безопасность- В дополнение к появившейся в ядре 4.14 поддержке технологии AMD SME (Secure Memory Encryption), позволяющей автоматически зашифровывать и расшифровывать страницы памяти при записи и чтения из DRAM, в новой версии ядра реализована начальная поддержка механизма AMD Secure Encrypted Virtualization (http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/...), которые предоставляет средства шифрования памяти для виртуальных машин. AMD Secure Encrypted Virtualization позволяет защитить виртуальные машины от компрометации со стороны гипервизора или адмнинистратора хост системы. Суть метода защиты в интеграции в архитектуру виртуализации AMD-V возможности для прозрачного шифрования памяти виртуальных машин, при которой доступ к расшифрованным данным имеет только текущая гостевая система, а остальные виртуальные машины и даже гипервизор при попытке обращения к этой памяти получают зашифрованные данные. В версии 4.15 добавлены компоненты для использования Secure Encrypted Virtualization на стороне гостевой системы, компоненты для создания и управления защищёнными гостевыми системами появятся в одном из следующих выпусков ядра Linux;
- Добавлена поддержка режима "User Mode Instruction Prevention" (UMIP), предоставляемого процессорами Intel. При включении данного режима на уровне CPU в пространстве пользователя запрещается выполнение некоторых инструкций, таких как SGDT, SLDT, SIDT, SMSW и STR, которые могут применяться в атаках, нацеленных на повышение привилегий в системе. Для корректной работы эмуляторов, таких как Wine и DOSEMU2, инструкции SGDT, SIDT и SMSW при включении режима эмулируются;
- Включены последние наработки для блокирования атак Meltdown и Spectre (https://www.opennet.me/opennews/art.shtml?num=47856). Для противодействия атаке Meltdown (CVE-2017-5754) на системах x86 с процессорами Intel (процессоры AMD данной атаке не подвержены) добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) технология PTI (Page Table Isolation), обеспечивающая разделение таблиц страниц памяти ядра и пространства пользователя при переключении контекста во время системного вызова. Для процессоров PowerPC для защиты от Meltdown добавлен код на основе применения инструкции RFI (Return from Interrupt) для сброса кэша L1-D.
Для блокирования эксплуатации второго варианта уязвимости Spectre (CVE-2017-5715) добавлен (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) механизм retpoline, основанный на применении специальной последовательности инструкций, исключающей вовлечение механизма спекулятивного выполнения для косвенных переходов (для работы защиты также требуется сборка модифицированной версией GCC 7.3, в которой появилась поддержка режима "-mindirect-branch=thunk-extern"). Включение средств для обеспечения защиты от первого варианта атаки Spectre (CVE-2017-5753) и кода для блокирования Meltdown на процессорах ARM отложено до выпуска 4.16.Так как механизмы защиты приводят (https://www.opennet.me/opennews/art.shtml?num=47880) к снижению производительности, предусмотрены опции для их отключения, которые могут применяться на системах с минимальным риском атаки, например на однопользовательских рабочих станциях. Для отключения PTI во время загрузки ядру можно передать (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) опцию pti=off, а для отключения retpoline - опцию (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) "spectre_v2=off". В состав ядра также добавлен (http://kroah.com/log/blog/2018/01/19/meltdown-status-2/) диагностический вызов в sysfs для быстрого определения степени устранения уязвимостей Meltdown и Spectre, который привязан к директории /sys/devices/system/cpu/vulnerabilities/:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic SM retpoline- В Xen реализован фронтэнд для протокола PV Calls, позволяющего перенаправлять POSIX-вызовы, инициированный из приложения в DomU, для обработки на стороне Dom0 или другой гостевой системы;
- Добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) реализация криптографического хэша OSCCA SM3, стандартизированного для учреждений Китая;
- Интерфейс /sys/kernel/security/evm расширен (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) возможностью информирования о загрузки RSA-ключа для блокирования загрузки других ключей в случае компрометации;
-
Дисковая подсистема, ввод/вывод и файловые системы
- В XFS добавлна начальная поддержка проверки целостности файловой системы на лету (online), которая пока не готова для широкого использования. В XFS также осуществлён переход на структуру b+tree для встроенного списка экстентов, которая позволяет избежать выделения крупных непрерывных блоков и исключить подтормаживания в условиях применения огромных списков экстентов (например, при работе с сильно фрагментированными файлами);- В EXT4 улучшена (https://git.kernel.org/linus/439e7271dc2b63de379e37971dc2f64...) масштабируемость генерации inode на SMP-системах. Добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) поддержка изменения размера на лету для ФС, в которых используется bigalloc;
- В Btrfs добавлена возможность указания уровня сжатия для zlib (-o compress=zlib:9). Добавлена дополнителная
эвристике для быстрой приблизительно оценки степени сжимаемости данных. Проведена оптимизация операции send для больших файлов. Добавлена новая версия ioctl "extent to inode mapping", позволяющая ценой снижения точности получить больше данных для постобработки в пространстве пользователя, например, для оценки состояния утилитами дефрагментации или дедупликации. Реализована отладочная опция ref-verify для верификации учёта ссылок на экстенты;
- В OverlayFS добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) возможность применения индексации при использовании Btrfs в качестве ФС для базового сл...URL: https://lkml.org/lkml/2018/1/28/173
Новость: http://www.opennet.me/opennews/art.shtml?num=47942
> RISC-VЖдем малинок, контроллеров и смартфонов на RISC-V.
>> RISC-V
> Ждем малинок, контроллеров и смартфонов на RISC-V.А эльбрусы раньше[I]!
Эльбрусы на платках с малинкоподобными размерами? Маловероятно, практически невероятно.
> Эльбрусы на платках с малинкоподобными размерами? Маловероятно, практически невероятно.Да!! Вы правильно поняли!
Эльбрусов на всём вышеперечисленном "не будет никогда"ТМ намного раньше, чем. И ранее того - "не было никогда".
---
Впрочем, буду рад ошибиться.Смотрю по сторонам, наблюдаю "видовое разнообразие". Пару коробочек с рокчипами aarch64, роутер(полтора:E ) с бродкомом:/ мипс32. Звонилки "у всех" - на armhf. Ничего из этого никакого отношения к субжу "4.15" по факту не имеет.
Вдруг, risc-v или(/и!) эльбрус ка-а-ак стрельнут (не в смысле поставок C400 в Иран) -- в "следующем новом устройстве", купленном задёшево в соседнем лабазе... Всем мечтать 5 секунд.
Запустил 4.15 на коробочке с 32-битным armhf, полет нормальный.
> Запустил 4.15 на коробочке с 32-битным armhf, полет нормальный.Когда купишь "задёшево в соседнем лабазе" эльбрус или risc-v, возвращайся и расскажи, какую версию ${на который из них} поставил.
В добрый путь.
Если ставить - то на rics-v. Он уже поддерживается открытыми компилерами, ядро уже есть, несколько SoC выпустили. Процессы раскручиваются быстро, SoC под линух уже разрабатывают, по всем признакам через несколько лет "задёшево в соседнем лабазе" как раз.А эльбрус - спасибо, я на примере чипов глонасса увидел как это бывает. Эльбрус из той же оперы, только еще печальнее.
>по всем признакам через несколько лет "задёшево в соседнем лабазе" как раз.А дешевле OpenSPARC-a будет? Который как помницццо "по всем признакам через несколько лет" уже тоже _был_ :-)
>А эльбрус - спасибо, я на примере чипов глонасса увидел как это бывает. Эльбрус из той же оперы, только еще печальнее.Хотелось бы грязных подробностей(С)
А то глядя на пачку премиум смартов у которых у _всех_ Глонасс таки есть, всякие мысли о компетенции в ... возникают :-/ И самса, и ябблы, и хтц значит не в ногу? Я скорее поверю что ты очередная дщерь морского крабэ(С)
> А дешевле OpenSPARC-a будет? Который как помницццо "по всем признакам через несколько
> лет" уже тоже _был_ :-)Покажи хоть один реальный чип в железе на основе спарцо? Спарцо сложные и большие. Выпустить такой чип сложно. RISC-V мелкие и проще, на их основе УЖЕ полдюжины разныз SoC ВЫПУСКАЕТСЯ.
> Хотелось бы грязных подробностей(С)
Сколько лет этим эльбрусам? И до сих пор им там надо что-то объяснять, видите ли, что хороший чип должен обеспечивать разумное соотношение цена/качество. И уж навернео системные тулсы должны быть открытыми и желательно чтобы чип поддерживался майнлайновыми версиями инструментов, а не внебрачными выпердышами. Это если интересует чтобы
1) чип реально что-то из себя представлял и его покупали, а не надеялись что в очеретной автоТАЗ донакинут из бюджета.
2) нормальная экосистема разработчиков и проч вокруг всего этого> А то глядя на пачку премиум смартов у которых у _всех_ Глонасс
> таки есть, всякие мысли о компетенции в ... возникают :-/Так ты разбери их и посмотри какой чип там для GPS стоит, все сомнения отпадут. Это если чип вообще отдельный, может быть и частью сотового модема. Понятно что не made in russia, чипы такого уровня интеграции россияне в принципе не производят, равно как и стэк GSM они не разработали ни разу, не говоря про 3G, LTE и проч. Это иной уровень R&D требует, присвоением чужих заслуг и громкой пропагандой там не отделаешься. А если на этом еще и попытаться пильнуть, по цене выйдет как межгалактический космофлот.
> И самса, и ябблы, и хтц значит не в ногу? Я скорее
> поверю что ты очередная дщерь морского крабэ(С)Ну стоит там какой-нибудь STMicro, MTK, или встроено в сотовый модем. Российские же разработчики смогли сделать дуры размером с чипсет на мамке и прожорливее стмикро раза в три. Куда их такие? Вот они поматросили и сдулись, теперь "российские" разработчики дружно паяют те же STM и MTK на "российские" модули и устройства, где даже текстолит и сборка на поверку китайские. Т.е. разработки чуть выше уровнем чем белорусский интеграсер, где все производство сводилось к наклейке.
Ещё как правдоподобно. У них в планах зашить КПИ (аналог южного моста) в процессор, а сам проц у них не использует сокетов. Итого, малинкоподобие реально, но тогда процессор займёт примерно треть площади платы и потребует радиатора.
> А эльбрусы раньше[I]!Ну ты сравнил, блин, пильщиков бюджета и стартаперов.
>> А эльбрусы раньше!
> Ну ты сравнил, блин, пильщиков бюджета и стартаперов.Академ-пе*дунов, пилящих гранты, с гордостью российской стартапии-то?
Чё б не посравнивать: кто первый до "никогда" добежит...
Академики свое дело сделали и вывалили результат на паблик. И уже появилось штук пять резвых стартапов. В которых таки не академики. От академиков коммитов в компилер и майнлайн не дождешься, им такие приземленные вещи не интересны.
И что, скоро ждать поддержку E2k в ванильных GCC, GNU Binutils, GDB?
Вам зачем что мешает скачать православый Baikal SDK и собрать его gcc-ой?
> Удалён код для обеспечения поддержки звуковой подсистемы OSSРадует, что хоть что-то выкидывают. А то слишком жирно.
Давай называть вещи своими именами: выкидывают годные вещи чтобы жЫрнота systemd влезла. Удачи.
Годной вещью OSS было тогда, когда она была нужна, а исходники были закрытыми. С выходом свободной ALSA OSS была сразу обречена.Если нужна работа древних приложений, которые не умеют работать через ALSA, то вот в помощь OSS Proxy: https://sourceforge.net/projects/osspd/
>Годной вещью OSS было тогда, когда она была нужна, а исходники были закрытыми. С выходом свободной ALSA OSS была сразу обречена.Спорить не буду, но друЗЗя музыканты ... ну ты понел :) Ну ничо, перейдут назад на маки\форточки проблем то?
Они jack по жизни пользуются, поверх алсы. А ты наверное бсдшник, что так за маки и форточки радеешь. Своя то система как десктоп г-но, вот и завидуешь пингвинам.
Отставить срaч. В GNU/Hurd нет даже этого, но это не делает систему гoвнoм. Просто, пока это было никому не нужно. :-)С практической точки ALSA более переносима и умеет работать на платформах, отличных от x86 и x86_64. OSS в GPL-редакции не умеет.
А тот же Jack, работает как раз-таки не сам по себе, а поверх ALSA. Причём поддержка ALSA в Jack считается стабильной, тогда как поддержка OSS появилась относительно недавно и считается пока экспериментальной.
Тоже самое относится к PulseAudio. Но у пульсы есть фатальный недостаток, - её пейсал Леннарт Поттеринг. Это тоже надстройка над ALSA. Изначальна содержала в себе благую идею, - заменить морально устаревшие aRts и ESD (cами разработчики Enlightenment, кстати походу повелись и теперь собрать E совсем без пульсы довольно проблематично, хотя и возможно). Но так как, Поттеринг писал пульсу, похоже, ногами, то ничего хорошего из этого не получилось.
Те программисты, которым нужна работа программ только в GNU/Linux, предпочитают использовать ALSA напрямую, без посредников.
Те, кому нужна кроссплатформенность, предпочитают работать со звуком через SDL_mixer. Ну, или, Jack, жеж...Надеюсь доступно разъяснил. :-)
Жесть, размер патча сравним с размером самого ядра несколько лет назад)
Нет, жесть то, что только патч к видеодрайверу AMDGPU сравним с размером ядра Linux 1.0 - 132 тысячи против 176 тысяч строк кода.
А что вы хотели - железки, с которыми этот драйвер работает, на порядок сложнее, чем вся система, где крутился первый линукс
Вы хотите сказать что наконец-то мы дождались нормальных драйверов для современных AMD видеокарт?
У меня Vega 56 со свободными драйверами работает хорошо. OpenGL и Vulkan. Вулкан пока ещё хуже птимизирован. AMDGPU-PRO просто шлак. Но есть и другие десктопные задачи.
У меня почти одинаково хорошо в Виндовс и Линикс работает Intel Iris Plus Graphics 640.
Хотя бы всё видео аппаратно декодируется. VP9 10 бит процессор почти не нагружает.
В Линуксе Ютуб процессор нагружает, а в Виндовсе нет.
С Vega 56 в Виндовсе процессор не нагружается в Ютубе. Все кодеки аппартно поддерживаются. В Линуксе VP9 аппаратно вообще не поддерживается. Просмотр видео значительно сильне нагружает процессор, чем с Intel.
Поставь h264fy, и будет тебе счастье на Ютубе.
Конечно поставил.
> Поставь h264fy, и будет тебе счастье на Ютубе.Не будет: ютуб сейчас VP9 чаще всего сватает - битрейт ниже, качество выше. Так что нужна поддержка VP9.
Какой юзкейс что вас устраивает? Opencl?
нужен патченный Хромиум для аппаратного декодирования видео на Интеле
http://bugs.rosalinux.ru/show_bug.cgi?id=8655
https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-...
> Вы хотите сказать что наконец-то мы дождались нормальных драйверов для современных AMD видеокарт?В первом приближении - таки да.
>Включены патчи для оптимизации энергопотребления на системах с SATA AHCI->контроллерами, поддерживающими функцию ALPM (Aggressive Link Power >Management).
>........
>Данные параметры не описаны в документации, а использование наугад приводило к >проблемам с повреждением данных. В принятом в состав ядра 4.15 патче удалось >подобрать параметры, при которых не замечено проблем, а время автономной работы >при некоторых видах нагрузки существенно увеличивается;Жесть. Реверс винды чтоли делали?
Написано же - подбирали.
В каждой версии ядра выкатывали новые и смотрели, как хомяки реагируют. :)
> Включены патчи для оптимизации энергопотребления на системах с SATA AHCIНаконец-то.
Вот лучше пусть внешний диск работает, чем электричество экономит :-)
>> Включены патчи для оптимизации энергопотребления на системах с SATA AHCI
> Наконец-то.Ну, в следующих сериях расскажещь нам, как оно там у тебя -->
#>>приводило к проблемам с повреждением данных. В принятом в состав ядра 4.mm патче удалось подобрать параметры, при которых не замечено проблем, а время автономной работы >при некоторых видах нагрузки существенно увеличивается;
Ну а чего делать. Штеуд такой штеуд. Механизмы есть, инфы по ним ноль...
> Прекращена чистка драйверов ap1302 и oss, в связи с их удалением из ядра.Как теперь делать cat /boot/vmlinuz /dev/dsp? Неудежи устанавливать OSS v.4? Мне этот пакет отключает ALSA.
aplay /boot/vmlinuz
> aplay /boot/vmlinuzЛучше вот так
aplay vmlinuz-4.9.0-3-amd64 -r 300
а то не успеваю записывать )
modprobe snd-pcm-oss
Удалена никем не используемая подсистема OSS со своими драйверами, которую было невозможно использовать параллельно с ALSA для той же звуковой карты, а не эмуляция альзой oss.
"Реализована шина ac97 с реализацией модели устройство/драйвер для чипов с поддержкой звуковых кодеков AC97. Шина предоставляет средства для автоматического обнаружения устройств AC97"Это автоматически теперь сможет выключаеться звук в колонках при подключении наушников на переднюю панель? Или это не про то?
Про то. Вновь подключаемое устройство должно получать приоритет и звук должен идти и туда, или только туда.
AC'97 ведь не умеет этого, такая функциональность появилась только в HDA (AC'04).
>Это автоматически теперь сможет выключаеться звук в колонках при подключении наушников на переднюю панель?Если аналогвых наушников, то вряд ли. Если USB, то может быть.
>> отложено до выпуска 4.16Долго они всё это патчить ещё будут. Интересно, к следующему LTS успеют? Кстати, следующий LTS это какой?
>> Среди наиболее заметных изменений: защита от атак Meltdown и SpectreОн таки принял патчи от интела которые сам же сильно критиковал? Кто в курсе?
Насколько я понял, нет. В релизе только kpti и retpoline (который Google-вский).
тогда не понятно как отключается зашита от спектра, если гугловские патчи включены в гцц и нужно пересобирать бинарник что бы это включать/отключать. А интеловские патчи позволяли это делать на лету не перекомпилируя юзерспейс.
> тогда не понятно как отключается зашита от спектраВ новости так-то ссылка на патч есть. Там вроде бы всё понятно.
Им бы уже нейросеть начать тренировать патчи принимать. Типа прислали патч, нейросеть такая смотрит и либо матерится на разработчика, либо шлёт в ответ замечания, либо благодарит и принимает в ветку. И тренировать эту нейросеть должен сам Линус.
так он и тренирует, сети называются мейнтейнеры
Вроде как сеть называется Greg KH
Ещё в это ядро добавили патчи от Кита Пакарда для новой инфраструктуры DRM Leases, благодаря которой в Линуксе нормально будут работать шлемы виртуальной реальности, в частности HTC Vive
>Ещё в это ядро добавили патчи от Кита Пакарда для новой инфраструктуры DRM Leases, благодаря которой в Линуксе нормально будут работать шлемы виртуальной реальности, в частности HTC ViveДа?! Только не говори что не знаешь о старом ядре, а иначе как ты его соберешь без посредников?
Далее. Про шлемы это хорошо, но как быть другим корпорациям?
После появления супердыр в многозадачности всех поколений процессоров начиная с i386 (Meltdown и Spectre) максимум можно одну задачу на одном компьютере исполнять, либо задачи одного уровня секретности!
>процессоров начиная с i386ну нельзя же так, мат часть надо изучать!!!
суть дела, это не меняет! Никакой многозадачности!
> После появления супердыр в многозадачности всех поколений процессоров начиная с i386 (Meltdown
> и Spectre) максимум можно одну задачу на одном компьютере исполнять, либо
> задачи одного уровня секретности!Бери i286 там все впорядке )
Появилась ли какая-либо альтернатива удаленному параметру - tcp_tw_recycle ?
Нет, данный механизм полностью удалён и не будет реализован в будущем, если конечно tcp timestamp offset randomization не удалят.А для каких нужд вы использовали данный механизм?
Я использую данный механизм на тестовой машине для проведения опытов над сервером. Для того, чтобы сгенерировать достаточное количество запросов на тестовой машине имеется 2 интерфейса(по 10ГБит/с). Чтобы отправить пакет с нужного интерфейса, для сокета, после его создания, вызывается функция bind(параметром является локальный ip адрес). При интенсивной отправке коротких запросов на тестовой машине все сокеты переходят в состояние TIME_WAIT. И только tcp_tw_recycle установленный в 1 помогает переиспользовать данные сокеты. Причем, если не использовать bind, а использовать только маршрут по-умолчанию, то tcp_tw_recycle не нужен. Но этот случай я не рассматриваю за ненадобностью.
Понятно, с ходу в голову приходит только увеличить диапазон портов до максимума, который можно использовать, а так же количество локальных IP адресов. Ещё нашёл вариант, использовать опцию SO_REUSEADDR, если у вас есть доступ к исходным кодам генератора запросов.
> Понятно, с ходу в голову приходит только увеличить диапазон портов до максимума,
> который можно использовать, а так же количество локальных IP адресов. Ещё
> нашёл вариант, использовать опцию SO_REUSEADDR, если у вас есть доступ к
> исходным кодам генератора запросов.Или узнать про zmap, где вообще нет этих проблем. Просто как класса нет. Но он специфичная штука, где все ради скорости. Зато эта штука может просканить порт по всему IPv4 с гигабита за час, чтоли.
Латиноамериканский Фонд это небось - бразильцы? Наши "библиотечные" в свое время у них код воровали, когда еще не было открытого кода OpenIsis. По моему до сих пор на нем и сидят. Новое осваивать не кому, денег нет!
>бразильцы?
> Среди наиболее заметных изменений: защита от атак Meltdown и SpectreА в 4.14 бэкпортируют?
Давно уже. KPTI — c 4.14.10, retpoline — c 4.14.14.
Спасибо.
Когда в btrfs добавят шифрование на уровне ФС? И не надо кричать, что не нужно. Нужно, чтобы зашифровать уже установленную систему на лету. Тем более, что btrfs весьма перспективна для смартфонов (когда допилят ;)).
f2fs
Судя по вики, над шифрованием даже никто не начинал работать. Хотя в предложениях по проекту этот пункт присутствует: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Encryp...
btrfs функциональная, но очень тяжелая фс. Для смартфонов больше подойдет f2fs. Она намного шустрее, легче по потреблению памяти и, самое главное, энергоэффективнее btrfs.
> но очень тяжелая фсТы её с ZFS спутал, Btrfs ничем не тяжелее Ext4
Ага, ЩАЗ! :) И это я ещё о ея кривизне громко молчу :)
Эксперты уровня ЛОР, как обычно, поражают аргументацией
> Ага, ЩАЗ! :) И это я ещё о ея кривизне громко молчу :)В отличие от ZFS там нормальное управление памятью, как у всех остальных линевых файлух. Поэтому народ сие запускает даже на эмбедовке с 256-512 мегов оперативки. Работает себе, даже довольно резвенько. Народ на ней мини-сервачки на allwinner с SATA городит. Удобно же когда штука с кредитку размером файло ворочает не хуже любого дешевого NAS, толко еще и OS открытая от и до, например Debian обычный.
И нет там никакой особой кривизны уже. Разве что RAID5/6 все-таки пока WIP, но в 4.16 им как раз уже уделили внимание. А так работает себе, лишь бы кернел не сильно древний.
Часто вижу новости про протокол SCTP, а есть уже программы использующие его? Истории успеха использующие его фитчи?
SCTP может быть использован, как транспортный протокол для SIP, Diameter и других протоколов, в основном это будут видео/аудио области.
Могли бы браузеры, но в винде его нет (а может не только по этому), в итоге гугл изобретает http/2 и имеем что имеем.
> Могли бы браузеры, но в винде его нет (а может не только
> по этому), в итоге гугл изобретает http/2 и имеем что имеем.1. Есть, причём несколько реализаций. :-)
Жаль. В SCTP есть вполне годные идеи, например, возможность синхронно использовать несколько каналов для связи двух и более хостов. На википедии, кстати, есть вполне информативная табличка UDP/TCP/SCTP показывающая возможности протоколов.
2. Ответ на чей-то коммент про шифрование.
Шифрование - не задача SCTP. Это задача 6 представительского уровня (если смотреть в эталонной модели OSI). То, что в http/tls всё намешано еще не является поводом делать также.
Во многом поэтому, я считаю, http/2 это тот же ..., только в другой руке. Особо усугубленный ещё и тем, что позволяет посылать то, что у него не просили.
А если говорить максимально просто, то там где изначально хаос, рождается ещё больший хаос. Именно поэтому мы имеем то, что имеем. :-)
Вопрос знатокам: вот эти фиксы в 4.15 уже используют наномеханизмы последних моделей процессоров, позволяющих уменьшить ужас борьбы с кешем? Что-то там с идентификаторами процессов вроде бы анонсировалось для 4.15
zram + zstd будет только если наложить патч, его почему-то не добавили в осн. ветку:https://lkml.org/lkml/2017/8/4/582
Из-за zswap?
zram, zstd, zswap... Но где же zroot?:D
> zram, zstd, zswap... Но где же zroot?:DSquashFS должен вам помочь. :-)