The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект CoreOS представил Rocket, конкурирующий с Docker инструментарий управления контейнерами

01.12.2014 22:00

Проект CoreOS, развивающий основанное идеях контейнерной изоляции серверное окружение, анонсировал создание нового инструментария для управления созданием, запуском и выполнением изолированных контейнеров - Rocket, выступающего в качестве более безопасной, переносимой и адаптированной для серверного применения альтернативы Docker. Rocket нацелен на манипуляцию контейнерами, построенными в соответствии со спецификацией App Container, также предложенной проектом CoreOS и нацеленной на создание универсального переносимого формата контейнеров.

Наиболее существенные отличия Rocket от Docker заключаются в использовании иной модели выполнения, позволяющей достигнуть значительно более высокого уровня защищённости. В Docker все операции проводятся с участием одного централизованного фонового процесса, что создаёт серьезные потенциальные проблемы с безопасностью, устранить которые можно лишь путём полной переработки организации работы. Также утверждается, что последнее время Docker отклонился от первоначальных задач и стал развивать функции, выходящие за рамки средств управления контейнерами, превращаясь в излишне усложнённую платформу.

Rocket сосредоточен только на управлении контейнерами и обеспечении их максимальной переносимости. В Rocket применяется многоуровневая модульная архитектура, разделяющая операции работы с контейнером, на отдельные стадии, отдельно обрабатывающие этапы настройки файловой системы, подготовки исполняемого окружения и запуска приложений в контейнере. Кроме безопасности подобный подход также позволяет добиться хорошей расширяемости за счёт возможности реализации дополнительных функций через подключение дополнений.

Выделяются три основные стадии запуска контейнера:

  • Нулевая стадия, обработка которой производится силами утилиты rkt без привлечения дополнительных средств. На данной стадии производится начальная подготовка контейнера: генерация UUID и манифеста, создания файловой системы для контейнера, настройка директорий для выполнения следующих стадий, копирование исполняемого файла первой стадии в ФС контейнера, извлечение заданных ACI (App Container Image), распаковка образов и копирование приложений в директории третьей стадии;
  • Первая стадия, работа которой обеспечивается отдельным исполняемым файлом, имеющим полномочия настройки cgroups, запуска процессов и выполнения операций под пользователем root. На данной стадии осуществляется создание исполняемой группы на основе ФС, подготовленной в нулевой стадии, установка cgroups, пространств имён и точек монтирования. Настройка производится через генерацию unit-файлов systemd и использование systemd-nspawn для организации работы окружения;
  • Вторая стадия, на которой производится непосредственный запуск приложения в подготовленном контейнере. В частности, на данной стадии выполняется процесс инициализации содержимого контейнера, описанный в манифесте запуска приложения (Application Manifest).

Основные компоненты Rocket:

  • App Container Image - определяет образ, содержащий все необходимые элементы для запуска контейнера приложения. Для защиты применяется проверка по цифровой подписи и опционально шифрование, что позволяет использовать для распространения образов публичные сети хранения и BitTorrent;
  • App Container Runtime - определяет окружение для запуска контейнера приложения;
  • App Container Discovery - федеративный протокол для поиска и загрузки образов контейнеров приложений.

Для создания контейнеров и организации их изолированного выполнения применяются те же штатные механизмы ядра Linux, что в Docker - пространства имён (namespaces) и группы управления (cgroups). При этом, для управления контейнером используются средства запуска изолированных окружений, предоставляемые системным менеджером systemd. Для управления предложена новая консольная утилита rkt, предоставляющая набор команд, похожий на docker. Как и Docker, код Rocket написан на языке Go и поставляется под лицензией Apache 2.0.

Следование универсальной спецификации App Container, определяющей окружающие контейнер службы, позволяет создавать независимые собственные реализации, совместимые с Rocket. Более того, в будущем, когда App Container достигнет зрелости, планируется подготовить реализацию данной спецификации для Docker, что позволит обеспечить переносимость обоих проектов.

  1. Главная ссылка к новости (https://coreos.com/blog/rocket...)
  2. OpenNews: Первый стабильный выпуск серверной Linux-системы CoreOS
  3. OpenNews: Red Hat представил Atomic, концепцию модульной ОС на базе изолированных контейнеров
  4. OpenNews: Выпуск cистемы управления контейнерной виртуализацией Docker 1.3
  5. OpenNews: Canonical и Docker развивают LXD, гипервизор для изолированных контейнеров (дополнено)
  6. OpenNews: Обновление Docker 1.3.2 с устранением критических уязвимостей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41168-coreos
Ключевые слова: coreos, roket
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (78) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:20, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну и кто кого уже? :)
     
     
  • 2.3, Аноним (-), 22:38, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных дистрах, все позиционируются как безопасные и переносимые в отличии друг от друга.
     
     
  • 3.5, Bizdelnick (?), 22:47, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных
    > дистрах, все позиционируются как безопасные и переносимые в отличии друг от
    > друга.

    Ага.

    % aptitude versions docker.io
    Пакет docker.io:                                      
    p   1.3.1~dfsg1-2                                      testing                         400
    p   1.3.2~dfsg1-1                                      unstable                        200

     
  • 3.7, Аноним (-), 23:17, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Хрен их разберет. Куча систем, ни одна нормально не поддерживается в популярных дистрах

    На презентации RH7 Тоттон больше получаса распинался о полной коммерческой поддержке докера.
    Тоттон  https://www.linkedin.com/pub/jim-totton/13/a58/b9b
    С марта сертификация есть конкретно по докеру.
    In March, Red Hat announced certification for containerised applications, with Docker as a primary supported container format.

     
  • 3.14, Michael Shigorin (ok), 00:11, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > все позиционируются как безопасные

    docker изначально почему-то не вызывал особого доверия, а стопка детских дырок это ощущение превратила в уверенность, что это не те люди.

    > и переносимые в отличии друг от друга.

     
     
  • 4.21, Аноним (-), 06:11, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я думал на GO можно писать без дырок.
     
     
  • 5.34, Xaionaro (ok), 08:28, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Я думал на GO можно писать без дырок.

    Я бы скорее сказал, что на всём можно писать с дырками.

     

  • 1.2, th3m3 (ok), 22:37, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Реально то какая польза от всех этих докеров? Я почитал про эти контейнеры. Сплошные ограничения. Даже ssh нельзя. Ограничивать себя, непонятно зачем.
    Так сказать, традиционный подход к развёртыванию приложений - более надёжен.
     
     
  • 2.6, Аноним (-), 23:05, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Я почитал про эти контейнеры.

    Вы в конце 2014 года узнали о контейнерах?
    >Так сказать, традиционный подход к развёртыванию приложений - более надёжен.

    Так сказать, после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys. Поэтому каждый 50-тый сервер (на гугл ИО приводили такие цифры) работает не на своего владельца, а рассылает спам.

     
     
  • 3.9, vitalif (ok), 23:32, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну для борьбы с этим, положим, контейнеры - overkill, обычного чрута достаточно...

    В общем и контейнеры в их текущем виде, когда root в контейнере == root во всей системе - это просто chroot на стероидах, и толку от них большого нет.

     
     
  • 4.11, Аноним (-), 23:45, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы знаете модное слово overkill, но не знаете что с точки зрения безопасности chroot бесполезен? lmgtfy://Breaking Out of a Chroot
     
     
  • 5.16, Michael Shigorin (ok), 00:13, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Вы знаете модное слово overkill, но не знаете что с точки зрения
    > безопасности chroot бесполезен? lmgtfy://Breaking Out of a Chroot

    Не бесполезен, но рута в чруте лучше считать эквивалентом рута в хосте.

    Как выражается альтовский security officer, "хороший чрут -- пустой read-only чрут" :)

     
  • 5.24, Аноним (-), 07:32, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Почему админы в РФ упорто считают срадствами безопасной изоляции, то средства ви... большой текст свёрнут, показать
     
     
  • 6.30, Аноним (-), 08:12, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Правильно настроеный chroot гарантирует безопасную изоляцию процессов!!!
    >гарантирует безопасную

    Гарантирует что атакующий не сможет исчерпать всю память или файловые дескрипторы или fs inode, вызвав, по меньшей, мере DoS?


     
     
  • 7.37, grec (?), 09:37, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    RES_CPU - CPU time in milliseconds RES_FSIZE - Maximum file size in by... большой текст свёрнут, показать
     
  • 6.39, Аноним (-), 09:45, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Chroot was never supposed to be used as a security mechanism - Alan Cox

    chroot
    Разработан в 1982
    Изоляция ФС - частичная
    Copy on write - нет
    Дисковые квоты - нет
    Ограничение I/0 rate - нет
    Ограничение потребления памяти - нет
    Ограничение потребление CPU - нет
    Изоляция сетевого стека - нет
    Сохранение состояния и миграция - нет
    http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualization

    Если в этом треде отписываются реальные админы я не удивлен что каждый 50 сервер взломан.

     
     
  • 7.41, Аноним (-), 09:47, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualization
    парсер лох
     
  • 7.44, anonymous (??), 09:58, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >[оверквотинг удален]
    > Copy on write - нет
    > Дисковые квоты - нет
    > Ограничение I/0 rate - нет
    > Ограничение потребления памяти - нет
    > Ограничение потребление CPU - нет
    > Изоляция сетевого стека - нет
    > Сохранение состояния и миграция - нет
    > http://en.wikipedia.org/wiki/Operating_systemБ─⌠level_virtualization
    > Если в этом треде отписываются реальные админы я не удивлен что каждый
    > 50 сервер взломан.

    Посмотрите посты выше. Большая часть этих механизмов в chroot уже реализована.

     
     
  • 8.46, Аноним (-), 10:09, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не вижу Покажите ... текст свёрнут, показать
     
  • 5.64, vitalif (ok), 15:37, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это под рутом. Но имея рута, ты вылезешь и из LXC. А без рута ты и chroot не покинешь.
     
  • 4.12, Аноним (-), 23:48, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать спам.


     
     
  • 5.25, Аноним (-), 07:38, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать
    > спам.

    Правильной настройкой iptables.

     
     
  • 6.56, Аноним (-), 11:07, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Я верю что с помощью большого количества костылей можно превратить детскую коляску в танк, но зачем? Есть же готовые решения.
     
  • 5.65, vitalif (ok), 15:39, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Особенно интересно узнать как chroot помешает атакующему открыть 25/110/etc порты и рассылать спам.

    Что значит "открыть"? Как "открытие" поможет рассылке спама? И как к спаму вообще относится 110?

     
  • 4.15, Michael Shigorin (ok), 00:12, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну для борьбы с этим, положим, контейнеры - overkill, обычного чрута достаточно...

    chroot -- не средство безопасности.

    > В общем и контейнеры в их текущем виде, когда root в контейнере == root во всей системе

    Как минимум в openvz это сильно не так.

     
     
  • 5.23, Аноним (-), 06:41, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > chroot -- не средство безопасности.

    А что тогда?

     
     
  • 6.26, Аноним (-), 07:42, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> chroot -- не средство безопасности.
    > А что тогда?

    https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configura

    Chroot это специально разработаное экспертами в области безопасности средство изоляции процесов!!!

    Виртуализация, контейнеры разрабатывались людьми далёкими от безопасности и больше для решения задач администрирования.

     
     
  • 7.29, Xaionaro (ok), 08:11, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не понял я, это был сарказм или вы серьёзно, но на всякий случай отвечу Если вы... большой текст свёрнут, показать
     
     
  • 8.50, Аноним (-), 10:40, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это слёзы Укреплённые технологии chroot и jail сегодня дают больше гарантий б... текст свёрнут, показать
     
     
  • 9.52, Аноним (-), 10:47, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОСТАВЛЯЕТСЯ КАК ЕСТЬ ЕЕ ПОСТАВЩИКИ ОТКАЗЫВАЮТСЯ ОТ ВС... текст свёрнут, показать
     
  • 8.58, bOOster (ok), 11:47, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    И все эти костыли в купе еще современные плюшки как то виртуализация IP стека ... текст свёрнут, показать
     
  • 7.35, Аноним (-), 09:16, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >en.wikibooks.org/wiki/Grsecurity

    При чем тут grsecurity? Это совершенно независимый набор патчей затыкающих кучку потенциальных дыр и уязвимостей, в том числе и в chroot.
    https://grsecurity.net/
    У вас есть статистика по его использованию? 100%?

     
     
  • 8.42, grec (?), 09:53, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Причем тут независимость Разговор не об этом, а об контейнерах vs grsec selinux... текст свёрнут, показать
     
     
  • 9.43, Xaionaro (ok), 09:57, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В контейнерной виртуализации вас никто не ограничивает в применяемых технологиях... текст свёрнут, показать
     
     
  • 10.47, Аноним (-), 10:20, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Большинство так и делает grsec виртуализация grsec RBAC grsec chroot ... текст свёрнут, показать
     
     
  • 11.48, Аноним (-), 10:25, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только для домашнего использования ... текст свёрнут, показать
     
     
  • 12.51, Аноним (-), 10:44, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http www opennet ru openforum vsluhforumID3 100446 html 50 ... текст свёрнут, показать
     
     
  • 13.54, Аноним (-), 10:56, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильно настроеный chroot гарантирует безопасную изоляцию процессов -Аноним... текст свёрнут, показать
     
     
  • 14.57, Аноним (-), 11:29, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но он же три восклицательных знака ... текст свёрнут, показать
     
  • 11.76, Xaionaro (ok), 10:40, 03/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    IMHO, очень странная у вас выборка, если в ней большинство использует grsec ... текст свёрнут, показать
     
  • 9.45, Аноним (-), 10:06, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Где Я вижу только Что полная чушь Почему vs Why not both не вижу ничего что... текст свёрнут, показать
     
     
  • 10.53, Аноним (-), 10:54, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    man limits conf man ulimit grsec Dec 2 10 00 03 xxxxx kernel grsec deni... текст свёрнут, показать
     
     
  • 11.55, Аноним (-), 11:05, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ты видишь тут ulimit Нет А он есть Why not cgroups LXC docker cgroup... текст свёрнут, показать
     
  • 6.27, Xaionaro (ok), 08:00, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> chroot -- не средство безопасности.
    > А что тогда?

    Это средство для смены корневой директории (не безвозвратно). IIRC, изначально создавалось и использовалось для работы с тестовыми окружениями (для проверки процессов сборки и установки).

     
  • 6.49, Аноним (-), 10:31, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    chroot это средство безопасности. В той же мере как носок средство контрацепции.
     
  • 5.66, vitalif (ok), 15:40, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как минимум в openvz это сильно не так.

    Вот именно - в OpenVZ-то это не так, а в LXC именно так.

     
  • 3.18, th3m3 (ok), 03:15, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю? Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного там нет. Оказалось, что можно жить как и прежде, без всяких контейнеров. А с ними будут только новые проблемы, которые нужно будет решать. Нет смысла время тратить зря. Во всяком случае в таком виде, в каком они сейчас - мне не нужно.
     
     
  • 4.32, Xaionaro (ok), 08:17, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю?
    > Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного
    > там нет. Оказалось, что можно жить как и прежде, без всяких
    > контейнеров. А с ними будут только новые проблемы, которые нужно будет
    > решать. Нет смысла время тратить зря. Во всяком случае в таком
    > виде, в каком они сейчас - мне не нужно.

    А что вы используете для изоляции окружений? Гипервизорные виртуальные системы? Или просто голый chroot?

     
  • 4.33, Аноним (-), 08:19, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да, в 2014 году прочитал. Подумал, мало ли, может я чего-то упускаю?
    > Что-то модное и проходит мимо меня. Выяснил, что ничего особо революционного
    > там нет. Оказалось, что можно жить как и прежде, без всяких
    > контейнеров. А с ними будут только новые проблемы, которые нужно будет
    > решать. Нет смысла время тратить зря. Во всяком случае в таком
    > виде, в каком они сейчас - мне не нужно.

    Замените 2014 на 1914 и вы получите типичные рассуждения интеллигенции начала века о электричестве

     
     
  • 5.69, cmp (ok), 16:22, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А замените 2014 на 2004, контейнеры на ява, и смысл сохранится, или если хотите больших масшатабов на временной шкале, вспомните сверхзвуковую гражданскую авиацию, или сверхтяжелые танки, или непотопляемый титаник, или любой другой "проект" который в масштабах истории оказался пшиком, и которых было гораздо больше, чем "стрельнувших".

    В системе должна быть некая песочница, чтобы можно было там всякое запускать без риска порушить систему, но глобального баланса между "конкретной копией процесса", "ОС" и "ограниченными аппаратными ресурсами" эти контейнеры не решают, то есть решают добавляя еще одну прослойку, но если _не_ рассматривать ее как часть ОС, но тогда это уйдет в ресурсы, то есть каждому контейнеру своя копия либы, свой корень.. ну так или иначе переопределение ОС и исполняемого формата. Будет у вас не elf исполняемым, а zip в котором лежит elf, либы, катинки, все подряд, вон на андроиде почти так и есть, только виртуализация на уровне явы, которую 10 лет назад обещали сделать надежнее, избавить нас от утечек памяти, блаблабла))

    Только тут go, не асилили копирование файлов и монтирование на си)).

     
  • 3.22, Аноним (-), 06:39, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Так сказать, после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys.
    > SQL-инъекция
    > читать/писать ФС

    ЩИТО?

     
     
  • 4.28, Аноним (-), 08:07, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    MySQL SQL Injection Cheat Sheet
    ...UNION ALL SELECT LOAD_FILE(‘/etc/passwd’)
    SELECT * FROM mytable INTO dumpfile ‘/.../file’;
    Не?
     
  • 3.72, Typhoon (ok), 22:34, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > после первой успешной SQL инъекции атакующий может читать, а иногда и писать по всей фс включая .ssh/authorized_keys.

    бред

     

  • 1.4, Bizdelnick (?), 22:43, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Этого следовало ожидать. Docker прибит гвоздями к их инфраструктуре, а это не может всех устраивать. Есть, правда, опасения, что и с этим Rocket будет то же самое, только с привязкой к другому вендору, но рано или поздно кто-нибудь положит этому конец. Так что конкуренция здесь - однозначно позитивное явление.
     
  • 1.8, Аноним (-), 23:22, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Переносимость и завязанность на systemd как-то противоречат друг лругу.
     
     
  • 2.40, Аноним (-), 09:47, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Переносимость и завязанность на linux как-то противоречат друг другу
     
     
  • 3.67, Аноним (-), 16:03, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Совершенно никак. Ни капельки.
     

  • 1.20, Бутират (?), 05:50, 02/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что за идиотская традиция писать системные утилиты на Go
     
     
  • 2.31, Xaionaro (ok), 08:15, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что за идиотская традиция писать системные утилиты на Go

    А вы пробовали этот go [1, 2]? IMHO, он намного лучше подходит для системных задач, чем python или perl, которые уже давно в моде в данной области.

    [1] http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=threadring&la
    [2] http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=spectralnorm&

     
     
  • 3.59, anonymous (??), 12:33, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1) perl
    появился для автоматизации обработки текста
    позволяет легко прочитать файл/stdin, сделать преобразования (в первую очередь текстовые) в несколько строчек (максимум - несколько десятков) и вывести результаты, в этой нише (весьма узкой, к слову) - вне конкуренции
    что-то большое писать противопоказано, код очень слабо читаем
    интерпретируем (не требует компиляции, переносим между платформами)
    популярность в администрировании во многом обрел из-за того что исторически появился первым более-менее подходящим

    2) python
    приятный синтаксис, очень лаконичный, хорошо читаем
    оптимален для небольших проектов (на любую тему - тяжело что-то найти, на чем можно накалякать быстрее и элегантней) да и для средних проектов своего класса (где не критично быстродействие, не нужны навороченные ооп возможности, да и в целом динамическая типизация не под ынтерпрайз)
    также интерпретируем (уже удар по быстродействию), только формальная многопоточность (фактически интерпретатор всё выполняет в один поток), т.е. если что критическое к скорости выполнения и пишут, то только с обильными с/c++ вставками (интеграция в языке на уровне)

    3) go
    это ж что-то как понимаю С-подобное - на замену (до недавнего времени считалось, что альтернативы С в системном программировании вообще нету), а это совершенно другой класс языков
    ну тут да, системный софт писать самое то, но администрировать на нем в принципе невозможно (ведь ещё и скомпилить надо перед тем как запускать, и кода в исполняемом файле не видно, представьте что всеми любимые bash-простыни в init-e заменят на бинари)

    иначе говоря, разработчики если и выбирали, то скорее между с/с++ и go, python на мой вкус может и хорош, но область его применения похоже несколько другая

     
     
  • 4.61, csdoc (ok), 13:11, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > 3) go
    > это ж что-то как понимаю С-подобное - на замену (до недавнего времени
    > считалось, что альтернативы С в системном программировании вообще нету), а это
    > совершенно другой класс языков
    > ну тут да, системный софт писать самое то, но администрировать на нем
    > в принципе невозможно (ведь ещё и скомпилить надо перед тем как
    > запускать, и кода в исполняемом файле не видно, представьте что всеми
    > любимые bash-простыни в init-e заменят на бинари)

    при желании - можно писать скрипты на Go: https://wiki.ubuntu.com/gorun

     
     
  • 5.63, anonymous (??), 15:32, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    неужели так все просто
    в С/С++ уже целую пачку систем сборок понаписывали (autotools, cmake, scons, ..), чтобы компилять на различных платформах/дистрибутивах
     
     
  • 6.84, prostoqw (?), 09:48, 08/05/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да, просто.
    Именно для этого Go и проектировался.
    Чтобы все было просто - крайне быстрая компиляция безо всяких configure и cmake с самыми минимальными завязками на конкретную платформу (разумеется, если вы в коде зашьете "C:\mydir\myfile" то это вы САМИ завязались на Win). Язык имеет всего лишь пару-тройку ограничений по платформе. Например, syslog из коробки не работает с Win и MacOSX.
     
  • 4.68, vitalif (ok), 16:12, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1) perl код очень слабо читаем

    МИФ. Читаемость вода - вопрос криворукости, а не перла. Хотя говнокода на перле понаписано прилично, конечно. Но будем честны, не на нём одном.

    2) python приятный синтаксис

    ога, только всем кто на C писал противопоказан, потому что от форматирования блоков отступами вместо { } блевать будут

    и типизация странная - недодинамическая, например строка+число не конкатенируется

    и всяких стандартно-полезных для веба фич из коробки (как в php) нет

     
     
  • 5.70, anonymous (??), 17:17, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Читаемость кода - вопрос криворукости

    во многом это так
    проблема в том, что в перле присутсвуют экстравагантные возможности, с которыми естественно перебирают

    >ога, только всем кто на C писал противопоказан, потому что от форматирования блоков отступами вместо { } блевать будут

    после джавы в качестве разнообразия мне наоборот только понравилось, а ещё больше понравилось, что кода в 2 раза меньше становится

    >и типизация странная - недодинамическая, например строка+число не конкатенируется

    разве это необходимое условие динамической типизации?
    мне кажется так было сделано умышленно, чтоб побыстрее ошибки отлавливать

    >и всяких стандартно-полезных для веба фич из коробки (как в php) нет

    мне ещё тех же встроенных в синтаксис регулярных выражений не хватает, а также возможности получать результат внешних команд и тп не очень удобно
    с точки зрения администрирования конечно минус
    видать питон позиционируют как язык общего назвачения без каких-то компромиссов и все тут


     
  • 5.71, Ordu (ok), 19:40, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > и типизация странная - недодинамическая, например строка+число не конкатенируется

    Не путайте приведение типов и динамичность типизации. Динамическая типизация тоже может быть строгой. Построже чем в C, который числовые типы приводит один к другому даже не считая это заслуживающим упоминания, а если попросить по хорошему, то и int к void* и обратно приведёт неявно. Правда тут, надо отметить, он всё же варнинг кинет.

    Да, я не спорю, тут много путаницы -- статическая/динамическая типизация, неявное приведение типов, перегрузка функций/операторов (built-in или на стороне юзера, как в C++) -- всё это сбивает с толку. Но вы как-нибудь на досуге сядьте и подумайте такую мысль: статическая типизация -- это когда типизированы идентификаторы (переменные, имена функций...), динамическая типизация -- это когда типизированы значения (то есть когда заглянув в рандомное место памяти, вы можете отличить значение типа int от значения типа unsigned int, не глядя в код, работающий с этими значениями). 10 минут переваривания этой мысли в голове будет достаточно, для окончательного и бесповоротного избавления от бардака в голове на эту тему.

     
     
  • 6.73, vitalif (ok), 01:01, 03/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да слышал я это, понты это гнилые, про "строгую" динамическую типизацию. Она строгая только в таких вот маразмах со строками. С объектами например всё точно то же что в других скриптовых языках. Нет проверок типов параметров функций. Какая тут нафиг строгая типизация может быть? Маркетинг только)
     
  • 6.74, vitalif (ok), 02:41, 03/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    т.е. если "строгая типизация" = "отсутствие любых неявных преобразований типов" - чего это даёт в динамическом языке, кроме неудобства - непонятно.
     
     
  • 7.77, Ordu (ok), 18:56, 03/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > т.е. если "строгая типизация" = "отсутствие любых неявных преобразований типов" - чего
    > это даёт в динамическом языке, кроме неудобства - непонятно.

    Ах пичаль-пичаль... Непонятно... Ознакомьтесь с каким-нибудь ЯП отличным от пэхапэ/пайтон. Лучше, не насилуя мозги, сразу с lisp'ом. Есть шансы, что поможет. Ну а если нет, то просто признайтесь, что программирование -- это не ваша стихия и смените место работы.

     
     
  • 8.78, vitalif (ok), 22:34, 05/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты на личности-то на переходи Лучше по существу скажи чо-нить ... текст свёрнут, показать
     
     
  • 9.79, Ordu (ok), 22:54, 05/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Что именно тебе сказать Ссылку кинуть на учебник по лиспу Гугл подойдёт, в кач... текст свёрнут, показать
     
     
  • 10.80, vitalif (ok), 23:34, 06/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты что ли серьёзно думаешь, что я на C и C не писал По существу - это какие р... текст свёрнут, показать
     
     
  • 11.81, Ordu (ok), 00:33, 07/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А какое это имеет отношение к динамической типизации Но вообще, я не думаю, что... текст свёрнут, показать
     
     
  • 12.82, vitalif (ok), 00:31, 08/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, а то, что объект любого класса можно использовать как объект любого класса,... текст свёрнут, показать
     
     
  • 13.83, Ordu (ok), 01:15, 08/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Противоречит, наверное Я хз, но это уже нерелевантные терминологические игрища ... текст свёрнут, показать
     
  • 2.36, Аноним (-), 09:29, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Что за идиотская традиция писать системные утилиты на Go

    Никто не хочет второго #Heartbleed

     

  • 1.38, Cotan (ok), 09:41, 02/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    У Докера бабахнуло http://blog.docker.com/2014/12/initial-thoughts-on-the-rocket-announcement/
     
  • 1.62, Аноним (-), 13:22, 02/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Зоопарк, когда уже порядок наведут?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру