Сообщение Re[28]: Windows захватили инопланетяне? от 23.01.2020 6:28
Изменено 23.01.2020 6:31 Sinclair
Re[28]: Windows захватили инопланетяне?
Здравствуйте, blp, Вы писали:
blp>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать.
Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
blp> "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача.
Мы в данном случае обсуждаем не рефакторинг.
blp> Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
Не "наблюдаемые изменения", а "изменения интересующих параметров". Я вам пример про криптоферму уже приводил — из того, что наблюдаемыми изменениями является повышение температуры в квартире, никак не следует то, что именно оно и было целью.
Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором.
Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
blp>И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Именно поэтому их не стали документировать — чтобы избежать будущих зависимостей. Собственные сервисы можно выпилить с обозримым бюджетом; бегать за неизвестным числом производителей с попытками отозвать API займёт годы.
Потому же не стали допиливать GUI — зачем это делать, если есть риск через полгода убирать всё обратно?
Теперь у нас есть три варианта развития событий:
1. Сервисы признаются приемлемым решением; недоделки доделываются.
2. Сервисы признаются неудачным решением; в очередном релизе они исчезают.
3. Никто ничего не делает, т.к. "работает — не трогай", "покажите мне business justification для предлагаемого вами изменения", "это всё понятно, но на этот релиз у нас другие приоритеты".
Наиболее вероятен третий вариант.
>>Что именно было отрефакторено?
blp>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
Эмм, вы уверены? CDPSvc никуда не делся. Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
blp>Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
Ещё раз: давайте всегда будем начинать с того, что вы пишете после "например, для того, чтобы". Потому что задачи типа "иметь отдельный процесс на каждого юзера" — это не задачи, это решения.
По их формулировке невозможно понять уместность решения. Например, я ставлю задачу "иметь отдельный поток под каждую пользовательскую сессию". Задача? Задача. Является ли она уместной в контексте высоконагруженного сервиса?
Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться.
blp>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
Потому что объём ресурсов всегда ограничен. Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
S>>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
blp>Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих.
Взаимодействие с десктопом тут дело десятое. Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
S>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
Нет там никаких костылей в ядре. Или вы костылями называете http.sys?
S>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя?
blp>Как запущен? ну вот реально как?
Запущен через CreateProcessWithToken, например.
blp>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное?
Оконное приложение, которое не создаёт никаких окон.
blp>ShutdownBlockReasonCreate вызывался?
Нет, мы говорим не о шатдауне, а о logoff.
blp>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
blp>попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь
.
blp>вот — начните отсюда
Это я читал. Ничего интересного в рамках нашей дискуссии там нет. Напомню, что мы обсуждаем именно logoff — задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис.
blp>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
>>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
blp>Опять-таки, читаем MSDN.
Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы.
blp>А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
Почему не знают? Конечно знают. Вы попробуйте на конференции подойти к любому сотруднику MS (кроме, естественно, маркетологов) и спросить, идеален ли их продукт. Вам каждый скажет, что у них есть бэклог толщиной в хобот мамонта на следующие релизы. И конечно все знают, что разные фичи шипятся в разных степенях готовности и проработанности.
>>Жду открытия истины — киньте скрипт на повершелле, который это сделает?
blp>Не могу вам его дать
Ну, спасибо что признались.
blp>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
Ну как же так? Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен. Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так? Ну ладно, фиг с ним
blp>У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
Не, это как раз у вас очень собственное определение "задача". В стиле "подмети плац ломом". А что, тоже задача, не хуже других. Архитекторы системы формулируют задачи в стиле "обеспечить чистоту плаца при таких-то ограничениях". И там уже или метлой, или ломом, или спецтехникой.
blp>Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
Во-первых, не при запуске, а при логоне. Во-вторых, понятно, что не было — непонятно, для чего они нужны. И непонятно, почему они так криво сделаны.
blp>Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить.
Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться.
blp>Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
При том, что он спроектирован нормально, с учётом сценариев пользователя.
blp>Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
Дизайн приемлемый. По крайней мере, в этом дизайне предусмотрен способ опознать тот из бесчисленных firefox.exe, который мне нужен.
blp>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
Я и так сомневаюсь
Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
На всякий случай поясню: на позиции "раз винда — значит отстой" я тоже не стою.
Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
В MSDN про это ничего не написано. Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это. Либо, что на этом форуме найдутся люди, достаточно квалифицированные для обсуждения данного вопроса. В том смысле, что уже прочли MSDN вдоль и поперёк, и смогли сопоставить фрагменты документации для получения целостной картины.
Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов и на задачи уровня "мне сказали запилить сервис — я запилил. Сказали бы запилить приложение — запилил бы приложение".
Вот представьте себя в роли архитектора. Вы пишете какое-то приложение для windows 10. Требования к нему формулирует product manager — в терминах прикладных сценариев. Ему вообще неважно, будет это сервис, пользовательский сервис, драйвер, или веб-страничка. В каких случях вы бы рассмотрели применение per-user service в рамках этого приложения? А в каких случаях бы решили обойтись без него?
У вас нет никакого senior architect, который примет решение за вас. Предположительно, вы настолько хорошо знаете "MSDN", что можете сами принять решение.
blp>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать.
Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
blp> "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача.
Мы в данном случае обсуждаем не рефакторинг.
blp> Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
Не "наблюдаемые изменения", а "изменения интересующих параметров". Я вам пример про криптоферму уже приводил — из того, что наблюдаемыми изменениями является повышение температуры в квартире, никак не следует то, что именно оно и было целью.
Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором.
Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
blp>И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Именно поэтому их не стали документировать — чтобы избежать будущих зависимостей. Собственные сервисы можно выпилить с обозримым бюджетом; бегать за неизвестным числом производителей с попытками отозвать API займёт годы.
Потому же не стали допиливать GUI — зачем это делать, если есть риск через полгода убирать всё обратно?
Теперь у нас есть три варианта развития событий:
1. Сервисы признаются приемлемым решением; недоделки доделываются.
2. Сервисы признаются неудачным решением; в очередном релизе они исчезают.
3. Никто ничего не делает, т.к. "работает — не трогай", "покажите мне business justification для предлагаемого вами изменения", "это всё понятно, но на этот релиз у нас другие приоритеты".
Наиболее вероятен третий вариант.
>>Что именно было отрефакторено?
blp>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
Эмм, вы уверены? CDPSvc никуда не делся. Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
blp>Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
Ещё раз: давайте всегда будем начинать с того, что вы пишете после "например, для того, чтобы". Потому что задачи типа "иметь отдельный процесс на каждого юзера" — это не задачи, это решения.
По их формулировке невозможно понять уместность решения. Например, я ставлю задачу "иметь отдельный поток под каждую пользовательскую сессию". Задача? Задача. Является ли она уместной в контексте высоконагруженного сервиса?
Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться.
blp>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
Потому что объём ресурсов всегда ограничен. Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
S>>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
blp>Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих.
Взаимодействие с десктопом тут дело десятое. Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
S>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
Нет там никаких костылей в ядре. Или вы костылями называете http.sys?
S>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя?
blp>Как запущен? ну вот реально как?
Запущен через CreateProcessWithToken, например.
blp>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное?
Оконное приложение, которое не создаёт никаких окон.
blp>ShutdownBlockReasonCreate вызывался?
Нет, мы говорим не о шатдауне, а о logoff.
blp>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
blp>попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь
.blp>вот — начните отсюда
Это я читал. Ничего интересного в рамках нашей дискуссии там нет. Напомню, что мы обсуждаем именно logoff — задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис.
blp>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
>>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
blp>Опять-таки, читаем MSDN.
Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы.
blp>А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
Почему не знают? Конечно знают. Вы попробуйте на конференции подойти к любому сотруднику MS (кроме, естественно, маркетологов) и спросить, идеален ли их продукт. Вам каждый скажет, что у них есть бэклог толщиной в хобот мамонта на следующие релизы. И конечно все знают, что разные фичи шипятся в разных степенях готовности и проработанности.
>>Жду открытия истины — киньте скрипт на повершелле, который это сделает?
blp>Не могу вам его дать
Ну, спасибо что признались.
blp>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
Ну как же так? Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен. Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так? Ну ладно, фиг с ним
blp>У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
Не, это как раз у вас очень собственное определение "задача". В стиле "подмети плац ломом". А что, тоже задача, не хуже других. Архитекторы системы формулируют задачи в стиле "обеспечить чистоту плаца при таких-то ограничениях". И там уже или метлой, или ломом, или спецтехникой.
blp>Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
Во-первых, не при запуске, а при логоне. Во-вторых, понятно, что не было — непонятно, для чего они нужны. И непонятно, почему они так криво сделаны.
blp>Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить.
Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться.blp>Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
При том, что он спроектирован нормально, с учётом сценариев пользователя.
blp>Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
Дизайн приемлемый. По крайней мере, в этом дизайне предусмотрен способ опознать тот из бесчисленных firefox.exe, который мне нужен.
blp>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
Я и так сомневаюсь
Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
На всякий случай поясню: на позиции "раз винда — значит отстой" я тоже не стою.
Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
В MSDN про это ничего не написано. Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это. Либо, что на этом форуме найдутся люди, достаточно квалифицированные для обсуждения данного вопроса. В том смысле, что уже прочли MSDN вдоль и поперёк, и смогли сопоставить фрагменты документации для получения целостной картины.
Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов и на задачи уровня "мне сказали запилить сервис — я запилил. Сказали бы запилить приложение — запилил бы приложение".
Вот представьте себя в роли архитектора. Вы пишете какое-то приложение для windows 10. Требования к нему формулирует product manager — в терминах прикладных сценариев. Ему вообще неважно, будет это сервис, пользовательский сервис, драйвер, или веб-страничка. В каких случях вы бы рассмотрели применение per-user service в рамках этого приложения? А в каких случаях бы решили обойтись без него?
У вас нет никакого senior architect, который примет решение за вас. Предположительно, вы настолько хорошо знаете "MSDN", что можете сами принять решение.
Re[28]: Windows захватили инопланетяне?
Здравствуйте, blp, Вы писали:
blp>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать.
Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
blp> "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача.
Мы в данном случае обсуждаем не рефакторинг.
blp> Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
Не "наблюдаемые изменения", а "изменения интересующих параметров". Я вам пример про криптоферму уже приводил — из того, что наблюдаемыми изменениями является повышение температуры в квартире, никак не следует то, что именно оно и было целью.
Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором.
Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
blp>И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Именно поэтому их не стали документировать — чтобы избежать будущих зависимостей. Собственные сервисы можно выпилить с обозримым бюджетом; бегать за неизвестным числом производителей с попытками отозвать API займёт годы.
Потому же не стали допиливать GUI — зачем это делать, если есть риск через полгода убирать всё обратно?
Теперь у нас есть три варианта развития событий:
1. Сервисы признаются приемлемым решением; недоделки доделываются.
2. Сервисы признаются неудачным решением; в очередном релизе они исчезают.
3. Никто ничего не делает, т.к. "работает — не трогай", "покажите мне business justification для предлагаемого вами изменения", "это всё понятно, но на этот релиз у нас другие приоритеты".
Наиболее вероятен третий вариант.
>>Что именно было отрефакторено?
blp>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
Эмм, вы уверены? CDPSvc никуда не делся. Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
blp>Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
Ещё раз: давайте всегда будем начинать с того, что вы пишете после "например, для того, чтобы". Потому что задачи типа "иметь отдельный процесс на каждого юзера" — это не задачи, это решения.
По их формулировке невозможно понять уместность решения. Например, я ставлю задачу "иметь отдельный поток под каждую пользовательскую сессию". Задача? Задача. Является ли она уместной в контексте высоконагруженного сервиса?
Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться.
blp>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
Потому что объём ресурсов всегда ограничен. Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
S>>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
blp>Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих.
Взаимодействие с десктопом тут дело десятое. Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
S>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
Нет там никаких костылей в ядре. Или вы костылями называете http.sys?
S>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя?
blp>Как запущен? ну вот реально как?
Запущен через CreateProcessWithToken, например.
blp>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное?
Оконное приложение, которое не создаёт никаких окон.
blp>ShutdownBlockReasonCreate вызывался?
Нет, мы говорим не о шатдауне, а о logoff.
blp>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
blp>попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь.
blp>вот — начните отсюда
Это я читал. Ничего интересного в рамках нашей дискуссии там нет. Напомню, что мы обсуждаем именно logoff — задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис.
blp>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
>>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
blp>Опять-таки, читаем MSDN.
Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы.
blp>А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
Почему не знают? Конечно знают. Вы попробуйте на конференции подойти к любому сотруднику MS (кроме, естественно, маркетологов) и спросить, идеален ли их продукт. Вам каждый скажет, что у них есть бэклог толщиной в хобот мамонта на следующие релизы. И конечно все знают, что разные фичи шипятся в разных степенях готовности и проработанности.
>>Жду открытия истины — киньте скрипт на повершелле, который это сделает?
blp>Не могу вам его дать
Ну, спасибо что признались.
blp>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
Ну как же так? Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен. Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так? Ну ладно, фиг с ним с настройками сервиса (которые выдают invalid parameter — см. заглавное сообщение). Но уж старт-стоп то мы должны получить на халяву, нет? Иначе не очень понятно, какие такие преимущества даёт нам запиливание этой функциональности в виде сервиса, а не обычного процесса.
blp>У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
Не, это как раз у вас очень собственное определение "задача". В стиле "подмети плац ломом". А что, тоже задача, не хуже других. Архитекторы системы формулируют задачи в стиле "обеспечить чистоту плаца при таких-то ограничениях". И там уже или метлой, или ломом, или спецтехникой.
blp>Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
Во-первых, не при запуске, а при логоне. Во-вторых, понятно, что не было — непонятно, для чего они нужны. И непонятно, почему они так криво сделаны.
blp>Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить.
Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться.
blp>Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
При том, что он спроектирован нормально, с учётом сценариев пользователя.
blp>Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
Дизайн приемлемый. По крайней мере, в этом дизайне предусмотрен способ опознать тот из бесчисленных firefox.exe, который мне нужен.
blp>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
Я и так сомневаюсь Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.
Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
На всякий случай поясню: на позиции "раз винда — значит отстой" я тоже не стою.
Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
В MSDN про это ничего не написано. Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это. Либо, что на этом форуме найдутся люди, достаточно квалифицированные для обсуждения данного вопроса. В том смысле, что уже прочли MSDN вдоль и поперёк, и смогли сопоставить фрагменты документации для получения целостной картины.
Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов и на задачи уровня "мне сказали запилить сервис — я запилил. Сказали бы запилить приложение — запилил бы приложение".
Вот представьте себя в роли архитектора. Вы пишете какое-то приложение для windows 10. Требования к нему формулирует product manager — в терминах прикладных сценариев. Ему вообще неважно, будет это сервис, пользовательский сервис, драйвер, или веб-страничка. В каких случях вы бы рассмотрели применение per-user service в рамках этого приложения? А в каких случаях бы решили обойтись без него?
У вас нет никакого senior architect, который примет решение за вас. Предположительно, вы настолько хорошо знаете "MSDN", что можете сами принять решение.
blp>Общепринятое понимание слов "поставленная задача" — это какой-то набор работ, который нужно сделать.
Простите, но с т.з. архитектуры такое понимание задачи — это уровень джуниор-девелопера. Ему сказали "написать функцию" — он написал функцию. Сказали бы "написать класс" — он бы написал класс.
blp> "Наблюдаемые характеристики" могут в результате и не меняться, если у вас, скажем, доступа к коду нет и вести наблюдения вы не можете. "Рефакторинг" например — тоже задача.
Мы в данном случае обсуждаем не рефакторинг.
blp> Впрочем в обсуждаемом случае наблюдаемыми изменениями является появление новых сервисов, так что под ваше кастомное определение оно тоже попадает.
Не "наблюдаемые изменения", а "изменения интересующих параметров". Я вам пример про криптоферму уже приводил — из того, что наблюдаемыми изменениями является повышение температуры в квартире, никак не следует то, что именно оно и было целью.
Вы рассуждаете на каком-то сверхнизком уровне принятия решений — в рамках задачи "написать per-user service" задача "написать per-user service" очевидно является единственным возможным выбором.
Интересует не она, а то, откуда вообще взялась задача "написать per-user service".
blp>И? Какой именон вывод делаете вы? Я пока никакого анализа от собеседников на форуме не видел, кроме бития себя пяткой в грудь и предложения неработающих решений (разбивающихся о суровую реальность из того же MSDN)
Я, с точки зрения своего опыта работы продукт менеджером, делаю вывод о том, что была поставлена какая-то прикладная задача. При обсуждении кто-то предложил прикостылить вот эти вот per-user services.
Судя по всему, единодушной поддержки это решение не получило; его приняли с условием "ок, давайте попробуем; если окажется, что проблем создаётся больше, чем решается — откатим обратно".
Именно поэтому их не стали документировать — чтобы избежать будущих зависимостей. Собственные сервисы можно выпилить с обозримым бюджетом; бегать за неизвестным числом производителей с попытками отозвать API займёт годы.
Потому же не стали допиливать GUI — зачем это делать, если есть риск через полгода убирать всё обратно?
Теперь у нас есть три варианта развития событий:
1. Сервисы признаются приемлемым решением; недоделки доделываются.
2. Сервисы признаются неудачным решением; в очередном релизе они исчезают.
3. Никто ничего не делает, т.к. "работает — не трогай", "покажите мне business justification для предлагаемого вами изменения", "это всё понятно, но на этот релиз у нас другие приоритеты".
Наиболее вероятен третий вариант.
>>Что именно было отрефакторено?
blp>Блин, мне правда скучно быть капитаном очевидность, уже начинает подзадалбывать. Ну посмотрите глазами. CDPSvc / CDPUserSvc хотя бы
Эмм, вы уверены? CDPSvc никуда не делся. Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc, или его код вынесен в сервис из каких-то приложений, которые до этого бегали в пользовательской сессии?
blp>Еще один. Еще можно поставить задачу нарисовать лошадку и нрисовать лошадку. Надо было не "испольнять код серивса под аккантом юзера", а иметь отдельный процесс на каждого юзера. Например, для того, чтобы краш процесса не влиял на всех юзеров сразу. например для того, чтобы в памяти одного процесса не было данных разных юзеров в случае code injection и т д
Ещё раз: давайте всегда будем начинать с того, что вы пишете после "например, для того, чтобы". Потому что задачи типа "иметь отдельный процесс на каждого юзера" — это не задачи, это решения.
По их формулировке невозможно понять уместность решения. Например, я ставлю задачу "иметь отдельный поток под каждую пользовательскую сессию". Задача? Задача. Является ли она уместной в контексте высоконагруженного сервиса?
Как мы знаем — нет. Ну так какой смысл рассуждать в терминах стажёрских задач?
Про задачу "сделать так, чтобы краш процесса не влиял на всех юзеров сразу" я уже писал, не буду повторяться.
blp>Почему "ивестиции в QA" и "разделениесервисов по юзерам" взаимоисключающие вещи?
Потому что объём ресурсов всегда ограничен. Менеджер продукта всегда выбирает не то, что делать, а то, чего не делать в рамках релиза.
S>>Вот, например, IIS. Там как раз и пользовательский код, и изоляция. Почему-то там не стали плодить per-user сервисы, а запускают worker processes. Почему?
blp>Потому что iis никак не привязан к пользовательским логон-сессиям. Это system-wide сервис, запускающий несколько копий w3wp.exe ниак с десктопом не взаимодействующих.
Взаимодействие с десктопом тут дело десятое. Уж оно-то точно легче делается в обычных приложениях, чем в сервисах. Вы сформулировали задачу изолировать пользовательские процессы друг от друга — вот вам пример решения аналогичной задачи. Ведь можно было бы сделать и per-virtual-application сервисы, следуя ровно той же логике.
S>>Плюс для IIS в виндах есть столько внутренних костылей в ядре, что я бы не стал приводить его в пример как образец красивой архитектуры.
Нет там никаких костылей в ядре. Или вы костылями называете http.sys?
S>>Ок, как будет себя вести при логоффе неинтерактивный процесс, который запущен из-под сервиса под токеном пользователя?
blp>Как запущен? ну вот реально как?
Запущен через CreateProcessWithToken, например.
blp>что вообще такое "неинтерактивный процесс"? Консольное приложение? Приложение без видимых окон? консольное?
Оконное приложение, которое не создаёт никаких окон.
blp>ShutdownBlockReasonCreate вызывался?
Нет, мы говорим не о шатдауне, а о logoff.
blp>Что такое "при логоффе"? Инсталл критических апдейтов вызывает логофф, но другого типа — и т. д.
О, вот это интересно. Расскажите, что за типы логоффа? Я вот в MSDN не нашёл.
blp>попробуйте детально почитать MSDN чтобы найти дырки в вашем предложении. Мне это делать за вас уже лень, да и в некоторых местах за это платят неплохие деньги, а я тут чисто зачем-то бесплатно распинаюсь
.blp>вот — начните отсюда
Это я читал. Ничего интересного в рамках нашей дискуссии там нет. Напомню, что мы обсуждаем именно logoff — задержка шатдауна как раз хорошо документирована, и её прекрасно обработает system-wide сервис.
blp>Как именно сервис поймает момент логина / логоффа, чтбы что-то там запустить? Я уж молчу про то, о чем я уже говорил — "запустить" это задача сложнее, чем она вам кажется из уютного мира с пони и единорогами.
Ну, это же вы рассказываете мне, что именно сервис имеет возможность задерживать логофф, в отличие от приложения. Вот и расскажите, как именно.
"Запустить" — а в чём, собственно, проблема? CreateThread() и поехали.
>>Будет ли для него вызван TerminateProcess; будет ли показан warning пользователю о том, что this application is preventing logoff? Может ли system-wide сервис перехватить logoff евент и попросить систему отложить logoff до удобного момента?
blp>Опять-таки, читаем MSDN.
Ну, вы же уже прочитали, и уверены в том, что хорошо во всём разобрались. Если нет — так и напишите, будем вместе читать. А критика чужой квалификации без демонстрации своей — неубедительна, увы.
blp>А мужики-то не знают! Регулярно шипают недокументированные фичи виндов уже лет 30 как. Сырой продукт, стало быть. Недоделаный!
Почему не знают? Конечно знают. Вы попробуйте на конференции подойти к любому сотруднику MS (кроме, естественно, маркетологов) и спросить, идеален ли их продукт. Вам каждый скажет, что у них есть бэклог толщиной в хобот мамонта на следующие релизы. И конечно все знают, что разные фичи шипятся в разных степенях готовности и проработанности.
>>Жду открытия истины — киньте скрипт на повершелле, который это сделает?
blp>Не могу вам его дать
Ну, спасибо что признались.
blp>Нету сервиса "OneSyncSvc", который вы хотите перезапустить. Sad but true.
Ну как же так? Ладно, давайте остановим сервис CDPUserSvc, т.к. я не подключаю устройства, для которых он нужен. Только, пожалуйста, тот, который в моей сессии — не хочу случайно стопнуть чужой сервис.
Вы же говорите, что существующие тулзы прекрасно работают с этими новыми сервисами, так? Ну ладно, фиг с ним с настройками сервиса (которые выдают invalid parameter — см. заглавное сообщение). Но уж старт-стоп то мы должны получить на халяву, нет? Иначе не очень понятно, какие такие преимущества даёт нам запиливание этой функциональности в виде сервиса, а не обычного процесса.
blp>У нас с вами какое-то очень разное восприятие. Ну ок, бывает, чо. У вас собственное определение того, что таое "задача", что уж там со всем остальным.
Не, это как раз у вас очень собственное определение "задача". В стиле "подмети плац ломом". А что, тоже задача, не хуже других. Архитекторы системы формулируют задачи в стиле "обеспечить чистоту плаца при таких-то ограничениях". И там уже или метлой, или ломом, или спецтехникой.
blp>Оооо. Что ни заявление — то просто огонь. Еще раз: раньше per-user сервисов, создающихся на запуске не было. Ваши красивые рассуждения по имена и прочее — не особо интересны. Ну да, есть у вас такое мнение. Я особо с ним не спорю.
Во-первых, не при запуске, а при логоне. Во-вторых, понятно, что не было — непонятно, для чего они нужны. И непонятно, почему они так криво сделаны.
blp>Непонятно, как вы сделали такой вывод. Я вам многократно задаю вопрос, на который вы пока не ответили — сформулируйте какой именно сервис вы хотите перезапустить.
Я же вам написал — тот экземпляр сервиса, который запущен в моей сессии. Вы продолжаете выкручиваться.blp>Ничего я не проигнорировал. Я же ответил — это не per-user сервис. Причем он тут?
При том, что он спроектирован нормально, с учётом сценариев пользователя.
blp>Можно было. Но эти сервисы создаются людьми, которые указывают имя инстанса. per-user сервисы созаются и уничтожаются автоматически. Можете еще прикопаться к тому, что PID у процессов каждый раз разный и очень трудно процесс прибить, используя PID. Плохой дизайн, непродуманый!
Дизайн приемлемый. По крайней мере, в этом дизайне предусмотрен способ опознать тот из бесчисленных firefox.exe, который мне нужен.
blp>Начните сомневаться в том, что вы лучше людей из МСа, дизайнящих ОС, знаете как это делать. Полезно. Я, кажется, дал вам достаточно поводов об этом задуматься. Но если нет — то медицина тут бессильна
Я и так сомневаюсь
Просто моя вера в то, что люди из МС обладают какими-то священными свойствами, прошла лет двадцать тому назад.Познакомился с ними — такие же люди, как везде. В разработке — такой же бардак, как у нас. Решения — такие же, как у нас. Где-то — офигенные, где-то — слабые. А где-то вообще джуну дали реализовать, и там во все стороны верёвки торчат. Поэтому считаю совершенно нормальным обсуждать любые решения, принятые в Редмонде, не пытаясь сразу встать на позицию "раз это МС — значит это круто, даже если я не понимаю".
На всякий случай поясню: на позиции "раз винда — значит отстой" я тоже не стою.
Поэтому как раз интересно выяснить подробности — зачем вообще нужны per-user services, и являются ли они оптимальными для того, для чего позиционируются.
В MSDN про это ничего не написано. Остаётся только надеяться на то, что кто-то из евангелистов напишет таки блог про это. Либо, что на этом форуме найдутся люди, достаточно квалифицированные для обсуждения данного вопроса. В том смысле, что уже прочли MSDN вдоль и поперёк, и смогли сопоставить фрагменты документации для получения целостной картины.
Вы, вроде бы, как раз такой человек. Но почему-то всё время скатываетесь на обсуждение личности оппонентов и на задачи уровня "мне сказали запилить сервис — я запилил. Сказали бы запилить приложение — запилил бы приложение".
Вот представьте себя в роли архитектора. Вы пишете какое-то приложение для windows 10. Требования к нему формулирует product manager — в терминах прикладных сценариев. Ему вообще неважно, будет это сервис, пользовательский сервис, драйвер, или веб-страничка. В каких случях вы бы рассмотрели применение per-user service в рамках этого приложения? А в каких случаях бы решили обойтись без него?
У вас нет никакого senior architect, который примет решение за вас. Предположительно, вы настолько хорошо знаете "MSDN", что можете сами принять решение.