Написать движок, сравнимый по размеру, наверно да.
Но что мешает использовать существующий? Ведь лицензия это позволяет, а сама технология не привязана к изолированной экосистеме одного владельца.
На самом деле, тут можно поспорить. То, что Гугл убил огнелиса и другие браузеры, это безусловно. Но сам движок открытый, бери и делай свой бразуер.
В случае же с Microsoft, у них происходит привязка с собственным продуктам, без покупки которых продолжать пользоваться захваченной технологией уже невозможно.
Тут вопрос не в том, сработало или нет. Ей не дали этого сделать, но это не значит, что Microsoft не пыталась. Тоже самое касается и IE, очень сильно хотела, но не смогла.
Что же касается протоколов, то для меня это было новостью, хотя и довольно предсказуемо.
В сентябре 2019 года Microsoft объявила, что прекратила поддержку базового аутентификационного доступа к API Exchange Online для пользователей Office 365[14]. Это фактически привело к тому, что многие пользователи, в основном университеты, прекратили поддержку IMAP и SMTP, ограничив своих пользователей только доступом к электронной почте Microsoft Outlook или через веб[15][16][17][18].
Несовместимость реализаций Java: Предполагалось, что Microsoft могла использовать стратегию «embrace and extend» в конце 1990-х по отношению к платформе Java (изначально разработанной для работы на различных ОС, в том числе Windows, Mac и Linux). Microsoft в собственной реализации отказалась от интерфейса Java Native Interface, заменив его собственным J/Direct, доступным лишь для ОС Windows, но не для Linux и Mac. Согласно внутренним документам, компания пыталась таким образом ограничить портируемость платформы.[5] В январе 2001 года Microsoft выплатила Sun 20 миллионов долларов.[6]
Собственно после этого Microsoft и сосредоточилась на развитии собственного C# вместо Java
Естественно, что неоднократно обжёгшись, другие компании будут крайне осторожно относится к любым «благим намерениям» от Microsoft. Поэтому теперешнее сопротивление таким предложениям вполне обоснованно.
Второе может не получится по причине того, что M$ может запретить использовать какие нибудь запатентованные технологии или спецификации TS. Например, как это пытается не первый год сделать Oracle с Java.
Будь Microsoft белыми и пушистыми, можно было бы включиться в развитии исходного проекта, а не форкать его с привязкой к своим продуктам. А сейчас если M$ получит подавляющее преимущество, то и соблазн повторить работающую тактику будет очень велик.
По данным журналистов и исследователей, швейцарская фирма заработала миллионы долларов, десятилетиями продавая оборудование в более чем 120 стран. Все это время ею тайно владела ЦРУ в рамках секретного партнёрства с западногерманской разведкой БНД
Вы передергиваете мои слова. Я не говорил про «херню на коленке», хотя быстрая поставка MVP фактически поощряет такой подход. Путь это будет на совести Product Owner`ов и владельцев бизнеса.
Я на это смотрю именно как разработчик/архитектор, который понимает движение денежных потоков. Ведь именно мне/моим сотрудникам придется закрывать данные задачи, а бюджет и время, которое отводится на их решение не безгранично.
Это относится совершенно ко всем компаниям. И даже если какая-то компания так не делает, то скорее всего не потому, что не хочет, а из-за того, что возможности нет :-)
При чем тут скрам, этапы развития команды или зрелость компании?
Даже если нет выделенного человека «архитектор», то эту роль будет выполнять разработчик не зависимо от всего выше перечисленного.
Допускаю что наш ракурс, отличается от вашего, но это не значит что он не тот
Согласен.
Просто у меня при упоминании про микроконтроллер, внимание акцентируется на первой части слова. Поэтому считаю важным разрабатывать код под любую элементную базу, а не только для самой производительной серии.
Вы же не будете какой нибудь миниатюрный автономный датчик делать с цветным экраном? Либо вам придется шаманить, как в упомянутой выше статье про efm32_zero.
Мы с вами говорим про разные уровни абстракции. Под словом «разработка» вы понимаете только процесс написание кода (драйвера, бизнес логики и т.д.), а я вам пытаюсь пояснить про финансирование данного процесса, т.е. про расходы на заплату этого самого разработчика.
Это очень хорошо, если ваши устройства разработанные однажды, больше не требует ни обновления прошивок ни наращивания функционала, т.е. платить зарплату программисту. И если дела обстоят именно так, тогда я с вами соглашусь, что лучше один раз потратится на вылизывание кода при разработке, т.к. постоянные затраты на поддержку будут отсутствовать.
К сожалению, у меня за все время работы, таких проектов не было ни разу. Да и сам бизнес стремится к тому, чтобы привязать пользователя и заставить его платить постоянно.
А для этого требуется всегда исправлять баги (случайные и не очень), поддерживать новые технологии или протоколы, расширить функционал по просьбе заказчика или обновлять саму аппаратную платформу. И вот это все и есть поддержка, т.е. постоянные затраты.
Вы рассматриваете разработку для микроконтроллера не с того ракурса. Какие сторонние библиотеки, которых «может быть много», какие процессы Linux, если вы делаете прошивку, например для STM32F1хх? Да там флеша для памяти программ может быть меньше, чем стек на Linux машине.
Цитируйте пожалуйста правильно без передергивания и изменения контекста.
И для этого Embox не нужен.
Под Linux я разрабатывают приложение в виде одного или нескольких классов + тесты и ответные части интерфейсов (если они есть). Если планируется задействовать специфические особенности аппаратуры, тогда под Linux реализуется только интерфейс с заглушкой.
А уже после отладки основной логики на микроконтроллере запускается отлаженный код в потоках FreeRTOS под STM32CubeIDE.
Таким способом получается очень легко разделять бизнес логику и аппаратно-зависимую часть кода и значительно ускорить процесс разработки.
Ведь мы по сути дела, взяли готовый модуль, разработали бизнес логику на Linux используя при этом несколько приложений. И запустили все это на нашей целевой платформе. Тем самым существенно упростив и ускорив саму разработку.
Я тоже сперва разрабатываю под Linux, а потом уже отлаженный код разработанного класса приложения запускаю на целевой платформе под FreeRTOS.
И для этого Embox не нужен.
Но что мешает использовать существующий? Ведь лицензия это позволяет, а сама технология не привязана к изолированной экосистеме одного владельца.
В случае же с Microsoft, у них происходит привязка с собственным продуктам, без покупки которых продолжать пользоваться захваченной технологией уже невозможно.
Что же касается протоколов, то для меня это было новостью, хотя и довольно предсказуемо.
Собственно после этого Microsoft и сосредоточилась на развитии собственного C# вместо Java
Будь Microsoft белыми и пушистыми, можно было бы включиться в развитии исходного проекта, а не форкать его с привязкой к своим продуктам. А сейчас если M$ получит подавляющее преимущество, то и соблазн повторить работающую тактику будет очень велик.
Швейцарская разведка с 1993 года знала о контроле над шифрованием в стране со стороны ЦРУ
Я на это смотрю именно как разработчик/архитектор, который понимает движение денежных потоков. Ведь именно мне/моим сотрудникам придется закрывать данные задачи, а бюджет и время, которое отводится на их решение не безгранично.
Даже если нет выделенного человека «архитектор», то эту роль будет выполнять разработчик не зависимо от всего выше перечисленного.
Просто у меня при упоминании про микроконтроллер, внимание акцентируется на первой части слова. Поэтому считаю важным разрабатывать код под любую элементную базу, а не только для самой производительной серии.
Вы же не будете какой нибудь миниатюрный автономный датчик делать с цветным экраном? Либо вам придется шаманить, как в упомянутой выше статье про efm32_zero.
Это очень хорошо, если ваши устройства разработанные однажды, больше не требует ни обновления прошивок ни наращивания функционала, т.е. платить зарплату программисту. И если дела обстоят именно так, тогда я с вами соглашусь, что лучше один раз потратится на вылизывание кода при разработке, т.к. постоянные затраты на поддержку будут отсутствовать.
К сожалению, у меня за все время работы, таких проектов не было ни разу. Да и сам бизнес стремится к тому, чтобы привязать пользователя и заставить его платить постоянно.
А для этого требуется всегда исправлять баги (случайные и не очень), поддерживать новые технологии или протоколы, расширить функционал по просьбе заказчика или обновлять саму аппаратную платформу. И вот это все и есть поддержка, т.е. постоянные затраты.
А уже после отладки основной логики на микроконтроллере запускается отлаженный код в потоках FreeRTOS под STM32CubeIDE.
Таким способом получается очень легко разделять бизнес логику и аппаратно-зависимую часть кода и значительно ускорить процесс разработки.
И для этого Embox не нужен.