У нас есть реальная проблема того, что водители Яндекса или просто таксисты повально убивают или грабят пассажиров?
По такой логике рак лечить тоже не нужно, доля умерших от рака около 0.11% от населения планеты — вообще ни о чём.
Если проблема не носит массового характера — это не значит что её можно игнорировать, более того, если её игнорировать, она может стать массовой через некоторое время.
И почему-то у меня есть подозрение что если вдруг что случится с вашими близкими из-за таксиста — вы скорее всего пересмотрите свою точку зрения. А так да — пока это лично вас не коснулось и вероятность мала, конечно это "не проблема" и "такова жизнь".
Для вас — не нормально, ок, ваши проблемы. Для других — не вы определяете нормы, извините.
Почти любой родитель беспокоится за своего ребёнка которого он лично отвёл в садик, школу, на танцы — но "не решает проблему". Ему не нужно, он просто беспокоиться — и это нормально. Позвольте другим людям вести себя так как они считают нужным — по крайней мере пока это не имеет отношения к вам.
PS: И нет, "беспокоиться" — это необязательно "звонить, проверять, доставать" — это часто происходит молча и даже тот о ком беспокоятся об этом не догадывается.
Честно говоря так себе альтернатива, по крайней мере в сдаваемых в аренду квартирах и прочих помещениях — владелец может и не разрешить ставить тарелку, а в ряде мест они вообще могут быть запрещены по "эстетических" соображениям.
Беспокоиться за близких — совершенно нормально, и неважно сколько им лет, и также совершенно неважно насколько им реально что-то угрожает, что важно — это как вы себя чувствуете если не знаете где они, или когда их нет там и тогда когда вы их ожидаете.
Когда этот самый — на минуточку, совершенно взрослый — человек просто в такси едет?
То есть с совершенно взрослым человеком который едет в такси совершенно ничего не может случится — например инсульт, ну или там лобовое с камазом? Это такая временная неуязвимость и гарантия абсолютной безопасности на время поездки?
Скорее всего он сдох по другим причинам, не связанных с шифрованием, потому что с точки зрения диска разницы нет, а VeraCrypt пишет ровно столько же данных сколько писалось бы без шифрования.
К тому же, по одному случаю судить несколько преждевременно.
К примеру, полное шифрование диска сильно увеличивает износ.
За счёт чего? С точки зрения накопителя абсолютно ничего не меняется, разве что записанные нули не будут таковыми — некоторые накопители используют это как хинт для трима, но если использовать трим то и это несущественно.
Вы, вероятно, русскоязычный перевод читали? Потому что в оригинале чётко видно:
Disabling swap does not prevent disk I/O from becoming a problem under memory contention, it simply shifts the disk I/O thrashing from anonymous pages to file pages.
Поразительно, но в русскоязычной версии это звучит совсем иначе:
Отключение подкачки не мешает дисковому вводу/выводу стать проблемой при работе с памятью, а просто сдвигает дисковую подкачку ввода/вывода с анонимных страниц на файловые.
И куда же делось "under memory contention" (это можно перевести как "нехватка памяти")?
Второй момент тоже ссылается на OOM:
Disabling swap doesn't prevent pathological behaviour at near-OOM, although it's true that having swap may prolong it.
Но самое важное идёт чуть дальше, где он описывает ситуации, в частности отсутствие нехватки памяти:
With swap: We can choose to swap out rarely-used anonymous memory that may only be used during a small part of the process lifecycle, allowing us to use this memory to improve cache hit rate, or do other optimisations. Without swap: We cannot swap out rarely-used anonymous memory, as it's locked in memory. While this may not immediately present as a problem, on some workloads this may represent a non-trivial drop in performance due to stale, anonymous pages taking space away from more important use.
Со свопом — мы может улучшить попадание кэша и ещё что-то мелкое, но очевидно что если памяти более чем достаточно они и так будут хороши. А без свопа — таки да — после дождичка в четверг, когда (если) рак на горе свистнет — отсутствие свопа может стать проблемой и когда памяти достаточно, но это не точно. Я вот на своих и клиентских системах (многие не имеют свопа) и не встречал такого, да и кубернеты его не используют и не жужжат.
Так что да, мнение специалиста существенно — если конечно читать его полностью.
Ирония в том, что при отключенном свопе minidump для анализа будет недоступен, т.к. его логи пишутся используя своп.
А смотреть на processhacker/taskmanager в фоне? Проверить журнал после падения? С вероятностью 99.9% проблема в том что кто-то сожрал всю память — и это обычно видно и без minidump.
А чем своп-то мешает? Если нет места на диске, просто купите диск побольше
Вы же не будете покупать лопату для уборки снега и зимнюю одежду если в вашем регионе температура не опускается ниже 30°C? Они ведь не мешают.
Так посмотрите что именно вызывает BSOD и что происходит в системе перед ним — очень маловероятно что это связано с нехваткой памяти.
У меня на вынь всего 32GB и никакого свопа — и я не могу вспомнить когда у меня был BSOD или даже просто нехватка памяти, всё просто работает, при этом иногда (если лень апдейты ставить) аптайм до полугода доходит.
И для вынь и для линь верно одно — если памяти хватает для всех потенциально запускаемых одновременно приложений — своп не нужен. Если без него возникает проблема нехватки — добавьте оперативки. Если бюджет или железо не позволяет — ок, тогда выхода нет и придётся добавлять своп.
С основателями там всё в порядке — их биографии проверяемы. Один вёл миссии NASA, второй занимался проектами в MIT которые спонсировались NASA, DoD и FAA, ещё один вполне себе профессор астронавтики.
Что касается NB IoT — то эксперименты по связи со спутнками напрямую уже были и вполне успешны, и как это ни странно Skylo к ним приложил руку, вместе с израильским подразделением Sony.
В общем это гораздо больше похоже на правду чем на развод.
Допустим что валидация занимает существенное время (даже если речь про int64 — да, существенное), и у вас функция которая должна обрабатывать данные, но вызывается она уже после валидации на верхнем уровне, который обязуется предоставлять только правильные данные и берет на себя все риски с этим связанные (для простоты — представте grep -E '^[0-9]+$' перед вашим stdin).
Вы правда при таком раскладе обвешаетесь валидацией? Ладно это парсинг int64, но данные могут быть гораздо сложнее а стоимость их валидации — даже в разы выше стоимости обработки (напомню — вам "сверху" гарантируют правильные данные).
Нет. Потому что не может быть garbage in, значит не может и out. По определению. Может там на входе стоит железный валидатор, или стадо обезьян всё проверяет лапками — это неважно, на входе гарантированы только целые числа.
Если вы будете писать библиотеку или функцию/приложение для неясно кого — да, валидация может быть нужна (но это не точно), если вы работаете с данными полученными от неизвестно кого неизвестно откуда — нужна безусловно, но во всех остальных случаях — нужно исходить из условий конкретной задачи. Всё же иногда людям (и данным) можно и нужно верить.
Если речь о целых в десятичной записи (и вообще любой где база кратна 2), то разрядность не имеет значения — ими можно оперировать как строками, а чётность определять по последней цифре.
По такой логике рак лечить тоже не нужно, доля умерших от рака около 0.11% от населения планеты — вообще ни о чём.
Если проблема не носит массового характера — это не значит что её можно игнорировать, более того, если её игнорировать, она может стать массовой через некоторое время.
И почему-то у меня есть подозрение что если вдруг что случится с вашими близкими из-за таксиста — вы скорее всего пересмотрите свою точку зрения. А так да — пока это лично вас не коснулось и вероятность мала, конечно это "не проблема" и "такова жизнь".
Для вас — не нормально, ок, ваши проблемы. Для других — не вы определяете нормы, извините.
Почти любой родитель беспокоится за своего ребёнка которого он лично отвёл в садик, школу, на танцы — но "не решает проблему". Ему не нужно, он просто беспокоиться — и это нормально. Позвольте другим людям вести себя так как они считают нужным — по крайней мере пока это не имеет отношения к вам.
PS: И нет, "беспокоиться" — это необязательно "звонить, проверять, доставать" — это часто происходит молча и даже тот о ком беспокоятся об этом не догадывается.
Честно говоря так себе альтернатива, по крайней мере в сдаваемых в аренду квартирах и прочих помещениях — владелец может и не разрешить ставить тарелку, а в ряде мест они вообще могут быть запрещены по "эстетических" соображениям.
Чтобы бы ставить диагнозы нужно быть врачём соответствующего профиля и тщательно изучить конкретную ситуацию.
А границы тут у каждого свои — если беспокойство не наносит вреда и не мешает жить — это не должно волновать никого кроме того кто беспокоится.
Беспокоиться за близких — совершенно нормально, и неважно сколько им лет, и также совершенно неважно насколько им реально что-то угрожает, что важно — это как вы себя чувствуете если не знаете где они, или когда их нет там и тогда когда вы их ожидаете.
У меня обычный бензиновый автомобиль, но за последние полгода я заправлялся всего три раза, так что вполне себе сбылось.
То есть с совершенно взрослым человеком который едет в такси совершенно ничего не может случится — например инсульт, ну или там лобовое с камазом? Это такая временная неуязвимость и гарантия абсолютной безопасности на время поездки?
Скорее всего он сдох по другим причинам, не связанных с шифрованием, потому что с точки зрения диска разницы нет, а VeraCrypt пишет ровно столько же данных сколько писалось бы без шифрования.
К тому же, по одному случаю судить несколько преждевременно.
За счёт чего? С точки зрения накопителя абсолютно ничего не меняется, разве что записанные нули не будут таковыми — некоторые накопители используют это как хинт для трима, но если использовать трим то и это несущественно.
Это только если не вся толпа такая, а если вся — то вроде как раскраски (пока) вполне законны, даже в толпе.
Не назовёте эти "другие параметры" — доступные для изменений без пересборки ядра (через /sys или /proc)?
Вы, вероятно, русскоязычный перевод читали? Потому что в оригинале чётко видно:
Поразительно, но в русскоязычной версии это звучит совсем иначе:
И куда же делось "under memory contention" (это можно перевести как "нехватка памяти")?
Второй момент тоже ссылается на OOM:
Но самое важное идёт чуть дальше, где он описывает ситуации, в частности отсутствие нехватки памяти:
Со свопом — мы может улучшить попадание кэша и ещё что-то мелкое, но очевидно что если памяти более чем достаточно они и так будут хороши. А без свопа — таки да — после дождичка в четверг, когда (если) рак на горе свистнет — отсутствие свопа может стать проблемой и когда памяти достаточно, но это не точно. Я вот на своих и клиентских системах (многие не имеют свопа) и не встречал такого, да и кубернеты его не используют и не жужжат.
Так что да, мнение специалиста существенно — если конечно читать его полностью.
А смотреть на processhacker/taskmanager в фоне? Проверить журнал после падения? С вероятностью 99.9% проблема в том что кто-то сожрал всю память — и это обычно видно и без minidump.
Вы же не будете покупать лопату для уборки снега и зимнюю одежду если в вашем регионе температура не опускается ниже 30°C? Они ведь не мешают.
Так посмотрите что именно вызывает BSOD и что происходит в системе перед ним — очень маловероятно что это связано с нехваткой памяти.
У меня на вынь всего 32GB и никакого свопа — и я не могу вспомнить когда у меня был BSOD или даже просто нехватка памяти, всё просто работает, при этом иногда (если лень апдейты ставить) аптайм до полугода доходит.
И для вынь и для линь верно одно — если памяти хватает для всех потенциально запускаемых одновременно приложений — своп не нужен. Если без него возникает проблема нехватки — добавьте оперативки. Если бюджет или железо не позволяет — ок, тогда выхода нет и придётся добавлять своп.
С основателями там всё в порядке — их биографии проверяемы. Один вёл миссии NASA, второй занимался проектами в MIT которые спонсировались NASA, DoD и FAA, ещё один вполне себе профессор астронавтики.
Что касается NB IoT — то эксперименты по связи со спутнками напрямую уже были и вполне успешны, и как это ни странно Skylo к ним приложил руку, вместе с израильским подразделением Sony.
В общем это гораздо больше похоже на правду чем на развод.
Допустим что валидация занимает существенное время (даже если речь про int64 — да, существенное), и у вас функция которая должна обрабатывать данные, но вызывается она уже после валидации на верхнем уровне, который обязуется предоставлять только правильные данные и берет на себя все риски с этим связанные (для простоты — представте
grep -E '^[0-9]+$'перед вашим stdin).Вы правда при таком раскладе обвешаетесь валидацией? Ладно это парсинг int64, но данные могут быть гораздо сложнее а стоимость их валидации — даже в разы выше стоимости обработки (напомню — вам "сверху" гарантируют правильные данные).
Нет. Потому что не может быть garbage in, значит не может и out. По определению. Может там на входе стоит железный валидатор, или стадо обезьян всё проверяет лапками — это неважно, на входе гарантированы только целые числа.
Если вы будете писать библиотеку или функцию/приложение для неясно кого — да, валидация может быть нужна (но это не точно), если вы работаете с данными полученными от неизвестно кого неизвестно откуда — нужна безусловно, но во всех остальных случаях — нужно исходить из условий конкретной задачи. Всё же иногда людям (и данным) можно и нужно верить.
Условия задачи гарантируют только целые числа, а так да — нужно проверять чтобы были только цифры на входе.
Это почему? Почти вся спутниковая связь построена на ГСО, просто их достаточно много чтобы перекрыть всю планету.
Если речь о целых в десятичной записи (и вообще любой где база кратна 2), то разрядность не имеет значения — ими можно оперировать как строками, а чётность определять по последней цифре.