• Есть ли способ задать пользовательские стили тегу audio через css?

    @aslanovich
    Web/Art Designer. Front+Back-end Geek
    Список всех модификаторов :


    audio::-webkit-media-controls-panel
    audio::-webkit-media-controls-mute-button
    audio::-webkit-media-controls-play-button
    audio::-webkit-media-controls-timeline-container
    audio::-webkit-media-controls-current-time-display
    audio::-webkit-media-controls-time-remaining-display
    audio::-webkit-media-controls-timeline
    audio::-webkit-media-controls-volume-slider-container
    audio::-webkit-media-controls-volume-slider
    audio::-webkit-media-controls-seek-back-button
    audio::-webkit-media-controls-seek-forward-button
    audio::-webkit-media-controls-fullscreen-button
    audio::-webkit-media-controls-rewind-button
    audio::-webkit-media-controls-return-to-realtime-button
    audio::-webkit-media-controls-toggle-closed-captions-button
    Ответ написан
    2 комментария
  • Как удалить старые письма Postfix+Dovecot / CentOS6?

    falsebyte
    @falsebyte
    find /mail/dir -type f -mtime +1095 -delete

    /mail/dir каталог с письмами
    -mtime +1095 старше 1095 дней
    -delete удалить
    предварительно проверить список файлов на удаление примерно так
    find /mail/dir -type f -mtime +1095 -print
    Ответ написан
    Комментировать
  • Конфиг 3 proxy?

    auth iponly
    
    allow *
    parent 1000 socks4  12.12.12.12 8080
    proxy -i5.5.5.5 -p10001
    
    flush
    
    allow *
    parent 1000 socks4  13.13.13.13 8080
    proxy -i5.5.5.5 -p10002
    Ответ написан
    6 комментариев
  • Выгрузка драйвера в ОС Windows

    mshewzov
    @mshewzov
    Юрист и IT-любитель
    Команда sc поможет Вам: sc stop <имя_драйвера>

    Имя нужного драйвера, в свою очередь, можно добыть командой: sc queryex type= driver

    Либо найти ветку драйвера в реестре и посмотреть имя там: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services
    Ответ написан
    Комментировать
  • С сего начать изучение c# и wpf?

    tohendiy
    @tohendiy
    Xamarin/.Net Developer in Leale Solutions
    Посмотрите на этом сайте. Очень сильно мне помог в изучении WPF. Все кратко и по делу. Для старта - отличный материал.
    metanit.com/sharp/index.php
    Ответ написан
    Комментировать
  • Стоит ли использовать RSA?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    И да и нет одновременно.

    (обновлено, ибо внезапно прочитал и половину не понял - видимо писал на "потоке")
    RSA стоит использовать лишь для шифрования других ключей - ключей симметричных алгоритмов шифрования. AES, ГОСТ 28147-89, 3DES и другие. Почему? Во-первых, симметричные алгоритмы более устойчивы к взлому при большом известном закрытом тексте, тогда как ассиметричное шифрование потенциально имеет изъяны. В том смысле, что (почти) любое ассиметричное шифрование использует задачу NP-класса (точнее - NP-полную задачу): факторизация числа (RSA), декодирование полных (общих) линейных кодов (McEliece), вычисление дискретного логарифма на элептической кривой (ГОСТ Р 34.10-2012), или в конечном поле (Elgamal). Другое дело, что любая эта задача потенциально - решаемая. В случае с симметричным шифрованием действительно стоит лишь надеяться на чудо (в ГОСТе разрешено выбирать любые s-блоки, так что криптоаналитику ничего не остаётся, как молиться пролетариату в надежде на терморектальный криптоанализ). В случае же с ассиметричным шифром в дело вступают две вещи - высокая сложность реализации действительно стойкого алгоритма (ассиметричные шифры очень сложны и полны нюансов, не учитывая которые можно запросто порушить систему), низкая скорость работы (в силу того, что приходиться использовать очень абстрактные математические функции, сложно реализуемые аппаратно и таящие в себе множество низкоуровневых операций) при требовании к очень длинным ключам заставляют использовать небольшие ключи для того, чтобы не ждать вечность.

    Однако. Здесь имеется странный парадокс. Если данные очень важные и на их защиту можно убить несколько миллионов енотов, то надо использовать только ассиметричный шифр. Потому что, он потенциально даёт большую стойкость. Парадокс здесь в том, что если классы P и NP неравны, то мы получаем едва ли не идеальную и приемлемую по стоимости защиту, так как есть возможность сложной организационной защиты.
    (здесь было многое отправлено в топку)

    Окай, посмотрим на стандартную схему с Алисой, Бобом и Евой:
    Алиса -> c = E(m, Eb) -> -------- -> D(c, Db) -> Боб (
                                     |
                                     |
                                     v
                         Ева <- c, E, D, d

    здесь m - текст, который надо передать (сообщение)
    c - шифротекст
    E - функция шифрования (получения из сообщения шифротекста)
    D - функция дешифрования, иначе - обратная функция шифрования (получения из шифротекста - сообщения)
    Eb, Db - секретный и открытый ключи Боба (в литературе используется различное обозначение, здесь так)
    Собственно, Ева знает всё о функциях шифрования и дешифрования, имеет доступ к шифротексту и будем считать, что она получает и открытый ключ.

    Теперь, что нам это даёт? А это нам даёт возможность наплодить большое количество ключей и шифровать каждое сообщение отдельным ключём. Потенциально, но если есть $$$, то можно скупить половину серверов страны, если не планеты и радоваться жизни. Хотя ровно так же можно поступить и с симметричным шифрованием, и называется это одноразовым блокнотом, используют и различные режимы шифрования и всё равно выходит профитнее. Где же профит здесь?
    Во-первых, если нужно передавать по каналу, а не хранить, то можно генерировать ключи налету и после расшифровки их уничтожать. По сути, получиться что для того, чтобы получить сообщение длины l бобу потребуется передать и ключей в общей сумме длины l. Много? Да. Профитно? Очень - ибо мы реализуем
    ассиметричный одноразовый блокнот (упс), который, однако, нет никакого смысла использовать нет - слишком дорого. Да и не всегда возможно - порой обратный канал чрезвычайно узкий.
    Во-вторых, есть способ организовать защиту, основанную на иерархии пользователей. То есть майор Алиса написала отчёт, который ей надо отправить подполковнику Бобу. При этом читать этот отчёт должны иметь право все, кто равен или выше подполковника.
    В-третьих, как писалось выше, сложность взлома достаточно велика. И не только потому, что P != NP. Даже P довольно большое получается, поэтому и используют асимметричный шифр для передачи ключей симметричных ключей. Но и взлом получается очень не простым из-за тяжёлых математических абстракций. Обычно. Да, RSA можно "взломать" перебрав все возможные делители, но это долго из-за астрономического размера ключа. А способы обхода или упрощения опираются на такой зубодробительный матан, что попытка как-то это реализовать заставит использовать сами по себе очень тяжёлые операции. Так это при работе с банальными числами (и это показывает, насколько плохо развита теория чисел), а что если уйти на эллиптическую кривую - аналитическая геометрия развита может чуть лучше, но абстракции намного тяжелее для компьютеров. И даже использование графических карт не помогает, ведь есть ещё и макэлис. Я к тому, что O(2^32) для симметричного шифра и O(2^32) для асимметричного шифра не очень таки равны. Так же не равны, как не равны день и месяц.

    Но самое главное. Сегодня всё что угодно можно взломать. А то, что нельзя взломать - бесполезно (ибо либо уничтожено полностью, либо предоставляет такие же непосильные сложности для расшифровки и получателю). Во-первых, атака может быть не на сами шифры, а на организационные методы (которые, можно улучшить применением асимметричного шифра). Во-вторых, некоторые шифры таки имеют изъяны, просто возможно о них знают ограниченный круг лиц; привет масонам. И, наконец, криптоаналитик может быть просто ну очень удачлив.

    Поэтому шифрование надо использовать соразмерно цене риска. Чем выше риск - тем сильнее шифрование, но самое главное - сложнее и дисциплинированнее организационные меры. Согласитесь - бесполезно иметь централизованное хранилище сертификатов с одним сервером в бункере за 200 км под землей и круглосуточной охраной из армии маленькой страны, всего лишь одним портом торчащим во внешний мир с каналом около 200 бит в секунду и постоянным наблюдением за организационными методами (авторизация, доступ и подобной)... Имея пароль на суперюзер - qwerty, и держа на винчестере архив с котиками.
    Ответ написан
    Комментировать
  • Оптимальные конфиги для связки: DigitalOcean(5$) + VestaCP + Wordpress?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    1. Веста хоть и самая легкая из CP, но все же жрет ресурсы, а на дроплете за $5 их и так очень мало. Ну а для одного сайта зачем вообще контрольная панель?! Удалите к чертям. Ну или попробуйте объяснить, зачем вам эта панель вообще нужна. Уверен, смысла в ней нет.

    2. На минимальном дроплете надо все делать максимально продуманным и эффективным. Обязательно нужен swap 512Мб или даже 1Гб. Nginx, желательно последний mainline. PHP5-FPM с Opcache, для Opcache необходимо выделить 32Мб. Если сайтов больше чем 1 - возможно придется увеличить до 64Мб. Вместо MySQL ставим MariaDB. Обязательно ставим Memcached, php5-memcached (c буквой "d" в конце), ему даем 64-128Мб памяти. В WordPress устанавливаем плагин Memcached Redux (только внимательно читаем как его устанавливать - вместо активации плагина надо скопировать файл в wp-content). Это включит persistent object cache на уровне WordPress, большинство запросов вообще перестанет доходить до БД, а это самое узкое место на минимальном дроплете. Кроме того, если уж делать все серьезно, ставим плагин FFPC (Fast Full Page Cache), он позволит кешировать страницы целиком, а чуть поковырявшись с конфигами, можно кешировать страницы в Memcached (то есть в память), и отдавать их оттуда непосредственно Nginx'ом, даже не поднимая PHP-процесс, и уж тем более не касаясь базы данных. Объем памяти для Memcached, возможно, придется увеличивать - все зависит от объема сайта. Но при таком подходе вы получите очень высокую скорость отклика от своего маленького сервера, и он сможет выдерживать очень большие нагрузки. С полностью кешированным в память сайтом и отдачей Nginx'ом непосредственно из Memcached, а также с оптимизированным кодом и файлами (минификация и конкатенация скриптов и стилей, gzip, оптимизированные картинки и т.д., минимизация количества запросов и т.п.) данный дроплет за $5 сможет обслуживать и 50 000 просмотров в сутки. А это уже 1 500 000 в месяц. Даже пиковые 1-2-3 тысячи запросов (что будет крайне редко, если будет вообще) за короткий промежуток времени ("хабраэффект") пройдут еле-еле заметно - даже если начнет использоваться swap, на SSD-дисках он быстр. В итоге часть клиентов будут испытывать небольшие задержки, не более. Но это речь об одновременной тысяче посетителей на сайте, не меньше. К тому времени, как аудитория сайта дорастет до этого уровня, уверен вы уже перейдете хотя бы на дроплет за $10. А там ресурсов больше, при аналогичном подходе этот дроплет выдержит намного больше.
    Ответ написан
    5 комментариев