Я ничего не хочу доказать, я свои ощущения описал.
Я считаю что это странно и показывает определенного рода беспомощность современной MS.
Я был бы рад если бы они сделали полноценный порт Visual Studio, как это прекрасно удается им с Office.
Контейнер Atom — ну это как в свое время Internet Explorer был по сути оболочкой для запуска ActiveX реализующего браузер :-) Ну т.е. можно конечно говорить что это «всего лишь платформа», но понятно же что Atom разделен на платформу и конкретный редактор для удобства разработки, нельзя же «платформу» заменить. Я думаю там в платформе 90% фич редактора.
Просто это несерьезно для такой компании как MS брать готовую платформу, чуть припудрить ее и назвать Visual Studio Core.
Отличия от Atom на мой взгляд на уровне «сборок» Emacs — но никто же обычно не говорит что представляет соверешенно новый редактор, просто на платформе Emacs :)
Я лично ожидал увидеть частично портированный Visual Studio, как произошло например со свежим Office 2016 для Mac. А увидел Sublime-переросток на платформе Atom.
Contents/MacOS/Atom — бинарник для запуска
Contents/Frameworks/AtomFramework.framework — фреймворк от атома
Форкнули то может и форкнули, но это как-то мелко для MS. Ну опубликовали бы как форк. Но зачем это называть VisualStudio Core. Так могла бы называться какая-то ограниченная в возможностях VisualStudio, но не форк OpenSource редактора.
А как ситуация с протезом пластины будет развиваться дальше, с ростом ребенка?
Ее придется периодически заменять или рост черепа будет происходить нормально?
openvz это все-же больше «виртуалки» на базе контейнеров. А docker — это упаковка отдельных приложений и запуск их в контейнерах, причем с уклоном в immutable контейнеры.
Весь смысл в том, что это и так нужно в системе для работы приложения.
А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.
Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
Образ убунты для докера — 200 мегов.
И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
Так что не понятно, какие ресурсы может использовать контейнер сами по себе.
Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
В unix такой проблемы нет, shell-скрипты могут быть полноценными программами (не без огороворок, но простейшее скачивание файлов делается элементарно). Потребление памяти для скриптов, запускаемых редко — вообще не проблема.
P.S. ссылку на википедию хабр не ест, легко гуглиться по «грамматика, разбирающая выражение».
Подобные задачи вообще решаются в курсе теории алгоритмов как пример использования формальных грамматик.
Я считаю что это странно и показывает определенного рода беспомощность современной MS.
Я был бы рад если бы они сделали полноценный порт Visual Studio, как это прекрасно удается им с Office.
Контейнер Atom — ну это как в свое время Internet Explorer был по сути оболочкой для запуска ActiveX реализующего браузер :-) Ну т.е. можно конечно говорить что это «всего лишь платформа», но понятно же что Atom разделен на платформу и конкретный редактор для удобства разработки, нельзя же «платформу» заменить. Я думаю там в платформе 90% фич редактора.
Просто это несерьезно для такой компании как MS брать готовую платформу, чуть припудрить ее и назвать Visual Studio Core.
Отличия от Atom на мой взгляд на уровне «сборок» Emacs — но никто же обычно не говорит что представляет соверешенно новый редактор, просто на платформе Emacs :)
Я лично ожидал увидеть частично портированный Visual Studio, как произошло например со свежим Office 2016 для Mac. А увидел Sublime-переросток на платформе Atom.
Sublime прежде всего редактор, а VS — именно что IDE
Contents/MacOS/Atom — бинарник для запуска
Contents/Frameworks/AtomFramework.framework — фреймворк от атома
Форкнули то может и форкнули, но это как-то мелко для MS. Ну опубликовали бы как форк. Но зачем это называть VisualStudio Core. Так могла бы называться какая-то ограниченная в возможностях VisualStudio, но не форк OpenSource редактора.
Под OSX даже исполнимый файл называется «Atom»
Ее придется периодически заменять или рост черепа будет происходить нормально?
Связка постоянно меняется — отлично — делаем кучу контейнеров и экспериментируем.
Запуск пачки можно делать обычным bash-скриптом, что тут сложного — даже полезно.
Ну и docker-compose (бывший fig) позволяет собирать связки легко и просто. Я лично использую make-файлы, make run и все :-)
А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.
Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
Это же ваше приложение, оно будет так-же стартовать и вне контейнера.
Смысл «легкости» докера в том что оверхед минимален, в практической жизни — незаметен.
И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
Так что не понятно, какие ресурсы может использовать контейнер сами по себе.
Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
В unix такой проблемы нет, shell-скрипты могут быть полноценными программами (не без огороворок, но простейшее скачивание файлов делается элементарно). Потребление памяти для скриптов, запускаемых редко — вообще не проблема.
Извините, если вам кажется будто вопросы простые и очевидные.
Я вот навскидку могу предложить по десятку аргументов за и против загрузки одинаковых прайсов от разных поставщиков.