Смешно то, что вы считаете что между количеством рабочих часов и успехами в экономике прямая связь. В мире много стран где рабочая неделя больше 70 часов, но вы привели только те которые по стечению обстоятельств успехами обзавелись, так может быть проблема не в количестве часов в неделю? Я уж не говорю что в Японии до сих пор принято уходить с работы много позже конца рабочего дня и как-то это не помогает выйти из тридцатилетней стагнации.
Мой опыт общения с интернами в компании сводился к перманентному ощущению что я не с человеком говорю, а пишу промт для слабенькой gpt - ведь твои слова в итоге не пойдут 1-в-1 в промт, а будут искажены "пониманием" другого человека. Часто приходится подпинывать в самостоятельное написание кода, понимаю что звучит как "использование калькулятора отупляет" но боюсь что с такими темпами качество джунов упадет в ноль. В итоге сошлось все к объяснению на пальцах идеи о том, что с джуна взятки гладки, никто не просит немедленного результата, и можно потратить на задачи чуть больше времени. И только тогда все сдвинулось с мертвой точки и появился осмысленный результат, а не просто прокладка между мной и gpt
В Красноярске (для не знающих напомню - это практически посреди страны, сибирь, расстояние до Москвы и до Владивостока не сильно отличается) мобильный интернет с проблемами с августа. С пробуждением.
Даже пример простого многопоточного кода на Rust — вещь, которую молодой разработчик сегодня спокойно скомпилирует в браузере на любом онлайн-песочнице, а лет десять назад это бы выглядело как мини-квест
Это какой-то тонкий тролинг? Онлайн компиляция rust на их офсайте доступна с 14-го года минимум. Допустим tokio еще как такового не было, но докер и кубер тогда уже были. Что за странные утверждения в статье? Это не скачок в производительности разработчиков, это взросление технологий как таковых.
Заголовок стремный кликбейт, первые компиляторы высокоуровнего кода с этой точки зрения тоже сделали "молодых разработчиков" бородатых годов способными "на то что раньше казалось недостижимым", но причем тут молодые разработчики-то?
Ну то есть окей, не мне судить что важно а что нет, но есть ли какая-то логика почему именно этот продукт удостоен новости? Почему, например, нет новостей про минорные релизы Google Chrome? Этож сколько новостей можно написать-то...
Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
"Переход к новой "короткой" схеме стал возможен только с вводом в эксплуатацию ракеты-носителя "Союз-2.1а", позволяющей по своим техническим характеристикам и возможностям системы управления выводить космические объекты на заданную орбиту с высочайшей точностью. Также важной особенностью реализации двухвитковой схемы сближения со станцией является предварительное формирование требуемой рабочей орбиты МКС и точное выполнение заложенной в бортовой вычислительный комплекс транспортного корабля программы автономного наведения"
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
Не удивлюсь, если немецкие инженеры, увидев, что творит их начальство, уже передали...
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?
Смешно то, что вы считаете что между количеством рабочих часов и успехами в экономике прямая связь. В мире много стран где рабочая неделя больше 70 часов, но вы привели только те которые по стечению обстоятельств успехами обзавелись, так может быть проблема не в количестве часов в неделю? Я уж не говорю что в Японии до сих пор принято уходить с работы много позже конца рабочего дня и как-то это не помогает выйти из тридцатилетней стагнации.
Мой опыт общения с интернами в компании сводился к перманентному ощущению что я не с человеком говорю, а пишу промт для слабенькой gpt - ведь твои слова в итоге не пойдут 1-в-1 в промт, а будут искажены "пониманием" другого человека. Часто приходится подпинывать в самостоятельное написание кода, понимаю что звучит как "использование калькулятора отупляет" но боюсь что с такими темпами качество джунов упадет в ноль.
В итоге сошлось все к объяснению на пальцах идеи о том, что с джуна взятки гладки, никто не просит немедленного результата, и можно потратить на задачи чуть больше времени. И только тогда все сдвинулось с мертвой точки и появился осмысленный результат, а не просто прокладка между мной и gpt
В Красноярске (для не знающих напомню - это практически посреди страны, сибирь, расстояние до Москвы и до Владивостока не сильно отличается) мобильный интернет с проблемами с августа. С пробуждением.
Это какой-то тонкий тролинг? Онлайн компиляция rust на их офсайте доступна с 14-го года минимум. Допустим tokio еще как такового не было, но докер и кубер тогда уже были. Что за странные утверждения в статье? Это не скачок в производительности разработчиков, это взросление технологий как таковых.
Заголовок стремный кликбейт, первые компиляторы высокоуровнего кода с этой точки зрения тоже сделали "молодых разработчиков" бородатых годов способными "на то что раньше казалось недостижимым", но причем тут молодые разработчики-то?
Я наверное чего-то не понимаю, но зачем писать на технический ресурс новости о минорном релизе просмотрщика изображений?
3.1.3 - https://habr.com/ru/news/913042/ - 27 мая
3.1.4 - https://habr.com/ru/news/920432/ - 21 июня
и теперь 3.1.5 - 16 июля.
Ну то есть окей, не мне судить что важно а что нет, но есть ли какая-то логика почему именно этот продукт удостоен новости? Почему, например, нет новостей про минорные релизы Google Chrome? Этож сколько новостей можно написать-то...
А кто-нибудь знает существует ли еще smd-taxi ? Сайт у них не особо обновляется, но по крайней мере это был установщик реально местной сборки
Именно по этому Дракон отправляется с урезанным экипажем - двое вместо четверых. Так что риск будет только между моментом отстыковки старлайнера (планируется на 6 сентября) и пристыковкой Crew-9 (25 сентября), что, впрочем, тоже не хорошо.
Проблема не только в этом. У посетителей МКС (астронавтов, космонавтов и т.п.) должна быть возможность экстренной эвакуации. Если Старлайнер отправляется в беспилотном режиме, астронавты остаются на МКС без пути отхода - ведь на оставшихся кораблях места не хватит. Не спичку же тянуть...
Это одна из причин по которой в НАСА до сих пор не определились. Наряду с проблемой того что сбойный сервисный модуль сгорит в атмосфере, а значит расследование причин отказа усложняется значительно - на Земле же походу не воспроизвели.
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
Чисто технически, разворачивание и сворачивание это разные операции, скорее всего нужны отдельные приводы для этого, такую массу тащить на орбиту незачем, а на земле можно свернуть внешними приводами. Ну и в целом - сведение и выведение это очень разные процессы по перегрузкам. Для понимания - большую часть времени при создании подобных систем занимает тестирование - т.е. дешевле новый сделать чем спустить этот и потом опять подготовить к запуску.
Вообще предусмотрены. Для возможной дозаправки добавлены соответствующие клапаны, пассивный стыковочный механизм (простейший, по сути интерфейс с РБ) тоже есть. Всерьез, правда, никто не планировал... Подробней можно почитать тут
Другое дело, что в отличие от Хаббла никакая разборка на орбите с заменой внутренних деталей невозможна - там обслуживание было полноценной фичей, Хаббл делался как ПН для Шаттла в первую очередь
На самом деле скорость столкновения может быть почти какой угодно. Мусор может быть и на не-круговой орбите и на наклоненной на 180 градусов относительно орбиты космонавта - вариантов не так уж и мало. А объекты на той же орбите опасности не представляют вообще - относительная скорость почти никакая. 7км\с это ведь относительно Земли, а не относительно космонавта
https://tass.ru/kosmos/5360378
Уж не знаю зачем это конкретно, я не настоящий сварщик, видимо не всякая возможная орбита МКС подходит для быстрой схемы
Вы так говорите как будто это фишка Союза (корабля) хотя это в большей степени обеспечено расчетом баллистики и минимизацией "зазора" запуска РН. Ну и тем фактом что наклонение МКС подобрано именно под Байконур, и не факт что с какого-либо другого космодрома, кроме реально экваториальных (а не просто близких, как Канаверал), можно делать выкрутасы с ловлей МКС за 1-2 витка.
Это было бы очень странно, ведь то что делает телескоп первое время это обзоры, а обзоры имеет смысл делать в наиболее широком спектре, т.е. обоими телескопами. Можно вот тут почитать https://habr.com/ru/post/508760/
А потом сели мотать срок? У нас тут умудряются сесть и за журналистику в этой области, а "передать документацию по управлению" это несколько иной уровень
Срок активного существования у этого телескопа 6.5 лет, и несколько обзоров неба eROSITA уже собрала, так что мы не останемся совсем без ничего. Я думаю шанс на то что сотрудничество по фундаментальным наукам стабилизируется за следующие 3.5 года есть - ИТЕР же как-то продолжают строить. А шанс восстановить сломанный телескоп без знания как он устроен крайне низок. Включить они его наверное включат, но, как и во всем космическом - нет проблем с ситуацией когда все хорошо, главные проблемы возникают в ситуации когда хорошо не все, и вот режимы восстановления можно и не осилить.
Можно сколько угодно спорить о том стоило ли его выключать, фундаментальная наука она для всех. Но это дело тех, кто этим инструментом владеет. Впрочем, Роскосмосу не привыкать заниматься космическим пиратством.
Такие телескопы работают долгие годы - может лучше подождать пока отношения стабилизируются хоть чуть-чуть? С орбиты он никуда не денется, сломать всегда можно успеть, а чинить потом - как? Это не домашняя фотокамера с защитой от дурака, телескоп при неправильном обращении легко можно и спалить или, в лучшем случае, отправить в безопасный режим, а как его оттуда вытаскивать потом, методом тыка?
Желание даже всех ученых ЕКА недостаточно - нужна более конкретная информация о порядке восстановления и требуемых командах, а такую без явного и публичного разрешения никто не предоставит.
Это не то дело, которое "пробуют" - риск не оправдан, второго шанса может не быть.
Просто инженеры консервативны в оценках. Это как с марсоходами - гарантируют не меньше месяца работы, а караются потом годами сверх гарантированного срока.
Да и вообще, тут же речь про передовой научный инструмент! Большинство ключевых технологий в космосе в первый раз, было бы странно если бы предельные характеристики всех решений были точно известны заранее, ведь тогда бы он не был бы передовым, скорее рядовым, правильно?