Идентификация по серийному номеру (или, например, MAC-адресу) имеет один существенный недостаток - надо настраивать для каждого экземпляра устройства.
Т.е. если вы делаете девайс с тремя сетевыми платами, серийно делаете, хотя бы по 100 штук в месяц - вас задолбает привязка по МАС-адресу каждой платы в каждом девайсе.
А ещё при ремонте - плату заменил, меняй правила в udev. А меняет - местный персонал, который открутить-прикрутить может, а вот прописать правило в udev - нет.
Это как минимум чрезвычайно неудобно.
--------------------
Можно конечно скрипт написать, типа "вставьте кабель/нажмите/где лампочка зажглась скажите" - который бы позволял более-менее автоматизировать привязку по серийнику. Но всё равно неудобно.
Делов-то! Всё это ИИ-говно тупо убыточно и живёт за счёт роста "пузыря". Пузырь лопается, и остаётся вонючий запах и миллионы нагенерированных котиков.
Вообще именно в RAID это очень, очень вероятно. Скорее всего ваши SSD диски "умерли" из-за того, что количество записей на них превысило порог перехода в режим "только чтение".
А так как это RAID, количество записей на них более-менее одинаковое...
Открою вам большой секрет - только вы не обижайтесь.
Если взять существующий продукт и переписать его заново - да хоть на том же языке - он станет существенно качественнее и безопаснее.
Просто потому, что при переписывании продукта - сразу известно что и как он должен делать, как должен быть устроен и почему именно так.
Поэтому говорить "переписали говнокод на Раст и сразу стало хорошо" - смысла не имеет. Можно переписать на кондовый С - и тоже будет хорошо.
Потому что это - переписанный код.
------------------------
Ну, а по поводу "безопасности памяти" в целом: знаете, если бы люди реально хотели "безопасной памяти" - то просто запретили бы выпускать цифровые устройства любого типа с памятью без ECC. Память с чётностью - и случайных падений и странных зависаний становится на порядок меньше.
Потому что эти библиотеки начали разрабатывать до того, как появился в принципе СМаке.
Да, это так. Я, например, такой старый, что помню, что когда-то CMake не было.
А когда он появился, то далеко не сразу стал достаточно распространённым, чтобы серьёзную библиотеку перенесли на него. Системы сборки, извините, каждый год новые появляются.
Можно. Это называется - контрольная сумма достаточной разрядности. По крайней мере от шумовых помех ( а не от целенаправленной генерации ложных сообщений ) защитит надёжно.
Реально интересная история. Многого не знал. Хотя в своё время перестроечную литературу по этой теме читал.
Но, похоже, более-менее понятно, почему так получилось с Вавиловым: его открытия, конечно, великие, и имя своё он в историю вписал.
Но: реальной отдачи от них в пределах десятилетий - не было и быть не могло.
Ну не было у СССР в тот момент возможности заниматься фундаментальной наукой без очевидной привязки к прикладному применению.
А Лысенко напирал именно на прикладное применение. И - правдиво или нет - какие-то результаты демонстрировал.
С Королёвым, кстати, та же самая штука случилась: потратил деньги на проект, который изначально (на том уровне развития техники) был невозможен. Но ему повезло больше, и он дожил до момента, когда его идеи осуществились.
------------------------
Кстати, насчёт Вавилова-шпиона. Есть теория, что он действительно был шпионом - в смысле, что его путешествия по всяческим ебеням использовались спецслужбами СССР для маскировки своей разведдеятельности. Всё-таки его выпускали за границу, и снабжали валютой - не верится, что "под чистую науку".
Ой блин, а нельзя было наклеить плитки на стену и подогреть выхлопом из того же реактивного двигателя?
А то, что "металлические плитки окисляются при высокой температуре" - блин, да за то, что у них нет в команде химика и материаловеда - или они их тупо не слушают - надо руководство ставить к стенке.
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
Идентификация по серийному номеру (или, например, MAC-адресу) имеет один существенный недостаток - надо настраивать для каждого экземпляра устройства.
Т.е. если вы делаете девайс с тремя сетевыми платами, серийно делаете, хотя бы по 100 штук в месяц - вас задолбает привязка по МАС-адресу каждой платы в каждом девайсе.
А ещё при ремонте - плату заменил, меняй правила в udev. А меняет - местный персонал, который открутить-прикрутить может, а вот прописать правило в udev - нет.
Это как минимум чрезвычайно неудобно.
--------------------
Можно конечно скрипт написать, типа "вставьте кабель/нажмите/где лампочка зажглась скажите" - который бы позволял более-менее автоматизировать привязку по серийнику. Но всё равно неудобно.
Делов-то! Всё это ИИ-говно тупо убыточно и живёт за счёт роста "пузыря". Пузырь лопается, и остаётся вонючий запах и миллионы нагенерированных котиков.
Не кончится. Бабла немерянно - его тупо печатают. Поэтому эта песня будет вечной - и крахнется вместе с финансовой цивилизацией в целом.
Вообще именно в 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 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
Халява! Оплачивается госдепом США. Всё ради процветания и демократии в Иране!