На самом деле всё просто решается, нужно на каждого мантейнера взять дополнительного, который понимает в подсистеме за которую отвечает и rust. Тогда легко будет поддерживать два языка.
Ну чтобы OpenOCD из репозитория подходил, есть только один путь - пропихнуть патчи в апстрим, что маловероятно. Тут хоть от производителя, а много лет назад я по всея интернету искал патчи для TI.
Это только десктоп версия для упрощения разработки, на Win и Mac тоже в виртуалке. В бой уже нативная идёт только на Linux (namspaces + cgroups) - без KVM.
Да просто высокоскоростной интерконнект между хостами поверх PCIe шины. В основном, встречается во всяких HA парах СХД, чтобы делать когерентные кэши и т.д. Очень распространённый вариант - двух юнитовый сервер с общим бекплейном для двухпортовых nvme дисков.
Если это одна задача, которая ждёт окончания одной операции прежде чем приступить к другой - то в чём, блин, проблема от асинхронности?
Если одна задача (поток) ждёт окончания предыдущей операции прежде чем приступить к другой, то это синхронные операции. И тут конечно нет никаких проблем от асинхронности. т.к. её тут нет.
Можно, но как гарантировать что прям до диска всё дойдёт в нужном порядке, тот же posix aio это очередь которая обрабатывается несколькими нитями, кто первый встал того и тапки.
Я к тому, что в случае БД - системного ПО, всё гораздо сложнее.
Правильно! Только нужно копать глубже, сможет ли ваш асинхронный код на уровне языка программирования обеспечить упорядоченную запись. А как там на уровне ОС, контроллеров дисков? И если мы говорим о БД, то о всём этом нужно задумываться.
Ценник на самом деле не адекватный. ".. это как плевок в лицо народа..." - это конечно инфантил писал. Но когда на ОЗОН есть платы на этом же МК с плюс-минус теми же ценами и большей обвязкой, Микрон... Могли бы и демпингануть для большего охвата.
Я больше всё-таки про низкоуровневый код. Если Си становится тесным, то вполне можно перейти на С++, потихоньку добавляя разные возможности. Есть свои нюансы, но в принципе возможно. И тут большой плюс у C++ - какая-никакая но совместимость.
А в остальном согласен, С++ за время существования, такое легаси накопил, что очень сложно читать код реальных проектов, там разброс от фабрик-фабрик, до шаблоны-шаблонами погоняют. а ещё функциональщина. И это не говоря о библиотеках.
На Си тоже есть мастера жанра, которые изобретают ручное ООП, ещё и с макросами, но лично для меня классический процедурный код понятнее. Например, Linux-ядро - тупое как пробка.
Да нет, конечно. Другое дело, что нафига оно нужно в таком исполнении, если на том же ОЗОН валяются платы за +2000-5000 т.р. с отдельной флешкой. программатором и т.д.
ИМХО если требуется что-то низкоуровневое, то я бы предпочел чистый C, а не C++, из-за читаемости и "отлаживаемости".
Можно всегда на С++ в Си-стайл писать, используя только подмножество языка. Но у Си конечное есть своя ниша - старые/актуальные и новые проекты, типа Linux/DPDK/SPDK/кодеки/либы и т.д. Ну и конечно C ABI.
Интересно, а он сам уже много написал ядерного кода на rust?
На самом деле всё просто решается, нужно на каждого мантейнера взять дополнительного, который понимает в подсистеме за которую отвечает и rust. Тогда легко будет поддерживать два языка.
Ну чтобы OpenOCD из репозитория подходил, есть только один путь - пропихнуть патчи в апстрим, что маловероятно. Тут хоть от производителя, а много лет назад я по всея интернету искал патчи для TI.
Миграцию контейнеров? Если да, то там есть наработки по миграции процессов ОС, но до mainline linux вроде пока не добралось.
Это только десктоп версия для упрощения разработки, на Win и Mac тоже в виртуалке. В бой уже нативная идёт только на Linux (namspaces + cgroups) - без KVM.
В таблице где сравниваются различные продукты, что за KVM такой? Или это опять модуль ядра Линукс в целый продукт выделяют?
Да просто высокоскоростной интерконнект между хостами поверх PCIe шины. В основном, встречается во всяких HA парах СХД, чтобы делать когерентные кэши и т.д. Очень распространённый вариант - двух юнитовый сервер с общим бекплейном для двухпортовых nvme дисков.
Нет, это в вымышленном мире.
Ну если душнить, то я бы поспорил, что в ОС реализовали N:M. Последняя успешная попытка была в солярке. Сейчас все основные ОС сидят на один к одному.
Но в языках и библиотеках, конечно пытаются иммитировать.
А сопрограммы как выполняются?
Нет, это просто перекладывание задачи на ОС.
Может я и не прав, но оппонент скорее всего оперирует высокоуровневыми языками, где всё это скрыто под капотом. Поэтому и нет понимания.
Если одна задача (поток) ждёт окончания предыдущей операции прежде чем приступить к другой, то это синхронные операции. И тут конечно нет никаких проблем от асинхронности. т.к. её тут нет.
Можно, но как гарантировать что прям до диска всё дойдёт в нужном порядке, тот же posix aio это очередь которая обрабатывается несколькими нитями, кто первый встал того и тапки.
Я к тому, что в случае БД - системного ПО, всё гораздо сложнее.
Правильно! Только нужно копать глубже, сможет ли ваш асинхронный код на уровне языка программирования обеспечить упорядоченную запись. А как там на уровне ОС, контроллеров дисков? И если мы говорим о БД, то о всём этом нужно задумываться.
А кто гарантирует порядок в случае асинхронного I/o?
Ценник на самом деле не адекватный. ".. это как плевок в лицо народа..." - это конечно инфантил писал. Но когда на ОЗОН есть платы на этом же МК с плюс-минус теми же ценами и большей обвязкой, Микрон... Могли бы и демпингануть для большего охвата.
Я больше всё-таки про низкоуровневый код. Если Си становится тесным, то вполне можно перейти на С++, потихоньку добавляя разные возможности. Есть свои нюансы, но в принципе возможно. И тут большой плюс у C++ - какая-никакая но совместимость.
А в остальном согласен, С++ за время существования, такое легаси накопил, что очень сложно читать код реальных проектов, там разброс от фабрик-фабрик, до шаблоны-шаблонами погоняют. а ещё функциональщина. И это не говоря о библиотеках.
На Си тоже есть мастера жанра, которые изобретают ручное ООП, ещё и с макросами, но лично для меня классический процедурный код понятнее. Например, Linux-ядро - тупое как пробка.
Да нет, конечно. Другое дело, что нафига оно нужно в таком исполнении, если на том же ОЗОН валяются платы за +2000-5000 т.р. с отдельной флешкой. программатором и т.д.
Можно всегда на С++ в Си-стайл писать, используя только подмножество языка. Но у Си конечное есть своя ниша - старые/актуальные и новые проекты, типа Linux/DPDK/SPDK/кодеки/либы и т.д. Ну и конечно C ABI.