|
|
|
4.111, Аноним (3), 18:18, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> То есть декодер сделали раньше кодировщика?
Есть по меньшей мере 3 кодировщика помимо сабжа (больше) и 3 декодировщика. Dav1d только декодировщик, работает быстрее libaom (референсной реализации). Спеки открыты, каждый пилит как хочет.
| |
|
|
|
1.2, Аноним (3), 22:08, 09/11/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +5 +/– |
А чё с аналогичными кодировщиками не сравнили? Ну, x265 там хотя бы, и libaom или как там его. Зачем сравнивать несравниваемое?
| |
|
|
3.7, Аноним (3), 22:32, 09/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Сабж не ограничен? Я так картиночки сохранял, емнип пришлось взять tga вместо tiff. Не встречал больше 10 на практике, но 12 вроде уже в ходу (для сравнения, у мониторов ограничение 10 с хаками было, не в курсе как сейчас).
| |
|
|
|
|
3.8, IRASoldier_registered (ok), 22:33, 09/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +4 +/– |
Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п. Слишком частые релизы для того, чтобы можно было в спокойный, неторопливый продакшен.
| |
|
4.23, Ordu (ok), 00:02, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +7 +/– |
> Rust'у, имхо, пока не хватает чего-то типа LTS. Наподобие стандартов C++98, C++11, С++17 и т.п.
Есть такое. Rust 2015 и Rust 2018. Ты можешь взять распоследний rustc и сказать ему, что тебя интересует rust 2015, и будет тебе rust 2015.
Впрочем они сломали rust 2018 в последней версии раста, переведя из разряда варнингов в разряд еггогов ругань нового борроу-чекера. Но они предупреждали заранее и эти варнинги довольно долго мозолили глаза, было время всё исправить.
Они так же планируют сломать rust 2015, через некоторое время, сейчас там пока продолжают быть варнинги.
Но это, по-моему, единственное что они ломали. Дело не в стабильности языка, дело в стабильности библиотек. Есть всякие там std, tokio и ряд других, которые достаточно стабильны, но их не так уж и много. Но для того, чтобы набрать достаточное количество и разнообразие стабильных библиотек расту потребуется ещё не меньше пяти лет, а может и лет десять. Это не быстро, потому что такое количество кода требует очень много человекочасов.
| |
|
5.95, Аноним (95), 14:40, 11/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
- Вот смешные пошли программисты...
"Дело не в стабильности языка"
(Или это только растаманы? Впрочем, само это название тут: пожалуй - намекает)
| |
|
6.117, Аноним (117), 21:27, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Проблем со стабильностью языка не должно вроде быть пока все обратно совместимо, разве нет? Комментарий выше говорит про некоторые примеры когда обратная совместимость в последнее время ломалась, но вроде в целом выглядит все не так страшно, если честно. Насколько я понимаю они там говорят что обратная совместимость у вас сломается только если у вас уже баг в коде.
| |
|
|
6.127, Ordu (ok), 03:02, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Это не просто варнинги, это баги старого чекера. Так что это не
> прихоть
Я не говорю, что это прихоть, или что так не надо было делать. Но в контексте разговора о стабильности языка, это явное указание на его нестабильность, вне зависимости от причин её.
| |
|
|
|
|
4.16, анонн (ok), 23:00, 09/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +6 +/– |
> Только вот перформанс сильно хуже C, а UB просто не называют UB.
Ну раз аноним так говорит, то так оно и есть.
| |
|
|
6.33, burjui (ok), 03:37, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
Никак, для этого есть:
https://docs.rs/parking_lot/0.9.0/parking_lot/type.ReentrantMutex.html
Любой желающий может написать RFC, чтобы включили в std, а пока разработчики решают более важные проблемы, т.к. язык ещё относительно молод.
Только, ради всего святого, не надо гундеть про 3rd party (это я не лично вам, а всем "критикам"). parking_lot - стандарт де-факто в Rust.
| |
|
5.44, asdasd (?), 12:31, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –2 +/– |
В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения / уменьшения счетчика атомарные, что ни разу не быстро.
| |
|
6.52, Аноним84701 (ok), 14:21, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
> В Rust как минимум выделение памяти через подсчет ссылок, а операции увеличения
> / уменьшения счетчика атомарные, что ни разу не быстро.
Хм, т.е. на самом деле "занятия любовью" с владениями/заимствованиями -- это чисто из любви к мазохизму, а не потому что при этом компилятор может отслеживать владельца (ссылки) и автоматически вставлять освобождалку памяти при выходе владельца за пределы области видимости?
| |
|
7.96, Аноним (95), 14:49, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Ага... Проверка индексов массивов в runtime, и всё прочее
- типа бесплатно?...
Так что ничего не удивительно что:
цитата:"из-за усложнения алгоритмов требует существенно больше времени для кодирования (по скорости кодирования libaom отстаёт от libvpx-vp9 в (!)сотни раз, а от x264 в (!)тысячи раз)"
Т.к."усложнения алгоритмов" - без публичного сравнения по скорости с полноценно оптимизированным вариантом на Си(+SIMD+Asm) это деза, как причина таких убер-тормозов.
| |
|
|
|
4.47, Аноним (47), 13:12, 10/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
В некоторых кейсах Rust быстрее. Например проблема алиасинга разрешается на этапе компиляции, а не в рантайме. Возможности статического анализа у Rust значительно шире. Это позволит в будущем автоматически применять более глубокие и сложные алгоритмические оптимизации. C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста. И это часто ведет к значительному усложнению кода, снижению читаемости. Но обычно разработчик просто забивает, т.к. это требует анализа и потерь времени.
| |
|
5.63, Аноним (63), 16:43, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +5 +/– |
> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.
Вот только пока код писался на сях, программисты не забывали про оптимизацию, а с появлением всяких растов и прочих питонов решили, что оптимизацией теперь должен заниматься кто угодно, только не они. В итоге мы имеем калькуляторы, требующие гиг оперативки ("Не, ну а чо, она же дИшОвая").
| |
|
|
7.66, Аноним (66), 17:03, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
>>> C/С++ - это не про "что делать", а про то "как делать". Оптимизации ложатся на плечи программиста.
>> Вот только пока код писался на сях, программисты не забывали про оптимизацию,
> Угу, а тож никто не помнит и ни разу не видел шЫдевры
> "оптимизации":
> while(n>0) { n= read(fd, buf + pos, 1); size++; buf = realloc(buf,
> size); }
[CODE]
while(n>0) {
n= read(fd, buf + pos, 1);
size++;
old_buf = buf;
buf = realloc(buf, size);
assert (old_buf == buf);
old_buf = buf;
}
[/CODE]
Простите за мой французский.
| |
|
|
|
|
5.97, Аноним (95), 15:00, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
> Кто сказал, что хуже?
Я сказал.
Тут же выше: https://www.opennet.ru/opennews/art.shtml?num=51837#96
"... Проверка индексов массивов в runtime, и всё прочее - типа бесплатно?... ..."
P.S.
А, бенчмаркам верят только те - кому выгодно верить в *конкретный* бенчмарк...
Сколько было уже таких людей несосчитать... то C# такой же по скорости, то ранее - Джаба с JITом;
а, по факту - выше головы никому не прыгнуть.
| |
|
|
3.26, Аноним (26), 01:11, 10/11/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| –3 +/– |
Если -20-60% условной производительности(и это без компиляторной магии си) это "не уступает", то можете использовать, только про си не упоминайте, уместнее тогда сравнивать с го и джава.
| |
|
2.19, Аноним (19), 23:34, 09/11/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
Стоит. Заметил, что я стал в своих программах на полноценном ООП отказываться от наследования в пользу композиции. Правда можно было бы и сделать нормальное наследование через композицию, но таких ЯП я не знаю.
| |
|
3.29, Crazy Alex (ok), 02:19, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Ну и при чём тут Rust? Это отнюдь не вчера появившаяся идея. Я её у Саттера, кажется, первый раз встретил, а судя по википедии - она была ещё в книжке Банды Четырёх от 95-го года, и это много лет как совершенно базовый принцип, где-то рядом с single responsibility.
| |
|
4.81, a3k (?), 20:17, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Это как-то само доходит после опыта поддержки хоть немного большого ООП-кода с изменяющимися требованиями.
| |
|
|
|
|
4.46, JL2001 (ok), 12:49, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Ассемблер быстрее. Учите лучше его.
он не оптимизируется автоматически, непереносим, долог в написании и рефакторинге, порождает множество ошибок в силу ограниченности человеческого разума и больших размеров программ
| |
4.51, Аноним (66), 14:15, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> Ассемблер быстрее. Учите лучше его.
Лучше так не шутите, ведь подобные утверждения начинают повсюду копировать. Человек может написать боле быстрый код чем оптимизатор, но далеко не каждый.
| |
|
|
6.128, Аноним (66), 10:12, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Впрочем, речь то была про ассемблер и забытость его критичной важности.
Напомню: "Ассемблер быстрее". В то время как это лишь мнемоническая запись машинного кода. Надо ли понимать, как работает железо? Для определённых категорий это, безусловно, необходимый навык. Именно понимание даёт возможность написать "быстрее", но никак не ассемблер.
| |
|
|
|
|
4.78, Аноним (78), 18:28, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Ты эту ссылку из новости в новость тягаешь, не надоело еще? "Мы написали говнокод, хахаха, он работает неочевидным образом". Да подобным примерам на питоне и js целые сайты посвящены.
| |
|
|
2.67, Wilem (?), 17:18, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
Подобные вопросы лучше задавать гуглу. Если ты это делаешь на опеннете то ты либо тут первый раз, либо наслаждаешься неминуемым срачем (что не плохо, в общем-то - весело). Практической пользы немного, тк мало экспертов, в основном тут просто любители линукса.
| |
|
|
|
3.125, Аноним (122), 02:57, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Хмм, а чего тогда не на сишке то написали оптимизированные оптимизации, зачем было тратить время на асм? Раст же виноват
| |
|
4.155, Аноним (144), 21:06, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
А, кто же ещё. Ну не помянутый же Си...
Оптимизация - должна быть комплексно...
А, выросшим на Rust - откуда уметь даже просто ассемблерные оптимизации полноценно - пиши не пиши теперь на ассемблере..., и основной то код на Rust - никто не отменял.
Не отмажитесь - тут уже таки: «Раст виноват».
| |
|
|
|
|
2.15, анонн (ok), 22:58, 09/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
> Основная половина кодировщика написана на ассемблере. Смените название поста ;)
Основная половина mem/strcpy/strstr в glibc написана на асм, смените название либы
| |
2.34, burjui (ok), 03:57, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
Только подавляющая часть ассемблера - в директориях x86 и arm, что достаточно прозрачно намекает на то, что на ассемблере написаны специально оптимизированные версии алгоритмов и функций, а не основное мясо кодировщика.
| |
|
3.38, Аноним (66), 06:16, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –4 +/– |
Названия каталогов явно говорят о том, что в них содержится оптимизация под конкретные архитектуры. Что именно там оптимизировано и где (и что) мясо -- непонятно как из тех названий следует (а изучение содержимого каталогов и файлов -- это задача как раз делавшего исходное утверждение).
| |
|
|
|
2.99, Аноним (27), 15:24, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
короче, проверил
при аналогичном качестве видео занимает в ~8 раз меньше места на диске по сравнению с hevc
но есть недостатки:
1) работает слишком медленно, почему-то использует только одно ядро процессора, несмотря на опции
2) принимает на вход только в y4m формате, который занимает слишком много места на винте
| |
|
3.107, Аноним (107), 16:45, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
2) принимает на вход только в y4m формате, который занимает слишком много места на винте
это референсный инкодер (commandline), подразумевается что либу запилят во что-то типа fmpeg (я надеюсь C биндинги будут), поэтому это вообще ни разу не недостаток.
про первое - оч странно, какие опции использовали. Надо бы баг им запилить) должно все использовать.
| |
|
|
1.36, Аноним (-), 06:02, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| –6 +/– |
>Код проекта распространяется под лицензией BSD.
Вот такое вот БЗДунство растаманов меня сильно огорчает. Ибо ничего лучше GPL v3+ нети никогда не будет.
| |
|
|
3.48, Аноним (48), 13:34, 10/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –2 +/– |
Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
| |
|
4.58, Аноним (-), 15:56, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>Один форкнет, измажет в гпл, а потом прибежит толпа боевых гплерастов и будет указывать на нарушения копилефт и копирайт
Не прибежит. Проприетарщики выбирают БЗДу. А с БЗДы на ГПЛ в можно. С БЗДы в любое направление можно.
| |
|
5.93, КО (?), 10:19, 11/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>А с БЗДы на ГПЛ в можно
Не совсем, в BSD есть одно требование, на которое в GPL кладут болт.
| |
|
|
7.130, Аноним (-), 10:36, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
У противника Свободы бомбануло. Ничо FSF будет давить проприетарщиков и колаборантов-БЗДунов революционными методами.
| |
|
|
|
|
3.57, Аноним (-), 15:50, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>Ну так форкни и перелицензируй под GPL, вы же так постоянно делаете.
Расскажи это пацыкам, которые переписали утилиту ls. Вместе посмеёмся.
| |
|
2.60, Аноним (41), 16:02, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> GPL v3+
Я правильно понимаю, что ты, придя, скажем, в банк, подписываешь абсолютно чистые листы А4, а уже потом банк печатает на эти листы абсолютно любые условия? Потому что "+" в GPLv3+ именно то и означает, что ты передал столлману пачку листов А4 со своей подписью внизу. Ну а он в них может вписать любой свой маразматический бред.
| |
|
1.50, Простой парень (?), 14:00, 10/11/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –1 +/– |
Проблема не в том, какой язык лучше, а в том, какое место он может занять. Вот смотрите: приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере. Чёткая иерархия, каждому языку есть место, согласно тому, какие задачи на нём проще решать. Проблема в том, что это складывается стихийно, а не предсказуемым образом. Разработчики языка исходят из того, что они могут сделать, какие у них есть идеи, а не из того, какие задачи стоят перед современным языком. Вот раст пока не нашёл свою нишу, но то что развитие с++ зашло в тупик, подталкивает разработчиков испытывать новые языки у себя в проектах, и только поэтому раст держится.
| |
|
|
3.82, Простой парень (?), 20:40, 10/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
>>развитие с++ зашло в тупик
> и в чём это проявляется?
map, unordered_map - этого мало? А то что конструктора для std::string из форматированной строки до сих пор нет, это что? Эти все конференции где тучи высоколобых с упорством достойным лучшего применения спорят о какой то никому кроме них не нужной сpaни, мало?
| |
3.163, Lex (??), 23:53, 12/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
С каждыми "новыми плюшками", синтаксис плюсОв становится всё монструозней и уродливей.
Хотя, и с джавой примерно аналогично.
| |
|
2.89, nelson (??), 23:39, 10/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +3 +/– |
> приложение пишется на питоне, интерпретатор питона на си, а среда выполнения си на ассемблере
Среда выполнения си на ассемблере, говорите? Правду говорят, что обучение программированию питоном до добра не доводит )
| |
|
|
2.86, Ordu (ok), 23:01, 10/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
#[no_mangle]
fn print_int(i: i32) {
println!("{}", i);
}
Такое вполне можно вызывать из C. Но если ты заботишься о кроссплатформенности кода, то вместо i32 тебе лучше использовать std::os::raw::c_int.
| |
|
1.116, Аноним (87), 20:58, 11/11/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
Что-то ебилдов не видно — ни в портеже, ни в оверлеях, ни на багтрекере нет. Деплой зоопарка растолиб оказался гентушникам не под силу?
| |
|
|
3.129, Аноним (-), 10:31, 12/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –1 +/– |
>Какой такой зоопарк? В расте статическую линковку делают обычно,.
Поэтому helloworl! на Расте весит 5 Мегабайт?
| |
|
4.134, анонн (ok), 13:03, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Поэтому helloworl! на Расте весит 5 Мегабайт?
Странно.
% rustc -V
rustc 1.38.0
% cat hello.rs
fn main() {
println!("Hello World!");
}
% rustc hello.rs
% ll hello
-rwxr-x--- 1 анонн wheel 286K 12 Nov. 16:59 hello
% readelf -d hello|grep NEED
0x0000000000000001 NEEDED Shared library: [libthr.so.3]
0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1]
0x0000000000000001 NEEDED Shared library: [libc.so.7]
% strip hello
% ll hello
-rwxr-x--- 1 анонн wheel 215K 12 Nov. 16:59 hello
% rustc hello.rs -O -C lto
% strip hello
% ll hello
-rwxr-x--- 1 анонн wheel 189K 12 Nov. 17:00 hello
Попробуйте собирать не из под Виндовс.
| |
|
5.140, Anonymoustus (ok), 16:19, 12/11/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
>> Поэтому helloworl! на Расте весит 5 Мегабайт?
> % ll hello
> -rwxr-x--- 1 анонн wheel 189K 12 Nov. 17:00
> hello
>
> Попробуйте собирать не из под Виндовс.
Всё равно же много.
У меня в Виндовс хелловорлд на Сишечке, собранный посредством TCC (Tiny C Compiler by Fabrice Bellard), весит 2048 байт. TCC, конечно, не мейнстрим вроде GCC, но пусть будет убойным примером ради высшей справедливости.
Если собирать обычным GCC (была использована версия 4.7.2), то получается 34816 байт статически слинкованного сабжа.
| |
|
|
3.133, Аноним (87), 11:56, 12/11/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Дикий зоопарк совершенно, который при запуске сборки начинает качаться с репозиториев на жидхабе неконтролируемым образом. Для сборки сабжа нужно скачать 138 (!) пакетов с библиотеками, все из которых для включения в Gentoo нужно оформить в виде ебилдов. Это уже привязка к облаку какая-то пошла, в оффлайне build-система раста растеряется и ничего не сможет сделать.
Статическая линковка помогает только в случае распространения бинария от разработчика к пользователю. В большинстве дистрибутивов unix-подобных ОС принята другая модель, в которой от разработчика берутся только исходники и далее подготавливаются мэйнтейнерами для автономной сборки на build-фермах. Сабж довольно сложно деплоить таким образом.
| |
|
4.137, Аноним (-), 15:37, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Слыхал поговорку: "Linux писан сишными прогоаммистами, и для сишных программистов Linux".
UNIX - BSD - Linux - это множество кусков сишного кода. При всём уважении к языку Rust, но всё же этот язык является чужеродным элементом в Unix-подобных системах.
| |
|
5.154, Аноним (87), 21:05, 12/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Проблема не в языке, а в том, что используемая сабжем build-система, cargo, включает в себя средство установки компонентов из удалённого репозитория, что в UNIX-подобных ОС является прерогативой исключительно пакетного менеджера. В экосистеме UNIX отлично живут программы на любых языках, где build-системе достаточно скормить каталог с исходниками и она его автономно и предсказуемо соберёт, но ситуация, когда эта build-система при сборке внезапно (в man cargo-build нигде не сказано о возможной сетевой активности, а также нет опции для её отключения) начинает самостоятельно ломиться во внешний мир и что-то непонятное из него тащить, абсолютно недопустима.
| |
|
|
7.183, Аноним (87), 18:54, 15/11/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> как будто в неюниксоподобных это не так
Там обычно нет пакетного менеджера с исключительной прерогативой установки компонентов из внешнего мира. Вместо этого программы поставляются в виде отдельного инсталлятора, который всё чаще самой программы не содержит, а лезет за ней в веб. Вероятно, по образу и подобию этих инсталляторов и сделан вышеупомянутый cargo.
> Вермишель из pkg-config, модных систем сборок на нескучных язычках с зависимостями всего от всего, и каких нибудь авторских соплей сверху фэйлится на любом чуть отличающемся от совсем дубового раскладе.
Как же тогда софт собирается в nixos и guixsd, где /usr и /lib вообще отсутствуют?
> афтыри раньше программировали на nodejs
Похоже на то: js-макакам вообще никакие правила не писаны.
| |
|
|
|
|
|
|
1.161, Аноним (161), 23:02, 12/11/2019 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– |
Ну, hevc не такой уж медленный. У меня на Pentium 4 он кодит 576p с пресетом fast аж целый 1 fps. Мне не проблема подождать пару часов, чтобы закодить 6-минутный ролик. Другое дело, что декод 576p 1500k в realtime уже не тянет. Результат не посмотреть, только для других делать. Меньшие разрешения идут.
| |
|