Угол обзора — средний. Ну т.е. не сильно уж узкий, но и не 100%. Сложно описать, представьте вы держите лист формата А4 перед лицом на расстоянии наверное ~20-25 сантиметров — вот какой-то такой. Края активной области — видны, но они не сильно мешают. Их перестаешь замечать когда делаешь что-то — всегда можно немного повернуть голову чтобы объект оказался ровно по центру и тогда с обзором проблем нет. Даже я бы сказал это иногда помогает сосредоточиться — я ради прикола увешал угол комнаты окнами браузера если видеть их все сразу — у меня сильно отвлекается внимание. А с ограниченным углом обзора — повернул голову и оказался в конкретном контексте — одно окно.
Из дополнительных замечаний — устаешь махать руками, зарядка для программиста конечно полезная штука, но так долго не поработаешь. Нужно что-то типа виртуальных рук, чтобы не двигать активно конечностями в пределах видимости камер в девайсе. С устройством идет кликер, но у нас он где-то был заныкан и я пользовался без него, так что не могу сказать насколько он облегчает жизнь.
Гоняем в офисе периодически. Все-таки девайс не готов к повседневной работе — в офисе свет не выключить а при ярких лампах такого классного погружения нет.
Очень интересно и удобно браузить и смотреть youtube — я бы себе взял подобный девайс для просмотра видео — никому не мешаешь и диагональ телевизора — любая. Rogue One ролик как в кинотеатре смотрится.
Немного тяжеловат, но привыкаешь быстро.
Уже видели что не всем подходит — есть люди у кого эффект вызывает тошноту и головокружение.
Ну и что-то надо делать с восприятием. Человек работающий в гололенз выглядит мягко говоря странно, даже неадекватно — машет руками делает странные жесты. Видно, что не в себе а в виртуальном мире каком-то.
Я бы сказал так — направление самое правильное — смешивать реальность и цифровой мир, осталось сделать устройство которое будет легче, компактнее и более автономное — нужно хотя бы сутки работы. А пока — очень классная, но все же игрушка, как и остальные гаджеты такого рода. И пока не хватает экосистемы приложений и дополнительных гаджетов. Руками 8 часов в день не намашешься.
И да, зарядный порт надо делать другим — Все-таки немного страшно в девайсе за $5к обломать USB порт, а заряжать приходится довольно регулярно.
Это "объектная" ориентация. Все в этом мире — объект. Потом чешут репу и удивляются обилию аллокаций и GC.
Хотя мне кажется тут автор пропустил один важный компонент — не хватает абстрактной фабрики провайдеров языков. Ну чтобы уж точно добить бедный простой switch-case. А то как-то предложенное решение не до конца "объектно" ориентированно.
Это рекордная для самого сайта krebsonsecurity.com.
Вообще то вот тут есть более интересный твит (похоже что использовали такой же или тот же IoT botnet)
Last days, we got lot of huge DDoS. Here, the list of "bigger that 100Gbps" only. You can see the simultaneous DDoS are close to 1Tbps ! pic.twitter.com/XmlwAU9JZ6
Ну мы в общем тоже давно забили на универсальных прокси-провайдеров и переключились на Serilog — просто написали тонкую прослойку-враппер над методами, которые мы вызываем (что может показаться оверкилом но делать некоторые конфигурации просто удобней в классе-враппере).
Вообще чем больше в интернете Logging as a service, тем больше приходишь к выводу что вот эти ребята предлагают тебе установить свой bottleneck за деньги. Современные логгеры настолько просты и удобны, что added value таких прокси в части scalability стремится к нулю. Хорошо если они еще какую-то аналитику предлагают по вашим логам, но чаще всего оказывается чтобы она работала — надо писать сообщения в service-specific формате ( что приводит к тому что эти фичи не работают при переходе между вендорами). Структурные логи в этом отношении спасают, т.к. хранят не конечный результат, а все исходные данные и могут отдать их в любой sink с сохранением большего количества деталей, чем "просто строка"
И к слову — структурированные логи оказались очень практичными и при поиске — можно делать запросы по данным не при помощи регэксов а по структуре сообщений и внутренних значений.
Хмм, и где вы нашли в моем комментарии что я что-то хочу этим компенсировать? Особенно пресловутое неумение программирования…
Вы очень пространно интерпретировали мой комментарий, похоже сильно им оскорбились (VB-погроммист?) и решили завуалировать ответное оскорбление в приписанных мне желаниях и отсутствиях компетенций.
Ну что ж, очень показательно.
А я, случайно, младенцев по ночам в вашей интерпретации не ем ??
Та же самая схема…
Ну учитывая что орлеанс хост жадный до памяти и CPU чтобы работать наиболее эффективно — засовывать все на одну машину все равно не рекомендуется, что в cloud service, что в SF. Сейчас вы это тоже можете сделать захостив Host или клиента в отдельном AppDomain, примеры есть в тестах. Это даст отсутствие раундтрипа по сети только если клиент обращается к зерну в сило на нем самом. А так — будете также общаться по сети между вебролями.
А теперь представьте кейс когда в SF у вас по какой-то причине на одной машине будет 2-3 сило крутиться и драться за CPU — чем это полезно то? Да, фабрика из коробки прикольная, но все же я бы ставил на орлеанс.
Ну кстати в сообществе, есть желание сделать глубокую интеграцию с SF, чтобы не было всякого головняка с деплоем и обновлениями. И я знаю что так некоторые делают (и мы тоже возможно соберемся). потому как орлеанс не предоставляет хостинг сам по себе — нужно или в консольке или в вин-сервисе или в клауд сервисе хостить. Там у каждого свой велосипед с обновлениями, кластером и мониторингом здоровья. А СФ именно предлагает полный стек — с хорошей штукой вокруг инфраструктуры и убого скопированной моделью акторов.
Низкоуровневые кейсы это например про описанный сценарий TcpListener. Может я не очень понял для чего такие сложности, хотя видно необходимы без поддержки клиентской подписки. А при наличии стримов — такие коммуникации организовываются очень просто.
Если кому интересно как работает атака, но читать оригинальные 26 страниц — TL;DR — есть неплохая статья на arstechnica.com
Там же есть и ссылки на описания Breach и Crime в стиле научпоп — не глубоко но подробнее чем — "Эээ, у нас проблема, назвали heist, интернет сломан, мы все умрем."
А почему не взяли Orleans? Из всего что вы описали выглядит так, что решение принималось — "потому что это Майкрософт", а не исходя из объективных потребностей проекта и удобств фреймворков.
А тут так много описаний низкоуровневых кейсов, т.е. то что фремворк призван решить и спрятать — он выдает наружу и создает сложности программистам. К тому же можно взгромоздить Orleans на SF в Stateless Worker, хотя мы чем дальше — тем более скептически смотрим на это решение. SF выглядит хорошо в плане возможностей devops, но в плане актеров — Orleans ощутимо впереди. В gitter проекта Orleans народ плачет когда их заставляют переходить на SF...
Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?
Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.
Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.
Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.
А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны
Если наступили на эти грабли и у вас перестал работать RDP к серверам — вот как вычистить эти эээ "настройки безопасности" через PowerShell ( выполнять под админом):
# these settings are the conflicting configuration on the client
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
# Remove these settings to restore NLA support for RDP and working latest RDP to Azure VMs
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
# Restore these settings to have protection from NTLM hash leak until there will be better ways to prevent the problem
#Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" -value 2
#Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" -value 2
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
Ага, отваливается в том числе и Azure VM RDP, причем жестко
Сегодня вот отобщался с саппортом который помогал восстановить доступ к машине по RDP. Печально вот так применять реестрик чтобы одну проблему исправить, а вторую, скрытую, добавить.
Угол обзора — средний. Ну т.е. не сильно уж узкий, но и не 100%. Сложно описать, представьте вы держите лист формата А4 перед лицом на расстоянии наверное ~20-25 сантиметров — вот какой-то такой. Края активной области — видны, но они не сильно мешают. Их перестаешь замечать когда делаешь что-то — всегда можно немного повернуть голову чтобы объект оказался ровно по центру и тогда с обзором проблем нет. Даже я бы сказал это иногда помогает сосредоточиться — я ради прикола увешал угол комнаты окнами браузера если видеть их все сразу — у меня сильно отвлекается внимание. А с ограниченным углом обзора — повернул голову и оказался в конкретном контексте — одно окно.
Из дополнительных замечаний — устаешь махать руками, зарядка для программиста конечно полезная штука, но так долго не поработаешь. Нужно что-то типа виртуальных рук, чтобы не двигать активно конечностями в пределах видимости камер в девайсе. С устройством идет кликер, но у нас он где-то был заныкан и я пользовался без него, так что не могу сказать насколько он облегчает жизнь.
У меня не устают, но это все индивидуально.
Гоняем в офисе периодически. Все-таки девайс не готов к повседневной работе — в офисе свет не выключить а при ярких лампах такого классного погружения нет.
Очень интересно и удобно браузить и смотреть youtube — я бы себе взял подобный девайс для просмотра видео — никому не мешаешь и диагональ телевизора — любая. Rogue One ролик как в кинотеатре смотрится.
Немного тяжеловат, но привыкаешь быстро.
Уже видели что не всем подходит — есть люди у кого эффект вызывает тошноту и головокружение.
Ну и что-то надо делать с восприятием. Человек работающий в гололенз выглядит мягко говоря странно, даже неадекватно — машет руками делает странные жесты. Видно, что не в себе а в виртуальном мире каком-то.
Я бы сказал так — направление самое правильное — смешивать реальность и цифровой мир, осталось сделать устройство которое будет легче, компактнее и более автономное — нужно хотя бы сутки работы. А пока — очень классная, но все же игрушка, как и остальные гаджеты такого рода. И пока не хватает экосистемы приложений и дополнительных гаджетов. Руками 8 часов в день не намашешься.
И да, зарядный порт надо делать другим — Все-таки немного страшно в девайсе за $5к обломать USB порт, а заряжать приходится довольно регулярно.
Это "объектная" ориентация. Все в этом мире — объект. Потом чешут репу и удивляются обилию аллокаций и GC.
Хотя мне кажется тут автор пропустил один важный компонент — не хватает абстрактной фабрики провайдеров языков. Ну чтобы уж точно добить бедный простой switch-case. А то как-то предложенное решение не до конца "объектно" ориентированно.
Это рекордная для самого сайта krebsonsecurity.com.
Вообще то вот тут есть более интересный твит (похоже что использовали такой же или тот же IoT botnet)
Ну мы в общем тоже давно забили на универсальных прокси-провайдеров и переключились на Serilog — просто написали тонкую прослойку-враппер над методами, которые мы вызываем (что может показаться оверкилом но делать некоторые конфигурации просто удобней в классе-враппере).
Вообще чем больше в интернете Logging as a service, тем больше приходишь к выводу что вот эти ребята предлагают тебе установить свой bottleneck за деньги. Современные логгеры настолько просты и удобны, что added value таких прокси в части scalability стремится к нулю. Хорошо если они еще какую-то аналитику предлагают по вашим логам, но чаще всего оказывается чтобы она работала — надо писать сообщения в service-specific формате ( что приводит к тому что эти фичи не работают при переходе между вендорами). Структурные логи в этом отношении спасают, т.к. хранят не конечный результат, а все исходные данные и могут отдать их в любой sink с сохранением большего количества деталей, чем "просто строка"
И к слову — структурированные логи оказались очень практичными и при поиске — можно делать запросы по данным не при помощи регэксов а по структуре сообщений и внутренних значений.
Хмм, и где вы нашли в моем комментарии что я что-то хочу этим компенсировать? Особенно пресловутое неумение программирования…
Вы очень пространно интерпретировали мой комментарий, похоже сильно им оскорбились (VB-погроммист?) и решили завуалировать ответное оскорбление в приписанных мне желаниях и отсутствиях компетенций.
Ну что ж, очень показательно.
А я, случайно, младенцев по ночам в вашей интерпретации не ем ??
Отличный способ избавиться от VB на планете!
Да, точно, это я смешал со своими размышлениями о потенциальных граблях Орлеанс когда они поверх SF… Мой косяк.
А вы кстати тут упомянуты ? Если нет — отправляйте PR, adoption cases всегда интересны.
а, про Tcp теперь понял, у нас наверное похожая ситуация с вебсокетами — стримы просто сказка для этого...
Та же самая схема…
Ну учитывая что орлеанс хост жадный до памяти и CPU чтобы работать наиболее эффективно — засовывать все на одну машину все равно не рекомендуется, что в cloud service, что в SF. Сейчас вы это тоже можете сделать захостив Host или клиента в отдельном AppDomain, примеры есть в тестах. Это даст отсутствие раундтрипа по сети только если клиент обращается к зерну в сило на нем самом. А так — будете также общаться по сети между вебролями.
А теперь представьте кейс когда в SF у вас по какой-то причине на одной машине будет 2-3 сило крутиться и драться за CPU — чем это полезно то? Да, фабрика из коробки прикольная, но все же я бы ставил на орлеанс.
Ну кстати в сообществе, есть желание сделать глубокую интеграцию с SF, чтобы не было всякого головняка с деплоем и обновлениями. И я знаю что так некоторые делают (и мы тоже возможно соберемся). потому как орлеанс не предоставляет хостинг сам по себе — нужно или в консольке или в вин-сервисе или в клауд сервисе хостить. Там у каждого свой велосипед с обновлениями, кластером и мониторингом здоровья. А СФ именно предлагает полный стек — с хорошей штукой вокруг инфраструктуры и убого скопированной моделью акторов.
Низкоуровневые кейсы это например про описанный сценарий TcpListener. Может я не очень понял для чего такие сложности, хотя видно необходимы без поддержки клиентской подписки. А при наличии стримов — такие коммуникации организовываются очень просто.
Если кому интересно как работает атака, но читать оригинальные 26 страниц — TL;DR — есть неплохая статья на arstechnica.com
Там же есть и ссылки на описания Breach и Crime в стиле научпоп — не глубоко но подробнее чем — "Эээ, у нас проблема, назвали heist, интернет сломан, мы все умрем."
А почему не взяли Orleans? Из всего что вы описали выглядит так, что решение принималось — "потому что это Майкрософт", а не исходя из объективных потребностей проекта и удобств фреймворков.
А тут так много описаний низкоуровневых кейсов, т.е. то что фремворк призван решить и спрятать — он выдает наружу и создает сложности программистам. К тому же можно взгромоздить Orleans на SF в Stateless Worker, хотя мы чем дальше — тем более скептически смотрим на это решение. SF выглядит хорошо в плане возможностей devops, но в плане актеров — Orleans ощутимо впереди. В gitter проекта Orleans народ плачет когда их заставляют переходить на SF...
Теперь понятно, спасибо. Это печалька что при использовании NLA опять надо быть или доменным пользователем или ходить со старым NTLM
Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?
Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.
Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.
Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.
А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны
Если наступили на эти грабли и у вас перестал работать RDP к серверам — вот как вычистить эти эээ "настройки безопасности" через PowerShell ( выполнять под админом):
Ага, отваливается в том числе и Azure VM RDP, причем жестко
Сегодня вот отобщался с саппортом который помогал восстановить доступ к машине по RDP. Печально вот так применять реестрик чтобы одну проблему исправить, а вторую, скрытую, добавить.