Плеер и сплиттер может быть любой. Например, PotPlayer, для .avi, .mp4 и .*ts настроить сплиттер LAV Filters, a для .mkv и .ogm — Haali Media Splitter.
В двух словах: для проигрывания Hi10P без потерь нужно использовать декодер LAV Video Decoder и рендер madVR.
Декодер Microsoft DTV-DVD Video Decoder работать не будет. Декодер CoreAVC 3 переключится в программные режим и будет работать. Лучше не использовать ffdshow raw video filter, чтобы не происходил дополнительный dithering при преобразовании к YV12 8-bit, который понимает этот фильтр.
Это не защита, а всего лишь дополнительный заголовок. Пользователя он ни от чего не защищает. А разработчику бесполезен, поскольку поддерживается пока только в Chrome.
Текст ошибки может быть такой: “SQL Error (1118): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs”.
Если создаётся таблица, которая не нуждается в новых возможностях, то она будет создана в более простом формате Antelope.
2) преобразовать таблицу в новый формат строки:
ALTER TABLE tableName ENGINE = InnoDB ROW_FORMAT = Dynamic;
Формат строки Dynamic означает, что для длинных TEXT/VARCHAR, не являющихся частью primary key, в B-дереве могут хранятся только 20 байт указателя на отдельную область с данными (overflow). База сама выбирает, какие колонки держать в B-дереве, а какие слишком длинные, и нужно держать отдельно в overflow: если строка таблицы не умещается в размер половины страницы (8126 байт), то самая длинная колонка целиком помещается во внешнее хранилище. Процедура повторяется, пока все оставшиеся колонки не уместятся в размер половины страницы.
Итак, в этом формате каждая TEXT/VARCHAR колонка занимает минимум 20 байт в странице, и одна строка таблицы может содержать максимум 400 TEXT/VARCHAR полей. Колонка может занимать больше байт в странице, если там осталось место.
Чтобы в будущем MySQL выдавал ошибку при создании таблицы, если она не помещается в формат строки, включаем innodb_strict_mode в my.cnf:
innodb_strict_mode = ON
Также можно обратить внимание на sql_mode для упрощения отладки.
Частичное решение для FireFox
1. Установить Noscript.
2. Набрать в адресной строке “about:config” и согласиться быть зайками, если попросят.
3. В строке фильтра набрать “allowURLBarJS” и переключить значение на “false” двойным щелчком.
Это запретит data и javascript в адресной строке для всех сайтов, кроме разрешённых (Allowed, Trusted, Whitelisted). Решение частичное, поскольку FaceBook чаще всего добавляется посетителями в разрешённые сайты (иначе Javascript на нём будет работать не везде).
Для FireFox фокус в адресную строку — это Alt-D, или F6, или Ctrl-L. Фокус в строку поиска — Ctrl-E или Ctrl-K. Для остальных браузеров, вероятно, похоже.
Для каждой A записи должна существовать зеркальная PTR запись, то есть по имени хоста через DNS получаем IP, а по IP — обратно то же имя хоста.
# Запись A для почтового сервера всегда должна иметь зеркальную PTR запись.
Нет. Более мягкое ограничение reject_unknown_reverse_client_hostname требует у клиента наличия любого PTR для его IP адреса, более строгое ограничение reject_unknown_client_hostname требует, чтобы IP клиента ресолвился в любое доменное имя, и это доменное имя ресолвилось в IP клиента. Ограничения на «то же имя хоста» нет. Пример проверки клиента: 10.11.1.1 → example.com; example.com → 10.11.1.1; 10.11.1.1 = 10.11.1.1.
[reject_unknown_client_hostname] требует, чтобы IP, с которого совершается соединение, резолвился в имя из HELO, а имя из HELO резолвилось в свою очередь обратно в искомый IP. То есть фактически эта опция требует, чтобы сервер представлялся именно тем именем, под которым он известен в интернете (прописан в DNS).
# HELO заголовок должен в точности совпадать с именем сервера из A и соответствующей PTR записи.
Ничего он такого не требует и не должен, см. выше. Имя может быть любым, с HELO не сравнивается. Единственное ограничение на HELO — имя должно иметь любую A или MX запись (reject_unknown_helo_hostname).
Можно спокойно иметь MX mail.example.com, представляться в HELO как sender.example.com, и иметь PTR example.com.
smtpd_reject_unlisted_recipient = yes
Этот параметр установлен по умолчанию, про него можно не писать.
Либо запрещающей опцией, имеющей тот же эффект:
reject_unlisted_sender
Ещё чего. Здесь, видимо, имелось в виду reject_unlisted_recipient.
[reject_unauth_destination] превращает Postfix из почтового релея (то есть сервера пересылки) в конечный пункт назначения писем, поэтому используется не часто (т.к. обычно исходящие SMTP серверы совпадают со входящими, а значит вашим пользователям нужна будет возможность посылать через SMTP сервер письма наружу для адресатов, находящихся вне обслуживаемых постфиксом доменов).
Ну да, опция, установленная по умолчанию в настройке smtpd_recipient_restrictions, «используется не часто». Чтобы разрешить отсылку писем на чужие адреса, используется либо опция доверенного IP клиента (permit_mynetworks), либо авторизация паролем (permit_sasl_authenticated). Опция же smtpd_recipient_restrictions никуда не убирается, поскольку иначе вы разрешите рассылать через ваш сервер всем (open-relay).
Если включить все ограничения, то письма от почтовых клиентов и крупных почтовых сервисов будут приходить без проблем. Но с различными уведомлениями сайтов, платёжных систем, банков, регистраторов доменов и т.п. начнутся проблемы, поскольку чаще всего их ПО не соответствует стандартам, почтовые сервера и DNS настроены не во всём верно.
Например: многие сервисы используют обратный адрес вида no-reply@example.com, которого не существует. Или добавляют случайный id в обратный адрес: client-62961@example.com. Или неверно кодируют кириллицу в поле From. Откройте любое «Это автоматическое уведомление...» и посмотрите сами.
Одно из решений — включить эти проверки синтаксиса вместе с DNSBL, SPF, DKIM и т.п. в систему, которая выдаёт разные баллы за каждое условие, и в зависимости от результирующей суммы перемещает письмо в соответствующую IMAP папку (Входящие / Подозрительно / Спам) или, при превышении порога, удаляет с уведомлением отправителя.
Также в ходе доказательства, судя по всему, доказывается существование односторонней функции.
Функция односторонняя, если она может быть «легко» сосчитана (за полиномиальное время), но в среднем случае «тяжело» обратима (не за полиномиальное время). Существование односторонней функции до сих пор не было доказано. Но есть несколько кандидатов, которые и применяются в криптографии. Если будет доказано, что односторонняя функция существует, то автоматически будет доказано, что P ≠ NP.
Ниже спрашивают, какое ещё практическое значение имеет это доказательство. Я постараюсь объяснить.
Существует класс coNP — класс P входит и в NP, и в coNP. Если доказано, что NP ≠ coNP, то в coNP не может быть NP-полных проблем.
Приведу некоторые не искусственные проблемы, которые не попадают в класс P и NP-полный:
1. Факторизация целых чисел. Дано целое число, найти простые сомножители.
2. Кратчайший вектор в решётке. Дана решётка L в Rⁿ и целое k, будет ли длина (Евклидова) кратчайшего вектора L находиться в диапазоне [k; kn]?
3. Стохастические игры. Чёрные, Белые и Природа по очереди перемещают фишку по вершинам направленного графа. Природа перемещает случайно. Дан граф, начальная и конечная вершина для фишки. Есть ли у Белых стратегия, которая гарантирует, что фишка достигнет цели с вероятностью ≥ ½?
4. Изоморфизм графа. Даны два графа, являются ли они изоморфными? Другими словами, есть ли взаимо однозначное отображение их вершин, при котором сохранятся рёбра?
Сейчас нет эффективных алгоритмов для этих проблем. Но мы знаем, что первые три находятся и в NP, и в coNP. А значит, если NP ≠ coNP, то они не могут быть NP-полными! А значит, сохраняется вероятность быстрого решения. Аналогичное заключение возможно и для четвёртой проблемы.
P.S. Может показаться, что с факторизацией возникло противоречие. На самом деле нет, и я поправился ранее: доказательство в данном случае означает, что нет решений класса P, и в то же время проблема не NP-полная.
Если завтра обнаружат быстрое решение NP-полной задачи, то любая NP задача сможет быть решена быстро. Пока этого не произошло, я и привёл упрощённую формулировку.
Декодер Microsoft DTV-DVD Video Decoder работать не будет. Декодер CoreAVC 3 переключится в программные режим и будет работать. Лучше не использовать ffdshow raw video filter, чтобы не происходил дополнительный dithering при преобразовании к YV12 8-bit, который понимает этот фильтр.
Единственное, что он делает, это POST запросы с non-whitelisted сайтов превращает в GET.
Либо нужно писать правила для его встроенного фаервола ABE. Правила по умолчанию защищают только локальные сайты.
Сейчас разрабатываются спецификации на эту тему: черновик от W3C, черновик RFC.
Текст ошибки может быть такой: “SQL Error (1118): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs”.
Чтобы решить проблему в MySQL 5.5, нужно:
1) включить новый формат InnoDB файлов в my.cnf:
Если создаётся таблица, которая не нуждается в новых возможностях, то она будет создана в более простом формате Antelope.
2) преобразовать таблицу в новый формат строки:
Формат строки Dynamic означает, что для длинных TEXT/VARCHAR, не являющихся частью primary key, в B-дереве могут хранятся только 20 байт указателя на отдельную область с данными (overflow). База сама выбирает, какие колонки держать в B-дереве, а какие слишком длинные, и нужно держать отдельно в overflow: если строка таблицы не умещается в размер половины страницы (8126 байт), то самая длинная колонка целиком помещается во внешнее хранилище. Процедура повторяется, пока все оставшиеся колонки не уместятся в размер половины страницы.
Итак, в этом формате каждая TEXT/VARCHAR колонка занимает минимум 20 байт в странице, и одна строка таблицы может содержать максимум 400 TEXT/VARCHAR полей. Колонка может занимать больше байт в странице, если там осталось место.
Чтобы в будущем MySQL выдавал ошибку при создании таблицы, если она не помещается в формат строки, включаем innodb_strict_mode в my.cnf:
Также можно обратить внимание на sql_mode для упрощения отладки.
Частичное решение для FireFox
1. Установить Noscript.
2. Набрать в адресной строке “about:config” и согласиться быть зайками, если попросят.
3. В строке фильтра набрать “allowURLBarJS” и переключить значение на “false” двойным щелчком.
Это запретит
dataиjavascriptв адресной строке для всех сайтов, кроме разрешённых (Allowed, Trusted, Whitelisted). Решение частичное, поскольку FaceBook чаще всего добавляется посетителями в разрешённые сайты (иначе Javascript на нём будет работать не везде).Ничего он такого не требует и не должен, см. выше. Имя может быть любым, с HELO не сравнивается. Единственное ограничение на HELO — имя должно иметь любую A или MX запись (reject_unknown_helo_hostname).
Можно спокойно иметь MX mail.example.com, представляться в HELO как sender.example.com, и иметь PTR example.com.
Этот параметр установлен по умолчанию, про него можно не писать.
Ещё чего. Здесь, видимо, имелось в виду reject_unlisted_recipient.
Ну да, опция, установленная по умолчанию в настройке smtpd_recipient_restrictions, «используется не часто». Чтобы разрешить отсылку писем на чужие адреса, используется либо опция доверенного IP клиента (permit_mynetworks), либо авторизация паролем (permit_sasl_authenticated). Опция же smtpd_recipient_restrictions никуда не убирается, поскольку иначе вы разрешите рассылать через ваш сервер всем (open-relay).
Если включить все ограничения, то письма от почтовых клиентов и крупных почтовых сервисов будут приходить без проблем. Но с различными уведомлениями сайтов, платёжных систем, банков, регистраторов доменов и т.п. начнутся проблемы, поскольку чаще всего их ПО не соответствует стандартам, почтовые сервера и DNS настроены не во всём верно.
Например: многие сервисы используют обратный адрес вида no-reply@example.com, которого не существует. Или добавляют случайный id в обратный адрес: client-62961@example.com. Или неверно кодируют кириллицу в поле From. Откройте любое «Это автоматическое уведомление...» и посмотрите сами.
Одно из решений — включить эти проверки синтаксиса вместе с DNSBL, SPF, DKIM и т.п. в систему, которая выдаёт разные баллы за каждое условие, и в зависимости от результирующей суммы перемещает письмо в соответствующую IMAP папку (Входящие / Подозрительно / Спам) или, при превышении порога, удаляет с уведомлением отправителя.
Функция односторонняя, если она может быть «легко» сосчитана (за полиномиальное время), но в среднем случае «тяжело» обратима (не за полиномиальное время). Существование односторонней функции до сих пор не было доказано. Но есть несколько кандидатов, которые и применяются в криптографии. Если будет доказано, что односторонняя функция существует, то автоматически будет доказано, что P ≠ NP.
Существует класс coNP — класс P входит и в NP, и в coNP. Если доказано, что NP ≠ coNP, то в coNP не может быть NP-полных проблем.
Приведу некоторые не искусственные проблемы, которые не попадают в класс P и NP-полный:
1. Факторизация целых чисел. Дано целое число, найти простые сомножители.
2. Кратчайший вектор в решётке. Дана решётка L в Rⁿ и целое k, будет ли длина (Евклидова) кратчайшего вектора L находиться в диапазоне [k; kn]?
3. Стохастические игры. Чёрные, Белые и Природа по очереди перемещают фишку по вершинам направленного графа. Природа перемещает случайно. Дан граф, начальная и конечная вершина для фишки. Есть ли у Белых стратегия, которая гарантирует, что фишка достигнет цели с вероятностью ≥ ½?
4. Изоморфизм графа. Даны два графа, являются ли они изоморфными? Другими словами, есть ли взаимо однозначное отображение их вершин, при котором сохранятся рёбра?
Сейчас нет эффективных алгоритмов для этих проблем. Но мы знаем, что первые три находятся и в NP, и в coNP. А значит, если NP ≠ coNP, то они не могут быть NP-полными! А значит, сохраняется вероятность быстрого решения. Аналогичное заключение возможно и для четвёртой проблемы.
P.S. Может показаться, что с факторизацией возникло противоречие. На самом деле нет, и я поправился ранее: доказательство в данном случае означает, что нет решений класса P, и в то же время проблема не NP-полная.