После двух месяцев разработки Линус Торвальдс представил (https://lkml.org/lkml/2017/11/12/123) релиз ядра Linux 4.14 (https://www.kernel.org/).
Основные (http://kernelnewbies.org/Linux_4.14) новшества (https://lwn.net/Articles/733846/):
-
Дисковая подсистема, ввод/вывод и файловые системы
- Проведена большая работа по увеличению производительности подсистемы дисковых квот. Производительность создания файлов при включенных квотах в ext4 возросла примерно в два раза;- В сетевой файловой системе CIFS добавлена поддержка чтения и записи расширенных атрибутов с использованием протокола SMB3;
- В Btrfs добавлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... поддержка алгоритма сжатия zstd (https://www.opennet.dev/opennews/art.shtml?num=45058), который может рассматриваться как оптимальный компромисс, между быстрым но неэффективым lz4 и медленным но хорошо сжимающим xz. По сравнению с zlib/Deflate, zstd демонстрирует в 3-5 раз более высокую скорость сжатия и в два раза более быструю распаковку, при уровне сжатия выше на 10-15%.
- Добавлен новый флаг IOCB_NOWAIT, при установке которого асинхронные операции буферизированного блочного ввода/вывода выполняются по возможности как в неблокирующем режиме (например, без флага IOCB_NOWAIT могут блокироваться операции управления памятью);
-
Виртуализация и безопасность- Добавлена поддержка шифрования отдельных страниц памяти при помощи представленной в процессорах AMD технологии SME (http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/... (Secure Memory Encryption). SME позволяет пометить страницы памяти как подлежащие шифрованию, после чего данные страницы будут автоматически зашифрованы при записи в DRAM и расшифрованы при чтении из DRAM;
- Из-за невостребованности и отсутствия сопровождающего удалён код системы виртуализации lguest (http://lguest.ozlabs.org/), позволяющей загружать ядра Linux как пользовательский процесс;- Добавлена возможность использования file capabilities (http://man7.org/linux/man-pages/man7/capabilities.7.html) в пространстве имён идентификаторов пользователя (user namespaces), что позволяет обойтись одним расширенным атрибутом security.capability для любого файла;
- Расширен перенесённый из патчей grsecurity плагин к GCC для рандомизации раскладки структур данных, который на этапе сборки делает непредсказуемым следование полей в структурах и затрудняет проведение атак, базирующихся на знании раскладки структур в ядре. Плагин теперь дополнительно автоматически выполняет перегруппировку элементов структур, состоящих целиком из указателей на функции;
-
Сетевая подсистема- Реализована возможность отправки данных в сетевой сокет в режиме zero-copy (https://netdevconf.org/2.1/papers/netdev.pdf) (вызов send с флагом MSG_ZEROCOPY), позволяющем организовать передачу данных по сети без промежуточной буферизации;
-
Память и системные сервисы- Добавлена система раскрутки стека ORC unwinder (https://lwn.net/Articles/728339/), позволяющая повысить надёжность трассировки стека в процессе отладки крахов ядра и увеличить качество анализа стека в момент применения live-патчей на предмет влияния подмены функции на выполняемые в текущий момент процессы. Выполнение раскрутки стека, т.е. определения цепочки вызовов, которые привели к текущему состоянию, является нетривиальной задачей в ядре, так как кроме вызова Си-функций приходится учитывать такие нюансы как вызовы из кода на ассемблере, прерывания и trap-исключения процессора;
- В cgroup добавлен (https://lwn.net/Articles/729215/) режим гибкого управления потоками процесса (cgroup.type threaded), в дополнение к ранее применяемой группировки всех потоков одного процесса и управления этой группой как единым целым. В режиме cgroup.type потоки одного процесса не обязаны входить в одну группу и могут быть разнесены по разным группам, но все из этих групп должны быть с типом threaded и размещаться в одной иерархии cgroup;
- В подсистему RDMA (http://en.wikipedia.org/wiki/Remote_direct_memory_access), предоставляющую похожие на DMA возможности для организации прямого доступа к памяти другого компьютера, добавлен новый API для использования из пространства пользователя через ioctl();
- В системный вызов membarrier(), обеспечивающий установку барьеров на память для всех работающих в системе потоков, добавлен режим MEMBARRIER_CMD_SHARED_EXPEDITED, позволяющий значительно ускорить выполнение вызова ценой применения IPI (https://en.wikipedia.org/wiki/Inter-processor_interrupt) (inter-processor interrupt);
- В системный вызов madvise(), предоставляющий средства для оптимизации управления памятью процесса, добавлена опция MADV_WIPEONFORK, при которой после выполнении fork() указанный регион памяти будет получен дочерним процессов в обнулённом виде;
- Для архитектуры x86 реализована поддержка пятиуровневых таблиц страниц памяти, позволяющих управлять до 128 Пб виртуального адресного пространства на системах с 5 Пб физической памяти;
- В системе динамического управления частотой процессора (cpufreq) появилась (https://lwn.net/Articles/732740/) возможность раздельного управления каждым CPU, что позволяет улучшить управление питанием и повысить отзывчивость при изменениях нагрузки;
- Продолжена оптимизация процесса вытеснения в раздел подкачки больших страниц памяти (Transparent Huge-Pages). Обеспечено откладывание разбиения больших страниц на маленькие до момента фактической записи в раздел подкачки или чтения из него, что позволило поднять пропускную способность вывода в раздел подкачки на 42% за счёт уменьшения конфликтов блокировок;
- Добавлена поддержка подсистемы Heterogeneous memory management (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (HMM), позволяющей использовать устройства с собственными блоками управления памятью (MMU, memory management unit), которые могут получать доступ к основной памяти. Например, при помощи HMM можно организовать совместное адресное пространство между GPU и CPU, в котором GPU может получить доступ к основной памяти процесса;
-
Оборудование- В DRM-драйвере (Direct Rendering Manager) Nouveau добавлены (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... средства для управления видеорежимами для GPU GP108 (GeForce GT 1030)
- В DRM-драйвере AMDGPU продолжена реализация поддержки GPU Radeon RX Vega.
- В DRM-драйвер для GPU Intel продолжена реализация поддержки грядущих процессоров на базе микроархитектуры Intel Cannonlake.- Поддержка звуковых кодеков Realtek RT274, Wolfson Microelectronics WM8524 и Cirrus Logic CS43130;
- Поддержка USB-контроллеров Atheros ath10k и Ralink USB PHY;
- Добавлен драйвер "rtlwifi" для беспроводных карт на базе чипов Realtek RTL8822BE (802.11ac);- Поддержка встроенных в CPU Allwinner и Freescale i.MX генераторов псевдослучайных чисел, а также средств ускорения криптографии по эллиптическим кривым в чипах Microchip и Atmel;
- Поддержка Ethernet-контроллеров Hisilicon HNS3, Rockchip, Marvell CP110 и Adaptrum Anarion GMAC, а также беспроводных адаптеров Realtek RTL8822BE;- Подсистема драйверов IRDA (поддержка инфракрасного порта) перемещена в ветку staging с целью дальнейшего удаления из ядра (драйвер на уровне ядра не востребован, так как все приложения используют реализацию (http://www.lirc.org/) в пространстве пользователя);
- Из основного ядра в репозиторий linux-firmware вынесен набор прошивок, ранее поставляемых в каталоге "firmware/". По сути, решено объединить в одном месте разрозненные прошивки, часть которых поставлялась в архиве с ядром, а часть в пакете linux-firmware. Набор прошивок в ядре продолжал ...
URL: https://lkml.org/lkml/2017/11/12/123
Новость: http://www.opennet.dev/opennews/art.shtml?num=47513
Тоска. Ничего интересного. Ну разве что только поржать над BTRFS, который как Пресли, Ленин или *BSD -- давно мертв, но некотрые вздыхают и говорят "жив!"
Это будет следующее LTS ядро, новость примечательна хотя бы только поэтому. Лично я не-LTS версии пропускаю, а к этой можно потихоньку присматриваться и некритичные системы начинать переводить.
Но с точки зрения обычного пользователя -- скучно. Меня не интересует особо стабильность и т.п. Меня больше интересуют всякие "плюшки". А тут просто "накопилось некоторое количество полезных коммитов, надо бы и релизнуть".
> Но с точки зрения обычного пользователя -- скучно.Обычный юзер, расскажи, как ты юзаешь MADV_MERGEABLE, O_TMPFILE, COPYUSER, DMA_BUF?
Отвечу за тебя - НИКАК. А тут уже MADV_WIPEONFORK и RDMA пришло!
На Сapabilities V2 весь софт перевёл? Ага, а тут уже V3 пришло.
Списочек https://kernelnewbies.org/LinuxChanges весь изучил, протестил?
Я и пишу -- скучный релиз. Для обычного пользователя ничего интересного.
А чего для обычного пользователя может быть интересного в ядре, кроме поддержки новых железок?
>Около 32% всех представленных в 4.14 изменений связаны с драйверами устройствЭто и говорит о том, что поддержка новых железок в него добавлена, улучшена поддержка ранее добавленных.
> А чего для обычного пользователя может быть интересного в ядреВсяческие улучшения поддержки этих самых железок а так же улучшения в различных подсистемах ядра.
>А чего для обычного пользователя может быть интересного в ядре, кроме поддержки новых железок?Встроенные обои.
На заборе тоже пишут.
> Я и пишу -- скучный релиз. Для обычного пользователя ничего интересного.Обычному пользователю интересен урожай кабачков да поголовье свиней на виртуальной ферме. Какое ему дело до каких-то там ядер?
> Лично я не-LTS версии пропускаюЯ тоже хотел начать так делать во времена ещё первого LTS (2.6.16 вроде). Но оказалось, что драйвер ext3 той версии постоянно приводил файловую систему к ошибочному состоянию (что показывал предусмотрительно запускающийся раз в 7 дней fsck). Я тогда дождался 2.6.16.16 или типа того, увидел что проблема не исправлена, и пересел на 2.6.17, где этой проблемы не было.
Со следующим после него "стабильным" тоже была какая-то проблема, уже не помню.
Потом был какой-то, то ли 3.10, то ли 3.16, в котором у меня система при подключении по usb мобильного телефона не видела его как диск, забэкапить на хард фоточки я не мог, пока не пересел на 3.18.
Теперь выпустили 4.14 с некорректными значениями частоты в /proc/cpuinfo.
Итого, из 3 LTS которые я пробовал, 2 содержали критичные для меня баги, и ещё один выпустили в режиме "ну и ладно что баг, потом может поправим".
Да гори оно синим пламенем, с такими-то проблемами в LTS-ах, я пожалуй на нестабильных посижу, в них у меня всё работает.
А у меня system:D при загрузке требовал новое ядро
cgroup: cgroup2: unknown option "nsdelegate"
Даже не успел посидеть на последней LTS.
> Даже не успел посидеть на последней LTS.А зачем ты руками обновляешь LTS?
>А зачем ты руками обновляешь LTS?Спроси у создателей Manjaro, зачем они выпустили 17.0.6 с конфликтом.
>>А зачем ты руками обновляешь LTS?
> Спроси у создателей ManjaroНу тут ССЗБ. LTS есть у Ubuntu/Suse/Debian/Oracle, остальное херь игрушечная :)
>>>А зачем ты руками обновляешь LTS?
>> Спроси у создателей Manjaro
>Ну тут ССЗБ. LTS есть у Ubuntu/Suse/Debian/Oracle, остальное херь игрушечная :)Ну речь была о LTS ядре, а не дистрибутиве. :)
Касательно бубунт то я пришол к выводу шо у них LTS отсутствует как клас: обжогся на kubuntu 16.04 (о дааа, я из тех удачников которые поставили ее как основную ОС при выходе) и погорел на xubuntu 16.04 (отсутствие нужных инструкций на старом ЦП при обновлении). Не думаю шо на основной Ubuntu подход к стабильности сильно отличается.
> Не думаю шо на основной Ubuntu подход к стабильности сильно отличается.Ядро там хорошо фиксят. Накрайняк пересобрать ядро под свой проц.
>Ядро там хорошо фиксят. Накрайняк пересобрать ядро под свой проц.Я под Ubuntu LTS понимаю ОС которая не должна терпеть никаких изменений в целом, кроме исправлений ошыбок (а не только ядро держать одинаковым). Может я шыбаюся?
>исправлений ошыбок
>Может я шыбаюся?Да, ты ошибаешься.
>Да, ты ошибаешься.Ну в каждой ошыбке должна быть доля ошыбки.
В LTSах есть hardware enablement stack - набор пакетов (в имени есть lts или hwe) с новыми ядрами, xorgом и прочей хрупкой хренью, которые можно поставить только вручную (обычно вместе с минорным апдейтом версии). Поэтому в убунточке с этой точки зрения сломать что-то достаточно сложно.
> hardware enablement stack - набор пакетовКстати, никто не знает в других дистрах что-то подобное?
> Кстати, никто не знает в других дистрах что-то подобное?Это только LTSам надо.
Выдержка из моего вывода screenfetch:
> OS: Manjaro 17.0.6-EOL Gellivara
> Kernel: x86_64 Linux 4.14.0-1-MANJAROЧЯДНТ?
>Выдержка из моего вывода screenfetch:
>ЧЯДНТ?Ну и молодец шо тестовое ядро поставил, цытата из манжаро.ру: "Сообщение «cgroup2: unknown option „nsdelegate“ при загрузке системы. Пользователям, использующим LTS версию ядра, возможно будет интересно почитать эту ветку. Кратко: в systemd 235 внесены изменения, которые не поддерживаются текущей LTS версией ядра. При переходе с нового года на 4.14 LTS — сообщение исчезнет."
> в systemd 235 внесены изменения, которые не поддерживаются текущей LTS версией ядраIt's… beautiful! Они там в сустемды совсем упоролись?
> совсем упоролись?Ты неправильно ставишь вопрос: они там ещё больше упоролись?! будет более правильным.
> Теперь выпустили 4.14 с некорректными значениями частоты в /proc/cpuinfo.ох, дорогой аноним, это не баг, а фича:
начиная с 4.13 частота ядра перестала экспортироваться в /proc/cpuinfo
смотреть так: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freqда, многие программы полагались на cpuinfo, но всем плевать, и чинить это не будут
> не баг, а фичаФича - баг в красивой обертке.
> начиная с 4.13 частота ядра перестала экспортироваться в /proc/cpuinfolinux 4.13.12-1 on archlinux
$ cat /proc/cpuinfo | grep cpu
cpu family : 6
cpu MHz : 1323.406
cpu cores : 2
cpuid level : 13
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority dtherm
cpu family : 6
cpu MHz : 1325.844
cpu cores : 2
cpuid level : 13
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority dthermГде ты тут видишь что перестала экспортироваться частота в cpuinfo?
Предыдущему оратору, смотрите внимательно в единицы измерения, там все корректно иначе в алгоритм калькуляции частоты посмотрите. (Если я не ошибаюсь, этот механизм не изменили.)
> linux 4.13.12-1 on archlinuxВ 4.13.12 это как раз поправили.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... : "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo".
В 4.14 тоже поправили, но потом оказалось, что на многоядерных системах эта правка слишком медленная и отревертили непосредственно перед релизом с обещанием пофиксить потом лучшим способом.
>> не баг, а фича
> Фича - баг в красивой обертке.
>> начиная с 4.13 частота ядра перестала экспортироваться в /proc/cpuinfo
> linux 4.13.12-1 on archlinux
> $ cat /proc/cpuinfo | grep cpu
> cpu MHz : 1323.406
> Где ты тут видишь что перестала экспортироваться частота в cpuinfo?$ cat /proc/cpuinfo | grep MHz; echo '---'; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
cpu MHz : 1400.000
---
1176294
1060461
1101892
979524
1002605
850526
924488
1158529
1306901
1347833
1108185
1131643
1219999
1092448
1130538
1151412
Хвалишься?
> Где ты тут видишь что перестала экспортироваться частота в cpuinfo?Вся соль в том, что при активированном frequency scaling довольно продолжительное время вместо текущей частоты отображалась только максимально возможная :)
--!!++ вместо текуЩИХ частот
Не ври.
https://www.spinics.net/lists/stable/msg195663.html
> да, многие программы полагались на cpuinfo, но всем плевать, и чинить это не будутТак а как же знаменитая линусова мантра "we don't break userspace"?
В порядке мантра. Отревертили, в очередном миноре 4.13 всё вернут назад. В 14 - полагаю, тоже.
Починили 10 дней назад :)
> Теперь выпустили 4.14 с некорректными значениями частоты в /proc/cpuinfo??? А точно не наоборот? :)
_____________________
10 days ago
Commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for
/proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous
behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes
made after the commit it has reverted.To address this, make the code in question use arch_freq_get_on_cpu()
which also is used by cpufreq for reporting the current frequency of
CPUs and since that function doesn't really depend on cpufreq in any
way, drop the CONFIG_CPU_FREQ dependency for the object file
containing it.Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and
return cached values right away if it is called very often over a
short time (to prevent user space from triggering IPI storms through
it).Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"")
Cc: stable@kernel.org # 4.13 - together with 890da9cf0983
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ??? А точно не наоборот? :)точно
_____________________4 days ago
Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"
This reverts commit 941f5f0f6ef5338814145cf2b813cf1f98873e2f.Sadly, it turns out that we really can't just do the cross-CPU IPI to
all CPU's to get their proper frequencies, because it's much too
expensive on systems with lots of cores.So we'll have to revert this for now, and revisit it using a smarter
model (probably doing one system-wide IPI at open time, and doing all
the frequency calculations in parallel).Reported-by: WANG Chao <chao.wang@ucloud.cn>
Reported-by: Ingo Molnar <mingo@kernel.org>
Cc: Rafael J Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Да, но (сейчас точно не вспомню с какого RC) текущие частоты во всех привычных программах снова отображаются :)
>Ну разве что только поржать над BTRFS, который как Пресли, Ленин или *BSD -- давно мертв, но некотрые вздыхают и говорят "жив!"Единственное шо мертво это ум у автора цытаты, по этому освободившееся место приходится заполнять ржачем, шобы не расплющило атмосферным давлением. xD
BTRFS отличная ФС для HDD, а возможность мгновенного бекапа на уровне ФС делает ее незаменимой в мире случайно ломающихся дистрибутивов от громкого чиха не в ту сторону.
>делает ее незаменимой в мире случайно ломающихся дистрибутивов от громкого чиха не в ту сторонуНе умнее ли поменять дистриб?
>Не умнее ли поменять дистриб?Как будто существует дистрибутив который невозможно сломать. :D
Тут токо squashfs корня поможет.
> Как будто существует дистрибутив который невозможно сломать. :D
> Тут токо squashfs корня поможет.От dd в блочный девайс не спасет.
>От dd в блочный девайс не спасет.Ну тут и BTRFS не спасет, нужна TANKFS с противокумулятивноdd защитой. :D
> Ну тут и BTRFS не спасет, нужна TANKFS с противокумулятивноdd защитой. :DМожно блочный девайс ридонли сделать. Ты стреляешь, но снаряд куда-то проебывается и тебе сообщают что ты не можешь нанести вред.
> Не умнее ли поменять дистриб?Не, в таких случаях надо прокладку менять.
ECC RAM уже купил?
Btrfs в этом не нуждается
> Btrfs в этом не нуждаетсяВ этом нуждается любая система с повышенными требованиями к надежности. Если ты попросишь файловую систему записать тебе мусор, потому что память уже разрушена - потом ты и прочитаешь мусор. Правильные чексумы и избыточность будут посчитаны для этого мусора и радости от того что чексумма правильная и записано дважды будет мало. Потому что это не то что ты хотел записать.
>В этом нуждается любая система с повышенными требованиями к надежности. Если ты попросишь файловую систему записать тебе мусор, потому что память уже разрушена - потом ты и прочитаешь мусор.Ну тогда и минимум RAID 1 нужен + ИБП... иии никакого разгона. :D
А то пользы без всего этого от ECC RAM как от бронестекла при аварии автомобиля.
> Ну тогда и минимум RAID 1 нужен + ИБП...Хуже от них не станет. Лучше - зависит от ситуации.
> иии никакого разгона. :D
Разгоняльщиков надежность не интересует.
> А то пользы без всего этого от ECC RAM как от бронестекла при аварии автомобиля.
Скорее как от системы диагностики тормозов.
>>Ну разве что только поржать над BTRFS, который как Пресли, Ленин или *BSD -- давно мертв, но некотрые вздыхают и говорят "жив!"
> Единственное шо мертво это ум у автора цытаты, по этому освободившееся место
> приходится заполнять ржачем, шобы не расплющило атмосферным давлением. xD
> BTRFS отличная ФС для HDD, а возможность мгновенного бекапа на уровне ФС
> делает ее незаменимой в мире случайно ломающихся дистрибутивов от громкого чиха
> не в ту сторону.Moжет для единственного диска она и хороша, но как жить в боевых системах без multipath'инга я не очень представляю. Пока делаем костыли на программном РАЙДе.
> возможность мгновенного бекапа на уровне ФС делает ее незаменимойСнапшот это не бекап.
Любой жив, пока он востребован. Вы же мертвы уже при жизни.
> Тоска. Ничего интересного. Ну разве что только поржать над BTRFS, который как
> Пресли, Ленин или *BSD -- давно мертв, но некотрые вздыхают и говорят "жив!"Может ты и фэйсбук заодно похоронил?
факинбук не хранит на btrfs ценных данных, в этом вся разница. Если завтра половина твоих котиков накроется - тебя отправят читать service agreement, где черным по белом написано что твои данные больше не твои, но ответственность за них все равно никто не несет.
> факинбук не хранит на btrfs ценных данных, в этом вся разница. Если
> завтра половина твоих котиков накроется - тебя отправят читать service agreement,
> где черным по белом написано что твои данные больше не твои,
> но ответственность за них все равно никто не несет.Зато их храню я и за несколько лет оно не подводило по крупному. А еще:
1) С btrfs с их инструментами, если что, вытаскивать данные с ФС более перспективно чем с многих других ФС. Потому что есть user-mode парсер, умеющий к тому же якориться за "ревизию" (generation) ФС и плясать оттуда, вытаскивая файлы и не меняя состояние ФС вообще. Это позволяет вычитать много файлов даже с подубитой ФС. Ну там если HDD пошел бэдами и избыточности не было, например.
2) На однодисковом хранилище по дефолту метаданные пишутся 2 раза. В случае если "HDD пошел бэдами" и проч это очень полезно для доступности файлов и возможности осмысленного разбора ФС. Остальные могут очень сильно сдохнуть если бэд попал на метаданные и с этим ничего не сделаешь вообще. Устроены они так.
3) Чексумы данных и метаданных позволяют замечать явные проблемы оборудования ДО того как половина файлов превратится в труху.
А если какой-нибудь ext4 или XFS развалится до немоунтабельного состояния и fsck не исправит - ты резко пойдешь хексэдитором файлы доставать. Не говоря о том что то что файлы развалились ты узнаешь сильно потом. Нет, есть ZFS но у него своих проблем есть и к тому же он внебрачный. Так что если его на рутфс поставить - наверняка очень весело остаться без рутфс после обновления ядра.
>*BSD -- давно мертвЗавезите сначала хоть какую-нибудь нормальную CoW FS, да научите ваш эмулятор терминала-переросток отдавать с одного сервера 100Гбит шифрованного трафика - вот тогда поговорим о мавзолеях и Ленине.
> Из основного ядра в репозиторий linux-firmware вынесен набор прошивок,
> ранее поставляемых в каталоге "firmware/".Их бы там ещё структурировать, как ядерные драйверы пару лет тому назад... чтоб на подпакеты рубить можно было по подкаталогам, а не с будкой.
> чтоб на подпакеты рубить можно было по подкаталогам, а не с
> будкой.что значит с будкой?
Анекдот такой. "Колбаса по-чапаевски: мясо, нарубленное крупными кусками, ...вместе с будкой"
>> чтоб на подпакеты рубить можно было по подкаталогам, а не с будкой.
> что значит с будкой?Сравните структуру каталогов верхнего уровня фирмварей и ядерных драйверов (где вообще куча файлов прям в корне и валяется, помимо ad hoc вместо структуры):
[mike@basalt firmware-linux]$ ls -d */
3com/ carl9170fw/ imx/ netronome/ sb16/
acenic/ cavium/ intel/ nouveau/ slicoss/
adaptec/ cis/ isci/ nvidia/ sun/
advansys/ cpia2/ kaweth/ ositech/ sxg/
amdgpu/ cxgb3/ keyspan/ qca/ tehuti/
amd-ucode/ cxgb4/ keyspan_pda/ qcom/ ti-connectivity/
ar3k/ dabusb/ korg/ qed/ tigon/
ath10k/ dsp56k/ libertas/ qlogic/ ti-keystone/
ath6k/ e100/ liquidio/ r128/ ttusb-budget/
ath9k_htc/ edgeport/ matrox/ radeon/ ueagle-atm/
atmel/ emi26/ mellanox/ rockchip/ usbdux/
atusb/ emi62/ moxa/ rsi/ vicam/
av7110/ ene-ub6250/ mrvl/ RTL8192E/ vxge/
bnx2/ ess/ mwl8k/ rtl_bt/ yam/
bnx2x/ go7007/ mwlwifi/ rtl_nic/ yamaha/
brcm/ i915/ myricom/ rtlwifi/[mike@basalt drivers]$ ls
accessibility dca iio mmc pwm thermal
acpi devfreq infiniband mtd rapidio thunderbolt
amba dio input net ras tty
android dma iommu nfc regulator uio
ata dma-buf ipack ntb remoteproc usb
atm edac irqchip nubus reset uwb
auxdisplay eisa isdn of rpmsg vfio
base extcon Kconfig oprofile rtc vhost
bcma firewire leds parisc s390 video
block firmware lguest parport sbus virt
bluetooth fmc macintosh pci scsi virtio
bus gpio mailbox pcmcia sfi vlynq
cdrom gpu Makefile phy sh vme
char hid mcb pinctrl sn w1
clk hsi md platform soc watchdog
clocksource hv media pnp spi xen
connector hwmon memory power spmi zorro
coresight hwspinlock memstick powercap ssb
cpufreq i2c message pps staging
cpuidle ide mfd ps3 target
crypto idle misc ptp tc
> Их бы там ещё структурировать, как ядерные драйверы пару лет тому назад... чтоб на подпакеты рубить можно было по подкаталогам, а не с будкой.Киньте исправление туда, но так чтобы ничего не сломалось у прочих.
>> Их бы там ещё структурировать, как ядерные драйверы пару лет тому назад...
>> чтоб на подпакеты рубить можно было по подкаталогам, а не с будкой.
> Киньте исправление туда, но так чтобы ничего не сломалось у прочих.Так эт вникать надо. Можно, но у меня сейчас совсем другое всё рабочее время занимает: http://sdelanounas.ru/blogs/100183/
PS: про "тебе надо -- ты и делай" понимаю и поддерживаю :-)
> Так эт вникать надо.Вникать нужно всегда если ты в IT, либо привлекать незанятых работников в вашем случае. Если все заняты, тогда посмотрим что сообщество сделает. (Ответ от чайников "...", от "поумнее" "делайте сами", от "шибко умных" "не моих рук дело", от умелых "посмотрим что можно сделать", от "совсем" умных "всё сломать и перестроить".)
> Вникать нужно всегда если ты в ITУроки информатики - это не "в IT".
> Так эт вникать надо."Это что, еще и работать надо?!"
> всё рабочее время занимает: http://sdelanounas.ru/blogs/100183/
Даже компилера открытого нет. До такой наглости даже какой-нибудь квалком проприетарный не докатывается.
> Даже компилера открытого нет.А должен быть? VLIW без компилера в принципе быть не может. Эльбрус - VLIW. Следовательно, компилер поставляется вместе с CPU, как ПАК.
> До такой наглости даже какой-нибудь квалком проприетарный не докатывается.В чём наглость?
> А должен быть? VLIW без компилера в принципе быть не может.Много вокруг себя VLIW видишь? То-то и оно.
> Следовательно, компилер поставляется вместе с CPU, как ПАК.
Удачи в продажах этого.
> В чём наглость?
Коменты по той ссылке почитай.
>> всё рабочее время занимает: http://sdelanounas.ru/blogs/100183/
> Даже компилера открытого нет. До такой наглости даже какой-нибудь квалком проприетарный
> не докатывается.А интел(*) -- вполне: вона Микаэль вовсю пиарит ClearOS, собранный с icc.
Если бы :/ это что-то доказывало или о чём-то говорило.
Предположил бы, что всякие цпу-"меншинства" (tilera, openrisc, riscv?), так же мучаются.
(*)Впрочем, для интела _есть_ и gcc, и llvm, и все-все-все. Ничего, вот мсцт подрастёт... "немного" %) , и тогда-а-а... #Заживём #МонополистНаш
> А интел(*) -- вполне: вона Микаэль вовсю пиарит ClearOS, собранный с icc.Странно что итаник не вспомнили, он сразу после tablet PC в списке ачивок.
> Предположил бы, что всякие цпу-"меншинства" (tilera, openrisc, riscv?), так же мучаются.
Под них есть gcc и/или clang. Иначе как ими пользоваться?
> http://sdelanounas.ru
> "У нас есть чем гордиться"Если оставить за рамками любимую современную безграмотность в заголовках, то другой вопрос: что за рефлексия такая? Почему не ссылки на блоги обычных парней-разработчиков на hackerne.ws , например, а, непременно, громкие слова на местечковом standalone? По-моему такая сугубо техническая интересная статья достойна популярных читаемых площадок, а не соседства с сомнительными статьями о надоях
Популярных площадок этот трэш будет достоен не раньше чем проц можно будет купить по вменяемой цене и потом нормально им пользоваться. Т.е. поддержка в mainline и компиляторах как минимум. Но судя по тенденциям, рак на горе устанет свистеть намного раньше. А до тех пор этому самое место в таком местечковом хламежнике как раз, рядом с надоями.
> Их бы там ещё структурировать, как ядерные драйверы пару лет тому назад... чтоб на подпакеты рубить можно было по подкаталогам, а не с будкой.Я думаю, это сложно, т. к. тогда сломается совместимость со старыми ядрами. В модулях же жестко зашит путь до фирмвари относительно каталога с фирмварью.
> Из-за невостребованности и отсутствия сопровождающегооппа... Расти - всё?
Вот так всегда, об интересных фишках узнаешь из списка того что было удалено
Раньше нововведения были эпичные и долгожданные.. А теперь.. Оно просто работает и все есть.. и новшества кажутся мелкими и не значительными. Стоит радоваться. Исключение только Nouveau.
> Раньше нововведения были эпичные и долгожданные..Ловите эпичное, ещё год вам траху Попов и Торвальдц подогнали:
- structleak: add option to force initialize all struct type variables passed by reference
- randstruct: Enable function pointer struct detection
Чем нам это грозит, расскажите?
> Чем нам это грозит, расскажите?Следите за анонсами CVE
В ядре станет ещё меньше багов? А что в этом плохого?
Ну, в следующее, если Лиус не пошлёт, прилетит наконец DC от AMD прилетит... А так - LTS, тут особо интересного ждать не приходится.
Заведи RAID под BTRFS и будет тебе эпическое и долгожданное нововведение в новости.
Раньше нововведения касались обычных пользователей. Потом - корпораций.
> Раньше нововведения были эпичные и долгожданные..Небо голубее, трава забористее, джой-стик тверже и всегда готовым к бою..
> А теперь..
> Подсистема драйверов IRDA (поддержка инфракрасного порта) перемещена в ветку staging с целью дальнейшего удаления из ядра (драйвер на уровне ядра не востребован, так как все приложения используют реализацию в пространстве пользователя);LIRC к IrDA имеет слабое отношение. Первый про инфракрасные пульты, второй про инфракрасные передатчики (которые, например, встречались лет 10 назад в телефонах). Там даже протоколы разные, и LIRC ядерному IrDA не замена.
> Там даже протоколы разные, и LIRC ядерному IrDA не замена.Быстрее и легче открыть usb-порт и писать туда свои байтики,
нежели постоянно мониторить сюрпризы API ядра, и круглые сутки
патчить дрова для своих IR приборов.
Если ядерный irda еще и не поддерживается никем, то разумеется, легче. Но от этого бред от переводчика в новости про то, что lirc - юзерспейсная реализация irda, бредом быть не перестает
Блоб-384.90
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/common/inc/nvmisc.h 384.90/kernel/common/inc/nvmisc.h
--- NVIDIA-Linux-x86_64-384.90/kernel/common/inc/nvmisc.h 2017-09-20 04:33:10.000000000 +0300
+++ 384.90/kernel/common/inc/nvmisc.h 2017-11-13 02:29:23.063790152 +0300
@@ -53,6 +53,7 @@ extern "C" {
//
// Miscellaneous macros useful for bit field manipulations
//
+#undef BIT
#define BIT(b) (1<<(b))
#define BIT32(b) ((NvU32)1<<(b))
#define BIT64(b) ((NvU64)1<<(b))
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv.c 384.90/kernel/nvidia/nv.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv.c 2017-09-20 04:33:09.000000000 +0300
+++ 384.90/kernel/nvidia/nv.c 2017-10-02 03:45:21.001709217 +0300
@@ -38,7 +38,7 @@
#if (NV_BUILD_MODULE_INSTANCES != 0)
#if defined(MODULE_LICENSE)
-MODULE_LICENSE("NVIDIA");
+MODULE_LICENSE("GPLv2");
#endif
#if defined(MODULE_INFO)
MODULE_INFO(supported, "external");
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv-frontend.c 384.90/kernel/nvidia/nv-frontend.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv-frontend.c 2017-09-20 04:33:10.000000000 +0300
+++ 384.90/kernel/nvidia/nv-frontend.c 2017-10-02 03:45:21.008707347 +0300
@@ -15,7 +15,7 @@
#include "nv-frontend.h"
#if defined(MODULE_LICENSE)
-MODULE_LICENSE("NVIDIA");
+MODULE_LICENSE("GPLv2");
#endif
#if defined(MODULE_INFO)
MODULE_INFO(supported, "external");
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv-gpu-numa.c 384.90/kernel/nvidia/nv-gpu-numa.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia/nv-gpu-numa.c 2017-09-20 04:33:09.000000000 +0300
+++ 384.90/kernel/nvidia/nv-gpu-numa.c 2017-11-13 02:28:19.730516708 +0300
@@ -111,7 +111,7 @@ static NV_STATUS bad_idea_read_string_fr
size_t read_buffer_size)
{
struct file *filp;
- int read_count;
+ ssize_t read_count;
filp = filp_open(path_to_file, O_RDONLY, 0);
if (IS_ERR(filp))
@@ -120,7 +120,7 @@ static NV_STATUS bad_idea_read_string_fr
return NV_ERR_NO_VALID_PATH;
}
- read_count = kernel_read(filp, 0, read_buffer, read_buffer_size - 1);
+ read_count = kernel_read(filp, (void *)read_buffer, read_buffer_size - 1, 0);
filp_close(filp, NULL);
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-crtc.c 384.90/kernel/nvidia-drm/nvidia-drm-crtc.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-crtc.c 2017-09-20 04:33:13.000000000 +0300
+++ 384.90/kernel/nvidia-drm/nvidia-drm-crtc.c 2017-11-13 02:31:54.897292978 +0300
@@ -162,7 +162,7 @@ static void nvidia_crtc_disable(struct d
}
-static void nvidia_crtc_enable(struct drm_crtc *crtc)
+static void nvidia_crtc_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
}
@@ -170,7 +170,7 @@ static void nvidia_crtc_enable(struct dr
static const struct drm_crtc_helper_funcs nv_crtc_helper_funcs = {
.prepare = nvidia_crtc_prepare,
.commit = nvidia_crtc_commit,
- .enable = nvidia_crtc_enable,
+ .atomic_enable = nvidia_crtc_enable,
.disable = nvidia_crtc_disable,
.mode_fixup = nvidia_crtc_mode_fixup,
};
@@ -220,10 +220,9 @@ static struct drm_plane *nvidia_plane_cr
dev,
plane, crtc_mask, funcs,
formats, formats_count,
+ NULL,
plane_type
-#if defined(NV_DRM_INIT_FUNCTIONS_HAVE_NAME_ARG)
, NULL
-#endif
);
if (ret != 0)
@@ -349,9 +348,7 @@ struct drm_crtc *nvidia_drm_add_crtc(str
&nv_crtc->base,
primary_plane, cursor_plane,
&nv_crtc_funcs
-#if defined(NV_DRM_INIT_FUNCTIONS_HAVE_NAME_ARG)
, NULL
-#endif
);
if (ret != 0)
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-encoder.c 384.90/kernel/nvidia-drm/nvidia-drm-encoder.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-encoder.c 2017-09-20 04:33:13.000000000 +0300
+++ 384.90/kernel/nvidia-drm/nvidia-drm-encoder.c 2017-10-02 03:42:52.110505816 +0300
@@ -150,9 +150,7 @@ nvidia_encoder_new(struct drm_device *de
ret = drm_encoder_init(dev,
&nv_encoder->base, &nv_encoder_funcs,
nvkms_connector_signal_to_drm_encoder_signal(format)
-#if defined(NV_DRM_INIT_FUNCTIONS_HAVE_NAME_ARG)
, NULL
-#endif
);
if (ret != 0)
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-linux.c 384.90/kernel/nvidia-drm/nvidia-drm-linux.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-drm/nvidia-drm-linux.c 2017-09-20 04:33:13.000000000 +0300
+++ 384.90/kernel/nvidia-drm/nvidia-drm-linux.c 2017-10-02 03:45:21.031701200 +0300
@@ -185,7 +185,7 @@ module_init(nv_linux_drm_init);
module_exit(nv_linux_drm_exit);
#if defined(MODULE_LICENSE)
- MODULE_LICENSE("MIT");
+ MODULE_LICENSE("GPLv2");
#endif
#if defined(MODULE_INFO)
MODULE_INFO(supported, "external");
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nvidia-modeset-linux.c 384.90/kernel/nvidia-modeset/nvidia-modeset-linux.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-modeset/nvidia-modeset-linux.c 2017-09-20 04:33:12.000000000 +0300
+++ 384.90/kernel/nvidia-modeset/nvidia-modeset-linux.c 2017-10-02 03:46:56.059301612 +0300
@@ -343,8 +343,8 @@ static void nvkms_resume(NvU32 gpuId)
static nvidia_modeset_rm_ops_t __rm_ops = { 0 };
static nvidia_modeset_callbacks_t nvkms_rm_callbacks = {
- nvkms_suspend,
- nvkms_resume
+ .suspend = nvkms_suspend,
+ .resume = nvkms_resume
};
static int nvkms_alloc_rm(void)
@@ -1309,7 +1309,7 @@ module_init(nvkms_init);
module_exit(nvkms_exit);
#if defined(MODULE_LICENSE)
- MODULE_LICENSE("NVIDIA");
+ MODULE_LICENSE("GPLv2");
#endif
#if defined(MODULE_INFO)
MODULE_INFO(supported, "external");
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm/uvm_common.c 384.90/kernel/nvidia-uvm/uvm_common.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm/uvm_common.c 2017-09-20 04:33:10.000000000 +0300
+++ 384.90/kernel/nvidia-uvm/uvm_common.c 2017-10-02 03:45:21.011706545 +0300
@@ -388,5 +388,5 @@ module_param(uvm_enable_builtin_tests, i
MODULE_PARM_DESC(uvm_enable_builtin_tests,
"Enable the UVM built-in tests. (This is a security risk)");
-MODULE_LICENSE("MIT");
+MODULE_LICENSE("GPLv2");
MODULE_INFO(supported, "external");
diff -urp NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm/uvm_unsupported.c 384.90/kernel/nvidia-uvm/uvm_unsupported.c
--- NVIDIA-Linux-x86_64-384.90/kernel/nvidia-uvm/uvm_unsupported.c 2017-09-20 04:33:10.000000000 +0300
+++ 384.90/kernel/nvidia-uvm/uvm_unsupported.c 2017-10-02 03:45:21.014705743 +0300
@@ -171,6 +171,6 @@ static void __exit uvm_unsupported_exit(
module_init(uvm_unsupported_module_init);
module_exit(uvm_unsupported_exit);
-MODULE_LICENSE("MIT");
+MODULE_LICENSE("GPLv2");
MODULE_INFO(supported, "external");
Упс, не увидел, что 384.98 вышло.
Ну и на кой здесь этот флуд?
> Ну и на кой здесь этот флуд?Наверное у него патч в майнлайн не приняли. Абыдна, да?!
Вижу что NVIDIA внедряет свой патч туда чтобы могла много non-NVIDIA видюшек.
+ В этом вижу некоторую угрозу безопасности, однако, сейчас это делают для пользователей Embedded Linux. (Если что-то неверно, простите.)
> Вижу что NVIDIA внедряет свой патч туда чтобы могла много non-NVIDIA видюшек.
> + В этом вижу некоторую угрозу безопасности,99% работающих пользователей делают свою работу, им нужна стабильность и скорость.
> 99% работающих пользователей делают свою работу, им нужна стабильность и скорость.И все это - не про непонятно чьи блобы, разрабатываемые вне ядра.
> -MODULE_LICENSE("NVIDIA");
> +MODULE_LICENSE("GPLv2");Да ты хакир!!! А можешь винду так же?
>> -MODULE_LICENSE("NVIDIA");
>> +MODULE_LICENSE("GPLv2");
> Да ты хакир!!! А можешь винду так же?Что тебя удивляет? Арчешколота всегда так "патчит".
> Что тебя удивляет?Удивляет то что человек хвалит нвидию и расхваливает ее работу, попутно накатывая за нвидией какие-то внебрачные патчи, сам же иллюстрируя как именно он работает. Забесплатно подчищая срань за нвидией.
> Арчешкoлота всегда так "патчит".
Павлинукс вроде достаточно древний.
>> Что тебя удивляет?
> Удивляет то что человек хвалит нвидию и расхваливает ее работу, попутно накатывая
> за нвидией какие-то внебрачные патчи, сам же иллюстрируя как именно онбольшая часть этого патча - заставить ведро линукса не визжать как резанное что оно грязное-блобное-нихачюнибуду. А нвидия, вот, соблюдает во вред себе ненужный политес.
а ты ведь даже этого не знаешь и не понимаешь, но критиковать полез?
> работает. Забесплатно подчищая срань за нвидией.
за рукожопыми линуксерами. Без конца старательно ломающими API, и не забесплатно, а на бабки корпораций.
Об этом вся остальная часть патча, кроме, может, единственной строчки. Кстати, подозрительной. Я бы посмотрел, что это за "BIT" и откуда он такой взялся.но вы продолжайте распространять FUD, у вас хорошо получается.
А у вас очко подгорело...
> большая часть этого патча - заставить ведро линукса не визжать как резанное
> что оно грязное-блобное-нихачюнибуду.А смысл? Разработчиков ядра патчем не заменишь.
> А нвидия, вот, соблюдает во вред себе ненужный политес.
Политес будет когда что-то не заработает как надо. Разработчики покажут факи и ты пойдешь майнтайнить такое ядро сам, на пару с павлином и нвидией.
> а ты ведь даже этого не знаешь и не понимаешь, но критиковать полез?
А я понимаю что команда разработчиков не заменяется ламерским патчем.
> за рукожопыми линуксерами. Без конца старательно ломающими API, и не забесплатно, а
> на бабки корпораций.Можешь потребовать деньги назад и перейти на другую ОС. Можно подумать тебя заставляют.
> Об этом вся остальная часть патча, кроме, может, единственной строчки. Кстати, подозрительной.
Аяй-яй-яй, павлин пытается бэкдоры в исходниках раздавать.
> Я бы посмотрел, что это за "BIT" и откуда он такой взялся.BIT обычно кернельный макрос для выставления нужного бита, что актуально для работы с оборудованием. Но что тут - сами разбирайтесь, мне эти художества интересны только как научный курьез.
> но вы продолжайте распространять FUD, у вас хорошо получается.
FUD, не FUD, а команда разработчиков - круче павлинукса и поха.
> Забесплатно подчищая//Если в коде ядра каждые три дня менять схемы лицензирования модулей -- нас никогда и никто не догонит :))
> Да ты хакир!!!А, наверное, можно было бы и такой патч состряпать, который перелицензировал всё ядро хоть под Microsoft, хоть под NVidia (для личного пользования...))
Под VMware® Workstation 14 Pro тут: https://communities.vmware.com/thread/573209
или тут https://github.com/pavlinux/vmware-modules/tree/master/14.0....
Ути-тю. Какой любитель зондов.
- PKT_FIELD(vsk, writeNotifyWindow) = PAGE_SIZE;
- PKT_FIELD(vsk, writeNotifyMinWindow) = PAGE_SIZE;
- PKT_FIELD(vsk, peerWaitingWrite) = FALSE;
+ PKT_FIELD(vsk, writeNotifyWindow) = PAGE_SIZE;
+ PKT_FIELD(vsk, writeNotifyMinWindow) = PAGE_SIZE;
+ PKT_FIELD(vsk, peerWaitingWrite) = FALSE;
PKT_FIELD(vsk, peerWaitingWriteDetected) = FALSE;зачем ты так делаешь в _не_своем_ коде?
ZSTD понравился.
> ZSTD понравился.Бенчи уже погоняли?
> Бенчи уже погоняли?Да. Если вкратце: жмет немного хуже LZMA, но по скорости распаковки делает в разы gzip. EPIC WIN. А так еще Lizard есть. Жмет еще чуть похуже, но в некоторых режимах распаковывается аж быстрее чем LZ4. И это без asm, simd и avx, чистый си.
> - Поддержка звуковых кодеков Realtek RT274, Wolfson Microelectronics WM8524 и Cirrus
> Logic CS43130;Подскажите (с целью повышения уровня образованности), а на каких юзеродоступных платах водятся циррусы и вольфсоны? А то кругом один рыгалтек, куда не глянь. (Читал давно, что вольфсоны вроде бы в айфонах использовались).
> Подскажите (с целью повышения уровня образованности), а на каких юзеродоступных платах
> водятся циррусы и вольфсоны?У меня на звуковой плате с VT1720/24 стоит уж не помню сходу какой, стерео/24 через него.
Я даже не сомневался, что у тебя он!
https://www.ebay.com/sch/items/?_nkw=vt1720&_sacat=&_ex_kw=&...
И каким концом куда?
На топовых. Но дискретным решениям они не конкуренты.
>>а на каких юзеродоступных платах водятся циррусыAmiga One, маки
> В ext4 увеличена масштабируемость при выделении места под inode. Обеспечена обратная совместимость с реализацией ea_inode из ФС Lustre;За одно увеличили в 3 раза количество random seek. Отличная победа лобирования со стороны Андреаса, вместо того что бы сделать 1 раз нормальную реализацию - он пролобировал написанный индусами на коленке код. "Не выкидывать же" "у нас он уже есть, поэтому новая реализация будет конфликтовать с текущей"
Да и чёрт с ним. Кому нужна приличная ФС - сто лет как на XFS сбежали, с редхатом во главе...
А можно немного подробностей или где об этом почитать?
в рассылке ext4-devel. Там было объяснение почему не стоит брать в ядро ea_inode.
если кратко - для хранения больших EA используется дополнительная inode, что взывает проблемы с увеличенным количеством кредитов при удалении / добавлении данных в EA, требует дополнительный seek хрен знает куда - когда вдруг в ближайшей группе не нашлось свободной inode. Не считая забавных deadlock в прошлом.
Но.. что не сделаешь ради старого друга который просит. Вот и приняли эту хрень в ядро.
Это как-то отключается?
так не используй EA - оно и не включится.
HMM, вот если бы наоборот, можно было бы расширить ОЗУ за счёт набортной памяти дискретной видеоплаты, было бы практичней.
То есть сейчас можно расширить видеопамять за счёт системной ОЗУ?
С разморозкой!
> В подсистему GRE (Generic Routing Encapsulation) добавлена поддержка второго > типа туннелей ERSPAN, которые могут использоваться для приёма или > перенаправления трафика с данными мониторинга от коммутаторов Cisco;Хорошая новость, однако.
А мой первый патчик только в следующую версию ядра попадёт. пИчалька
> А мой первый патчик только в следующую версию ядра попадёт. пИчалькаПочему пичалька? Скажи sha коммита, может уже прилетело?
Не, проверял. Будет только в 4.15
> Не, проверял. Будет только в 4.15Проверял что? Окно коммитов уже открыто, в mainline могло прилететь уже.
А он, случайно, в firefox-58b3 не попал уже? :))
а шо на Raspberry Pi опять невнятные улучшения и добавления чего то, вместо того что бы видеодравер наконец нормально прикрутить?
> а шо на Raspberry Pi опять невнятные улучшения и добавления чего
> то, вместо того что бы видеодравер наконец нормально прикрутить?Броадком снялся с тормоза и вообще поддержку в майнлайн добавили пару ядер назад. До этого там вообще все работало только с левыми патчеными ядрами.
Ну когда уже сделают звук для BayTrail и CharyTrail из под коробки? Знаю, что есть патчи, но их ещё ни в одной сборке ни одного дистрибутива нет(
Не помню, но вроде на ядре 4.11 или 4.12 у меня звук работал на недобуке с BayTrail в ROSA.
"В F2FS добавлена поддержка обычных и журналируемых квот, добавлены ioctl F2FS_IOC_FS{GET,SET}XATTR, обеспечена возможность хранения контрольных сумм для inode; "Удивительно, разработчик F2FS свои патчи в ядро засунуть может, а в GRUB2 до сих пор как не поддержки так и предвидится.
> Удивительно, разработчик F2FS свои патчи в ядро засунуть может, а в GRUB2
> до сих пор как не поддержки так и предвидится.Зато в uboot уже есть. И половина андроидов ей пользуется. Все-таки GRUB2 стартующий чего-то типа SD или eMMC - немного экзотика. А вот uboot делающие так - в порядке вещей. Отсюда и приоритеты.
Небольшая поправочка: 5-уровневые таблицы трансляции - это 57-битная (а не 56-битная) виртуальная адресация. +1 уровень таблиц == +9 бит виртуального адреса. Сейчас он 48 (9+9+9+9+12 = 4х9+12 = 48), будет 57 (9+9+9+9+9+12 = 5х9+12 = 57) https://software.intel.com/sites/default/files/managed/2b/80...