У Раста, кроме безопасности в работе с памятью, есть еще возможность применений формальных доказательств на уровне компиляции за счет нормальной системы типов. Минимизация человеческого фактора всегда лучше любых тестов.
1. Можно ли сделать так чтобы, программам пользователя когда нужно, исполнять код напрямую из ПЗУ, а не с виртуальной памяти. То есть нельзя ли иметь свой кастомный SWAP файл, сохранять его и исполнять код оттуда когда надо? 2. Нельзя ли перенести ядро Линукса на аппаратный уровень, чтобы ядро было в виде микросхем, а не загружался в ОЗУ, или ядро было бы частью ОЗУ на аппаратном уровне? Ведь ядро Линукса в общем стабильное.
1. Можно ли программам пользователя исполнять код напрямую из ПЗУ, а не с ОЗУ Программы из ОЗУ не исполняются. Потому что слишком медленно. Есть кэш инструкций. Так что из ПЗУ тем более не подойдет. Только если на каких-то кастомных встраиваемых системах 2. А как вы будете патчи и обновления приносить? Можно сделать в теории, но это будет слишком дорого и негибко. Части можно заносить, особенно с помощью FPGA - программируемых чипов
На сто процентов из ПЗУ не удастся, где-то надо хранить оперативные данные. Существует технология XIP - Execute in place, которая позволяет выполнять код не загружая сам код в оперативную память.
Ребят, ну вы чего?! DPDK - это еще больший отход от идей Таненбаума. Идея микроядра - растащить все по разным процессам-серверам: сетевой стек, файловые систем и уже через порты коммуницировать с ними из прикладных процессов. DPDK же, наоборот, тащит все внутрь, чтобы максимально избавиться от переключения контекстов.
Если бы знали какой объем должны прокачивать SGDMA 10/40 G ethernet, Infiniband, а для передачи из ядра linux в юзерспейс используется copy_from_user copy_to user вы бы понимали что это и почему DPDK вообще возник.
DPDK был приведен как пример успешного переноса типичных функций ядра в пользовательское пространство, что позволило добиться повышения производительности. DPDK, безусловно, комбайн, но не может не впечатлить результат, которого добился этот проект.
что бы любить линукс нужно быть извращенцем не желающим просто наслаждаться работой компа, а вечно исправлять косяки помимо основной своей деятельности
dos и freedos позволяют максимально непосредственно работать с железом и получить хотябы в некоторых задачах преимущество над linux? понятно что вопрос про x86
Преимущество в производительности? Точно можно получить преимущество в экономии дискового пространства. :D Минимальное ядро linux, собранное с tinyconfig, занимает полмегабайта. Причем в нем отключено буквально всё, то есть оно непригодно к какому-то осмысленному использованию. Включим хотя бы поддержку сети, минимальный toybox или busybox и получим уже что-то с трудом влезающее на дискету. FreeDOS, конечно, тоже не дюймовочка, но, выглядит, что дискетка с ней будет более полезной. Все зависит от задачи, но у MSDOS точно есть пара киллер-фич - она работает на 386м процессоре и в ней можно вешать резидентов на прерываниях. :)
bigphysarea патч, если быть точным. Да, там не было SG, поэтому так и выкручивалсь. Почему не было, сейчас уже и не вспомнить, возможно не хватало ресурсов. Какую плисину не бери, туда вечно что-то не влезает. :)
Про цифровую обработку сигнала говорятся какие-то странные вещи, похоже что человек все уже забыл или перепутал. Для мощных TMS семейств 64XX, 67XX, 674X, 66XX практически невозможно писать на ассемблере оптимальнее компилятора. Обычно используется С в котором с помощью прагм, интринсиков, выравнивания, рестриктед и т.д объясняют как оптимизировать код. И своя операционка Dsp Bios у Ti всегда была отличной
Старая школа сейчас таких не делают =) Современные программисты не могут на собесе рассказать что такое IPC и слово POSIX они говорят тоже не слыхали=)
Начиная с версии ядра 6.6.x начались проблемы с поддержкой sparc и mips. А именно чтото там в ядре портит память, не учитывая особенностей. Просто эти ядра больше никто в мире уже не тестит. Китайцы и русские со своими лонгсунами и эльбрусами остались, и в силу тотальной закрытости их pull-request в апстрим никто не подпишет как checked-by: не на чем запустить.
Rust? systemd тоже обещали асинхронный режим запуска процессов, загрузка за доли секунды - а в результате это всё переросло в полное гамно. Пользователи ни чего не получили, в результате по-факту старый инит обросший водорослями из скриптов и текстовых конфигов с бинарями
Небезопасного кода на расте не может быть. Иначе бы не было unsafe. Допустим вы делаете простейший односвязный список на раст. Нельзя делать null указатели. Идете в unsafe. Другой вопрос что в расте это огорожено, а в С никаких границ нет. Думаю, если посмотреть возраст разработчиков ядра линукс, это будет лет 50. Им учить раст, тяжело и желания нет. Либо процесс должен быть плавный, со сменой поколений, либо растоводам надо писать свое ядро.
Они их пишут! Вот только сегодня очередная новость пробегала на opennet. Однако, linux сейчас не сдвинуть с его места на пьедестале. Зачем кто-то будет брать новое ядро, если и со старым неплохо? Тащить еще один язык, готовить соответствующую инфраструктуру в ядре, это большая работа, которую надо чем-то оправдать. В конце концов, никто не запрещает - берите и пишите, это же open-sources. Может быть недостаточно желающих? Дополнять ядро linux штуками на rust, думаю никто не запретит, переписывать ядро на rust - колоссально дорого.
Да как то непонятное ощущение от видео. И про dpdk как то не внятно и про линукс как то хз а как про rust в ядре лучше бы ничего не говорили. Лучше взять линукс:))) apple это скажите.;)))
Нужно больше подкастов про Linux!
У Раста, кроме безопасности в работе с памятью, есть еще возможность применений формальных доказательств на уровне компиляции за счет нормальной системы типов. Минимизация человеческого фактора всегда лучше любых тестов.
А ещё у раст руководство под повесточкой и нестабильная ситуация со статусом проекта
Спасибо! Очень живо и интересно.
Открыл для себя такой интересный канал. Молодцы. Классный гость
Спасибо вам! Добро пожаловать на канал :)
Так интересно слушать, что невольно задумался о Gentoo. Но нет, нет и ещё раз нет. Проч эти мысли ) Только с арчем начал возиться
Отличный подскаст. Спасибо, случайно наткнулся на вас
1. Можно ли сделать так чтобы, программам пользователя когда нужно, исполнять код напрямую из ПЗУ, а не с виртуальной памяти. То есть нельзя ли иметь свой кастомный SWAP файл, сохранять его и исполнять код оттуда когда надо?
2. Нельзя ли перенести ядро Линукса на аппаратный уровень, чтобы ядро было в виде микросхем, а не загружался в ОЗУ, или ядро было бы частью ОЗУ на аппаратном уровне? Ведь ядро Линукса в общем стабильное.
1. Можно ли программам пользователя исполнять код напрямую из ПЗУ, а не с ОЗУ
Программы из ОЗУ не исполняются. Потому что слишком медленно. Есть кэш инструкций. Так что из ПЗУ тем более не подойдет. Только если на каких-то кастомных встраиваемых системах
2. А как вы будете патчи и обновления приносить? Можно сделать в теории, но это будет слишком дорого и негибко.
Части можно заносить, особенно с помощью FPGA - программируемых чипов
На сто процентов из ПЗУ не удастся, где-то надо хранить оперативные данные. Существует технология XIP - Execute in place, которая позволяет выполнять код не загружая сам код в оперативную память.
@@dmitriytochansky2463 но ведь Swap файл находится в ПЗУ
Ребят, ну вы чего?! DPDK - это еще больший отход от идей Таненбаума. Идея микроядра - растащить все по разным процессам-серверам: сетевой стек, файловые систем и уже через порты коммуницировать с ними из прикладных процессов. DPDK же, наоборот, тащит все внутрь, чтобы максимально избавиться от переключения контекстов.
Если бы знали какой объем должны прокачивать SGDMA 10/40 G ethernet, Infiniband, а для передачи из ядра linux в юзерспейс используется copy_from_user copy_to user вы бы понимали что это и почему DPDK вообще возник.
@@АндрейАндреевич-з7т знакомы и с DPDK, и с ibverbs, и с eBPF+XDP, и с io_uring.
DPDK был приведен как пример успешного переноса типичных функций ядра в пользовательское пространство, что позволило добиться повышения производительности. DPDK, безусловно, комбайн, но не может не впечатлить результат, которого добился этот проект.
Отличный выпуск, про XDP, eBPF жалко не поговорили, eBPF тоже целая вселенная поверх ядра.
@@cubicattache в eBPF циклов нет ;) но зато может исполняться на сетевухе
Молодцы !!!
Поделитесь ссылкой на визуализацию подсистем Линукс
Сейчас радиолюбители на stm32h7 кое как реализовывают преобразование фурье и КИХ БИХ фильтры. А ПЛИС очень дорого да еще и санкционная.
как портировать носок?
что бы любить линукс нужно быть извращенцем не желающим просто наслаждаться работой компа, а вечно исправлять косяки помимо основной своей деятельности
Качество звука и картинки заметно выросло по сравнению с прошлыми выпусками.
Спасибо, стараемся 💪🏼
dos и freedos позволяют максимально непосредственно работать с железом и получить хотябы в некоторых задачах преимущество над linux? понятно что вопрос про x86
Преимущество в производительности? Точно можно получить преимущество в экономии дискового пространства. :D Минимальное ядро linux, собранное с tinyconfig, занимает полмегабайта. Причем в нем отключено буквально всё, то есть оно непригодно к какому-то осмысленному использованию. Включим хотя бы поддержку сети, минимальный toybox или busybox и получим уже что-то с трудом влезающее на дискету. FreeDOS, конечно, тоже не дюймовочка, но, выглядит, что дискетка с ней будет более полезной. Все зависит от задачи, но у MSDOS точно есть пара киллер-фич - она работает на 386м процессоре и в ней можно вешать резидентов на прерываниях. :)
"... У FreeBSD не хватает критической массы, что бы она стала серверной..." ??? Ну может оговорился человек. Довольно странное заявление. 1:18:45
Bigmem патч? Continuous memory allocation? Забудьте. Это для тех, кто scatter-gather dma и message-signaled interrupts написать в плисине не осилил.
bigphysarea патч, если быть точным. Да, там не было SG, поэтому так и выкручивалсь. Почему не было, сейчас уже и не вспомнить, возможно не хватало ресурсов. Какую плисину не бери, туда вечно что-то не влезает. :)
Про цифровую обработку сигнала говорятся какие-то странные вещи, похоже что человек все уже забыл или перепутал. Для мощных TMS семейств 64XX, 67XX, 674X, 66XX практически невозможно писать на ассемблере оптимальнее компилятора. Обычно используется С в котором с помощью прагм, интринсиков, выравнивания, рестриктед и т.д объясняют как оптимизировать код. И своя операционка Dsp Bios у Ti всегда была отличной
Старая школа сейчас таких не делают =) Современные программисты не могут на собесе рассказать что такое IPC и слово POSIX они говорят тоже не слыхали=)
Елена очень мила :)
Что делать если ничего не понял?
Забыть про Embedded Linux на SoC системах ) Либо же наоборот - начать изучать, но, в таком случае, с самых азов.
По расту блокеры для ядра - это проблема со спецификацией и компилятором.
о! экс-джетБрейнс девелопер
Начиная с версии ядра 6.6.x начались проблемы с поддержкой sparc и mips. А именно чтото там в ядре портит память, не учитывая особенностей. Просто эти ядра больше никто в мире уже не тестит. Китайцы и русские со своими лонгсунами и эльбрусами остались, и в силу тотальной закрытости их pull-request в апстрим никто не подпишет как checked-by: не на чем запустить.
Лена знает, что она делает
Rust? systemd тоже обещали асинхронный режим запуска процессов, загрузка за доли секунды - а в результате это всё переросло в полное гамно. Пользователи ни чего не получили, в результате по-факту старый инит обросший водорослями из скриптов и текстовых конфигов с бинарями
Небезопасного кода на расте не может быть. Иначе бы не было unsafe. Допустим вы делаете простейший односвязный список на раст. Нельзя делать null указатели. Идете в unsafe. Другой вопрос что в расте это огорожено, а в С никаких границ нет. Думаю, если посмотреть возраст разработчиков ядра линукс, это будет лет 50. Им учить раст, тяжело и желания нет. Либо процесс должен быть плавный, со сменой поколений, либо растоводам надо писать свое ядро.
Вот правильно, пусть свое ядро и пишут. А не лезут в наше ядро😂
Они их пишут! Вот только сегодня очередная новость пробегала на opennet. Однако, linux сейчас не сдвинуть с его места на пьедестале. Зачем кто-то будет брать новое ядро, если и со старым неплохо? Тащить еще один язык, готовить соответствующую инфраструктуру в ядре, это большая работа, которую надо чем-то оправдать. В конце концов, никто не запрещает - берите и пишите, это же open-sources. Может быть недостаточно желающих? Дополнять ядро linux штуками на rust, думаю никто не запретит, переписывать ядро на rust - колоссально дорого.
пишут, пишут. вчера смотрел redox например
Если напрячься, то можно понять рассказчика. Специалист хороший, наверное. Но вещает человек сумбурно, временами варит кашу в своей голове.
Блин как этот реалтиме заели, человек живёт постоянно в прошлом, он воспринимает от внешних сенсоров с задержкой...
да, но в мозгу есть "branch predictor", который это выравнивает.
Сложилось впечатление что у гостя информация 2 летней давности. Про rust в ядре, про zfs.;)
Да как то непонятное ощущение от видео. И про dpdk как то не внятно и про линукс как то хз а как про rust в ядре лучше бы ничего не говорили. Лучше взять линукс:))) apple это скажите.;)))