Здравствуйте, 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>есть ещо окружение, за которым тоже надо следить и своевременно обновлять.
Докер это не запрещает, а упрощает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
