чот, коллеги, вы тут экстремизьму почти накрутили. надо помнить что: - память была дорогой - multi-instance library object (aka versioning) не существовало - концепция изоляции сервисов друг от друга (и, соответственно, организации IPC для изолированных сервисов) не существовало

мы всё ещё посреди сильно переделывающего процесса

чот, коллеги, вы тут экстремизьму почти накрутили. надо помнить что: - память была дорогой - multi-instance library object (aka versioning) не существовало - концепция изоляции сервисов друг от друга (и, соответственно, организации IPC для изолированных сервисов) не существовало

чойта? они уже даже на юниксах были, изоляция процессов с IPC

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

чойта? они уже даже на юниксах были, изоляция процессов с IPC

IPC было, изоляция была только по фрагментам памяти, не по библиотекам (а вы обсуждаете именно это)

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

вот простой вопрос "в лоб" - на Mac OS X есть пакетный менеджер? ))

нет, "везде" это все операционные системы, кроме линукса

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

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

ни в коем разе, дистрибутивы не являются самостоятельными ОС

вот простой вопрос "в лоб" - на Mac OS X есть пакетный менеджер? ))

нет, и макось не юзабельна (имхо)

вот простой вопрос "в лоб" - на Mac OS X есть пакетный менеджер? ))

Я слышал что без homebrew там жизни нет

вот простой вопрос "в лоб" - на Mac OS X есть пакетный менеджер? ))

есть, и сильно более одного (и, да, на этом все отхватывают) а "официательного" — ннуу, есть, но сильно спрятан

охлол

Ну начнем с того что линукс это ядро, а пакетных систем на нем десятки. Так что "везде" как раз пакеты. А в bsd этот атавизм просто тянется с допакетной эпохи и надеюсь скоро наконец скончается, по крайней мере на фре

Хрена ты контр революционер

А как вам такая мысля :

с точки зрения ОБЫЧНОГО юзера как раз макось ОЧЕНЬ юзабельна

потому что ты просто перетаскиваешь иконку dmg и всё!

BSD это принцип построения системы

вот тебе инсталл

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

Не спецификация или стандарт

А ряд принципов

Не самых гласных правил

Они же живут долго

В мэйлинглистах

и Поттеринг щас по факту предлагает альтернативную пакетам систему на снапшотах fs/контейнерах

как альтернативу пакетам

Он не первый

поэтому всегда надо идти от истока, а не считать, что как в линуксе - это острие прогресса, и ваще линуксов больше всех

И не последний

кагбе, надо не спрашивать, "в чем дзен базовой системы", а пойти от истоков

Не хочешь от истоков тогда выпилить kqueue/sendfile?

Вспомните про Fat ELF

BSD это принцип построения системы

это не BSD, это называется философия Unix way

Да нет никаких принципов. Поэтому и debian/kfreebsd возможен, и ravenports и pkgsrc на linux/freebsd/macos

с точки зрения ОБЫЧНОГО юзера как раз макось ОЧЕНЬ юзабельна

я тоже обычный юзер. т.к. критерий обычности не определен

это не BSD, это называется философия Unix way

Ох, а я-то думал почему книжка так называется

Про unix

Да нет никаких принципов. Поэтому и debian/kfreebsd возможен, и ravenports и pkgsrc на linux/freebsd/macos

и все они почему-то более мертвы, чем живы, лол

А все контейнеры просто уровень абстракции над пакетами

В какой-то пасте с зк сосача рекомендовали

А все контейнеры просто уровень абстракции над пакетами

необязательно

и все они почему-то более мертвы, чем живы, лол

Это дело десятое

нет, предки заповедали делить /bin и /usr/bin и мы будем ибо есть это благодать

и все они почему-то более мертвы, чем живы, лол

ну а вот какой юзкейс у kfreebsd?

Это дело десятое

нет, не десятое

А я не дочитал, кек

эксперименты всегда существовали и будут существовать, это не отменяет наличия принципов

парадигмы даже, скажем так

ну а вот какой юзкейс у kfreebsd?

Такой же как у debian/hurd

кагбе, надо не спрашивать, "в чем дзен базовой системы", а пойти от истоков

ну а вдруг есть дзен и удобство текущей организации, а значит их надо понять

необязательно

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

Не хочешь от истоков тогда выпилить kqueue/sendfile?

судя по возникшим вопросом, до этого мы доберемся в обсуждении эдак завтра ))

https://i0.wp.com/channelingvsem.com/wp-content/uploads/2017/05/%D0%98%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B5-%D0%A1%D0%BA%D1%80%D0%B8%D0%B6%D0%B0%D0%BB%D0%B8-%D0%91%D0%BE%D0%B3%D0%B0..jpg?resize=300%2C257

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

нет, не обязательно, потому что то, что разделено в апстриме, вовсе не обязано быть таковым и локально по типу в виде сущности типа "пакет"

А все контейнеры просто уровень абстракции над пакетами

Нет, хотя ядро ничего не знает про контейнеры

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

когда вендор тебе сразу слепок всей системы - хлоп

а то, что сам вендор внутри себя компилит из апстрима и стыкует версии, ну и во фре так с contrib всегда делали

нет, не обязательно, потому что то, что разделено в апстриме, вовсе не обязано быть таковым и локально по типу в виде сущности типа "пакет"

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

Нет, хотя ядро ничего не знает про контейнеры

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

А объединить этот набор в одну сущность не получится уже никак, поскольку поддерживать это будет невощможно

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

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

А объединить этот набор в одну сущность не получится уже никак, поскольку поддерживать это будет невощможно

крайне спорная заява

коммерческие производители ОС так делали десятилетиями, и ничего.

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

А зачем?

ERROR: S client not available

ну т.е. "чего" (привет винде), но отупение массового юзера и уход в облака могут снова сделать это не актуальным

А зачем?

смотря как архитектору было удобнее

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

Присоединюсь к тем, кто за базовую систему во FreeBSD. Всегда нравилось, что жизненый цикл системы и ПО не зависит друг от друга. Хочешь - используй порты/пакеты. Всегда можнешь почти безболезненно снести /usr/local и /var/db/pkg и начать жизнь с чистого листа. ОС как обновлялась, так и будет далее. И установка кривого пакета никогда не разнесёт тебе систему. Хочешь - вообще пиши свою пакетную систему и используй её вместо дефолтной - ОС как обновлялась, так и будет. Если при замене freebsd-update на pkg эти кейсы и их производные не сломают, мне, в принципе пофигу. Но ИМХО - сломают.

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

уже звучал пример с макосью

уже звучал пример с макосью

И где в макоси, скажем, блендер?

и да, тащем-то в 80-е так и было "сразу все существующие приложения", надо больше, вот тебе компилятор

И где в макоси, скажем, блендер?

там в телеге наверху есть кнопка с лупой, набери туда dmg

Ну так это и есть пакеты

да щазз

для человека, предпочитающего пакеты (и пакетные менеджеры), это пиздец, а не пакеты

а для простого юзера - удобно! просто поставить, просто снести

Да никакой разницы, на dmg кликнуть, rpm или иконку порта в каком-нибудь графическом менеджере

есть разница

кто пользовал - или пытался пробовать - PCBSD еще давно, а потом попозже, может вспомнить PBI

смотря как архитектору было удобнее

См cilium, где дошли до того, что политики изоляции генерируются на лету и транслируется в ebpf. все это поверх плоской v6-сети

А что кстати с PBI стало? Закопали? Почему, может знает кто?

потом они от них отказались в пользу pkg (и это вышла самая удачная ветка PCBSD, на базе 10-ки)

А что кстати с PBI стало? Закопали? Почему, может знает кто?

ну потому что тяжело это, если ты не коммерческий вендор

Кому сейчас нужны пакеты, когда есть docker?

Кому сейчас нужны пакеты, когда есть docker?

кхе... ты хоть за полчаса лог перечитай штоле

ну потому что тяжело это, если ты не коммерческий вендор

Развей мысль, если не сложно. Тяжело - что именно? Собирать "самодостаточные" пакеты?

Кому сейчас нужны пакеты, когда есть docker?

тем кто не очень хипстер

Развей мысль, если не сложно. Тяжело - что именно? Собирать "самодостаточные" пакеты?

самодостаточные собирать действительно намного сложнее, чем обычные.

например, flatpak vs deb

фряхопакеты я еще не собирал, но там будет примерно как deb

самодостаточные собирать действительно намного сложнее, чем обычные.

Смотря наскольлко самодостаточные. Имел разнообразный опыт.

или RPM

Смотря наскольлко самодостаточные. Имел разнообразный опыт.

ну частично саомдостаточный вряд ли имеет большой смысл

например, flatpak vs deb

flatpak ещё не пробовал, но сборке deb паектов - это на любителя, мягко говоря. Я блевал.

тем кто не очень хипстер

Спорно. Вот есть условный веб-сайт с nginx + php-fpm + mysql + redis. И надо его быстро перенести на другую машину.

Спорно. Вот есть условный веб-сайт с nginx + php-fpm + mysql + redis. И надо его быстро перенести на другую машину.

zfs send + zfs receive