OberonCore

Процессы в ОС - довольно сложная штука. Что у них есть?

• pid
• stdin, stdout, stderr
• отношения родства
• код возврата (можно возвращать не только число в XXI веке, а хотя бы строку)
• приоритет
• способность обрабатывать сигналы
• fork и подобные конструкции

Что из этого является лишним, если мы следуем путём Оберона?

лишними являются процессы.

Думаю что fork - наиболее бессмысленная конструкция, если говорить об Оберон-технологиях. Stdin и так далее считаю неправильным (мои размышления, не имеющие отношения к Оберону). Если кто то пишет/читает, то пусть конкретно укажет откуда/куда.

Процессы в A2/ЯОС уже есть (точнее, команды, но они близки по смыслу). Fork - да, в модели единой памяти он не особо осмысленен. В unix-системах просто копируются страницы памяти и получается дешёвый клон процесса. Это выгодно с точки зрения производительности, но приводит к заморочкам. В Оберонах такого нет, т.к. нельзя взять и скопировать кусок памяти задёшево.

stdin и stdout тоже уже присутствуют в A2/ЯОС, в объекте Commands.Context . У меня в основном вопрос про stderr. Мне кажется, что должно быть достаточно одного потока. Наличие двух потоков затрудняет синхронизацию. С другой стороны, можно различать "информацию для пользователя" и "информацию для специалистов". Например, в звукорежиссуре ещё больше потоков - там есть поток для зрителей, поток для телевидения, потоки для исполнителей и поток для звукорежиссёра, который он подключает то туда, то сюда, налаживая звук в остальных потоках. А есть и какой-нибудь индикатор громкости на канале, который не нужен слушателям, но звукорежиссёру он показывает проблемы.

Кстати, я ещё не упомянул переменные окружения. Вещь, в принципе, нужная, например, она в Linux указывает графическим приложениям, на каком экране им запускаться, показывает ширину консоли для консольных приложений и т.п. (не говоря про общеизвестный путь поиска исполняемых приложений).

Переменные окружения - это дырка в надёжности и безопасности, особенно касаемо пути поиска исполняемых приложений.

В целом, ОС более высокого уровня может только мешать перетаскивание понятий из ОС более низкого уровня.

Да, там есть проблемы с безопасностью. Но как обойтись без переменных $TERM и $DISPLAY? Можно, конечно, по-большевистски объявить их ненужными, но должны быть и другие возможные ответы. Я стараюсь избегать характеристик типа "ОС более высокого уровня". Достаточно перейти с Си на какой-то более нормальный язык и это будет уже огромный шаг вперёд в безопасности, даже если вовсе не менять архитектуру. Прежде всего, новая ОС должна быть работоспособна и быть способной решать те задачи, которые обычно разрешимы в ОС. Т.е. она не должна стать хуже от новшеств, которые мы в неё внедряем. Переменные окружения используются для определённых вещей. Если мы упраздняем их, то нужно предложить что-то взамен.

чем угодно можно заменить переменные окружения. это просто бородатый костыль.
$PATH -- в конфиги и апи
$TERM и ко -- меняем на нормальное апи или вообще можно анигилировать. не ansi терминал днем с огнем не сыщешь.
$DISPLAY -- многие прграммы предоставляют параметр -display, который делает тоже самое
для всего остального тоже самое - нормальные апи, параметры, конфиги, ипц.

У терминала есть ещё разные параметры, например $LINES, $COLUMNS, $LANG Возможно, что есть и другие (я в этом плохо разбираюсь). Они автоматически меняются, если изменить размер окна. Хотя я вот не знаю, как это обрабатывают другие программы, запущенные в терминале, насколько я понимаю, у них своя копия окружения и эти изменения уже на них не должны повлиять. Т.е. если мы запустили что-то в терминале, а потом поменяли размер окна терминала, то по идее запущенная программа не узнает об этих изменениях, если не сделать каких-то особых костылей. Я ведь правильно понимаю, что окружение наследуется целиком, а потом можно уже в дочернем процессе менять его? Однако mc же как-то умеет перерисовываться под размер терминала. Видимо, здесь действительно какое-то "API", т.е. программа должна быть подписана на события терминала, в котором она запущена, или ещё как-то быть с ним связана. Никогда этого не изучал под линуксом.

Что касается переменной DISPLAY. Вот у меня сейчас есть рабочий стол на компьютере и tigervnc. Если я физически на компьютере, я запускаю несколько программ. Допустим, хромиум, codium, lxterminal, leafpad, gitk. Если я из дома, то я подключаюсь через tigervnc и запускаю те же программы, они должны показаться на экране vnc, а не на экране физического компьютера. Кроме того, я ещё захожу через ssh и там нет дисплея. Как поступить с переменной $DISPLAY? Если речь о конфигах и параметрах, то, я так понимаю, Вы предлагаете каждый раз, когда я захожу через удалённый рабочий стол, править конфиги всех этих программ? Или запускать каждый раз каждую программу с явным параметром? Соответственно, сейчас у меня всё само работает, а при таком решении произойдёт снижение уровня механизации моей работы, будет вероятность ошибиться и запустить программу не на том дисплее и т.п. Это не выглядит слишком конкурентоспособным решением.

Насчёт API вообще не понял, что имеется в виду, поясните, пожалуйста.

Не совсем. Язык является важнейшей частью архитектуры и особенности языка shell, во многом, являются следствием особенностей системного языка, с другой стороны формируя ещё один дополнительный язык. Заменить C на более нормальный язык, но оставить следствия менее нормального, это всё равно что построить бассейн, но слить из него воду, потому что люди уже привыкли прыгать в пустой бассейн.

именно. если делать ось — она должна быть написана на том же языке, который предлагается применять как основной под ней. а пытаться лечить уже существующее бесполезно, потому что: «если ваш язык такой крутой, почему ваша ось написана не на нём?» это уж не говоря о том, что родовые травмы изо всех щелей торчат. язык реализации оси накладывает отпечаток на всё, и пытаться чинить то, что defective by design… ну, у каждого человека есть право тратить свою жизнь так, как ему хочется, конечно.

Есть ли какие-то ответы по существу вопроса про переменную DISPLAY? Я задал конкретный вопрос, ответ на который мог бы позволить улучшить архитектуру, мне пока что дали один ответ, который не дотягивает по качеству (в части конфигов) или который я недопонял (в части API/ИПП). А дальше пошли какие-то проповеди за всё хорошее. Жизнь, конечно, у каждого своя, каждый сам решает, на что её тратить. Можно и на проповеди. Правда, я бы не хотел её тратить на чтение таких проповедей.

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

Переход на личности = слив, засчитано. Вы уже после прошлой темы, которую даже прочитать не осилили (а при этом лезете меряться интеллектом), а ответ, который дали, не соответствовал собственным же заявлениям (надо ли менять код или не надо), могли бы перестать мешать своими высокоумными комментариями, однако не удержались от того, чтобы прийти и ещё какую-нибудь столь же высокоумную мысль написать, а лучше две. Например, что может быть более интеллектуальным, чем заявление, что мне не хватает интеллекта или кругозора. Вы прямо блеснули, Эйнштейн перевернулся в гробу от зависти. Что же касается проповедей, то Вы с Константином написали совершенно тривиальные вещи, которые каждому понятны, а мой вопрос был не про это. Т.е. начали с офтопика, а закончили хамством. Тут уже в гробу перевернулись Д'Артаньян с Дон Кихотом, видя такое благородное поведение. Но, видимо, вопрос про переменную DISPLAY и как правильно это сделать, был настолько простым, что вообще не стоит обсуждения. Тем не менее, всё ещё жду от кого-нибудь ответа про $DISPLAY по существу дела.

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


и ответ (я его сократил до тезисов):

Здесь, правда, неясно, какие механизмы находятся внутри ncurses. Например, она может содержать обёртку для обработки управляющих символов, подключая его к механизму событий. Машина не сказала, что я могу установить функцию обратного вызова, которая будет вызвана при изменении размера терминала. Но в случае терминала как раз использование ESC-последовательностей является наиболее логичным, т.к. укладывается в общую идеологию последовательного способа взаимодействия программ, легко передаётся по сети и т.п.

Также я спросил у умной машины про DISPLAY. Машина сказала про переменную, не сказала про параметр -display, который упомянул SovietPony и мне было указано на альтернативу - Wayland. Правда, репутация оного уже подмочена, но я спросил про Wayland. Там произошёл длинный диалог, и обе стороны друг друга вроде бы поняли. Моё понимание дошло до того, что уд.раб стол в Wayland - это xrdp. Когда программа запускается в Wayland, ей даётся выбор outputs (графических выводов), из которых она как-то должна выбрать тот, который ей нравится. Я не смог узнать, как именно программа его выбирает. Но в случае запуска в xrdp доступный вывод будет только один, а значит, и проблема выбора будет решена автоматически. Возможно, что это и есть то самое "продвинутое архитектурное решение", теперь нужно осознать, насколько это всё хорошо. Так-то, конечно, не должно быть простой возможности запустить программу на удалённом экране - это нарушает изоляцию сессий, а в X11 такое есть. Но этот вопрос не про переменные окружения.

Ещё он написал:


Что будет в этой ситуации? Уже будет доступно более одного дисплея и всё сводится к случаю X11. Значит, опять нужно как-то передавать программе выбор и возможен спонтанный запуск программы по ошибке на локальном рабочем столе удалённой машины вместо удалённого. Видимо, это уже надо на ЛОРе спрашивать.

мимоходом: если вы про сокращение "ипц" из сообщения SovietPony, то там подразумевался IPC (inter-process communication, межпроцессное взаимодействие).
просто для меня было непонятно, почему Вы пишете про API, а потом говорите, мол, что "вообще не поняли насчёт API".

Я понял, что ипц - это IPC, но я не понял, как конкретно оно даст процессу понять, что он должен рисоваться на дисплее удалённого рабочего стола. Сам по себе механизм же этого не сделает, тут нужно какое-то архитектурное решение, которое будет лишь использовать этот механизм. Само решение не приведено. То, что я понял - про конфиги, мне не понравилось и я указал на то, что считаю (как пользователь) недостатками. Я клоню к тому, что когда решение будет полностью и в явном виде выписано, может получиться, что оно не лучше, чем переменные окружения, а даже хуже.

Касаемо API та же ситуация. Допустим, может быть некое API, которое будет заменять мне переменную DISPLAY. Допустим, особый системный вызов. И дальше что? Как из этого возникнет тот факт, что приложения для VNC будут отрисовываться именно через VNC?