Comments 249
Darwin — это открытая POSIX-совместимая операционная система, выпущенная Apple Inc. в 2000 году. Она совмещает код, написанный самой Apple, с полученным от NeXTSTEP (система выпущена в 1989), FreeBSD (выпущена в 1993) и прочих свободных проектов. Система Darwin представляет собой набор основных компонентов, используемых в macOS и iOS. Из Википедии.
UFO landed and left these words here
Третья важная причина заключается в том, что BSD разрабатывалась относительно небольшой организованной группой профессиональных программистов из Беркли. В то время как разработка ядра Linux велась Линусом Торвальдсом с помощью широкой и гибкой сети добровольцев раскиданных по всему миру.
Ну прямо опенсурсная идиллия) Линукс то как раз «выстрелил» (в контексте статьи) именно тогда, когда в бум доткомов на него обратили внимание Ынтерпрайзы и стали вливать кучи бабла и прочих «профессиональных программистов». И это очень прекрасно, что так вышло.
upd. А вот почему так вышло и почему именно в линукс, а не в bsd, например — уже частично в статье есть ответы.
Сейчас не найду источники, но в то время IBM в порядке борьбы с (понятно, почему) ненавистным MS вкачивал в линукс многие десятки миллионов долларов. Причём вкачивались они не в зарплату разработчиков (этого не требовалось ни для BSD, ни для Linux), а в создание среды, востребованность. Потому и выстрелило.
Скорее, начали вливать, потому что вместе со SCO провалили портирование AIX на платформу x86, а вливать в очередной Unix-like проект на основе BSD было уже не рентабельно.
ну да, и добавим, что провалили OS/2 и DB/2, при этом сделав/получив врагов в лице WinNT и MS SQL
Ну я про то же, собственно…
А источники… да это вроде общеизвестные факты, описанные в анналах того времени. В revolution os про это есть в том числе, там Линус и Ко воодушевлённо расписывают что вот сейчас-то с таким раскладом точно вендекапец.
Я ждал, когда будет упомянут этот замечательный документальный фильм «Revolution OS» («Революционная ОС») про историю возникновения GNU/Linux, движения open source, Red Hat и т.п. Крайне рекомендуется к просмотру, можно найти на ютубе или торрент-трекерах.
Хочу от себя добавить: смотреть обязательно в переводе Дмитрия Бачилы.
Многие думают, что дистрибутив GNU/Linux и был первой open source операционной системой. Но это не так. Его опередил проект Berkeley Software Distribution, или BSD.


С одной стороны GNU/Linux была первой «free software» — свободной операционной системой (в отличие от «open source»). С другой стороны, даже BSD не была первой «open source», так как изначально почти весь софт разрабатывался в научных и образовательных целях, был свободным и никому не приходило в голову использовать лицензии.
Ну ладно — раньше были юридические тяжбы, а сейчас что мешает BSD стать более популярной? По-моему, проблема не столько в юридической плоскости, сколько в подходе к программным пакетам в системе — типовой для BSD подход «компилируем всё, что можно под свою систему» имеет слишком большой оверхед. В итоге, установки пакетов почти всегда превращаются в танцы с бубнами.
Я уже давно не танцевал с бубнами. Не хотите использовать порты — берите пакеты. Да даже для NAT'а давно уже не нужно пересобирать ядро.
У вас очень искажённое понимание BSD с устаревшими лет на 15 впечатлениями про пакеты и „танцы” с „бубнами”. Что бинарное обновление системы за две команды, что бинарное обновление бинарных же пакетов выполняется вообще без проблем парой команд и это так же доступно уже лет десять.

Кому нужен кастом — собирает из портов и это куда как проще централизованно собирать и поддерживать, чем делать аналогичное что-либо из исходников на любых линуксах.

Главное для моего удобства, что было в той же FreeBSD — jails & zfs наконец-то есть и в линуксах, lxc/lxd с zfs. Без lxc/lxd было совсем тяжко.
… Сеть в линуксе обогнала bsd-ную по производительности, файрволлы/NAT-ы под линуксы работают быстрее и фичастее, софта и окружения под БСД уже критически не хватает, систем конфигурации не хватает, решений для массового управления/мониторинга/деплоя/развертывания и тд не хватает, по виртуализации линукс далеко впереди, популярные хайповые языки (nodejs, Go, например) всё меньше и меньше обращают внимание на совместимость с BSD…

BSD планомерно теряли каждую из сфер. Сейчас linux просто делает лучше всё — а это отражается и на рынке специалистов. Ну а дальше замкнутый круг.
UFO landed and left these words here

Опередили меня. У некоторых есть совершенно очаровательная манера рассуждать о том, о чём они имеют, в лучшем случае, крайне слабое представление.

> Сетевой стек, если быть корректным.
«Иван Михалыч, прекратите, пожалуйста, капать оловом мне на лицо!»
Все (ну ок, вне 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. А может уже.
(При этом они те ещё свинтусы, взяв ejabberd за основу они же фактически и убили протокол XMPP.)

Поверьте, я тоже не рад тому, что 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 надев голубую шляпу вместо красной ;-)

> Это вопрос как мерить. Netflix, «отчего-то», стримит через FreeBSD. Да, частный случай, но, напомню, это по оценкам 20% мирового трафика.
Ну такое себе. Во-первых, не 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."


https://fosdem.org/2019/schedule/event/netflix_freebsd/

28659

С каких пор эта циферка стала что-то значить? У меня в репах 20000 собранных пакетов, а не портов, значит ли это, что в моём дистре особенно хорошая (или плохая) поддержка софта?
ansiible

Если бы под него модули были.
bhyve

А в продакшене он хоть где-нибудь есть (кроме вашего локалхоста, конечно)?
прежде чем писать сравнение, неплохо все таки знать каждую из систем

Ох, это знакомое до боли угадывание знаний собеседника по комментам на хабре.
У меня в репах 20000 собранных пакетов, а не портов

Писал уже выше. Не хотите порты — пользуйтесь пакетами. Я уже забыл когда оно появилось, настолько давно это все работает.
UFO landed and left these words here
Ну, для кого-то и тексты книг неведомая абракадабра.

Т.е. вы так и не смогли ответить, что же значит это число. Ответ: оно обозначает число существующих портов, и с количеством софта оно лишь коррелирует, а не связано напрямую. Соответственно значит оно примерно ничего.
Где-то четверть из почти 200 корпоративных VM.
Управление через github.com/churchers/vm-bhyve
Обепечивают реальные промышленно-торговые процессы.
Приложения разные.

Неплохо. Почему именно *BSD? В чём реальные преимущества на реальных задачах кроме довольно субъективной «привычности» и «продуманности»?
Эффект Даннинга-Крюгера, пик глупости?

Угадывание квалификации собеседника по комментам на хабре.
UFO landed and left these words here
Вы, в общем-то, говорите об одном и том же. Во FreeBSD есть несколько фич, которые ещё 10 лет назад были мегафичами: bpf, jails, ZFS с возможностью даже загружатсья с неё. С тех пор во FreeBSD ничего не поменялось, а Linux догнал и перегнал. В результате фря из вполне себе мейнстрима стала нишевым продуктом.
Главная проблема BSD что 15 лет назад (когда я её на серверы массово ставил), что сейчас это недостаток ресурсов разработчиков, что выливается в отсутствие security-only фиксов для портов.

Итого, поставил linux и забыл на несколько лет. А FreeBSD поставил и либо забыл и её ломанули через дырку в ПО, либо у тебя постоянно меняются версии ПО вне базовой системы.
И это форменный анекдот, потому что FreeBSD собирается выкинуть собственную реализацию и переезжать как раз таки на ZoL.

Неплохо вы меня удивили, спасибо за ссылку.
И это форменный анекдот, потому что 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, это магия и объяснений и рационализации не требует.

Про пакеты вы правы (? не помню уже, мог.ли инсталлятор апдейтить пакеты). Но что с дискет, что с CD, бинарное обновление системы было доступно. Однако пока не было CD, исходники было проще распространять по эл. почте чем бинарники. Но при этом, все всё-равно собирали любые пакеты из исходников, т.к. магия.
Вы говорите про обновление из «живой» системы через freebsd-update, которое действительно появилось в 6.2. Однако, задолго до этого существует обновление через штатный инсталлятор, как при загрузке со внешнего носителя, так и из «живой» системы
P.S. В отличие от пакетных дистрибутивов, BSD традиционно состоят из двух частей: базовой системы и управляемой пакетным менеджером/pkgsrc/ports частью. Первая часть условно статична и монолитна, вторая же полностью управляется в том же смысле, что и системы, построенные целиком на основе пакетного менеджера: установка/удаление средствами pkgsrc/ports полностью адекватно модифицирует БД пакетов
Нету проблем, там давно есть собранные пакеты. и почти всю историю были, в т.ч. репы. Даже для генту ничего не мешает брать бинарные пакеты.
Хммм… Как это «нету проблем»? Проблемы есть, и много.
Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD. Между этими клонами довольно трудно сориентироваться не особо разбирающемуся человеку. Какой вариант ставить? Что лучше для каких-то конкретных целей? Куда бежать, если возникли проблемы? Когда у потенциального пользователя нехватка времени и нет особого желания ковыряться в деталях — он плюнет на все эти заморочки и поставит линукс.
Продолжим.
Мейнтейнеров BSD мало, учитывая, что надо мейнтейнить аж три разных дистрибутива. Среди них нет единства, нет харизматичного лидера, зато есть этакий «корпоративный подход» к решению проблем. В результате решения принимаются коллегиально — т.е. из двух зол выбирается третье, чтобы никому не было обидно.
Еще о проблемах BSD (конкретно — NetBSD) писал Чарльз Ханнум: mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
надо мейнтейнить аж три разных дистрибутива
Назвать три вообще разные операционные системы видами дистрибутивов, которые де мейнтейнить надо аж три все разом — это сильно.
Рад был угодить.
Что касается терминологии — я уже давненько в линуксе, посему да, забыл тонкости. Не просветите, чем «вообще разные операционные системы», собранные на одном ядре плюс-минус патчи, отличаются от линуксовых дистрибутивов, собранных на одном ядре плюс-минус патчи?
Что касается «мейнтейнить аж все три разом» — я такого не говорил, это уже ваши додумки. Моя мысль была в том, что мейнтейнеры разбежались по конкурирующим проектам, и в результате их усилий стало не хватать.
Угу, а я ещё шестую шапку и вторую фряху помню, вот только эти различные *BSD всегда были абсолютно разными.

Коллега, пожалуйста, прочитайте про FreeBSD, OpenBSD и NetBSD, это не конкуренты, это совсем разные задачи и цели. Это совсем не тоже самое, что Гента и Центось. Абсолютно.

Я не в смысле вам пытаюсь указывать что делать или не дай бог как-то побольнее подъебать, нет, я в смысле серьёзно, я вам не смогу в коротком комментарии объяснить истории или хронологии. И история BSD очень интересная, это часть всего IT мира, это история Unix в конце концов. Но мешать в один тазик эти три вообще разных операционных системы и объединять их в дистрибутивы — это совсем неправильно.
я вам не смогу в коротком комментарии объяснить истории или хронологии.

Для таких случаев есть прекрасная фраза: «так исторически сложилось». Ничего не объясняет, но звучит убедительно.

И история BSD очень интересная, это часть всего IT мира, это история Unix в конце концов.

Как и история любой другой операционной системы.

Но мешать в один тазик эти три вообще разных операционных системы и объединять их в дистрибутивы — это совсем неправильно.

Можно назвать их тремя абсолютно различными операционными системами, можно назвать их тремя пряниками. Суть моего высказывания от этого не меняется: мейнтейнеров не хватает, и в этом — одна из основных проблем BSD.
А какой именно линукс?
Вот где проблема выбора стоит ещё более остро!

Да я о том, что сейчас и для десктопа и для сервера выбирают в основном Ubuntu.

Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD

Сразу видно линуксоида плохо понимающего "кто на ком стоял". Между ними общего в разы меньше, чем между любым клоном (вот тут это уместно слово, действительно) Linux.


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

Ещё раз, это не дистрибутивы, а независимые операционные системы.
Резюмируя, вы б почитали по теме что-то для начала чтобы впредь не садиться в лужу.

Резюмируя, вы б почитали по теме что-то для начала чтобы впредь не садиться в лужу.

Если б от моего чтения БЗДя ожила, я б, может, всю библиотеку конгресса перечитал бы. Но — увы.

ЗЫ: Забавно: уже второй человек посылает меня «что-нибудь почитать по теме», но при этом не удосуживается дать ни единой ссылки.
Еще о проблемах BSD (конкретно — NetBSD) писал Чарльз Ханнум
Забавно: письмо от 2006 г., а во многом пересекается с другой, более поздней заметкой (2013 г.), которую я здесь переводил.
Начнем с того, что BSD разделена на несколько клонов: FreeBSD, OpenBSD, NetBSD <...> Какой вариант ставить? <...> Когда у потенциального пользователя нехватка времени и нет особого желания ковыряться в деталях — он плюнет на все эти заморочки и поставит линукс.

лол, какой?
лол, какой?

Лол, любой из убунт.
Там из мук выбора — только какой образ выкачать, сервер или десктоп.
а сейчас что мешает BSD стать более популярной?
Успешно раскрутится на уже поделенном рынке можно только выйдя с какой-то убер-киллер-фичей, отсутствующей у конкурентов.
UFO landed and left these words here

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

Как раз хотел написать про драйверы. Во времена ядер 2.4 под них многие драйверы могли написать любители-энтузиасты, а разработчики от производителей железа могли меньше вникать в работу ядра. В FreeBSD порог вхождения был гораздо выше. Ну, в Linux до сих пор планировщик и oom killer сильно проще.

Где-то слышал, что один из разработчиков FreeBSD наоборот перебрался на эту платформу, поскольку она проще. Мне тоже FreeBSD казалась всегда проще, во-первых, просто по объёму кода, во-вторых, по тому с какой простотой достаточно небольшая когорта разработчиков умудряется внести разные куски из других систем. Не может незрелая система принять в себя инородный код и не стать куском дряни, поскольку вживление это всегда костыли. А при наложении этих костылей с уже существующими в системе недоразумениями, задача дурная и чрезвычайно сложная.

Во FreeBSD, кроме того, крайне тяготеют к фреймворкам, объединяя куски в логически стройную систему. Это и сеть с NetGraph и GEOM для хранения данных и прочее. В то же время Linux — это почти всегда промежуточное состоянии в движении из прошлого в будущее, причём очень промежуточное. Я снимаю шляпу перед всеми, кто работает над ней, но блин, помнится за попытку исправить что-то в терминалах Линус обложил ответственного за подсистему, и дело закончилось неприятно, костыль остался на месте. Во FreeBSD при этом между мажорными релизами перелопатили консоль, и при этом о жертвах и разрушениях мне лично неизвестно.

Ещё ZFS, который вполне великолепно заехала во FreeBSD, при том, что мне до сих пор кошмары снятся от эксплуатации ZFS под dkms на Debian 6, и эта лютая грызня за память в dmesg. А та часть где, ZFS не нужно ставить на 32-х битный Linux и его сносной работе на 64-х битном из-за «разницы в работе с памятью»(с). Это в более простой системе у каждой архитектуры НАСТОЛЬКО разная работа с памятью, при том что архитектуры родственны…

Не верю я в простоту Linux, вот не верю и всё.
Жертв и разрушений не было, потому что не было пользователей?
Сложно пользоваться системой, у которой основная работа идёт через консоль, и не пользоваться консолью…
15 лет назад и Linux подхватывал далеко не все железо. А на ноутбуках это с ним и посейчас случается, хотя уже и нечасто.
Вчера компилировал дрова на BCM43142 которому около 8 лет, под CentOS 7, так что да, не так все гладко как рассказывают
Наверное потому, что очень мало усилий было направлено для превращения *bsd в десктопные ОС, всместе с тем, с поддержкой серверного оборудования проблем небыло, а по поддержке ращличных платформ, и подавно linux был не конкурент.
TrueOS, бывший PC-BSD, вполне себе лояльный к пользователю дистриб.
DesktopBSD тоже был вполне дружелюбен, как у него сейчас дела не вкурсе.
Единственная гипотеза низкой популярности фрюши, которая кажется мне правдоподобной — разработка драйверов. Когда я жил на PC-BSD, единственное, что на тот момент вызывало зубную и головную боль — это поиск дров для свежего железа.
ИМХО Linux популярнее поскольку он хайповее. Раньше был модным-стильным-молодёжным, а сейчас та молодёж занимает различные посты в различных компаниях и всячески продвигает Linux, просто потому что она его хорошо знает. Сейчас Linux — основная бизнес платформа для всего, что не требует Windows. Отсюда и драйверы, которые вынуждены выпускать производители, и тонна ПО и всякие вкусные плюшки. *BSD не были столь обласканы, они являлись утилитарными, не были в такой мере как Linux религией, и в этом причина пониженной популярности. Всё остальное следствия.

Щa TridentOS активно допиливают. Ну и как сборку для десктопа можно ещё на NomadBSD посмотреть, если лень руками всё это на FreeBSD ставить самому.

Сказанное вами абсолютно не противоречит моим словам.
Фрюша вполне может быть красивой и удобной, по крайней мере, в сравнении с линуксом она точно не уступит.
Визарды, которые есть у линуксы для комфортной установки рабочей станции есть и во фрюше.
Управление пакетами не более проблемное, чем везде. Особенно если ты просто пользователь и не тянешь софт, что называется, прямо из под пальцев разработчика.
С оговоркой, что я просто пользователь, если вдруг чего — то в штатных пакетах не хватает, я не испытывал проблем с установкой линуксового софта из rpm. Фря прекрасно умеет исполнять линуксовую софтину «почти как родную». Не знаю, может просто везло?

Единственная большая претензия с моей стороны — и почему я все таки пересел на mint-a, года 4 тому как, это список поддерживаемого оборудования. Вафля и иксы ни как не хотели нормально работать на моем тогдашнем буке. На тот момент не оказалось, ни времени, ни настроения, разбираться, поматерился и дизертировал на линуксу.
В начале своей карьеры я познакомился с RedHat и FreeBSD. FreeBSD субъективно была гораздо приятнее в использовании, а ее handbook я частично использовал чтобы ковырять линуксы (внезапно, да?). Но фряха проигрывала линуксу уже тогда по одной очень важной причине — поддержка оборудования. То что без проблем заводилось на Linux, на FreeBSD приходилось ждать годами. А чего-то так и никогда и не дождались. В общем ситуация была похожа на Windows vs Linux, где под первый дрова были подо все, а в Linux как повезет.
Интересно, чем FreeBSD приятнее? Я тоже попробовал RedHat и FreeBSD году в 2002-м и впечатление получил совершенно обратные.
Логичнее и стройнее.
Видно, что одна команда делает, и с пониманием процесса. ИМХО, разумеется.
Сложно объяснить, именно по субъективным ощущениям FreeBSD тогда была логичнее и стройнее. Система портов, хэндбук, организация каталогов. Для меня она еще некоторое время оставалась почти эталоном, пока я не познакомился с Debian.
SCO Group подала в суд на нескольких крупных вендоров Linux.

Во второй половине 80-х мы наверное были первыми и единственными в СССР, кто поставил на UNIX-системы. И начинали мы, помимо Xenix-аЮ c SCO, BSD еще не было. Но вот прошло 30 лет и где сейчас BSD, Linux, а SCO совсем не найдешь.

"невзлету" *BSD дистрибутивов и клонов способствовало несколько моментов.


Как уже говорилось — лицензия, которая, по сути, ничего нового не привносила. Да, можно было взять "за просто так", это было важно, но не более.
По началу всем было весело с Linux, где вопросы решались быстро, потом, заинтересовашиеся компании, поддержавшие Linux, уаилиши в нем ровно то же самое: мы себе кусочек выбъем и будем его пилить. Сами. В BSD это впринципе не получится.


Второй важный момент это адаптация на разных платформах. С этим у BSD было более-менее ок, но "соборный" способ разработки не давал нужную скорость адаптации.


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


Получается, что BSD был такой "сам в себе" проект, который не учитывал процессов и чаяний индустрии (читай — внешнего мира). И это не отрицательная его сторона — это его фича.


Продукт был хорош — маркетинг провалился.
Сравните с Linux ;)
Сделайте выводы.

> Возможно, это печально, ведь программные решения Apple закрыты настолько, насколько это возможно.

Внезапно.
Именно «насколько это возможно». Почти всё, что там выложено — это GPL софт, который и требует публикацию исходников. Не было бы GPL — не было бы и opensource.apple.com
Как мне кажется, в этом случае там бы не было чего-то вроде AppleRAID или xnu.
Я не спорю, эппл — это не совсем про опенсорц, но таки какие-то свои разработки они выкладывают.
У Линуса в Just for fun есть такие строки:
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.

Может это как-то повлияло)
Здесь Торвальдс сравнивает свое ядро с ближайшими «конкурентами» — учебными и хоббийными системами. У «взрослых дяденек» эти технологии были давно отработаны. Я напомню, что виртуальная память и своппинг были еще во времена БЭСМ-6.
меня сейчас начнут нещадно минусовать… но я не могу промолчать. проблема отсталости BSD и фряхи это не лицензия(хотя она и не последнюю роль играет), а сообщество. их можно охарактеризовать несколькими словами: тяга к некрофилии и гомофилии… зачем пытаться поддерживать то что устарело и умерло? например кеды 2. ну отказались от них и нового в них не предвидится… так закопайте и сами не мучайтесь и не напрягайте пользователей. а по поводу испортивших символ детства — радугу, ведь даже символ они себе выбрали чертёнка. ну не будут православные или верующие юзать то что противоречит их убеждениям. да и Эрик Пол Олман и Маршал Кирк МакКасик не добавляют в копилку доверия.

Вас надо не минусовать, а попросту забанить в порядке сокращения общего уровня идиотизма если не глобально, то, хотя бы, на Habr.

Внезапно, православные начали слезать с FreeBSD только тогда, когда ну очень захотелось наличествующей в Linux прямо сейчас виртуализации. По крайней мере по этой причине уехал Яндекс. Но даже сейчас фильтрация трафика на уровне доступа сотрудников всецело на FreeBSD. А хостинг платформы на Руси были чуть менее чем полностью на фре. Черти не причём, а особенности разрабов вообще нынче в тренде во всяких там Европах ;-))).

Старые версии некоторых продуктов — следствие того, что оно пишется под Linux и портировать его от туда задача не тривиальная. Завести сырые кеды, которые на Linux устаканились совсем не сразу — самоубийство. Сколько людей пилят кеды под Linux, а сколько из них тратят время на Фрю?..
мне как-то рассказывали забавную вещь — в одном монастырей (вроде Ново-Тихвинский) г. Екатеринбурга в качестве маршрутизатора стояла freebsd, уж не знаю как-бы отреагировали попы/монахини узнай какой символ используется у этой ОС) (дело было более 10 лет назад)
UFO landed and left these words here

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

Да нет же. Для бизнеса куда как удобнее и выгоднее BSD, которая не обязывает возвращать собственные наработки. А предпочли они Linux во-первых, по причинам описанным в статье (юридическим, что часто недооценивается выросшей и живущей в правовом ниглизме большей частью русскоязычной аудитории), а, во-вторых, это модель разработки. Во FreeBSD и тогда и сейчас используется довольно консервативный и академический подход. Быстро внести требуемые кому-то, но слабо проработанные, изменения (принцип "херак-херак" и в продакшн) там не прокатывает.
В Linux такое везде и рядом. И сейчас тоже. Любой непредвзятый наблюдатель без труда это заметит на мало-мальски большом временном интервале.

Для бизнеса куда как удобнее и выгоднее BSD, которая не обязывает возвращать собственные наработки

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

Тут соглашусь. Во FreeBSD возвращают, конечно, но сильно меньше чем могли бы.

Дану…
Притянутая Netgraph из Juniper, bhyve приехавший из NetAPP. Кроме того есть не стеснительные Netflix активно пилящий подсистему хранения, Яндекс много сил вложивший в ipfw и сеть. Вроде много чего давал Yahoo. Есть возврат, и достаточно хороший.

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

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

В общем верно. Как бывший разработчик FreeBSD, могу сказать, что компании активно заимствовали код в своих разработках, но лишь малая их часть тратила силы на обратные инвестиции. А имеющиеся у CoreTeam средства распределялись только на наиболее важные, по ее мнению, разработки и конференции. Но на голом энтузиазме далеко не уедешь, поэтому имеем то, что имеем.
Во FreeBSD и тогда и сейчас используется довольно консервативный и академический подход. Быстро внести требуемые кому-то, но слабо проработанные, изменения (принцип «херак-херак» и в продакшн) там не прокатывает.

Хороший пример: freebsd перешли с CVS на SVN в 2008-м году. Линус запил GIT и перевёл на него Linux в 2005-м.
Ретрограды всегда проигрывают ньюфагам.
Вопрос в утилитах и процессах. Много чего было завязано на CVS и никто не видел в себе сил бросить всё и переписать. Переезд всего на новую систему каждый месяц хорош, когда кроме кода перевозить нечего. Остановить всё и начать перетаскивать всё куда-нибудь потому, что «оно уже вышло, а мы ещё не там» странен. Когда CSV утомил, перетащили постепенно за несколько релизов на Svn, тихо, цивилизовано, поэтапно.
UFO landed and left these words here
Опять сравнение тёплого с мягким. Тут системы выбираются именно из принципов разработки, где git — ДЕцентрализован, тогда как svn — централизован. У них существенные отличия в работе с ними. И выше уже было про разные подходы к разработке "… и в продакшен" против централизованной разработки неким ядром сообщества.
> И выше уже было про разные подходы к разработке "… и в продакшен" против централизованной разработки неким ядром сообщества.

Ну вот именно, что централизованный подход SVN приходит к регулярным «что вы закоммитили! уберите немедленно», или «ой, скриворучил, отменяю». Я читаю src-all@ и вижу такие плачи регулярно. При прохождении через предварительный фильтр типа LKML бо́льшая часть подобного мусора отфильтровывается и не попадает в репозиторий.
Имхо насчет регулярных вы, Валентин, всё-таки преувеличиваете. Да, факапы время от времени случаются, но большинство крупных (и даже мелких) изменений таки проходят предварительный фильтр, обсуждаются, рефайнятся/отменяются и т.п.
Там бы не «Ubuntu/CentOS», а «DEB-/RH-based»
Не надо так уж опускать читателей.
PS. есть еще слака и всё такое иное.
UFO landed and left these words here
Еще одним ярким примером популярности наследия BSD является игровая приставка Sony Play Station — ее операционная система является форком FreeBSD.

Судя по лицензионному соглашению FreeBSD взята за основу и для Horizon (ОС для Nintendo Switch).

Да что им JunOS, они тут говорят, что сетевой стек в БСД отстал на декады от линукса.
Ну да, им невдомек, что BSDшный стек полмира пользуют, остальные полмира — embedded типа LWIP
Жму руку понимающему человеку)
P.S. Я вот читаю хабр, и понять не могу, что здесь сейчас за аудитория. Сплошные docker/kubernetes/go и прочее. Фрилансеры-программисты на стартапах чтоли тут в основном и сидят? Я нигде ничего подобного не вижу у крупных заказчиков в инфрастуктурах, с которыми приходится работать.
Похоже на то. Go, кстати, не совсем к месту в этом списке. Очень консервативная штука. Я совсем не понимаю, откуда вокруг него столько хайпа у молодежи. Из-за гугла что-ли?
UFO landed and left these words here
P.S. Я вот читаю хабр, и понять не могу, что здесь сейчас за аудитория. Сплошные docker/kubernetes/go и прочее. Фрилансеры-программисты на стартапах чтоли тут в основном и сидят?

Вон ниже пишут, что мегафон уже мигранул. Мелкие и средние заказчики используют докер и кубер только так.

А мужики из WhatsApp то и не в курсе, нужно им срочно новость донести, а то мучаются бедолаги.

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


Маршрутизаторы, прокси-сервера и так далее это еще есть, а вот конечные сервера уже давно под линуксом.

Netflix и WhatsApp использует FreeBSD именно на серверах, насколько мне известно, кроме того есть крупный список владельцев инфраструктуры на FreeBSD. Но с другой стороны, да, большинство использует Linux, поскольку его знают больше народа и под него ПО оптимизируется. И это грустно.
Ну вот конкретно WhatsApp недавно свалил, про Netflix написано то, что он через freeBSD раздает трафик, если я не ошибаюсь.

Ну, мне радостно, что хотя бы не Windows :)
Ну вот конкретно WhatsApp недавно свалил

А где про это почитать? Мне страшно интересно.
По моему, Linux выиграл в основном благодаря информационной поддержке FSF, которая определялась лицензией.
Я достаточно много копался в ядре и libc FreeBSD 3,4,5 и, иногда, заглядывал в ядро Linux. Код FreeBSD мне нравился больше. Но качество кода редко заметно влияет на успех или неудачу проекта.
Полностью согласен с Вашим мнением. Мне вообще кажется, что Linux это феномен не мира информационных, а мира социальных технологий. Это в своё время, по воспоминаниям знакомых мне, ярых линуксоидов, была больше религия, нежели чем система.
Я уже писал своё мнение об этом не раз — GPL лицензия для корпораций это договор о сотрудничестве, мол делаем вместе и никто никого не кидает, не увиливает от делания своего вклада.
Так-то они конкуренты, но благодаря лицензии сотрудничают.
Да что вы переживаете, у BSD есть своя ниша. И там все неплохо живется и развивается своими, хоть и не семимильными темпами.
Я не программист, а системный инженер, админ, и тот еще ретроград. Я ничего плохого не имею против линукса, даже наоборот.
Я настолько отстал, что глядя на то, как сейчас устроена разработка, совершенно не понимаю как это устроено. Получается DevOps вытеснили системных инженеров/админов, и сейчас вместо build-фермы и testing-фермы (даже на ВМ) тупо виртуалки, а в них докеры?

Лично я выбираю ОС простым способом:
— Если это open-source, никто кроме меня это админить не будет, этот софт есть в портах, то это FreeBSD, однозначно, и никак иначе.
— Если требуется БД Oracle, это железо от Oracle и Solaris на SPARC, и никак иначе.
— Если требуется БД DB2, это железо от IBM и AIX на PowerPC, и никак иначе.
— Во всех остальных случаях, это любое приличное железо и Red Hat / CentOS.
— Про Windows оставим без комментариев :) Тут итак всё ясно.
А я вот программист, а не системный инженер и у меня нет личного системного инженера поднимать мне окружение на целевой платформе. Поэтому я выбираю FreeBSD за то, что это полная операционная система(включая user space) тестированная, документированная, внятно организованная и постигаемая в поддержке для непрофессиональных админов, в отличии от зоопарка сборок linux. И она без бубна разворачивается на любом железе которое я эксплуатирую.
Лично я предпочитаю удобство и количество софта, а не тесты и документацию. Да, линукс зачастую сумбурен, да, есть странные моменты, но зато в нём можно комфортно работать на десктопе и запускать код на сервере из (почти) одинакового окружения.

Да прекратите уже бредить. По объёму доступного софта и его свежести FreeBSD всегда была в лидерах, а уж удобнее портов и представить что-то сложно. Хотите ставьте из них, хотите из готовых пакетов собранных из тех же портов, хотите свой репо разворачивайте со своими опциями используя poudriere (причем можно и для другой версии).

Total:
AUR (44909)
nixpkgs unstable (43125)

FreeBSD Ports (32313)
Newest:
nixpkgs unstable (21394)
FreeBSD Ports (16497)

(Справедливости ради, оба счётчика сломаны :P)

Там гранулярность разная, так что напрямую сравнивать некорректно. Где вот FreeBSD один порт, в репозитории Linux может быть три — пять собранных с разными опциями или побитые на мелкие пакеты.
Если интересно — можете озаботиться, проверить.

В nix гранулярности нет, там как раз все «пакеты» — на самом деле derivations, все флаги и настройки изменяются путём оверрайда этих derivations. Разница такая большая из-за того, что в nixpkgs есть пакеты из Pypi, npm, hackage и прочих ЯП, в которых обычно с пакетами справляются встроенные ПМ. Если интересно — можете озаботиться, почитать.
И не просто вытеснили: сейчас просто админом быть не только не модно, но и не выгодно. Называешь девопсом, получаешь минимум 50-100 процентов к зарплате. Так что тут не получится быть олдскульным админом, надо прокачивать все стороны…
DevOps — они тоже разные бывают. Сейчас холивар века — DevOps/Agile vs DevOps/Requirements/Validation/Verification.
Опять же оговорюсь, я никакого отношения к Develompent-стейджам отношения не имею. Я инженер поддержки инфрастуктуры, в том числе и ОС. Ынтырпрайз в чистом виде.

И чтобы кто-то из крупных заказчиков пришел и сказал, «о боги, у нас там kubernetes упал», никогда не было, да и не используют они такое.
Опять же habr.com/post/435910/#comment_19613146
Все зависит от того, какой бизнес считать крупным. Ну вот, к примеру, Мегафон — крупный? У них там есть Kubernetes (и не только он). Или в МТС. Все еще недостаточно крупные? Тогда Сбербанк.
Чтобы
kubernetes упал
его нужно ещё поднять и как-то интегрировать в сеть компании, протащив мимо СИБ и объяснив инфраструктурщикам, сетевикам, базерам и прочее как с этим теперь жить. Если всё готово к kubernetes — всё ОК. Шаг влево, шаг вправо — и всё, уже не так всё хорошо и безоблачно.
Из всех переселенцев мне больше понравилась мотивация Яндекса. Народу просто не хватало того, что навернули в Linux с виртуализацией и контейнеризацией. Причём, что характерно, до этого сидели и молчали, поскольку после переездов, во FreeBSD начали активно пилить и довели до ума пакеты, доводят до ума виртуализацию, размещаются в нужных местах типа github-а и прочее. Ещё не Linux но уже на пути.
интересно, а есть где-нибудь ссылка почитать [про мотивацию Яндекса подробнее]?

Ещё не Linux но уже на пути.
реально очень рад за бзду, я вообще за разнообразие
интересно, а есть где-нибудь ссылка почитать [про мотивацию Яндекса подробнее]?

Вот тут к примеру.
UFO landed and left these words here
Что-то вспомнился дядя Вова в ru.unix в далеком 1998 что-ли году… он там очень ярко и образно описывал, почему у его кроссплатформенного продукта основная платформа вдруг Linux, а разработку вообще он вел на Windows NT. С примерами, ага.

И он тогда наглядно изображал — куда (и почему) шла FreeBSD. И нет, это была не лицензия.

Если в трех словах — это темпы развития, общий вектор, и коммунити.

Первых два очень хорошо описывал на примерах стандартного API (libc/libc_r) и реализации threads (емнип, в линуксе аж две либы было на тот момент работы с потоками, а фря который год выстраивала монументальный проект с моделью ниток с фиберами N:K, который умер не родившись. Как потом злословили — потому что в линуксе придумали в итоге epoll, ага, с третьей попытки. Но смысла в зеленых нитках не стало).

А третий компонент лучше всего проиллюстрировал в примерно то же время Алекс Кошмарь, в своем фирменном стиле обложив матом «поделие финского студента», но опять же фирменно с цифрами и примерами. Что характерно, один из кернельдевелоперов той поры, легендарный ANK, не просто связался с Алексом прямо в фидо, но и получил доступ к хосту с репортом, и решил таки проблему внезапной паники линуксового ядра на запредельных сетевых потоках (а, да, потом опять весь стек переписали). А в freebsd с багрепортами было мнэ… не очень.

А тут — лицензия уиноуатая, и не виноват ли снова межделмаш?
Я бы искал на groups.google.com — жаль что архивы там сильно не все.

Ну, вот для примера, 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 ;-)
Странно было ожидать в комментариях что-то кроме холивара.

Я — простой пользователь, и когда понадобилось переехать с Windows на домашнем сервере на что-то, что не отжирает 50% оперативки сразу после загрузки, я стал искать среди дистрибутивов Linux, и не смог адекватно сориентироваться в этом зоопарке из десятка дистрибутивов, у каждого из которых свои особенности. И тогда я взял, и переполз на FreeBSD. Сначала было трудно — из окошек с чекбоксами с головой уйти в консоль, но благодаря абсолютно всеобъемлющей документации — всё получилось. И когда голая свежезагруженная система заняла в памяти 140Мб — я возрадовался, и понял, что это хорошо, и продолжил осваивать BSD.

Сейчас я пихаю FreeBSD где можно, и где нельзя — это основная система для мультимедиа, работы с документами, веб-серфинга, для домашнего сервера, т.е. именно для того, для чего используют компьютер 90% обычных пользователей, которые не играют в игры. Я бы сказал, что по надёжности FreeBSD, видимо, на уровне MacOS. Несколько раз пережил апгрейд релиза, и ни разу система не упала из-за несовместимости чего-то с чем-то. Про обновления в пределах релиза — вообще молчу. Проблемы с совместимостью были только с WiFi-карточками, которые решились выбором подходящей карты из коробки с барахлом.

К сожалению, приходится держать в дуал-буте Виндовс для всяческого специфического инструментария, которого и под Линукс нет, вроде банк-клиентов, всяких радиолюбительских программ-калькуляторов, и прочего.

В системе привлекает неизменность конфигов от версии к версии, возможность установить базовую систему, и дальше доставить всё, что нужно, а не пытаться выковыривать лишние пакеты, вдруг обнаружив потом, что порушились какие-то неведомые зависимости, или что-то унесло с собой пол-системы. Адекватность маниалов — в них или точно расписан принцип, по кторому решается проблема, а не даётся совет типа «я выполнил в терминале вот эту команду, которую нашёл в интернете, и мне помогло, но кому-то не помогло, а почему — я не знаю». Быстродействие — на глаз, BSD работает быстрее и Windows, и Linux на одном и том же железе.

Я для своего сервачка OpenBSD использовал. Но боль от отсутствия поддержки UTF была. Правда потом и сервака не стало. А дальше я плотно сел на Debian ибо не хотел сильно мучиться с настройками web сервера для себя.

Одно в ней плохо: ufs2 (как и zfs) ни один сторонний редактор диска не умеет нормально масштабировать. Другими словами, на виртуалку фряху ставить неудобнее, если учесть дальшейшее масштабирование системы.

Ну, или мне просто так не везло (что тоже возможно).
UFO landed and left these words here
А когда с Gparted LiveCD грузишься, то весь раздел с его слайсами — «черный ящик». Неудобно крайне, не говоря что слайсы ресайзить тоже хочется.
Не путайте линуксовый Gparted и фряшный Gpart. Gpart прекрасно видит и слайсы, и разделы на них. Всё очень понятно, иерархично, надёжно. Можно реализовывать, к примеру, такие извращённые конфигурации, при которых, к примеру, как у меня на ноутбуке — на 60Гб SSD стоит Фря и Виндовс(20/40Гб), а на дополнительном диске — раздел Swap + раздел UFS + раздел в FAT32 + раздел NTFS. Всё разбито вручную Gpart'ом из коммандной строки.
Да, как раз не путаю, специально указал. Как раз отсутствие поддержки UFS/UFS2 в других ОС (и в других кусочках ПО, кроме теплого-лампового родного фряшного gpart) довольно сильно мешает обслуживанию томов на вируальных платформах (да и просто в жизни).
Я уже не говорю о том, что гипервизоры и хранилки не всегда могут понять, какая часть диска в виртуалке занято полезными данными, нужно что-то придумывать.
Хорошая система, как-то проскочившая мимо массовости (и это с таким-то вдумчивым развитием!), от чего сегодня стала если не совсем экзотикой, но хотя бы редкостью.
Как-то у меня голый свежезагруженный debian занял 18 мегабайт памяти (без учета ядерной памяти)… Хорошие были времена, deb5 был, помнится.
Впрочем, голый он и сейчас укладывается в сотню.
Эх, 15 лет назад я строил на FreeBSD / OpenBSD Интернет шлюзы, прокси, веб-серверы и даже подымал BGP маршрутизацию на quagga. И все это работало годами без сбоев и тормозов, и требовало перезагрузки только при обновлении с пересборкой ядра, и то не всегда…

Спасибо за статью, столько милоты накатило )))
работало годами без сбоев и тормозов

Ну вот это как раз не повод для сравнения с *nix-ами: даже нормально настроенная Убунта вряд ли будет тормозить и сбоить.

Но, должен сказать, есть какой-то юмор в том, что во времена, когда для пересборки ядра фряхи требовалось часа три, они находились, а сегодня, когда то же закончится минут за 15-20, мы ругаемся на тормоза пересборки. Наверное, еще и взгляд на мир меняется, взрослеем? *смайлик*
… даже нормально настроенная Убунта вряд ли будет тормозить и сбоить.

ню-ню, мсье Аптимизт..


Но, должен сказать, есть какой-то юмор в том, что во времена, когда для пересборки ядра фряхи требовалось часа три

не надо ля-ля ради красного словца: никогда за >20 лет моей памяти ядро не собиралось три часа.
сейчас на древнющем одноядерном ноуте (Samsung R60) ядро FreeBSD 12.0 штатным clang'ом собирается чуть меньше часа. и да — на zfs :)

Подзабыл уже, ядро на p2 собиралось примерно час. Трех часов там не было, факт.
Но даже «древнющий одноядерный ноут» — это ракета против p2, который как раз относится к категории "> 20 лет". Да и фряха не стоит на месте, как и частоты памяти, кеши и пр.
Я не говорю что linux будет тормозить, и я на SUSE поднимал шлюзы. Но там и там свои особенности.

Ну и три часа на сборку ядра я никогда не тратил, несколько минут и все готово.
На P2 в свое время занимало час, про три я погорячился.

А насчет инструмента (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.
UFO landed and left these words here
В статье перепутано все, что только можно.
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 были зачастую интереснее.
А потом пришел Большой Капитал…
А потом пришел Большой Капитал…
Дык он и в BSD приходил! Но вот тогда, собственно, GPL и «выстрелила»: коммерческие фотки BSD часто достигали «почти совершенства» в той или иной области… А потом «умирали, не оставив потомства». В в Linux можно было эти наработки в основную сетку подтягивать…
Мои воспоминания про freebsd из 2000х гдето такие:
надо карту интел, материнку интел, видеокарту специальную из спец списка по заказу.
потом пара суток настроек и компиляция и у вас сервер… в котором еще надо убирать мелкие баги.
в то же время opensuse(centos не было еще) — на любую материнку из наличных за 30 минут.
бинарные порты? да были, но на 386, а opensuse была на i586, что давало приличную разницу в скорости.
Да, сейчас в freebsd поддержка железа получше, но поезд уже ушел.
А есть еще и FreeBSD (и ОС на ее основе) — тоже отличная ОС. В моем вузе есть сервера под BSD и FreeBSD (есть также и под Linux и Windows, какие-то крутятся в виртуалках, какие-то — отдельно). Linux развивается значительно быстрее др. ОС, т.к. имеет огромнейшее сообщество разработчиков, и корпорации-гиганты вкладывают средства в развитие этой ОС. Но Windows, разрабатываемая одним разработчиком — Microsoft, развивается еще быстрее, т.к. корпорация Гейтса вкладывает еще большие средства, чем все сообщество разработчиков Linux вместе взятых; и вряд ли Linux ее догонит по популярности. Но как быстро Linux с нуля догнал Windows по функциональности и юзабельности! Помню первые версии Linux и попытки их применения в повседневной работе. С каждым годом Linux все активнее применяется в десктопах (в т.ч. в офисах), серверах и в качестве встраиваемых ОС (сетевые устройства, приставки, гаджеты и т.д.)

*BSD идёт более правильным путём, чем *Linux хотя бы потому, что не превращает OS в kernel+systemd...

А чем это более лучший путь? Тем что интеграция между ядром и юзерспейсом ещё плотнее? То есть, по-вашему, будет лучше если kernel и systemd станут одним проектом? Я в этом не уверен.

по-моему, я предельно ясно выразился, что *BSD в более правильном направлении развивается потому, что там нет системды :)
а линух прикончит системда, когда оно "срастётся" с кёрнелом и гномом в [практически] монолит: отсутствие вариантов — плохо для системы.
и да, я знаю о слухах, что во FreeBSD тоже рассматривается вариант разработки launchd. но как это уже было неоднократно, резкого и безальтернативного перехода a-la linux (а теперь — капец), полагаю, не будет: хочется верить, что мудрости у дядек из беркли больше, чем у горячего финского студента...

вы меня конечно можете заминусовать, но на мой программерский взгляд, systemd — это одно из лучших, что случилось с Linux за последние 10 лет.
Написание постоянно работающих служб ешё никогда не было настолько простым и приятным.
Про systemd как-то amarao хорошо написал:
Очень часто бывает так, что проект с офигенными идеями оказывается с ужасной реализацией, и все плюются и ненавидят. Systemd оказался в обратной ситуации — омерзительная идея, от которой все плюются и ненавидят, но реализация, к которой нет никаких вопросов или нареканий. В силу того, что хорошим софтом является софт с хорошей реализацией...
Не очень понял, с чем он должен был столкнуться или найти, но общий смысл в том, что чем глубже в systemd, тем меньше ты программист на баше и тем больше ты системный администратор. :-)

Disclaimer: вообще я, конечно, против systemd, оно очень anti-unix; зачастую его достоинства выливаются, например, в необходимость городить уродства вроде ExecStartPre=/bin/sh -c "/usr/bin/systemctl set-environment JVM_OPTIONS=\"$(tr -s '[:cntrl:]' ' ' < jvm.options)\"", но в целом юнит-файлы выглядят декларативнее и понятнее, чем привычные rc-скрипты, а их сопровождение и отладку можно доверить даже начинающему инженеру.
Минусовать, конечно же, я не буду. Но вот если бы systemd не тянул под себя всю функциональность, до которой мог добраться, а занимался бы только upstart'ом демонов, то все бы ему были благодарны.
К сожалению, у него столько всего есть, что я удивлен как это так до сих пор нет дистрибутива 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: делай что-то… хреново, а когда кто-то жалуется — забивай болт.
UFO landed and left these words here
/sbin/init запускает только getty и sh
далее сценарии запуска для каждой из.
Это — печальная реальность прямо перед переходом на systemd. В прошлом веке, когда SysVinit был молод, он запускал и Xы и другие демоны. Однако возникали проблемы с остановом (SysVinit останавливал «по запросу» основной сервер, а вспомогательные процессы выживали и «отравляли жизнь»). В результате от использования его в такой роли отказались, а реальная работа была переложена на плечи кучи bash-скриптов.

И да — договориться о каком-то порядке в этих скриптах было невозможно ибо каждый дистрибутив гордился тем, что именно они сделали «правильные скрипты».

Что же касается «собора и базара» — то уже очень хорошо видно, что работает только нечто среднее: если над системой работает горстка разработчиков и они всё делают сами (подход *BSD) — то вы безнадёжно отстаёте, если у вас есть сотни форков, но нет никого, кто бы отбирал самое важно — то «обычный пользователь» с вашими поделками работать не будет, так как просто в них запутается (это как раз долгое время мешало продвижению Linux на desktop), чтобы добиться успеха нужны сотни/тысячи независимых программистов — кто-то, кто будет собирать их в «генеральную версию».
UFO landed and left these words here
Блин, откуда этот миф о закрытости _публичных_ проектов?
Потому что это не миф. Огромное количество вещей, которые есть в 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…
UFO landed and left these words here
Имеется в виду, что если есть лапша из демонов, один из которых запускает дочерние процессы, то вы можете грохнуть гарантированно только сам основной процесс. А дочерние могут остаться жить. В парадигме init-скриптов в Linux такая проблема имеет место быть. И никакого отношения к типу сигнала это не имеет.
К сожалению, не все сервисы умеют правильно хендлить своих потомков…

Я уж не говорю о кейсах, когда нужно обеспечить порядок запуска.
Например, мы хотим сначала подмонтировать какой-либо каталог и ТОЛЬКО после этого запустить сервис (т.к. его данные лежат в этой точке монтирования). И в линуксе с SysV начинается геморрой. Точка монтирования отвалилась — как перезапустить сервис гарантированно без дополнительных обвязок. Или куча других интересных вещей.

Я уж не говорю про то, что у меня был кейс, когда init-скрипт думал, что сервис запущен, т.к. существовал pid файл, но фактически под этим pid'ом был запущен вообще другой процесс. Немного вмешательства ручек ops и полетели дальше… но осадочек очень неприятный.
>В мире *BSD на вторую проблему забили большой болт

Откуда эта информация?
Из первых рук, однако. Darwin, FreeBSD, NetBSD, OpenBSD — у них у всех разные (хотя у последних трёх и похожие) системы запуска… при этом только у первой — сколько-то осмысленное количество установок (но не на серверах).

Если некоторые демоны некорретно отрабатывают SIGTERM/USR12/INT/STOP, то на это есть таки злобный SIGKILL.
Вот только для того, чтобы найти процессы, которым нужно послать «злобный SIGKILL» — нужно провести целое расследование… которые соответствующие bash-скрипты и делают… но не всегда успешно.

В норме разработчие должен минимум озаботиться корректной остановновкой процесса по сигналу TERM со всеми необходимыми приседаниями, и обработкой иных сигналов. Это же как «отче наш».
Для разработчика, для которого основная платформа — Windows? В гробу он видал и TERM и KILL. И вообще — если платформа приносит 0.5% продаж, то на её поддержку можно выделить один день. В год. Ну хорошо: от щедрот — два. Это же как «отче наш».

А тут вы с тоннами правил, док и прочего.
UFO landed and left these words here
Просто надо понимать, что подавляющее большинство разработчиков — работают под Windows. Это не что-то с чем можно спорить и что стоит обсуждать. Это — просто факт.

Соответственно это можно либо учитывать, либо бороться с ветряными мельницами. systemd — это попытка это учесть.
Разработчиков под что простите?
Очень многие сидят на маках.
Или думаете, что они все хипстеры чертовы?
Разработчиков под что простите?
Подо что угодно.

Очень многие сидят на маках.
Разрабочики — нет. Они могут разрабатывать подо что угодно, но сидеть они будут под Windows — и, скорее всего, в Visual Studio.

Или думаете, что они все хипстеры чертовы?
Художники, дизайнеры — да, там Маков много. Хотя не уверен, что большинство. Но разработчики — сидят под Windows.

Да, спасибо за то, что заставили пошевелиться и посмотреть. Действительно: времена, когда 90% разработчиков сидели под Windows уже прошли. Сейчас — речь скорее идёт о 50%, однако если учесть, что 35% испольщуют VS Code и 34% Visual Studio, то понятно, что даже убежавшие на Mac «хипстеры» по прежнему имеют представления о внутреннем устройстве Windows больше, чем о том Mac'е, на котором они работают.

А уж о том, что там творится на FreeBSD — они не имеют вообще никакого представления… кроме тех 0.2%, которые на ней работают, конечно.
Есть ещё куча людей, которые сидят на продуктах JetBrains (IDEA?). И есть отщепенцы, которые пишут на Eclipse (и что там ещё бывает). Я, честно говоря, вообще не уверен, что Вы рассмотрели Джава-мир, т.к. очевидно, что M$ всегда себя ему противопоставлял (хотя в какой-то момент даже был Microsoft J++)

Вот есть ещё biased опрос www.jetbrains.com/research/devecosystem-2018
Маков реально много
Я рассматривать опрос на Stack Overflow. Да, это не 100% объективность — но уж явно ближе к истине, чем опрос среди пользователей продукта, который, автоматически, просто по определению, игнорирует самую большую группу — разработчиков, пользующихся Visual Studio.
Анализ статистики дело сложное. Я честно сказал, что опрос на сайте JetBrains не может не быть biased. Но и на SO тоже, если подумать. Или Вы правда верите, что все разрабы, во-первых, участвуют в опросах SO (мое время сейчас ценнее, чем эта фигня), а, во-вторых, вообще там присутствуют (с какого-то момента мне там стало неинтересно, но иногда (т.е. =редко) ресурс мне помогает в решении проблем).
UFO landed and left these words here
Написать обход по дереву процессов с передачей сигналов 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) «хвост по частям» отрезали.
линух прикончит системда, когда оно «срастётся» с кёрнелом и гномом в [практически] монолит

Андроид и есть сросшийся монолит на основе Убунту, но он жив.
UFO landed and left these words here
Погодите — а что в Android от Ubuntu? Libc там своя, init — тоже, gcc/clang — тоже, вроде как, не изобретение Ubuntu…
Как мне кажется, похожая история происходит с файловой системой ZFS. По сути это просто офигенная технология. Хотя бы одно то, что можно автоматически делать снапшоты при обновлениях и откатывать всю систему при желании за долю секунды, делает ОС на её основе уникальной. Ну и во многих других отношениях это очень крутая файловая система. Однако мутный юридический статус мешает её признанию, пока только Ubuntu её официально и полноценно поддерживает, да и та не из коробки и без задействования её фич. Боюсь, так и не «выстрелит» она.
Снапшоты есть уже давно в btrfs и xfs, так что да… «скрипач не нужен»…

и не снапшотами едиными… xfs — это вообще каменный век в купе с ext*, jfs, ntfs, hpfs… я вот на zfs ~10 лет храню данные своих серверов и рабочих станций (zfs volumes only). а вы btrfs так используетете?
вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.

вот в этом и разница между декларировать [возможность хранения данных на btrfs] и делать это [хранение данных] настолько хорошо, чтоб перестать об этом задумываться.
«Перестать об этом задумываться» нельзя как минимум до тех пор, пока она из коробки на большинстве дистрибутивов не будет доступна. А посылок к тому, чтобы это случилось — как не было, так и нет.
пока она из коробки на большинстве дистрибутивов не будет доступна

извините, но это ваши линусячьи проблемы ;)
зато докер [через stdio] работает :)
каждому — своё...

А что для вас «вышла из беты»? У меня на ней основная система, с которой эти строки пишу, стоит. А ждать, покуда кто-то другой заявит «всё, можно пользовать» — то такое, можно всю жизнь прождать: новые фичи там всё время появляются, так что что-нибудь всегда в бете будет. Главное — перед использованием взглянуть на статус, чтобы потом не плакать…

А то есть любители на ней RAID6 поднять, а потом плакать…
У меня на ней основная система, с которой эти строки пишу, стоит.

ну, авантюризм, в общем случае, присущ некоторому количеству человеков.
остаётся только пожелать удачи вам и вашим данным :)


А то есть любители на ней RAID6 поднять, а потом плакать…

а как без RAID данные будут в сохранности?

А как же бекапы? RAID решает одну задачу, бекапы — другие. И желательно бекапы куда-то в другое место.

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

В случае если они терабайтные — может и больше. Вот только мой опыт показывает, что происходит это не настолько часто, чтобы поверх SSD ещё и 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 на пару десятков терабайт, спокойно заменить наживую, не прерывая работы, один (или несколько одновременно) вышедших из строя дисков
А зачем вам несколько десятков терабайт дома и куда вы бекапите с них данные???

Просто интересно — чем нужно заниматься, чтобы в этом возникла потребность…
Серверные диски это расходники. SSD тем более. Если у вас нет гугловой инфраструктуры с тысячами серверов и натягиванием образа на новый в течение минут при умирании старого, рейд это самый разумный способ организации хранения, чтобы не прерывая или не сильно прерывая работы обслуживать типовую ситуацию отказа одного из дисков. Бэкапов это не отменяет, но восстановление из бэкапа может занимать дни, поэтому бэкапы это как последний бастион, до которого лучше не доводить.
ZFS RAIDZ не привязаны к контроллеру, напротив — для ZFS крайне желателен прямой доступ к устройству. Нет прослойки в виде контроллера — нет опасности повреждения им данных. В идеале — вы просто скармливаете ZFS сырые диски. Проблема на новых FreeBSD в этом случае только в отсутствии возможности включить статическую нумерацию дисков по порту контроллера без пересборки ядра, поэтому всё же приходится накатывать ZFS поверх GPT-лейблов.

У меня на домашнем сервере 6 4Тб дисков в RAIDZ2. ZFS равномерно размазывает данные и контрольные суммы по дискам, согласно каким-то там своим алгоритмам. Диски можно произвольно тасовать в корзине, данные сохраняют целостность при потере двух дисков, никакой привязки к конкретному контроллеру — вы можете воткнуть диски в любую машину с достаточным количеством SATA-портов, и массив соберётся.

Минус — при битой оперативке возможно повреждение данных, я видел такое, но, что характерно, после замены памяти на нормальную scrub устранил ошибки без порчи данных.
В идеале — вы просто скармливаете 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 и свопы, правильно и уникально их пометить, чтобы массив гарантированно собрался на любом оборудовании, и пр.
Проблема — в плане возможности физических манипуляций с сырыми дисками, если их нумерация динамическая, а не привязана к порту контроллера, как, если не ошибаюсь, в Солярисе. Да, само-собой, GTP-лейблы дают бОльше возможностей по переносимости массива.

Основная — в смысле — ноутбук (или рабочий компьютер-десктоп)? Ну, у меня тоже. И что? OpenSUSE по умолчанию на btrfs ставится. В этом есть и плюсы, и минусы.
Минусы — например, нужно следить за местом при zypper in чего-то угодно, т.к. создается снапшот. И место тает на глазах.
Из плюсов — работает быстро и относительно стабильно.
Но тащить это на продакшен в сервера… ну, такое.

Но тащить это на продакшен в сервера… ну, такое.
А в production требования к фс как раз ниже, чем на десктопе. В ext4 режим работы без журнала существует именно для гугловых серверов, если вы не знали.

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

А если налажен — то нафига вам журналирование, RAID и всё прочее?
Потому что если у вас не налажен процесс восстановления при внезапном умирании сервера (ну там пожар, наводнение и просто «пробой» в блоке питания — неважно) — то вы таки сильно рискуете.

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

нет, не знал :-) И какую цель они достигают таким образом? Быстродействие ФС на значение 100%?
Просто в случае работы без журнала и с не очень продакшен ФС типа btrfs мне лично стремно — даже не потому что будет отказ, а не будут ли превращены данные в фарш, причем я об этом узнаю не сразу, а когда-нибудь потом?
А если налажен — то нафига вам журналирование, RAID и всё прочее?

Обеспечение низкого RTO.

Но вообще — да, учитывая, что резервирование есть и на других уровнях (ну, например, ВМ работают поверх какого-то реплицированного стореджа) мы реально греем воздух лишними «защитами»
нет, не знал :-) И какую цель они достигают таким образом? Быстродействие ФС на значение 100%?
Да. Собственно этот режим там появился, когда встал вопрос «что делать с ext2». Всем казалось, что про неё все забыли… а оказалось, что Гугл её на серверах использовал — потому что бессмысленно использовать ext3 как основу для GFS.

В ext4 добавили режим «без журнала» и всем стало хорошо.

Просто в случае работы без журнала и с не очень продакшен ФС типа btrfs мне лично стремно — даже не потому что будет отказ, а не будут ли превращены данные в фарш, причем я об этом узнаю не сразу, а когда-нибудь потом?
А вы от этого никогда не застрахованы. Достаточно чуть-чуть глючного контроллера дисков — и всё, ваши данные будут превращены «в фарш» без всякого участия файловой системы и операционки.

Спасают только контрольные суммы — и то до некоторой степени (процессор ведь тоже может глючить).
Вообще-то спасает ZFS (особенно вкупе с ECC-ОЗУ); вот коротенький тред на эту тему, в качестве бонуса там есть ссылка на исследование поведения ZFS на битых дисках и памяти. Вообще народ хайдокал ZFS, что называется, в хвост и в гриву; случаев превращения данных «в фарш» я лично не припомню (в отличие от Btrfs, которая может ничтоже сумняшеся убить файлуху целиком из-за банальной kernel panic).
А что для вас «вышла из беты»? У меня на ней основная система, с которой эти строки пишу, стоит.
Ох… Мы её иногда вспоминаем в профильной теме на iXBT, народ делится впечатлениями. Ну, знаете, такое (и это пишет человек, btrfs и линуксу в целом симпатизирующий).
А то есть любители на ней RAID6 поднять, а потом плакать…
Да имхо ничего не надо на ней поднимать. :-) Есть стабильная, фичастая и всё умеющая ZFS. Хочется стоя и в гамаке толком не работающую и находящуюся в вечной альфе/бете Btrfs? Дело хозяйское. Впрочем, если бы она работала, одно реальное преимущество перед ZFS у неё вроде как есть: можно добавлять диски в уже созданный массив RAID5/6.
Впрочем, если бы она работала, одно реальное преимущество перед ZFS у неё вроде как есть: можно добавлять диски в уже созданный массив RAID5/6.
Реальное преимущество у неё одно: одна работает и «каши не просит» — до тех пор пока вы не начинаете использовать вещи, которые на официальном сайте помечены как неработающие.

RAID5/6 ни в одной версии btrfs стабильным объявлен не был — потому я никак не могу понять откуда такое маниакальное желание таки его включить и поиметь неприятностей на свою задницу.

Без бекапов всё равно жить нельзя, а надёжность современных SSD такова, что смысла в RAID я сейчас не вижу нигде — ни на рабочей станции, ни, тем более, в production.

RAID — это пережиток тех времён, когда компьютеры разнимали целую комнату и представить что у кого-то их будет десяток было нельзя. Сейчас же, когда в одном датацентре у вас могут быть десятки тысяч компьютеров смысла в нём никакого: если у вас компьютеров много — то вы должны быть готовы к тому, что их часть будет время от времени умирать целиком — вместе со всеми данными, а если вы к этому уже подготовились, то зачем вам, я извиняюсь, RAID?
RAID — это пережиток тех времён, когда компьютеры разнимали целую комнату и представить что у кого-то их будет десяток было нельзя. Сейчас же, когда в одном датацентре у вас могут быть десятки тысяч компьютеров смысла в нём никакого: если у вас компьютеров много — то вы должны быть готовы к тому, что их часть будет время от времени умирать целиком — вместе со всеми данными, а если вы к этому уже подготовились, то зачем вам, я извиняюсь, RAID?

как вариант — legacy enterprise приложения, которые спроектированы именно для работы в режиме сингл инстанса. И которые не умеют горизонтально скейлиться, а только вертикально…
как вариант — legacy enterprise приложения, которые спроектированы именно для работы в режиме сингл инстанса. И которые не умеют горизонтально скейлиться, а только вертикально…
В этом случае вам можно только посочувствать… и посоветовать обратиться к IBM: z/OS — это как раз для вас. Но причём тут FreeBSD или Linux?
Извините, зачем мне z/OS, если конкретный софт под нее не заточен (а под Windows/Linux, край — BSD). Да и архитектура целевая — x86-64
Оличная фраза, пожалуй, надо запомнить. Заказчикам буду так говорить: «Чего пристали, у нас всё работает, кроме того, что не работает. Не пойму, что вас не устраивает?»

Про RAID вообще эпично, во-первых, то, что вы лично его нигде не видите, это ваши трудности, я вот постоянно сталкиваюсь с рейдами того или иного вида; во-вторых, рейд это не только про дублирование данных, это еще и про скорость.
Заказчикам буду так говорить: «Чего пристали, у нас всё работает, кроме того, что не работает. Не пойму, что вас не устраивает?»
А вы являетесь заказчиком btrfs? Оплачивали работы по разработке RAID6? Когда и сколько?

Про RAID вообще эпично, во-первых, то, что вы лично его нигде не видите, это ваши трудности, я вот постоянно сталкиваюсь с рейдами того или иного вида;
Ну если вы, почему-то, хотите тратить деньги на snake oil — то это ваш выбор… но причём тут btrfs?

во-вторых, рейд это не только про дублирование данных, это еще и про скорость.
Скорость — это RAID0. Он отлично в btrfs работает.
О, пошли Ad hominem аргументы!
Так вы определитесь, Btrfs таки работает и есть не просит, или всё таки есть проблемы?
btrfs работает ровно в том объёме, в каком написано на сайте.
Не то чтобы это играет роль, но оригинал датирован April 10, 2017. Конечно, мир BSD за это время не изменился так уж сильно, но… Мне кажется, впору было написать пост по мотивам этой статьи почти двухгодичной давности.

P.S. Про качество оригинала даже не буду писать, человек написал «очень свою» точку зрения — и, так кажется, мысль вызвать холивар у автора была не на последнем месте.
У некоторых хостеров в вариантах выбора системы для KVM до сих пор есть вариант FeeBSD. Кто то в настоящее время пользуется? Меня интересует как BSD ведет себя на малонагруженных системах (пару тысяч уников в сутки) при работе на машинах с 512 и 1024 Мб? Интересует связка LEMP. Или из за того, что софт с Lin системами идентичный разницы нет?
Я использую. В том числе для пэт проектов. Какой-то дешевый 1CPU, 1Gb.
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 мьсе о-Торвальдс… то ли вопрос оказался для него плёвый, но с мёртвой точки в правильном направлении столкнул...

Совершенно точно про сообщество. Во FreeBSD оно, конечно, насколько меньше, но и настолько же более компетентно.

Отличная статья. Читается с удовольствием.
Кто- то согласится, а кто-то нет. Вечный спор о том, что побеждает. В системотехнике есть даже теорема о « замкнутых системах и циклах развития»

«она была по сути первой open source операционной системой в истории»

А какой тогда была OS/360, нулевой?
У FreeBSD не было своего RedHat'a и Ubuntu, а также огромного комьюнити как у линукса, все это явно способствовало популярности и маркетингу. По-моему всем давно известно, что выигрывают не лучшие программы, а популярные. (Я не утверждаю что линукс хуже FreeBSD!)
Насколько вижу тенденции в технологии, то это уменьшение важности хоста и его надежности, взамен этого упор идет на High Availability и распределение по клаудам. Так что можно хоть на распберри сервера свои держать, лишь бы их был миллион — половина сгорит в вулкане, треть потонет в цунами — а остальное будет работать и сервис будет доступен как ни в чем и не бывало. А что там под ним, и насколько оно надежно — пофигу по большому счету. Как и глючные программы это нормально — половина упадет в сегфолты, зато другая половина будет работать. Очень повышается общая толерантность к ошибкам, будь они в системе или в коде. Отсюда и популярность облаков, кубернетис, контайнеров и т.д. и т.п. И походу это и есть будущее.
Некоторые так называемые девопсы уже и не знают даже на какую они систему деплой делают — в амазон, а какая там ОС и не догадываются :) И они уж точно дебиан от сентоса, а их всех от FreeBSD не отличат. Так что наши тут холивары это уже беседы на лавочке.
На самом деле
Некоторые так называемые девопсы уже и не знают даже на какую они систему деплой делают — в амазон, а какая там ОС и не догадываются :

это пугающая перспектива. Т.к. большинство людей и не понимает, что у них под капотом систем, которые они используют. Обычно это не проблема, но иногда из-за этого случаются эпичные фейлы. Или решение инцидента становится дольше и сложнее.
Ну, и вообще — действительно SRE о бюджете ошибок и простоя и эффективном их управлении
> У FreeBSD не было своего RedHat'a и Ubuntu
Было, вроде даже не по разу же. ubuntuBSD, Debian GNU/kFreeBSD…
UFO landed and left these words here
Порог вхождения снизился, и мамкины хакеры подались в Линукс. 95% из них побалуются, и поняв, что их любимые игрушки на Линуксе не запускаются — снесут его. Но некоторые из них через несколько лет подадутся в админы, и сработает синдром утёнка — «единственная альтернатива Виндовс — это Линукс, а лучший Линукс — это Убунту, потому-что там уже всё есть, и всё просто, потому-что такому занятому человеку как я — некогда компилить что-то или копаться в конфигах».
Вы всё прекрасно описали, но так и не ответили на вопрос: что делать-то? Сетовать на то, что мир несовершенен и люди, зачастую, действуют как утки, а не глубоко вникают во всё (и тратя по три часа на то, чтобы шнурки завязять, да) — не слишком-то конструктивно…
А зачем что-то делать? Ну, то есть, изначально ведь такой вопрос не ставился.

Есть ситуация, которая сложилась так, а не иначе. Ситуация никому ничем не угрожающая, кроме постепенного увеличения громоздкости операционных систем, кода, и снижения качества кода, эффективности использования аппаратных средств, и прочего. Это неприятно, но от индусского кода ещё нннко не умер (по крайней мере массово).

Кргда будем ставить операционную систему на межзвёздный корабль — будем думать, что лучше, и вылизывать код, а пока — смысл есть ли что-то делать?
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.