| 1.3, Ahulinux (ok), 00:06, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –15 +/– |
 значит до июля уязвимость активно эксплуатировалась. Еще раз становиться очевидно что браузером должен оставаться браузером. Либо в инете надо сидеть с виртуалки.
| | |
| |
| 2.9, Aceler (ok), 08:00, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > значит до июля уязвимость активно эксплуатировалась.
Ага, как только она в октябре в браузере появилась, так сразу до июля и начала.
| | |
| 2.25, iZEN (ok), 14:31, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Либо в инете надо сидеть с виртуалки.
Ага — каждой программе по jail(8). ;)
| | |
|
| 1.5, th3m3 (ok), 02:06, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 А меня и штатная возможность через GStreamer устраивала, отрубил этот кодек из-за ненадобности.
| | |
| 1.6, Аноним (-), 05:30, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>фактически исправления уязвимости были внесены без лишней огласки в кодовую базу
Где ссылка на коммит? "Океания всегда воевала с Остазией".
| | |
| 1.7, vn971 (ok), 06:13, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?
Вы вот прям точно всё равно уверены что CPP безопасен, и для написания кода без "языковых" ошибок достаточно будет вам заплатить побольше? (Извините за передёргивание если что.)
Или может быть ржавчина (rust-lang) всё-таки имеет смысл? И может быть JVM не позволяет такого вида ошибок? (При всей отстойности JVM по ооочень широкому спектру других вещей.)
| | |
| |
| 2.8, vn971 (ok), 06:17, 01/12/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
(Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая психология перед очевидным багом, привязанным к конкретному языку и практически невозможная на rust/jvm.)
| | |
| |
| 3.17, kurokaze (ok), 11:33, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая
> психология перед очевидным багом, привязанным к конкретному языку и практически невозможная
> на rust/jvm.)
Credo, quia absurdum
| | |
|
| 2.10, JSmith (??), 08:28, 01/12/2014 [^] [^^] [^^^] [ответить]
| +3 +/– | |
JVM сам по себе дает массу возможностей отстрелить себе ногу. И для таких низкоуровневых вещей, как видеокодеки - любой managed код это бестолковая трата ресурсов. Зачастую даже для видеокодеков делают оптимизации ассемблерными вставками - там, где это очень критично, не то что cpp.
Управляемый код имеет смысл в уровнях много выше, базовая система обязана быть настолько производительной, насколько это возможно. Для безопасности C++ существуют тонны софта, обеспечивающего анализ кода и его тестирование, - как открытые, так и проприетарные. И конкретно Mozilla Foundation вполне располагает средствами, чтобы купить необходимый для контроля софт и время специалистов-аналитиков.
C++ никогда не был и не будет безопасным языком. Это бред. Но в текущих условиях он обеспечивает хороший баланс скорости и синтаксических/функциональных плюшек.
| | |
| |
| 3.11, freehck (ok), 09:18, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Знаете, эти плюшки скорее время тратят, нежели экономят. Я припоминаю, что неделю отлавливал языковые баги в C++, а потом плюнул и переписал всё за 3 дня на Common Lisp. И получил готовый к работе код.
В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс. Единственный вариант, когда я могу на нём писать быстро - это использовать С++ только возможности языка C плюс одна или две плюшек C++ (Полиморфизм, например, бывает очень кстати). А в общем случае весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и изобилует багами, что печально.
| | |
| |
| 4.18, kurokaze (ok), 11:35, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и
> изобилует багами, что печально.
Ты всё правильно для себя решил. Не получается - не трожь
| | |
| 4.19, F (?), 12:13, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Я про синтаксический сахар в принципе - мне, например, очень нравился когда-то ассемблер, но при всём - более-менее серьезный проект на нем не написать. Макроассемблеры же очень быстро по существу начинают догонять Си (в процессе дописывания макросов) - то есть уход от низкого уровня.
Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных техник и рецептов. Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик. CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык).
С++ достаточно выразительный, чтобы на нем можно было написать что угодно - от ОС до приложений и скриптов.
ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си.
| | |
| |
| 5.36, freehck (ok), 07:57, 02/12/2014 [^] [^^] [^^^] [ответить] | +/– | И это основной минус Масса народа, которая в общем-то не разбирается в языке, и... большой текст свёрнут, показать | | |
|
| 4.33, Аноним (-), 06:04, 02/12/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс.
Пока вы не видите - игроделы на нем здоровенные проекты наворачивают, например. И да, их скорость и предсказуемость поведения - интересует. По этим же причинам на них пишут требовательные к скорости программы, которые на сях уже стало слишком разлаписто писать.
| | |
|
| 3.13, vn971 (ok), 10:01, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Спасибо за ответ.
Если вдуматься, на самом деле, то я ни в одном месте не говорил про то плохой ли язык c++. Я прошу признать одну конкретную проблему.
Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на самом деле и не распологает ими: они сами на каких-то из видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов и прочие именно языковые ловушки. Да и в Яндексе, если верить другой видяшке, тоже допускаются такие ошибки. То есть это уходит в продакшон, потом в конце концов одна из машинок заваливается с ошибкой. Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую версию.. And the circle goes on.
| | |
| |
| 4.22, F (?), 12:30, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>[оверквотинг удален]
> Если вдуматься, на самом деле, то я ни в одном месте не
> говорил про то плохой ли язык c++. Я прошу признать одну
> конкретную проблему.
> Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на
> самом деле и не распологает ими: они сами на каких-то из
> видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов
> и прочие именно языковые ловушки. ... То есть это уходит в
> продакшон, потом в конце концов одна из машинок заваливается с ошибкой.
> Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую
> версию.. And the circle goes on.
Говорят, что подавляющее большинство такого прекрасно ловится статическими анализаторами. Проблема же ошибок кода в целом - это проблема явно не языка программирования, а программиста.
Да, никто не спорит, чем строже язык, тем сложнее в нем начудить. Вопрос цены. В данном случае цена - способность кодека выполнять свою задачу. Т.е. (для кодека) работать за минимальное время. Поэтому управляемый код для кодека H.264 - исключен.
Думаю, даже больше - особо критичные куски кода даже не используют ресурсоемких возможностей С++ (вроде упомянутого тут полиморфизма).
Стоит делать различие между managed и unmanaged/классическим кодом, ок?
Ориентированный на массы софт - тоже понятно, почему в основном не на управляемом коде (JVM/.Net) - охват аудитории зависит и от поддержки старого железа, т.е. низкой ресурсоемкости - что для managed code неверно как в части памяти, так и в части CPU.
Кстати, показательно (сейчас будет флейм) - managed Андроид по отзывчивости явно сливает unmanaged iOS / Symbian при равном железе. И программисты на Андроиде вынуждены пользоваться NDK в тех местах, где производительность критична.
| | |
| |
| 5.23, Crazy Alex (ok), 12:45, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Эм... не то чтобы флейм, но некоторая корректировка. Я бы не называл iOS-код unmanaged. Там вполне приличный подсчет ссылок. Что до отзывчивости андроида - когда гугл таки собрался и сделал AOT в Android 5 жизнь резко улучшилась. Так что дело там скорее в превосходстве заранее скомпилированного кода перед JIT.
| | |
| 5.26, vn971 (ok), 14:46, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
Ещё раз, вы считаете что я говорю что CPP плохой/неподходящий язык?
Я это где-то говорил или имел в виду, по-вашему?
| | |
| 5.27, vn971 (ok), 15:09, 01/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
Иными словами,
я за -- называть плюсы хорошим компромиссом для риал-таймовых задач или тех где высокие требования к ресурсам.
я против -- притворяться что не видишь слона в комнате (небезопасность).
| | |
| |
| 6.28, Аноним (-), 18:22, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> я против -- притворяться что не видишь слона в комнате (небезопасность).
У каждого языка свой небезопасный слон в комнате. У одного это прямой доступ к памяти, у другого динамическая типизация и duck typing, а значит возможность подсовывания объекта другого типа, у третьего injections, у четвертого eval() (частный случай injections), у пятого уязвимости в интерпретаторе или VM, у шестого излишняя зависимость от переменных окружения (частный случай уязвимости в интерпретаторе). NULL/Null/null/nil, опять таки, не только в С/С++ есть.
Уже ж несколько лет назад это обсасывали на форумах.
| | |
| |
| 7.35, Аноним (-), 06:11, 02/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Уже ж несколько лет назад это обсасывали на форумах.
Ну вон в вебе используют пыхи, питоны и прочие. В результате то иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь хрень. И в результате теперь системы в основном ломают через дырявую вебню. Си теперь конечно стал менее виноват, а вот взломов меньше не стало. Даже больше. Да что там, даже целые червяки появились, долбящие вебню на автомате. Не багом - так глупым паролем админа.
| | |
| |
| 8.39, F (?), 21:20, 08/12/2014 [^] [^^] [^^^] [ответить] | +/– | Таки я вас уверяю - в вебе образца 97-98 года когда еще была масса cgi, писаных... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.15, Вася Пупкин (?), 11:25, 01/12/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Блин, ну что ж вам свербит-то так? Да пишите на чём хотите, и другим не мешайте. Сколько можно уже по кругу всё это обсуждать..
| | |
| 2.16, kurokaze (ok), 11:31, 01/12/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?
Толстота.
Вообразил себе оппонентов, вложил им в уста воображаемые аргументы и начал героически их развенчивать, PROFIT!
Взрослеть то собираешься?
>И может быть JVM не позволяет такого вида ошибок?
JVM написана на плюсах, конец религии
| | |
| 2.34, Аноним (-), 06:08, 02/12/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Вы вот прям точно всё равно уверены что CPP безопасен,
Чего бы это вдруг? Си++ позволяет себе прострелить пятки при желании. Единственная проблема - языки которые делают добавочные проверки на видеокодеке провалятся по производительности. Раза так в три. И юзеры, особенно с слабыми компьютерами, обложат такой кодек матом. Особенно при попытках посмотреть что-нибудь в разрешении поболее почтовой марки.
> (При всей отстoйности JVM по ооочень широкому спектру других вещей.)
Вы, конечно, извините, но кому и зачем надо кодек, тормозящий в 3 раза сильнее и икающий в моменты когда GC приспичило собрать мусор? Это сойдет как PoC, показать "ява не тормозит" всему миру. Но на практике этим будет пользоваться разве что сам автор, которому свое не пахнет.
| | |
| |
| 3.37, Ordu (ok), 09:36, 02/12/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > икающий в моменты когда GC приспичило собрать мусор
Я не интересовался именно джавой, но мне несколько удивительно слышать, что джава так и не научилась гонять gc в отдельном потоке. Уж кому-кому, а жабе с её популярностью и использованием во всех щелях это просто необходимо. В связи с этим вопрос: это вы чисто умозрительно предполагаете икание у java-кодека, или на своём опыте сталкивались? Расскажете как воспроизвести?
| | |
| |
| 4.38, vn971 (ok), 14:54, 02/12/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Ответ такой что нет, это было исключительно умозрительное предположение анонима, и совершенно неверное. В JVM gc-шка является настраиваемой, т.е. ты можешь указать её сам при старте jvm. Версия которая не делает "stop the world" возникла уже очень давно, и вроде по дефолту и запускается в JVM тоже уже давно. Т.е. gc действительно идёт в параллельном потоке.
При всём при этом, я вообще хотел лишь обратить внимание на безопасность c/cpp.
По факту писать именно кодеки я ни за что на JVM не рекомендую. Будет гигантское потребление памяти и медленная скорость работы (хоть и "плавная", без пауз). Касательно рекоммендаций, мне кажется кодеки надо писать на rust-lang. Или, если этот язык кажется недостаточно стабильным, то по-старинке на c/cpp.
| | |
|
|
|
| 1.21, Аноним (-), 12:28, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё опен соурс называется.
| | |
| |
| 2.29, Нимо Ан (?), 18:45, 01/12/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё
> опен соурс называется.
Ну потому и называется: читайте сорсы, в них никаких недоговорок нет.
| | |
|
|
