С утильсбором как раз всё просто: правила ВТО не дают России повышать таможенные пошлины на авто, поэтому ввели "сбор", который формально платят все, но отечественным производителям его потом компенсируют субсидиями. Получается пошлина, которая правил не нарушает.
Могут и принять, но я думаю это проблема таких как я которые решили прочитать по диагонали и зацепились за тригер, это уже просто "усталость металла" после волн ботов и попытки (возможно успешной) превратить хабрахабр в филиал новостного сайта, где достаточно объявить о том что все хорошо, а доказывать на практике не принято. Но таки да - и новости про инновационность Артемиды (без шуток - это наконец выглядит как коммандировка а не как подвиг, так что иновации не нулевые) слишком заполонили инфопространство, я сам их давно просто мимо проглядываю
Передоз сарказма я и не уловил, батхертнуло так что пошел строчить ответ. Посыпаю голову пеплом, после многочисленных объявлений о том как старшип плох и как наш Зевс всех раскидает ру сегменте мой сарказм-фильтр сбоит.
"пока сенаторы не могли решить, какого цвета краску они хотят оплачивать" у нас тут один сенатор несколько раз выбирал имя "Орлу", и ничего, видимо на сроке в 100 об этом забыли, зато про краску у "Ориона" не забыли. Фантастика, что тут сказать. Фантазии по поводу "Орла" попросту не уместны - он в разработке с 2009-го года, и до сих пор железки нет, то есть, извините - только железка и есть - голый корпус который постоянно предъявляют на претензии о готовности. Орион начали разрабатывать в 2006-м, и уже в 2014-м был первый запуск. ПТК НП успел разве что поменять материал корпуса и название пару-тройку раз. Исходя из уже пройденного опыта шансы на то что что-то с первого раза сядет ну прямо скажем ничтожны.
И то и то долгострои, но у кого-то есть результат, а у кого-то - обещания. Можно поспорить об эффективности траты средств, но пока результата от программы ПТК НП нет никакого я думаю разумно считать что эффективность - ноль. С такими темпами программу быстрее "оптимизируют" и перенесут на 35-й чем, наконец, закончат хотя бы одним пилотируемым полетом.
Смешно то, что вы считаете что между количеством рабочих часов и успехами в экономике прямая связь. В мире много стран где рабочая неделя больше 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/
С утильсбором как раз всё просто: правила ВТО не дают России повышать таможенные пошлины на авто, поэтому ввели "сбор", который формально платят все, но отечественным производителям его потом компенсируют субсидиями. Получается пошлина, которая правил не нарушает.
Могут и принять, но я думаю это проблема таких как я которые решили прочитать по диагонали и зацепились за тригер, это уже просто "усталость металла" после волн ботов и попытки (возможно успешной) превратить хабрахабр в филиал новостного сайта, где достаточно объявить о том что все хорошо, а доказывать на практике не принято.
Но таки да - и новости про инновационность Артемиды (без шуток - это наконец выглядит как коммандировка а не как подвиг, так что иновации не нулевые) слишком заполонили инфопространство, я сам их давно просто мимо проглядываю
Передоз сарказма я и не уловил, батхертнуло так что пошел строчить ответ. Посыпаю голову пеплом, после многочисленных объявлений о том как старшип плох и как наш Зевс всех раскидает ру сегменте мой сарказм-фильтр сбоит.
Действительно, банкет удался
"пока сенаторы не могли решить, какого цвета краску они хотят оплачивать" у нас тут один сенатор несколько раз выбирал имя "Орлу", и ничего, видимо на сроке в 100 об этом забыли, зато про краску у "Ориона" не забыли.
Фантастика, что тут сказать. Фантазии по поводу "Орла" попросту не уместны - он в разработке с 2009-го года, и до сих пор железки нет, то есть, извините - только железка и есть - голый корпус который постоянно предъявляют на претензии о готовности. Орион начали разрабатывать в 2006-м, и уже в 2014-м был первый запуск. ПТК НП успел разве что поменять материал корпуса и название пару-тройку раз. Исходя из уже пройденного опыта шансы на то что что-то с первого раза сядет ну прямо скажем ничтожны.
И то и то долгострои, но у кого-то есть результат, а у кого-то - обещания. Можно поспорить об эффективности траты средств, но пока результата от программы ПТК НП нет никакого я думаю разумно считать что эффективность - ноль. С такими темпами программу быстрее "оптимизируют" и перенесут на 35-й чем, наконец, закончат хотя бы одним пилотируемым полетом.
Смешно то, что вы считаете что между количеством рабочих часов и успехами в экономике прямая связь. В мире много стран где рабочая неделя больше 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/