Комментарии 390
Даешь Kubernetes на FreeBSD!
Было бы просто прекрасно.
Обожаю эту ось, к сожалению они уступили линуксу на волне хайпа и не смогли в виртуализацию(bhyve и jail только).
Обожаю эту ось, к сожалению они уступили линуксу на волне хайпа и не смогли в виртуализацию(bhyve и jail только).
Да пожалуйста!
www.bsdnow.tv/337
www.bsdnow.tv/337
НЛО прилетело и опубликовало эту надпись здесь
Ну соглашусь с Вами, но есть
bastillebsd.org/templates
Прекрасная система от Олега Гинзбурга, активно живущая и с развивающимся сообществом
www.bsdstore.ru
bastillebsd.org/templates
Прекрасная система от Олега Гинзбурга, активно живущая и с развивающимся сообществом
www.bsdstore.ru
Есть более короткий формат:
Если коротко:
— FreeBSD: гораздо лучше GNU/Linux
— чем лучше?
— чем GNU/Linux…
— FreeBSD: гораздо лучше GNU/Linux
— чем лучше?
— чем GNU/Linux…
Будьте добры скрыть это в черновики и подготовить более основательное сравнение, без субъективной оценки. Плашка «далее написанное — мое личное мнение» не помогает, особенно в статье на тему «мои фломастеры более вкусные, чем другие».
BSD: Уже 12+ лет имеет надёжную работающую ZFS реализацию.
Linux: До сих пор production ready ZFS нет.
А теперь барабанная дробь — BSD переезжает на кодовую базу ZFSonLinux, который теперь OpenZFS.
*задумчиво* в Oracle Linux есть и поддержка zfs, и готовые ПАК под zfs стойками продаются уже несколько лет как.
У вас ссылка не приложилась.
Наверное, потому что и не прикладывал: вот рекламная ссыль на zfs одной из последних версий https://www.oracle.com/storage/nas/zs7-2/, вот реклама одной из первых версий, датированная 2014 годом http://www.tadviser.ru/index.php/%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82:Oracle_ZFS_Storage_ZS3_Series
Или вы о чём?
Не знаю что имел в виду оригинальный автор, но Oracle ZFS storage appliance (ZFS SA) базируется на Solaris и там не OpenZFS.
Посмотрел — да, вы правы: в серверах oracle zfs стоит солярка, а zfs на ol смонтировалась как том nfs. К тому же, нашёл официальный ответ на форумах оракла про Zpool: «Oracle does not currently offer ZFS as a supported product for Linux.»
Похоже, ввёл всех в заблуждение, извиняюсь.
Похоже, ввёл всех в заблуждение, извиняюсь.
Вы долго эту чушь "про переезд на кодовую базе ZoL" нести будете?
Нет никакой "кодовой базы ZoL", а есть репозиторий где на базе OpenZFS пилили костыли для Linux (впрочем, не слишком успешно).
Было принято решение о слиянии базовых репозиториев, где велась разработка ZFS для различных систем на базе ZoL потому что он более жив, чем использовавшийся ранее аналогичный в проекте IllumOS.
Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS.
на базе ZoL потому что он более жив
так про это и речь
Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS.
на гитхабе уже
Нет никакой «кодовой базы ZoL», а есть репозиторий где на базе OpenZFS пилили
Ну это и есть кодовая база проекта ZoL. Речь именно о жизни в конкретном репозитории, до этого все OpenZFS проекты жили отдельно, теперь непосредственно в репу ZoL добавляют обвязки для сборки из неё и для FreeBSD.
Чем вам «кодовая база» не нравится?:)
Было принято решение о слиянии базовых репозиториев, где велась разработка ZFS для различных систем на базе ZoL потому что он более жив, чем использовавшийся ранее аналогичный в проекте IllumOS.
Как непосредственно участвовавший — слияния репозиториев нет, ZoL активно пилит свои фичи и он уже 2-3 года впереди, мы давно забекпортили все нужные изменения из Illumos и уже несколько лет бекпортят из ZoL в обратную сторону. В том числе и «костыли», как вы их называете.
Репозиторий ZoL, кстати, на днях будет переименован в OpenZFS
Уже.
Как непосредственно участвовавший
Ну тогда тем паче грешно дезинформировать публику заявляя о "переезде не кодовую базу ZoL", тем более что, со своей стороны, я вижу, что за примерно год прошедший с начала объявления процесса миграции разработка ZFS во FreeBSD фактически заморожена и она получила из кодовой базы наработанной в рамках ZoL примерно ничего, в то время как идущая на "2-3 года впереди" ZoL, наконец-то, получила SSD TRIM и ZFS on root.
ну вроде как скоро получит special allocation class, ИМХО мегаполезная фича
что за примерно год прошедший с начала объявления процесса миграции разработка ZFS во FreeBSD фактически заморожена и она получила из кодовой базы наработанной в рамках ZoL примерно ничего
Именно.
ZoL, наконец-то, получила SSD TRIM
С другой реализацией с нуля, если что.
и ZFS on root.
Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.
Не понимаю что вы хотите доказать. FreeBSD будет собираться из репы ZoL->OpenZFS? Да. «разработка ZFS во FreeBSD фактически заморожена». Вот и переезд на кодовую базу. Вас смущает терминология?
Если хотите что-то объяснить, то скажите просто что вам в этом выражении не нравится.
Доказывать тут ничего не нужно, поскольку на сегодня объективно FreeBSD не использует "кодовую базу ZoL", что аннулирует ваше начальное заявление.
Вы серьёзно? Я 5 лет этим на линуксе пользуюсь уже, и я не первый.
Я не знаю что вы (и откуда) используете, но вижу что в популярные дистрибутивы это стало заезжать в прошлом году (пример). Впрочем, я особенно за этим не слежу ввиду отсутствия интереса да и надобности.
А подскажите что за терки с ZoL в линуксе, вроде Линус сильно недоволен и вроде как выпилил ядерные структуры для поддержки ZFS в ядре. Удалось как-то решить эту проблему? Я ZFS в линкксах не пользуюсь поэтому не знаю…
Да, проблему решили, GKH принял патч, где несколько функций начали экспортировать только для GPL совместимых модулей. Пришлось сделать патч и реализовать просто часть логики на стороне zfsonlinux.
Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.
Т.е. мейнтейнеры ядра придерживаются подхода «на всё, что не в ядре — нам плевать» и они не пытаются помогать сторонним проектам, а иногда (не буду говорить насколько осознанно) вставляют этим палки в колёса. Но всё можно обойти на своей стороне.
Не Линус, а Грег, не выпилил, а упорядочил свой код, недоволен чужим недовольством, т.к. с чего бы человеку GPL заботиться о ПО, намеренно и умышленно выпущенным под несовместимой с GPL лицензией. Могли выпустить под совместимой лицензией — никто не мешал.
Идут споры о совместимости — несовместимости лицензий: GPL у Linux и CDDL у ZFS.
Вроде как поставка готовой сборки Linux с включённой поддержкой ZFS вообще незаконна, чем занимается Canonical, но вроде как больше никто из крупных поставщиков.
У Linux есть «своя» BTRFS, использующаяся по умолчанию в SUSE и openSUSE, и ими же поддерживающаяся (кроме прочих). Redhat отошёл от BTRFS и делает свою Stratis (или что-то там ещё).
Подробнее см.:
ru.wikipedia.org/wiki/ZFS#Linux
en.wikipedia.org/wiki/ZFS#Linux
ru.wikipedia.org/wiki/CDDL
en.wikipedia.org/wiki/Common_Development_and_Distribution_License#GPL_compatibility
Идут споры о совместимости — несовместимости лицензий: GPL у Linux и CDDL у ZFS.
Вроде как поставка готовой сборки Linux с включённой поддержкой ZFS вообще незаконна, чем занимается Canonical, но вроде как больше никто из крупных поставщиков.
У Linux есть «своя» BTRFS, использующаяся по умолчанию в SUSE и openSUSE, и ими же поддерживающаяся (кроме прочих). Redhat отошёл от BTRFS и делает свою Stratis (или что-то там ещё).
Подробнее см.:
ru.wikipedia.org/wiki/ZFS#Linux
en.wikipedia.org/wiki/ZFS#Linux
ru.wikipedia.org/wiki/CDDL
en.wikipedia.org/wiki/Common_Development_and_Distribution_License#GPL_compatibility
Их позиция "нам пофиг на всё, что не в ядре" имеет право на жизнь, жаль что при этом начинаются политические игрища по поводу лицензий, при этом никто не агитирует gkh и Линуса вливать код zfs в ядро. Но зачем осознанно портить жизнь другим людям?
Но вот такой патч упорядочиванием кода назвать сложно, по сути убран экспорт функции для nongpl консьюмеров, и всё https://github.com/torvalds/linux/commit/12209993e98c5fa1855c467f22a24e3d5b8be205
Что мешало оставить экспорт как было раньше? Вот и недовольство.
Что мешало оставить экспорт как было раньше?
Ну вообще каждая функция объявленная как static в таком огромном
проекте это благо. Это и ускоряет компиляцию и линковку, и упрощает поддержку, так как чем меньше функций доступных извне данной единицы трансляции тем меньше межмодульных связей, и думаю очевидна польза от уменьшения связанности огромного проекта?
С козырей зашел)
… который не совместим с ядром 5.5, потому что… не GPL и Linus решил, что еще один метод будет GPL-only
И так при каждым выпуске ядра было и будет продолжаться :)
несовместимость только с PREEMPT ядром, так норм:
CONFIG_PREEMPT_NONE тоже годится, особенно для сервера
p.s. кстати, дело c «нелюбовью» не только в лицензии, но и в идеологии комбайн (aka Rampant Layering Violation?) vs модульность
# 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 для всех этих тысяч популярных проектов с открытым кодом дописывают документацию, переделывают им формат конфигов и так далее? Почему-то я очень в этом сомневаюсь.
Думаю, что речь идёт про базовую систему: www.freebsd.org/doc/en_US.ISO8859-1/books/handbook
Для конечного юзера софт один до тех пор, пока его разработчик юзает только posix, а иначе терпит.
Например, есть доклад от nginx про ядро, там есть явные места про «в bsd задизайнено удобнее»: sendfile, epoll_ctl.
p.s. Кстати, бы очень интересно услышать отзыв от nginx команды про io_uring
Например, есть доклад от 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.
Так как я работаю восновном с веб и почтовым хостингом то в этих прикладных областях доля FreeBSD ничтожно мала.
Также отмечу что для СХД FreeBSD (FreeNAS и аналоги) встречается часто благодаря zfs.
Если есть ниши где FreeBSD также используется широко — расскажите об этом, думаю всем будет интересно узнать.
Я предполагаю что мы говорим про администрирование серверов, и возможно СХД и странно читать что:
«Поддержка TRIM появилась лишь в прошлом году, по сути не позволяв достойно использовать ZFS на SSD.»
Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?
И это нисколько не мешает использовать SSD.
TRIM имеет смысл только на десктопных SSD, для серверных он не нужен.
И немножко про zfs:
zfs является бесспорно отличной ФС, также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs.
Вас не смущает что в большинстве RAID контроллеров нет поддержки TRIM?
А вас не смущает, что RAID контроллеры противопоказаны при работе с ZFS?
также в линуксе уже давно есть btrfs кторая сейчас является достойной альтернативой zfs
Не является даже близко. Почитайте эпичный тред на IXBT с обсуждением реально с ней работающих… Там, очень мягко говоря, до продакшн реди ещё как до Луны пешком. В общем, Redhat не даром её из кодовой базы выпил к чертям.
Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
«Redhat не даром её из кодовой базы выпил к чертям.» я лично считаю что это решение было политическим ради того чтобы не уменьшалась доля xfs.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Меня смущает то что вы почемуто решили что TRIM нужен на серверных SSD.
Отнюдь.
Меня смущает что вы, видимо, считаете что ZFS хорош только на серверах. Так вот нет. Boot environments и snapshots, не говоря уже про надёжность хранения, чрезвычайно полезны и востребованы и при персональном использовании.
Чтото я не могу нагуглить «эпичный тред на IXBT про btrfs», поделитесь ссылкой пожалуста.
Честно говоря мне лень, но вы найдёте. Там реальный "адъ и Израиль".
UPD. По-моему это был тред про NAS.
Ссылочку на тред про ZFS на IXBT скиньте пожалуйста.
он не совсем про 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 просто сильно заигралась. Никому не нужно такой ценой идеальность.
У меня вон есть серверы на SUSE Linux, первом выпуске. Тоже еще работают. Сколько им лет? 15?
Убунту это не серверная среда. Смысл ее ставить на сервер, а потом использовать как аргумент.
Имхо FreeBSD просто сильно заигралась. Никому не нужно такой ценой идеальность.
Все дистрибутивы Linux — суть Linux. Отличия в части «серверной среды» минимальны, ибо базируются на функционале ядра. Даже systemd теперь практически везде — вроде все чуть ли не молятся на него, а на деле, можно убить кучу времени пытаясь понять, почему служба не стартует. И окажется, что это чудо _думает_ что демон жив и здоров, а значит не надо ничего делать.
Что касается серверов на 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
11.3? 12.1 уже давно надо.
Продуктивный же пока ещё 12.0.
27 октября будет релиз 12.2.
27 октября будет релиз 12.2.
www.freebsd.org/releases
11.3 вполне Ок, особенно для старого железа.
Most Recent Releases
Production Release
Release 12.1 (November, 2019)
Release 11.3 (July, 2019)
11.3 вполне Ок, особенно для старого железа.
Учитывая какой был раздрай и бардак до systemd, его наличие благо. Но как и все поделия Поттеринга, нужно подождать пока он перестанет его писать :) И тогда станет все прекрасно и хорошо. Как это стало когда он перестал активно пилить pulseaudio. Как визионер он молодец, но вот его код и то как он это делает нууу такое :)
Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз.
Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз.
"Насчет же а как же в разобраться, ну дак почитайте документацию к systemd там не так уж много, достаточно сделать это один раз."
У вас хорошая память, вам повезло ..
Читайте концепции и то как устроен unit файл. Не надо читать там все специфические случаи, там действительно много что сделано, так чтобы скрипты надо было писать только в 0.01% случаев. Когда надо фичу M открыли документацию да посмотрели.
Да не с unit фалом то проблем нет, проблема в том какие зависимости прописать под ситуацию, было ровно 2 кейса, монтирование root раздела с dm-raid (вышло так, при миграции с win) и перевод видеокарты в low режим, со вторым чуть проще (разгон турбины, нагрев, не такой шустрый) а вот с первым было трудно понять куда его ставить :)
большинство RAID контроллеров поддерживает UNMAP, с которого скопирован TRIM. Кроме того ZFS рекомендуют использовать не с RAID контроллерами а с HBA, т.к. у последних задержки ниже, а функциональность первых не востребована.
это нисколько не мешает использовать SSD.
Ну, если не смущает необходимость регулярно менять диски. И если не смущает постепенная деградация их скорости. Оба эффекта мы ловили.
В 2000 году FreeBSD не умел грузиться с extended partition. А lilo и Linux умели. Это похоронил вряху для меня. Субъективно.
Простите, но ссылаться на 2000 год также "актуально", как обсуждать сейчас достоинства и недостатки Windows XP
Так оно и сейчас вроде не умеет.
Другое дело, что там кроме ZFS больше нет файловых систем нормальных. ufs — зеркало из 2 дисков по 1тб, fsck после хард резета занимает 6 часов. Нормально?
Другое дело, что там кроме ZFS больше нет файловых систем нормальных. ufs — зеркало из 2 дисков по 1тб, fsck после хард резета занимает 6 часов. Нормально?
Можно (нужно) включить журналирование для этой ФС, вместе с soft-updates (SU+J). Занимать будет секунды.
SU нужно для ускорения работы фс, разрушение данных как раз при аппаратном ребуте будет только сильнее. А журнал — он там как 5 нога, сбоку приделан костылём. И под него нужно или уменьшать раздел, или иметь место после раздела. Точных значений не скажу, лет 10 назад последний раз активировал, но помню что без освобождения места за разделом журнал не сделать. И помнится что с ним существенно проседала производительность…
Хотя может за 10 лет сильно поменялось всё, но вообще на такие объёмы только zfs имело смысл, имхо разумный предел для ufs — гигабайт 50-100.
Хотя может за 10 лет сильно поменялось всё, но вообще на такие объёмы только zfs имело смысл, имхо разумный предел для ufs — гигабайт 50-100.
Ваша претензия была к времени fsck. На любой ФС без журнала (ну и не CoW) это будет долго, по очевидным причинам.
То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).
С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
То, что вы написали про журнал, это похоже вы руками делали gjournal (10 лет назад возможно только такой вариант и был). Сейчас это автоматизированно можно сделать, просто одним аргументом к newfs. И производительность, похоже, тоже страдала из-за этого (хотя с журналированием она в любом случае просядет).
С SU вы всегда будете иметь консистентное (работающее) состояние ФС. Без него вы рискуете «терять» часть ФС, а то и всю. Без SU вы вынуждены всегда делать fsck при сбоях. С SU вы всегда можете подмонировать и работать с ФС. Единственное от чего SU не обезопашивает, так это от утечки места при сбоях (блоки диска могут быть помечены как занятые, хотя это не так): только для этого нужен fsck, время которого сокращается за счёт журнала.
Простое и логичное управление памятью и нехваткой памяти.
а что там вместо OOM killer?
Он просто работает. Причём работает так, что даже мысли не возникает об использовании своего отдельного OOM "с блекджеком и шлюхами" в userland как это теперь водится в Linux.
Интересно а как? Вот есть 2 user space процесса постепенно выбирающих память до предела, какое решение?
Немного не по теме, но например в MacOS при нехватке памяти (и свопа тоже) ОС фризит процессы которые запрашивают аллокацию. Это несколько раз спасало меня позволив разрулить ситуацию, закрыть что-то тяжелое и ненужное, а потом разморозить процессы и они продолжали работу штатно. Своп у меня отключен, а великолепное сжатие ОЗУ на лету тоже не всесильно.
Такое поведение возможно при существовании гарантированного резервирования памяти под системный процесс, насколько я понимаю, проблемы возникают из-за механизмов типа copy on write, я в принципе далёк от системного программирования, но на мо взгляд такие механизмы очень усложняют отслеживание процесса которой запросил больше чем доступно, в итоге тот самый oom killer который по умолчанию настроен на работу до последнего (ведь крайний запрос на память может быть от системного процесса не смотря на то что 99% съел условный браузер) просто не успевает отработать и в итоге выстраивается очередь подвисших процессов.
Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб. RAM, насколько я понимаю (из прочитанного лет 7-8 назад) из-за особенностей алгоритма наличие swap даже небольшого размера частично решает проблему(зависаний нет совсем, но да что-то будет прибито).
> проблемы возникают из-за механизмов типа copy on write, я в принципе далёк от системного программирования, но на мо взгляд такие механизмы очень усложняют отслеживание процесса которой запросил больше чем доступно
Именно так.
Заметку по этому поводу я не обновлял по сути где-то с 2002 года. И сейчас ничего не изменилось.
> Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб
Своп помогает — за счёт превращения исчерпания памяти в торможение программ — и даёт время, если есть админ или автоматический мониторинг, остановить проблему до наступления критического исчерпания. Может, поэтому никто и не чешется лечить по сути.
Именно так.
Заметку по этому поводу я не обновлял по сути где-то с 2002 года. И сейчас ничего не изменилось.
> Дома на debian эта проблема решилась добавлением 1Гб swap при 16гб
Своп помогает — за счёт превращения исчерпания памяти в торможение программ — и даёт время, если есть админ или автоматический мониторинг, остановить проблему до наступления критического исчерпания. Может, поэтому никто и не чешется лечить по сути.
Про это вроде и писал, в общем проверил на себе работает…
Вашу заметку не читал, вроде (память ненадёжная штука, не уверен), мысль о механизмах пришла в голову когда где-то читал о самом механизме передачи крупных блоков памяти.
за счёт превращения исчерпания памяти в торможение программ
Только из-за современных nvme или ssd этого почти незаметно.
Не соглашусь. Точнее, не всегда и не везде это так.
Вот у меня дома 8 ГБ оперативки, и своп на 1ГБ. Однако, когда прожорливый процесс подбирается к потолку (это около 7,4...7,6ГБ), он и вся система начинает жутко тормозить. До того, что сложно (или невозможно в адекватное время) переключиться по Ctrl+Alt+F2 на консоль и грохнуть там процесс.
При этом swap и вся система на SSD, и swap на отдельном разделе. И oomkiller не срабатывает почему-то.
Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).
Для конкретики,
Процесс — игра Deus Ex: Mankind Devided, запущенная из steam.
В процессе игры иногда встречаются моменты, когда логично и понятно, что будет занято много памяти, и на компе индикатор активности диска сразу начинает активность, а игра подвисает, и иногда может даже «прожевать» этот пик нагрузки на оперативку, используя swap, но чаще приходится делать hard reset кнопкой.
P.S. Да, я понимаю, что лучше просто добавить память. Но не всегда можно быть богатым и здоровым :-)
Вот у меня дома 8 ГБ оперативки, и своп на 1ГБ. Однако, когда прожорливый процесс подбирается к потолку (это около 7,4...7,6ГБ), он и вся система начинает жутко тормозить. До того, что сложно (или невозможно в адекватное время) переключиться по Ctrl+Alt+F2 на консоль и грохнуть там процесс.
При этом swap и вся система на SSD, и swap на отдельном разделе. И oomkiller не срабатывает почему-то.
Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).
Для конкретики,
[avx@localhost ~]$ uname -a
Linux localhost.localdomain 5.5.6-desktop-2.mga7 #1 SMP Tue Feb 25 11:54:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Процесс — игра Deus Ex: Mankind Devided, запущенная из steam.
В процессе игры иногда встречаются моменты, когда логично и понятно, что будет занято много памяти, и на компе индикатор активности диска сразу начинает активность, а игра подвисает, и иногда может даже «прожевать» этот пик нагрузки на оперативку, используя swap, но чаще приходится делать hard reset кнопкой.
P.S. Да, я понимаю, что лучше просто добавить память. Но не всегда можно быть богатым и здоровым :-)
Мне кажется, хотя я могу ошибаться, но ваш сценарий, независимо от того, что у вас вроде как 1 большой процесс, не исключает указанной мной причины, просто если в вашем случае реализовать только гарантированное выделение, возможно "провисания" не будет, но при этом ваша игра выпадет по "out if memory", насколько я понимаю, в текущих системах, система до последнего пытается высвободить место под ваш процесс, а когда почти все системные процессы (в том числе код библиотек) уже вытеснены, происходит ошибка идёт в процесс, который пытается её обработать, но для этого ему нужно поднять то что до этого было вытеснено из памяти, но на этот процесс уже не хватает ресурсов и тут просыпается oom killer, я не настаиваю, но возможно именно не совсем некорректная обработка прерывания процессом игры и вызывает такое поведение. Особенность в том, что современное ПО уже "привыкло" к тому что можно выделять памяти больше чем есть реально, и при этом использовать сколько нужно (когда я первый раз увидел много лет назад объём виртуальной(не уверен в точности термина) памяти больше чем вся RAM я удивился, а теперь никто и не обращает внимания.
p.s. совсем не специалист в части работы ядра и его систем, всё что написано выше, только исходя из моего понимания логики работы подобных систем.
Особенность в том, что современное ПО уже "привыкло" к тому что можно выделять памяти больше чем есть реально, и при этом использовать сколько нужно (когда я первый раз увидел много лет назад объём виртуальной(не уверен в точности термина) памяти больше чем вся RAM я удивился, а теперь никто и не обращает внимания.
Именно так. Это тот же самый бич, когда программа требует привилегий больше, чем ей нужно для работы — но все уже привыкли и теперь ломать стереотипы сложно. Проще запихивать этот помойкософт в контейнеры (докер) и виртуалки (qubeos) и надеяться, что все будет хорошо. Ну, и своевременно подкидывать новых аппаратных ресурсов
Да мне как-то и не хочется чтобы этот процесс убивался, было бы гораздо логичнее, если бы процессу на запрос новой памяти система вернула бы «эй, у нас больше нет!», а процесс обработал бы это событие, и уже как-то сам выкручивался (выдать сообщение пользователю, использовать какие-то другие методы вычислений, и т.д.).
в линуксе достаточно отключить оверкоммит памяти, но только при этом начинаются спецэффекты. Чертов софт, который написан кое-как
Подробнее можно? Где и как отключить, и чем именно это грозит? Для обычных приложений залезть в своп — ну, замедлится, ну подождёт пользователь подольше… А для игры — это подобно просто выключению игры. Ибо настолько всё замирает, что уже об игре и не вспоминаешь, а только как бы её просто закрыть (да, потерянный прогресс иногда жалко). Так что если игра просто вылетит с ругательствами на память — пусть бы и так, это лучше, чем просто висеть и насиловать мой SSD.
P.S. на работе выключил на одной слабой машинке (2004 г выпуска, Celeron 2.6GHz, 512MB памяти, winXP и KES10 + рабочий софт несколько штук) swap совсем, и… работать стало лучше! Раньше — запустит юзер сразу 5 программ, они сожрут оперативку (которой уже на старте ОС почти нет), и машина свопится, а диск тормозной, и всё сильно подвисает. После — запускают одну программу, вторую, третью — оп, а на четвёртой (или на третьей, как повезёт) ошибка — нехватка памяти! Они закрывают ненужные на данный момент программы, и работают дальше, без тормозов (ну, для этой машины если так можно сказать). И аптайм машинки по несколько месяцев случается.
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/
Это баг, из-за которого Linux на компьютерах с низким количеством памяти лучше вообще не использовать. В Windows, например, ситуация намного лучше.
bugzilla.kernel.org/show_bug.cgi?id=196729
bugzilla.kernel.org/show_bug.cgi?id=199763
www.reddit.com/r/linux/comments/94u116/gnulinux_on_12gb_ram_tablets_how_it_really_works
Причину этой проблемы пытались выяснить разные люди в разное время, но до конца она так до сих пор и не устранена.
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...
Тем не менее почему-то разработчики суперкомпьютеров как правило выбирают GNU/Linux. Может они тупые, или есть какие-то другие причины? Насколько мне понаслышке известно, у FreeBSD еще большая проблема с драйверами, чем у Linux (возможно, не прав, только вот на сайтах производителей видеокарт, например, драйверы для Linux можно встретить, причем для разных дистрибутивов, а FreeBSD как-то не встречал). Возможно, FreeBSD — неплохой вариант для сервера, который достаточно один раз настроить и забыть, но в статье это не раскрыто. Думаю, что ставить ее себе на ноутбук не особо хорошая идея.
Миллионы мух [не] ошибаются?
на сайтах производителей видеокарт, например, драйверы для Linux можно встретитьСпособ распространения драйверов у винды сильно отличается от всех других ОС. Предоставьте, пожалуйста, ссылки на страницы на сайтах производителей видеокарт, где есть драйвера кроме как для винды.
Драйвера для FreeBSD есть на сайте Nvidia. Раньше делали и для Solaris x86/x64, но уже вроде как прекратили для GeForce 1600-х (может, ещё появятся, но вряд ли).
Вакансий с требованиями именно xBSD в РФ не нашёл, они перечисляются среди пожеланий — т.е. требуется «Linux, ну и до кучи еще и BSD».
С поддержкой оборудования есть трудности — его список меньше, чем у Linux.
С поддержкой новейшего оборудования — ещё сложнее.
Драйвера FreeBSD обычно берёт у Linux.
ZFS хороша, но для начала желательно что попроще. А этого в готовых сборках FreeBSD обычно нет, в отличие от Linux.
У Linux есть больше преимущество — гораздо легче начать им пользоваться, чем xBSD. У Linux есть «преимущество лёгкого начала»: Linux можно поставить не особо разбираясь, и он начнёт работать. С FreeBSD всё труднее. А когда освоил Linux, заниматься xBSD уже не особо-то и нужно.
FreeBSD — хорошая система, и местами выглядит лучше чем Linuix. Но пока что работать с ней и изучать её — тяжело, распространена она меньше. Знание FreeBSD навряд ли значительно повысит зарплату (в РФ и Украине. Для Netflix м.б. будет преимуществом).
Т.ч. всё вот так — «не очень».
Звучит так будто вы BSD никогда не пользовались, она значительно проще в администрировании и настройке нежели линукс, так же первой установке. Этому способствует bsdinstaller, псевдографическая утилита настройки, ей же можно и обновлять систему и тд, псевдографика есть так же при установке из портов, и широкий выбор удобных утилит для отладки и мониторинга, а так общая консистентность в расположении конфигов, логов и прочего. Всегда все конфиги установленных программ будут в /usr/local/etc//, системные в /etc и тд. В то время как интернет полнится запросами подобно «где конфиг %app_name% в линукс %dist_name%, где в зависимости от дистра, ментейнера или просто автора аппки он может где угодно лежать.
Так же FreeBSD по-умолчанию идет с UFS — это как раз и есть „что попроще“. С поддержкой железа сейчас ситуация в принципе в паритете с линуксом, десктопное железо конечно пониже приоритет имеет. Но у меня Фря даже на малинке бегает бодро. В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Так же FreeBSD по-умолчанию идет с UFS — это как раз и есть „что попроще“. С поддержкой железа сейчас ситуация в принципе в паритете с линуксом, десктопное железо конечно пониже приоритет имеет. Но у меня Фря даже на малинке бегает бодро. В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Вы говорите так как будто зоопарк утилит и софта это плохо? Лично я считаю что чем больше возможностей сделать одну и туже задачу тем лучше. Или Вы склонны делать всё по шаблонам? и как китайские программисты которые выучили только один способ работы другому же практически не обучаемы? и тем более высших грех им думать о другом способе который может быть в разы быстрее, легче и удобнее?
Это порождает фрагментацию, сам альтернативный софт — это хорошо, плохо когда в рамках по сути одной ОС в базе используются разные подходы, разные утилиты, разный синтаксис команд и прочее. База должна быть стандартизирована. Не стоит так же забывать про принцип KISS. Собственно поэтому существуют всякие POSIX и UNIX сертификации. И что плохого в шаблонах? Они экономят время позволяя не задумываться над базовыми операциями. Не думаю что это то место где нужен творческий подход.
Если хотите что-то единое, используйте коммерческие ОС, типа Windows и Darwin/Mac OS, где народ без дополнительной копейки даже «пукать» не будет, не то что бы что-то иное либо новое реализовывать… И даже в рамках всей этой проприетарщины многие утилиты чистое гоумно и сторонними разработчиками за отдельную не маленькую такую копеечку разрабатываются утилиты которые предоставляют больший набор возможностей и при условии что Вы хотите а иногда и вынуждены их использовать нужно будет эту копеечку платить. А теперь по поводу KISS, это конечно хорошо, но что для одного «просто», для другого будет крайне сложно и это уже от человека зависит. Теперь по поводу того что же из себя представляет GNU/Linux — это такой крутой конструктор лего… из которого Вы можете сделать то что хотите используя те подходы которые Вам ближе а не какому-то дяде. Нет или не устраивает что-то в одном дистрибутиве, не проблема найдёте это в другом. Зачастую многие GNU/Linux даже специализируются на каких-то задачах, что нельзя сказать о других О.С.…
Теперь по поводу шаблонов, с одной стороны это удобно, но с другой они образуют шаблонное мышление и как следствие деградацию разума, даже в простых вещах если что-то пойдёт не по шаблону или не возможно это шаблоном выполнить люди становятся бессильны… Так что «в меру всё лекарство, но только если в меру.»
А теперь по поводу творческого подхода, он нужен везде, можно использовать стандартные базовые операции и тратить время к примеру на копирование вручную сотни каталогов, подкаталогов и файлов с разных устройств и мест, а можно подойти творчески засунуть всё в 1 список и выполнить за раз написанным скриптом ))))
так же можно развёртывать новые машины и настраивать их каждый раз ручками, а можно подойти творчески взять ансибл либо паппет и всё будет работать само…
Теперь по поводу шаблонов, с одной стороны это удобно, но с другой они образуют шаблонное мышление и как следствие деградацию разума, даже в простых вещах если что-то пойдёт не по шаблону или не возможно это шаблоном выполнить люди становятся бессильны… Так что «в меру всё лекарство, но только если в меру.»
А теперь по поводу творческого подхода, он нужен везде, можно использовать стандартные базовые операции и тратить время к примеру на копирование вручную сотни каталогов, подкаталогов и файлов с разных устройств и мест, а можно подойти творчески засунуть всё в 1 список и выполнить за раз написанным скриптом ))))
так же можно развёртывать новые машины и настраивать их каждый раз ручками, а можно подойти творчески взять ансибл либо паппет и всё будет работать само…
Я для десктопа и использую макось, и там как раз есть покрытие всего линукс софта и плюс коммерческого, все что есть на линь портируют на мак для удобства разработки, а утилиты тут BSD, макось же подтверждают юникс сертификацию и позикс и не надо ни за что платить ) только за коммерческий гуевый софт.
За линь же как раз эту фрагментацию дистрибутивов и критикуют. Это только на словах звучит так круто, большое обилие выбора и свободы, по факту это это сотни и тысячи дистрибутивов с минимальными отличиями в виде нескучных обоев с разной степенью стабильности как самой ОС так и своих реп и наличия софта в ней. А в этот конструктор совершенно не хочется лезть, хочется что б все просто работало, при этом выглядело не всрато, и требовало минимальных и понятных вмешательств для настройки, все остальное лежит в области хобби и энтузиазма. Либо если тебе очень хорошо платят за создание конкретной эмбед платформы, типо роутеров, прошивочки камер и прочего и время которое ты тратишь разбираясь в этом.
За линь же как раз эту фрагментацию дистрибутивов и критикуют. Это только на словах звучит так круто, большое обилие выбора и свободы, по факту это это сотни и тысячи дистрибутивов с минимальными отличиями в виде нескучных обоев с разной степенью стабильности как самой ОС так и своих реп и наличия софта в ней. А в этот конструктор совершенно не хочется лезть, хочется что б все просто работало, при этом выглядело не всрато, и требовало минимальных и понятных вмешательств для настройки, все остальное лежит в области хобби и энтузиазма. Либо если тебе очень хорошо платят за создание конкретной эмбед платформы, типо роутеров, прошивочки камер и прочего и время которое ты тратишь разбираясь в этом.
Насчёт фрагментации — полностью поддержу.
Просто задумайтесь сколько способов есть решить тривиальную задачу в линуксе, а именно настройку сети. Причем рассмотрите не только конкретный дистрибутив, а ситуацию в целом.
Повторюсь ещё раз, вы смотрите со стороны того кому все и всё обязаны. GNU/Linux состоит из открытого софта разработчики которого предлагают свои решения ничего не требуя в замен того времени и тех усилий которые пришлось потратить на разработку этого софта. Вы же не довольные этим фактом, пользуетесь и плюетесь сравнивая его с проприетарным коммерческим софтом…
Теперь по поводу многообразия всевозможных дистрибутивов с нескучными обоями, да такая беда есть, но никто и ничто не мешает вам не использовать их а использовать корневые родительские дистрибутивы.
А по поводу многообразия утилит которым Вы так не довольны, да их много но время отсеивает большую часть и остаются только те которые действительно удобны народу. Если Вы считаете иначе это Ваше мнение как индивида из всего того сообщества которое использует их и далеко не факт что все должны думать и думают как Вы…
Теперь по поводу многообразия всевозможных дистрибутивов с нескучными обоями, да такая беда есть, но никто и ничто не мешает вам не использовать их а использовать корневые родительские дистрибутивы.
А по поводу многообразия утилит которым Вы так не довольны, да их много но время отсеивает большую часть и остаются только те которые действительно удобны народу. Если Вы считаете иначе это Ваше мнение как индивида из всего того сообщества которое использует их и далеко не факт что все должны думать и думают как Вы…
Нет, счего бы? Просто есть code of conduct, который держит проект на определенном уровне качества, если ты как разработчик не готов ему следовать и доводить свои решения до определенных стандартов принятых в проекте, каким бы полезным не был твой вклад — это будет медвежья услуга, неуважение к комьюнити и такой продукт даже не будет принят. Тем более когда есть аналоги. А если кто-то создал действительно уникальный полезный инструмент, то люди приведут его под стандарты проекта либо же напишут свой велосипед (привет Поттеринг).
1. Вы снова пытаетесь сравнивать дистрибутив и отдельных разработчиков которые ведут свой проект. Это тоже самое что сравнить Blender и к примеру Inkscape и говорить какой плохой дистрибутив они отличаются стилистически… и набором функционала…
2. Code of conduct — к сведению, привязан к одному конкретному проекту, не путайте. Да и это больше относится к поведению, нежели разработке и составу кода и качеству кода.
2. Code of conduct — к сведению, привязан к одному конкретному проекту, не путайте. Да и это больше относится к поведению, нежели разработке и составу кода и качеству кода.
Разработчики ведут свой проект для какой-то целевой системы же, должны учитывать специфику и правила, а раз в Линуксе строгих правил нет это и порождает беспорядок.
Ну Фря и есть конкретный проект, это целостная ОС. Вообще в различных ОС приняты свои требования к ПО под нее. Как, например, в MacOS в любой программе комбинация CMD +, откроет окно настроек программы. Так же частенько вижу в консольных утилитах и софте определенные флаги с пометкой «добавленно для совместимости с POSIX».
За флаги, кстати, тоже раздражает, в одних программах --version выводит версию в по, в других внезапно только -v, в третьих это verbouse, а четвертые вообще выводят версию без "-" просто version. Это пример, такие претензии к -h help и прочим стандартным флагам, очевидно же было бы лучше будь они как-то стандартизированы.
Ну Фря и есть конкретный проект, это целостная ОС. Вообще в различных ОС приняты свои требования к ПО под нее. Как, например, в MacOS в любой программе комбинация CMD +, откроет окно настроек программы. Так же частенько вижу в консольных утилитах и софте определенные флаги с пометкой «добавленно для совместимости с POSIX».
За флаги, кстати, тоже раздражает, в одних программах --version выводит версию в по, в других внезапно только -v, в третьих это verbouse, а четвертые вообще выводят версию без "-" просто version. Это пример, такие претензии к -h help и прочим стандартным флагам, очевидно же было бы лучше будь они как-то стандартизированы.
CMD +,
Не с "Command ," перепутали? А, все, понял, неудачное форматирование было )
Разработчики ведут свой проект для какой-то целевой системы же
Вы сильно ошибаетесь. Ещё раз Вы путаете всё и вся. Не нужно писать об этом если Вы в этом ничего не понимаете. Как разработчик говорю.
А по поводу команд так нет ничего в этом плохого, многих же устраивают утилиты под мелкомягких хотя там тоже не наблюдается солидарности в этом даже повершел от мелкомягких отличается хотя там многое поменяли…
В общем я ещё раз убеждаюсь в вашей не компетенции в этих вопросах. разработкой нужно заниматься что бы понимать о чём речь. Консольные утилиты и набор команд для них а тем более обработчик их может сильно зависеть от выполняемых ими функционала.
Именно. «Если ты читаешь книгу по FreeBSD, ты читаешь книгу по FreeBSD. Если ты читаешь книгу по Linux, ты читаешь книгу по конкретному дистрибутиву Linux.» ©
> BSD никогда не пользовались, она значительно проще в администрировании и настройке нежели линукс, так же первой установке.
Вот сейчас решил проверить, при том, что до 2008 этих самых FreeBSD поставил несколько десятков штук и основные воспоминания сохранились. Ставлю по сети с bootonly образа.
Задал дохлое зеркало: минут 10 попыток достучаться и перешло в режим, что на клавиши не реагировало. Пришлось перезагружать.
Манера диалогов, что пробел меняет настройку, а Enter применяет весь диалог — нигде не описана на экране (что мешало дать подсказку?)
Куча вопросов типа «а включать ли ntpd?» Почему вообще спрашивают, что, точное время обычно локально не нужно?
В диалоге добавления юзера: «Invite vasya into other groups? []» — как догадаться с первого раза, что тут нужно не «yes», а список групп?
Пошёл в postinstall настройку интерфейсов — спрашивает, вам DHCP там нужен? На моё Yes говорил — не шмогла. Ещё бы, dhclient уже запущен, а она этого не помнит.
А почему не было пункта добавить софта (может, я хочу KDE сразу поставить?)
Что-то многовато получилось жалоб даже от опытного пользователя и админа. А новичку как?
> Всегда все конфиги установленных программ будут в /usr/local/etc//, системные в /etc и тд. В то время как интернет полнится запросами подобно «где конфиг %app_name% в линукс %dist_name%, где в зависимости от дистра, ментейнера или просто автора аппки он может где угодно лежать.
Во-первых, это очень дурная манера использовать /usr/local для пакетного хозяйства. Не зря в NetBSD поместили это в /usr/pkg.
Во-вторых, проблемы линукса от стиля управления или от принципов типа «называть по сервису или по продукту» (отсюда различие типа /etc/httpd vs. /etc/apache2), а во FreeBSD получается, например, пока BIND был в базе — есть /etc/named, а потом вдруг /usr/local/etc/named, причём там только первый конфиг, продолжение из-за jail где-то глубоко в /var/named…
> В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Зато если остановиться на одном конкретном — то возможностей больше и реализуются они обычно с меньшей пляской с бубном.
Исключения — всё те же netgraph и GEOM — сейчас это два основных кита, на которых FreeBSD ещё хоть как-то держится на плаву. Ну ещё ZFS немного помогает. Linux сильно шире в количестве ниш и между ними всеми перетекают новые разработки.
Вот сейчас решил проверить, при том, что до 2008 этих самых FreeBSD поставил несколько десятков штук и основные воспоминания сохранились. Ставлю по сети с bootonly образа.
Задал дохлое зеркало: минут 10 попыток достучаться и перешло в режим, что на клавиши не реагировало. Пришлось перезагружать.
Манера диалогов, что пробел меняет настройку, а Enter применяет весь диалог — нигде не описана на экране (что мешало дать подсказку?)
Куча вопросов типа «а включать ли ntpd?» Почему вообще спрашивают, что, точное время обычно локально не нужно?
В диалоге добавления юзера: «Invite vasya into other groups? []» — как догадаться с первого раза, что тут нужно не «yes», а список групп?
Пошёл в postinstall настройку интерфейсов — спрашивает, вам DHCP там нужен? На моё Yes говорил — не шмогла. Ещё бы, dhclient уже запущен, а она этого не помнит.
А почему не было пункта добавить софта (может, я хочу KDE сразу поставить?)
Что-то многовато получилось жалоб даже от опытного пользователя и админа. А новичку как?
> Всегда все конфиги установленных программ будут в /usr/local/etc//, системные в /etc и тд. В то время как интернет полнится запросами подобно «где конфиг %app_name% в линукс %dist_name%, где в зависимости от дистра, ментейнера или просто автора аппки он может где угодно лежать.
Во-первых, это очень дурная манера использовать /usr/local для пакетного хозяйства. Не зря в NetBSD поместили это в /usr/pkg.
Во-вторых, проблемы линукса от стиля управления или от принципов типа «называть по сервису или по продукту» (отсюда различие типа /etc/httpd vs. /etc/apache2), а во FreeBSD получается, например, пока BIND был в базе — есть /etc/named, а потом вдруг /usr/local/etc/named, причём там только первый конфиг, продолжение из-за jail где-то глубоко в /var/named…
> В целом обьем знаний для работы с Линукс требуется больше, этому способствует большой зоопарк утилит, особенностей каждого дистра и пакетных менеджеров.
Зато если остановиться на одном конкретном — то возможностей больше и реализуются они обычно с меньшей пляской с бубном.
Исключения — всё те же netgraph и GEOM — сейчас это два основных кита, на которых FreeBSD ещё хоть как-то держится на плаву. Ну ещё ZFS немного помогает. Linux сильно шире в количестве ниш и между ними всеми перетекают новые разработки.
Честно говоря больше на придирки похоже. Дохлое зеркало не вина FreeBSD, по-умолчанию там толи эникастом толи роутером выдается оптимальное корневое зеркало и есть так же зеркала 2го эшелона работоспособность которых никто не гарантирует, но они могут висеть на сайте.
NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
отсюда и выбор. В какой-то момент FreeBSD решили так же захватить и десктопную аудиторию, возможно тогда опция и появилась, а может и была там исторически, не знаю.
Почему манера использовать /usr/local дурная? Вообще именование каталогов, точек монтирования в unix исторически довольно малосвязная и забавная тема, просто FreeBSD использует одну из ранних вариаций, не думаю что она чем-то хуже или лучше любой другой, мне лично скорее нравится отсутствие лишних сущностей в виде /opt /pkg и тд и этот подход, опять же лично мне, кажется вполне логичным.
В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить, я обычно сразу пишу wheel для админский учетки, мне честно говоря сложно судить насколько это интуитивно, мне как программисту эти скобки сразу список напоминают, может вы и правы.
> Зато если остановиться на одном конкретном…
А вот проблема в том что приходится использовать то что там уже есть, а предидущий интегратор мог развернуть тот дистр что он больше знает или по каким-то своим убеждением, холивары там между дистрами идут еще горячее, хоть казалось бы. Это и имелось мной в виду.
NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
25.10.3.1 Если вам нужно только синхронизировать ваши часы при загрузке машины, вы можете воспользоваться утилитой ntpdate(8). Это может подойти для некоторых настольных машин, которые часто перезагружаются и только требуют изредка синхронизироваться, но на большинстве машин должен работать ntpd(8).
отсюда и выбор. В какой-то момент FreeBSD решили так же захватить и десктопную аудиторию, возможно тогда опция и появилась, а может и была там исторически, не знаю.
Почему манера использовать /usr/local дурная? Вообще именование каталогов, точек монтирования в unix исторически довольно малосвязная и забавная тема, просто FreeBSD использует одну из ранних вариаций, не думаю что она чем-то хуже или лучше любой другой, мне лично скорее нравится отсутствие лишних сущностей в виде /opt /pkg и тд и этот подход, опять же лично мне, кажется вполне логичным.
В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить, я обычно сразу пишу wheel для админский учетки, мне честно говоря сложно судить насколько это интуитивно, мне как программисту эти скобки сразу список напоминают, может вы и правы.
> Зато если остановиться на одном конкретном…
А вот проблема в том что приходится использовать то что там уже есть, а предидущий интегратор мог развернуть тот дистр что он больше знает или по каким-то своим убеждением, холивары там между дистрами идут еще горячее, хоть казалось бы. Это и имелось мной в виду.
> Честно говоря больше на придирки похоже. Дохлое зеркало не вина FreeBSD,
А вот то, что на опознание проблемы потребовалось ему 10 минут, за это время нельзя было нажать отмену, и после этого на клавиши перестало реагировать — вот это полностью вина FreeBSD, точнее, авторов кривого инсталлятора. Странно вы читаете, если это проигнорировали.
> там толи эникастом толи роутером выдается оптимальное корневое зеркало
Но оно же может быть недоступным по сетевым причинам.
> NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
Даже для выключаемого десктопа мягкая корректировка темпа хода полезнее, чем прыжки. В плане управления временем тут у FreeBSD отсталость лет на 15.
> Почему манера использовать /usr/local дурная?
Потому что /usr/local — типовое умолчание для autotools и аналогов для ручной сборки. Поставленное таким образом плохо отделяется от установленного из портов и может с ним подраться.
> В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить,
Для установщика для простого юзера это должно быть написано сразу там же.
Этот инсталлятор, на самом деле, всегда затачивается под то, что он будет идти с инструкцией (в Handbook, в браузере чего-то соседнего или вообще в бумажном виде). Но типовой современный юзер никогда эту handbook не читает (и игнорирует её существование, если не наступил уже на эти грабли). Инсталляторы типа RHEL ещё предполагают, что установщик что-то читает кроме того, что пишет сам инсталлятор, но Ubuntu — уже нет.
> А вот проблема в том что приходится использовать то что там уже есть,
Да, это факт. Ты набил руку на Debian, приходишь — а там SLES. «Дык опаньки, братуха» (tm)
А вот то, что на опознание проблемы потребовалось ему 10 минут, за это время нельзя было нажать отмену, и после этого на клавиши перестало реагировать — вот это полностью вина FreeBSD, точнее, авторов кривого инсталлятора. Странно вы читаете, если это проигнорировали.
> там толи эникастом толи роутером выдается оптимальное корневое зеркало
Но оно же может быть недоступным по сетевым причинам.
> NTPd нужен далеко не всегда естественно, это в хендбуке описано кстати:
Даже для выключаемого десктопа мягкая корректировка темпа хода полезнее, чем прыжки. В плане управления временем тут у FreeBSD отсталость лет на 15.
> Почему манера использовать /usr/local дурная?
Потому что /usr/local — типовое умолчание для autotools и аналогов для ручной сборки. Поставленное таким образом плохо отделяется от установленного из портов и может с ним подраться.
> В диалоге добавления юзера квадратные скобки намекают на то что там пусто и предлагается что-то добавить,
Для установщика для простого юзера это должно быть написано сразу там же.
Этот инсталлятор, на самом деле, всегда затачивается под то, что он будет идти с инструкцией (в Handbook, в браузере чего-то соседнего или вообще в бумажном виде). Но типовой современный юзер никогда эту handbook не читает (и игнорирует её существование, если не наступил уже на эти грабли). Инсталляторы типа RHEL ещё предполагают, что установщик что-то читает кроме того, что пишет сам инсталлятор, но Ubuntu — уже нет.
> А вот проблема в том что приходится использовать то что там уже есть,
Да, это факт. Ты набил руку на Debian, приходишь — а там SLES. «Дык опаньки, братуха» (tm)
В убунтовском инсталляторе проблемы похлеще есть. Например, у меня последний инсталлятор серверной убунты тупо завис, когда сетевуха была не подключена к сети. Лол што. Реальные проблемы с разбивкой диска — то ту разметку, которую тебе надо, через инсталлятор не применить, то что-то ещё. Вообще все эти претензии к инсталлятора фрибсд смешны… Поверьте — у остальных линуксов они (инсталлятора) не лучше.
> В убунтовском инсталляторе проблемы похлеще есть.
Ну я, конечно, последние K лет записной кедорас, но проблемы инсталлятора собственно Ubuntu мне неинтересны, а в Kubuntu я таких эффектов не видел.
И тупых зависов не было, и разметка получалась.
Ставил также центось — стиль совсем другой, но тоже прилично. Может, если бы захотел суперстранного, то получил бы по рукам, но фрёвый в принципе такого не умеет.
Всё-таки само по себе участие большего количества пользователей обеспечивает, в среднем по больнице, лучшее качество просто за счёт обратной связи.
> Поверьте — у остальных линуксов они (инсталлятора) не лучше.
Вот я таки испытал обе стороны и делаю другой вывод — что как для рядового пользователя линуксовые таки лучше.
Когда я фряхи ставил потоком, там уже все чудеса были отработаны, рука набита… но там и результаты часто требовались нестандартные. И таки это были pets, а не cattle.
Ну я, конечно, последние K лет записной кедорас, но проблемы инсталлятора собственно Ubuntu мне неинтересны, а в Kubuntu я таких эффектов не видел.
И тупых зависов не было, и разметка получалась.
Ставил также центось — стиль совсем другой, но тоже прилично. Может, если бы захотел суперстранного, то получил бы по рукам, но фрёвый в принципе такого не умеет.
Всё-таки само по себе участие большего количества пользователей обеспечивает, в среднем по больнице, лучшее качество просто за счёт обратной связи.
> Поверьте — у остальных линуксов они (инсталлятора) не лучше.
Вот я таки испытал обе стороны и делаю другой вывод — что как для рядового пользователя линуксовые таки лучше.
Когда я фряхи ставил потоком, там уже все чудеса были отработаны, рука набита… но там и результаты часто требовались нестандартные. И таки это были pets, а не cattle.
А как ты Фряху на малинку накатил?
Сам образ наваял?
Или есть готовые на сайте малинки?
Сам образ наваял?
Или есть готовые на сайте малинки?
Есть готовые образы, img просто dd на флешку. Тут, например, небольшой список: wiki.freebsd.org/action/show/arm/Raspberry%20Pi?action=show&redirect=FreeBSD%2Farm%2FRaspberry+Pi#Pre-Built_Images
Либо просто с фтп Фри: download.freebsd.org/ftp/releases/arm
Либо просто с фтп Фри: download.freebsd.org/ftp/releases/arm
Драйвера FreeBSD обычно берёт у Linux.
Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.
У Linux есть больше преимущество — гораздо легче начать им пользоваться, чем xBSD.
Вообще неправда. Наоборот. Если, конечно, вы не имеете в виду «скачать образ, не читая ничего».
Так-то поддерживается меньшее количество железа, да.
А вот «выглядит лучше, чем Linux» субъективно везде.
Ну графические, под нвидиа например, нативные под фрю и даже в пакетах лежат. И они кстати содержат два набора файликов: нативно под ядро фри и линуксовые под эмулятор линя. Недавно поднимал нас и медиацентр под Фрей, на Коди. Вобщем-то довольно безпроблемно завелось все с карточной нвидиа.
Что, простите? Им лицензия какбэ не позволяет. Так что не берут. Кроме графических, которые под MIT лицензией.Пойдите и почитайте что и как и берётся у Linux
Дадите ссылку с пруфами? (риторический вопрос, не дадите)
Неужели вы не умеете пользоваться гуглом? и Мне нужно тыкать пальцем как маленькому ребёнку? и даже забить запрос в гугл и щёлкнуть по первой же ссылке сложно? wiki.freebsd.org/Graphics… Ах да, Многим же сейчас это делать сложно… так как лапки…
Nvidia прямо с сайта предлагает дрова для: GeForce, RTX, Titan
Дык у него как были так и остались проблемы с драйверами, при мне извечный фряхолюб на 11 фряхе решил доказать что она быстра и работает везде… решил поставить себе на корпоративный ПК фряху 11, да не получилось оказалось нет драйвера под чипсет и следовательно не виделись винты… А так многие драйвера фряхи по прежнему тянут с GNU/Linux. Как я ниже писал и это ещё одно доказательство технологической отсталости GNU/Linux…
А так многие драйвера фряхи по прежнему тянут с GNU/Linux.
Что? Этого нет и никогда не было, потому что лицензии.
Никогда не сталкивался с тем, чтобы фряха не узрела такую базовую переферию, как винты. Я там понимаю ещё, когда она не видит какие-нибудь там принтеры или (как это бывало нередко лет 20 назад) не может нормально включить графику в иксах — эти штуки серверной операционке и даром не нужны. Но не видеть винты… — это очень странно.
Это как раз один из самых частых кейсов. Интел делает новый чипсет, сата контроллер в нем. В итоге не то что не увидеть — инсталер может просто зависнуть. Так же помню когда на сата только переходили, на фре отваливались сата винты, причем это довольно продолжительное время происходило. Потом вроде стабилизировали, но осадочек остался.
Я еще напомню, что новые контроллеры без встроенных драйверов не видятся не только во фре, пресловутые винды этим страдали не в меньшей степени. Вспомните ХР + SATA в enhanced mode, если нет дискетки с драйвером (или не вживить драйвер в дистрибутив руками).
В винде это было в 2000х годы, а во фряхе с этим я столкнулся 2 года назад.
На семерке я с этим сталкивался лет пять назад: деталей не помню, да и не в них суть: я все это писал к тому, что «винты» — это вовсе не настолько «базовая периферия».
А что полшага в сторону от совсем массовых систем, и проблема с драйверами встает в полный рост, так по-моему, этим вряд ли кого здесь можно удивить. Имхо, конечно.
А что полшага в сторону от совсем массовых систем, и проблема с драйверами встает в полный рост, так по-моему, этим вряд ли кого здесь можно удивить. Имхо, конечно.
Тут не проблема в винте а проблема в контроллере а он и есть базовая периферия, не путайте, ставили разные винты.
Да, приношу извинения.
Винт подключается к контроллеру жестких дисков, и драйвера нужны именно для этого контроллера (при этом еще один контроллер расположен непосредственно на винте).
Свойство базовости периферии не кодифицировано, о его значении и объеме можно спорить, но необходимости драйверов ни один спор не отменит.
Винт подключается к контроллеру жестких дисков, и драйвера нужны именно для этого контроллера (при этом еще один контроллер расположен непосредственно на винте).
Свойство базовости периферии не кодифицировано, о его значении и объеме можно спорить, но необходимости драйверов ни один спор не отменит.
Это говорит лишь о том что линукс это попсовая система для позеров
Тут товарищ просто забыл написать, что во FreeBSD все довольно плохо, с масштабированием на большие машины с большим количеством процессоров и памяти. Как сейчас там не знаю, но вот несколько лет назад FreeBSD показывала производительность хуже на машинах с больше чем 16 процессорными ядрами. Тест был насколько помню на использование PostgreSQL и MySQL. Причем мотивация людей со стороны FreeBSD была такова, что товарищи не делают специфичные для FreeBSD оптимизации.
> Причем мотивация людей со стороны FreeBSD была такова, что товарищи не делают специфичные для FreeBSD оптимизации.
А что удивительного? Если делается явная оптимизация под Linux, но не FreeBSD, и получатся результаты с явным перекосом.
Так уже было с таймером. В Linux было очень дешёвое, хоть и неточное, gettimeofday() (это ещё до варианта с user space, забыл его название), и MySQL очень активно его использовал (вызывая во много раз чаще, чем надо — в strace можно было видеть просто сотни вызовов подряд в одной нитке). Аналог FreeBSD был дорогой, потому что лез к аппаратному таймеру. В результате производительность страдала заметно, а на бенчмарках — просто чудовищно.
Пришлось сделать специальный удешевлённый вызов (clock_gettime с CLOCK_REALTIME_FAST) и подставлять его в свою сборку через патч порта. Цифры выправились, и об этом гордо отрапортовали, с объяснением причин.
Аналогично было в некоторых других проектах с kqueue — epoll сделан, а остальным — раз не умеете, довольствуйтесь медленным poll или вообще select. И пришлось самим патчить в порте.
Соотношение сил и намерений разработки под Linux vs. FreeBSD напоминает сейчас такое же для Windows vs. Linux ещё совсем недавно: есть типа одна большая целевая ОС, всё делаем под неё, там реальные потребители. Уже второй по счёту получает объедки, третий не получает ничего. И эта история точно так же продолжается дальше — на OpenBSD ещё на порядок меньше сил, чем на FreeBSD (хотя тут помогает, что все проекты BSD группы очень активно друг у друга тянут код).
А что удивительного? Если делается явная оптимизация под Linux, но не FreeBSD, и получатся результаты с явным перекосом.
Так уже было с таймером. В Linux было очень дешёвое, хоть и неточное, gettimeofday() (это ещё до варианта с user space, забыл его название), и MySQL очень активно его использовал (вызывая во много раз чаще, чем надо — в strace можно было видеть просто сотни вызовов подряд в одной нитке). Аналог FreeBSD был дорогой, потому что лез к аппаратному таймеру. В результате производительность страдала заметно, а на бенчмарках — просто чудовищно.
Пришлось сделать специальный удешевлённый вызов (clock_gettime с CLOCK_REALTIME_FAST) и подставлять его в свою сборку через патч порта. Цифры выправились, и об этом гордо отрапортовали, с объяснением причин.
Аналогично было в некоторых других проектах с kqueue — epoll сделан, а остальным — раз не умеете, довольствуйтесь медленным poll или вообще select. И пришлось самим патчить в порте.
Соотношение сил и намерений разработки под Linux vs. FreeBSD напоминает сейчас такое же для Windows vs. Linux ещё совсем недавно: есть типа одна большая целевая ОС, всё делаем под неё, там реальные потребители. Уже второй по счёту получает объедки, третий не получает ничего. И эта история точно так же продолжается дальше — на OpenBSD ещё на порядок меньше сил, чем на FreeBSD (хотя тут помогает, что все проекты BSD группы очень активно друг у друга тянут код).
Ну дак, а еще усилия по нормальной работе ОС на больших машинах так же пилятся в Linux в первую очередь как в целевой платформе. Больше ресурсов больше выхлоп.
«Но и это ещё не всё».
1. FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc. Сейчас почти сравнялись, но «в среднем» всё же FreeBSD+clang немного медленнее, чем FreeBSD+gcc (зависит от задачи).
2. После трёх лет (!!!) обсуждения всё-таки включили поддержку OpenMP во FreeBSD:
начало
конец
Не включали потому что «нам в базе не надо, а на остальных пох», при этом ныли «а чё на Форониксе такие циферки маленькие?...». А надо не ныть, не жить прошлым, а внедрять новые фичи, которых просят люди.
На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX. (когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ). Опять же щас Linux и FreeBSD сравнялись.
1. FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc. Сейчас почти сравнялись, но «в среднем» всё же FreeBSD+clang немного медленнее, чем FreeBSD+gcc (зависит от задачи).
2. После трёх лет (!!!) обсуждения всё-таки включили поддержку OpenMP во FreeBSD:
начало
конец
Не включали потому что «нам в базе не надо, а на остальных пох», при этом ныли «а чё на Форониксе такие циферки маленькие?...». А надо не ныть, не жить прошлым, а внедрять новые фичи, которых просят люди.
На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX. (когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ). Опять же щас Linux и FreeBSD сравнялись.
> когда я на хабре говорил, что Linux ≠ UNIX мне заминусовали карму + ответ
Ну ответ я бы тоже поминусовал (в карму не полезу из принципа даже когда/если будут права) — различия между разными вроде бы Unix (Bell, BSD, SysV, OSF...) настолько велики, что надо или называть Unix только то, что происходит без потерь от SVR4 и OSF/1, или надо расширять понятие, и тогда, если мы включаем туда BSD системы, то включать и Linux. То, что Linux был испечён с нуля, имело значение первые лет 5 его существования, но сейчас уже всё это давно потерялось.
> На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX.
Никакого «унаследованного опыта Unix» у FreeBSD нет. Реальная многонитевость во FreeBSD появилась только в 5.x, и то она была очень кривой — авторы не смогли реализовать наполеоновские планы на M:N модель через scheduler activations. Уже в 6.x вариант 1:1 стал основным, в 7.x — единственным. Код поддержки этого всего свой (ну, в пределах копирований внутри BSD сообщества). Linux на тот момент имел уже NPTL. Накладные расходы на смену контекста и на сисколл у FreeBSD всегда были и сейчас есть чуть выше. Многопроцессорность ядра тоже очень долго выравнивали (чисто скользящую сериализацию 5.x во многом убили и сейчас она заметно ближе к линуксовой). Если в каком-то случае получается тут выигрыш, то за счёт других факторов.
> FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc.
Тут как раз разница очень неровная. Иногда clang выигрывает. Более того, на том же phoronix есть примеры, где gcc7 резко ухудшил часть тестов.
Но для основного кода FreeBSD это всё несущественно. Часть портов явно имеет инструкцию использовать GCC — там, где есть проблемы с Clang, не только с производительностью.
Про OpenMP в ней я совсем не знаю, надо будет как-нибудь почитать.
Ну ответ я бы тоже поминусовал (в карму не полезу из принципа даже когда/если будут права) — различия между разными вроде бы Unix (Bell, BSD, SysV, OSF...) настолько велики, что надо или называть Unix только то, что происходит без потерь от SVR4 и OSF/1, или надо расширять понятие, и тогда, если мы включаем туда BSD системы, то включать и Linux. То, что Linux был испечён с нуля, имело значение первые лет 5 его существования, но сейчас уже всё это давно потерялось.
> На многопоточных нагрузках FreeBSD может быть лучше, чем Linux (и тем паче — Windows) в силу унаследования опыта UNIX.
Никакого «унаследованного опыта Unix» у FreeBSD нет. Реальная многонитевость во FreeBSD появилась только в 5.x, и то она была очень кривой — авторы не смогли реализовать наполеоновские планы на M:N модель через scheduler activations. Уже в 6.x вариант 1:1 стал основным, в 7.x — единственным. Код поддержки этого всего свой (ну, в пределах копирований внутри BSD сообщества). Linux на тот момент имел уже NPTL. Накладные расходы на смену контекста и на сисколл у FreeBSD всегда были и сейчас есть чуть выше. Многопроцессорность ядра тоже очень долго выравнивали (чисто скользящую сериализацию 5.x во многом убили и сейчас она заметно ближе к линуксовой). Если в каком-то случае получается тут выигрыш, то за счёт других факторов.
> FreeBSD предпочитает LLVM Clang, с которым производительность была существенно меньше, чем с gcc.
Тут как раз разница очень неровная. Иногда clang выигрывает. Более того, на том же phoronix есть примеры, где gcc7 резко ухудшил часть тестов.
Но для основного кода FreeBSD это всё несущественно. Часть портов явно имеет инструкцию использовать GCC — там, где есть проблемы с Clang, не только с производительностью.
Про OpenMP в ней я совсем не знаю, надо будет как-нибудь почитать.
Я бы не был так уж уверен, современные суперкомпьютеры живут под управлением GNU/Linux так как другие не особо то справлялись с таким огромным количеством ядер. Где-то одно время даже читал тесты которые показали что лучше GNU/Linux не найти было, обосновывалась на примере расчётов многопоточных для сборки с 512 ядрами. Вполне возможно что уже что-то поменялось с тех пор, однако я не вижу движухи в сторону фряхи с той стороны…
Вообще суть сравнения ХЗ/BSD (потому что понатаскали от всего и вся) vs GNU/Linux, знаю что у обе системы можно спокойно уместить в мизер ОЗУ для линухи последних версий это порядка 4х МБ и 16мб на ПЗУ. Да уже и не в том возрасте что бы мериться у кого длинней и толще… работать надо, да и дома десктом уже давно без дуалбутов и всё работает на Debian Sarge GNU/Linux… в своё время перепробовал всё, убунты, федоракоры, мандрейки, редхаты и т.п. остался на дебе так как оптимальное соотношение цены / качества.
Вообще суть сравнения ХЗ/BSD (потому что понатаскали от всего и вся) vs GNU/Linux, знаю что у обе системы можно спокойно уместить в мизер ОЗУ для линухи последних версий это порядка 4х МБ и 16мб на ПЗУ. Да уже и не в том возрасте что бы мериться у кого длинней и толще… работать надо, да и дома десктом уже давно без дуалбутов и всё работает на Debian Sarge GNU/Linux… в своё время перепробовал всё, убунты, федоракоры, мандрейки, редхаты и т.п. остался на дебе так как оптимальное соотношение цены / качества.
Ох, lets lorcombat begin!
Для меня Эдуард Шишкин является примером специалистом, который продолжает развивать свою тему наперекор всем, включая Линуса Allmightly.
Фря в качестве датаьейз сервера просто унылое говно — скорости нет. Это единственное место где у меня не фря, все остальное инфраструктурное только на фре, если я выбираю.
А так вообще пофигу что настраивать
Так. А Солярис?
Пилили её дико крутые люди, дико крутые технологии зародились именно на ней, вообще прогресс она двигала ещё как (ну, не она, а Sun Microsystems в целом), но… она не является свободным ПО, так что тут уж лучше даже GNU/Linux :-(
RIP. Развитие закрыто, все новые системы на Oracle Linux. Выпускаются только обновления и security fix.
Лучше срачей *Nix vs Windows, только срачики Linux vs FreeBSD
помню в 90-х некоторые очень жаловались на виддовс и хвалили «правильную» os/2. где теперь та os/2?
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))
примерно то же самое с freebsd, сколько на ней сетапов в top500, например?
конечно же все эти люди из top500 на linux те еще мухи, кушающие то, что на земле лежит :))
Я и сейчас готов хвалить OS/2.
Для того времени это был очень серьёзный шаг вперёд, намного более стабильный и удобный.
Но сейчас "оспополам" это просто часть истории.
Где-то в 2000х я активно использовал FreeBSD и для работы с сетью она объективно была сильно круче Linux'а (всё портил разве что NAT в userspace'е, но и это в итоге починили). Я и сейчас готов утверждать, что тогда для многих серверных задач она была лучше. А уж jail был (на фоне имевшегося chroot в линуксе) просто великолепен.
Но сейчас лично для меня FreeBSD — часть истории.
Приятно осознавать, что в отличии от OS/2 она всё ещё жива, но не более того.
Да и OS/2 вполне себе жива, в виде ArcaOS…
Полуось часто вижу на IBM-овских кассовых терминалах в супермаркетах, те что моноблоки с экранами и тд.
Пока IBM исходники не откроет, скорее мертва. А она их не откроет, ибо там не только их интеллектуальная собственность.
На самом деле вот ядро уже не так важно. Я больше скажу. IBM-овское ядро это боль и ужасы(судя по реакции тех ребят что делают ядро OS/4). А вот сорцы всяких системных компонентов, особенно SOM/DSOM/WorkPlace Shell это очень сильно-бы помогло в ускорении пиления опенсурсной полуоси… Ну и людей не хватает конечно.
В конце нулевых — начале 10-х фряха была очень популярна как серверная ось. Как-раз, по причинам, описанным автором статьи. В последнее время, как я вижу, для серверов выбирают centOS, Debian и Ubuntu. Почему фряха обосралась — сложно сказать. Насколько помню, в десятых годах активно находили уязвимости в ntp, openssl и проч. И фряха оказывалась крайне небезопасной при том, что обновление проблемных утилит в ней вызывало проблемы. Плюс, получили распространение лёгкие дистрибутивы типа CentOS. Их развёртывание и обслуживание было легче, чем развёртывание и обслуживание фряхи. А без популярности на серверах фряха, по сути, нафиг не нужна и её смерть — вопрос времени.
В определенный момент в linux все стало сильно лучше с драйверами и производительностью. Плюс с коммерческой поддержкой как итог интерпрайз голосовал рублем и переходил с коммерческих *nix на linux с коммерческой поддержкой.
Был админом в "нулевых" - модемные пулы, вот это все - "плавали, знаем". FreeBSD тогда была By default. У всех. 4.3 как сейчас помню. На 5-ку не переходили принципиально - FreeBSD 5 была чем-то вроде Windows Vista от мира винды
Не знаком с BSD, но мне кажется или у вас аргумент про 3 фаервола противоречит аргументу про отсутствие "зоопарка" утилит для одних и тех-же задач?
Еще и DPDK на BSD не работает
Легкий наброс, bsd конечно ок, но сообщество в разы кислотнее, нежeли linux
ps: десктоп клиента для телеги даже на gtk так и не изобрели, запускают linux клиент в эмуляторе… это все, что нужно знать о будущем
bpftraсe автору не знаком, ну ок.
По наблюдениям — BSD заводится там, где сошлись звезды и несколько BSD-шников. Так оно в NetFlix, примерно так — в Juniper (там вообще дикая смесь под капотом).
По наблюдениям — BSD заводится там, где сошлись звезды и несколько BSD-шников. Так оно в NetFlix, примерно так — в Juniper (там вообще дикая смесь под капотом).
Холивар знатный конечно же. Весело. :) Давайте вспомним ещё, что PlayStation тоже на FreeBSD работает. Адепты фряхи ещё вспоминают давнишнюю историю с MacOS.
Если серьёзно, то шлюзы безопасности на всех предприятиях, где я работал или фрилансил, я всегда поднимал и настраивал на FreeBSD. PF — отличный пакетный фильтр.
Если серьёзно, то шлюзы безопасности на всех предприятиях, где я работал или фрилансил, я всегда поднимал и настраивал на FreeBSD. PF — отличный пакетный фильтр.
Адепты фряхи ещё вспоминают давнишнюю историю с MacOS.
Apple как сосал, так и сосёт код из FreeBSD в свои OS. И в ядро тоже. Только особенно по теме не распостраняется. Информация об этом выдаётся только вскользь, как это было, к примеру, при обнаружении Meltdown / Spectre.
А еще они роутеры делали на NetBSD когда-то давно :-)
github.com/apple/darwin-xnu явно написано что там есть компоненты FreeBSD, но архитектура все же сильно отличается
А ещё есть чудесные pfSense/OPNSense.
Это всё просто замечательно, но как там во фре с играми? :D
Плэйсэйшон же
Очень плохо. Даже в NetBSD есть games.tar.xz, а во Free ничего нет :D
Wine есть(обычный, из портов можно собрать с -staging и dxvk, например), старые линуксовые работают, свободные нативно.
Не знаю насчет FreeBSD, но в OpenBSD c играми не так уж и плохо.
www.reddit.com/r/openbsd_gaming
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 — эксперты в написании программ редко являются экспертами в их упаковке. Ровно обратное тоже верно — в результате — мы для каждого дистрибутива линукса видим какие-то просто дичайшие патчи в каждом пакете
НЛО прилетело и опубликовало эту надпись здесь
Отвечу сразу вам и gecube в одном комментарии, вы очень похожие тезисы высказываете.
У меня есть некоторый опыт с FreeBSD (годика 3 в конце нулевых мы с ним очень плотно общались и после этого я из ностальгических соображений держал несколько серверов на нем, включая один домашний и до сих пор он кое-где у меня в хозяйстве есть), но по сути большую часть времени я все-таки работал с Linux, а с LXC познакомился на практике еще до того, как Docker появился, как раз будучи «админом крупной серьезной организации» и собственно до сих пор продолжаю в таких организациях работать, правда фин. организаций касался мало, не лежит у меня к ним душа ну совсем.
Так вот, история про «все в контейнерах» это примерно то-же самое, что история «все в jail-ах», только… удобнее.
Да, я не считаю, что все надо в них упаковывать, но когда речь идет о некоем «пользовательском приложении», то контейнер — это неплохой выход, потому что:
1. Удобно управлять:
— Стандартный интерфейс (docker/podman/что угодно еще), стандартные команды везде. Если сравнивать с джейлами — то в принципе то же самое, но есть человечесикий API с биндингами под все популярные языки. Да, джейлы тоже можно скриптовать, но на порядок (а то и больше) менее удобно, особенно с точки зрения управления жизненным циклом.
2. Удобно собирать и распространять:
— Собрать контейнер, упаковать его и отправить в хранилище очень просто.
— Не надо писать скрипты для установки, конфигурации и чистки.
— Само хранилище (считай репу) поднять просто или очень просто (одна команда на своем сервере/можно купить практически в любом облаке как сервис).
— Обслуживать хранилище аналогично просто (под ногами или FS, или S3 совместимый сторадж, который опять же можно поднять\собрать\купить совершенно без проблем).
3. Удобно версионировать:
— Нет мусора, контейнер — вещь в себе.
— Зависимости катаются вместе с приложением (да, оверхед, но это пока ничего несовместимого по системным библиотекам запускать не приходится, вот там и начинается веселье и ты готов хоть по 10гб качать каждый раз, лишь бы с этим не разбираться).
4. Легко для освоения. Да, это важно. После N-го объяснения о том, как правильно готовить пакет\порт и как готовить окружение для этого, начинаешь прям задумываться над тем, как этого избежать. В итоге, инструкция вида «базовый контейнер вот этот, контейнер для сборки софта на языке $langname вот этот, после сборки все копировать вот в эту конкретную папочку, вот тут вписать команду для запуска» выглядит гораздо менее сложно и потенциала для выстрела себе в ногу меньше.
5. Безопаснее. Стоит пояснить, что контейнер сам по себе нельзя считать 100% изоляцией, там мест для накосячить более чем достаточно, да и сама по себе технология контейнеризации не совсем про безопасность, но тем не менее:
— Удобнее контролировать версии и выкатывать security-патчи. Тебе не нужно следить вот прям за всеми всеми версиями всего ПО на каждой машине, тебе просто нужно знать, что работает вот такой-то контейнер с таким-то тегом, который можно просканировать один раз и так же один раз централизованно поменять, пересобрав от него остальные контейнеры и контролируемо выкатить везде где нужно без риска замены версии библиотек под ногами. На самих же хост-машинах стоит минимальный набор ПО, который опять же легче контролировать, чем если бы там стояло все то, что тянет пачка приложений.
— Уже упомянул, но — можно удобно после сборки, но до деплоя, гонять всякие security-сканеры поверх образа для поиска известных уязвимостей, причем делать это ровно один раз, т.к. есть гарантия что контейнер не поменяется (по крайней мере, не должен, а если поменялся в процессе выполнения там, где не должен был, то вообще это повод посмотреть на то, все ли впорядке).
6. Побочные удобства:
— Логи и ротейт (можно сказать девелоперу «пиши все в stdout/stderr, а дальше не твои проблемы, все уедет куда надо») и настраивается это один раз, а не для каждого приложения.
— Удобно откатывать версии (хвостов не отстанется, проблем с совместимостью не будет).
— Есть мощные оркестраторы вроде K8s, которые дадут еще миллион всего, от дискавери до сложных деплоев и распределенного крона до (через плагины) сетевых полиси, дополнительных изоляций и системы управления релизами.
Вообще, нет ничего страшного в том, чтобы «накатить контейнер в прод», это не отменяет требований к качеству того, что там внутри контейнера будет работать, но многие вещи это и правда может порешать и сильно ускорить.
Что же касается «админа локалхоста», то контейнеры в первую очередь удобны для сборки (можно в разных окружениях все что нужно посмотреть, разные версии компилятора и библиотек проверить\попробовать, зависимости постоянно ставить не надо и т.д.) и для использования того софта, который не компилится в бинарь (все что угодно на python/node, допустим). Небольшая магия с алиасами и контейнерное приложение работает как обычно, но все свои зависимости держит при себе. И обновляется удобно. Хотя, такие решения и без контейнеров конечно же существуют.
У меня есть некоторый опыт с FreeBSD (годика 3 в конце нулевых мы с ним очень плотно общались и после этого я из ностальгических соображений держал несколько серверов на нем, включая один домашний и до сих пор он кое-где у меня в хозяйстве есть), но по сути большую часть времени я все-таки работал с Linux, а с LXC познакомился на практике еще до того, как Docker появился, как раз будучи «админом крупной серьезной организации» и собственно до сих пор продолжаю в таких организациях работать, правда фин. организаций касался мало, не лежит у меня к ним душа ну совсем.
Так вот, история про «все в контейнерах» это примерно то-же самое, что история «все в jail-ах», только… удобнее.
Да, я не считаю, что все надо в них упаковывать, но когда речь идет о некоем «пользовательском приложении», то контейнер — это неплохой выход, потому что:
1. Удобно управлять:
— Стандартный интерфейс (docker/podman/что угодно еще), стандартные команды везде. Если сравнивать с джейлами — то в принципе то же самое, но есть человечесикий API с биндингами под все популярные языки. Да, джейлы тоже можно скриптовать, но на порядок (а то и больше) менее удобно, особенно с точки зрения управления жизненным циклом.
2. Удобно собирать и распространять:
— Собрать контейнер, упаковать его и отправить в хранилище очень просто.
— Не надо писать скрипты для установки, конфигурации и чистки.
— Само хранилище (считай репу) поднять просто или очень просто (одна команда на своем сервере/можно купить практически в любом облаке как сервис).
— Обслуживать хранилище аналогично просто (под ногами или FS, или S3 совместимый сторадж, который опять же можно поднять\собрать\купить совершенно без проблем).
3. Удобно версионировать:
— Нет мусора, контейнер — вещь в себе.
— Зависимости катаются вместе с приложением (да, оверхед, но это пока ничего несовместимого по системным библиотекам запускать не приходится, вот там и начинается веселье и ты готов хоть по 10гб качать каждый раз, лишь бы с этим не разбираться).
4. Легко для освоения. Да, это важно. После N-го объяснения о том, как правильно готовить пакет\порт и как готовить окружение для этого, начинаешь прям задумываться над тем, как этого избежать. В итоге, инструкция вида «базовый контейнер вот этот, контейнер для сборки софта на языке $langname вот этот, после сборки все копировать вот в эту конкретную папочку, вот тут вписать команду для запуска» выглядит гораздо менее сложно и потенциала для выстрела себе в ногу меньше.
5. Безопаснее. Стоит пояснить, что контейнер сам по себе нельзя считать 100% изоляцией, там мест для накосячить более чем достаточно, да и сама по себе технология контейнеризации не совсем про безопасность, но тем не менее:
— Удобнее контролировать версии и выкатывать security-патчи. Тебе не нужно следить вот прям за всеми всеми версиями всего ПО на каждой машине, тебе просто нужно знать, что работает вот такой-то контейнер с таким-то тегом, который можно просканировать один раз и так же один раз централизованно поменять, пересобрав от него остальные контейнеры и контролируемо выкатить везде где нужно без риска замены версии библиотек под ногами. На самих же хост-машинах стоит минимальный набор ПО, который опять же легче контролировать, чем если бы там стояло все то, что тянет пачка приложений.
— Уже упомянул, но — можно удобно после сборки, но до деплоя, гонять всякие security-сканеры поверх образа для поиска известных уязвимостей, причем делать это ровно один раз, т.к. есть гарантия что контейнер не поменяется (по крайней мере, не должен, а если поменялся в процессе выполнения там, где не должен был, то вообще это повод посмотреть на то, все ли впорядке).
6. Побочные удобства:
— Логи и ротейт (можно сказать девелоперу «пиши все в stdout/stderr, а дальше не твои проблемы, все уедет куда надо») и настраивается это один раз, а не для каждого приложения.
— Удобно откатывать версии (хвостов не отстанется, проблем с совместимостью не будет).
— Есть мощные оркестраторы вроде K8s, которые дадут еще миллион всего, от дискавери до сложных деплоев и распределенного крона до (через плагины) сетевых полиси, дополнительных изоляций и системы управления релизами.
Вообще, нет ничего страшного в том, чтобы «накатить контейнер в прод», это не отменяет требований к качеству того, что там внутри контейнера будет работать, но многие вещи это и правда может порешать и сильно ускорить.
Что же касается «админа локалхоста», то контейнеры в первую очередь удобны для сборки (можно в разных окружениях все что нужно посмотреть, разные версии компилятора и библиотек проверить\попробовать, зависимости постоянно ставить не надо и т.д.) и для использования того софта, который не компилится в бинарь (все что угодно на python/node, допустим). Небольшая магия с алиасами и контейнерное приложение работает как обычно, но все свои зависимости держит при себе. И обновляется удобно. Хотя, такие решения и без контейнеров конечно же существуют.
Не буду спорить — докер удобен, но затыкать им каждую дыру, как это делают сейчас, совсем скоро будет моветон.
По пунктам мне немного сложно ответить, потому как я не настоящий админ, но отвечу так: Все эти плюсы — по сути есть плюсы кастрированной ВМ до размера приложения со всеми плюшками и карасями. Для меня это выглядит примерно одинаково, за исключением накладных расходов. Это бесспорно плюс и все что вы написали я не буду отрицать, это отличные решения и каждый из этих пунктов я так или иначе использую.
Может я становлюсь скрягой (сейчас пойдет поток мыслей) — но для меня это нарушение принципов линукса и даже принципов KISS — мы имеем блакбокс, который, как правило, за нас настроили и выложили другие люди, мы его качаем и донастраиваем. Мы это делаем зачем? Потому что иначе задачу решить будет сложней. Тогда чем это отличается от тупого копипаста команд из гугла и тыканьем в слепую, вместо понимания как оно работает? Ок, на деве можно, но на продакшне я хочу точно знать что у меня и как.
Лично для меня, но я не навязываю, более близок путь с собиранием софта под свои нужды во фряхе из портов с отключением ненужного функционала.
Не хочу сильно вдаваться в спор. В целом, все что пишете — относительно верно. Проблема только лишь в том, что дьявол в нюансах. Вот скажите — зачем нужен докер, если можно катить в облако виртуалками? Мы же все прекрасно понимаем, что один сервер — много сервисов — это плохо. Да, конечно, если хочется гонять стейтлес и максимально уплотнять ресурсы — тут контейнеризапция вне конкуренции, но это явно не история про БД, хранение и что ещё стейтфул. Базы вообще очень не любят делить ресурсы с кем бы то ни было ещё. Для тестовых контуров — конечно, пофиг.
К тому же, докер — это про контейнер приложения. Со всеми вытекающими. Поэтому в админстве для долгоживущих задач хорошо зашёл lxc/lxd. Я очень долго со скепсисом относился к этой технологии, но знаю немало примеров ее удачного внедрения.
Оркестратор — сюда приплепать вообще излишне, т.к. под капотом у него может быть что угодно. Вон — коллеги уже разрабатывают легковесные виртуалки на базе firecracker и аналогов, чтобы решить часть проблем докера. А что оркестрировать — вообще по барабану. Кубернетес в целом позволяет писать адаптеры к чему угодно. Просто так исторически сложилось, что эта система началась как оркестрация контейнеров…
В общем, я к чему. Докер в зависимости от контекста — может быть от "великое благо" до "ненужный компонент". Нужно смотреть по своим задачам и по своей инфраструктуре.
Ну если мы говорим уж за совсем egde инсталяции, на примере которых обсуждают обычно такие штуки, то все выглядит несколько по-другому.
Не совсем так. Но даже если так, то вообще нынче принято базы брать как сервис, если уж у нас облако. При этом — само наличие контейнера совершенно не определяет то, будет ли у нас этот контейнер один на машине или их будет сотня. Даже если он будет один, то все плюсы в целом присутствуют (как в общем то и минусы).
Не очень понятно про какие вытекающие вы говорите. К тому же конктерно containerd позволяет очень много штук, включая достаточно гибкое управление контекстом. Про то, что сеть может быть любая (хоть своя, хоть хостовая) я думаю и так понятно.
Безусловно. С одной пометкой — у контейнеров весьма широкое применение (настолько широкое, что принципы контейнерной дистрибуции живут уже черт знает сколько лет в mac os и на них основан snappy) и вариантов использовать его реально странно (ну, роутер там сделать внутри контейнера) не так много. В остальных случаях он не хуже обычного apt-get/dnf/yum/pkg install.
Вообще, мне кажется очень влияет масштаб. Пока мне приходилось работать с единицами и десятками серверов и приложений на них — вроде как все было неплохо и без него и вообще можно походить пособирать каждое приложение отдельно вдумчиво руками.
А вот когда серверов уже десятки, приложений сотни и релизы катятся один за одним — вот тут контейнеры очень даже в тему. Можно на виртуалках где-нибудь в AWS/GCloud/Azure, да, но контейнерами выходит проще и дешевле.
это явно не история про БД, хранение и что ещё стейтфул. Базы вообще очень не любят делить ресурсы с кем бы то ни было ещё.
Не совсем так. Но даже если так, то вообще нынче принято базы брать как сервис, если уж у нас облако. При этом — само наличие контейнера совершенно не определяет то, будет ли у нас этот контейнер один на машине или их будет сотня. Даже если он будет один, то все плюсы в целом присутствуют (как в общем то и минусы).
К тому же, докер — это про контейнер приложения. Со всеми вытекающими.
Не очень понятно про какие вытекающие вы говорите. К тому же конктерно 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 тысяч евро относительно решения на своей инфраструктуре.
Вы обсуждаете разную контейнеризацию. Docker — контейнер приложений (application container), LXC/LXD/OpenVZ/Jail — системные контейнеры (system container). Сделаны по-разному и для разного.
Спасибо, кэп, но это не отменяет того, что у указанных технологий пересекаются сферы применимости.
Они пересекаются технологически, но не идеологически. Docker не подходит и не предназначен для контейнеров с большим количеством демонов, как и не подходит LXC/Jail для запуска одной единственной программы, предварительно установив туда всю ОС.
Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
Иногда и 1 приложение затрагивает данную проблему. В частности, если что-то написано под systemd, оно не работает в докере. Точнее, нужно много приседаний по запуску подрезанного systemd, и только тогда оно начинает работать. Названия не могу вспомнить, но несколько лет назад в прошлой компании сталкивался с таким софтом.
Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
В сознании обывателя — докер понятнее и удобнее. Те же докерфайлы, возможность сгружать готовые образы в стандартном формате из докерхаба или любого совместимого хранилища… К сожалению, ни nspawn, ни lxd не создали такую широкую экосистему… Поэтому и понятное желание пихать докер в любую дырку. Ну, и подогрело это все оркестраторы вроде кубернетеса — в которые тот же nspaws/lxd положить можно, но это надо самому писать необходимые прослойки и модули, а докер — вот он, из коробки
Я собираю образ сервиса и запускаю его для k8s и у пользователей на компах.
Особенно это критично когда нужно с Python пакетами работать на компах, а на в «Клауде». Тут даже virtual environment не поможет для компов на Виндовс, МакОс и Линукс.
А почему заоопарк?
А потому, что на Винде пользователи PowerBI и других программ. На Маке — как бы стандарт. А на Линуксе — продвинутые.
Особенно это критично когда нужно с Python пакетами работать на компах, а на в «Клауде». Тут даже virtual environment не поможет для компов на Виндовс, МакОс и Линукс.
А почему заоопарк?
А потому, что на Винде пользователи PowerBI и других программ. На Маке — как бы стандарт. А на Линуксе — продвинутые.
> Без приуменьшения — любая задача
Как это любая?
Порисовать в гимпе — нужен докер?
Установить самбу или апача — нужен докер?
И как это я всю жизнь всё это и всё остальное делал без докера… (из которого знаю только слово докер)
Как это любая?
Порисовать в гимпе — нужен докер?
Установить самбу или апача — нужен докер?
И как это я всю жизнь всё это и всё остальное делал без докера… (из которого знаю только слово докер)
Докер это рак. Просто примите это как данность. Почему? Окей расскажите мне как вы через лет 5-10 будете софт ставить? Из того же контейнера? Ну он например может не заработать и надо будет изменить окружения софта. Или например вам надо обновить ПО. Тоже будет боль и страдания. Нельзя привязываться к конкретному окружению это путь в никуда.
НЛО прилетело и опубликовало эту надпись здесь
Ухудшил. Я все чаще встречаю софт который имеет инструкции поставьте наш контейнер. Остальное просто игнорируется. И это не про коммерческий софт, а про opensource. Причем часто чтобы запустить в итоге без докера может потребоваться куча не тривиальных движений. Потому что установка через docker первична, а как оно там без докера работает нас не волнует.
Гниение софта это вообще отдельная боль и печаль, но банальный configure и make работают заметно лучше и портировать или починить софт проще чем вынуть его из докера.
Гниение софта это вообще отдельная боль и печаль, но банальный configure и make работают заметно лучше и портировать или починить софт проще чем вынуть его из докера.
починить софт проще чем вынуть его из докера.
Ну, я не согласен. Смотря что Вы понимаете под вынуть из докера. Перенести в ДРУГУЮ песочницу — типа chroot или systemd nspawn? Да не проблема. Работоспособность софта пострадает? Нет! А дальше можете весь этот чрутованный пакет точно так же превратить в rpm/deb и доставить на целевую машину. Здесь просто происходит смена парадигмы — раньше мы действительно пытались зависеть от того какие пакеты сидят в системе, но по определенным причинам — это действительно сложно. Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.
Проблема в том что приложение которое оттуда вынули ставится своим набором костылей и без зависимостей, потом при переносе можно долго их разматывать.
В случае если приложение просто ставится локально попроще все же.
Вот я про это и говорю. А это всплывает не сразу, а через 5-10 лет что выливается в сложности при размотке контейнера.
В случае если приложение просто ставится локально попроще все же.
Проще отдать самодостаточное приложение (тут есть нюансы с версией драйвера, ядра и прочего, что у контейнеров общее) и не ломать голову ни себе, ни пользователю.
Вот я про это и говорю. А это всплывает не сразу, а через 5-10 лет что выливается в сложности при размотке контейнера.
НЛО прилетело и опубликовало эту надпись здесь
Это проблем докера. Я уж молчу что фактически докер привязывает нас к одной платформе. make кстати в большинстве случаев позволяет легко адаптировать его и под другую posix платформу. Докер нет. Если вы мне тут начнете рассказывать про докер в windows то я напомню что он там работает не поверх нативного слоя. Дополнительно докер контейнер банально бинарная сборка и допустим x86 на x86_64 я запустить могу, то вот на mips и arm ой. Нужен отдельный docker.
Докер провоцирует собрать в него, так же разработчику удобнее. Но это аукнется потом, когда потребуется перенести куда-то еще и контейнер там просто не работает и все.
Докер провоцирует собрать в него, так же разработчику удобнее. Но это аукнется потом, когда потребуется перенести куда-то еще и контейнер там просто не работает и все.
Я очень извиняюсь за собственную категоричность, но судя по вашим суждениям вам никогда не приходилось деплоить пару десятков приложений в десятках и сотнях экземпляров как минимум в 2 разных места хотя бы 2 раза в день. Искренне желаю вам удачи повозить кругом свой код и поделать make на каждой машинке.
Все это «у меня make не ломается» и «а вот тут я могу запустить сборку под другую архитектуру, а тем не могу» в подавляющем большинстве практических задач просто не имеет никакого смысла. Разнообразие архитектур у конкретного бизнеса обычно минимально. Особенно если говорить об одном и том же приложении.
И кстати да, докер есть допустим под arm и да, под него можно собрать контейнер и это даже будет работать. Собрать 1 раз. И запустить за пару минут в любом месте.
Тут же все очень просто — если есть подходяще написанный код и руки, то никакой докер не помешает собрать приложение под другую архитектуру. Он никак не привязывает. Результирующий образ вполне может собираться командами make. А где этот make запускать — дело десятое.
Но — подавляющее большинство серверов на x86_64 и да, разработчик просто не заморачивается.
Все это «у меня 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 и не ломайте голову. Бридж реально под нагрузкой очень проседает и латентность в космос. А изоляция по сети между проекта докера… на самом деле такая большая фикция
НЛО прилетело и опубликовало эту надпись здесь
Чему Эпол сопротивляется? Макось — это итак Юникс, они стабильно подтверждают это каждый раз сертификатами, а так же соответствию POSIX, там определенно никто не будет делать бинарной совместимости с линуксом как в винде, никогда. Разработчики сами портируют свой софт на макось для удобства разработки, а докер под макось есть, официальный, посредством виртуализации через HyperKit. Оно куда медленнее нативной работы под линуксом, но и задачи у него другие.
НЛО прилетело и опубликовало эту надпись здесь
Так hyperkit это собственная разработка докера, оно надстройка над hypervisor.framework. Я использовал какой-то экспериментальный гипервизор на базе встроенного hypervisor.framework veeamu veemu как-то там, весил всего несколько мб, видно что минимальная надстройка и глючный, но десктопные ОСи работали там шустренько.
Я про то что сборка бинарная. А если это единственный метод получить ПО то мы приплыли. Даже если софт не питоне сделан, а контейнер будет содержать бинарное окружение. Для запуска придется или пересобрать контейнер, если для него опять же доступен файл сборки или ковырять руками.
Закон Мура умер как только у нас появились двуядерные процессоры. Вы правда думаете что многоядерность от хорошей жизни? :))
Закон Мура умер как только у нас появились двуядерные процессоры. Вы правда думаете что многоядерность от хорошей жизни? :))
НЛО прилетело и опубликовало эту надпись здесь
Часто исходники доступны и их можно собрать в том числе и под другой дистрибутив, с довольно минимальными правками. Это я вам как человек который регулярно занимается всяким бекпортом и сборками говорю :)
Ну а многопоточность конечно улучшают, нужно же чтобы это требовало меньшей квалификации от программистов.
Ну а многопоточность конечно улучшают, нужно же чтобы это требовало меньшей квалификации от программистов.
А мне например понравилось юзать jails в FreeBSD вместо Docker на Ubuntu.
И софтверный RAID6 на ZFS для домашнего сервера очень зашёл.
Но на десктоп ставить это уже мазохизм/энтузиазм
Простите, но как же можно сравнивать Jail c Docker-ом ???
jail — FreeBSD-специфичная контейнерная виртуализация. Аналоги в Linux — chroot, OpenVZ, LXC и кучка устаревших/проприетарных технологий. Аналоги, кстати, куда более продвинутые, в отличии от Jail, где не поддерживается ни квотирование/лимиты толком ни миграция ни… впрочем, этого достаточно.
Docker — «система быстрого деплоя с клиент-серверной архитектурой» (простите за вольный перевод), в качестве контейнерной виртуализации использующая Linux LXC/cgroups, так же имеющая «на борту» еще кучу других сущностей…
jail — FreeBSD-специфичная контейнерная виртуализация. Аналоги в Linux — chroot, OpenVZ, LXC и кучка устаревших/проприетарных технологий. Аналоги, кстати, куда более продвинутые, в отличии от Jail, где не поддерживается ни квотирование/лимиты толком ни миграция ни… впрочем, этого достаточно.
Docker — «система быстрого деплоя с клиент-серверной архитектурой» (простите за вольный перевод), в качестве контейнерной виртуализации использующая Linux LXC/cgroups, так же имеющая «на борту» еще кучу других сущностей…
> Но на десктоп ставить это уже мазохизм/энтузиазм
Если не требуются «принтеры да сканеры», то для десктопа фряха уже давно — годная система. А для подключения к ней принтера бубен пока ещё нужен…
Если не требуются «принтеры да сканеры», то для десктопа фряха уже давно — годная система. А для подключения к ней принтера бубен пока ещё нужен…
Я ожидал более подробной статьи
Вот так и я. FreeBSD — моя любовь навсегда, ставлю, когда могу, на сервера, новые выпуски тереблю в виртуалке, пытаюсь ставить на каждый новый ноут как десктоп-систему (ни разу успешно — железо не имеет драйверов). А работаю в основном с Linux.
Запустил бы jail и радовался, но нет, приходится жрать docker, подавляя рвотный рефлекс, потому что он нужен клиенту
Фряха форева, что уж
Наверняка любой пользователь сталкивался с тем, что система или перестаёт отвечать/работать при нехватке памяти
Ага, при исчерпании памяти на диске система (Ubuntu 18.04) постоянно перезапрашивает пароль при входе в систему. :)
P.S. Лечится очисткой жёсткого диска для не нулевого размера доступного пространства, например, загрузив какой нибудь LiveCD.
init=/bin/bash
и не нужны никакие livecd.
и не нужны никакие livecd.
Ctrl-Alt-F2 и ваши волосы становятся мягкими и шелковистыми.
И чем поможет возможность зайти другим пользователем?
Зачем другим? Заходите под собой, чистите раздел от хлама и уже потом, спокойно, можете логиниться в гуй.
Где гарантия текстового входа в этом случае? Ой не уверен, с новыми-то веяниями...
Гарантия в настройках tty. Какие такие мифические веяния вы имеете ввиду, мне даже и придумать сложно.
Гарантия в настройках tty.
Что, tty сам по себе может обеспечить шелл? Без /usr/bin/login, полного набора действий в setusercontext(), вызова шелла, инициализационных скриптов шелла и тэ дэ и тэ пэ? Ну тогда вы говорите о какой-то другой системе, не о FreeBSD.
Какие такие мифические веяния вы имеете ввиду, мне даже и придумать сложно.
Ну я вот ставлю bash в качестве шелла, а как он отреагирует со всеми стандартными скриптами на переполнение диска, предсказать сложно.
Может, надо было бы tcsh ставить, но как-то сейчас даже в BSD мире без баша не прожить.
Что это без баша не прожить? Много лет назад как избавился от него на всех своих системах, так и нету его. Бесполезен. Причём раньше я ещё встречал частенько какие-нибудь (не свои) скрипты написанные на «bash», а не POSIX shell — сейчас такого значительно меньше.
И баш и любой другой шелл нормально отреагируют. Ну максимум отматюкают что логи в хистори прописать не могут.
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 работают уже по несколько лет с почти стопроцентным аптаймом.
НЛО прилетело и опубликовало эту надпись здесь
Лет 20 назад я ещё мог понять такие сравнения, сейчас то чего вдруг?
в десктопе — просто жопа, в доступности приложений/игр аналогично, в оборудовании — вах, вах, мобилки — все на android, а в серверах — ну найди в webservers/top500 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.
мне думается что смысл жизни последних 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.
Playstation 3, Playstation 4 и Nintendo Switch используют форки FreeBSD.
дык, тут дело больше в лицензии — Sony имеет право не открывать свои доработки
Насколько я знаю вы не правы насчет Nintendo Switch, немного об этом есть тут, но в целом на видео с конференций о взломах 3ds, и Switch так же об этом говорилось. У них своя ОС, а не форк.
Единственным ближайшим аналогом является SystemTap
BPF и bpftrace.
Брэндан Грегг даже книжку уже выпустил.
НЛО прилетело и опубликовало эту надпись здесь
Идёт процесс заворачивания софт в Capsicum но не так чтобы быстро.
В systemd встроено управление capabilities и namespaces, можно всё достаточно удобно и быстро разграничить. Для десктопных программ есть firejail и альтернативы.
systemd и один только факт того, что *BSD его не используют уже является killer-feature.
Почему?
Извиняюсь за то что я могу показаться малость резким. Я с вашим мнением указанным в этой статье категорически не согласен. Ваше сравнительное описание BSD > GNU/Linux мягко говоря странная затея… тем более что компетенции по описанию мягко говоря мало…
или вот это ваше сильное заявление:
Это ваше доказательство: вах ВАХ вах нет практически бесполезной ZFS…
Ок: ZFS разве есть всё? и без него жить не возможно? О_о.
А про losetup дык это вообще верх возмущения… не читается автоматом таблица ВАХ ВАХ ВАХ, беда беда. Отсталые в технологии… Это же как можно быть такими отсталыми…
В указанной статье вы смотрите на это с точки зрения глупого пользователя которому все всё должны… И ментейнеры, разработчики и в общем все те кто предоставляет Вам свои труды бесплатно и не требуя ничего в замен… Увы но такая точка зрения мне категорически не приятна.
GNU/Linux разрабатывалась программистами и для программистов… и многое из того что Вы считаете неделимым и приписываете к BSD это часть проектов GNU и других… только Вы об этом либо не знаете либо решили промолчать.
И следовательно ваше заявление о целостности BSD выглядит мягко говоря печально… Что там целостного набор тех же открытых проектов только бантик с права?
И так далее по всей статье… ничего кроме пустых заявлений.
Более того из моего личного опыта я могу сказать что отсталость наблюдается именно на стороне BSD… Если хотите примеры приведу как и где и почему.
В общем я крайне не согласен с вашей точкой зрения. И прошу меня извинить за резкость и если я Вас или кого-то обидел, но это моё скромное мнение как программиста и простого юзера который работает на GNU/Linux уже порядка 14 лет…
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 я о таком что-то не слышал.
На systemd вы зря наехали, все сетевые настройки, которые вы записали в минусы линуксу, делаются через systemd легко. Плюс те которые во фре вообще сделать нельзя.
ipfw это же просто файрволл, эволюция которого была остановлена :)
Напоминаю откуда появился nftables: ipfw->ipchains->iptables->nftables
pf, когдя я его последний раз смотрел, был слишком тормозной. Просто добавление модуля pf в ядро, сразу зарезало 20% ПС интеловской встройки на системе с Атомом D525
Но вот интеграция ZFS с ОС FreeBSD шикарна. И работает ZFS во фре обычно быстрее, процентов на 10% как минимум. Это лучше всего видно на LSOF (lot of small files).
ipfw это же просто файрволл, эволюция которого была остановлена :)
Напоминаю откуда появился nftables: ipfw->ipchains->iptables->nftables
pf, когдя я его последний раз смотрел, был слишком тормозной. Просто добавление модуля pf в ядро, сразу зарезало 20% ПС интеловской встройки на системе с Атомом D525
Но вот интеграция ZFS с ОС FreeBSD шикарна. И работает ZFS во фре обычно быстрее, процентов на 10% как минимум. Это лучше всего видно на LSOF (lot of small files).
slonik-v-domene.livejournal.com/96331.html — вот альтернативный наброс
Мы ушли с FreeBSD потому что они много лет не могли нормально запилить балансировку потоков по разным процессорам.
Мы ушли с 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?
И тем не менее, на любые плюсы и минусы рынку наплевать. Так что FreeBSD будет оставаться в своих условных 0.5%.
Если ты такой умный, почему такой бедный.
Или почему 100 из 100 серверов крутятся на Linux тем временем как bsd всем хороша?
НЛО прилетело и опубликовало эту надпись здесь
Я молчу о том, что преобладающая часть популярных дистрибутивов начало активно использовать systemd и один только факт того, что *BSD его не используют уже является killer-feature.
Серьезно? Не знаю, какая система инициализации использутеся в *BSD, но я, когда узнал о systemd, сразу подумал: наконец-то сделали что-то нормальное вместо костылей из bash-сценариев, коими по сути являются OpenRC, SysVinit и пр.
Не знаю, какая система инициализации использутеся в *BSDBSD Init, как ни удивительно.
Бизнес: мое приложение тормозит, держите мои деньги!
FreeBSD: Нуу, сейчас сделаем трейс, построим график и найдем узкое место вашего приложения
Linux: Просто добавляю ноду в кластер на кубере. %pockerface%
FreeBSD: Нуу, сейчас сделаем трейс, построим график и найдем узкое место вашего приложения
Linux: Просто добавляю ноду в кластер на кубере. %pockerface%
НЛО прилетело и опубликовало эту надпись здесь
Очень доходчиво, но в корне не верно. Уж больно узкая точка зрения, всё зависит от человека, норм админ vs покер админ… Мне никогда в GNU/Linux не составляло трудностей делать трассировки и даже в закрытом софте накладывать свои патчи на асме и т.п. Так что ваше сравнение не верное.
Linux: Просто добавляю ноду в кластер на кубере. %pockerface%
эх, если бы всегда было так просто
Добавили ноду, ниче не поменялось. Все равно делать трейс и смотреть графики.
Еще забыл про dllsohell
На практике, если сейчас взять одни из последних дистрибутивов Ubuntu, то вы не факт что сможете поставить его не на первый жёсткий диск
BIOS или UEFI? До недавних времен мог, что сменилось сейчас?
Теперь только ALSA, мало чего умеющая из вышеперечисленного
В ядре при сборке можно включить режим совместимости, или не оно?
если выбирать, то лучше тогда допиленную версию фряхи к которой народные умельцы наконец прикрутили что-то поприличнее доисторического кошмара иксов. Ею, говорят, даже эппловцы не брезгуют :trollface:
Добавлю свои 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 лет :)) а так да, кубернетес, циско и всё прочее… ага :))
Я так понимаю поддержка freebsd в ansible, salt, chef, puppet тоже оставляет желать лучшего. 90% модулей не умеют работать в этой ОС. То есть писать все самому…
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 божественен.
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.
Вот с агентами контейнеров, да, провал.
Всё или почти всё по списку есть в портах. Это как раз не проблема — специфической кодовой заточки под 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 и миллион подводных камней, которые всплывут в процессе всего этого. Я думаю бизнес ответит мне, что я дурачек и наймет другого инженера.
В портах? То есть я сейчас в 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 и миллион подводных камней, которые всплывут в процессе всего этого. Я думаю бизнес ответит мне, что я дурачек и наймет другого инженера.
Все что есть в портах есть в пакетах, вот проверил ClickHouse и Nginx
проверить наличие, если у вас нет FreeBSD, можно тут www.freebsd.org/ru/ports/databases.html
В Hetzner Cloud я лично держу VPS на FreeBSD, она у них есть в списке ОС и более того, у них даже есть рекавери для FreeBSD, вот в Амазон: aws.amazon.com/marketplace/pp/FreeBSD-FreeBSD-12/B07L6QV354 за другие уже не скажу, но имхо она есть почти везде.
⋊> ~ 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 за другие уже не скажу, но имхо она есть почти везде.
> В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?
Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять.
«Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты. Есть какая-то малая доля тех, что лицензия требует собирать только на месте, но после всяких 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, если будут думать по принципу «сегодня на локалке, завтра в амазоне, послезавтра в азуре или на дедике в соседнем ДЦ, и всё это с минимизацией расходов на людей». Но вроде же с этим никто и не спорил? И почему у всех должны быть именно такие задачи?
Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять.
«Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты. Есть какая-то малая доля тех, что лицензия требует собирать только на месте, но после всяких 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:
> Вы домысливаете несуществующее, не попытавшись хотя бы минуту почитать и понять. «Порты» это инфраструктура поставки продуктов за пределами базовой системы, но она позволяет как собирать на месте (если хотите), так и стягивать готовые пакеты
Это хорошо, видимо я что-то упустил. Я уделил точно больше минуты, так как в прошлом был опыт обслуживания серверов на freebsd. Возможно что-то забыл, но как-то запомнилось что порты это именно про сборку из исходников, а pkg пакетный менеджер, который качает и устанавливает архивы с бинарниками.
Не понимаю с чего вы взяли что я «взвился» на ваше сообщение. Я лишь пытаюсь выяснить как именно 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, но именно тут сами его нарушают.
А как ещё понять реплику типа
>> Мне наверное не понять людей, которые топят за замену 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 бесполезен, и только приведет к затратам на эксплуатацию и никаких плюсов от него не будет.
GEOM — мне хватало device mapper в Linux. Сейчас нигде не использую.
ZFS — у меня работал на Linux. Сейчас тоже нигде его не использую.
Netgraph — мне не нужен, да и на практике я его встречал совсем в уникальных кейсах. Вряд-ли когда-то потребуется
То есть для моей работы (обычный веб) FreeBSD бесполезен, и только приведет к затратам на эксплуатацию и никаких плюсов от него не будет.
В портах? То есть я сейчас в 2020 году должен компилировать софт из исходников чтобы его поставить?Ну или ты хочешь оптимизированную компиляцию (-march=native) под свою железку или нет…
> Ну или ты хочешь оптимизированную компиляцию (-march=native) под свою железку или нет…
Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
>Нет. Бизнес мне говорит, что ему надо в случае чего быстро развернуть 100+ нод в облаке и добавить их в кластер. Оптимизированную компиляцию бизнесу точно не надо
Очень надеюсь, что дойдёт до вас Грета, и выдвинет вам регуляцию, и станете вы carbon footprint уменьшать всеми силами под угрозой штрафов. И будете вместо 100+ нод использовать 5, я думаю что вам хватит — если вместо Ruby писать на Rust, или хотя бы на C#, и делаться всё будет в интересах того самого «бизнеса», на который вы молитесь.
Очень надеюсь, что дойдёт до вас Грета, и выдвинет вам регуляцию, и станете вы carbon footprint уменьшать всеми силами под угрозой штрафов. И будете вместо 100+ нод использовать 5, я думаю что вам хватит — если вместо Ruby писать на Rust, или хотя бы на C#, и делаться всё будет в интересах того самого «бизнеса», на который вы молитесь.
Ну на 32-битке это ещё имело смысл — дефолтная компиляция под некоторый базовый i386 не включала кучу вкусностей более позднего периода; я обычно задавал там опции типа "-march=pentium4 -mtune=k8 -msse2". На amd64 смысл теряется. Выигрыш от SSE3/4 и AVX128 копеечный, от AVX2 можно даже проиграть. BMI всякие нужны только для особых алгоритмов, а программы, что их используют, включают какую-нибудь рантайм-проверку. Где-нибудь есть пример реальной пользы от такой компиляции под amd64?
Про облако тоже замечание в тему — вот что в облаке обычно не гарантируют (или слишком дорого), так это что узлы будут поддерживать все эти новые фишки.
Про облако тоже замечание в тему — вот что в облаке обычно не гарантируют (или слишком дорого), так это что узлы будут поддерживать все эти новые фишки.
В начале нулевых ставил и сравнивал Mandriva(падала и била себе фс) и FreeBSD на мелкий комп для сервера CS1.6. Да, тогда сервер на FreeBSD летал и было удобно, но сейчас я не вижу смысла пересаживаться с linux.
Да, новый resolve меня пробесил в ubuntu не нашел как теперь глобально и просто прописать nameserver'а).
Да, несколько способов прописать сервис не шик.
Но, я уверен, что если выйдет какая-то местечковая прога для, например, для логического анализатора saleae, то она будет работать у меня. Я знаю, что в случае проблемы, в интернете больше шансов найти решение для linux, чем для unix.
Кроме того, поправьте меня если не так, та же ubuntu лучше оптимизированна для работы на ноутбуках, чем та же FreeBSD. Еще расскажите можно ли быстро и просто установить *BSD с шифрованием всего диска и LXDE?
Да, новый resolve меня пробесил в ubuntu не нашел как теперь глобально и просто прописать nameserver'а).
Да, несколько способов прописать сервис не шик.
Но, я уверен, что если выйдет какая-то местечковая прога для, например, для логического анализатора saleae, то она будет работать у меня. Я знаю, что в случае проблемы, в интернете больше шансов найти решение для linux, чем для unix.
Кроме того, поправьте меня если не так, та же ubuntu лучше оптимизированна для работы на ноутбуках, чем та же FreeBSD. Еще расскажите можно ли быстро и просто установить *BSD с шифрованием всего диска и LXDE?
Мне кажется вы суть статьи не поняли, речь в целом о серверном функционале и там фря отлично себя чувствует. В качестве десктопа ее рассматривать определенно не стоит. Впрочем как и линукс имхо. Но я себе мультимедиа центр поднял с коди на ней потому что хотел так же нас и zfs и вобщем-то там это делается парой команд, но настраивать придется вручную, а так есть PC-BSD/TrueOS.
Про т.ч. речь идёт только про сервера — автор обсуждаемой статьи нигде не упоминал.
История развития сборки фряхи для пользовательских ПК (настольных + ноутбуков): PC-BSD -> TrueOS -> Project Trident -> Void Linux.
В комментариях к статье на Phoronix создатели PC-BSD и её потомков жалуются на жизнь с FreeBSD — их патчи не принимали, и пр.
Линукс хорошо работает на настольных ПК и ноутбуках, xBSD — либо очень плохо, либо вообще не работают. Ноутбуки с предустановленным Линуксом есть в продаже — Acer, Asus, Dell. Линукс становится широко распространённой ОС. Драйвера для принтеров-сканеров зачастую есть для Линукса наравне с Win и Mac.
Про заимствование драйверов: когда ищешь их для какого-то устройства, то для Линукса — они уже есть, опробованы другими людьми и работают. Для xBSD — давай сам всё делай. Код берётся у тех, у кого уже работает — т.е. у Линукса. Да, можно конечно и самому всё делать, но зачем?
Преобразуя недавние слова Джо Байдена, «Нам не нужны обещания революции, нам нужно большее — результаты».
История развития сборки фряхи для пользовательских ПК (настольных + ноутбуков): PC-BSD -> TrueOS -> Project Trident -> Void Linux.
В комментариях к статье на Phoronix создатели PC-BSD и её потомков жалуются на жизнь с FreeBSD — их патчи не принимали, и пр.
Линукс хорошо работает на настольных ПК и ноутбуках, xBSD — либо очень плохо, либо вообще не работают. Ноутбуки с предустановленным Линуксом есть в продаже — Acer, Asus, Dell. Линукс становится широко распространённой ОС. Драйвера для принтеров-сканеров зачастую есть для Линукса наравне с Win и Mac.
Про заимствование драйверов: когда ищешь их для какого-то устройства, то для Линукса — они уже есть, опробованы другими людьми и работают. Для xBSD — давай сам всё делай. Код берётся у тех, у кого уже работает — т.е. у Линукса. Да, можно конечно и самому всё делать, но зачем?
Преобразуя недавние слова Джо Байдена, «Нам не нужны обещания революции, нам нужно большее — результаты».
Смотря что эти авторы PC-BSD предлагали, это еще раз говорит о строгой разработке и не засовывания всего подряд в кодовую базу как в лине, хотят свое пусть делают патчи, что-то хорошее итак перенесут в основную ОС.
>Линукс хорошо работает на настольных ПК и ноутбуках, 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. Существенные цифры, которыми любят хвастать фанаты, Линукс показывает благодаря сохо роутерам и смартфонам, ито уже гугол тот же пилит замену.
Таковы результаты.
>Линукс хорошо работает на настольных ПК и ноутбуках, 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. Существенные цифры, которыми любят хвастать фанаты, Линукс показывает благодаря сохо роутерам и смартфонам, ито уже гугол тот же пилит замену.
Таковы результаты.
на Rasberry аппаратное ускорение графики работает? :)
Вот не помню уже или не проверял, у меня там сейчас RasPlex. Это позже я собрал центр на ITX с freebsd и kodi, и там у меня карточка Nvidia на которой работает аппаратное ускорение, я возможно позже попробую это решение на малинку перенести.
На x86 я не удивлен. А вот на mips arm и прочем linux работает лучше и на большем количестве устройств.
А вот не факт ) Посмотрите на поддержку железа NetBSD, у них девиз — работаем на всем.
В т.ч кроссплатформенную поддержку Фря из нее тянет.
В т.ч кроссплатформенную поддержку Фря из нее тянет.
На всем и ничего толком :) Простой пример
wiki.netbsd.org/ports/evbarm/allwinner
Вот где прочерки стоят в случае linux стоит yes
wiki.netbsd.org/ports/evbarm/allwinner
Вот где прочерки стоят в случае linux стоит yes
Ладно это софистика конечно, но так как работают оф дистры линукса в тех железках сложно назвать работой в принципе, и дженерик линукс там тоже либо не заведется совсем без кучи вендоровских хаков и патчей (что опять приведет систему в полурабочее состояние) либо будет изрядным инвалидом с полурабочим функционалом. Это и отпугивает меня от этих железок с довольно хорошими характеристиками и ценой.
У вас устаревшие сведения. Я спокойно ставил fedora для arm на allwinner. И более того все работает. Уже давно все разработчики таких плат перестали пилить свои ветки и вливают это все в mainline ядро. А за счет такой вещи как Device Tree нет проблем с конфигурацией устройств. К примеру довольно простым изменением dbs файла я включил два uart порта на гребенке cubieboard 2.
Мм, может быть. Это отличные новости, значит настало время снова присмотреться к этим железкам, благодарю.
Я спокойно ставил fedora для arm на allwinner. И более того все работает. Уже давно все разработчики таких плат перестали пилить свои ветки и вливают это все в mainline ядро.Речь точно про Allwinner? Про какие-то старые чипы, A10, A20?
а так есть PC-BSD/TrueOSУже нет. Сайт и репозиторий будут отключены, как только у разработчиков выдастся свободная минутка.
Еще расскажите можно ли быстро и просто установить *BSD с шифрованием всего диска и LXDE?Это несколько разных систем. Можно.
С энергопотреблением и ноутбучными вещами у линуксов лучше, да, и вообще с любой поддержкой железа, wi-fi — боль. Просто кому-то достаточно того, что есть.
НЛО прилетело и опубликовало эту надпись здесь
Либо киньте пожалуйста актуальной документацией к netgraph, либо никогда не упоминайте этот пункт.
Довольно странное сравнение. Существенная часть пунктов сводится к «фича X в *BSD есть уже давно, а в GNU/Linux только что появилась». Часть пунктов рассматривают Linux, как ядро с kernel.org, часть — дистрибутивы, остальные — весь существующий юзерспейс. Кажется, будет правильнее взять какой-нибудь один дистрибутив, и сравнивать FreeBSD (а не все существующие *BSD-системы) с ним.
Если хочется получить целостную систему, с централизованным управлением всем подряд, стоит попробовать 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).
Если хочется получить целостную систему, с централизованным управлением всем подряд, стоит попробовать 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).
Поясните пожалуйста, почему наличие systemd в дистрибутиве является чем-то ужасным?
И чем вам мешает наличие IPv4 в ядре? Место на диске экономим?
И чем вам мешает наличие IPv4 в ядре? Место на диске экономим?
Мне как-то потребовалось настроить DoH ризолв. С systemd-resolved не получилось этого сделать от слова «совсем», я наступил на кучу грабель и багов, которые подтверждались на stackoverflow. Пришлось городить зоопарк.
Но самое эпичное было, когда systemd-journal начал падать и я даже не мог посмотреть логи.
Ну и еще целый шлейф багов.
Ну и странно держать ipv4 на сервере в ipv6-only сети. Косвенно это говорит о качестве кода, которым это все реализуется. Заглянув же в репозиторий кода ядра и увидев файлы tcp_ipv4.c и tcp_ipv6.c даже не будучи программистом можно понять, что «в консерватории что-то не то».
Но самое эпичное было, когда systemd-journal начал падать и я даже не мог посмотреть логи.
Ну и еще целый шлейф багов.
Ну и странно держать ipv4 на сервере в ipv6-only сети. Косвенно это говорит о качестве кода, которым это все реализуется. Заглянув же в репозиторий кода ядра и увидев файлы tcp_ipv4.c и tcp_ipv6.c даже не будучи программистом можно понять, что «в консерватории что-то не то».
увидев файлы tcp_ipv4.c и tcp_ipv6.c даже не будучи программистом можно понять, что «в консерватории что-то не то».
Вы наверное знаете, что это разные протоколы? Там отличия не только в структуре адреса.
Но на 4000 строк в двух файлах — различия как-то не тянут. В FreeBSD на всю адаптацию TCP под два базовых IP стека ушло около 200 строк. Это уже проблема, что IPv6 в Linux был сделан копипастингом и не отрефакторен.
Честно говоря не вижу проблемы для пользователя в том, что у разработчиков 4к строчек кода копипасты. 30 лет развития проекта показывают, что технический долг там вполне контролируем.
Да и не совсем копипаста там. Просто не стали городить уровни абстракции. Учитывая, что мы не ожидаем 10 разных реализаций TCP, я и как разработчик не вижу в этом проблемы. Больше похоже на исскуственный поиск дополнительных пунктов в список.
Причем интересно, что гну есть за что подколоть по делу — например разницу дистрибутивов мало описали — все эти утилиты типа ifconfig только для настроек интрефейса еще и только в текущей сессии настройки меняют. А вот если вы хотите прописать статический айпи адрес так, чтобы после перезагрузки хоста он остался, это у каждого дистрибутива делается по разному и настройки хранятся в разных файлах.
Да и не совсем копипаста там. Просто не стали городить уровни абстракции. Учитывая, что мы не ожидаем 10 разных реализаций TCP, я и как разработчик не вижу в этом проблемы. Больше похоже на исскуственный поиск дополнительных пунктов в список.
Причем интересно, что гну есть за что подколоть по делу — например разницу дистрибутивов мало описали — все эти утилиты типа ifconfig только для настроек интрефейса еще и только в текущей сессии настройки меняют. А вот если вы хотите прописать статический айпи адрес так, чтобы после перезагрузки хоста он остался, это у каждого дистрибутива делается по разному и настройки хранятся в разных файлах.
НЛО прилетело и опубликовало эту надпись здесь
То есть плох факт наличия единого способа делать что-то во время инициализации? А как хорошо? У BSD можно компоненты разными способами инициализировать в рамках одной ОС?
Мне не приходят в голову, к чему могла бы привести свобода в примере с systemd, кроме необходимости приделывать к машине все 10 разных ручек сразу, чтобы оно на разных дистрибутивах работало.
Мне не приходят в голову, к чему могла бы привести свобода в примере с systemd, кроме необходимости приделывать к машине все 10 разных ручек сразу, чтобы оно на разных дистрибутивах работало.
Как бы RedHat это про коммерцию. В systemd насильно никого не тянули. RedHat у себя внедрил и ок. Остальные внедряли просто потому что это лучше, чем sysv-init и все.
Вот тут вы, вероятно историю внедрения systemd не застали, по этому так говорите. Systemd внедрялся в принудительном порядке. Была целая история с советом в debian. И вероятно потому, что systed такой хороший некоторые дистрибутивы обратно рассматривают альтернативную возможность использовать другую систему инициализации.
Реально, с «внедряли потому, что это лучше» вы сильно маху дали. Когда внедряли это было не лучше далеко. Особенно для простых админов, которые не могли на новой системе запустить вполне себе банальные сервисы, и нужно было либо брать предыдущую версию ОС, либо проникаться замыслом поттеринга и писать самому инициализацию. Это такое себе добровольное решение. Тех, кого с этим лихорадило в то время спросить. Они бы вам в лицо плюнули бы. Ну, и были шизики, которым в кайф что-то новенькое поковырять, попереписывать, что уже прекрасно работало… в те времена только такие смотрели с пафосом в горизонт и уверяли, что, когда всё отладится в systemd, когда все разработчики адаптируются к новой систем, тогда заживём. Зажили… Но это было через боль и страдания, да и вовсе не добровольно.
Я наблюдал эту драму в прямом эфире.
И да она сильно лучше. Критики было много, но ворох костылей который она заменяла была еще хуже. Они просто привычные что вы собственно и подтверждаете.
И да я вот поддерживал сервис на нескольких системах одновременно. И вот когда завезли systemd стало возможным в сервис положить инициализацию. А раньше под каждую систему иди напиши, и у каждой свои тараканы. Так что systemd лучше того что было. А я знаком был с 4 разными системами инициализации. Нет спасибо я лучше systemd unit напишу.
ZFS, при всех плюсах, имеет минус в прожорливости по памяти, поэтому на виртуалках с небольшим количеством выделенной памяти не годится и приходится жить на UFS. Тут тоже есть засада, если хочется журналирования (а хочется его часто), то у вас не будут работать snapshots и, как следствие, нормальный бекап. Поэтому приходится сидеть в каменном веке без журнала. И на это полностью забили ввиду популярности ZFS.
Есть другие минусы, но общее ощущение порядка на FreeBSD гораздо лучше влияет на нервную систему :)
С Linux нервов у меня гораздо больше тратится. Но есть области, где он практически не заменим, например, у меня на ноутбуке.
Хороший же админ будет знать плюсы и минусы обоих систем и выбирать систему под задачу (как уже написали выше).
Есть другие минусы, но общее ощущение порядка на FreeBSD гораздо лучше влияет на нервную систему :)
С Linux нервов у меня гораздо больше тратится. Но есть области, где он практически не заменим, например, у меня на ноутбуке.
Хороший же админ будет знать плюсы и минусы обоих систем и выбирать систему под задачу (как уже написали выше).
Если под Фрю завезут Кубер, если будет работать лучше и если будет поддержка вендоров — тогда why not? Не понимаю всех этих холиваров. Сама по себе ось не имеет никакой ценности.
Берете и завозите. Вам всего лишь нужно kubelet переписать ))) что у него под капотом — контейнеризация линукс или что-то еще — уже суть менее важно.
Кстати kubelet как раз переписывать особо и не надо (он на Go, вполне соберется под bsd и сам по себе он по сути является машиной состояний), другое дело что нужно что-то, что будет запускать пейлоад (container runtime) и обеспечивать сеть (а считай во всех текущих имплементациях все неплохо так прибито к iptables).
поддерживающая зависимости между службамиэто ошибочное утверждение — на самом деле, указанные в стартовых файлах зависимости учитывается только при выборе порядка запуска служб
Ну, раз таблица сравнения по пунктам — пройдёмся аналогично. Не обязательно в том же порядке.
> Если разработчики говорят что такой-то функционал готов к промышленному использованию, то значит это так.
Но самого такого функционала значительно меньше.
> Почти всё что касается конфигурирования уровня ОС, глобального, использует 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 уже не хочется.
> Если разработчики говорят что такой-то функционал готов к промышленному использованию, то значит это так.
Но самого такого функционала значительно меньше.
> Почти всё что касается конфигурирования уровня ОС, глобального, использует 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
— 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, тут я согласен.
Я сам уже больше 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, люблю ее), но прочитав, стал относиться к написанному проще. Простите.
Вы серьезно считаете синтаксис iptables удобным? Просто сравните с сематическим синтаксисом того же packet filter:
и iptables:
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, я бы сказал, обплевался поначалу :) Но, согласитесь, по сути, prerouting и output — разные цепочки, смысл у них разный. Если бы я плотно сидел на BSD, мне было бы некомфортно. А с iptables на микротик тот же пересесть — там одно и тоже, по сути. Удобно. И никогда, хоть я и не меняю оборудование часто, не стал бы я ставить нечто вроде ufw над родными и чистыми что ipfw, что iptables. Я за чистоту в этом плане. Без доп. обвесов. А для неспециалиста что ipfw, что iptables — им одинаково надо просто где-то нарыть пример конкретных команд.
Тот же скрипт написать на iptables, нет проблем. Один раз сделал, потом везде его используешь, только правки вносить. Нет проблем. А то там firewalld, там ufw. Вот это неудобно. Я что, не здоровый человек после этого?
Тот же скрипт написать на iptables, нет проблем. Один раз сделал, потом везде его используешь, только правки вносить. Нет проблем. А то там firewalld, там ufw. Вот это неудобно. Я что, не здоровый человек после этого?
я на iptables смотрю сквозь синтаксис микротиковской роутерОС, ито голова кругом порой. Что б разобраться в packet flow идешь на их вики и смотришь зубодробильные диаграммы (https://wiki.mikrotik.com/wiki/Manual:Packet_Flow). А еще там куча сайд эффектов и конфликтных ситуаций. Ну серьезно у меня язык не поворачивается назвать это комфортной работой. Хоть в целом iptables + mangle довольно мощный инструмент. Конечно привыкнуть можно ко всему =)
Основная проблема скриптов — они сначала сбрасывают все правила, а потом все правила применяют по одному. Фу-фу-фу. В частности, весело, когда на той же машине ВПН или докер крутятся. После такой настройки и впн, и докер становятся неработоспособны. До перезапуска сервиса
del
Я всё ждал, но никто так и не спросил:
Как пропатчить KDE под FreeBSD?
:-)
Как пропатчить KDE под FreeBSD?
:-)
Почему-то не упомянули один колоссальный плюс FreeBSD, по сравнению с Linux: она никогда не страдала от 12309. Насколько слышал, это касается и всех остальных систем BSD семейства.
Один коллега находил источник этого бага — ещё в 2.1.каком-то — «оптимизация» стиля VM некоторым ломастером, который «у меня всё работает», когда у него было 2GB RAM в то время, когда остальные с трудом позволяли себе 64MB :(
Ну и до сих пор ничего не изменилось, в нескольких видах.
Я вот сегодня опять нарвался (ну и побежал лечить sysctlʼами...)
Один коллега находил источник этого бага — ещё в 2.1.каком-то — «оптимизация» стиля VM некоторым ломастером, который «у меня всё работает», когда у него было 2GB RAM в то время, когда остальные с трудом позволяли себе 64MB :(
Ну и до сих пор ничего не изменилось, в нескольких видах.
Я вот сегодня опять нарвался (ну и побежал лечить sysctlʼами...)
parted работает и с MBR и с GPT и позволяет задавать размер в процентах.
А есть какие-то плюсы для владельцев ПК? Потому что в основном все описанное в статье для простых пользователей не очень понятно и вряд-ли представляет интерес. Сейчас еще Линукс то на ПК пока ставят не часто и до сих пор бытует миф что это система «для айтишников». Про БСД думаю большинство юзверей и не слышало. Насколько я знаю есть несколько дистрибутивов на базе Фряхи которые имеют графический установщик и DE из коробки, но выглядят они не очень, даже по сравнению с Линуксом, а уж тем более с Виндой или Маком. Будут ли БСД продвигать для ПК?
КМК обычному пользователю нет особого смысла ставить БСД системы. Но вот если вы занимаетесь юникс-системам на профессиональной основе, то как минимум это будет полезно в порядке самообразования.
Какой-либо унификации документации, конфигурации, вывода информации в софте толком нет. Всюду и везде будет явно и отчётливо видно, что вот эта небольшая программа/утилита написана одним человеком, а вот эта другим. Всюду и везде разные подходы ко всему: один считает так, другой считает так.
Золотые слова. Добавлю, что ещё хуже дело обстоит с синтаксисом вызова этих самых команд и конфигурацинных файлов. Там логика своя у каждого свободного художника. И есть впечатление, что часто этот художник был нетрезв или обкурен.
FreeBSD: гораздо лучше GNU/Linux