Там немного хитрее. Эти полуколеса движутся не синхронно, пока одни внизу, другие вверху. Поэтому сильных колебаний не возникает. Но зато эта штука может перешагивать через относительно большие препятствия и прыгать.
Ioanlarionov, огромное спасибо за статью. Я думал, что у меня антенна от магнитолы отошла и поэтому радио стало плохо ловиться. А оказывается это адвокамовский блок питания так фонит.
Если хорошей бумагой, то напечатайте на ней: «Продам такую же по n рублей за пачку» — и схему, как складывать журавлика. Сам лист сложить журавликом и в таком виде прислать.
1. Спутник вместе с топливом. С его помощью он будет корректировать и удерживать орбиту.
2. Вес железяки без топлива.
3. Вес платформы. Зачем каждый раз разрабатывать все заново? Берем готовую платформу, которая занимается энергообеспечением, связью, маневрированием, соблюдением температурного режима. И на неё вешаем своё оборудование. Вот bus — это платформа.
4. Вес полезных приборов, ради которых все и затевалось.
Я повторю еще раз: сравните вес камеры на GeoEye-1 и на LRO. И еще учитывайте, что высокое разрешение означает узкую полосу обзора. Увеличив разрешение вдвое мы увеличиваем время сканирования поверхности Луны в 2 или в 4 раза (зависит от того, в какие ограничения упремся). Соответсвенно полную карту получим значительно позже.
Вашим незнанием предметной области и математики. Разрешение LRO — 50см/пиксель. На 10 порядков больше — это 10 пикометров/пиксель. Так что речь не про порядки. Самые современные спутники сейчас снимают с разрешением 31 см/пиксель. На время запуска LRO лучшим результатом было 41 см/пиксель. Только весили эти спутники в два раза больше LRO и несли на себе только камеру. На LRO установлены и другие инструменты.
Ну а снимки городов с более высоким разрешением получены с самолетов и машин.
Поэтому мне кажется, что вы зря жалуетесь.
Я жалуюсь на то, что патч был отклонен с формулировкой «мы не знаем как работает эта часть кода из нашго репозитория поэтому не можем понять хороший патч или плохой, вдруг он не только исправит critical багу, но и еще что-нибудь сломает».
И еще я жалуюсь на то, что код у celery + combu очень сложный. Очень много абстракций.
А та часть системы, для которой у меня отлично подходил RabbitMQ — это небольшая часть, деталь реализации.
В случае ОМС с помощью быстрого нагрева в область переохлажденной жидкости можно получить изделие с высоким качеством поверхности в одну стадию как при сверхпластичной формовке. Но ОМС ввиду отсутствия границ зерен будут предпочтительнее для микрообъектов чем сверхпластичные сплавы ввиду исключительно высокого качества поверхности.
Вот меня и удивило
1) Не кристаллизуется ли при этой процедуре металл? Из общих соображений я понимаю, что рекристаллизация должна пытаться происходить, но почему тогда поверхность получается хорошей? Или все-таки умеют провести формовку достаточно быстро, чтобы металл остался аморфным?
2) Какая это температура переохлажденной жидкости? Насколько проще работать с ней, чем с расплавленным металлом.
Насколько я понял, одно из преимуществ металлических стекол в том, что если заготовку нагреть, то она легко и хорошо формуется. Насколько сильно её надо нагреть? Как эта температура соотносится с температурой плавления сплава? И в каком состоянии будет металл в итоговом изделии? Он останется аморфным или кристаллизуется?
Для меня это самый интересный материал как минимум за сегодня. И в посте столько новой интересной информаци, сколько я получил с остального geektimes сегодня. Ради этого я готов продираться через незнакомые термины. Их на самом деле не так много оказалось.
Или использовать хорошую антенну. Например bluetooth обычно работает на расстоянии нескольких метров. Но лет пять-десять назад рекорд по утаскиванию телефонной книжки с обычного телефона был около 1.6 км.
В проекте уже использовалась монга. Соответсвенно можно было использовать её, а можно было поднимать рядом RabbitMQ. Отделу администрирования не понравилась идея поднимать еще один сервис и обеспечивать его отказоустойчивость. Причем опыт эксплуатации mongo был значительно больше, чем и RabbitMQ.
У меня очень негативный опыт использования celery и особенно связки celery + mongo. Производительность мне была не важна, задачь очень мало. Но их надо было не терять. Т.е. если я добавляю задачу то она, во-первых, должна когда-нибудь выполниться, а во-вторых, мне должен прийти результат выполнения задачи. Запускаю систему, она работает, но иногда задачи исчезают. Долго копаюсь в коде, а там в celery абстракция над абстракцией и абстракцией погоняет, нахожу проблему, исправляю. Заодно понимаю, что оно by design будет терять задачи: задача выгружается в память воркера и если он упадет, то попытается в expect блоке положить её обратно в очередь. Но может и не положить.
Потом выясняется, что при смене мастера монги celery виснет. Оно исключение не обрабатывало. Пишу патч, отправляю разработчикам. Результат — мы сами не используем mongodb, поэтому не понимает что это исправление делает, так что патч принимать не будем.
Пока они над этим думали, я написал свой велосипед который занимает на несколько порядков меньше строк кода и который рагантированно отказоустойчив.
Volatile и многопоточность — не очень хорошая практика. По крайней мере в C++. Для многопоточности есть специальные высокоуровневые примитивы, в частности atomic.
2. Вес железяки без топлива.
3. Вес платформы. Зачем каждый раз разрабатывать все заново? Берем готовую платформу, которая занимается энергообеспечением, связью, маневрированием, соблюдением температурного режима. И на неё вешаем своё оборудование. Вот bus — это платформа.
4. Вес полезных приборов, ради которых все и затевалось.
Ну а снимки городов с более высоким разрешением получены с самолетов и машин.
Я жалуюсь на то, что патч был отклонен с формулировкой «мы не знаем как работает эта часть кода из нашго репозитория поэтому не можем понять хороший патч или плохой, вдруг он не только исправит critical багу, но и еще что-нибудь сломает».
И еще я жалуюсь на то, что код у celery + combu очень сложный. Очень много абстракций.
А та часть системы, для которой у меня отлично подходил RabbitMQ — это небольшая часть, деталь реализации.
Вот меня и удивило
1) Не кристаллизуется ли при этой процедуре металл? Из общих соображений я понимаю, что рекристаллизация должна пытаться происходить, но почему тогда поверхность получается хорошей? Или все-таки умеют провести формовку достаточно быстро, чтобы металл остался аморфным?
2) Какая это температура переохлажденной жидкости? Насколько проще работать с ней, чем с расплавленным металлом.
Потом выясняется, что при смене мастера монги celery виснет. Оно исключение не обрабатывало. Пишу патч, отправляю разработчикам. Результат — мы сами не используем mongodb, поэтому не понимает что это исправление делает, так что патч принимать не будем.
Пока они над этим думали, я написал свой велосипед который занимает на несколько порядков меньше строк кода и который рагантированно отказоустойчив.