Я понимаю вашу логику, но, по-моему, странно игнорировать то, что на компьютер пользователю приходят уже пожатое видео. Если бы пользователю приходило lossless - то никто бы, наверное, с обходом DRM даже не заморачивался, потому что можно было бы эффективно записывать с экрана в любом удобном качестве и кодеке. Без взломанного DRM имеем либо заметное ухудшение картинки, либо большой размер файла - довольно актуально для 4к-контента.
Возможно, в случае с Kotlin - это интеграция с JVM-экосистемой, в частности - с бигдатой и Андроидом. Там пока все еще не идеально, но Kotlin (потенциально) можно и к спаракам-хадупам-флинкам-кафкам приделывать, и на мобилках использовать (уже давно), без необходимости как-то туда портировать Python-код.
В принципе, сюда немного метит Kotlin. Его сейчас куда только не пытаются впихнуть - в том числе и в DL (https://github.com/JetBrains/KotlinDL), причем не силами пары энтузиастов, а с поддержкой со стороны компаний. В принципе, уже сейчас можно запустить Jupyter с Kotlin-ноутбуком и делать там model.fit() и model.predict(). По части типов, это, конечно, не Хаскель, но уж точно лучше, чем python.
Почему одинарное? Сначала перекодирование из исходника в lossy-формат на стороне сервиса, затем из lossy в lossy при записи экрана. Или вы перекодированием только lossy->lossy транскодинг называете?
К слову, "Native" еще не означает, что при запуске на Linux у игры не будет проблем. Буквально неделю назад я не смог запустить "Native"-порт Plannetary Annihilation: Titans - пришлось запускать на Windows. Разного рода проблемы/баги, конечно, у всех игр бывают - но тем не менее, "Native" не совсем честно считать эквивалентом "Platinum" в смысле "Запускается без ошибок".
Ну и да, в реальности я связных списокв не видел ни разу в итоге — везде их выпиливали в пользу какого-нибудь вектора или кольцевого буффера.
Это про Раст речь или про C? Я иногда краем глаза смотрю, что там в исходниках десктопных линуксов, и, по-моему, если проект на С написан - то там связные списки оказываются с завидной регулярностью.
Да, все так. Я просто хотел отметить, что pinephone - это не "имиджево-маркетинговый" товар, с которого Pine64 не имеют прибыли и торгуют в ноль/минус (как ресторан в Икее), и даже не работающий в убыток стартап с целью продаться гуглу, а настоящее железное направление, в которое они вкладывают деньги и рассматривают как источник прибыли.
> Does Pine64 make money off the Pinephone/Pro orders? > Yes, after the Community Editions ended, we have been making money of the PinePhone - which was funneled into creating the PinePhone Pro. Information regarding the PinePhone Pro and our future initiative to support mobile Linux development will be made at a later date.
Теория вероятности и статистики работает только с полностью случайными процессами.
А как определить что являющийся набор данных не содержит закономерностей
Хм, вроде бы была область математики, которая, среди прочего, занимается поиском закономерностей в данных. Стар.. Став.. Статис.. Не напомните название? Точно не статистика, она только полностью случайными процессами занимается.
GraalVM/Polyglot как-то справляется. Там, вроде бы, один GC и JIT на все рантаймы - js, java, ruby. Я бы сказал, что это даже более красивое решение, чем то, что в Хромиуме сделали.
в чём разница между gc, который тормознул мой ввод буковки в поле ввода и тормознутой транзацией
Просто для контекста - в браузерах ужедавноесть как минимум 1 gc - в js-движке. Более того, в Хромиуме для управления некоторой памятью в C++ тоже GC используется (интересно, кстати, было бы его сравнить с G1 или ZGC - jvm позволяет использовать намного более интересные GC по сравнению с C++). Я бы не связывал отсутствие браузеров на джаве только с GC.
Оффтоп - фоллбек-гифки в h264 лучше делать h264/yuv420p, а не h264/yuv444. h264/yuv444 каким-то рандомным образом не поддерживается (у меня только десктопный Brave ее смог осилить - в Firefox не работает, на android-телефоне ни Chrome, ни Firefox не справились, вот тут чуть больше проверили - https://bugzilla.mozilla.org/show_bug.cgi?id=1368063#c16).
Учитывая, что речь про Хром - там вообще аудитория под 3 миллиарда, т.е. почти миллион человек хотя бы раз в месяц что-то скачивали по ФТП. Тем не менее, не вижу здесь причины для лишней драматизации: скачать FTP клиент - это два клика, людям же не браузер использовать запрещают. Выкинуть кусок легаси кода и потенциально доставить неудобства 0.03% пользователей - вполне прагматичное решение, не смотря на абсолютную цифру в миллион человек.
Не то, чтобы в Chrome была какая-то образцовая поддержка FTP - FTPS не работало, прокси не работали. Особой популярностью ftp не пользовался (0.03% пользователей за месяц там что-то по FTP скачивали). Собственно, я не вижу ни одной причины, по которой непопулярную, недоделанную, потенциально несекьюрную фичу, которая не пользуется популярностью, нужно держать и поддерживать в браузере, а не делегировать специализированной программе.
Я бы даже сказал, что параллель с аггресивным внедрением HTTPS на замену HTTP тут немного ложная. Мне кажется, что в случае с HTTPS - это мотивация вида "основной протокол, который используется в вебе, должен быть безопасен по-умолчанию", а с FTP - "FTP в его текущем виде не место в браузере, пользуейтесь специализированным ПО".
Хотел тоже поругать статью за неграмотную картинку, но вы уже это сделали за меня) Всем сомневающимся - советую очень наглядную демонстрацию в видео (https://wiki.xiph.org/Videos/Digital_Show_and_Tell, есть текстовая расшифровка)
Не "жизненно необходима", но очень сильно повышает комфорт. Программисту, вообще говоря, и монитор большой не супер-важен, и CPU быстрый не всегда нужен, а вместо удобного кресла можно обойтись табуреткой. По-моему, по уровню получаемых плюсов, вложиться (временем) в быструю слепую печать - это примерно как вложиться (деньгами) в удобное оборудование.
Я понимаю вашу логику, но, по-моему, странно игнорировать то, что на компьютер пользователю приходят уже пожатое видео. Если бы пользователю приходило lossless - то никто бы, наверное, с обходом DRM даже не заморачивался, потому что можно было бы эффективно записывать с экрана в любом удобном качестве и кодеке. Без взломанного DRM имеем либо заметное ухудшение картинки, либо большой размер файла - довольно актуально для 4к-контента.
Возможно, в случае с Kotlin - это интеграция с JVM-экосистемой, в частности - с бигдатой и Андроидом. Там пока все еще не идеально, но Kotlin (потенциально) можно и к спаракам-хадупам-флинкам-кафкам приделывать, и на мобилках использовать (уже давно), без необходимости как-то туда портировать Python-код.
В принципе, сюда немного метит Kotlin. Его сейчас куда только не пытаются впихнуть - в том числе и в DL (https://github.com/JetBrains/KotlinDL), причем не силами пары энтузиастов, а с поддержкой со стороны компаний. В принципе, уже сейчас можно запустить Jupyter с Kotlin-ноутбуком и делать там model.fit() и model.predict(). По части типов, это, конечно, не Хаскель, но уж точно лучше, чем python.
Почему одинарное? Сначала перекодирование из исходника в lossy-формат на стороне сервиса, затем из lossy в lossy при записи экрана. Или вы перекодированием только lossy->lossy транскодинг называете?
Главное, чтобы не задушили такие VPN как VKO, DME, SVO, LED... Уже давно собираюсь ими воспользоваться, но в этом году короновирус помешал.
К слову, "Native" еще не означает, что при запуске на Linux у игры не будет проблем. Буквально неделю назад я не смог запустить "Native"-порт Plannetary Annihilation: Titans - пришлось запускать на Windows. Разного рода проблемы/баги, конечно, у всех игр бывают - но тем не менее, "Native" не совсем честно считать эквивалентом "Platinum" в смысле "Запускается без ошибок".
Это про Раст речь или про C? Я иногда краем глаза смотрю, что там в исходниках десктопных линуксов, и, по-моему, если проект на С написан - то там связные списки оказываются с завидной регулярностью.
Примеры - поищите по
wl_listилиwl_list_initв wlroots (https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/), поGListв mutter (https://gitlab.gnome.org/GNOME/mutter), поlist_initв libinput (https://gitlab.freedesktop.org/libinput/libinput/-/tree/main), не говоря уже про тысячи различных списков в ядре линукса (искать, например, поlist_head).Да, все так. Я просто хотел отметить, что pinephone - это не "имиджево-маркетинговый" товар, с которого Pine64 не имеют прибыли и торгуют в ноль/минус (как ресторан в Икее), и даже не работающий в убыток стартап с целью продаться гуглу, а настоящее железное направление, в которое они вкладывают деньги и рассматривают как источник прибыли.
Нет, не в ноль. Они проводили AMA на reddit, и там был про это вопрос (https://www.reddit.com/r/linux/comments/qald3w/comment/hh3qimb):
> Does Pine64 make money off the Pinephone/Pro orders?
> Yes, after the Community Editions ended, we have been making money of the PinePhone - which was funneled into creating the PinePhone Pro. Information regarding the PinePhone Pro and our future initiative to support mobile Linux development will be made at a later date.
Хм, вроде бы была область математики, которая, среди прочего, занимается поиском закономерностей в данных. Стар.. Став.. Статис.. Не напомните название? Точно не статистика, она только полностью случайными процессами занимается.
GraalVM/Polyglot как-то справляется. Там, вроде бы, один GC и JIT на все рантаймы - js, java, ruby. Я бы сказал, что это даже более красивое решение, чем то, что в Хромиуме сделали.
Просто для контекста - в браузерах уже давно есть как минимум 1 gc - в js-движке. Более того, в Хромиуме для управления некоторой памятью в C++ тоже GC используется (интересно, кстати, было бы его сравнить с G1 или ZGC - jvm позволяет использовать намного более интересные GC по сравнению с C++). Я бы не связывал отсутствие браузеров на джаве только с GC.
Я так понимаю, вы хотите lossless-видео записать, и затем сжать гифку в h264?
Тогда во вторую команду будет достаточно добавить -pix_fmt yuv420p:
Оффтоп - фоллбек-гифки в h264 лучше делать h264/yuv420p, а не h264/yuv444. h264/yuv444 каким-то рандомным образом не поддерживается (у меня только десктопный Brave ее смог осилить - в Firefox не работает, на android-телефоне ни Chrome, ни Firefox не справились, вот тут чуть больше проверили - https://bugzilla.mozilla.org/show_bug.cgi?id=1368063#c16).
Учитывая, что речь про Хром - там вообще аудитория под 3 миллиарда, т.е. почти миллион человек хотя бы раз в месяц что-то скачивали по ФТП. Тем не менее, не вижу здесь причины для лишней драматизации: скачать FTP клиент - это два клика, людям же не браузер использовать запрещают. Выкинуть кусок легаси кода и потенциально доставить неудобства 0.03% пользователей - вполне прагматичное решение, не смотря на абсолютную цифру в миллион человек.
Аналогия очень неудачная (как, кстати, и сама статья с новостью - лучше прочитать оригинальный документ - https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit).
Не то, чтобы в Chrome была какая-то образцовая поддержка FTP - FTPS не работало, прокси не работали. Особой популярностью ftp не пользовался (0.03% пользователей за месяц там что-то по FTP скачивали). Собственно, я не вижу ни одной причины, по которой непопулярную, недоделанную, потенциально несекьюрную фичу, которая не пользуется популярностью, нужно держать и поддерживать в браузере, а не делегировать специализированной программе.
Я бы даже сказал, что параллель с аггресивным внедрением HTTPS на замену HTTP тут немного ложная. Мне кажется, что в случае с HTTPS - это мотивация вида "основной протокол, который используется в вебе, должен быть безопасен по-умолчанию", а с FTP - "FTP в его текущем виде не место в браузере, пользуейтесь специализированным ПО".
Я бы дополнил, что самое интересное в tun2socks - он умеет пускать траффик не только через обычные socks5-прокси, но и через shadowsocks (внутри tun2socks используется ядро из go-shadowsocks2 - https://github.com/shadowsocks/go-shadowsocks2) - т.е. вы получаете почти полноценный VPN - весь трафик до прокси будет зашифрован, в отличие от socks5, где нужно полагаться на вышележащие протоколы. Кстати, в следующем релизе shadowsocks-rust (https://github.com/shadowsocks/shadowsocks-rust) будет доступна аналогичная функциональность (см. https://github.com/shadowsocks/shadowsocks-rust#tun-interface-client).
Хотел тоже поругать статью за неграмотную картинку, но вы уже это сделали за меня) Всем сомневающимся - советую очень наглядную демонстрацию в видео (https://wiki.xiph.org/Videos/Digital_Show_and_Tell, есть текстовая расшифровка)
По поводу Hi-Res музыки есть старая, но все еще актуальная статья - https://web.archive.org/web/20180307183656/https://people.xiph.org/~xiphmont/demo/neil-young.html (ссылка на web-archive - на оригинальном сайте ее уже нет) и ее обсуждение на hackernews (https://news.ycombinator.com/item?id=15127633)
Не "жизненно необходима", но очень сильно повышает комфорт. Программисту, вообще говоря, и монитор большой не супер-важен, и CPU быстрый не всегда нужен, а вместо удобного кресла можно обойтись табуреткой. По-моему, по уровню получаемых плюсов, вложиться (временем) в быструю слепую печать - это примерно как вложиться (деньгами) в удобное оборудование.
Скорее всего, у вас работает libva-vdpau-driver. Это довольно ограниченное решение (без дополнительных патчей (https://github.com/xtknight/vdpau-va-driver-vp9) работает только с h264, не работает в хромиуме (тоже есть патчи - https://aur.archlinux.org/packages/libva-vdpau-driver-chromium/), на гибридной графике у меня с ним проблемы), но для каких-то юзкейсов подходит.