Насколько я понимаю, формирование вектора по номеру посылки заранее не слишком сложной функцией, вряд ли лучше чем вектор, собранный из двух РАЗНЫХ криптостойких PRNG, поксоренный на число тактов процессора и внутренние такты ОС со смещением. Разве нет?
Я немного писал про это в тексте. Решение с взятием сообщений от окна (движение мышью, клавиатура, системные сообщения) мне не очень нравится в виду неудобств для пользователя. Меня лично необходимость елозить мышкой (если это не игра Hammerfight :) напрягает. К тому же, я мог бы потеоретизировать на тему «90% пользователей генерируют в целом схожие пассы мышкой, что вряд ли лучше хорошего PRNG по ДРУГОМУ алгоритму, поксоренному на всякие процессорные такты и прочее», если бы был профессионалом в криптографии.
Извините за глупые вопросы, если что.
Изменить свою температуру можно из-за конвекции, теплопередачи или излучения (если верить физике).
Пространство безвоздушное, т.е. конвекции и теплопередачи там нет. Вода, нагретая до комнатной температуры, вряд ли передаёт много энергии из-за излучения. Тогда чем вызвано такое быстрое превращение воды (мочи) в лёд в космосе?
Второй момент. 68 килограмм при плотности воды 1000 кг/м3, соответствует объёму в 0,068 м3, или 68 дм3. Это, скажем, сфера радиусом примерно 4 дм или диаметром 80 см. Неужели такой маленький объект так сильно заметен при многокилометровом удалении?
Я никаким боком не специалист в астрономии, если что. Размышляю на уровне обычной школьной физики.
1. Хотелось бы пару скриншотов нового интерфейса (об этом писали выше).
2. — 3. Хотелось бы конкретных цифр, хотя бы банального замера Hellow World в плане память / скорость загрузки.
За новость спасибо. Хотелось бы конкретных цифр, чтобы, например, сравнить с используемым фреймворком и принять решение о возможном переходе на Кьют 4.6.
Иллюстрация скорее свидетельствует о контингенте, пользующимся данным сервисом, чем о реальном соотношении разных категорий спроса для социума в целом.
Статья поднимает важную тему, но является скорее констатацией, чем исследованием.
Программируя многопоточные приложения в течение нескольких лет, пришёл к полностью асинхронной модели взаимодействия потоков. Всё это позволило мне отказаться от (явного) использования объектов синхронизации.
Как ни странно, выросла не только стабильность работы, но и простота отладки. В конечном итоге, оказалось что асинхронный подход сильно снижает затраты на разработку многопоточных приложений, уже хотя бы потому что исчезает огромное количество проблем и потенциальных неприятностей вроде deadlock.
Всё это дело было реализовано в рамках одного их кроссплатфороменных фреймворков на С++. Тесты показали очевидную вещь: за всё приходится платить, и иногда данный подход себя оправдывает. О чём конкретно речь? Асинхронная модель предполагает наличие у каждого потока очереди сообщений (в моём случае я вместо сообщений храню указатели на функции и их аргументы). Очевидно, это приводит к увеличению использования оперативной памяти и работы процессора по переносу (копированию) вышеозначенных элементов очереди.
Таким образом, асинхронный подход с очередью сообщений актуален для применений, где этих сообщений не так много (не больше нескольких десятков тысяч в секунду). Это актуально для большинства прикладных программ (увы, всякие серьёзные вещи вроде серверов зачастую требуют большее быстродействие). Если условие выполняется, то есть хороший шанс написать программу, избавив себя от большинства проблем с многопоточностью.
Как пример, приведу свою прошлую программу, где шесть потоков почти не потребовали отладки при синхронизации, из-за использования асинхронного подхода и очередей.
Не в целях рекламы, а в целях обмена опытом, хочу сказать, что в своё время сделал сравнительно универсальный движок сайта для хранения и поиска информации по набору иерархических тэгов. Любой информации, любой тематики.
Будет интересно — скину адрес для посмотреть.
В этом направлении, кстати, сейчас движутся Маркет.Яндекс, сами того не зная. )
Так вот, самое главное: работа с иерархическими тэгами оказалась слегка тяжёлой для рядового пользователя. Здесь бы скорее обсудить формы их представления для юзера. Вот это действительно большой вопрос.
Согласен. Причём в общем случае иерархий тэгов может быть несколько, т.к. любой объект можно классифицировать по целому ряду свойств. В каждой конкретной задаче может быть ровно столько иерархий тэгов, сколько необходимо (или достаточно?) для быстрого поиска нужного объекта в разных ситуациях.
Было бы здорово если бы кто-нибудь квалифицированный и «в теме», ответил на эти вопросы.
В качестве альтернативной мысли могу вспомнить, что тот же Тесла умер в более чем преклонном возрасте (около 90 лет, сбила машина), хотя через себя пропускал жуткие напряжения с жуткими частотами.
www.computerworld.com/s/article/9048438/Microsoft_confirms_that_XP_contains_random_number_generator_bug
rnd.cnews.ru/math/news/top/index_science.shtml?2007/11/26/276723
www.computerworld.com/s/article/print/9047179/Reverse_engineering_cracks_Windows_encryption
В результате пришёл к реализации OpenSSL, про чей генератор PRNG, вроде как, отзывы лучше.
habrahabr.ru/blogs/popular_science/69655/#comment_1985702
Вы таки про кристаллизацию из-за низкой температуры точно знаете или только предполагаете? Скажите честно.
Изменить свою температуру можно из-за конвекции, теплопередачи или излучения (если верить физике).
Пространство безвоздушное, т.е. конвекции и теплопередачи там нет. Вода, нагретая до комнатной температуры, вряд ли передаёт много энергии из-за излучения. Тогда чем вызвано такое быстрое превращение воды (мочи) в лёд в космосе?
Второй момент. 68 килограмм при плотности воды 1000 кг/м3, соответствует объёму в 0,068 м3, или 68 дм3. Это, скажем, сфера радиусом примерно 4 дм или диаметром 80 см. Неужели такой маленький объект так сильно заметен при многокилометровом удалении?
Я никаким боком не специалист в астрономии, если что. Размышляю на уровне обычной школьной физики.
2. — 3. Хотелось бы конкретных цифр, хотя бы банального замера Hellow World в плане память / скорость загрузки.
За новость спасибо. Хотелось бы конкретных цифр, чтобы, например, сравнить с используемым фреймворком и принять решение о возможном переходе на Кьют 4.6.
Программируя многопоточные приложения в течение нескольких лет, пришёл к полностью асинхронной модели взаимодействия потоков. Всё это позволило мне отказаться от (явного) использования объектов синхронизации.
Как ни странно, выросла не только стабильность работы, но и простота отладки. В конечном итоге, оказалось что асинхронный подход сильно снижает затраты на разработку многопоточных приложений, уже хотя бы потому что исчезает огромное количество проблем и потенциальных неприятностей вроде deadlock.
Всё это дело было реализовано в рамках одного их кроссплатфороменных фреймворков на С++. Тесты показали очевидную вещь: за всё приходится платить, и иногда данный подход себя оправдывает. О чём конкретно речь? Асинхронная модель предполагает наличие у каждого потока очереди сообщений (в моём случае я вместо сообщений храню указатели на функции и их аргументы). Очевидно, это приводит к увеличению использования оперативной памяти и работы процессора по переносу (копированию) вышеозначенных элементов очереди.
Таким образом, асинхронный подход с очередью сообщений актуален для применений, где этих сообщений не так много (не больше нескольких десятков тысяч в секунду). Это актуально для большинства прикладных программ (увы, всякие серьёзные вещи вроде серверов зачастую требуют большее быстродействие). Если условие выполняется, то есть хороший шанс написать программу, избавив себя от большинства проблем с многопоточностью.
Как пример, приведу свою прошлую программу, где шесть потоков почти не потребовали отладки при синхронизации, из-за использования асинхронного подхода и очередей.
100*10*( 2*sizeof(int) ) = 8000 байт, что после архивации даст что-то около 1 кБ.
Очень неплохой результат.
Не в целях рекламы, а в целях обмена опытом, хочу сказать, что в своё время сделал сравнительно универсальный движок сайта для хранения и поиска информации по набору иерархических тэгов. Любой информации, любой тематики.
Будет интересно — скину адрес для посмотреть.
В этом направлении, кстати, сейчас движутся Маркет.Яндекс, сами того не зная. )
Так вот, самое главное: работа с иерархическими тэгами оказалась слегка тяжёлой для рядового пользователя. Здесь бы скорее обсудить формы их представления для юзера. Вот это действительно большой вопрос.
В качестве альтернативной мысли могу вспомнить, что тот же Тесла умер в более чем преклонном возрасте (около 90 лет, сбила машина), хотя через себя пропускал жуткие напряжения с жуткими частотами.