Недостаточно гибкие правила, т.к. они полностью в ручном режиме создаются штатом rulewriter-ов из солнечной Одессы, и на самом устройстве зашифрованы во избежание использования спамерами для выяснения ключевых признаков и их успешного обхода.
«IronPort заботит не тело письма, а его отправитель» — не всегда и не совсем, да и не так это, на самом деле. Отправитель важен только на ранних этапах фильтрации — когда у отправителя слишком низкий рейтинг SBRS, письма можно даже не анализировать. Если с рейтингом все не совсем грустно, часть спама и часть хороших писем («хАма») отправляется в Ironport для последующего анализа, и тело с заголовками как раз играют важную роль на этом этапе.
Хм, а как насчет такого — что, если шифровать только заголовки и ключевые кадры? Даже если криминалист восстановит заголовки по каким-то косвенным признакам, без ключевых кадров не получится восстановить собственно видеоряд, т.к. остальные кадры являются, грубо говоря, описаниями изменений к ключевым — или я неправильно понимаю суть? Т.е. на выходе, если не расшифровать ключевые кадры, будет просто глитчевая мешанина, по которой достоверно определить, порнография ли это, детская ли, взрослая ли, или это демонстрация паровых двигателей 18 века, будет определить невозможно.
Если и это не препятствие для предъявления претензий, то тогда на этих серверах вообще могло не быть распознаваемых файловых систем — все равно на диске C: в папке Users\VKONTAKTE\Videos\DETSKOE_PORNO нашли бы с десяток запрещенных роликов.
В Python 3 больше нет метода __cmp__() и функции cmp(), и рекомендуется использовать __lt__/__gt__/__le__/__ge__/__eq__/__ne__ исключительно. Если нет необходимости определять все операторы сравнения, можно определить один оператор сравнения (например, __eq__) и один оператор упорядочения (например, __lt__), и применить к объявлению класса декоратор @functools.total_ordering — он достроит остальные функции на основании имеющихся.
Если в первом примере под тильдой в filepath='~' понимается домашняя директория текущего пользователя, то это так не работает — будет попытка открыть файл в директории ./~/, т.к. Python не разворачивает шелл-подстановки (и спасибо ему). Чтобы работало, код нужно написать следующим образом:
def __init__(self, filepath = '~', filename = 'sample.txt'):
# открыть файл filename в filepath в режиме чтения и записи
self.file = open(os.path.expanduser(os.path.join(filepath, filename)), 'r+')
Более того, опасно использовать __del__ так, как это было продемонстрировано, так как __del__ вызывается даже для тех экземпляров класса, для которых не было завершено конструирование. Таким образом, если создать FileObject с неправильным именем файла, open() выбросит IOError, и self.file не будет присвоен — но к нему обратится __del__ и получит вдобавок еще и AttributeError, и последующая деинициализация выполнена не будет, лишая __del__ того смысла, который в него вкладывал автор. Будьте осторожнее.
Между точками — 5 мкм. Квадрат в 241 точек имеет сторону в приблизительно 1482911 точку, что дает сторону квадрата 7414550 мкм = 7.414550 м, и площадь порядка 55 м2/ТиБ.
Энергия на запись одной точки — 8 мкДж, на запись 1 ТиБ (241 точек) — 244 мкДж ≈ 17592186 Дж ≈ 4.887 кВт⋅ч, что при цене 0.14$/(кВт⋅ч) дает 0.68$/ТиБ.
Время на запись одной точки — 1/200 с, скорость записи 100 байт/с. Если писать в одно «сопло», запись 1 ТиБ займет 10995116278 секунд ≈ 348.65 лет.
Соответственно, диск в 360 ТиБ будет иметь площадь в 19800 м2 (1.98 гектар), по затратам энергии обойдется в 244.8$, и записываться будет 125'513 лет.
«Все ОС не защищены от гипервизора» — к этому и сводилась суть моего комментария. По реплике же sirinbird складывается ощущение, что он уверен в защищенности *nix-ов от злонамеренных гипервизоров, злонамеренных thunderbolt/pcie-устройств и злонамеренных плат расширения.
По поводу «до лампочки, какая ОС стоит» — да, до тех пор, пока он не собирается вмешиваться в ее работу на более тонких уровнях.
Скорее всего, этот записанный файл в 300 КБ — просто Proof of Concept, а все накинулись на него так, как будто это уже финальный образец технологии. Наверняка оптимизацией плотности, затрат энергии и скорости записи просто еще не занимались.
Открытый PIN никуда не передается и на карте не хранится — PIN вообще не хранится на карте с магнитной лентой ни в какой форме. Правильность PIN сверяется по контрольной сумме или шифроблоку, которую вычисляет сам пин-пад инкрементально во время ввода пользователем — софт банкомата PIN-кода не знает.
«IronPort заботит не тело письма, а его отправитель» — не всегда и не совсем, да и не так это, на самом деле. Отправитель важен только на ранних этапах фильтрации — когда у отправителя слишком низкий рейтинг SBRS, письма можно даже не анализировать. Если с рейтингом все не совсем грустно, часть спама и часть хороших писем («хАма») отправляется в Ironport для последующего анализа, и тело с заголовками как раз играют важную роль на этом этапе.
Если и это не препятствие для предъявления претензий, то тогда на этих серверах вообще могло не быть распознаваемых файловых систем — все равно на диске C: в папке Users\VKONTAKTE\Videos\DETSKOE_PORNO нашли бы с десяток запрещенных роликов.
__cmp__()и функцииcmp(), и рекомендуется использовать__lt__/__gt__/__le__/__ge__/__eq__/__ne__исключительно. Если нет необходимости определять все операторы сравнения, можно определить один оператор сравнения (например,__eq__) и один оператор упорядочения (например,__lt__), и применить к объявлению класса декоратор@functools.total_ordering— он достроит остальные функции на основании имеющихся.filepath='~'понимается домашняя директория текущего пользователя, то это так не работает — будет попытка открыть файл в директории./~/, т.к. Python не разворачивает шелл-подстановки (и спасибо ему). Чтобы работало, код нужно написать следующим образом:Более того, опасно использовать __del__ так, как это было продемонстрировано, так как __del__ вызывается даже для тех экземпляров класса, для которых не было завершено конструирование. Таким образом, если создать FileObject с неправильным именем файла, open() выбросит IOError, и self.file не будет присвоен — но к нему обратится __del__ и получит вдобавок еще и AttributeError, и последующая деинициализация выполнена не будет, лишая __del__ того смысла, который в него вкладывал автор. Будьте осторожнее.
1 точка — 4 бита. 1 байт — 8 бит — 2 точки. 1 ТиБ — 241 точек.
Между точками — 5 мкм. Квадрат в 241 точек имеет сторону в приблизительно 1482911 точку, что дает сторону квадрата 7414550 мкм = 7.414550 м, и площадь порядка 55 м2/ТиБ.
Энергия на запись одной точки — 8 мкДж, на запись 1 ТиБ (241 точек) — 244 мкДж ≈ 17592186 Дж ≈ 4.887 кВт⋅ч, что при цене 0.14$/(кВт⋅ч) дает 0.68$/ТиБ.
Время на запись одной точки — 1/200 с, скорость записи 100 байт/с. Если писать в одно «сопло», запись 1 ТиБ займет 10995116278 секунд ≈ 348.65 лет.
Соответственно, диск в 360 ТиБ будет иметь площадь в 19800 м2 (1.98 гектар), по затратам энергии обойдется в 244.8$, и записываться будет 125'513 лет.
Вроде бы все правильно на этот раз?
По поводу «до лампочки, какая ОС стоит» — да, до тех пор, пока он не собирается вмешиваться в ее работу на более тонких уровнях.