Всё же в вашей статье отчетливо читается некая предвзятость. Не знаю осознанно или из экономии времнии на поиск более убедительных и строгих аргументов, но в статье вы постоянно манипулируете мнением читателя:
И здесь на сцену выходит Docker, эдакая смесь виртуализации, разграничения ресурсов и способа поставки. Это сейчас модно, молодежно, но нужен ли он для всего? Панацея ли это?
В какой-то момент к нам начали приходить свежеиспеченные мидлы, бурлящие идеями и бредящие докером. Что ж, флаг в руки — делаем! Было две попытки. Обе неудачных — скажем так, из-за больших амбиций, но недостаточности реального опыта. Надо ли было форсировать и доделывать любыми силами? Вряд ли — коллектив должен эволюционно дорасти до нужного уровня [..]
С другой стороны, чем Spring-сервис в виде jar-архива хуже деплоить через тот же deb? Реально ли нужна изоляция ресурсов? Стоит ли лишаться удобных инструментов операционной системы, запихивая сервис в сильно урезанный контейнер?
Как показала практика — в реальности это не нужно, deb-пакета хватает в 90% случаев.
При этом перечисленные вами проблемы при использовании контейнеров — это либо признаки не совсем правильного использования контэйнеризации (в плане логов или шелла внутри контейнера), либо «какие-то частные непонятные проблемы», в суть которых, видимо, никто не углублялся (проблемы с сетью, странные зависания ElasticSearch), либо понятные и по-разному решаемые особенности докеризации, которые, по сути, и есть та компромиссная часть trade-off, на которую мы смотрим решая допустимо ли перевести систему на docker (размеры контейнеров, скорость сборки).
Да, докер не панацея и, чем у'же убласть, тем больше поводов смотреть на частные и альтернативные решения. Однако, чем шире мы смотрим на индустрию, тем в лучшем свете представляется докер, ведь он хорош своим движением в сторону универсализации и унификации.
Квинтесценция манипулятивности и некоторой нелогичности вашей статьи на мой взгляд в этой цитате:
По моим наблюдениям, очень часто Docker предлагается не как разумный выбор, а просто потому, что об этом, с одной стороны, говорят в сообществе, и те, кто предлагают, только его и знают. С другой стороны, о старых добрых системах упаковки по большей части молчат — они есть и есть, свое дело делают тихо и незаметно.
Я там наподчёркивал то, что меня, прям, покоробило. Тут и отсылка к личному опыту, и странное обобщение, будто бы о докере говорят исключительно те, кто лишь его только и знает…
Лично я, когда такое читаю, сразу задумываюсь о предвзятости мнений и о направлении причинно-следственных связей. Почему об одном молчат, а о другом кричат? Если бы вы нейтрально рассмотрели плюсы и минусы без манипуляций, то как по-вашему, статья стала бы менее объективной? Может быть она дала бы читателям лишнюю возможность сделать неверные выводы? Ну не знаю…
Вы только не обежайтесь, уважаемый автор. Я постарался внести конструктивную критику вашей статьи. Из моих тезисов, конечно, не следует, что вы не правы по существу, что докер в вашем юзкейсе более верное решение, и даже что в сторону докера нет излешнего перекоса в среде хипстеров от девопса=).
Да уж, отстал я от жизни. За последний год посмотрел лишь пару фильмов и ни одного сериала.=( Как-то всё некогда.
Зато я прослушал довольно много аудиокниг, а еще больше прочитал раньше, когда ваших сериалов не было. К сожалению у нас теперь разные референсы. На пенсии постараюсь догнать=)
Люди нужны как среда для эволюции мемов. Идеи — это тоже мемы, они рождаются, конкурируют и умирают. Без эволюции мемов будет стагнация или даже угасание, поскольку антропия растёт, а ресурсы тратятся. Если останется мало свободных агентов, если не будет избыточности, прогресс прекратится, а потом начнётся упадок, на руинах которого снова заведутся более простые «организмы» и начнут свою ветку эволюции.
Именно это я и имел в виду. И не обязательно. что мы найдём более развитую ситуацию, просто натолкнуться на любую жизнь есть больше шансов, если ищем и стараемся понять мы вообще всё непонятное, чем только то, что, как мы сейчас считаем, похоже на проявления цивилизации.
а сильный ИИ начнет с замены мозга на WiFi модуль и прямое управление
Зачем сильному ИИ ваша жалкая тушка, когда можно сконструировать более эффективные, сильные, точные манипуляторы? Почему вообще есть мнение, что будет какой-то мгновенный скачок, когда «появится сильный ИИ» и всех поработит? Это из разряда: «вот придёт человек в нашу бабуинскую рощу и отнимет все бананы», или, к примеру, кот рычит на всякий случай на человека, потому что боится, что тот у него мышь отнимет… У "внезапного сильного ИИ с возможностями, внезапно и многократно превосходящими человеческие" будут, надо полагать, и амбиции соответствующие, и интересы. На кой черт ему забирать нашу вонючую косточку? Вот если его возможности и скорость развития будут не сильно превосходить наши и смогут возникнуть конфликты интересов, то, возможно, и будет какая-то «война» за ресурсы. Но при меньших этих разницах и победа будет не столь стремительной и не столь однозначной, как пророчится.
Ещё один аспект, который постоянно упускается, это возможность и вероятность интеграции и ассимиляции искусственного и естественного интеллектов. Если искусственный интеллект будет совершенствоваться плавно и неспеша (как это, в общем-то, сейчас и происходит с Сири, Алисой, алгоритмами поисковой выдачи и рекламмных интеграций), то вполне вероятна и ожидаема ситуация, когда ИИ станет своеобразным расширителем нашего естественного интеллекта. Тут полная аналогия с автомобилями и поездами, которые заменяют нам сильные ноги и выносливость многократно при этом повышая возможности. Также калькуляторы заменяют нам умение считать в уме, органайзеры и записные книжки заменяютпамять, книги, видеоигры, фильмы заменяют интеллектуальный груминг у костра, инсулин в шприцах заменяет собственный инсулин… Всё это сильно интегрировалось в нашу культуру. Современный человек без цивилизации просто нежизнеспособен в подавляющей своей массе. Ну представьте, что по всему миру в одно мгновение исчезла электроэнергия, канализация и водопровод, какой процент населения погибнет, если, ну скажем инопланетяне, просто не дадут восстановить эти блага.
Так же в наш быт может быть тесно и глубоко интегрирован ИИ. Глубже, чем сейчас письменность, календари, органайзеры, смартфоны, мессенджеры и компьютеры. Часть рутинных вещей вполне воможно за нас будет когда-то делать наша электронная половина. Эта «половина» настолько плавно может вырасти и стать восьмидесятью процентами и больше, что мы как лягушки не заметим как «сваримся» в электронном супе и это будет всех устраивать кроме мелкой кучки электронных шовинистов-ретроградов. И нет, я не вижу в этом ничего плохого, как не вижу ничего плохого в некотором «отупении» человека современного по отношению к первобытным людям, которым нужны были гораздо более гибкие и сметливые мозги в их опасном мире.
Вот зашел в каменты написать то же самое и, к приятному удивлению, увидел эту мысль, изложенную неоднократно многими здесь. Но остаётся вопрос, неужели все эти люди из SETI и те, что сейчас продвигают поиск цивилизаций не приходят к тем же выводам? Это же очень логично!
Какой смысл искать «отражение самих себя» вокруг во вселенной, когда мы сами такими будем жалкие 10-20 лет и изменимся до неузнаваемости?
Если учесть плотность звёзд в галлактике, то можно понять насколько мизерна вероятность попасть своей «щелью» восприятия в пространстве и времени на узкий пик похожести технопризнаков чужой на нашу цивилизацию.
Зачем тратить огромные ресурсы на эти поиски, если можно третить эти ресурсы на просто познание и понимание устройства окружающего мира? Возможно более эффективные способы наблюдать и передавать информацию лежат совсем рядом, а мы вместо этих способов ищем «паровые котлы» и «каменные топоры».
Я не сторонник рассуждений вида «давайте вместо того, лучше сделаем это», но здесь явно какой-то нерациональный путь наблюдается.
А нужно отдельный мещочек для каждой пары? Подозреваю, что как только в один мешочек будет помещено несколько пар, после стирки их станет как минимум нечетное количество в этом мешочке, а возможно. что половина потеряет симметричную пару по цвету, и спину (и аромату, но потеря этого признака в данном случае логична).
Дело в том, что маленький докер-файл, размещенный в репозитории, не отменит возможности поставить и запускать проект через virtualenv или вовсе глобально. Просто будет дополнительный способ развернуть приложение быстро и просто, возможно с маленькими накладными расходами. Почему бы не предоставить право выбирать способ установки конечному пользователю? Кроме того, докер позволит без танцев с бубном развернуть вашего бота на каком-нибудь NAS вроде synology или на современном медиа-плеере. Да, контейнер будет прилично весить по сравнению с «чистой» установкой, но такие ресурсы нынче дешевы.
Коллега vassabi в соседнем комментарии прав, не знаю кто влепил ему минус за вполне разумную точку зрения.
С другой стороны, не очень понятен ваш экспрессивно негативный тон отзыва о докере и его применимости в данном случае. Невольно читается какое-то предвзятое отношение.
Питон, конечно, старается быть на всех платформах одинаковым, и у него немножко это даже местами получается, но унификация, прсотота и изоляция докера перевешивает. Кстати, запускать какой-то чужой код, пусть даже бегло просмотренный ввиду своих невеликих размеров, спокойнее в изолированной среде отдельного контейнера, а не на сервере, где грутится помимо всего прочего много полезных и нужных вещей вроде сайта (тоже в контейнерах) и прочих более важных сервисов, чем какой-то чат-бот.
Почему? Докер же беспрецедентно прекрасен. Если у вас пачка специфических зависимостей, то спрятать их в контейнер — это лучшее, что можно придумать для тех, кому нужно «ехать», а не «шашечки». Те, кому «шашечки», всё и так поставят да развернут, пропишут и запустят, но докер даёт унификацию и изоляцию.
Вообще, у меня, простите, бомбануло. Обоснуйте, пожалуйста, подробнее почему вы думаете, что контейнеризация в этом проекте не уместна?
Да что там переделывать-то?
Однако даже в 2 питоне есть простое правило: на входе декодируем, на выходе кодируем, внутри только юникод.
Проблема с символами, кстати, в данном случае на уровне Windows. Там до сих пор встречаются ситуации, когда командная строка и входные параметры интерпретируется как win866 (запрещенная в разумном мире однобайтовая кодировка), а терминал, куда пишет stdout, в win1251 (запрещенная в разумном мире однобайтовая кодировка).
Можно задекорировать stdout в перекодирующий поток. Там, в общем-то, так и задумано из коробки, но для винды имеет смысл это сдедалть явно, поскольку не всегда можно получить от stdout его кодировку через атрибут. Ошибка возникает в двух случаях: 1) когда кодировка не определена и принимается как ascii, соответственно любые не ascii символы будут конвертироваться с ошибкой; 2) когда в строке попадаются символы, которым нет аналогов в однобайтной кодировке (длинные тире, мягкие переносы и всякое такое). Первый пункт у вас решен, второй вы решаете заменой некоторых символов. Я бы настроил дополнительно конвертацию с игнором или автозаменой непредставимых символов. И я бы всё же не работал внутри программы с кодированными (не юникодными) строками. Это плохая примета=)
Ой, ну мало ли… Например мы хотим фитнес-функцию какую-то сделать атрибутом класса. Можно, конечно, завернуть её в декортаор `staticmethod` всё станет гораздо прозрачнее…
Вообще в питоне порой встрачаются разные извращения, когда классы используются, например, как способ сгруппировать константы и настройки, когда классы используютсядля для всякой неявной подкапотной черной магии, когда ещё на этапе объявления классы где-то там регистрируются, формируют какие-то индексы… Можно долго спорить о целесообразности или нецелесообразности конкретных решений, но потенциальна ягибкость, конечно, радует.
Нет, мне не сложно, поскольку я планомерно избавляюсь от винды везде где мне это критично. Даже работу выбираю такую, где можно подальше держаться от этой операционной системы. Мы сами себе формируем комфортную среду.
Это самый тупой способ решить проблему. Правильнее было бы просто с прогрессирующей степенью навязчивости напоминать в заведомо подходящие моменты. В конце концов в «руках» операционной системы статистика многих сотен сеансов работы пользователя. Можно выделить паттерны и предлагать обновление в момент ожидаемого окончания сеанса работы пользователя, а не в момент ожиаемого начала сеанса.
К примеру, если один из типичных паттернов пользователя — это заход на некий конкретный сайт, раскрытие видео на полный экран и через некоторое время закрытие вкладки прекрачшение сеанса работы, то оптимальный момент НАПОМНИТЬ об обновлении — это при закрытии той вкладки. Один клик переда почти гарантированным периодом неиспользования компьютера — это оптимальный вариант.
Представьте каково будет раздражение пользователя, если принудительное обновление начнётся в начали или в середине такого типичного сеанса.
Ещё раз. Всегда есть спосбо что-то сделать лучше чем есть. Почти всегда за счет инженерных масштабируемых решений можно сделать это с небольшими эффективными затратами на разработку. Это именно тот самый случай.
В том-то и суть задачи, что не вариант. Иначе было бы слишком просто. ну представьте, что есть два изолированных подразделения спецназа. которые даже не знают друг о друге и в какой-то момент по одному бойцу из каждого десантируют по условиям задачи. Возможности договориться у них, конечно, не будет, но подразумевается, что они знают одно и то же о задании и, соответственно, могут выбрать какую-то оптимальную стратегию.
Где-то там прозвучало условие, что стратегия у них должна быть одинаковая. Но это скорее не условие, а логичное следствие (из теории игр) того, что обмениваться информацией они не могут, и, видимо, должна быть какая-то одна оптимальная стратегия, придерживаясь которой оба «игрока» окажутся в выигрыше.
Ну об этом же вся статья, почитайте.
И как они решат без передачи информации кто будет стоять, а кто ходить? Если ориентироваться на монетку, то возможны ситуации, когда оба будут стоять или оба ходить. У них нет в кармане квантово-запутанных между собой фотонов для принятия гарантированно противоположных решений.
Отлично. Не было печали. Вот мне теперь еще и проверять регулярно обновления не хватало. Может мне и дефрагментацию раз в неделю делать и ещё какое-то обслуживание?!
Есть вполне понятный и простой способ сделать лучше и не усложнять жизнь неожиданными перезагрузками и обновлениями:
1. Спрашивать у пользователя не «точное время когда обновиться» а «через сколько напомниить об обновлении»;
2. Дать возможность пользователю запустить обновление в тот момент, когда он хочет одним (или двумя) кликами из систем-трея, даже если до назначенного времени обновления еще 15 минут или два часа. Почему-то в винде не так просто найти как запустить отложенное обновление. не два клика в систем-трее.
3. Напоминать пользователю об обновлении не тогда, когда он скорее всего начинает чем-то заниматься, а тогда, когда он заканчивает чем-то заниматься. Очевидно, что включив компьютер пользователь имеет какие-то другие планы, нежели потретить пол часа на обновление.
Наверно есть люди, котороых не раздражают такие вещи. Видимо вы относитесь именно к такой категории. Чтобы какие-то предметы вам не доставляли неудобства вы готовы менять привычки, работать над собой и делать лишнее. Наверно это замечательное и полезное качество, но меня, как инженера, унижает такое доминирование окружения. Я не хочу подстраиваться под лишние особенности окружающих меня интерфейсов и систем. Мне важно, чтобы все вторичные сервисные сущности меня трогали минимально, минимально влияли на моё поведение, мои привычки, моё настроение и планы.
При этом перечисленные вами проблемы при использовании контейнеров — это либо признаки не совсем правильного использования контэйнеризации (в плане логов или шелла внутри контейнера), либо «какие-то частные непонятные проблемы», в суть которых, видимо, никто не углублялся (проблемы с сетью, странные зависания ElasticSearch), либо понятные и по-разному решаемые особенности докеризации, которые, по сути, и есть та компромиссная часть trade-off, на которую мы смотрим решая допустимо ли перевести систему на docker (размеры контейнеров, скорость сборки).
Да, докер не панацея и, чем у'же убласть, тем больше поводов смотреть на частные и альтернативные решения. Однако, чем шире мы смотрим на индустрию, тем в лучшем свете представляется докер, ведь он хорош своим движением в сторону универсализации и унификации.
Квинтесценция манипулятивности и некоторой нелогичности вашей статьи на мой взгляд в этой цитате:
Я там наподчёркивал то, что меня, прям, покоробило. Тут и отсылка к личному опыту, и странное обобщение, будто бы о докере говорят исключительно те, кто лишь его только и знает…
Лично я, когда такое читаю, сразу задумываюсь о предвзятости мнений и о направлении причинно-следственных связей. Почему об одном молчат, а о другом кричат? Если бы вы нейтрально рассмотрели плюсы и минусы без манипуляций, то как по-вашему, статья стала бы менее объективной? Может быть она дала бы читателям лишнюю возможность сделать неверные выводы? Ну не знаю…
Вы только не обежайтесь, уважаемый автор. Я постарался внести конструктивную критику вашей статьи. Из моих тезисов, конечно, не следует, что вы не правы по существу, что докер в вашем юзкейсе более верное решение, и даже что в сторону докера нет излешнего перекоса в среде хипстеров от девопса=).
Зато я прослушал довольно много аудиокниг, а еще больше прочитал раньше, когда ваших сериалов не было. К сожалению у нас теперь разные референсы. На пенсии постараюсь догнать=)
Зачем сильному ИИ ваша жалкая тушка, когда можно сконструировать более эффективные, сильные, точные манипуляторы? Почему вообще есть мнение, что будет какой-то мгновенный скачок, когда «появится сильный ИИ» и всех поработит? Это из разряда: «вот придёт человек в нашу бабуинскую рощу и отнимет все бананы», или, к примеру, кот рычит на всякий случай на человека, потому что боится, что тот у него мышь отнимет… У "внезапного сильного ИИ с возможностями, внезапно и многократно превосходящими человеческие" будут, надо полагать, и амбиции соответствующие, и интересы. На кой черт ему забирать нашу вонючую косточку? Вот если его возможности и скорость развития будут не сильно превосходить наши и смогут возникнуть конфликты интересов, то, возможно, и будет какая-то «война» за ресурсы. Но при меньших этих разницах и победа будет не столь стремительной и не столь однозначной, как пророчится.
Ещё один аспект, который постоянно упускается, это возможность и вероятность интеграции и ассимиляции искусственного и естественного интеллектов. Если искусственный интеллект будет совершенствоваться плавно и неспеша (как это, в общем-то, сейчас и происходит с Сири, Алисой, алгоритмами поисковой выдачи и рекламмных интеграций), то вполне вероятна и ожидаема ситуация, когда ИИ станет своеобразным расширителем нашего естественного интеллекта. Тут полная аналогия с автомобилями и поездами, которые заменяют нам сильные ноги и выносливость многократно при этом повышая возможности. Также калькуляторы заменяют нам умение считать в уме, органайзеры и записные книжки заменяютпамять, книги, видеоигры, фильмы заменяют интеллектуальный груминг у костра, инсулин в шприцах заменяет собственный инсулин… Всё это сильно интегрировалось в нашу культуру. Современный человек без цивилизации просто нежизнеспособен в подавляющей своей массе. Ну представьте, что по всему миру в одно мгновение исчезла электроэнергия, канализация и водопровод, какой процент населения погибнет, если, ну скажем инопланетяне, просто не дадут восстановить эти блага.
Так же в наш быт может быть тесно и глубоко интегрирован ИИ. Глубже, чем сейчас письменность, календари, органайзеры, смартфоны, мессенджеры и компьютеры. Часть рутинных вещей вполне воможно за нас будет когда-то делать наша электронная половина. Эта «половина» настолько плавно может вырасти и стать восьмидесятью процентами и больше, что мы как лягушки не заметим как «сваримся» в электронном супе и это будет всех устраивать кроме мелкой кучки электронных шовинистов-ретроградов. И нет, я не вижу в этом ничего плохого, как не вижу ничего плохого в некотором «отупении» человека современного по отношению к первобытным людям, которым нужны были гораздо более гибкие и сметливые мозги в их опасном мире.
Какой смысл искать «отражение самих себя» вокруг во вселенной, когда мы сами такими будем жалкие 10-20 лет и изменимся до неузнаваемости?
Если учесть плотность звёзд в галлактике, то можно понять насколько мизерна вероятность попасть своей «щелью» восприятия в пространстве и времени на узкий пик похожести технопризнаков чужой на нашу цивилизацию.
Зачем тратить огромные ресурсы на эти поиски, если можно третить эти ресурсы на просто познание и понимание устройства окружающего мира? Возможно более эффективные способы наблюдать и передавать информацию лежат совсем рядом, а мы вместо этих способов ищем «паровые котлы» и «каменные топоры».
Я не сторонник рассуждений вида «давайте вместо того, лучше сделаем это», но здесь явно какой-то нерациональный путь наблюдается.
Коллега vassabi в соседнем комментарии прав, не знаю кто влепил ему минус за вполне разумную точку зрения.
С другой стороны, не очень понятен ваш экспрессивно негативный тон отзыва о докере и его применимости в данном случае. Невольно читается какое-то предвзятое отношение.
Питон, конечно, старается быть на всех платформах одинаковым, и у него немножко это даже местами получается, но унификация, прсотота и изоляция докера перевешивает. Кстати, запускать какой-то чужой код, пусть даже бегло просмотренный ввиду своих невеликих размеров, спокойнее в изолированной среде отдельного контейнера, а не на сервере, где грутится помимо всего прочего много полезных и нужных вещей вроде сайта (тоже в контейнерах) и прочих более важных сервисов, чем какой-то чат-бот.
Вообще, у меня, простите, бомбануло. Обоснуйте, пожалуйста, подробнее почему вы думаете, что контейнеризация в этом проекте не уместна?
Однако даже в 2 питоне есть простое правило: на входе декодируем, на выходе кодируем, внутри только юникод.
Проблема с символами, кстати, в данном случае на уровне Windows. Там до сих пор встречаются ситуации, когда командная строка и входные параметры интерпретируется как win866 (запрещенная в разумном мире однобайтовая кодировка), а терминал, куда пишет stdout, в win1251 (запрещенная в разумном мире однобайтовая кодировка).
Можно задекорировать stdout в перекодирующий поток. Там, в общем-то, так и задумано из коробки, но для винды имеет смысл это сдедалть явно, поскольку не всегда можно получить от stdout его кодировку через атрибут. Ошибка возникает в двух случаях: 1) когда кодировка не определена и принимается как ascii, соответственно любые не ascii символы будут конвертироваться с ошибкой; 2) когда в строке попадаются символы, которым нет аналогов в однобайтной кодировке (длинные тире, мягкие переносы и всякое такое). Первый пункт у вас решен, второй вы решаете заменой некоторых символов. Я бы настроил дополнительно конвертацию с игнором или автозаменой непредставимых символов. И я бы всё же не работал внутри программы с кодированными (не юникодными) строками. Это плохая примета=)
Вообще в питоне порой встрачаются разные извращения, когда классы используются, например, как способ сгруппировать константы и настройки, когда классы используютсядля для всякой неявной подкапотной черной магии, когда ещё на этапе объявления классы где-то там регистрируются, формируют какие-то индексы… Можно долго спорить о целесообразности или нецелесообразности конкретных решений, но потенциальна ягибкость, конечно, радует.
К примеру, если один из типичных паттернов пользователя — это заход на некий конкретный сайт, раскрытие видео на полный экран и через некоторое время закрытие вкладки прекрачшение сеанса работы, то оптимальный момент НАПОМНИТЬ об обновлении — это при закрытии той вкладки. Один клик переда почти гарантированным периодом неиспользования компьютера — это оптимальный вариант.
Представьте каково будет раздражение пользователя, если принудительное обновление начнётся в начали или в середине такого типичного сеанса.
Ещё раз. Всегда есть спосбо что-то сделать лучше чем есть. Почти всегда за счет инженерных масштабируемых решений можно сделать это с небольшими эффективными затратами на разработку. Это именно тот самый случай.
Где-то там прозвучало условие, что стратегия у них должна быть одинаковая. Но это скорее не условие, а логичное следствие (из теории игр) того, что обмениваться информацией они не могут, и, видимо, должна быть какая-то одна оптимальная стратегия, придерживаясь которой оба «игрока» окажутся в выигрыше.
Ну об этом же вся статья, почитайте.
1. Внезапность такой задачи.
2. Забывание о том, что на какое-то время назначил обновление.
Мне не хочется тратить когнитивный ресурс на тупые интерфейсы,. запоминание ненужной информации и учитывание незначительных для меня расписаний.
Есть вполне понятный и простой способ сделать лучше и не усложнять жизнь неожиданными перезагрузками и обновлениями:
1. Спрашивать у пользователя не «точное время когда обновиться» а «через сколько напомниить об обновлении»;
2. Дать возможность пользователю запустить обновление в тот момент, когда он хочет одним (или двумя) кликами из систем-трея, даже если до назначенного времени обновления еще 15 минут или два часа. Почему-то в винде не так просто найти как запустить отложенное обновление. не два клика в систем-трее.
3. Напоминать пользователю об обновлении не тогда, когда он скорее всего начинает чем-то заниматься, а тогда, когда он заканчивает чем-то заниматься. Очевидно, что включив компьютер пользователь имеет какие-то другие планы, нежели потретить пол часа на обновление.
Наверно есть люди, котороых не раздражают такие вещи. Видимо вы относитесь именно к такой категории. Чтобы какие-то предметы вам не доставляли неудобства вы готовы менять привычки, работать над собой и делать лишнее. Наверно это замечательное и полезное качество, но меня, как инженера, унижает такое доминирование окружения. Я не хочу подстраиваться под лишние особенности окружающих меня интерфейсов и систем. Мне важно, чтобы все вторичные сервисные сущности меня трогали минимально, минимально влияли на моё поведение, мои привычки, моё настроение и планы.