Не просто на порядки. С теоретической точки зрения, энергии батареи моего телефона 6.11 Wh хватит хватит для обработки примерно 8076668869795109 гибабайт информации. В идеальном случае, конечно :) см. Принцип_Ландауэра
Что за бред вы тут несёте? Брейнфаки, одноразовые блокноты, которые взламываются за месяц, ключи длиннее открытого текста, какое-то устаревание и невозможность криптостойко зашифровать открытый текст одним паролем… Идите почитайте хотябы начальную литературу по криптографии.
А в чём посыл-то? В чём диаметральная противоположность подходов? Компьютеры уже достаточно мощные, чтобы с лёгкостью и без урона производительности шифровать всё. Чем меньше данных зашифровано, тем легче выделить среди их потока важные и сконцентрировать усилия на них. Нет никаких «всё кое-как» и «не всё, но надёжно». Есть «всё и надёжно» и «не всё и кое-как» — эти два показателя связаны между собой прямой зависимостью, а не обратной. Не всегда, конечно, но в текущих реалиях и подавляющем большинстве случаев именно так. Когда шифрование и дешифрование занимали ценные и ограниченные вычислительные ресурсы, имело смысл сконцентрировать их на более надёжном шифровании небольшого, но наиболее важного подмножества информации.
Один из самых уважаемых мной людей. Если такие люди начинают говорить, то ещё не всё потеряно.
А если этот, не побоюсь этого слова, великий человек, приложит свои усилия к разработке криптографических протоколов нового интернета, может начаться новая эпоха. А нам, инженерам и техническим специалистам необходимо обеспечить должный уровень реализации.
Я достаточно хорошо разбираюсь в IM-протоколах — реализовывал бинарный ICQ-протокол, реверс-инженерил Skype, реализовывал клиентов, ботов, серверные сервисы XMPP, и даже писал свой сервер в порядке эксперимента, писал клиента нового вконтактового MTProto. Хоть меня уже слили однажды за такое мнение, но повторюсь — XMPP нельзя называть устаревшим, но он не реализовывает и не может реализовать множество возможностей, которые требуются от современных IM-протоколов, и XEP-ами эта проблема не решается — они располагаются на слишком высоком уровне.
А именно:
1. Стабильная работа на нестабильном сетевом соединение — если соединение рвётся, сообщения могут теряться, как входящие, так и исходящие. XMPP работает исключительно по TCP и полагается на стабильность соединения, нет возможности создавать сессии, размазанные по нескольким соединениям, нет гарантированной доставки сообщений, существует XEP-0184, но он до сих пор Draft и никем не поддерживается и не решает проблемы полностью, так как находится на высоком уровне и распространяется далеко не на все сообщения протокола.
2. Нет возможности доставки сообщений на все девайсы пользователя и синхронизации истории между ними — с доставкой gtalk решил проблему, нарушив спецификацию XMPP, но это ему не очень помогло.
3. Нет возможностей отправки медиавложений в сообщения — фотографии, видео, геолокоейшоны и прочее. Даже если реализовать поверх костылями, это будет работать не очень хорошо и с большим оверхедом.
4. Нет единого стандарта на отправку файлов, существует огромное количество разнообразных костылей и proxy service для этого.
5. MUC для организации групповых чатов слишком неудобен и его очень непросто интегрировать с существующими сервисами, как в случае ВК, не верите — почитайте спецификацию, почитайте ВК-апи, и попробуйте предположить, как могла бы работать подобная интеграция, не нарушая спецификаций XMPP.
6. Ещё можно добавить, что сам протокол тяжел, гибок не в том месте, где надо и избыточен, но это уже много раз обсуждалось и сущие мелочи по сравнению с недостатками выше.
Мне больше интересно, насколько юридически законны действия ФБР по использованию 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, было бы отлично.
А если этот, не побоюсь этого слова, великий человек, приложит свои усилия к разработке криптографических протоколов нового интернета, может начаться новая эпоха. А нам, инженерам и техническим специалистам необходимо обеспечить должный уровень реализации.
А именно:
1. Стабильная работа на нестабильном сетевом соединение — если соединение рвётся, сообщения могут теряться, как входящие, так и исходящие. XMPP работает исключительно по TCP и полагается на стабильность соединения, нет возможности создавать сессии, размазанные по нескольким соединениям, нет гарантированной доставки сообщений, существует XEP-0184, но он до сих пор Draft и никем не поддерживается и не решает проблемы полностью, так как находится на высоком уровне и распространяется далеко не на все сообщения протокола.
2. Нет возможности доставки сообщений на все девайсы пользователя и синхронизации истории между ними — с доставкой gtalk решил проблему, нарушив спецификацию XMPP, но это ему не очень помогло.
3. Нет возможностей отправки медиавложений в сообщения — фотографии, видео, геолокоейшоны и прочее. Даже если реализовать поверх костылями, это будет работать не очень хорошо и с большим оверхедом.
4. Нет единого стандарта на отправку файлов, существует огромное количество разнообразных костылей и proxy service для этого.
5. MUC для организации групповых чатов слишком неудобен и его очень непросто интегрировать с существующими сервисами, как в случае ВК, не верите — почитайте спецификацию, почитайте ВК-апи, и попробуйте предположить, как могла бы работать подобная интеграция, не нарушая спецификаций XMPP.
6. Ещё можно добавить, что сам протокол тяжел, гибок не в том месте, где надо и избыточен, но это уже много раз обсуждалось и сущие мелочи по сравнению с недостатками выше.
Почитайте про него, я надеюсь в будущем он станет более широко применим.
Тем более что функционал игры вобщем-то без проблем реализуется чистым HTML5.
ИМХО, статья вызывает больще вопросов, чем что-то объясняет. Простую и доходчивую книгу «Groovy for domain-specific languages» я в свое время прочитал за вечер. Кстате, есть перевод на русский.