Только если она утекла в оригинальном виде. Если это хэш (fuzzy или обычный), то успехов в восстановлении оригинальной фотки.
При нормальном раскладе, биометрические данные не должны хранится в оригинальном виде, а только в пост-обработанном виде, который позволяет их сравнивать с оригиналом. Многие сканнеры отпечатков сканнеров работают именно по такому принципу, подозреваю что другая биометрика тоже. Красть такие данные имеет смысл только если злоумышленник намерен сам идентифицировать жертв, а вот подделать что-то он не сможет, разве что банальным брут-форсом, генерируя картинки или подставляя имеющиеся.
Следующим этапом (хотя прототипы есть и сейчас) будет сочетание обычной биометрики со вспомогательными данными — т.е. при сканировании лица, к примеру, будет ИК-сканирование (тепловизор), который сразу отметёт фотографии и маски. Можно, конечно, сделать маску которая «прогреется» на лице, но это не так просто. Такой же метод + «сигналы жизни» можно применить и к отпечаткам пальцев/рук — т.е. ИК-скан + объёмный скан + пульс и насыщение крови кислородом (как у медицинских пульсометров, правда, простым прикладыванием пальца уже не обойтись).
В общем, есть куда развиваться, так что не всё так плохо.
В разных странах разные законы. В Германии, к примеру, нельзя просто взять и поставить камеру с видом на общую улицу (любое общественное место), даже в окне своего дома — это считается нарушением приватности. Камера смотрящая прямо на клочок перед дверью — пожалуйста, пока не видно тех кто к двери не подходит, равно как и камера с видом на свой двор (но не соседский). Впрочем, в любом случае придётся вешать лейбл «видеонаблюдение» и (если кто-то поинтересуется) объяснить с какой целью ведётся видеонаблюдение — иначе это тоже незаконно.
Второй момент заключается в том, что даже если сам факт видеонаблюдения не нарушает закон, то запись нельзя публиковать или иным способ распостранять без разрешения лиц которые на ней — в том числе отдавать на просмотр какой-то частной фирме, которая не имеет к нему прямого отношения (т.е. охранная фирма, к примеру, может это просматривать, другие — нет). Суд, полиция etc конечно могут получить доступ к видео, если потребуют.
Я очень подозреваю что аналогичные законы есть в большинстве развитых стран, и если даже видеонаблюдение само по себе разрешено, то не факт что разрешена запись, её распостранение, публичная демонстрация или передача третьим лицам.
Не хотите, чтобы разработчики имели доступа к вашим видео — не ставьте себе камеру, которая загружает в облако видео и считает там какую-то аналитику.
Есть сервисы которые не пускают разработчиков к видео, они просто их хранят (даже в зашифрованном виде) — тут проблем нет, вся ответственность на пользователе, если они утекут по его вине.
В данном же случае, как минимум, нарушены права тех кто оказался записан на видео — потому что они 100% не давали согласия что это видео будет просматривать непонятно кто.
В T&C сервиса Ring нет ни слова про аналитику или доступ к видео кому-то кроме пользователя, и даже если бы это упоминалось, это было бы незаконно (потому что, опять-таки, нужно получить разрешение записываемых, что практически неосуществимо).
Собственно, именно те кто оказался записан и могут предъявить претензии, вне зависимости от чего-либо — если докажут факт утечки или доступа, разумеется, причём связка с реальным именем пользователя тут не играет никакой роли.
Насколько я понимаю, сервис можно использовать чисто для экспериментов? Потому как отсутствуют какие-либо гарантии (SLA) и уверенность в том что он вдруг резко не станет очень платным и не прекратит существование.
Честно говоря, аутсорсить проверку паролей кому-то совершенно чужому — как-то очень стрёмно, ибо если что — то сервис превращается в тыкву, ничего не работает, пользователи негодуют и всё такое.
В Letsencrypt много кто заинтересован, посему шансы что он умрёт уж очень малы (несмотря на бесплатность), да и альтернативы есть, но тут совсем другое дело.
По факту оно и не нужно, если бы GDPR и его аналоги распостранялись на всех.
Увы, GDPR не запрещает сбор данных, он просто выставляет к нему определенные требования, в частности, явное согласие пользователя на их сбор, его право на opt-out и удаление уже собранных данных. Но после первого согласия до opt-out данные уже могут быть собраны, а удаление проверить невозможно — есть где разгуляться для нечестных разработчиков, особенно если они из Китая или Индии, а пользователи где-то в других странах.
Единственным действенным методом воздействия может быть только жёсткая политика платформы — если бы приложения, которые безусловно запрашивают неадекватные разрешения (т.е. те которые не необходимы для выполнения основной функции приложения) явно помечались красным флажком с пометкой «потенциально небезопасно» и понижались в рейтинге поиска, тогда бы лёд тронулся (мало кто захотел бы такой флажок).
По хорошему, «правильный» магазин приложений должен требовать от разработчика обосновать наличие того или иного разрешения, и отказывать в публикации если обоснование слабое (к примеру, доступ к контактам в приложении для фотографий, или доступ к GPS в календаре — и то и другое могут выполнять свои функции без контактов и GPS).
Но маловероятно что такой магазин появится, или выживет (если таки появится) — разве что подобные требования введут на уровне закона, что, в свою очередь, приведет к другим проблемам.
А еще не написали патч, который позволяет эмулировать выданный доступ?
Есть вполне законный способ это делать для большинства разрешений без рута (но только для Android 6.0 и выше).
Можно поставить Shizuku Manager, дать ему доступ с помощью adb (инструкция прямо в приложении), потом поставить App Ops — и рулить как угодно.
Если доступ к чему-то закрыт в App Ops, то приложению (если оно его запрашивает) можно сказать Allow — оно всё равно ничего не получит (пустой список контактов, SMS etc), хотя будет уверено что разрешение получило.
Закрыть таким образом доступ в сеть нельзя, но контакты, микрофон, камера, GPS и ещё куча всего (включая возможность работать в фоне) — вполне можно.
Используются стандартные возможности Android, никакой магии (отбирать доступ можно просто с помощью adb — до переустановки приложения), эти два приложения просто удобный UI.
Я могу, разумеется, ошибаться, но мне кажется логичным что TBW относится к количеству «честных» TB записанных на SSD (NAND), а не то количество которое получено от хоста — хотя бы потому что могут вмешаться компрессия и кэш.
Кэш же (на самом накопителе) может уменьшить реальное количество записей на NAND в случае, если в течение короткого времени перезаписываются одни и те же участки диска (LBA) — если эти перезаписи делаются до того как он сброшен на NAND (а это может быть и несколько секунд), то в итоге на NAND попадают только последние записанные данные. Т.е., к примеру, если кэш сбрасывается раз в 5 секунд (условно), а мы эти 5 секунд будем непрерывно писать только в сектора 0-1023, то в итоге Host writes будет намного больше чем NAND writes. Кэш также может использовать другую стратегию, типа процента «грязных блоков», в этом случае время сброса в NAND (после записи от хоста) может и минут достигать (будь я разработчиком SSD, так бы и сделал, если бы мог гарантировать сброс кэша или его сохранность при выключении питания).
При размере кэша в 512M-1G это вообще может быть очень существенная разница, в зависимости от того что и как пишет на SSD — к примеру, если это что-то типа часто обновляющейся RRD базы размером который помещается в кэш, и софт который в неё пишет не создает новые файлы а переиспользует их (типа кольцевой буфер на диске). Поскольку обычно кэшу всё равно, пишутся данные рандомно или последовательно (важно лишь наличие сектора в нём), то экономия может быть очень существенной.
И насчёт «40 гигов в день в течение 5 лет» — в вашем случае вы умудрились записать больше 800 за 241 час, что в два раза больше чем 40/день. Опять-таки, я могу ошибаться, но 40гиг/день (а не общее TBW) может быть неспроста — вполне возможно что более высокая нагрузка его и убила. Это конечно не механика, но я могу себе представить что у него кэш который расчитан на то что эти самые 40 гиг он ещё может успевать раскидать всё как положено в течение суток (если не спит и не отключен), а если больше то начнёт «задыхаться», повышая степень износа (либо NAND, либо компонент).
Никто ж не спорит, оно может ещё долго прожить, но для случаев когда доступность и сохранность особенно важны (т.е. позволить себе неожиданный даунтайм для смены диска и восстановления тяжко, и это не RAID) — я бы сразу начал искать замену.
Иногда случается когда между первым появлением переназначенных секторов и их лавинообразным ростом или даже смертью диска проходит совсем немного времени — поэтому лучше упредить такую ситуацию, если есть возможность. SSD нынче дешевы, не то что 10 лет назад.
Даже если у вас регулярные бэкапы или там нет ничего «такого», представьте ситуацию — после очередной перезагрузки/включения (или в процессе работы) диск вдруг умирает и вам внезапно приходится тратить несколько часов времени (пусть даже «всего» час-два) на поиск замены, восстановление всего что нужно и т.п. — приятного мало, однако. Если же вы на выезде в этот момент — ситуация ещё неприятней, поэтому я лично предпочитаю действовать с упреждением (а на выезд обычно беру с собой запасной ноутбук поменьше, но с копией всего что на первом).
Для этой серии, насколько я знаю, Intel не указывает TBW (и много других важных параметров), но для меня сигналом к замене послужил бы первый перераспределенный сектор или первое использование резервной области.
Разница в значениях host writes и nand writes (если они правдивы) скорее всего связана с кэшем (если он там есть, ибо спецификация молчит и об этом тоже), другого логичного объяснения я не вижу.
И конечно же, нельзя исключить что именно конкретный экземпляр оказался дефектным и поэтому прожил так недолго (если это единичный случай), ибо записанные 840GiB даже при размере SSD в 60GB было бы слишком мало, даже для TLC. С другой стороны, раз уж у него гарантия 5 лет, то им явно проще их менять чем делать надёжными.
По своему опыту выбора SSD для серверов скажу, что просто даже не смотрю в сторону тех где в спецификации так мало данных (пусть даже это известный бренд), особенно если не упоминаются TBW и наличие кэша (как DRAM так и SLC). Если выбора нет, то относительно безопасно оценивать количество циклов перезаписи для TLC в районе 250-300, но это имеет смысл только если SMART позволяет мониторить NAND writes.
К сожалению, в статье нет совершенно никакой информации о том в каком режиме работал почивший, его срок службы и сколько уже было данных записано относительно TBW в спецификации, даже конкретная модель не указана. Вполне может быть что он уже был на границе (или даже за ней) и использовался очень интенсивно (ZFS хороший генератор нагрузки сам по себе, за счёт контрольных сумм и «деревянной» структуры записи).
Если верить некоторым тестам на живучесть, многие SSD (даже самсунги) спокойно переживают записи за пределами спецификаций, молчат в SMART до последнего, но при этом превышают TBW в несколько раз, а умирают молча и внезапно.
С другой стороны, массовых жалоб о внезапной смерти SSD при обычных декстопных нагрузках вроде как в сети не наблюдается, так что для обычных пользователей ситуация не настолько ужасна, как мне кажется.
Сервера, конечно, это другое дело, но если мониторить TBW (после него заканчивается гарантия) и предупредительно их менять при достижении 95% — то можно избежать проблем в дальнейшем. Мало кто так делает, на самом деле — все ждут пока «сам умрёт», что, безусловно, не может сказаться на надёжности положительно.
Периодически я устраиваю проверку наличия адреса отправителя — больше половины спама валится с реальных адресов. Хуже того, часть из них даже с валидной DKIM подписью.
Из этого можно сделать вывод что для спаммеров не представляет никакого труда использовать реальные адреса, если нужно — возможно, угнанные, хакнутые, или просто созданные массово с нужной целью.
Что касается регулярок — помню был у клиента адрес типа ..xx|zz..@ — и он оказался работающим (попал в базу до того как email стал проверяться на фронтэнде и прошел валидацию через отправку кода).
Так что, как уже говорили раньше, единственный способ убедится в реальности адреса — это получить от пользователя подтверждение после отправки ему кода валидации или URL (причём последний должен быть с явным подтверждением после нажатия, или его могут случайно «подтвердить» антивирусы и/или антиспамы).
Единственное что можно улучшить — это интегрировать валидацию в процесс регистрации (или смены адреса), т.е. делать её немедленно после подтверждения email, и говорить пользователю если адрес получил отлуп. Но этот путь тернист, ибо ведет к потенциальной DoS, а также может дать сбой если сервер временно недоступен.
Вы не в курсе какие ошибки можно допустить, дуплицируя код и ссылаясь на что-то много раз? Или что можно сослаться не туда в конце трудного рабочего дня?
Кто этот автор? Откуда этот вброс без фактов?
Вы не заметили ссылку в моём сообщении? Да, я её добавил через минуту, но просто потому что нажал «отправить» вместо «предосмотр». Почитайте её. Пусть он и не прямой автор языка, но всё же имеет достаточный вес чтобы быть к нему причастным.
А дискуссии на эту тему в сообществе Rust вы и сами нагуглите, по словам «rust object inheritance».
Честно говоря, мне несколько непонятно, почему такая агрессия на вполне справедливое замечание — что отсутствие нормально наследования является неудобным и увеличивает вероятность ошибок. Нравится вам всё делать ручками, повторяясь — делайте.
Если большинство языков пришли к тому, что надо отказаться от множественного наследования, то в Rust наследования нет вообще.
Большинство языков пришло к этому по той простой причине что множественное наследование в основном использовалось для реализации того что нам известно как интерфейсы, поэтому создание интерфейсов эту проблему решило.
Но наследование вообще (точнее, его отсутствие), увы, это слабое место Rust, и даже его автор этого не скрывает. Было много дискуссий на эту тему, и довольно немало людей жалуется что это одна из причин по которой на Rust очень сложно писать UI и другие подобные древовидные конструкции.
Если грубо, то получится что-то типа (псевдокод):
Window {
x
y
width
height
show()
hide()
}
Widget {
Window win
...
}
В Rust, если у нас есть объект типа Widget wg, к его окошку (для координат, к примеру) нам придется лезть весьма коряво — wg.win.show(), т.е. в любом случае нужно хорошо знать что у слоника внутри и пользоваться этим косвенно, вместо того чтобы в любом нужном объекте напрямую сделать что хочется, без тупого дублирования ссылок на методы в родительских классах.
Если у нас будет слой потолще, в духе Window > Widget > ListView > TreeListView, то можно будет просто умереть от лишней писанины, не говоря уже о том что в каждом классе придётся вручную прописать обращение к конструкторам (неважно что под ними подразумевается) и ещё кучу всего.
Да, само по себе это не является препятствием для написания UI и вообще чего угодно, в конце концов, всё это пишется на C где вообще нет классов, не говоря уже про наследование — но остальные свойства (требования) языка делают написание подобных вещей адским трудом, т.е. с точки зрения ООП это шаг назад, однако. Если рассматривать его как «лучший C» — да, может быть, но всё же полноценный ООП лучше, да есть и другие «лучшие C» без таких проблем.
В общем, Rust помогает решить ряд проблем для ленивых и нерадивых разработчиков за счёт бития по пальцам, но при этом создает массу трудностей для сравнительно простых (в других языках) вещей. Как всегда, безопасность и комфорт — вещи почти взаимоисключающие.
...in a structured, commonly used and machine-readable format...
Текстовые файлы, формально, это вполне широко используемый и (иногда) машинно-читаемый формат, но они должны быть структурированы.
Я не видел как выглядят файлы VK, но если их сложно парсить из-за отсутствия структуры — то машинно-читаемость ставится под сомнение. В случае разногласий у меня есть глубокие сомнения что суд встанет на сторону контроллера (если дойдёт до суда).
Интересно, а кто-нибудь задумывается всерьез о проблемах, которые возникут у человечества, если (внезапно) найдут способ побороть все сокращающие жизнь болезни и увеличить продолжительность жизни в (хотя бы) два раза?
Пока это будет дорого и доступно единицам — ещё ладно, но если это станет доступно всем… не то что бы я (и некоторые другие) не хотел жить вечно (или хотя бы просто дольше и без болезней, или даже просто без болезней), но ведь проблемы явно возникнут, хотя бы потому что всю эту массу здоровых и долгоживущих придётся чем-то кормить и где-то селить, а ведь планета не резиновая.
Впрочем, гораздо хуже будет если гарантированный способ продления жизни будет найден, но доступен будет только богатым, и это станет известно всем остальным.
Если у злоумышленника есть доступ к конфигу которого нет в репозитории, то это гораздо серьезней проблемы с паролями.
Только если она утекла в оригинальном виде. Если это хэш (fuzzy или обычный), то успехов в восстановлении оригинальной фотки.
При нормальном раскладе, биометрические данные не должны хранится в оригинальном виде, а только в пост-обработанном виде, который позволяет их сравнивать с оригиналом. Многие сканнеры отпечатков сканнеров работают именно по такому принципу, подозреваю что другая биометрика тоже. Красть такие данные имеет смысл только если злоумышленник намерен сам идентифицировать жертв, а вот подделать что-то он не сможет, разве что банальным брут-форсом, генерируя картинки или подставляя имеющиеся.
Следующим этапом (хотя прототипы есть и сейчас) будет сочетание обычной биометрики со вспомогательными данными — т.е. при сканировании лица, к примеру, будет ИК-сканирование (тепловизор), который сразу отметёт фотографии и маски. Можно, конечно, сделать маску которая «прогреется» на лице, но это не так просто. Такой же метод + «сигналы жизни» можно применить и к отпечаткам пальцев/рук — т.е. ИК-скан + объёмный скан + пульс и насыщение крови кислородом (как у медицинских пульсометров, правда, простым прикладыванием пальца уже не обойтись).
В общем, есть куда развиваться, так что не всё так плохо.
Второй момент заключается в том, что даже если сам факт видеонаблюдения не нарушает закон, то запись нельзя публиковать или иным способ распостранять без разрешения лиц которые на ней — в том числе отдавать на просмотр какой-то частной фирме, которая не имеет к нему прямого отношения (т.е. охранная фирма, к примеру, может это просматривать, другие — нет). Суд, полиция etc конечно могут получить доступ к видео, если потребуют.
Я очень подозреваю что аналогичные законы есть в большинстве развитых стран, и если даже видеонаблюдение само по себе разрешено, то не факт что разрешена запись, её распостранение, публичная демонстрация или передача третьим лицам.
Есть сервисы которые не пускают разработчиков к видео, они просто их хранят (даже в зашифрованном виде) — тут проблем нет, вся ответственность на пользователе, если они утекут по его вине.
В данном же случае, как минимум, нарушены права тех кто оказался записан на видео — потому что они 100% не давали согласия что это видео будет просматривать непонятно кто.
В T&C сервиса Ring нет ни слова про аналитику или доступ к видео кому-то кроме пользователя, и даже если бы это упоминалось, это было бы незаконно (потому что, опять-таки, нужно получить разрешение записываемых, что практически неосуществимо).
Собственно, именно те кто оказался записан и могут предъявить претензии, вне зависимости от чего-либо — если докажут факт утечки или доступа, разумеется, причём связка с реальным именем пользователя тут не играет никакой роли.
Честно говоря, аутсорсить проверку паролей кому-то совершенно чужому — как-то очень стрёмно, ибо если что — то сервис превращается в тыкву, ничего не работает, пользователи негодуют и всё такое.
В Letsencrypt много кто заинтересован, посему шансы что он умрёт уж очень малы (несмотря на бесплатность), да и альтернативы есть, но тут совсем другое дело.
Увы, GDPR не запрещает сбор данных, он просто выставляет к нему определенные требования, в частности, явное согласие пользователя на их сбор, его право на opt-out и удаление уже собранных данных. Но после первого согласия до opt-out данные уже могут быть собраны, а удаление проверить невозможно — есть где разгуляться для нечестных разработчиков, особенно если они из Китая или Индии, а пользователи где-то в других странах.
Единственным действенным методом воздействия может быть только жёсткая политика платформы — если бы приложения, которые безусловно запрашивают неадекватные разрешения (т.е. те которые не необходимы для выполнения основной функции приложения) явно помечались красным флажком с пометкой «потенциально небезопасно» и понижались в рейтинге поиска, тогда бы лёд тронулся (мало кто захотел бы такой флажок).
По хорошему, «правильный» магазин приложений должен требовать от разработчика обосновать наличие того или иного разрешения, и отказывать в публикации если обоснование слабое (к примеру, доступ к контактам в приложении для фотографий, или доступ к GPS в календаре — и то и другое могут выполнять свои функции без контактов и GPS).
Но маловероятно что такой магазин появится, или выживет (если таки появится) — разве что подобные требования введут на уровне закона, что, в свою очередь, приведет к другим проблемам.
Есть вполне законный способ это делать для большинства разрешений без рута (но только для Android 6.0 и выше).
Можно поставить Shizuku Manager, дать ему доступ с помощью adb (инструкция прямо в приложении), потом поставить App Ops — и рулить как угодно.
Если доступ к чему-то закрыт в App Ops, то приложению (если оно его запрашивает) можно сказать Allow — оно всё равно ничего не получит (пустой список контактов, SMS etc), хотя будет уверено что разрешение получило.
Закрыть таким образом доступ в сеть нельзя, но контакты, микрофон, камера, GPS и ещё куча всего (включая возможность работать в фоне) — вполне можно.
Используются стандартные возможности Android, никакой магии (отбирать доступ можно просто с помощью adb — до переустановки приложения), эти два приложения просто удобный UI.
Кэш же (на самом накопителе) может уменьшить реальное количество записей на NAND в случае, если в течение короткого времени перезаписываются одни и те же участки диска (LBA) — если эти перезаписи делаются до того как он сброшен на NAND (а это может быть и несколько секунд), то в итоге на NAND попадают только последние записанные данные. Т.е., к примеру, если кэш сбрасывается раз в 5 секунд (условно), а мы эти 5 секунд будем непрерывно писать только в сектора 0-1023, то в итоге Host writes будет намного больше чем NAND writes. Кэш также может использовать другую стратегию, типа процента «грязных блоков», в этом случае время сброса в NAND (после записи от хоста) может и минут достигать (будь я разработчиком SSD, так бы и сделал, если бы мог гарантировать сброс кэша или его сохранность при выключении питания).
При размере кэша в 512M-1G это вообще может быть очень существенная разница, в зависимости от того что и как пишет на SSD — к примеру, если это что-то типа часто обновляющейся RRD базы размером который помещается в кэш, и софт который в неё пишет не создает новые файлы а переиспользует их (типа кольцевой буфер на диске). Поскольку обычно кэшу всё равно, пишутся данные рандомно или последовательно (важно лишь наличие сектора в нём), то экономия может быть очень существенной.
И насчёт «40 гигов в день в течение 5 лет» — в вашем случае вы умудрились записать больше 800 за 241 час, что в два раза больше чем 40/день. Опять-таки, я могу ошибаться, но 40гиг/день (а не общее TBW) может быть неспроста — вполне возможно что более высокая нагрузка его и убила. Это конечно не механика, но я могу себе представить что у него кэш который расчитан на то что эти самые 40 гиг он ещё может успевать раскидать всё как положено в течение суток (если не спит и не отключен), а если больше то начнёт «задыхаться», повышая степень износа (либо NAND, либо компонент).
Иногда случается когда между первым появлением переназначенных секторов и их лавинообразным ростом или даже смертью диска проходит совсем немного времени — поэтому лучше упредить такую ситуацию, если есть возможность. SSD нынче дешевы, не то что 10 лет назад.
Даже если у вас регулярные бэкапы или там нет ничего «такого», представьте ситуацию — после очередной перезагрузки/включения (или в процессе работы) диск вдруг умирает и вам внезапно приходится тратить несколько часов времени (пусть даже «всего» час-два) на поиск замены, восстановление всего что нужно и т.п. — приятного мало, однако. Если же вы на выезде в этот момент — ситуация ещё неприятней, поэтому я лично предпочитаю действовать с упреждением (а на выезд обычно беру с собой запасной ноутбук поменьше, но с копией всего что на первом).
Разница в значениях host writes и nand writes (если они правдивы) скорее всего связана с кэшем (если он там есть, ибо спецификация молчит и об этом тоже), другого логичного объяснения я не вижу.
И конечно же, нельзя исключить что именно конкретный экземпляр оказался дефектным и поэтому прожил так недолго (если это единичный случай), ибо записанные 840GiB даже при размере SSD в 60GB было бы слишком мало, даже для TLC. С другой стороны, раз уж у него гарантия 5 лет, то им явно проще их менять чем делать надёжными.
По своему опыту выбора SSD для серверов скажу, что просто даже не смотрю в сторону тех где в спецификации так мало данных (пусть даже это известный бренд), особенно если не упоминаются TBW и наличие кэша (как DRAM так и SLC). Если выбора нет, то относительно безопасно оценивать количество циклов перезаписи для TLC в районе 250-300, но это имеет смысл только если SMART позволяет мониторить NAND writes.
Если верить некоторым тестам на живучесть, многие SSD (даже самсунги) спокойно переживают записи за пределами спецификаций, молчат в SMART до последнего, но при этом превышают TBW в несколько раз, а умирают молча и внезапно.
С другой стороны, массовых жалоб о внезапной смерти SSD при обычных декстопных нагрузках вроде как в сети не наблюдается, так что для обычных пользователей ситуация не настолько ужасна, как мне кажется.
Сервера, конечно, это другое дело, но если мониторить TBW (после него заканчивается гарантия) и предупредительно их менять при достижении 95% — то можно избежать проблем в дальнейшем. Мало кто так делает, на самом деле — все ждут пока «сам умрёт», что, безусловно, не может сказаться на надёжности положительно.
Из этого можно сделать вывод что для спаммеров не представляет никакого труда использовать реальные адреса, если нужно — возможно, угнанные, хакнутые, или просто созданные массово с нужной целью.
Что касается регулярок — помню был у клиента адрес типа ..xx|zz..@ — и он оказался работающим (попал в базу до того как email стал проверяться на фронтэнде и прошел валидацию через отправку кода).
Так что, как уже говорили раньше, единственный способ убедится в реальности адреса — это получить от пользователя подтверждение после отправки ему кода валидации или URL (причём последний должен быть с явным подтверждением после нажатия, или его могут случайно «подтвердить» антивирусы и/или антиспамы).
Единственное что можно улучшить — это интегрировать валидацию в процесс регистрации (или смены адреса), т.е. делать её немедленно после подтверждения email, и говорить пользователю если адрес получил отлуп. Но этот путь тернист, ибо ведет к потенциальной DoS, а также может дать сбой если сервер временно недоступен.
Вы не в курсе какие ошибки можно допустить, дуплицируя код и ссылаясь на что-то много раз? Или что можно сослаться не туда в конце трудного рабочего дня?
Вы не заметили ссылку в моём сообщении? Да, я её добавил через минуту, но просто потому что нажал «отправить» вместо «предосмотр». Почитайте её. Пусть он и не прямой автор языка, но всё же имеет достаточный вес чтобы быть к нему причастным.
А дискуссии на эту тему в сообществе Rust вы и сами нагуглите, по словам «rust object inheritance».
Честно говоря, мне несколько непонятно, почему такая агрессия на вполне справедливое замечание — что отсутствие нормально наследования является неудобным и увеличивает вероятность ошибок. Нравится вам всё делать ручками, повторяясь — делайте.
Этот.
Это именно то о чём я и говорю — лишний мартышкин труд для разработчика. И возможность допустить ошибку.
Большинство языков пришло к этому по той простой причине что множественное наследование в основном использовалось для реализации того что нам известно как интерфейсы, поэтому создание интерфейсов эту проблему решило.
Но наследование вообще (точнее, его отсутствие), увы, это слабое место Rust, и даже его автор этого не скрывает. Было много дискуссий на эту тему, и довольно немало людей жалуется что это одна из причин по которой на Rust очень сложно писать UI и другие подобные древовидные конструкции.
Если грубо, то получится что-то типа (псевдокод):
В Rust, если у нас есть объект типа Widget wg, к его окошку (для координат, к примеру) нам придется лезть весьма коряво — wg.win.show(), т.е. в любом случае нужно хорошо знать что у слоника внутри и пользоваться этим косвенно, вместо того чтобы в любом нужном объекте напрямую сделать что хочется, без тупого дублирования ссылок на методы в родительских классах.
Если у нас будет слой потолще, в духе Window > Widget > ListView > TreeListView, то можно будет просто умереть от лишней писанины, не говоря уже о том что в каждом классе придётся вручную прописать обращение к конструкторам (неважно что под ними подразумевается) и ещё кучу всего.
Да, само по себе это не является препятствием для написания UI и вообще чего угодно, в конце концов, всё это пишется на C где вообще нет классов, не говоря уже про наследование — но остальные свойства (требования) языка делают написание подобных вещей адским трудом, т.е. с точки зрения ООП это шаг назад, однако. Если рассматривать его как «лучший C» — да, может быть, но всё же полноценный ООП лучше, да есть и другие «лучшие C» без таких проблем.
В общем, Rust помогает решить ряд проблем для ленивых и нерадивых разработчиков за счёт бития по пальцам, но при этом создает массу трудностей для сравнительно простых (в других языках) вещей. Как всегда, безопасность и комфорт — вещи почти взаимоисключающие.
Текстовые файлы, формально, это вполне широко используемый и (иногда) машинно-читаемый формат, но они должны быть структурированы.
Я не видел как выглядят файлы VK, но если их сложно парсить из-за отсутствия структуры — то машинно-читаемость ставится под сомнение. В случае разногласий у меня есть глубокие сомнения что суд встанет на сторону контроллера (если дойдёт до суда).
всесокращающие жизнь болезни и увеличить продолжительность жизни в (хотя бы) два раза?Пока это будет дорого и доступно единицам — ещё ладно, но если это станет доступно всем… не то что бы я (и некоторые другие) не хотел жить вечно (или хотя бы просто дольше и без болезней, или даже просто без болезней), но ведь проблемы явно возникнут, хотя бы потому что всю эту массу здоровых и долгоживущих придётся чем-то кормить и где-то селить, а ведь планета не резиновая.
Впрочем, гораздо хуже будет если гарантированный способ продления жизни будет найден, но доступен будет только богатым, и это станет известно всем остальным.
То есть вы предпочитаете раскачивать поезд, создавая иллюзию его движения, даже когда уже совершенно очевидно что это иллюзия?
Если так — успехов вам.
Вовремя уйти — не позорно. Правда, чтобы это понять, нужно время. В вашем случае оно, видимо, ещё не пришло.