А там просто нет пространства и объема. Там искривление пространства такое, что вы видите объем, а к самом деле это непрерывное пространство такой формы.
Мы не может быть "внутри ЧД" даже умозрительно, т.к. "внутри ЧД" не существует. Вот прямо весь объём не существует. Есть горизонт событий, а за ним ничего. И нет никакой возможности предположить, что там такое. Более того, существует возможность (и скорее всего так оно и есть), что "там" действительно просто не существует - сферический разрыв в пространстве. Вот нет там пространства (в силу его искривления) и всё. Поэтому все ваши умозрительные эксперименты и предположение в коре не верны. Более того, что находится на самом горизонте событий мы тоже не знаем, так как все эти предположения о том, что там время бесконечно замедлилось тоже основаны на упрощениях и упираются во всякие тонкие эффекты вроде испарения ЧД. Поэтому с нашей точки зрения всё заканчивается на границе горизонта событий.
Линукс не дурак и отлично мапит в память все файлы, к которым обращался. И на самом деле система действительно грузится один раз, дальше могут какие-то вспомогательные скрипты или команды загружаться, но нет ничего страшного если они будут аж 100 мс грузиться. Самое главное, что HDD надёжнее NVME в таких сценариях, реже требует замены и сильно дешевле. В масштабах Яндекса должно прямо заметно выходить.
Специально посмотрел: да, у Хаббла механические гироскопы. Причём оригинальной нестандартной конструкции, так как нужна очень высокая точность, и именно поэтому они изнашиваются со временем. Для нормальной работы Хабблу нужны три гироскопа. Но ещё со времён первых поломок туда добавили режим работы с двумя гироскопами, когда для навигации дополнительно используется магнитометр, датчик Солнца и звездный датчик. Тогда же заложили возможно работы вообще с одним гиросокопом. Точность наведения с одним гироскопом падает аж до 10 градусов (до 2/36000 градуса), но донаведение в нужную позицию по звёздному полю даёт 1,5/36000 градуса, а через некоторое время за счёт анализа расположения звёзд и 0,2/36000 градуса. Всё становится очень медленно, но всё равно работает. В режиме с одним гироскопом телескоп уже работал в 2004 году.
Приборный отсек на Сюзах не может использовать для шлюзования. Выход в космос возможен только из бытового отсека. Это очень опасно. Надувный шлюзы туда не приколхозишь по конструктивными причинам. В Союз с трудом влезает три человека. В космос при этом выйти нельзя физически. Два человека могут выйти в космос с трудом. Но замена гироскопа это работа для двух человек, так что Союз вообще никак.
Гироскоп Хаббла со всеми причиндалами имеет размер с два кулака, но обычно меняют сразу навигационный блок, содержащий два гироскопа. Эта штука рамером маленькую микроволновку. Но нужны инструменты размером с два приличных чемодана. А ещё нужны фалы с руку толщиной, длинной 15 метров хотя бы. А ещё нужно как-то до Хаббла добраться. Пристыковаться к нему нельзя. Совсем вплотную подлететь тоже. Нужен или манипулятор или ранец, иначе риски слишком велики.
Короче, Союз устарел давным давно и даже для полётов экипажа уже с трудом подходит.
Возможно, что сильно старый. Во-вторых, речь наверняка идёт о гиродинах, которые тоже "гироскопы", но используются для удержания и изменения ориентации, а не для её определения. Они, само-собой, могут быть только механическими и достаточно активно изнашиваются. Держать ориентацию и крутить телескоп двигателями - не напасёшься топлива.
У Союза очень маленький объём, низкая грузоподъёмность и нет шлюза. Очень старый корабль. Маск свой может послать, там объём и лютый и грузоподъёмность достаточная. Остаётся только проблема со шлюзом, которая решается разгерметизацией всего корабля, что заметно увеличивает риск для экипажа.
Потребительская инфляция также не может перекрываться ставками вкладов, так как это тут же приведет к ускорению инфляции, которая превысит ставки.
Росстат показвает откровенную дичь. Самый яркий пример из относительно свежего - нарисованное снижение инфляции из-за разовых (!!!) скидок на автомобили Москвич. Результаты получились просто потрясающие.
Росстат показвает дважды дичь, так как лично я ловил его на манипуляции сырыми данными, когда для сравнения цен брались не эквивалентные товары. Я ловил на том, что сравнивалась пачки молока разного объема и тому подобные фокусы.
Росстат показвает трижды дичь, так как регулярно кардинально меняет методику, при этом каждое изменение волшебным образом совпадет с ожидаемым скачком инфляции. Вы же в курсе, что со следующего года Росстат снова меняет методику расчета ИПЦ? До этого он менял методику в 2022 году. А до того в 2021. А до того - в 2020. Вы всё ещё верите результатам при ежегодно (!!!) изменяющейся методике?
Росстат показвает четырёхкратную дичь, так как учитываемая им структура потребления не актуальна ни для реальных пропорций расходов населения, ни для реальной структуры потребления населения.
В общем, что по инфляции, что по ВВП Росстату нельзя верить примерно никак, и тому есть объективные причины.
Потому что на самом деле в большинстве случаев прибыльность растёт вместе с инфляцией (общим ростом цен). Т.е. 15% + инфляция. А банковский процент совершенно точно никогда не перекрывает реальную инфляцию, иначе этот будут деньги из воздуха. Кроме того сегодня у вас 15% вклад, а завтра ставка понизится и будет 8..10%, а для бизнеса это просто праздник будет его маржа вырастет, например, до 20%.
Там проблема в том, что бинарный код после JIT жёстко привязан к адресному пространству и запросу, а потому: 1) каждый новый запрос будет занимать всё новые адреса. Выгружать это всё не получится, так как у кода жёсткая привязка к адресам. То есть выгрузить можно, но если при попытке загрузить из кэша обратно окажется, что по этому адресу уже есть какой-то другой запрос, то что тогда делать? Жонглировать запросами в адресном пространстве СУБД? Так себе идея, особенно учитывая, что обрабатывающих запросы потоков много, а адресное пространство у них общее - что делать если разные потоки захотят исполнять разные запросы, которые были скомпилированы по одному адресу? А ещё (все) ОС и процессор очень не любят динамического изменения кода. В качестве решения предлагается относительного легковесное исправление всех адресов при извлечении запроса из кэша. Но это достаточного тяжёлая операция. Кроме того при патчинге адресов возникают некоторые конфликты с оптимизацией. 2) генерируемый JIT код очень жёстко оптимизируется под конкретный запрос. Например, у вас там проверка на ноль, какая-нибудь или на константу - этот будет очень круто заоптимизировано при JIT, и если в другом запросе константа другая, то ой - наш старый кэш уже не подходит. Если же мы начнём генерировать универсальный код без оптимизации констант и сравнений, то это сильно снизит степень оптимизации кода и замедлит сложные и длительные запросы, ради которых этот JIT и задумывался. Кроме того, конкретно в PG (но в целом это общая проблема всех СУБД) вся оптимизация завязана на планировщик запросов (что логично), и нужно отключать часть оптимизаций уже на уровне планировщика, а значит потенциально замедлять вообще все запросы вне зависимости от JIT и нашего кэша.
Короче, на данный момент создать эффективный кэш оптимизированного бинарного кода невозможно. Не придумано пока никакого нормального общего решения и всё. А все предполагаемые пути решения проблемы ведут к тому, что нужно с ноля писать планировщик и оптимизатор, которые изначально архитектурно будут рассчитаны на последующую работу JIT и кэша. А это громадная работа и переписывание примерно три всего кода СУБД. Причём, всё равно придётся идти на компромиссы в какие-то моменты. Например, нужно, чтобы планировщик очень точно считал вычислительную сложность запросов, а это само по себе нерешённая пока задача (особенно в PG).
Ну, садиться самолётный автопилот, кстати, давно умеет. Даже вообще без помощи аэропорта (но с помощью GPS и Gbas/Sbas/Waas увеличивающих точность GPS). Он на "обычном" GPS сядет, но точность будет недостаточная для большинства полос аэропортов, что уже прямо сильно опасно. Просто считается, что надёжность автопилота недостаточна для посадки, плюс, он не умеет реагировать на весь возможный спектр нештатных ситуаций.
И меня всегда веселило, что вся эта метрология не сходится с методичками по реактивному движению. Единственное разумное объяснение, что сечение сопла для метрологии очень небольшое и эффекты действительно получаются очень близки к идеальным теоретическим. Но это так себе объяснение. С тем же успехом можно допустить, что в методичках упрощённая туфта, так как в реальности все всё равно давно уже считают через динамическое моделирование по очень сложным моделям.
Давно это было, сейчас не найду. Но метрология для поверки и проверки расхода газов - вплоть до бытовых счётчиков газа - во много построена на постоянном расходе газа через критическое сопло. Измеряем атмосферное давление (благо, что супер-точность не нужна), измеряем температуру воздуха, ставим баллон и за ним мощный вакуумный насос, поддерживающий разряжение в баллоне. Ставим на входе в баллон сопло. В трубе перед соплом будет постоянный и заранее известный расход воздуха/газа, а потому туда можно воткнуть счётчик и сверить/поверять его показания. Именно так большинство стендов для поверки и работают. Компухтер корректирует расход с учётом давления и температуры на входе. Точность у них заявляется до 0.1%. Единственный минус - переменная влажность воздуха, но это решается установкой осушающего кондиционера на температуру в комнате заведомо ниже уличной и контролем, чтобы влажность случайно не превысила макимально-допустимую. Для самых упоротых есть супер-пупер точные системы замкнутого цикла, на каком-нибудь азоте. Сами сопла покупаются у других очень специальных метрологов, которые изготавливают их с очень высокой геометрической точностью. Стендов по стране сотни тысяч и каждый сертифицирован по самое не могу. К каждому идёт комплект документации, где расписан принцип действия с обоснованием получаемой точности поддержания расхода и приведены формулы зависимости расхода от диаметра сопла и перепада давлений для воздуха. На всё это само собой есть ещё и набор ГОСТов, в которых эти формулы утверждены высшими силами с гарантией точности в нужном диапазоне условий.
А ещё есть метрологи, которые измеряют расход газа через критическое сопло, что является одним из самых точных методов. И они смотрят на это всё с недоумением, так как их формулы, хоть и являются очень частным случаем, но непрерывно подтверждаются экспериментально с относительной погрешностью до 0.1%. Но если посчитать то же самое по формулам из учебников по реактивной тяге или по вакуумной технике некоторых вузов, то там выходят совершенно иные цифры. И всем плевать. А потом приходят студенты, видят необходимость рассчитать расход газа через сопло, радуются, что их не зря учили, считают и получают невообразимую дичь с ошибкой 30+%.
А там просто нет пространства и объема. Там искривление пространства такое, что вы видите объем, а к самом деле это непрерывное пространство такой формы.
Мы не может быть "внутри ЧД" даже умозрительно, т.к. "внутри ЧД" не существует. Вот прямо весь объём не существует. Есть горизонт событий, а за ним ничего. И нет никакой возможности предположить, что там такое. Более того, существует возможность (и скорее всего так оно и есть), что "там" действительно просто не существует - сферический разрыв в пространстве. Вот нет там пространства (в силу его искривления) и всё. Поэтому все ваши умозрительные эксперименты и предположение в коре не верны.
Более того, что находится на самом горизонте событий мы тоже не знаем, так как все эти предположения о том, что там время бесконечно замедлилось тоже основаны на упрощениях и упираются во всякие тонкие эффекты вроде испарения ЧД. Поэтому с нашей точки зрения всё заканчивается на границе горизонта событий.
WG блокируется как протокол . Хоть на своём сервере, хоть на "помойке".
Всё хорошо. Хотели попилить, не получилось, не пропадать же сайту.
Скорее всего нормально пройдёт, но при разгерметизации единственного объёма это всегда высокий риск.
Линукс не дурак и отлично мапит в память все файлы, к которым обращался. И на самом деле система действительно грузится один раз, дальше могут какие-то вспомогательные скрипты или команды загружаться, но нет ничего страшного если они будут аж 100 мс грузиться. Самое главное, что HDD надёжнее NVME в таких сценариях, реже требует замены и сильно дешевле. В масштабах Яндекса должно прямо заметно выходить.
Всё нормально. Не получилось.
Специально посмотрел: да, у Хаббла механические гироскопы. Причём оригинальной нестандартной конструкции, так как нужна очень высокая точность, и именно поэтому они изнашиваются со временем.
Для нормальной работы Хабблу нужны три гироскопа. Но ещё со времён первых поломок туда добавили режим работы с двумя гироскопами, когда для навигации дополнительно используется магнитометр, датчик Солнца и звездный датчик. Тогда же заложили возможно работы вообще с одним гиросокопом.
Точность наведения с одним гироскопом падает аж до 10 градусов (до 2/36000 градуса), но донаведение в нужную позицию по звёздному полю даёт 1,5/36000 градуса, а через некоторое время за счёт анализа расположения звёзд и 0,2/36000 градуса. Всё становится очень медленно, но всё равно работает.
В режиме с одним гироскопом телескоп уже работал в 2004 году.
Приборный отсек на Сюзах не может использовать для шлюзования. Выход в космос возможен только из бытового отсека. Это очень опасно. Надувный шлюзы туда не приколхозишь по конструктивными причинам.
В Союз с трудом влезает три человека. В космос при этом выйти нельзя физически. Два человека могут выйти в космос с трудом. Но замена гироскопа это работа для двух человек, так что Союз вообще никак.
Гироскоп Хаббла со всеми причиндалами имеет размер с два кулака, но обычно меняют сразу навигационный блок, содержащий два гироскопа. Эта штука рамером маленькую микроволновку.
Но нужны инструменты размером с два приличных чемодана.
А ещё нужны фалы с руку толщиной, длинной 15 метров хотя бы.
А ещё нужно как-то до Хаббла добраться. Пристыковаться к нему нельзя. Совсем вплотную подлететь тоже. Нужен или манипулятор или ранец, иначе риски слишком велики.
Короче, Союз устарел давным давно и даже для полётов экипажа уже с трудом подходит.
Возможно, что сильно старый. Во-вторых, речь наверняка идёт о гиродинах, которые тоже "гироскопы", но используются для удержания и изменения ориентации, а не для её определения. Они, само-собой, могут быть только механическими и достаточно активно изнашиваются. Держать ориентацию и крутить телескоп двигателями - не напасёшься топлива.
У Союза очень маленький объём, низкая грузоподъёмность и нет шлюза. Очень старый корабль. Маск свой может послать, там объём и лютый и грузоподъёмность достаточная. Остаётся только проблема со шлюзом, которая решается разгерметизацией всего корабля, что заметно увеличивает риск для экипажа.
Надо брать, ятакщитаю.
Чего подозрительного? Ну, не хочет человек позориться под основным аккаунтом - вполне понятное стремление.
Потребительская инфляция также не может перекрываться ставками вкладов, так как это тут же приведет к ускорению инфляции, которая превысит ставки.
Росстат показвает откровенную дичь. Самый яркий пример из относительно свежего - нарисованное снижение инфляции из-за разовых (!!!) скидок на автомобили Москвич. Результаты получились просто потрясающие.
Росстат показвает дважды дичь, так как лично я ловил его на манипуляции сырыми данными, когда для сравнения цен брались не эквивалентные товары. Я ловил на том, что сравнивалась пачки молока разного объема и тому подобные фокусы.
Росстат показвает трижды дичь, так как регулярно кардинально меняет методику, при этом каждое изменение волшебным образом совпадет с ожидаемым скачком инфляции. Вы же в курсе, что со следующего года Росстат снова меняет методику расчета ИПЦ? До этого он менял методику в 2022 году. А до того в 2021. А до того - в 2020. Вы всё ещё верите результатам при ежегодно (!!!) изменяющейся методике?
Росстат показвает четырёхкратную дичь, так как учитываемая им структура потребления не актуальна ни для реальных пропорций расходов населения, ни для реальной структуры потребления населения.
В общем, что по инфляции, что по ВВП Росстату нельзя верить примерно никак, и тому есть объективные причины.
Потому что на самом деле в большинстве случаев прибыльность растёт вместе с инфляцией (общим ростом цен). Т.е. 15% + инфляция. А банковский процент совершенно точно никогда не перекрывает реальную инфляцию, иначе этот будут деньги из воздуха. Кроме того сегодня у вас 15% вклад, а завтра ставка понизится и будет 8..10%, а для бизнеса это просто праздник будет его маржа вырастет, например, до 20%.
Там проблема в том, что бинарный код после JIT жёстко привязан к адресному пространству и запросу, а потому:
1) каждый новый запрос будет занимать всё новые адреса. Выгружать это всё не получится, так как у кода жёсткая привязка к адресам. То есть выгрузить можно, но если при попытке загрузить из кэша обратно окажется, что по этому адресу уже есть какой-то другой запрос, то что тогда делать? Жонглировать запросами в адресном пространстве СУБД? Так себе идея, особенно учитывая, что обрабатывающих запросы потоков много, а адресное пространство у них общее - что делать если разные потоки захотят исполнять разные запросы, которые были скомпилированы по одному адресу? А ещё (все) ОС и процессор очень не любят динамического изменения кода.
В качестве решения предлагается относительного легковесное исправление всех адресов при извлечении запроса из кэша. Но это достаточного тяжёлая операция. Кроме того при патчинге адресов возникают некоторые конфликты с оптимизацией.
2) генерируемый JIT код очень жёстко оптимизируется под конкретный запрос. Например, у вас там проверка на ноль, какая-нибудь или на константу - этот будет очень круто заоптимизировано при JIT, и если в другом запросе константа другая, то ой - наш старый кэш уже не подходит. Если же мы начнём генерировать универсальный код без оптимизации констант и сравнений, то это сильно снизит степень оптимизации кода и замедлит сложные и длительные запросы, ради которых этот JIT и задумывался. Кроме того, конкретно в PG (но в целом это общая проблема всех СУБД) вся оптимизация завязана на планировщик запросов (что логично), и нужно отключать часть оптимизаций уже на уровне планировщика, а значит потенциально замедлять вообще все запросы вне зависимости от JIT и нашего кэша.
Короче, на данный момент создать эффективный кэш оптимизированного бинарного кода невозможно. Не придумано пока никакого нормального общего решения и всё. А все предполагаемые пути решения проблемы ведут к тому, что нужно с ноля писать планировщик и оптимизатор, которые изначально архитектурно будут рассчитаны на последующую работу JIT и кэша. А это громадная работа и переписывание примерно три всего кода СУБД. Причём, всё равно придётся идти на компромиссы в какие-то моменты. Например, нужно, чтобы планировщик очень точно считал вычислительную сложность запросов, а это само по себе нерешённая пока задача (особенно в PG).
Ну, садиться самолётный автопилот, кстати, давно умеет. Даже вообще без помощи аэропорта (но с помощью GPS и Gbas/Sbas/Waas увеличивающих точность GPS). Он на "обычном" GPS сядет, но точность будет недостаточная для большинства полос аэропортов, что уже прямо сильно опасно.
Просто считается, что надёжность автопилота недостаточна для посадки, плюс, он не умеет реагировать на весь возможный спектр нештатных ситуаций.
И меня всегда веселило, что вся эта метрология не сходится с методичками по реактивному движению. Единственное разумное объяснение, что сечение сопла для метрологии очень небольшое и эффекты действительно получаются очень близки к идеальным теоретическим. Но это так себе объяснение. С тем же успехом можно допустить, что в методичках упрощённая туфта, так как в реальности все всё равно давно уже считают через динамическое моделирование по очень сложным моделям.
Давно это было, сейчас не найду. Но метрология для поверки и проверки расхода газов - вплоть до бытовых счётчиков газа - во много построена на постоянном расходе газа через критическое сопло.
Измеряем атмосферное давление (благо, что супер-точность не нужна), измеряем температуру воздуха, ставим баллон и за ним мощный вакуумный насос, поддерживающий разряжение в баллоне. Ставим на входе в баллон сопло. В трубе перед соплом будет постоянный и заранее известный расход воздуха/газа, а потому туда можно воткнуть счётчик и сверить/поверять его показания. Именно так большинство стендов для поверки и работают. Компухтер корректирует расход с учётом давления и температуры на входе. Точность у них заявляется до 0.1%. Единственный минус - переменная влажность воздуха, но это решается установкой осушающего кондиционера на температуру в комнате заведомо ниже уличной и контролем, чтобы влажность случайно не превысила макимально-допустимую. Для самых упоротых есть супер-пупер точные системы замкнутого цикла, на каком-нибудь азоте. Сами сопла покупаются у других очень специальных метрологов, которые изготавливают их с очень высокой геометрической точностью. Стендов по стране сотни тысяч и каждый сертифицирован по самое не могу. К каждому идёт комплект документации, где расписан принцип действия с обоснованием получаемой точности поддержания расхода и приведены формулы зависимости расхода от диаметра сопла и перепада давлений для воздуха. На всё это само собой есть ещё и набор ГОСТов, в которых эти формулы утверждены высшими силами с гарантией точности в нужном диапазоне условий.
А ещё есть метрологи, которые измеряют расход газа через критическое сопло, что является одним из самых точных методов. И они смотрят на это всё с недоумением, так как их формулы, хоть и являются очень частным случаем, но непрерывно подтверждаются экспериментально с относительной погрешностью до 0.1%. Но если посчитать то же самое по формулам из учебников по реактивной тяге или по вакуумной технике некоторых вузов, то там выходят совершенно иные цифры. И всем плевать. А потом приходят студенты, видят необходимость рассчитать расход газа через сопло, радуются, что их не зря учили, считают и получают невообразимую дичь с ошибкой 30+%.