Тестируется на собираемость и на запускаемость в той же кему. А то что много различных устройств нельзя так протестировать, и что без тестов и всесторонней проверки кода ядра, это опускается.
Надежда на авось и прочие особенности разработки людьми не несущими ответственность. Что интересно из одной это ошибки видно очень много допущений и ошибок которые совершили разработчики ПО для данного КА.
Флешка это скорей всего криптор для прошивки, т.е. она работает по тому же принципу что и все современные обновления для железок по сети: прошивка шифруется на той стороне и снабжается подписью, и придя на устройство она верифицируется и дешифруется. Это объясняет то что её можно использовать как для локального управления, так и для удалённого.
Во-первых, проблема двух глаз, направленных в одну сторону – это не нужно роботам.
, если внимательно посмотреть на голову робота, а также на «вид изнутри», то можно понять что это не два «глаза», а обыкновенный экран(в фильме также можно видеть загрузку робота), а глаза у него таки внизу, ниже динамика. И да там присутствует подвижный лидар и пару других специфичных датчиков.
Тут скорее другое хотел подчеркнуть: то что текущие реализации это даже не грубая модель, а просто «догадки» о содержимом чёрного ящика.
Т.е. посмотрели что поведение сходно, а как и главное зачем особо размышлять не стали. И проблема тут не в том, что специалистов нету, а в том, что нету специалистов подобных Норберту Винеру, которые бы могли мыслить сразу в нескольких областях, на грани между биологией и информатикой. Все современные исследования наоборот либо утекают в область реализации на биологических компонентах, либо на чисто электронных и принципам более типичным в каждой области, так например более 70% решений идут чисто цифровые, используя классическую электронную базу. И очень часто подменивают понятия — т.е. «обычный» векторно-матричный процессор называют нейронным (походу маркетинг чистой воды). Таких примеров много.
Я сам когда-то пытался понять всё это, но к сожалению не хватило ни знаний, ни опыта, ни времени.
«Понятность» можно сделать объективным если измерять ещё разработчиком со стороны, который не имеет отношение к написанному коду. Для форматирования кода есть свои стандарты, которые можно требовать от участников процесса. И т.д. и т.п.
А касательно времени жизни структуры проекта это уже другой вопрос. Есть люди которые помнят свой код достаточно долго (у меня напарник на работе достал код 3-х годичной давности и смог его поправить, т.к. помнил даже название методов которые делали нужную ему работу). Поэтому это сложный момент, что считать «плохой архитектурой».
Также касательно «сеансов», лучше их избегать вовсе на этапе разработки рабочего кода, в следствии того что разрабатывать будет команда со средним опытом, а не одиночки, как бывает у прототипа. Отсюда следует то что «сеансам» самое место на прототипировании проекта, при проверки смелых идей и новых мыслей.
Конечно, т.к. достаточно почитать Буча — там таких примеров навалом. Главное не забывать что реально, а что нет. Т.к ход мыслей бывает сложно остановить. Вообще это черта любой профессии в которой есть творческий контекст и требуется абстракция над текущим процессом.
Но при этом многие товарищи, в том числе тот же Макконнел, Роберт Мартин советуют не «увлекаться потоковым программированием». Причина этому проста — в состоянии потока как и в любой эйфории есть отвлечение от реальности, когда мы можем упустить самые базовые вещи по причине того что они нам кажутся слишком очевидными.
1) Опять слова из контекста, я не говорю что он чем-то был скопирован, я говорю что он появился из сходных побуждений.
2) Касательно клонов ядер NT, так это уже боян, причём давнишний. Этим баловались серьёзные Windows программисты 200х, так и частные конторы. На основе одного из таких проектов и зародился нынешний ReactOS.
А совместимость софта она очень зыбкая, т.к. не возможно на те же 80% сделать совместимость с Windows не используя код Windows (если парням из MS такое не удаётся сделать даже внутри ветки NT, между версиями).
Тут немного другое, т.к. главный показатель это количество повторно используемого кода — стандартные библиотеки и прочее. А также технологичность подхода, наличие схожих проектов и много чего другого.
Так вот ReactOS это чуточку переросший Wine, имеющий как свои достоинства так и недостатки. Попытка из Wine сделать ОС, это очень смелый шаг, который требует очень много внимания к себе. Это во первых, а во вторых необходима чётка цель проекта, идея которая отличает его от прочего.
В данном случае я пока не вижу особого различия между копипастой алгоритмов из работающей ос (Windows) и ReactOS, и которой в своё время ушёл один из разработчиков как раз по этой причине (да, я как человек в своё время являвшийся ярым сторонником Windows достаточно подробно изучил всё то что составляет ReactOS).
P.S. не надо рассматривать мои комментарии как ненависть к разработчикам — это их свободное время, и им решать что правильней. Однако следует помнить о том что любой аргумент должен иметь под собой базу. А не попытку давить на жалость.
Ну на лицо подмена понятий. Повторение уже пройденного пути (используя информацию от других людей) и самостоятельное открытие своей «Луны» напрочь игнорируя чужой опыт.
Первое даёт понимание проблемы человеком, последнее кучу убитого времени и негативное отношение как к собственной работе так и к работе других.
Первое с чем сталкивается человек который выкладывает что-то в открытый доступ — это критика и неуважение со стороны других. Причём в это число входят как те кто в будущем будет активно пользоваться этим продуктом, так и те кто не смог построить аналогичный продукт в своё время и поэтому всячески старается его задавить.
Однако вместе с тем существует куча различных вещей которые не надо делать, не потому что они плохие, а потому, что их уже сделали.
Один из первых признаков правильной организации труда — повторное использование уже сделанного. Поэтому и возникают различные трения и реакции других людей.
Нету смысла переоткрывать уже открытые планеты и звёзды, однако можно просто их изучать с целью понимания происходящего.
Холивар это попытка доказать что ботинки твоего размера лучше всего подходят соседу(даже если у вас различия в размере больше чем в 2 раза).
Всё выше перечисленное чисто личное мнение, однако как показывает практика (а у меня её было достаточно), нету таких вещей которые нельзя усовершенствовать и лучше приложить силы именно туда, нежели пытаться навязывать другим свои личные мысли и заблуждения.
Тут да, местами удачный конец не по нраву тем кто проживает на западе.
Правда вступает в ход одно оправдание — режиссёрское видение.
Хотя по мне лучше так чем придумывать логически не связанные с основным сюжетом концовки.
Ну как сказать — от оригинального произведения (если его из минусующих кто-нибудь читал) — не осталось почти ничего.
Да и красивая секира у героини превратилась в лопасть от хвостового пропеллера.
Т.е. посмотрели что поведение сходно, а как и главное зачем особо размышлять не стали. И проблема тут не в том, что специалистов нету, а в том, что нету специалистов подобных Норберту Винеру, которые бы могли мыслить сразу в нескольких областях, на грани между биологией и информатикой. Все современные исследования наоборот либо утекают в область реализации на биологических компонентах, либо на чисто электронных и принципам более типичным в каждой области, так например более 70% решений идут чисто цифровые, используя классическую электронную базу. И очень часто подменивают понятия — т.е. «обычный» векторно-матричный процессор называют нейронным (походу маркетинг чистой воды). Таких примеров много.
Я сам когда-то пытался понять всё это, но к сожалению не хватило ни знаний, ни опыта, ни времени.
А касательно времени жизни структуры проекта это уже другой вопрос. Есть люди которые помнят свой код достаточно долго (у меня напарник на работе достал код 3-х годичной давности и смог его поправить, т.к. помнил даже название методов которые делали нужную ему работу). Поэтому это сложный момент, что считать «плохой архитектурой».
Также касательно «сеансов», лучше их избегать вовсе на этапе разработки рабочего кода, в следствии того что разрабатывать будет команда со средним опытом, а не одиночки, как бывает у прототипа. Отсюда следует то что «сеансам» самое место на прототипировании проекта, при проверки смелых идей и новых мыслей.
2) Касательно клонов ядер NT, так это уже боян, причём давнишний. Этим баловались серьёзные Windows программисты 200х, так и частные конторы. На основе одного из таких проектов и зародился нынешний ReactOS.
А совместимость софта она очень зыбкая, т.к. не возможно на те же 80% сделать совместимость с Windows не используя код Windows (если парням из MS такое не удаётся сделать даже внутри ветки NT, между версиями).
Так вот ReactOS это чуточку переросший Wine, имеющий как свои достоинства так и недостатки. Попытка из Wine сделать ОС, это очень смелый шаг, который требует очень много внимания к себе. Это во первых, а во вторых необходима чётка цель проекта, идея которая отличает его от прочего.
В данном случае я пока не вижу особого различия между копипастой алгоритмов из работающей ос (Windows) и ReactOS, и которой в своё время ушёл один из разработчиков как раз по этой причине (да, я как человек в своё время являвшийся ярым сторонником Windows достаточно подробно изучил всё то что составляет ReactOS).
P.S. не надо рассматривать мои комментарии как ненависть к разработчикам — это их свободное время, и им решать что правильней. Однако следует помнить о том что любой аргумент должен иметь под собой базу. А не попытку давить на жалость.
Первое даёт понимание проблемы человеком, последнее кучу убитого времени и негативное отношение как к собственной работе так и к работе других.
Однако вместе с тем существует куча различных вещей которые не надо делать, не потому что они плохие, а потому, что их уже сделали.
Один из первых признаков правильной организации труда — повторное использование уже сделанного. Поэтому и возникают различные трения и реакции других людей.
Нету смысла переоткрывать уже открытые планеты и звёзды, однако можно просто их изучать с целью понимания происходящего.
Холивар это попытка доказать что ботинки твоего размера лучше всего подходят соседу(даже если у вас различия в размере больше чем в 2 раза).
Всё выше перечисленное чисто личное мнение, однако как показывает практика (а у меня её было достаточно), нету таких вещей которые нельзя усовершенствовать и лучше приложить силы именно туда, нежели пытаться навязывать другим свои личные мысли и заблуждения.
Правда вступает в ход одно оправдание — режиссёрское видение.
Хотя по мне лучше так чем придумывать логически не связанные с основным сюжетом концовки.
Да и красивая секира у героини превратилась в лопасть от хвостового пропеллера.