Здравствуйте, sergey2b, Вы писали:
S>я плохо выразился должно быть MBASIC компилятор и GW BASIC для CPM S>+ они выпускали 30+% плат CPM для Apple II https://en.wikipedia.org/wiki/Z-80_SoftCard
+100500
Классное фото!!! Там Z80
Вспомнил молодость!
Огромное Спасибо, Сергей!
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ilya81, Вы писали:
I>>>>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. S>>>Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц. I>>И не случалось при этом такого, что при перемещении на другой hosting приходилось что-то вручную доисправлять? S>Тут как минимум два варианта: S>1. Заказчик сам деплоит. ХЗ, может и допиливает. S>2. Деплою я. У меня значит есть все входные данные и хотелки заказчика. Деплой изначально подравнивается под него.
S>Но ты увёл разговор немного в сторону. Речь щла о деплое под разные дисрибутивы а не про переезд с одного хостера в лругой. Тут непонятно что такое hosting. Если это виртуалки — то какая разница. С точки зрения деплоя это просто сервера. Если это некие сервисы (типа амазоновских) то непонятно почему вообще возникает вопрос такой "не допиливается ли?...". Ясен хрен не просто допиливается а хорошо допиливается ибо все подобные сервисы — разные.
Это лишь пример ситуации, когда docker полезен — если удобнее разместить на каком-то мелком hosting'е, совсем не уровня amazon, ибо связь оного с Россией может периодически срываться с разных сторон, то возможность лёгкого переезда бывает полезной. И у нового hoster'а выбор изначальных конфигураций виртуальных серверов может оказаться ограниченным, хотя с других точек зрения может быть выгоднее.
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
Здравствуйте, vsb, Вы писали:
vsb>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта.
vsb>Никогда у меня не было проблем с повторяемостью. Это что должно случиться, чтобы с этим были проблемы? По-моему это как раз не главное, а второстепенное.
Здравствуйте, Sheridan, Вы писали:
S>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта. S>Нет, это просто возведение отмазки "у меня — работает" в абсолют.
Сейчас как правило типичная команда не может себе позволить разработчика, который сможет и бд подфисить, и запросы к ней, и фронт накидать, и апи спроектировать, и настроить всё как положено.
1. Процентов наверное 99 проектов имеют бюджет недостаточный для таких работ.
2. таких людей слишком мало в общей массе
3. количество программных проектов все еще растет быстрее количества разработчиков.
Здравствуйте, Pauel, Вы писали:
vsb>>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта.
vsb>>Никогда у меня не было проблем с повторяемостью. Это что должно случиться, чтобы с этим были проблемы? По-моему это как раз не главное, а второстепенное.
P>Каким образом ты обеспечил эту повторяемость?
Да никаким образом я её не обеспечивал, у меня её нет и не надо. Если мы под повторяемостью понимаем одно и то же. Я под повторяемостью понимаю набор скриптов для сборки конечного артефакта, которые дают идентичные байт в байт артефакты при запуске в разное время на разном оборудовании, без интернета. Логическая повторяемость у меня есть — версии образом фиксированные, версии зависимостей фиксированные, но конечно гарантии того, что завтра скачается то же, что сегодня — нет, бинарники отличаются из-за всяких встроенных дат компиляции и тд. Этого мне хватает на практике.
Здравствуйте, vsb, Вы писали:
P>>Каким образом ты обеспечил эту повторяемость?
vsb>гарантии того, что завтра скачается то же, что сегодня — нет
Итого — повторяемости нет. Просто она тебе не нужна.
Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев? Во время очередного билда выясним, что в проекте надо править зависимости, которые дают баги-несовместимости-итд.
Докер дает стабильный результат — никто задним числом не подменит тот самый байтик.
Здравствуйте, Pauel, Вы писали:
P>>>Каким образом ты обеспечил эту повторяемость?
vsb>>гарантии того, что завтра скачается то же, что сегодня — нет
P>Итого — повторяемости нет. Просто она тебе не нужна.
Ну да, я про это и написал.
P>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев?
Искать эти зависимости где-нибудь или искать другие. Но это фантастическая ситуация, тратить кучу времени и сил на решение проблемы, которая никогда не возникнет — не очень-то разумно. По крайней мере для типового проекта.
>Во время очередного билда выясним, что в проекте надо править зависимости, которые дают баги-несовместимости-итд. P>Докер дает стабильный результат — никто задним числом не подменит тот самый байтик.
Докер не даёт стабильный результат. При сборке контейнера всё так же тянется из интернета. И при сборке контейнера два раза эти контейнеры получатся разными. Докер вообще ничего в этом плане не даёт. Ты можешь складировать свои собранные артефакты в любом хранилище без всяких докеров, разницы — ноль.
Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.
А для закрытых проектов, ну максимум — какой-нибудь кеш для зависимостей поставить. Удалить-то вряд ли удалят, а вот очередной роскомпозор забанит npm и будет гемор, решаемый, но гемор. К повторяемости это отношения не имеет, но соглашусь, что в оффлайне собирать проект может быть полезно. Я лично это делал в своё время, когда был заказчик, у которого интернета не было и надо было на его территории что-то исправлять/дорабатывать. Хотя всё равно без существенных причин наверное это лишний труд, по крайней мере для небольших проектов.
Здравствуйте, vsb, Вы писали:
P>>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев? vsb>Искать эти зависимости где-нибудь или искать другие. Но это фантастическая ситуация, тратить кучу времени и сил на решение проблемы, которая никогда не возникнет — не очень-то разумно. По крайней мере для типового проекта.
В общем да, обычно не нужно. С другой стороны, отсутствие повторяемости создаёт очень неявные и тонкие проблемы, которые приходится героически решать. Когда возникают всякие невоспроизводимые баги, когда что-то где-то поломалось и повторить не получается. Надо как-то вручную описывать зависимости, контролировать это всё. Т.е. переизобретать хотя бы частично всё то, что докер предоставляет из коробки.
>>Во время очередного билда выясним, что в проекте надо править зависимости, которые дают баги-несовместимости-итд. P>>Докер дает стабильный результат — никто задним числом не подменит тот самый байтик. vsb>Докер не даёт стабильный результат. При сборке контейнера всё так же тянется из интернета. И при сборке контейнера два раза эти контейнеры получатся разными. Докер вообще ничего в этом плане не даёт. Ты можешь складировать свои собранные артефакты в любом хранилище без всяких докеров, разницы — ноль.
Это заблуждение. Имадж докера это Merkle Tree. Т.е. там нелья подменить никакой байтик вообще никак, без взлома криптографии. Другое дело, что типичный hello-world скрипт сборки ссылается на какие-нибудь latest-теги и поэтому собирается свежак. Но, во-первых, пересобирать имаджи не надо. Их можно просто хранить готовыми. Во-вторых, в скриптах можно прописывать явные ревизии зависимостей, так что сборка имаджа тоже станет повторяемой.
vsb>Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так.
Для упомянутых мною сценариев — тестировать имадж и отправлять ровно его в прод. Воспроизводить прод в тестовом енве для поиска багов ровно в той ревизии, в которой баги возникли в проде.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>В общем да, обычно не нужно. С другой стороны, отсутствие повторяемости создаёт очень неявные и тонкие проблемы, которые приходится героически решать. Когда возникают всякие невоспроизводимые баги, когда что-то где-то поломалось и повторить не получается. Надо как-то вручную описывать зависимости, контролировать это всё. Т.е. переизобретать хотя бы частично всё то, что докер предоставляет из коробки.
Ну как бы да, но вот я с такими проблемами никогда не сталкивался, чтобы у меня был баг от того, что там что-то где-то в зависимости поменялось, если они адекватно прописаны.
·>Это заблуждение. Имадж докера это Merkle Tree. Т.е. там нелья подменить никакой байтик вообще никак, без взлома криптографии. Другое дело, что типичный hello-world скрипт сборки ссылается на какие-нибудь latest-теги и поэтому собирается свежак. Но, во-первых, пересобирать имаджи не надо. Их можно просто хранить готовыми. Во-вторых, в скриптах можно прописывать явные ревизии зависимостей, так что сборка имаджа тоже станет повторяемой.
Типичный скрипт сборки может ссылаться и на версии 3.2.0, которые по сути теги, такие же как :latest, которые так же можно изменить в будущем. Чтобы нельзя было изменить — нужно прописывать хеши, а не ревизии. Но кто это делает (кроме меня, лол).
Если "пересобирать имаджи не надо", то это уже не повторяемая сборка. Так же можно сказать про то, что пересобирать программу не надо. Докер дает зафиксированное окружение, если мы не пересобираем контейнер. Но это не совсем та повторяемость, которую я имею в виду, когда говорю про repeatable builds. В общем вопрос терминологии.
vsb>>Повторяемость может быть важна для некоторых проектов. К примеру для публичных проектов, связанных с безопасностью. Если я скачиваю бинарник того же signal-а, я хочу быть уверенным, что этот бинарник соответствует опубликованным исходникам. И для этого signal поддерживает повторяемость билдов. И даже если я сам это не проверяю, я примерно представляю, что среди тысяч программистов, пользующихся им, хотя бы пара гиков найдётся, которые это проверят за меня и поднимут хай-вай, если что не так. ·>Для упомянутых мною сценариев — тестировать имадж и отправлять ровно его в прод. Воспроизводить прод в тестовом енве для поиска багов ровно в той ревизии, в которой баги возникли в проде.
Ну вот у меня в тестовом окружении то, что собирается из HEAD тестовой ветки, а когда надо релизить, я делаю пару отдельных коммитов, которые меняют версию в pom.xml и на этот коммит вешается git-тег, по которому контейнер пересобирается. В исходниках из отличий только 1.2.0-SNAPSHOT меняется на 1.2.0, но формально образ пересоберётся другой. И вот не было пока с этой схемой проблем, чтобы я захотел это как-то исправить.
Здравствуйте, vsb, Вы писали:
vsb>Если "пересобирать имаджи не надо", то это уже не повторяемая сборка. Так же можно сказать про то, что пересобирать программу не надо. Докер дает зафиксированное окружение, если мы не пересобираем контейнер. Но это не совсем та повторяемость, которую я имею в виду, когда говорю про repeatable builds. В общем вопрос терминологии.
А, ну да. С терминологией путаница. Тут не repeatable builds, а repeatable deployments. Ортогональное понятие.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Pauel, Вы писали:
P>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев?
Разумеется расстреливать из говномёта перед строем того дебила, который добавил в проект зависимость из сторонней, внешней репы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Скажем, что делать, если зависимости были удалены по каким либо причинам из публичных репозиториев? CC>Разумеется расстреливать из говномёта перед строем того дебила, который добавил в проект зависимость из сторонней, внешней репы.
В переводе с фекального на русский это звучит так — "мы храним все возможные зависимости у себя в локальных репозиториях и оплачиваем это щасте много лет подряд"
Здравствуйте, vsb, Вы писали:
vsb>Искать эти зависимости где-нибудь или искать другие. Но это фантастическая ситуация, тратить кучу времени и сил на решение проблемы, которая никогда не возникнет — не очень-то разумно. По крайней мере для типового проекта.
Я периодически сталкиваюсь с этим — нужно пускануть не такой уж старый проект, а он больше не собирается. С докером проще — пусканул контейнер и всё готово.
vsb>Докер не даёт стабильный результат. При сборке контейнера всё так же тянется из интернета. И при сборке контейнера два раза эти контейнеры получатся разными. Докер вообще ничего в этом плане не даёт. Ты можешь складировать свои собранные артефакты в любом хранилище без всяких докеров, разницы — ноль.
То есть, вместе с билдом мы собираем докер-образ. И всё. Потом когда бы тебе он ни понадобился, всё будет с точностью до байта.
Хранить собраные артефакты неудобно — их еще и деплоить надо, например.
vsb>А для закрытых проектов, ну максимум — какой-нибудь кеш для зависимостей поставить.
Для закрытых проектов варианты исчерпываются только фантазией сотрудников. Докер образы просят все подряд. А вот собраные артефакты как то не пользуются таким спросом.
Компания Microsoft похвасталась успехами облачного игрового сервиса Xbox Cloud Gaming. Согласно данным, число пользователей выросло до 20 млн человек. Об этом сообщил глава компании Сатья Наделла (Satya Nadella) в отчёте за первый финансовый квартал 2023 года.
Источник: Pixabay
Источник: Pixabay
За полгода число пользователей облачного сервиса удвоилось — в апреле 2022 года Microsoft отчитывалась о 10 млн пользователей. Вероятно, большую роль сыграло партнёрство с Epic Games, после чего в сервисе появилась единственная бесплатная игра — шутер в жанре королевской битвы Fortnite. В связи с этим остаётся вопрос доли платных подписчиков, потому что для остальных игр требуется подписка Xbox Game Pass Ultimate.
Несмотря на рост Xbox Cloud Gaming, непонятно, как оценивать успех сервиса относительно конкурентов. Google никогда не раскрывала данные по статистике Stadia, пока не объявила о закрытии платформы в январе 2023 года. NVIDIA и Amazon также не раскрывают данные о GeForce Now и Luna.
Не исключено, что Fortnite станет одним из многих бесплатных проектов на площадке. Возможно, вместо платы за подписку, в таких случаях компания будет монетизировать проекты через комиссию за внутриигровые покупки. На момент написания новости, других бесплатных игр в сервисе нет.
Microsoft опубликовала финансовый отчёт 25 октября. Компания превзошла показания аналитиков по выручке ($50,1 млрд против $49,6 млрд) и прибыли на акцию (EPS $2,35 против $2,30). Несмотря на это, акции компании упали на 8 % после публикации отчёта. Журналисты CNBC предположили, что это связано со слабыми прогнозами на второй квартал, в котором Microsoft планирует получить до $53,35 млрд выручки.
Нацелились они на облака. Поэтому много чего и похерили.
и солнце б утром не вставало, когда бы не было меня
