FreeBSD mint desktop OS - tapasztalatok

 ( gergelykiss | 2018. október 20., szombat - 21:59 )

Néhány hónapja CentOS-ről FreeBSD-re váltottam otthon, így most egy 11.2-RELEASE fut az otthoni desktop gépemen, az alábbiakban összefoglalnám az eddigi tapasztalataimat.

Összességében nem bántam meg az átállást, de azért van pár kényelmetlenség, amit a mai napig nem sikerült orvosolni, és ami miatt még mindig "visszasírom" a Linuxot néha...

Ami tetszik:

  • A rendszer elképesztően profi módon van összerakva - minden a helyén van, és nem is változtatnak indokolatlanul a konvenciókon a fejlesztők. Az eddigiek alapján úgy látom, egyébként sem túl nyitottak a változásokra, ez nyilván előny és hátrány is lehet, nézőpont kérdése. Nekem tetszik, mivel elég makacsul tudok ragaszkodni a régi, jól bevált dolgokhoz, de tudom, hogy ezzel nem mindenki van így.
  • A release-ek kiadása egy alaposan átgondolt (és kicsit bonyolult) rendszer szerint történik, nekem kifejezetten tetszik a CURRENT/STABLE/RELEASE ágak különválasztása, így az ember mindig tudja, mire számíthat egy upgrade után. Ahol a stabilitás kell, oda jöhet a RELEASE, ahol a legújabb feature-ök kellenek, és nem baj, ha a rendszer kevésbé kiforrott, ott a STABLE-t lehet használni, fejlesztőknek és tesztelőknek pedig ott vannak a CURRENT release-ek. Tiszta, világos elvek mentén adják ki a frissítéseket, illetve mindig készül release notes és errata dokumentum is, ami a frissítés előtt álló usereknek és rendszergazdáknak gyakorlatilag kötelező olvasmány.
  • Mivel FreeBSD-ben a kernel és az OS többi része (library, shell, alkalmazások) egységet alkot, így sokkal kevesebb buggal és stabilitási problémával lehet találkozni mint bármelyik Linux disztró alatt. Kifejezetten jó megbízhatóság szempontjából, hogy a kernel eléggé konzisztens módon működik, nincs meg az a kellemetlenség, hogy egy kernel frissítésnél egy csomó minden nem működik vagy másképp működik mint korábban. Ez Linux alatt tipikus probléma, az például a halálom, hogy a Debiant futtató HTPC-men a tunerkártya driverét minden alkalommal újra kell fordítani, ha változik a kernel verziója. Tudom, erre találták ki a DKMS-t, meg is próbálom majd belehegeszteni a tuner kártya driverét, ha lesz hozzá affinitásom egyszer. :)
  • Egészen korrekt a hardvertámogatás x86 architektúrán. Tény, hogy a Linux jobban áll ezen a téren, de szerintem ha nem bleeding-edge hardvereken akar valaki FreeBSD-t használni, igen kicsi az esélye, hogy lesz olyan vas, ami ne működne FreeBSD alatt. Az otthoni gépem már igencsak elavultnak számít (2012-es évjárat), így ez nem feltétlenül jó referenciának, de ki fogom majd próbálni a FreeBSD-t HP szervergépeken is és a szintén itthon használt Dell E5440-es gépemen is. Mindenképp említésre méltó, hogy van hivatalos, karbantartott NVIDIA driver, az AMD kártyákkal viszont kifejezetten problémás a driver támogatás. Zárt forrású driver tudtommal sosem készült FreeBSD-hez, a nyílt forrású pedig sokéves lemaradásban van a linuxos radeon/amdgpu driver-ekhez képest... konkrétan emiatt voltam kénytelen lecserélni a videokártyát, mivel mindenképp szükségem volt a hardveres gyorsításra (leginkább a window manager és a szaggatásmentes FullHD videólejátszás miatt).

Ami nem tetszik, avagy mi az, ami kisebb-nagyobb kellemetlenségeket okozott eddig:

  • Alapvetően segítőkész a közösség, de az amatőr hozzáállást és a figyelmetlenséget nem tolerálják, sok olyan posztot látni a fórumon, ahol a "vén rókák" kiosztják az odatévedő tapasztalatlan és/vagy esetlenül kérdező usereket. Ebbe én magam is belefutottam az elején, de gyorsan túltettem magam rajta, ez egy ilyen világ és kész. :)
  • Baromi komplex a rendszer, többszáz tunable finomhangolására van lehetőség, viszont ezek nem minden esetben vannak korrektül dokumentálva. Igaz, a dokumentációra alapvetően nem lehet panasz, az általam eddig használt FOSS projektek közül messze a FreeBSD-nek a legjobb/legátfogóbb a dokumentációja, ami mindenképp dicséretes.
  • Kompatibilitási problémák bőven vannak, egy csomó szoftver (jellemzően a Linuxból jól ismert, GNU-s cuccok) kiforratlanabbak FreeBSD alatt mint Linuxon, arról nem is beszélve, hogy sok tool paraméterezése és működése nagyban eltér a Linuxon megszokotthoz képest. Többször volt már olyan, hogy valamelyik gyakran használt toolnál hiányoltam egy olyan kapcsolót, ami Linuxon van, viszont a BSD-s variánsban nincs implementálva.
  • Az előző ponthoz kapcsolódan, tudtommal nincs GUI-s megoldás GNOME alatt a diszkek kezeléséhez, a Disk Utility itt nem működik, tekintve, hogy erősen kernelhez és fájlrendszerhez kötött a tool, és sajnos még nem portolták FreeBSD-re. Parancssorból persze bármit el lehet intézni, de sokszor jól jönne egy grafikus tool, amivel két kattintással újra lehet partícionálni és formázni egy pendrive-ot.
  • A legutóbbi minor frissítés után (11.1 -> 11.2) valamelyik virtualbox kernel modul kernel panic-et okozott bootoláskor, ami miatt boot loop-ba került a gép. Nyilván ez a saját rutintalanságomnak köszönhető, de nem volt könnyű orvosolni a problémát. A megoldás az volt, hogy le kellett tiltani a problémás modulokat az előző (frissítés előtti) kernel alatt, majd reboot után manuálisan újra kellett forgatni őket az új, 11.2-es release-hez. Pozitívum, hogy amint fény derült a problémára, a fejlesztők beraktak egy figyelmeztetést a 11.2-es release-hez készült errata dokumentumba ezzel kapcsolatban.
  • Ez kicsit szubjektív, de security téren azért bőven van elmaradása a FreeBSD-nek, a HardenedBSD és az OpenBSD is elhúzott mellette az utóbbi években. Tekintve, hogy a FreeBSD-t elsősorban szerveres/hálózatos környezetbe szánták, ez szerintem kiemelt szempont kellene, hogy legyen, de valamiért mégsem az, ahogy itt a HUP-on is volt már erről szó pár hónapja.
  • Igazából ez csak apró kényelmetlenség, de nekem először nem esett le (tudom, RTFM), hogy a csomagokat és a disztrót magát külön kell frissíteni, a csomagkezelő (pkg) nem frissíti az OS központi részeit, csak a ports collection-ből származó csomagokat. Szerintem logikusabb és praktikusabb lenne a kettőt együtt kezelni, én azt vártam volna, hogy a pkg az OS-t is frissíti (vagy legalább legyen olyan kapcsolója, amivel ez megoldható).
  • A rendszer ZFS támogatása és integrációja kiemelkedően jó, viszont a cache beállítások default értékei nem éppen ideálisak, a ZFS cache megeszi a RAM-ot egy idő után (8GB van a gépben, ami azért elég kéne, hogy legyen sima irodai/multimédiás felhasználás mellett). Mivel nem lapozható memóriaként foglalja le a kernel a ZFS cache részére fenntartott memóriát, így a RAM telítődése esetén veszettül swappelni kezdi a rendszer a futó processek által használt memóriát, ami komoly lassulásokat tud okozni. Ez gyakorlatilag azt jelenti, hogy ha csak 1-2 program is fut, azok brutálisan belassulnak és csak reboot után szűnik meg a probléma. Alapbeállítás szerint az ARC mérete a teljes RAM méretének 90%-a, ami 8 GB RAM mellett túl sok. A megoldás a "vfs.zfs.arc_max" sysctl változó finomhangolása volt, ezt belőttem 2 GB-ra, azóta nem tapasztalok swappelésből fakadó lassulásokat. A gépben két HDD van, ezeket a GELI+ZFS kombóval összevontam egy titkosított ZFS kötetté. Ez kiválóan működik, mindkét disk bootolható, és a hardveres AES titkosításnak köszönhetően a teljesítmény sem romlik észrevehetően a titkosítás használata miatt. Rendhagyó módon a FreeBSD-ben tényleg komolyan van véve a "full disk encryption" koncepció, mivel kizárólag az első fázisú boot code van titkosítás nélkül tárolva a diszkeken, minden, ami utána jön, már csak a titkosítás feloldása után férhető hozzá. Ennek egyetlen hátránya, hogy a jelszó prompt fixen angol kiosztás szerint kéri be a jelszót. Ez annyit jelent a gyakorlatban, hogy memorizálnom kellett a jelszóban lévő speciális karakterek angol kiosztás szerinti helyét, persze, nem nagy áldozat, de elvártam volna, hogy be lehessen állítani a korrekt layout-ot. CentOS alatt ezzel nem volt gond, ott a kernel paraméterben beállított kiosztás szerint lehetett begépelni a jelszót.
  • Ez inkább GNOME-specifikus probléma, de azért megemlékezem róla: a GDM összekapcsolja a locale beállítást a bill. kiosztással, ez is problémát okozott, mivel ezer éve úgy használom az otthoni gépeimet, hogy angolul beszél az OS, de magyar a bill. kiosztás. Ez a felállás, úgy tudom, a GDM-ben nem lehetséges, ha angol a locale, akkor en-us a kiosztás fixen, magyar kiosztást csak úgy lehet használni, ha a locale-t magyarra állítom, viszont az utána globálisan vonatkozik a user session-re is és valamiért nem lehet felülbírálni a session-ön belül.

Update 2018-10-21:

A GUI-ra nem tértem ki elég részletesen, holott ez lett volna a posztom fő témája. :)

Egy alap GNOME3 interfészt használok, ami tökéletesen stabilan működik, a GUI animációk gyárilag hibátlanul működnek, a videolejátszás teljesen akadásmentes FullHD felbontásban is a zárt forrású NVIDIA driverrel. Abszolút semmi panasz nincs, bátran ki merem jelenteni, hogy tökéletesen megállja a helyét a FreeBSD desktopos felhasználás mellett is. A Gnome jelenlegi, Ports Collection-ben lévő verziója 3.28.2, ami nem a legfrissebb verzió, de csak két minor verzióval van elmaradva a legfrissebb stabil release-hez képest. KDE és más WM-ek kapcsán nincs tapasztalatom, de gyanítom, hogy ezeknél is hasonló a helyzet.

Update 2018-11-03:

Röviden megemlékeznék a FreeBSD Linux emulációjáról is. A FreeBSD natívan képes futtatni a Linuxra fordított binárisokat egy erre szolgáló kernel modul (ez teszi lehetővé a linux-os ELF binárisok közvetlen futtatását a rendszerhívások valós idejű "eltérítése" révén), valamint egy minimalista Linux disztribúció segítségével, ami a futtatókörnyezetet biztosítja az emulációhoz. Eleinte csak 32-bites binárisokat lehetett így futtatni, de a 10.3-as release óta már a 64-bites Linux binárisok futtatása is lehetséges. A futtatókörnyezetként funkcionáló Linux disztrónál két opció közül lehet választani: CentOS 6-ot vagy 7-et lehet használni, mindkét környezet csomagezelőből telepíthető (linux_base-c6 és linux_base-c7 csomagok). A tapasztalat azt mutatja, hogy a Linux emuláció az esetek többségében kiválóan működik, a Linux binárisok többsége gyorsan és stabilan futtatható. Azért előfordulhatnak anomáliák komplex, sok függőséggel bíró alkalmazásoknál, volt pl. egy közel két tucatnyi függőséggel fordított bináris, amit sehogy sem sikerült elindítanom (azonnal segfault-olt indítás után), hiába szedtem össze minden függéségét egy natív CentOS 7 rendszerből. Az mindenképp sokat elárul az Linux emulációban rejlő lehetőségekről (és a fejlesztők humorérzékéről), hogy a doksiban a Doom linuxos verzióján keresztül mutatják be a konfigurálás menetét. :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én már bő öt éve cseréltem le az ArchLinuxot FreeBSD-re.
Akkoriban viszont történtek nagyobb változások a FreeBSD körül: a korábbi csomagkezelőt akkor váltotta a most is használt pkgng (10-es verziótól), valamint a konzol is (link). Amúgy igen, én is azt látom, hogy a legtöbb esetben az ami bevált, ne piszkáld-elv érvényesül ("öregkoromra" egyre inkább egyetértek ezzel).

Dell E5440-es gépemen is
Dell E5430-on szépen megy.

Problémáid (amire tudok érdemben reagálni):
egy csomó szoftver (jellemzően a Linuxból jól ismert, GNU-s cuccok) kiforratlanabbak FreeBSD alatt mint Linuxon
Ha az alapparancsokra gondolsz (find, grep, stb.), akkor telepíthetőek a linuxos (gnu) fajták (a sysutils/coreutils csomag, ezek g előtaggal érhetőek el, pl. gfind, ggrep, stb.).
Ezek nem kiforratlanabbak, hanem a POSIX-hoz jobban (vagy teljesen) passzolnak - azaz nagyobb az esélye, hogy a szkripted más rendszereken is rendesen fut (pl. grep, find - valamiért most nem jönnek be). Amelyik kapcsolókat hiányolod, azokat szokták "linuxizmusnak" nevezni.

két kattintással újra lehet partícionálni és formázni egy pendrive-ot
Azért nem olyan nehéz az a két parancs :)

valamelyik virtualbox kernel modul kernel panic-et okozott bootoláskor, ami miatt boot loop-ba került a gép
Zahy írt erről :)

nekem először nem esett le (tudom, RTFM), hogy a csomagokat és a disztrót magát külön kell frissíteni
Először én se tudtam, de aztán én is olvasgattam. Egyébként erre is van igyekezet, ez lesz(?) majd a pkgbase. Nem tudom, hogy áll a dolog, nem követem.
Egyébként ebben a rendszerben is van logika: ami nem az alaprendszer ("3rdparty"), ahhoz használsz egy eszközt (ami egyébként szintén "3rdparty" :) ). Ami az alaprendszer, ahhoz egy másikat. Linux alatt nyilván nincs ilyen szétválasztódás, ezért elsőre fura lehet.

Dell E5430-on szépen megy.

Szuper, akkor jó eséllyel nálam se lesz gond a hardvertámogatással, ez mindenképp jó hír.

Ha az alapparancsokra gondolsz (find, grep, stb.), akkor telepíthetőek a linuxos (gnu) fajták (a sysutils/coreutils csomag, ezek g előtaggal érhetőek el, pl. gfind, ggrep, stb.).
Ezek nem kiforratlanabbak, hanem a POSIX-hoz jobban (vagy teljesen) passzolnak - azaz nagyobb az esélye, hogy a szkripted más rendszereken is rendesen fut (pl. grep, find - valamiért most nem jönnek be). Amelyik kapcsolókat hiányolod, azokat szokták "linuxizmusnak" nevezni.

A GNU-s variánsokról még nem hallottam, ha legközelebb hiányzik valami, meg fogom próbálni ezeket, köszi a tippet! A POSIX-kompatibilitás valóban fontos szempont a szkriptek hordozhatósága miatt, és valószínűleg kevésbé szúrna szemet a hiányzó kapcsolók problémája is, ha nem a Linux világából jöttem volna át.

Azért nem olyan nehéz az a két parancs :)

Persze, de lássuk be, a kényelem nagy úr, ha össze is lehet klikkelgetni, akkor minek koptassam a billentyűzetet parancsok gépelésével. :) Egyébként egész jól használhatók a parancsori tool-ok (geli, gpart), de ezeket is csak tanulgatom még, azért nem annyira felhasználóbarátak mint mondjuk Linuxon az fdisk/gdisk kombó, itt is érződik, hogy a BSD világa tapasztalt sysadminoknak való, egy átlag user (vagy akár power user) elég hamar el tud akadni, ha nincs teljesen képben az elmélettel. Ide kapcsolódóan eszembe jutott még egy "furcsaság": a diszkek MBR-jét nem engedi írni a kernel még a root-nak sem (ez gondolom valamiféle extra paranoid védelem akar lenne a véletlen felülírás ellen), ez pl. diszk klónozásnál vagy image kiírásakor okozott egy kis fejtörést, nem igazán tudtam hova tenni, hogy a root-nak "permission denied" hiábát ad a kernel. A megoldás egyébként annyi, hogy a "kern.geom.debugflags" sysctl változó értékét 0x10-re kell állítani.

Egyébként erre is van igyekezet, ez lesz(?) majd a pkgbase. Nem tudom, hogy áll a dolog, nem követem.
Egyébként ebben a rendszerben is van logika: ami nem az alaprendszer ("3rdparty"), ahhoz használsz egy eszközt (ami egyébként szintén "3rdparty" :) ). Ami az alaprendszer, ahhoz egy másikat. Linux alatt nyilván nincs ilyen szétválasztódás, ezért elsőre fura lehet.

Ezt nem tudtam, de egyébként valóban van logika a különválasztásban is. Persze ez a téves feltételezés is abból fakad, hogy közel 15 évnyi linuxozás után kezdtem el a BSD-vel ismerkedni, így elkerülhetetlen, hogy prekoncepciók és a Linuxból megszokott működési mechanizmusok "árnyékában" tekintek a BSD-re, nehéz tudatosítani magamban, hogy a közös gyökerek ellenére azért igen sok eltérés van a Linux és a BSD-k világa között.

"A POSIX-kompatibilitás valóban fontos szempont a szkriptek hordozhatósága miatt"

Tudom, nem fogtok szeretni, de hová kéne manapság hordozni a scripteket? A régi rendszerek halottak vagy kimúlóban vannak, már nagyvállalati szinten is csak ritkán találkozni velük, és ott is szabadulnának tőlük (ha lehet).

Azt akarod mondani, hogy gyakorlatilag mindenhol Linux van?

Kérdés: ha egy program valóban hasznos "-X" kapcsolója nem POSIX kompatibilis, de a program kb. 50000x annyi helyen fut mindenki örömére, mint a POSIX kompatibilis verziója (ami nem implementálja a -X kapcsolót), akkor nem kellene inkább felvenni a szabványba a "-X" kapcsolót?

Példa: grep vs egrep.

Gondolom, nem annyira egyszerűen működik a dolog, hogy holnaptól a -X is benne lesz a POSIX-ban - hiszen az összes grep-implementációban implementálni kellene, különben addig nem számítanak POSIX-kompatibilisnek (legalábbis a legújabb verzió szerint).

Hát akkor nem lesznek azok.
Ha implementálják, akkor azok lesznek.
Nem tudom egyébként, számít-e még bármit igazán a POSIX kompatibilitás.
Akik nem azok, vagy csak részben, azok is remekül elvannak.

Nem tudom egyébként, számít-e még bármit igazán a POSIX kompatibilitás.
Szerintem a szabványok mindig számítanak: tudod, hogy mire számíthatsz, mit használhatsz.
Akik nem azok, vagy csak részben, azok is remekül elvannak.
Ezt nem vitatom - csak azt nem kell elfelejteni, hogy a Linuxokon kívül is van világ, ha más nem, a topiknyitó ürügy :)

Persze hogy van világ a Linuxon kívül, csak az volt a kérdés, hogy érdemes-e egy ősrégi szabványhoz ragaszkodni, vagy csatlakozni lehet egy újabb kvázi-szabványhoz.

De dolgoztam mindenféle "hagyományos" (?) Unixon is, és valahogy egyik sem volt szabványos. Akkor miről beszélünk?

Persze hogy van világ a Linuxon kívül, csak az volt a kérdés, hogy érdemes-e egy ősrégi szabványhoz ragaszkodni, vagy csatlakozni lehet egy újabb kvázi-szabványhoz.
Csak ugyebár a klasszikus felvetés, hogy ki fogja megmondani, mi lesz az a "kvázi" szabvány. Mert amíg nincs egységesség, addig a böngészős javascript szintjén lesz az egész: az egyik így működik (mert így látja jónak), a másik meg úgy.

valahogy egyik sem volt szabványos
Viszont gondolom, hogy a "minimumot" (POSIX) mindegyik hozta - és ezt a minimumot elvileg mindegyik hozza, ezért tudsz erre építeni. Persze ezen kívül tudhatnak többet a minimumnál, csak mondjuk mindegyik mást tart fontosnak, más viselkedést lát logikusabbnak, stb.
Jó példa erre a BSD és a GNU make: mindkettő többet tud az "alapkövetelménynél", viszont más a többlet szintaxisa, más lehetőségeket nyújtanak, stb.

Azt egyébként nem tudom, hogy a POSIX bővítése hogyan megy, mivel, milyen következményekkel jár - gondolom, nem annyira egyszerű.

Engem ebből az egészből a "grep vs egrep" rész érdekel. Mit akartál itt mondani? A grep ismeri a reguláris kifejezések alapkészletét + némi bővítést. Az egrep pedig a bővített regexpet. (Ami szintén az alapkészlet, csak éppen egyéb bővítményekkel.) A POSIX szabvány meg tudtommal azt mondja, hogy használd a grep-et magában ha az alapfunkció kell, és -E opcióval, ha a bővebb (és a -F -et, ha fgrep kell).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Közben utána néztem és kiderült, hogy tévedtem.
Meg voltam róla győződve, hogy a mezítlábas grep a POSIX -os és minden más extra hozzá már nem az.

Az a baj, hogy ez megint meghozta a kedvemet, de a FreeBSD on desktop az kb. 2002-es Linux desktop érzet. Ez persze szubjektív, de én már úgy vagyok, hogy működjön minden OOTB.

Az ilyenek teszik be mindig a kaput, mint amikor pl. a Chrome installer a telepítés végén még dob egy listát a kézzel elvégzendő teendőkről. Legalább rákérdezne, hogy megcsinálja-e helyettem.

Persze ez nem a FreeBSD hibája, egyszerűen nem desktop OS (arra ott van pl. MidnightBSD, vagy a GhostBSD).

Hát igen.

Valami ilyesmi volt:
- olvastam ezt a cikket
- nem sokkal később a manjaro megint szó nélkül kikapcsolt
- beütött a "vissza BSD-re érzés", de gyorsan el is múlt
- elementary fel
- déjà vu ("ez is csak másképpen szar")

ez is csak másképpen szar
Pontosan, én is így látom :)
Lehet választani a nagy-nagy felhozatalból, hogy a szar melyik módját választod :)

> GDM összekapcsolja a locale beállítást a bill. kiosztással, ez is problémát okozott

nalam LANG=hu_HU.UTF-8 es LC_MESSAGES=C van (magyar billentyuzettel), ilyen kombot probaltal? mondjuk en nem gdm miatt csinaltam ezt, hanem az zavart, hogy (linuxon) kde alatt nem latszanak a magyar nemzeti unnepek, de tovabbra is keresheto hibauzeneteket akartam.

Próbáltam többféle beállítást, de sehogy se sikerült elérni az angol nyelv + magyar kiosztás használatát a GDM login képernyőn. :(

Ez szinte biztos, hogy GDM-sajátosság, gondolom Linuxon egy workaround-dal megoldották, hogy ne legyen ezzel gond. Persze együtt lehet élni ezzel, pláne, hogy automatikus bejelentkezést használok (csak én használom a gépet, nincs több user).

Kicsit zavarban vagyok, mostanában épp kísérletezem a FBSD-vel, uefi & geli kombóval szeretnék teljes lemez titkosítást, de dokumentációk nagy része erre nem ad receptet (arra van leírás, hogy az esp mellett legyen külön titkosítás nélküli /boot a kernelnek és a loadernek.).
Illetve valami régi hibajegyet is találtam, hogy uefi módban erre még nem képes a bootloader.

Illetve van még ez: https://www.youtube.com/watch?v=q8goXAkp-xo

Ezzel még nem kísérleteztem, nekem MBR+GPT sémával vannak a diszkek partícionálva, és idáig nem tapasztaltam semmi problémát se a titkosítás, se a boot folyamat kapcsán. Elvileg UEFI-kompatibilis az alaplapom (egy 2011-ben piacra dobott MSI alaplapról beszélünk), de kétlem, hogy egy kiforrott, bugmentes UEFI-implementáció lenne a flash-be égetve, tekintve, hogy ebben az évben kezdte az MSI bevezetni az UEFI-t a consumer kategóriás alaplapjain, idézem: "In 2011, major vendors (such as ASRock, Asus, Gigabyte, and MSI) launched several consumer-oriented motherboards using the Intel 6-series LGA 1155 chipset and AMD 9 Series AM3+ chipsets with UEFI.").

Köszi az összefoglalót!

Én is köszönöm az összefoglalót. Nálam egyelőre marad a slackware.

> Sol omnibus lucet.

Egy biztos, a kifogástalan mentális állapothoz, - nekem feltétlen szükséges,- "stabil állandóságérzést" a BSD biztosítja. Ehhez nagyban hozzájárulnak a böngészőből több-kevesebb rendszerességgel meglátogatott leak-tesztes oldalak nemleges képei. Már 3 éve nyugodtan alszom. - (Nyilván azért, - ha kijön és nincs fontosabb dolgom, - váltok egy újabb verzióra.)

(Ettől függetlenül, a körülöttem azért tömegben található W10-k - számomra, - reggelenkénti kérdőjeles állapota kelt bennem visszás érzéseket, de én legalább tudok dolgozni.)

+1 FreeBSD => igényelt stabil állandóságérzés

sub

Engem leginkább az érdekelne, az mit jelent h. pl 11.2 release-p1 vs. 11.2 release-p2. Az FTP-n csak 11.2 release.iso van.
--

Telepíted a letöltött 11.2-t. Ha a kiadása óta bejött valami gond (pl. itt vagy itt), akkor a telepített rendszereket lehet frissíteni a /usr/sbin/freebsd-update fetch install paranccsal - viszont új ISO-t nem adnak ki.
Ha jól tudom, akkor minden egyes ilyen "gond" után növekszik eggyel a -p értéke (gondolom, a patch szóból ered, és talán a "patchlevel" lenne a megfelelő kifejezés).
Esetleg bővebben itt.

kössz, elolvasom a linkeket, mert a nagy doksi oldalakon a release-logikát elég szűkszavúra vették, kb. semmit nem értettem meg belöle
--

Szívesen - remélem, nem mondtam nagy hülyeségeket és téves infókat :)

Az dokumentálva van, h. mi az aktuális legutolsó -pXYZ az adott pl. 11.2 release-hez, ill. mi a changelog pX és pX+1 között?

Ez az update amúgy forráskódos újrafordítós móka, v. csak binárisokat tölt le / cseréli a GENERIC kernelt pX --> pX+1 -re?
--

Ez binárist tölt le, cseréli a kernelt (ha szükséges) illetve a szoftvereket (ha szükséges) - persze részletesen kiírja, mit fog cserélni. Ha jobban tetszik, akkor újrafordítós mókázás is lehetséges, ezeknek a módjait is mindig írják (bár sose olvasom el, a freebsd-update nekem megfelelő).

Changelogot nem tudok (bár létezhet), max. a már korábbi linkeket vagy az svn log-ot tudom ajánlani.

Azt, hogy éppen milyen verziónál járunk, azt a freebsd.org oldalon a jobb oldali "Security Advisories" illetve "Errata Notices" blokkok legfelső bejegyzéséből lehet megtudnod. Amelyik a kettőből az újabb, abban a leírásban megkeresed a téged érdeklő ág (stable / X vagy releng / Y) "corrected" bejegyzését, és ott látod a patch-levelt. Jelenleg a 11.2-höz van SA is és EN is, de az utóbbi a frissebb, ezért az abban szereplő 11.2-p4 tekinthető legutolsó verziónak.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ez segített, megtaláltam!

Elég körülményes és átláthatatlan megoldás mondjuk.
--

Szerintem ez tetszeni fog:
https://svn.freebsd.org/base/releng/11.2/UPDATING
Vagy akár
svnlite cat https://svn.freebsd.org/base/releng/`uname -r | sed 's,-.*,,'`/UPDATING | sed "/`uname -r | sed -E 's,-p[0-9]+,,'`/q" :)

Az 1. link az emészthetőbb, és pont ezt kerestem ;-)

De miért kell ezt ennyire eldugni b+, h. földi halandó az életben ne találja meg magától, csak ha már megmutatták neki h
ilyen is létezik amúgy?
Pl. most már én is tudom h. létezik ilyen oldal, mégsem tudtam megtalálni épeszű úton a
https://www.freebsd.org/security/notices.html oldalról elindulva.

földi halandó az életben ne találja meg magától, csak ha már megmutatták neki
Nekem se mutatták meg, mégis megtaláltam. Azaz nem földi vagy pedig nem halandó vagyok? :)

Az 1. link az emészthetőbb, és pont ezt kerestem ;-)
A parancs esetleg azért lehet érdekes, mert (elvileg) csak az épp futó rendszerhez kapcsolódó frissítésékről szóló listát szedi le, a 3-4-5 évvel korábbiakat nem. Nyilván nem FreeBSD-rendszeren nem lesz olyan szép :)
Szerk.: sőt, ha még egy | sed -n '/^2/,$p' okossággal bővíted a parancsot, akkor a fájl elején levő információt se írja ki.

Hány perced / órád ment bele a keresgélésbe mielőtt ezt megtaláltad első alkalommal? Melyik URL direktlinkeli ezt?
Ha SVN-t hadználsz napi szinten, akkor te már nem földi halandó vagy ;-)
--

Hány perced / órád ment bele a keresgélésbe mielőtt ezt megtaláltad első alkalommal? Melyik URL direktlinkeli ezt?
Semennyi, mivel nem ezt kerestem, csak véletlenül botlottam bele. Az UPDATING fájl meg a ports-ban is van, ezért kíváncsiságból ránéztem, mit tud. Aztán rögtön eszembe jutott ez a szál, hogy valaki pont egy ilyet keresett.

Ha SVN-t hadználsz napi szinten, akkor te már nem földi halandó vagy ;-)
:)

(Csak zárójelben jegyzem meg, hogy az hogy az SA+EN segítségével ezt az infót hogy szeded össze, azt abban a pillanatban szoptam ki a kisujjamból, amikor itt felmerült, hogy honnan lehetne tudni az aktuális verziót. Annyi könnyítésem volt, hogy:
- láttam már FreeBSD-SA-t - és EN-t korábban, azaz tudtam, hogy abban benne van az éppen aktuális verzió száma/neve
- valamint voltam már a FreeBSD weboldalán is korábban, és emlékeztem, hogy ott vannak ezek a problémákról szóló hírecskék.

Szóval nem annyira reménytelen ezt ki- és megtalálni.)

Ezzel együtt is amikor ez felmerült, akkor nekem az jutott eszembe, hogy pl. ugyanezen infókat hogy lehet nagyon egyszerűen kinyerni RHEL, SLES és Ubuntu-server esetén.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Csoda, hogy nem szúrta ki a szemem :)

E6440-en is megy hibamentesen.

A rendszer pkg-val frissíthetősége elvben a 11-es ág újdonsága lett volna, de végül - mint tapasztaltad is 11.2-ig nem csinálták meg. Nem tudom, hogy mi a helyzet a majd egyszer megjelenő 11.3-mal, vagy pláne a most már remélhetőleg hamar itt levő 12.0-val e téren. (Egyelőre csak annyit látok, hogy noha 2-3 alpha szokott lenni az első béta előtt, most ALPHA10-ig (vagy csak 9-ig?) elmentek. A kiadást meg szokta előzni 2-3 Beta és 2-3 RC, kb hetente kiadva, azaz ha ezt az eszement csúszást a mostani verzióknál már nem ismétlik meg, kb 6 hét múlva esedékes.) Amúgy én is úgy vagyok vele, hogy a freebsd-update + pkg update + pkg upgrade nekem már elég (én annyit bonyolítottam csak a dolgon, hgy nem "quarterly" repót használok a csomagokhoz - ez ugye az alapbeállítás, hanem "latest"-et, így gyakorlatilag problémamentesen van szinte 100%-os frissességű desktop a stabil OS-en).

Elvben a 3D gyorsítás 12.0-tól sokkal közelebb fog kerülni a linuxos verzióhoz, ehhez mostanában elég sokat játszanak a különböző drm-* csomagokkal.

Jav: a régebbi sc(4) driver használatakor bele lehetett fordítani a kernelbe a billentyűzetkiosztást, az újabb vt(4) esetén egyszerűen nem tudom. (Ráadásul mivel ha új kernelt gyártok, akkor ezt a frissítésenként is mindig el kell játszani, így eről szépen leszoktam.) Nyilván az lenne az ideális, ha valahogy /boot/loader.conf-on keresztül be lehetne állítani a billentyűzetkiosztást (loader tunable-k segítségével), de nem tudom, hogy egyáltalán valaki foglalkozott-e már ilyesmivel, vagy felmerült-e egyáltalán. (Hm. Nem találom a kernel konfigot hozzá, így lehet, hogy erre rosszul emlékeztem, és csak a fontot lehetett kernelbe forgatni, a kbdmap-et nem.)

Ami pedig a sok tuningolható paramétert illeti, Linux alatt is van legalább ennyi. Amúgy nyilván nem minden esetben segít, de "man loader.conf rc.conf sysctl" , illetve a sysctl-ek egy jelentős részénél legalább szűkszavú leírást kapsz a sysctl -d ize.mize.ecet parancs hatására. Persze nyilván az nem ad vissza használhatót, amit az ember épp keres :-(

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Köszi, hasznos tudni ezeket!

A quarterly vs. latest ügyben én végül inkább visszaálltam a quarterly ágra. Ez is megkapja a security fixeket, csak nem mindig a legfrissebb verzió van benne a csomagokból, de engem ez egyáltalán nem zavar. Nem is tudom már, mi volt a gond, talán valami függőségi anomáliába futottam bele a quarterly->latest váltás után, de nem igazán volt hangulatom debuggolni a problémát, így inkább viszaálltam a quarterly ágra.

A saját kernel használatát nem favorizálom, fordítottam már FreeBSD-t (sőt, embedded eszközre is, ehhez még szkriptet is írtam), de az asztali gépemet nem szeretném hackelgetni, ezt a gépet kivételesen tényleg "csak" használni szeretném. :)

Közben eszembe jutott, hogy a text console környékén is volt egy kisebb problémám, igaz, ott az NVIDIA driver volt a ludas. Ha futó X szerver mellett átváltottam valamelyik tty-ra, egy színes, értelmezhetetlen karakterekkel tarkított fekete képernyő fogadott. Maga a rendszer nem fagyott le, simán vissza lehetett váltani grafikus módba, de a kimenet értelmezhetetlen volt. A megoldás itt annyi volt, hogy a vt drivert be kellett lőni sima, 80x25-ös (VGA) üzemmódra (most épp nincs előttem, de ha jól emlékszem, a loader.conf-ba kellett csak betenni egy sort).

Még nagyon az elején játszogattam a CURRENT release-ekkel is, de sajnos ezzel sem működött az AMD-s kártyámon a 3D gyorsítás, így feladtam és inkább a RELEASE ágra váltottam (pláne, miután a fórumon felhívták a figyelmemet arra a nem éppen elhanyagolható apróságra, hogy a CURRENT build-ek bármikor eltörhetnek, így nem célszerű ezeket "élesben" használni). Végül munkahelyről vadásztam egy selejtezett, de működőképes NVIDIA kártyát és felraktam hozzá a bináris NVIDIA drivert, azóta semmi panasz a 3D gyorsításra, ráadásul a hardveres MPEG-2/4 dekódolás is kiválóan működik. Ezek a feature-ök sajnos még mindig nem, vagy csak részben támogatottak az újabb Radeon kártyáknál (Southern Islands-től felfelé) a wiki oldalon írtak alapján.

Ha már megjelent a leírásban a linux_emu, akkor annyit hadd tegyek hozzá, hogy vannak (és voltak) kisérletek egyéb disztrók kényelmes támogatására is. Azaz volt (jóval) korábban linux_base-fc{3,4,5,6,7,8}, linux_base_f{9,10} (Fedora(Core)) illetve linux_base-debian, -gentoo, -rh, -suse port/package is. Igazából a CentOS 6 és 7 annyiban különleges, hogy egy csomó - az emulációval kapcsolatos dolgot - beállítanak a csomagokkal, de ha valaki OpenSuse-ra, Ubuntura vagy bármelyik egyébre jobban vágyik, akkor elvben kézzel össze lehet olyat is állítani. Nyilván itt is előjön az, hogy kevés a fejlesztő, így ezért koncentrálnak egy hosszú karbantartású disztrónak a FreeBSD alá reszelésére. Más kérdés, hogy igazából a RHEL/CentOS vonal nagy előnye, hogy nyilván kevés olyasmi van, amit valaki akarhat, de másik Linux disztróra van, erre meg nincs - gondolom én.

(Ha esetleg publikus, hogy mi volt amivel lukra futottál?)

Jav: volt egy időszak, amikor a linuxos a.out-ok is mentek linuxemuval, de az átlag Linux terjesztésben már nem volt a kernelben a.out támogatás, és valami korai 3D játék a.out-os formában volt elérhető, így FreeBSD-n a linuxemu telepyítése után már tudtam futtatni, valami akkori linuxon meg OOB már nem.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?