Как стать автором
Обновить

Комментарии 390

Даешь Kubernetes на FreeBSD!
Было бы просто прекрасно.
Обожаю эту ось, к сожалению они уступили линуксу на волне хайпа и не смогли в виртуализацию(bhyve и jail только).
Да пожалуйста!
www.bsdnow.tv/337
НЛО прилетело и опубликовало эту надпись здесь
Как появится работающий апдейтер — позовите меня.
Есть более короткий формат:
image
Если коротко:
— FreeBSD: гораздо лучше GNU/Linux
— чем лучше?
— чем GNU/Linux…
Будьте добры скрыть это в черновики и подготовить более основательное сравнение, без субъективной оценки. Плашка «далее написанное — мое личное мнение» не помогает, особенно в статье на тему «мои фломастеры более вкусные, чем другие».
BSD: Уже 12+ лет имеет надёжную работающую ZFS реализацию.

Linux: До сих пор production ready ZFS нет.


А теперь барабанная дробь — BSD переезжает на кодовую базу ZFSonLinux, который теперь OpenZFS.
*задумчиво* в Oracle Linux есть и поддержка zfs, и готовые ПАК под zfs стойками продаются уже несколько лет как.
У вас ссылка не приложилась.

Наверное, потому что и не прикладывал: вот рекламная ссыль на zfs одной из последних версий https://www.oracle.com/storage/nas/zs7-2/, вот реклама одной из первых версий, датированная 2014 годом http://www.tadviser.ru/index.php/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82:Oracle_ZFS_Storage_ZS3_Series
Или вы о чём?

Не знаю что имел в виду оригинальный автор, но Oracle ZFS storage appliance (ZFS SA) базируется на Solaris и там не OpenZFS.
Посмотрел — да, вы правы: в серверах oracle zfs стоит солярка, а zfs на ol смонтировалась как том nfs. К тому же, нашёл официальный ответ на форумах оракла про Zpool: «Oracle does not currently offer ZFS as a supported product for Linux.»
Похоже, ввёл всех в заблуждение, извиняюсь.

Вы долго эту чушь "про переезд на кодовую базе ZoL" нести будете?
Нет никакой "кодовой базы ZoL", а есть репозиторий где на базе OpenZFS пилили костыли для Linux (впрочем, не слишком успешно).
Было принято решение о слиянии базовых репозиториев, где велась разработка ZFS для различных систем на базе ZoL потому что он более жив, чем использовавшийся ранее аналогичный в проекте IllumOS.
Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS.

на базе ZoL потому что он более жив

так про это и речь


Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS.

на гитхабе уже

Нет никакой «кодовой базы ZoL», а есть репозиторий где на базе OpenZFS пилили

Ну это и есть кодовая база проекта ZoL. Речь именно о жизни в конкретном репозитории, до этого все OpenZFS проекты жили отдельно, теперь непосредственно в репу ZoL добавляют обвязки для сборки из неё и для FreeBSD.

Чем вам «кодовая база» не нравится?:)

Было принято решение о слиянии базовых репозиториев, где велась разработка ZFS для различных систем на базе ZoL потому что он более жив, чем использовавшийся ранее аналогичный в проекте IllumOS.


Как непосредственно участвовавший — слияния репозиториев нет, ZoL активно пилит свои фичи и он уже 2-3 года впереди, мы давно забекпортили все нужные изменения из Illumos и уже несколько лет бекпортят из ZoL в обратную сторону. В том числе и «костыли», как вы их называете.

Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS

Уже.
Как непосредственно участвовавший

Ну тогда тем паче грешно дезинформировать публику заявляя о "переезде не кодовую базу ZoL", тем более что, со своей стороны, я вижу, что за примерно год прошедший с начала объявления процесса миграции разработка ZFS во FreeBSD фактически заморожена и она получила из кодовой базы наработанной в рамках ZoL примерно ничего, в то время как идущая на "2-3 года впереди" ZoL, наконец-то, получила SSD TRIM и ZFS on root.

ну вроде как скоро получит special allocation class, ИМХО мегаполезная фича

что за примерно год прошедший с начала объявления процесса миграции разработка ZFS во FreeBSD фактически заморожена и она получила из кодовой базы наработанной в рамках ZoL примерно ничего

Именно.

ZoL, наконец-то, получила SSD TRIM

С другой реализацией с нуля, если что.

и ZFS on root.

Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.

Не понимаю что вы хотите доказать. FreeBSD будет собираться из репы ZoL->OpenZFS? Да. «разработка ZFS во FreeBSD фактически заморожена». Вот и переезд на кодовую базу. Вас смущает терминология?

Если хотите что-то объяснить, то скажите просто что вам в этом выражении не нравится.

Доказывать тут ничего не нужно, поскольку на сегодня объективно FreeBSD не использует "кодовую базу ZoL", что аннулирует ваше начальное заявление.


Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.

Я не знаю что вы (и откуда) используете, но вижу что в популярные дистрибутивы это стало заезжать в прошлом году (пример). Впрочем, я особенно за этим не слежу ввиду отсутствия интереса да и надобности.

А подскажите что за терки с ZoL в линуксе, вроде Линус сильно недоволен и вроде как выпилил ядерные структуры для поддержки ZFS в ядре. Удалось как-то решить эту проблему? Я ZFS в линкксах не пользуюсь поэтому не знаю…

Да, проблему решили, GKH принял патч, где несколько функций начали экспортировать только для GPL совместимых модулей. Пришлось сделать патч и реализовать просто часть логики на стороне zfsonlinux.

Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.

Спасибо за ликбез. Рад что нашли решение проблемы. Надеюсь общими усилиями удастся сделать ZFS и стабильной и совместимой хотябы в Open Source OS.

FS не в ядре? Тогда это просто игрушка
Не Линус, а Грег, не выпилил, а упорядочил свой код, недоволен чужим недовольством, т.к. с чего бы человеку GPL заботиться о ПО, намеренно и умышленно выпущенным под несовместимой с GPL лицензией. Могли выпустить под совместимой лицензией — никто не мешал.

Идут споры о совместимости — несовместимости лицензий: GPL у Linux и CDDL у ZFS.
Вроде как поставка готовой сборки Linux с включённой поддержкой ZFS вообще незаконна, чем занимается Canonical, но вроде как больше никто из крупных поставщиков.
У Linux есть «своя» BTRFS, использующаяся по умолчанию в SUSE и openSUSE, и ими же поддерживающаяся (кроме прочих). Redhat отошёл от BTRFS и делает свою Stratis (или что-то там ещё).

Подробнее см.:
ru.wikipedia.org/wiki/ZFS#Linux
en.wikipedia.org/wiki/ZFS#Linux
ru.wikipedia.org/wiki/CDDL
en.wikipedia.org/wiki/Common_Development_and_Distribution_License#GPL_compatibility

Их позиция "нам пофиг на всё, что не в ядре" имеет право на жизнь, жаль что при этом начинаются политические игрища по поводу лицензий, при этом никто не агитирует gkh и Линуса вливать код zfs в ядро. Но зачем осознанно портить жизнь другим людям?


Но вот такой патч упорядочиванием кода назвать сложно, по сути убран экспорт функции для nongpl консьюмеров, и всё https://github.com/torvalds/linux/commit/12209993e98c5fa1855c467f22a24e3d5b8be205


Что мешало оставить экспорт как было раньше? Вот и недовольство.

Что мешало оставить экспорт как было раньше?

Ну вообще каждая функция объявленная как static в таком огромном
проекте это благо. Это и ускоряет компиляцию и линковку, и упрощает поддержку, так как чем меньше функций доступных извне данной единицы трансляции тем меньше межмодульных связей, и думаю очевидна польза от уменьшения связанности огромного проекта?

С козырей зашел)

… который не совместим с ядром 5.5, потому что… не GPL и Linus решил, что еще один метод будет GPL-only


И так при каждым выпуске ядра было и будет продолжаться :)

несовместимость только с PREEMPT ядром, так норм:

# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_NOTIFIERS=y


CONFIG_PREEMPT_NONE тоже годится, особенно для сервера

p.s. кстати, дело c «нелюбовью» не только в лицензии, но и в идеологии комбайн (aka Rampant Layering Violation?) vs модульность
Какой-либо унификации документации, конфигурации, вывода информации в софте толком нет. Всюду и везде будет явно и отчётливо видно, что вот эта небольшая программа/утилита написана одним человеком, а вот эта другим.

Как-то притянуто за уши. Кроме базовых утилит набор-то софта у обоих одинаковый. От GNOME до Wireshark, от mongodb до nginx все же одинаковое. Или разработчики *BSD для всех этих тысяч популярных проектов с открытым кодом дописывают документацию, переделывают им формат конфигов и так далее? Почему-то я очень в этом сомневаюсь.

Так я писал


Кроме базовых утилит

А если речь идет именно про базовую, то насколько я помню
туда входит совсем небольшое количество утилит, насколько это критично по сравнению
со всем остальным набором софта в котором есть куча разночтений.

Для конечного юзера софт один до тех пор, пока его разработчик юзает только posix, а иначе терпит.

Например, есть доклад от nginx про ядро, там есть явные места про «в bsd задизайнено удобнее»: sendfile, epoll_ctl.

p.s. Кстати, бы очень интересно услышать отзыв от nginx команды про io_uring
Очень однобокое сравнение.

Сегодня вроде не 1 апреля.

Спасибо за проделанный труд и интересное сравнение, правда ОС обычно выбирается исключительно под задачи.
Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.
Также отмечу что для СХД FreeBSD (FreeNAS и аналоги) встречается часто благодаря zfs.
Если есть ниши где FreeBSD также используется широко — расскажите об этом, думаю всем будет интересно узнать.

Я предполагаю что мы говорим про администрирование серверов, и возможно СХД и странно читать что:
«Поддержка TRIM появилась лишь в прошлом году, по сути не позволяв достойно использовать ZFS на SSD.»

Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?
И это нисколько не мешает использовать SSD.
TRIM имеет смысл только на десктопных SSD, для серверных он не нужен.

И немножко про zfs:
zfs является бесспорно отличной ФС, также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs.
Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?

А вас не смущает, что RAID контроллеры противопоказаны при работе с ZFS?


также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs

Не является даже близко. Почитайте эпичный тред на IXBT с обсуждением реально с ней работающих… Там, очень мягко говоря, до продакшн реди ещё как до Луны пешком. В общем, Redhat не даром её из кодовой базы выпил к чертям.

Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.

Отнюдь.
Меня смущает что вы, видимо, считаете что ZFS хорош только на серверах. Так вот нет. Boot environments и snapshots, не говоря уже про надёжность хранения, чрезвычайно полезны и востребованы и при персональном использовании.


Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.

Честно говоря мне лень, но вы найдёте. Там реальный "адъ и Израиль".


UPD. По-моему это был тред про NAS.

Ссылочку на тред про ZFS на IXBT скиньте пожалуйста.

Часто ОС и даже конкретный дистрибутив в компаниях выбирается исключительно под знания, навыки и вкусы имеющегося персонала.

Это если только говорить о выборе типа фряха, линь или винда.
Если говорить о линушных дистрибутивах, то разницы, по большому счёту, нет. Линукс он и в Африке линукс.
Линукс он и в Африке линукс.

К сожалению, нет. Как говорится — бери тот дистрибутив, который знает твой друг-админ.

Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.
Когда-то работал в конторе обслуживающей кроме всего прочего почтовые и веб сервера в коммерческих конторах. Линукс не использовался вообще. Почта, прокси, маршрутизация и проч связанное с сетями — 100% FreeBSD. Сейчас поинтересовался у коллеги — ситуация та-же самая.
Что греха таить, домашний NAS/сервер живет у меня с 98-го года под FreeBSD, но в 2016-м одна очень нужная софтина не захотела ставиться не под каким соусом и психанув, поставил Ubuntu, тем более, что десктоп у меня уже с ~2010 под ним же. Не буду описывать причины, что бы не скатываться в субъективизм, но с начала 2019-го сервер вернулся под управление FreeBSD. При этом на десктопе отказываться от Линукса пока не собираюсь.
Ну это не показатель от слова вообще.
У меня вон есть серверы на SUSE Linux, первом выпуске. Тоже еще работают. Сколько им лет? 15?
Убунту это не серверная среда. Смысл ее ставить на сервер, а потом использовать как аргумент.
Имхо FreeBSD просто сильно заигралась. Никому не нужно такой ценой идеальность.
Все дистрибутивы Linux — суть Linux. Отличия в части «серверной среды» минимальны, ибо базируются на функционале ядра. Даже systemd теперь практически везде — вроде все чуть ли не молятся на него, а на деле, можно убить кучу времени пытаясь понять, почему служба не стартует. И окажется, что это чудо _думает_ что демон жив и здоров, а значит не надо ничего делать.
Что касается серверов на FreeBSD, то это не где-то забытые машины, а регулярно обновляемые и поддерживаемые системы.
Собственно, домашний сервер:
FreeBSD xxx.xxx 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0: Mon Aug 19 21:08:43 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
11.3? 12.1 уже давно надо.
Продуктивный же пока ещё 12.0.
27 октября будет релиз 12.2.
www.freebsd.org/releases
Most Recent Releases
Production Release
Release 12.1 (November, 2019)
Release 11.3 (July, 2019)

11.3 вполне Ок, особенно для старого железа.
Учитывая какой был раздрай и бардак до systemd, его наличие благо. Но как и все поделия Поттеринга, нужно подождать пока он перестанет его писать :) И тогда станет все прекрасно и хорошо. Как это стало когда он перестал активно пилить pulseaudio. Как визионер он молодец, но вот его код и то как он это делает нууу такое :)

Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз.

"Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз."
У вас хорошая память, вам повезло ..

Читайте концепции и то как устроен unit файл. Не надо читать там все специфические случаи, там действительно много что сделано, так чтобы скрипты надо было писать только в 0.01% случаев. Когда надо фичу M открыли документацию да посмотрели.

Да не с unit фалом то проблем нет, проблема в том какие зависимости прописать под ситуацию, было ровно 2 кейса, монтирование root раздела с dm-raid (вышло так, при миграции с win) и перевод видеокарты в low режим, со вторым чуть проще (разгон турбины, нагрев, не такой шустрый) а вот с первым было трудно понять куда его ставить :)

большинство RAID контроллеров поддерживает UNMAP, с которого скопирован TRIM. Кроме того ZFS рекомендуют использовать не с RAID контроллерами а с HBA, т.к. у последних задержки ниже, а функциональность первых не востребована.
это нисколько не мешает использовать SSD.

Ну, если не смущает необходимость регулярно менять диски. И если не смущает постепенная деградация их скорости. Оба эффекта мы ловили.

В 2000 году FreeBSD не умел грузиться с extended partition. А lilo и Linux умели. Это похоронил вряху для меня. Субъективно.

Простите, но ссылаться на 2000 год также "актуально", как обсуждать сейчас достоинства и недостатки Windows XP

Так оно и сейчас вроде не умеет.
Другое дело, что там кроме ZFS больше нет файловых систем нормальных. ufs — зеркало из 2 дисков по 1тб, fsck после хард резета занимает 6 часов. Нормально?
Можно (нужно) включить журналирование для этой ФС, вместе с soft-updates (SU+J). Занимать будет секунды.
SU нужно для ускорения работы фс, разрушение данных как раз при аппаратном ребуте будет только сильнее. А журнал — он там как 5 нога, сбоку приделан костылём. И под него нужно или уменьшать раздел, или иметь место после раздела. Точных значений не скажу, лет 10 назад последний раз активировал, но помню что без освобождения места за разделом журнал не сделать. И помнится что с ним существенно проседала производительность…
Хотя может за 10 лет сильно поменялось всё, но вообще на такие объёмы только zfs имело смысл, имхо разумный предел для ufs — гигабайт 50-100.
Ваша претензия была к времени fsck. На любой ФС без журнала (ну и не CoW) это будет долго, по очевидным причинам.

То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).

С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
Простое и логичное управление памятью и нехваткой памяти.

а что там вместо OOM killer?

Он просто работает. Причём работает так, что даже мысли не возникает об использовании своего отдельного OOM "с блекджеком и шлюхами" в userland как это теперь водится в Linux.

Интересно а как? Вот есть 2 user space процесса постепенно выбирающих память до предела, какое решение?

Немного не по теме, но например в MacOS при нехватке памяти (и свопа тоже) ОС фризит процессы которые запрашивают аллокацию. Это несколько раз спасало меня позволив разрулить ситуацию, закрыть что-то тяжелое и ненужное, а потом разморозить процессы и они продолжали работу штатно. Своп у меня отключен, а великолепное сжатие ОЗУ на лету тоже не всесильно.

Такое поведение возможно при существовании гарантированного резервирования памяти под системный процесс, насколько я понимаю, проблемы возникают из-за механизмов типа copy on write, я в принципе далёк от системного программирования, но на мо взгляд такие механизмы очень усложняют отслеживание процесса которой запросил больше чем доступно, в итоге тот самый oom killer который по умолчанию настроен на работу до последнего (ведь крайний запрос на память может быть от системного процесса не смотря на то что 99% съел условный браузер) просто не успевает отработать и в итоге выстраивается очередь подвисших процессов.
Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб. RAM, насколько я понимаю (из прочитанного лет 7-8 назад) из-за особенностей алгоритма наличие swap даже небольшого размера частично решает проблему(зависаний нет совсем, но да что-то будет прибито).

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

Именно так.

Заметку по этому поводу я не обновлял по сути где-то с 2002 года. И сейчас ничего не изменилось.

> Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб

Своп помогает — за счёт превращения исчерпания памяти в торможение программ — и даёт время, если есть админ или автоматический мониторинг, остановить проблему до наступления критического исчерпания. Может, поэтому никто и не чешется лечить по сути.

Про это вроде и писал, в общем проверил на себе работает…
Вашу заметку не читал, вроде (память ненадёжная штука, не уверен), мысль о механизмах пришла в голову когда где-то читал о самом механизме передачи крупных блоков памяти.

за счёт превращения исчерпания памяти в торможение программ

Только из-за современных nvme или ssd этого почти незаметно.

Не соглашусь. Точнее, не всегда и не везде это так.
Вот у меня дома 8 ГБ оперативки, и своп на 1ГБ. Однако, когда прожорливый процесс подбирается к потолку (это около 7,4...7,6ГБ), он и вся система начинает жутко тормозить. До того, что сложно (или невозможно в адекватное время) переключиться по Ctrl+Alt+F2 на консоль и грохнуть там процесс.
При этом swap и вся система на SSD, и swap на отдельном разделе. И oomkiller не срабатывает почему-то.
Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).
Для конкретики,
[avx@localhost ~]$ uname -a
Linux localhost.localdomain 5.5.6-desktop-2.mga7 #1 SMP Tue Feb 25 11:54:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Процесс — игра Deus Ex: Mankind Devided, запущенная из steam.
В процессе игры иногда встречаются моменты, когда логично и понятно, что будет занято много памяти, и на компе индикатор активности диска сразу начинает активность, а игра подвисает, и иногда может даже «прожевать» этот пик нагрузки на оперативку, используя swap, но чаще приходится делать hard reset кнопкой.
P.S. Да, я понимаю, что лучше просто добавить память. Но не всегда можно быть богатым и здоровым :-)

Мне кажется, хотя я могу ошибаться, но ваш сценарий, независимо от того, что у вас вроде как 1 большой процесс, не исключает указанной мной причины, просто если в вашем случае реализовать только гарантированное выделение, возможно "провисания" не будет, но при этом ваша игра выпадет по "out if memory", насколько я понимаю, в текущих системах, система до последнего пытается высвободить место под ваш процесс, а когда почти все системные процессы (в том числе код библиотек) уже вытеснены, происходит ошибка идёт в процесс, который пытается её обработать, но для этого ему нужно поднять то что до этого было вытеснено из памяти, но на этот процесс уже не хватает ресурсов и тут просыпается oom killer, я не настаиваю, но возможно именно не совсем некорректная обработка прерывания процессом игры и вызывает такое поведение. Особенность в том, что современное ПО уже "привыкло" к тому что можно выделять памяти больше чем есть реально, и при этом использовать сколько нужно (когда я первый раз увидел много лет назад объём виртуальной(не уверен в точности термина) памяти больше чем вся RAM я удивился, а теперь никто и не обращает внимания.
p.s. совсем не специалист в части работы ядра и его систем, всё что написано выше, только исходя из моего понимания логики работы подобных систем.

Особенность в том, что современное ПО уже "привыкло" к тому что можно выделять памяти больше чем есть реально, и при этом использовать сколько нужно (когда я первый раз увидел много лет назад объём виртуальной(не уверен в точности термина) памяти больше чем вся RAM я удивился, а теперь никто и не обращает внимания.

Именно так. Это тот же самый бич, когда программа требует привилегий больше, чем ей нужно для работы — но все уже привыкли и теперь ломать стереотипы сложно. Проще запихивать этот помойкософт в контейнеры (докер) и виртуалки (qubeos) и надеяться, что все будет хорошо. Ну, и своевременно подкидывать новых аппаратных ресурсов

Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).

в линуксе достаточно отключить оверкоммит памяти, но только при этом начинаются спецэффекты. Чертов софт, который написан кое-как

Подробнее можно? Где и как отключить, и чем именно это грозит? Для обычных приложений залезть в своп — ну, замедлится, ну подождёт пользователь подольше… А для игры — это подобно просто выключению игры. Ибо настолько всё замирает, что уже об игре и не вспоминаешь, а только как бы её просто закрыть (да, потерянный прогресс иногда жалко). Так что если игра просто вылетит с ругательствами на память — пусть бы и так, это лучше, чем просто висеть и насиловать мой SSD.

P.S. на работе выключил на одной слабой машинке (2004 г выпуска, Celeron 2.6GHz, 512MB памяти, winXP и KES10 + рабочий софт несколько штук) swap совсем, и… работать стало лучше! Раньше — запустит юзер сразу 5 программ, они сожрут оперативку (которой уже на старте ОС почти нет), и машина свопится, а диск тормозной, и всё сильно подвисает. После — запускают одну программу, вторую, третью — оп, а на четвёртой (или на третьей, как повезёт) ошибка — нехватка памяти! Они закрывают ненужные на данный момент программы, и работают дальше, без тормозов (ну, для этой машины если так можно сказать). И аптайм машинки по несколько месяцев случается.
Для обычных приложений залезть в своп — ну, замедлится, ну подождёт пользователь подольше…

У меня линукс не отвисает вовсе после ухода в своп. Видимо баг, но я хз что делать — IO LED висит сутки-вторые-третьи...

Это баг, из-за которого Linux на компьютерах с низким количеством памяти лучше вообще не использовать. В Windows, например, ситуация намного лучше.

bugzilla.kernel.org/show_bug.cgi?id=196729
bugzilla.kernel.org/show_bug.cgi?id=199763
www.reddit.com/r/linux/comments/94u116/gnulinux_on_12gb_ram_tablets_how_it_really_works

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

А внутре неонка!

По параметрам, про которые вы говорите, msdos восхитительна. Там нет зоопарка веб-серверов, а все фичи, если они поддерживаются, поддерживаются всюду (например, директории). А уж как хорошо msdos справляется с зоопарком файловых систем — словами не передать. msdos использует только те файловые системы, которые поддерживаются всеми другими операционными системами. msdos удивительно компактна и требует микроскопический объём памяти.


По всем этим критериям msdos лучше, чем freebsd.

FreeDOS же. Там даже драйвера сетевые есть!
Я думал холивары начинаются и заканчиваются на ЛОРе… Странно видеть это здесь.
Хотя я часто слышал что теряли данные на UFS2, но у меня за всю жизнь с FreeBSD ни разу не было, тогда как на ext3/ext4 неоднократно.

Единственной хорошей работающей достойной ФС в GNU/Linux я видел только XFS, творение начала 90-х SGI IRIX.

я вот как раз терял данные на xfs, а с ext3/4 проблем не было.

Я слышал, что xfs не умеет в сжатие (я сейчас про уменьшение виртуального диска у ВМ, например с 20 до 10гб — если xfs, то такой фокус не пройдет), расскажите теперь про zfs, а то я с *BSD на уровне "потыкать" сталкивался.

Угу. На чем там по-умолчанию собирается pfSense? Два раза разбирался после обычного reset...

Тем не менее почему-то разработчики суперкомпьютеров как правило выбирают GNU/Linux. Может они тупые, или есть какие-то другие причины? Насколько мне понаслышке известно, у FreeBSD еще большая проблема с драйверами, чем у Linux (возможно, не прав, только вот на сайтах производителей видеокарт, например, драйверы для Linux можно встретить, причем для разных дистрибутивов, а FreeBSD как-то не встречал). Возможно, FreeBSD — неплохой вариант для сервера, который достаточно один раз настроить и забыть, но в статье это не раскрыто. Думаю, что ставить ее себе на ноутбук не особо хорошая идея.

Миллионы мух [не] ошибаются?

А вы не задумывались о том, почему мухи как вид намного старее нас, и нас ещё переживут?
на сайтах производителей видеокарт, например, драйверы для Linux можно встретить
Способ распространения драйверов у винды сильно отличается от всех других ОС. Предоставьте, пожалуйста, ссылки на страницы на сайтах производителей видеокарт, где есть драйвера кроме как для винды.

Драйвера для FreeBSD есть на сайте Nvidia. Раньше делали и для Solaris x86/x64, но уже вроде как прекратили для GeForce 1600-х (может, ещё появятся, но вряд ли).

Вакансий с требованиями именно xBSD в РФ не нашёл, они перечисляются среди пожеланий — т.е. требуется «Linux, ну и до кучи еще и BSD».
С поддержкой оборудования есть трудности — его список меньше, чем у Linux.
С поддержкой новейшего оборудования — ещё сложнее.
Драйвера FreeBSD обычно берёт у Linux.
ZFS хороша, но для начала желательно что попроще. А этого в готовых сборках FreeBSD обычно нет, в отличие от Linux.
У Linux есть больше преимущество — гораздо легче начать им пользоваться, чем xBSD. У Linux есть «преимущество лёгкого начала»: Linux можно поставить не особо разбираясь, и он начнёт работать. С FreeBSD всё труднее. А когда освоил Linux, заниматься xBSD уже не особо-то и нужно.
FreeBSD — хорошая система, и местами выглядит лучше чем Linuix. Но пока что работать с ней и изучать её — тяжело, распространена она меньше. Знание FreeBSD навряд ли значительно повысит зарплату (в РФ и Украине. Для Netflix м.б. будет преимуществом).
Т.ч. всё вот так — «не очень».
Звучит так будто вы BSD никогда не пользовались, она значительно проще в администрировании и настройке нежели линукс, так же первой установке. Этому способствует bsdinstaller, псевдографическая утилита настройки, ей же можно и обновлять систему и тд, псевдографика есть так же при установке из портов, и широкий выбор удобных утилит для отладки и мониторинга, а так общая консистентность в расположении конфигов, логов и прочего. Всегда все конфиги установленных программ будут в /usr/local/etc//, системные в /etc и тд. В то время как интернет полнится запросами подобно «где конфиг %app_name% в линукс %dist_name%, где в зависимости от дистра, ментейнера или просто автора аппки он может где угодно лежать.
Так же FreeBSD по-умолчанию идет с UFS — это как раз и есть „что попроще“. С поддержкой железа сейчас ситуация в принципе в паритете с линуксом, десктопное железо конечно пониже приоритет имеет. Но у меня Фря даже на малинке бегает бодро. В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Вы говорите так как будто зоопарк утилит и софта это плохо? Лично я считаю что чем больше возможностей сделать одну и туже задачу тем лучше. Или Вы склонны делать всё по шаблонам? и как китайские программисты которые выучили только один способ работы другому же практически не обучаемы? и тем более высших грех им думать о другом способе который может быть в разы быстрее, легче и удобнее?
Это порождает фрагментацию, сам альтернативный софт — это хорошо, плохо когда в рамках по сути одной ОС в базе используются разные подходы, разные утилиты, разный синтаксис команд и прочее. База должна быть стандартизирована. Не стоит так же забывать про принцип KISS. Собственно поэтому существуют всякие POSIX и UNIX сертификации. И что плохого в шаблонах? Они экономят время позволяя не задумываться над базовыми операциями. Не думаю что это то место где нужен творческий подход.
Если хотите что-то единое, используйте коммерческие ОС, типа Windows и Darwin/Mac OS, где народ без дополнительной копейки даже «пукать» не будет, не то что бы что-то иное либо новое реализовывать… И даже в рамках всей этой проприетарщины многие утилиты чистое гоумно и сторонними разработчиками за отдельную не маленькую такую копеечку разрабатываются утилиты которые предоставляют больший набор возможностей и при условии что Вы хотите а иногда и вынуждены их использовать нужно будет эту копеечку платить. А теперь по поводу KISS, это конечно хорошо, но что для одного «просто», для другого будет крайне сложно и это уже от человека зависит. Теперь по поводу того что же из себя представляет GNU/Linux — это такой крутой конструктор лего… из которого Вы можете сделать то что хотите используя те подходы которые Вам ближе а не какому-то дяде. Нет или не устраивает что-то в одном дистрибутиве, не проблема найдёте это в другом. Зачастую многие GNU/Linux даже специализируются на каких-то задачах, что нельзя сказать о других О.С.…

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

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

так же можно развёртывать новые машины и настраивать их каждый раз ручками, а можно подойти творчески взять ансибл либо паппет и всё будет работать само…
Я для десктопа и использую макось, и там как раз есть покрытие всего линукс софта и плюс коммерческого, все что есть на линь портируют на мак для удобства разработки, а утилиты тут BSD, макось же подтверждают юникс сертификацию и позикс и не надо ни за что платить ) только за коммерческий гуевый софт.

За линь же как раз эту фрагментацию дистрибутивов и критикуют. Это только на словах звучит так круто, большое обилие выбора и свободы, по факту это это сотни и тысячи дистрибутивов с минимальными отличиями в виде нескучных обоев с разной степенью стабильности как самой ОС так и своих реп и наличия софта в ней. А в этот конструктор совершенно не хочется лезть, хочется что б все просто работало, при этом выглядело не всрато, и требовало минимальных и понятных вмешательств для настройки, все остальное лежит в области хобби и энтузиазма. Либо если тебе очень хорошо платят за создание конкретной эмбед платформы, типо роутеров, прошивочки камер и прочего и время которое ты тратишь разбираясь в этом.

Насчёт фрагментации — полностью поддержу.
Просто задумайтесь сколько способов есть решить тривиальную задачу в линуксе, а именно настройку сети. Причем рассмотрите не только конкретный дистрибутив, а ситуацию в целом.

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

Теперь по поводу многообразия всевозможных дистрибутивов с нескучными обоями, да такая беда есть, но никто и ничто не мешает вам не использовать их а использовать корневые родительские дистрибутивы.

А по поводу многообразия утилит которым Вы так не довольны, да их много но время отсеивает большую часть и остаются только те которые действительно удобны народу. Если Вы считаете иначе это Ваше мнение как индивида из всего того сообщества которое использует их и далеко не факт что все должны думать и думают как Вы…
Нет, счего бы? Просто есть code of conduct, который держит проект на определенном уровне качества, если ты как разработчик не готов ему следовать и доводить свои решения до определенных стандартов принятых в проекте, каким бы полезным не был твой вклад — это будет медвежья услуга, неуважение к комьюнити и такой продукт даже не будет принят. Тем более когда есть аналоги. А если кто-то создал действительно уникальный полезный инструмент, то люди приведут его под стандарты проекта либо же напишут свой велосипед (привет Поттеринг).
1. Вы снова пытаетесь сравнивать дистрибутив и отдельных разработчиков которые ведут свой проект. Это тоже самое что сравнить Blender и к примеру Inkscape и говорить какой плохой дистрибутив они отличаются стилистически… и набором функционала…
2. Code of conduct — к сведению, привязан к одному конкретному проекту, не путайте. Да и это больше относится к поведению, нежели разработке и составу кода и качеству кода.
Разработчики ведут свой проект для какой-то целевой системы же, должны учитывать специфику и правила, а раз в Линуксе строгих правил нет это и порождает беспорядок.

Ну Фря и есть конкретный проект, это целостная ОС. Вообще в различных ОС приняты свои требования к ПО под нее. Как, например, в MacOS в любой программе комбинация CMD +, откроет окно настроек программы. Так же частенько вижу в консольных утилитах и софте определенные флаги с пометкой «добавленно для совместимости с POSIX».

За флаги, кстати, тоже раздражает, в одних программах --version выводит версию в по, в других внезапно только -v, в третьих это verbouse, а четвертые вообще выводят версию без "-" просто version. Это пример, такие претензии к -h help и прочим стандартным флагам, очевидно же было бы лучше будь они как-то стандартизированы.
CMD +,

Не с "Command ," перепутали? А, все, понял, неудачное форматирование было )

Разработчики ведут свой проект для какой-то целевой системы же

Вы сильно ошибаетесь. Ещё раз Вы путаете всё и вся. Не нужно писать об этом если Вы в этом ничего не понимаете. Как разработчик говорю.

А по поводу команд так нет ничего в этом плохого, многих же устраивают утилиты под мелкомягких хотя там тоже не наблюдается солидарности в этом даже повершел от мелкомягких отличается хотя там многое поменяли…

В общем я ещё раз убеждаюсь в вашей не компетенции в этих вопросах. разработкой нужно заниматься что бы понимать о чём речь. Консольные утилиты и набор команд для них а тем более обработчик их может сильно зависеть от выполняемых ими функционала.
Именно. «Если ты читаешь книгу по FreeBSD, ты читаешь книгу по FreeBSD. Если ты читаешь книгу по Linux, ты читаешь книгу по конкретному дистрибутиву Linux.» ©
> BSD никогда не пользовались, она значительно проще в администрировании и настройке нежели линукс, так же первой установке.

Вот сейчас решил проверить, при том, что до 2008 этих самых FreeBSD поставил несколько десятков штук и основные воспоминания сохранились. Ставлю по сети с bootonly образа.
Задал дохлое зеркало: минут 10 попыток достучаться и перешло в режим, что на клавиши не реагировало. Пришлось перезагружать.
Манера диалогов, что пробел меняет настройку, а Enter применяет весь диалог — нигде не описана на экране (что мешало дать подсказку?)
Куча вопросов типа «а включать ли ntpd?» Почему вообще спрашивают, что, точное время обычно локально не нужно?
В диалоге добавления юзера: «Invite vasya into other groups? []» — как догадаться с первого раза, что тут нужно не «yes», а список групп?
Пошёл в postinstall настройку интерфейсов — спрашивает, вам DHCP там нужен? На моё Yes говорил — не шмогла. Ещё бы, dhclient уже запущен, а она этого не помнит.
А почему не было пункта добавить софта (может, я хочу KDE сразу поставить?)
Что-то многовато получилось жалоб даже от опытного пользователя и админа. А новичку как?

> Всегда все конфиги установленных программ будут в /usr/local/etc//, системные в /etc и тд. В то время как интернет полнится запросами подобно «где конфиг %app_name% в линукс %dist_name%, где в зависимости от дистра, ментейнера или просто автора аппки он может где угодно лежать.

Во-первых, это очень дурная манера использовать /usr/local для пакетного хозяйства. Не зря в NetBSD поместили это в /usr/pkg.
Во-вторых, проблемы линукса от стиля управления или от принципов типа «называть по сервису или по продукту» (отсюда различие типа /etc/httpd vs. /etc/apache2), а во FreeBSD получается, например, пока BIND был в базе — есть /etc/named, а потом вдруг /usr/local/etc/named, причём там только первый конфиг, продолжение из-за jail где-то глубоко в /var/named…

> В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.

Зато если остановиться на одном конкретном — то возможностей больше и реализуются они обычно с меньшей пляской с бубном.
Исключения — всё те же netgraph и GEOM — сейчас это два основных кита, на которых FreeBSD ещё хоть как-то держится на плаву. Ну ещё ZFS немного помогает. Linux сильно шире в количестве ниш и между ними всеми перетекают новые разработки.
Честно говоря больше на придирки похоже. Дохлое зеркало не вина FreeBSD, по-умолчанию там толи эникастом толи роутером выдается оптимальное корневое зеркало и есть так же зеркала 2го эшелона работоспособность которых никто не гарантирует, но они могут висеть на сайте.
NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
25.10.3.1 Если вам нужно только синхронизировать ваши часы при загрузке машины, вы можете воспользоваться утилитой ntpdate(8). Это может подойти для некоторых настольных машин, которые часто перезагружаются и только требуют изредка синхронизироваться, но на большинстве машин должен работать ntpd(8).

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

Почему манера использовать /usr/local дурная? Вообще именование каталогов, точек монтирования в unix исторически довольно малосвязная и забавная тема, просто FreeBSD использует одну из ранних вариаций, не думаю что она чем-то хуже или лучше любой другой, мне лично скорее нравится отсутствие лишних сущностей в виде /opt /pkg и тд и этот подход, опять же лично мне, кажется вполне логичным.

В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить, я обычно сразу пишу wheel для админский учетки, мне честно говоря сложно судить насколько это интуитивно, мне как программисту эти скобки сразу список напоминают, может вы и правы.

> Зато если остановиться на одном конкретном…
А вот проблема в том что приходится использовать то что там уже есть, а предидущий интегратор мог развернуть тот дистр что он больше знает или по каким-то своим убеждением, холивары там между дистрами идут еще горячее, хоть казалось бы. Это и имелось мной в виду.
> Честно говоря больше на придирки похоже. Дохлое зеркало не вина FreeBSD,

А вот то, что на опознание проблемы потребовалось ему 10 минут, за это время нельзя было нажать отмену, и после этого на клавиши перестало реагировать — вот это полностью вина FreeBSD, точнее, авторов кривого инсталлятора. Странно вы читаете, если это проигнорировали.

> там толи эникастом толи роутером выдается оптимальное корневое зеркало

Но оно же может быть недоступным по сетевым причинам.

> NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:

Даже для выключаемого десктопа мягкая корректировка темпа хода полезнее, чем прыжки. В плане управления временем тут у FreeBSD отсталость лет на 15.

> Почему манера использовать /usr/local дурная?

Потому что /usr/local — типовое умолчание для autotools и аналогов для ручной сборки. Поставленное таким образом плохо отделяется от установленного из портов и может с ним подраться.

> В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить,

Для установщика для простого юзера это должно быть написано сразу там же.

Этот инсталлятор, на самом деле, всегда затачивается под то, что он будет идти с инструкцией (в Handbook, в браузере чего-то соседнего или вообще в бумажном виде). Но типовой современный юзер никогда эту handbook не читает (и игнорирует её существование, если не наступил уже на эти грабли). Инсталляторы типа RHEL ещё предполагают, что установщик что-то читает кроме того, что пишет сам инсталлятор, но Ubuntu — уже нет.

> А вот проблема в том что приходится использовать то что там уже есть,

Да, это факт. Ты набил руку на Debian, приходишь — а там SLES. «Дык опаньки, братуха» (tm)

В убунтовском инсталляторе проблемы похлеще есть. Например, у меня последний инсталлятор серверной убунты тупо завис, когда сетевуха была не подключена к сети. Лол што. Реальные проблемы с разбивкой диска — то ту разметку, которую тебе надо, через инсталлятор не применить, то что-то ещё. Вообще все эти претензии к инсталлятора фрибсд смешны… Поверьте — у остальных линуксов они (инсталлятора) не лучше.

> В убунтовском инсталляторе проблемы похлеще есть.

Ну я, конечно, последние K лет записной кедорас, но проблемы инсталлятора собственно Ubuntu мне неинтересны, а в Kubuntu я таких эффектов не видел.
И тупых зависов не было, и разметка получалась.
Ставил также центось — стиль совсем другой, но тоже прилично. Может, если бы захотел суперстранного, то получил бы по рукам, но фрёвый в принципе такого не умеет.

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

> Поверьте — у остальных линуксов они (инсталлятора) не лучше.

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

Когда я фряхи ставил потоком, там уже все чудеса были отработаны, рука набита… но там и результаты часто требовались нестандартные. И таки это были pets, а не cattle.
А как ты Фряху на малинку накатил?
Сам образ наваял?
Или есть готовые на сайте малинки?
Есть готовые образы, img просто dd на флешку. Тут, например, небольшой список: wiki.freebsd.org/action/show/arm/Raspberry%20Pi?action=show&redirect=FreeBSD%2Farm%2FRaspberry+Pi#Pre-Built_Images
Либо просто с фтп Фри: download.freebsd.org/ftp/releases/arm
Драйвера FreeBSD обычно берёт у Linux.

Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.
У Linux есть больше преимущество — гораздо легче начать им пользоваться, чем xBSD.

Вообще неправда. Наоборот. Если, конечно, вы не имеете в виду «скачать образ, не читая ничего».

Так-то поддерживается меньшее количество железа, да.
А вот «выглядит лучше, чем Linux» субъективно везде.
Ну графические, под нвидиа например, нативные под фрю и даже в пакетах лежат. И они кстати содержат два набора файликов: нативно под ядро фри и линуксовые под эмулятор линя. Недавно поднимал нас и медиацентр под Фрей, на Коди. Вобщем-то довольно безпроблемно завелось все с карточной нвидиа.
У Nvidia есть официальный проприетарный драйвер под фрю, да. Свободные портируются с linuxkpi, и они староваты(linux 4.4, если не ошибаюсь), конечно, но работают.
Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.
Пойдите и почитайте что и как и берётся у Linux
Дадите ссылку с пруфами? (риторический вопрос, не дадите)
Неужели вы не умеете пользоваться гуглом? и Мне нужно тыкать пальцем как маленькому ребёнку? и даже забить запрос в гугл и щёлкнуть по первой же ссылке сложно? wiki.freebsd.org/Graphics… Ах да, Многим же сейчас это делать сложно… так как лапки…
Мой комментарий:
«Так что не берут. Кроме графических, которые под MIT лицензией.»
Когда научитесь читать, можете использовать этот тон.
Как это отменят тот факт что они берут драйвера у GNU/Linux? речь шла про это. Я в своё время на стаксоверфлоу видел кучу описаний по портации линуксовых драйвров PCiE на фряху, не спорю особо не вчитывался в то под какой лицензией драйвера были, но всё же…
Nvidia прямо с сайта предлагает дрова для: GeForce, RTX, Titan
Дык у него как были так и остались проблемы с драйверами, при мне извечный фряхолюб на 11 фряхе решил доказать что она быстра и работает везде… решил поставить себе на корпоративный ПК фряху 11, да не получилось оказалось нет драйвера под чипсет и следовательно не виделись винты… А так многие драйвера фряхи по прежнему тянут с GNU/Linux. Как я ниже писал и это ещё одно доказательство технологической отсталости GNU/Linux…
А так многие драйвера фряхи по прежнему тянут с GNU/Linux.

Что? Этого нет и никогда не было, потому что лицензии.
Никогда не сталкивался с тем, чтобы фряха не узрела такую базовую переферию, как винты. Я там понимаю ещё, когда она не видит какие-нибудь там принтеры или (как это бывало нередко лет 20 назад) не может нормально включить графику в иксах — эти штуки серверной операционке и даром не нужны. Но не видеть винты… — это очень странно.

Это как раз один из самых частых кейсов. Интел делает новый чипсет, сата контроллер в нем. В итоге не то что не увидеть — инсталер может просто зависнуть. Так же помню когда на сата только переходили, на фре отваливались сата винты, причем это довольно продолжительное время происходило. Потом вроде стабилизировали, но осадочек остался.

Я еще напомню, что новые контроллеры без встроенных драйверов не видятся не только во фре, пресловутые винды этим страдали не в меньшей степени. Вспомните ХР + SATA в enhanced mode, если нет дискетки с драйвером (или не вживить драйвер в дистрибутив руками).
В винде это было в 2000х годы, а во фряхе с этим я столкнулся 2 года назад.
На семерке я с этим сталкивался лет пять назад: деталей не помню, да и не в них суть: я все это писал к тому, что «винты» — это вовсе не настолько «базовая периферия».
А что полшага в сторону от совсем массовых систем, и проблема с драйверами встает в полный рост, так по-моему, этим вряд ли кого здесь можно удивить. Имхо, конечно.
Тут не проблема в винте а проблема в контроллере а он и есть базовая периферия, не путайте, ставили разные винты.
Да, приношу извинения.
Винт подключается к контроллеру жестких дисков, и драйвера нужны именно для этого контроллера (при этом еще один контроллер расположен непосредственно на винте).
Свойство базовости периферии не кодифицировано, о его значении и объеме можно спорить, но необходимости драйверов ни один спор не отменит.
Это говорит лишь о том что линукс это попсовая система для позеров
Тут товарищ просто забыл написать, что во FreeBSD все довольно плохо, с масштабированием на большие машины с большим количеством процессоров и памяти. Как сейчас там не знаю, но вот несколько лет назад FreeBSD показывала производительность хуже на машинах с больше чем 16 процессорными ядрами. Тест был насколько помню на использование PostgreSQL и MySQL. Причем мотивация людей со стороны FreeBSD была такова, что товарищи не делают специфичные для FreeBSD оптимизации.
> Причем мотивация людей со стороны FreeBSD была такова, что товарищи не делают специфичные для FreeBSD оптимизации.

А что удивительного? Если делается явная оптимизация под Linux, но не FreeBSD, и получатся результаты с явным перекосом.

Так уже было с таймером. В Linux было очень дешёвое, хоть и неточное, gettimeofday() (это ещё до варианта с user space, забыл его название), и MySQL очень активно его использовал (вызывая во много раз чаще, чем надо — в strace можно было видеть просто сотни вызовов подряд в одной нитке). Аналог FreeBSD был дорогой, потому что лез к аппаратному таймеру. В результате производительность страдала заметно, а на бенчмарках — просто чудовищно.
Пришлось сделать специальный удешевлённый вызов (clock_gettime с CLOCK_REALTIME_FAST) и подставлять его в свою сборку через патч порта. Цифры выправились, и об этом гордо отрапортовали, с объяснением причин.

Аналогично было в некоторых других проектах с kqueue — epoll сделан, а остальным — раз не умеете, довольствуйтесь медленным poll или вообще select. И пришлось самим патчить в порте.

Соотношение сил и намерений разработки под Linux vs. FreeBSD напоминает сейчас такое же для Windows vs. Linux ещё совсем недавно: есть типа одна большая целевая ОС, всё делаем под неё, там реальные потребители. Уже второй по счёту получает объедки, третий не получает ничего. И эта история точно так же продолжается дальше — на OpenBSD ещё на порядок меньше сил, чем на FreeBSD (хотя тут помогает, что все проекты BSD группы очень активно друг у друга тянут код).
Ну дак, а еще усилия по нормальной работе ОС на больших машинах так же пилятся в Linux в первую очередь как в целевой платформе. Больше ресурсов больше выхлоп.
«Но и это ещё не всё».

1. FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc. Сейчас почти сравнялись, но «в среднем» всё же FreeBSD+clang немного медленнее, чем FreeBSD+gcc (зависит от задачи).

2. После трёх лет (!!!) обсуждения всё-таки включили поддержку OpenMP во FreeBSD:
начало
конец
Не включали потому что «нам в базе не надо, а на остальных пох», при этом ныли «а чё на Форониксе такие циферки маленькие?...». А надо не ныть, не жить прошлым, а внедрять новые фичи, которых просят люди.

На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX. (когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ). Опять же щас Linux и FreeBSD сравнялись.
> когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ

Ну ответ я бы тоже поминусовал (в карму не полезу из принципа даже когда/если будут права) — различия между разными вроде бы Unix (Bell, BSD, SysV, OSF...) настолько велики, что надо или называть Unix только то, что происходит без потерь от SVR4 и OSF/1, или надо расширять понятие, и тогда, если мы включаем туда BSD системы, то включать и Linux. То, что Linux был испечён с нуля, имело значение первые лет 5 его существования, но сейчас уже всё это давно потерялось.

> На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX.

Никакого «унаследованного опыта Unix» у FreeBSD нет. Реальная многонитевость во FreeBSD появилась только в 5.x, и то она была очень кривой — авторы не смогли реализовать наполеоновские планы на M:N модель через scheduler activations. Уже в 6.x вариант 1:1 стал основным, в 7.x — единственным. Код поддержки этого всего свой (ну, в пределах копирований внутри BSD сообщества). Linux на тот момент имел уже NPTL. Накладные расходы на смену контекста и на сисколл у FreeBSD всегда были и сейчас есть чуть выше. Многопроцессорность ядра тоже очень долго выравнивали (чисто скользящую сериализацию 5.x во многом убили и сейчас она заметно ближе к линуксовой). Если в каком-то случае получается тут выигрыш, то за счёт других факторов.

> FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc.

Тут как раз разница очень неровная. Иногда clang выигрывает. Более того, на том же phoronix есть примеры, где gcc7 резко ухудшил часть тестов.
Но для основного кода FreeBSD это всё несущественно. Часть портов явно имеет инструкцию использовать GCC — там, где есть проблемы с Clang, не только с производительностью.

Про OpenMP в ней я совсем не знаю, надо будет как-нибудь почитать.
Я бы не был так уж уверен, современные суперкомпьютеры живут под управлением GNU/Linux так как другие не особо то справлялись с таким огромным количеством ядер. Где-то одно время даже читал тесты которые показали что лучше GNU/Linux не найти было, обосновывалась на примере расчётов многопоточных для сборки с 512 ядрами. Вполне возможно что уже что-то поменялось с тех пор, однако я не вижу движухи в сторону фряхи с той стороны…

Вообще суть сравнения ХЗ/BSD (потому что понатаскали от всего и вся) vs GNU/Linux, знаю что у обе системы можно спокойно уместить в мизер ОЗУ для линухи последних версий это порядка 4х МБ и 16мб на ПЗУ. Да уже и не в том возрасте что бы мериться у кого длинней и толще… работать надо, да и дома десктом уже давно без дуалбутов и всё работает на Debian Sarge GNU/Linux… в своё время перепробовал всё, убунты, федоракоры, мандрейки, редхаты и т.п. остался на дебе так как оптимальное соотношение цены / качества.

Ох, lets lorcombat begin!
Для меня Эдуард Шишкин является примером специалистом, который продолжает развивать свою тему наперекор всем, включая Линуса Allmightly.

Фря в качестве датаьейз сервера просто унылое говно — скорости нет. Это единственное место где у меня не фря, все остальное инфраструктурное только на фре, если я выбираю.
А так вообще пофигу что настраивать

А в чем именно скорости нет? Во что упирается?
Так. А Солярис?
Пилили её дико крутые люди, дико крутые технологии зародились именно на ней, вообще прогресс она двигала ещё как (ну, не она, а Sun Microsystems в целом), но… она не является свободным ПО, так что тут уж лучше даже GNU/Linux :-(
RIP. Развитие закрыто, все новые системы на Oracle Linux. Выпускаются только обновления и security fix.
Лучше срачей *Nix vs Windows, только срачики Linux vs FreeBSD
НЛО прилетело и опубликовало эту надпись здесь
Была бы карма, я бы лайкнул)
помню в 90-х некоторые очень жаловались на виддовс и хвалили «правильную» os/2. где теперь та os/2?
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))

Я и сейчас готов хвалить OS/2.
Для того времени это был очень серьёзный шаг вперёд, намного более стабильный и удобный.
Но сейчас "оспополам" это просто часть истории.


Где-то в 2000х я активно использовал FreeBSD и для работы с сетью она объективно была сильно круче Linux'а (всё портил разве что NAT в userspace'е, но и это в итоге починили). Я и сейчас готов утверждать, что тогда для многих серверных задач она была лучше. А уж jail был (на фоне имевшегося chroot в линуксе) просто великолепен.
Но сейчас лично для меня FreeBSD — часть истории.


Приятно осознавать, что в отличии от OS/2 она всё ещё жива, но не более того.

Да и OS/2 вполне себе жива, в виде ArcaOS…
Полуось часто вижу на IBM-овских кассовых терминалах в супермаркетах, те что моноблоки с экранами и тд.
Пока IBM исходники не откроет, скорее мертва. А она их не откроет, ибо там не только их интеллектуальная собственность.
На самом деле вот ядро уже не так важно. Я больше скажу. IBM-овское ядро это боль и ужасы(судя по реакции тех ребят что делают ядро OS/4). А вот сорцы всяких системных компонентов, особенно SOM/DSOM/WorkPlace Shell это очень сильно-бы помогло в ускорении пиления опенсурсной полуоси… Ну и людей не хватает конечно.

В конце нулевых — начале 10-х фряха была очень популярна как серверная ось. Как-раз, по причинам, описанным автором статьи. В последнее время, как я вижу, для серверов выбирают centOS, Debian и Ubuntu. Почему фряха обосралась — сложно сказать. Насколько помню, в десятых годах активно находили уязвимости в ntp, openssl и проч. И фряха оказывалась крайне небезопасной при том, что обновление проблемных утилит в ней вызывало проблемы. Плюс, получили распространение лёгкие дистрибутивы типа CentOS. Их развёртывание и обслуживание было легче, чем развёртывание и обслуживание фряхи. А без популярности на серверах фряха, по сути, нафиг не нужна и её смерть — вопрос времени.

В определенный момент в linux все стало сильно лучше с драйверами и производительностью. Плюс с коммерческой поддержкой как итог интерпрайз голосовал рублем и переходил с коммерческих *nix на linux с коммерческой поддержкой.

Был админом в "нулевых" - модемные пулы, вот это все - "плавали, знаем". FreeBSD тогда была By default. У всех. 4.3 как сейчас помню. На 5-ку не переходили принципиально - FreeBSD 5 была чем-то вроде Windows Vista от мира винды

Не знаком с BSD, но мне кажется или у вас аргумент про 3 фаервола противоречит аргументу про отсутствие "зоопарка" утилит для одних и тех-же задач?

Их не обязательно все использовать одновременно, в отличие от того зоопарка. Точнее, никто и не использует обычно. Просто выбор.

Еще и DPDK на BSD не работает

Работает. Есть и статьи с этим опытом и даже просто на Wikipedia указывается поддержка FreeBSD и Linux. Про другие BSD не в курсе.

Справедливости ради — netmap появился на FreeBSD.

Ну он и появился от автора ipfw. Вот только его идеи не пошли дальше в штатный сетевой стек. В итоге стек Linux на ядрах 3.12 и 4.5 резко прогрессировал, а FreeBSD так и утилизируется на 100% при 100kpps syn-флуда.

Легкий наброс, bsd конечно ок, но сообщество в разы кислотнее, нежeли linux


ps: десктоп клиента для телеги даже на gtk так и не изобрели, запускают linux клиент в эмуляторе… это все, что нужно знать о будущем

Что? Официальный клиент как бы открытый, соответственно нативный с небольшим отставанием версий(и если так уж хочется свежий, можно руками собрать или из свежих портов).
bpftraсe автору не знаком, ну ок.
По наблюдениям — BSD заводится там, где сошлись звезды и несколько BSD-шников. Так оно в NetFlix, примерно так — в Juniper (там вообще дикая смесь под капотом).

Juniper переходит на Linux. Junos Evolved называется.

Холивар знатный конечно же. Весело. :) Давайте вспомним ещё, что PlayStation тоже на FreeBSD работает. Адепты фряхи ещё вспоминают давнишнюю историю с MacOS.
Если серьёзно, то шлюзы безопасности на всех предприятиях, где я работал или фрилансил, я всегда поднимал и настраивал на FreeBSD. PF — отличный пакетный фильтр.
Адепты фряхи ещё вспоминают давнишнюю историю с MacOS.

Apple как сосал, так и сосёт код из FreeBSD в свои OS. И в ядро тоже. Только особенно по теме не распостраняется. Информация об этом выдаётся только вскользь, как это было, к примеру, при обнаружении Meltdown / Spectre.

А еще они роутеры делали на NetBSD когда-то давно :-)

github.com/apple/darwin-xnu явно написано что там есть компоненты FreeBSD, но архитектура все же сильно отличается
А ещё есть чудесные pfSense/OPNSense.

Плэйсэйшон же

Очень плохо. Даже в NetBSD есть games.tar.xz, а во Free ничего нет :D
Wine есть(обычный, из портов можно собрать с -staging и dxvk, например), старые линуксовые работают, свободные нативно.
Не знаю насчет FreeBSD, но в OpenBSD c играми не так уж и плохо.
www.reddit.com/r/openbsd_gaming
BSD это целостные законченные ОС, разрабатывающиеся как единое целое.

А DE и программы входящие в KDE, Gnome, XFCE тоже сами делают?
Качество ПО BSD систем значительно лучше.

И по этому используют портированные программы?
А DE и программы KDE, Gnome, XFCE тоже сами делают?

На правах шутки:
они нужны только для
Поддержка всякого ширпотреба домашнего, ноутбуков, desktop-ов наверняка будет лучше.

На правах шутки:
они нужны только для

Да. Всего лишь для большинства компьютеров)))
В компании, в которой я работаю, соотношение один к одному. На один декстоп или тонкий клиент приходится один сервер.
А DE и программы входящие в KDE, Gnome, XFCE тоже сами делают?

Они относятся к FreeBSD так же, как к Linux(ну, конечно, с поправкой на популярность). При сравнении между двумя Unix-подобными системами класть весь общий софт для таких систем на одну чашу весов как-то странно.
НЛО прилетело и опубликовало эту надпись здесь

А зачем Вам контейнеры, какая задача, что дают?

НЛО прилетело и опубликовало эту надпись здесь

Вы знаете… контейнеры на сегодняшний день пихают как панацею от всего. Нестабильное приложение? Завернем в докер и будем перезапускать. Нет мультипоточности? Завернем в докер и напишем простой роутинг сверху. В приложении дыры в безопасности? Да и хрен с ним, оно в контейнере, дальше не выйдет.


Доходит до маразма, когда веб-сервер пихают в докер просто так, без причины. Почему? Потому что проще стало скачать готовый контейнер и поставить его одной командой (утрирую), заменив по сути виртуальную машину уменьшая накладные расходы.


Задач которых нельзя решить без докера — крайне мало и лично я всегда крайне скептически отношусь к тем людям которые предлагают поставить у нас на продакшн "небольшой контейнер" для решения каких-либо проблем. Лично у меня такие люди не нашли аргумента против "перепишите чтоб работало без сбоев" и варианта с jail (да, я тот олдфаг который поставил в свое время на фряху).


При всем при этом я не говорю отказываться от докера, упаси Гоги, но пока что в окружении своих знакомых, которые реальные админы крупных организаций и банков, а не как я, я не вижу острой потребности и мастхав. Вижу лишь а) тренд на контейнеризацию б) почему-бы и нет в) нагуглил решение не напрягая ганглий.

НЛО прилетело и опубликовало эту надпись здесь
Вот эта причина перекрывает все недостатки.

Это ничем не лучше, чем качать софт с торрентов, качать "левые" исходники и делать им make all && make install. Да, конечно, докер упрощает этот процесс и создаёт ложную иллюзию защищённости. Ну, и чуточку меньше мусора в хостовой системе. Поэтому он и популярен. Но есть платформы, вроде винды и мака, где докер все ещё плохо работает. А есть платформы вроде фрибсд, где в обозримом будущем нормально докера в принципе не будет. Поэтому говорить, что это панацея… Ну, такое себе.

НЛО прилетело и опубликовало эту надпись здесь

docker — не make ни разу.
Докер — это скорее замена deb/rpm/flatpack/snap.
В процессе сборки докер образ это именно целевой артефакт, а не нечто промежуточное. Тем более, если нужно деплоиться на разные целевые платформы.
Я уж не говорю о том, что докер ни разу не помогает в вопросах кросс компиляции.
Единственный плюс — действительно пайплайны сборки УДОБНО делать в виде докеров, т.к. среда сборки получается с фиксированными версиями компонентов. Так работают и гитлаб, и дженкинс, и concourse

НЛО прилетело и опубликовало эту надпись здесь
Докер — это скорее замена deb/rpm/flatpack/snap.

Докер на текущий момент — это обертка к рантайму containerd.
Я думаю вы имеете ввиду container image и он да, как раз замена пакета, по концепции весьма похожая на маковские пакеты, а snap так вообще очень и очень похож.
А что касается целевых платформ, то тут у контейнеров как у Ford-T с цветом — платформа может быть любой, если это Linux:)

Мне кажется странным, что снижение накладных расходов Вы характеризуете как маразм, да ещё и без причины. Я тоже против беспричинного маразма, но уместное снижение накладных расходов к этой категории, как мне кажется, не относится никак.

Для меня накладные расходы на докер существенны, по этому я сторонник оптимизации ПО.

НЛО прилетело и опубликовало эту надпись здесь
Amazon недавно представила новую вертку развития докера. Грубо говоря тонкий квм чтобы образы получили больше ресурсов.

Это не докер от слова совсем.

Без докера очень сильно возрастают расходы на подготовку инфраструктуры тестирования и разработки. С докером очень легко поднять для тестов всю нужную инфраструктуру прямо у разработчика на ПК/выделенном сервере. Без докера начинают плодиться самописные скрипты которые по сути делают тоже самое, но содержат дополнительные ошибки.

Замените слово докер на слово виртуальная машина — ничего не поменяется. Для девов держать машинку в зене и хайперви — никакой разницы, не те нагрузки и накладные расходы.

НЛО прилетело и опубликовало эту надпись здесь

Виртуальная машина не избавляет от настройки и возни так радикально как докер. Вам прежнему предстоит самостоятельно решать проблемы с получением актуальных образов сторонних сервисов. Порядке старта вртуалок и гашения их после тестов

орядке старта вртуалок и гашения их после тестов

докер, к сожалению, эту проблему тоже не решает.


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

В докере — то же самое. Идеальный сценарий — варить образы самостоятельно. И тут действительно разницы нет — варить образа докера docker build'ом со всеми его ограничениями или варить "золотой" образ виртуалки тем же hashicorp packer'ом.
Я уж не говорю, что только тот человек может говорить про проблему с образами, который не работал с Vagrant :-)

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

Вы сейчас про какую проблему?
Те образы, которые выложены на докерхаб — максимум тянут на образец. В них куча проблем. Есть официальные, но не для всего — и зачастую их конфигурация и подгонка под конкретную задача очень ограничена. Это примерно та же история, что и с deb/rpm — эксперты в написании программ редко являются экспертами в их упаковке. Ровно обратное тоже верно — в результате — мы для каждого дистрибутива линукса видим какие-то просто дичайшие патчи в каждом пакете

НЛО прилетело и опубликовало эту надпись здесь
Отвечу сразу вам и gecube в одном комментарии, вы очень похожие тезисы высказываете.
У меня есть некоторый опыт с FreeBSD (годика 3 в конце нулевых мы с ним очень плотно общались и после этого я из ностальгических соображений держал несколько серверов на нем, включая один домашний и до сих пор он кое-где у меня в хозяйстве есть), но по сути большую часть времени я все-таки работал с Linux, а с LXC познакомился на практике еще до того, как Docker появился, как раз будучи «админом крупной серьезной организации» и собственно до сих пор продолжаю в таких организациях работать, правда фин. организаций касался мало, не лежит у меня к ним душа ну совсем.
Так вот, история про «все в контейнерах» это примерно то-же самое, что история «все в jail-ах», только… удобнее.
Да, я не считаю, что все надо в них упаковывать, но когда речь идет о некоем «пользовательском приложении», то контейнер — это неплохой выход, потому что:
1. Удобно управлять:
— Стандартный интерфейс (docker/podman/что угодно еще), стандартные команды везде. Если сравнивать с джейлами — то в принципе то же самое, но есть человечесикий API с биндингами под все популярные языки. Да, джейлы тоже можно скриптовать, но на порядок (а то и больше) менее удобно, особенно с точки зрения управления жизненным циклом.
2. Удобно собирать и распространять:
— Собрать контейнер, упаковать его и отправить в хранилище очень просто.
— Не надо писать скрипты для установки, конфигурации и чистки.
— Само хранилище (считай репу) поднять просто или очень просто (одна команда на своем сервере/можно купить практически в любом облаке как сервис).
— Обслуживать хранилище аналогично просто (под ногами или FS, или S3 совместимый сторадж, который опять же можно поднять\собрать\купить совершенно без проблем).
3. Удобно версионировать:
— Нет мусора, контейнер — вещь в себе.
— Зависимости катаются вместе с приложением (да, оверхед, но это пока ничего несовместимого по системным библиотекам запускать не приходится, вот там и начинается веселье и ты готов хоть по 10гб качать каждый раз, лишь бы с этим не разбираться).
4. Легко для освоения. Да, это важно. После N-го объяснения о том, как правильно готовить пакет\порт и как готовить окружение для этого, начинаешь прям задумываться над тем, как этого избежать. В итоге, инструкция вида «базовый контейнер вот этот, контейнер для сборки софта на языке $langname вот этот, после сборки все копировать вот в эту конкретную папочку, вот тут вписать команду для запуска» выглядит гораздо менее сложно и потенциала для выстрела себе в ногу меньше.
5. Безопаснее. Стоит пояснить, что контейнер сам по себе нельзя считать 100% изоляцией, там мест для накосячить более чем достаточно, да и сама по себе технология контейнеризации не совсем про безопасность, но тем не менее:
— Удобнее контролировать версии и выкатывать security-патчи. Тебе не нужно следить вот прям за всеми всеми версиями всего ПО на каждой машине, тебе просто нужно знать, что работает вот такой-то контейнер с таким-то тегом, который можно просканировать один раз и так же один раз централизованно поменять, пересобрав от него остальные контейнеры и контролируемо выкатить везде где нужно без риска замены версии библиотек под ногами. На самих же хост-машинах стоит минимальный набор ПО, который опять же легче контролировать, чем если бы там стояло все то, что тянет пачка приложений.
— Уже упомянул, но — можно удобно после сборки, но до деплоя, гонять всякие security-сканеры поверх образа для поиска известных уязвимостей, причем делать это ровно один раз, т.к. есть гарантия что контейнер не поменяется (по крайней мере, не должен, а если поменялся в процессе выполнения там, где не должен был, то вообще это повод посмотреть на то, все ли впорядке).
6. Побочные удобства:
— Логи и ротейт (можно сказать девелоперу «пиши все в stdout/stderr, а дальше не твои проблемы, все уедет куда надо») и настраивается это один раз, а не для каждого приложения.
— Удобно откатывать версии (хвостов не отстанется, проблем с совместимостью не будет).
— Есть мощные оркестраторы вроде K8s, которые дадут еще миллион всего, от дискавери до сложных деплоев и распределенного крона до (через плагины) сетевых полиси, дополнительных изоляций и системы управления релизами.
Вообще, нет ничего страшного в том, чтобы «накатить контейнер в прод», это не отменяет требований к качеству того, что там внутри контейнера будет работать, но многие вещи это и правда может порешать и сильно ускорить.

Что же касается «админа локалхоста», то контейнеры в первую очередь удобны для сборки (можно в разных окружениях все что нужно посмотреть, разные версии компилятора и библиотек проверить\попробовать, зависимости постоянно ставить не надо и т.д.) и для использования того софта, который не компилится в бинарь (все что угодно на python/node, допустим). Небольшая магия с алиасами и контейнерное приложение работает как обычно, но все свои зависимости держит при себе. И обновляется удобно. Хотя, такие решения и без контейнеров конечно же существуют.

Не буду спорить — докер удобен, но затыкать им каждую дыру, как это делают сейчас, совсем скоро будет моветон.
По пунктам мне немного сложно ответить, потому как я не настоящий админ, но отвечу так: Все эти плюсы — по сути есть плюсы кастрированной ВМ до размера приложения со всеми плюшками и карасями. Для меня это выглядит примерно одинаково, за исключением накладных расходов. Это бесспорно плюс и все что вы написали я не буду отрицать, это отличные решения и каждый из этих пунктов я так или иначе использую.


Может я становлюсь скрягой (сейчас пойдет поток мыслей) — но для меня это нарушение принципов линукса и даже принципов KISS — мы имеем блакбокс, который, как правило, за нас настроили и выложили другие люди, мы его качаем и донастраиваем. Мы это делаем зачем? Потому что иначе задачу решить будет сложней. Тогда чем это отличается от тупого копипаста команд из гугла и тыканьем в слепую, вместо понимания как оно работает? Ок, на деве можно, но на продакшне я хочу точно знать что у меня и как.
Лично для меня, но я не навязываю, более близок путь с собиранием софта под свои нужды во фряхе из портов с отключением ненужного функционала.

Не хочу сильно вдаваться в спор. В целом, все что пишете — относительно верно. Проблема только лишь в том, что дьявол в нюансах. Вот скажите — зачем нужен докер, если можно катить в облако виртуалками? Мы же все прекрасно понимаем, что один сервер — много сервисов — это плохо. Да, конечно, если хочется гонять стейтлес и максимально уплотнять ресурсы — тут контейнеризапция вне конкуренции, но это явно не история про БД, хранение и что ещё стейтфул. Базы вообще очень не любят делить ресурсы с кем бы то ни было ещё. Для тестовых контуров — конечно, пофиг.
К тому же, докер — это про контейнер приложения. Со всеми вытекающими. Поэтому в админстве для долгоживущих задач хорошо зашёл lxc/lxd. Я очень долго со скепсисом относился к этой технологии, но знаю немало примеров ее удачного внедрения.


Оркестратор — сюда приплепать вообще излишне, т.к. под капотом у него может быть что угодно. Вон — коллеги уже разрабатывают легковесные виртуалки на базе firecracker и аналогов, чтобы решить часть проблем докера. А что оркестрировать — вообще по барабану. Кубернетес в целом позволяет писать адаптеры к чему угодно. Просто так исторически сложилось, что эта система началась как оркестрация контейнеров…


В общем, я к чему. Докер в зависимости от контекста — может быть от "великое благо" до "ненужный компонент". Нужно смотреть по своим задачам и по своей инфраструктуре.

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

Не совсем так. Но даже если так, то вообще нынче принято базы брать как сервис, если уж у нас облако. При этом — само наличие контейнера совершенно не определяет то, будет ли у нас этот контейнер один на машине или их будет сотня. Даже если он будет один, то все плюсы в целом присутствуют (как в общем то и минусы).
К тому же, докер — это про контейнер приложения. Со всеми вытекающими.

Не очень понятно про какие вытекающие вы говорите. К тому же конктерно containerd позволяет очень много штук, включая достаточно гибкое управление контекстом. Про то, что сеть может быть любая (хоть своя, хоть хостовая) я думаю и так понятно.
Докер в зависимости от контекста — может быть от «великое благо» до «ненужный компонент».

Безусловно. С одной пометкой — у контейнеров весьма широкое применение (настолько широкое, что принципы контейнерной дистрибуции живут уже черт знает сколько лет в mac os и на них основан snappy) и вариантов использовать его реально странно (ну, роутер там сделать внутри контейнера) не так много. В остальных случаях он не хуже обычного apt-get/dnf/yum/pkg install.
Вообще, мне кажется очень влияет масштаб. Пока мне приходилось работать с единицами и десятками серверов и приложений на них — вроде как все было неплохо и без него и вообще можно походить пособирать каждое приложение отдельно вдумчиво руками.
А вот когда серверов уже десятки, приложений сотни и релизы катятся один за одним — вот тут контейнеры очень даже в тему. Можно на виртуалках где-нибудь в AWS/GCloud/Azure, да, но контейнерами выходит проще и дешевле.
Не очень понятно про какие вытекающие вы говорите.

Проведите сравнение LXC vs Docker. Контейнер приложений хорош, когда у вас своя собственная разработка. Делаете FROM scratch, запихиваете минимально необходимый набор библиотек — и полетели. Потому что в противном случае получаются монстры по 1,5ГиБ — практически полное окружение операционной системы со всеми служебными утилитами и всем прочим. С другой сторону, это не отменяет удобство дистрибуции. Ну, и контейнер докера — это эфемерная, короткоживущая сущность. Он не предназначен для того, чтобы долго работать — отсюда история с эфемерными слоями, их быстродействием, необходимостью выносить данные наружу, в volume.


само наличие контейнера совершенно не определяет то, будет ли у нас этот контейнер один на машине или их будет сотня.

Несомненно. Но как я выше указал — абстракции имеют тенденцию течь. И какой-нибудь ресурсоемкий контейнер может украсть ресурсы (cpu, ram, iops, ядерные ресурсы — всякие inotify, dentry...) у менее ресурсоемких контейнеров. И все будет работать из рук вон плохо. Да, виртуалки тоже подвержены этому, но там распределение ресурсов более честное и поэтому для них эта проблема стоит менее остро. Лимиты на контейнеры спасают, но только очень отчасти.


А вот когда серверов уже десятки, приложений сотни и релизы катятся один за одним — вот тут контейнеры очень даже в тему.

Еще раз — зависит от инфраструктуры и задач. Сами же признаете, что можно катиться виртуалками.


выходит проще и дешевле.

А еще проще и дешевле перейти на Serverless и NoOps :-) Ничего, что при этом эксплуатационные расходы могут быть огромными, но народ про это узнает тольно на масштабе, зато стартапы могут быстро стартовать )

Потому что в противном случае получаются монстры по 1,5ГиБ — практически полное окружение операционной системы со всеми служебными утилитами и всем прочим.

Это кстати не очень критично при условии, что все твои контейнеры собраны на базе одного образа. Этот слой не перекачивается и не множится, а просто линкуется.
Он не предназначен для того, чтобы долго работать — отсюда история с эфемерными слоями, их быстродействием, необходимостью выносить данные наружу, в volume.

Так это же наоборот прекрасно. Идея про «попишу-ка я куда нибудь в непонятное место, ну, в рут, допустим» — она плохая. Я достаточно повыковыривал данных с машин где куча софта и непонятно где что лежит, чтобы только радоваться такому подходу. Ограничения вроде «пиши только вот сюда, остальное будет как минимум потеряно, а так то еще и тормозить будет» на практике очень помогают не разводить хаос.
Ничего, что при этом эксплуатационные расходы могут быть огромными, но народ про это узнает тольно на масштабе, зато стартапы могут быстро стартовать

Ну под них надо архитектуру готовить и внимательно считать. У меня есть некоторый опыт в этой области и я продолжаю его набираться и если хорошо подумать можно реально сделать дешево как раз с точки зрения эксплуатационных расходов (просто их считать надо правильно, учитывая все расходы обоих решений). Это кстати интересная тема. В пересчете на время выполнения serverless конечно дороже, чем просто приложения.
Но, стоимость человека, который поддерживает окружение тоже ненулевая (более-менее приличный девопс нынче в Европе стоит от 65к евро в год, а их поидее надо два, bus-factor и все такое), с серверлесом поддерживать нечего и он поидее особо и не нужен. Я если что девопс, так что себе яму копаю:)
Отсюда и возникает вопрос — в какой момент существования разница оверпрайсе serverless под большими нагрузками привысит 130 тысяч евро относительно решения на своей инфраструктуре.
Это кстати не очень критично при условии, что все твои контейнеры собраны на базе одного образа. Этот слой не перекачивается и не множится, а просто линкуется.

А образ собран из 10-15 других образов :) В итоге толщина слоя веселит и бодрит.

Вы обсуждаете разную контейнеризацию. Docker — контейнер приложений (application container), LXC/LXD/OpenVZ/Jail — системные контейнеры (system container). Сделаны по-разному и для разного.

Спасибо, кэп, но это не отменяет того, что у указанных технологий пересекаются сферы применимости.

Они пересекаются технологически, но не идеологически. Docker не подходит и не предназначен для контейнеров с большим количеством демонов, как и не подходит LXC/Jail для запуска одной единственной программы, предварительно установив туда всю ОС.

Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
Иногда и 1 приложение затрагивает данную проблему. В частности, если что-то написано под systemd, оно не работает в докере. Точнее, нужно много приседаний по запуску подрезанного systemd, и только тогда оно начинает работать. Названия не могу вспомнить, но несколько лет назад в прошлой компании сталкивался с таким софтом.
Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.

В сознании обывателя — докер понятнее и удобнее. Те же докерфайлы, возможность сгружать готовые образы в стандартном формате из докерхаба или любого совместимого хранилища… К сожалению, ни nspawn, ни lxd не создали такую широкую экосистему… Поэтому и понятное желание пихать докер в любую дырку. Ну, и подогрело это все оркестраторы вроде кубернетеса — в которые тот же nspaws/lxd положить можно, но это надо самому писать необходимые прослойки и модули, а докер — вот он, из коробки

Я собираю образ сервиса и запускаю его для k8s и у пользователей на компах.
Особенно это критично когда нужно с Python пакетами работать на компах, а на в «Клауде». Тут даже virtual environment не поможет для компов на Виндовс, МакОс и Линукс.
А почему заоопарк?
А потому, что на Винде пользователи PowerBI и других программ. На Маке — как бы стандарт. А на Линуксе — продвинутые.
> Без приуменьшения — любая задача
Как это любая?
Порисовать в гимпе — нужен докер?
Установить самбу или апача — нужен докер?
И как это я всю жизнь всё это и всё остальное делал без докера… (из которого знаю только слово докер)
НЛО прилетело и опубликовало эту надпись здесь
Уже есть flatpack, да-да именно для этого, установки пользовательского софта в контейнерах. Это призвано как-то компенсировать проблему фрагментации Линя для разработчиков, ну и все остальные фишки контейнеров бонусом.
Докер это рак. Просто примите это как данность. Почему? Окей расскажите мне как вы через лет 5-10 будете софт ставить? Из того же контейнера? Ну он например может не заработать и надо будет изменить окружения софта. Или например вам надо обновить ПО. Тоже будет боль и страдания. Нельзя привязываться к конкретному окружению это путь в никуда.
НЛО прилетело и опубликовало эту надпись здесь
Ухудшил. Я все чаще встречаю софт который имеет инструкции поставьте наш контейнер. Остальное просто игнорируется. И это не про коммерческий софт, а про opensource. Причем часто чтобы запустить в итоге без докера может потребоваться куча не тривиальных движений. Потому что установка через docker первична, а как оно там без докера работает нас не волнует.

Гниение софта это вообще отдельная боль и печаль, но банальный configure и make работают заметно лучше и портировать или починить софт проще чем вынуть его из докера.
починить софт проще чем вынуть его из докера.

Ну, я не согласен. Смотря что Вы понимаете под вынуть из докера. Перенести в ДРУГУЮ песочницу — типа chroot или systemd nspawn? Да не проблема. Работоспособность софта пострадает? Нет! А дальше можете весь этот чрутованный пакет точно так же превратить в rpm/deb и доставить на целевую машину. Здесь просто происходит смена парадигмы — раньше мы действительно пытались зависеть от того какие пакеты сидят в системе, но по определенным причинам — это действительно сложно. Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.

Проблема в том что приложение которое оттуда вынули ставится своим набором костылей и без зависимостей, потом при переносе можно долго их разматывать.

В случае если приложение просто ставится локально попроще все же.

Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.

Вот я про это и говорю. А это всплывает не сразу, а через 5-10 лет что выливается в сложности при размотке контейнера.
В случае если приложение просто ставится локально попроще все же.

Именно поэтому докер должен быть одним из вариантов дистрибуции, не единственным.

НЛО прилетело и опубликовало эту надпись здесь
Это проблем докера. Я уж молчу что фактически докер привязывает нас к одной платформе. make кстати в большинстве случаев позволяет легко адаптировать его и под другую posix платформу. Докер нет. Если вы мне тут начнете рассказывать про докер в windows то я напомню что он там работает не поверх нативного слоя. Дополнительно докер контейнер банально бинарная сборка и допустим x86 на x86_64 я запустить могу, то вот на mips и arm ой. Нужен отдельный docker.

Докер провоцирует собрать в него, так же разработчику удобнее. Но это аукнется потом, когда потребуется перенести куда-то еще и контейнер там просто не работает и все.
Я очень извиняюсь за собственную категоричность, но судя по вашим суждениям вам никогда не приходилось деплоить пару десятков приложений в десятках и сотнях экземпляров как минимум в 2 разных места хотя бы 2 раза в день. Искренне желаю вам удачи повозить кругом свой код и поделать make на каждой машинке.
Все это «у меня make не ломается» и «а вот тут я могу запустить сборку под другую архитектуру, а тем не могу» в подавляющем большинстве практических задач просто не имеет никакого смысла. Разнообразие архитектур у конкретного бизнеса обычно минимально. Особенно если говорить об одном и том же приложении.
И кстати да, докер есть допустим под arm и да, под него можно собрать контейнер и это даже будет работать. Собрать 1 раз. И запустить за пару минут в любом месте.
Тут же все очень просто — если есть подходяще написанный код и руки, то никакой докер не помешает собрать приложение под другую архитектуру. Он никак не привязывает. Результирующий образ вполне может собираться командами make. А где этот make запускать — дело десятое.
Но — подавляющее большинство серверов на x86_64 и да, разработчик просто не заморачивается.
никогда не приходилось деплоить пару десятков приложений в десятках и сотнях экземпляров как минимум в 2 разных места хотя бы 2 раза в день.

Нет не приходилось. Но вообще говоря ребята если вы два раза в день в двух разных местах постоянно что-то деплоите да еще и на рабочее то боюсь у меня для вас плохие новости :)

А вот деплоить на много узлов кучу всякого софта на протяжении нескольких лет приходилось. И в этом случае делаем сборки для deb или rpm пакетов и свой репозиторий. Этот подход стар как мир и работает ничуть не хуже. И на дальней дистанции даст более стабильный и предсказуемый результат.

Плюс у докера есть одна маленькая проблема. Разработчики так и не смогли решить задачу один контейнер один процесс. До сих пор есть случаи где оно не работает. Ладно в podman сдались и подпихивают туда systemd :)
НЛО прилетело и опубликовало эту надпись здесь
Влямывались пару раз в адд зависимостей.

Надо уметь готовить, как и докер. С докером можно к примеру собрать контейнер так что он будет весить крайне дофига. Недавно тут пробегала статья про то что люди собирали докер под питон на базе дистрибутива musl и забывали дропнуть зависимости сборочные после сборки. В итоге дистрибутив раздувался больше обычного на базе ubuntu.

Плюс с докером люди забывают про безопасность. Если в случае долгоживущей машины мы имеем возможность обновлять пакеты и исправлять уязвимости, то в случае docker окружение застывает в том виде в котором его поставляли. И ой.
НЛО прилетело и опубликовало эту надпись здесь
Докер готовить проще. И судя по рынку — дешевле по зарплате.

Готовить проще. Главное под капот не заглядывать.

Это не правда. Более того, именно вопрос безопастности окружения делает докер лучше в перспективе.

С докером маинтейнер отвечает за весь образ. Если зависимость в его образе дырявая — это его отвественность изменить контейнер.

Именно что придется менять весь контейнер

Если в dpm у вас есть зависимость с дыркой — то это проблема юзера играться с покетменеджером, чтобы вытащить версию зависимости без дырки.

Если вы используете поддерживаемый дистрибутив достаточно обновлять пакеты. Это в свое время один товарищ просил мне надо самый свежий openssl. Я спросил, а кто будет мониторить дырки в нем и обновлять его? В случае дистрибутива это делают люди которые его сопровождают и делают они быстрее тебя и меня.

Про замораживание. Это действительно проблема докера. Но она решается не на уровне самого докера, а на уровне софта который билдит. Уже пару лет назад начали работать над софтом, который позволяет пересобрать все свои контейнеры, при обновлении базового (или какого-то ниже) слоя.

Докеру как технологии уже скоро будет 7 лет. И только сейчас это заметили ага.

одна из вещей, которые докер заставил учить большинство программистов — как сделать долгоживущий _сервис_ у которого под капотом коротко живущие виртуалки. Эта такая же смена парадигмы мышления/программирования — как и переход к многопоточности.

Это вы про микросервисную архитектуру? Она как подход стара как мир. Смотрим микроядерные операционные системы. Подход идентичен. И проблемы кстати тоже идентичны :)
Это в свое время один товарищ просил мне надо самый свежий openssl. Я спросил, а кто будет мониторить дырки в нем и обновлять его?

К сожалению, это работает только до момента, пока внешний API этого OpenSSL остается тот же. Как только в связи с уязвимостью меняется внешний API — вы попадаете как минимум на рекомпиляцию своего зависимого проекта, а в худшем случае — переписывание части вызовов (а здесь — да, нужна квалификация)

Используете LTS дистрибутив и не имеете проблем, понятное дело потом LTS завершается, но тут внезапно вам уже точно пора переезжать на новое API.
Ночью обновился pandas и штатный numpy в CenOs стал непригоден на серверах, которые накатываются ночью.
И мы на можем использовать имидж — так как не можем его построить и не сломать установку от Амазона на EMR.
А в докере нет такой проблемы — вообще.
Но вообще говоря ребята если вы два раза в день в двух разных местах постоянно что-то деплоите да еще и на рабочее то боюсь у меня для вас плохие новости :)

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

У вас зависимости правда никогда не ломались? А два приложения один и тот же пакет разных версий не просили? И скрипты чистки из пакетов не фейлились? Но вообще, на счет «предсказуемости результата» я с вами согласен — рано или поздно придется все это очень геморно чинить, когда apt в очередной раз внутри сломается и «ой, не могу завершить транзакцию, пойду еще упаду на откате, все, замечательно, теперь готово» или начнет приезжать два пакета и один будет откатывать версии зависимостей другого.
Разработчики так и не смогли решить задачу один контейнер один процесс.

Эм что? Тысячи образов собраны from scratch и работают себе спокойно. Есть вопрос про init, а точнее про правильную обработку сигналов, но тут во многом беда именно приложений внутри, которые могут вести себя несколько странно, поэтому подставляется костыль именно для приложений.
Если у вас есть яркий пример, когда что-то не работает именно по причине докера — ссылку в студию, пожалуйста.
Вы лучше эту новость передайте FAANGу, Яндексу и тысячам других компаний с распределенными системами и тысячами собственных приложений, я думаю они тоже захотят узнать столь плохую новость и перестать так делать.

В большой компании этот процесс разделен и разнесен между командами. И одна команда там за день под два раза в день в свой рабочий проект не деплоит. Если же деплоит то им весьма скоро расскажут как это плохо.

У вас зависимости правда никогда не ломались? А два приложения один и тот же пакет разных версий не просили? И скрипты чистки из пакетов не фейлились?

Конечно ломались и я это все фиксил не раз. Но тут есть интересный момент, эти проблемы специфичны только для deb дистрибутивов. В rpm дистрибутиве такое поймать намного сложнее. Потому что там используется транзакционный подход и это позволяет не ломать систему.

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

Именно про это. И костыль кстати не всегда срабатывает как надо. Это просто сломано by design. Самый правильный вариант сделан был в podman где просто сдались и положили туда systemd.

С точки зрения дизайна в podman все сделано лучше. А уж про сетевую систему в docker промолчу :)
В большой компании этот процесс разделен и разнесен между командами. И одна команда там за день под два раза в день в свой рабочий проект не деплоит. Если же деплоит то им весьма скоро расскажут как это плохо.

Во-первых — какая разница, разнесено оно между командами или нет, если инфраструктура общая.
Во-вторых — и одна команда может деплоить на прод несколько раз в день легко. Есть же еще Canary, A/B тесты и вот это все.
В rpm дистрибутиве такое поймать намного сложнее.

Ломается сильно реже, да. Но проблемы с зависимостями остаются, как вы говорите, by design.
Это просто сломано by design

«Сломано разработчиками при написании софта» вы хотели сказать? Оно и без докера ломаться будет, если запускать то же приложение напрямую, без надстроек в виде базового процесса, который проконтролирует и перехватит сигналы. Это не в докере плохо все, это просто докер вскрыл проблему, потому что способ запуска изменился и о нем до этого никто особо не думал по вполне понятным причинам. А вот systemd в контейнере это конечно такое себе… излишнее, хоть и закрывает проблему.
С точки зрения дизайна в podman все сделано лучше.

Возможно. Частично. Правда при сборке контейнеров хэши слоев считает неправильно, что ломает его использование с некоторыми реджистри. А так да, все прекрасно.
Что касается «сетевой подсистемы» в докере, там все просто как топор. Хотите сложно — есть плагины.
Вообще, докер сам по себе далек от идеальной имплементации, но мы же не имплементации обсуждаем вроде, а саму концепцию.
Во-первых — какая разница, разнесено оно между командами или нет, если инфраструктура общая.
Во-вторых — и одна команда может деплоить на прод несколько раз в день легко. Есть же еще Canary, A/B тесты и вот это все.

Не мешайте все подряд, тестовую и продакшен среду разделяют. Иначе тестами можно легко положить часть прода. Что не приятно.

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

Оно и без докера ломаться будет, если запускать то же приложение напрямую, без надстроек в виде базового процесса, который проконтролирует и перехватит сигналы. Это не в докере плохо все, это просто докер вскрыл проблему

Это не докер вскрыл проблему, а сам себе создал. А теперь изображают что проблема была.

А вот systemd в контейнере это конечно такое себе… излишнее, хоть и закрывает проблему.

Нормальное это решение. Иногда бывает удобнее запустить пачку процессов просто внутри одного контейнера вместо создания группы и пачки контейнеров. Зависит от.

Что касается «сетевой подсистемы» в докере, там все просто как топор. Хотите сложно — есть плагины.

Ага правила в iptables пишем. Именно, что топорно и на костылях. Лучше кстати сделано в lxc.

Вообще, докер сам по себе далек от идеальной имплементации, но мы же не имплементации обсуждаем вроде, а саму концепцию.

У него и с первичной концепцией проблемы. Он должен был обеспечивать init процесс сам, а по факту получился ой и systemd в качестве прослойки.
Не мешайте все подряд, тестовую и продакшен среду разделяют. Иначе тестами можно легко положить часть прода. Что не приятно.

Причем тут разделение тестовой и прод среды? Вы точно понимаете, что такое A/B и Canary, или вы просто увидели слово «тесты»? Если вкратце — это все тестирование на проде в том числе.
А то что сейчас деплоят через контейнеры в итоге вылилось что админам приходится мутировать в девопсов.

Хорошие админы всегда умели и код писать немного, и сложные штуки автоматизировать. Концептуально ничего не поменялось.
Это не докер вскрыл проблему, а сам себе создал.

То есть приложений, запускаемых напрямую без инита и умеющих так жить до докера не существовало? Любопытно…
Зависит от.

От умения готовить контейнеры. Технически — можно, практически — антипаттерн. Нет никакой проблемы запустить два контейнера в общем контексте без всякого инита.
Лучше кстати сделано в lxc.

Лучше это как? Там или тот же бридж, или самосборная виртуальная сеть с натом, который опять внезапно в iptables.
У меня создается ощущение, что вы современные контейнеры то знаете так себе, но действуете по принципу «не читал, но осуждаю».
Он должен был обеспечивать init процесс сам

Кому должен? Где это было написано? SystemD там получился только в одной из имплементаций контейнеров (даже не в докере), а так да, встроенный tinit добавили для тех приложений, которые плохо без него живут.
То есть приложений, запускаемых напрямую без инита и умеющих так жить до докера не существовало?

В *nix нет. Всегда запускалось ядро, затем первый процесс. Все остальное запускалось им или через него. В случае проблем он же убирает или не убирает мусор.

Технически — можно, практически — антипаттерн. Нет никакой проблемы запустить два контейнера в общем контексте без всякого инита.

Бывают случаи когда это быстрее. То что это антипаттерн в рамках докера понятное дело.

Там или тот же бридж, или самосборная виртуальная сеть с натом, который опять внезапно в iptables.

Там заметно больше вариантов. И бридж и p2p есть вообщем поиграться там есть с чем. Ну и одно дело когда у вас там пара правил, другое дело когда на каждый порт проброс пишется.

Кому должен? Где это было написано? SystemD там получился только в одной из имплементаций конейтеров (даже не в докере), а так да, встроенный tinit добавили для тех приложений, которые плохо без него живут.

В концепции самого docker. Я беру запускаю приложение в контейнере и в ус не дую. И как оно запускается меня волновать не должно. А по факту получается что если не дай бог оно форкается по старинке то все плохо :) Если как-то порождает процессы и умирает тоже. В итоге подкладываем прокладочку через которую запускаем и получаем обычный контейнер. Который был до этого. Это меня скажем печалит.
Там заметно больше вариантов. И бридж и p2p есть вообщем поиграться там есть с чем. Ну и одно дело когда у вас там пара правил, другое дело когда на каждый порт проброс пишется.

либо используйте host network и не ломайте голову. Бридж реально под нагрузкой очень проседает и латентность в космос. А изоляция по сети между проекта докера… на самом деле такая большая фикция

Контейнеры они не для изоляции, а для удобства :) Как показала практика даже виртуализация хорошо пробивается.
НЛО прилетело и опубликовало эту надпись здесь
Чему Эпол сопротивляется? Макось — это итак Юникс, они стабильно подтверждают это каждый раз сертификатами, а так же соответствию POSIX, там определенно никто не будет делать бинарной совместимости с линуксом как в винде, никогда. Разработчики сами портируют свой софт на макось для удобства разработки, а докер под макось есть, официальный, посредством виртуализации через HyperKit. Оно куда медленнее нативной работы под линуксом, но и задачи у него другие.
НЛО прилетело и опубликовало эту надпись здесь
Так hyperkit это собственная разработка докера, оно надстройка над hypervisor.framework. Я использовал какой-то экспериментальный гипервизор на базе встроенного hypervisor.framework veeamu veemu как-то там, весил всего несколько мб, видно что минимальная надстройка и глючный, но десктопные ОСи работали там шустренько.
НЛО прилетело и опубликовало эту надпись здесь
С докером я редко работаю, для единичных случаев у меня проблем не было, может если там какой-то swarm разворачивать… Но от коллег часто слышу претензии что докер очень медленно работает на маке, думаю ситуация никак не изменилась.
Я про то что сборка бинарная. А если это единственный метод получить ПО то мы приплыли. Даже если софт не питоне сделан, а контейнер будет содержать бинарное окружение. Для запуска придется или пересобрать контейнер, если для него опять же доступен файл сборки или ковырять руками.

Закон Мура умер как только у нас появились двуядерные процессоры. Вы правда думаете что многоядерность от хорошей жизни? :))
НЛО прилетело и опубликовало эту надпись здесь
Часто исходники доступны и их можно собрать в том числе и под другой дистрибутив, с довольно минимальными правками. Это я вам как человек который регулярно занимается всяким бекпортом и сборками говорю :)

Ну а многопоточность конечно улучшают, нужно же чтобы это требовало меньшей квалификации от программистов.
НЛО прилетело и опубликовало эту надпись здесь
Не для всего и не всегда. Плюс когда докер является первичной упаковкой у нас возникают проблемы при отклонении от базового окружения. Программистам конечно проще один раз окружение настроил завернул в докер и раз везде работает.

А мне например понравилось юзать jails в FreeBSD вместо Docker на Ubuntu.
И софтверный RAID6 на ZFS для домашнего сервера очень зашёл.
Но на десктоп ставить это уже мазохизм/энтузиазм

Простите, но как же можно сравнивать Jail c Docker-ом ???
jail — FreeBSD-специфичная контейнерная виртуализация. Аналоги в Linux — chroot, OpenVZ, LXC и кучка устаревших/проприетарных технологий. Аналоги, кстати, куда более продвинутые, в отличии от Jail, где не поддерживается ни квотирование/лимиты толком ни миграция ни… впрочем, этого достаточно.
Docker — «система быстрого деплоя с клиент-серверной архитектурой» (простите за вольный перевод), в качестве контейнерной виртуализации использующая Linux LXC/cgroups, так же имеющая «на борту» еще кучу других сущностей…

CBSD

> Но на десктоп ставить это уже мазохизм/энтузиазм
Если не требуются «принтеры да сканеры», то для десктопа фряха уже давно — годная система. А для подключения к ней принтера бубен пока ещё нужен…

Я ожидал более подробной статьи

Вот так и я. FreeBSD — моя любовь навсегда, ставлю, когда могу, на сервера, новые выпуски тереблю в виртуалке, пытаюсь ставить на каждый новый ноут как десктоп-систему (ни разу успешно — железо не имеет драйверов). А работаю в основном с Linux.


Запустил бы jail и радовался, но нет, приходится жрать docker, подавляя рвотный рефлекс, потому что он нужен клиенту


Фряха форева, что уж

Вы обсуждаете разную контейнеризацию. Docker — контейнер приложений (application container), LXC/LXD/OpenVZ/Jail — системные контейнеры (system container). Сделаны по-разному и для разного.
По применению OpenVZ и Jail имеют гораздо меньше общего, чем Jail и Docker

А деление довольно условное
Наверняка любой пользователь сталкивался с тем, что система или перестаёт отвечать/работать при нехватке памяти

Ага, при исчерпании памяти на диске система (Ubuntu 18.04) постоянно перезапрашивает пароль при входе в систему. :)

P.S. Лечится очисткой жёсткого диска для не нулевого размера доступного пространства, например, загрузив какой нибудь LiveCD.
init=/bin/bash
и не нужны никакие livecd.
Ctrl-Alt-F2 и ваши волосы становятся мягкими и шелковистыми.
И чем поможет возможность зайти другим пользователем?