Мне вдится основной проблемой модульных устройств — это размеры и прочность: из-за наличия соединений страдают размеры в сравнении с обычной электроникой, да и корпусу это не добовляет прочности.
Конекретно по этому девайсу: а как будет регулироваться браслет по толщине руки? у людей ведь далеко не идентичные модули вместо рук проинсталированны…
У нас вся конфигурация таким образом получается в одном месте, и для деплоя, и для админов, и для разработчиков. Конфиги puppet храним в репозитории git с посткомитными скриптами проверок + каждый коммит перед мержем с мастером проходит пару проверок людьми (не теми, которые коммитили).
У нас таким образом ни разу не всплывала проблема «почему на том или ином сервере не та версия софта, или не те настройки», более того, наши разработчики используют один унифицированный образ с фиксированными версими всего и всея.
Поэтому мне ваш случай с новыми версиями пакетов и нестыковками не нравится.
Вы можете хранить конфиги и в build тулзах, по сути разницы нет, просто тогда у вас странно процесс разработки, деплоя и тестов построен, если допускается ситуация с конфликтом версий.
Все чистое имхо.
А не пробовали создать свой образ дистрибутива и использовать только его? С отключенным автообновлением и нужными настройками? И обновление оного только после прогона тестов.
Решает кучу проблем, заодно и траффик экономит.
Не вижу проблем использовать puppet как раз-таки для установки и обновления софта.
+ если у вас puppet обновляет все и сразу — есть смысл пересмотреть свои рецепты.
У нас каждый кластер (и каждая виртуалка и тому подобное) имеет свои настройки. И возможно обновлять софт выборочно, штучно.
Простите, а вы накатываете обновления пакетов на сервера без тестов?
У нас подобная проблема решается средствами puppet с подробным описанием зависимостей и специфичными репами врода testing для тех пакетов, которые пересобираются руками у нас.
И цикл deploy`я идет: локальные виртуалки -> тестовый продакшен -> продакшен.
Мне кажется, ваш путь излишен в связи с современными утилитами развертывания…
ps:
Опишу проще, допустим программисты взялись что-то писать. Для них налили виртуалки и они что-то там химичат. Через месяц приходят с каким-то результатом, который нужно протестировать. Соответственно наливаются testing виртуалки а на них все работает по другому и немного криво потому что оказалось что за месяц обновился libxml2, из-за чего по другому стали работать какие-то функции.
Просто подписываюсь под каждым словом статьи!
В конце декабря переводил библиотеку для работы с .kdb на 3 питон, в частности стоит 3.3, на нем и тестировал. Больше всего вызвало проблемы корректно обрабатывать b"" в новом питоне вместо старого доброго str во втором.
Вполне вероятно, что у него есть фатальный недостаток
Или ребята захотели реализовать несколько другую систему, что более вероятно…
The entire project will be open source and built using existing code such as Libtorrent, Webkit, SQLite v3 and node-js. The Pirate Bay team is still looking for coders to assist, mainly on the Windows side, but thus far the development has been going steady.
It may take a few months before the first version is released in public, but it already promises to be a game changer in the ongoing censorship Whack-a-Mole.
Кстати, я бы с удовольствием взглянул на код где-нибудь на гитхабе…
Аналогично — поверх уже установленной ос/ядра, если загрузчик не залочен: ubuntu touch, etc…
Если ставить вместо os со своим родным ядром — при незаблокированном загрузчике — очень большая вероятность получить систему без поддержки хардварного видеоускорения и прочих прелестей.
IMHO, большой разницы в установке на другие китайские планшеты, даже арм, нет.
Хотя люди ставили linux на планшеты на чипе Intel Atom Z2760, отзывы не очень хорошие…
как вариант, но я смотрел с двух позиций:
1) как параноику мне нужен ифрованный раздел, желательно с внешним ключем;
2) записать загрузчик вида «загрузчик iso для загрузочной флэшки» на флэшку проще, чем на раздел efi;
А без этого проще использовать варинат с uefi shell, описанный чуть выше
+ если не хочется углублятся в UEFI shell, может прокатить вариант собрать загрузчик на отдельную флэшку и с нее грузиться — я в свое время рассматривал планшет на этой архитектуре и думал об этом варианте. Остановила как раз-таки графика PowerVR SGX — за 700+ долларов покупать полурабочий вариант желания не было.
Из плюсов флэшки — без нее невозможно будет включить — этакий ключик. И на нее еще можно записать ключ от шифрованного раздела с системой.
Простите, но, к примеру, на лурке статья гораздо подробнее и полезнее.
Если Вы так рады от нового открытого мира, то хоть сделайте полноценный обзор одной из игр…
зы: вот мой
Конекретно по этому девайсу: а как будет регулироваться браслет по толщине руки? у людей ведь далеко не идентичные модули вместо рук проинсталированны…
EVE online — c++ and python
…
Может, не все так плохо с вашей мечтой? ;)
Есть базовый образ, его же можно отдельно обновлять и полностью тестить на совместимость, если все ок — появляется новый унифицированный образ.
У нас таким образом ни разу не всплывала проблема «почему на том или ином сервере не та версия софта, или не те настройки», более того, наши разработчики используют один унифицированный образ с фиксированными версими всего и всея.
Поэтому мне ваш случай с новыми версиями пакетов и нестыковками не нравится.
Вы можете хранить конфиги и в build тулзах, по сути разницы нет, просто тогда у вас странно процесс разработки, деплоя и тестов построен, если допускается ситуация с конфликтом версий.
Все чистое имхо.
Решает кучу проблем, заодно и траффик экономит.
+ если у вас puppet обновляет все и сразу — есть смысл пересмотреть свои рецепты.
У нас каждый кластер (и каждая виртуалка и тому подобное) имеет свои настройки. И возможно обновлять софт выборочно, штучно.
У нас подобная проблема решается средствами puppet с подробным описанием зависимостей и специфичными репами врода testing для тех пакетов, которые пересобираются руками у нас.
И цикл deploy`я идет: локальные виртуалки -> тестовый продакшен -> продакшен.
Мне кажется, ваш путь излишен в связи с современными утилитами развертывания…
ps:
Это вообще недопустимый ад на мой взгляд.
В конце декабря переводил библиотеку для работы с .kdb на 3 питон, в частности стоит 3.3, на нем и тестировал. Больше всего вызвало проблемы корректно обрабатывать b"" в новом питоне вместо старого доброго str во втором.
Или ребята захотели реализовать несколько другую систему, что более вероятно…
Кстати, я бы с удовольствием взглянул на код где-нибудь на гитхабе…
И не ли против портирования его на pyside or pyqt?
Если ставить вместо os со своим родным ядром — при незаблокированном загрузчике — очень большая вероятность получить систему без поддержки хардварного видеоускорения и прочих прелестей.
IMHO, большой разницы в установке на другие китайские планшеты, даже арм, нет.
Хотя люди ставили linux на планшеты на чипе Intel Atom Z2760, отзывы не очень хорошие…
Еще есть варинат с e17 — там неплохой планшетный интерфейс, но тоже очень сырой, и пилят его крайне медленно
1) как параноику мне нужен ифрованный раздел, желательно с внешним ключем;
2) записать загрузчик вида «загрузчик iso для загрузочной флэшки» на флэшку проще, чем на раздел efi;
А без этого проще использовать варинат с uefi shell, описанный чуть выше
Из плюсов флэшки — без нее невозможно будет включить — этакий ключик. И на нее еще можно записать ключ от шифрованного раздела с системой.
Если Вы так рады от нового открытого мира, то хоть сделайте полноценный обзор одной из игр…