Выглядит так, что Вы пытаетесь в действиях компании google найти какую-то осознанность. При этом, так безапелляционно отвечаете мне, как будто точно знаете что ей важно. Откуда и Вам, и мне знать что там для неё важно. Я вижу в происходящем только броуновское хаотичное движение, характерное для ведения разработки в больших корпорациях. Менеджеры приходят, решают сиюминутные задачи, уходят. Разработчики пилят так, как им удобнее. Сегодня их кидают на одну задачу, завтра на другую. Единой архитектуры и тех стратегии нет, есть правила оформления кода и беклог из актуальных фич. Причем сейчас актуально одно, завтра - уже другое. Как и везде.
Вы кстати пробовали собрать clang и другие зависимости проекта chromium на старом дистрибутиве? Я пробовал и в своем комментарии делюсь опытом. В принципе, по объему работ можно говорить о полноценной сборке новой версии ОС. И это не вопрос пары вечеров. Продолжая Вашу логику - можно и свою ОС написать, если windows не устраивает. Но что-то никто не пишет.
Автор поста написал про windows, но то, о чем он пишет еще более актуально для мира linux.
Такой подход разработчиков chromium устраивает постоянную гонку. Релизить ОС как можно чаще, пихать туда самые последние версии библиотек и компиляторов, постоянно что-то менять, ломать то, что до этого хорошо работало. Очень мало линуксов выдерживают такую гонку и успевают каждый месяц клепать качественные дистрибутивы. А не успел обновить релиз своей ОС и всё, на твоей ОС вдруг перестал работать браузер. Очень мило.
Дальше, после таких доводов обычно следует предложение использовать везде какой-нибудь популярный ubuntu, который постоянно обновляется и не париться с экзотическими сборками. Сразу отвечу: линуксы крутят не только на PC, есть embedded решения, решения под специальные экзотические архитектуры. Там авторы потратили кучу времени например на адаптацию под особенности железа, но у них нет сил и времени выдерживать гонку, о которой вы написали, и постоянно держать в актуальном состоянии релиз своей ОС.
Есть еще чисто российская история: сертифицированные версии linux, которые на долгое время (на годы!) замирают в том состоянии, в котором их сертифицировали. Есть китайские версии embedded linux в каком-нибудь оборудовании, обновить которые тоже нет никакой возможности.
Я постоянно сталкиваюсь в своей работе вот с такими приколами. Разработчик почитал последний стандарт C++ и непременно захотел использовать это при решении своей очередной небольшой задачи. Он собрал всё на своей домашней ubuntu и у него все работает. Потом начинает жаловаться: у меня всё работает, всё по последнему стандарту, а у вас на целевой системе всё устарело, как можно запускаться на таком старье, надо срочно чтобы всё было последних версий. А на целевой системе у нас экзотическое железо и полное отсутствие обновлений, или корпоративный стандарт с прибитой гвоздями версией ОС, или просто сложная работающая система, где никто не будет ничего обновлять и потом месяцы заново тестировать из-за одного небольшого сервиса.
Всё должно использоваться с умом. Можно ядро писать в более консервативном стиле, дополнения, которые можно отключить на этапе компиляции - в более современном стиле. К выбору версии языка C++, компилятора и зависимостей для того или иного решения надо подходить также осознанно, как и ко всему остальному.
Спасибо за статью. Читать тяжеловато, но если в теме, то интересно. Хочу поделиться воспоминаниями и размышлениями на эту тему:
Я сам разбирал проект Chromium несколько лет назад. Задача была: скомпилировать старую версию из исходников под старую версию linux с другими флагами компиляции. Оказалось, что это в принципе невозможно, потому что у проекта миллион внешних зависимостей и стабильно несколько зависимостей ведут на коммиты проектов, которые на момент моих попыток собрать проект уже были удалены из своих репозиториев.
Я до сих пор под впечатлением:
Оказывается никакие системы хранения версий не являются панацеей и даже ранее написанный исходный код популярных опенсорсных проектов может быть утрачен навсегда.
Есть собранные старые версии Chromium и вы можете их скачать, но вы НЕ можете их пересобрать из исходников. Никак. Это невозможно.
Дальше я пытался решить свою задачу в лоб, вычищая из последней на тот момент версии исходников весь код, который отказывался компилироваться на нужной мне версии Linux. В какой-то момент я гонялся по исходному коду проекта за каким-то автором, который очень грязно по всему проекту вставлял изменения добавляя какую-то, видимо, очень важную фишку для popup уведомлений и везде использовал последние на тот момент времени нововведения языка С++, которые компилятор на моей старой версии linux не понимал. Я бегал за ним по коду и думал три вещи:
Ну зачем он это делает? Ну пиши ты свой новый код в том же стиле, как вокруг всё написано, зачем лезешь с этими хипстерскими новомодными оборотами в готовый проект?
Почему в таком вроде важном, мегапопулярном и очень серьезном проекте такой бардак? Почему его коммиты пропустили в мастер? Там есть какие-то правила вообще на этот счет? Зачем на ровном месте, ради какой-то непонятной маленькой фишки добавлять несовместимость со старыми компиляторами для проекта, который, по идее, как раз по максимуму должен быть совместим со множеством разных платформ и компиляторов?
Как они вообще тестируют такой разношерстный объем кода и следят за его целостностью и безопасностью? Там вообще есть кто-нибудь у руля?
В итоге, с решением в лоб у меня тоже ничего не получилось, потому что я не супер мозг, таких авторов там было много и столько исправлений я не смог осилить. Но после тех мытарств и исследований проекта Chromium мне теперь очень страшно ставить этого монстра на свой компьютер (хотя я, конечно, все равно ставлю, потому что удобно). До сих пор ощущение, что там внутри на уровне кода полная анархия и бардак. Как говорится: меньше знаешь, крепче спишь)
С документацией по zigbee чипам ситуация неоднозначная - она есть, она довольно подробная, многие нюансы хорошо описаны, из нее совершенно не понятно как все работает и что с этим делать.
Абсолютно согласен! По началу совершенно непонятна логика инициализации и переинициализации устройств. Какая-то память, куда надо что-то записывать, потом перезапускать, потом при отключении питания из неё все равно всё теряется. Горячая и холодная инициализации для устройства, сконфигурированного как end_device. Ключи шифрования, мощность передатчика, установка каналов, на которых будет происходить поиск. Какие-то endpoints, applications, clusters.
Дальше, есть три версии Z-Stack, у них есть последние актуальные версии (1.2.2, 2.5.1, 3.0.1), соответственно три набора документации, в одном наборе не хватает чего-то одного, в другом другого. На форуме TI отвечают односложными фразами и отправляют просителей в документацию или в соседние треды, где также ничерта нет и сразу закрывают дискуссию.
Попробуй сходу найти ответ, как отключать при старте ожидание от бутлоадера или как скомпилировать Z-Stack c включением CTS/RTS для UART? Какое значение у ключа шифрования по умолчанию? Как управлять мощностью передатчика? Как зарегистрировать свой endpoint через ZNP команды? Как отправлять и принимать через него сообщения? Каким софтом сниферить сеть и какие прошивки использовать для устройства, которое используется в качестве снифера?
Вообще для себя понял, что единственный способ однозначно разобраться как работать с Z-Stack - это скачать все три версии исходников и докуметации Z-Stack, а затем открывать по три версии соответсвующих документов и лезть разбирать соответствующий исходный код. При этом, в документации, помимо отсутствия описания логики инициализации иногда отсутствуют например целые команды ZNP и/или описания кодов, которые они возвращают (например команды Simple API через ZNP).
Вообще обидно, что так все запущено с документацией для Zigbee. Из-за этого появились и развиваются такие монстры, как zigbee2mqtt (монстр, потому что решает примитивную задачу, но написан на typescript и тянет за собой целый node.js и движок v8). И всё из-за того, что новичкам трудно разобраться как сделать то, что им нужно без подобного софта-посредника. Когда разберешься (потратив кучу времени на реверс инжиниринг исходников и проверку гипотез и догадок, ага), zigbee протокол становится очень простым и понятным =)
Нет, полностью сносить Hyper-V не надо. Для того, чтобы переключаться с виртуалок Hyper-V к виртуалкам VMWare и обратно:
1. Новая фишка Windows — DeviceGuard (виртуализация ядра самой windows через гипервизор hyper-V) должна была отключена — тут понятно, иначе мы не сможем отключать сам гипервизор hyper-V (включение/отключение этого DeviceGuard не влияет на работоспособность виртуалок Hyper-V и поэтому можно держать его всегда выключенным).
2. Далее, можно выключить на время гипервизор hyper-V командой:
bcdedit /set hypervisorlaunchtype off
перезагрузиться.
3. Теперь можно запустить виртуальную машину vmware, поработать с ней.
4. Теперь можно включить гипервизор hyper-V обратно командой:
bcdedit /set hypervisorlaunchtype auto
перезагрузиться.
5. Теперь можно запустить виртуалку Hyper-V и поработать с ней.
В общем, удобно)
Чтобы два раза не вставать, подскажите пожалуйста если кто знает: какими инструментами можно удобно перегонять образы из vmdk в vhd и обратно?
Получается, современные используемые методы обработки изображений всё больше становятся похожи на то, что происходит в человеческом мозгу во время анализа зрительной информации.
Особенно запомнилось, что для повышения разрешения, а также для построения карты глубин используются непроизвольные микродвижения рук держащего смартфон перед тем, как он нажмет на кнопку «Сфотографировать». Всё прям как в жизни)
Работал с данной операционной системой, а также со всякими Астра, Заря, Роса и прочими. Очень специфические проблемы возникали у меня, как у разработчика с этими ОС. Если в двух словах, все эти специализированные ОС делаются примерно следующим образом:
— выбирается некоторая версия некоторого свободного linux дистрибутива.
— репозиторий копируется, некоторые пакеты выкидываются, некоторые добавляются, какие-то немного допиливаются.
— после чего всё это проходит сертификацию: репозитории сохраняются на CD диски, считаются контрольные суммы — таким образом сама ОС и все версии пакетов в её репозиториях фиксируются для какого-то определенного момента времени. Я сейчас не могу вспомнить точно версию МСВС, с которой нам нужно было работать, но её репозитории были зафиксированы 2006 годом.
Теперь представьте себя на месте разработчика, который должен что-то разрабатывать под такую ОС. Для того, чтобы разработка прошла сертификацию, она не должна содержать бинарников, всё должно собираться из исходных кодов сертифицированными для данной версии ОС инструментами. То есть, для примера выше, с 2006 года поменялось буквально всё: вышли новые версии компиляторов, систем сборки, стандартных библиотек, IDE, утилит и всего прочего. И ничем из этого такой разработчик не может пользоваться, он должен намеренно оставаться в 2006 году) И если столкнешься с ошибками работы системных утилит или библиотек, нужно гуглить сообщения на формуах для 2006 года и ранее, потому что сейчас все эти ошибки давно уже устранены и не все уже помнят как их когда-то нужно было решать или обходить.
И дополнительно я сделал для себя интересное открытие: оказывается современные сложные проекты, такие как chromium невозможно откатить назад на несколько лет и просто собрать из исходного кода для устаревшего linux дистрибутива. Да, там будут стоять теги, по ним можно вычислить версии стандартной библиотеки и компилятора, совпадающие с твоей устаревшей операционной системой, но собрать по тегу старую версию оказывается невозможно. Причина в том, что такие большие проекты как chromium несут в себе множество ссылок на коммиты других проектов и из десятков зависимостей обязательно будет несколько, которые будут вести на уже удаленные/более не существующие коммиты в репозиториях других проектов.
То есть собрать под такую специализированную ОС тот же chromium из исходников, практически невозможно)
Спасибо за ответ. В DeployR Open меня подкупало количество документации и примеров для работы через REST API. Не могу сказать того же о Shiny — не могу сходу найти информацию как организовать работу с Shiny server как с сервисом для запуска R скриптов через REST API. Вы уже использовали его в таком качестве? Подскажете куда копать?
Да, в статью стоит внести комментарий относительно DeployR — версии DeployR Open больше нет, версии DeployR Enterprise больше нет как самостоятельного продукта, она вошла в состав Microsoft R Server, который затем был переименован в Microsoft Machine Learning Server.
Я пытался сейчас найти где скачать DeployR Open и не смог. На github такого проекта больше нет. Ссылки с сайта revolutionanalytics.com ведут на страницу Microsoft, где написано:
«Looking for a DeployR Open download? Attention: Microsoft has suspended distribution of DeployR Open releases».
Я правильно понимаю, что Microsoft выпилила отовсюду исходники и бинарники DeployR Open и больше на него можно не рассчитывать?
Кстати насчёт взять у кого-нибудь аккумулятор — есть такие люди во множестве.
Осень же на дворе, сейчас мотоциклисты массово паркуют коней, снимают с них аккумуляторы на зиму и тащят по домам, в тепло. Ну по крайней мере опытные, те, кто уже пару раз покупал весной новый аккум, так как не снял с мотика осенью старый)
Они вам не только отдадут аккумулятор попользоваться, но даже спасибо ещё скажут за то, что вы им будете пользоваться и будете держать его в рабочем состоянии до весны)
Хорошо читается. На одном дыхании, спасибо.
Еще не покидала мысль при чтении: как бы выглядела эта история, если бы это происходило в то же время, с таким же умным парнем, но в советском союзе)
Все верно, в nw.js при сборке и chromium, и node.js используют одну и ту же версию v8.
Версия v8 у них обновляется вместе со всеми изменениями проекта chromuim, который они регулярно мержат со своим проектом nw.js.
Интересно кстати тестируют ли разработчики проекта nw.js работу node.js + последняя версия v8, если разработчики node.js сами ещё не включили эту версию в свой релиз?
Недавно решал задачу по сборке NW.js из исходников в 32 битном линуксе с GLIBC 2.14 и 32 битным gcc 4.9.2. Сертификация, российские реалии, все такое. Долго и много разбирался с исходным кодом NW.js. В результате пришел к выводу, что это сделать невозможно. nw.js собирается только в debian wheezy x64 и только в static mode. Хочу поделиться здесь своими впечатлениями.
В начале про оригинальный chromium:
— Оригинальный chromium можно собрать на 32 битной системе и можно собрать в dynamic mode (с использованием shared библиотек).
— Разработчики chromium нашли фатальные недостатки в существующих системах сборки и написали для сборки свои инструменты: gyp (аналог cmake) — для верхнего уровня и ninja (аналог make) — для нижнего. Кроме того, они используют свой инструмент-обертку над системами контроля версий: depot_tools.
— Проекты, которые зависят от webkit, v8 и chromium также стараются использовать эти инструменты для сборки и контроля версий.
— Так как эти инструменты больше почти нигде не используются, документация и примеры по ним довольно скудные.
Теперь про nw.js, как я для себя понял структуру его исходного кода:
— Разработчики проекта nw.js клонировали исходный код проекта chromium в свой репозитрий. Вместе с wibkit, v8 и еще кучей всего, что входит в оригинальные проект.
— Клонировали туда исходный код проекта node.js.
— Добавили туда код, который дает возможность получать доступ из node,js к компонентам chromium и наоборот. Частично он внедрен в оригинальные файлы chromium и node.js.
— Добавили много хаотично расположенного кода, в том числе изменяя оригинальные файлы проектов chromium и node.js, который там и тут костылями устраняет появившиеся проблемы с безопасностью.
— Для сборки всего этого использовали инструменты и файлы конфигурации оригинального chromium, на живую и очень грубо внедряя свои модули в процесс компиляции, описанный в gyp файлах конфигурации.
Что получилось в итоге:
— Самое важное для меня: сломались все типы сборок под линукс, доступных в оригинальном chromium, кроме одной. Собрать nw.js можно только под debian wheezy x64, 64 битным gcc и только в static mode.
— Код, который отвечает за связывание node.js и chromium выглядит очень не аккуратно. Так выглядит код человека,
которому нужно, чтобы к утру заработало, а остальное можно будет поправить позже, когда спешка закончится. Например после добавления костылей в оригинальный код chromium появились кольцевые зависимости когда один модуль ссылается на другой и наоборот (из-за этого он и не собирается в shared mode).
— Не завидую разработчикам nw.js: у них теперь огромная проблема с обновлением оригинальных проектов, которые они использовали. Раз они залезли прямо в исходный код этих проектов со своими костылями, значит теперь после каждого обновления например chromium им придется все мержить со своими изменениями, тестировать что ничего не отвалилось и только после этого добавлять в свой репозиторий.
— Нормальной документации по сборке (да и по самому проекту) нет. То, что есть по сборке — это просто документация, которая кусками скопирована (причем в разное время) с документации оригинального проекта chromium.
Мое мнение такое:
— этот проект не является дальнейшим развитием проекта node.js. Это отдельный проект, который взял проекты chromium и node.js и на их основе сделал свой продукт.
— этот проект должен был называться не «nw.js» и не «webkit + node.js», а «chromium + node.js + костыли». В таком случае было бы сразу понятно, с чем придется иметь дело.
— проект делается в спешке и очень небольшим количеством разработчиков.
— деньги, которые были выделены на развитие проекта, в основном, видимо, ушли на рекламу, раскрутку и супер красивый сайт.
Я считаю, что именно поэтому о nw.js сейчас столько говорят, но никто пока не торопится его использовать. Деньги, потраченные на рекламу, дали свой результат, но сам проект из-за выбранного разработчиками способа реализации содержит несколько трудно разрешаемых системных проблем и поэтому до сих пор находится в достаточно сыром состоянии.
Выглядит так, что Вы пытаетесь в действиях компании google найти какую-то осознанность. При этом, так безапелляционно отвечаете мне, как будто точно знаете что ей важно. Откуда и Вам, и мне знать что там для неё важно. Я вижу в происходящем только броуновское хаотичное движение, характерное для ведения разработки в больших корпорациях. Менеджеры приходят, решают сиюминутные задачи, уходят. Разработчики пилят так, как им удобнее. Сегодня их кидают на одну задачу, завтра на другую. Единой архитектуры и тех стратегии нет, есть правила оформления кода и беклог из актуальных фич. Причем сейчас актуально одно, завтра - уже другое. Как и везде.
Вы кстати пробовали собрать clang и другие зависимости проекта chromium на старом дистрибутиве? Я пробовал и в своем комментарии делюсь опытом. В принципе, по объему работ можно говорить о полноценной сборке новой версии ОС. И это не вопрос пары вечеров. Продолжая Вашу логику - можно и свою ОС написать, если windows не устраивает. Но что-то никто не пишет.
новые != безопасные
Автор поста написал про windows, но то, о чем он пишет еще более актуально для мира linux.
Такой подход разработчиков chromium устраивает постоянную гонку. Релизить ОС как можно чаще, пихать туда самые последние версии библиотек и компиляторов, постоянно что-то менять, ломать то, что до этого хорошо работало. Очень мало линуксов выдерживают такую гонку и успевают каждый месяц клепать качественные дистрибутивы. А не успел обновить релиз своей ОС и всё, на твоей ОС вдруг перестал работать браузер. Очень мило.
Дальше, после таких доводов обычно следует предложение использовать везде какой-нибудь популярный ubuntu, который постоянно обновляется и не париться с экзотическими сборками. Сразу отвечу: линуксы крутят не только на PC, есть embedded решения, решения под специальные экзотические архитектуры. Там авторы потратили кучу времени например на адаптацию под особенности железа, но у них нет сил и времени выдерживать гонку, о которой вы написали, и постоянно держать в актуальном состоянии релиз своей ОС.
Есть еще чисто российская история: сертифицированные версии linux, которые на долгое время (на годы!) замирают в том состоянии, в котором их сертифицировали. Есть китайские версии embedded linux в каком-нибудь оборудовании, обновить которые тоже нет никакой возможности.
Я постоянно сталкиваюсь в своей работе вот с такими приколами. Разработчик почитал последний стандарт C++ и непременно захотел использовать это при решении своей очередной небольшой задачи. Он собрал всё на своей домашней ubuntu и у него все работает. Потом начинает жаловаться: у меня всё работает, всё по последнему стандарту, а у вас на целевой системе всё устарело, как можно запускаться на таком старье, надо срочно чтобы всё было последних версий. А на целевой системе у нас экзотическое железо и полное отсутствие обновлений, или корпоративный стандарт с прибитой гвоздями версией ОС, или просто сложная работающая система, где никто не будет ничего обновлять и потом месяцы заново тестировать из-за одного небольшого сервиса.
Всё должно использоваться с умом. Можно ядро писать в более консервативном стиле, дополнения, которые можно отключить на этапе компиляции - в более современном стиле. К выбору версии языка C++, компилятора и зависимостей для того или иного решения надо подходить также осознанно, как и ко всему остальному.
Спасибо за статью. Читать тяжеловато, но если в теме, то интересно. Хочу поделиться воспоминаниями и размышлениями на эту тему:
Я сам разбирал проект Chromium несколько лет назад. Задача была: скомпилировать старую версию из исходников под старую версию linux с другими флагами компиляции. Оказалось, что это в принципе невозможно, потому что у проекта миллион внешних зависимостей и стабильно несколько зависимостей ведут на коммиты проектов, которые на момент моих попыток собрать проект уже были удалены из своих репозиториев.
Я до сих пор под впечатлением:
Оказывается никакие системы хранения версий не являются панацеей и даже ранее написанный исходный код популярных опенсорсных проектов может быть утрачен навсегда.
Есть собранные старые версии Chromium и вы можете их скачать, но вы НЕ можете их пересобрать из исходников. Никак. Это невозможно.
Дальше я пытался решить свою задачу в лоб, вычищая из последней на тот момент версии исходников весь код, который отказывался компилироваться на нужной мне версии Linux. В какой-то момент я гонялся по исходному коду проекта за каким-то автором, который очень грязно по всему проекту вставлял изменения добавляя какую-то, видимо, очень важную фишку для popup уведомлений и везде использовал последние на тот момент времени нововведения языка С++, которые компилятор на моей старой версии linux не понимал. Я бегал за ним по коду и думал три вещи:
Ну зачем он это делает? Ну пиши ты свой новый код в том же стиле, как вокруг всё написано, зачем лезешь с этими хипстерскими новомодными оборотами в готовый проект?
Почему в таком вроде важном, мегапопулярном и очень серьезном проекте такой бардак? Почему его коммиты пропустили в мастер? Там есть какие-то правила вообще на этот счет? Зачем на ровном месте, ради какой-то непонятной маленькой фишки добавлять несовместимость со старыми компиляторами для проекта, который, по идее, как раз по максимуму должен быть совместим со множеством разных платформ и компиляторов?
Как они вообще тестируют такой разношерстный объем кода и следят за его целостностью и безопасностью? Там вообще есть кто-нибудь у руля?
В итоге, с решением в лоб у меня тоже ничего не получилось, потому что я не супер мозг, таких авторов там было много и столько исправлений я не смог осилить. Но после тех мытарств и исследований проекта Chromium мне теперь очень страшно ставить этого монстра на свой компьютер (хотя я, конечно, все равно ставлю, потому что удобно). До сих пор ощущение, что там внутри на уровне кода полная анархия и бардак. Как говорится: меньше знаешь, крепче спишь)
Абсолютно согласен! По началу совершенно непонятна логика инициализации и переинициализации устройств. Какая-то память, куда надо что-то записывать, потом перезапускать, потом при отключении питания из неё все равно всё теряется. Горячая и холодная инициализации для устройства, сконфигурированного как end_device. Ключи шифрования, мощность передатчика, установка каналов, на которых будет происходить поиск. Какие-то endpoints, applications, clusters.
Дальше, есть три версии Z-Stack, у них есть последние актуальные версии (1.2.2, 2.5.1, 3.0.1), соответственно три набора документации, в одном наборе не хватает чего-то одного, в другом другого. На форуме TI отвечают односложными фразами и отправляют просителей в документацию или в соседние треды, где также ничерта нет и сразу закрывают дискуссию.
Попробуй сходу найти ответ, как отключать при старте ожидание от бутлоадера или как скомпилировать Z-Stack c включением CTS/RTS для UART? Какое значение у ключа шифрования по умолчанию? Как управлять мощностью передатчика? Как зарегистрировать свой endpoint через ZNP команды? Как отправлять и принимать через него сообщения? Каким софтом сниферить сеть и какие прошивки использовать для устройства, которое используется в качестве снифера?
Вообще для себя понял, что единственный способ однозначно разобраться как работать с Z-Stack - это скачать все три версии исходников и докуметации Z-Stack, а затем открывать по три версии соответсвующих документов и лезть разбирать соответствующий исходный код. При этом, в документации, помимо отсутствия описания логики инициализации иногда отсутствуют например целые команды ZNP и/или описания кодов, которые они возвращают (например команды Simple API через ZNP).
Вообще обидно, что так все запущено с документацией для Zigbee. Из-за этого появились и развиваются такие монстры, как zigbee2mqtt (монстр, потому что решает примитивную задачу, но написан на typescript и тянет за собой целый node.js и движок v8). И всё из-за того, что новичкам трудно разобраться как сделать то, что им нужно без подобного софта-посредника. Когда разберешься (потратив кучу времени на реверс инжиниринг исходников и проверку гипотез и догадок, ага), zigbee протокол становится очень простым и понятным =)
1. Новая фишка Windows — DeviceGuard (виртуализация ядра самой windows через гипервизор hyper-V) должна была отключена — тут понятно, иначе мы не сможем отключать сам гипервизор hyper-V (включение/отключение этого DeviceGuard не влияет на работоспособность виртуалок Hyper-V и поэтому можно держать его всегда выключенным).
2. Далее, можно выключить на время гипервизор hyper-V командой:
bcdedit /set hypervisorlaunchtype off
перезагрузиться.
3. Теперь можно запустить виртуальную машину vmware, поработать с ней.
4. Теперь можно включить гипервизор hyper-V обратно командой:
bcdedit /set hypervisorlaunchtype auto
перезагрузиться.
5. Теперь можно запустить виртуалку Hyper-V и поработать с ней.
В общем, удобно)
Чтобы два раза не вставать, подскажите пожалуйста если кто знает: какими инструментами можно удобно перегонять образы из vmdk в vhd и обратно?
Получается, современные используемые методы обработки изображений всё больше становятся похожи на то, что происходит в человеческом мозгу во время анализа зрительной информации.
Особенно запомнилось, что для повышения разрешения, а также для построения карты глубин используются непроизвольные микродвижения рук держащего смартфон перед тем, как он нажмет на кнопку «Сфотографировать». Всё прям как в жизни)
— выбирается некоторая версия некоторого свободного linux дистрибутива.
— репозиторий копируется, некоторые пакеты выкидываются, некоторые добавляются, какие-то немного допиливаются.
— после чего всё это проходит сертификацию: репозитории сохраняются на CD диски, считаются контрольные суммы — таким образом сама ОС и все версии пакетов в её репозиториях фиксируются для какого-то определенного момента времени. Я сейчас не могу вспомнить точно версию МСВС, с которой нам нужно было работать, но её репозитории были зафиксированы 2006 годом.
Теперь представьте себя на месте разработчика, который должен что-то разрабатывать под такую ОС. Для того, чтобы разработка прошла сертификацию, она не должна содержать бинарников, всё должно собираться из исходных кодов сертифицированными для данной версии ОС инструментами. То есть, для примера выше, с 2006 года поменялось буквально всё: вышли новые версии компиляторов, систем сборки, стандартных библиотек, IDE, утилит и всего прочего. И ничем из этого такой разработчик не может пользоваться, он должен намеренно оставаться в 2006 году) И если столкнешься с ошибками работы системных утилит или библиотек, нужно гуглить сообщения на формуах для 2006 года и ранее, потому что сейчас все эти ошибки давно уже устранены и не все уже помнят как их когда-то нужно было решать или обходить.
И дополнительно я сделал для себя интересное открытие: оказывается современные сложные проекты, такие как chromium невозможно откатить назад на несколько лет и просто собрать из исходного кода для устаревшего linux дистрибутива. Да, там будут стоять теги, по ним можно вычислить версии стандартной библиотеки и компилятора, совпадающие с твоей устаревшей операционной системой, но собрать по тегу старую версию оказывается невозможно. Причина в том, что такие большие проекты как chromium несут в себе множество ссылок на коммиты других проектов и из десятков зависимостей обязательно будет несколько, которые будут вести на уже удаленные/более не существующие коммиты в репозиториях других проектов.
То есть собрать под такую специализированную ОС тот же chromium из исходников, практически невозможно)
Да, в статью стоит внести комментарий относительно DeployR — версии DeployR Open больше нет, версии DeployR Enterprise больше нет как самостоятельного продукта, она вошла в состав Microsoft R Server, который затем был переименован в Microsoft Machine Learning Server.
«Looking for a DeployR Open download? Attention: Microsoft has suspended distribution of DeployR Open releases».
Я правильно понимаю, что Microsoft выпилила отовсюду исходники и бинарники DeployR Open и больше на него можно не рассчитывать?
Осень же на дворе, сейчас мотоциклисты массово паркуют коней, снимают с них аккумуляторы на зиму и тащят по домам, в тепло. Ну по крайней мере опытные, те, кто уже пару раз покупал весной новый аккум, так как не снял с мотика осенью старый)
Они вам не только отдадут аккумулятор попользоваться, но даже спасибо ещё скажут за то, что вы им будете пользоваться и будете держать его в рабочем состоянии до весны)
Еще не покидала мысль при чтении: как бы выглядела эта история, если бы это происходило в то же время, с таким же умным парнем, но в советском союзе)
Версия v8 у них обновляется вместе со всеми изменениями проекта chromuim, который они регулярно мержат со своим проектом nw.js.
Интересно кстати тестируют ли разработчики проекта nw.js работу node.js + последняя версия v8, если разработчики node.js сами ещё не включили эту версию в свой релиз?
Недавно решал задачу по сборке NW.js из исходников в 32 битном линуксе с GLIBC 2.14 и 32 битным gcc 4.9.2. Сертификация, российские реалии, все такое. Долго и много разбирался с исходным кодом NW.js. В результате пришел к выводу, что это сделать невозможно. nw.js собирается только в debian wheezy x64 и только в static mode. Хочу поделиться здесь своими впечатлениями.
В начале про оригинальный chromium:
— Оригинальный chromium можно собрать на 32 битной системе и можно собрать в dynamic mode (с использованием shared библиотек).
— Разработчики chromium нашли фатальные недостатки в существующих системах сборки и написали для сборки свои инструменты: gyp (аналог cmake) — для верхнего уровня и ninja (аналог make) — для нижнего. Кроме того, они используют свой инструмент-обертку над системами контроля версий: depot_tools.
— Проекты, которые зависят от webkit, v8 и chromium также стараются использовать эти инструменты для сборки и контроля версий.
— Так как эти инструменты больше почти нигде не используются, документация и примеры по ним довольно скудные.
Теперь про nw.js, как я для себя понял структуру его исходного кода:
— Разработчики проекта nw.js клонировали исходный код проекта chromium в свой репозитрий. Вместе с wibkit, v8 и еще кучей всего, что входит в оригинальные проект.
— Клонировали туда исходный код проекта node.js.
— Добавили туда код, который дает возможность получать доступ из node,js к компонентам chromium и наоборот. Частично он внедрен в оригинальные файлы chromium и node.js.
— Добавили много хаотично расположенного кода, в том числе изменяя оригинальные файлы проектов chromium и node.js, который там и тут костылями устраняет появившиеся проблемы с безопасностью.
— Для сборки всего этого использовали инструменты и файлы конфигурации оригинального chromium, на живую и очень грубо внедряя свои модули в процесс компиляции, описанный в gyp файлах конфигурации.
Что получилось в итоге:
— Самое важное для меня: сломались все типы сборок под линукс, доступных в оригинальном chromium, кроме одной. Собрать nw.js можно только под debian wheezy x64, 64 битным gcc и только в static mode.
— Код, который отвечает за связывание node.js и chromium выглядит очень не аккуратно. Так выглядит код человека,
которому нужно, чтобы к утру заработало, а остальное можно будет поправить позже, когда спешка закончится. Например после добавления костылей в оригинальный код chromium появились кольцевые зависимости когда один модуль ссылается на другой и наоборот (из-за этого он и не собирается в shared mode).
— Не завидую разработчикам nw.js: у них теперь огромная проблема с обновлением оригинальных проектов, которые они использовали. Раз они залезли прямо в исходный код этих проектов со своими костылями, значит теперь после каждого обновления например chromium им придется все мержить со своими изменениями, тестировать что ничего не отвалилось и только после этого добавлять в свой репозиторий.
— Нормальной документации по сборке (да и по самому проекту) нет. То, что есть по сборке — это просто документация, которая кусками скопирована (причем в разное время) с документации оригинального проекта chromium.
Мое мнение такое:
— этот проект не является дальнейшим развитием проекта node.js. Это отдельный проект, который взял проекты chromium и node.js и на их основе сделал свой продукт.
— этот проект должен был называться не «nw.js» и не «webkit + node.js», а «chromium + node.js + костыли». В таком случае было бы сразу понятно, с чем придется иметь дело.
— проект делается в спешке и очень небольшим количеством разработчиков.
— деньги, которые были выделены на развитие проекта, в основном, видимо, ушли на рекламу, раскрутку и супер красивый сайт.
Я считаю, что именно поэтому о nw.js сейчас столько говорят, но никто пока не торопится его использовать. Деньги, потраченные на рекламу, дали свой результат, но сам проект из-за выбранного разработчиками способа реализации содержит несколько трудно разрешаемых системных проблем и поэтому до сих пор находится в достаточно сыром состоянии.