А это точно не наколеночные поделки, которые страшно пихать в продакшен? Я слышал, для важных задач реального времени используют совсем не линукс.

Ну так-то Linux и есть студенческая поделка-переросток...
Сдается мне, его нереально по честному сертифицировать для использования в критически-важных областях...
В отличии от QNX какого-нибудь...

Да тот же QNX, куча проприетарщины, на худой конец FreeRTOS.

Славное деление на ноль.

Что ты несешь? Одно — риалтайм ос, другое — совсем нет.

Ну и кто тут сказал про FreeRTOS, как про ПРОДАКШОН-замену наколенной поделке Linux???

Debian линукс крутится на многих эмбеддед железяках и просто серверах без всяких сертификаций.

Я знаю, у самого пара cubietruck-ов с SoftEther в ro root работает...

И да, наcчет Debian и наколенных поделок:

https://packages.debian.org/wheezy/linux-image-rt-amd64
https://packages.debian.org/wheezy/xenomai-runtime
https://packages.debian.org/wheezy/rtai

Ну и зачем там ОКС7???

если на ЛОРе задать вопрос по любой теме, то 50% ответов сводятся к «ненужно», 20% не относятся к вопросу, из остальных половина просто тролли :-)

Ещё можно улучшить ом киллер, сейчас он убивает самый жирный процесс, а было бы хорошо, чтобы он выбивал процессы по заранее настроеному списку приоритета.
Например сначала убивает читалку pdf, потом smplayer, ну и далее как я этот список настрою.
Например в браузере у меня недописанные посты, его убивать по этому не надо
а вот в либре открыт docx с переводом ранобе. то есть он используется как читалка, его можно убивать спокойно. А у когото наоборот, в браузере мануальники, а в либре создаётся важный доклад.

Для этого в нём есть oom score.

Если задаёшь такой вопрос, то тебе ещё рано за это браться. Начни регулярно почитывать https://lkml.org/ хотя бы. А вообще, ответ на такой вопрос всегда один — займись тем, чего не хватает лично тебе. Это и есть основа подхода открытого программного обеспечения…

http сервер уже был (и вроде не один), qr коды тоже... как только потребуется запилить браузер появятся и реестр и гуй - подожди два года ;)

Хотел запилить c++ в ядро.

Не взлетит :3 Торвальдс не одобряет-с:

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Еще больше доставляет само его письмо http://harmful.cat-v.org/software/c /linus

Ну это боян. ЛТ имел в виду, что _само_ ядро нет смысла на C++ писать, хотя это было сказано в 90-х годах, когда компиляторы C++ были не торты.

и да, оно не сертифицировано

кем?

Пробрось блок девайс, карактер девайс и прочие примитивы в юзерспейс.

Нормальный быстрый gpio, а не то убожество что щас.

Slave mode i2c.

Синхронную передачу данных постранично между процессами как в л4

Я с наскоку в два часа ночи не могу придумать кейса для этого. Можно пример?

Хотел запилить JS-дивжок (duktape) в ядро.

А можно не в Ядро, а для Plan9 & Co? Вот как раз на днях обсуждали.

Альтернатив нет. Пруф:

NetSurf will incorporate Duktape javascript engine. Does Mothra have
javascript?

no.

- erik

Зато есть чел, который уже игрался:

Has anybody given them a look?

I tried to play with Duktape a while ago, but gave up after having had enough of preprocessor hell.

As always, portability macros have the opposite effect.

Официальный upstream: PREEMPT_RT. Это пилят, с каждым релизом перенося код из вот этих патчей в mainline. Некоторое время назад голова проекта возмутился, что куча компаний с очень известными названиями (глянул в серверные логи) пользуются, а вот отдачи никакой, денег не жертвуют. Заморозил он этот бесценный проект. Где-то год назад всё же нашёл поддержку, и вот свежий linux-image-rt снова в Debian.

Раскладку в консоли запили.

Перепили io, vm, шедулер, чтобы десктоп не лагал.

У тебя или плохое (дефективное) железо, или ядро некорректно сконфигурировано. Инфа 100. И то что под вендой не лагает (а оно скорее всего лагает, только менее заметно) не показатель.

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

Это позволит переопределять часть рабочей среды для разных пользователей (или наборов процессов одного пользователя), не засовывая их в chroot, namespaces и контейнеры (что явный оверкил для такой частной задачи). Несколько примеров:

1. Механизм Alternatives дебиана, который на обычных симлинках работает глобально для всей системы, можно сделать настраиваемым per user.

2. Во многих случаях мы не можем повлиять на выбор файла через переменные окружения, т.к. пути прошиты в файле - например в #! нотации скрипта или где-нибудь в недрах кода:

/usr/bin/python - это питон 2 или 3?
/usr/bin/autoconf - совместимой версии или нет? и т.п.

Per-user аналог Debian Alternatives позволит каждому пользователю откорректировать среду исполнения.

3. Иногда использование переменных окружения может быть не только неудобно, но и невозможно по причинам безопасности, т.к. они могут быть установлены непривилегированным кодом.

В частности, привилегированный код (например, после exec-а файла с SUID-битом), не может доверять переменным окружения, полученым от непривилегированного. Сейчас переход в привилегированный код всегда stateless: сохраняется некоторый небольшой набор состояний, таких как saved user ID, список groups, корневой каталог и т.п., но невозможно передать произвольное состояние.

Было бы полезно хранить некоторые переменные, которые наследуются по дереву процессов и которые непривилегированный код не может изменить:

привилегированный код сохраняет некоторое состояние в переменных varsym;
выполняется exec в непривелегированный код;
непривелегированный код выполняет любое количество fork и exec, все процессы хранят то же самое состояние, которому код может доверять;
выполняется exec в привелегированный код;
привелегированный код также может доверять полученному состоянию

Сейчас есть частные решения этой задачи для различных подсистем ядра, но нет общего, применимого в userspace.

4. Яркий пример безблагодатности — переменные XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_DATA_HOME, XDG_RUNTIME_DIR, XDG_CONFIG_DIRS.

С одной стороны, подход правильный: хотелось бы настраивать эти пути per user, и использование переменных окружения позволяет решить эту задачу.

С другой стороны, хотелось бы, чтобы модифицировать эти переменные, которые фактически определяют большую часть среды исполнения для десктопных программ, мог только доверенный код, а не любой случайный скрипт. Все эти переменные окружения нужно было выкинуть сразу после того как они были изобретены и никому не показывать. Но, увы, когда они изобретались, более безопасных средств задать процессам состояние среды не было.

То же самое относится и к костылю LD_LIBRARY_PATH.

5. Если копнуть глубже, то и PATH — из той же категории переменных, но на святую святых POSIX-а я покушаться не буду...

ISDN, ОКС-7 и прочая легаси телефония, - это ОЧЕНЬ специфическая вещь, мало кто этим интересуется, мало кто в это может.

Да и зачем? Хуавей все сделал за нас...

http://www.freertos.org/FreeRTOS-Plus/Safety_Critical_Certified/SafeRTOS.shtml

кем?

Никем.

это было сказано в 90-х годах, когда компиляторы C++ были не торты.

Как-раз у ЛТ претензии к самому языку. Я вообще предлагаю писать на Java! А что? Компилятор у нее уже почти торт.

Компилятор у нее уже почти торт.

это gcj компилятор?

Будет спрос на Java, компилятор подтянут. А пока никто не запрещает использовать другие. Название ядра сменим на jinux kernel!

1. Механизм Alternatives дебиана, который на обычных симлинках работает глобально для всей системы, можно сделать настраиваемым per user.

Симлинки в ~/.bin/.
~/.bin/ в PATH.

А можно не в Ядро, а для Plan9 & Co? Вот как раз на днях обсуждали.

Не знаю, зачем мне это :)

Я тоже игрался, duktape вполне запиливается в ядро, только нужно переложить double-арифметику на целые числа, там с этим основная проблема.

Твоего вмешательства =)

Ну да, конечно. А то извращение, которое в ядре используется для полиморфизма (vfs) и наследования (device model, crypto) это самый торт :-) ЛТ фанатик.

нет идей

Ну вот и не лезь.

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

Не знаю, зачем мне это :)

Вот и в гугле так решили и не включили Plan9 в GSOC 2016 :(

только нужно переложить double-арифметику на целые числа

Да, не рекомендуется пользоваться. Но вот даже cortex-m4f за пару евро, не имея MMU, имеет float. И тем не менее на нём тоже можно запустить ядро. Т.е. обернуть в ifdef, и будет работать по крайней мере у нас с вами. А вот где же вообще нет float/double? (Хотя мне это не принципиально.)

Симлинки в ~/.bin/.
~/.bin/ в PATH.

А как быть с хардкодом #!/bin/sh в скриптах?

Еще real-time было бы круто.

есть PREEMPT_RT и LITMUS RT. лучше сделать сложно, Linux для RT в принципе не очень подходит

лучше приходи к нам в Xen, там работы много :)

Как-будто HAMMER2 это не мечты Диллона

поттеринга там не хватает

и слава богу.

btrfs пили

Сделай порт micropython для ядра.

Kdbus уже появился? Его же обратно закопали.

Типа третьего набора юзерспейсных утилит, в которых тоже половина функций не будет работать?

Типа третьего набора юзерспейсных утилит, в которых тоже половина функций не будет работать?

типа сделать, чтобы все функции в текущем наборе работали?

В каком из? Который на камле или который на питоне? Я использую сейчас оба, потому что в каждом работают разные фичи.

P.S. Из того, что я видел, лучше всего работает вендовая гуйня от Citrix.

Который на камле или который на питоне?

на OCaml написана одна из реализаций xenstore, к юзерспейсным утилитам она прямого отношения не имеет. xl написан на C, равно как libxl и libxs

на Python написан генератор для libxl и xentrace_format

какие именно утилиты ты используешь?

Я использую сейчас оба, потому что в каждом работают разные фичи

уточни, пожалуйста, оба кого

из того, что я видел, лучше всего работает вендовая гуйня от Citrix.

какое отношение GUI от Citrix имеет к разработке самого Xen? Xen - это гипервизор, экзоядро, пользовательский интерфейс к нему - важная, но не такая уж большая часть

Squashfs over mtd

ubiblock уже есть, и он полезнее

Там хитрее всё. Ядро не использует арифметику с плавающей точкой и нельзя вот так просто запихнуть туда double/float числа без геморроя. Разовые вычисления - да, но код, общирно использующий такую арифметику - нет. Из того, что мне представлялось разумным при портировании duktape на ядро Linux - это 1) замена double на int 2) замена double на double_t (везде) и soft-реализация операций с этим типом

А вот где же вообще нет float/double?

Проблема не в том, что их где-то нет. В вендоядре они тоже не используются, хотя x86 во все поля.

какие именно утилиты ты используешь?

Xm и xl. У меня слегка старый Xen (4.4), но даже в нём я периодически натыкался на глюки в xl.

какое отношение GUI от Citrix имеет к разработке самого Xen? Xen - это гипервизор, экзоядро, пользовательский интерфейс к нему - важная, но не такая уж большая часть

Без пользовательсткого интерфейса гипервизор становится слегка бесполезным, не находишь? Я встречал довольно большое количество людей, выбравших kvm вместо Xen только из-за большего удобства работы с ним.

Без пользовательсткого интерфейса гипервизор становится слегка бесполезным, не находишь?

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

глюки в xl

писал в xen-users? в xen-devel? заводил баг?