The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз ядра Linux 6.11"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз ядра Linux 6.11"  +/
Сообщение от opennews (??), 16-Сен-24, 13:44 
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.11. Среди наиболее заметных изменений: поддержка операций атомарной записи на уровне блочных устройств, поддержка операций bind() и listen() в io_uring, новый  механизм блокировок программных обработчиков прерываний, возможность записи в отзеркаленные в память исполняемые файлы, поддержка написания драйверов блочных устройств на языке Rust, оптимизация вызова getrandom(), новая реализация AES-GCM...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=61869

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


2. Скрыто модератором  +55 +/
Сообщение от Аноним (2), 16-Сен-24, 13:46 
Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (4), 16-Сен-24, 13:51 
В Fedora 41 пока rc7.
Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз ядра Linux 6.11"  +3 +/
Сообщение от Аноним (16), 16-Сен-24, 14:36 
И что? Типа ты устал ждать или что?
Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (126), 16-Сен-24, 21:18 
Отстают. Непорядок
Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (16), 16-Сен-24, 14:38 
Ну поставь тестовое, если тебе срочно надо
https://bodhi.fedoraproject.org/updates/FEDORA-2024-7f71b5938b
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

25. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 16-Сен-24, 14:48 
> В Fedora 41 пока rc7.

Компильнуть ядро самому, юзанув конфиг дистра от соседнего RC - много ума не требует, если что. Даже на странные вопросы не придется отвечать.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

37. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Минона (ok), 16-Сен-24, 15:00 
Не юзерское это дело — компилять.
Ответить | Правка | Наверх | Cообщить модератору

40. "Релиз ядра Linux 6.11"  +4 +/
Сообщение от КО (?), 16-Сен-24, 15:04 
Так юзеры то линуксом и не пользуются
Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Минона (ok), 16-Сен-24, 15:20 
Видимо пользуются.
Вон в убунте своп починили, не прошло и пары недель.
Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз ядра Linux 6.11"  +/
Сообщение от eugener (ok), 16-Сен-24, 15:47 
а что там было со свопом?
Ответить | Правка | Наверх | Cообщить модератору

59. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (59), 16-Сен-24, 16:37 
поломался
Ответить | Правка | Наверх | Cообщить модератору

134. "Релиз ядра Linux 6.11"  +/
Сообщение от Минона (ok), 16-Сен-24, 21:40 
Заполнялся на 100%, за 10-20 минут.
Причём чем больше оперативы у сервера тем быстрее.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

62. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Те самые 4 (?), 16-Сен-24, 16:44 
А зачем сейчас нужен своп? Не на пентиуме, в смысле.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

64. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (-), 16-Сен-24, 16:50 
> А зачем сейчас нужен своп? Не на пентиуме, в смысле.

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

Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (65), 16-Сен-24, 17:20 
А некоторые люди не могут без тёплого и не знают, что есть такая штука, как мягкое.
Ответить | Правка | Наверх | Cообщить модератору

135. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Минона (ok), 16-Сен-24, 21:44 
А swap в zram это не swap?
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

165. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 07:41 
> А swap в zram это не swap?

Это по сути сжатая оперативка. Технически тоже типа-своп, но то что он в сжатой RAM с одной стороны экономит RAM сжатием "cold" страниц, а с другой - радикально решает вопрос с тормозами и лагами. Особенно с быстрым сжатием типа LZ4 или LZO+RLE. При допустим OOM - система лишь на несколько секунд проседает, и все. А с более обычным свопом - на SSD это дико протирает SSD. На HDD это дико тормозит. А оперативка и быстрая, и не протирается. А неактивных страниц - отыгрывает место в RAM в пользу чего-то более полезного.

И в этом смысле - я вообще не понимаю тех кто еще почему-то не выкинул свопы на storage device.

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз ядра Linux 6.11"  +3 +/
Сообщение от Аноним (127), 16-Сен-24, 21:19 
Да своп при 16 физических гигах иногда нужен. Да, опять же, чтоб компилять всякие Расты.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

176. "Релиз ядра Linux 6.11"  +/
Сообщение от tty2 (?), 17-Сен-24, 08:50 
Да своп и при 64ГБ часто нужен. И сжимать его при этом - дичь бессмысленная. ООМ менеджер тут только поможет.
Ответить | Правка | Наверх | Cообщить модератору

180. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 09:00 
> Да своп и при 64ГБ часто нужен. И сжимать его при этом
> - дичь бессмысленная. ООМ менеджер тут только поможет.

А своп при этом зачем? А, чтобы до того как OOM манагер активируется - потормозить? :)

Ответить | Правка | Наверх | Cообщить модератору

194. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (194), 17-Сен-24, 14:13 
а если OOM манагер не активировался, то в случае без свопа типа не тормозит?

Своп служит для выгрузки из памяти того, что сейчас не очень нужно. Не все программы написаны хорошо и не у всех память хорошо сжимается.
oom-killer/earlyoom/cgroups вещи хорошие, но иногда бывает нужно чтобы процесс таки выдал результат

Ответить | Правка | Наверх | Cообщить модератору

199. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:15 
> а если OOM манагер не активировался, то в случае без свопа типа не тормозит?

Прикинь, при этом ядерный OOM killer придет и через пару секунд пристрелит runaway жирдяя.

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

Zram для этого лучше: если оно все ж понадобится, декомпреснуть пагу сжатую LZ4 или LZO+RLE много времени не займет, а при душняке это лишь немного просаживает перфоманс активным сжатием, но не протирает SSD и тем более не тупит что капец механическим винчом. RAM быстрый и без ограничений перезаписи.

> Не все программы написаны хорошо и не у всех память хорошо сжимается.

Чисто статистически "холодная" память сжимается весьма прилично. Там часто всякий uninitialized типа нолей, потому и "LZO + RLE" например.

> oom-killer/earlyoom/cgroups вещи хорошие, но иногда бывает нужно чтобы процесс таки выдал результат

Ну так есть настройка OOM score adjust. А кроме результата есть еще время за которое он получен.

Ответить | Правка | Наверх | Cообщить модератору

210. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (194), 17-Сен-24, 20:00 
> Прикинь, при этом ядерный OOM killer придет и через пару секунд пристрелит runaway жирдяя.

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

> Zram для этого лучше: если оно все ж понадобится, декомпреснуть пагу сжатую LZ4 или LZO+RLE много времени не займет

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

> Чисто статистически "холодная" память сжимается весьма прилично. Там часто всякий uninitialized типа нолей, потому и "LZO + RLE" например.

или неприлично. Там вполне может быть "инициализированная" память, просто внутри программы она управляется кривым аллокатором, который еще и уплотнять не умеет или не может

> Ну так есть настройка OOM score adjust.

а чем она поможет? На диске я могу своп на десятки гигабайт сделать, а для zram больше объема оперативки я выделить не смогу. Да, у zram есть backing_dev, но мы ведь своп отключили, чтобы на диск не писать

> А кроме результата есть еще время за которое он получен.

там еще есть сумма, которую готовы потратить на апгрейд, замену софта, переписывание и пр.

Ответить | Правка | Наверх | Cообщить модератору

211. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (-), 17-Сен-24, 21:00 
> или не придет. Периодически вижу тормозящие безсвоповые виртуалки, а все потому что
> ядро умеет выгружать "неизменные" страницы из памяти, которые можно потом подрузить
> с диска — например код библиотек, не нужных для процессов, исполняющихся в данный момент

Этот эффект и правда иногда возможен, но только в каких-то специфичных дурацких случаях. Когда это что-то типа механики, душняк с RAM не только в гуесте но и у хоста, так что там буфера IO не было. При более-менее обычной эксплуатации виртуалок я ЭТО не вижу - и поэтому вон теми извратами с oomd и проч не парился. При явном runaway - oom killer быстро порядок наводит, а в штатном виде у меня VM с "mem pressure" ессно не работают. Дико оверселлить сам себе с ущербом user experience я ессно не собираюсь :)

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

Проблема в том что тут заранее неизвестно что и как - и можно получить и неприличные времена отклика, и печальный перфоманс. Мне такое нахрен надо. Особенно - на моем десктопе. Ух да, я на нем виртуалки тоже гоняю. В одной из - я с вами и треплюсь. Такой самопальный аналог cubeos.

> Но вот если в своп выгружаются данные, к которым часто обращаются, то тут уже точно
> памяти недостаточно

Да. И я просто не практикую крейсерскую работу с душняком памяти. На этом даже ZRAM начнет протуплять из-за компрессии. Фатально конечно не заклинит, на минуты, но скорость работы просядет.

> или неприлично. Там вполне может быть "инициализированная" память, просто внутри программы
> она управляется кривым аллокатором, который еще и уплотнять не умеет или не может

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

>> Ну так есть настройка OOM score adjust.
> а чем она поможет? На диске я могу своп на десятки гигабайт сделать,

Только вот worst case этого свопа - жесткий выстрел себе в пятку. Если его весь удумать поюзать - это будет медленно и печально. А пристрелить runaway процесс раньше его заполнения видимо не вариант, если такой ужас отрастили.

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

> а для zram больше объема оперативки я выделить не смогу.

И тем не менее, это x2 или x3 от выделенного объема, если сжатие прокатило. Т.е. условно выделенные 5 гигов смогут вместить 10...15гиг холодных страниц. Десятки гигов на механике? Упаси меня, я не маклауд. На SSD? Ну он до дыр при случае протрется влет.

> Да, у zram есть backing_dev, но мы ведь своп отключили, чтобы на диск не писать

Zram это сжатый блочный девайс в оперативе... в принципе туда даже можно и не своп класть, в общем то.

>> А кроме результата есть еще время за которое он получен.
> там еще есть сумма, которую готовы потратить на апгрейд, замену софта, переписывание и пр.

А еще есть user experience. Ну да, можно таскать 100 тонн из пункта A в пункт B клячами на деревянных телегах. Но, вероятно, фурами или поездом это было бы все же эффективнее. Если уж такая задача есть.

Ответить | Правка | Наверх | Cообщить модератору

212. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (194), 18-Сен-24, 00:20 
> Этот эффект и правда иногда возможен, но только в каких-то специфичных дурацких случаях.

например если покрутить рекомендованный OOM score adjust? :)
Мы не крутили, но наши программисты умеют писать так, чтобы этот эффект проявлялся хеть на виртуальном, хоть на железном сервере.

> Проблема в том что тут заранее неизвестно что и как

в этом в принципе проблема спора про нужность свопа. Все сильно зависит от запущенных процессов и настроек хоста — можно получить отстрел ненужных процессов и жить дальше, а можно получить тормоза там, где со свопом бы и пожили еще

> Фатально конечно не заклинит,

а если не угадал со степенью сжатия и резервированием памяти, то еще и ошибки записи начнет кидать

> А пристрелить runaway процесс раньше его заполнения видимо не вариант, если такой ужас отрастили.

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

> Вот именно несжимаемые данные, именно в оперативе - все-же довольно экзотичный сценарий

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

> Zram это сжатый блочный девайс в оперативе... в принципе туда даже можно и не своп класть, в общем то.

я знаю что это. А backing_dev это обычный несжатый блочный девайс, куда zram может записывать то, что не сжимается или к чему не было обращений

> А еще есть user experience.

и так можно дальше продолжать, потому что много чего есть :)

Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

220. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 18-Сен-24, 09:38 
>> Этот эффект и правда иногда возможен, но только в каких-то специфичных дурацких случаях.
> например если покрутить рекомендованный OOM score adjust? :)

Оказывается, если захотеть прострелить пятку, может получиться и будет больно. Какая неожиданность! Вон то надо не для того чтобы пытаться нарисовать оперативку которой нет. А для того чтобы маркировать более критичные задачи и менее критичные, которые допустимо убивать раньше. Если вы пользовались этим для чего-то другого - кто вам доктор?

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

С SSD под систему оно вообще не есть проблема - и скорее фича: readonly быстрый своп, который не протирает диск. На механике... ох, кто ж держит ос нынче на механике? Мазохисты которым перфоманс и латенси ОС совсем похрен? Ну раз похрен, о чем мы говорим?

>> Проблема в том что тут заранее неизвестно что и как
> в этом в принципе проблема спора про нужность свопа. Все сильно зависит
> от запущенных процессов и настроек хоста — можно получить отстрел ненужных
> процессов и жить дальше, а можно получить тормоза там, где со
> свопом бы и пожили еще

И именно поэтому настройки и есть. Но в большинстве случаев, своп, особенно на механике, на данный момент - таки, архаизм. А на SSD это может быть круто и быстро, но write amplification может быть конский и при неудачном раскладе SSD может быстро дать дуба. А учитывая как это выглядит - потом еще и данные будут заср@ны нафиг если не повезло.

>> Фатально конечно не заклинит,
> а если не угадал со степенью сжатия и резервированием памяти, то еще
> и ошибки записи начнет кидать

Я не знаю что для этого с ZRAM надо сделать. Вы им точно пользовались, и ни с чем не путаете? Ибо я никогда ЭТО не видел за все время его эксплуатации, на СОТНЯХ разных штук. С довольно разными параметрами. В системах с ZRAM - обычено просто OOM наступает при душняке памяти. Приходит OOM killer, прибивает что-нибудь. И все. А чтоб кернел не смог себе память аллоцировать - ну вот нет, он, имхо OOM killer при этом как раз и вызовет.

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

Вот тут я ничего полезного не скажу. Мой passion - быстрые, предсказуемые, low latency системы. Своп, особенно большой и на механике, враг номер 1 этих начинаний. Он был быстро идентифицирован - и аннулирован как класс. Везде. А для холодных страниц, вот, zram. Такой RAM doubler/tripler. Что надо писать в RAM чтобы это не жалось - не знаю, я пробовал zram на всем, от мегасерверов до эмбедовки и роутеров-мыльниц с 32 мег на все. Оно всегда давало нехилый выигрыш. Так что для меня это весьма теоретический сценарий, если вы не можете назвать воспроизводимые задачи где это реально увидеть "в интерьере". На практике в всех опробованых мной случаях RAM нехило жалась. Там правда есть ограничения - для скорости парсинга, пага должна сжаться в 2 (или опционально 3) раза. Если меньше, не считается, сохранится несжатой. Но как я сказал в всех случаях которые я опробова это работало на ура. И я не знаю что надо в RAM напихать чтобы он плохо жался. Системы ворочающие откровенным рандомом, оптом - ужасная экзотика.

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

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

> я знаю что это. А backing_dev это обычный несжатый блочный девайс, куда
> zram может записывать то, что не сжимается или к чему не
> было обращений

А, тут я тупанул. Я этим никогда не пользовался - ибо "defeats whole point". Потому что IO в блочный девайс - аннулирует все бенефиты ради которых я упирался. И ведет либо к малопредсказуемому протиранию флешатины, либо к факапам латенси на механике. And we're back to square one.

>> А еще есть user experience.
> и так можно дальше продолжать, потому что много чего есть :)

Вообще - да. Но нагрузки с несжимающейся оперативкой и тому подобное - это все же какая-то весьма специфичная экзотика. Как будто кто-то попытался откосплеить кастомный кеш. И вообще-то если они это полезли делать - ну, могли бы попытаться пользоваться Pressure Stall Information-ом например. Правда все равно франкенштейн типа ZFS получится. Но лучше чем совсем нифига реакции на душняк оперативы. PSI на какие-то вот такие странные случаи и сделали по большому счету.

Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

222. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (194), 18-Сен-24, 10:41 
> Я не знаю что для этого с ZRAM надо сделать.

несколько версий хрома при автотестах сильно текли пустыми страницами и zram жал это дело в сотни тысяч раз. А потом что-то исправили и хром потек по настоящему, а выделенной под zram памяти не хватило, т.к. никто на такое не рассчитывал

> И чтобы вон то получить - это надо чуть ли не самому накодить нечто типа кэша, забить чем-то сжатым надолго.

достаточно чтобы сборщик мусора не затирал нулями память, которую отдал код. В многопоточных скриптах при интенсивной работе с памятью может получиться (при использовании malloc из glibc), что памяти выделяется гораздо больше чем нужно и она забита мусором. А сборщик мусора память системе часто не возвращает (например потому что указатель на область памяти можно передать в модуль на С, а значит объединить несколько страниц в одну и отдать лишнее нельзя)

Ответить | Правка | К родителю #220 | Наверх | Cообщить модератору

245. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 21:11 
> несколько версий хрома при автотестах сильно текли пустыми страницами и zram жал
> это дело в сотни тысяч раз. А потом что-то исправили и
> хром потек по настоящему, а выделенной под zram памяти не хватило,
> т.к. никто на такое не рассчитывал

А zram то тут чем виноват, интересно? Он кстати более 2 или 3 в 1 всяко не могет, насколько я помню, ибо в сжатом варианте должно быть целое число страниц. Для упрощения и ускорения менеджмента оных.

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

В 2 раза в пределах паги даже это может сжаться. Особенно чем-то типа zstd. А так - никто не обещал что average и worst case это 1 и то же.

> В многопоточных скриптах при интенсивной работе с памятью может получиться
> (при использовании malloc из glibc), что памяти выделяется гораздо больше чем нужно и
> она забита мусором.

Такое ощущение что кое-кто на самом деле - другой аллокатор памяти на самом деле хотел.

> А сборщик мусора память системе часто не возвращает
> (например потому что указатель на область памяти можно передать в модуль
> на С, а значит объединить несколько страниц в одну и отдать
> лишнее нельзя)

Ну понятно. Так то я не настаивал что zram всенепременно серебряная пуля. Это было бы слишком хорошо чтобы быть правдой. Но для меня он оказался на удивление близок к этой точке. И я теперь в принципе не юзаю свопы на сторажах.

Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

111. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (111), 16-Сен-24, 20:30 
>Так юзеры то линуксом и не пользуются

Тот случай, когда Капитан очевидность ошибается.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

166. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 07:45 
>>Так юзеры то линуксом и не пользуются
> Тот случай, когда Капитан очевидность ошибается.

Значит это был не Капитан Очевидность а всего лишь Спиди Гонщик.

Ответить | Правка | Наверх | Cообщить модератору

54. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (54), 16-Сен-24, 16:29 
> Не юзерское это дело — компилять.

Если кто -RC юзает, он, вероятно уже не совсем юзер...

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

142. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Igor (??), 16-Сен-24, 22:22 
Так Федора-41 сама еще не вышла!
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

154. "Релиз ядра Linux 6.11"  +/
Сообщение от Xvig (?), 16-Сен-24, 23:28 
Завтра 17 сент. будут объявлено о выходе Fedora 41 beta. Скачать оригинальный образ можно уже сейчас https://dl.fedoraproject.org/pub/alt/stage/41_Beta-1.2/Works...
Ответить | Правка | Наверх | Cообщить модератору

153. "Релиз ядра Linux 6.11"  +/
Сообщение от Xvig (?), 16-Сен-24, 23:26 
Уже обновили.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

160. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (160), 17-Сен-24, 04:12 
Накой черт они юзают rc? Чем им 6.10 то не угодил?)
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

15. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (15), 16-Сен-24, 14:34 
что там по rust нового в ядре ?
Ответить | Правка | Наверх | Cообщить модератору

18. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Аноним (16), 16-Сен-24, 14:39 
Как обычно мало.
Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Аноним (21), 16-Сен-24, 14:44 
Пока что. Медленно но верно.
Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (21), 16-Сен-24, 14:58 
Собаки лают, а караван идёт!
Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз ядра Linux 6.11"  +/
Сообщение от IdeaFix (ok), 16-Сен-24, 15:03 
Да ладно, всё достойно - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... вроде и не сделали ничего и не сломали.
Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз ядра Linux 6.11"  +/
Сообщение от Минона (ok), 16-Сен-24, 15:12 
Даже без unsafe написали.
Ответить | Правка | Наверх | Cообщить модератору

146. "Релиз ядра Linux 6.11"  +6 +/
Сообщение от Шарп (ok), 16-Сен-24, 22:50 
>_disk: Pin<Box<Mutex<GenDisk<NullBlkDevice>>>>

Это превосходно. Ещё чуть больше угловых скобочек и получится brainfuck.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

196. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Минона (ok), 17-Сен-24, 14:36 
>>_disk: Pin<Box<Mutex<GenDisk<NullBlkDevice>>>>
> Это превосходно. Ещё чуть больше угловых скобочек и получится brainfuck.

(Pin(Box(Mutex(GenDisk NullBlkDevice))))
Вот так приятнее ;)

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (59), 16-Сен-24, 16:37 
Боты также смуту рекламировали, а потом их вк забанил)
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

67. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (21), 16-Сен-24, 17:22 
И правильно, не нужно рекламировать в ВК всякие оппозиционные идеи.
Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (94), 16-Сен-24, 19:27 
Что в этой игре оппозиционного?
Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (111), 16-Сен-24, 20:31 
Хочется спросить, а где в Смуте геймплей?
Ответить | Правка | Наверх | Cообщить модератору

162. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Афроним (?), 17-Сен-24, 06:35 
Это как и та чешская Kingdom Come: Deliverance, а не Ведьмак, но вам ведь все равно.
Ответить | Правка | Наверх | Cообщить модератору

262. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (262), 20-Сен-24, 15:54 
и та и та игра про злых поляк. но есть ньюанс...
Ответить | Правка | Наверх | Cообщить модератору

161. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Омномнимус (?), 17-Сен-24, 06:27 
В случае с растом лает караван, а не собаки.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

208. Скрыто модератором  +/
Сообщение от Аноним (208), 17-Сен-24, 18:53 
Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (21), 16-Сен-24, 14:59 
В статье 9 упоминаний про rust, вам этого мало?
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

84. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (84), 16-Сен-24, 18:28 
Мало. Нужно стремиться все ядро на rust переписать. Безопасности много не бывает
Ответить | Правка | Наверх | Cообщить модератору

130. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (127), 16-Сен-24, 21:31 
Ну это слишком долго. Когда будет совсем почти готово, ядро Linux станет просто морально устаревшим. Поэтому лучше в каждую подсистему добавить по своему CoC.rs, так быстрее.
Ответить | Правка | Наверх | Cообщить модератору

31. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (21), 16-Сен-24, 14:56 
Самое глазное что % rust растёт!
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

32. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (21), 16-Сен-24, 14:57 
Нужно дожать линук ядро до 100%
Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (127), 16-Сен-24, 21:33 
Лучше Redox дожмите.
Ответить | Правка | Наверх | Cообщить модератору

178. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:54 
> Нужно дожать линук ядро до 100%

Двуногие столько на этом глобусе, увы и ах, не живут. Так что сишка вас совершенно точно переживет. Скриньте, и - когда соберетесь на кладбище - вспомните эти слова.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

185. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Аноним (185), 17-Сен-24, 11:51 
Кобол передает привет)
Сейчас никто в здравом уме, на дыряшки писать новые проекты не будут.
Как минимум возьмут C++.

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Наноним (?), 16-Сен-24, 16:16 
Ещё не выпилили, к сожалению
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

87. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от xsignal (ok), 16-Сен-24, 18:55 
/dev/null переписали =)
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

138. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Минона (ok), 16-Сен-24, 21:55 
В 6.12 перепишут /dev/hand и дальше все пойдёт семимильными шагами 😉
Ответить | Правка | Наверх | Cообщить модератору

209. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от AKRemail (ok), 17-Сен-24, 19:21 
Всё уже можно не переходить :)
17.09    C++ Alliance продвигает в C++ механизмы безопасной работы с памятью, опробованные в Rust
https://www.opennet.me/opennews/art.shtml?num=61878
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

26. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Гиде (-), 16-Сен-24, 14:48 
Не вижу изменений для лучшей в мире ФС Ext2.
Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Минона (ok), 16-Сен-24, 15:02 
Она идеальна!
Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (-), 16-Сен-24, 16:36 
> Не вижу изменений для лучшей в мире ФС Ext2.

Она окончательно застабилизировалась, присоединившись в софтварной валхалле^W^W ну или где там к всяким MSDOS, FAT, командиру нортону и тому подобному софту.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

68. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (21), 16-Сен-24, 17:26 
Зачем, если уже есть ext4? Какие ваши аргументы?
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

91. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Аноним (-), 16-Сен-24, 19:12 
Во второй версии нет журналиврования, и поэтому чтение и запись файлов будет идти быстрее, но при сбоях нежурналируемая ФС будет терять данные. Мне кажется быстрота не преимущество.
Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (112), 16-Сен-24, 20:30 
> Во второй версии нет журналиврования, и поэтому чтение и запись файлов будет
> идти быстрее, но при сбоях нежурналируемая ФС будет терять данные. Мне
> кажется быстрота не преимущество.

Учитывая что в именно классическом понимании EXT2 также нет экстентов и HTREE (индекс дир) - сказ о его производительности несколько преувеличен.

Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (121), 16-Сен-24, 21:07 
Так выруби журнал у ext4
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

164. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 17-Сен-24, 06:52 
Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (167), 17-Сен-24, 07:51 
> Так выруби журнал у ext4

Выруби журнал у ext4 - и получи нужду гонять fsck после каждого краха на эн-терабайтном томе в подарок!

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

216. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (160), 18-Сен-24, 04:05 
Как у ext2 зато)
Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (127), 16-Сен-24, 21:36 
Флешка с поддержкой Unix Rights. Журнал на.рен ненужен, даже вреден.
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

179. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:58 
> Флешка с поддержкой Unix Rights. Журнал на.рен ненужен, даже вреден.

А ничего что флешки порой сдуру как раз дергают без отмонтирования? Потом fsck чтоли там каждый раз гонять? Или гадать когда именно она крякнет от неконсистентности метаданных? Да вы издеваетесь?!

Если уж такое хочется - btrfs можно распихать туда. Ему во всяком случае fsck не требуется после краха. И журнала в том его понимании можно считать что нет.

Ответить | Правка | Наверх | Cообщить модератору

189. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (189), 17-Сен-24, 12:32 
А ничего, что журнал сокращает жизнь флешки?
У тех, кто сдуру дёргает без отмонтирования, на флешках FAT32.
Ответить | Правка | Наверх | Cообщить модератору

193. "Релиз ядра Linux 6.11"  +/
Сообщение от maximnik0 (?), 17-Сен-24, 13:22 
>А ничего, что журнал сокращает жизнь флешки?

Хм, смотря какая флэшка и какая фс.Если флэшка  с умным контроллером ,при условии что фс используется классический журнал ,то не сильно ресурс то и сокращает - там для часто переписываемых блоков контроллер производит подмену на альтернативные блоки.Иногда даже ext4 оказывается предпочтительней чем btrfs,т.к у бтрфс бывает слишком много мелких операций в метаданных ( по крайней мере китайцы на ноутбуки с флэшкой используют ext4) .А с другой стороны f2fs использует распределенные дерево и COW транзакции - но не кто не кричит что эта фс убивает флэшки , наоборот она проектировалась для флэшек.

Ответить | Правка | Наверх | Cообщить модератору

201. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:22 
>>А ничего, что журнал сокращает жизнь флешки?
> Хм, смотря какая флэшка и какая фс.Если флэшка  с умным контроллером
> ,при условии что фс используется классический журнал ,то не сильно ресурс
> то и сокращает -

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

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

Тем не менее новые записи идут в новые локации - и кроме всего прочего это несколько ослабляет вопросы к wear leveling.

> другой стороны f2fs использует распределенные дерево и COW транзакции - но
> не кто не кричит что эта фс убивает флэшки , наоборот
> она проектировалась для флэшек.

F2FS довольно странная штука. Особенно в плане реакции на power loss.

Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз ядра Linux 6.11"  +/
Сообщение от maximnik0 (?), 18-Сен-24, 01:06 
>F2FS довольно странная штука. Особенно в плане реакции на power loss.

Не довели до ума оптимизации , некоторые китайские приставки с этой фс- спокойно десятки раз рестарты переносят и не умирает фс:-( Производителям оказалось проще повесить контроллер на флэшку и использовать более простые фс, или вообще без фс, использовать флэшку как блочное устройство.Может сообщество и заинтересовалось бы этой фс- всё-таки она неплохо на обычных жёстких работает,но нет контрольной суммы для данных:-( ,а так была бы альтернатива btrfs.

Ответить | Правка | Наверх | Cообщить модератору

221. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 18-Сен-24, 10:08 
>>F2FS довольно странная штука. Особенно в плане реакции на power loss.
> Не довели до ума оптимизации , некоторые китайские приставки с этой фс-
> спокойно десятки раз рестарты переносят и не умирает фс:-(

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

А у меня он таки при powerloss test'ах быстро отлетел в страну вечной охоты, максимально дурным способом, когда уже не маунтится ядром, но еще не чинится fsck,что хотите то и делайте (я пробурчал "как хорошо что это был ТЕСТОВЫЙ конфиг" и списал его в утиль, но это работает только с ТЕСТОВЫМИ сетапами :D). В этом смысле даже новомодный bcachefs - ни разу насовсем не сдох при дерганиях питания.

А так - ну да, шустренький, для флеша удобный. Но вот висит на вечно замордованом Jeon на котором еще ksmbd и ExFAT. Это перебор для 1 кодера, даже прошареного, и у всех трех в итоге "software quality problems" чаще всего проявляющиеся в багах, вулнах и странной реакции на краевые условия и необычные ситуации.

> вообще без фс, использовать флэшку как блочное устройство.Может сообщество и заинтересовалось

С этим есть определенный облом. NAND, особенно высокоемкий, это просто брейнфак. Там и bad block management - при том сразу с фабы идет с дефект листом, и резерв блоков надо, и ECC, а еще там "read disturbance" и потребна регенерация если регион много ЧИТАЛИ (почти как DRAM). Разборчивость к паттернам - повторящийся паттерн взаимодействует с соседними ячейками и перекашивает чтение, когда хочется 16 уровней на ячейку различать (QLC) это эвон какой аргумент! И это надо FTL от и до накодить. UBIFS так то - пытался, но реально он ок для SLC NAND, а с большими костылями - можно на 2-level MLC по граблям попрыгать, но не рекомендуется.

> бы этой фс- всё-таки она неплохо на обычных жёстких работает,но нет
> контрольной суммы для данных:-( ,а так была бы альтернатива btrfs.

Btrfs в том взаимодействии забавен тем что как бы доделывает собой неважно работавшую часть типа кривоватого wear leveling'а. А вот целиком FTL в фс засунуть... это несколько экстрим. Попробуй раз в жизни сам сделать образ чему-нибудь с хотя-бы SLC и записать его - поймешь в чем прикол. Даже в UBI придется ответить на довольно забавные вопросы. С какого числа записией начинать wear level? Сколько блоков - в резерв? И так далее. Все еще выглядит как "просто блочный девайс"? Хотя честно говоря если бы ubi умел вывешивать себя как generic блочный девайс, делая ECC/remap/etc было бы забавно. Но это сложно. И там траблы с например масштабированием. Частично решены, но не 100%. Скажем сканить огромный флешак на метки bad блоков в его eraseblocks - долго. Надо каие-то свои структуры из этого отстраивать. Иначе монтирования фс в 100500 гигз не дождешься. Тем не менее Zoned - это шаг в ту сторону. Он может как для черепицы применяться, так и для флешовых штук, более явно вывешивая топологию флеша.

Ответить | Правка | Наверх | Cообщить модератору

224. "Релиз ядра Linux 6.11"  +/
Сообщение от maximnik0 (?), 18-Сен-24, 11:44 
> сканить огромный флешак на метки bad блоков в его eraseblocks -
> долго. Надо каие-то свои структуры из этого отстраивать. Иначе монтирования

Я видел  компьютер для  видиомонтажа ,там задолго до бума М2 накопителей стоял интересный агрегат - но стоил он просто космических денег - 5,25 внутренний 2й по высоте sata !!! флэш накопитель на 2 тб,софт для монтажа шел в "подарок".Так там софт писал на него как Raw накопитель (офтопик 7 там стояла), явно было на уровне железа  FEC  и куча резерва .Сервисная утилита показывала что на 6 год службы  вылетело 4 микросхемы и не каких проблем,ещё было в запасе если не ошибаюсь было 3 штуки,данные даже не терялись.Я не думаю что нету современного такого железа или уже разучились делать качественные вещи ?

Ответить | Правка | Наверх | Cообщить модератору

246. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 21:56 
> него как Raw накопитель (офтопик 7 там стояла), явно было на
> уровне железа  FEC  и куча резерва .

FEC на уровне железа есть всегда, что у хардов, что у флеша. И так уже много лет. 4K сектора появились в угоду улучшения соотношений FEC (так % оверхеда ниже). NAND - подразумевает FEC, там стандартно есть OOB area вне основного сектора, спецом для. Очень радует в паре с менеджментом дефектов тех кто хочет "точный дамп" отстроить. Понятие "точного дампа" сразу становится очень интересным и ни разу не однозначным.

> Сервисная утилита показывала что на 6 год службы  вылетело 4 микросхемы и не
> каких проблем,ещё было в запасе если не ошибаюсь было 3 штуки,

Обычно флеш сыпется не "микросхемами" а отдельными erase-блоками. Которые маркируются как плохие и переназначаются на резерв. Процесс вероятностный, блоки сыпятся в разные моменты времени и никто не отстреливает это целыми чипами.

> данные даже не терялись.

Собссно нормальные SSD уходят в readonly - когда запас eraseblocks кончился. Хреновые могут при этом сделать черт знает что - отгрузив откровенную труху наверх при случае. Лучше всего это почему-то bcache провоцирует, и подпертые им ФС при кончине кеша зачастую разматывает просто в хлам. Особенно те которые без чексум. С ческсумами орать начинает до того как факап примет катастрофические масштабы - и зачастую успевают заменить. FEC тоже не панацея, его можно и пробить так то. Т.е. с энной вероятностью FEC сойдется на совершенно кривой фигне как якобы-исправное. Если сбоев много - в какой-то момент труха видимо все же проскакивает наверх.

> Я не думаю что нету современного такого железа или
> уже разучились делать качественные вещи ?

Да почему, как заплачено так и зафигачено не отменяли. Но все хотят дофига, за нифига. Это им и обеспечивают - но оно взамен хлипкое, сыпучее и глючное. Потому что бойтесь своих желаний.

Ответить | Правка | Наверх | Cообщить модератору

267. "Релиз ядра Linux 6.11"  +/
Сообщение от maximnik0 (?), 21-Сен-24, 01:33 
>Обычно флеш сыпется не "микросхемами" а отдельными erase-блоками.

Как практика показывает - я в этом убедился после появления "Бад" блока,буквально 5-10 до записей и микросхема начинает "сыпаться " с переводом в RO режим.А в основном резко и внезапно дохнут,что даже сервисные программы не помогают, китайцы нехорошие дяди поднимают вольтаж для более быстрой записи,а то что ресурс уменьшается в 10 раз их не волнует,и получается при выходе блока КЗ с выходом из строя микросхемы :-(.Не бывают исключения конечно, особенно если качественная флэшка и не чего не нахимичено,у меня есть пару флэшек которые а разметил хитро,что убитые участки не используются.Но это геморно и в офтопике не работает.Правда  есть одна утилита (устаревшая ,в комплекте для создания лайв флэшек),она как то забивает скрытым объемом фат32 ,это в офтопике работает, довольно интересная утилита,можно и файлы записать и лайв дистрибутив использовать,но сейчас поддержка МБР к сожалению редкость :-(

Ответить | Правка | Наверх | Cообщить модератору

271. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 21-Сен-24, 22:48 
>>Обычно флеш сыпется не "микросхемами" а отдельными erase-блоками.
> Как практика показывает -

Таки, обычно это делается как-то так: делается N резервных erase блоков, при том чем дешевле железка, тем ниже процент оных VS емкость девайса.

Когда не удается стереть энный блок, он ремапается - на резерв. А если весь резерв вышел и заменять больше не на что, не очень глупые девайсы в RO уходят. Может быть хуже - если оно попробует работать с игнором этого факта RW, вы получите знатный осыпон ФС и не факт что вам это больше понравится.

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

> я в этом убедился после появления "Бад" блока,буквально
> 5-10 до записей и микросхема начинает "сыпаться " с переводом в RO режим.

Процесс вероятностный. Какой-то erase блок может на 1-м циле осыпаться, а какой-то на 1001-м. Если на резерв зажались, "ранние" дефекты могут выжрать все блоки резерва и скажите спасибо что хотя-бы RO, а мог бы и бесконтрольный осыпон/ломовые утечки/застрявшие биты быть, так вы еще и данные пролюбите. Ибо FEC не будет выдюживать и ФС на сильно протертом девайсе однажды крякнет при том fsck уже может и не помочь.

Мораль сей басни такова: там поставили хреновый флеш, и сделали резерв по минимуму. Видимо что-то совсем дешевое.

> А в основном резко и внезапно дохнут,что даже сервисные программы
> не помогают, китайцы нехорошие дяди поднимают вольтаж для более быстрой записи,а
> то что ресурс уменьшается в 10 раз их не волнует,

Они и флеш паяют, скажем прямо, абы какой. И резерв по минимуму. И скажи спасибо если гигабайты честные, а не так что оверсайзнутый партишн 100500 гигз на 8 гиг флеху, так что первые 8 гиг даже хранятся, а вот потом... хехехе :)

> при выходе блока КЗ с выходом из строя микросхемы :-(.

Erase блоки не уходят в КЗ как таковые. Они просто перестают стираться. Некоторые биты не приходят в стертое состояние. Ну блок и становится непригодным - произвольные данные ячейка с застрявшими битами уже не может хранить.

> исключения конечно, особенно если качественная флэшка и не чего не нахимичено,у
> меня есть пару флэшек которые а разметил хитро, что убитые участки не используются.

Обычно фирмвара допирает таки ремапнуть проблемный блок - если есть на что. А если не на что - ну значит она не такая уж качественная. Или _сильно_ заюзаная.

Я по приколу на сыпучую 32 гиг флеху btrfs с dup положил - как прикольный стресстест механики рекавери в реалистичных условиях с 1 стороны, и как любопытство проиграю ли я этот теорвер хоть когда-то. Стало 16 гиг. Довольно надежно. Если какой-то блок не читается, вопит на csum error, чинит из 2 копии. Полторы тыщи ошибок пофиксило, теорвер пока не лоханулся. Да, это с xxhash, чтобы 64 бита чексум: при 32 битах CRC32 теорвер может подвести и чисто вероятностно, при интенсивных сбоях и активной игре в рулетку размер имеет значение.

> скрытым объемом фат32 ,это в офтопике работает, довольно интересная утилита,можно и
> файлы записать и лайв дистрибутив использовать,но сейчас поддержка МБР к сожалению
> редкость :-(

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

А я более-менее в курсе потому что UBI все это примерно в таком же виде на raw nand тоже делает. И да, тоже можно например на свое горе потереть factory bad blocks. C риском что они вскоре опять подведут, даже если начальный тест и прокатил. Ну то-есть UBI это нормальный flash translation layer, просто для SLC в основном. Для 2-level (MLC) уже не очень, а более злые NAND типа TLC/QLC - ну вот не, не стоит. Не готово оно к ЭТОМУ и ВСЕМ тем проблемам.

Ответить | Правка | Наверх | Cообщить модератору

275. "Релиз ядра Linux 6.11"  +/
Сообщение от maximnik0 (?), 21-Сен-24, 23:51 
>Erase блоки не уходят в КЗ как таковые.

Забыли про поднятое напряжение при перезаписи сделанное  Ляо Шао ? В этих условиях может произойти КЗ , особенно при отключённом термоконтролле :-(

В нашем ДНС офигенную партию подделок завезли- поначалу пишут быстро,потом резкое падение скорости и 50% КЗ.Хорошо хоть юсб защита срабатывает,не экономили,но 2 хаба жалко :-( Что странно,КЗ должны были выдержать.Сейчас цены взлетели - жёсткие диски и флэшки поехали на переработку,целых 3 контейнера:-( Не часть то жёстких удалось сбагрить ,там просто залежавшийся партия другого производителя,не чего так,рабочие,а другие хлам.

Ответить | Правка | К родителю #271 | Наверх | Cообщить модератору

280. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 23-Сен-24, 16:53 
>>Erase блоки не уходят в КЗ как таковые.
> Забыли про поднятое напряжение при перезаписи сделанное  Ляо Шао ? В
> этих условиях может произойти КЗ , особенно при отключённом термоконтролле :-(

Операции с флешом штатно требуют повышенное напряжение, сильно выше Vcc. В стародавние времена еепромки до 24-26V хотели. На более тонких процессах меньше, но ранний флеш с внешним Vpp был. Сейчас не модно - повышенное напряжение само себе синтезирует, используя "charge pump". Мощность этого всего комариная и КЗ само по себе оно имхо не вызовет.

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

> скорости и 50% КЗ. Хорошо хоть юсб защита срабатывает,не экономили,но 2 хаба
> жалко :-(

У меня примерно так погорел когда-то сотовый модем. От длительного активного трафа - в чипе усилка RF образовалась аккуратная дырочка в месте перегрева, чип ушел в КЗ, usb его срубил. А при попытке перезапуска модем еще и LDOшку рядом испек, в теории у LDO защита есть. Видимо у китайского LDO и защита китайская, 1 раз сработала, а 2й - нет :\. Но вон то явно было вызвано - перегревом.

> диски и флэшки поехали на переработку,целых 3 контейнера:-( Не часть то
> жёстких удалось сбагрить ,там просто залежавшийся партия другого производителя,не чего
> так,рабочие,а другие хлам.

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

Ответить | Правка | К родителю #275 | Наверх | Cообщить модератору

200. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:19 
> А ничего, что журнал сокращает жизнь флешки?

В принципе - может. В воооое том случае cow же - он как раз флехам (в том числе и тупым) довольно удобен - не перетирает постоянно 1 и тот же регион, так что качество wear leveling в фирмваре этой штуки оказывается несколько за скобками. Во всяком случае, нет поводов для откровенно патологических случаев как с журналом и проч в конкретном регионе.

> У тех, кто сдуру дёргает без отмонтирования, на флешках FAT32.

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

Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

33. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (33), 16-Сен-24, 14:57 
А в чем смысл поддерки io_uring в LXC?
Ответить | Правка | Наверх | Cообщить модератору

238. "Релиз ядра Linux 6.11"  +/
Сообщение от myster (ok), 19-Сен-24, 11:31 
Хороший вопрос, учитывая наличие уязвимостей в прошлом
https://github.com/containerd/containerd/issues/9048
И еще подозрительно, что изначально человек с Facebook автор этой фичи.
Ответить | Правка | Наверх | Cообщить модератору

41. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (41), 16-Сен-24, 15:09 
Где ntsync?
Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз ядра Linux 6.11"  –7 +/
Сообщение от Аноним (43), 16-Сен-24, 15:15 
а почему там сайт такой убогий? как-будто 80-е вернулись
Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Минона (ok), 16-Сен-24, 15:18 
А зачем там все эти свистоперделки Web 3.0?
Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз ядра Linux 6.11"  –3 +/
Сообщение от Аноним (43), 16-Сен-24, 15:55 
на gnome.org зайди, тот же минимализм но всё нормально красиво сделано
Ответить | Правка | Наверх | Cообщить модератору

76. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от Аноним (76), 16-Сен-24, 17:54 
Инфы нуль там.
Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз ядра Linux 6.11"  +5 +/
Сообщение от BeLord (ok), 16-Сен-24, 15:29 
На данном сайте нужны а) список изменений; б)исходники; в)документация, как следствие простого HTML за глаза и за уши хватит. Что за страсть генерить мусорный трафик?
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

56. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (56), 16-Сен-24, 16:33 
Главное, что продукт хороший. Сейчас наоборот принято.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

81. "Релиз ядра Linux 6.11"  +2 +/
Сообщение от anonymous (??), 16-Сен-24, 18:08 
Свистоперделки не нужны. Очень хотел бы, чтобы все сайты были такими.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

83. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (65), 16-Сен-24, 18:27 
Свистоперделки не нужны, а нормальное оформление нужно.
Ответить | Правка | Наверх | Cообщить модератору

92. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (-), 16-Сен-24, 19:13 
У кернел.орг нормальное оформление. Просто у вас вкус плохой.
Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (65), 16-Сен-24, 20:19 
Думаю, анон выше, как и я, про lkml.org
Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 16-Сен-24, 20:12 
> а почему там сайт такой убогий? как-будто 80-е вернулись

Пххх. А что ты хотел от застрявших там?
Может ты еще предложишь патчи не имейлами рассылать?

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

226. "Релиз ядра Linux 6.11"  +/
Сообщение от Антон (??), 18-Сен-24, 17:34 
Ну ты еще Линусу за GIT предьяви!
Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (160), 16-Сен-24, 15:18 
А что ntsync? Говорили, что включат его с 6.11. В новости ничего.
Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (52), 16-Сен-24, 16:14 
В версии libre не нашел.
Ответить | Правка | Наверх | Cообщить модератору

168. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от llolik (ok), 17-Сен-24, 08:23 
Как я понял, не успели до конца закрытия окна приёма изменений допилить. Ищи треды Elizabeth Figura в LKML.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

217. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от n00by (ok), 18-Сен-24, 08:53 
До выхода Wine 10 будет ещё ядро 6.12, так что успеют.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

49. "Релиз ядра Linux 6.11"  +/
Сообщение от Страдивариус (?), 16-Сен-24, 15:53 
Опять какой-то ntfs в ченджлоге. Его ж вроде выпилили уже три раза, оставив только fuse?
Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (51), 16-Сен-24, 16:13 
Так дас два драйвера было и фусе

Старый, вроде как, выпилили.

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 16-Сен-24, 16:33 
> Опять какой-то ntfs в ченджлоге. Его ж вроде выпилили уже три раза, оставив только fuse?

Выпилили старый readonly недоделаный драйвер, оставив только парагоновский NTFS3. Ну а что, парагон делом показал что в принципе - названию фирмы соответствует. И показали пример что могут не только с лопаты выгрузить, но и майнтайнить более-менее адекватно. Тот редкий случай когда фирмачи все сделали правильно. И это так то, имхо, неплохая реклама фирме и ее продуктам.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

117. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (117), 16-Сен-24, 20:46 
>Выпилили старый readonly недоделаный драйвер

в этой ветке? потому что в 6.10 присутствуют оба

Ответить | Правка | Наверх | Cообщить модератору

159. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (160), 17-Сен-24, 04:00 
А разве он (старый) не отключен?
Ответить | Правка | Наверх | Cообщить модератору

172. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (-), 17-Сен-24, 08:38 
> А разве он (старый) не отключен?

Он не только "отключен" но и выпилен нахрен на уровне кода уже несколько версий ядер к ряду! Возможно конфиги ядра которые его включают для совместимости теперь включают ntfs3. Но в конечном итоге - берете сорце, спускаетесь в fs/ и ищете старый ntfs. Удачи.

Ответить | Правка | Наверх | Cообщить модератору

171. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (-), 17-Сен-24, 08:36 
>>Выпилили старый readonly недоделаный драйвер
> в этой ветке? потому что в 6.10 присутствуют оба

Это заявление также не соответствует действительности. Его выкинули несколько раньше. Я не поленился, сделал git checkout v6.10 - и вот покажите мне там "старый" NTFS в fs/ - удачи! Там только "ntfs3". Парагоновский драйвер как раз.

Это опеннет, детка. Тут твои заявления могут фактчекнуть.

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

186. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (117), 17-Сен-24, 12:08 
$ zcat /proc/config.gz |grep NTFS
CONFIG_NTFS3_FS=m
# CONFIG_NTFS3_64BIT_CLUSTER is not set
CONFIG_NTFS3_LZX_XPRESS=y
# CONFIG_NTFS3_FS_POSIX_ACL is not set
CONFIG_NTFS_FS=m

$ uname -r
6.10.10_1

Ответить | Правка | Наверх | Cообщить модератору

202. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:26 
> $ zcat /proc/config.gz |grep NTFS
> CONFIG_NTFS3_FS=m
> # CONFIG_NTFS3_64BIT_CLUSTER is not set
> CONFIG_NTFS3_LZX_XPRESS=y
> # CONFIG_NTFS3_FS_POSIX_ACL is not set
> CONFIG_NTFS_FS=m
> $ uname -r
> 6.10.10_1

У вас есть какие-то пробелемы с чтением? Перечитайте еще раз предыдушее сообщение. Повторяйте пока не допрет.

Если хотите поспорить - вооон там на кернел орге есть cgit, покажите мне "старый" ntfs в fs/ - и тогда будет разговор. Но вы это "почему-то" не сможете. А если вы повелись на CONFIG_NTFS_FS=m оставленный для совместимости но переназначенный на NTFS3 - так это ваш факап. Как я уже сказал, тут ваши сказки могут и фактчекнуть.

Ответить | Правка | Наверх | Cообщить модератору

61. Скрыто модератором  +/
Сообщение от Аноним (-), 16-Сен-24, 16:42 
Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Walker (??), 16-Сен-24, 16:47 
А где QUIC протокол в ядре?
Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз ядра Linux 6.11"  +/
Сообщение от ИмяХ (ok), 16-Сен-24, 19:47 
Там же, где и графика.
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз ядра Linux 6.11"  +/
Сообщение от Анониматор (?), 16-Сен-24, 17:21 
Ура, поддержку X-Elite запилили. Кто там на ARM собирался?
Ответить | Правка | Наверх | Cообщить модератору

156. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (156), 16-Сен-24, 23:47 
Непонятно только - для кого они это сделали. Распберри пи на квалкоме мы увидим примерно никогда. А венда эту архитектуру на консьюмерских устройствах тупо похоронит.
Ответить | Правка | Наверх | Cообщить модератору

169. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:27 
> Непонятно только - для кого они это сделали. Распберри пи на квалкоме
> мы увидим примерно никогда. А венда эту архитектуру на консьюмерских устройствах
> тупо похоронит.

Квалком к таким факапам привычный :). Не первый фэйл и не последний. Странно что они до сих пор не выкинули каку. Видимо уволить мамонтов из windows drivers team - жалко.

Ответить | Правка | Наверх | Cообщить модератору

182. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (65), 17-Сен-24, 09:58 
Ну да, Alpha-то всяко нужнее.
Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

70. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 16-Сен-24, 17:28 
Всё, что угодно, но не десктоп-ориентированность. Увы.
Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от чатжпт (?), 16-Сен-24, 17:57 
а чего тебе надо от ядра для десктопа?
Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (89), 16-Сен-24, 19:07 
Поддержку модулей на питоне и js, чего же еще?!
Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (127), 16-Сен-24, 21:12 
Да и поддержки фреймворков node.js, Electron в ядре не хватает! Можно ещё JVM, .NET до кучи.
Ответить | Правка | Наверх | Cообщить модератору

215. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от maximnik0 (?), 18-Сен-24, 03:56 
>Можно ещё JVM,

Так была.Серьезно .Ядра серии  2.1.хх-2.2.хх .Потом деды собрали комитет и сказали какого лешего вся эта фигня в ядре делает ? Роста скорости не наблюдается,а дырень  в безопасности громадная.Так и не вышло тогда у народа байт компилятор на уровне ядра -сделали перенаправление на JVM .
И позже сделали универсальный механизм запуска приложений в пространстве юзера.

Ответить | Правка | Наверх | Cообщить модератору

170. "Релиз ядра Linux 6.11"  +/
Сообщение от Анониматор (?), 17-Сен-24, 08:28 
встроенный KDE, и чтоб не модулем
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

214. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (214), 18-Сен-24, 01:48 
А чем тебе улучшение сетевого стека не десктоп ориентированность? Ты сознательно отпиливаешь интернет, да?
Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

80. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (80), 16-Сен-24, 18:05 
>позволяющего отслеживать значения, возвращаемые функциями в приложениях пространства пользователя.

LTrace/DRLtrace, не?

Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (41), 16-Сен-24, 19:36 
А про новый зонд в 6.11 промолчали:
https://lists.gnu.org/archive/html/info-gnu/2024-09/msg00007...
Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 16-Сен-24, 20:10 
> новый зонд ...

по мнение кучки шизиков-грантоедов.

Вот только этому "правдорубу" даже не хватилос духа написать, что за модуль и кто код добавил.
Только абстрактные "the contributor of the new driver".
Ну это и понятно, так можно и на бобах остаться))

"Cleaned up amdgpu isp" Маладца!
С их поделием реальное железо вообще работает?
Или раз ядро скомпилиось, то можно и в прод?

Ответить | Правка | Наверх | Cообщить модератору

136. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (41), 16-Сен-24, 21:45 
Те, кто жертвует свободой ради функционала не достойны качать либрелинпус!
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (144), 16-Сен-24, 22:41 
К контрибьютору как раз вопросов нет, он признал ошибку и прислал патч, убирающий блоб. Вышестоящий мейнтейнер по какой-то причине решил патч в эту версию не включать.
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

148. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 16-Сен-24, 22:55 
> К контрибьютору как раз вопросов нет, он признал ошибку и прислал патч,
> убирающий блоб.

чтобы железка теперь не работала - к великой радости белок-истеричек.

> Вышестоящий мейнтейнер по какой-то причине решил патч в эту версию не включать.

потому что не заинтересован в том чтобы все сломалось.

Но вы не переживайте - из libre lin00ps вредный драйвер уже выпилен. Вместе со всеми остальными драйверами всего.

Ответить | Правка | Наверх | Cообщить модератору

175. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:50 
> Но вы не переживайте - из libre lin00ps вредный драйвер уже выпилен.
> Вместе со всеми остальными драйверами всего.

А вот раб - злобно истерит на тему того что кто-то смеет цепи раздалбывать и снимать. Ведь цепь не должна быть слишком длинной! А совсем без цепи это как?! Еще и еду себе самому добывать?! И теперь бесплатный барак с надзирателем не предоставляют! Ну и гадость эта ваша свобода! :)

Ответить | Правка | Наверх | Cообщить модератору

184. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 11:42 
> А вот раб - злобно истерит на тему того что кто-то смеет цепи раздалбывать и снимать.

А вот фанатик шво6одки громко радуется, что у него нифига не работает!
Ваша /b/орьба заключается в отпиливании ноги, которая закована в кандалы.
И второй ноги тоже. И даже одной руки.
Но одну руку вы оставляете, иначе как тогда восхвалять свою швоboдку в интернетиках и клянчить грантики))

Ответить | Правка | Наверх | Cообщить модератору

203. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:29 
> А вот фанатик шво6одки громко радуется, что у него нифига не работает!

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

> Ваша /b/орьба заключается в отпиливании ноги, которая закована в кандалы.

А вы видимо предпочитаете "коготок увяз - всей птичке пропасть".

> И второй ноги тоже. И даже одной руки.
> Но одну руку вы оставляете, иначе как тогда восхвалять свою швоboдку в
> интернетиках и клянчить грантики))

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

Ответить | Правка | Наверх | Cообщить модератору

230. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (230), 18-Сен-24, 21:40 
> у меня могут быть системки которые прекрасно обходятся без блоботы?

что-то уровня спектрума?)) давай конфиг в студию

> И там как раз удобно гарантированное отсутствие подлян и сюрпризов.

обожаю этот самообман. вы даже сорцы прочитать не в состоянии и rce, который по 5-10 лет живут, в них найти))

> хотеть системы без мутной функциональности

хотеть вам можно все что угодно))
но пока вы получаете системы без функциональности вообще

> с неопределенным кругом подлян и вулнов.

почему это с неопределенным? вот в ядре куча вулнов! каждую неделю находят подляны

Ответить | Правка | Наверх | Cообщить модератору

247. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (112), 19-Сен-24, 22:12 
> что-то уровня спектрума?)) давай конфиг в студию

Я б не назвал одноплатники на allwinner совсем уж спектрумом. Даже у 64 бит - народ запилил майнлайновый uboot и поддержку в официальном ATF от ARM (это то что в Trustzone грузится).

Вот так - все системные компоненты - внезапно опенсорц. И бутлоадер, и ATF, и DTB (назовм суммарно "системным фирмваре"). И ядро майнлайновое. И юзермодом у меня на таком - стандартный дебиан. В общем неплохие спектрумы, в принципе 64 бит даже как небольшой десктопчик катят если хочется странного. Это и привело меня к мысли что мой следующий воркстэйшн будет не на x86 и с открытым системным уровнем. А вы можете ME, PSP и прочими лочеными бутлоадерами наслаждаться, я за вас это делать - не буду ;). Через считанные годы RISCV64 будет не хуже моего воркстэйшна по мощще.

>> И там как раз удобно гарантированное отсутствие подлян и сюрпризов.
> обожаю этот самообман. вы даже сорцы прочитать не в состоянии и rce,
> который по 5-10 лет живут, в них найти))

Кроме самообмана я умею - косплеить этакого OEM-lite. Собирая себе весь системный уровень от и до. Это МОИ системы. Они служат - МНЕ. И верховный ауторити там - я. А от всяких там может и секурбут всякий быть и прочие lockdown.

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

>> хотеть системы без мутной функциональности
> хотеть вам можно все что угодно))
> но пока вы получаете системы без функциональности вообще

Судя по моему присутствию здесь - "all systems online". В том числе и те, без блобов. Без них я бы вообще тут пискнуть не смог, они так то - мой "периметр". Как раз потому что им можно более-менее доверять. Это вам не та фигня с пэйджерами... :)

>> с неопределенным кругом подлян и вулнов.
> почему это с неопределенным? вот в ядре куча вулнов! каждую неделю находят подляны

В ядре у меня git log к моим услугам. И сорцы. А в блоботе меняют хз кто, что, и зачем. Это не подлежит какому либо аудиту и трекингу изменений. И простите но доверять софту делаемому по ТАКИМ лекалам я не намерен. Особенно - на системном уровне.

Ответить | Правка | Наверх | Cообщить модератору

190. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 17-Сен-24, 13:06 
> А вот раб - злобно истерит на тему того что кто-то смеет цепи раздалбывать и снимать.

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

> А совсем без цепи это как?!

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

А бесплатный (платный вообще-то) барак с надзирателями поплыл дальше без тебя. Но там к вечеру - кооормят. А ты - к вечеру будешь кормить бычков.


Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

204. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:33 
>> А вот раб - злобно истерит на тему того что кто-то смеет цепи раздалбывать и снимать.
> чувак, спрыгнуть после этого за борт галеры - даже без цепи так
> себе идея. Пойдешь рыбкам на корм. А галера без весел - е плавает.

КМК это сильно зависит от того где эта галера была. Если она около пирса отвисает, и я с нее слился - отлично, теперь кнутовать будут сильнее - ТЕБЯ! Чтоб греб лучше. За меня в том числе.

> А весла ты, нераб, выкинул вместе с цепью, и сделать не сумеешь,

Нахрен мне твои весла, если оно около пирса стояло?!

> в море пойдут другие. На твоих нешва6одных веслах, заметим, других не бывает.

Да вот - у меня почему-то есть эн системок которым никакие блобы не надо. И там гарантированное отсутствие таких подарков - так то по своему удобно.

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

Или не утону. С хрена ли мне тонуть если до пирса рукой подать?

> А бесплатный (платный вообще-то) барак с надзирателями поплыл дальше без тебя. Но
> там к вечеру - кооормят. А ты - к вечеру будешь кормить бычков.

Или не буду. Ибо этот мир не ограничен твоим скудным и печальным воображением раба о том что тут возможно.

Ответить | Правка | Наверх | Cообщить модератору

234. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 00:05 
> Да вот - у меня почему-то есть эн системок которым никакие блобы
> не надо. И там гарантированное отсутствие таких подарков - так то

Пишешь ты конечно с одной из них? Ой, нет, у той из интерфейсов только мигатель светодиодиком и флэшкочитатель, и тот самым медленным и неэффективным протоколом.

А отсутствие подарков например в микрокоде или начальном загрузчике тебе гарантировано, конечно же, тысячеглассом.

Остальное - увы, твои больные фантазии. Пока галера - плывет.

Ответить | Правка | Наверх | Cообщить модератору

248. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:18 
> Пишешь ты конечно с одной из них? Ой, нет, у той из
> интерфейсов только мигатель светодиодиком и флэшкочитатель, и тот самым медленным и
> неэффективным протоколом.

Да вообще с 64 бит ARM с 2-4 гиг RAM я и сюда пискнуть смогу. А что до протоколов - ну не тебе меня этому учить. Я в этом получше твоего шарю, имхо.

> А отсутствие подарков например в микрокоде

У ARM и RISCV вообще микрокода нет. Потому что сложных команд цуко нет.

> или начальном загрузчике тебе гарантировано, конечно же, тысячеглассом.

У меня дофига железоа с u-boot и кернелом которые я САМ СОБРАЛ. В некоторых из них я uboot еще и пропатчил к тому же. Так что насчет тысяч глаз... как видишь, я могу и сам научиться хаживать на пантеон, если вон те "false gods" задолбают. И я в курсе что с ними за вот это все надо сделать.

> Остальное - увы, твои больные фантазии. Пока галера - плывет.

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

Ответить | Правка | Наверх | Cообщить модератору

149. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от нах. (?), 16-Сен-24, 22:56 
> С их поделием реальное железо вообще работает?

нет, а зачем, собственно?
> Или раз ядро скомпилиось, то можно и в прод?

И компилять его незачем. Его читать надо по субботам, хором, и молиться пресвятаму встолМану.

Истиный образчик шва6одки нуждается в поклонении, а не в примитивном использовании.

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

158. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (144), 17-Сен-24, 03:38 
То, которое не требует блобов, очевидно, работает.

Это ядро не для обладателей железок, которым нужны блобы. Это ядро для людей, у которых железо работает без ядерных блобов, и которые не хотят иметь в ядре блобы на ненужных им железок.

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

177. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:51 
> Это ядро не для обладателей железок, которым нужны блобы. Это ядро для
> людей, у которых железо работает без ядерных блобов, и которые не
> хотят иметь в ядре блобы на ненужных им железок.

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

Ответить | Правка | Наверх | Cообщить модератору

191. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 17-Сен-24, 13:06 
> То, которое не требует блобов, очевидно, работает.

то есть несуществующее.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

205. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (-), 17-Сен-24, 18:35 
>> То, которое не требует блобов, очевидно, работает.
> то есть несуществующее.

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

Ответить | Правка | Наверх | Cообщить модератору

228. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 18-Сен-24, 21:16 
>>> То, которое не требует блобов, очевидно, работает.
>> то есть несуществующее.
> Вот те раз, у меня оказывается несуществующее железо есть. Бедный раб не

воображаемое?
> может вообразить что бывает мир без цепей.

Ответить | Правка | Наверх | Cообщить модератору

249. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:22 
> воображаемое?
>> может вообразить что бывает мир без цепей.

У меня из такого "воображаемого" собран внешний уровень networking'а. Который, как ты понимаешь несколько отличается от стандартно-хомячкового. Если бы это не работало, я бы не смог с тобой тут трындеть ;).

Ответить | Правка | Наверх | Cообщить модератору

252. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 22:32 
> У меня из такого "воображаемого" собран внешний уровень networking'а.

пяток bgp-peer'ов и соответствующее число апстримных линков по десятке хотя бы? Или может ты канальный оператор и там сотни mpls vpn ? Может хотя бы segment routing а чудо-коробочка работает контроллером (жаль что она наверное лопнет)?
А, нет, обычная васянская насопливленная мыльница на палочке с мега-фиреволом без понимания и умения.
Стесняюсь спросить - сетевых интерфейсов-то у твоего недоразумения хотя бы два проводных?

> Если бы это не работало

то справился бы тплинк за $5 из ближайшего ларька.

Ответить | Правка | Наверх | Cообщить модератору

259. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 20-Сен-24, 02:22 
> пяток bgp-peer'ов и соответствующее число апстримных линков по десятке хотя бы?

Я не энтерпрайз и не ISP. Откуда я тебе 10 Гбит аплинки возьму? Не все же в датацентрах живут. Странное хобби - в ДЦ жить. А кому сильно надо было - типа гуглов и фэйсбуков, таки, запилили себе железки без тех "благодетелей", на линухе, если уж мы об этом.

> Или может ты канальный оператор и там сотни mpls vpn ? Может
> хотя бы segment routing а чудо-коробочка работает контроллером (жаль что она
> наверное лопнет)?

Я и за жратвой на карьерном самосвале не подруливаю. А зачем мне увозить весь магазин?!

> А, нет, обычная васянская насопливленная мыльница на палочке с мега-фиреволом без понимания и умения.

Да и ты небось не на карьернике за жратом подруливаешь то? А ютуб у тебя как, играется, со всеми твоими аплинками и гигабитами? А то что-то с болот вой какой-то доносился, гонят или таки нет? :)

> Стесняюсь спросить - сетевых интерфейсов-то у твоего недоразумения хотя бы два проводных?

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

>> Если бы это не работало
> то справился бы тплинк за $5 из ближайшего ларька.

Это врядли. Процы у них хилые шибко. Особенно у дешевых. Да и фабричная фирмварь у них, пардон, кусок бэкдоров, дыреней и спасибо если не спайвари.

Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от ИмяХ (ok), 16-Сен-24, 19:49 
>>возможность записи в отзеркаленные в память исполняемые файлы

Это не бэкдор, это прям парадная дверь.

Ответить | Правка | Наверх | Cообщить модератору

116. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (116), 16-Сен-24, 20:35 
>>>возможность записи в отзеркаленные в память исполняемые файлы
> Это не бэкдор, это прям парадная дверь.

Ну, правильно, кто же описание комитов то читает? Там было популярно расписано что как защитная мера оно - примерно как хлипкая калитка. В чистом поле. Без остального забора.

...потому что например на .so это все не распостранялось. Да и вообще - очень странный критерий для перезаписи - запущена прога или нет. С одной стороны малвари это не очень то и мешает, кроме самой уж педальной. С другой периодически делает мозг легитимным пользователям.

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

Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (127), 16-Сен-24, 21:09 
>на .so это все не распостранялось

А что же мешало поступить наоборот, распространить ограничение и на .so ?

Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (144), 17-Сен-24, 03:34 
А потом ещё одно расширение. И ещё. А потом вы обнаруживаете у себя в почте разгневанного Линуса, который, не стесняясь в выражениях, популярно на всю рассылку объясняет, что он думает про такие предложения.
Ответить | Правка | Наверх | Cообщить модератору

174. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:48 
> А потом ещё одно расширение. И ещё. А потом вы обнаруживаете у
> себя в почте разгневанного Линуса, который, не стесняясь в выражениях, популярно
> на всю рассылку объясняет, что он думает про такие предложения.

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

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

Ответить | Правка | Наверх | Cообщить модератору

173. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 08:44 
>>на .so это все не распостранялось
> А что же мешало поступить наоборот, распространить ограничение и на .so ?

То что левые костыли в качестве security subsystem - это весьма такая себе практика. Как вы уже поняли, в целом это работает "не очень" и есть дофига способов это обойти.

А вооооон там, в коммите с вот этим, господа с контейнеризаторами которые этого хотели - показали как сие делать правильно. Намного более радикально огородив свои процессы которые by design могут этому подвергнуться. Там вообще записи в sealed память - сразу обломаются. И файла процесса совсем нет на диске в видимом состоянии, так что гадить вообще некуда.

Грубо говоря, если кто хотел бронежилет, пусть и берет - бронежилет. А старая ржавая бочка в этом качестве - ну такое себе.

Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

192. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 17-Сен-24, 13:08 
> Грубо говоря, если кто хотел бронежилет, пусть и берет - бронежилет. А
> старая ржавая бочка в этом качестве - ну такое себе.

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

Ответить | Правка | Наверх | Cообщить модератору

206. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:36 
> Как многие уже убедились - если бронежилет тебе по статусу не положен
> и жить не снимая его так себе перспетивка - лучше ныкайся
> за ржавыми бочками, всяко веселее чем ловить хлебалом осколки.

Ну вот ты так и живи, имхо :). Воооон тебя поселят куданить на кладбище, к бсдюкам, и там ныкайся за чем тебе удобно.

Ответить | Правка | Наверх | Cообщить модератору

218. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 18-Сен-24, 09:01 
> ...потому что например на .so это все не распостранялось. Да и вообще
> - очень странный критерий для перезаписи - запущена прога или нет.
> С одной стороны малвари это не очень то и мешает, кроме
> самой уж педальной.

Действительно, странный. Потому в Windows NT помимо файла есть такой объект ядра - секция. Удачи твоей не очень педальной малвари записать в файл.


Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

223. "Релиз ядра Linux 6.11"  –1 +/
Сообщение от Аноним (-), 18-Сен-24, 10:42 
> Действительно, странный. Потому в Windows NT помимо файла есть такой объект ядра
> - секция. Удачи твоей не очень педальной малвари записать в файл.

В этой вашей NT - жесточайший брейнфак с апдейтом софта, если кто за столько лет еще не заметил. И постоянные ребуты на каждый пшик - именно оттуда проистекает, невозможность записи в исполняемый файл.

А мы вот не хотим постоянно ребутать сервера и эмбедовку ради накатки минорных апдейтов. Факъ, у нас уже часть дистро даже КЕРНЕЛ без ребута патчит. Попробуйте так в своей маздайке вообще?

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

А если я захочу радикально обуть таких как ты на запись в ОС - я какой-нибудь squashfs поюзаю. И попробуй в него что-то записать хоть там как. У него операция записи - просто не предусмотрена. Чисто технически. Поэтому малвар для всяких роутеров-мыльниц - живет до первого ребута, а что им делать с такой ФС остается? :)

Ответить | Правка | Наверх | Cообщить модератору

239. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от n00by (ok), 19-Сен-24, 13:55 
>> Действительно, странный. Потому в Windows NT помимо файла есть такой объект ядра
>> - секция. Удачи твоей не очень педальной малвари записать в файл.
> В этой вашей NT - жесточайший брейнфак с апдейтом софта, если кто
> за столько лет еще не заметил.

Я заметил, что у кого-то прям манечка написать своё особо ценное мнение с подменой темы. Но я понял, что с апдейтом своего гипотетического софта он не справлялся и полагает, что все такие.

Ответить | Правка | Наверх | Cообщить модератору

250. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:25 
> Я заметил, что у кого-то прям манечка написать своё особо ценное мнение
> с подменой темы. Но я понял, что с апдейтом своего гипотетического
> софта он не справлялся и полагает, что все такие.

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

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

Ответить | Правка | Наверх | Cообщить модератору

261. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 20-Сен-24, 08:57 
>> Я заметил, что у кого-то прям манечка написать своё особо ценное мнение
>> с подменой темы. Но я понял, что с апдейтом своего гипотетического
>> софта он не справлялся и полагает, что все такие.
> Если я что-то искренне ненавидел в винде - то это то как
> там софт апдейтится. Ребуты на каждый пук - это издевательство над
> здравым смыслом. А с точки зрения имплементера софта это - гемор
> на всю бошку, делать сетапер под винду - почти рокетсайнс и
> много горя.

Да, Виндоус имела такую особенность - нечитавшие Рихтера и криворукие сразу были видны. В Линуксе допонижали порог вхождения, теперь вкушайте плоды свободы.

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

Пакет-то, да, собрал парочку из готовых сорцов - и ты уже автономный разработчик операционных систем. А stop_machine() вообще мечта руткитчика. ;)

Ответить | Правка | Наверх | Cообщить модератору

263. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (263), 20-Сен-24, 18:18 
> Да, Виндоус имела такую особенность - нечитавшие Рихтера и криворукие сразу были
> видны. В Линуксе допонижали порог вхождения, теперь вкушайте плоды свободы.

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

Компьютеры должны обслуживать нужды людей. А не превращаться в карго-культ. И если вы про это забыли - инженеры могут и напомнить. Сколько ваши талмуды не читай, live patch кернела у вас не отрастет. А каждый убунтуй получает это нашару! Сразу! Без вот этого всего.

Как вы при таком сочетании смотритесь - догадаетесь, или подсказать? ;)

> Пакет-то, да, собрал парочку из готовых сорцов - и ты уже автономный
> разработчик операционных систем.

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

> А stop_machine() вообще мечта руткитчика. ;)

Мечтать не вредно... но на моих системах врядли им это поможет.

Ответить | Правка | Наверх | Cообщить модератору

270. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 21-Сен-24, 09:36 
> мы хотим заниматься прагматичной эксплуатацией

Пока что ты настолько неуверен в своей позиции, что прячешься за воображаемое мнение "всех".

Ответить | Правка | Наверх | Cообщить модератору

272. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 21-Сен-24, 23:02 
>> мы хотим заниматься прагматичной эксплуатацией
> Пока что ты настолько неуверен в своей позиции, что прячешься за воображаемое
> мнение "всех".

Голимый wishful thinking, не более. Это как раз выдано по итогам смотрения что хочет огромная толпа реальных эксплуатантов самых разных компьютерных системы.

Хотят они - чтобы это работало и разруливало те задачи для чего поставлено. Трах с залочеными ехешниками которые без ребута фиг обновишь - совершенно точно не ЭТО. А в линухе как видим пошли дальше и сделали - вот - патч ядра на лету. Без этих ваших е...х ребутов. Это было хорошо и правильно. А вы можете камлать на свои ритуалы из нафигнужных книжек по издыхающей оси для офисных клерков.

Ответить | Правка | Наверх | Cообщить модератору

277. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 22-Сен-24, 09:53 
>>> мы хотим заниматься прагматичной эксплуатацией
>> Пока что ты настолько неуверен в своей позиции, что прячешься за воображаемое
>> мнение "всех".
> Голимый wishful thinking, не более.

Баззворды - характерный маркер не имеющего ничего сказать по существу.

Ответить | Правка | Наверх | Cообщить модератору

281. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (281), 23-Сен-24, 17:06 
>> Голимый wishful thinking, не более.
> Баззворды - характерный маркер не имеющего ничего сказать по существу.

Кивание на ритуалы и талмуды - характерный маркер отщибленого на всю бошку академа, живущего в башне из слоновой кости и класть хотевшего на проблемы эксплуатантов систем. В его чудном мире компьютеры существуют исключительно чтобы тешить его отожраное ЧСВ.

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

Ответить | Правка | Наверх | Cообщить модератору

283. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 24-Сен-24, 09:59 
Навязчивые ответы мне после "я это не читаю" - характерный пример чего?
Ответить | Правка | Наверх | Cообщить модератору

243. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (243), 19-Сен-24, 18:38 
Надо тогда сразу объявить в манифесте, что Linux это не безопасность.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

129. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Motaro (?), 16-Сен-24, 21:31 
>>>возможность записи в отзеркаленные в память исполняемые файлы
> Это не бэкдор, это прям парадная дверь.

Это я вот помню, backdoor), а не не doorways) :d

Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

219. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 18-Сен-24, 09:03 
>>>возможность записи в отзеркаленные в память исполняемые файлы
> Это не бэкдор, это прям парадная дверь.

Оно и так открыто было изначально.

Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

244. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (243), 19-Сен-24, 18:41 
Чего напрягаться. Просто объявить, что Linux просто рычаги.
Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (127), 16-Сен-24, 21:06 
>Ранее, как и в других Unix-подобных системах, ядро выводило ошибку при попытке записи в исполняемый файл запущенного процесса. Данное ограничение снято, так как оно лишено практического смысла.

Ну да, получил доступ к образу чьего-то процесса - практический смысл записать в исполняемый файл определённо есть ;)

Ответить | Правка | Наверх | Cообщить модератору

242. "Релиз ядра Linux 6.11"  +1 +/
Сообщение от Аноним (243), 19-Сен-24, 18:32 
Ну да смысла нет системе защищать чужой код от записи посторонним. ))
Куда катится ядро...
Ответить | Правка | Наверх | Cообщить модератору

264. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (264), 20-Сен-24, 21:13 
> Ну да, получил доступ к образу чьего-то процесса - практический смысл записать
> в исполняемый файл определённо есть ;)

Если кто-то получил доступ к образу процесса, он уже в общем то - доступа поимел очень даже. И довольно много чего интересного может, в общем случае.

А чтобы вон то эксплуатировать - надо было приаттачиться к ПРИВИЛЕГИРОВАННОМУ контейнеру. Т.е. в принципе это такой хак сам себя по сути. Уже имеючи права. В каких-то менее эзотеричных сценариях, посторонние вообще ТАКОЙ доступ в чужие процессы попросту не получают.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

137. "Релиз ядра Linux 6.11"  +/
Сообщение от anon74 (?), 16-Сен-24, 21:53 
Модно ли на уровне ядра добавить поддержку resizeble bar? А то есть не удачный опыт пролить биос...
Ответить | Правка | Наверх | Cообщить модератору

181. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (181), 17-Сен-24, 09:15 
Не путайте bar с brick.
Ответить | Правка | Наверх | Cообщить модератору

163. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (163), 17-Сен-24, 06:40 
"от 2078 разработчиков" это скорее всего люди ответственные за коммиты от внешних контор, а разработчиков гораздо больше
Ответить | Правка | Наверх | Cообщить модератору

187. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (189), 17-Сен-24, 12:27 
>обработка имён файлов без учёта регистра символов (casefold) упрощена через хранение имён в форме qstr-строк без лишних преобразований регистра

QString ?

Ответить | Правка | Наверх | Cообщить модератору

197. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (197), 17-Сен-24, 18:06 
Атомарная запись явно связана с тем укладывается блок в сектор HDD или нет, поскольку именно запись сектора атомарна. Для SSD как я понимаю таких гарантий нет.
Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 17-Сен-24, 18:37 
> поскольку именно запись сектора атомарна. Для SSD как я понимаю таких гарантий нет.

Это почему? Они в целом примерно так же исполняют команды flush и проч.

Ответить | Правка | Наверх | Cообщить модератору

225. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (225), 18-Сен-24, 12:54 
можно узнать источник информации? HDD гарантирует атомарность потому что кроме сектора должна записываться контрольная сумма сектора, поэтому там стоит конденсатор который гарантирует что даже при потере питания сектор будет дописан до конца вместе с контрольной суммой, чтобы данные были консистентны.
Ответить | Правка | Наверх | Cообщить модератору

229. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 18-Сен-24, 21:18 
> можно узнать источник информации? HDD гарантирует атомарность потому что кроме сектора
> должна записываться контрольная сумма сектора, поэтому там стоит конденсатор который гарантирует
> что даже при потере питания сектор будет дописан до конца вместе
> с контрольной суммой, чтобы данные были консистентны.

и ты конечно же можешь показать этот самый конденсатор на платке?

P.S. у меня для тебя хреновая новость...

Ответить | Правка | Наверх | Cообщить модератору

231. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (225), 18-Сен-24, 21:53 
гарантия атомарной записи сектора с контрольной суммой сектора это факт
Ответить | Правка | Наверх | Cообщить модератору

232. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (225), 18-Сен-24, 21:53 
для HDD. а для SSD походу ничего такого и близко нет
Ответить | Правка | Наверх | Cообщить модератору

236. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 00:08 
> для HDD. а для SSD походу ничего такого и близко нет

для ssd (которому не надо крутить тяжеленный шпиндель) как раз есть, иначе бы бесконечно перезаписываемые таблицы трансляции после каждого отключения превращались в тыкву. А они только в одном случае из десятка.

Ответить | Правка | Наверх | Cообщить модератору

241. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (243), 19-Сен-24, 18:28 
тяжеленность здесь играет на стороне возможности закончить запись.
а вот изменение содержания ячейки требует повышенного потребления.
Ответить | Правка | Наверх | Cообщить модератору

255. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:38 
> тяжеленность здесь играет на стороне возможности закончить запись.
> а вот изменение содержания ячейки требует повышенного потребления.

Нафиг не вперлось для реализации атомарности. Единственное что накопитель должен реально уметь - слать ACK скидывания буфера только ПОСЛЕ того как реально сделал это. Без этого ACK - вы не считаете запись успешной и приступаете к откату, если облом случился ДО этого. И все.

Ответить | Правка | Наверх | Cообщить модератору

233. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 00:02 
> гарантия атомарной записи сектора с контрольной суммой сектора это факт

А потом, после внезапного отключения питания - ой, sector not found вообще, и никаким боком его назад не вернуть.


Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

254. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:35 
>> гарантия атомарной записи сектора с контрольной суммой сектора это факт
> А потом, после внезапного отключения питания - ой, sector not found вообще,
> и никаким боком его назад не вернуть.

Это как? Ты про настоящий IDNF? Оно так то довольно редкая ситуация. В случае HDD это значит что сервометкам - капец. В случае флеша - вероятно амба транслятору. В любом случае ты пойдешь менять это.

Ответить | Правка | Наверх | Cообщить модератору

257. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 22:44 
> Это как? Ты про настоящий IDNF? Оно так то довольно редкая ситуация.
> В случае HDD это значит что сервометкам - капец. В случае

с разморозочкой. Границы секторов нигде-не-кончаются (с)фюрер, наш фюрер - уже 25 лет.
Они софт и перезаписываются каждый раз вместе с сектором.

Раньше проблему могла вылечить format track, но и это кончилось тоже лет 20 назад вместе с последними true scsi дисками.

Именно по этой причине внезапных отключений питания _надо_ бояться.

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

Ответить | Правка | Наверх | Cообщить модератору

265. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 20-Сен-24, 21:37 
> с разморозочкой. Границы секторов нигде-не-кончаются (с)фюрер, наш фюрер - уже 25 лет.
> Они софт и перезаписываются каждый раз вместе с сектором.

С разморозочкой. Сервометки уже дохрена лет как пишут на ФАБЕ специальной приблудой, "серворайтером". Потому что по ним привод voice coil, цук, позиционируется. И при их слете он в принципе не способен ЭТО вернуть на место сам. Он просто не знает куда позиционироваться.

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

Называя вещи своими именами - я видел довольно много (полу)дохлых винчей. IDNF точно не был в топчарте шит-парада. Я его вообще несколько раз за всю жизнь видел.

> Раньше проблему могла вылечить format track, но и это кончилось тоже лет
> 20 назад вместе с последними true scsi дисками.

Это перестало работать много лет назад, когда в погоне за емкостью и плотностью треков стали использовать привод "voice coil". У голосовой катушки нет фиксированных "дорожек", ее отклонение зависит от тока. И куда ее гонять - по сервометкам определяется. А если они серьезно погроханы - навигация по поверхности накрывается медным тазом. В менее жестком случае, вот, не удается найти энные сектора и тогда случается странноватый код отлупа IDNF.

> Именно по этой причине внезапных отключений питания _надо_ бояться.

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

Иногда глючные питальники ведут к более забавным вещам - "софт бэды". Кажется что винч совсем сыкотный, не читается дохрена. А если переписать поверхность - опа, reallocated ноль или мало, все читается на ура. Оно просто видимо местами битфлипало - и ECC не сходится. А сам сектор - как новенький. Несколько таких экземпляров после перезаписи поверхности потом работали еще дофига (а может какие и сейчас работают).

> У флэша там таки конденсаторы. Последний сектор он конечно прочавкает, но таблицу
> спасет. Просто будет показывать на старое содержимое.

Все на самом деле проще - FTL часто делают как CoW. И у него есть маневровый резерв блоков. Ну и ACK команды в ифейс можно и не отдавать покуда не удалось провернуть всю механику и заапдейтить указатели на последнюю версию служебных структур и представления.

...а если не прокатило - ну, вот, вашей записи никогда не было, откат в cow стиле. Ее же не ack'нули на команду слива буферов, так что в своем праве, нарушения семантики нет.

Ответить | Правка | Наверх | Cообщить модератору

268. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 21-Сен-24, 02:11 
в викивракии прочитал?

Оно и заметно (и нет, сервометки тоже есть, но это метки - треков). А вот метки секторов софтовые с какого-то изобретения кажись seagate конца 90х, мгновенно растащенного всеми, у каждого был свой патентованный tm.

> Все на самом деле проще - FTL часто делают как CoW.

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

Ответить | Правка | Наверх | Cообщить модератору

273. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 21-Сен-24, 23:29 
> в викивракии прочитал?

Я знаю и места получше. На русском неплохо скажем у https://rlab.ru/doc/hdd_tracks_and_zones.html - и конечно реально все заметно сложнее. И рядом скажем https://rlab.ru/doc/hdd_translator.html

> Оно и заметно (и нет, сервометки тоже есть, но это метки - треков). А вот метки
> секторов софтовые с какого-то изобретения кажись seagate конца 90х, мгновенно
> растащенного всеми, у каждого был свой патентованный tm.

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

>> Все на самом деле проще - FTL часто делают как CoW.
> если бы они были сделаны как бырбырфесе - ты бы давно остался без своего ssd.

Да вот что-то бытыэры у меня все не дохнут и не дохнут. А у меня их так то довольно много. Единственный known issue - они довольно чувствивтельны к битой RAM. Но поскольку орут в логи на csum error то для меня сие не проблема.

> Но они там чуточку иначе устроены, не пилят один и тот же блок бесконечно

У btrfs так то из фиксированых структур только супера. В zoned mode - даже они раскиданы по тем правилам, довели идею "write anywhere" почти до абсолюта. Zoned режим это наполовину FTL и есть по сути.

> и к тому же эта операция действительно подперта конденсатором, чтоб
> ненароком не похоронить все целиком.

Ну как минимум счетчик power loss count оно успевает записать при слете питания :). Или как вариант - таки, по недописаной версионированой структуре какой-нибудь видит что питание грохнули ДО финализации структуры -> "unsafe_shutdown++". И кастомер в гарантийке нафиг++ если что, ибо все ходы записаны :)

Ответить | Правка | Наверх | Cообщить модератору

251. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:30 
> и ты конечно же можешь показать этот самый конденсатор на платке?
> P.S. у меня для тебя хреновая новость...

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

Эта логика неплохо в общем то работает. В случае cow это к тому же достаточно халявно ибо оформляется по сути "перевесом указателей" на более новые блоки. И единственный сложный момент как сделать чтобы это тоже атомарное было. Но это решаемо.

Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

258. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 22:47 
> Вообще-то все чуть прозаичнее: фирмваре отрапортует успех наверх не раньше чем сольет
> кеш. Это и позволяет атомарность. Получив репорт что кеш слит можно

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


Ответить | Правка | Наверх | Cообщить модератору

266. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (266), 20-Сен-24, 21:57 
> для этого надо вручную дернуть этому кэшу flush,

Вообще-то RTFM про write barriers и все такое.

> что делается в линухе примерно никогда (ок, оно делается при дисконнекте устройства)

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

Особенно хороши кривые флешастики - при внезапном powerloss могут пролюбить сразу кучу erase blocks/erase groups которые кантовали - а это регионы в цать мегов каждый. И к такой подляне в общем то ни 1 ФС не готова сама по себе, дальнейшее весьма undefined. А, да, dup в btrfs таки по приколу такое - фиксит. Впервые я о таком эффекте так и узнал, потом обнаружил что это в общем то known issue у дешевых флех/ssd/карт, где FTL ж@пой писан.

С флешастиками вообще - есть всяких приколов. Скажем - их нельзя выключать без явного анонса намерений. Они в лог записывают и считют такие события. Связано с тем что GC и проч у FTL таки фоновая операция. И если ее наобум загасить powerloss - вот как повезет. У хорошо сделаного FTL это адекватно обрабатывается, но если что - вон там счетчик записал все дерги, хрен чего предъявишь. В вещах типа смарта сие называется "unsafe shutdowns count" или наподобие.

> потому что угробит производительность до невиданных днищ.

Это и правда так. Поэтому btrfs сие делает лишь эпизодически, commit=<время> - параметр :).

И да, апликухи сисколами тоже flush могут вызывать, форсируя семантику ФС. По этой причине "eatmydata apt" - в разы быстрее "apt". Ессно так можно только если снашот для отката при факапе был. Технически вот так - это просто 1 очень большая транзакция, немного мануально хахинтованая :). Примерно так же в базы делают bulk insert, если что. Т.е. чем атомарно тупить на каждый record - транзакцией делают весь insert или его приличный кус, и дергают такую механику сильно реже. Что и разгоняет перфоманс в разы.

Ответить | Правка | Наверх | Cообщить модератору

269. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 21-Сен-24, 02:12 
>> для этого надо вручную дернуть этому кэшу flush,
> Вообще-то RTFM про write barriers и все такое.

чудик, это про buffer cache, причем тут кэш самого устройства.

Ответить | Правка | Наверх | Cообщить модератору

274. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 21-Сен-24, 23:47 
>>> для этого надо вручную дернуть этому кэшу flush,
>> Вообще-то RTFM про write barriers и все такое.
> чудик, это про buffer cache, причем тут кэш самого устройства.

Чудик, там вообще-то взаимодействие есть - с форсированым сбросом именно накопительского кеша, и довольно много тантров вокруг этого действа. Quirk'ов у девайсов есть. Кернел даже IIRC умеет переконфигурять режимы кеширования. Это с весьма лохматых времен mandatory command set для корректной работы журналируемых ФС, которые на эту механику уповают от и до в своей логике.

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

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

Ответить | Правка | Наверх | Cообщить модератору

227. "Релиз ядра Linux 6.11"  +/
Сообщение от Анонимemail (227), 18-Сен-24, 18:39 
Для интереса купил Lenovo Yoga 7x. Установка ubuntu 24.10 (там вроде пилят что бы инсталлер снапдрагоны понимал) на нем даже не запустилась, после отключения секурбута (с ним вообще не работает) запустился граб. Клавиатура не пашет. Дождался таймаута, он ребутнулся просто и так по кругу.
Ответить | Правка | Наверх | Cообщить модератору

235. "Релиз ядра Linux 6.11"  –2 +/
Сообщение от Аноним (214), 19-Сен-24, 00:05 
И зачем нам читать про твои проблемы без указания дистрибутива и версии ядра?
Сиди себе на вантузе, если даже изъясняться понятно неспособен.
То что появилось в ядре не значит что собрано под это дело на армах с их загонами и разнвми процессорами в принципе с разной системой команд. Если бы создал по LFS загрузочный образ, а потом накатил Gentoo было бы о чем с тобой вообще говорить.
Ответить | Правка | Наверх | Cообщить модератору

256. "Релиз ядра Linux 6.11"  +/
Сообщение от нах. (?), 19-Сен-24, 22:40 
> И зачем нам читать про твои проблемы без указания дистрибутива и версии
> ядра?

" Установка ubuntu 24.10 " это вполне себе дистрибутив и версия ведра.
Но не для местных мамкиных кекспертов.

> То что появилось в ядре не значит что собрано под это дело
> на армах с их загонами и разнвми процессорами в принципе с

похоже оно просто в secure boot нишмагло. Какие  там армы и процессоры. (при том что это наипопулярнейший snapdragon а не m4 какой для блохатых)

> разной системой команд. Если бы создал по LFS загрузочный образ, а
> потом накатил Gentoo было бы о чем с тобой вообще говорить.

пердолики умеют поговорить только о пердолинге. Совершенно бессмысленном и беспощадном.

Но совет не мучать зверушку, сделанную строго под использование copilot - в принципе, верный.

Ответить | Правка | Наверх | Cообщить модератору

253. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 19-Сен-24, 22:33 
> отключения секурбута (с ним вообще не работает) запустился граб. Клавиатура не
> пашет. Дождался таймаута, он ребутнулся просто и так по кругу.

Откуда напрашивается вывод - надо отребилдить образ чтобы GRUB по дефолту грузил что надо. Так то вполне решаемая смертными задача. Но насколько вы именно так можете - вопросец, конечно.

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

240. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (243), 19-Сен-24, 18:24 
"возможность записи в отзеркаленные в память исполняемые файлы,"
Это вот зачем?
Ответить | Правка | Наверх | Cообщить модератору

276. "Релиз ядра Linux 6.11"  +/
Сообщение от vvm13 (ok), 22-Сен-24, 00:01 
"поддержка атомарных операций записи на блочном уровне, при которых на накопитель записывается либо весь указанный набор блоков, либо ни один из блоков, что позволяет защититься от ситуаций, когда после сбоя оборудования записывается лишь часть блоков, а в другой части остаётся старая информация" для народа совершенно тривиальна, похоже.

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

Ответить | Правка | Наверх | Cообщить модератору

279. "Релиз ядра Linux 6.11"  +/
Сообщение от pavlinux (ok), 23-Сен-24, 15:50 

Какие магнитные головки? Хоть про ленты и перфокарты не вспомнил :)
Из ядра код IDE/MFM пора выкидывать.  Уже 1/4 21 века прошла, головки .... :D  

  

Ответить | Правка | Наверх | Cообщить модератору

278. "Релиз ядра Linux 6.11"  +/
Сообщение от pavlinux (ok), 23-Сен-24, 15:48 
> Интегрированы патчи, значительно (до 15 раз) ускоряющие
> получение случайных чисел через системный вызов getrandom().

А кто будет, в 15 раз быстрее, накачивать энтропию?  

Ответить | Правка | Наверх | Cообщить модератору

282. "Релиз ядра Linux 6.11"  +/
Сообщение от Аноним (-), 23-Сен-24, 17:22 
>> Интегрированы патчи, значительно (до 15 раз) ускоряющие
>> получение случайных чисел через системный вызов getrandom().
> А кто будет, в 15 раз быстрее, накачивать энтропию?

Так он же PRNG на стероидах, с подмесом энтропии по ходу дела из доступных источников. В нем нечему тормозить самому по себе. А детерминированность и возможность реплея, вот, покиляны тем подмешиванием.

Системд вообще скидывает random seed накопленой энтропии при шатдауне, а при старте вгружает заново, блок 512 байтов чтоли. Весьма актуально на виртуалках и эмбедовке, где boot sequence воспроизводим почти 1 в 1 и без таких маневров можно и нарваться при случае.  ЧСХ вон те мыльницы без systemd - и наорываются, оптом. За что им и спасибо - "я угадаю твой бесплатный интернет с трех нот". Хотя часто и с одной - прокатывает :)

Ответить | Правка | Наверх | Cообщить модератору

285. "Релиз ядра Linux 6.11"  +/
Сообщение от pavlinux (ok), 26-Сен-24, 12:07 
>>> Интегрированы патчи, значительно (до 15 раз) ускоряющие
>>> получение случайных чисел через системный вызов getrandom().
>> А кто будет, в 15 раз быстрее, накачивать энтропию?
> ... В нем нечему тормозить самому по себе.

Там есть гадкая функция wait_for_random_bytes() -> wait_event_interruptible_timeout()

Ответить | Правка | Наверх | Cообщить модератору

284. "Релиз ядра Linux 6.11"  +/
Сообщение от n00by (ok), 24-Сен-24, 10:00 
>> Интегрированы патчи, значительно (до 15 раз) ускоряющие
>> получение случайных чисел через системный вызов getrandom().
> А кто будет, в 15 раз быстрее, накачивать энтропию?

Microsoft Pluton будет выкачивать с Опеннета сообщения Анонимов.

Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру