Comments 254
Просто оставлю это здесь.
Третья важная причина заключается в том, что BSD разрабатывалась относительно небольшой организованной группой профессиональных программистов из Беркли. В то время как разработка ядра Linux велась Линусом Торвальдсом с помощью широкой и гибкой сети добровольцев раскиданных по всему миру.Ну прямо опенсурсная идиллия) Линукс то как раз «выстрелил» (в контексте статьи) именно тогда, когда в бум доткомов на него обратили внимание Ынтерпрайзы и стали вливать кучи бабла и прочих «профессиональных программистов». И это очень прекрасно, что так вышло.
upd. А вот почему так вышло и почему именно в линукс, а не в bsd, например — уже частично в статье есть ответы.
А источники… да это вроде общеизвестные факты, описанные в анналах того времени. В revolution os про это есть в том числе, там Линус и Ко воодушевлённо расписывают что вот сейчас-то с таким раскладом точно вендекапец.
Многие думают, что дистрибутив GNU/Linux и был первой open source операционной системой. Но это не так. Его опередил проект Berkeley Software Distribution, или BSD.
С одной стороны GNU/Linux была первой «free software» — свободной операционной системой (в отличие от «open source»). С другой стороны, даже BSD не была первой «open source», так как изначально почти весь софт разрабатывался в научных и образовательных целях, был свободным и никому не приходило в голову использовать лицензии.
Кому нужен кастом — собирает из портов и это куда как проще централизованно собирать и поддерживать, чем делать аналогичное что-либо из исходников на любых линуксах.
Главное для моего удобства, что было в той же FreeBSD — jails & zfs наконец-то есть и в линуксах, lxc/lxd с zfs. Без lxc/lxd было совсем тяжко.
BSD планомерно теряли каждую из сфер. Сейчас linux просто делает лучше всё — а это отражается и на рынке специалистов. Ну а дальше замкнутый круг.
Опередили меня. У некоторых есть совершенно очаровательная манера рассуждать о том, о чём они имеют, в лучшем случае, крайне слабое представление.
«Иван Михалыч, прекратите, пожалуйста, капать оловом мне на лицо!»
Все (ну ок, вне enterprise) давно уже говорят просто «сеть».
> Нет. В общем случае не быстрее. При том же самом алгоритме стека быть быстрее просто нечему.
Нет, как раз в общем среднем случае — быстрее linux. А в отдельных с несколькими если — bsd быстрее.
Если карточка intel, если cpu один и желательно интел, если драйвер под bsd для соответствующей карточки (особенно не eth) есть и нормально написан, если не нужно шарить сетевые сессии между железками, если алгоритм шифрования (применительно к VPN-сетям) реализован в BSD и умеет использовать фичи процессора (а не едет на одних только герцах) и много других если.
В итоге для сетевых задач проще взять вендорскую железку (cisco, juniper, huawei, whatever) чем нанять BSD-ника, а в LB linux впереди.
> это типа ублюдочной надстройки над iptabes под названием ufw и иже с ними?
Это типа ipset, который позволил догнать ipfw и pf на фильтровании (где *tables исторически проигрывали), ну а bpf с обвязками в целом завершит эту историю.
> $ find /usr/ports/[a-z]* -maxdepth 1 -type d | wc -l
Мир (к моему, впрочем, огромному сожалению) изменился с тех пор, когда эта цифра что-то значила.
Строчка в современном мире «Docker on FreeBSD is experimental.» на странице wiki.freebsd.org/Docker говорит всем о том, что софта под BSD нет.
> wiki.freebsd.org/bhyve
> на практике очень хорошо работает.
Оно может работать в 10 раз лучше KVM, но без понятных обвязок и инфраструктуры никто пользоваться ей не будет.
KVM победил в эпоху openstack/RHEV, docker победил в эпоху swarm/kubernetes, lxc без lxd — тот ещё мусор.
Openvz проиграл рынок тупо за счет libvirt-а — когда openvz починили свои known big issues, весь мир сидел на Xen и KVM и в ус не дул, а на VZ смотрел с недоумением «как мы этим гомном без нормальных API пользовались».
> /usr/ports/sysutils/ansible/Makefile:PORTVERSION?= 2.7.5
А что с него толку, если модулей в ансибле под bsd нет? PKG разве что, да файловые модули.
Этот порт жив только как playbook runner (только зачем, если есть tower и awx, которые, опять же, нужно запускать под linux), а как средство настройки BSD он проигрывает даже CFEngine, который вообще не фичастый.
И что сейчас в BSD вместо ironic и ему подобных?
> $ go version
Ну а в ноде уже несколько раз поднимался вопрос о прекращении поддержки BSD.
www.freebsd.org/java — здесь что-то пишут про 7-8 версии, мир едет на 11-ю.
> прежде чем писать сравнение, неплохо все таки знать каждую из систем
Честно говоря, лет 5 уже не слежу внимательно за тем, что в BSD происходит (а на opennet-е ничего особенного не пишут, даже release notes не сияют). Как перевезли «десятки тысяч серверов» (точное их количество Главный Безопасник запретил называть) с BSD на Linux, так и не следим.
Srsly, BSD смотрится в современном мире… никак. Там нет того, чем пользуются техногенные стартапы (docker, kubernetes/swarm и всё вокруг), там нет того, что нужно enterprise (поддержка за бешеные деньги, которая бегом пойдет патчить что угодно, если у вас проблема), там нет того, что необходимо энтузиастам-новичкам (большого community молодых общительных пользователей и простого старта), вокруг BSD нет устоявшейся системы (была, теперь её нет) подготовки специалистов — а значит и самих специалистов. Нет и вакансий (их число в сравнении с linux-devops/linux-SA отличается минимум на порядок).
Whatsapp был последней крупной технологической компанией, сидящей на BSD. Мигрирует на linux. А может уже.
Поверьте, я тоже не рад тому, что BSD катится в пропасть. Но факт есть факт — FreeBSD не выглядит современной ОС. В Linux (точнее, вокруг него) за 10 лет изменилось ВСЁ. Принципиально. BSD (для стороннего наблюдателя) последние 5 лет стоит на месте.
Нет, как раз в общем среднем случае — быстрее linux. А в отдельных с несколькими если — bsd быстрее.
Это вопрос как мерить. Netflix, "отчего-то", стримит через FreeBSD. Да, частный случай, но, напомню, это по оценкам 20% мирового трафика.
Или ещё один частный случай — оборудование Juniper которое, внезапно, тоже на модифицированной FreeBSD работает под именем JunOS. Какой процент мирового трафика через него прокачивается я даже воображать боюсь.
Это типа ipset, который позволил догнать ipfw и pf на фильтровании
Ну наконец-то. Пару десятков лет заняло, всего-то.
Оно может работать в 10 раз лучше KVM, но без понятных обвязок и инфраструктуры никто пользоваться ей не будет.
Оно и работает лучше QEMU/KVM, на самом деле. Да, и как пользовались, так и пользуются. И до (типа)гуёв, и теперь с ними (см. CBSD и ClonOS). И, да вот прямо в "кровавом энтерпрайзе", хотя и не маcштабов телекомовской Big 4.
docker, kubernetes
Я вот вангую закат этого всего в пользу serverless / microserver.
Поверьте, я тоже не рад тому, что BSD катится в пропасть.
А мне кажется Linux надев голубую шляпу вместо красной ;-)
Ну такое себе. Во-первых, не 20 мирового, а 30 американского, во-вторых только в кеширующих серверах (читай — только железо, стоящее в чужих стойках/ДЦ), а в третьих с 2016 года ничего про это не слышно, может и передумали. Новость была про то, что «мы готовы переводить кеши на FBSD», а не «мы перевезли все кеши на FBSD».
Для запуска приложений (в том числе и для раздачи контента для кешей) они всё так же используют linux, потому что им удобнее управлять.
> И до (типа)гуёв
Гуи уже не настолько критичны, нужны API для управления. Интерфейсы и автоматику все давно рисуют сами, это делается за неделю.
> Я вот вангую закат этого всего в пользу serverless / microserver.
Вот только под serverless лежит огромный слой инфраструктуры (в том числе и пресловутый docker, чаще всего), которого под bsd ещё не написали =( Так что и в этот уходящий паравоз запрыгнуть не успеваем.
> А мне кажется Linux надев голубую шляпу вместо красной ;-)
Linux надел на голову контейнер, а не шляпу.
о-первых, не 20 мирового, а 30 американского
15% мирового по последним данным
в третьих с 2016 года ничего про это не слышно, может и передумали
Отнюдь. Netflix, 2019: "Using #reeBSD and commodity parts, we achieve 90 Gb/s serving #TLS -encrypted connections with ~55% CPU on a 16-core 2.6-GHz CPU."
28659
С каких пор эта циферка стала что-то значить? У меня в репах 20000 собранных пакетов, а не портов, значит ли это, что в моём дистре особенно хорошая (или плохая) поддержка софта?
ansiible
Если бы под него модули были.
bhyve
А в продакшене он хоть где-нибудь есть (кроме вашего локалхоста, конечно)?
прежде чем писать сравнение, неплохо все таки знать каждую из систем
Ох, это знакомое до боли угадывание знаний собеседника по комментам на хабре.
У меня в репах 20000 собранных пакетов, а не портов
Писал уже выше. Не хотите порты — пользуйтесь пакетами. Я уже забыл когда оно появилось, настолько давно это все работает.
Ну, для кого-то и тексты книг неведомая абракадабра.
Т.е. вы так и не смогли ответить, что же значит это число. Ответ: оно обозначает число существующих портов, и с количеством софта оно лишь коррелирует, а не связано напрямую. Соответственно значит оно примерно ничего.
Где-то четверть из почти 200 корпоративных VM.
Управление через github.com/churchers/vm-bhyve
Обепечивают реальные промышленно-торговые процессы.
Приложения разные.
Неплохо. Почему именно *BSD? В чём реальные преимущества на реальных задачах кроме довольно субъективной «привычности» и «продуманности»?
Эффект Даннинга-Крюгера, пик глупости?
Угадывание квалификации собеседника по комментам на хабре.
Итого, поставил linux и забыл на несколько лет. А FreeBSD поставил и либо забыл и её ломанули через дырку в ПО, либо у тебя постоянно меняются версии ПО вне базовой системы.
zfs наконец-то есть и в линуксах
Есть хорошие шансы что скоро опять не будет. Главный по пингвинчикам её не любит, видите ли…
https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problem
Неплохо вы меня удивили, спасибо за ссылку.
И это форменный анекдот, потому что FreeBSD собирается выкинуть собственную реализацию и переезжать как раз таки на ZoL
Вы где этого вздора то понабрались?
Во-первых, ни там ни там никогда не было собственной реализации. Это адаптация и доработки реализации Sun полученные через OpenSolaris/Illumos/DelphixOS с учётом собственной специфики.
Во-вторых, то, что вы написали, невозможно по причинам из "во-первых".
И, наконец, в-третьих, речь шла об объединении наработок FreeBSD и Linux используя вместо базового репозитория DelphixOS, как это было раньше, ZoL, куда переместилась большая часть активных разработчиков ZFS.
https://lists.freebsd.org/pipermail/freebsd-fs/2018-December/027085.html
Что бинарное обновление системы за две команды, что бинарное обновление бинарных же пакетов выполняется вообще без проблем парой команд и это так же доступно уже лет десять.
Во FreeBSD это было доступно с версии 2.х если не ошибаюсь. Просто "магия" make buildworld, это магия и объяснений и рационализации не требует.
Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD. Между этими клонами довольно трудно сориентироваться не особо разбирающемуся человеку. Какой вариант ставить? Что лучше для каких-то конкретных целей? Куда бежать, если возникли проблемы? Когда у потенциального пользователя нехватка времени и нет особого желания ковыряться в деталях — он плюнет на все эти заморочки и поставит линукс.
Продолжим.
Мейнтейнеров BSD мало, учитывая, что надо мейнтейнить аж три разных дистрибутива. Среди них нет единства, нет харизматичного лидера, зато есть этакий «корпоративный подход» к решению проблем. В результате решения принимаются коллегиально — т.е. из двух зол выбирается третье, чтобы никому не было обидно.
Еще о проблемах BSD (конкретно — NetBSD) писал Чарльз Ханнум: mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
надо мейнтейнить аж три разных дистрибутиваНазвать три вообще разные операционные системы видами дистрибутивов, которые де мейнтейнить надо аж три все разом — это сильно.
Что касается терминологии — я уже давненько в линуксе, посему да, забыл тонкости. Не просветите, чем «вообще разные операционные системы», собранные на одном ядре плюс-минус патчи, отличаются от линуксовых дистрибутивов, собранных на одном ядре плюс-минус патчи?
Что касается «мейнтейнить аж все три разом» — я такого не говорил, это уже ваши додумки. Моя мысль была в том, что мейнтейнеры разбежались по конкурирующим проектам, и в результате их усилий стало не хватать.
Коллега, пожалуйста, прочитайте про FreeBSD, OpenBSD и NetBSD, это не конкуренты, это совсем разные задачи и цели. Это совсем не тоже самое, что Гента и Центось. Абсолютно.
Я не в смысле вам пытаюсь указывать что делать или не дай бог как-то побольнее подъебать, нет, я в смысле серьёзно, я вам не смогу в коротком комментарии объяснить истории или хронологии. И история BSD очень интересная, это часть всего IT мира, это история Unix в конце концов. Но мешать в один тазик эти три вообще разных операционных системы и объединять их в дистрибутивы — это совсем неправильно.
я вам не смогу в коротком комментарии объяснить истории или хронологии.
Для таких случаев есть прекрасная фраза: «так исторически сложилось». Ничего не объясняет, но звучит убедительно.
И история BSD очень интересная, это часть всего IT мира, это история Unix в конце концов.
Как и история любой другой операционной системы.
Но мешать в один тазик эти три вообще разных операционных системы и объединять их в дистрибутивы — это совсем неправильно.
Можно назвать их тремя абсолютно различными операционными системами, можно назвать их тремя пряниками. Суть моего высказывания от этого не меняется: мейнтейнеров не хватает, и в этом — одна из основных проблем BSD.
Вот где проблема выбора стоит ещё более остро!
Да, Ubuntu, Kubuntu, xubuntu и ещё куча разных -buntu — чёрт ногу сломает :)
Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD
Сразу видно линуксоида плохо понимающего "кто на ком стоял". Между ними общего в разы меньше, чем между любым клоном (вот тут это уместно слово, действительно) Linux.
Мейнтейнеров BSD мало, учитывая, что надо мейнтейнить аж три разных дистрибутива.
Ещё раз, это не дистрибутивы, а независимые операционные системы.
Резюмируя, вы б почитали по теме что-то для начала чтобы впредь не садиться в лужу.
Резюмируя, вы б почитали по теме что-то для начала чтобы впредь не садиться в лужу.
Если б от моего чтения БЗДя ожила, я б, может, всю библиотеку конгресса перечитал бы. Но — увы.
ЗЫ: Забавно: уже второй человек посылает меня «что-нибудь почитать по теме», но при этом не удосуживается дать ни единой ссылки.
Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD <...> Какой вариант ставить? <...> Когда у потенциального пользователя нехватка времени и нет особого желания ковыряться в деталях — он плюнет на все эти заморочки и поставит линукс.
лол, какой?
а сейчас что мешает BSD стать более популярной?Успешно раскрутится на уже поделенном рынке можно только выйдя с какой-то убер-киллер-фичей, отсутствующей у конкурентов.
Возможно, это следствие того, что разработчики железа, поддерживающие ОС с открытыми исходниками, предпочитали вкладываться кодом в ядро линукс, а в BSD приходилось команде разработчиков пилить большой объем самостоятельно.
Как раз хотел написать про драйверы. Во времена ядер 2.4 под них многие драйверы могли написать любители-энтузиасты, а разработчики от производителей железа могли меньше вникать в работу ядра. В FreeBSD порог вхождения был гораздо выше. Ну, в Linux до сих пор планировщик и oom killer сильно проще.
Во FreeBSD, кроме того, крайне тяготеют к фреймворкам, объединяя куски в логически стройную систему. Это и сеть с NetGraph и GEOM для хранения данных и прочее. В то же время Linux — это почти всегда промежуточное состоянии в движении из прошлого в будущее, причём очень промежуточное. Я снимаю шляпу перед всеми, кто работает над ней, но блин, помнится за попытку исправить что-то в терминалах Линус обложил ответственного за подсистему, и дело закончилось неприятно, костыль остался на месте. Во FreeBSD при этом между мажорными релизами перелопатили консоль, и при этом о жертвах и разрушениях мне лично неизвестно.
Ещё ZFS, который вполне великолепно заехала во FreeBSD, при том, что мне до сих пор кошмары снятся от эксплуатации ZFS под dkms на Debian 6, и эта лютая грызня за память в dmesg. А та часть где, ZFS не нужно ставить на 32-х битный Linux и его сносной работе на 64-х битном из-за «разницы в работе с памятью»(с). Это в более простой системе у каждой архитектуры НАСТОЛЬКО разная работа с памятью, при том что архитектуры родственны…
Не верю я в простоту Linux, вот не верю и всё.
DesktopBSD тоже был вполне дружелюбен, как у него сейчас дела не вкурсе.
Единственная гипотеза низкой популярности фрюши, которая кажется мне правдоподобной — разработка драйверов. Когда я жил на PC-BSD, единственное, что на тот момент вызывало зубную и головную боль — это поиск дров для свежего железа.
Щa TridentOS активно допиливают. Ну и как сборку для десктопа можно ещё на NomadBSD посмотреть, если лень руками всё это на FreeBSD ставить самому.
Фрюша вполне может быть красивой и удобной, по крайней мере, в сравнении с линуксом она точно не уступит.
Визарды, которые есть у линуксы для комфортной установки рабочей станции есть и во фрюше.
Управление пакетами не более проблемное, чем везде. Особенно если ты просто пользователь и не тянешь софт, что называется, прямо из под пальцев разработчика.
С оговоркой, что я просто пользователь, если вдруг чего — то в штатных пакетах не хватает, я не испытывал проблем с установкой линуксового софта из rpm. Фря прекрасно умеет исполнять линуксовую софтину «почти как родную». Не знаю, может просто везло?
Единственная большая претензия с моей стороны — и почему я все таки пересел на mint-a, года 4 тому как, это список поддерживаемого оборудования. Вафля и иксы ни как не хотели нормально работать на моем тогдашнем буке. На тот момент не оказалось, ни времени, ни настроения, разбираться, поматерился и дизертировал на линуксу.
Видно, что одна команда делает, и с пониманием процесса. ИМХО, разумеется.
SCO Group подала в суд на нескольких крупных вендоров Linux.
Во второй половине 80-х мы наверное были первыми и единственными в СССР, кто поставил на UNIX-системы. И начинали мы, помимо Xenix-аЮ c SCO, BSD еще не было. Но вот прошло 30 лет и где сейчас BSD, Linux, а SCO совсем не найдешь.
"невзлету" *BSD дистрибутивов и клонов способствовало несколько моментов.
Как уже говорилось — лицензия, которая, по сути, ничего нового не привносила. Да, можно было взять "за просто так", это было важно, но не более.
По началу всем было весело с Linux, где вопросы решались быстро, потом, заинтересовашиеся компании, поддержавшие Linux, уаилиши в нем ровно то же самое: мы себе кусочек выбъем и будем его пилить. Сами. В BSD это впринципе не получится.
Второй важный момент это адаптация на разных платформах. С этим у BSD было более-менее ок, но "соборный" способ разработки не давал нужную скорость адаптации.
Ну и последнее, конечно — адаптация для рабочих станций. О ней вообще не думали до самого конца. Да, портировались всякие оболочки, но опять же — с других проектов.
Получается, что BSD был такой "сам в себе" проект, который не учитывал процессов и чаяний индустрии (читай — внешнего мира). И это не отрицательная его сторона — это его фича.
Продукт был хорош — маркетинг провалился.
Сравните с Linux ;)
Сделайте выводы.
Page-to-disk was a fairly big thing because it was something Minix had never done. It was included in version 0.12, which was released in the first week of January 1992. Immediately, people started to compare Linux not only to Minix but to Coherent, which was a small Unix clone developed by Mark Williams Company. From the beginning, the act of adding page-to-disk caused Linux to rise above the competition.
Может это как-то повлияло)
Вас надо не минусовать, а попросту забанить в порядке сокращения общего уровня идиотизма если не глобально, то, хотя бы, на Habr.
Старые версии некоторых продуктов — следствие того, что оно пишется под Linux и портировать его от туда задача не тривиальная. Завести сырые кеды, которые на Linux устаканились совсем не сразу — самоубийство. Сколько людей пилят кеды под Linux, а сколько из них тратят время на Фрю?..
Возможно, основной причиной утраты позиций со стороны BSD является юридический вопрос а именно особенности лицензии.
Именно благодаря лицензии крупные коммерческие игроки в большинстве своем предпочли линукс. Ведь затраченные на разработку самой системы усилия не могут привести к усилению конкурентов за счет того, что те возьмут готовый результат добавят к нему свою закрытую киллер-фичу и выпустят в итоге свой закрытый продукт.
В итоге разработчики BSD остались практически без поддержки крупного бизнеса. BSD активно использовали, получая выгоду, но обратного вклада в систему со стороны бизнеса практически не было.
В то же время в код линукса бизнес вкладывался очень серьезно, оплачивая таким образом возможность пользоваться системой. Поичем вкладывался не только деньгами, спонсируя разработку, но и кодом, реализующим потребное самому бизнесу.
Да нет же. Для бизнеса куда как удобнее и выгоднее BSD, которая не обязывает возвращать собственные наработки. А предпочли они Linux во-первых, по причинам описанным в статье (юридическим, что часто недооценивается выросшей и живущей в правовом ниглизме большей частью русскоязычной аудитории), а, во-вторых, это модель разработки. Во FreeBSD и тогда и сейчас используется довольно консервативный и академический подход. Быстро внести требуемые кому-то, но слабо проработанные, изменения (принцип "херак-херак" и в продакшн) там не прокатывает.
В Linux такое везде и рядом. И сейчас тоже. Любой непредвзятый наблюдатель без труда это заметит на мало-мальски большом временном интервале.
Для бизнеса куда как удобнее и выгоднее BSD, которая не обязывает возвращать собственные наработки
Просто использовать в своем бизнесе — было удобнее и выгоднее, но это не стимулировало развитие исходной системы, поскольку бизнес вкладывался не в саму ОС, а в собственные продукты на ее основе.
А в линукс, вкладывались активно, и кодом, и деньгами, что стимулировало его развитие.
Тут соглашусь. Во FreeBSD возвращают, конечно, но сильно меньше чем могли бы.
Притянутая Netgraph из Juniper, bhyve приехавший из NetAPP. Кроме того есть не стеснительные Netflix активно пилящий подсистему хранения, Яндекс много сил вложивший в ipfw и сеть. Вроде много чего давал Yahoo. Есть возврат, и достаточно хороший.
Это всё известно. Плюс можно прибавить активизацию Intel в последние пару лет, но, всё же, это куда как меньше чем могло было бы быть.
но это не стимулировало развитие исходной системы, поскольку бизнес вкладывался не в саму ОС, а в собственные продукты на ее основе
В общем верно. Как бывший разработчик FreeBSD, могу сказать, что компании активно заимствовали код в своих разработках, но лишь малая их часть тратила силы на обратные инвестиции. А имеющиеся у CoreTeam средства распределялись только на наиболее важные, по ее мнению, разработки и конференции. Но на голом энтузиазме далеко не уедешь, поэтому имеем то, что имеем.
Во FreeBSD и тогда и сейчас используется довольно консервативный и академический подход. Быстро внести требуемые кому-то, но слабо проработанные, изменения (принцип «херак-херак» и в продакшн) там не прокатывает.
Хороший пример: freebsd перешли с CVS на SVN в 2008-м году. Линус запил GIT и перевёл на него Linux в 2005-м.
Ретрограды всегда проигрывают ньюфагам.
Ну вот именно, что централизованный подход SVN приходит к регулярным «что вы закоммитили! уберите немедленно», или «ой, скриворучил, отменяю». Я читаю src-all@ и вижу такие плачи регулярно. При прохождении через предварительный фильтр типа LKML бо́льшая часть подобного мусора отфильтровывается и не попадает в репозиторий.
Не надо так уж опускать читателей.
PS. есть еще слака и всё такое иное.
Еще одним ярким примером популярности наследия BSD является игровая приставка Sony Play Station — ее операционная система является форком FreeBSD.
Судя по лицензионному соглашению FreeBSD взята за основу и для Horizon (ОС для Nintendo Switch).
P.S. Я вот читаю хабр, и понять не могу, что здесь сейчас за аудитория. Сплошные docker/kubernetes/go и прочее. Фрилансеры-программисты на стартапах чтоли тут в основном и сидят? Я нигде ничего подобного не вижу у крупных заказчиков в инфрастуктурах, с которыми приходится работать.
P.S. Я вот читаю хабр, и понять не могу, что здесь сейчас за аудитория. Сплошные docker/kubernetes/go и прочее. Фрилансеры-программисты на стартапах чтоли тут в основном и сидят?
Вон ниже пишут, что мегафон уже мигранул. Мелкие и средние заказчики используют докер и кубер только так.
Я достаточно много копался в ядре и libc FreeBSD 3,4,5 и, иногда, заглядывал в ядро Linux. Код FreeBSD мне нравился больше. Но качество кода редко заметно влияет на успех или неудачу проекта.
Так-то они конкуренты, но благодаря лицензии сотрудничают.
Я не программист, а системный инженер, админ, и тот еще ретроград. Я ничего плохого не имею против линукса, даже наоборот.
Я настолько отстал, что глядя на то, как сейчас устроена разработка, совершенно не понимаю как это устроено. Получается DevOps вытеснили системных инженеров/админов, и сейчас вместо build-фермы и testing-фермы (даже на ВМ) тупо виртуалки, а в них докеры?
Лично я выбираю ОС простым способом:
— Если это open-source, никто кроме меня это админить не будет, этот софт есть в портах, то это FreeBSD, однозначно, и никак иначе.
— Если требуется БД Oracle, это железо от Oracle и Solaris на SPARC, и никак иначе.
— Если требуется БД DB2, это железо от IBM и AIX на PowerPC, и никак иначе.
— Во всех остальных случаях, это любое приличное железо и Red Hat / CentOS.
— Про Windows оставим без комментариев :) Тут итак всё ясно.
Да прекратите уже бредить. По объёму доступного софта и его свежести FreeBSD всегда была в лидерах, а уж удобнее портов и представить что-то сложно. Хотите ставьте из них, хотите из готовых пакетов собранных из тех же портов, хотите свой репо разворачивайте со своими опциями используя poudriere (причем можно и для другой версии).
Total:
AUR (44909)
nixpkgs unstable (43125)
…
FreeBSD Ports (32313)
Newest:
nixpkgs unstable (21394)
FreeBSD Ports (16497)
(Справедливости ради, оба счётчика сломаны :P)
Там гранулярность разная, так что напрямую сравнивать некорректно. Где вот FreeBSD один порт, в репозитории Linux может быть три — пять собранных с разными опциями или побитые на мелкие пакеты.
Если интересно — можете озаботиться, проверить.
И чтобы кто-то из крупных заказчиков пришел и сказал, «о боги, у нас там kubernetes упал», никогда не было, да и не используют они такое.
Опять же habr.com/post/435910/#comment_19613146
kubernetes упалего нужно ещё поднять и как-то интегрировать в сеть компании, протащив мимо СИБ и объяснив инфраструктурщикам, сетевикам, базерам и прочее как с этим теперь жить. Если всё готово к kubernetes — всё ОК. Шаг влево, шаг вправо — и всё, уже не так всё хорошо и безоблачно.
Не от хорошей жизни они перекатиться с AIX на Linux.
И мне кажется, что это общий тренд перехода на Линуксы
Ещё не Linux но уже на пути.реально очень рад за бзду, я вообще за разнообразие
И он тогда наглядно изображал — куда (и почему) шла FreeBSD. И нет, это была не лицензия.
Если в трех словах — это темпы развития, общий вектор, и коммунити.
Первых два очень хорошо описывал на примерах стандартного API (libc/libc_r) и реализации threads (емнип, в линуксе аж две либы было на тот момент работы с потоками, а фря который год выстраивала монументальный проект с моделью ниток с фиберами N:K, который умер не родившись. Как потом злословили — потому что в линуксе придумали в итоге epoll, ага, с третьей попытки. Но смысла в зеленых нитках не стало).
А третий компонент лучше всего проиллюстрировал в примерно то же время Алекс Кошмарь, в своем фирменном стиле обложив матом «поделие финского студента», но опять же фирменно с цифрами и примерами. Что характерно, один из кернельдевелоперов той поры, легендарный ANK, не просто связался с Алексом прямо в фидо, но и получил доступ к хосту с репортом, и решил таки проблему внезапной паники линуксового ядра на запредельных сетевых потоках (а, да, потом опять весь стек переписали). А в freebsd с багрепортами было мнэ… не очень.
А тут — лицензия уиноуатая, и не виноват ли снова межделмаш?
В стародавние времена был эпичный тред на ixbt: вот он, голубчик.
Ну, вот для примера, 2001 год.
VB> Так на ней и положено падать — она работает согласно ценнику. Во
VB> Фри-2.2.8 — не работало вообще. В 3.3 — работало «почти» (то есть
VB> падало только иногда, но регулярно). Фри 4 — вроде как все работает.
VB> А в 5-ой они обещали нормальные (то есть кернельные) треды сделать.
VB> Hу так делают. Может, через год заработает. А может и ни.
Это про треды во FreeBSD.
А в линуксе NPTL тогда победил ;-)
Первых два очень хорошо описывал на примерах стандартного API (libc/libc_r) и реализации threads (емнип, в линуксе аж две либы было на тот момент работы с потоками, а фря который год выстраивала монументальный проект с моделью ниток с фиберами N:K, который умер не родившись.Память вам изменяет — их было три: LinuxThreads, NGPT и, наконец, NPTL.
NGPT был как раз N:K — но исследования показали, что сложности это добавляет изрядно, а выигрыш — ограничен.
Память вам изменяет — их было три: LinuxThreads, NGPT и, наконец, NPTL.
Точно, про NGPT я и запамятовал. Было и такое, да…
NGPT был как раз N:K — но исследования показали, что сложности это добавляет изрядно, а выигрыш — ограничен.
Особенно если учесть, что выигрыш получался в основном при рисовании Finite State Machine — а в таком стиле программировать дело нелегкое ;-) Победил подход «херак-херак и в thread pool». Что как бы уже было очевидно в 1998м году.
Правда в 1998м у апологетов FSM фигурно лобзиком — был неоспоримый аргумент в виде «в тредах очень накладно висеть в listen()/accept()». При появлении нового соединения будились все «тыщи» ниток, чтобы только одна продолжила работу. Но горячий финский парень этот вопрос решил, повторив подход kqueue из FreeBSD ;-)
Я для своего сервачка OpenBSD использовал. Но боль от отсутствия поддержки UTF была. Правда потом и сервака не стало. А дальше я плотно сел на Debian ибо не хотел сильно мучиться с настройками web сервера для себя.
Ну, или мне просто так не везло (что тоже возможно).
Я уже не говорю о том, что гипервизоры и хранилки не всегда могут понять, какая часть диска в виртуалке занято полезными данными, нужно что-то придумывать.
Хорошая система, как-то проскочившая мимо массовости (и это с таким-то вдумчивым развитием!), от чего сегодня стала если не совсем экзотикой, но хотя бы редкостью.
Впрочем, голый он и сейчас укладывается в сотню.
Спасибо за статью, столько милоты накатило )))
работало годами без сбоев и тормозов
Ну вот это как раз не повод для сравнения с *nix-ами: даже нормально настроенная Убунта вряд ли будет тормозить и сбоить.
Но, должен сказать, есть какой-то юмор в том, что во времена, когда для пересборки ядра фряхи требовалось часа три, они находились, а сегодня, когда то же закончится минут за 15-20, мы ругаемся на тормоза пересборки. Наверное, еще и взгляд на мир меняется, взрослеем? *смайлик*
… даже нормально настроенная Убунта вряд ли будет тормозить и сбоить.
ню-ню, мсье Аптимизт..
Но, должен сказать, есть какой-то юмор в том, что во времена, когда для пересборки ядра фряхи требовалось часа три
не надо ля-ля ради красного словца: никогда за >20 лет моей памяти ядро не собиралось три часа.
сейчас на древнющем одноядерном ноуте (Samsung R60) ядро FreeBSD 12.0 штатным clang'ом собирается чуть меньше часа. и да — на zfs :)
Ну и три часа на сборку ядра я никогда не тратил, несколько минут и все готово.
А насчет инструмента (FreeBSD vs Linux) — очень редко бывает, что строить можно только на чем-то одном, а другое по показаниям не подходит. Тот же шлюз поднять можно хоть на калькуляторе, главное не «на чем», а «чем» (я про прямизну рук) и «с чем в голове». Да вы о том же: действительно, если есть понимание «особенностей» там и там — то все в порядке!
Я отлично помню как в первой половине 2000-х, времена расцвета LAMP, большая часть рунета хостилась на FreeBSD. Все рассказывали про то как круто собирать пакеты, какие они оптимизированные, а Linux на тот момент не умел даже файлы больше 2GB на Ext2.
Потом корпорации вложились в Linux, появилась журналируемая файловая система — Ext4, ResierFS, а главное, после чего все начали переходить на Linux — это балансировка тредов по процессорам. MySQL, поднятый на FreeBSD4 не мог занимать больше одного процессора, а на серверах в то время были 2CPU.
Потом вышла FreeBSD5, и наш админ по прежнему плевался на их треды, а Intel уже выпустила Pentium4 и уже было 4 вычислительных потока на рядовом сервере.
Ну и удобство обновления Linux в какой-то момент сильно превосходило всю эту возню с пакетами.
Финальный гвоздь в FreeBSD прозвучал лет 10 назад, когда CTO какого-то крупняка написал статью вида «идите в зад со своим FreeBSD, мы мигрируем на Debian, мы хотим работать и приходить домой а не трахаться с системой». Причем я знал его лично — в начале 2000х он агитировал за FreeBSD против Linux.
BSD означает Berlkey Software Distribution. Дело в том, что хотя Bell Labs и не могли продавать Unix, но все права на его тексты оставались у них. Билл Джой из Беркли (впоследствии, один из основателей Sun) начал формировать и рассылать ленты с патчами к оригинальному тексту, а также с собственными разработками (csh и vi, хе-хе!). После ухода Джоя его работу взял на себя Маршалл МакКузик. До 1989 года код BSD не представлял из себя отдельную ОС, а для его работы нужно было купить лицензию Unix. Выпущенный в 1991 году Net/2 был почти самостоятельной ОС, нужно было только написать заново 6 файлов. Это сделал Билл Джолиц, выложивший 386bsd на ftp в январе 1992 года. Но Джолиц не мог заниматься поддержкой, поэтому вскоре образовались две группы пользователей — NetBSD (версия 0.8 — аррель 1993) и FreeBSD (версия 1.0 — декабрь 1993).
Для сравнения: Debian 1.0 — август 1993, Slackware 1.0 — июль 1993. Еще до них в 1992 году были выпущены SLS и коммерческий Yggdrasil. Так что если говорить о гандикапе по времени, он скорее был у линукса. Но до начала 21 века и *BSD, и Linux развивались примерно одинаково, причем решения *BSD были зачастую интереснее.
А потом пришел Большой Капитал…
надо карту интел, материнку интел, видеокарту специальную из спец списка по заказу.
потом пара суток настроек и компиляция и у вас сервер… в котором еще надо убирать мелкие баги.
в то же время opensuse(centos не было еще) — на любую материнку из наличных за 30 минут.
бинарные порты? да были, но на 386, а opensuse была на i586, что давало приличную разницу в скорости.
Да, сейчас в freebsd поддержка железа получше, но поезд уже ушел.
*BSD идёт более правильным путём, чем *Linux хотя бы потому, что не превращает OS в kernel+systemd...
по-моему, я предельно ясно выразился, что *BSD в более правильном направлении развивается потому, что там нет системды :)
а линух прикончит системда, когда оно "срастётся" с кёрнелом и гномом в [практически] монолит: отсутствие вариантов — плохо для системы.
и да, я знаю о слухах, что во FreeBSD тоже рассматривается вариант разработки launchd. но как это уже было неоднократно, резкого и безальтернативного перехода a-la linux (а теперь — капец), полагаю, не будет: хочется верить, что мудрости у дядек из беркли больше, чем у горячего финского студента...
Написание постоянно работающих служб ешё никогда не было настолько простым и приятным.
Очень часто бывает так, что проект с офигенными идеями оказывается с ужасной реализацией, и все плюются и ненавидят. Systemd оказался в обратной ситуации — омерзительная идея, от которой все плюются и ненавидят, но реализация, к которой нет никаких вопросов или нареканий. В силу того, что хорошим софтом является софт с хорошей реализацией...
он просто не столкнулся или поленился искать...
Disclaimer: вообще я, конечно, против systemd, оно очень anti-unix; зачастую его достоинства выливаются, например, в необходимость городить уродства вроде
ExecStartPre=/bin/sh -c "/usr/bin/systemctl set-environment JVM_OPTIONS=\"$(tr -s '[:cntrl:]' ' ' < jvm.options)\""
, но в целом юнит-файлы выглядят декларативнее и понятнее, чем привычные rc-скрипты, а их сопровождение и отладку можно доверить даже начинающему инженеру.К сожалению, у него столько всего есть, что я удивлен как это так до сих пор нет дистрибутива SystemdOS.
Но вот если бы systemd не тянул под себя всю функциональность, до которой мог добраться, а занимался бы только upstart'ом демонов, то все бы ему были благодарны.И тогда — он был бы всего лишь ещё одним 100500м запускальщиком процессов.
К сожалению, у него столько всего есть, что я удивлен как это так до сих пор нет дистрибутива SystemdOS.Есть много вещей, которые для этого нужно в него добавить. Сейчас же systemd, фактически, является аналогом того, в мире *BSD традиционно называлось «base system»: некий набор «базовых утилит», которые в системе всегда есть и на присутствие которых можно положиться. Только ограниченным и урезанным: в «base system» *BSD, как правило, входят libc и shell, cpio и tar и много других утилит, которые, пока что, частью systemd не являются.
Так как systemd, фактически, является «возвращением к истокам» и приносит в мир GNU/Linux подход Unix, которым всегда пользовались, в том числе, и *BSD, то возникает вопрос: а чего ещё-то нужно включить в systemd, чтобы вам понравилось? Ядро? Shell? Или что?
И тогда — он был бы всего лишь ещё одним 100500м запускальщиком процессов.
А что в этом плохого? Делай свое дело качественно — unixway.
Сейчас же systemd, фактически, является аналогом того, в мире *BSD традиционно называлось «base system»: некий набор «базовых утилит», которые в системе всегда есть и на присутствие которых можно положиться.
И никто этого не просил.
Так как systemd, фактически, является «возвращением к истокам» и приносит в мир GNU/Linux подход Unix
Вот совсем наоборот, категоически нет! Да, буду слит, но вы, товарищ, наркоман.
Вот совсем наоборот, категоически нет! Да, буду слит, но вы, товарищ, наркоман.То есть человек, который считает, что название unixway никак не может быть присвоено подходу, которым UNIX никогда не пользовался — наркоман?
А что в этом плохого? Делай свое дело качественно — unixway.А где systemd этот принцип нарушает? У него в репозитории много отдельных программ и каждая из них — весьма несложна. Вполне себе unixway.
То извращение, которое под «unixway» понимают людители GNU/Linux скорее уж можно назвать «GNU way» (как GNU, как известно, «is Not Unix»): кажется именно проект GNU начал выпускать отдельные компоненты Unix-подобной системы, которые могли интегрироваться с компонентами, разработанными другими людьми.
Unix же всегда разрабатывался ровно так как systemd: набор мелких улититок в одном репозитории, работащих совместно. Системную библиотеку от OpenBSD вы не сможете использовать на NetBSD и утилиты от FreeBSD на NetBSD также не запустятся.
То есть человек, который считает, что название unixway никак не может быть присвоено подходу, которым UNIX никогда не пользовался — наркоман?
Ну не совсем так. Вы таки что-то путаете. Наркоман этот тот, кто unixway'ю приписывает движения по типу «делай как можно больше» вместо «делай одно, но отлично».
Ну и все таки скорее всего да. Если всю жизнь хз сколько лет говорили, что unixway это одни принципы, а вы сейчас врываетесь и обижаетесь на то, что я вас называю наркоманом за признание unixway'ем других… Вы наркоман.
А где systemd этот принцип нарушает?
Прямо по пунктам расписать? Давайте я ограничусь следующим (кроме апстарта):
- Монтирование файловый систем
- Бинарное логирование
- Работа с памятью
- Изолирование процессов
- Работа с сетью сокетами
- Подключенные устройства
- Файловая система
Еще хз зачем ему вебсервер и еще тонна приблуд. Где тут unixway?
Еще хз зачем ему вебсервер и еще тонна приблуд. Где тут unixway?Unixway тут в том, что всё вами вышеперечисленное делает не одна утилита, а несколько десятков. Каждая из которых отвечает за что-то своё.
SysVinit, если вспомните, тоже должен был заниматься управлением процессами (про уровни выполнения не забыли, нет?) — вот только делал он это настолько отвратительно, что в 99% случаев из 100 вместо них использовались разного рода костыли.
Наркоман этот тот, кто unixway'ю приписывает движения по типу «делай как можно больше» вместо «делай одно, но отлично».И что ж такого «отличного» умел делать SysVinit? Запускал процессы и всё (ибо уже с их остановкой у него были баааалшые проблемы — из-за чего и началась в дистрибутивах GNU/Linux вся эта каша в /etc/init.d). Это скорее анти-unixway: делай что-то… хреново, а когда кто-то жалуется — забивай болт.
/sbin/init запускает только getty и shЭто — печальная реальность прямо перед переходом на systemd. В прошлом веке, когда SysVinit был молод, он запускал и Xы и другие демоны. Однако возникали проблемы с остановом (SysVinit останавливал «по запросу» основной сервер, а вспомогательные процессы выживали и «отравляли жизнь»). В результате от использования его в такой роли отказались, а реальная работа была переложена на плечи кучи bash-скриптов.
далее сценарии запуска для каждой из.
И да — договориться о каком-то порядке в этих скриптах было невозможно ибо каждый дистрибутив гордился тем, что именно они сделали «правильные скрипты».
Что же касается «собора и базара» — то уже очень хорошо видно, что работает только нечто среднее: если над системой работает горстка разработчиков и они всё делают сами (подход *BSD) — то вы безнадёжно отстаёте, если у вас есть сотни форков, но нет никого, кто бы отбирал самое важно — то «обычный пользователь» с вашими поделками работать не будет, так как просто в них запутается (это как раз долгое время мешало продвижению Linux на desktop), чтобы добиться успеха нужны сотни/тысячи независимых программистов — кто-то, кто будет собирать их в «генеральную версию».
Блин, откуда этот миф о закрытости _публичных_ проектов?Потому что это не миф. Огромное количество вещей, которые есть в GNU/Linux изначально были внутренними проектами, которые открыли из-за требований лицензии и интегировали — часто вопреки желаниям первоначальных разработчиков. В *BSD чуть ли не единственная вещь, с которой так поступили — это ZFS.
Где вы это вычитали?Я это не вичитал, я это сам, лично набюдал. Изменение runlevel с такого, где есть X'ы на такой, где их нет — останавливает сами X'ы, но не останавливает порождённые ими процессы. Починили, как обычно, костылём в виде bash-скрипта.
Количество процессов в сервисе = CPU numberИ вот в этой-то библиотеке как раз и проблема.
Скрипт 15 строк + /etc/rc.subr shell библиотека
Наверное проблема линуксо-строительства в другом.Проблем было, собственно, два:
1. Даже после многих лет пристраивания костылей к костылям библиотеки для работы с демонами под SysVInit работали плохо.
2. Главное — они во всех дистрибутивах были разными, что обозначало что «из коробки» не поддерживался ни один.
systemd полностью решил вторую проблему — и на 99% первую.
В мире *BSD на вторую проблему забили большой болт (можно ваши скрипты использовать, чтобы работать с демонами в OpenBSD или NetBSD и прочим зоопарком? а — да: нинужнааа… понял), а первую… ну им как раз удалось её решить лучше, чем линуксоидам в силу того, что система разрабатывается как единое целое… подход, который унаследовал от UNIX и *BSD как раз systemd…
К сожалению, не все сервисы умеют правильно хендлить своих потомков…
Я уж не говорю о кейсах, когда нужно обеспечить порядок запуска.
Например, мы хотим сначала подмонтировать какой-либо каталог и ТОЛЬКО после этого запустить сервис (т.к. его данные лежат в этой точке монтирования). И в линуксе с SysV начинается геморрой. Точка монтирования отвалилась — как перезапустить сервис гарантированно без дополнительных обвязок. Или куча других интересных вещей.
Я уж не говорю про то, что у меня был кейс, когда init-скрипт думал, что сервис запущен, т.к. существовал pid файл, но фактически под этим pid'ом был запущен вообще другой процесс. Немного вмешательства ручек ops и полетели дальше… но осадочек очень неприятный.
>В мире *BSD на вторую проблему забили большой болтИз первых рук, однако. Darwin, FreeBSD, NetBSD, OpenBSD — у них у всех разные (хотя у последних трёх и похожие) системы запуска… при этом только у первой — сколько-то осмысленное количество установок (но не на серверах).
Откуда эта информация?
Если некоторые демоны некорретно отрабатывают SIGTERM/USR12/INT/STOP, то на это есть таки злобный SIGKILL.Вот только для того, чтобы найти процессы, которым нужно послать «злобный SIGKILL» — нужно провести целое расследование… которые соответствующие bash-скрипты и делают… но не всегда успешно.
В норме разработчие должен минимум озаботиться корректной остановновкой процесса по сигналу TERM со всеми необходимыми приседаниями, и обработкой иных сигналов. Это же как «отче наш».Для разработчика, для которого основная платформа — Windows? В гробу он видал и TERM и KILL. И вообще — если платформа приносит 0.5% продаж, то на её поддержку можно выделить один день. В год. Ну хорошо: от щедрот — два. Это же как «отче наш».
А тут вы с тоннами правил, док и прочего.
Соответственно это можно либо учитывать, либо бороться с ветряными мельницами. systemd — это попытка это учесть.
Очень многие сидят на маках.
Или думаете, что они все хипстеры чертовы?
Разработчиков под что простите?Подо что угодно.
Очень многие сидят на маках.Разрабочики — нет. Они могут разрабатывать подо что угодно, но сидеть они будут под Windows — и, скорее всего, в Visual Studio.
Или думаете, что они все хипстеры чертовы?Художники, дизайнеры — да, там Маков много. Хотя не уверен, что большинство. Но разработчики — сидят под Windows.
Да, спасибо за то, что заставили пошевелиться и посмотреть. Действительно: времена, когда 90% разработчиков сидели под Windows уже прошли. Сейчас — речь скорее идёт о 50%, однако если учесть, что 35% испольщуют VS Code и 34% Visual Studio, то понятно, что даже убежавшие на Mac «хипстеры» по прежнему имеют представления о внутреннем устройстве Windows больше, чем о том Mac'е, на котором они работают.
А уж о том, что там творится на FreeBSD — они не имеют вообще никакого представления… кроме тех 0.2%, которые на ней работают, конечно.
Вот есть ещё biased опрос www.jetbrains.com/research/devecosystem-2018
Маков реально много
Написать обход по дереву процессов с передачей сигналов term/kill и контролем процессов это задание для студента.
То есть ты считаешь, что не было никого, кто мог бы написать элементарный, на 2 страницы кода со всеми приседаниеми, контроль/управление процессами в /sbin/init?
Я считаю, что есть люди, которые это могут сделать, но, как выше правильно было замечено:
- Квалификация людей, работающих на (в) опен-сурс — совершенно различная. Есть и криворукие, есть и прям профессионалы и гении своего дела. Чего говорить про инит-скрипты, если для многих вендоров запаковать свой софт корректно в пакеты представляет невыполнимую задачу???
- По init. А Вы не рассматривали, что решение указанной проблемы не является нужным? Ну, тем более, что вроде как уже продавили systemd во все дистрибутивы?
- Ну, и, выше правильно заметили, что каждый дистрибутив во времена init предлагал СВОЙ «самый правильный» способ написания инициализационных скриптов, что тоже не добавляло радости всем.
… на мой программерский взгляд, systemd — это одно из лучших, что случилось с Linux за последние 10 лет.
очевидно же, что ваш программерский взгляд, к сожалению, ограничился исключительно поделками шляпы (и тех, кого она продавила).
позволю себе озвучить мнение, что система старта FreeBSD божественна своей простотой и при этом гибкостью.
как и система портов + pkg, кстати.
Написание постоянно работающих служб ешё никогда не было настолько простым и приятным.
да, да.
особенно приятно когда эти службы начинают просто драться между собой :)
по-моему, я предельно ясно выразился, что *BSD в более правильном направлении развивается потому, что там нет системды :)Вы высказались непонятно потому, что systemd — это, фактически, перенос подхода *BSD, где есть «base system», собираемая из одного репозитория, в мир Linux.
Сосственно ровно так Unix всегда и был сделан — со времён его изобретения в 70х годах. Один общий репозиторий, где живёт вся система — init, cron и прочее добро. И работать совместно могут только программы из этого репозитория, «смешения пакетов» для базовой системы не предусмотрено. Большое отличие, собственно, ровно одно: в *BSD (как и вообще в UNIX) ядро — часто того же репозитория.
но как это уже было неоднократно, резкого и безальтернативного перехода a-la linux (а теперь — капец), полагаю, не будет: хочется верить, что мудрости у дядек из беркли больше, чем у горячего финского студента...Наоборот: ровно «резкий и безальтернативный переход» — это как раз фирменная фишка в UNIX и *BSD (особенно этим OpenBSD славится). Это как раз в мире Linux (до появления systemd) «хвост по частям» отрезали.
линух прикончит системда, когда оно «срастётся» с кёрнелом и гномом в [практически] монолит
Андроид и есть сросшийся монолит на основе Убунту, но он жив.
и не снапшотами едиными… xfs — это вообще каменный век в купе с ext*, jfs, ntfs, hpfs… я вот на zfs ~10 лет храню данные своих серверов и рабочих станций (zfs volumes only). а вы btrfs так используетете?
вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.
вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.«Перестать об этом задумываться» нельзя как минимум до тех пор, пока она из коробки на большинстве дистрибутивов не будет доступна. А посылок к тому, чтобы это случилось — как не было, так и нет.
А то есть любители на ней RAID6 поднять, а потом плакать…
У меня на ней основная система, с которой эти строки пишу, стоит.
ну, авантюризм, в общем случае, присущ некоторому количеству человеков.
остаётся только пожелать удачи вам и вашим данным :)
А то есть любители на ней RAID6 поднять, а потом плакать…
а как без RAID данные будут в сохранности?
А как же бекапы? RAID решает одну задачу, бекапы — другие. И желательно бекапы куда-то в другое место.
а как без RAID данные будут в сохранности?Так же, как в случае с RAID: ваши данные будут в сохранности если вы делаете бекапы и не будут — если не делаете.
Никакой RAID не спрасёт вас от ошибки в контроллере, которая приведёт к тому, что один бит из примерно каждых 10 мегабайт случайным образом флипается при записи на диск. Пронаблюдав как-то такой эффект на одной машинке «вживую» я и отказался от RAID — раз и навсегда. Ибо не нужен мне этот «эффект плацебо», убеждащий меня в том, что я могу «задёшево» сохранить-таки свои данные. Не могу.
Пронаблюдав как-то такой эффект на одной машинке «вживую», я и отказался от RAID — раз и навсегда.А, теперь понятно. Только почему-то вместо того, чтобы просто отказаться от аппаратных рейдов (глючных контроллеров, проприетарных, писанных левой ногой темными индийскими ночами прошивок и т.д.), вы решили отказаться от идеи избыточного массива вообще.
RAID — это пережиток тех времён, когда компьютеры разнимали целую комнату, и представить, что у кого-то их будет десяток, было нельзя.Когда компьютеры занимали (?) целую комнату, стоимость накопителей была, боюсь, такова, что говорить о Redundant Array of Inexpensive Disks было несколько преждевременно. :-)
Сейчас же, когда [...] у вас компьютеров много — то вы должны быть готовы к тому, что их часть будет время от времени умирать — вместе со всеми данными, а если вы к этому уже подготовились, то зачем вам, я извиняюсь, RAID?Например затем, чтобы имея дома локальный storage на пару десятков терабайт, спокойно заменить наживую, не прерывая работы, один (или несколько одновременно) вышедших из строя дисков.
Когда компьютеры занимали (?) целую комнату, стоимость накопителей была, боюсь, такова, что говорить о Redundant Array of Inexpensive Disks было несколько преждевременно. :-)Термин появился в 80е, да. Но технология в 70е уже использовалась — как минимум RAID1
Только почему-то вместо того, чтобы просто отказаться от аппаратных рейдов (глючных контроллеров, проприетарных, писанных левой ногой темными индийскими ночами прошивок и т.д.), вы решили отказаться от идеи избыточного массива вообще.Потому что принципиально это ничего не меняет. При использовании RAID у вас, на самом деле, одна точка отказа. Неважно — это контроллер, процессор или операционка. То есть RAID — это не замена резервному копированию. В лучшем случае — экономия времени на восстановление при сбое.
Но если учесть, что современные системы вполне могут работать годами без сбоев — то это дурная экономия.
Например затем, чтобы имея дома локальный storage на пару десятков терабайт, спокойно заменить наживую, не прерывая работы, один (или несколько одновременно) вышедших из строя дисковА зачем вам несколько десятков терабайт дома и куда вы бекапите с них данные???
Просто интересно — чем нужно заниматься, чтобы в этом возникла потребность…
В идеале — вы просто скармливаете ZFS сырые диски. Проблема на новых FreeBSD [...] приходится накатывать ZFS поверх GPT-лейблов.Нет никакой проблемы накатывать ZFS поверх GPT-лейблов:
The reason the Solaris docs recommend full-disks for ZFS is due to their disk caching sub-system only enabling the write-cache on drives when passed a raw disk. If you use a partition, then Solaris disables the write-cache on the disk, severely impacting performance. FreeBSD's GEOM system has always allowed the drive's write-cache to be enabled regardless of how the drive is accessed, which made this a non-issue on FreeBSD.Это наоборот правильнее: можно оптимально выровнять разделы в зависимости от размера сектора, добавить все нужные сервисные efi и свопы, правильно и уникально их пометить, чтобы массив гарантированно собрался на любом оборудовании, и пр.
Основная — в смысле — ноутбук (или рабочий компьютер-десктоп)? Ну, у меня тоже. И что? OpenSUSE по умолчанию на btrfs ставится. В этом есть и плюсы, и минусы.
Минусы — например, нужно следить за местом при zypper in
чего-то угодно, т.к. создается снапшот. И место тает на глазах.
Из плюсов — работает быстро и относительно стабильно.
Но тащить это на продакшен в сервера… ну, такое.
Но тащить это на продакшен в сервера… ну, такое.А в production требования к фс как раз ниже, чем на десктопе. В ext4 режим работы без журнала существует именно для гугловых серверов, если вы не знали.
Потому что если у вас не налажен процесс восстановления при внезапном умирании сервера (ну там пожар, наводнение и просто «пробой» в блоке питания — неважно) — то вы таки сильно рискуете.
А если налажен — то нафига вам журналирование, RAID и всё прочее?
Потому что если у вас не налажен процесс восстановления при внезапном умирании сервера (ну там пожар, наводнение и просто «пробой» в блоке питания — неважно) — то вы таки сильно рискуете.
Я полностью поддерживаю. Это тем более реализуется грамотной архитектурой приклада.
В ext4 режим работы без журнала существует именно для гугловых серверов, если вы не знали.
нет, не знал :-) И какую цель они достигают таким образом? Быстродействие ФС на значение 100%?
Просто в случае работы без журнала и с не очень продакшен ФС типа btrfs мне лично стремно — даже не потому что будет отказ, а не будут ли превращены данные в фарш, причем я об этом узнаю не сразу, а когда-нибудь потом?
А если налажен — то нафига вам журналирование, RAID и всё прочее?
Обеспечение низкого RTO.
Но вообще — да, учитывая, что резервирование есть и на других уровнях (ну, например, ВМ работают поверх какого-то реплицированного стореджа) мы реально греем воздух лишними «защитами»
нет, не знал :-) И какую цель они достигают таким образом? Быстродействие ФС на значение 100%?Да. Собственно этот режим там появился, когда встал вопрос «что делать с ext2». Всем казалось, что про неё все забыли… а оказалось, что Гугл её на серверах использовал — потому что бессмысленно использовать ext3 как основу для GFS.
В ext4 добавили режим «без журнала» и всем стало хорошо.
Просто в случае работы без журнала и с не очень продакшен ФС типа btrfs мне лично стремно — даже не потому что будет отказ, а не будут ли превращены данные в фарш, причем я об этом узнаю не сразу, а когда-нибудь потом?А вы от этого никогда не застрахованы. Достаточно чуть-чуть глючного контроллера дисков — и всё, ваши данные будут превращены «в фарш» без всякого участия файловой системы и операционки.
Спасают только контрольные суммы — и то до некоторой степени (процессор ведь тоже может глючить).
А что для вас «вышла из беты»? У меня на ней основная система, с которой эти строки пишу, стоит.Ох… Мы её иногда вспоминаем в профильной теме на iXBT, народ делится впечатлениями. Ну, знаете, такое (и это пишет человек, btrfs и линуксу в целом симпатизирующий).
А то есть любители на ней RAID6 поднять, а потом плакать…Да имхо ничего не надо на ней поднимать. :-) Есть стабильная, фичастая и всё умеющая ZFS. Хочется
Впрочем, если бы она работала, одно реальное преимущество перед ZFS у неё вроде как есть: можно добавлять диски в уже созданный массив RAID5/6.Реальное преимущество у неё одно: одна работает и «каши не просит» — до тех пор пока вы не начинаете использовать вещи, которые на официальном сайте помечены как неработающие.
RAID5/6 ни в одной версии btrfs стабильным объявлен не был — потому я никак не могу понять откуда такое маниакальное желание таки его включить и поиметь неприятностей на свою задницу.
Без бекапов всё равно жить нельзя, а надёжность современных SSD такова, что смысла в RAID я сейчас не вижу нигде — ни на рабочей станции, ни, тем более, в production.
RAID — это пережиток тех времён, когда компьютеры разнимали целую комнату и представить что у кого-то их будет десяток было нельзя. Сейчас же, когда в одном датацентре у вас могут быть десятки тысяч компьютеров смысла в нём никакого: если у вас компьютеров много — то вы должны быть готовы к тому, что их часть будет время от времени умирать целиком — вместе со всеми данными, а если вы к этому уже подготовились, то зачем вам, я извиняюсь, RAID?
RAID — это пережиток тех времён, когда компьютеры разнимали целую комнату и представить что у кого-то их будет десяток было нельзя. Сейчас же, когда в одном датацентре у вас могут быть десятки тысяч компьютеров смысла в нём никакого: если у вас компьютеров много — то вы должны быть готовы к тому, что их часть будет время от времени умирать целиком — вместе со всеми данными, а если вы к этому уже подготовились, то зачем вам, я извиняюсь, RAID?
как вариант — legacy enterprise приложения, которые спроектированы именно для работы в режиме сингл инстанса. И которые не умеют горизонтально скейлиться, а только вертикально…
как вариант — legacy enterprise приложения, которые спроектированы именно для работы в режиме сингл инстанса. И которые не умеют горизонтально скейлиться, а только вертикально…В этом случае вам можно только посочувствать… и посоветовать обратиться к IBM: z/OS — это как раз для вас. Но причём тут FreeBSD или Linux?
Про RAID вообще эпично, во-первых, то, что вы лично его нигде не видите, это ваши трудности, я вот постоянно сталкиваюсь с рейдами того или иного вида; во-вторых, рейд это не только про дублирование данных, это еще и про скорость.
Заказчикам буду так говорить: «Чего пристали, у нас всё работает, кроме того, что не работает. Не пойму, что вас не устраивает?»А вы являетесь заказчиком btrfs? Оплачивали работы по разработке RAID6? Когда и сколько?
Про RAID вообще эпично, во-первых, то, что вы лично его нигде не видите, это ваши трудности, я вот постоянно сталкиваюсь с рейдами того или иного вида;Ну если вы, почему-то, хотите тратить деньги на snake oil — то это ваш выбор… но причём тут btrfs?
во-вторых, рейд это не только про дублирование данных, это еще и про скорость.Скорость — это RAID0. Он отлично в btrfs работает.
P.S. Про качество оригинала даже не буду писать, человек написал «очень свою» точку зрения — и, так кажется, мысль вызвать холивар у автора была не на последнем месте.
Nginx+Django+PostgreSQL — полет спокойный. Единственное с чем столкнулся, это при обработке загруженных изображений не хватало библиотек, которые почему-то в ubunt'е шли сразу.
t2.nano, t3.nano — о чём-то говорит?
полёт нормальный.
ядро — не GENERIC (для себя ведь старался).
t3.micro — keycloak (openjdk8 под капотом).
А.
ну, и замена NAT Gateway (там где в нём есть необходимость) на t?.nano рулит по деньгам. разворачивается автомагически из Auto Scaling Group. где можно — на спотах.
P.S. по поводу community.
не представляю, куда бы я пошёл, направь e-mail не Colin Percival, а кому-нибудь a-la мьсе о-Торвальдс… то ли вопрос оказался для него плёвый, но с мёртвой точки в правильном направлении столкнул...
Отличная статья. Читается с удовольствием.
Кто- то согласится, а кто-то нет. Вечный спор о том, что побеждает. В системотехнике есть даже теорема о « замкнутых системах и циклах развития»
А какой тогда была OS/360, нулевой?
Насколько вижу тенденции в технологии, то это уменьшение важности хоста и его надежности, взамен этого упор идет на High Availability и распределение по клаудам. Так что можно хоть на распберри сервера свои держать, лишь бы их был миллион — половина сгорит в вулкане, треть потонет в цунами — а остальное будет работать и сервис будет доступен как ни в чем и не бывало. А что там под ним, и насколько оно надежно — пофигу по большому счету. Как и глючные программы это нормально — половина упадет в сегфолты, зато другая половина будет работать. Очень повышается общая толерантность к ошибкам, будь они в системе или в коде. Отсюда и популярность облаков, кубернетис, контайнеров и т.д. и т.п. И походу это и есть будущее.
Некоторые так называемые девопсы уже и не знают даже на какую они систему деплой делают — в амазон, а какая там ОС и не догадываются :) И они уж точно дебиан от сентоса, а их всех от FreeBSD не отличат. Так что наши тут холивары это уже беседы на лавочке.
Некоторые так называемые девопсы уже и не знают даже на какую они систему деплой делают — в амазон, а какая там ОС и не догадываются :
это пугающая перспектива. Т.к. большинство людей и не понимает, что у них под капотом систем, которые они используют. Обычно это не проблема, но иногда из-за этого случаются эпичные фейлы. Или решение инцидента становится дольше и сложнее.
Ну, и вообще — действительно SRE о бюджете ошибок и простоя и эффективном их управлении
Было, вроде даже не по разу же. ubuntuBSD, Debian GNU/kFreeBSD…
Почему BSD проиграла в битве с GNU/Linux?