У меня был Intel Atom 32х бит тоже 13 года. Я родителям покупал. Вместе с Window-XP.
Нормально там и youtube можно было смотерть.
Давайте будем честны. Ну не игровая эта платформа Debian. Тем более что если искать
дрова по состоянию на 2013 год то найдете то что как раз и было 10 лет назад в статусе
поддержки игр.
Есть известный доклад Алименкова на тему JMS и он там где-то рекомендует вместо пересылки по MQ толстых файлов - складывать их в любое key-value хранилище и передавать по MQ только линку на файл.
С моей точки зрения это правда имеет смысл но только в том случае если чтение файла - опционально. Тоесть потребитель может захотеть читать файл а может и нет.
Александр Ананьев, почему. Не факт. Шрифты и векторные фигурки он рисует нормально. Насчет пикселей я не уверен. Ну я-бы протестировал еще раз. Последний раз я игрался лет 7 назад в графику.
Хрен его знает какой тут фильтр. Можешь приаттачить 2 фото. Например слева чтоб было такое фото с дымкой. А справа - ты чуть наклонил объектив и снял нормально. Тогда может люди подскажут комбинацию фильтров.
MrakLula, я не знаю что такое "напрямую". Но мне показалось визуально что перформанс
при работе с SDL в Windows был быстрее чем если-бы я рисовал это GDI+ на Bitmap context
и отображал бы этот bitmap по событию OnPaint(HDC hdc). Вот. Если кто-то может объяснить
почему работа с SDL быстрее чем c GDI+ - то я был бы рад. Я не могу объяснить но мне для
себе и не особо нужно. Просто так вижу.
forced, смотри It доклады и конференции очень крупных компаний которые уже что-то сделали и хвастаются как у них там все ловко и хитро. Тут особенно ценен опыт докладчика который не теоретик а как раз зашел со стороны инженерной. Тоесть он уже горел в performance issues, он видел сложные баги которые никакой теоретик не придумает просто в силу синергии многих технологий. И как он эти баги решал. Мне например было интеренсно послушать доклады про протокол Http3/Quic и просто понять что все мои представления о скорости TCP были немного другие. Вот. Много докладов было в разделах Amazon (AWS) кажется где крупные компании (авиа, транспорт, продажи) хвастаются где они чего соптимизировали.
В целом векторы оптимизации - почти всегда это event sourcing, partitioning, ослабление уровней ACID
и все в условиях когда бизнес этому удовлетворяет.
Вот. А EAV - это взгляд из 20-го века. Он безнадежно устарел и его обычно читают старые и дряхлые преподаватели-куколды которые только и помнят что Турбо-Паскаль и БД Информикс. Современные БД
поддерживают документы блобы в XML/JSON и не нужен тебе ЕАВ аж никогда.
Нормализации нет предела. Можно считать что руководители и исполнители - это суть персоны. И их персональность - это тоже реляция в данной модели.
Вобщем слушай автор. В Mongo и в Cassandra и в Couchdb данные лежат не в нормалях в агрегатах.
И это считается best practices. Я не хочу сказать что тебе нужны агрегаты. Просто существуют
в природе и такие задачи и они вполне себе живут. Особенно если данные исторические
и больше не меняются. Или меняются только как журнал (append only) или исторические
метаданные.
Я не знаю есть ли у этого фреймворка сообщество или багтрекер. Но я-бы на твоем месте написал бы сюда например https://community.khronos.org/ . С примером.
И исходник надо переделать. Выкинуть все ООП. И сделать такой себе плоский тест кейс который просто показыает ошибку. В один main.
Может это и в самом деле не баг а такое документированное поведение.
Это еще пустяк. Хотя-бы баг стабильный. И воспроизводится постоянно. Бери себе. Дебаж похихоньку. Хоть целый день на брейкоинтей стой. Можешь чай пить.
А бывают баги которые толи под нагрузкой стреляют. Толи по часам. В определенный интервал суток. Вот это печаль-беда.... Мдя.
