mayton2019

Есть такое шуточное выражение - "works as designed". :)
Обычно так мы отмахиваемся от тестировщиков если те подозревают баг но не уверены. :)

Скорее всего нет т.к identifiers всегда начинаются не с цифр. Это старое правило. Ему уже пол-века и оно действует не только в pg но и Oracle и во многих языках трансляторах.

До того как автор начнет что-то повышать. Пускай послушает мою мысль. Между 3.33 и 3.6 разница порядка 8%
Общий индекс производительности системы зависит не только от процессора но вообще от совокупной работы всех частей (реакция памяти и скорость кешей L1/L2/L3). Если просто повышать частоту CPU но при этом не менять ничего остального то эффект - нивелируется. Ожидаемого прироста 8% не будет. Будет меньше.

Даже если гипотетически предположить что автор поднял частоту до 5Ghz то и в этом случае удвоения перформанса не будет.

Вобщем послушайте старого программиста на C++ и прочих ассемблерах. Не тратье своё время на фигню. Ваша игра или рендеринг 3Д графики особой разницы не почувствуют. Взамен вы получите потенциальные проблемы. Ведь производитель не собирался делать нестандартный режим номинальным. В этом был свой смысл.

Вопрос - обо всем и ничем сразу. Скорее всего надо найти готовую имплементацию QR-распознавателя и проверить поддерживает он режим такого множественного распознавания.

Скорее всего убунта была не выключена а запаркована в хибернейт. В этом случае большинство устройств тоже паркуются.

Проверь настройки кнопки power.

Лови первую помидорку!

Нет смысла делать операции XOR над char типом данных.
newMassage[x] = (char)(newMassage[x] ^ dayKey);
В криптографии если ты решил серъезно играть - то надо весь открытый текст перевести в byte array
(здесь как раз появляется понятие кодовая страница) и потом применить XOR к этому байтовому массиву.
Для печати на экране байт-масив переводят либо в binhex, либо в base64.

Для дешифрования - соотв. надо сделать обратный цикл. Из binhex в байтовый массив. Потом из него XOR и потом - национальная кодовая страница.

В какой строке у тебя NPE?

Дело в том что bash сам по себе не является языком программирования. Он - просто связующий клей который вызывает внешние утилиты. Поэтому если у вас задача серъезная - то берите Perl/Python. Там есть сильные средства для процессинга текста и отчотов.

Bash подойдет только до первого out of memory как только у вас зайдет файл превышающий оперативку. Или просто зайдет "технически"-нетекстовый файл где строки будут сверх-длинные или просто вызывающие побочные эффекты. Обработать такую ситуацию в ЯП - нормально а в баше - сложно.

Поскольку речь идет о языке "C" - то надо корректно обрабатывать ошибки open/read/write/fseek/close и реагировать на них. И закрывать файловые хендлы при любом возможном исходе. Ну и не забывать делать free() после malloc(). Грубо говоря количество malloc должно быть всегда равно free.

Если была смерть posix-потока то надо как-то найти все брошеные дескрипторы-сироты и закрыть их тоже. Тоесть процесс-родитель должен как-то их видеть.

Есть хорошая поговорка про пудинг.

Вобщем для расчета значение математического выражения - его надо вычислить. Никакие брутфорсы скорее всего не помогут. Выражение может потребовать расчетов функций. И их надо провести. Как - это уже другой вопрос но ясно что не в строках.

Непонятно зачем автор обсуждает глифы и шрифты? Данная задача состоит из двух частей.
1) Преобразование двоичного числа (например int) в строковое представление двоичного числа.
2) Печать этой строки на экране используя (или не используя) явное указание шрифтов и прочее.

И мне кажется что автор не решил пункт (1) этой задачи. Этот пункт является обязательным на первых уроках информатики. Он называется "Системы счисления". Позиционные. Непозиционные. Перевод из одних систем в другие и прочее. Вот с этого надо начать обсуждение.

Вопрос в перспективе тянет на экспертную систему по выбору БД.

При данной постановке - можно брать любую документно-ориентированную. Все одинаково подходят.
Но если основной контент (80% берем по Паретто) это файлы - то можно брать Amazon S3, в дальнейшем с перспективой трансформировать это в DynamoDb если понадобятся транзакции или в Amazon Document Db (он же Mongo) если понадобится тонкая работа с атрибутами документов (или файлов).

Автор должен понять что в это вопросе нет единого правильного решения. Есть просто некая сравнительная табличка где есть набор фичей с одной стороны и набор DBMS с другой и нет такого покрытия которое бы закрыло ВСЕ фичи.

Если часто удаляется папка с over миллиардом файлов то можно пересмотреть эту задачу архитектурно. Например смонтировать эту папку как volume и форматировать ее. Это быстрее. В противоположность, файловые удаления по 1 штуке требуют фиксации транзакции для каждого файла. А это избыточные действия которые как раз и создают поток IOPs над структурами данных ext4. По аналогии с БД. То что делает автор это удаление каждой строчки из таблицы с коммитом. А то что я предлагаю - это по смыслу truncate table.

Если автору нужно хранить данные измерений (графики) в режиме append-only, то можно посмотреть в сторону InfluxDB.

Сразу 3 замечания.

Непонятно зачем автору считать 43 мегабайта на фоне 3Гб. Это 1%.
Непонятно зачем автор печатает физические размеры файлов. Ведь в них хранятся заголовки и всякие
прочие служебные структуры данных которые к размеру таблицы не относятся.
И непонятно зачем автор вывел длины файлов в размере который округлён в human-readable? Там все равно не учтены килобайты. Уж если пошёл счет на копейки так надо и копейки печатать.

Прости но уж очень много неточностей и косвенностей в самом вопросе. Просто нельзя так.

Почти таже самая проблема на стареньком HP Core i3. Пока стояла десятка все норм. Как только поставил Ubuntu 18 LTS - пошли регулярные дисконнекты. Субъективно вижу что очень низкая чувствительность антены приёмника в ноуте. Грешу на хреновые дрова. Так и не пролечил.

Workaround: Когда включаю смартфон в режиме wifi-точки и ложу его рядом прямо с корпусом ноута - связь появляется.

Можно эту прямоугольную "колбасу" вообще не поворачивать. А хранить вектор повернутости. И перегрузить оператор индекса чтобы доступ вел себя по правилам аффинных преобразований.

Вопрос звучит неправильно. Сам по себе С++ не имеет никаких встроенных в себя технологий для отрисовки графики. Это уже - задача библиотек которые будут зависеть от ОС или оконного менеджера.

И здесь Qt, Gnome, KDE, WTL просто производные от ОС.