Вселенная - это материя. Для нас она бесконечно “растет” “из ничего”.
Если положить, что мы осознаём только три измерения пространства, а пространство на самом деле четырёх- или более мерное, то осознаём мы только трёхмерную проекцию пространства. А значит можно представить расширение/сжатие вселенной в виде колебания пространства вселенной в четвёртом (или ещё каком) одном измерении. Подобно тому, как колеблющийся шар в сечении двумерной плоскостью будет образовывать на ней циклично расширяющийся/сжимающийся круг из “ничего”.
линукс в дуалбуте для задач, которые на семерке не запускаются
заголовки у всех окон должны быть абсолютно единообразны
В линуксе имеет место тенденция замены протокола Xorg на Wayland. Оконный менеджер и композитор сливаются воеидно, а отрисовкой окна и, соответственно, window decorations занимается само приложение. И там полная свобода действий. Единообразия можно достичь разве что путём использования приложений на одном и том же графиическом тулките (Qt, GTK и подобные) и соответствующей графической среды, в которой этот тулкит будет основным. Иначе будет разрозненность во внешнем виде - не только в заголовках окон, но и в самих компонентах интерфейса. Можно, конечно, различными махинациями и совместимыми темами минимизировать такие различия, но дело не только во внешнем виде, но и поведении (стандартные горячие клавиши, стандартное поведение элементов интерфейса и т. д.).
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
вот незадача — OBS заставляет ваш ноутбук задыхаться
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени. Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
Кстати про неоновые интерфейсы. Не читая текст новости, а только лишь увидев скриншот приложения, сразу подумал, что нейрослоп. По аналогии с результатами экспериментов в комментариях под новостью про новую модель Qwen: раз, два. В обоих случаях тоже неоновый интерфейс. Забавно, сначала научились различать графический нейрослоп, потом текстовый, теперь вот ещё UI/UX-нейрослоп...
стандартная библиотека Rust — чтобы собирать и запускать приложения, написанные на чистом Rust;
Неужели планируется динамическое связывание программ на Rust со стандартной библиотекой Rust (кажется, видел такое в Redox OS)? Внешние крейты при сборке не выносятся в shared objects, а просто добавляются к бинарю? Просто приложения на "чистом Rust" в большинстве своём после сборки представляют собой большой почти статический бинарь, имеющий в зависимостях разве что libc и ещё пару системных библиотек.
Ещё вопрос не по теме. Читал предыдущие части, слог довольно приятный. Вы пишете текст/наброски статьи по ходу работы или апостериори?
Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 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 выделяешь нужные изменения, коммитишь и т.д.
Если положить, что мы осознаём только три измерения пространства, а пространство на самом деле четырёх- или более мерное, то осознаём мы только трёхмерную проекцию пространства. А значит можно представить расширение/сжатие вселенной в виде колебания пространства вселенной в четвёртом (или ещё каком) одном измерении. Подобно тому, как колеблющийся шар в сечении двумерной плоскостью будет образовывать на ней циклично расширяющийся/сжимающийся круг из “ничего”.
ослепляющие 3000 заклёпок :D
(в оригинале “nits”)
В линуксе имеет место тенденция замены протокола Xorg на Wayland. Оконный менеджер и композитор сливаются воеидно, а отрисовкой окна и, соответственно, window decorations занимается само приложение. И там полная свобода действий. Единообразия можно достичь разве что путём использования приложений на одном и том же графиическом тулките (Qt, GTK и подобные) и соответствующей графической среды, в которой этот тулкит будет основным. Иначе будет разрозненность во внешнем виде - не только в заголовках окон, но и в самих компонентах интерфейса. Можно, конечно, различными махинациями и совместимыми темами минимизировать такие различия, но дело не только во внешнем виде, но и поведении (стандартные горячие клавиши, стандартное поведение элементов интерфейса и т. д.).
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени.
Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
Кстати про неоновые интерфейсы. Не читая текст новости, а только лишь увидев скриншот приложения, сразу подумал, что нейрослоп. По аналогии с результатами экспериментов в комментариях под новостью про новую модель Qwen: раз, два. В обоих случаях тоже неоновый интерфейс. Забавно, сначала научились различать графический нейрослоп, потом текстовый, теперь вот ещё UI/UX-нейрослоп...
Ещё чем-нибудь занимаетесь помимо программирования? В плане увлечений. Может нужно отвлечься?
С этим примерно понятно. А что имеется ввиду под
Неужели планируется динамическое связывание программ на Rust со стандартной библиотекой Rust (кажется, видел такое в Redox OS)? Внешние крейты при сборке не выносятся в shared objects, а просто добавляются к бинарю? Просто приложения на "чистом Rust" в большинстве своём после сборки представляют собой большой почти статический бинарь, имеющий в зависимостях разве что libc и ещё пару системных библиотек.
Ещё вопрос не по теме. Читал предыдущие части, слог довольно приятный. Вы пишете текст/наброски статьи по ходу работы или апостериори?
Извините
... пока оба операнда отличны от NaN :)
только для целочисленного деления. В случае чисел с плавающей точкой существуют ±inf и NaN.
Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 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 выделяешь нужные изменения, коммитишь и т.д.
...или просто использовать статический анализатор
почему-то порвало с этого