The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Код поддержки кодека VP9 в V4L2 для чипов Hantro и Rockchip переписан на Rust

28.02.2024 12:23

Дэниел Алмейда (Daniel Almeida), занимающийся развитием видеокодеков в компании Collabora, представил для обсуждения разработчиками ядра Linux новую реализацию прослойки для использования аппаратных декодировщиков видео в формате VP9 в подсистеме V4L2, применяемой для организации доступа устройствам видеозахвата, таким как web-камеры и TV-тюнеры. Код прослойки полностью переписан на языке Rust и ориентирован на работу с драйверами rkvdec и hantro, предоставляющими доступ к средствам аппаратного декодирования видео, доступным в чипах Rockchip и Hantro.

Код с реализацией поддержки VP9 для v4l2 занимает около 2000 строк. В качестве причины создания альтернативной реализации на языке Rust упоминается желание добиться дополнительного уровня защиты за счёт применения предоставляемых языком Rust средств для безопасной работы с памятью в коде, который содержит реализацию достаточно сложных алгоритмов и применяется для обработки данных, поступающих из пространства пользователя через интерфейс V4L2. Несмотря на то, что реализация на Rust пока имеет статус выставленного на обсуждение экспериментального прототипа, при тестировании пакетом Fluster, оценивающим соответствие декодировщиков эталонным спецификациям, версии на Си и Rust показали идентичные результаты.

  1. Главная ссылка к новости (https://lkml.org/lkml/2024/2/2...)
  2. OpenNews: Выпуск языка программирования Rust 1.76
  3. OpenNews: Google выделил миллион долларов на улучшение переносимости между С++ и Rust
  4. OpenNews: Опубликован embedded-hal 1.0, инструментарий для создания драйверов на языке Rust
  5. OpenNews: Ядро Maestro, написанное на Rust и частично совместимое с Linux
  6. OpenNews: В ядро Linux 6.8 намечено включение первого сетевого драйвера на языке Rust
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60682-v4l
Ключевые слова: v4l, rust, vp9, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Витюшка (?), 12:48, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В общем направление развития понятно. Я все свои новые pet проекты буду писать на Rust. С Zig тоже перепишу.
     
     
  • 2.2, Аноним (-), 12:53, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А как же невозможность написать на Раст код, который изменяет память с разных потоков одновременно?
    Помню ты мне рассказывал, что это не просто важно, а жизненно необходимо!
    И что раст без такой функции вообще плохой язык.
     
     
  • 3.18, Вирт (?), 13:48, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  А как же невозможность написать на Раст код, который изменяет память с разных потоков одновременно?

    Вообще-то можно. Можно например создать тип 'MyPtr' как обертку для указателя,
    объявить что для этого типа реализован "Send", и можно будет
    копировать указатель и разъименовывать в разных потоках,
    но это конечно потребует использования "unsafe".

     
     
  • 4.71, Аноним (71), 18:17, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А еще лучше использовать готовые и проверенные примитивы - Arc/Mutex/Rwlock
     
  • 3.78, Витюшка (?), 19:17, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нельзя сделать просто, как в Zig. Будем делать "сложно", если понадобится)
     
  • 2.3, Аноним (3), 12:54, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На питон перепиши, не ошибёшься.
     
     
  • 3.17, Аноним (17), 13:38, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Или на джаваскрипт. Всё летать будет, отвечаю.
     
     
  • 4.93, Аноним (93), 11:32, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А если с привлечением фреймворка Electron, ваще реактивно будет.
     
  • 2.68, Аноним (-), 17:45, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты перепишешь. Нет это промежуточное направление. Хуанг сказал он стремится, чтобы программы писали программы, чтобы любой человек мог создавать программы через компьютер - программисты не нужны с написанием кода. В принципе отчасти так уже и делают берут готовое и стыкуют. А выйдет у них так сделать кто знает? Ответ мне не нужен.
     
     
  • 3.69, Аноним (-), 17:49, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как я понял имеется ввиду что-то вроде разновидности GPT для создания готового кода под нужные задачи.
     
  • 3.70, Аноним (-), 17:59, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это моё предположение понимание из его слов, там где я его слова сказанные увидел, он сказал одной фразой. Ещё могу предположить, что сложный код смогут создавать через аналог GPT только те у кого будут определённые дорогие мощности, а простое будет доступно в открытом доступе.
     
  • 3.72, Аноним (-), 18:21, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё я. Могу обнадёжить немного, не всё так грустно, не в пустыне живём. Работа будет. Не выйдет устроится писать код так как GPT уже пишет не беда копать лопатой или трактором, вёдра с чем-то носить, канализацию чистить и тому подобное GPT научить делать не возможно. Если только заменить всех водителей всей строительной техники на автоматическое управление - возможно, с комбайнами так уже сделано, где водитель управляет комбайном, а где и сам комбайн программой управляется. КамАЗ тестирует фуры без водителей. В тестовом режиме ездят такие машины. Но! с сантехниками так не выйдет.  
     
     
  • 4.75, Аноним (-), 18:41, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Но! с сантехниками так не выйдет.  

    Т.е походу ничего ен поменяется?
    Опять придется или разгребать овна, или исправлять бракоделие, или делать бракоделие)
    Даже фразу "ну прошлый мастер какой-то ужась сделал" менять не придется :-D

     

  • 1.4, Аноним (-), 12:57, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Всего один unsafe на 2к строк кода.
    И тот в fn v4l2_vp9_seg_feat_enabled_rs, который нельзя сделать без него, потому что это FFI extern "C".
    Неплохо, неплохо.
     
     
  • 2.10, Аноним (-), 13:26, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  потому что это FFI extern "C"

    Уточню, там unsafe не именно из-за FFI.
    А потому что извне приходит feature_enabled, которая с точки зрения раста "неизвестно что и никаких гарантий на нее нет".
    Поэтому вызов from_raw_parts_mut должен быть обернут в unsafe.

     
     
  • 3.67, m228chtig (?), 17:39, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > с точки зрения раста "неизвестно что и никаких гарантий на нее нет".

    Почему эту точку зрения не пофиксят? 🤔😐😏

     
     
  • 4.96, Не аноним я (?), 14:54, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Иди и фикси
     

  • 1.5, Серб (ok), 13:16, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    При добавлении rust в ядро говорили, что будут его использовать, в том случае, если даст какое-либо преимущество.

    Новая реализация дала преимущество?

    Сколько раз встречается на 2000 строк слово unsafe,

    PS:

    Хотя сам отвечу. 1.
    Хороший пример.

     
     
  • 2.8, Аноним (-), 13:21, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Новая реализация дала преимущество?

    Да, там стало меньше потенциальных дыр в ответственном компоненте.

    > Сколько раз встречается на 2000 строк слово unsafe

    Один раз. В функции v4l2_vp9_seg_feat_enabled_rs (https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/commit/7681609641fb9c9)

    Еще вопросы?

     
     
  • 3.11, Серб (ok), 13:27, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Да, там стало меньше потенциальных дыр в ответственном компоненте.

    В 800 строках изолированного кода?

    1200 строк - там данные забитые в исходники.

    Как пример - хороший вариант. Показать преимущества - не получилось.

    > Один раз.

    Это я уже нашел.

     
  • 3.28, Аноним (28), 15:04, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    какие дыры могут быть в разборе фреймов от железного декодера?
     
     
  • 4.33, Аноним (-), 15:24, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > какие дыры могут быть в разборе фреймов от железного декодера?

    О, не нужно недооценивать сишников!
    Как будто есть мало месть где можно выйти за пределы буфера или записать не туда.

     
     
  • 5.101, Аноним (101), 00:30, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Аппеляция к неким теоретически возможным дырам всегда умиляет, не не убеждает.
     
  • 2.24, Аноним (24), 14:14, 28/02/2024 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     
     
  • 3.41, Аноним (-), 16:12, 28/02/2024 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
     
  • 4.48, Аноним (24), 16:59, 28/02/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 5.62, Аноним (-), 17:29, 28/02/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.88, Sw00p aka Jerom (?), 08:33, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >какое-либо преимущество.

    "прослойка" должна давать преимущества?

     
  • 2.99, Аноним (99), 17:11, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    да, один, но эта функция вызывается уже в десяти местах..
     

  • 1.6, Аноним (6), 13:18, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Раст уже настолько крут что может тягаться с ассемблером?
     
     
  • 2.9, Аноним (9), 13:25, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем там ассемблер?
     
  • 2.25, нах. (?), 14:22, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В переписывании указателей на структуры - c ассемблером мог бы потягаться gwbasic.
    А больше ничего эта аж двухтысячестрочная прослойка к прокладке ничего и не делает, декодер - в железе.

    Нишка хруста вполне определилась.

     
     
  • 3.39, Аноним (-), 15:44, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А вот и кекспертное мнение из самых лучших совковых НИИ.
    С учетом кучи проектов которые уже используют раст, то пук знатный, но в лужу.
    Наверное про видео драйвера ты не слышал.
     
     
  • 4.102, Аноним (101), 00:34, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но даже у него уровень аргументации выше, чем у тебя - какой-то поток мыслей обиженки на весь мир.
     

  • 1.12, name (??), 13:30, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Переписали бы сломанный драйвер для амлоджиков, эти и так хорошо работали.
     
     
  • 2.13, Аноним (-), 13:33, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  Переписали бы сломанный драйвер для амлоджиков, эти и так хорошо работали.

    А как ты перепишешь то что уже сломано?
    Его вначале исправить нужно, а потом переписывать.
    Если там ошибки в логике обработки, то раст тебе не поможет - ты их точно также повторишь и на нем.

     
     
  • 3.14, name (??), 13:37, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Считаешь, они могут только повторять...
     
     
  • 4.21, Аноним (-), 13:59, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Считаю что "они хотят повторять")
    Если у тебя есть глючный инструмент, то логично сначала попробовать починиить или переделать его.
    В случае с/с++ починить равноценно переделать)
    Вот они и исправляют сначала то что им важно в данный момент. Заодно навыки растописания улучшают.
     
     
  • 5.40, An (??), 16:01, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя есть "глючный" инструмент(на самом деле нет), и ты хочешь его заменить(допустим) - зачем переделывать качественно получившуюся деталь, которая создана с помощью этого инструмента?
     
     
  • 6.60, Аноним (-), 17:24, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так плохим инструментом хорошую деталь не сделаешь.
    Деталь явно ущербная, вероятность ее поломки слишком большая - можно посмотреть новости про сишные дыры и это станет очевидно.

    Тут аналогия неправильная, лучше бы аноним со стройматериалом стравнил.
    Можно строить дом из овна и палок.
    И так строили в древности и некоторые ценители даже сейчас (саманный кирпич и глинобитные постройки).
    Но прогресс не стоит на месте и сейчас строят из более удобных и в строительстве, и в обслуживании материалов.
    Так же и с языками программирования.

    Каменный век закончился не потому что закончились камни.

     

  • 1.16, Шарп (ok), 13:38, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А что-нибудь новое на расте пишут или только переписывают уже работающее?

    Так же хочу спросить у специалистов по поводу API. Раст умеет в ядре экспортировать свой API или только через сишные обёртки и соответственно через обмазывание unsafe?

     
     
  • 2.19, Аноним (-), 13:54, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можешь пройтись по тегу, куча новых проектов пишутся из того что запомнилось мн... большой текст свёрнут, показать
     
     
  • 3.29, Аноним (28), 15:06, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Подход "давайте перепишем" - самый плохой из всех возможных и единственным оправданием для него может являться только "оно вообще не справляется с поставленной задачей, а исправить возможностей нет".

    Это азы программирования.

     
     
  • 4.32, Аноним (-), 15:23, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  "оно вообще не справляется с поставленной задачей, а исправить возможностей нет".

    Именно так.
    Постоянные проблемы с памятью, одинаковые уже десятки лет - use-after-free, double-free и out-of-bounds.
    И да, исправить возможности нет - тк исправить окаменевшие мозги сишников это не реально.

    А переписывание на новый ЯП - это полность изменение кода.
    По хорошему остается только логика и то ее тоже можно улучшить с учетом возможностей языка.
    Например выкинуть уродливые контрукции типа "нам достаточно и UINT, но будем использовать знаковый тип, чтобы отрицательными значениями пробрасывать ошибки ."

     
  • 4.35, Аноним (-), 15:27, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > самый плохой из всех возможных

    Это прекрасный вариант. Он позволяет заменять код частями, прогоняя тесты и отслеживая регрессии.

    Автор так и пишет:
    f) run the test suite (fluster.py run -d GStreamer-VP9-V4L2SL-Gst1.0 -ts VP9-TEST-VECTORS)
    g) results should be the same both with and without this patch

     
     
  • 5.59, Аноним (24), 17:23, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > отслеживая регрессии

    ну какие регрессии в расте, ну? Это ж раст с безопасной работой с памятью

     
     
  • 6.86, Аноним (-), 23:00, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А как гарантии безопасности памяти тебе помогут при копипасте? или сравнение перепутать?
     
  • 2.65, Аноним (-), 17:33, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Zed зарелизили намедни Но пока только для iOS repr C функции имеют C шный ... большой текст свёрнут, показать
     
  • 2.73, Аноним (71), 18:24, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://youtu.be/CEznkXjYFb4?t=930
    есть один крейт kernel, реализующий подсистемы через unsafe-обертки. весь слой выше - драйверы и прочее используют этот крейт и не имеют unsafe. в этом основной замысел.
     
  • 2.97, Аноним (97), 15:29, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А что-нибудь новое на расте пишут или только переписывают уже работающее?

    А что, у тебя есть какие-то распространённые востребованные для решения задачи, под которые еще никто ничего раньше не написал?
    А то ты любую задачу, если уже для её решения написали какой-то софт, называешь "переписывают работающее".
    Так-то с таким подходом и ядро лулникса, и вэйланд и 100500 DE - это "переписывание уже работающего". И все шутеры после вульфенштайна 3Д (даже дум).

     
     
  • 3.98, Шарп (ok), 16:47, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, у тебя есть какие-то распространённые востребованные для решения задачи, под
    > которые еще никто ничего раньше не написал?

    Если после переписывания функциональность не увеличилась или вообще уменьшилась, то это бесполезное переписывание.


     
     
  • 4.107, Аноним (97), 12:49, 04/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Если после переписывания функциональность не увеличилась или вообще уменьшилась, то это бесполезное переписывание.

    Ооо, теперь я вижу ЦА, которое живёт по плану: не буду ставить этот патч безопасности, ведь новой функциональности не добавилось.
    Если пропадёт пачка всяких там выход за границы массива, UB и прочего CVE-генерирования под лозунгом "тут тоже можно безопасТно писать, просто ну не шмогла я, не шмогла" (говоря проше: повысилась безопасность) - то вполне.

     
  • 3.103, Аноним (101), 00:40, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но никому в здравом уме не придет в голову переписать Doom 2016 и сделать из него Wolfenstein 3D, но на Расте, чем регулярно и занимаются переписывальщики.
     

  • 1.22, Аноним (22), 14:09, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Rockchip и Hantro

    Так это для ARM SoC. Там пусть экспериментируют.

     
  • 1.26, Аноним (28), 14:50, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Новость написана так, будто на расте написали декодер vp9. Хитро, хитро.

    На самом деле никакого декодера там в помине нет - обычный разбор уже готовых битовых полей, ничем не отличающийся, например, от разбора сетевых фреймов.

    Не вижу ни одного преимущества, кроме синтаксического замусоривания красивого С-подобного кода с целью усложнить чтение кода.

     
     
  • 2.27, Аноним (9), 14:56, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Новость совершенно нормально написана. Ну если дальше заголовка читать, конечно. Хотя и он в заблуждение не вводит.
     
  • 2.37, Аноним (-), 15:29, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты не в состоянии понять заголовок "Код ПОДДЕРЖКИ кодека VP9"?
    Потом про декодер ты придумываешь сам...
    А потом идешь громко возмущаться в комменты!

    Может вначале стоит научиться читать? И желательно глазами.

     
     
  • 3.104, Аноним (101), 00:42, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >И желательно глазами.

    А может сам попробуешь для начала? "Поддержка" может означать и реализацию кодека.

     
  • 2.38, нах. (?), 15:38, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > На самом деле никакого декодера там в помине нет - обычный разбор уже готовых битовых полей

    дык это и есть то, с чем идеально справляется нескучный йезычок.

    Главное не давать ему перекладывать эти поля непосредственно в порты железяки - что в данном случае с блеском и сделано (правда, опять не хрустиками - но они точно выбрали объект приложения усилий)

    > Не вижу ни одного преимущества

    почему? Он действительно идеален для работы по переписыванию полей структурок. И защищает от механических ошибок. А от боровчекера в двух тысячах строк из которых 2/3 оказывается и вовсе не кодом - вполне можно и убежать.

    Стоит ли оно таскания за собой еще одного отдельного громадного сборочного инструментария - ну так себе конечно вопрос.

     
     
  • 3.89, Sw00p aka Jerom (?), 08:36, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Он действительно идеален для работы по переписыванию полей структурок.

    видели недавно, как структуру из двух интов16 заменили на просто инт32, такое он может?

     
  • 2.46, Анонист (?), 16:44, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > с целью усложнить чтение кода.

    Так это же самое главное в современной айтишечке. Предел своих возможностей человечество уже достигло и теперь чтобы собирать бабло пошли по пути искусственного усложнения, преподнося хомячью это как "упрощение" и "улучшение".

     
     
  • 3.49, Аноним (-), 17:00, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    К сожалению предел возможностей люди овстигли еще 30 лет назад, когда писаки на СИ так и не научились не портить память((
    Но что самое страшное, им за это не надавали ко корявкам!
     

  • 1.44, Анонист (?), 16:31, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Представляю насколько сильнее это всё будет тормозить и насколько больше занимать памяти. Реально айтишечка свернула куда-то не туда.
     
     
  • 2.50, Аноним (-), 17:03, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хм... посмотри сравнение С и Раста.
    Например benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
    И ты увидешь что они идут примерно наровне.
    Что говорит о твоих познаниях в теме)

    Так что айтишека свернула, а тебя оставила за бортом.

     
  • 2.74, Аноним (71), 18:26, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Такова плата за сложность
     
  • 2.85, bnm (?), 22:41, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть статья на хабре, «Ржавая» IP-камера: прошивка на rust
     

  • 1.56, Аноним (56), 17:08, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь рокчип будет еле шевелиться.
     
     
  • 2.63, An (??), 17:31, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На Linux - да. Зато есть шанс для Free/NetBSD.
     
     
  • 3.80, Аноним (22), 19:46, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    О, оказывается, Rust обладает скрытым свойством, работать быстрее в БЗДях!
     
     
  • 4.81, An (??), 19:59, 28/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага. По причине отсутствия присутствия.
     

  • 1.64, Аноним (64), 17:33, 28/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Видимо, на расте совсем мало пишут, раз про 800 строка кода целую новость делают.
     
     
  • 2.100, Аноним (100), 23:12, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чуть более года назад в 13-м андроиде было примерно 1.5 млн строк кода на расте. Но тебе ведь всё равно, ты ведь в комменты к новости зашел не за правдой, а сладкого хлебушка поесть и самому набросить на вентилятор.
     
     
  • 3.105, Аноним (101), 00:47, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А сколько на C и C++? Google заявил, что их цель - не переводить существующий код C/C++ на Rust, а скорее направить разработку нового кода на безопасные для памяти языки, не только Rust кстати.
     

  • 1.87, Аноним (87), 03:15, 29/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    VP9 устарел, мало где поддерживаеться. В отличии от H.264/HEVC/AV1
     
     
  • 2.95, Аноним (95), 13:59, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +/
    VP9 появился позже H.264. Это VP8 не видел, чтоб использовался.
     

  • 1.91, S22 (?), 10:30, 29/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Сейчас в Раст появилось движение снизить гарантии для упрощения написания код.
    Учить язык сложно
     
  • 1.92, Аноним (92), 10:50, 29/02/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://www.tomshardware.com/software/security-software/white-house-urges-deve

    Капец для си-шников... ;)

     
     
  • 2.94, Аноним (93), 11:38, 29/02/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну если NSA предлагает/намекает, то да, точно всё будет безопасТно.
     
  • 2.106, Аноним (101), 00:52, 01/03/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Дядя Сэм конечно же плохого не посоветует. Но прошивку для F-35 пишут на C и C++.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру