Вообще именно в RAID это очень, очень вероятно. Скорее всего ваши SSD диски "умерли" из-за того, что количество записей на них превысило порог перехода в режим "только чтение".
А так как это RAID, количество записей на них более-менее одинаковое...
Открою вам большой секрет - только вы не обижайтесь.
Если взять существующий продукт и переписать его заново - да хоть на том же языке - он станет существенно качественнее и безопаснее.
Просто потому, что при переписывании продукта - сразу известно что и как он должен делать, как должен быть устроен и почему именно так.
Поэтому говорить "переписали говнокод на Раст и сразу стало хорошо" - смысла не имеет. Можно переписать на кондовый С - и тоже будет хорошо.
Потому что это - переписанный код.
------------------------
Ну, а по поводу "безопасности памяти" в целом: знаете, если бы люди реально хотели "безопасной памяти" - то просто запретили бы выпускать цифровые устройства любого типа с памятью без ECC. Память с чётностью - и случайных падений и странных зависаний становится на порядок меньше.
Потому что эти библиотеки начали разрабатывать до того, как появился в принципе СМаке.
Да, это так. Я, например, такой старый, что помню, что когда-то CMake не было.
А когда он появился, то далеко не сразу стал достаточно распространённым, чтобы серьёзную библиотеку перенесли на него. Системы сборки, извините, каждый год новые появляются.
Можно. Это называется - контрольная сумма достаточной разрядности. По крайней мере от шумовых помех ( а не от целенаправленной генерации ложных сообщений ) защитит надёжно.
Реально интересная история. Многого не знал. Хотя в своё время перестроечную литературу по этой теме читал.
Но, похоже, более-менее понятно, почему так получилось с Вавиловым: его открытия, конечно, великие, и имя своё он в историю вписал.
Но: реальной отдачи от них в пределах десятилетий - не было и быть не могло.
Ну не было у СССР в тот момент возможности заниматься фундаментальной наукой без очевидной привязки к прикладному применению.
А Лысенко напирал именно на прикладное применение. И - правдиво или нет - какие-то результаты демонстрировал.
С Королёвым, кстати, та же самая штука случилась: потратил деньги на проект, который изначально (на том уровне развития техники) был невозможен. Но ему повезло больше, и он дожил до момента, когда его идеи осуществились.
------------------------
Кстати, насчёт Вавилова-шпиона. Есть теория, что он действительно был шпионом - в смысле, что его путешествия по всяческим ебеням использовались спецслужбами СССР для маскировки своей разведдеятельности. Всё-таки его выпускали за границу, и снабжали валютой - не верится, что "под чистую науку".
Ой блин, а нельзя было наклеить плитки на стену и подогреть выхлопом из того же реактивного двигателя?
А то, что "металлические плитки окисляются при высокой температуре" - блин, да за то, что у них нет в команде химика и материаловеда - или они их тупо не слушают - надо руководство ставить к стенке.
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
Вообще именно в RAID это очень, очень вероятно. Скорее всего ваши SSD диски "умерли" из-за того, что количество записей на них превысило порог перехода в режим "только чтение".
А так как это RAID, количество записей на них более-менее одинаковое...
Мониторьте SMART:
177 Wear_Leveling_Count 0x0013 099 099 005 Pre-fail Always - 4
Как падает со 100% до меньше 50% - думайте о замене. По-моему, в read-only он переходит на 20%.
У меня на простейшем зеркале количество записей на оба диска в паре - практически одинаковое, различие в 4 знаке.
Открою вам большой секрет - только вы не обижайтесь.
Если взять существующий продукт и переписать его заново - да хоть на том же языке - он станет существенно качественнее и безопаснее.
Просто потому, что при переписывании продукта - сразу известно что и как он должен делать, как должен быть устроен и почему именно так.
Поэтому говорить "переписали говнокод на Раст и сразу стало хорошо" - смысла не имеет. Можно переписать на кондовый С - и тоже будет хорошо.
Потому что это - переписанный код.
------------------------
Ну, а по поводу "безопасности памяти" в целом: знаете, если бы люди реально хотели "безопасной памяти" - то просто запретили бы выпускать цифровые устройства любого типа с памятью без ECC. Память с чётностью - и случайных падений и странных зависаний становится на порядок меньше.
Потому что эти библиотеки начали разрабатывать до того, как появился в принципе СМаке.
Да, это так. Я, например, такой старый, что помню, что когда-то CMake не было.
А когда он появился, то далеко не сразу стал достаточно распространённым, чтобы серьёзную библиотеку перенесли на него. Системы сборки, извините, каждый год новые появляются.
Можно. Это называется - контрольная сумма достаточной разрядности. По крайней мере от шумовых помех ( а не от целенаправленной генерации ложных сообщений ) защитит надёжно.
Без ограничений, т.е. из организма не выводится.
Реально интересная история. Многого не знал. Хотя в своё время перестроечную литературу по этой теме читал.
Но, похоже, более-менее понятно, почему так получилось с Вавиловым: его открытия, конечно, великие, и имя своё он в историю вписал.
Но: реальной отдачи от них в пределах десятилетий - не было и быть не могло.
Ну не было у СССР в тот момент возможности заниматься фундаментальной наукой без очевидной привязки к прикладному применению.
А Лысенко напирал именно на прикладное применение. И - правдиво или нет - какие-то результаты демонстрировал.
С Королёвым, кстати, та же самая штука случилась: потратил деньги на проект, который изначально (на том уровне развития техники) был невозможен. Но ему повезло больше, и он дожил до момента, когда его идеи осуществились.
------------------------
Кстати, насчёт Вавилова-шпиона. Есть теория, что он действительно был шпионом - в смысле, что его путешествия по всяческим ебеням использовались спецслужбами СССР для маскировки своей разведдеятельности. Всё-таки его выпускали за границу, и снабжали валютой - не верится, что "под чистую науку".
К сожалению, кодируют. И Ё, и Й кодируют. Я сам нарывался - при копировани из MS Excel названия документа - скопировалость именно таким образом.
Не представляете, как потом бесило то, что файл не мог быть найден в файловой системе - хотя вот он, блин, лежит.
Но это не проблема UTF-8 - это Unicode в целом.
Ой блин, а нельзя было наклеить плитки на стену и подогреть выхлопом из того же реактивного двигателя?
А то, что "металлические плитки окисляются при высокой температуре" - блин, да за то, что у них нет в команде химика и материаловеда - или они их тупо не слушают - надо руководство ставить к стенке.
Извините за вопрос - а ЗАЧЕМ нужен абсолютный детерменизм в машинном обучении?
Возможно, имеет некоторый смысл при тонкой оптимизации/отладки собственно алгоритмов разработчиками библиотек МЛ - но для обычных целей - зачем?
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Ну выбирай, будешь крепостным или колхозником?
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
Халява! Оплачивается госдепом США. Всё ради процветания и демократии в Иране!
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Это и называется галлюцинацией нейросети.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
А критиковать Троцкий начал именно тогда, когда проиграл во внутрипартийной борьбе. А проиграл, потому что не смог предложить ничего разумного.