Не просто на порядки. С теоретической точки зрения, энергии батареи моего телефона 6.11 Wh хватит хватит для обработки примерно 8076668869795109 гибабайт информации. В идеальном случае, конечно :) см. Принцип_Ландауэра
Что за бред вы тут несёте? Брейнфаки, одноразовые блокноты, которые взламываются за месяц, ключи длиннее открытого текста, какое-то устаревание и невозможность криптостойко зашифровать открытый текст одним паролем… Идите почитайте хотябы начальную литературу по криптографии.
А в чём посыл-то? В чём диаметральная противоположность подходов? Компьютеры уже достаточно мощные, чтобы с лёгкостью и без урона производительности шифровать всё. Чем меньше данных зашифровано, тем легче выделить среди их потока важные и сконцентрировать усилия на них. Нет никаких «всё кое-как» и «не всё, но надёжно». Есть «всё и надёжно» и «не всё и кое-как» — эти два показателя связаны между собой прямой зависимостью, а не обратной. Не всегда, конечно, но в текущих реалиях и подавляющем большинстве случаев именно так. Когда шифрование и дешифрование занимали ценные и ограниченные вычислительные ресурсы, имело смысл сконцентрировать их на более надёжном шифровании небольшого, но наиболее важного подмножества информации.
Один из самых уважаемых мной людей. Если такие люди начинают говорить, то ещё не всё потеряно.
А если этот, не побоюсь этого слова, великий человек, приложит свои усилия к разработке криптографических протоколов нового интернета, может начаться новая эпоха. А нам, инженерам и техническим специалистам необходимо обеспечить должный уровень реализации.
Мне больше интересно, насколько юридически законны действия ФБР по использованию 0day-эксплоитов. Несмотря на все благородные цели — публикация 0day эксплоита ставит под угрозу огромную часть пользователей интернета, чьи убытки от этого наверняка в сумме перекроют весь бюджет подофильского бизнеса. Не всё конечно так страшно, но такие действия от государственных органах заставляют задуматься.
У XMPP есть немало принципиальных проблем. Он совершенно не приспособлен к работе в мобильных сетях. Ведь там главное — легковесность протокола, гарантированное подтверждение каждого важного сообщения, и переотправка их в случае отсутствия подтверждения, TCP-соединения в мобильных сетях могут рваться и заного устанавливаться по десять раз в минуту — XMPP не умеет стабильно работать в этих услових. Я вообще не знаю ни одного IM-протокола, который это умеет. Есть близкие протоколы в категории enterprise-MQ, но у них своя специфика. А вот разработанный вконтактом MTProto — умеет. К тому же он совершенно не завязан на VK и у него нет принципиальных отличий клиента и сервера, по сути, это RPC-протокол с подтверждениями, криптографией и не зависимостью от транспорта (TCP/UDP/HTTP), сессии могут размазываться между многими соединениями совершенно не мешаясь.
Почитайте про него, я надеюсь в будущем он станет более широко применим.
Занялся бы фундаментальной математикой. И знания есть, и способности, и энтузиазм. Но программирование получается лучше всего, и за него, в отличие от математики, у нас хорошо платят. И нравится видеть результаты своего труда.
как раз наоборот, на своих почтовых серверах они могут как угодно выделить «письма от государства» и как угодно их подтверждать — использованием криптографических подписей, например.
Купон только на питере действует? На озоне заказывать значительно удобнее, т.к. в моём городе есть его пункт доставки, на который доставляют быстро и дёшево. На озоне выходит на 500 рублей дешевле, несмотря на отсутствие купона.
Т.е., будете перехватывать все исключения, чтобы самостоятельно убить JVM? А смысл? Более того, параллельно задавив дебаг вывод. Или зачем-то делая его каждый раз вручную.
JVM тут не при чём. Если бы вы хоть немного изучили архитектуру Eclipse платформы (именно платформы, IDE — это лишь одно её применение), то поняли бы, что именно делает её такой тяжелой. И, к слову, 300мб на современных компьютерах — мелочи, ради которых не стоит жертвовать удобством и скоростью разработки.
В данном случае это оправдано. Программа не должна «работать несмотря ни на что», это не ынтырпрайз. Завершиться в случае возникновения непредусмотренной ошибки тут — вполне ожидаемое от неё поведение.
Да ладно бы только linux, мы тут привычные и не такое запускали с помощью прямых рук и волшебных жестов. Вообще ни на чём, кроме винды не заработает.
Тем более что функционал игры вобщем-то без проблем реализуется чистым HTML5.
Хотел уже посоветовать другу, который собирается изучать java, пока не заметил, что ни у меня ни у него ничего не заработает — Silverlight-с… Удачи с продвижением сервиса. Идею поддерживаю, хоть инструменты для неё и подобраны не самым лучшим образом.
Я хоть и имею опыт реализации DSL на groovy, но статья все равно выглядит мануалом «как нарисовать сову» — сначала показывается обычный подход, ок, всем все понятно. Далее — «в groovy можно написать свой builder», и дается код, который это делает. И «резюмируется», что область применения у этого большая. Если бы я не был знаком с groovy, у меня возникли бы следующие вопросы — как это работает? что за класс BuilderSupport, который мы расширяем? Что за методы CreateNode и SetParent, которые мы перегружаем, когда они вызываются? Как, черт возьми, работают замыкания в groovy? (точнее, я даже не знал бы, что для работы билдеров, используются замыкания с модменой контекста).
ИМХО, статья вызывает больще вопросов, чем что-то объясняет. Простую и доходчивую книгу «Groovy for domain-specific languages» я в свое время прочитал за вечер. Кстате, есть перевод на русский.
Даже у нас в университете на лабораторных по теоретико-числовым методам в криптографии студенты реализовывали длинную арифметику на С++ несколько качественнее и обширнее. Мне кажется для публикации должны использоваться лучшие решения в своей области. Разобрали бы вы хотябы реализацию алгоритмов в GMP, было бы отлично.
А если этот, не побоюсь этого слова, великий человек, приложит свои усилия к разработке криптографических протоколов нового интернета, может начаться новая эпоха. А нам, инженерам и техническим специалистам необходимо обеспечить должный уровень реализации.
Почитайте про него, я надеюсь в будущем он станет более широко применим.
Тем более что функционал игры вобщем-то без проблем реализуется чистым HTML5.
ИМХО, статья вызывает больще вопросов, чем что-то объясняет. Простую и доходчивую книгу «Groovy for domain-specific languages» я в свое время прочитал за вечер. Кстате, есть перевод на русский.