Сообщение Re[25]: Windows захватили инопланетяне? от 21.01.2020 18:58
Изменено 21.01.2020 22:39 blp
Re[25]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали:
S>>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
blp>>Потому что задача — сделать per-user сервис.
S>Это не задача. Это решение. Задача в чём?
Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide". Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера. В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
blp>>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
S>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
S>Ну, ок. Допустим, аргумент про изоляцию.
Ну слава богу. А чего только "допустим"?
blp>>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
S>Не получается.
Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess) или сделать так, чтобы процесс сам завершился, послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
С юзерскими приложениями типа ноутпада TerminateProcess еще туда-сюда возможен — юзеру сначала показывается окошко с предложением самому разобраться что надо сделать через GUI, но если он ничего не сделает, а логофф все равно нужно делать, делается TerminateProcess.
В случае с сервисами предполагается, что они написаны так, что могут корректно деинициализироваться за известное время (иногда довольно большое) без участия юзера, TerminateProcess вызывается только тогда, когда это условие нарушается (баг в сервисе); logoff блокируется пока сервис не остановится. Cервисы, очевидно, нельзя просто прибивать.
S>Меньше думайте о людях; больше — о технических подробностях.
Все мы люди, все мы человеки.
S>Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
S>Вот видите, как всё плохо.
Что именно плохо?
>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить",
Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
>вызывает какое-то извивание хребтом вместо простого ответа.
Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
>Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
blp>>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
S>А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
S>Здравствуйте, blp, Вы писали:
S>>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
blp>>Потому что задача — сделать per-user сервис.
S>Это не задача. Это решение. Задача в чём?
Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide". Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера. В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
blp>>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
S>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
S>Ну, ок. Допустим, аргумент про изоляцию.
Ну слава богу. А чего только "допустим"?
blp>>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
S>Не получается.
Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess) или сделать так, чтобы процесс сам завершился, послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
С юзерскими приложениями типа ноутпада TerminateProcess еще туда-сюда возможен — юзеру сначала показывается окошко с предложением самому разобраться что надо сделать через GUI, но если он ничего не сделает, а логофф все равно нужно делать, делается TerminateProcess.
В случае с сервисами предполагается, что они написаны так, что могут корректно деинициализироваться за известное время (иногда довольно большое) без участия юзера, TerminateProcess вызывается только тогда, когда это условие нарушается (баг в сервисе); logoff блокируется пока сервис не остановится. Cервисы, очевидно, нельзя просто прибивать.
S>Меньше думайте о людях; больше — о технических подробностях.
Все мы люди, все мы человеки.
S>Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
S>Вот видите, как всё плохо.
Что именно плохо?
>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить",
Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
>вызывает какое-то извивание хребтом вместо простого ответа.
Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
>Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
blp>>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
S>А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
Re[25]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, blp, Вы писали:
S>>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
blp>>Потому что задача — сделать per-user сервис.
S>Это не задача. Это решение. Задача в чём?
Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide". Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера. В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
blp>>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
S>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
S>Ну, ок. Допустим, аргумент про изоляцию.
Ну слава богу. А чего только "допустим"?
blp>>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
S>Не получается.
Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess,если быть совсем точным, ZwTerminatrProcess, хотя в целя данного разговора непринципиально) или сделать так, чтобы процесс сам завершился (вызвал Exit process), послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
С юзерскими приложениями типа ноутпада TerminateProcess еще туда-сюда возможен — юзеру сначала показывается окошко с предложением самому разобраться что надо сделать через GUI, но если он ничего не сделает, а логофф все равно нужно делать, делается TerminateProcess.
В случае с сервисами предполагается, что они написаны так, что могут корректно деинициализироваться за известное время (иногда довольно большое) без участия юзера, TerminateProcess вызывается только тогда, когда это условие нарушается (баг в сервисе); logoff блокируется пока сервис не остановится. Cервисы, очевидно, нельзя просто прибивать.
S>Меньше думайте о людях; больше — о технических подробностях.
Все мы люди, все мы человеки.
S>Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
S>Вот видите, как всё плохо.
Что именно плохо?
>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить",
Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
>вызывает какое-то извивание хребтом вместо простого ответа.
Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
>Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
blp>>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
S>А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.
S>Здравствуйте, blp, Вы писали:
S>>>Пока что всё ещё непонятно, почему нельзя обойтись system-wide сервисом, который тащит в себе нужное состояние со всеми перезапусками и прочими особенностями, а приложениям оставить то, для чего они нужны — коммуникацию с пользователем.
blp>>Потому что задача — сделать per-user сервис.
S>Это не задача. Это решение. Задача в чём?
Это именно задача, которая стояла перед людьми, ее решающими. Т.е. в документе было написано что-то вроде "Task: refactor XXX services into separate processes instead of system-wide". Вы наверное, хотите спросить зачем это вообще было нужно делать — зачем нужно системным сервисам разносить функциональность по разным процессам для каждого юзера. В такой формулировке вопроса ответ довольно очевиден — как минимум, код теперь выполняется под аккаунтом юзера, а не system, любые баги в таком сервисе не затрагивают всех юзеров сразу и т д.
blp>>Эти per-user сервисы раньше в таком виде не существовали. Судя по тому, что я вижу, они — результат рефакторинга и написания нового кода.
S>Тогда ваш аргумент про лёгкость превращения существующих system-wide сервисов и драйверов в per-user сервисы нерелевантен.
Почему? Вроде бы очевидно, что отрефакторить сервис и разнести per-user функционалонсть по разным процессам-сервисам проще, чем делать из сервиса приложение (подход, как мы уже выяснили, имеющий ряд проблем с реализацией)
S>Ну, ок. Допустим, аргумент про изоляцию.
Ну слава богу. А чего только "допустим"?
blp>>а, теоретические фантазии. Неинтересно. Предлагаю самостоятельно подумать и придумать сценарий, в котором нельзя откладывать завершение асинхронных задач до окончания логоффа (ну или наоборот, нельзя делать логофф пока не решена асинхронные задачи). Не получится — так и быть, помогу.
S>Не получается.
Ок, рассказываю: logoff предполагает, что access token юзера, который залогинен, уничтожается. Другими словами, на него никто не должен держать открытый handle. Если у вас есть процесс, который этот токен использует, то вариантов ровно два: завершить процесс принудительно (TerminateProcess,если быть совсем точным, ZwTerminatrProcess, хотя в целя данного разговора непринципиально) или сделать так, чтобы процесс сам завершился (вызвал Exit process), послав ему сигнал и дождавшись пока он корректно деинициализируется и сам завершится. Пока одно из этих двух действий не сделано, завершить logoff нельзя, по определению того, что такое logoff.
С юзерскими приложениями типа ноутпада TerminateProcess еще туда-сюда возможен — юзеру сначала показывается окошко с предложением самому разобраться что надо сделать через GUI, но если он ничего не сделает, а логофф все равно нужно делать, делается TerminateProcess.
В случае с сервисами предполагается, что они написаны так, что могут корректно деинициализироваться за известное время (иногда довольно большое) без участия юзера, TerminateProcess вызывается только тогда, когда это условие нарушается (баг в сервисе); logoff блокируется пока сервис не остановится. Cервисы, очевидно, нельзя просто прибивать.
S>Меньше думайте о людях; больше — о технических подробностях.
Все мы люди, все мы человеки.
S>Либо в Редмонде системный кризис с техдоками, либо эта версия неверна.
Обсуждать системный кризис с техдоками я в рамках этого треда не готов — это соврешенно другая тема. Мы вроде сейчас про архитектуру per-user сервисов и их необходимость, а не про техдоки?
S>Вот видите, как всё плохо.
Что именно плохо?
>Оказывается, что простая практическая задача типа "вот сервис, который мониторит XXXX, вот как его перезапустить",
Нету такой задачи, потому что нету "сервиса, который мониторит XXX" — у вас изначально была совсем другая формулировка. Сформулируйте что именно вам надо перезапустить и истина откроется вам.
>вызывает какое-то извивание хребтом вместо простого ответа.
Где вы видите извивание хребтом? Я вижу пока странные запросы типа "а как мне найти сервис, запущеный в Рамадан 2019 года" и предсказуемый плач о том, что иструментов для этого нет. Ну нет, да. И раньше не было.
>Для сравнения: со "старыми" сервисами такой проблемы нет — есть детерминированный способ узнать имя сервиса.
Что в лоб, что по лбу. Старые сервисы — они создаются каждый раз когда юзер залогинится? Нет? Тогда причем они тут?
blp>>Не, реально сучно. Пока что меня можно было бы заменить поиском по MSDN с тем же результатом. Это я еще не начал говорить ничего, что было бы неизвестно и недокументировано — просто не нужно.
S>А вот мне очень весело. Во-первых, я получаю полезные знания, а во вторых, получаю эстетическое удовольствие, глядя на то, как вы выкручиваетесь из положения, в которое сами себя загнали.
Я вижу исключительно постепенную выдачу детальной технической информации, которая с каждым постом показывает, что собеседники предметом не владеют даже в рамках способности почитать MSDN, но своё мнение у них по любому вопросу есть.
Но если для вас это выглядит так, будто вы меня тут загнали в угол и теперь получаете эстетическое удовольствие от каких-то ваших фантазий — хорошо, почему нет. У всех разные способы развлекаться.