Комментарии 393
Обожаю эту ось, к сожалению они уступили линуксу на волне хайпа и не смогли в виртуализацию(bhyve и jail только).
www.bsdnow.tv/337
bastillebsd.org/templates
Прекрасная система от Олега Гинзбурга, активно живущая и с развивающимся сообществом
www.bsdstore.ru
— FreeBSD: гораздо лучше GNU/Linux
— чем лучше?
— чем GNU/Linux…
BSD: Уже 12+ лет имеет надёжную работающую ZFS реализацию.
Linux: До сих пор production ready ZFS нет.
А теперь барабанная дробь — BSD переезжает на кодовую базу ZFSonLinux, который теперь OpenZFS.
Наверное, потому что и не прикладывал: вот рекламная ссыль на 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
Или вы о чём?
Похоже, ввёл всех в заблуждение, извиняюсь.
Вы долго эту чушь "про переезд на кодовую базе 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 в линкксах не пользуюсь поэтому не знаю…
Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.
Идут споры о совместимости — несовместимости лицензий: 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 в таком огромном
проекте это благо. Это и ускоряет компиляцию и линковку, и упрощает поддержку, так как чем меньше функций доступных извне данной единицы трансляции тем меньше межмодульных связей, и думаю очевидна польза от уменьшения связанности огромного проекта?
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_NOTIFIERS=yCONFIG_PREEMPT_NONE тоже годится, особенно для сервера
p.s. кстати, дело c «нелюбовью» не только в лицензии, но и в идеологии комбайн (aka Rampant Layering Violation?) vs модульность
Какой-либо унификации документации, конфигурации, вывода информации в софте толком нет. Всюду и везде будет явно и отчётливо видно, что вот эта небольшая программа/утилита написана одним человеком, а вот эта другим.
Как-то притянуто за уши. Кроме базовых утилит набор-то софта у обоих одинаковый. От GNOME до Wireshark, от mongodb до nginx все же одинаковое. Или разработчики *BSD для всех этих тысяч популярных проектов с открытым кодом дописывают документацию, переделывают им формат конфигов и так далее? Почему-то я очень в этом сомневаюсь.
Например, есть доклад от 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 не даром её из кодовой базы выпил к чертям.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.
Отнюдь.
Меня смущает что вы, видимо, считаете что ZFS хорош только на серверах. Так вот нет. Boot environments и snapshots, не говоря уже про надёжность хранения, чрезвычайно полезны и востребованы и при персональном использовании.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Честно говоря мне лень, но вы найдёте. Там реальный "адъ и Израиль".
UPD. По-моему это был тред про NAS.
он не совсем про zfs
https://forum.ixbt.com/topic.cgi?id=109:382
и плюс тут интересная информация есть
https://forum.ixbt.com/topic.cgi?id=109:310
Часто ОС и даже конкретный дистрибутив в компаниях выбирается исключительно под знания, навыки и вкусы имеющегося персонала.
Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.Когда-то работал в конторе обслуживающей кроме всего прочего почтовые и веб сервера в коммерческих конторах. Линукс не использовался вообще. Почта, прокси, маршрутизация и проч связанное с сетями — 100% FreeBSD. Сейчас поинтересовался у коллеги — ситуация та-же самая.
Что греха таить, домашний NAS/сервер живет у меня с 98-го года под FreeBSD, но в 2016-м одна очень нужная софтина не захотела ставиться не под каким соусом и психанув, поставил Ubuntu, тем более, что десктоп у меня уже с ~2010 под ним же. Не буду описывать причины, что бы не скатываться в субъективизм, но с начала 2019-го сервер вернулся под управление FreeBSD. При этом на десктопе отказываться от Линукса пока не собираюсь.
У меня вон есть серверы на SUSE Linux, первом выпуске. Тоже еще работают. Сколько им лет? 15?
Убунту это не серверная среда. Смысл ее ставить на сервер, а потом использовать как аргумент.
Имхо FreeBSD просто сильно заигралась. Никому не нужно такой ценой идеальность.
Что касается серверов на 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
27 октября будет релиз 12.2.
Most Recent Releases
Production Release
Release 12.1 (November, 2019)
Release 11.3 (July, 2019)
11.3 вполне Ок, особенно для старого железа.
Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз.
"Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз."
У вас хорошая память, вам повезло ..
Да не с unit фалом то проблем нет, проблема в том какие зависимости прописать под ситуацию, было ровно 2 кейса, монтирование root раздела с dm-raid (вышло так, при миграции с win) и перевод видеокарты в low режим, со вторым чуть проще (разгон турбины, нагрев, не такой шустрый) а вот с первым было трудно понять куда его ставить :)
это нисколько не мешает использовать SSD.
Ну, если не смущает необходимость регулярно менять диски. И если не смущает постепенная деградация их скорости. Оба эффекта мы ловили.
В 2000 году FreeBSD не умел грузиться с extended partition. А lilo и Linux умели. Это похоронил вряху для меня. Субъективно.
Простите, но ссылаться на 2000 год также "актуально", как обсуждать сейчас достоинства и недостатки Windows XP
Другое дело, что там кроме ZFS больше нет файловых систем нормальных. ufs — зеркало из 2 дисков по 1тб, fsck после хард резета занимает 6 часов. Нормально?
Хотя может за 10 лет сильно поменялось всё, но вообще на такие объёмы только zfs имело смысл, имхо разумный предел для ufs — гигабайт 50-100.
То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).
С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
Простое и логичное управление памятью и нехваткой памяти.
а что там вместо OOM killer?
Он просто работает. Причём работает так, что даже мысли не возникает об использовании своего отдельного OOM "с блекджеком и шлюхами" в userland как это теперь водится в Linux.
Интересно а как? Вот есть 2 user space процесса постепенно выбирающих память до предела, какое решение?
Такое поведение возможно при существовании гарантированного резервирования памяти под системный процесс, насколько я понимаю, проблемы возникают из-за механизмов типа copy on write, я в принципе далёк от системного программирования, но на мо взгляд такие механизмы очень усложняют отслеживание процесса которой запросил больше чем доступно, в итоге тот самый oom killer который по умолчанию настроен на работу до последнего (ведь крайний запрос на память может быть от системного процесса не смотря на то что 99% съел условный браузер) просто не успевает отработать и в итоге выстраивается очередь подвисших процессов.
Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб. RAM, насколько я понимаю (из прочитанного лет 7-8 назад) из-за особенностей алгоритма наличие swap даже небольшого размера частично решает проблему(зависаний нет совсем, но да что-то будет прибито).
Именно так.
Заметку по этому поводу я не обновлял по сути где-то с 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) и надеяться, что все будет хорошо. Ну, и своевременно подкидывать новых аппаратных ресурсов
Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).
в линуксе достаточно отключить оверкоммит памяти, но только при этом начинаются спецэффекты. Чертов софт, который написан кое-как
P.S. на работе выключил на одной слабой машинке (2004 г выпуска, Celeron 2.6GHz, 512MB памяти, winXP и KES10 + рабочий софт несколько штук) swap совсем, и… работать стало лучше! Раньше — запустит юзер сразу 5 программ, они сожрут оперативку (которой уже на старте ОС почти нет), и машина свопится, а диск тормозной, и всё сильно подвисает. После — запускают одну программу, вторую, третью — оп, а на четвёртой (или на третьей, как повезёт) ошибка — нехватка памяти! Они закрывают ненужные на данный момент программы, и работают дальше, без тормозов (ну, для этой машины если так можно сказать). И аптайм машинки по несколько месяцев случается.
Для обычных приложений залезть в своп — ну, замедлится, ну подождёт пользователь подольше…
У меня линукс не отвисает вовсе после ухода в своп. Видимо баг, но я хз что делать — IO LED висит сутки-вторые-третьи...
Подробнее можно?
Вот есть неплохая статья с описанием как настраивать ядро Linux:
http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/
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.
Хотя я часто слышал что теряли данные на UFS2, но у меня за всю жизнь с FreeBSD ни разу не было, тогда как на ext3/ext4 неоднократно.
Единственной хорошей работающей достойной ФС в GNU/Linux я видел только XFS, творение начала 90-х SGI IRIX.
я вот как раз терял данные на xfs, а с ext3/4 проблем не было.
Я слышал, что xfs не умеет в сжатие (я сейчас про уменьшение виртуального диска у ВМ, например с 20 до 10гб — если xfs, то такой фокус не пройдет), расскажите теперь про zfs, а то я с *BSD на уровне "потыкать" сталкивался.
Угу. На чем там по-умолчанию собирается pfSense? Два раза разбирался после обычного reset...
Миллионы мух [не] ошибаются?
на сайтах производителей видеокарт, например, драйверы для 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 м.б. будет преимуществом).
Т.ч. всё вот так — «не очень».
Так же FreeBSD по-умолчанию идет с UFS — это как раз и есть „что попроще“. С поддержкой железа сейчас ситуация в принципе в паритете с линуксом, десктопное железо конечно пониже приоритет имеет. Но у меня Фря даже на малинке бегает бодро. В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Теперь по поводу шаблонов, с одной стороны это удобно, но с другой они образуют шаблонное мышление и как следствие деградацию разума, даже в простых вещах если что-то пойдёт не по шаблону или не возможно это шаблоном выполнить люди становятся бессильны… Так что «в меру всё лекарство, но только если в меру.»
А теперь по поводу творческого подхода, он нужен везде, можно использовать стандартные базовые операции и тратить время к примеру на копирование вручную сотни каталогов, подкаталогов и файлов с разных устройств и мест, а можно подойти творчески засунуть всё в 1 список и выполнить за раз написанным скриптом ))))
так же можно развёртывать новые машины и настраивать их каждый раз ручками, а можно подойти творчески взять ансибл либо паппет и всё будет работать само…
За линь же как раз эту фрагментацию дистрибутивов и критикуют. Это только на словах звучит так круто, большое обилие выбора и свободы, по факту это это сотни и тысячи дистрибутивов с минимальными отличиями в виде нескучных обоев с разной степенью стабильности как самой ОС так и своих реп и наличия софта в ней. А в этот конструктор совершенно не хочется лезть, хочется что б все просто работало, при этом выглядело не всрато, и требовало минимальных и понятных вмешательств для настройки, все остальное лежит в области хобби и энтузиазма. Либо если тебе очень хорошо платят за создание конкретной эмбед платформы, типо роутеров, прошивочки камер и прочего и время которое ты тратишь разбираясь в этом.
Насчёт фрагментации — полностью поддержу.
Просто задумайтесь сколько способов есть решить тривиальную задачу в линуксе, а именно настройку сети. Причем рассмотрите не только конкретный дистрибутив, а ситуацию в целом.
Теперь по поводу многообразия всевозможных дистрибутивов с нескучными обоями, да такая беда есть, но никто и ничто не мешает вам не использовать их а использовать корневые родительские дистрибутивы.
А по поводу многообразия утилит которым Вы так не довольны, да их много но время отсеивает большую часть и остаются только те которые действительно удобны народу. Если Вы считаете иначе это Ваше мнение как индивида из всего того сообщества которое использует их и далеко не факт что все должны думать и думают как Вы…
2. Code of conduct — к сведению, привязан к одному конкретному проекту, не путайте. Да и это больше относится к поведению, нежели разработке и составу кода и качеству кода.
Ну Фря и есть конкретный проект, это целостная ОС. Вообще в различных ОС приняты свои требования к ПО под нее. Как, например, в MacOS в любой программе комбинация CMD +, откроет окно настроек программы. Так же частенько вижу в консольных утилитах и софте определенные флаги с пометкой «добавленно для совместимости с POSIX».
За флаги, кстати, тоже раздражает, в одних программах --version выводит версию в по, в других внезапно только -v, в третьих это verbouse, а четвертые вообще выводят версию без "-" просто version. Это пример, такие претензии к -h help и прочим стандартным флагам, очевидно же было бы лучше будь они как-то стандартизированы.
CMD +,
Не с "Command ," перепутали? А, все, понял, неудачное форматирование было )
Разработчики ведут свой проект для какой-то целевой системы же
Вы сильно ошибаетесь. Ещё раз Вы путаете всё и вся. Не нужно писать об этом если Вы в этом ничего не понимаете. Как разработчик говорю.
А по поводу команд так нет ничего в этом плохого, многих же устраивают утилиты под мелкомягких хотя там тоже не наблюдается солидарности в этом даже повершел от мелкомягких отличается хотя там многое поменяли…
В общем я ещё раз убеждаюсь в вашей не компетенции в этих вопросах. разработкой нужно заниматься что бы понимать о чём речь. Консольные утилиты и набор команд для них а тем более обработчик их может сильно зависеть от выполняемых ими функционала.
Вот сейчас решил проверить, при том, что до 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 сильно шире в количестве ниш и между ними всеми перетекают новые разработки.
NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
25.10.3.1 Если вам нужно только синхронизировать ваши часы при загрузке машины, вы можете воспользоваться утилитой ntpdate(8). Это может подойти для некоторых настольных машин, которые часто перезагружаются и только требуют изредка синхронизироваться, но на большинстве машин должен работать ntpd(8).
отсюда и выбор. В какой-то момент FreeBSD решили так же захватить и десктопную аудиторию, возможно тогда опция и появилась, а может и была там исторически, не знаю.
Почему манера использовать /usr/local дурная? Вообще именование каталогов, точек монтирования в unix исторически довольно малосвязная и забавная тема, просто FreeBSD использует одну из ранних вариаций, не думаю что она чем-то хуже или лучше любой другой, мне лично скорее нравится отсутствие лишних сущностей в виде /opt /pkg и тд и этот подход, опять же лично мне, кажется вполне логичным.
В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить, я обычно сразу пишу wheel для админский учетки, мне честно говоря сложно судить насколько это интуитивно, мне как программисту эти скобки сразу список напоминают, может вы и правы.
> Зато если остановиться на одном конкретном…
А вот проблема в том что приходится использовать то что там уже есть, а предидущий интегратор мог развернуть тот дистр что он больше знает или по каким-то своим убеждением, холивары там между дистрами идут еще горячее, хоть казалось бы. Это и имелось мной в виду.
А вот то, что на опознание проблемы потребовалось ему 10 минут, за это время нельзя было нажать отмену, и после этого на клавиши перестало реагировать — вот это полностью вина FreeBSD, точнее, авторов кривого инсталлятора. Странно вы читаете, если это проигнорировали.
> там толи эникастом толи роутером выдается оптимальное корневое зеркало
Но оно же может быть недоступным по сетевым причинам.
> NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
Даже для выключаемого десктопа мягкая корректировка темпа хода полезнее, чем прыжки. В плане управления временем тут у FreeBSD отсталость лет на 15.
> Почему манера использовать /usr/local дурная?
Потому что /usr/local — типовое умолчание для autotools и аналогов для ручной сборки. Поставленное таким образом плохо отделяется от установленного из портов и может с ним подраться.
> В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить,
Для установщика для простого юзера это должно быть написано сразу там же.
Этот инсталлятор, на самом деле, всегда затачивается под то, что он будет идти с инструкцией (в Handbook, в браузере чего-то соседнего или вообще в бумажном виде). Но типовой современный юзер никогда эту handbook не читает (и игнорирует её существование, если не наступил уже на эти грабли). Инсталляторы типа RHEL ещё предполагают, что установщик что-то читает кроме того, что пишет сам инсталлятор, но Ubuntu — уже нет.
> А вот проблема в том что приходится использовать то что там уже есть,
Да, это факт. Ты набил руку на Debian, приходишь — а там SLES. «Дык опаньки, братуха» (tm)
В убунтовском инсталляторе проблемы похлеще есть. Например, у меня последний инсталлятор серверной убунты тупо завис, когда сетевуха была не подключена к сети. Лол што. Реальные проблемы с разбивкой диска — то ту разметку, которую тебе надо, через инсталлятор не применить, то что-то ещё. Вообще все эти претензии к инсталлятора фрибсд смешны… Поверьте — у остальных линуксов они (инсталлятора) не лучше.
Ну я, конечно, последние K лет записной кедорас, но проблемы инсталлятора собственно Ubuntu мне неинтересны, а в Kubuntu я таких эффектов не видел.
И тупых зависов не было, и разметка получалась.
Ставил также центось — стиль совсем другой, но тоже прилично. Может, если бы захотел суперстранного, то получил бы по рукам, но фрёвый в принципе такого не умеет.
Всё-таки само по себе участие большего количества пользователей обеспечивает, в среднем по больнице, лучшее качество просто за счёт обратной связи.
> Поверьте — у остальных линуксов они (инсталлятора) не лучше.
Вот я таки испытал обе стороны и делаю другой вывод — что как для рядового пользователя линуксовые таки лучше.
Когда я фряхи ставил потоком, там уже все чудеса были отработаны, рука набита… но там и результаты часто требовались нестандартные. И таки это были pets, а не cattle.
Сам образ наваял?
Или есть готовые на сайте малинки?
Либо просто с фтп Фри: download.freebsd.org/ftp/releases/arm
Драйвера FreeBSD обычно берёт у Linux.
Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.
У Linux есть больше преимущество — гораздо легче начать им пользоваться, чем xBSD.
Вообще неправда. Наоборот. Если, конечно, вы не имеете в виду «скачать образ, не читая ничего».
Так-то поддерживается меньшее количество железа, да.
А вот «выглядит лучше, чем Linux» субъективно везде.
Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.Пойдите и почитайте что и как и берётся у Linux
А так многие драйвера фряхи по прежнему тянут с GNU/Linux.
Что? Этого нет и никогда не было, потому что лицензии.
Это как раз один из самых частых кейсов. Интел делает новый чипсет, сата контроллер в нем. В итоге не то что не увидеть — инсталер может просто зависнуть. Так же помню когда на сата только переходили, на фре отваливались сата винты, причем это довольно продолжительное время происходило. Потом вроде стабилизировали, но осадочек остался.
А что полшага в сторону от совсем массовых систем, и проблема с драйверами встает в полный рост, так по-моему, этим вряд ли кого здесь можно удивить. Имхо, конечно.
Винт подключается к контроллеру жестких дисков, и драйвера нужны именно для этого контроллера (при этом еще один контроллер расположен непосредственно на винте).
Свойство базовости периферии не кодифицировано, о его значении и объеме можно спорить, но необходимости драйверов ни один спор не отменит.
А что удивительного? Если делается явная оптимизация под 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 группы очень активно друг у друга тянут код).
1. FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc. Сейчас почти сравнялись, но «в среднем» всё же FreeBSD+clang немного медленнее, чем FreeBSD+gcc (зависит от задачи).
2. После трёх лет (!!!) обсуждения всё-таки включили поддержку OpenMP во FreeBSD:
начало
конец
Не включали потому что «нам в базе не надо, а на остальных пох», при этом ныли «а чё на Форониксе такие циферки маленькие?...». А надо не ныть, не жить прошлым, а внедрять новые фичи, которых просят люди.
На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX. (когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ). Опять же щас Linux и FreeBSD сравнялись.
Ну ответ я бы тоже поминусовал (в карму не полезу из принципа даже когда/если будут права) — различия между разными вроде бы 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 в ней я совсем не знаю, надо будет как-нибудь почитать.
Вообще суть сравнения ХЗ/BSD (потому что понатаскали от всего и вся) vs GNU/Linux, знаю что у обе системы можно спокойно уместить в мизер ОЗУ для линухи последних версий это порядка 4х МБ и 16мб на ПЗУ. Да уже и не в том возрасте что бы мериться у кого длинней и толще… работать надо, да и дома десктом уже давно без дуалбутов и всё работает на Debian Sarge GNU/Linux… в своё время перепробовал всё, убунты, федоракоры, мандрейки, редхаты и т.п. остался на дебе так как оптимальное соотношение цены / качества.
Ох, lets lorcombat begin!
Для меня Эдуард Шишкин является примером специалистом, который продолжает развивать свою тему наперекор всем, включая Линуса Allmightly.
Фря в качестве датаьейз сервера просто унылое говно — скорости нет. Это единственное место где у меня не фря, все остальное инфраструктурное только на фре, если я выбираю.
А так вообще пофигу что настраивать
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))
Я и сейчас готов хвалить OS/2.
Для того времени это был очень серьёзный шаг вперёд, намного более стабильный и удобный.
Но сейчас "оспополам" это просто часть истории.
Где-то в 2000х я активно использовал FreeBSD и для работы с сетью она объективно была сильно круче Linux'а (всё портил разве что NAT в userspace'е, но и это в итоге починили). Я и сейчас готов утверждать, что тогда для многих серверных задач она была лучше. А уж jail был (на фоне имевшегося chroot в линуксе) просто великолепен.
Но сейчас лично для меня FreeBSD — часть истории.
Приятно осознавать, что в отличии от OS/2 она всё ещё жива, но не более того.
В конце нулевых — начале 10-х фряха была очень популярна как серверная ось. Как-раз, по причинам, описанным автором статьи. В последнее время, как я вижу, для серверов выбирают centOS, Debian и Ubuntu. Почему фряха обосралась — сложно сказать. Насколько помню, в десятых годах активно находили уязвимости в ntp, openssl и проч. И фряха оказывалась крайне небезопасной при том, что обновление проблемных утилит в ней вызывало проблемы. Плюс, получили распространение лёгкие дистрибутивы типа CentOS. Их развёртывание и обслуживание было легче, чем развёртывание и обслуживание фряхи. А без популярности на серверах фряха, по сути, нафиг не нужна и её смерть — вопрос времени.
Был админом в "нулевых" - модемные пулы, вот это все - "плавали, знаем". FreeBSD тогда была By default. У всех. 4.3 как сейчас помню. На 5-ку не переходили принципиально - FreeBSD 5 была чем-то вроде Windows Vista от мира винды
Не знаком с BSD, но мне кажется или у вас аргумент про 3 фаервола противоречит аргументу про отсутствие "зоопарка" утилит для одних и тех-же задач?
Еще и DPDK на BSD не работает
Легкий наброс, bsd конечно ок, но сообщество в разы кислотнее, нежeли linux
ps: десктоп клиента для телеги даже на gtk так и не изобрели, запускают linux клиент в эмуляторе… это все, что нужно знать о будущем
По наблюдениям — BSD заводится там, где сошлись звезды и несколько BSD-шников. Так оно в NetFlix, примерно так — в Juniper (там вообще дикая смесь под капотом).
Если серьёзно, то шлюзы безопасности на всех предприятиях, где я работал или фрилансил, я всегда поднимал и настраивал на FreeBSD. PF — отличный пакетный фильтр.
Адепты фряхи ещё вспоминают давнишнюю историю с MacOS.
Apple как сосал, так и сосёт код из FreeBSD в свои OS. И в ядро тоже. Только особенно по теме не распостраняется. Информация об этом выдаётся только вскользь, как это было, к примеру, при обнаружении Meltdown / Spectre.
А еще они роутеры делали на NetBSD когда-то давно :-)
Это всё просто замечательно, но как там во фре с играми? :D
Плэйсэйшон же
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:)
Мне кажется странным, что снижение накладных расходов Вы характеризуете как маразм, да ещё и без причины. Я тоже против беспричинного маразма, но уместное снижение накладных расходов к этой категории, как мне кажется, не относится никак.
Замените слово докер на слово виртуальная машина — ничего не поменяется. Для девов держать машинку в зене и хайперви — никакой разницы, не те нагрузки и накладные расходы.
Виртуальная машина не избавляет от настройки и возни так радикально как докер. Вам прежнему предстоит самостоятельно решать проблемы с получением актуальных образов сторонних сервисов. Порядке старта вртуалок и гашения их после тестов
орядке старта вртуалок и гашения их после тестов
докер, к сожалению, эту проблему тоже не решает.
Вам прежнему предстоит самостоятельно решать проблемы с получением актуальных образов сторонних сервисов
В докере — то же самое. Идеальный сценарий — варить образы самостоятельно. И тут действительно разницы нет — варить образа докера docker build'ом со всеми его ограничениями или варить "золотой" образ виртуалки тем же hashicorp packer'ом.
Я уж не говорю, что только тот человек может говорить про проблему с образами, который не работал с Vagrant :-)
В чем проблема брать последний образ из репозитория образов, кажется все необходимое у докера есть?
Вы сейчас про какую проблему?
Те образы, которые выложены на докерхаб — максимум тянут на образец. В них куча проблем. Есть официальные, но не для всего — и зачастую их конфигурация и подгонка под конкретную задача очень ограничена. Это примерно та же история, что и с deb/rpm — эксперты в написании программ редко являются экспертами в их упаковке. Ровно обратное тоже верно — в результате — мы для каждого дистрибутива линукса видим какие-то просто дичайшие патчи в каждом пакете
У меня есть некоторый опыт с 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 и аналогов, чтобы решить часть проблем докера. А что оркестрировать — вообще по барабану. Кубернетес в целом позволяет писать адаптеры к чему угодно. Просто так исторически сложилось, что эта система началась как оркестрация контейнеров…
В общем, я к чему. Докер в зависимости от контекста — может быть от "великое благо" до "ненужный компонент". Нужно смотреть по своим задачам и по своей инфраструктуре.
это явно не история про БД, хранение и что ещё стейтфул. Базы вообще очень не любят делить ресурсы с кем бы то ни было ещё.
Не совсем так. Но даже если так, то вообще нынче принято базы брать как сервис, если уж у нас облако. При этом — само наличие контейнера совершенно не определяет то, будет ли у нас этот контейнер один на машине или их будет сотня. Даже если он будет один, то все плюсы в целом присутствуют (как в общем то и минусы).
К тому же, докер — это про контейнер приложения. Со всеми вытекающими.
Не очень понятно про какие вытекающие вы говорите. К тому же конктерно 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 тысяч евро относительно решения на своей инфраструктуре.
Спасибо, кэп, но это не отменяет того, что у указанных технологий пересекаются сферы применимости.
Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
В сознании обывателя — докер понятнее и удобнее. Те же докерфайлы, возможность сгружать готовые образы в стандартном формате из докерхаба или любого совместимого хранилища… К сожалению, ни nspawn, ни lxd не создали такую широкую экосистему… Поэтому и понятное желание пихать докер в любую дырку. Ну, и подогрело это все оркестраторы вроде кубернетеса — в которые тот же nspaws/lxd положить можно, но это надо самому писать необходимые прослойки и модули, а докер — вот он, из коробки
Особенно это критично когда нужно с Python пакетами работать на компах, а на в «Клауде». Тут даже virtual environment не поможет для компов на Виндовс, МакОс и Линукс.
А почему заоопарк?
А потому, что на Винде пользователи PowerBI и других программ. На Маке — как бы стандарт. А на Линуксе — продвинутые.
Как это любая?
Порисовать в гимпе — нужен докер?
Установить самбу или апача — нужен докер?
И как это я всю жизнь всё это и всё остальное делал без докера… (из которого знаю только слово докер)
Гниение софта это вообще отдельная боль и печаль, но банальный configure и make работают заметно лучше и портировать или починить софт проще чем вынуть его из докера.
починить софт проще чем вынуть его из докера.
Ну, я не согласен. Смотря что Вы понимаете под вынуть из докера. Перенести в ДРУГУЮ песочницу — типа chroot или systemd nspawn? Да не проблема. Работоспособность софта пострадает? Нет! А дальше можете весь этот чрутованный пакет точно так же превратить в rpm/deb и доставить на целевую машину. Здесь просто происходит смена парадигмы — раньше мы действительно пытались зависеть от того какие пакеты сидят в системе, но по определенным причинам — это действительно сложно. Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.
В случае если приложение просто ставится локально попроще все же.
Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.
Вот я про это и говорю. А это всплывает не сразу, а через 5-10 лет что выливается в сложности при размотке контейнера.
Докер провоцирует собрать в него, так же разработчику удобнее. Но это аукнется потом, когда потребуется перенести куда-то еще и контейнер там просто не работает и все.
Все это «у меня make не ломается» и «а вот тут я могу запустить сборку под другую архитектуру, а тем не могу» в подавляющем большинстве практических задач просто не имеет никакого смысла. Разнообразие архитектур у конкретного бизнеса обычно минимально. Особенно если говорить об одном и том же приложении.
И кстати да, докер есть допустим под arm и да, под него можно собрать контейнер и это даже будет работать. Собрать 1 раз. И запустить за пару минут в любом месте.
Тут же все очень просто — если есть подходяще написанный код и руки, то никакой докер не помешает собрать приложение под другую архитектуру. Он никак не привязывает. Результирующий образ вполне может собираться командами make. А где этот make запускать — дело десятое.
Но — подавляющее большинство серверов на x86_64 и да, разработчик просто не заморачивается.
никогда не приходилось деплоить пару десятков приложений в десятках и сотнях экземпляров как минимум в 2 разных места хотя бы 2 раза в день.
Нет не приходилось. Но вообще говоря ребята если вы два раза в день в двух разных местах постоянно что-то деплоите да еще и на рабочее то боюсь у меня для вас плохие новости :)
А вот деплоить на много узлов кучу всякого софта на протяжении нескольких лет приходилось. И в этом случае делаем сборки для deb или rpm пакетов и свой репозиторий. Этот подход стар как мир и работает ничуть не хуже. И на дальней дистанции даст более стабильный и предсказуемый результат.
Плюс у докера есть одна маленькая проблема. Разработчики так и не смогли решить задачу один контейнер один процесс. До сих пор есть случаи где оно не работает. Ладно в podman сдались и подпихивают туда systemd :)
Влямывались пару раз в адд зависимостей.
Надо уметь готовить, как и докер. С докером можно к примеру собрать контейнер так что он будет весить крайне дофига. Недавно тут пробегала статья про то что люди собирали докер под питон на базе дистрибутива musl и забывали дропнуть зависимости сборочные после сборки. В итоге дистрибутив раздувался больше обычного на базе ubuntu.
Плюс с докером люди забывают про безопасность. Если в случае долгоживущей машины мы имеем возможность обновлять пакеты и исправлять уязвимости, то в случае docker окружение застывает в том виде в котором его поставляли. И ой.
Докер готовить проще. И судя по рынку — дешевле по зарплате.
Готовить проще. Главное под капот не заглядывать.
Это не правда. Более того, именно вопрос безопастности окружения делает докер лучше в перспективе.
С докером маинтейнер отвечает за весь образ. Если зависимость в его образе дырявая — это его отвественность изменить контейнер.
Именно что придется менять весь контейнер
Если в dpm у вас есть зависимость с дыркой — то это проблема юзера играться с покетменеджером, чтобы вытащить версию зависимости без дырки.
Если вы используете поддерживаемый дистрибутив достаточно обновлять пакеты. Это в свое время один товарищ просил мне надо самый свежий openssl. Я спросил, а кто будет мониторить дырки в нем и обновлять его? В случае дистрибутива это делают люди которые его сопровождают и делают они быстрее тебя и меня.
Про замораживание. Это действительно проблема докера. Но она решается не на уровне самого докера, а на уровне софта который билдит. Уже пару лет назад начали работать над софтом, который позволяет пересобрать все свои контейнеры, при обновлении базового (или какого-то ниже) слоя.
Докеру как технологии уже скоро будет 7 лет. И только сейчас это заметили ага.
одна из вещей, которые докер заставил учить большинство программистов — как сделать долгоживущий _сервис_ у которого под капотом коротко живущие виртуалки. Эта такая же смена парадигмы мышления/программирования — как и переход к многопоточности.
Это вы про микросервисную архитектуру? Она как подход стара как мир. Смотрим микроядерные операционные системы. Подход идентичен. И проблемы кстати тоже идентичны :)
Это в свое время один товарищ просил мне надо самый свежий openssl. Я спросил, а кто будет мониторить дырки в нем и обновлять его?
К сожалению, это работает только до момента, пока внешний API этого OpenSSL остается тот же. Как только в связи с уязвимостью меняется внешний API — вы попадаете как минимум на рекомпиляцию своего зависимого проекта, а в худшем случае — переписывание части вызовов (а здесь — да, нужна квалификация)
Но вообще говоря ребята если вы два раза в день в двух разных местах постоянно что-то деплоите да еще и на рабочее то боюсь у меня для вас плохие новости :)
Вы лучше эту новость передайте 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 и не ломайте голову. Бридж реально под нагрузкой очень проседает и латентность в космос. А изоляция по сети между проекта докера… на самом деле такая большая фикция
Закон Мура умер как только у нас появились двуядерные процессоры. Вы правда думаете что многоядерность от хорошей жизни? :))
Ну а многопоточность конечно улучшают, нужно же чтобы это требовало меньшей квалификации от программистов.
А мне например понравилось юзать jails в FreeBSD вместо Docker на Ubuntu.
И софтверный RAID6 на ZFS для домашнего сервера очень зашёл.
Но на десктоп ставить это уже мазохизм/энтузиазм
jail — FreeBSD-специфичная контейнерная виртуализация. Аналоги в Linux — chroot, OpenVZ, LXC и кучка устаревших/проприетарных технологий. Аналоги, кстати, куда более продвинутые, в отличии от Jail, где не поддерживается ни квотирование/лимиты толком ни миграция ни… впрочем, этого достаточно.
Docker — «система быстрого деплоя с клиент-серверной архитектурой» (простите за вольный перевод), в качестве контейнерной виртуализации использующая Linux LXC/cgroups, так же имеющая «на борту» еще кучу других сущностей…
Если не требуются «принтеры да сканеры», то для десктопа фряха уже давно — годная система. А для подключения к ней принтера бубен пока ещё нужен…
Я ожидал более подробной статьи
Вот так и я. FreeBSD — моя любовь навсегда, ставлю, когда могу, на сервера, новые выпуски тереблю в виртуалке, пытаюсь ставить на каждый новый ноут как десктоп-систему (ни разу успешно — железо не имеет драйверов). А работаю в основном с Linux.
Запустил бы jail и радовался, но нет, приходится жрать docker, подавляя рвотный рефлекс, потому что он нужен клиенту
Фряха форева, что уж
Наверняка любой пользователь сталкивался с тем, что система или перестаёт отвечать/работать при нехватке памяти
Ага, при исчерпании памяти на диске система (Ubuntu 18.04) постоянно перезапрашивает пароль при входе в систему. :)
P.S. Лечится очисткой жёсткого диска для не нулевого размера доступного пространства, например, загрузив какой нибудь LiveCD.
и не нужны никакие livecd.
Где гарантия текстового входа в этом случае? Ой не уверен, с новыми-то веяниями...
Гарантия в настройках tty.
Что, tty сам по себе может обеспечить шелл? Без /usr/bin/login, полного набора действий в setusercontext(), вызова шелла, инициализационных скриптов шелла и тэ дэ и тэ пэ? Ну тогда вы говорите о какой-то другой системе, не о FreeBSD.
Какие такие мифические веяния вы имеете ввиду, мне даже и придумать сложно.
Ну я вот ставлю bash в качестве шелла, а как он отреагирует со всеми стандартными скриптами на переполнение диска, предсказать сложно.
Может, надо было бы tcsh ставить, но как-то сейчас даже в BSD мире без баша не прожить.
GNU/Linux это зоопарк, помойка
Именно по этой причине фряша реализовала Linux Kernel Programming Interfaces (Linux KPI) для полу-автоматического утягивания DRM-ного кода: Ctrl+ F :: linuxkpi
Ваш взгляд сильно перекошен на серверный сегмент. У линуха есть крайне сильные стороны в сравнении с другими Unix-ами. В первую очередь по причине существенного участия вендоров. И часть этих наработок заимствуют производители других ОС — FreeBSD, BlackBerry («Start the DRM Server»), Wind River (Ctrl + F :: DRM)
Для себя давно решил, что freebsd — хардкор, местами до полного отчаяния. Много раз пытался уйти на linux (понравилась opensuse), но всегда эксперименты с linux заканчивались возвращением к freebsd. По разным причинам.
Сейчас у меня несколько серверов (в основном для хостинга и своих pet-проектов) именно на freebsd работают уже по несколько лет с почти стопроцентным аптаймом.
мне думается что смысл жизни последних 10-ти лет у ребят из sco/freebsd/bsd/bsdi/openbsd/etc. в проистекании желчи по поводу Linux. только нам как-то насрать ;) причем началось это еще с 199x годов — я помню до сих пор одного дурачка (intes), который топил за SCO в Одессе и мне лично говорил что linux ничего не светит по жизни. также помню одного туповатого ISP директора (tenet), который брызгая слюной заявлял что linux у него никогда не будет стоять на серверах. я уверен что даже эти долбо#ебы сейчас юзают linux и не жужжат.
у меня на десктопе — linux, сервера под linux, домашняя автоматика — linux, в мобилках — linux, eReader под linux, во всех машинах магнитолы под linux. начинать такой тред можно если вдруг лет через 300 google запилит что-то на бзде или m$ выпустит хоть что-то — но этого никогда не будет, потому как, внимание, — не нужно. диванный админ локалхоста detected.
Единственным ближайшим аналогом является SystemTap
BPF и bpftrace.
Брэндан Грегг даже книжку уже выпустил.
Идёт процесс заворачивания софт в Capsicum но не так чтобы быстро.
systemd и один только факт того, что *BSD его не используют уже является killer-feature.
Почему?
BSD это целостные законченные ОСoh rly? RLY ?!?!
или вот это ваше сильное заявление:
Постоянная технологическая отсталость GNU/Linux
Это ваше доказательство: вах ВАХ вах нет практически бесполезной ZFS…
Ок: ZFS разве есть всё? и без него жить не возможно? О_о.
А про losetup дык это вообще верх возмущения… не читается автоматом таблица ВАХ ВАХ ВАХ, беда беда. Отсталые в технологии… Это же как можно быть такими отсталыми…
В указанной статье вы смотрите на это с точки зрения глупого пользователя которому все всё должны… И ментейнеры, разработчики и в общем все те кто предоставляет Вам свои труды бесплатно и не требуя ничего в замен… Увы но такая точка зрения мне категорически не приятна.
GNU/Linux разрабатывалась программистами и для программистов… и многое из того что Вы считаете неделимым и приписываете к BSD это часть проектов GNU и других… только Вы об этом либо не знаете либо решили промолчать.
И следовательно ваше заявление о целостности BSD выглядит мягко говоря печально… Что там целостного набор тех же открытых проектов только бантик с права?
И так далее по всей статье… ничего кроме пустых заявлений.
Более того из моего личного опыта я могу сказать что отсталость наблюдается именно на стороне BSD… Если хотите примеры приведу как и где и почему.
В общем я крайне не согласен с вашей точкой зрения. И прошу меня извинить за резкость и если я Вас или кого-то обидел, но это моё скромное мнение как программиста и простого юзера который работает на GNU/Linux уже порядка 14 лет…
По поводу СARP в linux он или userspace или кастомное ядро. Но самое интересное в том, что в OpenBSD есть Pfsync который синхронизирут PF state table и Sasync который синхронизирут IPsec SA. И что Linux я о таком что-то не слышал.
ipfw это же просто файрволл, эволюция которого была остановлена :)
Напоминаю откуда появился nftables: ipfw->ipchains->iptables->nftables
pf, когдя я его последний раз смотрел, был слишком тормозной. Просто добавление модуля pf в ядро, сразу зарезало 20% ПС интеловской встройки на системе с Атомом D525
Но вот интеграция ZFS с ОС FreeBSD шикарна. И работает ZFS во фре обычно быстрее, процентов на 10% как минимум. Это лучше всего видно на LSOF (lot of small files).
Мы ушли с FreeBSD потому что они много лет не могли нормально запилить балансировку потоков по разным процессорам.
slonik-v-domene.livejournal.com/96331.html
Ну там довольно много просвещенно управлению пакетами в Debian vs FreeBSD.
И это было в 2011, а в 2019:
https://forums.freebsd.org/threads/what-do-you-think-about-the-new-package-base.70608/
I think it's like a punch in the face. We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic. It means we admit Linux's way is practically easier, more flexible and more reasonable than our own that we finally have to adopt it. It's shameful. What about you?
Если ты такой умный, почему такой бедный.
Или почему 100 из 100 серверов крутятся на Linux тем временем как bsd всем хороша?
Я молчу о том, что преобладающая часть популярных дистрибутивов начало активно использовать systemd и один только факт того, что *BSD его не используют уже является killer-feature.
Серьезно? Не знаю, какая система инициализации использутеся в *BSD, но я, когда узнал о systemd, сразу подумал: наконец-то сделали что-то нормальное вместо костылей из bash-сценариев, коими по сути являются OpenRC, SysVinit и пр.
Не знаю, какая система инициализации использутеся в *BSDBSD Init, как ни удивительно.
FreeBSD: Нуу, сейчас сделаем трейс, построим график и найдем узкое место вашего приложения
Linux: Просто добавляю ноду в кластер на кубере. %pockerface%
Linux: Просто добавляю ноду в кластер на кубере. %pockerface%
эх, если бы всегда было так просто
На практике, если сейчас взять одни из последних дистрибутивов Ubuntu, то вы не факт что сможете поставить его не на первый жёсткий диск
BIOS или UEFI? До недавних времен мог, что сменилось сейчас?
Теперь только ALSA, мало чего умеющая из вышеперечисленного
В ядре при сборке можно включить режим совместимости, или не оно?
Добавлю свои 5 копеек. У меня на виртуальном хостинге сервер под Линуксом за год два или три раза просто падал. Последний раз до полной потери файловой системы.
Поднял там-же на FreeBSD + ZFS = третий год ни одной остановки. Это не холивар — это реальная статистика.
PS: на desktop давно пользуюсь Линуксом (Arch) — все устраивает. Пробовал его в качестве сервера — меньше чем через неделю понял, что это плохая идея.
Простое и логичное управление памятью и нехваткой памяти.
В Linux вы можете его получить путем выставления vm.overcommit_memory=2, и киллер не придет: процессы сами будут падать на cannot allocate memory, без всякого киллера, причем падать будет не самые большие по потреблению памяти, а именно те, которые запрашивают выделение. Вот пример: жирный процесс выделяет память, но обрабатывает ошибки выделения и пытается продолжить работу. В итоге падают маленькие процессы, котрые не обрабатывают ошибки выделения. Вот скриншоты такого — процессы getty падают без вмешательства киллера. Возможно ли подобное в *BSD?
Еще вопросы:
Есть ли в *BSD аналоги zram и zswap?
Есть ли в *BSD аналог PSI?
Как в *BSD обстоят дела с поддержкой иерархии контрольных групп? Есть ли аналоги cgroup в *BSD?
В Linux вы можете его получить путем выставления vm.overcommit_memory=2, и киллер не придет: процессы сами будут падать на cannot allocate memoryКонечно есть, и называется похоже — vm.overcommit, причем можно указать, сколько должно оставаться свопа до начала такого поведения. И в лучших традициях «кислотного» поведения: man tuning.
Фря работает там, где нужно просто работать в качестве сервера.Apache, ipfw,dovecot, postfix,dhcp,proxy,ipsec,racoon ну и там всякие spamassasin и прочего обвеса. Контора 80 человек, таких контор 5, каждый юзер имеет 50к писем в год. Ящик каждого по 20+Gb. Сервера Futjitsu rx1330m3 диски sata3, 16gb rama, цена сервера 1.5к евро. Меняю железо раз в 5 лет. Вытащил диски со старого поставил в новый gpart backup ada0 > ada0.gpt | gpart restore ada1 < ada0.gpt
Gmirror insert ada1px gmroot...synchronize 1%
Контора в год зарабатывает 1.000.000 евро. О чём тут спорить?? Каждый выбирает под свои задачи систему. Нужно всё самое модное? Привет убунту. Нужен просто работающий танк на стандартные задачи? Фря. Ниодного кейса за 15 лет. Всё как часы. С линуксами попадал в засаду. Ну и нужно понимать инфраструктуру. У меня бордер фря. Я как минимум не по модному делаю, но как максимум по моим подсчётам сэкономил компании около 500к евро за 8 лет :)) а так да, кубернетес, циско и всё прочее… ага :))
Jail это замечательно. Но containerd, cri-o там нет. А следовательно отсекаются все оркестраторы: k8s, nomad, mesos, docker swarm.
Без нормальной работы в freebsd: kubernetes, nomad, mesos, containerd, cri-o, ansible, salt, chef, puppet говорить о какой-то замене gnu/linux на freebsd как-то несерьезно.
Еще бы выяснить как часто выпускаются версии и поддерживается ли вообще популярное ПО: nginx, haproxy, envoy, traefik, clickhouse, mongodb, mariadb, percona xtradb cluster, portgres, tarantool, casandra, kafka, rabbitmq, prometheus, zabbix, elsasticsearch, kibana, logatash, nxlog, graylog, gitlab, jenkins и т.д.
Нормального IaC не построить, контейнеры (containerd, cri-o) и оркестраторы для них поднять нельзя. Половина популярного софта не выпускается под эту ОС, а у другой половины запаздывают версии. Я не очень понимаю как я могу в своей работе заменить GNU/Linux на FreeBSD, и как мне FreeBSD облегчит работу.
Хотя сетевой стек мне во FreeBsd очень нравится. netgraph божественен.
Всё или почти всё по списку есть в портах. Это как раз не проблема — специфической кодовой заточки под Linux у этих компонент крайне мало, где есть — майнтейнеры правят патчами на десяток строк. Nginx вообще исторически в основном разрабатывался на FreeBSD.
Вот с агентами контейнеров, да, провал.
В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?
Хочу поставить clickhouse на сотне серверов, мне писать плейбук который его компилирует на сотне серверов? И так со всем софтом?
> Nginx вообще исторически в основном разрабатывался на FreeBSD
Откуда информация? Дайте пруфы пожалуйста. Тем не менее на офф. сайте nginx.org/en/download.html, сборки под Linux и Windows есть, под FreeBSD нет.
Из списка почти весь софт нужно компилировать из исходников, либо его вообще никак не поставить на FreeBSD (envoy, docker, podman, cri-o, contanerd и т.д.)
Ни в одном облаке (amazon, linode, hetzner, vultr) с которыми я в основном работаю, нет возможности поднимать виртуалки на freebsd.
Мне наверное не понять людей, которые топят за замену linux на freebsd. Мы видимо живем и работаем совсем в разных сферах или реальностях.
Конечно можно пойти к бизнесу, и сказать: давайте вложим кучу времени и перейдем на freebsd. А еще наймем побольше инженеров, так как кучу новых модулей для ansible, salt, puppet, chef, надо будет написать. А еще портировать containerd и k8s на freebsd и миллион подводных камней, которые всплывут в процессе всего этого. Я думаю бизнес ответит мне, что я дурачек и наймет другого инженера.
⋊> ~ pkg search clickhouse 18:53:49
clickhouse-19.11.5.28_4 ClickHouse is a column-oriented database management system
⋊> ~ pkg search nginx 18:53:58
modsecurity3-nginx-g20181129_1 Instruction detection and prevention engine / nginx Wrapper
nginx-1.16.1_11,2 Robust and small WWW server
nginx-devel-1.17.7 Robust and small WWW server
nginx-full-1.16.1_4,2 Robust and small WWW server (full package)
nginx-lite-1.16.1_11,2 Robust and small WWW server (lite package)проверить наличие, если у вас нет FreeBSD, можно тут www.freebsd.org/ru/ports/databases.html
В Hetzner Cloud я лично держу VPS на FreeBSD, она у них есть в списке ОС и более того, у них даже есть рекавери для FreeBSD, вот в Амазон: aws.amazon.com/marketplace/pp/FreeBSD-FreeBSD-12/B07L6QV354 за другие уже не скажу, но имхо она есть почти везде.
Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять.
«Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты. Есть какая-то малая доля тех, что лицензия требует собирать только на месте, но после всяких qmail от DJB я такого уже не видел.
Большинство сейчас даже базу обновляет бинарно, а пакеты из портов — тем более.
> Откуда информация? Дайте пруфы пожалуйста.
Информация из личных контактов тех времён, начиная с Сысоева. Массовая миграция серверного хозяйства рунета и уанета на Linux это уже середина 2000-х, до этого FreeBSD преобладала. Я лично в этой системе, считаем, с 1998-го. Ссылки на рассылки поднимать не буду.
> Тем не менее на офф. сайте nginx.org/en/download.html, сборки под Linux и Windows есть, под FreeBSD нет.
Сейчас — да, из-за мизерности её доли. Но порт есть (в нескольких версиях) и работает. А официальные сборки для распространённых дистрибутивов — да, знаю, что это новохипстерский путь — всё искать через офсайт вместо пакетного менеджера, и причём лучше сразу контейнером для докера, но не считаю его единственно верным :)
> Из списка почти весь софт нужно компилировать из исходников
Тот список именно целевых средств — а не контейнеров — я не нашёл такого, что нельзя поставить из готового пакета. Можете проверить сами.
Если envoy это «a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and «universal data plane» designed for large microservice «service mesh» architectures.», то есть готовый пакет.
> Ни в одном облаке (amazon, linode, hetzner, vultr) с которыми я в основном работаю, нет возможности поднимать виртуалки на freebsd.
Вот рядом ответили — хетцнер и амазон — есть штатно.
> Мне наверное не понять людей, которые топят за замену linux на freebsd. Мы видимо живем и работаем совсем в разных сферах или реальностях.
А мне не понять, чего это вы вдруг взвились с подобными комментариями именно на моё сообщение просто о факте наличия софта — и при этом ещё и приводите все аргументы из области контейнеризации и облаков.
Да, «пластмассовый мир победил, макет оказался сильней» — тема серверов приложений вряд ли понудит смотреть на FreeBSD, если будут думать по принципу «сегодня на локалке, завтра в амазоне, послезавтра в азуре или на дедике в соседнем ДЦ, и всё это с минимизацией расходов на людей». Но вроде же с этим никто и не спорил? И почему у всех должны быть именно такие задачи?
Не понимаю с чего вы взяли что я «взвился» на ваше сообщение. Я лишь пытаюсь выяснить как именно FreeBSD облегчит мою работу. И например позволит сэкономить на эксплуатации. Если это не так, то ок.
> И почему у всех должны быть именно такие задачи?
Я не считаю что у всех именно такие задачи. В статье написано: «FreeBSD лучше чем GNU/Linux». Если это действительно так, то мне нужно непременно узнать про это и рассказать бизнесу. Что я и пытаюсь сделать.
> всё искать через офсайт вместо пакетного менеджера
Не знаю что такое «новохипстерский путь». Репозитории дистрибутивов, как правило могут не иметь нужный софт, или иметь слишком старую версию. Проверять последнюю версию ПО и есть ли репозитории для моего дистрибутива от разработчиков софта считаю нормальным. Часто репозиториями от разработчиков софта удобней пользоваться, например там часто содержаться все версии пакета и легко откатываться на предыдущую или какую угодно версию. Также у меня нет под рукой freebsd и поискать в пакетном менеджере возможности нет. Нагуглить смог только список портов: www.freebsd.org/ports/searching.html. А список пакетов из репозитория бинарных пакетов например как для debian (https://packages.debian.org/index) не нашел.
> Вот рядом ответили — хетцнер и амазон — есть штатно.
Установка из штатного образа, который поднимается за пару секунд. И примонтировать ISO и из него поставить, я бы не назвал это «штатно». В amazon, да, действительно можно сказать есть «штатно», просто среди дефолтных AMI я его не нашел, и сделал вывод что его нет.
Вот список образов которые действительно штатные в hetzner:
$ hcloud image list
ID TYPE NAME DESCRIPTION IMAGE SIZE DISK SIZE CREATED
1 system ubuntu-16.04 Ubuntu 16.04 - 5 GB 2 years ago
2 system debian-9 Debian 9 - 5 GB 2 years ago
3 system centos-7 CentOS 7 - 5 GB 2 years ago
168855 system ubuntu-18.04 Ubuntu 18.04 - 5 GB 2 years ago
5924233 system debian-10 Debian 10 - 5 GB 7 months ago
8356453 system centos-8 CentOS 8 - 5 GB 4 months ago
9032843 system fedora-31 Fedora 31 - 5 GB 4 months ago
> Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять. «Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты
Это хорошо, видимо я что-то упустил. Я уделил точно больше минуты, так как в прошлом был опыт обслуживания серверов на freebsd. Возможно что-то забыл, но как-то запомнилось что порты это именно про сборку из исходников, а pkg пакетный менеджер, который качает и устанавливает архивы с бинарниками.
А как ещё понять реплику типа
>> Мне наверное не понять людей, которые топят за замену linux на freebsd. Мы видимо живем и работаем совсем в разных сферах или реальностях.
?
> Я лишь пытаюсь выяснить как именно FreeBSD облегчит мою работу. И например позволит сэкономить на эксплуатации. Если это не так, то ок.
Ну вот на это я рядом писал — реально у FreeBSD сейчас, образно, три кита, на которых она может активно выплывать: Netgraph, GEOM и ZFS. Где они прибавляют какой-то реальной ценности — можно согласиться на расходы на её специфику (начиная с того, что «типа Linux, но непривычный какой-то, всё иначе, знакомые слова не работают»). Где нет — ну разве что сработает, что под неё вряд ли готовый эксплойт напишут, чёрные шляпы в основном бьют по площадям. Назначим это четвёртым китом:) Если этого нет — на сейчас Linux выгоднее по сумме факторов. Это, увы, несмотря на то, что по общему дизайну FreeBSD не хуже, а местами сильно лучше.
> Нагуглить смог только список портов: www.freebsd.org/ports/searching.html.
Ну вот и считайте по умолчанию, что то, что там названо — поставляется готовым в бинарке с указанной версией.
Если и будет где-то исключение, то всё равно максимум сложности — сказать локальный make install (или, например, portmaster). Тянуть, патчить самому — не надо, всё сделано за вас.
> И примонтировать ISO и из него поставить, я бы не назвал это «штатно».
Да, чуть сложнее. Но можно один раз сделать и распространить результат.
> Возможно что-то забыл, но как-то запомнилось что порты это именно про сборку из исходников, а pkg пакетный менеджер, который качает и устанавливает архивы с бинарниками.
Это и никогда не было так полностью, и скорее всего результат недочтения глоссария. Хотя результат типовой — очень многие так думают — значит, фряшникам следовало бы отдельно проинструктировать о правильном понимании. Они любят вспоминать про POLA, но именно тут сами его нарушают.
GEOM — мне хватало device mapper в Linux. Сейчас нигде не использую.
ZFS — у меня работал на Linux. Сейчас тоже нигде его не использую.
Netgraph — мне не нужен, да и на практике я его встречал совсем в уникальных кейсах. Вряд-ли когда-то потребуется
То есть для моей работы (обычный веб) FreeBSD бесполезен, и только приведет к затратам на эксплуатацию и никаких плюсов от него не будет.
В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?Ну или ты хочешь оптимизированную компиляцию (-march=native) под свою железку или нет…
Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
Очень надеюсь, что дойдёт до вас Грета, и выдвинет вам регуляцию, и станете вы carbon footprint уменьшать всеми силами под угрозой штрафов. И будете вместо 100+ нод использовать 5, я думаю что вам хватит — если вместо Ruby писать на Rust, или хотя бы на C#, и делаться всё будет в интересах того самого «бизнеса», на который вы молитесь.
Про облако тоже замечание в тему — вот что в облаке обычно не гарантируют (или слишком дорого), так это что узлы будут поддерживать все эти новые фишки.
Да, новый resolve меня пробесил в ubuntu не нашел как теперь глобально и просто прописать nameserver'а).
Да, несколько способов прописать сервис не шик.
Но, я уверен, что если выйдет какая-то местечковая прога для, например, для логического анализатора saleae, то она будет работать у меня. Я знаю, что в случае проблемы, в интернете больше шансов найти решение для linux, чем для unix.
Кроме того, поправьте меня если не так, та же ubuntu лучше оптимизированна для работы на ноутбуках, чем та же FreeBSD. Еще расскажите можно ли быстро и просто установить *BSD с шифрованием всего диска и LXDE?
История развития сборки фряхи для пользовательских ПК (настольных + ноутбуков): PC-BSD -> TrueOS -> Project Trident -> Void Linux.
В комментариях к статье на Phoronix создатели PC-BSD и её потомков жалуются на жизнь с FreeBSD — их патчи не принимали, и пр.
Линукс хорошо работает на настольных ПК и ноутбуках, xBSD — либо очень плохо, либо вообще не работают. Ноутбуки с предустановленным Линуксом есть в продаже — Acer, Asus, Dell. Линукс становится широко распространённой ОС. Драйвера для принтеров-сканеров зачастую есть для Линукса наравне с Win и Mac.
Про заимствование драйверов: когда ищешь их для какого-то устройства, то для Линукса — они уже есть, опробованы другими людьми и работают. Для xBSD — давай сам всё делай. Код берётся у тех, у кого уже работает — т.е. у Линукса. Да, можно конечно и самому всё делать, но зачем?
Преобразуя недавние слова Джо Байдена, «Нам не нужны обещания революции, нам нужно большее — результаты».
>Линукс хорошо работает на настольных ПК и ноутбуках, xBSD — либо очень плохо, либо вообще не работают.
Откуда такая информация? Вас послушать так Фря нигде не работает, для чего ж ее делают тогда? У меня лично еще ниразу не было проблем с установкой фри, у меня она работает от Raspberry до ITX решений, как в облаках так и на bare metal. Знаю что ставится и на брендовые сервера от той же HP, единственное нарекание что HP не пишет свои утилиты под нее.
>Ноутбуки с предустановленным Линуксом есть в продаже — Acer, Asus, Dell.
Тут есть большое НО, они продаются с Линуксом номинально как затычка, как MS-DOS так же предустанавливался раньше, просто что б не отчислять за Вин. При это там далеко не все работает, там в 90% случаев работает только встроенная ВК, нет никакой речи про Nvidia Optimus, потому что какой-нибудь Бамблби не поддерживает какую-нибудь 1050 и вендоры магически не отслюнявят ресурсы что б ее в Линуксе запилить, а зачастую даже поддержки дровами нет и возможно еще куча всего другого куда я уже не копал.
>Линукс становится широко распространённой ОС
Никогда он таким не был, процент его вообще не изменен и колеблется на уровне от десятых процента до 1% на ПК. По некоторым исследованиям, не w3c всяких по чисто вебу, а коммерческих доля ОС на серверах в 80% удерживает вообще Windows, процентов 10 линукс, Фря с остальными BSD в районе 5-7 и остальную часть другие ОС типа Солярки, AIX-UNIX и тд. Ну да в топ500 одни Линуксы — спасибо Scientific Linux, что-то мне кажется запили CERN ОС на базе BSD какой-нибудь топ500 занимал бы Unix. Существенные цифры, которыми любят хвастать фанаты, Линукс показывает благодаря сохо роутерам и смартфонам, ито уже гугол тот же пилит замену.
Таковы результаты.
В т.ч кроссплатформенную поддержку Фря из нее тянет.
wiki.netbsd.org/ports/evbarm/allwinner
Вот где прочерки стоят в случае linux стоит yes
Я спокойно ставил fedora для arm на allwinner. И более того все работает. Уже давно все разработчики таких плат перестали пилить свои ветки и вливают это все в mainline ядро.Речь точно про Allwinner? Про какие-то старые чипы, A10, A20?
а так есть PC-BSD/TrueOSУже нет. Сайт и репозиторий будут отключены, как только у разработчиков выдастся свободная минутка.
Еще расскажите можно ли быстро и просто установить *BSD с шифрованием всего диска и LXDE?Это несколько разных систем. Можно.
С энергопотреблением и ноутбучными вещами у линуксов лучше, да, и вообще с любой поддержкой железа, wi-fi — боль. Просто кому-то достаточно того, что есть.
Если хочется получить целостную систему, с централизованным управлением всем подряд, стоит попробовать NixOS. Там практически всё можно настроить в /etc/nixos/configuration.nix (какой-то пример с GitHub), прямо как в rc.conf. И бинарные пакеты (cache.nixos.org) прозрачно сосуществуют со сборкой из исходников, если где-то нужна кастомизация. А как сейчас обстоят дела во FreeBSD с одновременным использованием портов и пакетов?
Аргумент с ipfw мне не очень понятен — в GNU/Linux давно есть iproute2, в который входят все необходимые утилиты для настройки адресов, маршрутов, очередей. Фаервол можно настроить с помощью nftables (пример).
Аналогом GEOM действительно является device-mapper. Там есть и RAID (dm-raid), и более сложные топологии.
Аналога netgraph в таком же виде действительно нет. Но для простых задач можно обойтись и специфичными инструментами (тот же nftables, bridge/vlan filtering, netns, pppd/l2tpd/bluetoothd/...), а для сложных есть Open vSwitch.
Про трассировку много рассказать не смогу, но из быстрых работающих механизмов есть ftrace через debugfs и возможность навешывать bpf-программы в самые разные места. Для решения многих вопросов хватает tools/perf из ядра.
Кстати, а как так получается, что можно собрать систему без IPv4? Я сходу не могу придумать, как красиво отвязать реализацию TCP от IP (проблемы должны возникнуть, например, при вычислении pseudoheader checksum).
И чем вам мешает наличие IPv4 в ядре? Место на диске экономим?
Но самое эпичное было, когда systemd-journal начал падать и я даже не мог посмотреть логи.
Ну и еще целый шлейф багов.
Ну и странно держать ipv4 на сервере в ipv6-only сети. Косвенно это говорит о качестве кода, которым это все реализуется. Заглянув же в репозиторий кода ядра и увидев файлы tcp_ipv4.c и tcp_ipv6.c даже не будучи программистом можно понять, что «в консерватории что-то не то».
увидев файлы tcp_ipv4.c и tcp_ipv6.c даже не будучи программистом можно понять, что «в консерватории что-то не то».
Вы наверное знаете, что это разные протоколы? Там отличия не только в структуре адреса.
Да и не совсем копипаста там. Просто не стали городить уровни абстракции. Учитывая, что мы не ожидаем 10 разных реализаций TCP, я и как разработчик не вижу в этом проблемы. Больше похоже на исскуственный поиск дополнительных пунктов в список.
Причем интересно, что гну есть за что подколоть по делу — например разницу дистрибутивов мало описали — все эти утилиты типа ifconfig только для настроек интрефейса еще и только в текущей сессии настройки меняют. А вот если вы хотите прописать статический айпи адрес так, чтобы после перезагрузки хоста он остался, это у каждого дистрибутива делается по разному и настройки хранятся в разных файлах.
Мне не приходят в голову, к чему могла бы привести свобода в примере с systemd, кроме необходимости приделывать к машине все 10 разных ручек сразу, чтобы оно на разных дистрибутивах работало.
Вот тут вы, вероятно историю внедрения systemd не застали, по этому так говорите. Systemd внедрялся в принудительном порядке. Была целая история с советом в debian. И вероятно потому, что systed такой хороший некоторые дистрибутивы обратно рассматривают альтернативную возможность использовать другую систему инициализации.
Реально, с «внедряли потому, что это лучше» вы сильно маху дали. Когда внедряли это было не лучше далеко. Особенно для простых админов, которые не могли на новой системе запустить вполне себе банальные сервисы, и нужно было либо брать предыдущую версию ОС, либо проникаться замыслом поттеринга и писать самому инициализацию. Это такое себе добровольное решение. Тех, кого с этим лихорадило в то время спросить. Они бы вам в лицо плюнули бы. Ну, и были шизики, которым в кайф что-то новенькое поковырять, попереписывать, что уже прекрасно работало… в те времена только такие смотрели с пафосом в горизонт и уверяли, что, когда всё отладится в systemd, когда все разработчики адаптируются к новой систем, тогда заживём. Зажили… Но это было через боль и страдания, да и вовсе не добровольно.
Я наблюдал эту драму в прямом эфире.
И да она сильно лучше. Критики было много, но ворох костылей который она заменяла была еще хуже. Они просто привычные что вы собственно и подтверждаете.
И да я вот поддерживал сервис на нескольких системах одновременно. И вот когда завезли systemd стало возможным в сервис положить инициализацию. А раньше под каждую систему иди напиши, и у каждой свои тараканы. Так что systemd лучше того что было. А я знаком был с 4 разными системами инициализации. Нет спасибо я лучше systemd unit напишу.
Есть другие минусы, но общее ощущение порядка на FreeBSD гораздо лучше влияет на нервную систему :)
С Linux нервов у меня гораздо больше тратится. Но есть области, где он практически не заменим, например, у меня на ноутбуке.
Хороший же админ будет знать плюсы и минусы обоих систем и выбирать систему под задачу (как уже написали выше).
Берете и завозите. Вам всего лишь нужно kubelet переписать ))) что у него под капотом — контейнеризация линукс или что-то еще — уже суть менее важно.
поддерживающая зависимости между службамиэто ошибочное утверждение — на самом деле, указанные в стартовых файлах зависимости учитывается только при выборе порядка запуска служб
> Если разработчики говорят что такой-то функционал готов к промышленному использованию, то значит это так.
Но самого такого функционала значительно меньше.
> Почти всё что касается конфигурирования уровня ОС, глобального, использует sysctl.
1) Который при этом является бинарным интерфейсом.
2) Нет иерархического аналога sysfs. Некоторые аналогичные вещи можно получить разбирая те sysctl, которые дают блобы. И то не все.
Простейший procfs попроцессно — до сих пор необязательная фича, якобы из-за её секьюрити проблем.
> А можете получить дистрибутив в котором нет и компиляторов
Вообще-то наличие компилятора на боевом сервере может быть тупо запрещено, и это даже будет правильно. Нефиг давать взломщикам лёгкую возможность собрать бинарник на месте.
Базовая система FreeBSD, включающая в себя всё для работы вплоть до пересборки самой системы, но в которой в базе нет даже sudo — это очень странная штука. То, что недавно её начали распиливать — хорошо, но поздно и медленно.
> И при этом, как мне кажется, ни один здоровый человек не сможет сказать что синтаксис правил для iptables удобен — он выполняет задачу, но все будут писать собственные скрипты/обёртки с отличным синтаксисом для удобного конфигурирования типа ufw.
Реально именно из-за вложенных цепочек он практически в разы удобнее — говорю как активно использовавший обе стороны (хотя от FreeBSD только ipfw). Переходы на ipfw в какой-то момент становятся слишком сложными. Вот отсутствие таблиц в том же стиле, да, менее удобно, но есть близкие аналоги для большинства случаев.
> Кроме sysctl имеется /sys, а также ещё и дубляж аналогичных ручек управления через специфичные команды.
Linux sysctl это чисто имитатор BSD стиля на базе /proc.
> Уже 12+ лет имеет надёжную работающую ZFS реализацию.
Только вот в результате базовый набор FS в FreeBSD жёстко ограничен UFS и ZFS. Загрузчиков для других FS нет. Нет и штатного аналога initial ramdisk, который бы позволял запуститься откуда угодно и дальше подключать свои драйвера. В инсталляторе используется костыль, который позволяет запуститься из такого образа, но он непригоден для работы запущенной из-под него полноценной системы (нет аналога ни pivot_root, ни mount поверх, как от лени делают в новых линуксах).
Что же именно до ZFS — я с неё сбежал после того, как несколько раз при заполнении диска на 99% она начинала тупо всё блокировать какой-то внутренней вознёй. Мне пофиг, что за мусор она собирала и как уплотняла, но пусть это делает в фоне, а мне отдаст чистое «нет места».
> Не знаете с чего начать? man intro, а дальше куча ссылок на другие intro или описания подсистем.
И при этом вся документация плоская. Формат man'а непригоден для структурированного хранения, как в texinfo, аналога нет (стандартные /usr/share/doc/{psm,smm,usd} это всего лишь ещё один уровень).
> Простое и логичное управление памятью и нехваткой памяти.
Здесь прошу больше подробностей. Фактически, FreeBSD VM принципиально лучше только отсутствием 12309: что бы ни говорили линуксоеды, он и сейчас регулярно проявляется, а старожилы ещё помнят, как он был внесён в 2.1. Но OOM столь же вероятен (ещё бы, оба — наследники Mach) и будет рубиться столь же грубо.
> Имеет систему портов и параллельно систему бинарных пакетов.
Вот это безусловно плюс. Хотя скачать какой-нибудь SRPM, подпатчить и воткнуть в систему — ничто не мешает на типовом линуксе, но через порты это делать тупо удобнее. Опции сборки — тоже вкусно (если их применять с умом).
GEOM, netgraph — да, в безусловный плюс. Но GEOM тоже надо давно доработать с умом. Начать, может, с разворота терминов (provider и consumer по всей нормальной логике должны быть переставлены наоборот). А ещё у меня было, что в зависимости от фазы Луны или GPT ловит метки разделов и тогда пишет их в /dev, или не ловит и тогда в /dev исходные названия типа ada1p1. В Linux всегда выставлены все метки, и можно надёжно опереться на любую схему — UUID внутри раздела, UUID в GPT, регистрация в драйвере по типу /dev/sdb2 или длинный путь согласно физическим адресам на шине.
> Имеет jail подсистему контейнеров с 2000-го года.
> LXC, как нечто наиболее похожее и близкое, появилось спустя 10 лет.
VZ был раньше. OpenVZ как его открытый аналог, насколько помню — тоже. Система тонкого регулирования ресурсов через cgroup родилась раньше FreeBSD'шной, jail вначале умел быть ограничен только IP и парой базовых настроек, не было пространств uid'ов и т.п.
LXC в нынешнем виде это просто публичное средство управления cgroups для jail — да, плохо, что было не так рано, но закат вручную делался заметно раньше LXC.
> Всё это всё равно не покрывает все возможности kqueue.
Ну если сравнивать, что кроме UFS и ZFS всё остальное — ересь, то можно было бы и сравнять возможности. Это про мониторинг файлов: он есть и работает — но стиль другой, да. Остальные возможности kqueue делаются внешними средствами вроде timerfd, signalfd. Что линуксовцы откровенно сделали по NIH — да, грустный факт. У epoll чуть-чуть хуже интерфейс (одна модификация за раз, нельзя одновременно получать fd и udata). В остальном вполне достойное средство.
> Имеет CARP подсистему
CARP был хорош на 2000. Сейчас это откровенно тупой костыль для бедного случая.
У меня в ISP всё было на FreeBSD (это до 2008) и на десктопе держал её с 2001 до 2017. Ушёл по грустной причине — система не жила дольше полдня с процессором (Haswell), что-то там недоработали, причём даже в current'е не было нужных правок. Возвращаться с Kubuntu уже не хочется.
— www.unixsheikh.com/articles/why-you-should-migrate-everything-from-linux-to-bsd.html
— www.unixsheikh.com/articles/why-you-should-migrate-everything-from-linux-to-bsd-part-2.html
Я сам уже больше 20 лет использую FreeBSD и Linux и знаю их достаточно хорошо.
Очень уважаю FreeBSD за стройность и отличное качество кода.
(да, мне приходилось изучать и патчить исходники и того и другого)
Если бы я писал код как в Linux, то мне было бы стыдно.
Так что по всем приведённым пунктам с автором согласен.
Тут уже предсказуемо возникла дискуссия, но как это часто бывает, многие (не все конечно) толком не прочитали то подробное сравнение что человек привёл.
PS
Кстати, представьте себе что разработчики добавят свою реализацию containerd в FreeBSD.
Linux будет трудно конкурировать с ОС у которой отличная сетевая и дисковая подсистема.
Телефоны и лэптопы — это не target аудитория для FreeBSD, тут я согласен.
Добавлю свои 5 копеек. Я сильно рад приходу в линукс systemd — наконец то пришла унификация и это здорово. Очень буду рад если также унифицируется и сеть/файрвол. Что лично мне не нравится в линуксе — вышла например Centos 8, я на радостях скачал в первый же день и понял что GitLab на ней не ставится. Прошло пару месяцев, но гитлабовцы так и не посчитали нужным обеспечить совместимость с новой ОС. На 7-ке никаких проблем, на 8ке нужно красноглазить и не факт что будет смысл. То есть чтоб полноценно использовать Centos 8 нужно ждать какое-то время пока мантейнеры адаптируют софт под новую ОС, а они как-то не слишком спешат. Ну и конечно каждый вариант линукса это свои репозитории, версии софта в которых часто сильно отстают от действительности. Во FreeBSD в свою очередь не хватает докера/кубера и с быстродействием похуже, bhyve сильно отстает от хотелок. Ну и ембедовка, тут линукс впереди.
И при этом, как мне кажется, ни один здоровый человек не сможет сказать что синтаксис правил для iptables удобен — он выполняет задачу, но все будут писать собственные скрипты/обёртки с отличным синтаксисом для удобного конфигурирования типа ufw.
Это такое мнение автора, не более. Почему «все будут», почему iptables неудобен? До этого места читал, вроде бы соглашаясь с автором (начинал давно с FreeBSD, люблю ее), но прочитав, стал относиться к написанному проще. Простите.
rdr pass on $ext_if inet proto tcp to port http -> $ext_if port 8080и iptables:
iptables -t nat -A PREROUTING -p tcp --dport 5555 -j REDIRECT --to-port 22
iptables -t nat -A OUTPUT -p tcp -s 127.0.0.1 --dport 5555 -j REDIRECT --to-ports 22
Тот же скрипт написать на iptables, нет проблем. Один раз сделал, потом везде его используешь, только правки вносить. Нет проблем. А то там firewalld, там ufw. Вот это неудобно. Я что, не здоровый человек после этого?
Основная проблема скриптов — они сначала сбрасывают все правила, а потом все правила применяют по одному. Фу-фу-фу. В частности, весело, когда на той же машине ВПН или докер крутятся. После такой настройки и впн, и докер становятся неработоспособны. До перезапуска сервиса
Как пропатчить KDE под FreeBSD?
:-)
Один коллега находил источник этого бага — ещё в 2.1.каком-то — «оптимизация» стиля VM некоторым ломастером, который «у меня всё работает», когда у него было 2GB RAM в то время, когда остальные с трудом позволяли себе 64MB :(
Ну и до сих пор ничего не изменилось, в нескольких видах.
Я вот сегодня опять нарвался (ну и побежал лечить sysctlʼами...)
Какой-либо унификации документации, конфигурации, вывода информации в софте толком нет. Всюду и везде будет явно и отчётливо видно, что вот эта небольшая программа/утилита написана одним человеком, а вот эта другим. Всюду и везде разные подходы ко всему: один считает так, другой считает так.
Золотые слова. Добавлю, что ещё хуже дело обстоит с синтаксисом вызова этих самых команд и конфигурацинных файлов. Там логика своя у каждого свободного художника. И есть впечатление, что часто этот художник был нетрезв или обкурен.
Поддержка всякого ширпотреба домашнего, ноутбуков, desktop-ов наверняка будет лучше.
Поскольку есть тег netbsd, посмею спросить: разве не также дело обстоит и в NetBSD, у которого цель -- работать везде?
Вообще, началось всё с того, что прочитал на хабре статейку про FreeBSD (фри-бздю), где расписывается, какая же она хорошая, и лучше чем Linux. Ну, на счёт прям "хорошая" не знаю - но ZFS в ней нативно поддерживается, а я уже давненько собирался с этой файловой системой познакомиться на практике. Ещё, автор пишет, что "бздя, в отличие от линукса - это целостная ОСь", которая даже собирается полностью вся из "одного репозитория" - а не как линукс, где собсно и существует такое понятие, как "дистрибутив", и их компонуют совсем разные люди, из разных частей. А Linux - это только ядро ОС.
С этими тезисами я, пожалуй, согласен. Но на этом все преимущества FreeBSD и заканчиваются. Я затестил - благо, сейчас есть свободная железка, а именно ноутбук Xiaomi Notebook Pro i7-8550U, который мне любезно предоставил "на поиграться" братан. Так вот, на этом железе она тупо не работает. От аккумулятора ноутбук прожил 40 минут. Это значит, что никакого управления питанием и в помине нет. Wi-Fi, не смотря на то, что в адаптере есть и 802.11n, и пяти гигагерцовый 11ac - работает ТОЛЬКО в режиме 11b - даже не 11n. Ну это вообще фейспалм.
🤦♂️
(И в ноутбуке он припаян, б🤬ь!)
Но вот на счёт целостности - таки я готов поспорить. Дрова для видюхи в бзде - "из линукса", вместе со всей подсистемой KMS/DRM (вообще это хорошо, но всё-таки). Пока игрался - на глаза попался патч, в котором "какие-то там демоны перевели на использование netlink" - тоже из линукса (опять-таки - движение в правильном направлении, потому что всё остальное до сих пор сделано на ioctl, что есть абсолютное зло). И так - много с чем.
Помимо "эмулятора венды" (WINE), есть ещё "эмулятор линукса" (Linuxulator, гг), и нужен он за тем, что под бздю тупо есть не весь софт, который нужен, в основном проприетарщина всякая, но опять же - что делать, если его использование не избежать?
Ну и capabilities на всё и jail'ы - да, круто. Появились раньше линуксовых namespace'ов (и контрольных группу, cgroup; всё вместе это нынче называется "контейнеры"). Но системные сервисы до сих пор не переведены на их использование. Почему? Потому что "Mewburn rc.d", читай - шелл-срипты во все поля. Это, извините, прошлый век, и жутко бесит и не поддерживаемо. Собсно, никто менять по этому и не хочет. "Работает же - зачем менять?". Ну да, ну да, "работает". Порты (система сборки софта) - туда же, "шелл во все поля".
Нет, вы конечно возразите, что "ноутопроблемы, а фри-бздя - это ОСь для серверов, при том - настоящих, которые по 10k rps тянут и даже не икают".
Не соглашусь. Ноутбучное железо - не оправдание для ОС, если мы таки утверждаем, что "бздя лучше линукса". Линукс работает на том же железе - а бздя нет. И если уж мы вообще хотим их сравнивать - то должна работать, и не потому что мне так хочется, а потому что "хорошая (лучшая?) ОС должна работать на всё, даже на утюге".
"Исходники же есть, возьми да и запили поддержку своего железа".
Вот я, допустим, и рад был бы "взять да и запилить". Но вышеупомянутая система сборки к этому никак не располагает - барахтаться в лапше из shell-скриптов и make - крайне сомнительное удовольствие. Как раз по этому BSD так медленно развивается, как ОСь. Засилие старпёртсва и скуфства.
То есть, может быть раньше FreeBSD и была целостной системой - то сейчас она практически превратилась в "отрицание самоё себя", потому что "тащит из линукса всё, что плохо лежит", в ущерб развитию собственных аналогичных подсистем и решений.
Как-то так.
P. S. Там дальше ещё продолжение есть. Кому интересно - подписывайтесь на наш канал я могу запостить.
Если коротко, то FreeBSD это высокое качество, надёжность, удобство и простота работы. GNU/Linux это зоопарк, помойка малосвязанного кода, мало чего доделываемое до конца, отсутствие документации, хаос, базар.
Да, это так. Но почему при этом базар выставляется минусом? Почему например нет отсылки к книге "Собор и базар", без которой подобные утверждения слишком уж предвзяты?
FreeBSD: гораздо лучше GNU/Linux