32-битного типа time_t

Это типа юникс тайм с 70-ых годов закончится? А почему бы не передвинуть 000000 с 70 годов на 2020 1 января и уже от него считать в 64 бит счётчиком секунд?

Еще MPTCP добавили. Только непонятно что значит начальная поддержка MPTCP.

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

Смысла уже нет 64 битного хватит на 292471208677 лет, чё мелочится и передвигать какие то пару-тройку десятков

Если уж на то пошло, то использование unsigned дало бы +68 лет, т.е. на 18 больше чем откатывать на 2020!

не факт

В Red Hat Enterprise Linux 9 могут отказаться от поддержки старых x86-64 процессоров.

Fedoroвцы во всю трудятся начиная с версии 32. Причина: Отказ от старых процессоров позволит задействовать более современные процессорные инструкции по умолчанию, что упростит процесс разработки и уменьшит «зоопарк» аппаратных решений. Также это стимулирует клиентов обновить свои системы.

Если уж на то пошло, то изначально была допущена фатальная ошибка в дизайне. Необходимо было просто использовать отдельные счётчики для секунд, минут, часов, месяцев и годов, тогда запросто хватило бы обычных unsigned short int.

я очень извиняюсь - а какое нам дело до воплей красношапочников?

Гостевые Linux-системы в VirtualBox могут монтировать папки, экспортированные хост-системой.

пффф, ФЭНОменальная новость!

Да поздно уже )) 64 бита зохавали мир

Я кстати не очень понимаю почему нельзя сделать структуру из двух 32битных полей. Оверхед, но зато обратная совместимость.

Встройка смотрит с недоумением. Особенно когда встройки очень много и никто резко не пойдет перепроектировать и перепаивать устройства. Там внутреннего таймера-то на это может и не быть, но сама система-то должна как-то считать время.

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

Да не и 8 битки и (не видал таких в быту кроме консолей) 16 битки и 32 битки никуда не денутся. Это я про массовость. А так ну где то на необслуживаемых системах обнулиться время )) Где то обновят либу и будет 64 битное время хоть на 32/16/8 машинках. В целом проблем нет если нет согласования встройки с внешним миром по времени. А если есть ну переполниться время и всё будет переполнение как триггер с новой точке отсчёта. Ой да вариантов 100500 всё нормально будет.

Т.е. полноценной реализации в 5.6 не появится ?

Также это стимулирует клиентов обновить свои системы.

О да, это прорыв...

Блокирующий пул /dev/random был удалён, теперь /dev/random поведением более похож на /dev/urandom тем, что не блокирует доступную энтропию после инициализации пула.

Интересно, что это занчит.

USB4 и Thunderbolt там запилили. Странно, что упоминания об этом нет в числе главных нововведений.

А вот эта вот ZoneFS, это как понимать? из опеннетовского описания не понял, а тут вообще кратенько :) можете для глупенького объяснить?

Серьезно, ни слова про wireguard в основных изменениях?

Поддержка Intel MPX (memory protection extenstion) удалена из ядра.

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

новость позорно написана

Завершён перевод ядра с 32-битного типа time_t и ассоциированых с ним типов: ядро готово к проблеме-2038.

Добавлена поддержка копирования файлов с сервера на сервер в NFS v4.2

Ну наконец-то!

«П» значит «партнёрство»!

FS для некоторых новых винтов (как я понимаю Shingled Magnetic Recording) на кторых скорости доступа/чтения-записи различаются в разных областях диска - что-то подобное наблюдается на обычных жд, чтение-запись быстрее в начале диска чем в конце - но в случае SMR различия более весомы

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

Я, например, до сих пор иногда играю в Linux с помощью DosBox в игры: Quake, Karateka, Aladdin.

Сие называется так: https://www.linux.org.ru

Подача новости скверная.

Wireguard?

Usb4?

sch_ets?

Не понял как температуру HDD через sysfs стало можно посмотреть?
Не нахожу что-то.

хорошо, что всякий шлак удалять из ядра или отключают. Спасибо Линусу за ведро!

Основные изменения:

Поддержка Intel MPX (memory protection extenstion) удалена из ядра. 

а википузия грит:

https://ru.wikipedia.org/wiki/Intel_MPX

Поддержка удалена в версии ядра 4.20 (24 декабря 2018)

Как так?

для тебя это удаление ничего не даёт и никак не заметно

загрузи модуль и смотри как обычный сенсор

++

всё жирнее и жирнее

во, карантин пошёл на пользу, хоть новость о ядре запилили, ни как обычно.

Добавлена поддержка копирования файлов с сервера на сервер

Что это значит? Точнее в чем разница между копированием на клиент?

перевод ядра с 32-битного типа

Скажите, когда официально умрут 32-разрядные системы?
В каком году это свершиться?

Использовал без проблем с rc2. Настолько сильно хотелось ядерный вайргард. Накатил релиз — отвалился вайфай. Модуль грузится, интерфейс есть, к точке доступа не коннектится.

Это для pnfs. Ты можешь сказать серверу s1 скопировать данные на сервер s2, и он это может сделать по быстрому интерлинку, без участия клиентов.

Серьезно, ни слова про wireguard в основных изменениях?

Кстати, да. Пожалуй самая ожидаемая «фича».

На опеннете есть. Это здесь новости эталонные слоупоки пишут, с запаздыванием на 2-3 недели.

Накатил релиз — отвалился вайфай. Модуль грузится, интерфейс есть, к точке доступа не коннектится.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Broken-Intel-IWLWIFI

Постесняюсь спросить. А чем так замечателен Ку1 в ДосБоксе по сравнению с тем же DarkPlaces? Ну разве что кроме отсутствия пакета под ваш дистр + сильно другая архитектура машины.

Может это межсерверный какой пирингофайлоперенос? Чисто предположение навскидку.

Короче изобрели direct copy ) Кстати относительно недавно и для SSH такое сделали

Server-side copy там давно был. Это копирование именно между серверами.

Ждём RT

Что-то зачастили они. Или я раньше не обращал внимания?

Да, оно. Помогло, спасибо.