| 1.1, Аноним (-), 09:08, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Эта дурная мода на "кружочки" теперь и в презентации переползла, тьфу. Понятное дело, что в могильном интерфейсе круглые кнопки ближе к форме пальцев, но на десктопах выглядит неуместно.
| | |
| |
| 2.3, hoopoe (ok), 09:53, 13/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
 да ладно, по большому счёту покер в какой формы кнопари мышом тыкать... кстати, сейчас большинство ноутов идут с тач экранами, тоже, по сути, почти могильный интерфейс :)
| | |
| |
| 3.17, Аноним (-), 15:38, 13/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
Проще попасть в кнопку большей площади. Площадь прямоугольника больше, чем площадь круга.
Хотя к картинкам в презенташке это никакого отношения не имеет.
| | |
|
|
| 1.2, Аноним (-), 09:50, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
Интересно, это мода (помешательство, одержимость) докеризировать всё, что (шевелится :)) докеризируется или в этом есть реальный смысл и необходимость? В каких проектах такое может понадобится, что аж даже "Всё остальное, включая udev, dhcp, ntp, cloud-init и rsyslog, запускается внутри отдельных системных контейнеров" ?
| | |
| |
| 2.4, Аноним (-), 09:56, 13/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
IMHO, баловство всё это и оправдано только если а контейнере нет доступа с правами root. Если в контейнере есть возможность выполнить код под root, то создаётся лишь видимость защиты. Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.
| | |
| |
| 3.6, J.L. (?), 10:51, 13/04/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Особенно радует user namespace для которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере подняться до полноценного root на стороне хост-системы.
так нашли же и пофиксили
или нашлись какие-то концептуальные архитектурные уязвимости ?
| | |
| |
| 4.22, derlafff (ok), 08:28, 14/04/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Проблема не в концептуальных архитектурных уязвимостях, проблема в том, что весь ядерный код писался без оглядки на эти самые user namespaces. Поэтому, пока коды нормально не перечитают, подобные уязвимости продолжат появляться довольно часто. Т.е. еще несколько лет -- точно.
| | |
|
| 3.9, Аноним (-), 11:33, 13/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> IMHO, баловство всё это и оправдано только если а контейнере нет доступа
> с правами root. Если в контейнере есть возможность выполнить код под
> root, то создаётся лишь видимость защиты. Особенно радует user namespace для
> которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
> подняться до полноценного root на стороне хост-системы.
Так ограничьте права. И не запускайте что не попадя от root
| | |
| |
| 4.14, J.L. (?), 13:22, 13/04/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> IMHO, баловство всё это и оправдано только если а контейнере нет доступа
>> с правами root. Если в контейнере есть возможность выполнить код под
>> root, то создаётся лишь видимость защиты. Особенно радует user namespace для
>> которого уже нашли с десяток уязвимостей позволяющих от "псевдорута" в контейнере
>> подняться до полноценного root на стороне хост-системы.
> Так ограничьте права. И не запускайте что не попадя от root
контейнер к вам может попасть через жирный_пакет какой нить "как есть", с настройками контейнерного рута внутри
| | |
|
|
| 2.7, VoDA (ok), 11:19, 13/04/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Смысл в том, что контейнер в котором разработано приложение и запускается пользователем.
Вместе с приложением максимально переносится окружение.
Это позволяет избежать части багов появляющихся из-за разности в конфигурациях dev и prod.
| | |
| |
| |
| 4.11, VoDA (ok), 12:03, 13/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Главный фактор - это лень.
Лень чинить баги - правильный фактов. Заставляет заранее снижать их количество ;)
| | |
|
|
| 2.8, VoDA (ok), 11:20, 13/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Минорный плюс - контейнеры stateless. Для серверных приложений это позволяет динамически расширять и сжимать боевой кластер прямо на ходу.
| | |
|
| 1.15, theoneandonly (?), 13:36, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации
heretics!
| | |
| |
| 2.18, J.L. (?), 16:18, 13/04/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> отличаясь от них отказом от системного менеджера systemd в пользу собственной системы инициализации
> heretics!
killing it by fire!!!!
| | |
|
| 1.20, Петр Ильин (?), 21:35, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Это опять процессоры слишком мощные и памяти завались?
Т.е. сейчас все будет даже ls в контейнерахзапускаться? Модно типа?
А потом сделают контейнер на уровне CPU
| | |
| |
| 2.21, Аноним (-), 07:29, 14/04/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Это опять процессоры слишком мощные и памяти завались?
Процессоры и память не причём, это к виртуализации.
Основной смысл современных систем управления о оркестровки - разорвать зависимость от локального хоста и запускать приложение на кластере, так же просто, как сейчас запускаем приложение на процессоре с несколькими ядрами.
http://web.eecs.umich.edu/~mosharaf/Readings/DC-Computer.pdf
https://youtu.be/CESGogWbjeI
ОС и системные сервисы, это просто среда и транспорт: https://youtu.be/HhNIttd87xs
Полезную работу делают приложения.
ls как таковой не нужен в качестве приложения и смысла его в контейнере запускать нет.
Другое дело, что ls работает с файловой системой и если у нас в кластере несколько распределённых файловых систем, то может быть удобно просматривать списки файлов в каталогах запуская команду ls в контейнере, который запущен в группе с настроенной файловой системой. Запускаться этот ls может как внутри существующего контейнера, так и в отдельном (это задача обслуживания, а не реальной работы приложения, поэтому не так важно где).
> А потом сделают контейнер на уровне CPU
http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf
Есть наработки с тегированной памятью, но это ближе к системам типа selinux.
Уроверь CPU как раз слишком низкий, нужен уровень нескольких вычислительных узлов. Времена, когда в стойку влезает несколько тысяч ядер/компьютеров уже наступили и одним локалхостом не обойтись.
| | |
|
| |
| 2.25, JL2001 (ok), 16:55, 19/04/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Лучше бы микроядра пилили.
нужно и то и сабж (и не факт что нужно вместе, но кому как)
| | |
|
|
