Názory k článku
Vyšlo FreeBSD 15.1-RELEASE

O freebsd systém se pokouším již po několikáté. Většinu verzí jsem rozchodil i na vcelku starém obskurnim hw skoro bez problémů, jen proto abych poté zjistil, že pro ten systém nenacházím využití na desktopu, a pro využití jako NAS nebo fileserver zase existuje výkonnější alternativa..
Tak zatím testují co to umí.. Je fajn, že mohu spouštět nativně binárky linuxu, ale s bsd se furt učím.. Uvidím co dokáže tato novější verze.. Tady

výkonější varianta? Naopak já mám problém na linuxu vůbec postavit konkurence schopný řešení a ty komerční často právě na freebsd běží.

Hlavní výhoda je, že je vše velmi dobře dokumentované, přehledné, stabilní. Co jsi se naučil před 10 lety, platí pořád. Moje scripty přežívají dvacet let s minimem změn. Balíčky jsou jednotné, mohu si vybrat jestli použít překompilované nebo si nějaký zkompilovat, opatchovat, vše funguje plynule i s upgradem.

Linux, to je jeden obrovský chaos, nepořádek, bordel. Změny jsou jak na běžícím pásu, některé ti něco hlasitě rozbijí, některé ti to rozbijí naprosto tiše. Než se naučíš jednu věc, hned se to celé chová jinak. Každá distribuce je celá konfigurovaná jinde, nikdy nevíš, které nastavení ti bere v potaz a které tiše ignoruje. Balíčky mají vlastní správce, nevadí, když se pár let na ně nešáhne, to nikdo neřeší. Když už chceš něco vyřešit sám, tak vůbec nějaký balíček zkompilovat ze zdrojáku a používat je často na dlouhé hodiny, dny ladění, hledání správných závislostí.

Mně freebsd dává klid na duši, spolehlivost, kdy vím, co který příkaz udělá a jak.

Absolutne dokonale vystihnute, mam presne rovnaky pocit.

Free BSD

Ano, jinak řečeno ten systém 10 let stagnuje a nikam dál se neposouvá. Linux se naproti tomu posouvá mílovými kroky aby se vyrovnal dnešním nárokům na bezpečnost, funkčnost, konfigurovatelnost etc. (X->Wayland, init bash hell -> systemd, UI dependency hell -> flatpak, svc directly on baremetal -> containerd/doc­ker/podman, serverový orchestrační hell -> k8s atd.)

"ten systém 10 let stagnuje a nikam dál se neposouvá"
Během posledních ~5-ti let se ve FreeBSD rozloučili s většinou platforem a soustředí se plně na serverery a desktopy - tohle samo o sobě je docela velká koncepční změna, která Vaše tvrzení vyvrací

1) X->Wayland
FreeBSD jednak Wayland normálně umožňuje, ale hlavně teď když máme XLibre, tak Wayland není potřeba, protože X server je normálně vyvíjený.

2) systemd
Krásná ukázka toho, proč používat BSD systémy oproti Linuxu. Nehledě na to, že už v době vzniku molochu jménem systemd byly na Linuxu lepší alternativy (např. OpenRC).

3) flatpak,
To je problém Linuxu (ale taky velká výhoda), že se dělí na tisíce distribucí. BSD systémy se vyvíjejí jako celek, takže nějaký Flatpaky nemají zapotřebí.

4) containerd/doc­ker/podman
FreeBSD má už 20 let systém Jailsů, který na rozdíl od Linuxu nemění co pár let svojí architekturu.

Kromě Kubernetes tak všechny příklady které jste uvedl jsou irelevantní, protože se buďto FreeBSD netýkají, nebo za ně existuje lepší alternativa. Snad jedině ta zmínka o Kubernetes má nějakou relevanci, ale i tady existuje alternativa v podobě HashiCorp Nomad, která přesně kopíruje zásadní rozdíl v UI programů na Linuxu a BSD (Kubernetes - těžkopádný moloch ; HashiCorp Nomad - rychlé, jednoduché řešení bez tuny vlastností/ba­lastu).

To je možná zbožné přání. Posouvá se hodně, jen tím posunem prostě nerozbíjí user space.

Od FreeBSD 11 (vyšlo v roce 2016) se přešlo z GCC na LLVM/Clang, ZFS se zmigrovalo na OpenZFS vč. všech vylepšení (rychlost, šifrování, obnova, stabilita) a to se zachování zpětně kompatibility. Přibyla virtualizace bhyve, UEFI boot, nvme/virtio. Jails dostali jednodušší správu, lepší vnet. Máme tady nativně wireguard. Podporu arm, podporu v claudech. Podpora v HW (100G sítě, spousta notebooků, jednočipů atd.).

Zrovna pokud jde o bezpečnost, FreeBSD je reálně mnohem dál, jails fungují out of box (laborovnání s containers a různě dlouhými seznam CAP věcí je šílenost), capsicum funguje ot of box (na SElinux se nikdo neobtěžuje dělat pravidla a profily a seccomp je složitý a opět bez profilů). Linux má spoustu nástrojů a možností, ale to je jeho slabina, je těžké to správně používat a vůbec se na tom dohodnout.

rc scripty nejsou bash. Je to přímočarost. Pokud mi u linuxu nad systemd nebootuje nějaká core služba, která je v závislosti, je to peklo se dostat k logům a něčemu rozumnému. Na freebsd připojím zfs s logy a vidím to.

Flatpak je bezpečnostní průser, schované legacy závislosti s jiného stromu do něčeho, co se tváří bezpečně. Containerd se také tváří jako bezpečnostní řešení, není jim a je těžké ho udělat. Podman super, ale stačí více kontejnerů nebo auto start a jsi v loji (řešení, které řešením není). K8s je mimo téma.

Na freebsd s pf/jails se mi nestane, že omylem dám nějaké aplikace přístup na síť aniž bych chtěl. Na linuxu je dost velký problém vlastně izoloval container z dockeru mimo síť, najednou aktualizace změní iptables pravidla a přeskočí ti tvoje. Uděláš upgrade z RHEL 8 na RHEL 9 a tvoje vymazlený firewalld pravidla se přestanou z půlky aplikovat, protože tvoje síť skončila v jiném šuplíku.

Linux mě bohužel živí, protože potřebuje neustálou péči, naproti tomu freebsd té péče nepotřebuje tolik, tak si mě firmy nenajímají na migrace a instalace. Realita dnešních dní. Používej si ale co chceš, linux není špatný, jen je obrovský.

To ze sa posuva este neznamena, ze ide dobrym smerom. Ono sa da posuvat aj smerom k horsiemu.

A tenhle příspěvek je o čem? Buď napište, že FreeBSD se posouvá k horšímu a uveďte podporující argumenty a nebo tomu nerozumíte a tyhle nic neříkající věty raději nepište.

Jaké je počasí? Ono může být hezky, ale taky zataženo nebo dokonce bouřka, ale taky může být mlha nebo jenom déšť nebo ... (atd. atd.)

A přesně to je na něm sympatické!

To by bylo, abys ty hned nepřiběhl přidat, že "stagnace je prima". Ty už jsi přešel snad jen na trollení.

Jasně, jasně... <g>

A dalsi prijemna vec je dokumentace, manualove stranky, handbook - vse je aktualni a co je napsane v treba v manu, tak proste plati. Za tech 20 let u FreeBSD jsem nasel opravdu hodne malo veci, kde by byla nejaka nepresnost.
V linuxu je tohle v o dost horsim stavu.

A co je za problem s vykonosti ? ZFS je stejný jako na Linuxu a jde OS tunit.
Klidně mi napište.
[1] https://calomel.org/freebsd_network_tuning.html

Ted uz je podpora lepsi nez byla pred lety. Snažím se psát ovladače, když to jde. (ted delam mediatek, bananapi)

Dokonca uz funguju aj niektore Wifi od Broadcom

Nevím, já přešel na FreeBSD cca před deseti lety přímo z Windows a normálně ho používal jako desktopový systém. Nemůžu si stěžovat. Samozřejmě právě podpora hardwaru byla na noteboocích problematičtější tak jsem po několika letech přešel na Linux.

Ted uz je podpora lepsi nez byla pred lety. Snažím se psát ovladače, když to jde. (ted delam mediatek, bananapi)

Jen kdyby si s tím někdo hrál (jako já) a měl už někde systémy s pkgbase. Tzn. i základní systém je v balíčcích a nepoužívá se pak klasický nástroj freebsd-update.
V tuhle chvíli je to v 15.x řadě jako test a některé kroky nejsou úplně super dokumentované, ale funguje to.

Schválně jsem čekal na minor verzi, abych si ozkoušel jak se to bude chovat při reálných upgradech.

v konfiguraci repozitáře base v /etc/pkg/FreeB­SD.conf je ve výchozí konfiguraci url s proměnnou VERSION_MINOR.
"pkg+https://­pkg.FreeBSD.or­g/${ABI}/base_re­lease_${VERSI­ON_MINOR}"

Ta se ale nespecifikuje přímo, protože si ji nástroj pkg vyseká ze systémové proměnné OSVERSION.

Tzn. pro upgrade na 15.1 na amd64 platformě pak stačí použít:

env OSVERSION=1501000 ABI=FreeBSD:15:amd64 pkg update -r FreeBSD-base
env OSVERSION=1501000 ABI=FreeBSD:15:amd64 pkg upgrade -r FreeBSD-base

Zjistí si, že se změnil root repozitáře, znovu udělá index balíčků, nechá si potvrdit operaci upgrade. Následně reboot a je to.

Samozřejmě může dávat smysl udělat si před tím záložní boot environment přes bectl (tohle zatím není automaticky provázané jako u freebsd-update).
Taky pak po minor upgrade chce většinou doaktualizovat bootloader. Na UEFI systémech tedy:

cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi

(samozřejmě se dají oba soubory předtím porovnat, jestli je to opravdu potřeba)

Ako sa tam potom rieši aktualizácia konfiguračných súborov v /etc?

Myslím tým, že čo nahrádza etcupdate používaný pri source upgrades?

To si řeší každý balíček zvlášť. Resp. používají se standardní nástroje v pkg. Což je za mě jeden z benefitů tohohle přístupu.

V manifestu každého balíčku (nejen systémového z base repozitáře) jde nastavit sekce config, kde jsou uvedeny všechny konfigurační soubory z balíčku. K těm se pak chová jinak, nepřepisuje je, ale porovná existující a novou verzi, případně použije 3-way merge a kdyžtak dělá zálohy (.pkgsave, .pkgnew).

Prakticky, pokud už to máte nainstalované tímhle způobem, tak se můžete podívat např. na manifest balíčku v kterém je i část souborů do /etc
pkg info -R FreeBSD-runtime

tam máte sekci config, což obsahuje zmíněnou definici souborů.

config: [
    "/etc/ddb.conf",
    "/etc/defaults/devfs.rules",
    "/etc/devfs.conf",
    "/etc/disktab",
    "/etc/fbtab",
    "/etc/gettytab",
    "/etc/group",
    "/etc/hosts",
    "/etc/hosts.equiv",
    "/etc/login.access",
    "/etc/login.conf",
...

A pak třeba i sekci script, kde jsou zas uvedeny příkazy, co se spouští po instalaci. V tomhle případě to vygeneruje/ob­čerství databáze s loginy atp.

scripts: {
    post-install: "pwd_mkdb -i -p -d  ${PKG_ROOTDIR}/etc ${PKG_ROOTDIR}/etc/master.passwd\n    services_mkdb -l -q -o ${PKG_ROOTDIR}/var/db/services.db ${PKG_ROOTDIR}/"
}

Takže nemusíte dělat ohledně mergování víceméně nic dalšího, resp. pokud chcete být pečlivý, můžete si v /etc/ a /usr/local/etc vyhledat všechny soubory s příponami .pkgsave nebo .pkgnew, porovnat je s aktuálními soubory, a pak si to ručně doupravit.

Ďakujem za info, musím sa s tým niekedy pohrať. Idea správy base systému pomocou pkg balíčkov sa mi páči, ale bral som to ako niečo zatiaľ silne experimentálne a ešte som to v praxi netestoval.

Predpokladám, že tá funkcionalita mergovania configov pomocou pkg bude pomerne nová, lebo pri bežných "aplikačných" balíčkoch som ju zatiaľ ešte nezaznamenal. Zvyknutý som na tradičný prístup, kedy balíčky aktualizujú iba "sample" config files a samotné "aktívne" configy je treba upravovať ručne.

To je trochu paradox, právě že v pkg samotném je tahle funkcionalita už velmi dlouho.
https://github.com/freebsd/pkg/commit/e6cd4064e4f4a62cae8d1cddbaeeda043e1fcadb
A průběžně to vylepšují, třeba pkg 2.0 (pár let zpět) má dokonce v manifestu možnost použít externí nástroj pro merge.

Ale ten největší problém je v tom, že to nemá ekvivalentní funkci v normálních portech. Proto o tom taky nenajdete jedinou zmínku v Porter's Handbook.
V portech se používají jen klasicky .sample soubory, které jsou úplně mimo a veškeré případné mergování musíte řešit ručně.
Není tam ani žádný přechodový mechanismus nebo makro, kdy byste třeba případně mohl "otagovat" konfigurační soubory a vytvořit tu config sekci v manifestu jen v případě, pokud z portu děláte balíček (make package). Protože by se to chovalo jinak podle typu instalace.

Zatímco ty systémové base balíčky vznikají jinak. Když uděláte make buildworld, proleze to přes METALOG až do pkg-create, kde to rovnou nacpe ty manifesty s config sekcemi.

Takže to je důvod, proč se to nepoužívá v "normálních" balíčcích. Ale je evidentní, že s tím pro systém počítali už dlouho, po celou dobu toho kdy chystali pkg base. To samo o sobě bylo taky předmětem mnoha interních debat (výhody/nevýhody.. a názory od "nic takového nepotřebujeme, nejsme Linux" až po "jsme sto let za opicema, nedokážu selektivně aktualizovat jen části systému z binárních balíčků a je to pomalé") :)

Jinak za mě to chodí docela hezky, zkoušel jsem to už v 14, teď s 15 to mám na pár virtuálech.
Krom pár věcí, co si člověk musí uvědomit (třeba to, že tam není ten hook na bectl jako u freebsd-update), jsem nenarazil na zásadnější problémy.

Na případnou migraci (jednosměrnou), kdyby jste si s tím chtěl hrát, tak je pkgbasify.
https://github.com/FreeBSDFoundation/pkgbasify

Jinak ještě jestli si chcete vylistovat všechny soubory, co pkg spravuje jako configy, tak můžete přímo udělat query na databázi pkg.

sudo sqlite3 -readonly /var/db/pkg/local.sqlite "select path from config_files order by 1"