URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 110507
[ Назад ]

Исходное сообщение
"Релиз ядра Linux 4.10"

Отправлено opennews , 20-Фев-17 07:16 
После двух месяцев разработки Линус Торвальдс представил (https://lkml.org/lkml/2017/2/19/224) релиз ядра Linux 4.10 (https://kernel.org/).

В новую версию принято около 13 тысяч исправлений от 1647 разработчиков,
размер патча - 50 Мб (изменения затронули 11674 файлов, добавлено 743994 строк кода, удалено 249421 строк). Около 47% всех представленных в 4.10 изменений связаны с драйверами устройств, примерно 17% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 15% связано с сетевым стеком, 4% - файловыми системами и 5% c внутренними подсистемами ядра. 13.7% изменений внесено сотрудниками компании Intel,  7.1% изменений подготовлено сотрудниками Red Hat, 4.3% - Samsung, 3.9% - Linaro, 3.7% - SUSE, 3.0% - IBM, 2.5% - AMD, 2.4% - Google, 1.4% - Oracle, 1.4% - ARM.

Основные (http://kernelnewbies.org/Linux_4.10) новшества (https://lwn.net/Articles/710493/):

-  
Дисковая подсистема, ввод/вывод и файловые системы


-  Интегрированы патчи с улучшенной реализацией механизма фонового сброса данных на накопитель, решающие проблемы с подвисаниями во время фонового копирования данных на медленный USB-накопитель. На системах с большим объёмом ОЗУ и медленными устройствами ввода/вывода переносимые на накопитель данные буферизируются в кэше обратной записи и копирование завершается в фоне. Ранее, операции сброса кэша обратной записи приводили к существенному снижению отзывчивости интерфейса приложений, подобных Firefox, вплоть до невозможности нормальной работы в течение нескольких минут. Например, выполнение "dd if=/dev/zero of=foo bs=1M count=10k" или копирование большого файла на USB-накопитель не давало запустить браузер или любое крупное приложение пока оставался не сброшен кэш обратной записи.


Предложенный (https://lwn.net/Articles/682582/) в новом ядре режим "writeback throttling" решает указанную проблему благодаря урезанию интенсивности очистки кэша при наличии в очереди других операций ввода/вывода, что не затрудняет монополизирование очереди ввода/вывода операциями интенсивной записи. Алгоритм урезания отслеживает появление задержек и изменение размера очереди, автоматически корректируя параметры для достижения оптимального результата.  В итоге удалось решить проблемы с отзывчивостью за счёт незначительного увеличения времени сброса данных из кэша;

-  В подсистему MD RAID добавлена поддержка флага failfast, который может быть привязан к дискам в процессе создания массивов RAID1 или RAID10, и активирует режим быстрого перевода устройства в режим сбоя. В случае неудачного завершения операции ввода/вывода диск будет сразу выведен из массива, без проведения полноценной обработки ошибки и повторных попыток проведения операции чтения.

-  В  MD RAID также реализован кэш обратной записи для RAID5, позволяющий агрегировать операции записи для последующей единовременной записи блока чётности, что позволяет добиться повышения производительности в условиях последовательной записи данных с дальнейшим выполнением операции fsync;


-  В дополнение к появившейся в ядре 4.4 (https://www.opennet.me/opennews/art.shtml?num=43652) поддержке поллинга ввода/вывода для блочных устройств (I/O polling), в новой версии представлен режим гибридного адаптивного поллинга для блочных устройств. Поллинг позволяет уменьшить нагрузку на систему при использовании высокопроизводительных устройств за счёт периодического опроса состояния вместо генерации прерываний, при этом эффективность  поллинга высока только при высокой нагрузке, иначе затраты ресурсов CPU на периодический опрос могут привышать затраты на обработку прерываний. Гибридный режим, вместо выполнения поллинга после завершения операции ввода/вывода, выполняет поллинг через искусственную задержку (например, если операция ввода/вывода длится 8 мкс, то опрос инициируется через 4 мкс), что позволяет подогнать цикл
пробуждения ко времени до завершения операции, а не пробудиться после. Данный подход позволяет значительно сократить задержки без повышения нагрузки на CPU. По умолчанию гибридный режим отключен и для активации требует  установки (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) параметра /sys/block/{dev}/queue/io_poll_delay;

-  В файловую систему UBIFS, предназначенной для использования на Flash-накопителях,  добавлена (https://git.kernel.org/torvalds/c/39d2c3b96e072c8756f3b98058...) поддержка шифрования;

-  В файловой системе Ext4 добавлена защита (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) от включения режима журналирования данных для зашифрованных разделов (функции журналирования и шифрования данных не совместимы, но ранее могли быть активированы вместе из-за ошибки в настройках);
-  В XFS реализован более быстрый метод поиска в используемых для кэша буферах, для прямого ввода/вывода (Direct I/O) задействован  iomap, объявлены устаревшими опции монтирования barrier/nobarrier;


-  В CIFS добавлена новая опция монтирования "snapshot=время", позволяющая примонтировать прошлую версию внешнего раздела;

-  В F2FS, развиваемой компанией Samsung высокопроизводительной файловой системе для Flash-накопителей, появилась возможность объединения (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) нескольких устройств в рамках одного большого виртуального раздела с одним экземпляром F2FS;

-  Из состава ядра удалена (https://git.kernel.org/torvalds/c/1d0fd57a50aa372dd2e84b1671...) файловая система logfs (https://www.opennet.me/opennews/art.shtml?num=25716), которая несколько лет находится без сопровождения и на практике не используется;

-  Добавлена (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....) поддержка высокоприоритетных команд ATA, передаваемых устройству вне очереди. По умолчанию данный режим отключен;

-  
Виртуализация и безопасность

-  На системах с прошивками EFI ядро получило возможность сохранять некоторые случайные данные в виде EFI-переменных и затем на этапе загрузки использовать их для инициализации генератора псевдослучайных чисел. Данная возможность позволяет получить высокое качество энтропии сразу после начала загрузки.

-  В криптографические компоненты ядра включена новая подсистема "acomp (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....)", позволяющая сжимать данные в асинхронном режиме;

-  В подсистему virtio включено новое устройство virtio-crypto (http://qemu-project.org/Features/VirtioCrypto) для обеспечения шифрования, предоставляющее типовые криптографические операции для виртуализированных гостевых систем;


-  
Сетевая подсистема

-  В сетевом стеке обеспечена поддержка маршрутизации сетевых пакетов с учётом UID-идентификатора процесса получателя или отправителя. Возможность перенесена из платформы Android, на которой используется для  создания политик маршрутизации, привязанных к отдельным приложениям. Например, администратор теперь может использовать правила вида "ip rule add uidrange 100-200 lookup 123";


-  Для IPv6 реализована поддержка Segment Routing (http://www.segment-routing.org/) (SR-IPv6 (https://tools.ietf.org/html/draft-ietf-6man-segment-routing-...)), одной из новых техник маршрутизации от источника (source-routing);

-  В подсистему netfilter добавлена (https://marc.info/?l=netfilter-devel&m=148029128323837&w=2) поддержка объектов с сохранением состояния (stateful objects), которые могут быть  идентифицированы заданным пользователем уникальным именем и прикреплены к таблицам пакетного фильтра. В настоящее время поддерживается два типа таких объектов - счётчики и квоты;

-  В nftables добавлена поддержка выражения "rt", позволяющего проверить nexthop (IP-адрес шлюз...

URL: https://lkml.org/lkml/2017/2/19/224
Новость: http://www.opennet.me/opennews/art.shtml?num=46035


Содержание

Сообщения в этом обсуждении
"Релиз ядра Linux 4.10"
Отправлено iPony , 20-Фев-17 07:16 
> Из состава ядра удалена файловая система logfs

Радует, что хоть что-то удаляют. А то растаращит так, что лопнет же.


"Релиз ядра Linux 4.10"
Отправлено Анончег , 21-Фев-17 03:53 
Радует, что за 12309, кажется, всё же решили взяться.



"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 07:28 
> Интегрированы патчи с улучшенной реализацией механизма фонового сброса данных на накопитель, решающие проблемы с подвисаниями во время фонового копирования данных на медленный USB-накопитель. На системах с большим объёмом ОЗУ и медленными устройствами ввода/вывода переносимые на накопитель данные буферизируются в кэше обратной записи и копирование завершается в фоне. Ранее, операции сброса кэша обратной записи приводили к существенному снижению отзывчивости интерфейса приложений, подобных Firefox, вплоть до невозможности нормальной работы в течение нескольких минут. Например, выполнение "dd if=/dev/zero of=foo bs=1M count=10k" или копирование большого файла на USB-накопитель не давало запустить браузер или любое крупное приложение пока оставался не сброшен кэш обратной записи.

У меня дежавю это же в точь в точь подходит под описание https://bugzilla.kernel.org/show_bug.cgi?id=12309


"Релиз ядра Linux 4.10"
Отправлено анонимус_б6_выпуск_3 , 20-Фев-17 08:01 
это оно и есть

"Релиз ядра Linux 4.10"
Отправлено анан , 20-Фев-17 08:23 
Не на том баге держится всё ядро линукс, его нельзя исправлять, он был есть и будет))

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 10:43 
Для полноты картины: http://lurkmore.to/12309 И кстати на моей системе он виден во всей красе и не только во время работы Firefox.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 10:48 
А показывать реальную скорость записи на usb-накопитель Линукс не научили ещё? И чтобы интерфейс показывал окончание записи ровно тогда, когда она реально прекращается.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:16 
> И чтобы интерфейс показывал окончание записи ровно тогда, когда она реально прекращается.

Индикатор на корпусе флешки вам в помощь.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:27 
> Индикатор на корпусе флешки вам в помощь.

Типичный ответ линуксоида.
У меня в дорогом финском мидл тауэре юсб-порты на переднице кверх тормашками. Вот так и ничего не поделаешь. Мне становиться теперь перед ним на колени и заглядывать снизу на флешку ради твоей богоизбранной ОС?
Не всё так плохо, конечно. В Убунте с Юнити, например, я могу жмакнуть на извлечение и дождаться пока появится сообщение, что теперь уже можно, но это не правильно, это не по человечески.



"Релиз ядра Linux 4.10"
Отправлено Ordu , 20-Фев-17 11:35 
А как "по-человечески"? Сталкиваясь, например, с вендой я поступаю вот ровно так как ты описал. Может я что-то делаю неправильно?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 13:14 
В винде корректно отображается скорость записи на внешний накопитель. А не 120 мб/с на флешку, а на самом деле всего лишь в буфер вжжжж! А потом скорость медленно падает падает, ну и вот всё, скопировалось, судя по шкале - ан нет, на самом деле там ещё писаться с минуту.



"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 14:15 
Линукс (ядро) такое конечно же позволяет сделать:
очень даже запросто можно наблюдать и куда заливаются данные (в кеш или уже на физике)
и скорость и т.д. Работа с устройствами позволяет.
Это - прямой ответ на Ваш вопрос.
Но не надо путать ядро и ОС (в маздае ж это всё ОС делает).
Так что, это уже вопросы к Вашему окружению пользователя и файловому менеджеру,
которым пользуетесь.

"Релиз ядра Linux 4.10"
Отправлено Ordu , 20-Фев-17 18:34 
> В винде корректно отображается скорость записи на внешний накопитель. А не 120
> мб/с на флешку, а на самом деле всего лишь в буфер
> вжжжж! А потом скорость медленно падает падает, ну и вот всё,
> скопировалось, судя по шкале - ан нет, на самом деле там
> ещё писаться с минуту.

Монтируй флешку с опцией sync, и будет тебе нормально отображаться скорость записи на внешней носитель. Венда всегда так делает. Но, я полагаю, не столько ради нормального отображения скорости, сколько ради защиты от дурака, который забудет отмонтировать флешку перед извлечением.


"Релиз ядра Linux 4.10"
Отправлено Толл , 20-Фев-17 19:31 
> Монтируй флешку с опцией sync...

Монтируй флешку - это что-то из давно забытого. Теперь надо еще найти, как монтируют флешку кеды, например, и где настроить параметры этого дела.



"Релиз ядра Linux 4.10"
Отправлено Ordu , 20-Фев-17 19:46 
>> Монтируй флешку с опцией sync...
> Монтируй флешку - это что-то из давно забытого. Теперь надо еще найти,
> как монтируют флешку кеды, например, и где настроить параметры этого дела.

Ну, тут уж я ничем помочь не могу. Мне точно так же как и тебе было лень разбираться с этими проблемами автомаунта, поскольку написать mount в консольке совсем не сложно.
Но я предположу, что искать надо не в кедах а в настройках какого-нибудь там автомаунта, udev или ещё какой-то системной лабуды.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:39 
> юсб-порты на переднице кверх тормашками.
> Мне становиться теперь перед ним на колени и заглядывать снизу на флешку

Ну тогда дамское зеркальце вам в помощь. :)


"Релиз ядра Linux 4.10"
Отправлено soarin , 21-Фев-17 17:25 
С селфи палкой.

"Релиз ядра Linux 4.10"
Отправлено neon1ks , 20-Фев-17 11:41 
Можно в терминале выполнить команду `sync`

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 12:48 
> У меня в дорогом финском мидл тауэре юсб-порты на переднице кверх тормашками.

А у меня на недорогом китайском всё в порядке. Выброси свой дорогой финский мидл-тоуер и спи спокойно.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:39 
>Индикатор на корпусе флешки

4 флешки и все без индикаторов. Что делать?


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 21:39 
> Бежать с криком на опеннет.

"Релиз ядра Linux 4.10"
Отправлено Мадара , 20-Фев-17 22:05 
припаять индикатор

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 10:17 
> 4 флешки и все без индикаторов.
> Что делать?

Флешки сжечь.
Голову посыпать пеплом.


"Релиз ядра Linux 4.10"
Отправлено ЛинуксПользователь , 20-Фев-17 15:26 
Бред несёте.
Не у всех флешек имеется индикатор вовсе, помимо того, что он не обязателен.
Кроме того, лично я просто не любитель герлянды вместо флешки.
Да, такой баг есть, что копипаст 6гб инфы (не мелкими файлами) занимает на живой флешке не минуты, а десятки минут и порой переходит в часы.
Бесят такие анонимусы, у которых свербид в одном месте признать факт и писать бредятину.
Баг этот уже более чем давний и действительно, иногда быстрее грузануться в винду и копирнуть инфу, чем ждать около часа, а затем ещё ожидать сброса кеша.
Де факто, у винды это сделано правильнее и то же извлечение устройства занимает пару секунд, а не иногда пол часа или час.
И это всё, при условии, что флешки разные.
Поведение одинаково, как на новых флешках, так и на старых.
Так, что не нужно кукарекать, мол флешку шуструю юзай.

"Релиз ядра Linux 4.10"
Отправлено ПавелС , 20-Фев-17 15:53 
>[оверквотинг удален]
> Бесят такие анонимусы, у которых свербид в одном месте признать факт и
> писать бредятину.
> Баг этот уже более чем давний и действительно, иногда быстрее грузануться в
> винду и копирнуть инфу, чем ждать около часа, а затем ещё
> ожидать сброса кеша.
> Де факто, у винды это сделано правильнее и то же извлечение устройства
> занимает пару секунд, а не иногда пол часа или час.
> И это всё, при условии, что флешки разные.
> Поведение одинаково, как на новых флешках, так и на старых.
> Так, что не нужно кукарекать, мол флешку шуструю юзай.

Да мать ети, в виндовс для флэшек не отключен кэш на запись. Так было и в Linux когда-то, а теперь пишется прямо на флэш, потому и медленно. Первые секунды быстро - это кэш в самой флэшке, с тех пор как их стали такими делать, ядерный кэш решили не использовать.


"Релиз ядра Linux 4.10"
Отправлено Адекват , 21-Фев-17 08:05 
Какая разница что и где отключено, если ПОЛНОЦЕННЫЙ ПРОЦЕСС ЗАПИСИ (от момента когда мы жмакаем на красывенькую кнопочку, то того, когда последний байт на флешке) на флешку в виндах работает быстро, а в линуксах медленно ?
Вот зачем включили эту опцию sync, или как ее там ? в чем была необходимость ? Линакс безее не мог нормально дописывать данные ? Хм...еще есть одна крутая штука - noataime - это не оно ? если нет - срочно нужно включить !!

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:00 
Что у тебя за флешки такие, с ntfs-ом, чтоли? Да даже на ntfs так не тормозит.

ЗЫж У меня тоже флешки тупят, но чтобы 6Гб больше часа - это ты гонишь!


"Релиз ядра Linux 4.10"
Отправлено ryoken , 20-Фев-17 16:01 
> Индикатор на корпусе флешки вам в помощь.

Очевидно, благородный дон исключает вероятность существования на данном глобусе безиндкикаторных флешек... :D


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 21:52 
Дорогой финский мидл тауэер с перевернутыми кверх тормашками usb портами вам в помощь. :))

"Релиз ядра Linux 4.10"
Отправлено 1111 , 20-Фев-17 11:56 
Отмонтирование флешки закончится тогда, когда всё запишется.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:14 
> Отмонтирование флешки закончится тогда, когда всё запишется.

Но ведь можно сделать umount -f! И там не будет дополнительной проверки и диалогов "Уверенны?" "Точно?" "А может не надо?" для подтверждения!



"Релиз ядра Linux 4.10"
Отправлено Гентушник , 21-Фев-17 01:23 
Можно взять и разломать флешку пополам. Там тоже внезапно никаких диалогов подтверждения не будет.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 15:35 
У меня в KDE при безопасном извлечении флешки устройство из списка подключенных пропадает ровно в момент реального окончания записи если судить по светодиоду на флешке. Так что если пользоваться нормальной DE и файловым менеджером то проблем нет.

"Релиз ядра Linux 4.10"
Отправлено p5n , 20-Фев-17 15:56 
> показывать реальную скорость записи на usb-накопитель Линукс не научили ещё

Какой ты толстый! У линукса оказывается есть интерфейс, который показывает скорость записи.

Это всё вообще проблемы файлового мененеджера который копирует. Линукс все сисколлы для реализации такой чудофичи предоставляет.


"Релиз ядра Linux 4.10"
Отправлено bs0d , 21-Фев-17 01:57 
sync

"Релиз ядра Linux 4.10"
Отправлено all_glory_to_the_hypnotoad , 21-Фев-17 02:30 
не пиши через кеш

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:18 
Это вариант при записи, есть ещё вариант при чтении с mtp (android)через тот-же usb (только вешается не ff а вся подсистема io), как раз словил при копировании с устройства папки с 10Гб... на диск с ntfs в dmraid-1, при этом процессор загружен не был. Так как конфигурация весьма специфичная, просто оставил комп в покое на пол часа.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:19 
> Это вариант при записи, есть ещё вариант при чтении с mtp (android)через
> тот-же usb (только вешается не ff а вся подсистема io), как
> раз словил при копировании с устройства папки с 10Гб... на диск
> с ntfs в dmraid-1, при этом процессор загружен не был. Так
> как конфигурация весьма специфичная, просто оставил комп в покое на пол
> часа.

p.s. ядро 4.9 debian jessie, диск не системный


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 12:48 
Syncthing в помощь. Пользуюсь — не нарадуюсь

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:54 
https://bugzilla.kernel.org/show_bug.cgi?id=12309#c648

Похоже нужно экстремально тормозное устройство, или копировать с быстрого ссд на флешки/хдд на худой конец. Что бы объясняло почему никогда лично не ловил полуфимический баг.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 12:40 
не обязательно чтобы само устройство было экстремально тормозным. то же самое можно сделать если современное, быстрое устройство нагрузить большим вводом/выводом, например заставить swap-ить на него активно. ну или запустить кучу приложений активно что-то читающих пищущих.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 14:52 
Насчет swap. Тормоза от активного свопа вполне логичны, привычны и кроссплатформены. Разве бывает по-другому?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 15:18 
Из личных наблюдений: по работе приходится иметь дело с оффтопиком, так вот тормоза от swap есть везде, но в Linux это бьет прямо по интерфейсу, так, что даже курсор мыши зависает и переключаться между задачами нельзя. В оффтопике же просто некоторые вещи работают медленнее (копирование/удаление файлов), но на интерфейс это никак не влияет вот хотелось чтобы так-же было и в Linux.

"Релиз ядра Linux 4.10"
Отправлено Лютый , 20-Фев-17 16:08 
Люто плюсую, такая-же х..та только во фре. Если распаковывается допустим тарбол с fierfox'ом при установке порта, то всё просто стоит колом. Пока работа с диском не прекратится. А gstat при этом показывает активность диска хоть на r хоть на w какие-то жалкие килобайты в секунду. В линуксе видимо такая же проблема есть. Может это я что-то не то делаю или sysctl какой подкрутить надо? Подскажите кто знает.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:33 
> Люто плюсую, такая-же х..та только во фре. Если распаковывается допустим тарбол с
> fierfox'ом при установке порта, то всё просто стоит колом. Пока работа
> с диском не прекратится. А gstat при этом показывает активность диска
> хоть на r хоть на w какие-то жалкие килобайты в секунду.
> В линуксе видимо такая же проблема есть. Может это я что-то
> не то делаю или sysctl какой подкрутить надо? Подскажите кто знает.

kern.sched.preempt_thresh=224
vm.pageout_oom_seq=2
kern.ipc.shm_use_phys=1
vm.defer_swapspace_pageouts=1
или
vm.disable_swapspace_pageouts=1

С проблемой вставания колом как раз из-за IO как-то ни разу не сталкивался.


"Релиз ядра Linux 4.10"
Отправлено Адекват , 21-Фев-17 08:12 
> kern.sched.preempt_thresh=224
> vm.pageout_oom_seq=2
> kern.ipc.shm_use_phys=1
> vm.defer_swapspace_pageouts=1
> или
> vm.disable_swapspace_pageouts=1
> С проблемой вставания колом как раз из-за IO как-то ни разу не
> сталкивался.

Я бы не стал принимать советы от анонима из интернета, не понимая что они значат, чтобы потом их применить на личном компе или тем более сервере.


"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 21-Фев-17 14:02 
Как минимум, сгодится как указание, куда копать

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 14:27 
>[оверквотинг удален]
>> vm.pageout_oom_seq=2
>> kern.ipc.shm_use_phys=1
>> vm.defer_swapspace_pageouts=1
>> или
>> vm.disable_swapspace_pageouts=1
>> С проблемой вставания колом как раз из-за IO как-то ни разу не
>> сталкивался.
> Я бы не стал принимать советы от анонима из интернета, не понимая
> что они значат, чтобы потом их применить на личном компе или
> тем более сервере.

Сказал любитель закрытых осей и бинарей.

  % sysctl -d kern.sched.preempt_thresh
kern.sched.preempt_thresh: Maximal (lowest) priority for preemption
% sysctl -d vm.disable_swapspace_pageouts
vm.disable_swapspace_pageouts: Disallow swapout of dirty pages
Ну и маны с гуглами никто не отменял.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:28 
Ну вот что-то хитрое устроили. У меня как раз было самое приятное впечатление о фре: во время копирования всё было тихо, гладко. Специально проверял, и запускал сборку чего-нибудь эдакого, типа Libre'ы по всем ядрам. Тоже тихо, гладко.

"Релиз ядра Linux 4.10"
Отправлено ОлдФак , 20-Фев-17 20:32 
Товарищ свыше про фрю наверное говорил не про "вставание колом" при копировании, а именно про ситуацию с многими маленькими файлами. Я у себя тоже такое наблюдаю, при распаковке больших портов типа либры, хрома да лиса. Но отметить могу, что встаёт колом именно десктопные задачи, т.е. клики мышой достигают цели через секунд 30 или даже дольше, приложения между собой не переключаются. А в консоли всё работает в эти моменты сносно.

Надо проверить с предложенными sysctl'ами, вдруг поможет.


"Релиз ядра Linux 4.10"
Отправлено Андрей , 21-Фев-17 23:42 
При записи на флэшку только первые пару сек тормоза ощущаются. 64бит. ЧЯДНТ? o_O

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 13:07 
> или копировать с быстрого ссд на флешки/хдд на худой конец

а это редкий кейс? Кажется, что это как раз и есть типичная ситуация, разве нет?


"Релиз ядра Linux 4.10"
Отправлено Stax , 20-Фев-17 14:54 
Именно. Очень частый кейз. Например, на машине с 16 ГБ памяти я "вляпываюсь" в этот баг при попытке скопировать несколько ГБ на флешку: с таким объемом ОЗУ размер dirty (20% по умолчанию) это > 3 Гб, оно моментально накапливается, далее флешка, может, скажем, до 10 МБ/с на запись (это в хорошем случае, часто оказываются и более медленные) - для сброса 3 Гб требуется >300 секунд - и приехали. Как только попытаешься создать какую-либо еще нагрузку, получаешь жесткий ступор на эти самые 300 секунд, пока буфер того, что оказалось там ранее не сбросится.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 15:05 
>> или копировать с быстрого ссд на флешки/хдд на худой конец
> а это редкий кейс? Кажется, что это как раз и есть типичная
> ситуация, разве нет?

Насчет прям типичности не уверен. Не с пустого места производители и продавцы железа который год к ряду плачут о стагнации рынков. Нередкая, вот.


"Релиз ядра Linux 4.10"
Отправлено crypt , 20-Фев-17 14:57 
Он и есть! Ахахаха))) Сколько лет, сколько зим! Ну все, теперь ни что не остановит год линукса на десктопе!

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 17:12 
Секта свидетелей 12309 подошла. И ни одного багрепорта, as always.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 17:16 
> Секта свидетелей 12309 подошла. И ни одного багрепорта, as always.

Они стараются не отставать от секты Отрицающих.
Ваш КО.



"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 18:04 
Начнем с того, что сам баг давно исправлен, и уже много лет это толстый троллинг, теперь любая неполадка с флешками записывается в 12309, чего там только нет.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 27-Фев-17 12:50 
> Начнем с того, что сам баг давно исправлен.

Иди в пень, насчет исправлен. Достали такие "защитнички" Linux. Лишь чо брякнуть, только бы священный Linux не выглядел плохо в глазах бcдунов и вендузятников.

И флешки тут не причем. Я буквально пару дней на кубунточке 16.04 (ядро 4.4) наслаждался этой хренью, когда конвертировал виртуалбоксовский диск в raw формат, а потом жал его gzip'ом. Все в плазме встало колом, фаервокс ваще отвис только тогда, когда операция закончилась. Все происходило в пределах одного HDD, никаких флешек.

Если чо, то проц i5, 8 ГБ памяти. Давно исправили говоришь?


"Релиз ядра Linux 4.10"
Отправлено keka , 24-Фев-17 11:19 
На моём компе в Ubuntu Mate 14.04.5 LTS такой проблемы каких-либо тормозов при одновременном копировании на USB, серфинге и копировании между HDD и SSD совершенно не наблюдается. Но перегружаюсь в CentOS 7 с Mate или в Ubuntu 16.04 с MATE - тормоза есть.
За последний год Ubuntu 14.04 на моём железе работает, всё-таки, лучше других дистров.
Потому и не выкидываю. Удачный выпуск.

"Релиз ядра Linux 4.10"
Отправлено eRIC , 20-Фев-17 07:43 
Годное :)

"Релиз ядра Linux 4.10"
Отправлено Kleemhead , 20-Фев-17 07:53 
Наконец построили

"Релиз ядра Linux 4.10"
Отправлено Lolwat , 20-Фев-17 08:00 
Годнота. Особенно GVT-g. Будим пробывать

P.S.:  злые админы удалили мою толстую политическую шутку.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 10:11 
>злые админы удалили мою толстую политическую шутку.

все правильно сделали


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 12:01 
> Особенно GVT-g

Пока еще не годнота. Direct display не впилили, а это значит, что пользоваться можно, только через VNC или какой другой удаленный протокол. А раз так, то и смысла пока нет.


"Релиз ядра Linux 4.10"
Отправлено Fixer , 20-Фев-17 13:11 
да блин, а я уже обрадовался... продолжу пользователь vfio для проброса gpu в мою игровую виртуалку

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 08:04 
>Среди наиболее заметных изменений: решение проблемы с подвисаниями при интенсивном копировании на медленные USB-носители

джва года ждал..


"Релиз ядра Linux 4.10"
Отправлено Игорь , 20-Фев-17 08:48 
Я помню меня тоже сильно напрягал этот баг

"Релиз ядра Linux 4.10"
Отправлено yekm , 20-Фев-17 11:07 
Джва? Я лет 5 мучался, а потом отпала нужда писать чтолибо на флешки.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 08:22 
Поддержку Ryzen уже добавили?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:31 
Начальную точно - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:13 
> поллинга

Новые слова однако.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:51 
Если вы не знайте какого-то слова, то это не значит, что его нет.

https://ru.wikipedia.org/wiki/%D0%9F%D0%...

"Поллинг -  вариант опроса готовности устройств. Альтернатива использованию прерываний."


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:08 
Что ты мне ссылку на википедию даешь, на заборе тоже написано.
Поллинг прямо новое слово, а вот Polling вполне себе знакомое.
Вы мне прямо напоминаете одного из переводчиков генто-вики.

"Релиз ядра Linux 4.10"
Отправлено llolik , 20-Фев-17 13:05 
А как надо было написать? Опрашивание?

"Релиз ядра Linux 4.10"
Отправлено электронщег , 20-Фев-17 18:51 
Внезапно, "опрос". Вполне себе уайдли юзд терм.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 22:32 
> Внезапно, "опрос". Вполне себе уайдли юзд терм.

Вот только если написать "опрос",  хрен кто поймёт о чем речь. "Опрос" слишком общее понятие. Здесь либо "поллинг", либо многобукв.


"Релиз ядра Linux 4.10"
Отправлено электронщег , 21-Фев-17 01:21 
Даже если я буду обсуждать с коллегами софт для социологических ОПРОСОВ методом ОПРАШИВАНИЯ их мнений касательно решения про перерисовку GUI в одном потоке с ОПРОСОМ состояний некоторого драйвера — у меня не будет абсолютно никакой путаницы в терминах, т.к. адекватный человек следит за контекстом во время беседы. А неадекватный — вворачивает варваризмы по любому поводу.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 08:39 
> GUI в одном потоке с ОПРОСОМ состояний некоторого драйвера

Polling к опросу состояния драйвера при работе GUI не имеет никакого отношения. Для этого и написали явно "поллинг", чтобы подобной путаницы не возникало и специалистам стало сразу ясно о чём речь, а неспециалисты смогли быстро нагуглить подробности.

Понимайте, ядро может как просто опрашивать драйвер, так и выполнять polling, как отдельную технологию для замены дерганья прерываний при высокой нагрузке.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 11:51 
Для этого и написали явно "поллинг", чтобы подобной путаницы не возникало и специалистам стало сразу ясно о чём речь
Я наверное не специалист раз меня от русской транскрипции английской терминологии корежит.
А вот специалистам из 1С в самый раз.

"Релиз ядра Linux 4.10"
Отправлено электронщег , 21-Фев-17 19:22 
> так и выполнять polling, как отдельную технологию для замены дерганья прерываний при высокой нагрузке.

Чем это отличается от описанного мною случая? Какая разница, ядро или пространство пользователя? Опрос — он и в Африке опрос. И тут (в вашем случае) можно перейти на прерывания, и в моём случае можно перейти на "прерывания" (через callback).


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 22:36 
> Что ты мне ссылку на википедию даешь, на заборе тоже написано.

Ну да, для вас авторитетов нет. Википедия, с её моделью верификации и системой достижения консенсуса, заслуживает гораздо большего доверия, чем обычные энциклопедии. А если вы думайте, что там можно написать всё, что угодно, вам стоит изучить как там организованы процессы.


"Релиз ядра Linux 4.10"
Отправлено Неизвестный Автор , 21-Фев-17 11:48 
> Ну да, для вас авторитетов нет. Википедия, с её моделью верификации и
> системой достижения консенсуса, заслуживает гораздо большего доверия, чем обычные энциклопедии.
> А если вы думайте, что там можно написать всё, что угодно,
> вам стоит изучить как там организованы процессы.

А вы писали статьи в википедию? А мы писали. И, действительно, что угодно там не напишешь, но после бодания с присматривающими, в тексте останется только то, что по их мнению правильно. Останется реклама их любимых брендов, и их частное мнение по научным вопросам.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:21 
А я рад наконец то решению проблемы со флешками. А то запишется за 10 секунд , а флешка еще мигает пару часов.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:22 
Вот только непонятно со CIFS. Что они там реализовали то?

"Релиз ядра Linux 4.10"
Отправлено Ordu , 20-Фев-17 11:43 
Реальная скорость записи на флешку не увеличилась, а уменьшилась. То есть мигать она будет дольше. Единственное что изменилось -- всё остальное при этом не будет лагать. Собственно, сомнительное преимущество сегодня, ввиду всяких там облачных дисков: зачем нужна флешка, когда всё что надо можно таскать через сеть. Ну, может только особо чувствительные к раскрытию данные, типа детской порнографии, не стоит хранить на гуглодрайве. Но с детской порнографией вообще лучше не связываться.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:55 
У кого чего болит.

"Релиз ядра Linux 4.10"
Отправлено Я , 20-Фев-17 12:41 
>зачем нужна флешка, когда всё что надо можно таскать через сеть

Это работает только с личными данными. Рабочие обычно нельзя на всяких дропбоксах хранить, поскольку это уже нарушение NDA. Ну или ты поднял свой сервер с каким-нибудь owncloud, но не у всех же такой есть.


"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 20-Фев-17 14:13 
Для рабочих конторой поднимается свой сервис. Сетку,  в отличие от флешки, хоть забыть нельзя.

"Релиз ядра Linux 4.10"
Отправлено Я , 20-Фев-17 16:17 
Наличие смотрящего наружу сервиса -- уже потенциальная дыра, поэтому важные данные все-таки носят на флешке или ноуте.

"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 20-Фев-17 18:46 
Ну, если выносить из-за периметра железо - это более приемлемо... Успехов. В общем случае безопасная сеть - это проще.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 13:46 
Флешки хреново работают в линукс - флешки нинужно!



"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 15:39 
да нормально они работают. мне например такое поведение больше нравится - не нужны костыли в виде "асинхронного копирования" в тоталкомандере - в mc накидал файлов и оно уже само в фоне копируется. в DE файлы копировать не люблю, но если и копирую - тоже ничего не напрягает. А если такое поведение не устраивает - всегда можно уменьшить размер буфера до неприличного значения в 512 байт например (можно и 0) и будет как в венде.

"Релиз ядра Linux 4.10"
Отправлено Ordu , 20-Фев-17 18:28 
> Флешки хреново работают в линукс - флешки нинужно!

Да нормально они работают, но гуглодрайв реально удобнее. Он не только для личного пользования, я могу и ссылкой переслать любому человеку любую часть содержимого там, если вдруг понадобится, а он зальёт туда то, чего мне не хватает. Мне не надо для этого встречаться с человеком, тыкая и перетыкивая флешки в комп.


"Релиз ядра Linux 4.10"
Отправлено Адекват , 21-Фев-17 08:30 
>Собственно, сомнительное преимущество сегодня, ввиду всяких там облачных дисков:

Ага, осталось только телевизор у моих родителей подключить к интернету, и научить его с гуглдрайвом общаться. Придется впаивать ethernet-контроллер, и прошивку перепрограммировать, но это реально проще, чем воткнуть в него флешку.

Но это не самый упoрoтый совет, самый упoротый - "в локальной сети вместо самбы использовать битторент"


"Релиз ядра Linux 4.10"
Отправлено Ordu , 21-Фев-17 08:44 
>>Собственно, сомнительное преимущество сегодня, ввиду всяких там облачных дисков:
> Ага, осталось только телевизор у моих родителей подключить к интернету, и научить
> его с гуглдрайвом общаться. Придется впаивать ethernet-контроллер, и прошивку перепрограммировать,
> но это реально проще, чем воткнуть в него флешку.

А не надо было родителям покупать телевизор без ethernet-разъёма или без wifi. Они могли, как белые люди через самбу прокидывать файлы, но благодаря твоей недальновидности они до скончания века будут пользоваться морально-устаревшими флешками.


"Релиз ядра Linux 4.10"
Отправлено Адекват , 21-Фев-17 09:01 
> твоей недальновидности они до скончания века будут пользоваться морально-устаревшими
> флешками.

Только им еще и интернет нужно домой будет провести, а он им просто не нужен.


"Релиз ядра Linux 4.10"
Отправлено Ordu , 21-Фев-17 18:42 
>> твоей недальновидности они до скончания века будут пользоваться морально-устаревшими
>> флешками.
> Только им еще и интернет нужно домой будет провести, а он им
> просто не нужен.

Открою секрет: самба работает без интернета. Ну, локальная, по-крайней мере.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 02:01 
> Открою секрет: самба работает без интернета. Ну, локальная, по-крайней мере.

Чё-то родители не захотели смотреть как работает локальная самба.
Говорят голливуд лучше работает.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 09:59 
>используется для создания политик маршрутизации, привязанных к отдельным приложениям.

Так глядишь лет еще через пять и сделают нормальный фаерволл. Может быть.


"Релиз ядра Linux 4.10"
Отправлено zanswer CCNA RS , 20-Фев-17 11:00 
Эм, а как фильтрация пакетов, именно её в самом простом случае, выполняет Packet Filter (Firewall), связана с возможностью выполнение маршрутизации на основе UID приложения (Policy Routing)?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 12:47 
Всегда было...
# iptables -A OUTPUT -j REJECT -m owner --uid-owner 50-100

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 14:58 
>Доколе?

Потому что GNU/Linux не сохраняет нигде пути до экзешника и сам экзешник может быть удален напрочь (в отличие от винды, где это невозможно). Более того, места где сохраняется путь -- модифицируемы, что ведет к тому, что процесс невозможно отследить как надо.

Это, конечно, не является проблемой для BSD-систем, где путь до экзешника находится либо в read-only, либо дается копия для модифицирования путя пользователем.

Итого. Можно ждать вечность. По факту до того момента пока не пофиксят правила модификации пути исполняемого файла.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:14 
Ну вот потому и 2%, в том числе. Потому что юзкейс "разрешить одной проге ходить в инет на один определенный адрес, другой - только в локалку, а третьей вообще только на локалхост" встречаются в продакшене сплошь и рядом. И в линухе они либо не решаемы вообще, либо костылями через /dev/ass. Потому что корпоративные политики безопасности плевать хотели на кукареканье с дивана одминов локалхоста, что линух, дескать взломоустойчив, не то что дырявая В-нда.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:07 
> Ну вот потому и 2%, в том числе. Потому что юзкейс "разрешить
> одной проге ходить в инет на один определенный адрес, другой -
> только в локалку, а третьей вообще только на локалхост" встречаются в
> продакшене сплошь и рядом. И в линухе они либо не решаемы
> вообще, либо костылями через /dev/ass. Потому что корпоративные политики безопасности
> плевать хотели на кукареканье с дивана одминов локалхоста, что линух, дескать
> взломоустойчив, не то что дырявая В-нда.

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


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:17 
> кто даст гарантию, что это действительно то приложение с тем функционалом, которому эти права давались? или фаервол по твоему еще должен за хешами бинарников следить?

Именно поэтому он работает в разрезе программ. Даже если файл программы изменился, она не получит больше прав, чем ей было изначально необходимо.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 18:03 
A "в разрезе программ" это как ?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 18:24 
"в разрезе Х" = "в детализации по Х"

Права задаются для программы (пути к исполняемому файлу), значит они задаются в разрезе программ.

Впоследствии можно построить отчёт какая программа куда имеет доступ, сравнив имеющийся доступ с минимально требуемым. Это значительно удобнее, чем осуществлять контроль прав в разрезе пользователей или групп пользователей.

В новых версиях Windows есть понятие "список разрешённых программ", что позволяет создать группы пользователей по их ролям в компании. Это позволяет централизованно (через AD) настраивать права в соответствии с ISO 9001 (описывает кто конкретно что конкретно делает и кто конкретно за что конкретно отвечает).

Не уверен, что Линукс даже близко к этому подошёл. На мой взгляд, он идёт совсем в другом направлении.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 19:36 
Группы еще в юниксах были. Наконец-то индеец заметил, что нет одной стены. :))

"Релиз ядра Linux 4.10"
Отправлено vi , 20-Фев-17 21:40 
>[оверквотинг удален]
> разрезе программ.
> Впоследствии можно построить отчёт какая программа куда имеет доступ, сравнив имеющийся
> доступ с минимально требуемым. Это значительно удобнее, чем осуществлять контроль прав
> в разрезе пользователей или групп пользователей.
> В новых версиях Windows есть понятие "список разрешённых программ", что позволяет создать
> группы пользователей по их ролям в компании. Это позволяет централизованно (через
> AD) настраивать права в соответствии с ISO 9001 (описывает кто конкретно
> что конкретно делает и кто конкретно за что конкретно отвечает).
> Не уверен, что Линукс даже близко к этому подошёл. На мой взгляд,
> он идёт совсем в другом направлении.

У вас там еще в текстовом процессоре нет настройки "Кому какие символы можно печатать"?
Я рад, что вы даже близко к этому не подошли. Но первый_московский_дурдом уже вздрогнул ;)


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 21-Фев-17 00:30 
Не уверен - не срывай.

Попутно же можно загуглить как мракософт меняет позу своего поделия в попытках заявить, что оно умеет Docker _не хуже_ Линукса. Причём, они пихают туда целое линух ядро - иначе ж никак.

А куда подошёл Линукс - можно почитать на сайте docker.com
Там есть и про отдельные сетки для отдельных [множеств] программ (включая роутинг и фаерволл), про любой дистр для любой проги, про отдельные адресные пространства файловых систем (чтобы прога видела только те файлы, что нужны для её работы) и много ещё чего.

У меня уже больше половины GUI-шных программ ходят в нет из своих отдельных контейнеров (причём, фаерволом расписано какой и куда можно), включая браузеры (да, их много и разных).

И что-то мне думается, что в этом направлении закрытый стул-софт (опеннент не даёт это правильно назвать) не пойдёт никогда - напросто жаба задавит позволять юзерам пускать свои облицензённые со всех сторон ОСи в любом количестве с такими гибкими настройками на одном железе.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 10:16 
>больше половины GUI-шных программ ходят в нет из своих отдельных контейнеров

Тебе есть куда стремиться - в системе еще дофига файлов, как рассадишь каждый в свой контейнер, тут и наступит лепота и Сингулярность. Это ж насколько тяжелое поражение мозга надо иметь, чтобы столь очевидные костыли выдавать за нормальное положение вещей. Никогда никакие песочницы-виртуалки-контейнеры не компенсируют продолб в архитектуре, если это не очевидно - медицина тут бессильна. Это общая беда всего маргинального IT - превращать (точнее пытаться превратить) костыли, вожможно и актуальные в частном каком-то случае, в системный подход.


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 21-Фев-17 10:28 
> Это общая беда всего маргинального IT - превращать (точнее
> пытаться превратить) костыли, вожможно и актуальные в частном каком-то случае, в
> системный подход.

Расскажите это микроядерщикам. Там тоже всякий чих - в отдельном адресном пространстве.
Да, Таненбаум был прав. И счас жизнь дожимает всё изолировать и отгораживать.
Да, всякие анонимные режимы в браузерах - это тот же тренд. А ещё в фаерфоксе где-то читал запилили тестовую фичу ограждения множеств вкладов друг от друга. Представляете какие "идиоты", ерундой какой занимаются! Но внезапно оказалось, что утечка данных из одной вкладки в другую может обернуться колосальными материальными или моральными потерями для пользователя... Информационная безопасность называется.
Добро пожаловать в реальный мир.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 02:24 
>[оверквотинг удален]
>>> другой - только в локалку, а третьей вообще только на локалхост"
>>> встречаются в продакшене сплошь и рядом.
>>> И в линухе они либо не решаемы вообще, либо костылями ...
>> ... можно почитать на сайте docker.com
>> Там есть и про отдельные сетки для отдельных [множеств] программ (включая роутинг и фаерволл),
>> ... про отдельные адресные пространства файловых систем
> Тебе есть куда стремиться - в системе еще дофига файлов, как рассадишь
> каждый в свой контейнер, тут и наступит лепота и Сингулярность.
> Это ж насколько тяжелое поражение мозга надо иметь, чтобы столь
> очевидные костыли выдавать за нормальное положение вещей.

Уважаемый Аноним,
так это хорошо, или плохо что можно каждую программу отдельно ограничивать?


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 08:47 
Это хорошо и полезно в некоторых случаях, но всех по контейнерам не рассадишь.

"Релиз ядра Linux 4.10"
Отправлено Andrey Mitrofanov , 22-Фев-17 09:55 
>в некоторых случаях, но всех по контейнерам не рассадишь.

Да!1 Тюрьмы ж не резиновые.


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 22-Фев-17 10:12 
> Это хорошо и полезно в некоторых случаях, но всех по контейнерам не
> рассадишь.

Например, что принципиально невозможно ограничить лишь ему нужными файлами и или
сеткой и/или множеством процессов?

(/sbin/init - у него просто будет особая роль: всё смортировать, поднять сетку и запустить докер; причём, подобные дистры уже есть, типа CoreOS)


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 18:23 
>> кто даст гарантию, что это действительно то приложение с тем функционалом, которому эти права давались? или фаервол по твоему еще должен за хешами бинарников следить?
> Именно поэтому он работает в разрезе программ. Даже если файл программы изменился,
> она не получит больше прав, чем ей было изначально необходимо.

лол, так а если этих прав уже достаточно для нанесения вреда? понадеялись на то, что программа не может ничего сделать, я подменяю бинарник - и всё, защита что есть что нет. Не вижу преимуществ у такого подхода, одни недостатки


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 18:54 
>я подменяю бинарник

Проблемы безопасности доступа к файлу это не проблема файрволла. Кроме того, никто не запрещает написать файрволл, который бы сверял цифровую подпись приложения, контрольные суммы и т.п.

Факт в том, что нет никаког фундамента. Одни отмазки. Потому что это ж виндовая тема. А значит ататата по определению это плохо. Детсад.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 10:52 
> Проблемы безопасности доступа к файлу это не проблема файрволла. Кроме того, никто не запрещает написать файрволл, который бы сверял цифровую подпись приложения, контрольные суммы и т.п.

вот про это я и говорю. защита по сути бесполезна, т.к. работает ТОЛЬКО в комплексе с другими мерами. При этом малейшая ошибка в организации "других мер" и защита полностью недееспособна. И какой смысл тогда городить весь этот огород? Нужно тебе запретить ПОЛЬЗОВАТЕЛЮ доступ к какому-то ресурсу - запрещай. А запрещать доступ одной программе и разрешать другой - идиотизм.

> Факт в том, что нет никаког фундамента. Одни отмазки. Потому что это ж виндовая тема. А значит ататата по определению это плохо. Детсад.

Т.е. чужие аргументы ты в принципе не воспринимаешь?


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 15:12 
>защита по сути бесполезна, т.к. работает ТОЛЬКО в комплексе с другими мерами.

И зачем во всяких там армиях и спецурах таскают всякие шлемы и броники. Можно ж в ногу стрелять, которая зашищена лишь тонкой хебешкой. Дураки, наверное. Внезапно, ВСЯ защита такая. И от сигнализации мало толку будет, если ты банально не запираешь дверь. Из того, что идельная и абсолютная защита от всего недостижима, никак не следует, что никакая не нужна.

>Нужно тебе запретить ПОЛЬЗОВАТЕЛЮ доступ к какому-то ресурсу - запрещай.

А то, что на компе может быть не один пользователь - тебе не приходило в голову? Тогда весть о том, что корпоративная политика может предусматривать использование одного софта для внешних ресурсов, и другого - для интрасети, вообще сорвет твою неокрепшую крышу?

>А запрещать доступ одной программе и разрешать другой - идиотизм.

Нонеча программы шибко умные пошли. Лезут куда не надо безо всякого участия какого-либо пользователя.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 14:47 
https://shiftordie.de/blog/2013/11/12/http-over-x509-revisited/

Статья старая, однако, какой вектор атаки! Простой значится почтовик превращается в сканер портов. При этом ЛИЧНО ты о таких вещах не узнаешь, если не ковыряешь используемый софт на 200%. Либо, пока кто-то не расскажет.

Если не умеешь в инглиш, то пересказ статьи сводится к тому, что для S/MIME (RFC 5280) имеется опция, когда можно заставить приложение выполнять вслепую HTTP-запросы для проверки сертификата. К счастью, умея делать запросы на основании разницы промежутка ответов для открытых/закрытых портов можно выяснить внутреннюю топологию сети.

Не надо лялякать, что это проблема только MS. Найдется другой софт, опенсорсный, где будет что-то аналогичное. И вот без исследования всех таких тонкостей ты можешь сколько угодно говорить об "защита по сути бесполезна, т.к. работает ТОЛЬКО в комплексе с другими мерами".

Твою сеть просканили. А ты только и делаешь, что ляля про "комплекс мер". Нихера ты не безопасник, раз исключаешь меры по принципу их "комплексности". Или черт знает, что ты имел ввиду.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 15:32 
Свежая атака на Python: http://www.itworld.com/article/3172604/security/java-and-pyt...

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:41 
А что такое "одна прога"? Вы как её уникально идентифицировать собрались? Ц:\Program Files\abc\qaz.exe? А если я вирус, и скопировал её в другое место? Может по хэшу?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:46 
>> "разрешить одной проге ходить в инет на один определенный адрес, другой - только в локалку, а третьей вообще только на локалхост"

Похоже, что это локалхостство. Если у вас есть какие-никакие севера, то они разделены или уж группами, или в них чувствительные к компрометации сервисы засунуты в lxc/jail/docker/chooseyourisolationtechnology и дальше уж разруливайте как хотите.
А пока верните аванс Майкрософту - не отработали.


"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 20-Фев-17 16:27 
В такой постановке задача вообще решается в юзерспейсе построением маппинга "путь - pid" при запуске процесса, скажем, на уровне glibc.

Другое дело, что оно на фиг не нужно, а что нужно - это ещё аккуратно сформулировать надо.

Насчёт модифицируемых путей - чушь, конечно. В /proc/<pid>exe будет линк на запущенный файл. Даже удалённый, он будет доступен.

P.S. А что, в BSD я не смогу собрать исполняемый файл, запустить его и удалить? Что-то не верится.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:40 
>/proc/<pid>exe

А что будет если удалить файл знаешь?
>А что, в BSD я не смогу собрать исполняемый файл, запустить его и удалить? Что-то не верится.

Можешь. Я говорил про то, что оригинальный путь всегда известен, даже если сделать удаление. Хинт в решение задачи выше ^^^^.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 17:41 
> А что будет если удалить файл знаешь?

К имени файла симлинке добавится (deleted), содержимое файла останется доступным.


"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 20-Фев-17 19:36 
Именно

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 20:15 
Беда-печаль. Держи веселый код:

unlink (argv[0]);
prctl (PR_SET_DUMPABLE, 0UL, 0, 0, 0);
char proc_exe[PATH_MAX];
sprintf (proc_exe, "/proc/%d/exe", getpid());
unlink(proc_exe);

И, собственно, в чем прелесть BSD? В том, что даже с таким извращением из таблицы процессов (они в памяти ядра, а не в псевдо-фс) ТОЧНО известно откуда был запущен файл.

Самое смешное, что 4.1.20-0-grsec не спросил CAPABILITY на PR_SET_DUMPABLE и тупо позволил снести архиважный файл /proc/pid/exe.

Про то, что содержание файла останется и читабельно... ну, ребята, это не смешно. Не стану унижать, может вы имели в виду, что inode файла как бы еще открыт (а значит не будет очищен фс) и доступен... А по мне, вы просто нифига не знаете. Без обид. Ну, такие вещи не знать =\


"Релиз ядра Linux 4.10"
Отправлено Crazy Alex , 20-Фев-17 21:11 
И что, по-твоему, должен сделать этот пример? Удалить файл? Да вперёд, имеет полное право. /proc/pid/exe как был, так и есть, и доступен для чтения.

И именно это мы и имели в виду, что не только инод открыт, но известен путь в FS (тот самый /proc/<pid>/exe), по которому можно получить содержимое и, скажем, проверить подпись или контрольную сумму посчитать. Что ещё надо-то?


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 21-Фев-17 00:38 
> sprintf (proc_exe, "/proc/%d/exe", getpid());
> unlink(proc_exe);

$ rm -f /proc/self/exe
rm: невозможно удалить '/proc/self/exe': Отказано в доступе

uname -r: 4.4.x


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 05:57 
>$ rm -f /proc/self/exe

Иди читай ман. Ты вообще код прочитал?! Ты прочитал или выскочил выи***тся? Что ты доказал? Что ты хотел показать? Иди в ЛОР и там показывай какой ты крутой. Тут ты пока выглядишь дураком.


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 21-Фев-17 10:21 
>>$ rm -f /proc/self/exe
> Иди читай ман.

А... сердешный, то-то я смотрю у Вас таких нет... следовательно не знаете

На случай, если Вы где что пользуете, где в procfs нет симлинки "self"
на свой PID, просвещу (ибо, выходит, Вам даже это в манах почитать негде)

$ ls -l /proc/self
lrwxrwxrwx 1 user user x xxx xx xx:xx /proc/self -> 26558

$ ls -l /proc/self
lrwxrwxrwx 1 user user x xxx xx xx:xx /proc/self -> 27831

$ ls -l /proc/self
lrwxrwxrwx 1 user user x xxx xx xx:xx /proc/self -> 27848

Да, представляете, в линухе "self" в корне procfs всегда указывает на диру самого же процесса. Да, сам procfs за меня за ленивого вызывает getpid() и вкладывает в уста
"self" результат соответствующего sprintf(). А потому, /proc/self/xxx - это всегда
именно свои файлы, собственного процесса.


> Ты вообще код прочитал?!

И даже больше, скомпилил (представляешь, кто-то кроме тебя это тоже умеет).
Немного strace'а:

unlink("./test")                        = 0
prctl(PR_SET_DUMPABLE, 0)               = 0
getpid()                                = 25269
unlink("/proc/25269/exe")               = -1 EACCES (Permission denied)


> Ты прочитал или выскочил выи***тся?

Встречный вопрос.

Расписанный Вами "ужос" удаления действительно нужного файла из procfs не подтверждается.
Какой вывод?

> Тут ты пока выглядишь дураком.

И что же такого прям дурного я написал?
Что такого умные завсегдатаи скрывают в своих тайных манах?


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 21-Фев-17 11:30 
>>$ rm -f /proc/self/exe
> Иди читай ман. Ты вообще код прочитал?! Ты прочитал или выскочил выи***тся?
> Что ты доказал? Что ты хотел показать? Иди в ЛОР и
> там показывай какой ты крутой. Тут ты пока выглядишь дураком.

Я понял чё это Вы так взъерошились на других.
Во бзде, оказывается по умолчанию этого нету...

Поставил счас в вбокс глянуть что ж оно там щас из себя представляет (давно уж не счупал).
И да:

# ls -l /proc
total 0

Всё ясно.

Но стоит лишь подгрузить procfs и замонтировать его в /proc - то всё там практически так же, чуть называется по-другому:

# ls -l /proc/curproc
r--r--r--  1 root wheel  0 Feb 21 08:25 /proc/curproc -> 986

# ls -l /proc/curproc
r--r--r--  1 root wheel  0 Feb 21 08:25 /proc/curproc -> 987

# ls -l /proc/curproc
r--r--r--  1 root wheel  0 Feb 21 08:25 /proc/curproc -> 990

# ls -l /proc/curproc/file
r--r--r--  1 root wheel  0 Feb 21 08:25 /proc/curproc/file -> /bin/ls

И тоже - вполне логично - не удаляется (хоть и по другим причинам):
# rm /proc/curproc/file
rm /proc/curproc/file: Operation not supported


"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Фев-17 14:58 
> Я понял чё это Вы так взъерошились на других.
> Во бзде, оказывается по умолчанию этого нету...

Во-первых, признаю свой косяк с /proc/pid/exe. Действительно, procfs монтируется по правам 05xx (где x это 5 или 0). И симлинк на exe невозможно удалить и модифицировать в таком случае. Да, бывает проглядел вывод ls и отписался сгоряча. Звиняйте.

Во-вторых, в бзд таблица процессов находится в другом месте. Не procfs. Там и top работает по-другому. Мой наезд был на линукс в том плане, что без procfs утилиты вроде top, да и само ядро не узнают путь до бинарника. В бзде это зашивается во внутренную таблицу процессов, при этом путь этот никак не изменить, а все что можно изменить через, скажем, argv[0] - лишь копия, а оригинал можно легко вывести через ps(1) или top(1).

В-третьих, не надо думать, что я совсем идиот и не знаю про /proc/self -- для дебага этот /proc/self на*** не сдался: getpid() нужно смотреть, так пусть тестовая прога его печатает  сама.

Итого. В линуксе без procfs эта информация [о пути] _нигде_ не хранится. Да, систем без procfs можно сказать не бывает (ТМ). И тем не менее, procfs это лишь опция, которую можно вырезать из ядра и тогда оно превращается в биомассу. В отличие от бзди, где это прописано в ... недра.

Всё, вопрос про /proc/pid/exe закрываем. Хотя есть ряд вопросов по поводу '(deleted)'. Будет время -- поковыряю. Вот интересно, что будет при пути бинарника длиной PATH_MAX-1. Куда припишится '(deleted)'? :)


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 22-Фев-17 23:28 
> Звиняйте.

Ничё, бывает. Я вон дальше по треду разошёлся, что ld.so загрузчик может грузить бинарии с noexec дир и только потом попробовал на практике - оказалось, что уже не может, в glibc прикрыли.

> Мой наезд был на линукс в том
> плане, что без procfs утилиты вроде top...не узнают путь до бинарника.

Да, top требует для работы чтоб 'proc' (не 'procfs', к слову, но мелочи) был замонтирован в /proc

> да и само ядро не узнают путь до бинарника.

Даже не знаю откуда у Вас такие заблуждения (неужели так сложно исходники открыть, прежде чем делать такие выводы на публику?)
Линух 4.4.x

Смотрим структуру задачи-потока на юзер-левеле (task_struct). В процессе их может быть N+1, но тогда у всех них одна и та же память (т.е. указатель на "struct mm_struct *mm")

include/linux/sched.h:
   struct task_struct {
    ...
    struct mm_struct *mm,
    ...
   }


include/linux/mm_types.h:
   struct mm_struct {
    ...
    struct file __rcu *exe_file
    ...
   }

И эти места в коде не обусловлены никакими #ifdef, т.е. от опций сборки не зависят.
Т.е. ядро всегда знает каков бинарь у процесса.
А файловая система 'proc' - просто использует эти данные, будучи настройкой.

$ grep CONFIG_PROC_FS /boot/config-4.4.0-64-lowlatency
CONFIG_PROC_FS=y

которая да, чаще всего включена (хотя на суперограниченных встроенных системах это можно и убрать).


> В бзде это зашивается во внутренную таблицу процессов

Ну выше видите: в Линухе тоже.
(даже не пойму: с какой стати доставать ТАКУУУЮ огромную шашку против устройства Линуха, реально не смотрев его изнутри? Берёте на понт? - так упенсурс же, все могут проверить...)

> при этом путь этот никак не изменить, а все
> что можно изменить через, скажем, argv[0] - лишь копия, а оригинал
> можно легко вывести через ps(1) или top(1).

Ну то же и в пингвине. Оригинал никуда не спрятать. И?
"Во-вторых" ушло пока что вникуда.


> В-третьих, не надо думать, что я совсем идиот

И заметьте, не я это произнёс...

> и не знаю про
> /proc/self -- для дебага этот /proc/self на*** не сдался: getpid() нужно
> смотреть, так пусть тестовая прога его печатает  сама.

Да пусть. Если Вам так уж принципиально лично вызвать getpid(), а не через ФС 'proc'.


> Итого. В линуксе без procfs эта информация [о пути] _нигде_ не хранится.

См. выше и читайте прежде, чем говорить.


> Да, систем без procfs можно сказать не бывает (ТМ). И тем
> не менее, procfs это лишь опция, которую можно вырезать из ядра
> и тогда оно превращается в биомассу.

Какие-то далёкие от техники алегории...
И без PROC_FS ядро будет прекрано осведомлено кто откуда запущен.
И что-то набиомассу здесь активно начинает претендовать кто-то другой...


> В отличие от бзди, где это прописано в ... недра.

Да, внутренние файлики ядра и структуры данных называются по-разному. И всё отличие в этом вопросе.


> Всё, вопрос про /proc/pid/exe закрываем.

Да пожалуйста. Пофантазировали на тему Линукса и в люлю.
Что-то для осознающего свою правоту Вы несколько эмоциональны. К чему бы это? Или лавры Линуха на пингвине не дают покоя демону?

В бзд как-то гениально размещена таблица процесов? - нет
а в линухе? - тоже нет. Размещена и размещена.


> Хотя есть ряд вопросов по поводу '(deleted)'.
> Будет время -- поковыряю.

Ага! Обос*ать время есть, и прямо сейчас, а поднять достоверную инфу пока времени не было :) Классика.

Держите, Вам для затравочки:

запущен sleep (PID 14281)

а от рута делаем следующее:
# l /proc/14281/exe
lrwxrwxrwx 1 user user 0 фев 22 xx:09 /proc/14281/exe -> /bin/sleep

# mv /bin/sleep /bin/sleep1

# l /proc/14281/exe
lrwxrwxrwx 1 user user 0 фев 22 xx:09 /proc/14281/exe -> /bin/sleep1

Мож натолкнёт на какие мысли.


> Вот интересно, что будет при пути бинарника
> длиной PATH_MAX-1. Куда припишится '(deleted)'? :)

Досрочный ответ: выдача пути с приписанным '(deleted)' не ограничивается PATH_MAX'ом, а просто размером переданного буфера.


Просто вообще не очень ясно в чём собсно, проблема. Знать откуда был запущен процесс - ну хорошо. Структура списка процесов в Линухе покажет переименованный или удалённый путь бинаря. Но если у кого есть право удалять/переименовывать и запускать бинари - то это уже неслабый доступ. И если стоит задача наблюдать активность юзерей аж с таким уровнем доступа - то подсистема audit Вам в руки. Там каждый чих пишется: кто чего куда.
Как по мне, довольно логично: дефолтный уровень секурити - таков, надо больше - бери больше инструментов (поставить/запустить тот же auditd). Или всё сразу должно быть из коробки, невзирая надо оно или просто память жрёт? А если аналогичных инструментов не один? Возможность выбора можно считать плюсом или минусом? (необходимость думать и осознанно выбирать - тоже кому-то будет в минус)


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 23-Фев-17 00:34 
И кстати, о безопасности.
Если же знанием о файле запуска бинаря Вы планируете закрыть какой-либо из возможных т.н. "векторов атаки", типа, когда через дырь заливается и запускается бинарь, висит и внаглую слушает порт.
А Вы его планируете "опа" - и посмотреть куда он был залит, и, воможно, это бы указало на след. пролома в защите.

Но есть один момент. Если сей процесс хотя бы просто себя скопирует в менее "подсказочное" место и сделает оттуда же ещё раз exec() - то всё, все плюсы знания об источнике запуска бинаря зануляются.

Так что, если есть желание иметь достаточную инфу для анализа взломов - то придётся много логировать, вести аудит действий, чтобы все [стрёмные] exec()и писались.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 23-Фев-17 10:12 
Надоело спорить, у тебя слишком много повторяющейся простыни. Почитай man 2 prctl PR_SET_MM_EXE_FILE для интереса. Ты отчасти прав и не прав, есть еще копия exe_file в виде vm_file. Ни к exe_file, ни к vm_file API нет. Все через procfs.

"Релиз ядра Linux 4.10"
Отправлено Анонимм , 23-Фев-17 11:11 
> Надоело спорить

Дело сугубо добровольное.
Но лично мне было полезно.

> Почитай man 2 prctl PR_SET_MM_EXE_FILE для интереса.

О как. Спасибо за наводку.


> Ты отчасти прав и не прав, есть еще
> копия exe_file в виде vm_file. Ни к exe_file, ни к vm_file
> API нет. Все через procfs.

Да, ФС proc нужна для посчупать процессы. Такой дизайн.
Все разные, не обязательно же следовать какому-то древнему принципу в каком-то одном из юниксов.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 23:40 
>отому что GNU/Linux не сохраняет нигде пути до экзешника и сам экзешник может быть удален напрочь (в отличие от винды, где это невозможно). Более того, места где сохраняется путь -- модифицируемы, что ведет к тому, что процесс невозможно отследить как надо.

Capabilities? Не, не слышал.
А привязыввается оно не к путям файлов, а к метаданным файла. И поэтому пофиг, куда там исполняемый файл переместили.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:02 
Пусть сперва реестр доделают.

"Релиз ядра Linux 4.10"
Отправлено chinarulezzz , 20-Фев-17 10:51 
>13.7% изменений внесено сотрудниками компании Intel, 7.1% изменений подготовлено сотрудниками Red Hat, 4.3% - Samsung, 3.9% - Linaro, 3.7% - SUSE, 3.0% - IBM, 2.5% - AMD, 2.4% - Google, 1.4% - Oracle, 1.4% - ARM.

}{акеры/энтузиасты/анонимы не подсчитаны? :'|


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 08:00 
~25%. Но это чуваки которые официально не указываются компанию. Часто бывает, что она там все-таки есть.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 11:02 
> решение проблемы с подвисаниями при интенсивном копировании на медленные USB-носители

Ааааааааа! Релиз достоин номера 5.0!

Вообще-то подвисания наблюдаются и на медленных HDD, так что радость может быть преждевременной.


"Релиз ядра Linux 4.10"
Отправлено llolik , 20-Фев-17 11:12 
Насколько я понял, там занимались проблемой с io в принципе, а не конкретно c USB.

"Релиз ядра Linux 4.10"
Отправлено leap42 , 20-Фев-17 12:51 
давно пора, а то стыд такой

"Релиз ядра Linux 4.10"
Отправлено h31 , 20-Фев-17 12:00 
> Добавлен драйвер для Amlogic Meson Graphic Controller, используемого в SoC GXBB/GXL/GXM;

Интересно. Никто не пробовал заводить upstream-ядро на Amlogic-девайсах?


"Релиз ядра Linux 4.10"
Отправлено iCat , 20-Фев-17 13:51 
> В CIFS добавлена новая опция монтирования "snapshot=время", позволяющая примонтировать прошлую версию внешнего раздела

Внезапно... Надо будет оценить...


"Релиз ядра Linux 4.10"
Отправлено Ilya Indigo , 20-Фев-17 16:38 
Сколько всего вкусного. Вот именно это ядро должно было стать LTS. ИМХО!
Хотя мне от этого не холодно ни жарко, так как я всегда использую последнее стабильное ядро.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 16:45 
WiFi для Raspberry Pi 3 сделали?

"Релиз ядра Linux 4.10"
Отправлено llolik , 20-Фев-17 18:27 
> WiFi для Raspberry Pi 3 сделали?

А оно разве не работало?
Я просто не в курсе, у меня с из под их Raspbian Wifi работает.


"Релиз ядра Linux 4.10"
Отправлено AlexYeCu , 21-Фев-17 22:28 
>WiFi для Raspberry Pi 3 сделали?

«Бортовой» wi-fi на малине работает ещё в 4.8 «из коробки». По крайней мере в Raspbian. Если в каких-то kodi- или retroarch- сборках с этим проблемы — это вопрос к рукожопости тех, кто эти сборки делает.


"Релиз ядра Linux 4.10"
Отправлено Sunderland93 , 20-Фев-17 16:59 
>> реализован режим атомарного переключения видеорежимов

Если я правильно понял, то этот Atomic Mode-Setting - более совершенная замена KMS. Это так?


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 21:58 
Что за "блобы"? У автора скудный словарный запас, не позволяющий описать ситуацию родным языком?

"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 22:40 
> Что за "блобы"? У автора скудный словарный запас, не позволяющий описать ситуацию
> родным языком?

Есть такая вещь как термины. Если вы читайте про ядро, то должны ими владеть.
PS. https://ru.wikipedia.org/wiki/%D0%91%D0%...


"Релиз ядра Linux 4.10"
Отправлено Kodir , 21-Фев-17 01:17 
Лажепедия - это для вас авторитет? Ну-ну...

Вместо мартышкинского "блоб" вполне можно применять "скомпилированный модуль" или просто "модуль", ибо суть одна.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 08:03 
> Лажепедия - это для вас авторитет? Ну-ну...
> Вместо мартышкинского "блоб" вполне можно применять "скомпилированный модуль" или просто
> "модуль", ибо суть одна.

лол, термин модуль здесь вообще не подходит.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 08:28 
> Вместо мартышкинского "блоб" вполне можно применять "скомпилированный модуль" или просто
> "модуль", ибо суть одна.

В контексте Linux Libre "скомпилированный модуль" - это _совсем_ не то. И в составе ядра никаких скомпилированных модулей нет и небыло (не путать со сторонними закрытыми драйверами, которые тоже блобы), а есть лишь местами вкрапления кусков машинного кода, загружаемого в аппаратные компоненты для обновления микрокода или как прошивки.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 20-Фев-17 23:48 
>Реализована технология виртуализации GPU Intel GVT-g для гипервизора KVM (KVMGT)

Вот самая киллеp-фича данного ядра. К сожалению, только для Intel video.


"Релиз ядра Linux 4.10"
Отправлено Аноним , 21-Фев-17 11:57 
>>Реализована технология виртуализации GPU Intel GVT-g для гипервизора KVM (KVMGT)
> Вот самая киллеp-фича данного ядра. К сожалению, только для Intel video.

думаю другие скоро подтянутся, так как это рынок виртуал десктоп. Его сейчас активно форсят корпорации.


"Релиз ядра Linux 4.10"
Отправлено th3m3 , 21-Фев-17 00:23 
>>решение проблемы с подвисаниями при интенсивном копировании на медленные USB-носители

Джва года ждал!


"Релиз ядра Linux 4.10"
Отправлено edo , 22-Фев-17 04:32 
> В сетевом стеке обеспечена поддержка маршрутизации сетевых пакетов с учётом UID-идентификатора процесса получателя или отправителя. Возможность перенесена из платформы Android, на которой используется для создания политик маршрутизации, привязанных к отдельным приложениям. Например, администратор теперь может использовать правила вида "ip rule add uidrange 100-200 lookup 123" для задания иных правил маршрутизации для процессов с UID c 100 по 200;

разве это не решалось через пометку (mark) в iptables?


"Релиз ядра Linux 4.10"
Отправлено Аноним , 23-Фев-17 08:22 
Может скажу не то, но знатоки меня поправят.

Цитата из текста - "Добавлена поддержка звуковых кодеков Cirrus Logic CS35L34/CS42L42, Cirrus Logic wm8581, Qualcomm MSM8916 WCD, Realtek rt5665;"

К чему всё это, если в со звуком в ЛИНУКСе не очень всё хорошо, ссылаясь на Пульс и Алса. К примеру, нет поддержки вывода звука в HD, а только AC3 и DTS, да и с поддержкой аппаратных и программных возможностей популярных звуковых карт очень скупо. Винда, к примеру, в этом плане пригодней будет - если собирать HTPC с оболочкой КОДИ и передачей звука и видео по HDMI к ресиверу.


"Релиз ядра Linux 4.10"
Отправлено Анонимм , 23-Фев-17 10:02 
Ну если можешь позволить себе держать на винде несекретные данные для заокеанских мягких контор - то может и попригодней

"Релиз ядра Linux 4.10"
Отправлено Аноним , 23-Фев-17 11:27 
Linux умеет выводить HDMI звук через Альсу лет 10 или 15 уже. В том числе из Kodi/Xbmc.

А тем временем в оффтопике добились состояния, что на некоторых стандартных мостах интеля USB порт без отдельного драйвера не работает )))


"Релиз ядра Linux 4.10"
Отправлено Аноним , 02-Апр-17 10:06 
Вранье в общем! Поставил последнее ядро 4.10.X, баг как был так и остался. Причем на 2х совершенно разных ноутбуках, один из которых вполне себе мощный. А после патча BFQ даже малейших признаков этого бага не видно было.

"Релиз ядра Linux 4.10"
Отправлено Аноним , 22-Окт-21 19:36 
Фиг там что исправили. Подвисания системы при записи на любой носитель всё ещё есть, даже BFQ не спасает... Неужели разработчикам ядра так пофиг на всех?! Ну невозможно же пользоваться нормально...