Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Лучше колымить в Гондурасе, чем гондурасить на Колыме.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Здравствуйте, Tai, Вы писали:
Tai> Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Она не дарит, а продаёт за большие деньги большим корпорациям свои решения.
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
сильверлайт? ну ты зело насмешил. сдохло уже давно. осталось только в легаси и активно мигрирует.
а так дот нет активно развивается. сказал бы даже черезчур активно — хрен угонишься.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии?
MS не давали революционные технологии, они давали рабочие решения существующих идей.
Tai>Windows топчется на месте, .Net не убил все остальные платформы
Заняли свою нишу и генерят прибыль
Tai>куча продуктов и проектов закрывается (Сильверлайт и проч.)
Да, в кроссплатформенный UI они много раз пытались, но все как-то неудачно. Сейчас вот очередная попытка в виде Maui на базе помершего Xamarin.
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Поколение, создавшее Windows NT, ушло на пенсию около 2010. К власти пришли кастовые индусы, у них есть дела поважнее чем технологии.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Мне кажется, что Майкрософт потихоньку проникает в индустрию open source и этим сильно закрепляется в целом.
Кто тут у нас спонсор Линукса и вносит в него вклад в виде кода? Майкрософт.
Кто владеет крупнейшим хостингом открытых проектов? Майкрософт.
Кто обучает на нём свою модель copilot? Майкрософт.
Кто делает популярную и открытую IDE VSCode? Майкрософт.
Кто открыл исходники .Net Core?
Кто развивает язык Питон?
Ну и так далее.
Как говорил Стив Балмер: "Developers, Developers, Developers!"
>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
с точки зрения революционных технологий — а кто не топчется на месте?
последнее "событие", хоть что-то изменившее — айфон, представленный яблоком уже over 9000 лет назад.
всё прочее, что от мелкомягких, что от самого яблока — хождение кругами в суровой и беспощадной гонке гигагерц и мегапикселей
Здравствуйте, Вумудщзук, Вы писали:
В>с точки зрения революционных технологий — а кто не топчется на месте?
Нейросети в 2012 появились. Развилась новая область знаний — прикладная статистика или data science в виде автоматического анализа больших данных.
Распознавание картинок, видео, анализ и генерация текста, голосовые помощники и чат-боты и автоматизация кучи проектов на этой основе. Генерация картинок, 3D моделей и видео по их текстовому описанию!
Вот это всё не следует игнорировать.
Здравствуйте, Skorodum, Вы писали:
Tai>>куча продуктов и проектов закрывается (Сильверлайт и проч.) S>Да, в кроссплатформенный UI они много раз пытались, но все как-то неудачно. Сейчас вот очередная попытка в виде Maui на базе помершего Xamarin.
А когда он помер? А то я пишу на нем.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Windows это легаси. С .NET пока не понятно, но я бы на него не ставил.
Microsoft это сейчас Azure в первую очередь.
Ну из революционного — VS code. IDE в браузере это не шутки. Оказывается даже в гугле им уже пользуются. Безопасники в экстазе — код сервера вообще не покидает.
Ну и copilot, да. Не знаю, насколько его можно считать микрософтовским и какое у него будущее, но что технология нетривиальная — это точно.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Несколько лет прожил без их продуктов, но всё равно накрыло outlook.office.com, ms teams, azure. Нормально там всё, короче, не хуже гугла.
Здравствуйте, Nuzhny, Вы писали:
N>Мне кажется, что Майкрософт потихоньку проникает в индустрию open source и этим сильно закрепляется в целом.
N>Как говорил Стив Балмер: "Developers, Developers, Developers!"
N>Нейросети в 2012 появились. Развилась новая область знаний — прикладная статистика или data science в виде автоматического анализа больших данных.
Нейросети еще в 60-х появились, data science примерно тогда же, хотя может и не назывался так.
Просто в случае нейросеток примерно с 2010-х количество стало в качество переходить и одновременно более доступными становиться.
Здравствуйте, Michael7, Вы писали:
M>Нейросети еще в 60-х появились, data science примерно тогда же, хотя может и не назывался так. M>Просто в случае нейросеток примерно с 2010-х количество стало в качество переходить и одновременно более доступными становиться.
Нейросети в науке или в массовой индустрии? В индустрии они выстрелили только в 2012, когда появились простые GPU, много данных и вспомнили старую добрую теорию.
Нам же и прикладную статистику переименовали в data science, дали множество инструментария, курсов и т.д.
Это и есть вполне себе революционное изменение в индустрии (не в науке).
Здравствуйте, paucity, Вы писали:
N>>Это и есть вполне себе революционное изменение в индустрии (не в науке). P>Посмотри сначала определение слова "революционное," прежде чем ерунду пороть
Появился на горизонте эксперт уровня "Бог", у которого вместо аргументов только посылки.
Так ты сам посмотри сначала определение слова "определение", прежде чем отсылать меня к определению!
Здравствуйте, Pzz, Вы писали:
A>>Мне тоже это кажецца, начиная с Windows 3.0.
Pzz>Я в MS-DOS тебе удалось разглядеть что-то революционное?
Я тебе умный вещь скажу, только ты не обижайся.
Моя первая рабочая машина была MicroVax II.
До её возможностей Микрософт худо-бедно дополз только в 2000-м году.
MS-DOS был прикольной игрушкой за счёт того, что можно было влезть куда угодно.
Единственно чего мне там не хватало, — это размера памяти.
Я бы и сейчас не отказался поиграть в такую игрушку с гигабайтом памяти.
Но как только началась Винда, свобода кончилось,
а до возможностей MicroVax II ползли полтора десятилетия.
И до сих пор кое-чего нет, например некоторых фич XWindow.
Xamarin support will end on May 1, 2024 for all Xamarin SDKs. Android 13 and Xcode 14 SDKs (iOS and iPadOS 16, macOS 13) will be the final versions Xamarin will target.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>А когда он помер? А то я пишу на нем.
S>Xamarin Support Policy
S>
S>Xamarin support will end on May 1, 2024 for all Xamarin SDKs. Android 13 and Xcode 14 SDKs (iOS and iPadOS 16, macOS 13) will be the final versions Xamarin will target.
Текущие версии поддерживаются в течение следующих временных рамок:
1 мая 2024 года Или до более новой последующей текущей версии
Это делается при условии, что текущие зависимости, такие как Xcode (для Xamarin.iOS) и инструменты Android (для Xamarin.Android) не изменяются по сравнению с последней версией, и поддержка не будет гарантирована для любых новых версий сторонних зависимостей.
То есть, это даты окончания поддержки текущей версии. Предыдущие версии не поддерживаются
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Если смотреть отчет по годовой выручке — то с каждым годом всё лучше и краше.
Здравствуйте, Michael7, Вы писали:
M>Нейросети еще в 60-х появились, data science примерно тогда же, хотя может и не назывался так. M>Просто в случае нейросеток примерно с 2010-х количество стало в качество переходить и одновременно более доступными становиться.
Там не только железом закидали так то, там придумали обратное распространение ошибки и другие штуки от матана, которые наконец позволили получить нормальный результат.
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Да, вам именно кажется!
Microsoft постепенно переводит бизнес на облачные рельы.
Раньше люди за ОФис платили один раз, и апгрейдились когда хотели, а теперь платят ежемесячно и постоянно, а если перестанут, то потеряют доступ к облачному диску.
То же с Azure.
Именно потому что есть Azure, Linux перестал волновать MS.
И это именно что революция в бизнесе!
Раньше были закрытые исходники, лицензии, сейчас — открытый код, помесячная оплата. И юзерам удобно, и прибыли больше — с облачных сервисов слезть практически невозможно.
Здравствуйте, alpha21264, Вы писали:
A>Я тебе умный вещь скажу, только ты не обижайся. A>Моя первая рабочая машина была MicroVax II. A>До её возможностей Микрософт худо-бедно дополз только в 2000-м году.
А что мне обижаться? Я из мелкомягких "возможностей" только MS-DOS'ом и пользовался. Как только появилась возможность на PC уйти на UNIX, я сразу ей и воспользовался. Сначала Interactive UNIX (клон SysV r3), потом более-менее работоспособный линух завезли. Венда вся прошла мимо меня, только пару-тройку драйверов под нее написал. Но мне все равно подо что драйвера писать, хоть под венду, хоть под стиральную машину.
M>Там не только железом закидали так то, там придумали обратное распространение ошибки и другие штуки от матана, которые наконец позволили получить нормальный результат.
Всё это было известно давно на теоретическом уровне. Нашумевший Deep Learning — это всего лишь перемножение кучи матриц да функция минимизации ошибки, просто раньше не было таких вычислительных возможностей.
Лучше колымить в Гондурасе, чем гондурасить на Колыме.
Здравствуйте, waterman, Вы писали:
W>И это именно что революция в бизнесе! W>Раньше были закрытые исходники, лицензии, сейчас — открытый код, помесячная оплата. И юзерам удобно, и прибыли больше — с облачных сервисов слезть практически невозможно.
Возможно, просто переехав на свое. Это вот с Оракла слезть сложно и будете платить те же ежегодные платежи как всегда. А если невозможно заплатить что делать??? — а фиг знает!
Здравствуйте, alpha21264, Вы писали:
A>Моя первая рабочая машина была MicroVax II. A>До её возможностей Микрософт худо-бедно дополз только в 2000-м году.
MicroVax совсем мимо меня прошел. А что там было такого крутого?
Здравствуйте, Skorodum, Вы писали:
S>MS не давали революционные технологии, они давали рабочие решения существующих идей.
Ты прямо как про первый айфон пишешь. Там тоже не было ничего принципиально нового, того, что где-то уже не использовалось. Просто рабочее решение на существующих идеях.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Вумудщзук, Вы писали:
В>с точки зрения революционных технологий — а кто не топчется на месте? В>последнее "событие", хоть что-то изменившее — айфон, представленный яблоком уже over 9000 лет назад.
И там тоже не было никаких революционных технологий. Просто вовремя и качественно собрали существующие воедино.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, MaximVK, Вы писали:
A>>Моя первая рабочая машина была MicroVax II. A>>До её возможностей Микрософт худо-бедно дополз только в 2000-м году.
MVK>MicroVax совсем мимо меня прошел. А что там было такого крутого?
Ну это VAX в размерности писишки. Соответсвенно операционная система — VMS.
Соответственно нет ограничений по памяти — VAX уже тогда умел свопинг.
Ну и набор отладочных средств, который уже тогда позволял ловить все ошибки работы с памятью.
И XWindow, который родился в VAX/VMS, и только потом попал в Unix.
Поэтому все прогрессы и революции мира PC были для меня из области "Ну когда же вы наконец...".
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Убийство технологий это типичное поведение майкрософт. Они сначала что-то создают, потом рекламируют, подсаживают людей, потом убивают технологии. И так по кругу из года в год, из десятилетия в десятилетие.
А делают они это затем, чтобы убить конкурентов. Ведь конкурента можно убить создав альтернативу, или купив конкурента и похоронив. Тот же .NET был создан чтобы убить JavaVM.
В начале развития платформы «Java» существовали две конкурирующие реализации Java VM:
От фирмы Sun Microsystems (создателя языка Java) — для различных платформ: Windows, Mac OS, UNIX;
От фирмы Microsoft — «Microsoft Java VM» — ориентированная только на платформу «Windows» и, по утверждениям Microsoft, «специально оптимизированная для быстрого выполнения Java-кода на платформе «Windows».
Однако «Microsoft Java VM» не была полностью совместима со спецификацией, описанной Sun в «голубой книге JVM», и имела существенные проблемы с производительностью при работе под большими нагрузками (при большом числе одновременно выполняемых потоков) и с безопасностью.
Компания «Sun» посчитала такую ситуацию недопустимой и решила, что Microsoft занимается намеренной дискредитацией и профанацией платформы «Java» путём распространения своей версии виртуальной машины Java, обладающей вышеперечисленными недостатками. На этом основании Sun неоднократно подавала в суд на Microsoft — и Microsoft была лишена следующих прав на реализацию
И тогда они создали .NET, хотя смысла в нём не было. Нормальные люди вроде Линуса Торвальдса говорят учите и программируйте на Си. А тот же C++ это уже для тех, кто научился программировать на Си и захотел большего, но в нём можно совершить много ошибок из-за огромного количества возможностей.
А ещё они создали DirectX, причём драйвера от Microsoft для OpenGL были тормознутыми. Они много куда пытались залезть, и многое окончилось неудачей. Рынок смартфонов профукали, хотя были люди, которые им доверяли и покупали виндофоны, но они их кинули с софтом, как и сторонних разработчиков.
Недавняя история с закрытием Миксера тоже показательна. Я сейчас даже про санкции против некоторых стран не говорю, не в них дело. Майкрософт это глобальное зло выкупающее нормальные проекты и делающее из них говно. Тот же скайп был популярен, но куплен и превращён в странное поделие.
Здравствуйте, ути-пути, Вы писали:
УП>Ты прямо как про первый айфон пишешь. Там тоже не было ничего принципиально нового, того, что где-то уже не использовалось. Просто рабочее решение на существующих идеях.
Заметь, что первый айфон вышел через 1 год после убийства Микрософтлм win mobile "как неперспективного". Вот и доверяй технологиям Микрософт после такого.
Здравствуйте, Nuzhny, Вы писали:
N>Нейросети в науке или в массовой индустрии? В индустрии они выстрелили только в 2012, когда появились простые GPU, много данных и вспомнили старую добрую теорию.
GPU не был триггером. В 10 году какую-то новую прикладную базу придумали для создания всего этого деплёргнинга после чего была прямо революция, а точнее ренессанс.
Здравствуйте, Артём, Вы писали:
N>>>>Кто открыл исходники .Net Core? Аё>>>Который в общем-то никому не нужен. S>>Это пока windows-only Аё>Я не копенгаген в пончиках, но .net 5 чтоли ставится на линукс из репки. Я лично удивился в треде в дискорде и поставил, чтобы проверить.
Дочитай до конца что именно ты ставишь. Там .NET Core написано.
Здравствуйте, Sheridan, Вы писали: N>>>Кто открыл исходники .Net Core? Аё>>Который в общем-то никому не нужен.
S>Это пока windows-only
А ты пробовал докеры на линукс? Образы Docker для ASP.NET Core
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sheridan, Вы писали:
Аё>>Я не копенгаген в пончиках, но .net 5 чтоли ставится на линукс из репки. Я лично удивился в треде в дискорде и поставил, чтобы проверить. S>Дочитай до конца что именно ты ставишь. Там .NET Core написано.
.Net 5 это следующая версия .Net Core 3.1
.Net Core отличаются от .Net Framework. Он изначально был для .Net Native для UWP в том числе и Windows Mobile
То есть уже был отвязан от Win API и прочих Windows only, ну и монолит был разбит на большее количество библиотек, для упрощения компиляции в .Net Native
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии?
MS когда-нибудь дарила миру революционные технологии? Ты путаешь с IBM, Sun Microsystems, SGI и некоторые другие. Вот они дарили. MS и Apple-это исключительно паразитные шаражки по заколачиванию бабла на красивой обертке.
V>Нормальные люди вроде Линуса Торвальдса говорят учите и программируйте на Си.
Что-то мне это напоминает... А, вот что — нормальные люди говорят в 2022 году "учитесь ездить на механике", вместо того, чтобы взять автомат и не камасутрить мозг на горке и в пробках.
Здравствуйте, Michael7, Вы писали:
Tai>>Ну нет, Windows 95 был революцией.
M>Тогда уж Windows NT, а Win95 — что-то вроде расширенной версии набора библиотек Win32s.
Windows 95 был революцией в части вида интерфейса, в основном таскбара.
Здравствуйте, CreatorCray, Вы писали:
A>>а до возможностей MicroVax II ползли полтора десятилетия. CC>Например?
Например нормальная работа с памятью, нормальная многозадачность,
нормальная графическая система, нормальные средства отладки,
нормальная защищённость.
В 1981 году корпорация IBM разместила запрос на создание операционной системы, которая должна была использоваться в новом семействе компьютеров IBM PC. Microsoft выкупила права на операционную систему 86-DOS у Seattle Computer Products и начала работу по её модификации под требования IBM.
Хорошо, когда есть денежки скупать разработки и разработчиков. Применительно к майкрософт говорить о революционных технологиях вообще странно. Лучше уж говорить о революционных покупках и поглощениях.
Здравствуйте, smeeld, Вы писали:
S>MS когда-нибудь дарила миру революционные технологии? Ты путаешь с IBM, Sun Microsystems, SGI и некоторые другие. Вот они дарили. MS и Apple-это исключительно паразитные шаражки по заколачиванию бабла на красивой обертке.
Кстати, мода на стартапы говорят пошла, когда индустрия упёрлась в дефицит нормальных it-компаний, которые можно было купить. Та же майкрософт скупила и поглотила сотни компаний и проектов. Все так делали, а потом нормальные компании и проекты закончились.
Я ещё помню как раздували хайп на стартапы. Сделай стартап, а потом беги со всех ног запинаясь и падая и продавай большой компании. Большая компания ждёт тебя. Всё потому что it-гиганты, включая тот же гугл и остальных технологические импотенты.
Даже гугл не смог создать ютуб, хотя хвастался, но в итоге просто купил ютуб. Майки вон хотят купить активижн близзард чуть ли не за 70 миллиардов долларов. И плевать, что не окупится, покупать всё равно некого, а денег выше крыши.
Здравствуйте, Артём, Вы писали:
Аё>Я не копенгаген в пончиках, но .net 5 чтоли ставится на линукс из репки. Я лично удивился в треде в дискорде и поставил, чтобы проверить.
И как там с гуём?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Sheridan, Вы писали: N>>>>Кто открыл исходники .Net Core? Аё>>>Который в общем-то никому не нужен.
S>>Это пока windows-only S> А ты пробовал докеры на линукс? S>Образы Docker для ASP.NET Core
Оххх... Не нужен, пока программирование идёт windows-only.
Ну и относительно докеров это отдельный срач.
Я считаю, что докеры нужны только в двух случаях:
1. Дев-окружение. Удобно переключаться между проектами. Остановил группу контейнеров, запустил другие и уже другой проект.
2. Необходимость масштабировать мощности налету. Пришло больше клиентов — подняли ещё кучку инстансов. Ушла клиенты — остановили.
В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
Здравствуйте, Serginio1, Вы писали:
Аё>>>Я не копенгаген в пончиках, но .net 5 чтоли ставится на линукс из репки. Я лично удивился в треде в дискорде и поставил, чтобы проверить. S>>Дочитай до конца что именно ты ставишь. Там .NET Core написано. S> .Net 5 это следующая версия .Net Core 3.1
А, вот оно что. Я привык что тут дотнетом называют дотнет фреймворк а оказывается вотоночто.
Меня вот это с толку сбило
$ apt search dotnet-runtime
Sorting... Done
Full Text Search... Done
dotnet-runtime-3.1/production 3.1.14-1 amd64
Microsoft .NET Core Runtime - 3.1.14 Microsoft.NETCore.App 3.1.14
dotnet-runtime-5.0/production 5.0.5-1 amd64
Microsoft .NET Runtime - 5.0.5 Microsoft.NETCore.App 5.0.5
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
Докер нужен прежде всего для облаков!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять. S> Докер нужен прежде всего для облаков!
Пункт два.
Здравствуйте, Sheridan, Вы писали:
S>Ну и относительно докеров это отдельный срач. S>Я считаю, что докеры нужны только в двух случаях:
Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>Ну и относительно докеров это отдельный срач. S>>Я считаю, что докеры нужны только в двух случаях: ·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта.
Никогда у меня не было проблем с повторяемостью. Это что должно случиться, чтобы с этим были проблемы? По-моему это как раз не главное, а второстепенное.
Та же повторяемость билдов куда важней, но не для тестирования, а для безопасности. Чтобы пользователь мог проверить, что у него бинарник скомпилирован из опубликованных исходников. При этом с ней почти никто не заморачивается на практике.
Здравствуйте, vsb, Вы писали:
vsb>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта. vsb>Никогда у меня не было проблем с повторяемостью. Это что должно случиться, чтобы с этим были проблемы? По-моему это как раз не главное, а второстепенное. vsb>Та же повторяемость билдов куда важней, но не для тестирования, а для безопасности. Чтобы пользователь мог проверить, что у него бинарник скомпилирован из опубликованных исходников. При этом с ней почти никто не заморачивается на практике.
Повторяемость всего окружения. Версия компонент операционки, jvm, используемых бинарных библиотек, компонентов твоего приложения, конфиги всякие. Повторить всё ровно то же на другом серваке с точностью до байта. Или откатиться к определённой версии. Всякие скрипта ansible можно тоже, теоретически, но они тупо медленнее, т.к. команды прогоняют каждый раз, тогда как имадж — это по сути заархивированный снапшот работы скрипта.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>Ну и относительно докеров это отдельный срач. S>>Я считаю, что докеры нужны только в двух случаях: ·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта.
Нет, это просто возведение отмазки "у меня — работает" в абсолют.
Tai>Всё это было известно давно на теоретическом уровне. Нашумевший Deep Learning — это всего лишь перемножение кучи матриц да функция минимизации ошибки, просто раньше не было таких вычислительных возможностей.
Если так рассуждать, то любая программа — это четыре действия арифметики.
Здравствуйте, Tai, Вы писали:
Tai>Всё это было известно давно на теоретическом уровне. Нашумевший Deep Learning — это всего лишь перемножение кучи матриц да функция минимизации ошибки, просто раньше не было таких вычислительных возможностей.
Ты смотрел описание Stable diffusion? Там совсем не так просто.
Мультимодальные нейросети — это тоже нечто новое, ранее об этом никто не думал.
Самое интересное, на мой взгляд, что нейросетями научились решать физические и математические задачи, получая быстрые решения сложных проблем (исследование белков, физических моделей, быстрые приближенные вычисления). Вот эта штука очень полезна для человечества.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии? Windows топчется на месте, .Net не убил все остальные платформы, куча продуктов и проектов закрывается (Сильверлайт и проч.)
Здравствуйте, Sheridan, Вы писали:
S>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта. S>Нет, это просто возведение отмазки "у меня — работает" в абсолют.
Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде?
Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alpha21264, Вы писали:
A>>>а до возможностей MicroVax II ползли полтора десятилетия. CC>>Например?
A>Например нормальная работа с памятью, нормальная многозадачность, A>нормальная графическая система, нормальные средства отладки, A>нормальная защищённость.
Это ну очень уж нормальные общие слова.
В чём именно заключается "нормальность" каждого из них?
Ну вот например "нормальная многозадачность", как это "нормально" реализовывалось на 486x да чтоб ещё и работало приемлемо быстро?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Lloret, Вы писали:
L>вместо того, чтобы взять автомат и не камасутрить мозг на горке и в пробках.
Вот только "автоматом" тут будет таки С++ а не всякие питоны.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
Tai>>Нашумевший Deep Learning — это всего лишь перемножение кучи матриц да функция минимизации ошибки A>Если так рассуждать, то любая программа — это четыре действия арифметики.
Самое смешное, что да, вычисления сводятся к четырём основным действиям с числами. В некотором роде понимание этого является продвинутым знанием. Осталось добавить сюда логику и потоки управления и получаем практически всё, что нужно для программирования.
Программирование ещё можно рассматривать как попытку представить реальный мир в виде чисел, то есть создать числовой мир. К сожалению окунуться в него сразу мешают парадигмы программирования и прочие условные ограничения.
Процессоры посредством машинных команд сосредоточены на управлении потоком исполнения и обработкой чисел. В частности поддерживаются арифметические и логические операции. Чем хорош Мартин Роберт так это тем, что во времена его молодости всяких заумных штук не существовало.
Взять для примера управление потоком исполнения. Да его можно обернуть ветвлениями и циклами. Можно создать функции и передавать управление потоком в них. Можно сделать эти функции членами класса, а глобальные обернуть в пространства имён.
Но в конечном итоге всё всегда будет сводиться к числам, не важно данные ли это или управление потоком. Говорю я об этом потому, что если не воспринимать программирование за счёт парадигм, то как-то это всё равно нужно делать.
Само собой напрашивается решение в котором можно анализировать изменение чисел. Но этому будет мешать как чёрные ящики исполняемого кода, так и парадигмы программирования с огромным количеством налепленных на них абстракций.
Во втором случае даже, если код и виден, распутать его может быть крайне сложно. За абстракцией простого числа может скрываться сверхсложный программный "механизм", который очень далеко ушёл от простых машинных команд.
Здравствуйте, velkin, Вы писали:
V>Самое смешное, что да, вычисления сводятся к четырём основным действиям с числами.
Четыре — слишком много. Достаточно иметь функцию нуля, инкремента, и выбора i-го аргумента. На аппаратном уровне вам хватит блока NAND и тактового генератора.
V>В некотором роде понимание этого является продвинутым знанием. Осталось добавить сюда логику и потоки управления и получаем практически всё, что нужно для программирования.
Вся логика, потоки управления, арифметика, символьные вычисления и вообще всё, что можно придумать, выражаются через базисы МТ или ЧРФ. Ну и что? V>Программирование ещё можно рассматривать как попытку представить реальный мир в виде чисел, то есть создать числовой мир.
Можно, но не всегда это конструктивно. Вы можете считать матрицу aффинного преобразования эдаким длинным числом, но это никак не поможет вам этими числами оперировать.
Программирование — это не столько наука о том, каким образом комбинировать элементарные инструкции в полезные программы. Это наука о том, какие программы эквивалентны между собой, и о формальном доказательстве некоторых аспектов корректности таких программ.
И qsort и bubble sort реализуются на одних и тех же инструкциях процессора; но прикладные характеристики их очень сильно различаются.
Это означает, что нам недостаточно выучить некий конечный набор примитивов — лямбда-функции, инструкции x86-64, или байткод JVM, или MSIL. До сих пор делаются заметные открытия в уже, казалось бы, сильно вытоптанных областях информационных наук. Тем более это касается тех областей, которые изучены поменьше.
Поэтому я бы не стал торопиться с объявлением конца программирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
CC>Ну вот например "нормальная многозадачность", как это "нормально" реализовывалось на 486x да чтоб ещё и работало приемлемо быстро?
Согласен. Для одних "нормальная" многозадачность — это вытеснение, и аппаратная гарантия изоляции процессов через виртуализацию памяти.
А для других — формальная верификация отсутствия нарушений изоляции (Oberon/BlueBottle, Singularity). И, в идеале, формальная верификация отсутствия starvation, которая в полном виде эквивалентна проблеме останова, так что за неё мало кто берётся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
В качестве альтернативы если только shell script, который всё настроит на всякой начальной конфигурации ОСи, но это и впрямь ещё та задачка, мало того, что где-то может изначально другой репозиторий, у некоторых модулей могут быть конфликты с чем-то предустанвленным, к тому ж разные навороты с правами пользователей — у Ubuntu свои, где-то ещё — свои. Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. А доисправлять вручную — уж думаю понятно, что слишком непродуктивная деятельность. Ну это всё кроме случаев своего hosting'а, разумеется, не знаю уж, где такое в ходу.
Здравствуйте, ·, Вы писали:
S>>·>Главное это воспроизводимость, повторяемость. Девелопишь, делаешь докер-имадж и отправляешь на тестирование, демо, етс, потом в прод, с гарантированным откатом, если что пошло не так. И точно знаешь, что работает ровно то, что надевелопил и то что было протестировано, с точностью до байта. S>>Нет, это просто возведение отмазки "у меня — работает" в абсолют. ·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде?
Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения.
Как такого добиться? Очень просто. Устанавливаем дистрибутив, обновляем его (читай — восстанавливаем "как было" виртуалку из снапшота) и тестируем.
·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем?
Ничего переизобретать и вообще изобретать не надо. Я выше описал.
В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте.
И никакие тепличные докеры не нужны.
Тепличное окружение, знаешь ли, развращает. Программисты забывают что помимо их кода есть ещо окружение, за которым тоже надо следить и своевременно обновлять.
Здравствуйте, Ilya81, Вы писали:
I>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых.
Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц.
Здравствуйте, Sheridan, Вы писали:
S>·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде? S>Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения.
Однако, оно может работать немного по-разному.
S>Как такого добиться? Очень просто. Устанавливаем дистрибутив, обновляем его (читай — восстанавливаем "как было" виртуалку из снапшота) и тестируем.
И сколько по времени занимает установка дистрибутива и обновление?
При генерации docker image это и просиходит — устанавливается дистрибутив, нужные компоненты, обновляется, конфигурируется. Просто после этого результат фиксируется в виде снапшота с уникальным sha2 и может быть мгновенно за секунды развёрнут и запущен где угодно.
S>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>Ничего переизобретать и вообще изобретать не надо. Я выше описал.
Да, ты выше и переизобрёл, правда кривовато и тормозно.
S>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте.
Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить.
У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс.
S>И никакие тепличные докеры не нужны.
Не нужны, но с ними проще и быстрее решаются некоторые задачи.
S>есть ещо окружение, за которым тоже надо следить и своевременно обновлять.
Докер это не запрещает, а упрощает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ilya81, Вы писали:
I>>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. S>Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц.
И не случалось при этом такого, что при перемещении на другой hosting приходилось что-то вручную доисправлять?
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков.
тяпляпство — это когда на рабочих серверах ставят JVM от IBM, а разработчикам — от Oracle. Случай реальный.
S>Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять.
Балинн, сколько раз это уже обсуждалось. Ну не всегда есть возможность взять последние версии всего и вся.
Вот я несколько лет назад работал с одной библиотекой (open source, замечу). Однажды скачал ее последнюю версиию. И увидел, что некоторые классы, которые я активно использую, просто исчезли. Я сунулся в документацию, а ее почему-то не обновили. Исходников было всего ничего, каких-то 12 мегов. На полчаса чтобы разобраться. Но вот не было у меня тогда этиъ полчаса.
Позже я перешел на новую версию. Раскопал в исходниках то, что мне нужно. Потому что в новой версии были некоторые очень удобные функции. Плюс там починили пару багов. Но найти нужные классы и подключить их вместо старых заняло чуть больше получаса.
Здравствуйте, student__, Вы писали:
A>>2) X Window в то время уже был больше десяти лет.
__>Был-то он был, но какой полноценный десктоп был в 1995г. на X Window, и сколько стоило железо?
Я подозреваю, что стоимость железа к самому X Window отношения не имеет.
Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе.
Но он предпочёл идти своим путём. И создал глючное (очень глючное) поделие.
PS.
Ах да! Я же вспомнил! У меня на Windows95 стоял Xceed!
Это реализация X-протокола для Виндов.
Сидишь на Винде, а Sun не твоём мониторе тебе окошки отрисовывает.
Так что всё нормально тогда было со стоимостью железа.
Здравствуйте, Tai, Вы писали:
Tai>Мне одному кажется, что Microsoft перестаёт дарить миру революционные технологии?
А он их когда то дарил? Оппортунизм почти всегда был основой их стратегии.
Tai> Windows топчется на месте,
Десктоп умер, а на мобилках и серверах венда в итоге не шмогла. В первом случае в силу безумных действий топ менеджмента, во втором в силу неверно выбранной ценовой политики.
Здравствуйте, CreatorCray, Вы писали:
A>>Например нормальная работа с памятью, нормальная многозадачность, A>>нормальная графическая система, нормальные средства отладки, A>>нормальная защищённость.
CC>Это ну очень уж нормальные общие слова. CC>В чём именно заключается "нормальность" каждого из них?
Это примерно как обьяснить негру, что такое снег.
Ну вот вы не ели ничего слаще морковки, ну и не знаете, как оно бывает.
Ну, что, я тебе буду всю свою жизнь рассказывать?
Ну вот есть IBM PC с Виндой и ТурбоС и есть Микровакс.
И на Микроваксе разработка идёт в десять раз быстрее,
потому что он не падает, не ломается, не теряет данные, в нём нет вирусов,
он не убивает свою файловую систему, и фиксирует все ошибки работы с памятью.
CC>Ну вот например "нормальная многозадачность", как это "нормально" реализовывалось на 486x да чтоб ещё и работало приемлемо быстро?
Нормальная многозадачность — это когда одна задача не может завалить другую,
не может поставить всю ось раком, когда помогает только перезагрузка,
когда после перезагрузки не слетает файловая система,
и когда машину вообще можно перегружать раз в год.
Чё вам так дался этот 486?
Мой первый линукс (RedHat 5.2) был установлен именно на AMD486DX5.
И там была та самая многозадачность, и иксовая графика.
И работало всё там приемлемо быстро.
И набор средств программирования там был уже более-менее.
Винда так не умела? Ну кто-ж ей виноват?
Но только Микровакс давал всё это уже во времена 286-х.
И вообще, PC — отстой.
Я бы предпочёл иметь тот же самый Линукс, но на процессоре другой архитектуры.
VAX подходит, ARM — тоже ничего.
Здравствуйте, ·, Вы писали:
S>>·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде? S>>Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения. ·>Однако, оно может работать немного по-разному.
Значит вы чтото делаете не так.
S>>Как такого добиться? Очень просто. Устанавливаем дистрибутив, обновляем его (читай — восстанавливаем "как было" виртуалку из снапшота) и тестируем. ·>И сколько по времени занимает установка дистрибутива и обновление? ·>При генерации docker image это и просиходит — устанавливается дистрибутив, нужные компоненты, обновляется, конфигурируется. Просто после этого результат фиксируется в виде снапшота с уникальным sha2 и может быть мгновенно за секунды развёрнут и запущен где угодно.
Устанавливаются тепличные условия, ты прав.
S>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. ·>Да, ты выше и переизобрёл, правда кривовато и тормозно.
В чём кривость и тормоза?
S>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. ·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. ·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс.
Докер не для деплоя. Докер для тепличных условий. Деплой это сетуп.экзе, ансибл, салт.
S>>И никакие тепличные докеры не нужны. ·>Не нужны, но с ними проще и быстрее решаются некоторые задачи.
Я описал какие:
1. Создание окружений для разработки/тестирования (например, в условиях параллельной разработки нескольких проектов)
2. Необходимость масштабирования в рантайме.
S>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. ·>Докер это не запрещает, а упрощает.
Бгггг. Докер не запрещает и не обновлять. И этим категорически злоупотребляют.
Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать.
Здравствуйте, Ilya81, Вы писали:
I>>>Так что написать так, что сработает на разных первоначальных конфигурациях, предоставляемых конкретным hoster'ом — дело не из простых. S>>Это всё довольно просто делается. Вангую трудозатраты где-то 8 часов на дистрибутив при старте и поддержка 2-4 часа на дистрибутив в месяц. I>И не случалось при этом такого, что при перемещении на другой hosting приходилось что-то вручную доисправлять?
Тут как минимум два варианта:
1. Заказчик сам деплоит. ХЗ, может и допиливает.
2. Деплою я. У меня значит есть все входные данные и хотелки заказчика. Деплой изначально подравнивается под него.
Но ты увёл разговор немного в сторону. Речь щла о деплое под разные дисрибутивы а не про переезд с одного хостера в лругой. Тут непонятно что такое hosting. Если это виртуалки — то какая разница. С точки зрения деплоя это просто сервера. Если это некие сервисы (типа амазоновских) то непонятно почему вообще возникает вопрос такой "не допиливается ли?...". Ясен хрен не просто допиливается а хорошо допиливается ибо все подобные сервисы — разные.
Здравствуйте, Privalov, Вы писали:
S>>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. P>тяпляпство — это когда на рабочих серверах ставят JVM от IBM, а разработчикам — от Oracle. Случай реальный.
Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения.
S>>Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер. Как правило плюсом к этому идут старые либы окружения, которые разрабам "некогда" обновлять. P>Балинн, сколько раз это уже обсуждалось. Ну не всегда есть возможность взять последние версии всего и вся.
Всегда. Правильно распределяйте время, планируйте.
P>Вот я несколько лет назад работал с одной библиотекой (open source, замечу). Однажды скачал ее последнюю версиию. И увидел, что некоторые классы, которые я активно использую, просто исчезли. Я сунулся в документацию, а ее почему-то не обновили. Исходников было всего ничего, каких-то 12 мегов. На полчаса чтобы разобраться. Но вот не было у меня тогда этиъ полчаса.
Форсмажоры никто не отменяет. В данном случае оставаться на той что есть плюс запрос автору на документацию.
P>Позже я перешел на новую версию. Раскопал в исходниках то, что мне нужно. Потому что в новой версии были некоторые очень удобные функции. Плюс там починили пару багов. Но найти нужные классы и подключить их вместо старых заняло чуть больше получаса.
Но ты даже осилил сам всё раскопать. Молодец.
Здравствуйте, alpha21264, Вы писали:
A>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе.
Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ рахные вещи.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>Это примерно как обьяснить негру, что такое снег. A>Ну вот вы не ели ничего слаще морковки, ну и не знаете, как оно бывает.
Какие милые детские понты
Начало интересное, дальше надо полагать такие же растопыреные пальцы будут?
A>Ну, что, я тебе буду всю свою жизнь рассказывать?
Да кому твоя жизнь надо, тебя про технические детали спрашивают.
A>Ну вот есть IBM PC с Виндой и ТурбоС и есть Микровакс. A>И на Микроваксе разработка идёт в десять раз быстрее, A>потому что он не падает, не ломается, не теряет данные, в нём нет вирусов, A>он не убивает свою файловую систему, и фиксирует все ошибки работы с памятью.
Это всё пустой трёп и байки. Чикага была тем ещё говном, но в отличие от большинства альтернатив, которые юзер мог запускать на своём железе, она таки работала с приемлемой скоростью и, самое главное, давала юзеру возможность запускать тот софт, что ему был нужен.
Так что проблема винды была в том, как это всё заставить шевелиться на том букете железа, что есть у массового кастомера, а не на SoC от одного производителя.
Потому и были отдельно NT для серваков и отдельно чикага для юзверей, с кучей вынужденных компромиссов чтоб оно на том хламе, что у юзера есть, бегало.
A>не может поставить всю ось раком, когда помогает только перезагрузка,
Кривой драйвер или глючная железяка может поставить всё раком в любой системе.
В тепличных условиях, когда всё железо твоё — с этим проще. Но это не заслуга ОС.
A>когда после перезагрузки не слетает файловая система,
Это вообще не имеет отношения к многозадачности.
A>Чё вам так дался этот 486?
Да потому что на момент выходя Win95 это был наиболее вменяемый проц из того что было у клиентской базы.
A>Мой первый линукс (RedHat 5.2) был установлен именно на AMD486DX5.
А линух то к VMX каким боком?
A>И там была та самая многозадачность, и иксовая графика. И работало всё там приемлемо быстро. И набор средств программирования там был уже более-менее.
Вот это щас очень смешно было. Я помню как оно было "быстро", какой глючный мрак был та самая "иксовая графика", и какой там был набор средств для девелопмента — каменные топоры и палки копалки.
Причём что в те времена что линух что винду периодинчески раскорячивало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sheridan, Вы писали:
S>Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения.
Я, признаться, не знаю, как получилось, что разные JVM работали в разных средах. Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить.
S>Всегда. Правильно распределяйте время, планируйте. S>Форсмажоры никто не отменяет.
Не находишь тут противоречия? думаю, что нет.
Тебе всегда удается все правильно планировать? Мне — с переменным успехом. В силу ряда объективных и субъективных причин.
S>Но ты даже осилил сам всё раскопать. Молодец.
Опыт не пропьешь. Я чуть меньше, чем все врем, работаю с чужим кодом. После лазания с маркером и карандашом по километровым листингам с фортрановским кодом, а почти ничего не боюсь. Плюс толька везения в данном конкретном случае. Во-первых, все остальные части остались без изменений. Во-вторых, нужный мне функционал находился в определенном пространстве имен. Ну пришлось исходники покопать, и я знал что в данном конкретном случае на низком уровне происходит. Потому и справился.
Здравствуйте, Sheridan, Вы писали:
S>>>·>Причём тут отмазы? Какой ты ещё способ предложишь быть уверенным, что то что работает в проде это ровно то, что тестировалось? Как ещё быть уверенным, что ищешь багу ровно в том коде, который работает на проде? S>>>Оно должно работать без тепличных условий контейнера. А это значит как минимум — с актуальными версиями библиотек окружения. S>·>Однако, оно может работать немного по-разному. S>Значит вы чтото делаете не так.
Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения.
S>·>И сколько по времени занимает установка дистрибутива и обновление? S>·>При генерации docker image это и просиходит — устанавливается дистрибутив, нужные компоненты, обновляется, конфигурируется. Просто после этого результат фиксируется в виде снапшота с уникальным sha2 и может быть мгновенно за секунды развёрнут и запущен где угодно. S>Устанавливаются тепличные условия, ты прав.
Чем устанавливаются? Куда?
S>>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. S>·>Да, ты выше и переизобрёл, правда кривовато и тормозно. S>В чём кривость и тормоза?
Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
S>>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. S>·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. S>·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс. S>Докер не для деплоя. Докер для тепличных условий.
Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно.
S>Деплой это сетуп.экзе, ансибл, салт.
Это инсталляция.
S>>>И никакие тепличные докеры не нужны. S>·>Не нужны, но с ними проще и быстрее решаются некоторые задачи. S>Я описал какие: S>1. Создание окружений для разработки/тестирования (например, в условиях параллельной разработки нескольких проектов)
Это можно и тем же ансиблом можно делать. Докер для этого необязателен. Но таки да, удобнее, т.к. быстрее.
S>2. Необходимость масштабирования в рантайме.
Это уже следствие. Если мы можем легко и быстро переносить софт между хостами, то можно это делать много, т.е. масштабировать.
S>>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. S>·>Докер это не запрещает, а упрощает. S>Бгггг. Докер не запрещает и не обновлять.
А кто может запретить не обновлять?!
S>И этим категорически злоупотребляют.
Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п.
S>Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать.
Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так. Поэтому риск слишком высок.
С докером же если обновление не работает, откат тривиален и надёжен, и часто даже автоматический откат.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Privalov, Вы писали:
S>>Да, это тоже тяплапство: отсуствие упоминание о поддерживаемой jvm в документации. Отсуствие деплоя jvm в процессе, собственно, деплоя приложения. P>Я, признаться, не знаю, как получилось, что разные JVM работали в разных средах. Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить.
Как получилось не знаешь, но виноваты всё равно админы. Но работать ты их не учишь...
Может беды из-за этого и пора начать учить?
S>>Всегда. Правильно распределяйте время, планируйте. S>>Форсмажоры никто не отменяет. P>Не находишь тут противоречия? думаю, что нет. P>Тебе всегда удается все правильно планировать? Мне — с переменным успехом. В силу ряда объективных и субъективных причин.
"Не планировать" и "запланировать но в силу обстоятельств сдвинуть планы" — несколько разные вещи, не находишь ли?
Здравствуйте, Farsight, Вы писали:
S>>Докер не для деплоя. Докер для тепличных условий. Деплой это сетуп.экзе, ансибл, салт. F>А вдруг для деплоя?
В рекламе и не такого могут понаписать.
Здравствуйте, ·, Вы писали:
·>Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения.
Раз такая цель — то и никаких проблем, ибо изменения ожидаемые.
S>>Устанавливаются тепличные условия, ты прав. ·>Чем устанавливаются? Куда?
Докером для приложения.
S>>>>·>Можно, конечно, придумать какие-то скрипты, в которые можно прописать компоненты и их версии, описать как их разместить их в дереве файлов, запаковать в архивы и выложить в какое-нибудь хранилище. Или, Иными словами, переизобрести докер-имадж. Но зачем? S>>>>Ничего переизобретать и вообще изобретать не надо. Я выше описал. S>>·>Да, ты выше и переизобрёл, правда кривовато и тормозно. S>>В чём кривость и тормоза? ·>Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
S>>>>В дополнение могу написать только то, что если вы разрабатываете сложную систему (которая устанавливается не просто юзеру на машину, но требует для себя несколько серверов, несколько сервером для окружения итд), то деплой пишется на том-же ансибле или там солте. S>>·>Ансибл и подобное имеет другое предназначение. Это, например, подготовка компа для пользователя. Купили лаптоп, натравили ансибл и у тебя готовая машинка выдать очередному сотруднику. Если сотрудник что-то испортит — можно легко пофиксить. S>>·>У докера другое предназначение, для деплоймента приложений. Поставили новую железку в стойку и запустили на нём нужные сервисы. Потом обновляем сервис на новую версию, переносим на другую железку, етс. S>>Докер не для деплоя. Докер для тепличных условий. ·>Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно.
Ansible, salt для сложный систем.
Опакетить, опять же можно если очередной сидтэжектор.
Но нет же. Нужен именно докер...
S>>Деплой это сетуп.экзе, ансибл, салт. ·>Это инсталляция.
Ээээ, друг. Это смотря сколько чего участвует в развёртывании.
Если сидиэжектор очередной ставится на ноут домохозяйки — это инсталляция.
Если поднимается некая скада у которой только обслуживающих серверов под перефирийное ПО несколько штук — это деплой.
S>>>>есть ещо окружение, за которым тоже надо следить и своевременно обновлять. S>>·>Докер это не запрещает, а упрощает. S>>Бгггг. Докер не запрещает и не обновлять. ·>А кто может запретить не обновлять?!
Проблема в том, что нет как правило волевых людей, которые запрещают не обновлять. И в итоге всё скатывается в сраное говно когда приложения для работы нужны либы вековой давности а переход на новые версии, из-за систематического забивания болтов на обновления, настолько уже сложен, что проще начать писать с нуля.
И дуд приходит докер в ореоле Чистого Света. И появляется куча статей "ооо какие мы крутые переехали на докер!". А там куда ни копни — вежде говно мамонта внутрях.
S>>И этим категорически злоупотребляют. ·>Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п.
Попадаются, да. Категорически легко обходится пунктом в инструкции под заголовком "Минимальные системные требования".
S>>Точнее, сначала забивают болт на обновления, а потом прикручивают докер чтобы и дальше забивать. ·>Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. ·>Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так.
Вот, вот оно! Я дождался!
Знаешь почему это происходит в проде?
Потому что, ммать, вы забили болт обновлять дистрибутивы у себя даже на тестах, не говоря уже об остальном.
Добавьте в планы хотя бы раз в квартал обновляться. Да ладно раз в квартал... Хотя бы перед релизом протестируйте на свежих версиях поддерживаемых дистрибутивов.
Здравствуйте, Sheridan, Вы писали:
S>·>Цель изменений — чтобы что-то работало по-другому. Поэтому, разные версии по определению работают по-разному. Вопрос лишь в том, оказывает ли существенное влияние эта разница на функционирование нашего приложения. Это можно узнать только тестированием. А ещё бывают баги и неожиданные изменения. S>Раз такая цель — то и никаких проблем, ибо изменения ожидаемые.
Ты баги, например, уже запретил?
Как ты проверишь, что ожидаемые изменения работают ожидаемо?
S>>>Устанавливаются тепличные условия, ты прав. S>·>Чем устанавливаются? Куда? S>Докером для приложения.
Ты говоришь, как будто это что-то плохое.
S>>>В чём кривость и тормоза? S>·>Ответь на вопрос вначале: И сколько по времени занимает установка дистрибутива и обновление?
Сложный вопрос, да?
S>·>Именно — для быстрого и надёжного деплоя куда угодно ровно того что нужно. S>Ansible, salt для сложный систем.
Это как раз для простых систем. В сложных системах становится всё плохо.
Такой простой сценарий. Прогоняешь ты на проде очередной плейбук из 10 шагов. Допустим 5й шаг зафейлился. Что будешь делать?
В случае же докера у тебя ровно один шаг — выкатить имадж. Если он не срабатывает, то всё остаётся в текущем состоянии.
Другой сценарий. Ты прогнал таки плейбук и выкатил очередную версию. Через пол часа юзеры пожаловались, что как-то всё притормаживает. Как откатишься к предыдущему состоянию? Как потом будешь искать проблему тормозов, пока прод крутится на старой версии?
В случае докера просто выкатываешь предыдущий образ, идентифицируемый по sha2. Всё. Проблему ищешь в тестовом енве, выкатив ровно тот же sha2 на который юзеры жаловались.
S>Опакетить, опять же можно если очередной сидтэжектор. S>Но нет же. Нужен именно докер...
Я понял, ты не видел ничего сложнее сидиэджектора, вот и думаешь, что аснибл — всемогутер.
S>>>Деплой это сетуп.экзе, ансибл, салт. S>·>Это инсталляция. S>Ээээ, друг. Это смотря сколько чего участвует в развёртывании. S>Если сидиэжектор очередной ставится на ноут домохозяйки — это инсталляция. S>Если поднимается некая скада у которой только обслуживающих серверов под перефирийное ПО несколько штук — это деплой.
Ну вот видишь... А теперь представь, что серверов у тебя на порядка 2 больше, десятки разных приложений, на разных яп, использующие разные версии рантайма, операционки, дублирование в разных DC, всякий A/B-rollout, етс.
S>>>Бгггг. Докер не запрещает и не обновлять. S>·>А кто может запретить не обновлять?! S>Проблема в том, что нет как правило волевых людей, которые запрещают не обновлять.
Как только неожиданный очередной WindowsUpdate, или важные security updates внезапно перезагрузит прод и что-то не загрузится, так сразу все эти обнавлялки и повырубают.
S>И в итоге всё скатывается в сраное говно когда приложения для работы нужны либы вековой давности а переход на новые версии, из-за систематического забивания болтов на обновления, настолько уже сложен, что проще начать писать с нуля. S>И дуд приходит докер в ореоле Чистого Света. И появляется куча статей "ооо какие мы крутые переехали на докер!". А там куда ни копни — вежде говно мамонта внутрях.
Ты так и не объяснил, чем недокер поможет.
S>>>И этим категорически злоупотребляют. S>·>Злоупотреблять можно чем угодно. И без докеров нередко попадаются древние версии операционок и т.п. S>Попадаются, да. Категорически легко обходится пунктом в инструкции под заголовком "Минимальные системные требования".
Инструкции в ворд-документе?!
S>·>Отсутствие докера положение только усугубляет. Начнёшь что-нибудь обновлять, что-то сломается по дороге и фиг потом восстановишь. S>·>Особенно весело, когда на тестовом окружении всё прошло как по маслу, а на проде что-то пошло не так. S>Вот, вот оно! Я дождался! S>Знаешь почему это происходит в проде?
Потому что очень сложно без докера обеспечить повторяемость. Результат обновления у себя в тестах может быть не идентичен результату такого же обновления в проде, спустя некоторое время.
S>Потому что, ммать, вы забили болт обновлять дистрибутивы у себя даже на тестах, не говоря уже об остальном.
Ты видимо не понимаешь как докер работает. Он как раз этот процесс и облегчает. Обновляешь у себя в тестах, тестируешь, а потом ровно это обновлённое и оттестированное промоутишь в прод.
S>Добавьте в планы хотя бы раз в квартал обновляться. Да ладно раз в квартал... Хотя бы перед релизом протестируйте на свежих версиях поддерживаемых дистрибутивов.
Именно. Вопрос в планах на обновление, а не в докере-ансибле.
И ты упорно игнорируешь тот факт, что планы на обновление осуществлять _проще_ в докере, чем в ансибле.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sheridan, Вы писали:
P>>Могу сказать: админы накосячили. Но не скажу. Реальность суровее. Поэтому я и не учу админов админить. S>Как получилось не знаешь, но виноваты всё равно админы. Но работать ты их не учишь...
Величайшей ошибкой было бы думать. В. И. Ленин, ПСС, т.42. с.74
Может, попробуешь прочитать чуть дальше "авмины накосячили"? Специально оставлю.
S>Может беды из-за этого и пора начать учить?
Мое дитя выросло и стало нормальным сисадмином. Само научилось. Код писать не хочет. Говорит, не умеет.
У расработчиков специфика другая. Мы в реальности с админами взаимодействуем. Как и с безопасниками, и остальными спецами. Редкие исключения случаются. Типа того "админа",который на рабочий сервер дважды в неделю умудрялся трояна, шифрующего файлы, пропускать. Я его, кстати, однажды полдня убеждал, что у него на сервере часы неправильно идут. Убедил, только получив доступ к тому серверу и сделав снимок экрана с часами. А мог бы и отформатировать там чего-нибудь.
Сейчас там нормальный спец, никаких терок не возникает. Любые конфликты разрешаются в рабочем порядке.
S>"Не планировать" и "запланировать но в силу обстоятельств сдвинуть планы" — несколько разные вещи, не находишь ли?
Здравствуйте, 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 млрд выручки.
Нацелились они на облака. Поэтому много чего и похерили.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, smeeld, Вы писали:
S>MS когда-нибудь дарила миру революционные технологии?
Постоянно.
Весь современный web, так называемый web 2.0, стал возможен в результате того, что Microsoft сделали outlook web access, и добавили в свой браузер Internet Explorer 5.0 объект XMLHttpRequest.
Современные 3D GPUs стали повсеместным явлением потому, что Windows Vista в 2006 решили использовать 3D графику с шейдерами для окон на рабочем столе.
Здравствуйте, Pauel, Вы писали:
P>мы храним все возможные зависимости у себя в локальных репозиториях
Именно так. Ибо минимизация рисков
P> и оплачиваем это щасте много лет подряд
Ну да, ну да, место на дисках нынче ну ооочень дорогое!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Я периодически сталкиваюсь с этим — нужно пускануть не такой уж старый проект, а он больше не собирается.
И почему же он у тебя не собирается?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Константин, Вы писали:
К>Весь современный web, так называемый web 2.0, стал возможен в результате того, что Microsoft сделали outlook web access, и добавили в свой браузер Internet Explorer 5.0 объект XMLHttpRequest.
К>Современные 3D GPUs стали повсеместным явлением потому, что Windows Vista в 2006 решили использовать 3D графику с шейдерами для окон на рабочем столе.
Дадада, а до этого ни у кого GPU не было, ага И в тот же дум 3 (2004) все играли без шейдеров
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>мы храним все возможные зависимости у себя в локальных репозиториях CC>Именно так. Ибо минимизация рисков
P>> и оплачиваем это щасте много лет подряд CC>Ну да, ну да, место на дисках нынче ну ооочень дорогое!
Кроме места на диске, тебе нужно оплачивать всю инфраструктуру под это дело, трафик, инстансы, бекапы, что есть увеличение работы на местных админов/опсов/суппорт и вытекащее из этого постоянные расходы на зп этим людям.
И вот это уже будет несравнимо дороже просто места на диске.
Здравствуйте, CreatorCray, Вы писали:
P>>Я периодически сталкиваюсь с этим — нужно пускануть не такой уж старый проект, а он больше не собирается. CC>И почему же он у тебя не собирается?
1. депенденсы (билдтайм, рантайм) недоступны из за наличия секурити проблем, а новые версии не совместимы
2. новая платформа, которая не поддерживается старым кодом
Еще проблемы
3. старые скрипты не умеют деплоить на новую платформу
4. новые скрипты не умеют деплоить старые проекты
Итого — докер-образ решает 1 2 3 и 4. Просто пишешь docker run и всё палит.
Здравствуйте, Pauel, Вы писали:
P>Кроме места на диске, тебе нужно оплачивать всю инфраструктуру под это дело, трафик, инстансы, бекапы, что есть увеличение работы на местных админов/опсов/суппорт и вытекащее из этого постоянные расходы на зп этим людям. P>И вот это уже будет несравнимо дороже просто места на диске.
А докер образы твои хранятся святым духом забесплатно?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>И вот это уже будет несравнимо дороже просто места на диске.
CC>А докер образы твои хранятся святым духом забесплатно?
С ними все гораздо проще. Хранить нужно только релизные версии, и то не все. Депенденсов как правило гораздо больше — они должны покрывать вообще все проекты что старые, что новые.
И в любом случае это дополнительные издержки.
Здравствуйте, CreatorCray, Вы писали:
A>>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе. CC>Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ рахные вещи.
При чём здесь это? Ты понимаешь, что такое X-Window? Это программа такая.
Здравствуйте, mike_rs, Вы писали:
A>>2) X Window в то время уже был больше десяти лет.
_>а толку-то, если уровня win95 твои иксы достигли только пару лет назад?
Это нужно иметь очень извращённое представление о мире.
По моему, только в 2010-м Винды худо-бедно доползли до возможностей Иксов 80-х годов.
Здравствуйте, Pauel, Вы писали:
P>>>Я периодически сталкиваюсь с этим — нужно пускануть не такой уж старый проект, а он больше не собирается. CC>>И почему же он у тебя не собирается? P>1. депенденсы (билдтайм, рантайм) недоступны из за наличия секурити проблем
Это как? Куда ж они протерялись то?
P> а новые версии не совместимы
И кто ж тебе виноват что ты старые не сохранил?
P>Итого — докер-образ решает 1 2 3 и 4. Просто пишешь docker run и всё палит.
Это всё решается и без докера, но теми же самыми принципами.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>>>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе. CC>>Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ разные вещи. A>При чём здесь это?
биллигейц (tm) не делал железо, он делал софт, который должен был работать на том хламе, что есть у юзера.
A> Ты понимаешь, что такое X-Window? Это программа такая.
Это протокол для remote graphical user interface
Нахрена кому в локальной винде были навороты из зоопарка mainframes?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>По моему, только в 2010-м Винды худо-бедно доползли до возможностей Иксов 80-х годов. Это каких же?
Быструю графику иксы не могли вообще никогда, by design.
Аналогом иксов в винде был RDP, который изначально появился для NT 4.0, 1998 а уже в 2003м был весьма хорош.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>1. депенденсы (билдтайм, рантайм) недоступны из за наличия секурити проблем CC>Это как? Куда ж они протерялись то?
Похоже, ты забыл про что речь. Удаляют по разным причинам.
P>> а новые версии не совместимы CC>И кто ж тебе виноват что ты старые не сохранил?
Слишком дорого хранить все депенденсы, особенно публичные. Скажем, из наших внутренних депенденсов чудовищное количество имеют единицы скачиваний. И только малая доля скачивается постоянно.
P>>Итого — докер-образ решает 1 2 3 и 4. Просто пишешь docker run и всё палит. CC>Это всё решается и без докера, но теми же самыми принципами.
Ога. Жалко, что индустрия не пошла по твоему варианту.
Здравствуйте, Pauel, Вы писали:
P>Похоже, ты забыл про что речь. Удаляют по разным причинам.
Не, просто ты по какой то причине думаешь что кто то другой должен хранить нужное тебе за тебя.
CC>>И кто ж тебе виноват что ты старые не сохранил? P>Слишком дорого хранить все депенденсы, особенно публичные.
Puh-lease! Сколько у тебя терабайт зависимостей?
Вон, в амазоне ценник на хранение юзерского говна:
S3 Glacier Instant Retrieval*** — For long-lived archive data accessed once a quarter with instant retrieval in milliseconds
All Storage / Month $0.004 per GB
S3 Glacier Flexible Retrieval (Formerly S3 Glacier)***- For long-term backups and archives with retrieval option from 1 minute to 12 hours
All Storage / Month $0.0036 per GB
S3 Glacier Deep Archive*** — For long-term data archiving that is accessed once or twice in a year and can be restored within 12 hours
All Storage / Month $0.00099 per GB
Держать там терабайтный архив зависимостей, на случай если вдруг понадобятся ~$12.16 в год.
Ну просто капец как дорого!!!
P> Скажем, из наших внутренних депенденсов чудовищное количество имеют единицы скачиваний. И только малая доля скачивается постоянно.
Вопрос в том, почему вообще что то скачивается постоянно?
P>>>Итого — докер-образ решает 1 2 3 и 4. Просто пишешь docker run и всё палит. CC>>Это всё решается и без докера, но теми же самыми принципами. P>Ога. Жалко, что индустрия не пошла по твоему варианту.
Ты о какой индустрии говоришь то? В моей окрестности докера как то не наблюдается.
И потом, чем хранение докер образа отличается от хранения "исходников", из которых этот образ собирается?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Похоже, ты забыл про что речь. Удаляют по разным причинам. CC>Не, просто ты по какой то причине думаешь что кто то другой должен хранить нужное тебе за тебя.
Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее.
P>>Слишком дорого хранить все депенденсы, особенно публичные. CC>Puh-lease! Сколько у тебя терабайт зависимостей?
Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения.
CC>Держать там терабайтный архив зависимостей, на случай если вдруг понадобятся ~$12.16 в год. CC>Ну просто капец как дорого!!!
Во первых, терабата мало. Во вторых, сюда нужно добавить зп опсов которые будут заниматься всеми подобными вопросами, издержки на лишние билды и тд, см список внизу
И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов. Подтянул сотню другую зависимостей — надо что бы они автоматом появились в этом архиве. Кто это будет делать и кто будет платить за этот банкет?
P>> Скажем, из наших внутренних депенденсов чудовищное количество имеют единицы скачиваний. И только малая доля скачивается постоянно. CC>Вопрос в том, почему вообще что то скачивается постоянно?
Элементарно — билды на фичи-баги-секюрити требуют зависимостей.
P>>Ога. Жалко, что индустрия не пошла по твоему варианту. CC>Ты о какой индустрии говоришь то? В моей окрестности докера как то не наблюдается.
Потому, что ты работаешь в узенькой нише. Веб-приложений разного масштаба в тысячи раз бОльше.
Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ?
CC>И потом, чем хранение докер образа отличается от хранения "исходников", из которых этот образ собирается?
А ты вообще читал про докер?
Докер образ это наполовину продеплоеный артефакт. Секунды, и ты уже переключил энв на нужную версию.
Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты.
Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке.
За это время я могу перебрать десяток версий сервиса и найти вилку было-стало.
То есть, в случае с хранением исходников:
0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?
1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его
2. скачать нужную версию исходников по тегу
3. скачать все зависимости, коих обычно больше чем исходников, при чем намного
4. стартовать билд и собрать артефакты
5. собрать конфигурацию
6. залить на сервер, где лежат билды
7. скачать и пускануть пайплайн для деплоймента
И тут мы выясняем, что здесь ажно 8-10 разных шагов, каждый из которых время от времени отваливается по разными причинам — например
закончилось место на агенте, надо чпокать опсов
поменялся энвайрмент агента, надо чпокать опсов
протухли креденшиалы, надо чпокать опсов
отвалились пермишны, снова надо чпокать опсов
поменялась конфигурация сети, снова надо чпокать опсов или админов
итд итд, и каждый раз чпокаем опсов, админов, итд по списку
И самое забавное — пункт 0 — где гарантия, что ты подкинешь те самые переменные, что были использованы в первый раз?
Здравствуйте, Sinclair, Вы писали:
CC>> И, в идеале, формальная верификация отсутствия starvation, которая в полном виде эквивалентна проблеме останова, так что за неё мало кто берётся.
Здравствуйте, MaximVK, Вы писали:
MVK>А можно чуть подробней про это. Можно ссылками.
Ссылку сходу не найду, но там вроде как обоснование очевидно.
— вот у вас есть некая "параллельная программа". Можно считать, что она эквивалентна одновременному (ну, или поочерёдно-пошаговому) исполнению нескольких Машин Тьюринга.
Если мы говорим о кооперативной многозадачности, то нужно гарантировать, что
1. Ни одна из машин не сваливается в бесконечный цикл — эквивалентно проблеме останова
Если мы говорим о вытесняющей многозадачности, то нужно гарантировать, что
2. Мы не порождаем бесконечно большое количество новых МТ.
Предположим, что порождение новой МТ — это такая новая команда в нашей модифицированной Машине Тьюринга.
Гарантия непорождения бесконечного количества новых МТ эквивалентна гарантии того, что наша МТ выполнит команду "New Machine" ограниченное количество раз => эквивалентно проблеме останова.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pauel, Вы писали:
P>>С ними все гораздо проще. CC>Да то же самое по сути, только вид в профиль.
Нет. Докер математически эквивалентен идее "вот я собрал версию 3.1.1333.666 своего приложения — и теперь храню рядом с ним бинари всех зависимостей для этой версии".
Да, конечно, там тратится место на хранение бинарей какого-то древнего релиза какого-нибудь там Дебиана.
Но это всё ещё бесконечно выгоднее альтернативы "хранить рядом всю историю всех релизов Дебиана, и MySQL, и PHP, и всего остального, на что я задепендился, чтобы я мог завтра пересобрать позавчерашнюю версию моего софта".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pauel, Вы писали:
P>Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее.
Чем это отличается от хранения в докере всего, что надо чтоб одной кнопкой всё собрать?
P>Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения.
Издержки на хранение данных меряются как ни странно в объёмах данных, которые надо хранить. От этого всё дальше танцуется.
P>Во первых, терабата мало.
Возьми петабайт
P> Во вторых, сюда нужно добавить зп опсов которые будут заниматься всеми подобными вопросами
Они уже должны быть полюбас.
P>И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов.
Называется git
P>Элементарно — билды на фичи-баги-секюрити требуют зависимостей.
Ну т.е. это не версионированный билд, это TOT.
P>Потому, что ты работаешь в узенькой нише.
Эта узенькая ниша как раз занимается хранением всякого вашего говна.
P> Веб-приложений разного масштаба в тысячи раз бОльше. P> Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты.
Ты точно щас про веб?
P>Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ?
И слава богам, ибо помойка там страшная.
P>Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке.
А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?
P>То есть, в случае с хранением исходников: P>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ? P>1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его P>2. скачать нужную версию исходников по тегу P>3. скачать все зависимости, коих обычно больше чем исходников, при чем намного
Вы это что, всё врукопашную до сих пор делаете?
P>И тут мы выясняем, что здесь ажно 8-10 разных шагов, каждый из которых время от времени отваливается по разными причинам — например P> закончилось место на агенте, надо чпокать опсов P> поменялся энвайрмент агента, надо чпокать опсов P> протухли креденшиалы, надо чпокать опсов P> отвалились пермишны, снова надо чпокать опсов P> поменялась конфигурация сети, снова надо чпокать опсов или админов P> итд итд, и каждый раз чпокаем опсов, админов, итд по списку P>И самое забавное — пункт 0 — где гарантия, что ты подкинешь те самые переменные, что были использованы в первый раз?
Какой бардак!
Это впрочем многое объясняет.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
P>>>С ними все гораздо проще. CC>>Да то же самое по сути, только вид в профиль. S>Нет. Докер математически эквивалентен идее "вот я собрал версию 3.1.1333.666 своего приложения — и теперь храню рядом с ним бинари всех зависимостей для этой версии".
Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё.
А когда вылазит какое нить говно то надо всё равно подымать тот самый снапшот кода, чтоб детально разобраться (бывает ещё и инструментировать приходится) и потом патч выкатывать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: CC>Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё.
Ну, так в основном этого и требуется. Воспроизведение — половина починки. CC>А когда вылазит какое нить говно то надо всё равно подымать тот самый снапшот кода, чтоб детально разобраться (бывает ещё и инструментировать приходится) и потом патч выкатывать.
Ну так свой-то код, естественно, вы держите со всей историей. Поэтому взяли нужную клиенту базовую версию, воспроизвели проблему, собрали патченую версию, докатили её в новый докер-образ на основе того, на котором воспроизвели, и отдали. Всё.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
P>>Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее. CC>Чем это отличается от хранения в докере всего, что надо чтоб одной кнопкой всё собрать?
Я тебе привел цельный список. В твоей схеме надо
1 хранить чуть не все возможные версии всех депенденсов
2 тратить чудовищное время на билд в силу естественных причин
3 приседать с переменными билда-деплоя каждый раз когда понадобится
P>>Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения. CC>Издержки на хранение данных меряются как ни странно в объёмах данных, которые надо хранить. От этого всё дальше танцуется.
И всё равно надо считать суммарную стоимость владения. Например, каждый доп-сервис это плюс некоторый процент на ЗП опсов и админов.
Каждый билд — это время. Например, на предыдущем проекте включить старую версию на стг это дело секунд.
P>>Во первых, терабата мало. CC>Возьми петабайт
Нужно считать не байты, а суммарную стоимость владения в деньгах.
P>> Во вторых, сюда нужно добавить зп опсов которые будут заниматься всеми подобными вопросами CC>Они уже должны быть полюбас.
А капасити опсов по твоему неограничена?
P>>И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов. CC>Называется git
Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
Гит как хранилище артефактов работает плохо, его крайне трудно использовать, если у нас проекты разных сортов и депенденсы у всех разные, а размеры чудовищные.
P>>Элементарно — билды на фичи-баги-секюрити требуют зависимостей. CC>Ну т.е. это не версионированный билд, это TOT.
Бывает по всяком, смотря какие задачи.
P>>Потому, что ты работаешь в узенькой нише. CC>Эта узенькая ниша как раз занимается хранением всякого вашего говна.
Тем не менее, это узенькая ниша. Скажем, если собирать драйвер, десктоп приложение, или плагин к такому приложения, то тут билды падают раз в год, в основном когда заканчивается место на диске или протухают сертификаты.
Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
P>> Веб-приложений разного масштаба в тысячи раз бОльше. P>> Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты. CC>Ты точно щас про веб?
Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
P>>Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ? CC>И слава богам, ибо помойка там страшная.
Не работал, но мнение имеешь
P>>Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке. CC>А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?
Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
P>>То есть, в случае с хранением исходников: P>>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?
Забавно, что ответа от тебя не поступило. Гы!
P>>1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его P>>2. скачать нужную версию исходников по тегу P>>3. скачать все зависимости, коих обычно больше чем исходников, при чем намного CC>Вы это что, всё врукопашную до сих пор делаете?
Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.
CC>Какой бардак!
Это обычное веб-приложение. Забавно, что ты не смог ничего выдать про переменные билда. Каким чудом собираешься обеспечить идентичность переменных?
А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
Здравствуйте, Вумудщзук, Вы писали:
В>всё прочее, что от мелкомягких, что от самого яблока — хождение кругами в суровой и беспощадной гонке гигагерц и мегапикселей
ну нет, примерно на стыке 19-20 года произошел резкий скачок в качестве фоток телефонных, по сути приблизивший для обывателя качество до уровня зеркалок.
Примерно в то время (и только изза этого факта) я и купил для фоток себе один телефон, а для видео жене айфон, и в наши экспедиции мы перестали брать наконецто эти все здоровые бандуры зеркалки, с объяективами, штативами, и прочим трехомудьем.
Здравствуйте, Sheridan, Вы писали:
S>В остальных случаях использование докеров — звоночек в некотором тяпляпстве разработчиков. Значит что они не смогли разрулить зависимости и просто запихнули нужное окружение в контейнер.
Так а если я не хочу разруливать зависимости? Просто хочу стабильное окружение, одинаковое при разработке и в проде.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали:
vsb>Типичный скрипт сборки может ссылаться и на версии 3.2.0, которые по сути теги, такие же как :latest, которые так же можно изменить в будущем. Чтобы нельзя было изменить — нужно прописывать хеши, а не ревизии. Но кто это делает (кроме меня, лол).
Тогда и хеши не панацея, подменить может и сложно, а вот удалить соответствующий образ, обломав все — запросто.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, alpha21264, Вы писали:
A>>>>Ничто не мешало Биллигейцу запилить свою реализацию Иксов на своём железе. CC>>>Таки мешало. Потому как SW бизнес и HW бизнес это ОЧЕНЬ разные вещи. A>>При чём здесь это? CC>биллигейц (tm) не делал железо, он делал софт, который должен был работать на том хламе, что есть у юзера.
Ну и? В чём проблема? Вот пусть и работали бы "на том хламе, который есть у Юзера".
Тем более, что сторонние фирмы таки сделали X-клиент, который работал именно на том самом хламе, да ещё и поверх Виндов.
A>> Ты понимаешь, что такое X-Window? Это программа такая. CC>Это протокол для remote graphical user interface CC>Нахрена кому в локальной винде были навороты из зоопарка mainframes?
Здря ты выделяешь слово "remote". Ну да, remote и что?
Кто мешал Билли-Гейцу сделать свою реализацию Xlib хоть с ремоте, хоть без?
Это же просто протокол, по которому программа может иметь графику.
А нужно это для того, чтобы можно было переносить программы туда-сюда.
Не говорите, что это не нужно. Это нужно. Для этого даже Qt написали.
Здравствуйте, alpha21264, Вы писали:
A>Тем более, что сторонние фирмы таки сделали X-клиент, который работал именно на том самом хламе, да ещё и поверх Виндов.
Да на здоровье! МС то нафига было завязываться на иксы и все их болячки?
A>Зря ты выделяешь слово "remote". Ну да, remote и что?
А то, что это сильно ограничивает в том, как можно это всё ускорить, когда remote нафиг не надо.
A>Кто мешал Билли-Гейцу сделать свою реализацию Xlib хоть с ремоте, хоть без?
А зачем? Вот серьёзно, зачем вообще им всрались иксы если можно написать с нуля без всего этого груза легаси?
A>А нужно это для того, чтобы можно было переносить программы туда-сюда.
Им это было совсем не нужно. Им было нужно чтоб проги писали под их ОС, а не переносили туда обратно.
И таки по результатам видим что они всё тогда сделали правильно — выкатили новый API, который работал по факту куда лучше. Сделали упор на поддержку девелоперов и как итог — захватили рынок. Подавляющее большинство клиентского софта писалось под винду. Это потом уже начали просирать старые заслуги.
A>Не говорите, что это не нужно. Это нужно. Для этого даже Qt написали.
И? Всё равно по факту всем насрать, никто перекомпилировать не будет, нужный виндовый софт запускаем в wine.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>В твоей схеме надо P>1 хранить чуть не все возможные версии всех депенденсов
Нет. Ровно только то, что было использовано в билде.
P>2 тратить чудовищное время на билд в силу естественных причин
Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.
P>3 приседать с переменными билда-деплоя каждый раз когда понадобится
Никакой рукопашки, всё это уже должно быть в самом проекте.
P>А капасити опсов по твоему неограничена?
Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?
P> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
Это потому что ты мыслишь только в готовых бинарях.
P>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги
CC>>Ты точно щас про веб? P>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
Удивление?
CC>>А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда? P>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
В этом то и проблема что у тебя никогда нет стабильного билда. И не будет.
Говно и палки, печаль!
P>>>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ? P>Забавно, что ответа от тебя не поступило. Гы!
Ответ был ниже.
CC>>Вы это что, всё врукопашную до сих пор делаете? P>Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.
Да потому что всё это должно работать автоматически.
P>Забавно, что ты не смог ничего выдать про переменные билда. Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз".
Это лютый бардак, говно и палки.
P> Каким чудом собираешься обеспечить идентичность переменных?
Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?
P>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.
Впрочем с подходом "каждый раз тянется зоопарк из интернетов" такую элементарную вещь как повторяемый билд сделать нельзя, да. Ибо никто не знает какое говно скачается в следующий раз.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали:
CC>>Это всё верно, вот только не спасает жеж нифига. Годится для бинарного поиска в каком релизе сломали и в общем то всё. S>Ну, так в основном этого и требуется.
Готовые бинари хранить — да, только для того и нужны. А вот для всего остального надо таки иметь возможность повторить полный билд.
S>Ну так свой-то код, естественно, вы держите со всей историей.
Зависимости этого кода надо держать там же, иначе можно получить "ой" когда выяснится что нужной версии какой нить странной либы больше нигде нету.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>В твоей схеме надо P>>1 хранить чуть не все возможные версии всех депенденсов CC>Нет. Ровно только то, что было использовано в билде.
Ну так билды идут постоянно, и депенденсы обновляются, а раз так, то получаем "чуть не все возможные версии всех депенденсов"
P>>2 тратить чудовищное время на билд в силу естественных причин CC>Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.
Это только один из use case. А когда нужен bisect, необходимость билдовать убивает весь бенефит.
P>>3 приседать с переменными билда-деплоя каждый раз когда понадобится CC>Никакой рукопашки, всё это уже должно быть в самом проекте.
Ну вот есть сотня вариантов сборки-деплоймента. Каким образом будешь выбирать нужный? Будешь собирать всю сотню и тыкать наугад или таки переменную подкидывать?
Кроме того, инфраструктура/сеть в норме меняется постоянно.
1 Твои урлы которые ты вбил в конфиг могут протухнуть по естественным причинам — сервисы депрекейтнулись
2 сертификаты могут так же протухнуть
3 переменные могут стать уже невалидным
4 админы в норме вносят изменения по причинам секюрити, непрерывно, и это время от времени влияет на сборку, тесты, скачивание депенденсов, и даже на работу самих депенденсов. Самый простой пример — приложение теперь должно использовать другой коннекшн стринг к базе. Гы-гы.
Т.е. сеть принципиально а) нестабильна б) постоянно в изменениях. Это из букваря по веб-приложениям.
P>>А капасити опсов по твоему неограничена? CC>Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?
Ты добавляешь дополнительный сервис, который нужно мейнтейнить.
P>> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели. CC>Это потому что ты мыслишь только в готовых бинарях.
Мы здесь про депенденсы. Ты что, собираешься и депенденсы пересобирать?
P>>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев. CC>Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги
Стабильный билд — пусканули пять раз подряд, всё зелено. Но это не гарантирует, что и через погода будет так же. Например, за эти полгода админы точно применять десяток или сотню фиксов секюрити, закроют то или это именно по причинам секюрити.
Например — запретили basic http, а вместо этого oidc client_credentials grant.
Твой билдец накрылся, потому что грейс период был три месяца, а прошло полгода.
CC>>>Ты точно щас про веб? P>>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал CC>Удивление?
Так я вижу. Ты путаешь кейс нативного приложения типа дривер или близко к этому, и веб приложение. Веб приложение как правило распределенное, иначе не бывает. Из букваря мы знаем, что в таком случае есть одна единственная константа — это постоянные изменения в инфраструктуре/сети итд.
Инфраструктура сейчас и полгода назад это две разные инфраструктуры. И далеко не факт, что твой билд-скрипт может работать с любой из них.
P>>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда. CC>В этом то и проблема что у тебя никогда нет стабильного билда. И не будет. CC>Говно и палки, печаль!
Стабильный билд это когда мы пусканули его сейчас раз пять или десять подряд. Зато через полгода, когда админы закрыли basic-http, твой стабильно зеленый билд станет стабильно красным. Ты же по тегу выкачиваешь — а там старая версия которая продолжает слать basic-http а грейс период уже тю-тю.
CC>>>Вы это что, всё врукопашную до сих пор делаете? P>>Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится. CC>Да потому что всё это должно работать автоматически.
Автоматичность не страхует от сбоев. Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)
P>>Забавно, что ты не смог ничего выдать про переменные билда. CC> Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз". CC>Это лютый бардак, говно и палки.
Цитирую себя
Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)
Следствие из этого — все конфиги рано или поздно протухают.
P>> Каким чудом собираешься обеспечить идентичность переменных? CC>Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?
Цитирую себя:
Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)
Следствие из этого — все конфиги рано или поздно протухают.
На новых конфигах приложение работает трохи иначе. Упс!
P>>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать? CC>Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.
Спасибо, капитан! Вот пусканул ты старый билд, а с тех пор админы запретили basic-http, по которому стучится твой билд. Твои действия?
CC>Впрочем с подходом "каждый раз тянется зоопарк из интернетов" такую элементарную вещь как повторяемый билд сделать нельзя, да. Ибо никто не знает какое говно скачается в следующий раз.
Дело даже не в интернетах, сеть в каждой конторе меняется постоянно, инфраструктура — меняется, имена меняются, секюрити фиксы идут непрерывным потоком.
Заюзал ты функцию "скачаю я с локального сервера вон то", а в следующий раз этот локальный сервис скажет "этот запрос со вчерашного дня не секюрный, делай запрос секюрно"
Здравствуйте, CreatorCray, Вы писали:
S>>Ну так свой-то код, естественно, вы держите со всей историей. CC>Зависимости этого кода надо держать там же, иначе можно получить "ой" когда выяснится что нужной версии какой нить странной либы больше нигде нету.
Ты что, собираешься в репу коммитать mysql? бинарниками или в исходном коде ?
Вместо "патч под вон ту версию" выпускаем текущую патч версию, т.е. 3.8.19. Нам нужно гарантировать, что эта патч версия обратно совместима с той, что у юзера (3.8.10).
соответсвенно, у нас есть бранча support/3.8/master и в ней делаем фикс и запускаем обычный билд.
Поэтому все нужные зависимости у нас есть. Если чтото исчезло прямо сейчас — туда ему и дорога. Обновляем зависимости, фиксим, запускаем билд и отдаём юзеру 3.8.19
В релиз нотах указываем "депендеси x обновилась с 7.0.1 на 7.0.9"
Где нам может понадобиться версия — 3.8.10 или 3.8.11 — например, траблшутинг, bisect, итд, что бы люди могли за секунды вернуться на старый/новый вариант
И вот здесь нам нужен артефакт сразу, а не после n часов сборки, приседания "а что же админы поменяли на прошлой неделе"
Хранить все версии промежуточных билдов нам вряд ли нужно, разве что на короткий срок.
Здравствуйте, Sheridan, Вы писали:
S>И как там с гуём?
Гуй не нужен, консолька с командами по 15 строк, и нигде не документированные конфиги в vi — наше все. Ну еще курим маны, от чего глаза краснеют, а мозги студенеют.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
УП>Так а если я не хочу разруливать зависимости? Просто хочу стабильное окружение, одинаковое при разработке и в проде.
Ну так обновляйся раз в месяц-два и будет всё как ты говоришь.
Но вот не было у меня тогда этиъ полчаса.
