Пластины винчестера вращаются независимо от того, перезаписывается он, просто читается или вовсе бездействует (если бездействует долго, то можно остановить, но это отдельная история со своими нюансами).
Так что как минимум подшипникам все равно как часто будут перезаписаны данные.
The first time you build and run the project this way, it will download a prebuilt shared library for the Dawn native WebGPU implementation automatically <...> Optionally, Dawn can be built from scratch with gpu.cpp <...> However, this is recommended for advanced users only. Building Dawn dependencies with cmake takes much longer than using the precompiled Dawn shared library.
В наше-то время предлагать выполнять автоматически скачиваемый неизвестно откуда бинарник >___<.
Если начинающие программисты будут думать что массивы в C++ это std::array и std::vector, а T[] это такая штука из далекого прошлого примерно как register или std::auto_ptr, то всем будет только лучше.
FFmpeg тоже нельзя. Либо вы не замечаете погрешности, либо граница удачно попадает на опорный кадр.
Проблема в том, что практически в любом видео для декодирования кадра нужен как минимум предыдущий опорный кадр, а в некоторых случаях еще и следующий. Чтобы и включить нужные кадры в файл, и при этом не воспроизводить лишние, нужна возможность в файле оставить пометки сколько видео надо пропустить в начале и конце.
Причем такая функциональность должна поддерживаться форматом файла-контейнера, FFmpeg, большинством плееров и пр. Последний раз когда я пытался копировать отрезки из видео где-то лет пять назад, я ничего похожего не нашел.
Начало, а в некоторых случаях даже конец видеоряда нельзя обрезать в произвольном месте, так что Handbrake скорее всего реализовали более общий случай и не стали заморачиваться с частными.
для кодировщиков на базе QSV (Intel Quick Sync Video) метод управления битретом по умолчанию изменён с VBR (переменный битрейт) на CQP (постоянный битрейт)
CQP это постоянное качество (Constant Quantization Parameter), в зависимости от кодируемого видео это может ещё более переменный битрейт, чем VBR.
Проблема с наименованием тут в том, что логика прослеживается если знать историю появления этих типов и особенности принятия решений комитетом. Без этого контекста набор из этих трех типов выглядит как WTF.
Помимо SSO, там еще есть поддержка специализаций const/&/&&. В целом std::copyable_function -- это исправленный std::function. В определенной мере было бы даже логичнее назвать новый тип std::function2 и не морочить людям голову.
Или как минимум сразу же задепрекейтить старый std::function, но судя по std::thread и std::jthread этого не будет.
То, что он пока еще непринятый -- это софистика. std::jthread приняли, оставив std::thread как есть, и этот примут.
Если бы были только типы std::copyable_function и std::move_only_function, то все было бы в порядке. Но получается так, что в стандартной библиотеке на равных правах сосуществуют три типа:
std::function
std::copyable_function
std::move_only_function
И вот тут уже названия становятся понятными только тем, кто знает историю их появления и/или ход мыслей комитета.
в отличие от С++, где shared ptr передаёт семантику, в расте название это аббревиатура от реализации
После того, как в C++ получилось, что между std::function и std::copyable_function разница совсем не в том, что один тип копируемый, а другой -- нет, я как-то перестал пинать другие языки за неочевидные наименования.
Это удобно, когда в shared_ptr заворачивается какой-то посторонний ресурс: указатель из мира C, хендлер со своей логикой, токен какой-нибудь который надо вернуть в пул и т. п.
Можно сделать обертку с необходимым действием в деструкторе, но это нудно и неудобно по очевидным причинам. Или можно просто при оборачивании ресурса в умный указатель лаконично указать что надо сделать, когда указатель все.
Этот комментарий и ещё один выше от того же автора как будто сгенерированы нейросетью, которой дали задание написать оправдание/объяснение почему нейросеть может не справиться с задачей.
Проблемы с контекстом: В задаче описывается определенный контекст, включая цвета, национальности, питомцев, напитки и курение.
Совершенно очевидно, что все эти цвета и национальности не играют никакой роли и добавлены просто чтобы человеку было проще запомнить условия.
Логические задачи могут быть подвержены различным толкованиям и иметь несколько верных решений. <...> Однако, ваше видение и интерпретация задачи являются допустимыми и могут привести к другому верному ответу. Это связано с тем, что некоторые аспекты условий задачи могут быть неоднозначны или подвержены субъективному толкованию.
В данной задаче нет неоднозначностей и возможности различного и уж тем более субъективного толкования.
Ну и в целом текст написан в стиле, характерном для ИИ.
Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
в андроиде есть графика, андроид открыт, почему не использовать их решение для графики, зачем wayland?
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Вот не надо пытаться "поддерживать темы и стилизацию конкретного DE". <...> Ну а общий стиль декораций - это именно атавизм <...> одинаковые они не потому, что кто-то так захотел, а потому что декоратору проще рисовать всегда одинаково
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
декорации окна под голым вейландом делаются примерно настолько же просто как и обычная кнопка <...> проблем у бестулкитных программ в мире CSD вообще нет
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
И SSD эту проблему не решает вообще никак, даже частично.
SSD решает эту проблему целиком и полностью. Просто по построению.
если разработчик "ожидает по умолчанию" - это проблема разработчика, он, видимо, не до конца понимает, под какую среду он пишет
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.
Пластины винчестера вращаются независимо от того, перезаписывается он, просто читается или вовсе бездействует (если бездействует долго, то можно остановить, но это отдельная история со своими нюансами).
Так что как минимум подшипникам все равно как часто будут перезаписаны данные.
В наше-то время предлагать выполнять автоматически скачиваемый неизвестно откуда бинарник >___<.
Если решать недостаток новых рабочих рук исключительно автоматизацией, можно пройти точку невозврата в отдельно взятом социуме.
Одна фабрика на всю планету это как минимум ненадёжно.
Есть карты с шестизначным пином =).
Если начинающие программисты будут думать что массивы в C++ это std::array и std::vector, а T[] это такая штука из далекого прошлого примерно как register или std::auto_ptr, то всем будет только лучше.
FFmpeg тоже нельзя. Либо вы не замечаете погрешности, либо граница удачно попадает на опорный кадр.
Проблема в том, что практически в любом видео для декодирования кадра нужен как минимум предыдущий опорный кадр, а в некоторых случаях еще и следующий. Чтобы и включить нужные кадры в файл, и при этом не воспроизводить лишние, нужна возможность в файле оставить пометки сколько видео надо пропустить в начале и конце.
Причем такая функциональность должна поддерживаться форматом файла-контейнера, FFmpeg, большинством плееров и пр. Последний раз когда я пытался копировать отрезки из видео где-то лет пять назад, я ничего похожего не нашел.
Начало, а в некоторых случаях даже конец видеоряда нельзя обрезать в произвольном месте, так что Handbrake скорее всего реализовали более общий случай и не стали заморачиваться с частными.
CQP это постоянное качество (Constant Quantization Parameter), в зависимости от кодируемого видео это может ещё более переменный битрейт, чем VBR.
Проблема с наименованием тут в том, что логика прослеживается если знать историю появления этих типов и особенности принятия решений комитетом. Без этого контекста набор из этих трех типов выглядит как WTF.
Помимо SSO, там еще есть поддержка специализаций const/&/&&. В целом
std::copyable_function-- это исправленныйstd::function. В определенной мере было бы даже логичнее назвать новый типstd::function2и не морочить людям голову.Или как минимум сразу же задепрекейтить старый
std::function, но судя поstd::threadиstd::jthreadэтого не будет.То, что он пока еще непринятый -- это софистика.
std::jthreadприняли, оставивstd::threadкак есть, и этот примут.Если бы были только типы
std::copyable_functionиstd::move_only_function, то все было бы в порядке. Но получается так, что в стандартной библиотеке на равных правах сосуществуют три типа:std::functionstd::copyable_functionstd::move_only_functionИ вот тут уже названия становятся понятными только тем, кто знает историю их появления и/или ход мыслей комитета.
Что, думаете одумаются и таки назовут
std::function2?Ничего не знаю, у нас в 2026 все есть.
После того, как в C++ получилось, что между
std::functionиstd::copyable_functionразница совсем не в том, что один тип копируемый, а другой -- нет, я как-то перестал пинать другие языки за неочевидные наименования.Это удобно, когда в shared_ptr заворачивается какой-то посторонний ресурс: указатель из мира C, хендлер со своей логикой, токен какой-нибудь который надо вернуть в пул и т. п.
Можно сделать обертку с необходимым действием в деструкторе, но это нудно и неудобно по очевидным причинам. Или можно просто при оборачивании ресурса в умный указатель лаконично указать что надо сделать, когда указатель все.
Этот комментарий и ещё один выше от того же автора как будто сгенерированы нейросетью, которой дали задание написать оправдание/объяснение почему нейросеть может не справиться с задачей.
Совершенно очевидно, что все эти цвета и национальности не играют никакой роли и добавлены просто чтобы человеку было проще запомнить условия.
В данной задаче нет неоднозначностей и возможности различного и уж тем более субъективного толкования.
Ну и в целом текст написан в стиле, характерном для ИИ.
Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Учитывая что почти все сейчас рисуется GPU, проброс X в общем виде деградирует до RDP/VNC.
Я вообще не понимаю о чем Вы.
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
SSD решает эту проблему целиком и полностью. Просто по построению.
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.