All streams
Search
Write a publication
Pull to refresh
4
0

User

Send message
Читая статью, мне пришла в голову мысль, чтобы получить достоверные снимки луны без искажений цвета, вносимых атмосферой земли, достаточно посмотреть на снимки луны сделанные с борта МКС. И не надо никаких предсказательных моделей или компиляций множества снимков.
смотря из какого металла коробочка, если из железа то на земле она наверное не очень нужна, но как оболочка для груза сойдёт, а если из иридия или платины или ещё какого редкоземельного то может пригодиться
Но если вам нужно организовать на орбите не просто 70к живого веса с головой, а те же 70к помноженные на миллиард особей, да ещё и с генетическим разнообразием.
То я предполагаю, что поднимать с земли уже в готовом виде все эти белки жиры и углеводы, или как у другого комментатора кислород азот и углерод, это слишком дорогое удовольствие. Гораздо проще будет поднять инструкции по сборки в пробирках, а вещество собрать из мест где потенциальный колодец не такой глубокий.
Текущие технологии позволяют поднимать, грубо говоря, максимум 1000 людей в год. И это не особо сильно масштабируется. Сколько понадобится времени (и топлива) чтобы поднять хотя бы 2М людей? Сколько из них умрёт за это время и сколько родит новых? Так что космос не решение проблемы перенаселённости, для этого есть другие технологии.

Но если уж создавать самодостаточную колонию, то тут понадобится много рабочих рук, которые и так со сменой многих поколений родятся, и большое генетическое разнообразие. Есть конечно подсчитанный минимально необходимый уровень этого разнообразия, но и пополнение не будет лишним.
Это всё конечно правильно. Правда описано из предположения, что всё необходимое (коробка, двигатели, топливо) для доставки этого 1 кг урана сначала поднимается из потенциального колодца земли. Для чего естественно необходимо потратить очень много условного керосина. Доставляется до астероида, возвращается обратно и потом сбрасывается обратно на землю.
Но если допустить, что для разгона этого самого 1 кг урана использовать массу (для простоты возьмём воду) взятую с того же самого астероида, пусть даже если на это понадобиться не 200кг, а 2т или все 20т. Эту массу разгонять энергией, взятой например от солнца или если угодно от ещё 1-го кг урана. Коробку для этого 1 кг урана построить из металла, добытого на том же самом астероиде, на землю эту коробку спускать в идеале без двигателей и потом эту коробку не надо будет поднимать обратно с земли. То экономика такой доставки будет куда интереснее.
То есть строить десятки лет и засылать на условный Марс не единичный уникальный аппарат, который с некоторым шансом выживет, запустится и проработает хотя бы половину предполагаемого срока. А засылать туда десятки таких аппаратов сразу, да ещё контейнер запасных крупных блоков к ним, что бы с временным лагом в час удалённо по фотографиям анализировать и управлять починкой. При этом ценой ошибки в переданной команде будет два неработающих аппарата.

Хотя возможно это будет всё ещё дешевле инфраструктуры для человека.
Но если до этого построить и наладить перевалочные пункты на орбите земли и луны, добычу и переработку ресурсов в космосе. То не придётся на каждый такой аппарат запускать по ракете с поверхности планеты с топливом на перелёт сразу до конечного пункта.
Автор в заголовке задаёт первый вопрос, но складывается такое впечатление, что в статье пытается ответить на второй.

Осуществлять управление автоматами дистанционно можно, до некоторых пределов, а вот чинить поломки, неизбежно возникающие со временем, уже не возможно. Многократное резервирование помогает, до некоторой степени, хоть и предназначено в основном для повышения шансов выполнения миссии, и только в случае успеха позволяет продлить миссию на относительно небольшой срок.
Строительство и отправка с земли автоматов, хоть и дешевле отправки человека, но, на мой взгляд, является только первым этапом, призванным отладить технологии, за которым неизбежно должно последовать строительство всей необходимой инфраструктуры для комфортного пребывания человека. Особенно для долгосрочных проектов.
В качестве примера можно вспомнить хаббл, который пришлось чинить и обновлять человеческими руками. А сколько марсоходов, луноходов и венероходов бросили практически в самом начале миссии?
Зачем нам осваивать космос или зачем человеки в космосе?
1. далеко не всё можно сделать с помощью удалённо управляемых роботов, они на удивление быстро ломаются и чинить их некому, присутствие неподалёку универсального биологического робота сильно облегчает диагностику и ремонт.
3. изучение окружающего мира, как минимум с помощью сверх больших телескопов за пределами атмосферы, как максимум при личном присутствии, строительство и поддержание таких объектов немыслимо без присутствия человека
3. бэкап человеческого генома, культуры, науки и цивилизации, биосфера земли слишком хрупкая и может быстро разрушиться как от действий человека так и от случайно прилетевшего из вне метеорита
4. в космосе уже найден ресурс с которым большие проблемы на земле, даже два: вакуум и невесомость, и сейчас активно разрабатываются технологии в которых очень нужны эти два ресурса. и это не считая обычных металлов и энергии.

Но при этом космос не стоить рассматривать в качестве решения проблемы перенаселённости, не с текущими технологиями преодоления потенциального колодца планеты, выводить по сто килограмм живого веса, что бы сократить численность на пару миллиардов, это слишком дорогое удовольствие. Гораздо дешевле поднять наверх пробирки со сперматозоидами и яйцеклетками, вырастить их наверху и обучить на месте.
При упоминании улитки на склоне, мне почему то в первую очередь вспомнился Пелевин. Там тоже был своего рода финансовый гений.
Технически Stable Diffusion можно запустить только на CPU без привязки к GPU с большим количеством видео памяти. Да это будет работать на порядки медленней, но будет работать. Если бы это было сделано в режиме установки в 1 клик то это сделало бы модель ещё более народной. Вообще идеальный результат видится как запуск генерации изображения любого размера без ограничений с использованием всех доступных ресурсов.
Так же популярности возможно добавила бы мультиязычность. Я конечно понимаю что для этого скорее всего надо иметь переобученную модель, возможно даже немного другой архитектуры, но такие модели уже существуют, например от того же сбера.
Тоже такую картину наблюдал всё лето. Настойчиво перепробовал разные браузеры под разные операционки, неизменно в консоли браузера наблюдал ошибку CORS policy. Но где-то с месяц назад смог успешно активировать в последнем хроме. И сбрасывать для проверки что то не тянет.
Если есть опасения что смс не дойдёт или имеется общее недоверие одноразовым паролям по смс, то отключать двухфакторную авторизацию всё таки не стоит потому, что на на госуслугах всё таки заработал TOTP и второй фактор можно поменять на него.
Не знаю в каком качестве участвует секретный вопрос в процедуре восстановления доступа, не пробовал, но раз дают такую возможность, то его тоже стоит добавить, естественно не указывая в качестве ответа на него никакой публичной информации.
Популярные репозитории, на которых размещается исходный код – Github и Gitlab — стали популярными не потому, что продвигали централизованные структуры для дистрибуции Open Source, а потому что предлагали и предлагают бесплатный свободный сервис любому при соблюдении определённых условий. Если есть желание развивать Open Source движение в России, забудьте пожалуйста про централизованные структуры, в них никто не пойдёт, даже если будет какой нибудь закон требующий этого, структуры эти будут пустовать. Для развития Open Source могут стать привлекательным только множество различных децентрализованных, свободных от цензуры и блокировок, независимых и бесплатных сервисов. Один из которых вы можете развернуть на своих мощностях уже сейчас.
А можно ли в подобной схеме обойтись без постоянно работающего насоса?
Разместить основную ёмкость с раствором повыше, давление обеспечить за счёт разницы высот, слив опускать во вторую ёмкость пониже, из которой перекачивать в основную ёмкость только при заполнении регулируя поплавковым датчиком или например в ручную.
А насчет найма возможно интервьюеры хотят увидеть, что вы делали, работая в команде с заказчиками, а не чисто технические скиллы в проекте, где и вы и требования сами определяли и сроки и выбор технологий

Если это конечно не open-source, то показ кода, который пишется для заказчика и хранится в приватном репозитории, подпадает под ряд законов и положений договоров о неразглашении. А если найм идёт на написание такого же закрытого кода, то ещё более странно, что интервьюеры ожидают увидеть тех, кто готов раскрывать посторонним код и детали реализации в целях получения выгодного предложения.
Квантовые коммуникации ещё можно понять — это привычное уже оптоволокно по которому передаются запутанные (что бы это не значило) фотоны.
Но вот что такое квантовый интернет вещей?
Или в этом словосочетании «квантовый интернет вещей» упор делается на слово «интернет»?
Что приводит нас к тому же оптоволокну с фотонами. Вместо упора на слово «вещей» за которым скрывается обычно маломощный контроллер отправляемый данные с датчиков на сервера.
Я бы хотел прокомментировать ситуации, когда комментарии вполне уместны:
Информация об авторских правах.

Это те самые плашки в целый экран в начале каждого файла, которые никто никогда не читает, по этому IDE их скрывает автоматически, никто никогда не актуализирует, которые IDE вставляет автоматически при создании очередного файла по шаблону который никто никогда не меняет. Единственная причина по которой их вынужденно добавляют это наличие параллельного юридического мира, который вынуждает разработчиков заботиться о лицензионном статусе кода.
TODO-комментарии.

TODO-комментарии не должны в фиксироваться в репозитории в качестве конечного результата работы, не должны проходить код-ревью, не должны пропускаться CI/CD скриптами, иначе про них забудут и в проекте останутся TODO-комментарии добавленные много лет назад разработчиками которые уже давно ушли, код вокруг таких комментариев будет модифицироваться, но сам комментарий как памятник будет жить вечно.
Пояснения важности чего-либо или объяснение конкретного решения в коде.

противоречит всему что было написано в этом параграфе про комментарии
Комментарии публичных API обязательны (JavaDocs, …), но избегайте их в непубличном коде. Не заставляйте команду комментировать все функции всех ваших классов!

Это те самые JavaDocs которые вставляются IDE автоматически, которые не добавляют ничего нового к описанию методов и параметров, потому что генерируются на основе имён методов и параметров, и никогда никем потом не актуализируются и не обогащаются дополнительными разъяснениями по используемым параметрам и особенностям работы методов. На основе таких комментариев генерируются странички с документацией, которая вроде как есть, но не разъясняет ничего о том, как использовать методы и какие параметры передавать, тому, кто нашёл эту документацию. И те редкие разработчики, как например разработчики Spring-а, гордятся тем, что стараются писать такие комментарии максимально подробно и поддерживать в актуальном состоянии.
Насколько я понял, сейчас существуют и развиваются квантовые алгоритмы, которые предполагают, что как только появятся квантовые компьютеры, которые удовлетворяют определённым критериям и реализуют определённые квантовые операции и квантовые примитивы в достаточном количестве, то уже будут готовы эти самые алгоритмы и на их основе можно будет писать квантовые программы.
При этом, на каком физическом принципе будут основаны эти квантовые компьютеры не имеет значения, если они удовлетворяют заданным критериям.
И пока таких квантовых компьютеров нет, алгоритмы запускаются в симуляторах на обычных компьютерах и естественно работают медленно.
Но работа над созданием таких квантовых компьютеров ведётся, новые достижения постоянно анонсируются и вот уже эти конкретные реализации имеют определённые технические характеристики: количество кубитов, реализуемые операции и прочее.
Интересно, а вы вообще в курсе, что у вас проблемы с безопасностью аккаунтов настолько большие, что даже мошенники включили в свои сценарии социальной инженерии взлом аккаунта на госуслугах через выпрашивание номера из смсок?
Это показывает что номер телефона превратился из второго фактора авторизации в единственный достаточный. И уже неважно какой взломостойкий пароль придумает пользователь и какой второй фактор установит, для восстановления доступа достаточно четырёх цифр из смски.
Поэтому у меня вопрос: Как мне удалить номер телефона из аккаунта в госуслугах и запретить его добавление? О том, что его можно поменять я знаю, спасибо, но я хочу закрыть этот вектор взлома вообще. Телефон на аккаунт я добавлять не хотел, но его вытребовали в минуту слабости для регистрации в голосовании и меня не спросив привязали к аккаунту.
Кстати о втором факторе. Активация TOTP на аккаунте выглядело как нечто перспективное, не работает ни в одном браузере из-за не корректных CORS policy. А жаль.
Почему я это пишу здесь? Потому что на сайте госуслуг нет формы обратной связи. Все ссылки на форму обратной связи ведут на тупого бота. Но бот это не форма обратной связи потому, что надо очень сильно поломать мозг подбирая ключевые слова в сообщении, чтобы либо переключить бота на оператора и потом бесконечно ждать от него ответа, либо увидеть заветное «ваше сообщение передано разработчикам». Но и это не гарантирует того, что ваше подробное описание проблемы не отправлено в /dev/null. С тем, что этот тупой бот вылазит на каждой странице сайта и только раздражает, можно только смириться.

Information

Rating
Does not participate
Registered
Activity