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

Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повреждению ФС Ext4, opennews (??), 10-Дек-23, (0) [смотреть все] А я уже установил, что мне делать , Аноним (1), 11:30 , 10-Дек-23, (1)   // Мигрируй на бтрфс , Аноним (5), 11:33 , 10-Дек-23, (5) +1   // Чтобы не терять времени -- лучше сразу молотком комп разбить, чем сношаться с ра, Аноним (29), 12:00 , 10-Дек-23, (29) +5   // посоны поговаривают что бтрфс практически не рассыпается в отличие от практическ, Бывалый смузихлёб (?), 13:10 , 10-Дек-23, (80) –8   Развалиться может что угодно - но в btrfs чаще всего предупреждение о проблемах , Аноним (-), 14:17 , 10-Дек-23, (109) +2   Советую почитать форум Synology на предмет стабильности BRTFS очень советую, ну, Олег (??), 01:16 , 17-Дек-23, (263)   Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каж, Всем Анонимам Аноним (?), 13:19 , 10-Дек-23, (86)   Слегка не так Slight correction we use btrfs for the disk image backing the us, Аноним (151), 17:27 , 10-Дек-23, (151) +2   А что эти все делают и почему они вдруг в единственном числе , Анонимский (?), 22:54 , 10-Дек-23, (189) –1   Может прекратить жить по модели бабки, разносящей не проверенные слухи, лишь бы , 128557 (?), 14:09 , 10-Дек-23, (104) –2   сказала бабка, Аноним (120), 14:42 , 10-Дек-23, (120) +7   Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,е, maximnik0 (?), 16:10 , 10-Дек-23, (139)   Люблю экспертов опеннета, всегда блеснут экспертизой 1 CRC32 - вообще не код , Аноним (153), 17:41 , 10-Дек-23, (153) +1   xxhash64 в плане коллизий вполне надежен, он не криптографический, т е не имеет, penetrator (?), 17:53 , 10-Дек-23, (158)   Ну дык можно вот его Если кому совсем нечего делать, -dev версии btrfs-tools ум, Аноним (153), 17:56 , 10-Дек-23, (160)   Ты с ней побывал почти в каждой новости о файловых системах Учитывайте, что зде, Аноним (165), 18:37 , 10-Дек-23, (165) +3   1 Мне все время рассказывают страшилки как я потеряю данные и проч Уже какой т, Аноним (-), 20:52 , 11-Дек-23, (237)   На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентиру, Аноним (195), 23:55 , 10-Дек-23, (195) +1   Извольте-ка пруф на это храброе заявление предоставить На ваше несчастье я этих, Аноним (-), 21:03 , 11-Дек-23, (238)   Можно использовать для коррекции ошибок Как я помню один из видов crc32 может об, maximnik0 (?), 04:50 , 11-Дек-23, (209)   При сильном желании и SHA256 - код коррекции ошибок Вот вам блок с эн левых бит, Аноним (240), 21:43 , 11-Дек-23, (240)   вообще-то иногда и коррекции только никто в мире не умеет ее правильно применят, нах. (?), 09:35 , 11-Дек-23, (215)   Да я смогу и какимнить SHA256 например 1-бит ошибку замахать Но по мере роста ч, Аноним (240), 22:50 , 11-Дек-23, (244)   все же щупал однокурсницу - практическое - kernel panic при попытке прочитать п, нах. (?), 09:50 , 12-Дек-23, (251)   Все чуть хитрее Большую часть актуальных знаний по IT vs алго я получил путем ш, Аноним (240), 19:04 , 12-Дек-23, (253)   боюсь что это уровень заборостроительного факультета Я там вопрос задал - что н, нах. (?), 19:51 , 12-Дек-23, (255)   Меня интересуют практические применения и детали реализации Я этим пользуюс, Аноним (265), 06:23 , 19-Дек-23, (265)   Там даже конвертор EXT4 - btrfs есть Но вот это - таки не рекомендуется Это р, Аноним (153), 17:53 , 10-Дек-23, (159)   // блжад, да в каком месте у вас хоть изредка бывает не так , нах. (?), 09:23 , 11-Дек-23, (213)   Чудак Файлуха при этом врапает себя в свободное место имевшейся ФС 1 Это довол, Аноним (240), 21:52 , 11-Дек-23, (242)   для fs рекламируемая фича которой безобидное увеличение на ходу - не говоря уже , нах. (?), 09:53 , 12-Дек-23, (252)   ПЦ какой-то - по сравнению с чем А кто еще умеет вообще внутрь себя врапать , Аноним (240), 19:41 , 12-Дек-23, (254)   отмены в какой момент И что будет если управляющие структуры лежат по одинаковы, нах. (?), 20:07 , 12-Дек-23, (256)   IIRC пока не снесен subvol с файлом-образом старой ФС Забавная абстракция, а , Аноним (265), 05:59 , 19-Дек-23, (264)   откати ядро , старые из реп не исчезли, Аноним (6), 11:36 , 10-Дек-23, (6) +2   // Даже ничего откатывать не надо В Debian легко можно загрузиться с предыдущим яд, Аноним (50), 12:26 , 10-Дек-23, (50) +3   // Это если за консолькой сидеть в момент загрузки и ручками выбирать ядро в грубе , Аноним (73), 12:50 , 10-Дек-23, (73) +1   В etc default grub можно попробовать покрутить параметр GRUB_DEFAULT только по, Твайлайт Спаркл (ok), 12:55 , 10-Дек-23, (75) +2   А разве там не systemd-boot по умолчанию , Аноним (102), 13:55 , 10-Дек-23, (102)   В дебиане то GRUB там самый обычный , Аноним (153), 17:47 , 10-Дек-23, (154)   Самый необычный Пропатченный гигантcкими листингами на Си, не проходившими код-, Аноним (167), 18:49 , 10-Дек-23, (167) +1   И этот великолепный господин конечно же предоставит к ознакомлению портянку с ба, Джентельмен Шоу (?), 23:09 , 10-Дек-23, (190)   Нельзя ли пруфануть это все И как насчет URL CVE А так сабж тоже специфичен для, Аноним (240), 22:54 , 11-Дек-23, (245)   А если вместо grub а используется boot efi , 128557 (?), 14:11 , 10-Дек-23, (105)   То человек должен уже знать, что делает, Мимосисадмин (?), 15:24 , 10-Дек-23, (126) +1   Перезагрузитесь с использованием более раннего ядра, дебиан сохраняет 3 версии я, Аноним (10), 11:40 , 10-Дек-23, (10) +4   // 6 1 0-13-amd64 1 SMP PREEMPT_DYNAMIC Debian 6 1 55-1 2023-09-29 А версия 6 1 0, Твайлайт Спаркл (ok), 12:53 , 10-Дек-23, (74)   // Да, именно эта забагованная , Аноним (79), 13:09 , 10-Дек-23, (79) +2   Спасибо , Твайлайт Спаркл (ok), 13:28 , 10-Дек-23, (91)   Ты пакеты не разу не откатывал что-ли Посмотри в апт логе старые версии пакетов, Вы забыли заполнить поле Name (?), 11:42 , 10-Дек-23, (12)   Страдать 175 _ 12484 _ 175 , Аноним (38), 12:13 , 10-Дек-23, (38) +2   Пользоваться Эти мэйнтенеры всё равно ничего не понимают К тому же каждый поль, Аноним (83), 13:12 , 10-Дек-23, (83) +1   // Только вот пользователям рачика это давным-давно починили, а они и не заметили , НяшМяш (ok), 13:36 , 10-Дек-23, (93) –2   // Вооюще-то как раз заметили - и не выкатили провальный релиз , Аноним (153), 17:49 , 10-Дек-23, (155)   все равно каждый день переставляют, а прона нового всегда можно накачать а этим , нах. (?), 09:38 , 11-Дек-23, (216)   Обновление ядра с исправлением уже прилетело, Андрей04091977 (ok), 01:26 , 11-Дек-23, (199)   Тоже поставил 14 версию , а потом еще накатил последнюю 15 и после этого апгрейд, Cimeries (?), 21:21 , 12-Дек-23, (259) +1   Оперативно Буквально за день после релиза заметили Заметил сегодня из-за ошибо, Аноним (3), 11:32 , 10-Дек-23, (3) –1 // В репах лежит уже новое ядро, пофиксенное , Аноним (185), 22:19 , 10-Дек-23, (185) Скрыто модератором, нах. (?), 11:33 , 10-Дек-23, (4) –19 // Скрыто модератором, Аноним (3), 11:45 , 10-Дек-23, (16) +3 Скрыто модератором, Аноним (153), 17:51 , 10-Дек-23, (156) // Скрыто модератором, нах. (?), 19:09 , 10-Дек-23, (169) –2 Скрыто модератором, Don Perignon (?), 03:07 , 11-Дек-23, (205) // Скрыто модератором, нах. (?), 09:22 , 11-Дек-23, (212) Надо честно признать линукс себя изжил Пора дебиану на Illumos переходить , Аноним (29), 11:37 , 10-Дек-23, (7) –19 // Это не Линукс себя изжил, это дебиан себя изжил Перейти на Illumos и своими про, Аноним (102), 14:09 , 10-Дек-23, (103) –4 Ну дык, с 91 года пилится Как и иксы, код -- лютое устаревшее хауно, си-портянк, Аноним (106), 14:14 , 10-Дек-23, (106) –1 // systemd тоже на Си написан, причем написан плохо, Аноним (119), 14:42 , 10-Дек-23, (119) +1 // Воот, надо на расте переписать в стиле вейланда, чтоб каждый сервис сам себя зап, Аноним (106), 17:12 , 10-Дек-23, (146) +2 Вэйланд тоже на си блин, хотя для фанов раста запилить реализацию на этом - таки, Аноним (153), 17:52 , 10-Дек-23, (157) вейланд написан на английском, это протокол , emdash (?), 00:11 , 11-Дек-23, (196) +2 Есть реализация не на Си , Аноним (201), 02:00 , 11-Дек-23, (201) Да, ПомидорИзДолины (?), 02:25 , 11-Дек-23, (204) https github com Smithay smithay , Аноним (262), 19:58 , 15-Дек-23, (262) заменить на обычные портянки с сапогами, сразу дурь выйдёт, Аноним (120), 14:45 , 10-Дек-23, (121) Рано или поздно Linux сойдёт на нет, уступив место академическим Unix , 128557 (?), 14:15 , 10-Дек-23, (107) +2 // В этом месте должна звучать классическая рождественская песня O, Tannenbaum У, Аноним (148), 17:21 , 10-Дек-23, (148) +4 Академическим Unix давно уже пора на пенсию, борода до пола выросла , Neon (??), 05:39 , 11-Дек-23, (210) +1 // Это ты с ZZ Top попутал , 1 (??), 09:24 , 11-Дек-23, (214) +2 Ставлю на Иллинойс , Пряник (?), 15:34 , 11-Дек-23, (229) Ну это просто днище, господа Мало того, что стабильно ядро дырявое, так еще и в, Аноним (8), 11:39 , 10-Дек-23, (8) +1 // btrfs стала надежнее ext4 это в каком выдуманном мирке , Alladin (?), 11:43 , 10-Дек-23, (13) +8 // Чувак, ты это пишешь буквально в теме про баг в ext4 , Шарп (ok), 11:50 , 10-Дек-23, (20) +2 // Если он каждый раз будет писать это в теме про баг BTRFS - ты утонешь в его сооб, Аноним (38), 12:15 , 10-Дек-23, (40) +8 Проснись, BTRFS очень стабильна , 128557 (?), 14:18 , 10-Дек-23, (110) –2 // Ты в changelog и ядра хоть раз заглядывал , Wizard160888 (?), 14:31 , 10-Дек-23, (114) Так там во всех файлухах баги чинят Btrfs на данный момент не выглядит страшнее, Аноним (240), 22:58 , 11-Дек-23, (246) –1 Если да , то вопрос Не страшно , Wizard160888 (?), 14:34 , 10-Дек-23, (116) он смел и отважен, а прона, случись что, нового накачает , нах. (?), 19:10 , 10-Дек-23, (170) Вы там уже прочекали свои копии копий на предмет разрушения, эксперты Btrfs , Аноним (240), 23:00 , 11-Дек-23, (247) ага, не грузит - просто в один непрекрасный момент mount отвечает error, а чего , нах. (?), 01:05 , 12-Дек-23, (249) 1 Ну вообще-то обычно - монтируется, если не идиотничать 2 Прочитать, внезапно, Аноним (240), 12:56 , 15-Дек-23, (261) Стабильна в невосстановимых поверждениях в любой неожиданной для разработчиков с, Аноним (178), 21:17 , 10-Дек-23, (178) +1 насколько я понимаю - в случае ее raid6 можно сэкономить деньги и время - никому, нах. (?), 01:06 , 12-Дек-23, (250) А при zfs у тебя ничего и не восстановишь, КО (?), 14:36 , 10-Дек-23, (117) Сейчас закоммичу в btrfs баг и продолжим разговор , Пряник (?), 15:36 , 11-Дек-23, (230) Допатчились Вот причина, почему все deb based имеют некую шизу - что-то тупит , Аноним (11), 11:41 , 10-Дек-23, (11) // Но это не точно, Вы забыли заполнить поле Name (?), 11:44 , 10-Дек-23, (15) +4 make -j nproc bindeb-pkg, Аноним (17), 11:47 , 10-Дек-23, (17) Невероятно Диды сначала запутались в O_SYNC, потом шлифанули потерей данных, а , Шарп (ok), 11:48 , 10-Дек-23, (18) +5 // Поправил, Аноним (23), 11:52 , 10-Дек-23, (23) +8 // Нтфс рассыпалась куда чаще надо заметить, а баги весьма эпические с разносом суп, Аноним (43), 12:21 , 10-Дек-23, (43) +3 // И мне особенно нравятся неудаляемые файлы в ней В некоторых случаях не поможет , Аноним (43), 12:25 , 10-Дек-23, (48) +1 Такие файлы удавалось удалить в Far кто-то объяснял это тем, что в Far работа с, Аноним (173), 19:56 , 10-Дек-23, (173) Far умеет работать с UNC Возможно, с этим связано , Аноним (23), 23:13 , 10-Дек-23, (191) За всю мою практику рассыпалась один раз, и то сам виноват 8212 битый IDE-каб, Аноним (23), 14:50 , 10-Дек-23, (122) За 10 лет раз 5 устраняли баг с разносом при исчерпании места, и это только то, , Аноним (43), 15:05 , 10-Дек-23, (123) Ваша хваленая ntfs просто обнулила размер мне некоторых файлов после миграции с , Аноним (136), 15:57 , 10-Дек-23, (136) // так она не наша, Аноним (164), 18:22 , 10-Дек-23, (164) У ext4 пока баги из разряда забей , когда у остальных там что-то опасное было , Аноним (43), 12:08 , 10-Дек-23, (35) BTRFS и адекватная в одном предложении Смешно По серьёзке - у меня BTRFS раз, Аноним (38), 12:20 , 10-Дек-23, (42) +5 // За несколько лет использования Btrfs на нескольких HDD-дисках сталкивался только, Аноним (167), 19:18 , 10-Дек-23, (171) –4 Выпрями руки У меня с 2018 года на 2 ноутах btrfs, система установлена, работа, Андрей (??), 22:35 , 10-Дек-23, (187) –3 Ну что ты паришь Ты даже сам сидишь на NTFS , Аноним (56), 12:30 , 10-Дек-23, (56) –2 // поди что плохое , нах. (?), 13:40 , 10-Дек-23, (98) +1 А начал как-будто хочешь про безопасный язык задвинуть , Вы забыли заполнить поле Name (?), 12:47 , 10-Дек-23, (68) +1 btrfs обсирается регулярно, судя по линукс-форумам а фанатики бегают и орут что, voiceofreason (?), 11:59 , 21-Дек-23, (266) Вообще новость - ахтунг Разработчики ядра накатили на стабильную версию ядра па, Аноним (10), 11:49 , 10-Дек-23, (19) +7 // Олдстейбл теперь новый стейбл, Аноним (8), 11:51 , 10-Дек-23, (21) +4 // Видимо, да , Аноним (10), 11:53 , 10-Дек-23, (24) // Тебя ещё больше открытий ждёт Рановато тебе в аналитику лезть, поднаберись опыт, Аноним (43), 12:10 , 10-Дек-23, (36) –3 Ваше мнение очень важно для нас Пожалуйста, не вешайте трубку , Аноним (10), 12:31 , 10-Дек-23, (57) Обязательно держи в курсе чьё мнение важно для вас , Аноним (56), 12:34 , 10-Дек-23, (59) –1 А ты подпишись на рассылку, и узнаешь первым Как маленький, ей-богу , Аноним (10), 12:36 , 10-Дек-23, (61) Ты зато как старенький Кому нужны ваши рассылки - в мире, где изобрели твиттор,, Аноним (198), 00:45 , 11-Дек-23, (198) Ты зашёл на форум компьютерщиков и имеешь что-то против автоматизации рутинных о, Аноним (79), 02:01 , 11-Дек-23, (202) Зато мне в новостях про Федору любители дебиана и его убунту-тестинга на десктоп, FF (?), 12:44 , 10-Дек-23, (66) // я о том, что мейтейны бэкпортируют всякие не поддерживаемые межмажорные релизы,, FF (?), 12:46 , 10-Дек-23, (67) Это нормальная ситуация - если что-то считается сверхнадёжным, то рано или поздн, Аноним (79), 13:02 , 10-Дек-23, (77) обычное дело, ты, видимо, недавно с компьютерами познакомилсяо сколько нам откры, Аноним (43), 12:05 , 10-Дек-23, (33) +1 Ну, если ты обновляешься немедленно после выхода мажорной версии - ты должен пре, Аноним (38), 12:24 , 10-Дек-23, (46) –4 // Это минорный апдейт , Аноним (54), 12:29 , 10-Дек-23, (54) Ты вообще читаешь, что написано , Аноним (10), 12:47 , 10-Дек-23, (69) +1 Диванный теоретик Отозвали , Аноним (3), 13:20 , 10-Дек-23, (87) // Скрыто модератором, Аноним (79), 13:28 , 10-Дек-23, (90) Ошб 1 https deb debian org debian bookworm main amd64 linux-image-6 1 0-14-amd, Аноним (3), 13:35 , 10-Дек-23, (92) +1 // Тогда хорошо, а то я обновляться на эту версию не пытался Раньше она была в pro, Аноним (79), 13:39 , 10-Дек-23, (97) Ещё несколько часов назад спокойно обновлялось, хотя новость от вчера Такое , Аноним (54), 13:51 , 10-Дек-23, (100) +1 Я четыре часа назад обновлять пытался Результат в логе выше , Аноним (3), 15:36 , 10-Дек-23, (128) Не спорьте - у дебиан куча зеркал, где раньше синхронизировали, где позже, Аноним (73), 16:39 , 10-Дек-23, (142) +2 bookworm stable kernel ядро Linux для 64-разрядных персональных компьютеров, Аноним (200), 01:29 , 11-Дек-23, (200) // Да, уже несколько часов известно, что баг пофиксили , Аноним (79), 02:02 , 11-Дек-23, (203) Причем все дерьмо теперь льется на дебиан Вся вина которых что они взяли ядро , Аноним (148), 15:38 , 10-Дек-23, (129) +1 // Ну так почему-то дебиан воспринимается некоторыми не как арч с его собирается, , Аноним (43), 15:47 , 10-Дек-23, (131) самое короткое изложение проблемы взято https lwn net Articles 954285 - Stab, Аноним (148), 16:55 , 10-Дек-23, (143) +2 А на примере с Winodows Microsoft бы в первую очередь выпустила, а потом отложи, Аноним (22), 11:52 , 10-Дек-23, (22) Спасибо, чуваки Чую, неделя будет интересной , Аноним (54), 11:54 , 10-Дек-23, (25) +3 Самый стабильный дистрибутив, Алексей (??), 12:04 , 10-Дек-23, (32) –1 // Именно В рачах с бомжарами багованное ядро провисело несколько дней и никто даж, Аноним (50), 12:28 , 10-Дек-23, (53) –2 // Когда у тебя постоянно что-то отваливается, на такие мелочи не обращаешь внимани, Вы забыли заполнить поле Name (?), 12:50 , 10-Дек-23, (72) +2 // Вот и я о том же То что в Debian - ЧП, в других дистрибутивах обыденность , Аноним (50), 13:22 , 10-Дек-23, (88) +2 Да не обыденность, просто меньше косяков - вот и меньше про них пишут Там ещё ок, Михалков (?), 15:49 , 10-Дек-23, (132) –2 Стабильность -- понятие относительное По сравнению с остальными дистрибутивам, Аноним (29), 12:30 , 10-Дек-23, (55) Как там этот ваш Преображенский говорил Не понимаю, кто на ком стоял Кто что , freehck (ok), 12:12 , 10-Дек-23, (37) +4 // те кто понимают чего чего-чего - ext4 - не являются авторами новости, вероя, нах. (?), 19:07 , 10-Дек-23, (168) Из 6 5 криво набэкпортировали в 6 1 В результате 6 1 64 и 6 1 65 пользовать нел, Аноним (211), 07:00 , 11-Дек-23, (211) Никогда не было - и вот опять Код файловых систем неплохо бы изолировать от ОС, Аноним (41), 12:16 , 10-Дек-23, (41) –1 // Хорошо что ты заговорил про микроядро , Аноним (56), 12:27 , 10-Дек-23, (51) // Никто не говорит про микроядро Я заговорил о API и желательно ABI-совместимости, Аноним (63), 12:37 , 10-Дек-23, (63) +1 лог не пробовали посмотреть https git kernel org pub scm linux kernel git sta, Аноним (45), 12:23 , 10-Дек-23, (45) Через какое-то время Мы прекращаем сборку дебиан потому что у нас что-то не пол, Аноним (56), 12:25 , 10-Дек-23, (49) +3 // Грег бросает ядро линукс и переходит на гну хурд тогда уж , Аноним (54), 12:34 , 10-Дек-23, (58) +1 // В майкрософт, Вы забыли заполнить поле Name (?), 12:49 , 10-Дек-23, (71) +5 если честно, то можно и на 11м и на 10м сидеть и все будет в норме пакетов на , Аноним (22), 12:34 , 10-Дек-23, (60) +1 как хорошо что у мя хомяк на ext3, Аноним (64), 12:38 , 10-Дек-23, (64) // И четвёртое ядро , я (?), 13:51 , 10-Дек-23, (101) // черт а как ты догадался У меня LTS, который на поддержке , Аноним (64), 18:22 , 10-Дек-23, (163) У альтовцев просто пишут,что ext 2-3,а оно там явно 4 , Аноним (108), 14:17 , 10-Дек-23, (108) uname -aLinux devuan 5 15 142 1 SMP Sun May 1 12 00 00 CEST 2011 x86_64 GNU L, glad_valakas (?), 12:39 , 10-Дек-23, (65) –1 // Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..., Вы забыли заполнить поле Name (?), 12:48 , 10-Дек-23, (70) https git kernel org pub scm linux kernel git stable linux git log h v5 15 14, Аноним (45), 12:56 , 10-Дек-23, (76) Писали же что ребята на переносах выдыхаются Чтобы так бекпортировать между в, Аноним (78), 13:04 , 10-Дек-23, (78) +1 Опять direct i o поломали , Tron is Whistling (?), 13:10 , 10-Дек-23, (81) Вот поэтому я никогда и не обновляю ядро, какое было на iso такое и стоит годами, Аноним (82), 13:12 , 10-Дек-23, (82) // fat в ro на керамике веками проработает без сбоев, Аноним (45), 13:23 , 10-Дек-23, (89) +1 // fat -грязная проприетарщина mount dev root on type ext2 ro,noatime как-т, Аноним (241), 21:52 , 11-Дек-23, (241) непонятноскорее всегоАхахаЛинукс, Аноним (82), 13:16 , 10-Дек-23, (84) +2 // all stable kernels that have 91562895f803 ext4 properly sync file size update, Аноним (-), 17:02 , 10-Дек-23, (145) А я уже упоминал об этой проблеме с ядром 6 5 и замиранием системы в Endless OS , pic (?), 13:36 , 10-Дек-23, (94) // Ну вот и правильно, релиз Endless OS 5 1 с _проблемным ядром 6 5_ отключен для о, pic (?), 15:39 , 10-Дек-23, (130) Ну и как так вышло, что в типа самом стабильном дистрибутиве косяки уровня ролли, Аноним (96), 13:37 , 10-Дек-23, (96) –1 // Разогнались Проще говоря один раз отмерили и семь раз сделали , Аноним (22), 13:43 , 10-Дек-23, (99) –1 Задайте свой вопрос на kernel org, Аноним (135), 15:54 , 10-Дек-23, (135) Делать стэйбл версию, чтобы в неё переносить некритичные патчи из анстэйбл, гени, КО (?), 14:34 , 10-Дек-23, (115) +1 // По логике всё это надо было пихать опционально в backports-репозиторий , pic (?), 15:30 , 10-Дек-23, (127) // Еще раз - бэкпортили разработчики ядра, из 6 5 в 6 1, который отличается длитель, Аноним (148), 16:06 , 10-Дек-23, (138) +2 // Не усмотрел что релизе Debian 12 состоялся с ядром 6 1, как-то экстраполировал D, pic (?), 18:01 , 10-Дек-23, (161) Вот они, любители бэкпортировать во всей красе , Аноним (120), 14:41 , 10-Дек-23, (118) Горшочек вари В свое время намучился переустановками ос из-за обновлений и пл, Аноним (124), 15:12 , 10-Дек-23, (124) –1 Там ещё окаменелый софт со времён помёта мамонта Даже в этих условиях у кого-, Михалков (?), 15:50 , 10-Дек-23, (134) –2 Лучше бы дизайн нормальный нарисовали и выбрали один тулкит за стандарт, выброси, Аноним (150), 17:26 , 10-Дек-23, (150) // Нормальный дизайн давно нарисован - это win95-подобные схемы , Аноним (236), 19:01 , 11-Дек-23, (236) О, а я-то думал почему у меня при апгрейде E Failed to fetch 403 Access den, Аноним (162), 18:17 , 10-Дек-23, (162) Но зачем они притащили это в Debian стабильный, вот в чем вопрос Кто виновен в , Вася (??), 18:47 , 10-Дек-23, (166) –3 Установлен LMDE 6, uname -a показывает именно 6 1 0-14 Что теперь делать А как, Аноним (172), 19:26 , 10-Дек-23, (172) // См выше https www opennet ru opennews art shtml num 60261 138, Аноним (173), 20:07 , 10-Дек-23, (174) Читать Чернышевского и Ленина э-э-э Перезагрузиться в более раннюю, незаба, Аноним (79), 20:12 , 10-Дек-23, (175) +1 // И чем 5 15 не угодила , nox. (?), 22:13 , 10-Дек-23, (184) // А где в bookworm е версия 5 15 , Аноним (79), 22:40 , 10-Дек-23, (188) Смысле, что делать Загрузиться в предыдущую версию и ждать фикса Или вы из тех, Джентельмен Шоу (?), 03:31 , 11-Дек-23, (207) У меня после обновления ядра домашний сервачок в осадок выпал Пришлось ставить , Аноним (176), 20:22 , 10-Дек-23, (176) +2 И зачем нужны эти жалкие надстройки над EXT2 Почему бы просто не перейти на отве, Шишкин (?), 20:51 , 10-Дек-23, (177) +1 // Везде стоит ext2, она намного быстрее чем ext4 , Аноним (179), 21:22 , 10-Дек-23, (179) Дай набойчик на док где взять reiser5 и как потом применить , Аноним (192), 23:14 , 10-Дек-23, (192) Пофиксили, пришла обнова на 6 1 0-15 , eugener (ok), 21:47 , 10-Дек-23, (180) // да, так и есть обновил деб на втором ноуте, полёт норм , dannyD (?), 23:27 , 10-Дек-23, (194) Версия 6 6 6 на подходе Это знамения , Аноним (181), 21:52 , 10-Дек-23, (181) –1 // Последние времена настают, Аноним (79), 22:09 , 10-Дек-23, (182) // Всё ближе к демонам из FreeBSD , Аноним (192), 23:16 , 10-Дек-23, (193) Так ставь на Ext3 , nox. (?), 22:12 , 10-Дек-23, (183) –1 // у тебя ж ntfs , нах. (?), 12:52 , 11-Дек-23, (226) // Всего у меня в работе 4 компьютера ноутбуком что-то перестал пользоваться На , nox. (?), 14:06 , 13-Дек-23, (260) Но ведь сложность развесистых веток git оправдана как раз тем, что там не нужно , Аноним (186), 22:25 , 10-Дек-23, (186) // Кстати, там что-то типа https www atlassian com git tutorials comparing-workfl, Аноним (186), 15:43 , 11-Дек-23, (232) Debian стабильность, говорили они, и вот тебе на в стабильном дистрибутиве на , Аноним (197), 00:15 , 11-Дек-23, (197) –1 // Как достали дебилы, кричащие про протухшее ПО в Дебиане Хочется поновее - испол, Аноним (206), 03:13 , 11-Дек-23, (206) +1 // Но ведь testing или unstable вместе с новым ПО получают ещё большую нестабильнос, Аноним (197), 12:03 , 11-Дек-23, (222) А то что этот баг появился сперва в апстриме, в стабильной же версии ядра, мы ск, Аноним (208), 03:34 , 11-Дек-23, (208) +1 // что интересно - там ДВА бага Первый - тот что без особого шума был исправлен в , нах. (?), 09:40 , 11-Дек-23, (217) // Ну так в чем я не прав, пока нормальные дистрибутивы получили нормальный свежий , Аноним (197), 12:11 , 11-Дек-23, (224) нормальный свежий патч получить могли только любители сидеть на свеженьком тол, нах. (?), 12:51 , 11-Дек-23, (225) Демагогия , Аноним (197), 18:11 , 11-Дек-23, (235) Ну смысл в том что Debian должен был не попасть в просак из за особенностей его , Аноним (197), 12:09 , 11-Дек-23, (223) две сохраняет если не чистить apt autoremove , Аноним (219), 09:55 , 11-Дек-23, (219) Прекрасно по тексту таки непонятно --- это в kernel проблема или debian овском , yet another anonymous (?), 14:05 , 11-Дек-23, (227) // Перечитай первую строкуПроблема в ядре А разрабы Debian её заметили Но поздно , Пряник (?), 15:42 , 11-Дек-23, (231) // Дебиановский workflow во всй красе ни одного прямого указания на коммит в ядре , yet another anonymous (?), 23:14 , 11-Дек-23, (248) // они отгружают архив с kernel org, внезапно Без всякого понятия где и чьи там ко, нах. (?), 20:17 , 12-Дек-23, (258) Debian помогает искать баги в Linux , Пряник (?), 15:31 , 11-Дек-23, (228) +1 Версия ядра 6 6 6 вышла Страшно конпелять , Аноним (181), 15:47 , 11-Дек-23, (233) +1 Тысяча чертей Как можно было накосячить в коде ext4 Майки уволили криворуких ин, Минона (ok), 22:33 , 11-Дек-23, (243) // google silent data corruption ext4 ext3, ext2 впрочем о мертвых гугль обычно, нах. (?), 20:14 , 12-Дек-23, (257) 1,3,7,8,11,17,18,19,22,25,32,37,41,45,49,64,65,78,81,82,84,94,96,115,118,124,134,150,162,166,172,176,177,180,181,183,186,197,219,227,228,233,243

Сообщения

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

1. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
Сообщение от Аноним (1), 10-Дек-23, 11:30
> Пользователям уже установленных систем рекомендовано воздержаться от установки обновлений пакетов с ядром из репозитория до публикации исправления. А я уже установил, что мне делать?
Ответить | Правка | Наверх | Cообщить модератору

	5. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (5), 10-Дек-23, 11:33
	Мигрируй на бтрфс
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+5 +/–
	Сообщение от Аноним (29), 10-Дек-23, 12:00
	Чтобы не терять времени -- лучше сразу молотком комп разбить, чем сношаться с рассыпающейся от каждого чиха BTRFS.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–8 +/–
	Сообщение от Бывалый смузихлёб (?), 10-Дек-23, 13:10
	посоны поговаривают что бтрфс практически не рассыпается в отличие от практически не восстановимых при сбое ФС семейства экст№
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (-), 10-Дек-23, 14:17
	> посоны поговаривают что бтрфс практически не рассыпается в > отличие от практически не восстановимых при сбое ФС семейства экст№ Развалиться может что угодно - но в btrfs чаще всего предупреждение о проблемах все же есть сильно заранее, если системные логи мониторить хоть немного. А ext4 все пофиг, до того момента как объем факапа не нагнет все к чертям.
	Ответить | Правка | Наверх | Cообщить модератору

	263. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Олег (??), 17-Дек-23, 01:16
	Советую почитать форум Synology на предмет стабильности BRTFS) очень советую, ну это как пример сообщества активного BRTFS, других уж не знаю.... Разрушить ext еще постараться нужно, что не скажешь про кучу внутренних болячек BRTFS Вместо BRTFS лучше бы ZFS упомянули.... Вообще непонимаю что сподвигает людей всместо ZFS выбирать эксперементальный BRTFS, внедряли бы сразу уж Riserfs 5, фишек тоже тьма и с стабильностью так понимаю -+ также
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	86. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 10-Дек-23, 13:19
	Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каждый день рассыпается
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	151. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (151), 10-Дек-23, 17:27
	Слегка не так "Slight correction: we use btrfs for the disk image backing the user's crostini state only. The rest of Chrome OS, and the crostini VM rootfs, still use ext4."
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–1 +/–
	Сообщение от Анонимский (?), 10-Дек-23, 22:54
	> Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каждый день > рассыпается А что эти все делают и почему они вдруг в единственном числе?
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	104. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–2 +/–
	Сообщение от 128557 (?), 10-Дек-23, 14:09
	Может прекратить жить по модели бабки, разносящей не проверенные слухи, лишь бы обратили внимание? BTRFS хороша и стабильна.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	120. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+7 +/–
	Сообщение от Аноним (120), 10-Дек-23, 14:42
	сказала бабка
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от maximnik0 (?), 10-Дек-23, 16:10
	>BTRFS хороша и стабильна. Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,есть не хилый шанс не починить фс.Реально, средства проверки падают и хрен что сделаешь кроме отката.Это что за фс где из за одного файла вся фс в расскарячку становится :-( Я не спорю, сейчас гораздо она стала стабильный, и быстрей,уже детских ошибок нет,(по крайней мере приделали рабочий костыль_это я про дополнительное место для метаданных) но отсутствие рабочего fsck уже достало... Хорошо хоть все данные можно выципить. (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs хороша,такого конечно в ехт4 нету и хрен сделаешь....)
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	153. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (153), 10-Дек-23, 17:41
	>>BTRFS хороша и стабильна. > Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку, Люблю экспертов опеннета, всегда блеснут экспертизой... 1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет parity (RAID5/6, не рекомендуется, особенно второй). 2) CRC32 довольно хорошо ловит "битовые ошибки" типичные для факапов сторажей и глючного железа. 3) Если CRC32 мало под ваши требования есть xxhash, и даже sha256/blake2s - если надо ну вот реально неубиваемый хеш который хрен словит коллизию даже на петабайтах. Но если у вас хеш стресстестится - это наверное повод задуматься о смене гнилого железа так то. > есть не хилый шанс не починить фс. Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется ли чексум там. Избыточность с которой можно починиться либо есть, либо нет. Чудес не бывает. > Реально, средства проверки падают и хрен что сделаешь кроме отката. Сразу видно эксперта который btrfs видел только на картинке. И то не факт. > мере приделали рабочий костыль_это я про дополнительное место для метаданных) но > отсутствие рабочего fsck уже достало... Для меня это вообще ломовая фича в ситуациях где некому any key жать, оно просто работает, отклонения от идеала - парирует из другой копии. А отвечать на тупые вопросы на встраиваемых системах, да и серверах ВНЕЗАПНО, НЕКОМУ. Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными вполне может и скопытиться или потерять довольно много данных. Plan B на этот случай - нет. И даже RAID1 в подобной ситуации может и не помочь, особенно если накопитель как сейчас модно вернет труху без отлупа IO error, что конечно подляна - но бывает вот. > (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs > хороша,такого конечно в ехт4 нету и хрен сделаешь....) У EXT4 полное журналирование - капец тормозное. А без этого - он вообще класть хотел что с данными при крахе случится, его интересует только совпадение аллокаций свободного места с файлами, что там внутри файла... а вот что получится то и будет. Данных откатить это или довести до конца транзакцию без полного журнала нет. А с полным журналом - две записи вместо 1 будут. Сперва в журнал - намерения, потом в основной регион. Btrfs, bcachefs и ко читерят - идея cow в том что по сути журналом становится вся площадь. При этом более не надо переносить из журнала в основную область и вторая запись отпадает. К сожалению, это вызывает нужду в Garbage Collector ибо вечная история записей - все же сожрет место. И иногда надо все же подтирать. Такой подход приколен тем что при записи ничего не портится из существующего. А фикс консистентности делается ... простым игнором недописаного. Этого никогда не было - и все тут. Ведь все данные для предыдущего состояния - на месте. Отсюда и нужда в аллокации места для изменений. К метаданным это тоже применяется. Поэтому на btrfs всегда есть множество альтернативных точек входа для поыптки ре-парсинга. Это будут чуть более старые состояния, но возможно что нужный файл в нужном виде там был, а деревья этого состояния достаточно живые чтобы нужные файлы вынуть.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от penetrator (?), 10-Дек-23, 17:53
	xxhash64 в плане коллизий вполне надежен, он не криптографический, т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим аттакам (но ему и не нужно), а вот 64-битного пространства при его характеристиках хватает с запасом, можно посмотреть что отдает по нему SMHasher
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:56
	> xxhash64 в плане коллизий вполне надежен, он не криптографический, > т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим > аттакам (но > ему и не нужно), а вот 64-битного пространства при его характеристиках > хватает с запасом, можно посмотреть что отдает по нему SMHasher Ну дык можно вот его. Если кому совсем нечего делать, -dev версии btrfs-tools умеют конвертить тип чексум, на отмонтированой ФС. Я с сыпучей флехой поиздевался - оно даже допирает коррекцию сделать при такой конверсии походу, вот уж не ожидал то. Еще кстати из операций на отмонтированой ФС - bg_tree всячески рулит, особенно на механике, так оно маунтиться начинает быстрее чем даже ext4/bcachefswhatever.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+3 +/–
	Сообщение от Аноним (165), 10-Дек-23, 18:37
	> Я с сыпучей флехой поиздевался Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте, что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху" и закрыванием глаз на баги любимой ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (-), 11-Дек-23, 20:52
	>> Я с сыпучей флехой поиздевался > Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте, > что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху" > и закрыванием глаз на баги любимой ФС. 1) Мне все время рассказывают страшилки как я потеряю данные и проч. Уже какой там по счету год. А они все никак не теряются. 2) Есть ощущение что этот булшит часто ретранслируют кадры которые вон то не видели даже на картинке. А то и вовсе юзеры виндов позорные. Которые так то игнорят проблемы своих фетишей еще активнее, пытаясь даунплеить реально существующие проблемы. Коллекция глюкастиков наловленых btrfs'ом не даст соврать. 3) Я еще и с bcachefs экспериментирую - за примерно то же самое: продвинутый дизайн, обещающий опять же простой и удобный менеджмент :). Так что можете назло бабушке отморозить уши и ничего слаще EXT4 не использовать, кому хуже то?! А "евангелист" я только потому что мне нравятся продвинутые современные технологии - и крутые эффективные тимы разработчиков. Поэтому считаю несправедлимым тот крап который тут выдают те кто это вообше не юзал, но ценное мнение - имеют. И вообще, EXT4 всяким место на свалке истории. Дизайн который вечно тупит своими директориями которые он отрастить может, а сдуть нет, а то и вовсе налетает на недостаток, блин, инодов - и кладет с прибором на участь данных - это, извините, по современному состоянию дел - таки архаика. Ну как паровоз примерно. Вроде ездит - но желающих это делать вот так будет все меньше.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (195), 10-Дек-23, 23:55
	На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются, настолько переусложнена. Там по ходу разработки необходимость менять архитектуру возникала раза так два - изначальная ко всем новым задумкам не подходила. И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь и тупиковая ФС.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	238. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (-), 11-Дек-23, 21:03
	> На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются, Извольте-ка пруф на это храброе заявление предоставить? На ваше несчастье я этих разработчиков еще и знаю. И имел опыт взаимодействия с ними. Так что сейчас мы узнаем уровень вашей квалификации. Если не ответите и сольетесь - все понятно. Я даже могу назвать пару фич которые в разработке. Скажем Extent Tree V2, решающий ряд проблем масштабируемости на очень быстрых сторажах. А мне вот bg_tree очень понравился (since kernel 6.1), время монтирования скостил конкретно, особенно на механике. > настолько переусложнена. Там по ходу разработки необходимость менять архитектуру > возникала раза так два - изначальная ко всем новым задумкам не подходила. А теперь извольте показать - что там в архитектуре радикально поменяли? Желательно еще и с комитами где это случилось. Ща мы тут всех экспертов по полочкам и разложим, ибо дело мастера боится. > И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной > архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь > и тупиковая ФС. Если так рассуждать, то по таким стандартам NTFS это окаменелый помет динозавра, EXT4 и XFS - тоже окаменелые фекалии мамонта... а если так посмотреть, то новомодный bcachefs содрал процентов так 85-90 от именно архитектуры, именно btrfs'а. Ну не от вон тех же складов костылей, в самом то деле? И теперь файлухи будут делать - ну вот как-то так. Потому что перспективные паттерны дизайна. Сложное? Возможно, но эквивалентная этажерка md/dm/lvm/... - еще хуже, и, главное, менеджмент этого всего в том месиве уровней это подный крындец. Либо забить на все продвинутости типа чексумм, снапшотов, райды и прочь - и админить как будто на дворе 80-е прошлого века. Либо познать как выглядит боль. А потом сравнить с вон тем - и попробовать убедить себя использовать те деревянные оглобли еще раз...
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от maximnik0 (?), 11-Дек-23, 04:50
	>CRC32 - вообще не код коррекции ошибок! Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может обнаружить до 7 однобитных  ошибок для 1024 бит  и надёжно скорректировать 3 из них .Я это к чему-читал я в баг падчах что 1 битную ошибку все таки должен  btrfs-check ремонтировать если я правильно понял перевод. Теоретическая работа для коррекции 3 битных ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-... Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии......
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	240. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 21:43
	>>CRC32 - вообще не код коррекции ошибок! > Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может > обнаружить до 7 однобитных ошибок для 1024 бит и > надёжно скорректировать 3 из них . При сильном желании и SHA256 - код коррекции ошибок. Вот вам блок с эн левых битов, и тасуйте биты брутфорсом, пока SHA256 не сойдется! Сколько битов осилите сбрутфорсить, столько и ваше. Но какой-нибудь ридсоломон декодировать сильно быстрее, и починит намного больше. Но как чексум для вот именно валидации содержимого он не такой уж и сильный, рядом с SHA256 не стоял. Если даже некто и сбил автомобилем веротолет - это еще не делает автомобили ПВО. В btrfs - как минимум в обычном режиме, CRC32 сугубо как чексум и нужен сугубо для валидации прочитаного и единственное что интересует это коллизии, когда нечто левое будет проглочено как валидный блок. А восстановление из избыточной копии. И с вот этой частью механики я малость повозился и даже в стресстесты этого аспекта для тестов умею. > Я это к чему-читал я в баг падчах Что сие такое и есть ли у этого урл? > что 1 битную ошибку все таки должен btrfs-check Хотелось бы пруфлинк на это дело, чтоли. У меня сорц btrfs-tools если что есть. А так 1 бит и FEC накопителя обычно починит, левай случается когда он неосилил, и там уже что угодно может быть, кто ж знает что фирвар при этом выгружает. Да и идея в том что при избыточности оно self heal само на ходу делает. Прозрачно и без участия юзера. Это еще и ремапу проблемных секторов помогает, фирмваре стоража не надо пыхтеть пытаясь выдернуть нечитаемый сектор. EXT4 при таком будет как дятел ломиться в нечитаемый сектор, а запись туда может никогда и не случиться и ремапа не будет, будет сектор (и файл/метаданные) где всегда затык. > ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-...- > e6e82254-74722d776562/https/github.com/jeffareid/misc/blob/master/crccor3.c > Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии...... Концептуально, конечно, но с такими соотношениями - нахрена оно такое? Показать что автомобилем при очень сильном желании можно сбить вертолет?
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 11-Дек-23, 09:35
	> Люблю экспертов опеннета, всегда блеснут экспертизой... > 1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал, какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть. И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных по подписке за пару миллионов швейцарских франков, но это неточно.) > блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет > parity (RAID5/6, не рекомендуется, особенно второй). и если нам не повезло - нет второй или обе битые - "всеми щупальцами облизался и спрашивает - и что делать будиииим?!" Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?! > Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется надо же - в ext2 нет никакой второй копии - а починить ее обычно удается. Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое). >> Реально, средства проверки падают и хрен что сделаешь кроме отката. > Сразу видно эксперта который btrfs видел только на картинке. И то не если на картинке падают средства проверки - надо найти художника и выколоть ему глазки! > копии. А отвечать на тупые вопросы на встраиваемых системах, да и > серверах ВНЕЗАПНО, НЕКОМУ. внезапно, есть кому. Но на вопрос sigbus ответить кроме пол-второго и нечего. > Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными > вполне может и скопытиться или потерять довольно много данных. Plan B но все реальные случаи - почему-то именно с бырбырфэсе. > У EXT4 полное журналирование - капец тормозное. А без этого - он оно предназначалось для очень странного в те годы варианта быстрый журнал + медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже когда он появился. И оно предназначено вовсе не для защиты от крэша. > Btrfs, bcachefs и ко читерят - идея cow в том что по > сути журналом становится вся площадь. При этом более не надо переносить если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало. (я, кстати, честно не знаю где у нее и как, знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям разбирающимся в ней плохо. Нет, не спрашивайте как они доигрались - там все было плохо, не только не разбирались.) > А фикс консистентности делается ... простым игнором недописаного. Этого никогда не А теперь представим что это была страничка базы данных и она не совпадает с размером или алайментом блока...
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	244. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 22:50
	> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. Но по мере роста числа битов на брутфорс, наивное "декодирование" станет крайне ресурсоемким. > Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал, > какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть. В контексте btrfs-а меня интересует фактическое поведение self heal как ты понимаешь, а не абстрактные возможности сбития автомобилями вертолетов. > И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных > по подписке за пару миллионов швейцарских франков, но это неточно.) Да ну и болт с ним, а? У меня вон там шикарный ридсоломон есть, а вон там "очень странный формат сигнала". Но это к делу не относится. В вон том применении оно сугубо для детектирования ошибок. И есть на выбор несколько других алго для этого. > и если нам не повезло - нет второй или обе битые - Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или даже одном но исправном) сектора не прочтутся? А, это произведение вероятностей? А знаешь, вот так мне теорвер намного больше нравится. Если я вдруг смогу такой джекпот на реалистичных read error rate, числе секторов и проч - я тогда в ЛасВегас заеду, посмотреть что еще я могу. > "всеми щупальцами облизался и спрашивает - и что делать будиииим?!" Там для совсем параноиков есть RAID1C3 и даже C4. Если у тебя сразу столько сыпется - это чего? :) > Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?! В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он смогет? Констатировать что джеппа? Это очень ценно и полезно. И это если еще накопитель вернул io error а не выдал труху, иначе оно могло резко и внезапно скопытиться. Думаешь, CRC на журнал эти кадры от хорошей жизни налепили? Просто реплей кривого журнала - тома замешивает при случае совсем уж в спагетти имени рейзера, прищлось, вот, придумать хоть что-то. А btrfs даже на 1-девайсовой ФС хранит метаданные как DUP, что очень способствует тому чтобы не узнавать вон то "а что если". >> Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется > надо же - в ext2 нет никакой второй копии - а починить ее обычно удается. Агаблин, теорвер решил постебаться - на глаза попался EXT4 с бэдом под метаданными. Не то чтобы он вообще совсем помер - но это out of service и мануальные фиксы и потеря данных. Прости но мало кто хочет танцевать окучивая локалхост и откребая какие там еще ошметки, гоняя какие там еще fsck (что на современных объемах занимает немеряно времени). Хотят чтобы просто работало. Btrfs это и делает - пока это возможно. А если мануальное внимание надо - это всяко фейл. Ну и говоря за себя - я данные с такой штуки всяко достану, особенно с помощью вон того зала. > Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое). Это как неуловимый Джо. Людям от компьютеров надо чтобы работало. А не чтобы путем заклинаний подымать труп. Если он труп, требующий мануальщины это уже фейл. Кто мне будет на управляющем одноплатнике жать эникей? И отвечать на вопросы fsck? И на сервере кстати тоже. Да и на десктопе - я проснувшись в каде порисовать собирался, а не с fsck интерфеситься. И вопрос в том какой масштаб задника. Если это 1 бэд в сто лет, DUP его зарулил и на этом все закончилось это одно. Если хардвар осыпается и его надо инить/менять - окей, и чем мне вон то знание древних поможет? Тем что спрячет от меня факап и позволит порушить больше данных? > если на картинке падают средства проверки - надо найти художника и выколоть Как там твои средства проверки ZFS'а на тему факапов с копиями копий поживают? Помнится там диагностика проблемы была весьма компромиссным костылем. > но все реальные случаи - почему-то именно с бырбырфэсе. Мде? А почему я тогда рекаверил данные с NTFS и EXT4? Если btrfs с умом юзать - он вообще нагибаться ну вот не хочет чего-то. И это... у EXT4 in place запись очень даже деструктивная, в отличие от вон того. Так что если что-то затерлось в EXT4 - это уже совсем навсегда и отменить вообще совсем никак нельзя. Этого физически более нет. А вот в btrfs можно попытаться и выцепить немного более старое состояние если ну вот реально приспичило. Запись же недеструктивана, а GC в общем случае приходит не сразу. > оно предназначалось для очень странного в те годы варианта быстрый журнал + > медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже > когда он появился. И оно предназначено вовсе не для защиты от крэша. А что мне вообще делать с файлом где новая голова и старый хвост предлагается? Большая часть софта ЭТО жрать не будет. Всякие сжатые форматы словят decode error - и байбай. > если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало. У btrfs ответом на него является такая штука как "generation". Оно знает чего хочет (и насколько это актуально) - записи маркированы generation'ом. При серьезных расстыковках не станет маунтиться чтобы не разнести все. Мануально ессно есть ряд опций чтобы все же попытаться заякориться. Но это уже навороты и мануальщина. > (я, кстати, честно не знаю где у нее и как, Как минимум generation прописывается довольно много куда. Это нечто типа серийного номера очередного изменения, и по нему видно насколько это то что оно хотело. Если посмотреть логи офлайн вычитывалки и тому подобных продвинутых вещей - там бывает более подробно разрисовано как оно это видит - мол, это блоки такого-то файла, gen такой-то, но мы бы хотели gen такой-то, ищем дальше... > знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям > разбирающимся в ней плохо. У меня btrfs тоже не разваливался. А другим... ну я вот одному гражданину пул спас, сказав что у него ssd осыпается. Он очень радовался что ему вовремя на факап указали. Btrfs это чинил и еще не осыпался, но по логам было понятно что девайс просится в мусорку. > А теперь представим что это была страничка базы данных и она не > совпадает с размером или алайментом блока... Базы по сути сами наполовину файлухи - и используют свою логику журналинга. Это 1 из причин появления NOCOW. Если кто хотел косплеить ФС, с кастомной семантикой - пусть и косплеит, зачем ему вообше мешать? А делать 1 и ту же работу (журналинг, чексуминг, ...) 2 раза - вообще неоптимально. Если кто хотел фичесет EXT4 - btrfs "до кучи" может это ему дать! Но вообще конкретику ессно смотреть надо. Не тот случай когда универсальные ответы вида "а что будет если" есть. В целом - ФС оказывается в более старом консистентном состоянии. А БД, если ее писал не совсем кретин, своей семантикой должна форсить сброс буферов и фиксацию на диске данных в критичные для нее моменты. Если оно так делало - по идее семантика сохранится, очевидный минус - синк занимает энное время, так что перфоманс БД на CoW с типовыми паттернами - такое себе. Поэтому там и есть фича прикинуться "а я типа тоже EXT4, вот вам inplace патчинг, все как вы любите".
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 09:50
	>> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. > Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. все же щупал однокурсницу :-( > В контексте btrfs-а меня интересует фактическое поведение self heal практическое - kernel panic при попытке прочитать. > Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. потому что опыт ограничен одной сыпучей флехой. А на деле оно портится в памяти. (поэтому от корректирующего кода действительно ноль пользы) > А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или > даже одном но исправном) сектора не прочтутся? э... в реальном случае (один диск сдох совсем, второй из той же партии и того же возраста) - очень даже велика, но еще более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим? > В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он > смогет? смотря что за метаданные и что за бэд (не бывает у меня "бэдов", выкинь уже свою флэшку) смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное состояние, потеряешь только то что уже необратимо повреждено. За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью - ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще выкинуть чем разбираться. > В целом - ФС оказывается в более старом консистентном состоянии. спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 12-Дек-23, 19:04
	> все же щупал однокурсницу :-( Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования лекций CS западных вузов, по частной инициативе, с уклоном в современный state of art и практические применения. Поэтому мои знания имеют уклон в практические кейсы. Я понимаю основы и меня нельзя напугать какой-нибудь "дистанцией хэмминга" или полиномиальной математикой, да даже то что ридасоломон на полях галуа делает. Тем не менее, я пожалуй признаю что погорячился насчет заяв что CRC совсем не алгоритм коррекции. Некое его применение в этом качестве и правда возможно, так что в этом смысле я пожалуй погорячился. > практическое - kernel panic при попытке прочитать. Я что-то сравнимое видел 1 раз. В тестах, с -rc ядрами. На специфичной конфиге. Кредитсы по итогам разбора полетов (да, я впрягся и этого бага с нами уже нет) - ушли господам из mm/ с их рефакторами - реФАКтор вышел. Btrfs-ники виноваты тем что у них вылезло. Наверное и где-то еще, просто "где баг нашелся - там и гасится". Btrfs-ники компетентно и быстро вывели на чистую воду, пнули господ mm/, те резко зафиксили, я через полдня уже вертел патч фиксящий все это великолепие. Подтвердил что трабл починен, комитнули в майнлайн, вот, отлично, релиз не профакапили. Люблю хэппи энд :P. > потому что опыт ограничен одной сыпучей флехой. Неа. Еще оно несколько раз вполне успешно парировало редкие рандомные бэды, а еще у меня появилась коллекция глюкастиков - от шнурка до проца. И даже, вот - я ж писал что чуваку с энтерпрайзным ssd пул от разлета спас. А фигли, гад делал примерно то же что и флеха, только активнее. Чувак думал что это баг btrfs. Оказалось - сыпящийся SSDшник. Я понаблюдал, он такой дажеко не 1, лучше всего на это любители bcache (не того который fs) нарываются. > А на деле оно портится в памяти. > (поэтому от корректирующего кода действительно ноль пользы) Прикинь, в моей коллекции есть и несколько битых модулей памяти. И кроме всего прочего - я пользуясь случаем и немного поизучал как именно failure mode выглядит. Это как-то так: оно обычно видит CSUM error, вопит в лог, читает 2 копию, фиксит. На самом деле это не очень надо было (на стораже данные норм чаще всего), но кроме всего прочего это чинит буфер в RAM и проч, апликухам левак не уходит. Но самое главное - кривой хардвар хайлайтится. Да, вот тут с теорвером уже не стоит в кошки-мышки играть, проиграть однажды уже вполне реально. Я даже видел пару типов которые такой джекпот выиграли. На самом деле - в "зале" есть пара граждан которые изумительно просекают это, и ор на флипнутый бит в деревьях детектят влет (там есть некий sanity check). И вот тут - если "everything failed" можно гада реально флипнуть хексэдитором, но это для тех кто понимает дизайн и может такие вещи. Актуально только если избыточности ну вот не было, иначе оно само починит метаданные из другой копии, проблема прозрачно аннулируется и никакого хардкора. При том даже на 1-дисковой конфиге оно с неких пор DUP для метаданных делает, послав всех экспертов с "SSD дедублицирует, блаблабла" в пень - real world эксперименты показали что выживаемость ФС с DUP как метаданные - улучшается. В общем ты имхо недооцениваешь мое любопытство по части странных ситуаций. Но разумеется ВСЕ возможные взбрыки btrfs я не видел и врядли увижу. Да что там, я и все баги EXT4 наизусть не знаю. > э... в реальном случае (один диск сдох совсем, второй из той же > партии и того же возраста) - очень даже велика, но еще > более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим? На практике - таки обычно недурно парирует. Даже, вот, отгрузку трухи протертым энтерпрайзным SSD выживало, чувак думал что это баг btrfs. Пришлось объяснить что это "хана его энтерпрайз SSDшнику", а вовсе не. > смотря что за метаданные и что за бэд Ну и с btrfs'ом все примерно так же. Тем более что метаданные почти всегда дублированы. EXT4 так не умеет, однако. > (не бывает у меня "бэдов", Угумс. И труху накопители не возвращают. А как ты с нтфс и EXT4 это проверял то? > выкинь уже свою флэшку) Зачем? Кому баг, кому фича - теперь это реалистичный стресстест косплеящий вон то, возврат гамна без IO error наверх. Я и кентовскую штуку погоняю так - когда он привинтит некоторые запчасти на место, сейчас это еще малость негуманно. > смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное > место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное > состояние, потеряешь только то что уже необратимо повреждено. Вообще оно как бы да, неплохо чинится. Но технически это фейл: функциональность системы была потеряна, потребовалась мануальщина. Мне не надо жигуль с загаром, мне надо чтобы системы - работали. Пока это технически возможно. > За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью - EXT4 явно менее 30 лет... > ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без > журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще > выкинуть чем разбираться. Вот после каких-то таких прецедентов они кроме всего прочего приделали к журналу чексумы. Но между нами - это сейчас как обсуждение проблем джижка ржавых жигулей. > спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой. Ну так я о чем. Когда btrfs консистентный, то и данные обычно все же - в юзабельном формате. А базы таки - кастомные зверушки. Ими вообще лучше не заниматься если не понимать основы их механики, журнала, commit/rollback и прочего, иначе горя хлебнуть можно. А если это понимать - окей, можно осмысленно стыковать фичи движка и ФС, не вижу особых проблем. И если кому надо NOCOW - пусть сам и косплеит ФС, от вон того останется только управление местом/аллокацией по сути. Но БД чаще всего именно этого на самом деле и хотели. Они б и на RAW раздел бы, если б не было столько гимора с его администрированием. А в случае сабжа - баг таки весьма нишевой вышел, бэкпортеры бэк-испортили, и весьма резво заметили :). Это даже не к EXT4 претензия как таковая.
	Ответить | Правка | Наверх | Cообщить модератору

	255. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 19:51
	> Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования > лекций CS западных вузов боюсь что это уровень заборостроительного факультета. Я там вопрос задал - что надо спросить у гугля (на что он не ответит или даст только неправильные ответы) про itu-t crc ? Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ. И если бы тебя всерьез интересовала сохранность данных - ты был бы в ах...е от того на каких соплях и магических ритуалах вместо знаний построены технологии. > Я понимаю основы Чувак - основы - это вот рид-соломон. Его вообще никто не понимает, ни одна живая душа. Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно, обоим должно быть за 90. Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни к какому реальному делу. На CS этому не учат, этому учат на мехмате, и то не всех. Приложили к делу - некто профессор Планк со ученики (и ученицы, но это тоже неточно). "всего" через 35 лет сумев ту писанину прочитать и придумать как ее употребить. Через ШЕСТЬ гребаных лет некто по имени Dung заметил ашиппочку. Обмишулились чуток - очень похоже что университетская типография просто листик на пол уронила, или он к предыдущему прилип. Сводящую  все эти шаманские действия банально к х-ю. Вот это были - практики (ну старались, как могли). А ты - увы, в лучшем случае смог бы - скопипастить. Нет, это тоже не так легко  и просто, и понадобился еще один чувак - некто Peter Anvin. Вот он уже оставил (и до сих пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это, помножь вон на то, сложи вот с тем, и получившееся считай своими данными, раз уж часть массива накрылась. Небольшая проблемка была в том, что он это в первый раз сделал в 2002м году. А Ding нашел отклеившийся листик - в 2003м. Чуешь чем пахнет? P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или сразу перешел к готовым рецептам. ЧТО в ней самое странное и на самом деле - страшное, в очередной раз вызывающее ужас от соплей на которых построена цивилизация ?
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (265), 19-Дек-23, 06:23
	>> лекций CS западных вузов > боюсь что это уровень заборостроительного факультета. Меня интересуют "практические применения" и "детали реализации". Я этим пользуюсь для моих проектов - поэтому в курсе схем с неплохими соотношениями и интересными (мне) свойствами. Часть знаний optimized out, современный мир в 1 голову не лезет. > Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ. У меня ограниченный запас времени + дофига проектов которые я хочу попробовать. И перегруженный знаниями мозг ("фуллстэк" между хардом и софтом пушит меня за лимиты, но это и делает меня мощнее). Поискарь запросами? Только если gain стоит efforts! Пример: я запустил годный ридсоломон, даже на атмеге голимой ОК, сделав нехилый рефактор (и починив пару вулнов древних). Могу осмысленно параметризовать это (без лекций CS я б нихрена не понял). В паре с "странным форматом сигнала" превзошло самые дикие фантазии. Вон то расширит мои возможности так же? > И если бы тебя всерьез интересовала сохранность данных - ты был > бы в ах...е от того на каких соплях и магических ритуалах > вместо знаний построены технологии. Я частично видел. И даже сам смог некторые "ритуалы". После трансляций старинных рун из int в bin, без уверенности 100% эквивалентности... "signal acquired" сказало фирмваре =). Этого комбо никогда не существовало. Слишком примитивно для инопланетян, слишком сложно для землян. Мне стало интересно "а работает ли"? Я нашел ответы на свои вопросы. "В воздухе повисло присутствие". Теперь я знаю как это. В небольшом bias между рандомом и почти рандомом - бесконечность. Кстати, новомодный LDPC - научная версия "highly likely" вообще :P. Никаких ГАРАНТИЙ вообще IIRC нету. Зато соотношение DATA/FEC хорошее, за что и популяризовался. Правда в основном в эфирных делах. Меня больше это в контексте FEC интересовало. >> Я понимаю основы > Чувак - основы - это вот рид-соломон. Его вообще никто не понимает, > ни одна живая душа. Не все же такие мощные как те Древние. Обычный землянин с тех правил математики поделит на ноль. Но я смог отрефакторить за древними рунические письмена на древнем диалекте си, ничего не сломав и (после чтения paper'ов) дописав пару штук, посмотреть тонка ли у меня кишка. Заодно узнав на своем заду почему таблицы "с константами от богов" в рантайме считать плохая идея. Зато, вот, таблицы в RAM могу теперь генерить примерно как некоторые CRC, в фирмвари это выбор "flash size" VS "RAM usage". Для этого таки пришлось немного въехать в странноватую полиномиальную математику. > Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно, > обоим должно быть за 90. ЧСХ они изначально сформулировали свое добро заметно иначе чем это делают современные реализации. > Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни > к какому реальному делу. Я прицепил эту загогулину корректировать ошибки, правда, по воздуху, в той черной магии как раз не выделяется, остальное получилось под стать :). И да, они в оригинале сформулировали это заметно иначе. Современные объяснения заметно отличаются, в реальном коде - еще больше отличаются. > На CS этому не учат, этому учат на мехмате, и то не всех. Остальные с ума сойдут от такой математики. Но вон тем не покажут как это эффективно делать на реальных микропроцессорах с разумными параметрами. Это знание вообще есть у считанных единиц Древних на всю планету. Которые как-то смогли в оба мира. Их немного. Кст в вике где-то есть объяснение декодирования ридсоломона на тупом примере, для самых маленьких, экстраполяция на мелких числах, графически, показывающая "core" идеи. ЧСХ - нет, ЭТО не в статье про ридсоломона, ибо нефиг :). Операции над полиномами тоже найти можно но тоже в одупляемом виде где-то в сторонке. Или, вот, лекциях CS западных вузов, более нацеленных на то чтобы студень мог если не накодить свой - так хоть осмысленно юзать и рефакторить чужое. С пониманием почему оно такое и что он делает. > или он к предыдущему прилип. Сводящую  все эти шаманские действия > банально к х-ю. Это ты про одно из современных описаний RS как частного случая BCH чтоли? > Вот это были - практики (ну старались, как могли). А ты - > увы, в лучшем случае смог бы - скопипастить. Я таки - вот - рефакторнул и даже отсебятины немного докорябал. Хоть и очень примерно понимал что я делаю, но имеючи рунические таблицы древних я мог сравнить результат да посмотреть лажается мой код или нет (да, я никогда не настаивал что я эксперт в операциях над полиномами транслироваными в двоичную систему). > - некто Peter Anvin. Вот он уже оставил (и до сих > пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это, > помножь вон на то, сложи вот с тем, и получившееся считай > своими данными, раз уж часть массива накрылась. Я как ни странно больше с парой других реализаций развлекался, они больше для передачи данных в неидеальном мире - а я именно этого и хотел. Для блочных дел - как я понимаю ридсоломон может быть весьма урезанный, там предполагается что все "erasures" известны. В случае comm мы далеко не всегда знаем где у нас erasures и там соответственно полное декодирование. > в 2002м году. А Ding нашел отклеившийся листик - в 2003м. > Чуешь чем пахнет? Каким-нибудь факапом. Но как я уже сказал - не понимаю почему ты уверен что я прошел тот же путь что и ты, изучая это все дабы не быть абизяной и понимать что я делаю и почему, и даже иметь возможнось read/write этого кода. Что так то полезно - минус 2 вулна за дидами с референсом отрицательных индексов и переполнениями int-ов :) > P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или > сразу перешел к готовым рецептам. ЧТО в ней самое странное и > на самом деле - страшное, в очередной раз вызывающее ужас от > соплей на которых построена цивилизация ? Тех - это каких? CSовские лекции западных универов неплохо описывали именно то что я видел в фактической реализации. Это позволило довольно комфортно в ней шариться и я смог позволить себе рефактор и фикс вулнов, и даже оптимизации, понимая граничные условия и проч. А вот диды в этом деле слажали - и повесили пару вулнов. Что в коде потенциально кушающем random (или НеРандом) из эфира меня несколько напрягает. Почему-то.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:53
	> Мигрируй на бтрфс Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так можно получить странные баги.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	213. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 11-Дек-23, 09:23
	>> Мигрируй на бтрфс > Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки > не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так > можно получить странные баги. блжад, да в каком месте у вас хоть изредка бывает не так?!
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 21:52
	> блжад, да в каком месте у вас хоть изредка бывает не так?! Чудак. Файлуха при этом врапает себя в свободное место имевшейся ФС. 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где нашлось место". Поэтому перфоманс такого комбо - ну вот как повезет. 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код в редко используемых закоулках на странных комбо - это можно. Вот прям ща - оно, таки, вроде уже работает без особых приколов. Но с учетом 1) все равно очень на любителя комбо. 3) Если хочется побыковать на глючность фичи - окей, оно глючно по сравнению С КЕМ? Кто так вообще еще умеет? Я еще у кента какие-то зачатки этого видел. Ну он с его cow дизайном тоже может попытаться такие фортели в принципе. Для реализации такого пируэта надо CoW с write-anywhere структурой. Иначе номер не получится. Ведь надо втискиваться уж где есть место.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 09:53
	>> блжад, да в каком месте у вас хоть изредка бывает не так?! > Чудак. Файлуха при этом врапает себя в свободное место имевшейся ФС. > 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где для fs рекламируемая фича которой безобидное увеличение на ходу - не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то. Это даже хуже ntfs (у той только и беды что mft не посередине где теоретически оптимальнее, а где получилось) > 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код > в редко используемых закоулках на странных комбо - это можно. Вот нет, спасибо, у меня growfs таки очень обыденный случай, когда дотестите, тогда и приходите. > 3) Если хочется побыковать на глючность фичи - окей, оно глючно по > сравнению С КЕМ? Кто так вообще еще умеет? Я еще у fat2ntfs существует 25 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 12-Дек-23, 19:41
	>> 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где > для fs рекламируемая фича которой безобидное увеличение на ходу - > не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то. ПЦ какой-то  - "по сравнению с чем"? А кто еще умеет вообще внутрь себя врапать чужой ФС, да еще с возможностью отмены конверсии? Ну вот EXT4 в ZFS например вообще сконвертить - смогешь? Для референса в сравнении? А для понимания... как-то раз я под виндой хотел NTFS размер урезать и новый раздел втулить. Всего лишь. На том компе не было упса, я нашел какую-то прогу... шел примерно 30-й час ресайза (всего то, бжд) - и тут грохнулось питание. Догадайся что было дальше. DataRecovery мое давнее хобби, я большую часть выцепил, но "по...ться завернуть" резко подвалило. Надеюсь, это объясняет почему я полюбил управление местом btrfs, там это совсем иначе. Он по backref уберет что надо - совсем не за 30 часов если не хотеть чего-то вообще странного, а крах при этом похрен, т.к. у COW записи недеструктивные. Оно либо не успело "указатели перевесить" и провалившаяся операция - самоотменится, либо успело - и это "успешный commit" в терминах транзакций. > Это даже хуже ntfs (у той только и беды что mft не> посередине где теоретически оптимальнее, > а где получилось) Когда тебе надо вписаться вокруг уже существующей ФС - НЕ ИСПОРТИВ ЕЕ - ибо декларится возможность отката (можно получить старую ФС в исходном виде) - там, видишь ли, придется осетра урезать - и делать аллокации сугубо на свободном месте оригинала. Это на самом деле - офигеннейшее сбитие автомобилем вертолета, показывающее гибкость аллокатора и мощь CoW. Большинство inplace дизайнов так тупо не сможет - за отсутствием гибкости или фиксированного размещения структур. Но начать от этого считать что автомобили - отличное ПВО. По перфомансу этот кейс оптимальным быть не может - структуры новой ФС вкроены туда где было свободное место оригинальной ФС. Это и позволяет откат до старой ФС при таком желании. Если структуры оригинала трогать - ок, а как на это откат делать тогда?! А ты ТАКОЕ вообще с ZFS например смогешь вообще? Или с чем там еще? Такая технология требует CoW для "write anywhere" аллокаций, чтобы вписаться в свободное место другой ФС. На уровне абстракций - прикольно, имхо. >> 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код >> в редко используемых закоулках на странных комбо - это можно. > Вот нет, спасибо, у меня growfs таки очень обыденный случай, когда дотестите, Это не про grow. Прицепить еще +девайс - без проблем. И место добавится. Но вот лэйаут конверченой из другой ФС файлухи - "странный": btrfs вписывается в свободное место существовавшей ФС. Не трогая ее - дабы иметь возможность отката на оригинал. Представляешь, можно вернуться на старую ФС (конечно без изменений записаных в btrfs). Это круть cow механики. Вон то - нечто типа readonly базы, относительно которой cow будет дельту делать. Можно это снести, тогда откат на старую ФС станет невозможен. Однако лэйаут останется "странный" и в более адекватный вид приводится ребалансом + дефрагом для более разумной аллокации. А NTFS - попробуй впиши допустим в свободное место вон того EXT4? И как, хорошо получается? :) > тогда и приходите. Да оно вроде работает и даже баги более-менее поубиваля - просто я сразу на старте понимаю что из-за особенности технологии "мы сбили автомобилем вертолет" - лэйаут после такой конверсии будет не особо оптимальный, пришлось вписываться в свободное место чужой ФС уж как оно там есть. > Я еще у fat2ntfs существует 25 лет. Окей, а там можно откатиться на FAT если NTFS тебе не понравился? Вон то видите ли CoW механику использует, вообще не руша оригинал по сути :). Недеструктивная запись довольно круто отличается от in-place операций. В частности и - вот - возможностью UNDO этого всего. Это одно из лучших свойств CoW технологий.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 20:07
	>>> 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где >> для fs рекламируемая фича которой безобидное увеличение на ходу - >> не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то. > ПЦ какой-то  - "по сравнению с чем"? А кто еще умеет > вообще внутрь себя врапать чужой ФС, да еще с возможностью отмены отмены в какой момент? И что будет если управляющие структуры лежат по одинаковым офсетам (уж суперблок-то точно)? > конверсии? Ну вот EXT4 в ZFS например вообще сконвертить - смогешь? > Для референса в сравнении? вопрос в наличии места где это можно сделать. Его понадобится - много. > А для понимания... как-то раз я под виндой хотел NTFS размер урезать > и новый раздел втулить. Всего лишь. На том компе не было > упса, я нашел какую-то прогу... шел примерно 30-й час ресайза (всего ну может дело было в какой-то проге? А может в том что места банально не было. > то, бжд) - и тут грохнулось питание. Догадайся что было дальше. Казалось бы, что? При переписывании файлов внутри журналирующей метаданные fs? У скольких мильенов навернулось питание при ночном defrag? > крах при этом похрен, т.к. у COW записи недеструктивные. Оно либо > не успело "указатели перевесить" и провалившаяся операция - самоотменится, либо успело > - и это "успешный commit" в терминах транзакций. либо места на бесконечное стадо коров - не хватило. > Когда тебе надо вписаться вокруг уже существующей ФС - НЕ ИСПОРТИВ ЕЕ то на ней просто должно быть достаточно свободного места для манипуляций с двумя fs сразу. Чудес не бывает. > - ибо декларится возможность отката (можно получить старую ФС в исходном > виде) - там, видишь ли, придется осетра урезать - и делать и зачем она нам? Какое-то совсем ненужное действо. Нам нужно просто не потерять данные, а этот откат - ну ок, один из возможных механизмов. Как видим, довольно непростой и дорогой в реализации, может попроще стоило выбрать? Напоминаю, возможность ресайза вниз у ext4 - встроенная фича. > откат до старой ФС при таком желании. Если структуры оригинала трогать > - ок, а как на это откат делать тогда?! А ты А зачем он нужен? Нам нужно просто не потерять данные если что-то пойдет не так. Точки восстановления, не, не слышали? > Это не про grow. Прицепить еще +девайс - без проблем. И место > добавится. Но вот лэйаут конверченой из другой ФС файлухи - "странный": понятно. Лучше видимо избегать таких чудес. > дабы иметь возможность отката на оригинал. Представляешь, можно вернуться на старую > ФС (конечно без изменений записаных в btrfs). Это круть cow механики. троллейбусизбуханкижпг нам не надо обратно раз уж мы полезли в это - очевидно что мы хотим оригинал заменять (и вовсе не хотим выяснять потом как добавить к нему изменившееся, даже если откатимся). Нам надо просто не потерять данные если в процессе что-то сбойнет. Но, видимо, был выбран механизм по принципу "где светлее". > Окей, а там можно откатиться на FAT если NTFS тебе не понравился? нет, зачем он мне если мы от него пытаемся уйти? Что-то мне подсказывает что ТАКОЙ мне бы точно не понравился.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (265), 19-Дек-23, 05:59
	> отмены в какой момент? IIRC "пока не снесен subvol с файлом-образом старой ФС". Забавная абстракция, а? :). Посмотри в их readthedocs детали, прикольно придумано. > И что будет если управляющие структуры лежат по одинаковым офсетам (уж суперблок-то точно)? Не помню что там, вероятно несколько блоков физически удвигают. Логически, старая ФС вписана в btrfs как "файл образа" в subvol "ее снапшота". Это защищает старый фс, оформляя все аллокации (включая и метаданные) как аллокации btrfs. При откате видимо возврат нескольких блоков назад. Остальное... у оригинала ничего и не менялось! Конвертор сделал btrfs метаданные, которые референсятся на те же файлы, поскольку трогать их было нельзя из-за защиты снапшотом, cow при записи выноски делает. Это идет в btrfs free space, которое заодно и extX free space был. Поскольку Ext метаданные никто не апдейтил, откат ессно в оригинальное состояние, как и ожидаемо от снапшота. > вопрос в наличии места где это можно сделать. Его понадобится - много. Его надо... 1) Для служебных структур btrfs. 2) Для свободного места btrfs. Это вполне умеренно, bulk data никто не кантует! Конечно метаданные btrfs будут дублировать метаданные оригинала, но блоки будут референснуто прям из оригинала, не надо их копировать. Это ж cow/write anywhere! Что куда хочет то и референсит. Поэтому может и вон то защитить, и отреференсить, и запись редиректнуть в безопасный регион. Помнишь я говорил что ты не понимаешь истинную мощь технологий cow и write-anywhere? Это пример того что оно может. > ну может дело было в какой-то проге? А может в том что места банально не было. Я думаю что дело в том что в NTFS нет backrefs... Кент вон уже тоже заметил что у его сарая нет стены^W backrefs и скорость операций...не та которую он хотел! > Казалось бы, что? При переписывании файлов внутри журналирующей метаданные fs? А таки разлет был хорош. Записи же деструктивные! Это не cow где сперва "планируемую" копию сделали, а потом перевесили указатели, после чего GC может подгребать деаллоцированый старый вариант и мало места для лажи. А в деструктивной записи малейшее отклонение от идеала и усе, факап. > У скольких мильенов навернулось питание при ночном defrag? Не знаю. Но нескольким из - я вынимал данные с немоунтабельной виндой напроч нтфсины. Пришлось и вон там ту же магию, внепланово. Я более-менее все выцепил но времени убилось в разы больше планируемого и в итоге закончилось полным data move -> repartition -> возврат данных. Убийство времени и позор менеджмента систем. > либо места на бесконечное стадо коров - не хватило. Бесконечное не надо - только на маневровый регион, остальное GC может подгребать наздоровье, оно уже ни для чего не используется. После перевеса указателей - старый регион подлежит деаллокации. Теоретически надо места на 1 двигаемый экстент. Практически конечно супернеоптимально в таком виде. > то на ней просто должно быть достаточно свободного места для манипуляций с > двумя fs сразу. Чудес не бывает. Есть 1 чудо: указателей на регион может быть более 1. Блоки  будут реюзануты, место сожрется на второй набор метаданных. И конечно блоки оригинала нельзя деаллоцировать пока есть снапшот, иначе как откатывать?! Это просто креативное использование фич CoW. Люблю такое, так системщиков и архитектов видно. > и зачем она нам? Какое-то совсем ненужное действо. В случае btrfs 1) возможен откат на оригинал! крутое и стебное использование механики снапшотов. 2) конверсия делается с минимумом интрузива - основной объем не кантуют. > Нам нужно просто не потерять данные, а этот откат - ну ок, один из возможных механизмов. Ага! При этом с данными - да и метаданными старой ФС - ничего не случается, поводов для жесткого дестроя минимум. Они креативно крафтят второй набор метаданных по сути :) > Как видим, довольно непростой и дорогой в реализации, может попроще стоило выбрать? Чего такого дорогого в генерации второго набора метаданных по уже имеющемуся? Самое плохое что с этого происходит - не особо оптимальный лэйаут структур. Но это более-менее лечится, в доках написано как. > Напоминаю, возможность ресайза вниз у ext4 - встроенная фича. И чего? Ну попробуй вписать EXT4 в какой-нибудь другой ФС не разнося ту ФС в хламину. Сорян чтобы это работало - надо CoW семантику умеющую write anywhere. > А зачем он нужен? Нам нужно просто не потерять данные если что-то пойдет не так. > Точки восстановления, не, не слышали? По моему они наоборот намного красивее тех костылей сделали. Юзанули мощь cow по полной и по сути 2 набор метаданных создают. И если юзер захочет то может откатиться на старую фс. Прикольная манифестация настоящей мощи cow. > понятно. Лучше видимо избегать таких чудес. Да. И про это в доке написано, как и что сделать если снапшот снесен для оптимизации лэйаута. Но абстракция стебная. И да - кому-то идея зашла, и они внешний тул ntfs2btrfs сделали, то же самое делает как я понимаю. > троллейбусизбуханкижпг нам не надо обратно раз уж мы полезли в это - очевидно > что мы хотим оригинал заменять (и вовсе не хотим выяснять потом > как добавить к нему изменившееся, даже если откатимся). Откат на снапшот - подразумевает потерю изменений с момента снапшотирования. Это как раз ожидаемое поведение абстракции "снапшот". > Нам надо просто не потерять данные если в процессе что-то сбойнет. > Но, видимо, был выбран механизм по принципу "где светлее". Когда в руках молоток, все вокруг кажется гвоздями. Зачем изобретать костыли если вся механика умеющая это и намного круче уже была?! >> Окей, а там можно откатиться на FAT если NTFS тебе не понравился? > нет, зачем он мне если мы от него пытаемся уйти? Eval сделать - с возможностью передумать. > Что-то мне подсказывает что ТАКОЙ мне бы точно не понравился. А я таки проперся таким импользованием механики фс. Норм сбитие вертолета автомобилем. Ну и откат такой технологии должен быть достаточно прост и мало что может обломаться. Если не создавать себе проблем "точками отката" и проч, не придется их героически решать.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (6), 10-Дек-23, 11:36
	откати ядро , старые из реп не исчезли
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	50. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+3 +/–
	Сообщение от Аноним (50), 10-Дек-23, 12:26
	Даже ничего откатывать не надо. В Debian легко можно загрузиться с предыдущим ядром, оно никуда не исчезает.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (73), 10-Дек-23, 12:50
	Это если за консолькой сидеть в момент загрузки и ручками выбирать ядро в грубе. А так он загрузит последнее установленное ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 12:55
	В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT (только после сохранения вызывать update-grub)
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (102), 10-Дек-23, 13:55
	>В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT (только после сохранения вызывать update-grub) А разве там не systemd-boot по умолчанию?
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:47
	>> В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT >> (только после сохранения вызывать update-grub) > А разве там не systemd-boot по умолчанию? В дебиане то? GRUB там самый обычный.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (167), 10-Дек-23, 18:49
	Самый необычный. Пропатченный гигантcкими листингами на Си, не проходившими код-ревью апстрима, чтобы сделать то, что делается одной строчкой на шелле. С уникальными уязвимостями, которых не бывало нигде, кроме Дебиана.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Джентельмен Шоу (?), 10-Дек-23, 23:09
	> Самый необычный. Пропатченный гигантcкими листингами на Си, не проходившими код-ревью > апстрима, чтобы сделать то, что делается одной строчкой на шелле. С > уникальными уязвимостями, которых не бывало нигде, кроме Дебиана. И этот великолепный господин конечно же предоставит к ознакомлению портянку с багтрекера, где куча этих "уникальных уязвимостей, которых не бывало нигде, кроме Дебиана", дабы эти заявления не были голословными! ;)
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 22:54
	> Самый необычный. Пропатченный гигантcкими листингами на Си, > не проходившими код-ревью апстрима, чтобы сделать то, что делается > одной строчкой на шелле. Нельзя ли пруфануть это все? > С уникальными уязвимостями, которых не бывало нигде, кроме Дебиана. И как насчет URL? CVE? А так сабж тоже специфичен для бэкпортированых ядер. У полисей как и у медали есть 2 стороны. Это оборотная сторона фиксирования версии - иногда можно и уникальный баг словить. Но вообще это случается раз в дохрена. В отличие от развалов федороарчей где суицидникам выгружают на головы свежак "как есть".
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	105. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от 128557 (?), 10-Дек-23, 14:11
	> В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT А если вместо grub'а используется boot.efi?
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	126. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Мимосисадмин (?), 10-Дек-23, 15:24
	То человек должен уже знать, что делает
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+4 +/–
	Сообщение от Аноним (10), 10-Дек-23, 11:40
	Перезагрузитесь с использованием более раннего ядра, дебиан сохраняет 3 версии ядра при обновлениях.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	74. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 12:53
	6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) А версия 6.1.0-14-amd64 забагованная, да?
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (79), 10-Дек-23, 13:09
	Да, именно эта забагованная.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 13:28
	Спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 11:42
	Ты пакеты не разу не откатывал что-ли? Посмотри в апт логе старые версии пакетов, да запусти apt install с ними.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	38. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (38), 10-Дек-23, 12:13
	Страдать ¯\_(ツ)_/¯
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	83. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (83), 10-Дек-23, 13:12
	Пользоваться. Эти мэйнтенеры всё равно ничего не понимают. К тому же каждый пользователь Рачика признает вас своим корешем.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	93. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–2 +/–
	Сообщение от НяшМяш (ok), 10-Дек-23, 13:36
	Только вот пользователям рачика это давным-давно починили, а они и не заметили. А любителям окаменевшего наоборот сломали.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:49
	> Только вот пользователям рачика это давным-давно починили, > а они и не заметили. А любителям окаменевшего наоборот сломали. Вооюще-то как раз заметили - и не выкатили провальный релиз.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 11-Дек-23, 09:38
	> Только вот пользователям рачика это давным-давно починили, а они и не заметили. все равно каждый день переставляют, а прона нового всегда можно накачать. > А любителям окаменевшего наоборот сломали. а этим да, неповезло - они-то может хранили не только одноразовый прон.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	199. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Андрей04091977 (ok), 11-Дек-23, 01:26
	Обновление ядра с исправлением уже прилетело
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	259. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Cimeries (?), 12-Дек-23, 21:21
	Тоже поставил 14 версию , а потом еще накатил последнюю 15 и после этого апгрейда перестал выключатся комп! В итоге загружаюсь с 13 сейчас!  Теперь что делать не знаю! Ждать следующего обновления?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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