OberonCore https://forum.oberoncore.ru/ |
|
нужен ли stderr и другие вопросы по процессам https://forum.oberoncore.ru/viewtopic.php?f=27&t=6925 |
Страница 1 из 1 |
Автор: | budden [ Вторник, 04 Апрель, 2023 22:57 ] |
Заголовок сообщения: | нужен ли stderr и другие вопросы по процессам |
Процессы в ОС - довольно сложная штука. Что у них есть?
Что из этого является лишним, если мы следуем путём Оберона? |
Автор: | arisu [ Среда, 05 Апрель, 2023 00:37 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
лишними являются процессы. |
Автор: | JackKatch [ Среда, 05 Апрель, 2023 09:48 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Думаю что fork - наиболее бессмысленная конструкция, если говорить об Оберон-технологиях. Stdin и так далее считаю неправильным (мои размышления, не имеющие отношения к Оберону). Если кто то пишет/читает, то пусть конкретно укажет откуда/куда. |
Автор: | budden [ Среда, 05 Апрель, 2023 12:40 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Процессы в A2/ЯОС уже есть (точнее, команды, но они близки по смыслу). Fork - да, в модели единой памяти он не особо осмысленен. В unix-системах просто копируются страницы памяти и получается дешёвый клон процесса. Это выгодно с точки зрения производительности, но приводит к заморочкам. В Оберонах такого нет, т.к. нельзя взять и скопировать кусок памяти задёшево. stdin и stdout тоже уже присутствуют в A2/ЯОС, в объекте Commands.Context . У меня в основном вопрос про stderr. Мне кажется, что должно быть достаточно одного потока. Наличие двух потоков затрудняет синхронизацию. С другой стороны, можно различать "информацию для пользователя" и "информацию для специалистов". Например, в звукорежиссуре ещё больше потоков - там есть поток для зрителей, поток для телевидения, потоки для исполнителей и поток для звукорежиссёра, который он подключает то туда, то сюда, налаживая звук в остальных потоках. А есть и какой-нибудь индикатор громкости на канале, который не нужен слушателям, но звукорежиссёру он показывает проблемы. |
Автор: | budden [ Суббота, 08 Апрель, 2023 23:32 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Кстати, я ещё не упомянул переменные окружения. Вещь, в принципе, нужная, например, она в Linux указывает графическим приложениям, на каком экране им запускаться, показывает ширину консоли для консольных приложений и т.п. (не говоря про общеизвестный путь поиска исполняемых приложений). |
Автор: | Comdiv [ Вторник, 11 Апрель, 2023 00:45 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Переменные окружения - это дырка в надёжности и безопасности, особенно касаемо пути поиска исполняемых приложений. В целом, ОС более высокого уровня может только мешать перетаскивание понятий из ОС более низкого уровня. |
Автор: | budden [ Вторник, 11 Апрель, 2023 01:38 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Да, там есть проблемы с безопасностью. Но как обойтись без переменных $TERM и $DISPLAY? Можно, конечно, по-большевистски объявить их ненужными, но должны быть и другие возможные ответы. Я стараюсь избегать характеристик типа "ОС более высокого уровня". Достаточно перейти с Си на какой-то более нормальный язык и это будет уже огромный шаг вперёд в безопасности, даже если вовсе не менять архитектуру. Прежде всего, новая ОС должна быть работоспособна и быть способной решать те задачи, которые обычно разрешимы в ОС. Т.е. она не должна стать хуже от новшеств, которые мы в неё внедряем. Переменные окружения используются для определённых вещей. Если мы упраздняем их, то нужно предложить что-то взамен. |
Автор: | SovietPony [ Вторник, 11 Апрель, 2023 11:54 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
чем угодно можно заменить переменные окружения. это просто бородатый костыль. $PATH -- в конфиги и апи $TERM и ко -- меняем на нормальное апи или вообще можно анигилировать. не ansi терминал днем с огнем не сыщешь. $DISPLAY -- многие прграммы предоставляют параметр -display, который делает тоже самое для всего остального тоже самое - нормальные апи, параметры, конфиги, ипц. |
Автор: | budden [ Вторник, 11 Апрель, 2023 13:03 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
У терминала есть ещё разные параметры, например $LINES, $COLUMNS, $LANG Возможно, что есть и другие (я в этом плохо разбираюсь). Они автоматически меняются, если изменить размер окна. Хотя я вот не знаю, как это обрабатывают другие программы, запущенные в терминале, насколько я понимаю, у них своя копия окружения и эти изменения уже на них не должны повлиять. Т.е. если мы запустили что-то в терминале, а потом поменяли размер окна терминала, то по идее запущенная программа не узнает об этих изменениях, если не сделать каких-то особых костылей. Я ведь правильно понимаю, что окружение наследуется целиком, а потом можно уже в дочернем процессе менять его? Однако mc же как-то умеет перерисовываться под размер терминала. Видимо, здесь действительно какое-то "API", т.е. программа должна быть подписана на события терминала, в котором она запущена, или ещё как-то быть с ним связана. Никогда этого не изучал под линуксом. Что касается переменной DISPLAY. Вот у меня сейчас есть рабочий стол на компьютере и tigervnc. Если я физически на компьютере, я запускаю несколько программ. Допустим, хромиум, codium, lxterminal, leafpad, gitk. Если я из дома, то я подключаюсь через tigervnc и запускаю те же программы, они должны показаться на экране vnc, а не на экране физического компьютера. Кроме того, я ещё захожу через ssh и там нет дисплея. Как поступить с переменной $DISPLAY? Если речь о конфигах и параметрах, то, я так понимаю, Вы предлагаете каждый раз, когда я захожу через удалённый рабочий стол, править конфиги всех этих программ? Или запускать каждый раз каждую программу с явным параметром? Соответственно, сейчас у меня всё само работает, а при таком решении произойдёт снижение уровня механизации моей работы, будет вероятность ошибиться и запустить программу не на том дисплее и т.п. Это не выглядит слишком конкурентоспособным решением. Насчёт API вообще не понял, что имеется в виду, поясните, пожалуйста. |
Автор: | Comdiv [ Среда, 12 Апрель, 2023 03:18 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
budden писал(а): Достаточно перейти с Си на какой-то более нормальный язык и это будет уже огромный шаг вперёд в безопасности, даже если вовсе не менять архитектуру Не совсем. Язык является важнейшей частью архитектуры и особенности языка shell, во многом, являются следствием особенностей системного языка, с другой стороны формируя ещё один дополнительный язык. Заменить C на более нормальный язык, но оставить следствия менее нормального, это всё равно что построить бассейн, но слить из него воду, потому что люди уже привыкли прыгать в пустой бассейн.
|
Автор: | arisu [ Среда, 12 Апрель, 2023 10:38 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
именно. если делать ось — она должна быть написана на том же языке, который предлагается применять как основной под ней. а пытаться лечить уже существующее бесполезно, потому что: «если ваш язык такой крутой, почему ваша ось написана не на нём?» это уж не говоря о том, что родовые травмы изо всех щелей торчат. язык реализации оси накладывает отпечаток на всё, и пытаться чинить то, что defective by design… ну, у каждого человека есть право тратить свою жизнь так, как ему хочется, конечно. |
Автор: | budden [ Среда, 12 Апрель, 2023 12:31 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Есть ли какие-то ответы по существу вопроса про переменную DISPLAY? Я задал конкретный вопрос, ответ на который мог бы позволить улучшить архитектуру, мне пока что дали один ответ, который не дотягивает по качеству (в части конфигов) или который я недопонял (в части API/ИПП). А дальше пошли какие-то проповеди за всё хорошее. Жизнь, конечно, у каждого своя, каждый сам решает, на что её тратить. Можно и на проповеди. Правда, я бы не хотел её тратить на чтение таких проповедей. |
Автор: | arisu [ Среда, 12 Апрель, 2023 12:41 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
проблема в том, что вам не хватает то ли интеллекта, то ли кругозора понять ответы, которые вы называете «проповеди». ну, дело ваше, лично я вам больше мешать «проповедями» не буду, пустое это. |
Автор: | budden [ Среда, 12 Апрель, 2023 13:02 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Переход на личности = слив, засчитано. Вы уже после прошлой темы, которую даже прочитать не осилили (а при этом лезете меряться интеллектом), а ответ, который дали, не соответствовал собственным же заявлениям (надо ли менять код или не надо), могли бы перестать мешать своими высокоумными комментариями, однако не удержались от того, чтобы прийти и ещё какую-нибудь столь же высокоумную мысль написать, а лучше две. Например, что может быть более интеллектуальным, чем заявление, что мне не хватает интеллекта или кругозора. Вы прямо блеснули, Эйнштейн перевернулся в гробу от зависти. Что же касается проповедей, то Вы с Константином написали совершенно тривиальные вещи, которые каждому понятны, а мой вопрос был не про это. Т.е. начали с офтопика, а закончили хамством. Тут уже в гробу перевернулись Д'Артаньян с Дон Кихотом, видя такое благородное поведение. Но, видимо, вопрос про переменную DISPLAY и как правильно это сделать, был настолько простым, что вообще не стоит обсуждения. Тем не менее, всё ещё жду от кого-нибудь ответа про $DISPLAY по существу дела. |
Автор: | budden [ Среда, 12 Апрель, 2023 13:28 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Вот, к примеру, ChatGPT, в отличие от местных острословов, не вставлял шпильку в каждой реплике, а конкретно и по делу ответил мне на заданный вопрос. Цитата: /ask через какие механизмы Linux-программы, выполняемые в терминале (например, mc, EMACS или nano) узнают об изменении размера терминала и ответ (я его сократил до тезисов): Цитата: * использование символа ESC (\033) в сочетании с последовательностью управляющих символов, принадлежащих к группе ANSI Escape. Когда размер терминала изменяется, терминал отправляет соответствующую последовательность символов в программу, которая может использовать эту информацию для перераспределения своего интерфейса. * для получения информации о размере терминала можно использовать системный вызов ioctl с аргументом TIOCGWINSZ. Этот вызов возвращает текущий размер терминала в виде структуры winsize, которая содержит количество строк и столбцов в терминале. * Библиотека ncurses предоставляет набор функций, которые позволяют программам легко управлять выводом на терминале и обрабатывать события изменения размера терминала. Здесь, правда, неясно, какие механизмы находятся внутри ncurses. Например, она может содержать обёртку для обработки управляющих символов, подключая его к механизму событий. Машина не сказала, что я могу установить функцию обратного вызова, которая будет вызвана при изменении размера терминала. Но в случае терминала как раз использование ESC-последовательностей является наиболее логичным, т.к. укладывается в общую идеологию последовательного способа взаимодействия программ, легко передаётся по сети и т.п. |
Автор: | budden [ Среда, 12 Апрель, 2023 13:41 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Также я спросил у умной машины про DISPLAY. Машина сказала про переменную, не сказала про параметр -display, который упомянул SovietPony и мне было указано на альтернативу - Wayland. Правда, репутация оного уже подмочена, но я спросил про Wayland. Там произошёл длинный диалог, и обе стороны друг друга вроде бы поняли. Моё понимание дошло до того, что уд.раб стол в Wayland - это xrdp. Когда программа запускается в Wayland, ей даётся выбор outputs (графических выводов), из которых она как-то должна выбрать тот, который ей нравится. Я не смог узнать, как именно программа его выбирает. Но в случае запуска в xrdp доступный вывод будет только один, а значит, и проблема выбора будет решена автоматически. Возможно, что это и есть то самое "продвинутое архитектурное решение", теперь нужно осознать, насколько это всё хорошо. Так-то, конечно, не должно быть простой возможности запустить программу на удалённом экране - это нарушает изоляцию сессий, а в X11 такое есть. Но этот вопрос не про переменные окружения. Ещё он написал: Цитата: Однако, некоторые реализации xrdp могут поддерживать интеграцию с локальным сервером дисплея, позволяя программам запускаться в контексте локального сервера дисплея через xrdp. В этом случае программа будет иметь доступ к локальному рабочему столу Что будет в этой ситуации? Уже будет доступно более одного дисплея и всё сводится к случаю X11. Значит, опять нужно как-то передавать программе выбор и возможен спонтанный запуск программы по ошибке на локальном рабочем столе удалённой машины вместо удалённого. Видимо, это уже надо на ЛОРе спрашивать. |
Автор: | blackdoomer [ Пятница, 14 Апрель, 2023 05:29 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
budden писал(а): Насчёт API вообще не понял, что имеется в виду, поясните, пожалуйста. budden писал(а): или который я недопонял (в части API/ИПП) мимоходом: если вы про сокращение "ипц" из сообщения SovietPony, то там подразумевался IPC (inter-process communication, межпроцессное взаимодействие).просто для меня было непонятно, почему Вы пишете про API, а потом говорите, мол, что "вообще не поняли насчёт API". |
Автор: | budden [ Пятница, 14 Апрель, 2023 13:18 ] |
Заголовок сообщения: | Re: нужен ли stderr и другие вопросы по процессам |
Я понял, что ипц - это IPC, но я не понял, как конкретно оно даст процессу понять, что он должен рисоваться на дисплее удалённого рабочего стола. Сам по себе механизм же этого не сделает, тут нужно какое-то архитектурное решение, которое будет лишь использовать этот механизм. Само решение не приведено. То, что я понял - про конфиги, мне не понравилось и я указал на то, что считаю (как пользователь) недостатками. Я клоню к тому, что когда решение будет полностью и в явном виде выписано, может получиться, что оно не лучше, чем переменные окружения, а даже хуже. Касаемо API та же ситуация. Допустим, может быть некое API, которое будет заменять мне переменную DISPLAY. Допустим, особый системный вызов. И дальше что? Как из этого возникнет тот факт, что приложения для VNC будут отрисовываться именно через VNC? |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |