1. Хорошо, но для подземной базы должно сработать? А над водой это как работает — по поверхности дна или по уровню воды? Кажется, что подлодки или подводные базы тоже помогут. Поэтому Ельцин в своё время хотел встретиться с Клинтоном на подводной лодке, да? Он что-то знал? Нужно с помощью сайта проследить за Ельциным — есть подозрение, что некоторые из людей в прошлом уже были в курсе ограничений технологии. Впрочем, максимальная известная глубина погружения сегодняшней подлодки — около 1 км, что меньше объявленного лимита. Поэтому, наверное, Клинтон и не согласился — тоже всё знал, зараза?
4. Окей, тут всемогущие инопланетяне меня победили :)
5. Работа с документами — это в том числе их чтение (для ознакомления с секретными материалами — наверное, в первую очередь именно оно?). Читать документы с помощью технологии можно и «по телевизору», если знаешь, где они расположены, или где они располагались раньше. Ну и небольшое ноу-хау: можно формировать другие изображения из фрагментов трансляции сайта. Например, берём две трансляции, со светлым и тёмным фоном, и вместо foreground у текста ставим
6. Ну а человек в гипотетическом «доспехе» из экранов (повёрнутых наружу) зацензурируется? А где-нибудь в глазах смотрящего мы не сможем разглядеть изображение, на которое он смотрит? Ну и давайте тогда внедрять везде проекторы вместо экранов (ну или иные технологии просмотра данных, которые не приводят к цензуре), чтобы защиту пользователей нивелировать. Необязательно это делать топорно, можно и более-менее рыночными методами — субсидии вводить на производство проекторов, вкладывать ресурсы в нецензурируемые технологии. Инопланетяне хотят от нас что-то скрыть, и мы им будем мешать это делать.
7. То есть, если я сгенерирую фотографию, пиксель в пиксель соответствующую реальной фотографии — то по моей фотографии поиск не будет работать, а по реальной будет? Он как-то отслеживает источники каждого идентичного набора битов?
Ну и вот вам ещё одна интересная идейка: можно ли сайт использовать для мгновенных коммуникаций в пределах земного шара? Если с помощью сайта я смогу в реальном времени следить за отдалённой от меня на 16 тыс. км. точкой пространства — это экономия примерно 0.05 с (если я не ошибся в расчётах), что довольно немало; HFT-торговцы революционизируют свой бизнес. Хотя они и так его революционизируют, когда смогут к тому же следить за будущим :)
Вот тут приводили ещё несколько любопытных вариантов промышленного применения схожей технологии (магических зеркал).
У меня есть ряд интересных идей, которые можно использовать в борьбе со всемогущими инопланетянами. Считаю, что ограничения, которые они вложили в технологию, указывают на их слабости, и поэтому эти ограничения следует эксплуатировать по максимуму.
Ограничение в 2033 м — правильно ли я понял, что имеется в виду, что нам доступна для просмотра полоса от 2033 м ниже уровня моря до 2033 м выше уровня моря? Это означает, что:
Мы сможем хранить секретные материалы вне этого диапазона. Согласитесь, нетрудно представить себе секретные эксперименты где-нибудь на высокой горе или вообще на орбитальной станции, ну или хранение опасных материалов где-нибудь в глубоченной скважине.
Непонятно, как это будет работать с поиском людей по фотографии. Если они выйдут за пределы диапазона — что из этого получится? Мы сможем выйти за пределы ограничений в 2033? А камеру там крутить можно будет? А двигать? Похоже на дыру в системе.
Следует запустить группу каких-нибудь нейросетей на автоматическое исследование всех доступных фрагментов поверхности Земли и мирового океана на пределах видимости сайта. Возможно, мы сможем найти там что-то интересное — какие-нибудь неучтённые постройки или элементы инфраструктуры, ведущие «в никуда», которые на самом деле приведут нас в логово тех, кто всё это замыслил. Зачем нейросети? А на случай, если фрагменты изображений будут цензурироваться: по несоответствиям границ кадров или ещё каким-нибудь косвенным признакам можно будет попробовать это установить.
Очень интересным кажется свойство защиты от лукавого, вот вам несколько идей:
Во-первых, нужно исследовать границы технологии: маскируются только прямые трансляции непосредственно с сайта? А что, если смотреть их в записи? А что, если смотреть фрагменты записей? Фотографии, вырезанные из записей, или и фрагменты? А что, если художник, глядя на фотографию записи, будет её перерисовывать краской — в какой момент будет включаться цензура, и что она будет цензурировать?
Видится, что действия пользователей сайта всё равно можно будет отслеживать, просто наблюдая за движениями их рук (какие клавиши нажимают на клавиатуре) или подслушивая их голосовые команды.
Ну и, наконец, как вам такое? Наши сотрудники будут работать с документами не напрямую, а разглядывая их через средства сайта. Таким образом, нельзя будет понять, с чем же работает сотрудник, и некоторый уровень секретности будет сохранён.
Нарядим наш спецназ в костюмы, на поверхность которых проецируются изображения с сайта. И встроим прожекторы, которые на все окрестности тоже проецируют изображения с сайта. Приведёт ли это к полноценному цензурированию всех освещённых поверхностей? Можно ли будет на сайте что-то рассмотреть во время применения такой «светомузыки»?
Поиск людей по фотографии — тоже интересная затея сама по себе. Что, если взять фотографии, снятые до временной отсечки? Ну, Туринскую плащаницу какую-нибудь, а — ведь говорят, что она тоже была создана типа фотографическим способом? Или изображения с камер-обскур, если сохранились. Попахивает как минимум ещё одной волной сектантов :) А что, если мы начнём искать мёртвых людей — будет ли сайтик показывать нам, где находятся их тела, или же покажет из загробную жизнь? А что, если генерировать лица людей и пытаться найти по ним что-нибудь? Это будет работать? Не найдём ли мы таким способом чего интересного, если сгенерируем триллион зелёнокожих лиц? Не попадём ли рано или поздно в одного из инопланетян?
Вы исходите из предпосылки, что F# — это только про ФП. А между тем там есть и ООП-штуки, и некоторые из них очень интересные — object expressions, например, которых временами не хватает в C#.
Сильно зависит от вашего опыта в работе с тем и другим. Я бы вот скорее сказал, что моему опыту это утверждение не соответствует: интероп обычно прозрачен и прост.
Ваш случай с сетевыми пакетами и колбэками очень хорошо и аутентично решается в Erlang (в котором, если я правильно помню, вообще нет мутабельных переменных): этот функциональный язык программирования вообще хорошо подходит для решения такого рода задач. Здесь решение будет строиться на акторах: заведём, например, какого-нибудь глобального диспетчера, которому будут приходить сообщения из колбэков ОС, а он будет их раздавать акторам — которые, например, считают количество полученных сообщений. Код внутри акторов не мутирует никаких переменных, а просто принимает старое состояние (и пришедшее сообщение), а возвращает новое состояние (ну или рекурсивно себя вызывает с этим новым состоянием).
(При этом я полагаю, что где-то в глубине акторного фреймворка может быть мутабельный код, но в Erlang его вам никто не показывает.)
В F# может быть использовано то же самое решение — ведь у нас в .NET тоже есть акторные фреймворки — а ещё есть встроенные акторы в стандартной библиотеке F#, которые также позволят обойтись без mutable в пользовательском коде.
Если я правильно помню, одним из критериев, который разрешает отдавать любую информацию о вас, в соответствии с GDPR является требование закона. Иначе сервисы бы и от их собственных правоохранителей были обязаны скрывать информацию, а это абсурдно.
Ну, в таком случае нам остаётся пригласить товарища в багтрекер расширения: пускай оформит там возникшие у него проблемы, и тогда их можно будет починить!
А что бы вы хотели «из коробки»? Уже за вас всё реализовано. Вы просто берёте и пишете код на любом .NET-совместимом языке, который использует возможности библиотеки Avalonia. Я добросовестно пытаюсь понять, чего именно вам в библиотеке не хватает для того, чтобы начать писать код на VB.NET, но пока что не понял.
Попытаюсь перефразировать. Разработка с использованием Avalonia на языке VB.NET ничем не отличается от разработки с использованием Avalonia на языке C# — за исключением, разумеется, того, что вы весь код пишете на VB.NET :) Оба этих языка являются first-class citizens в экосистеме Avalonia, между ними нет разницы. Avalonia нигде не привязывается к какому-то конкретному языку (ну, кроме её собственного внутреннего кода — но вам-то его снаружи не видно, если вы его специально не открыли и не начали читать).
VB.NET поддерживается в полном объёме: XAML-разметку пишете так же, а вместо C# используете кодбехайнд и модели на C#. Энтузиасты используют для работы с Avalonia даже F# и PascalABC.NET — что уж говорить про поддержку VB.NET, одного из (официально) основных языков платформы .NET.
Не беспокойтесь, с поддержкой языков в Avalonia всё в полном порядке — даже получше, чем в WPF (который, к примеру, не считает F# за first-class citizen).
Мне кажется, проблему с Lazy можно было бы решить более изящно (не перенося ответственность по инициализации значений на вызывателя):
var dictionary = new ConcurrentDictionary<MyKey, MyValue>();
var lazy = new Lazy<MyValue>(() => new MyValue());
var value = dictionary.GetOrCreate(key, _ => lazy.Value);
Этот код так же защищён от множественных одновременных вызовов .Value, но при этом наружу из него Lazy не торчат — клиент получает обычный ConcurrentDictionary<MyKey, MyValue>.
Явно указывать ExecutionAndPublication тоже, кстати, необязательно — это и есть режим по умолчанию.
Обязательно стоит упомянуть это в тексте статьи (и в книге тоже)! Это крайне важная ремарка. Без неё у моих коллег сразу возникло резкое недоверие к материалу.
Это хорошая и правильная идея — предоставлять свой код для оценки сообществом (даже если вы новичок, в этом нет ничего зазорного). Другой разговор, что сообщество Хабра, возможно, для этого не лучшим образом подходит (на этом ресурсе люди всё-таки чаще ожидают каких-то законченных материалов для специалистов среднего и высокого уровня). Мне кажется, что куда больше фидбэка вы сможете получить, если обратитесь в места с более высокой концентрацией .NET-разработчиков.
Спасибо за ваши ответы!
1. Хорошо, но для подземной базы должно сработать? А над водой это как работает — по поверхности дна или по уровню воды? Кажется, что подлодки или подводные базы тоже помогут. Поэтому Ельцин в своё время хотел встретиться с Клинтоном на подводной лодке, да? Он что-то знал? Нужно с помощью сайта проследить за Ельциным — есть подозрение, что некоторые из людей в прошлом уже были в курсе ограничений технологии. Впрочем, максимальная известная глубина погружения сегодняшней подлодки — около 1 км, что меньше объявленного лимита. Поэтому, наверное, Клинтон и не согласился — тоже всё знал, зараза?
4. Окей, тут всемогущие инопланетяне меня победили :)
5. Работа с документами — это в том числе их чтение (для ознакомления с секретными материалами — наверное, в первую очередь именно оно?). Читать документы с помощью технологии можно и «по телевизору», если знаешь, где они расположены, или где они располагались раньше. Ну и небольшое ноу-хау: можно формировать другие изображения из фрагментов трансляции сайта. Например, берём две трансляции, со светлым и тёмным фоном, и вместо foreground у текста ставим
6. Ну а человек в гипотетическом «доспехе» из экранов (повёрнутых наружу) зацензурируется? А где-нибудь в глазах смотрящего мы не сможем разглядеть изображение, на которое он смотрит? Ну и давайте тогда внедрять везде проекторы вместо экранов (ну или иные технологии просмотра данных, которые не приводят к цензуре), чтобы защиту пользователей нивелировать. Необязательно это делать топорно, можно и более-менее рыночными методами — субсидии вводить на производство проекторов, вкладывать ресурсы в нецензурируемые технологии. Инопланетяне хотят от нас что-то скрыть, и мы им будем мешать это делать.
7. То есть, если я сгенерирую фотографию, пиксель в пиксель соответствующую реальной фотографии — то по моей фотографии поиск не будет работать, а по реальной будет? Он как-то отслеживает источники каждого идентичного набора битов?
Ну и вот вам ещё одна интересная идейка: можно ли сайт использовать для мгновенных коммуникаций в пределах земного шара? Если с помощью сайта я смогу в реальном времени следить за отдалённой от меня на 16 тыс. км. точкой пространства — это экономия примерно 0.05 с (если я не ошибся в расчётах), что довольно немало; HFT-торговцы революционизируют свой бизнес. Хотя они и так его революционизируют, когда смогут к тому же следить за будущим :)
Вот тут приводили ещё несколько любопытных вариантов промышленного применения схожей технологии (магических зеркал).
У меня есть ряд интересных идей, которые можно использовать в борьбе со всемогущими инопланетянами. Считаю, что ограничения, которые они вложили в технологию, указывают на их слабости, и поэтому эти ограничения следует эксплуатировать по максимуму.
Вы исходите из предпосылки, что F# — это только про ФП. А между тем там есть и ООП-штуки, и некоторые из них очень интересные — object expressions, например, которых временами не хватает в C#.
Писанины сразу станет значительно больше.
Это очень хороший и интересный язык, но, кажется, он умер? Поддержки .NET Core нет, растительности нет, жизни нет :(
Не каждый: React поддерживает и функциональные компоненты.
Сильно зависит от вашего опыта в работе с тем и другим. Я бы вот скорее сказал, что моему опыту это утверждение не соответствует: интероп обычно прозрачен и прост.
Ваш случай с сетевыми пакетами и колбэками очень хорошо и аутентично решается в Erlang (в котором, если я правильно помню, вообще нет мутабельных переменных): этот функциональный язык программирования вообще хорошо подходит для решения такого рода задач. Здесь решение будет строиться на акторах: заведём, например, какого-нибудь глобального диспетчера, которому будут приходить сообщения из колбэков ОС, а он будет их раздавать акторам — которые, например, считают количество полученных сообщений. Код внутри акторов не мутирует никаких переменных, а просто принимает старое состояние (и пришедшее сообщение), а возвращает новое состояние (ну или рекурсивно себя вызывает с этим новым состоянием).
(При этом я полагаю, что где-то в глубине акторного фреймворка может быть мутабельный код, но в Erlang его вам никто не показывает.)
В F# может быть использовано то же самое решение — ведь у нас в .NET тоже есть акторные фреймворки — а ещё есть встроенные акторы в стандартной библиотеке F#, которые также позволят обойтись без
mutableв пользовательском коде.Если я правильно помню, одним из критериев, который разрешает отдавать любую информацию о вас, в соответствии с GDPR является требование закона. Иначе сервисы бы и от их собственных правоохранителей были обязаны скрывать информацию, а это абсурдно.
Возможно, вас повеселит или заинтересует эта статья от Microsoft: Windows Update может создавать повышенную нагрузку, если в ОС существует пользователь с именем, содержащим подстроку "user".
Меня заинтересовали ваши идеи. Как планируете публиковать? Куда подписаться, чтобы узнать о публикации?
Разве? Кажется, Mono вполне себе живёт и развивается (постепенно объединяя части кода с .NET Core).
Спасибо, ваш рассказ мне понравился. Хотелось бы услышать и о реальной истории тоже.
Ну, в таком случае нам остаётся пригласить товарища в багтрекер расширения: пускай оформит там возникшие у него проблемы, и тогда их можно будет починить!
А что бы вы хотели «из коробки»? Уже за вас всё реализовано. Вы просто берёте и пишете код на любом .NET-совместимом языке, который использует возможности библиотеки Avalonia. Я добросовестно пытаюсь понять, чего именно вам в библиотеке не хватает для того, чтобы начать писать код на VB.NET, но пока что не понял.
Попытаюсь перефразировать. Разработка с использованием Avalonia на языке VB.NET ничем не отличается от разработки с использованием Avalonia на языке C# — за исключением, разумеется, того, что вы весь код пишете на VB.NET :) Оба этих языка являются first-class citizens в экосистеме Avalonia, между ними нет разницы. Avalonia нигде не привязывается к какому-то конкретному языку (ну, кроме её собственного внутреннего кода — но вам-то его снаружи не видно, если вы его специально не открыли и не начали читать).
К счастью, вы ошиблись :)
VB.NET поддерживается в полном объёме: XAML-разметку пишете так же, а вместо C# используете кодбехайнд и модели на C#. Энтузиасты используют для работы с Avalonia даже F# и PascalABC.NET — что уж говорить про поддержку VB.NET, одного из (официально) основных языков платформы .NET.
Не беспокойтесь, с поддержкой языков в Avalonia всё в полном порядке — даже получше, чем в WPF (который, к примеру, не считает F# за first-class citizen).
Мне кажется, проблему с
Lazyможно было бы решить более изящно (не перенося ответственность по инициализации значений на вызывателя):Этот код так же защищён от множественных одновременных вызовов
.Value, но при этом наружу из негоLazyне торчат — клиент получает обычныйConcurrentDictionary<MyKey, MyValue>.Явно указывать
ExecutionAndPublicationтоже, кстати, необязательно — это и есть режим по умолчанию.Обязательно стоит упомянуть это в тексте статьи (и в книге тоже)! Это крайне важная ремарка. Без неё у моих коллег сразу возникло резкое недоверие к материалу.
Это хорошая и правильная идея — предоставлять свой код для оценки сообществом (даже если вы новичок, в этом нет ничего зазорного). Другой разговор, что сообщество Хабра, возможно, для этого не лучшим образом подходит (на этом ресурсе люди всё-таки чаще ожидают каких-то законченных материалов для специалистов среднего и высокого уровня). Мне кажется, что куда больше фидбэка вы сможете получить, если обратитесь в места с более высокой концентрацией .NET-разработчиков.
Вот тут перечислено несколько .NET-сообществ в Telegram, приходите :)