Ну, садиться самолётный автопилот, кстати, давно умеет. Даже вообще без помощи аэропорта (но с помощью GPS и Gbas/Sbas/Waas увеличивающих точность GPS). Он на "обычном" GPS сядет, но точность будет недостаточная для большинства полос аэропортов, что уже прямо сильно опасно. Просто считается, что надёжность автопилота недостаточна для посадки, плюс, он не умеет реагировать на весь возможный спектр нештатных ситуаций.
И меня всегда веселило, что вся эта метрология не сходится с методичками по реактивному движению. Единственное разумное объяснение, что сечение сопла для метрологии очень небольшое и эффекты действительно получаются очень близки к идеальным теоретическим. Но это так себе объяснение. С тем же успехом можно допустить, что в методичках упрощённая туфта, так как в реальности все всё равно давно уже считают через динамическое моделирование по очень сложным моделям.
Давно это было, сейчас не найду. Но метрология для поверки и проверки расхода газов - вплоть до бытовых счётчиков газа - во много построена на постоянном расходе газа через критическое сопло. Измеряем атмосферное давление (благо, что супер-точность не нужна), измеряем температуру воздуха, ставим баллон и за ним мощный вакуумный насос, поддерживающий разряжение в баллоне. Ставим на входе в баллон сопло. В трубе перед соплом будет постоянный и заранее известный расход воздуха/газа, а потому туда можно воткнуть счётчик и сверить/поверять его показания. Именно так большинство стендов для поверки и работают. Компухтер корректирует расход с учётом давления и температуры на входе. Точность у них заявляется до 0.1%. Единственный минус - переменная влажность воздуха, но это решается установкой осушающего кондиционера на температуру в комнате заведомо ниже уличной и контролем, чтобы влажность случайно не превысила макимально-допустимую. Для самых упоротых есть супер-пупер точные системы замкнутого цикла, на каком-нибудь азоте. Сами сопла покупаются у других очень специальных метрологов, которые изготавливают их с очень высокой геометрической точностью. Стендов по стране сотни тысяч и каждый сертифицирован по самое не могу. К каждому идёт комплект документации, где расписан принцип действия с обоснованием получаемой точности поддержания расхода и приведены формулы зависимости расхода от диаметра сопла и перепада давлений для воздуха. На всё это само собой есть ещё и набор ГОСТов, в которых эти формулы утверждены высшими силами с гарантией точности в нужном диапазоне условий.
А ещё есть метрологи, которые измеряют расход газа через критическое сопло, что является одним из самых точных методов. И они смотрят на это всё с недоумением, так как их формулы, хоть и являются очень частным случаем, но непрерывно подтверждаются экспериментально с относительной погрешностью до 0.1%. Но если посчитать то же самое по формулам из учебников по реактивной тяге или по вакуумной технике некоторых вузов, то там выходят совершенно иные цифры. И всем плевать. А потом приходят студенты, видят необходимость рассчитать расход газа через сопло, радуются, что их не зря учили, считают и получают невообразимую дичь с ошибкой 30+%.
А дальше начинается... Нить/лента при подаче режет абсолютно всё. То, что она не режет, само сталь режет. Решаемо, но нужен опыт. Нужно постоянное натяжение нити/ленты при большом ходе каретки (ибо мачта). Причём это супер-критично. Пипец, как сложно, кстати. Тоже решаемо, но нужен огромный опыт. Нужна подача клея: равномерная и синхронизированная с подачей нити/ленты. Тоже решаемо, но нужно много опыта. Нужна механика и электроника, чтобы оно не клинило и не ломалось в случае чего. Нужна обслуживаемость, удобная смена катушек и расходников - тоже опыт. Вот и получается, что там 1'000'000 сам станок и 19'000'000 - знание как именно это всё собрать, чтобы оно реально работало. Но на самом деле, именно продажа лопат станков и является самым выскомаржинальным бизнесом. Но начальные инвестиции... мама не горюй. Вы не менее 10 станков должны за свой счёт сделать и минимум год упорной работы коллектива потрать, чтобы выйти на уровень, чтобы производимое что-то где-то как-то работало и продавалось. И это нужно несколько хороших специалистов, и каждому нужно хорошо платить на всё время опытов. А потом вложиться в выстраивание производственной цепочки, что отдельный процесс. Плюс, технологические риски - вы не знаете заранее себестоимость станка и его характеристики (ибо хайтек). Да, дальше оно несёт золотые яйца и отбивается за год или около того, но за эти деньги и время можно очень много всего другого менее технологичного запустить. Потому и очень мало желающих вкладываться. Мечта идиота в такое влезть, кстати...
А почему вместо шариков нельзя через трафарет нанести на чип/плату мелкую паяльную пасту? Или нанести пасту через трафарет на плату, убрать шарики с чипа, прогреть плату для формирования шариков на плате из пасты, остудить, положить чип и снова прогреть.
Более того, там же ещё вычеты и прочее, а мы этого не видим. Но я подозреваю, что в реальности автор платит налоги не со всего, а 6% посчитал, чтобы не инкриминировать.
В теории миграции должны уметь переводить базу из одного состояния в другое самостоятельно. То есть если у вас есть база, структура которой менялась несколько раз по мере развития программы, то если вы запустите последнюю версию, то она должна преобразовать базу к последней версии вне зависимости от того, какая текущая версия. Кроме того структура базы должна была автоматически строится из описания сущностей и взаимосвязей в ORM. Ради того оно всё и изобреталось. Это в теории. На практике оно ни черта так не работает. Точнее работает, но только для самых простых баз, а как только начинаем использовать что-то сложное и зависящее от конкретной реализации SQL, то сразу "Ой". А ещё оказалось, что часто при изменении структуры базы нужно ещё и данные в базе изменять нетривиальным образом, и тогда к красивой миграции приписывается куча кода, который очень все мечты об автогенерации. Ну, и в какой-то момент программисты, как обычно, стали миграциями заменять чуть ли не рукописное описание структуры базы, создав совершенно лишнюю сущность поверх SQL. На хрена это делается, и что именно экономится, никто зачастую толком объяснить не может, рассказывая абстрактные умные слова про миграции и автогенерацию, несмотря на то, что в реальности там внутри всё уже на костылях и подпорках и прибито к конкретной версии конкретной базы с кучей кастомного кода для преобразования базы от одной версии структуры к другой. Короче, всё как всегда.
Тем было ограничение на сжатие на уровне zswap. Что-то вроде не более четырех блоков памяти на место одного. Оно же все равно блоками жмёт. Но это очень жарко было, могли что-то и изменить уже.
У вас современный процессор, который умеет паковать со скоростью в несколько сотен мегабайт в секунду, и при этом нет SSD и не хватает ОЗУ? Это максимально странная конфигурация, как так получилось? А если у вас старый процессор, то он жмёт медленнее дешёвого SSD, нужно SSD ставить.
Не получится там десятков байт. Оно жмёт что-то вроде не более чем в три-четыре раза. И распаковка не мгновенная. А упаковка и вовсе. Если посмотреть скорость упаковки на слабых процессорах, то будет весьма неприятный сюрприз. Для бездимковых станций может и имеет смысл, но таки себе, м же т процессов слабый обычно. Оно то на то и выйдет. Я эту шляпу уже 15 лет на всяких сценариях использую, и с этого года от zswap отказался, если не HDD - нет сценария, при котором был бы хоть какой-то выигрыш. В реальности оно позволяло дать +15% памяти, если там есть какие-то редкоиспользуемые процессы. Как раз за счёт сжатия пустых страниц. Лучше всего работало на серверах, которые по какой-то причине были на HDD - там и процессор есть и долгоживущие фоновые задачи, которые выгрузить можно. Но сейчас этот нонсенс. На практике если latency посчитать... Работать с этим просто невозможно даже на "старых ноутбуках". Проще SSD минимальный поставить и на него своп+bcache, либо ОЗУ доставить.
Оно практически потеряло смысл сейчас. Сжатие имеет смысл только если ваш процессор по какой-то причине может упаковать данные быстрее, чем их может писать диск. В случае даже довольно старых процессоров и SSD/NVME дисков это уже практически невозможная ситуация. При этом нужно учитывать, что к времени сжатия нужно ещё суммировать время записи 2/3 изначального объёма, то есть времена суммируется. Если диск пишет хотя бы 300..500 мб/с, то уже всё очень сомнительно. Если 800 мб/с, то затея вообще смысла не имеет.
Только если HDD, вот там zswap при правильных настройках даёт заметный эффект.
История максимально странная. Его осудили за отказ сотрудничать со следствием. Но он мог отказаться свидетельствовать против себя, но почему-то этого не сделал. Возможно, там была информация, которая инкреминировала кого-то ещё, но точно не его, и это было заведомо известно следствию, и он с этим согласился или как-то признал. Только в таком случае мог появиться такой приговор.
Например, он знал что кто-то из друзей распространяет CP, и него были какие-то доказательства этого на диске. Сам он при этом мог ни раз этой CP не интересоваться, не распространять и не хранить (по крайней мере не хранить в меру своего знания). Например, у него была переписка с кем-то, в которой этот кто-то признаётся в распространении CP. Или чужой архив с паролем с CP "на продажу", сам он пароль мог не знать, если не участвовал, но происхождение, дата и наличие файла отлично можно свидетельствовать против кого-то другого. Или тупо логи какого-то распределённого клиента (типа eMule) - порнография могла проходить через его компьютер, но не присутствовать на нём. Вот тут отлично сядешь за отказ содействовать следствию. Правда, можно давить на отказ свидетельствовать против себя на основании вероятности обвинения в сокрытии преступления или соучастии. Короче, есть ощущение, что нормальный адвокат 100% его бы из этой ситуации выкрутил, но тут, похоже, парень решил поиграть в умника со следствием.
Ну, садиться самолётный автопилот, кстати, давно умеет. Даже вообще без помощи аэропорта (но с помощью GPS и Gbas/Sbas/Waas увеличивающих точность GPS). Он на "обычном" GPS сядет, но точность будет недостаточная для большинства полос аэропортов, что уже прямо сильно опасно.
Просто считается, что надёжность автопилота недостаточна для посадки, плюс, он не умеет реагировать на весь возможный спектр нештатных ситуаций.
И меня всегда веселило, что вся эта метрология не сходится с методичками по реактивному движению. Единственное разумное объяснение, что сечение сопла для метрологии очень небольшое и эффекты действительно получаются очень близки к идеальным теоретическим. Но это так себе объяснение. С тем же успехом можно допустить, что в методичках упрощённая туфта, так как в реальности все всё равно давно уже считают через динамическое моделирование по очень сложным моделям.
Давно это было, сейчас не найду. Но метрология для поверки и проверки расхода газов - вплоть до бытовых счётчиков газа - во много построена на постоянном расходе газа через критическое сопло.
Измеряем атмосферное давление (благо, что супер-точность не нужна), измеряем температуру воздуха, ставим баллон и за ним мощный вакуумный насос, поддерживающий разряжение в баллоне. Ставим на входе в баллон сопло. В трубе перед соплом будет постоянный и заранее известный расход воздуха/газа, а потому туда можно воткнуть счётчик и сверить/поверять его показания. Именно так большинство стендов для поверки и работают. Компухтер корректирует расход с учётом давления и температуры на входе. Точность у них заявляется до 0.1%. Единственный минус - переменная влажность воздуха, но это решается установкой осушающего кондиционера на температуру в комнате заведомо ниже уличной и контролем, чтобы влажность случайно не превысила макимально-допустимую. Для самых упоротых есть супер-пупер точные системы замкнутого цикла, на каком-нибудь азоте. Сами сопла покупаются у других очень специальных метрологов, которые изготавливают их с очень высокой геометрической точностью. Стендов по стране сотни тысяч и каждый сертифицирован по самое не могу. К каждому идёт комплект документации, где расписан принцип действия с обоснованием получаемой точности поддержания расхода и приведены формулы зависимости расхода от диаметра сопла и перепада давлений для воздуха. На всё это само собой есть ещё и набор ГОСТов, в которых эти формулы утверждены высшими силами с гарантией точности в нужном диапазоне условий.
А ещё есть метрологи, которые измеряют расход газа через критическое сопло, что является одним из самых точных методов. И они смотрят на это всё с недоумением, так как их формулы, хоть и являются очень частным случаем, но непрерывно подтверждаются экспериментально с относительной погрешностью до 0.1%. Но если посчитать то же самое по формулам из учебников по реактивной тяге или по вакуумной технике некоторых вузов, то там выходят совершенно иные цифры. И всем плевать. А потом приходят студенты, видят необходимость рассчитать расход газа через сопло, радуются, что их не зря учили, считают и получают невообразимую дичь с ошибкой 30+%.
Трафаретом и мелкой пастой? Трафарет на чип кладётся?
А дальше начинается... Нить/лента при подаче режет абсолютно всё. То, что она не режет, само сталь режет. Решаемо, но нужен опыт. Нужно постоянное натяжение нити/ленты при большом ходе каретки (ибо мачта). Причём это супер-критично. Пипец, как сложно, кстати. Тоже решаемо, но нужен огромный опыт. Нужна подача клея: равномерная и синхронизированная с подачей нити/ленты. Тоже решаемо, но нужно много опыта. Нужна механика и электроника, чтобы оно не клинило и не ломалось в случае чего. Нужна обслуживаемость, удобная смена катушек и расходников - тоже опыт.
Вот и получается, что там 1'000'000 сам станок и 19'000'000 - знание как именно это всё собрать, чтобы оно реально работало.
Но на самом деле, именно продажа
лопатстанков и является самым выскомаржинальным бизнесом. Но начальные инвестиции... мама не горюй. Вы не менее 10 станков должны за свой счёт сделать и минимум год упорной работы коллектива потрать, чтобы выйти на уровень, чтобы производимое что-то где-то как-то работало и продавалось. И это нужно несколько хороших специалистов, и каждому нужно хорошо платить на всё время опытов. А потом вложиться в выстраивание производственной цепочки, что отдельный процесс. Плюс, технологические риски - вы не знаете заранее себестоимость станка и его характеристики (ибо хайтек). Да, дальше оно несёт золотые яйца и отбивается за год или около того, но за эти деньги и время можно очень много всего другого менее технологичного запустить. Потому и очень мало желающих вкладываться. Мечта идиота в такое влезть, кстати...Просто сейчас я вижу, что реболинг делается реально установкой готовых шаров пинцетом, а раньше делали пастой через трафарет. Странно.
Спасибо
Почему должна быть индексация в коммерческих предприятиях? Нет такого закона.
А почему вместо шариков нельзя через трафарет нанести на чип/плату мелкую паяльную пасту? Или нанести пасту через трафарет на плату, убрать шарики с чипа, прогреть плату для формирования шариков на плате из пасты, остудить, положить чип и снова прогреть.
Более того, там же ещё вычеты и прочее, а мы этого не видим. Но я подозреваю, что в реальности автор платит налоги не со всего, а 6% посчитал, чтобы не инкриминировать.
В теории миграции должны уметь переводить базу из одного состояния в другое самостоятельно. То есть если у вас есть база, структура которой менялась несколько раз по мере развития программы, то если вы запустите последнюю версию, то она должна преобразовать базу к последней версии вне зависимости от того, какая текущая версия. Кроме того структура базы должна была автоматически строится из описания сущностей и взаимосвязей в ORM. Ради того оно всё и изобреталось. Это в теории. На практике оно ни черта так не работает. Точнее работает, но только для самых простых баз, а как только начинаем использовать что-то сложное и зависящее от конкретной реализации SQL, то сразу "Ой". А ещё оказалось, что часто при изменении структуры базы нужно ещё и данные в базе изменять нетривиальным образом, и тогда к красивой миграции приписывается куча кода, который очень все мечты об автогенерации. Ну, и в какой-то момент программисты, как обычно, стали миграциями заменять чуть ли не рукописное описание структуры базы, создав совершенно лишнюю сущность поверх SQL. На хрена это делается, и что именно экономится, никто зачастую толком объяснить не может, рассказывая абстрактные умные слова про миграции и автогенерацию, несмотря на то, что в реальности там внутри всё уже на костылях и подпорках и прибито к конкретной версии конкретной базы с кучей кастомного кода для преобразования базы от одной версии структуры к другой. Короче, всё как всегда.
Тем было ограничение на сжатие на уровне zswap. Что-то вроде не более четырех блоков памяти на место одного. Оно же все равно блоками жмёт. Но это очень жарко было, могли что-то и изменить уже.
CVV нет на магнитной ленте
У вас современный процессор, который умеет паковать со скоростью в несколько сотен мегабайт в секунду, и при этом нет SSD и не хватает ОЗУ? Это максимально странная конфигурация, как так получилось? А если у вас старый процессор, то он жмёт медленнее дешёвого SSD, нужно SSD ставить.
Не получится там десятков байт. Оно жмёт что-то вроде не более чем в три-четыре раза. И распаковка не мгновенная. А упаковка и вовсе. Если посмотреть скорость упаковки на слабых процессорах, то будет весьма неприятный сюрприз. Для бездимковых станций может и имеет смысл, но таки себе, м же т процессов слабый обычно. Оно то на то и выйдет. Я эту шляпу уже 15 лет на всяких сценариях использую, и с этого года от zswap отказался, если не HDD - нет сценария, при котором был бы хоть какой-то выигрыш. В реальности оно позволяло дать +15% памяти, если там есть какие-то редкоиспользуемые процессы. Как раз за счёт сжатия пустых страниц. Лучше всего работало на серверах, которые по какой-то причине были на HDD - там и процессор есть и долгоживущие фоновые задачи, которые выгрузить можно. Но сейчас этот нонсенс. На практике если latency посчитать... Работать с этим просто невозможно даже на "старых ноутбуках". Проще SSD минимальный поставить и на него своп+bcache, либо ОЗУ доставить.
Оно практически потеряло смысл сейчас. Сжатие имеет смысл только если ваш процессор по какой-то причине может упаковать данные быстрее, чем их может писать диск. В случае даже довольно старых процессоров и SSD/NVME дисков это уже практически невозможная ситуация. При этом нужно учитывать, что к времени сжатия нужно ещё суммировать время записи 2/3 изначального объёма, то есть времена суммируется. Если диск пишет хотя бы 300..500 мб/с, то уже всё очень сомнительно. Если 800 мб/с, то затея вообще смысла не имеет.
Только если HDD, вот там zswap при правильных настройках даёт заметный эффект.
Точно, лыжи, а я протупил.
А за время бурения самолёт несколько далеко уезжал, и что именно стимулировало полярников бежать быстрее самолёта, чтобы догнать его?
История максимально странная. Его осудили за отказ сотрудничать со следствием. Но он мог отказаться свидетельствовать против себя, но почему-то этого не сделал. Возможно, там была информация, которая инкреминировала кого-то ещё, но точно не его, и это было заведомо известно следствию, и он с этим согласился или как-то признал. Только в таком случае мог появиться такой приговор.
Например, он знал что кто-то из друзей распространяет CP, и него были какие-то доказательства этого на диске. Сам он при этом мог ни раз этой CP не интересоваться, не распространять и не хранить (по крайней мере не хранить в меру своего знания). Например, у него была переписка с кем-то, в которой этот кто-то признаётся в распространении CP. Или чужой архив с паролем с CP "на продажу", сам он пароль мог не знать, если не участвовал, но происхождение, дата и наличие файла отлично можно свидетельствовать против кого-то другого. Или тупо логи какого-то распределённого клиента (типа eMule) - порнография могла проходить через его компьютер, но не присутствовать на нём. Вот тут отлично сядешь за отказ содействовать следствию. Правда, можно давить на отказ свидетельствовать против себя на основании вероятности обвинения в сокрытии преступления или соучастии. Короче, есть ощущение, что нормальный адвокат 100% его бы из этой ситуации выкрутил, но тут, похоже, парень решил поиграть в умника со следствием.