Выше я писал свою точку зрения относительно порядка изучения языков и C в этом списке на первом месте. То есть, без императивных в любом случае никак не обойтись. Однако для общего развития не помешает также и знание функционального языка. Неслучайно разработчики императивных языков многое почерпнули из функциональных языков (к примеру, списковые выражения в питоне и в MoonScript).
Будет проигрыш в скорости, разумеется. Но я же не про конкретно этот случай говорил. Часто бывает, что время работы программиста — более ценный ресурс, чем время вычислений. Допустим, есть сложный алгоритм, который нигде не реализован. Во многих случаях его для начала надо реализовать в функциональном стиле, без mutable-объектов и преждевременных оптимизаций, чтобы правильно работало и было понятно, что где происходит. А потом уже, если понадобится, заниматься оптимизациями.
Это был лишь пример того, как коротко и понятно реализовать достаточно сложный алгоритм (которого, допустим, нет в стандартной библиотеке). Практически в любой программе можно выделить алгоритм, который не найти в стандартной библиотеке. Как в таком случае будет написан код, зависит от программиста. Возможно, что те, кто имел опыт с функциональными языками, напишут более понятный код, в котором будет меньше ошибок. Вот, собственно, и есть польза от функциональных языков в обучении, как я её вижу. Если бы C был молотком, то хаскель был бы инструкцией, как не попасть по пальцам.
Поддерживаю. После полного освоения C надо освоить какой-нибудь скриптовый язык с элементами функциональщины: Lua, JavaScript, Ruby или Python. Потом перейти к C++ и параллельно осваивать теорию: структуры данных и алгоритмы. А там и срок обучения закончится. Чистые функциональные языки можно осваивать параллельно как дополнительный материал, чтобы повышать кругозор.
GTK 3.4.2-7. Дебиан стабильный.
Не знаю, как проверить, был ли он собран с опцией --enable-broadway-backend. В папке debian/ пакета с исходниками broadway не упоминается, поэтому думаю, что не было этой опции.
Это уже будет не умный список, а искусственный интеллект. Правила naxsi помогают отрезать принципиально отличающиеся запросы, например эксплойты к веб-приложению. А правило о том, что юзеры не могут смотреть приватные данные друг друга, должны составлять люди (разработчики веб-приложения и конфигурации веб-сервера или тестировщики), а не роботы, я так думаю.
Качество картинки конечно не идеальное, но если не вглядываться, то и не заметишь, это всё-таки не JPEG :)
Можно доработать подход с чисткой HTML и сделать DOM-диффы, которыми и общаться с клиентом. Впрочем, если вы защищаете сайт, а не пользователя, то можно не чистить HTML, а просто брать диффы.
А как построить по настоящему умный белый список? Он ведь изменяется постоянно.
Добавили на сайт новую функциональность, протестировали, параллельно автоматически дополнили правила белого списка.
Делал похожую штуку, только с другой целью: защита пользователя от сайта. Программа представляет собой веб-прокси, написанный на Wt, в котором крутится вебкит в Qt. Сайт переводится в картинку PNG и в таком виде отправляется в настоящий браузер. События мыши и клавиатуры с клиента летят на сервер и переводятся в события Qt. Есть кнопочка для отображения безопасных частей страницы в виде текста (чтобы можно было скопировать).
Если зашить фиксированный URL и немного доработать, то будет как раз то, о чем вы говорите. Предупреждаю, что это прототип. Более дешевым решением вашей задачи является белый список паттернов запросов, который можно построить и применить при помощи nginx и naxsi.
А как составлять список этих «личностей» и искать по ним информацию? Сейчас это достаточно просто сделать, для этого надо отобрать только тех, кто «шифруется». Это потому, что таких мало относительно большинства людей, полностью открытых для слежки. А теперь представьте мир, где каждое письмо зашифровано PGP, весь трафик по умолчанию идёт через Tor, а для оплаты самых обычных покупок используется биткоин. В таком мире для АНБ все люди одинаково подозрительны и ему пришлось бы дешифровывать всё подряд. Что нас отделяет от такого мира? Неосведомлённость простых людей о сильных способах защиты и неудобства, связанные с их использованием. К примеру, блокировки пользователей Tor в том же GitHub.
Эксперты согласны в том, что разведывательным агентствам гораздо сложнее манипулировать программами с открытым исходным кодом, чем многими из закрытых систем, разрабатываемых такими компаниями, как Apple и Microsoft.
поэтому пусть будет не rar, а pgp или на худой конец 7zip. А в целом-то идея ваша правильная: если все начнут всё шифровать, то у АНБ кончатся ресурсы на расшифровку, даже если им известны способы ускорить перебор паролей.
«Электронные кодовые книги, такие как Advanced Encryption Standard, одновременно и широко распространены, и хорошо защищены от криптоатак. АНБ владеет только небольшим количеством внутренних техник по их взлому. Проект TUNDRA исследует потенциально новую технику для определения ее полезности при анализе электронных кодовых книг».
AES (и не только) в режиме electronic codebook как раз небезопасен. Проясните, пожалуйста, что имелось в виду под electronic codebook.
Ладно бы VPN. Блокируя по IP, сайты подталкивают хакеров к взлому машин пользователей для использования в качестве прокси. И всё потому что кто-то умеет решать проблему только баном по IP.
Если нет сомнений в том, что код работает правильно, читается средним программистом и на 100% покрыт тестами — можно идти пить пиво. Проблема ленивых программистов часто сводится к невыполнению одного из этих условий.
Первый вариант не так уж плох. Точнее, скажем так: он не так плох, чтобы изобретать замену.
В конце концов, если станет неприятно писать такое руками, всегда можно сделать генератор.
Есть ещё кое-что: JSON не позволяет ошибаться. Забыл кавычку и парсинг не проходит. А в вашем формате пропади хоть полфайла и всё распарсится. Мне кажется, что надёжность в этом месте важнее, чем человекочитаемость.
Этого достаточно, чтобы влюбиться в язык. Хотя на хаскеле не пишу, для меня это послужило уроком о том, как надо писать код на питоне и других языках.
Если пользователь проворонил такой троян, то вряд ли у него будет такой хитрый файрвол. Можно же пересылать информацию в DNS-запросах, к примеру.
Не знаю, как проверить, был ли он собран с опцией --enable-broadway-backend. В папке debian/ пакета с исходниками broadway не упоминается, поэтому думаю, что не было этой опции.
Trace/breakpoint trap
Можно доработать подход с чисткой HTML и сделать DOM-диффы, которыми и общаться с клиентом. Впрочем, если вы защищаете сайт, а не пользователя, то можно не чистить HTML, а просто брать диффы.
Добавили на сайт новую функциональность, протестировали, параллельно автоматически дополнили правила белого списка.
Если зашить фиксированный URL и немного доработать, то будет как раз то, о чем вы говорите. Предупреждаю, что это прототип. Более дешевым решением вашей задачи является белый список паттернов запросов, который можно построить и применить при помощи nginx и naxsi.
В конце концов, если станет неприятно писать такое руками, всегда можно сделать генератор.
Есть ещё кое-что: JSON не позволяет ошибаться. Забыл кавычку и парсинг не проходит. А в вашем формате пропади хоть полфайла и всё распарсится. Мне кажется, что надёжность в этом месте важнее, чем человекочитаемость.