Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Да и просто это неспортивно — использовать внешнюю память, когда на плате установлены безумные 32 мегабайта памяти,
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...
как в старые добрые времена зависишь от сторонних dll и без них даже не скомпилируется
сложить рядом с исходниками нужные бинарные либы
можете, пожалуйста, прояснить этот момент? Я, конечно, пока ненастоящий растовчанин, но статическая линковка Rust сейчас является его и плюсом (всё своё ношу с собой) и минусом (бинари довольно крупные получаются) одновременно, а все crates собираются по месту из исходников. То есть, испытал абсолютно противоположный вашему опыт.
Про системы сборки: для C и C++ стараюсь использовать CMake, где возможно (если проект сам в себе; если либы поддерживают или легко адаптируются под CMake), который уже генерирует Makefile или Ninja, где как лучше, а также compile_commands.json для clangd. С ним удобнее поддерживать зависимости в порядке и в целом проще иерархию проекта строить.
Сейчас активно пробую Rust, там вообще уже всё предусмотрено - и пакетный менеджер, и система сборки, и статический анализатор, и даже тестирование; пока моё мнение складывается не в пользу C/С++ (по большей части).
Я писал код в таком режиме несколько лет, без всяких intellisense и статических анализаторов - просто в vim без плагинов: пишешь несколько сотен строк, потом (зачастую) читаешь портянку, которую выдаёт компилятор, потом исправляешь; и так в цикле, пока не будет ошибок и предупреждений; а ведь потом ещё отлаживать. Опыт не самый лучший, открыл для себя vscode, стало проще (да, жрущий электрон с плагинами на джаваскрипте) - всё в реальном времени: пишешь, сразу же исправляешь косяки свои; и тут же в git выделяешь нужные изменения, коммитишь и т.д.
Метод, которому учат большинство детей в школе, — длинное умножение — включает в себя много шагов с отдельными произведениями, которые нужно записывать и позже комбинировать.
вот наступит чебурнет и куда будет стучаться git или apt
Насчёт пакетов - хотя бы в mirror.yandex.ru, например. Если не обращаться к белым спискам, то есть ещё и, внезапно, BitTorrent, только в случае зеркалирования репозитортев он будет не под пиратским флагом :)
если быть точным, то без ручной пересборки некоторых пакетов (mesa, gtk3, gtk4, qt6-base и пр.), в зависимостях которых есть либы обоих протоколов, у вас не выйдет сделать отдельно иксовую или отдельно wayland сборку, только солянку.
Может немного оффтоп, но как думаете, реально ли уместить в 512 байт (максимум, 1 килобайт) инструкций AVR хотя бы двухканальный синтезатор (шум и меандр) и в ещё 1 килобайт мелодию минуты на 3 (несколько небольших партий, которые повторяются в течение всей мелодии)? Сжимаю Bad Apple, видео вместе с декодером уже умещаются в 32 килобайта с выводом на дисплей (40x32, 7 FPS), думаю, стоит ли ещё музыку приделать. Модулировать планирую в половину амплитуды динамика через ШИМ за неимением ЦАП.
Использую локальный менеджер паролей, синхронизирую между устройствами через провод.
После копирования менеджер паролей через 10 секунд очищает буфер обмена (что на пк, что на мобилке), а мастер-пароль вручную вбиваю каждый раз. Вероятность кейлоггера низкая в моём сценарии использования.
пароли впринцепе изжили себя, никто не будет набирать пароль в 20 символов.
Набираю из головы мастер-пароль длиной ~70 символов за 10 секунд (осмысленная фраза), открывая доступ к базе случайно сгенерированных паролей из 32+ символов и TOTP. ЧЯДНТ?
никогда не понимал желания того чтобы ОС загружалась за пару секунд
У меня на основном компьютере хранится куча всякой информации, которая редко нужна, а последнее время я работаю с ноутбука для удобства, поэтому основной компьютер (как ни странно) большую часть времени выключен и стоит ко мне задом. Одним движением руки я управляю блоком питания, компьютер автоматически включается при появлении питания, и пока я с ноутбука в проводнике захожу на нужный раздел FTP или в терминале открываю SSH-сессию, компьютер уже загрузился и принимает соединения.
Повторюсь, очень редко включаю компьютер, но иногда может понадобиться несколько раз в день это делать, и когда он грузится 5 секунд, а не 30 - это немного делает жизнь легче.
На ноутбуке у меня одна система, раздел EFI я делал размером 256 мегабайт - и это очень избыточно (даже если бы было две системы).
$> ls -lah /boot
total 84M
drwxr-xr-x 2 root root 16K Jan 1 1970 .
drwxr-xr-x 16 root root 4.0K Oct 22 12:58 ..
-rwxr-xr-x 1 root root 50M Oct 22 12:59 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root 19M Oct 22 12:59 initramfs-linux.img
-rwxr-xr-x 1 root root 16M Oct 22 12:59 vmlinuz-linux
Как видите, большую часть занимают два варианта стартовой rootfs. fallback вариантом я не пользуюсь никогда, мне просто лень его отключить в конфиге. Обычный вариант можно тоже убрать, если пересобрать ядро с модулем используемой на корневом разделе файловой системы, но мне тоже лень. В итоге останутся жалкие 16 мегабайт.
Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Влезает тютелька в тютельку (32720 байт).
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...
можете, пожалуйста, прояснить этот момент? Я, конечно, пока ненастоящий растовчанин, но статическая линковка Rust сейчас является его и плюсом (всё своё ношу с собой) и минусом (бинари довольно крупные получаются) одновременно, а все crates собираются по месту из исходников. То есть, испытал абсолютно противоположный вашему опыт.
Почти как привычка сохранять файл у некоторых)
Про системы сборки: для C и C++ стараюсь использовать CMake, где возможно (если проект сам в себе; если либы поддерживают или легко адаптируются под CMake), который уже генерирует Makefile или Ninja, где как лучше, а также compile_commands.json для clangd. С ним удобнее поддерживать зависимости в порядке и в целом проще иерархию проекта строить.
Сейчас активно пробую Rust, там вообще уже всё предусмотрено - и пакетный менеджер, и система сборки, и статический анализатор, и даже тестирование; пока моё мнение складывается не в пользу C/С++ (по большей части).
Я писал код в таком режиме несколько лет, без всяких intellisense и статических анализаторов - просто в vim без плагинов: пишешь несколько сотен строк, потом (зачастую) читаешь портянку, которую выдаёт компилятор, потом исправляешь; и так в цикле, пока не будет ошибок и предупреждений; а ведь потом ещё отлаживать. Опыт не самый лучший, открыл для себя vscode, стало проще (да, жрущий электрон с плагинами на джаваскрипте) - всё в реальном времени: пишешь, сразу же исправляешь косяки свои; и тут же в git выделяешь нужные изменения, коммитишь и т.д.
...или просто использовать статический анализатор
почему-то порвало с этого
В голове:
27*9 = 180+63 = 243
32*9 = 270+18 = 288
16*12 = 160+32 = 192
Насчёт пакетов - хотя бы в mirror.yandex.ru, например. Если не обращаться к белым спискам, то есть ещё и, внезапно, BitTorrent, только в случае зеркалирования репозитортев он будет не под пиратским флагом :)
стимпанк, получается
так ведь на пониженной надо))
На современных великах пониженная есть
Причём иногда достаточно сильная
Интересно, как бы выглядела органическая коробка передач :D
Как вам такие дороги? :)
если быть точным, то без ручной пересборки некоторых пакетов (mesa, gtk3, gtk4, qt6-base и пр.), в зависимостях которых есть либы обоих протоколов, у вас не выйдет сделать отдельно иксовую или отдельно wayland сборку, только солянку.
вам не кажется расточительным создавать файл лишь ради того, чтобы через мгновение удалить? или он создаётся в tmpfs?
Может немного оффтоп, но как думаете, реально ли уместить в 512 байт (максимум, 1 килобайт) инструкций AVR хотя бы двухканальный синтезатор (шум и меандр) и в ещё 1 килобайт мелодию минуты на 3 (несколько небольших партий, которые повторяются в течение всей мелодии)? Сжимаю Bad Apple, видео вместе с декодером уже умещаются в 32 килобайта с выводом на дисплей (40x32, 7 FPS), думаю, стоит ли ещё музыку приделать. Модулировать планирую в половину амплитуды динамика через ШИМ за неимением ЦАП.
Использую локальный менеджер паролей, синхронизирую между устройствами через провод.
После копирования менеджер паролей через 10 секунд очищает буфер обмена (что на пк, что на мобилке), а мастер-пароль вручную вбиваю каждый раз. Вероятность кейлоггера низкая в моём сценарии использования.
Набираю из головы мастер-пароль длиной ~70 символов за 10 секунд (осмысленная фраза), открывая доступ к базе случайно сгенерированных паролей из 32+ символов и TOTP. ЧЯДНТ?
У меня на основном компьютере хранится куча всякой информации, которая редко нужна, а последнее время я работаю с ноутбука для удобства, поэтому основной компьютер (как ни странно) большую часть времени выключен и стоит ко мне задом. Одним движением руки я управляю блоком питания, компьютер автоматически включается при появлении питания, и пока я с ноутбука в проводнике захожу на нужный раздел FTP или в терминале открываю SSH-сессию, компьютер уже загрузился и принимает соединения.
Повторюсь, очень редко включаю компьютер, но иногда может понадобиться несколько раз в день это делать, и когда он грузится 5 секунд, а не 30 - это немного делает жизнь легче.
На ноутбуке у меня одна система, раздел EFI я делал размером 256 мегабайт - и это очень избыточно (даже если бы было две системы).
Как видите, большую часть занимают два варианта стартовой rootfs. fallback вариантом я не пользуюсь никогда, мне просто лень его отключить в конфиге. Обычный вариант можно тоже убрать, если пересобрать ядро с модулем используемой на корневом разделе файловой системы, но мне тоже лень. В итоге останутся жалкие 16 мегабайт.