Таким образом, в статье 2018 года были получены модифицированные уравнения Фридмана и аналитическое выражение для космологической постоянной, а также её числовая оценка, совпадающая по порядку величины с наблюдениями. Напомним, что результаты квантовых космологов по вычислению космологической постоянной, расходились с наблюдениями на 40-120 порядков."
Я просто напомню кусочек статьи:
Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.
Даже официально на посадке существовали ручные, неавтоматизированные обязательные операции. Поэтому теоретически посадку можно было ДОРАБОТАТЬ до автоматической.
Речь ведь не только о посадке. Переключение режимов полета Шаттла также производилось вручную(менялись касеиы с программами). Поэтому, потеряй экипаж сознание, и он был бы обречен.
Система не предполагала средств спасения на этапе выведения, что мы и увидели в катастрофе Чкленджера — экипаж был в сознании при пожаре центрального блока, но ничего не мог сделать. Экипаж погиб от удара о воду.
Поэтому утверждать, что пилотируемость Шаттла не скомпрометирована… Нтакое...
Это уже вопросы компромиссов.
Точно также можно сказать: цена предполетной подготовки Шаттла изрядно подмочила идею многоразовости, а отказ от системы спасения экипажа и необходимость участия экипажа в управлении на всех этапах полёта скомпрометировал и саму идею Шаттла, как пилотируемого носителя.
Поэтому не будем спекулировать, а вернемся к исходному тезису статьи: Энергия-Буран — клон Шаттла. Очевидно, это не так
Боковушки "Энергии" — это ракета "Зенит", которая имела самостоятельную ценность(20 лет после окнчания программы летала). Так что можно и развернуть тезис — если все равно нужно было создавать носитель такого класса, к которому еще хотели прикрутить и возвращение, то о какой дешевизне вообще идет речь? Расскажите это Маску с его Falcon Heavy.
Аналогично и с "Энергией", которая имела ценность как самостоятельный носитель. Представили себе допустимый размер марсохода, будь жив еще этот проект?
Например, борт не может точно просчитать баллистику на любое время вперед. Что-то он, конечно считает, но "локально". Дополнительно, нужно указать когда и какое оборудование включать — на разных дистанциях система сближения и стыковки работает по-разному. Добавьте, что и станция тоже движется, поэтому нужно считать и её баллистику тоже. Плюс, еще раз повторю, станция тоже должна знать временное окно стыковки — во время стыковки она должна переёти в соответственный режим, вводятся запреты на какие-то операции и тп. Поэтому вопрос несколько сложнее, чем "стыковаться через N витков".
Программой в данном случае называется не код, а "бинарный скрипт", который содержит кучу параметров типа: текущие параметры мкс (орбита, положение, ориентация), куда стыковаться, с помощью какой аппаратуры и тп. Проверяется корректность именно этого "скрипта" и согласованность его действий. + если мне не изменяет память, со стороны МКС тоже должны быть соответствующие изменения — она должна знать "когда и кого ждать", в какой ориентации и тп
По сути, на новом Союзе/Прогрессе было переписано ВСЁ ПО. До этого ПО было написано в машинных кодах еще в 70х. При переписывании оказалось, что часть кода утеряна, а некоторые части содержат ошибки. К этому нужно добавить, что для такого рода изделий нельзя "просто переписать" — нужно всё протестировать "от и до", провести тестовые пуски. В принципе, можно просто заглянуть внутрь нового и старого Союза и "почувствовать" разницу визуально…
К сожалению, специалиста РКК не пишут обо всём этом, а руководство явно не заинтересовано в популяризции...
Честно говоря, даже не обратил внимание на детали, т.к. знал эту историю от своего шефа из ИПМ им.Келдыша.
Траектории такого типа были исследованы Ивашкиным еще в 60х
Вот одна из публикаций:
Ивашкин В.В., Тупицын Н.Н. (1970) Об использовании гравитационного поля Луны для выведения космического аппарата на стационарную орбиту спутника Земли. — Препринт, Институт прикладной математики АН СССР. Москва, 1970 г. 31 с.
Очевидцы даже утверждают, что Huges даже прислала благодартсвенное письмо с благодарностью за те его исследования.
В общем, странная и, возможно, некрасивая история с этими патентами вырисовывается...
Не понятно, что подразумевается под статической типизацией. Посмотрите пример из статьи. Метод fixed_stack::on_push будет вызван только для сообщения push, ни для какого другого сообщения его использовать не получится. Возможно это как раз посредством статической типизации.
Вероятно, вы под статической типизацией понимаете что-то другое. Например, невозможность отправить агенту сообщение типа A, если агент в нем не заинтересован. Если так, то этого в SObjectizer нет. Поскольку на практике с такими задачами не встречались. Где это может потребоваться?
А что произойдёт с сообщением, для которого не задан обработчик?
В больших системах это как раз "обыденно", когда сообщение в следствие ошибок заруливается "не туда".
Правда, бывают ситуации, когда это делается намеренно (для маршрутизаторов), для этого в caf есть default_handler.
При очень высокой интенсивности и совсем дешевой обработке, вообще актуальность использования Модели Акторов под вопросом. Тут может лучше работать подход на основе Disruptor-а.
слишком мутное описание, чтобы из него можно было что-то почерпнуть об алгоритме.
Ну и на счет зоопарка в CAF. Документация говорит, что там есть где развернуться:
CAF provides several actor implementations, each covering a particular use case. The available implementations differ in three characteristics: (1) dynamically or statically typed, (2) class-based or function-based, and (3) using asynchronous event handlers or blocking receives.
Есть ли в SObjectizer статическая типизация агентов? Как это сделано у Вас?
Подразумевается, что актор может быть как функцией, так и классом. К чему требовать классы там, где достаточно лябды?
"зоопарк" типов акторов вроде как объективен:
не всегда возможно запихнуть всё приложение в модель акторов (gui, например), поэтому необходим тип акторов, который живёт "вовне" (scoped_actor) и управляется внешним event-loop
Для работы внутри системы акторов также вохможны 2 ситуации:
— работа, основанная на сообщениях от других акторов (event_based_actor)
— работа, требующая ручного управления событиями внутри актора (сокеты, железо, бд и тп) (blocking_actor)
Как решаеются эти задачи в SObjectizer?
Вероятно, кому-то доставляет удовольствие со всем этим разбираться :)
В SObjectizer настолько прост, что в нём ненужно разбираться?
Есть один существенный нюанс. При «небольшом» потоке сообщений и «быстрой» обработке, крайне невыгодно помещать генераторы и обработчики в свои индивидуальные потоки: расходы на переключение контекстов будут огромными. Акторный фреймворк может как взять на себя решение задачи по распределению задач по потокам, так и позволить разработчику быстро переконфигурировать приложение, указывая рспределение акторов по потокам.
В caf существует 3 типа акторов: event_based_actor, blocking_actor и scoped_actor.
event_based_actor только лишь обрабатывает сообщения (в том числе, может слать сообщения сам себе ). Для такого типа акторов caf учитывает «родство» и по умолчанию помещает потомка в поток родителя. При создании актора можно задать опцию «detached», что заставит caf поместить его в свой отдельный поток
blocking_actor живёт в своём собственном потоке и пользователь сам решает когда он должен принимать сообщения, а когда — спать
scoped_actor нужен для взаимодействия с системой акторов «извне».
Ну и да, каждый актор имеет свои собственные очереди сообщений и ожиданий ответов.
Текст претендует на некоторое сравнение существующих фреймфорков, и заканчивается фразой:
В чем SObjectizer сильно отличается от перечисленных выше проектов, так это симбиозом моделей Акторов, Publish-Subscribe и Comminicating Sequential Processes.
Но при этом не содержит упоминания о реализуемых моделях в других реализациях.
Да и вообще про CAF не сказано ничего, кроме требовательности и сомнений.
Поэтому я счёл необходимым добавить эти моменты в комментариях.
p.s.
Всё же написание статьи требует на порядок больше времени и сил, чем комментарий.
Хорошо бы добавить, что CAF поддерживает несколько различных типов обмена сообщениями:
Обычная отправка адресату, pub/sub (через группы), а также req/rep.
Кроме того, 0.15 получил возможность типизировать акторы, указывая типы обрабатываемых запросов/ответов, с проверкой в compile-time (невозможно отправить актору сообщение неподдерживаемого типа)
высокие требования CAF-а к уровню поддержки стандартов в C++ в компиляторе. Из-за этого разработчики CAF-а никогда не рассматривали Windows и VC++ в качестве одной из значимых платформ для своей разработки, ограничиваясь Linux-ом, FreeBSD MacOS, а также самыми свежими версиями компиляторов gcc и clang.
Высокие требования — это c++11, не более. Появилась поддержка c++11 — появилась поддержка платформы. В 2017 году говорить об этом, как о некой чрезвычайной требовательности, странно.
Посмотрете на историю добавления optional и variant типов — авторы добавили их с оглядкой на совместимость с c++17, но не потребовали поддержки "в новейших компиляторах".
CAF вполне себе нормально компилируется под msvc и требует лишь c++11, поэтому говорить о каком-то игнорировании платформы некорректно — требуется соответствие стандарту.
На данный момент есть вполне "физичные" объяснения космологической постоянной, на основании учета влияния грав.волн в самой ОТО:
Тёмная энергия с инфляцией: RIP
Ну и дальше гуглить и читать Николая Горькового.
Я просто напомню кусочек статьи:
Пол Тёрнер, инженер и руководитель основного костяка разработчиков Google, присутствовавший на конференции, рассказал, что никто из членов Project Zero не предупредил об открытии своих коллег; они узнали об этом вместе со всеми.
Даже официально на посадке существовали ручные, неавтоматизированные обязательные операции. Поэтому теоретически посадку можно было ДОРАБОТАТЬ до автоматической.
Речь ведь не только о посадке. Переключение режимов полета Шаттла также производилось вручную(менялись касеиы с программами). Поэтому, потеряй экипаж сознание, и он был бы обречен.
Система не предполагала средств спасения на этапе выведения, что мы и увидели в катастрофе Чкленджера — экипаж был в сознании при пожаре центрального блока, но ничего не мог сделать. Экипаж погиб от удара о воду.
Поэтому утверждать, что пилотируемость Шаттла не скомпрометирована… Нтакое...
Это уже вопросы компромиссов.
Точно также можно сказать: цена предполетной подготовки Шаттла изрядно подмочила идею многоразовости, а отказ от системы спасения экипажа и необходимость участия экипажа в управлении на всех этапах полёта скомпрометировал и саму идею Шаттла, как пилотируемого носителя.
Поэтому не будем спекулировать, а вернемся к исходному тезису статьи: Энергия-Буран — клон Шаттла. Очевидно, это не так
Причем здесь это?)
Боковушки "Энергии" — это ракета "Зенит", которая имела самостоятельную ценность(20 лет после окнчания программы летала). Так что можно и развернуть тезис — если все равно нужно было создавать носитель такого класса, к которому еще хотели прикрутить и возвращение, то о какой дешевизне вообще идет речь? Расскажите это Маску с его Falcon Heavy.
Аналогично и с "Энергией", которая имела ценность как самостоятельный носитель. Представили себе допустимый размер марсохода, будь жив еще этот проект?
Думаю, тут мало кто понимает, что у США в принципе не было аналога ракеты "Энергия" :)
Например, борт не может точно просчитать баллистику на любое время вперед. Что-то он, конечно считает, но "локально". Дополнительно, нужно указать когда и какое оборудование включать — на разных дистанциях система сближения и стыковки работает по-разному. Добавьте, что и станция тоже движется, поэтому нужно считать и её баллистику тоже. Плюс, еще раз повторю, станция тоже должна знать временное окно стыковки — во время стыковки она должна переёти в соответственный режим, вводятся запреты на какие-то операции и тп. Поэтому вопрос несколько сложнее, чем "стыковаться через N витков".
Программой в данном случае называется не код, а "бинарный скрипт", который содержит кучу параметров типа: текущие параметры мкс (орбита, положение, ориентация), куда стыковаться, с помощью какой аппаратуры и тп. Проверяется корректность именно этого "скрипта" и согласованность его действий. + если мне не изменяет память, со стороны МКС тоже должны быть соответствующие изменения — она должна знать "когда и кого ждать", в какой ориентации и тп
Там длинная цепочка "отладки" — подготовить программу, проверить на имитаторах. Готовят программу в ЦУПе, финальное "добро" дают в РКК.
По сути, на новом Союзе/Прогрессе было переписано ВСЁ ПО. До этого ПО было написано в машинных кодах еще в 70х. При переписывании оказалось, что часть кода утеряна, а некоторые части содержат ошибки. К этому нужно добавить, что для такого рода изделий нельзя "просто переписать" — нужно всё протестировать "от и до", провести тестовые пуски. В принципе, можно просто заглянуть внутрь нового и старого Союза и "почувствовать" разницу визуально…
К сожалению, специалиста РКК не пишут обо всём этом, а руководство явно не заинтересовано в популяризции...
Честно говоря, даже не обратил внимание на детали, т.к. знал эту историю от своего шефа из ИПМ им.Келдыша.
Траектории такого типа были исследованы Ивашкиным еще в 60х
Вот одна из публикаций:
Ивашкин В.В., Тупицын Н.Н. (1970) Об использовании гравитационного поля Луны для выведения космического аппарата на стационарную орбиту спутника Земли. — Препринт, Институт прикладной математики АН СССР. Москва, 1970 г. 31 с.
Очевидцы даже утверждают, что Huges даже прислала благодартсвенное письмо с благодарностью за те его исследования.
В общем, странная и, возможно, некрасивая история с этими патентами вырисовывается...
https://en.m.wikipedia.org/wiki/PAS-22
Также достоин попадания в этот список. На мой взгляд, одна из самых невероятных мсторий спасения.
С таким же успехом можно сказать "вызов функций в принципе ненадёжен"…
Надёжность определяется средой передачи и протоколом.
Нужно это примерно для того же, для чего разработчики protobuf создали тип Any.
А что произойдёт с сообщением, для которого не задан обработчик?
В больших системах это как раз "обыденно", когда сообщение в следствие ошибок заруливается "не туда".
Правда, бывают ситуации, когда это делается намеренно (для маршрутизаторов), для этого в caf есть default_handler.
слишком мутное описание, чтобы из него можно было что-то почерпнуть об алгоритме.
— работа, основанная на сообщениях от других акторов (event_based_actor)
— работа, требующая ручного управления событиями внутри актора (сокеты, железо, бд и тп) (blocking_actor)
Как решаеются эти задачи в SObjectizer?
В SObjectizer настолько прост, что в нём ненужно разбираться?
В caf существует 3 типа акторов: event_based_actor, blocking_actor и scoped_actor.
Ну и да, каждый актор имеет свои собственные очереди сообщений и ожиданий ответов.
Но при этом не содержит упоминания о реализуемых моделях в других реализациях.
Да и вообще про CAF не сказано ничего, кроме требовательности и сомнений.
Поэтому я счёл необходимым добавить эти моменты в комментариях.
p.s.
Всё же написание статьи требует на порядок больше времени и сил, чем комментарий.
Хорошо бы добавить, что CAF поддерживает несколько различных типов обмена сообщениями:
Обычная отправка адресату, pub/sub (через группы), а также req/rep.
Кроме того, 0.15 получил возможность типизировать акторы, указывая типы обрабатываемых запросов/ответов, с проверкой в compile-time (невозможно отправить актору сообщение неподдерживаемого типа)
высокие требования CAF-а к уровню поддержки стандартов в C++ в компиляторе. Из-за этого разработчики CAF-а никогда не рассматривали Windows и VC++ в качестве одной из значимых платформ для своей разработки, ограничиваясь Linux-ом, FreeBSD MacOS, а также самыми свежими версиями компиляторов gcc и clang.
Высокие требования — это c++11, не более. Появилась поддержка c++11 — появилась поддержка платформы. В 2017 году говорить об этом, как о некой чрезвычайной требовательности, странно.
Посмотрете на историю добавления optional и variant типов — авторы добавили их с оглядкой на совместимость с c++17, но не потребовали поддержки "в новейших компиляторах".
CAF вполне себе нормально компилируется под msvc и требует лишь c++11, поэтому говорить о каком-то игнорировании платформы некорректно — требуется соответствие стандарту.