У чому перевага BSD перед Linux?

[BeSiDa]

пишіть як є - обидва і БСД і ЛінуКС не для філософів, а то філософський модуль.. філософський модуль..)

То у вас якісь не ті лінукси та бсд, ви хоч пошукайте філософію в пакетах апт ("This package has a simple philosophy...") ))

[BeSiDa]

ФріБСД не для користувачів

я б так не сказав, в мене взагалі спеціальність не ІТ, але FreeBSD познайомила краще з UNIX чим Linux, NetBSD показала як добре портувати код на різні архітектури і взагалі, як в них розбиратись.

Ви дуже добре розписали що ви є "користувачем сорців", а не "користувачем продукту/інтерфейсу". Для "користувача продукту" все що є Юніксом не цікаво взагалі. Їм цікаво "щоб працювало" та "як пофіксити" і не більше того
Юнікс то взагалі народився в універах (тобто в лабораторіях) де професії були різні. Та й тоді не існувало такого слова ІТ.

[BeSiDa]

Підтримка cpu arch то далеко не все, для мобайл залізок більший стоппер то підтримка заліза периферії, тому на мобайл девайсах дуже малоймовірно що побачите *bsd.

То не про "залізо". Ви коли-небудь чули такий термін "софт-модем"? Де від "заліза" тільки мінімальний "огризок", а все інше то "залізо емульоване софтом".

[BeSiDa]

Де є мейнтейнер порту і він підтримує пакет, я знаю кому писати і де шукати відповідь.

Та не в тому сенс. Ви ж бачили з яких саме файлів складений "порт"? Заглядали в них?
"Порт" не містить в собі "сорців" (на відміну від пкг-срц). Він містить урл для скачування з сайту розробника софта та чексум.
І ще "патчі". Поки їх розробник не додав у софт.
Тому треба першим чином писати автору софта і лише потім мейнтейнеру.
Та й взагалі можна збирати з сорців автора, а не з порту.
Тобто бсд то "бути повноцінною частиною фрі соурс середовища" (разом з фідбеком). А не тільки "користувачем інтерфейсу".

[yvs115]

Збирати і шукати то різні дії

Але час займає, в моєму випадку, я хоч знаю що робота йде, підтримка якщо щось є

так у чому саме легше знайти в ports/pkgsrc у порівнянні з відповідно мабуть debian?

З src чому збирати незручно, для прикладу, принаймні - (1) довго, (2) потребує додаткового dev env для того

Я пишу просто для установки # make install clean, час на збирання залежить від величини проекту, далі ports все по Makefile залежності компілює сам, я нічого не шукаю, особливо коли в лінуксі я шукав залежні бібліотеки, залежної бібліотеки.

в debian з apt/dpkg не зустрічались такі проблеми, але якщо ближче щось до простоти написання маніфестів для пакетів - то з arch (напевно найпростіший варант) і зручно в aur маніфест для свого пакета

Далі якщо ПК чи ноутбук дозволяє то можна компілювати в декілька потоків make -j4, щоб швидше було. В мене коли збирається програма, це в окремому віртуальному вікні, далі я можу робити справу далі, а не просто сидіти і дивитись, як збирається пакет

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

У випадку ports/pkgsrc додається ще незручність - можливість розсинхронізації з бінарним репо

Ні, за всім слідкує менеджер пакетів, якщо щось, то в залежностях відбувається часто виконується make rebuild, та перебирається під пакети що користуються . Я розумію про що ви, я зустрівся з таким коли обновляв систему, але до певної версії почались викидати помилки, на сайті мені допомогли, не пам'ятаю точно утиліти типу poudriere і за ніч пересборок, все відновилось, хоча я думав буде довше. Головне що я не ставив систему заново.

У мене також були деякі складнощі під час розсинхронізації - коли частина була з bin репо а частина зібрана з ports/pkgsrc. Тому для себе зазвичай обираю - або все з ports/pkgsrc або з bin repo (без змішування двох підходів).

Без різниці де (якщо в рамках нп пакетизації) залежності мали бути прописані мантейнером

В лінукс деяких популярних дистрибутивах часто свіжий софт лежить на сайті як виходить.

тут треба більш конкретики - бо нп якщо працювати з чим-небудь на зразок dart/flutter - то це окрема категорія софта зі своїми власними апдейтами-апгрейдами та засобами для того поза системним пакадж менеджментом (в тому числі і модулі/пакаджі/etc з тим)

От тоді і морока, виходить потрібно шукати so, бо часто виробник не хоче зв'язуватись з залежностями, він викладає elf свого продукту

чесно кажучи знову не зовсім ясно, можливо це відносно 3rd party софта - так те саме і в bsd буде, і взагалі то говорили відносно системного пакадж менеджменту

Теж саме і навпаки - якщо в лінукс збираєте в рамках пакетизації, а в bsd поза тими рамками - квест буде в bsd, а в лінукс ні

І хто його збирає в лінукс?

кому треба той збирає, якщо вважаєте що з тим самим рівнем користувачу буде легше в bsd - то не так

можливість конфлікту з софтом що ставиться поза ports - бо все йде в одну і ту саму /local/. В linux саме цих недоліків якраз і немає.

якщо компілювати пакет ./configure && make && make install  , в не пакетним менеджером, то і в лінуксі це може бути проблема, давно читав про це новину, як раз і розробник лінукс ( ніби Лаборант Поттерінг, так давно було до не пам'ятаю хто ) просив менше користуватись таким способом і розповідав про наслідки і які можуть бути випадки, так що лінукс від цього не застрахований.

системні пакети попадають в /usr, щось своє непакетоване чи інший софт непакетований (не тільки зібрані з autotools, є ще інші опціїї автоконфігурування) зазвичай в /usr/local. Чи можуть бути при цьому нюанси - нп з питанням лінкування однакових ліб з якої локації робити - можуть бути. Але це робочий момент, а не сетап і пакаджів системи і свого софта нп в одну локацію з /local/ в fbsd.

І debian, redhаt просили не ставити так програми, бо більше плутанини в пошуку помилки. Саме тому я читаю про pkgsrc, ports і можу зробити свій тестовий пакет, є документація і вона відкрита.

так і в лінукс запакетували і питань нема, по легкості пакетування в лінукс залежить від дистро (для мене нп найпростішими то були підходи в arch та в alpine) - це я порівнюючи з пакетуванням в fbsd/nbsd бо з obsd рідше працював там не пакетував

Всі ми знаємо Debian де є розділення на stable, release, unstable

Саме такого розподілу з release у назвах в debian нема

Є, до теж Ubuntu це debian unstable

release - такого нема в debian, "release" то з freebsd (і для звичайного користувача то те що очікується з назвою stable, а не навпаки як у fbsd)

Різні дистро мають різне бачення на швидкість змін, і у лінукс є різні дистро по всій шкалі - як консервативніші за bsd, так і дистро з повним rolling).
 

і з тим зоопарком дистрибутивів нічого хорошого немає

А ніхто всі зразу (чи навіть декілька) використовувати і не примушує - кожен щось своє обирає чи під потреби/задачу які зустрічаються.
Обмеженість вибору (як у bsd дистрибуції) - я би не відносив до плюсів від слова зовсім.

так перемішайте в bsd різні release stable current потім і порівняйте де то більш трабл видасть)

Ні, поставиш ти реліз чи розробку в freebsd порти ставиш з одного місця

то поки вони не розїхалися достатньо -  нп не оновлюю pkgsrc деінде бо занадто давно вже не оновлював систему
Тому варіант як в лінукс коли є цикл життя якоїсь версії системи - і в рамках того йде оновлення пакетів - достатньо зручний

в лінуксі я ж зустрічався що помилка була в несумісності glibc, і за того що підключив ще репозиторії

щось зламати невідомо що підключивши і достатньо незнаючи як з тим працювати - можна де завгодно

не бачу необхідності, сидіти і збирати систему ночами, яка не буде нічим відрізнятись від тої що зібрано, навіть флагами компіляції -О2 чи -О3 за якої програми падають, це вже давно доведено, але людям подобається за цього вважати себе супер користувачами чи продуктивними користувачами. Це вже кому як подобається.

колись то вважалося деякими (може і зараз кимось) - тру bsd way

Підтримка cpu arch то далеко не все

Вже давно не показник, з років так 2010 точно, виставляти відкритим проектам ОС:
- нашу ОС можна компілювати з відкритого коду яка в репозиторії
Всі скажуть що це можна і в лінукс, bsd, opensolaris, plan9, freedos ...
- наша ОС безпечна
Всі скажуть що використовують системи безпеки і є навіть мейнтейнери які відповідають за безпеку в ядрі чи userspace

Тут не ясно то до чого знову. Поінт з "cpu arch то далеко не все" був в томущо зібрати щось з базово-системного під якусь архітектуру не проблема зазвичай, але що вам з того що ядро крутиться якщо нп не буде працювати чи екран чи вайфай чи ще щось на мобайл девайсі.

[yvs115]

Для "користувача продукту" все що є Юніксом не цікаво взагалі. Їм цікаво ...

з юнікс для кого то і що цікаво - нецікаво, а от що цікаво в юнікс філософам з тим "Їм цікаво"?)

[res2500]

Ви дуже добре розписали що ви є "користувачем сорців", а не "користувачем продукту/інтерфейсу".

Поки ні, лише досвід що "набив", так щоб вважати себе спеціалістом

Та не в тому сенс. Ви ж бачили з яких саме файлів складений "порт"? Заглядали в них?

Звичайно знаю, я вже писав що сам маю свої pkgsrc, часто код міститься в GitHub, sourceforge, тому там окремі змінні з ними робити, ${MASTER_SITE_GITHUB ..., тому я знаю що архіви з кодом знаходяться на різних запасних зеркалах

Для "користувача продукту" все що є Юніксом не цікаво взагалі. Їм цікаво "щоб працювало" та "як пофіксити" і не більше того

Не знаю що кому, наприклад, як появився systemd, користувачів лінукс питали про переваги на ПК, вони відповідали що ПК швидко завантажується і вимикається, висновок зробили всі, що люди з лінукс тільки вмикають ПК і вимикають.
 В мене був старий ПК, який мені підходив, та смисл брати новий не хотів, ХР вже на ньому  ледве робила, я почитав про лінукс і старий ПК, та спробував, на той час Федора 16 впала після встановлення пакетів і ніхто не сказав що робити, інші дистрибутиви особливо теж не зайшли, працювали і в один момент не завантажуватись, всі групи і сайти лиш писали про криві руки, тут мені знайомий скидає сайт freebsd і говорить спробуй, є сайт і документація там, почитав, поставив, помалу і X поставив, все працювало, ставив пакети, збирав якщо хотів в ports, нічого не падало, так, були помилки коли в /boot/loader.conf записав не правильну конфігурацію, в single user я монтував ФС в режим читання і запису, та виправив конфіг файл, і все перезавантажилось і завантажилась система, без перевстановлення, я не дивився особливо на робочий стіл і як він виглядає, мені потрібна була програма, я працював в сервісному центрі, десь в 2010 році в нас виникла проблема, з ліцензією і хто хотів перейшов на лінукс, але як виявилось, погрались і дальше на віндовс перейшли, хоча так описували arch, suse ... В мене такі пакети як ida pro, ponyprog2000, де часто ніхто залежності не ставить з тим архівом, і для запуску, потрібно шукати so які вона скаже, як там зараз, не знаю, але в 2017 році знайомий ще питав, де я знаходив для ponyprog бібліотеки, бо знайти не може, і в репозиторії немає
 Далі ситуація, знайомий писав, вчить qt і не може по репозиторіїв знайти QtNetwork, питав як там в freebsd її знайти, я відповів де його в freebsd знайти, в убунту, щось ніхто не підказав,і apt search не допомогло, от так, перейшов на віндовс

[res2500]

так у чому саме легше знайти в ports/pkgsrc у порівнянні з відповідно мабуть debian?

А що це дасть ? Не факт що репозиторії які є оновлюються і є всі пакети, повірте, це пройдений варіант, а так ти хоч бачиш кількість пакетів, які є в підтримці. А не шукати ебілд, чи чекати ebild. Ми спостерігали в середньому репозиторії власні, це на два три роки актуальності, а дальше про них забуває автор

в debian з apt/dpkg не зустрічались такі проблеми

У вас може не зустрічались проблеми, але https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014515    це не означає що їх немає, проблеми і баги є всюди, ідеального варіанту немає, я зустрічався з проблемами so not found,

якщо є можливість поставити вже зібраний пакет з репо

Це точно, якщо він є, сам ставлю elf, а як нема, в мене є варіанти, я писав що збираю

то це окрема категорія софта зі своїми власними апдейтами-апгрейдами та засобами для того поза системним пакадж менеджментом

Ні, Arduino раніше в репозиторії стара версія, а нова на сайті, через дві три неділі нова версія попадає в репозиторії, знову ж таки, як зараз не знаю, раніше було так. Особливо коли ти ждеш коли пофіксять баг який розділяє бібліотеки і платформи, а викидає помилка коли ти вибрав esp32 плату, а воно компілювати хоче його в avr, і ти вже десять раз глянув що ти не вибрав avr, бібліотека для еsp32 в include. Arduino 1.8 все зібрала і зробила з тими ж умовами, тому в ports/pkgsrc мені буває потрібно створити декілька версій пакетів з різними версіями, я їх можу створити gcc45, gcc49, пакетний менеджер це дозволяє

чесно кажучи знову не зовсім ясно, можливо це відносно 3rd party софта - так те саме і в bsd буде, і взагалі то говорили відносно системного пакадж менеджменту

Почитайте про помилки

https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fbugs.debian.org%2F+so+not+found&oq=site%3Ahttps%3A%2F%2Fbugs.debian.org%2F+so+not+found&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg60gEJMjIzMDVqMGo0qAIOsAIB8QURwi3HLeuqsA&client=tablet-android-blackview&sourceid=chrome-mobile&ie=UTF-8

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

зазвичай в /usr/local

Не завжди, в мене в /usr/local попали пакети arm-gcc, avr-gcc, хоч вони є в ports, pkgng, проблема збирати  як пакет ./configure && make && make install  не тільки бінарні проблеми, в й в обхід пакетного менеджера може створюватись конфігураційний файл, який створює проблему, і добре якщо архів не видалений, є умова make delete, від цього вже не застрахована ні одна ОС, навіть лінукс

release - такого нема в debian, "release"

Добре, немає, але проблема в stable перенести свіжий софт з unstable є
https://unix.stackexchange.com/questions/8049/how-to-install-some-packages-from-unstable-debian-on-a-computer-running-stabl

Обмеженість вибору (як у bsd дистрибуції) - я би не відносив до плюсів від слова зовсім.

Ніхто нікого не обмежує, підходить, працюй, хоч сервер, хоч ПК з своїм DE

колись то вважалося деякими (може і зараз кимось) - тру bsd way

То ще появилось з часів коли на вінчестері місця мало було, і щоб зібрати пакет з необхідними параметрами, наприклад apache сервер і чи потрібно тобі mod_perl чи ні, debug message ... Саме тому ставили з ports до там була завжди нова версія, ніж в pkg_install, деякі до цієї ситуації поставились дуже фанатично

Тут не ясно то до чого знову

Доповнив те що аргументи, типу наша ОС підтримує багато архітектур CPU, безпека, можна збирати з відкритого коду, не актуальна для 2025 року точно, це можливо робити з всіма відкритими системами, і фраза, вільна чи безкоштовна ОС
 Все залишимо розмову, зараз є більша проблема, я в ЗСУ, ніхто нікому не нав'язує думку, залишимось добрими користувачами, проблеми є всюди, в якщо не зустрічався з нею, це не означає що їх немає