Miért BSD 2023-ban?

UNIX kezdő

Fiatal vagyok, na. Csak Window-zal és Linux-szal találkoztam komolyabban, egyetlen igaz Unix amihez valaha hozzáértem az egy kis OS X volt 15 éve.

De pl. ügyfél IT csapatának adtam már távsegítséget amikor z/OS-szel bajlódtak és viszket a tenyerem, hogy valami "igazi" Unix-szal játszak.

Olvasgatok (Free|Open)BSD-ről de nem találom azt a killer feature-t ami lét jogosultságot adna nekik a játékon felül.

jails? Visszalépés lenne cgroups v2 után
performance? Linux győz
network? eBPF után?
hardware támogatás? Ugyan
software támogatás? Áh
security? Oké, ha beérem egy nagyon minimal desktop-pal, akkor az OpenBSD bejön, de FreeBSD?
stabilitás? talán

Akinél ezek futnak, mi a rationale?

  • 3333 megtekintés

Egyszerűen végiggondoltam. Régebben a stabil és jó dokumentációt mindenképp kiemeltem volna, ma már ez se a régi, minden egyebet pedig helyből elvetett. Mivel a tanulási görbéje szerintem sokkal nagyobb elvetemültséget igényel, mint egy mai segkitörlős Linuxnak, szerintem 2-3 karácsony is kevés lenne hozzá.

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

 

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

 

Egy két mondatban: kell keresni valakit akinek van, kell még egy csavarkulcs, amivel addig vered amíg oda nem adja neked. Ez az xkcd poén ma már sajnos valóság: 

Bitcoin: nagyon észnél kell lenni, vadásznak a kriptodevizák tulajdonosaira a bűnözők – a kínzástól sem riadnak vissza

“Az ellenség keze betette a lábát”

( chx | 2023. 12. 22., p – 12:09 )

OpenBSD-t használtam desktopon egy ideig. Tetszik a minimalizmusa, és igazából mindent tudott ami nekem akkor kellett. Geek, puritán, letisztult, KISS principle, csont unix filozófia. Nekem handybb mint a FreeBSD, NetBSD. De azokkal is rendszeresen játszom.

Szerverként sosem használtam, leszámítva pár játszadozást (NFS, PF, Samba ilyenek). A vmd-t kipróbálnám.

echo crash > /dev/kmem

Van azért az több is...

OpenBSD fuzzer bugok: kb. 120, de ezek között viszonylag kevés a buffer overflow és hasonló, amit konkrétan támadásra ki is lehetne használni
FreeBSD fuzzer bugok: kb. 40, viszont szerintem sokkal súlyosabbak (csak megérzésre, nem néztem mindet egyesével végig)
Linux fuzzer bugok: á, hagyjuk, begörcsölt az ujjam a szkrollozástól (ezek között akad bejelentett is)

Azért azt látni kell, hogy ez nem minden bug, csak amik automatizmus révén kibuktak (szóval nem bejelentettek, így több van, mint CVE, ellenben besorolatlanok. Nem biztos, hogy minden double-free kihasználható támadásra). Az sem látszik egyáltalán ezekből a listákból, hogy ebből mennyi lett már kijavítva, márpedig az is fontos szempont.

Minimális összehasonlításra mégis jó: OpenBSD jobban van megírva, de kevesebben dolgoznak rajta; FreeBSD-t sokkal többen használják, így a hibákat hamarabb javítják, ellenben amit fuzzer talált, azok súlyosabbak. A Linux meg egy nyilvános wc, amibe beleszarik az Microsoft, Apple, Oracle, IBM, Intel, Facebook stb. akiket kurvára nem érdekel, hogy milyen minőségű a kód, csak az számít, hogy a marketingeseik elmondhassák, hogy a Linux támogatja őket, de azért a saját rendszerük a jobb! (Érdemes összeszámolni, ezekből a hibákból mennyi került céges commitok révén a kódba, és mennyi cégfüggetlen, valódi FOSS fejlesztők által.)

Kicsit sarkítva ez a lényeg. Ha nem kell IBM/Red Hat, Poettering, systemd/pipewire, stb. vécé, csak egy minimalista, egyszerű, tradicionálisabb unixos életérzésű rendszer kell, és a hobbi, szakmai kíváncsiság hajt valakit, és van hozzá teljesen kompatibilis gépe/hardvere, akkor éri meg valamelyik BSD. Egyébként érdemesebb a Linuxnál maradni, nagyobb benne a választék, több mindent futtat, több a driver, fs hozzá, azonos hardveren jobb teljesítménnyel fut, stb..

Amondó vagyok, hogy ha a gép támogatja, akkor érdemes vele mindenképp játszani, ismerkedni, már csak arra az esetre is, ha a Linuxszal, Torvalds-zal történne valami. Nagyban segít, ha Linuxon is máris minimalista vagy, szög egyszerű ablakkezelő, terminálos workflow, dobtad a systemd-t, stb.. Nem csak 2023-ban érdemes ilyenkor, hanem 2024-ben is, meg utána is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Passz. Dragont még sose próbáltam, mindig bennem van, hogy majd egyszer, és ennyiben is maradt eddig. Milyen gépről van szó, fizikai, virtuális, mi a konfigja? Tudtommal a Dragon-nek 64 bites proci kell meg AVX, simán lehet ennek hiányában bootképtelen.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezeket a hardver-követelményeket pontosan honnan szedted? A 64-bitet én is megtaláltam a (tetű lassú) oldalukon, de pl. az AVX-ről semmit nem találtam. Mondjuk lehetne egy kicsit összeszedettebb - vagy csak könnyebben megtalálható? - a HW-kompatibilitási listájuk, mert az hogy van egy roppant elavult listájuk arról, hogy valahol valaki milyen gépen próbálta, az azért édeskevés.

(Speciel az itt nagyon szeretett ChatGPT szerint amd64 és SSE2.)

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

Igazad van, én olvastam félre az AVX csak támogatott, de nem követelmény. Az SSE2 se követelmény, ahogy egy másik topikban esett róla szó, csak véletlen egybeesés, hogy az összes x86_64-es proci van olyan új, hogy az SSE2-őt mindegyik támogatja, de nincs megkövetelve.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Emlékeim szerint a kiadási megjegyzésekben benne volt, szóval azokat kellene végignyálazni. (Ami még felködlik, hogy talán az mkimg parancs okosságán múlott, de annak az épp aktuális manuáljában semmi érdemit nem találtam gyors átfutás után.)

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

Nem mostanában telepítettem, de nem hiszem, hogy sokat változott a telepítő. Szóval a telepítés során végig mentem az ablakokon, amíg a végén a config/options ablakig értem. Ott lehet felhasználót, időzónát, fontot stb. beállítani és ott van a hálózat beállítás is, talán network interfaces néven. Én abban az ~autodetect lehetőséget választottam és mindent jól beállított, nem kellett utólag matatnom az rc.conf-ban. Desktop gépre telepítettem, ami kábelen kapta a netet.

Esetleg segít, ha már ezeken túl vagy.

( n.balazs v | 2023. 12. 22., p – 23:11 )

Akkor felsorolok pár dolgot a BSD mellett és Linux ellen:
- évtizedes stabilitás: a BSD-nél nem szokás sűrűn variálni a dolgokat. Ami működött 10-15 éve, az valószínűleg most is pontosan ugyanúgy működik. Igen, ez egyben lassabb fejlődést is jelent, de kiszámíthatóságot is a BSD-sek számára. Nincs "divat faktor".
- licencelés: érdemes megnézni, hogy a BSD hogyan licencelődik egy tetszőleges Linux disztribúcióhoz képest. Üzletileg olykor előnyös a BSD-s megközelítés.
- systemd: nincs és (remélhetőleg) nem is lesz soha BSD-ben.
- klasszikus Unix filozófia és életérzés: a BSD közelebb áll hozzá. A kis Unixok gyakorlatilag kihaltak, sajnos.

A többi érveddel pedig lehetne vitatkozni. Mit is értesz pl: performance alatt.
A security meg erősen kérdéses. Ha pl: az ls-ben találnak egy CVE-t, akkor az a BSD / Linux sebezhetőségéhez sorolod vagy simán 3rd party kategóriába? Legtöbbször egy 3rd party cucc tartalmazza a sebezhetőséget.

Továbbá mihez ért az üzemeltetés, miben van tapasztalata, milyen alkalmazásokat használnak, azok milyen OS-t igényelnek stb. Ezek mind fontos kérdések, hogy BSD vagy Linux. Lehet reszelővel is fát vágni....
Szerintem.

az ls-ben találnak egy CVE-t, akkor az a BSD / Linux sebezhetőségéhez sorolod

Attól függ, melyik ls-ben :) Ha a GNU-s coreutils-ban levőben vagy pl. a FreeBSD alaprendszerében levőben :)

Felhasználói szemmel teljes mértékben egyetértek, én is ilyesmiket írtam volna kb. 10 évnyi felhasználói FreeBSD-s tapasztalattal.

A többi érveddel pedig lehetne vitatkozni.

Nem értek hozzá, így nem vagyok benne biztos, hogy a cgroups és a jail ugyanarra valók (ahogy a cgroups-ra rákerestem).

 Ami működött 10-15 éve, az valószínűleg most is pontosan ugyanúgy működik

Csak az a probléma, hogy BSD-nél ez ma 2025-ben szó szerint igaz. A 15 évvel ezelőtti Linux élményt adja a 15 évvel ezelőtti hiányosságokkal, hiányzó drivertámogatással és járulékos egyebekkel. 

Több értelmét látom akkor már a forráskódalapú Gentoo megismerésének. Az AI és kölcsönös bizalmatlanság korszakában ennek a tudásnak még akár értéke is lehet, amit később megfizetnek. 

“Az ellenség keze betette a lábát”

Nyilván nem mérvadó, de eddig négy különböző gyártmányú laptopon működött kifogástalanul, valamint kettő desktop gépen. Nem a legújabb technológiák, ez igaz, de minden hardver elsőre működött. Nemigen tudom, mire gondolsz ezen kívül a 15 évvel ezelőtti Linux élmény alatt (tehát kb. 2010), de úgy emlékszem, hogy ebben az időben pont az akkori Linux-élményekből* volt elegem, és próbáltam ki a FreeBSD-t (és azóta se bántam meg).

Ha a hiányzó drivertámogatás a fő ellenérv, ez lehetne ellenérv a Linux vs. Windows esetén is.

 

* Lehet, hogy ez inkább Arch-specifikus és mindenféle csillagzat szerencsétlen együttállása volt: akkoriban változott minden, szinte minden frissítésnél kellett valamit kézzel elvégezni, ami néhány alkalommal LiveCD-s javítással végződött (pedig a leírás szerint csináltam). FreeBSD alatt a kb. 12 év alatt ilyennel nem találkoztam.

Modern GPU-k támogatása korlátozott. CUDA, ami nélkül nincs machine learning teljesen hiányzik a BSD világból. 

Realtek és Broadcom wifi támogatás is véleményes sajnos FreeBSD-n. A többi BSD ágon csak rosszabb a helyzet. 

USB perifériák támogatása, ACPI, hibernálás, netán érintőkijelzők szintén nem támogatottak BSD-n. 

Szerver oldalon sem makulátlan már a FreeBSD hírneve. Bhyve már nem egy fejlett virtualizációs megoldás. KVM/QEMU, Docker/Kubernetes ma már egy magasabb ligát képvisel. GPU passtrough sem működik FreeBSD-n. 

HBA kártyák, NIC-ek támogatása is problémás.

Ezzel szemben ugyanez már régen nem áll Linux vs Windows esetében. Sőt machine learningben ma már de facto Linux a standard. Ha Windowson fejlesztesz ML-re kelleni fog a WSL2 Linux. 

“Az ellenség keze betette a lábát”

Nyilván igazad van - bár alá semmivel nem támasztottad magvas gondolataidat.

Én most kizárólag FreeBSD-ről beszélek: Pontosan mi hiányzik a modern GPU-k támogatásából? Én a drm-61-kmod csomaggal (ez 6.1.es Linux-kernelbeli driverek portolása) illetve nvidia-drm-61-kmod csomaggal használom a laptop és desktop gépeimet, de aktívan folyik a drm-66-kmod hangolása. Megy.

CUDA-ról nem tudok véleményt nyilvánítani mert nem használom, de azt olvastam, hogy - mivel nem adták ki FreeBSD-re, azt valóban kénytelen vagy Linuxon fejleszteni. Az más kérdés, hogy ha már lefejlesztetted, akkor viszont a linuxemu szépen futtatja. (És ha már: a FreeBSD-mre ``pkg install ollama llama-cpp'' paranccsal tudtam felrakni ezt a két ismert LLM futtató környezetet - azaz a natív csomagtárolóból húztam le őket, de egy 24.04-es Ubuntura a gyári tárolóban már csak snap-féle ollama volt, llama-cpp meg egyáltalán nem. Persze nem komoly a baj, de azért nincs az a FreeBSD annyira lemaradva.)

Nem tudom mi hiányzik az USB, ACPI, hibernálás részből, a meglevő USB-s eszközeim használhatóak, az egyik laptopomat mióta megvan (kb fél éve) kb 2x kapcsoltam ki, rendszeresen hibernálom, és nem okoz fájdalmat neki. ACPI esetén mit hiányolsz?

Ebben a doksiban én azért látok komolyabb HBA-kat, nagyobb sebességű NIC-eket is, mi a probléma?

Itt egy leírás a bhyve és a GPU PT viszonyáról.

Docker tudtommal valóban nincs, de Podmannal azért lehet játszadozni  - legalábbis egy jó ideje elég sokszor szerepelt a negyedéves FreeBSD jelentésekben.

Szóval velőset mondtál de azért nem értünk mindenben egyet.

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

A commentet nem csak válaszként szánom, de saját tapasztalatot is szeretnék a freebsd-ről megosztani, azokkal, akiknek kétsége van, de esetleg még nem jól ismerik:

Az más kérdés, hogy ha már lefejlesztetted, akkor viszont a linuxemu szépen futtatja. (És ha már: a FreeBSD-mre ``pkg install ollama llama-cpp'' paranccsal tudtam felrakni ezt a két ismert LLM futtató környezetet

+1 Nem tettem fel, de olvastam róla leírást, ez működik, valóban linuxemu szépen futtatja, a leírások alapján is. Viszont utána ezt a környezetet felhasználhatod akár fejlesztéshez is, tehát lehet freebsd alatt fejleszteni.

Hibernálás

Linux alatt még egy gépet nem láttam, amin a deep sleep rendesen működött, össze-vissza kell konfigolni, hogy csak az esetek 20%-ban "fagyjon ki". Freebsd alatt (persze egy egyszerűbb környezetben használtam, de) tökéletesen működött.

bhyve

Használom, semmiben nincs hiány. Sőt, tökéletes... Ez a többi hypervisorral valószínűleg ugyanígy működne, de cloud image-eket futtatok cloud init-tel. Stabil, gyors, átlátható. A FreeBSD-n a bhyve "otthon van".

podman

Ezt ki kellene próbálni. A jail-eknél nekem nagyon hiányzik a docker-compose szintű élmény, az fájdalmas kicsit, hogy mindent úgy kell telepíteni, mint ha egy különálló gép lenne. Jó lenne előre összeállítani a dolgokat, és docker-compose szerűen felhúzni ezeket a gépeket. Az újrateleptés így kb fél perc lenne, szemben a 2-3 órától, ami nekem most lenne, egy újratelepítés esetén. De lehet, hogy nem jól használom. De végülis minden tökéletesen működik.

Egy freebsd gépem van (illetve egy RPI-vel együtt kettő, ami egy "backup" zfs replikációval), a ZFS nagyon a Freebsd mellett szól. Tudom, hogy fel lehet tenni linux alá is, de itt natívan támogatja. Már a root fájlrendszer is raidben van, bármelyik diszket fél perc alatt ki lehet most cserélni elvileg.

A ZFS-t így FreeBSD-vel egy stabil robosztus valaminek érzem/látom, amire rá mernek bízni komolyabb adatokat is. Sok félreértés van vele kapcsolatban szerintem:

1. Nem kell ECC memória. Más fájlredszer esetén úgyanúgy kellene, ha itt is kellene. Ez nyilván egy újabb biztonsági védőháló, ha valakinek van rá lehetősége, akkor miért ne. De én anélkül használom.

2. Nem kell hozzá sok memória. Nyilván akkora cache-t csinál, amennyi van, de ez tökéletes. Ugyanúgy fog működni egy kevés memóriát tartalmazó géppel. A memóriát amúgy szépen "átengedi" ha egy alkalmazásnak kell.

3. Hát magam is meglepődtem, de a ZFS full felhasználóbarát. Logikus, nincs benne semmi bonyoladom, el lehet vele nyugodtan indulni, anélkül, hogy az ember végigcsinálna akár egy több hetes tanfolyamot, vagy elolvasna többszáz oldalt. Persze később aki használja fog olvasni, de semmi bonyolultat.

A ZFS-ről még egy mondatot: alappillére a FreeBSD-nek, Több alkalmazás támaszkodik rá, és (szerintem) ez az egyik oka, hogy az ember FreeBSD-t választ.

A FreeBSD egy 15 évvel ezelőtti linuxra hasonlít

(írta itt valaki) Pont ez az egyszerűsége az, amit valaki vagy megért, és lát, vagy nem lát, de ez teszi zseniálissá. Keep it simple, do one thing good elv, amit általában dijjazni szoktam/szoktak egy rendszer esetén.

Nem retro rendszer, de kétségtelen van egy ilyen feelingje. Megelégedés érzés, a letisztult rendszer, amikor belépsz egy friss telepítés után, és 1, vagy két képernyőn elfér a futo processek száma. Inkább az a kérdés, hogy máshol miért is több. Nincsenek rejtett automatizmusok, háttérzaj, csak az fut, amit kérsz. És voilá, átlátható, stabil.

Talán a PF-fel volt a legnagyobb küzdelmem, itt is kaptam segítséget (utólag nézve talán nem bonyolult amit csináltam), de most van egy olyan gépem, amin kb 10-12 szolgáltatás fut, egy dobozként látszik kívülről az egész, és egy tűzfal és egy reverse proxy gondoskodik róla, hogy csak az legyen nyitva, csak az legyen elérve jail-ben, és a host-on is, ami kell. Kívülről meg egy "NAS"-t látsz, integrált egyéb funkciókkal. (Samba, NFS, plex, adguard, gitea, transmission, traefik, stb...)

 

Tanulási görbe

Ezt saját tapasztalat alapján mondom: Egyáltalán nem meredek. El tudod kezdeni használni, és egyik lépést csinálod a másik után, mindent el tudsz érni. Mondhatni a legjobb doksija van, és nagyon támogató a közösség.

1. Nem kell ECC memória. Más fájlredszer esetén úgyanúgy kellene, ha itt is kellene. Ez nyilván egy újabb biztonsági védőháló, ha valakinek van rá lehetősége, akkor miért ne. De én anélkül használom.

Szerintem ez arra vonatkozott, h. sok dolgot cache-ben (RAM) tartott, és ha volt hibázás, az keresztbe fektette a teljes fs-t. Más fs nem használ általában annyi RAM-ot, mint a ZFS

2. Nem kell hozzá sok memória. Nyilván akkora cache-t csinál, amennyi van, de ez tökéletes. Ugyanúgy fog működni egy kevés memóriát tartalmazó géppel. A memóriát amúgy szépen "átengedi" ha egy alkalmazásnak kell.

Ez is némileg kapcsolódik az 1.-hez. Tisztán emlékszem a rémtörténetekre 15-20 évvel ezelőttről, h. há a ZFS-nek kell min. 8 GB RAM, különben meg se mozdul (ami RAM akkoriban a legnagyobb szerverek kivételèvel még sci-fi-nek hatott, főleg hát egy "fájlszervernek").

Szerintem ez arra vonatkozott, h. sok dolgot cache-ben (RAM) tartott, és ha volt hibázás, az keresztbe fektette a teljes fs-t. Más fs nem használ általában annyi RAM-ot, mint a ZFS

Itt említik meg, hogy a ZFS-hez ECC memória kell. 

https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.ht…

Ez itt egy ajánlás, amit sokan úgy értelmeznek, hogy akkor felesleges is vele menni, holott más fájlrendszer esetén ugyanúgy ki vannak téve a bit flip-nek a memóriában.
Page cache-t minden használ. Nincs a lemezen (tök mindegy milyen fájlrendszer) olyan adat, ami nem memóriából került kiírásra, vagy nem memórián/cache-en keresztül kerülnek kiolvasásra.

ZFS esetén ezt ajánlják is, mert egy plusz védőháló, de ez nem azt jelenti, hogy ECC ram nélkül bármelyik másik fájlrendszernél "problémásabb" lenne. Sőt, a ZFS-el annyival előrébb vagy, hogy lemezre íráskor checksum-ot számol, és ki fog derülni később, ha valami félrement. Tehát nem rosszabb, hanem biztonságosabb.

Az ECC jó dolog, és enterprise környezetben mindenképpen javasolt. Más fájlrendszer, és más jellegű alkalmazások miatt is, ezt függeltenül, hogy ZFS-t, vagy mást használsz.

 

Ez is némileg kapcsolódik az 1.-hez. Tisztán emlékszem a rémtörténetekre 15-20 évvel ezelőttről, h. há a ZFS-nek kell min. 8 GB RAM, különben meg se mozdul (ami RAM akkoriban a legnagyobb szerverek kivételèvel még sci-fi-nek hatott, főleg hát egy "fájlszervernek").

Ha 2 Gb memóriád van, akkor mondjuk 1 GB memóriát (ARC cache-t) fog használni. Ha pl a bekapcsolod a tömörítést, meg egyéb feature-öket (nem tudom mi van, ami még memória igényes, pl sok-sok-sok user, de az más fájlrendszer esetén is), akkor van szükség többre.

Az ARC cache-nél egyébként azt is látod, hogy "húú mennyit foglal" (állítható egyébként a max méret), de egy program azt simán lefoglalhatja, ha kell a memória, a ZFS "átengedi" - gondolom innen is adódik még félreértés.

Egy írás erről, de több is van, akár YT-on is:

https://distrowatch.com/weekly.php?issue=20150420#myth

Tehát szerintem előnye az van, de hátrányát nem igazán látok... A licenszelése max, ami akadályozza a terjedését pl. linux-on.

> holott más fájlrendszer esetén ugyanúgy ki vannak téve a bit flip-nek a memóriában.

igen, anno (~25 eve) meg is tapasztaltam. beraktam a gepembe plusz memoriat (akkoriba meg nem volt memtest86 es tarsai), szepen mukodott is... ugy 2 hetig, amikor szethullott az ext2 rajta, mint utolag kiderult a memoria nem volt az igazi...

( jevgenyij | 2025. 06. 13., p – 12:07 )

Egy erős érv bármelyik BSD mellett, hogy nincs bennük systemd. 

Egyébként a Linuxok vagy GNU/Linuxok ugyanannyira unixok mint a BSDk. A Unix tanúsítványt nem magának a Linux kernelnek állítják ki hanem disztribúciónak, és van olyan Linux disztribúció ami megszerezte a Unix tanúsítvány, szóval van olyan Linux ami hivatalos Unix ha annyira számít neked a cert. 

“Az ellenség keze betette a lábát”

Biztos vagy abban, hogy van olyan Linux, amit Unix tanúsítvánnyal rendelkezik? Én nem látom ezen az oldalon:

https://www.opengroup.org/openbrand/register/

"Mert nincs különbség: mindenki vétkezett, és híjával van az Isten dicsőségének. Ezért Isten ingyen igazítja meg őket kegyelméből, miután megváltotta őket a Krisztus Jézus által." (Róma 3.22-24)

Ez egy marketing plecsni, bárki vehet a saját oprendszerére Unix plecsnit, igaz meg kell felelni némi POSIX követelményeknek, de a lényeg, hogy tejeljél a névhasználatáért. Ahogy írták, az EulerOS egy olyan Linux disztró, amire megvették a plecsnit, de ez csak konkrét verzióra szól, 2.0. Ha van újabb verziója, arra a plecsni nem érvényes, csak ha újra megveszik.

Az Apple is meg szokta venni minden egyes MacOS főverzióra, emiatt néha egy-egy verziónál van egy kis fáziskésés, hogy nincs megadva még rá, csak megigényelve, és csak később kap plecsnit. Pl. a MacOS Sequoia-ra meg van véve, de a Tahoe-ra még nincs.

Természetesen az egész nevetséges, ez csak üzlet, marketing, ha van plecsnid, az csak azt jelenti, hogy pénzt szántál rá, de ettől a rendszer nem lesz igazibb vagy eredetibb Unix, mint egy akármilyen másik BSD, Linux vagy Illumos disztró. Nem is értem, hogy minek veszi még akárki is ezt a plecsnit, annyira komolytalan, idejét múlt valami. Pl. ha jól megnézed, akkor már a SunOS, Solaris, stb. sincs rajta a listát, azok feltehetőleg rajta voltak, de lejárt rájuk egy régi verziónál.

Ma már az összes Unix és unixlike rendszer más csak igazából unixlike, 64 bites támogatással, sok millió új kódsorral, új technológiákkal, új fájlrendszerekkel, új csomagkezelővel, virtualizációs és konténerizációs megoldással, új hálózati protokollokkal és csatolókkal (Wi-Fi, BT, stb), új biztonsági követelményekkel. Egyiknek sincs már köze az eredeti kódbázishoz, annyi új technológia be van emelve mindegyikbe. A régi kódból már csak néhány kernelhívás meg néhány pontosvessző maradt meg.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( jimmy399 v | 2025. 06. 15., v – 00:54 )

Sziasztok!

 

Még új vagyok a BSD-ben, de mostanság ismét eljátszottam a gondolattal, hogy telepítek egy FreeBSD-t. A célgép egy Intel Atom N570-es DELL Inspiron 1090 duó lett. Gondoltam teszek egy próbát rajta, hogy egy Debian 12-höz képest hogy megy. 

Szokás szerint amennyire tudtam átolvastam a kézikönyvet, ismét ráeszméltem, hogy azért más, mint egy linux.

Sokadik nekifutásra feltettem a rendszert, egy partícióra, és sajnos az X.org-nál elakadtam, mert csak VESA módban indult el. Intel grafika, azért elég régi, de lehet én szurtam el valamit, így majd újratelepítem a rendszert és keztem előlről.

A poén, hogy a Stage 2 boot loader nem tudta a stage 3 loadert betölteni, és a root fs-t se tudta a kernel csatolni, ezeket kézzel adtam meg. A wifi csatoló a laptopban elég egzotikus, sajnos nem látja a kernel sem, így egy usb-s csatolót használtam. Az X.org-os driver telepítéssel próbálkoztam, de gyakrolatilag zsákutcára futottam, a No dri device found hibával, így sajnos a gép 1024x768-as felbontással VESA módban kb engedjük el kategória sajnos.

 

Meglátom mi sül ki az újratelepítéssel, (usb-s külső SSD-re tettem a rendszert elsőre is, de a bootloader valahogy eddig nem tippelte meg jól merre van a rendszer), hátha használható lesz.

FreeBSD 14.3 RC1-es telepítő iso lett letöltve, a laptop csak Legacy módot ismer. Debian telepítve, Win7 telepítve, és grub2 rendszerbetöltő kezeli a dual boot-ot, és a grub2-ben chainloader (hd0,3)+1-el sikeresen betölti a FreeBSD stage1-et, aztán az a Stage2-őt, majd behal a Stage3 előtt. Ja igen, olvstam, hogy a FreeBSD csak elsődleges partícióról tud indulni.

A feleségem régi laptopjára én is nehezebben tettem fel, mert látszólag felismerte a wifi csatolót, de nem volt a driver lefordítva/nem az volt ott, aminek kell -  valami gond volt.

A jó drivernek a forráskódját töltöttem le végül, és azt lefordítva megjavult.

Az X-szel nekem szerencsére nem volt gondom, a FreeBSD doksiban leirtakat nagyon szigorúan végigkövettem, akkor elkezdett működni. XFCE-t tettem fel.

Egy külső SSD-re is feltetettem, hogy a saját gépemet kipróbáljam: Ez egy modernebb gép, 11. generációs intel, Z590-es (?) Gigabyte alaplappal, nvidia videókártyával. Itt minden ment elsőre. (itt is szigorúan a freebsd doksit követve az X esetén).
Ami nem tetszett: feltettem a Vice-ot (c64 emulátor), fordítani kellett. Órákig fordította a csomagokat, amik kellenek még, nem volt meg lefordítva. A vice-ot lefordítani 1-2 perc amúgy, ha minden csomag megvan. (vagy valamit elcsesztem)

További tapasztalat: Laptopon fájdalmas volt, hogy konfig fájlt kell szerkeszteni egy webkamera hozzáadásához. (nem egy-két kattintás volt) - lehet, hogy nem jól csináltam.

"Szerver gépen", otthoni NAS-on: Minden elsőre megy, jól működik. Itt nem kell wifi csatoló, webkamera, és X.

A vice (meg általában a binárisan nem elérhető csomagok) kapcsán nekem az jött be, hogy elindítom a fordítást a ports-ból, és mihelyt elkezd valami függőséget csesztetni, azonnal megszakítom, és pkg install -U izé/mizé. Aztán újra indítom a ports-ból való ferdítést. Ezt csinálom egy a következő függőséggel, újra és újra. Ez ugyan fapados, de a szükséges dolgok 98%-a megvan binárisban, szóval a végén mégis csak keveset fog fordítani. Ez valóban nagyon fájdalmas, régebben ha jól rémlik a portmaster-t használtam, annak (tán valami -PP opcióval) meg lehetett mondani, hogy az elérhető dolgokat binárisból húzza, és csak minimálisan fordítson. De tudtommal ezt a natív pkg + ports nem tudja. (De igény az volna rá!)

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

az X.org-nál elakadtam, mert csak VESA módban indult el

Ezek (különösképpen ez) megvoltak?

wifi csatoló a laptopban elég egzotikus

Tudhatunk róla bővebbet is?

FreeBSD 14.3 RC1-es telepítő iso lett letöltve

Néhány napja megjelent a 14.3-as is (tehát nem rc), próbáld inkább azzal!

Igen,  megvolt mind a kettő. Betűre tűpontosan végeztem el a beállítást és telepítést, ahogy a kézikönyv írja, de sajnos nem sikerült így sem.

 

A csatoló egy BCM43xx csatoló, amihez hiába telepítettem a doksi alapján a drivert, nem látta egyáltalán a rendszer a sysctl -n net.wlan.devices nem ad vissza semmilyen adatot.Egy pkg update/upgrade-t már indítottam és azóta gondolom már nem RC1 hanem a  14.3

A pkg-vel az OS-t nem frissíted, ahhoz ``freebsd-update upgrade -r 14.3-RELEASE'' kellene (meg a további lépések).

A BCM43xx működéséhez meg vagy bwi-firmware-kmod vagy bwn-firmware-kmod csomag is kell. Amikor ez a kettő fönt van, akkor próbáld meg kézzel betölteni előbb az egyik drivert, aztán a másikat:

kldload if_bwi

kldload if_bwn

Ha valamelyik után lesz wifid, akkor annak a firmware-csomagját tartsd meg (a másikat töröld le: pkg remove....), és azt töltsd be automatikusan ``sysrc kld_list+=if_bwi'' (vagy if_bwn) formában.

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

Ha kézzel meg tudod adni a Stage2-nek, hogy honnan vegye elő a Stage3-t (ez a loader, ha jól rémlik), meg hogy mi a rootfs, akkor a működő rendszerben ``man boot boot.config'' (ez írja le a legacy boot-ot és a konfig fájlját) és máris lehet megcsinálni a /boot.config fájlt, amibe fel lehet venni a szükséges parancsot, hogy automatikus legyen a dolog. Esetleg ha ez kevés, akkor még lehet a loader-nek is el kell mesélni, hogy mi a rootfs, ehhez meg ``man loader loader.conf'' (Régebben nekem is volt olyan gépem, ahol a diszkek számozásával nem volt megelégedve, és valami nyakatekert paraméterezéssel lehetett csak rávenni a helyes bootra.) 

A korábban említett drm-kmod -ot azért még próbáld meg.

(Illeve majd mondj egy ``pciconf -lv'' -t, és a wifi sorait dobd be ide, hátha valami kijön belőle (bár asszem manapság a devmatch kb. minden támogatott eszközt meg kéne találjon :-( )

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

Jelenleg azzal küzdök, hogy a letöltött lemezképfájlt, felírjam pendrive-ra és ventoy-al futtassam. Elsőre gondoltam úgy is lassan jön lefelé, így közvetlen a pendrivra tölöttem le, aminek az eredménye egyvillogó kurzor lett a bal felső sarokban. Töröltem a pendriveról a képfájlt, letöltöttem gépre, majd felmásoltam a penre. Telepítő indul cheksum error... 3. alkalommal másolom a penre, és most már másolás után indítok egy cheksum ellenőrzést is. Hajam hullik most már...

65.558782] exFAT-fs (sdb1): Invalid exboot-signature(sector = 8): 0x2d8aa215
[   65.560010] exFAT-fs (sdb1): Invalid boot checksum (boot checksum : 0xc3e233c9, checksum : 0x3df4a34f)
[   65.560016] exFAT-fs (sdb1): invalid boot region
[   65.560018] exFAT-fs (sdb1): failed to recognize exfat type
 

 

I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2

sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current] 
kernel: Buffer I/O error on dev sdb, logical block 0, async page read
sdb: unable to read partition table

 

Hiába partícionáltam/formáztam dobja a hibát.

Sikeresen megkotlott a pen. Csere nincs itthon, így most ez a telepítés elmarad egy ideig.
 

Ha ilyennel foglalkozol, érdemes tartani tartalék pendrive-okat, külső meghajtókat. Nem baj, ha régi, lassú, kis tárhelyméretű. Nekem egy doboznyi ilyen szar van itthon, régi pendrive-ok, 2 gigástól a 16 gigásig, meg HDD, SSD-k és hozzájuk való SATA/USB átalakítók, de még M.2 SATA, M.2 NVMe SSD is fekszik el itthon, de ez utóbbi kettőhöz nincs még átalakítóm. Nem költöttem ezekre érdemi pénzt, az évek során gyülemlett fel, jöttek ajándékba, régi gépekkel, vagy használtam vettem potom pénzért.

Evileg SD, mikroSD kártya és hozzá való olvasó is játszhat, esetleg CD/DVD-re kiírod a lemezképet.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezek ilyenek, szeretnek x idő után, mindenféle előjel nélkül megdögleni, még akkor is, ha kímélve volt, nem volt sokat használva. Fogyóeszköz. Én az SD/pendrive helyett az SSD-ket preferálom egy ideje, ha még csak SATA2-őn is megy, meg USB 3.0-s sebességre korlátozva, 300-500 MB/sec-kel, akkor is töredéke idő, míg kiírod rá dd-vel a lemezképet, meg bebootol, telepítési idő is nagyon röpke bármilyen OS esetén, ha SSD-ről SSD-re települ, tényleg ilyen 1-2 perces nagyságrend.

Egyedül akkor nem erőltetem az SSD-t, ha minimal netinstall-os a cucc, és úgyse a drive sebessége határozza meg a telepítési időt, hanem a net sávszélessége, hiszen ilyenkor minden csomagot a tárolókból húz le, akkor egy lassabb pendrive is elég, akár egy USB2-es, régi, 2 gigás szutyok is.

Érdemes szétnézni ismerősöknél, rokonoknál is, lehet nekik is van a fiókban ilyen elfekvő régi drive, pendrive, SD kártya, ezeket az emberek általában behalmozzák, nem használják, és úgyis csak kidobják.

Amit én még tanácsolok, hogy ha akármilyen BSD-t telepítesz, mikor ahhoz a telepítési részhez érsz, ahol particionál, meg slice-okat kell választani, hogy ott kézzel csináld, mert egyébként őskorból fennmaradt tradíció alapján szétaprózza mappánként a partíciókat, jobb inkább modern séma szerint mindent egyben particionálni, elég, ha csak a /home van külön, esetleg /boot vagy szervernél a /var, ha a log túlhízik, ne fogyjon el a hely.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

ha akármilyen BSD-t telepítesz, ... ott kézzel csináld, mert egyébként őskorból fennmaradt tradíció alapján szétaprózza mappánként a partíciókat

NetBSD: egy partícióm van a /, nem emlékszem hogy kézzel változtattam rajta

FreeBSD: dettó

DragonFly: alapból /, /boot és /build partíciókat ajánl fel. Ott az OS frissítés nem bináris, hanem újrafordítós azért a /build

OpenBSD rémlik egyedül úgy, hogy eléggé darabol, de azt évekkel ezelőtt telepítettem, most nincs vm-ben sem, szóval az passz.

Akkor lehet ezt megszüntették, ami pozitív. Emlékeim szerint a FreeBSD-é, NetBSD-é is ugyanolyan szétszabdalt volt, a DragonFly-ról nem tudok nyilatkozni, azt még nem telepítettem. Lehet attól is függ, hogy UFS-sel vagy ZFS-sel telepíti valaki a rendszert, én UFS-sel szoktam.

Azzal sem lenne baj, ha több partíciót csinálna, de túlzásba viszi, ilyen néhány megás szutykokat hoz létre. Szerintem ez még a PDP11/VAX időszakból visszamaradt szokás, hogy ilyen 10-20-40 megás RA10 HDD-kre kellett szétosztani a rendszert, mert egy HDD nem volt olyan nagy, hogy az egész felférjen és még hely is maradjon.

Ha indokoltan osztja szét, az nem baj, pl. /home, /var vagy /build, az teljesen jó. Az se jó, ha minden egyben van, még a /home se lenne külön, mert akkor esetleg minden rendszer-újratelepítéskor mentésből kell visszahuzigálni a felhasználói adatokat.

A másik, ami szintén ilyen konzervatív elmaradottság, az hogy a BSD-k zöme a kernelparaméterek defaultjait is még nagyon régi, gyenge, kevés RAM-os gépekre határozta meg, és nem nyúltak hozzá 20-30 éve. Általában BSD-nként vannak tutorialok, hogy melyik kernelparaméternek az értékét kell emelni, hogy jobb legyen a teljesítmény vagy az energiatakarékosság.

OpenBSD-nél, ha gyenge a gép (1-2 magos, vagy 4, de gyenge magok), én a default letiltott Hyper-Threadinget is visszakapcsolom, nem érdekel semmilyen Spectre meg Meltdown, 30-50% teljesítményt nem hagyok veszni, mert valami Google Zero Security Influencer barom szerint támadható. 6-8 magos, modernebb, combosabb hardver már lehet nincs annyira rászorulva, 16-32 magnál meg néha egy-egy szoftvernek a futásán adott esetben a HTT még ronthat is pár százalékot.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Particionálás:

/

/boot

SWAP

/tmp

/usr

/var

/home

/opt (vagy /usr/local )

Ez mind indokolt. Itt - az indoklásba - beleszámít olyasmi is, mint mount-opciók (*), mentéssel kapcsolatos beállítások, kvótakezelés. Nem csak 1-felhasználós (desktop) rendszerek vannak, és nem csak usermentes szerverek, tehát attól, hogy nálad meg a Bélánál nem kell, simán lehet olyan rendszer, ahol viszont igen. Mindez megfejelve azzal, hogy tudtommal az összes aktív BSD a mai napig a szerver funkcióra lő elsődlegesen, attól még hogy én desktopnak használom, nem biztos, hogy e miatt ezen változtatnának.

A kernel paraméterekről nem tudom honnan szedted a mikori infóidat, de mondjuk FreeBSD-ben biztos hogy van egy vagon olyan, amire helyből nem igaz, hogy ezer évvel ezelőtti hardverre lennének belőve. Sőt van egy csomó olyan, ami eleve dinamikus, a bootkor látható hw-körülményekhez igazodik.

Sokadszor mondom, FreeBSD-vel kapcsolatos sommás véleményeid időnként erősen revideálásra szorulnak. Nem azt mondom, hogy amíg nem használtad aktívan 30 évig, addig ne alkoss róla véleményt, de kicsit jobban hangsúlyozd ki azt amit TUDSZ (releváns, többé-kevésbé friss tapasztalatból), és egyértelműbben kéne jelezni amit hallottál vagy pláne csak megálmodtad.

 

(*) ez lemaradt. Aki azt mondja egy RO / noexec mount-flag nem számít, mert úgy is a kernelt megborítva törik a mai rendszereket, az ugyanezen okból miért kapcsolja be az AppArmort vagy a SELinuxot? Ha a kernel borul ... Amúgy egy ilyentől nem lesz biztonságosabb egy rendszer, de kevésbé biztonságos sem.

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

Csomó FreeBSD tutorial van a neten, pl. Vermaden és mások tollából, hogy desktop telepítés után ajánlanak fine tuningot, egyes kernelparamétereknél, jellemzően ilyesmiket említenek ezek a leírások, a teljesség igénye nélkül pár példa, amiket most megtaláltam, nem mennek ezek fejből:
kern.ipc.shmmax
kern.ipc.shmseg
kern.ipc.shmmni
kern.maxproc
kern.ipc.shm_allow_removed
kern.sched.preempt_thresh
vfs.read_max

Ezeket, és hasonlóakat NEM KELL, de érdemes állítgatni, desktop felhasználásnál elvileg jobban, reszponzívabban futhatnak a dolgok utána. OpenBSD-n is vannak ilyenek:
kern.maxfiles
hw.smt (ez nem konzervativizmusból, hanem biztonsági mániából van tiltva default)
apmd_enable

Még Linuxnál is vannak ilyenek, de kevesebb és itt könnyebbség, hogy általában ilyenkor a nagy disztrók ezeket telepítésnél automatikusan módosítják, hogy ne a usernek kelljen ezt még külön telepítés után állítgatni:
vm.max_map_count
vm.swappiness
vm.dirty_ratio
hasonlók, kinek mire van igénye

Van, aki hardeninget is ajánl, random PID, user ne lássa a rendszerfolyamatokat, hasonlók, ez is igény szerinti.
 

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nemrég telepítettem egy régi laptopra FreeBSD 14.2-RELEASE. Én ZFS-t használtam:

kleinie@amilo:~ % gpart show 
=>       40  488397088  ada0  GPT  (233G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048    8388608     2  freebsd-swap  (4.0G)
    8390656  480006144     3  freebsd-zfs  (229G)
  488396800        328        - free -  (164K)

Szerintem ha UFS-t választom akkor sem darabolja már szét.

Valószínűleg ventoy-bug + freebsd releae specifikus lehet a dolog. Kijön mindig egy újabb linux disztró, és lehet a ventoy-t utána húzni pár héttel később, mert nem megy.

Pedig úgy adták elő a ventoy-t pár éve, mikor először hallottam róla, mint a legjobb találmányt a kerék és a melegvíz után; innentől kezdve életed végéig csak 1 db pendriájvra lesz szükséged, rajta az összes létező ISO amit telepíteni akarsz, és fog minden menni róla gond nélkül. Hát, ahogy nálam okosabbak szokták mondani: egy lófaszt! :)

( jimmy399 v | 2025. 06. 16., h – 19:11 )

Szerkesztve: 2025. 06. 16., h – 19:12

Itt vannak a dmesg és Xorg log kimenetek:

 

Kernel:

https://pastebin.com/G7KcmEBi

 

Xorg:

https://pastebin.com/XSZ3Dk3s

 

pciconf kimenetet majd holnap teszek fel.

 

"Amit az fwget parancs ad, azok a csomagok is fel vannak telepítve?" Holnap megnézem ezt is.

 

"A BCM43xx működéséhez meg vagy bwi-firmware-kmod vagy bwn-firmware-kmod csomag is kell. Amikor ez a kettő fönt van, akkor próbáld meg kézzel betölteni előbb az egyik drivert, aztán a másikat:

kldload if_bwi

kldload if_bwn

Ha valamelyik után lesz wifid, akkor annak a firmware-csomagját tartsd meg (a másikat töröld le: pkg remove....), és azt töltsd be automatikusan ``sysrc kld_list+=if_bwi'' (vagy if_bwn) formában."   - Ezt is holnap tudom megejteni.

 

Ez a sor hogy: "ACPI Warning: Time parameter 255 us > 100 us violating ACPI spec, please fix the firmware. (20221020/exsystem-307)" a telepítés közben is beszemeteli a telepítő képernyőjét, nem lehet ezt valahol letiltani?

 

 

Köszönöm előre is a segítséget!

A dmesg-ben gyönyörűen látszik, hogy mi a baj a VGA-val:

valószínűleg az RC1-es telepítő miatt pontosan a drm-kmod csomagok nem passzolnak a kernelhez, ezért NEM TÖLTŐDNEK BE. (Vannak benne a szép  link_elf_obj és linker_load_file kezdetű hibasorok)

Szóval első közelítésben azt javasolnám, hogy vagy húzd újra az egészet a 14.3-RELEASE telepítővel, vagy pedig frissítsd meg (az gyorsabb lesz) a leírást lépésről lépésre követve.

Ami a wifit illeti, a doksi szerint kéne mennie, majd ha túl vagy a frissítésen, egyszer még próbáld meg, de elsőként a ``kldload bhnd' legyen meg, és csak utána az if_bwi meg az if_bwn - de még egyszer, ahhoz kellenek a bw[in]-firmware-kmod csomagok is. De szintén a frissítés miatt azokat majd rakd fel újra!

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

fLetöltöttem a FreeBSD-14.3-RELEASE-amd64-dvd1-t sha256sum-al visszaellenőríztem a telepítő pendriveról, de úgy hogy lecsatlakoztattam, majd újra felcsatoltam, hogy a cache-t invalidálja a kernel, és végre jó lett a cseksum.

Teljesen új telepítés, egy külön lemezre, amit a FreeBSD telepítővel partícionáltam és formáztam le. Egy kis 64 GB-os SSD-re.

De ha ez e rendes nem RC1-es telepítő, akkor miért nem passzolnak a csomagok a kernelhez? 

A ports-al az a baj, hogy ez egy gyenge atom procis gép, N570, és végtelen ideig forgatja a csomagot, amit 2 GB-ram se segít, ami nem lehet bővíteni. :D

Plusz a rootfs-t se látja a rendszer telepítése után, kézzel kellett megadni a loader.conf-ban a  vfs.root.mountfrom -al hogy melyik lemezen van. Ez mindegy is, mivel meg lehet adni kézzel a conf-ban. Azt még leírom, hogy a kis gépben az ssd-t nem szedtem ki, mert ahhoz kompletten szét kell borítani a gépet hozzá.

 

Rendben, először a kldload bhnd-ot próbálom meg a wifihez, aztán majd leírom mi lett.

 

Köszönöm!

$ cd /usr/src/sys ; grep -R BCMD4313 .

./dev/bhnd/bhnd_ids.h:#define    PCI_DEVID_BCM4313_D11N2G    0x4727    /* 4313 802.11n 2.4G device */
./dev/bhnd/bhnd_ids.h:#define    PCI_DEVID_BCM43131_D11N2G    0x43aa    /* 43131 802.11n 2.4GHz device */
./dev/bhnd/bhnd_ids.h:#define    BHND_CHIPID_BCM4313        0x4313        /* 4313 chip id */
./dev/bhnd/bhnd_ids.h:#define    BHND_CHIPID_BCM43131        43131        /* 43131 chip id (OTP chipid) */
./dev/bhnd/bhnd_ids.h:/* BCM4313 boards */
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM4313:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM4313:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM4313:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM43131:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM43131:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM4313:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM4313:
./dev/bhnd/cores/pmu/bhnd_pmu_subr.c:    case BHND_CHIPID_BCM43131:
./dev/bwn/if_bwn_phy_common.c:    } else if (chip_id == BHND_CHIPID_BCM43131 ||
./gnu/dev/bwn/phy_n/if_bwn_phy_n_core.c:    /* Verified with BCM43131 and BCM43217 */
 

Azaz egyértelműen támogatott a 4313-as legalább a bhnd driverben. Attól még simán lehet, hogy valahol hiányzik 1-2 sor ami miatt végül mégsem találja meg - mondjuk az if_bwn driver.

Én speciel úgy emlékeztem, hogy a FW-fájlokat - ha fent van a megfelelő bw?-firmware-kmod, akkor - maguktól behúzzák ezek a driverek és nem kell explicit megadni, de dlaszlo megjegyzése után újra elolvasva a manualt, most hajlok rá, hogy talán tényleg kézel kell betölteni. Ellenőriztem, tényleg nincs belőlük bináris csomag - azaz portsból kell föltenni, de ezeknek nincs komoly fordítanivalója (első körben letölti a bináris FW-fájlokat, majd átalakítja a megfelelő formátumra), tehát valószínűleg még az Atom-procin is menni fog. Mivel kell hozzá egy segédszoftver (ami van csomagban), azt telepítsd fel kézzel, vagy a fentebb tanult módon rakasd fel, szóval:

pkg install b43-fwcutter

cd /usr/ports/net/bwn-firmware-kmod

make all install clean

Ebből az utolsó letölt jópár FW-fájlt, után fog egy keveset fordítani, és kész a telepítés. Utána be kell őket tölteni (?) :

kldload bwn_v4_ucode

kldload bhnd

kldload if_bwn

Ha nem nyert, akkor mindet ki kell dobatni (kldunload if_bwn bhnd bwn_v4_ucode) és ugyanezt előlről, csak a bwn_v4_lp_ucode az első lépés. (Végül gőzöm nincs mi az, de van még egy bwn_v4_n_ucode is, azzal is meg kéne próbálni.) Én most betöltöttem mind a hármat egymás mellé, (már a legelső betöltötte a bhnd-t függőségként) és ebbe se döglött be, szóval akár azzal is lehet kisérletezni. Legutolsó kisérletként még meg lehet próbálni a loader.conf -ból betölteni őket boot közben - ha már a doksi azt emlegeti.

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

Feladom. Nem érdekel a wifi kártya, az X érdekel, miért nem megy.

Amőgy meg kadtam a make all install clean, és HIBAÜZENET. Feladom, ez a rendszer piszkosul nem nekem lett kitalálva. 

Azt írta, hogy  Make: Unable to locate the kernel source tree. Set SYSDIR to override. Googlebe utánananézve elvileg töröljem le az egész /usr/ports-ot és valami nvlite-vel csináljam ujra, ami eleve nincs fennt a rendszeren...

A kernel forrása le van töltve a /usr/src-be? A hibaüzenet szerintem ennyit jelent.

Ezzel a wifi chippel nincs szerencséd, de látszik, hogy működnie kell. 

Még valami olyan perverz megoldást is olvastam, hogy xp-s drivert wrappelnek, vagy konvertálnak, fent van a leírása valahol. Na szerintem az előtt állj meg, ne most. :)

Bocs, most ugyan látom (meg olvasom), hogy RELEASE kernelbeli üzenetek szerepeltek a logban, de figyelmetlen voltam éjszaka, és azt hittem, még mindig az RC1-ről van szó. Így RELEASE esetén mondjuk nem értem, hogy a drm-kmod miért nem jó verziójú, de ebben az esetben még mindig van az, hogy akkor kell belőle egyet fordítani, ami már jó lesz. Ez valóban nem gyors, de egy a tiednél 10x lassabb netbookon is végig lehet várni (az az egyik frissítő tesztgépem). Szóval a következőt kellene a VGA-hoz megcsinálni:

cd /usr/ports/graphics/drm-61-kmod

# fentiek alapján amit lehet a függőségekből bináris csomagként feltesz

make install-missing-packages

Utána pedig akkor ezt le kell fordítani és kicserélni a fent levőt ezzel:

make all deinstall reinstall clean

Így talán már nem hibaüzenetet kapsz bootkor amikor betöltődnének a drm-modulok.

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

Azt a handbook-ot valamikor a 2000-es évek elején megírták, 1-2 fejezetet a 2000-es évek közepén v. végèn updatelték, aztán ma 2025 júniusban a franc se tudja róla eldönteni, h. aktuális 1-1 konkrét fejezet tartalma, vagy 20 éve elavult dolgokról hadovál.

Ezt kéne kiadni lelkes önkéntes újoncoknak nyári melóban h. rágják magukat végig rajta az első betűtől az utolsóig, és találjanak benne őskori marhaságokat. Meg próbáljanak ki minden egyes leírt parancsot meg példát. Ami működik, azt tag-eljék meg h. 2025.06 FBSD 14.3 alatt még igaz. Ami meg nem, azt meg h. OBSOLETE SHT. Az legalább 1 jelzés lenne bárkinek aki olvassa, h. lehet már rég nem aktuális az egész iromány.

Pont ez a rész azért baromság, mert a telepítő médián kb 30 éve ott van minden rendszerkomponens (OK, a bootonly-n nincs), tehát 30 éve ugyanúgy kéne onnan utólag feltenni egy kihagyott OS-komponenst. Ehhez képest a GIT használata csecsemőkorban sincs, tehát azt a részt átírták vagy 3x, de a legprimitívebb megoldás nincs benne leírva.

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

Amúgy, lehet hogy csak mert napi szinten dolgozok vele, de nekem a git sokkal egyszerűbb megoldás. :) mint hogy telepítő médián keresgéljem, hogy is kellene utólag feltenni egy csomagot. A git-est hamarabb megtalálom. (Már csak az, hogy megtaláljak egy pendrive-ot. :))

Szerintem erre szolgálna a telepítő médián a rendszer forrásainak a feltétele, eleve már a telepítéskor.
Most nem tudom szószerint pontosan beidézni ezt az opciót. De ebben a menüpontban tudod kijelölni a ports telepítését is. Meg a debug szimbólumokat, az only 32bites dolgokat, ecetara.

Nekem gitről nem kellett semmit felraknom, ha jól rémlik.

Igen, de

- évtizedek óta nem vagyok fejlesztő, így nekem a git nem áll kézre (és szerintem ezzel elég sokan vannak így)

- az meg csak hab a tortán, hogy a git használatához kell működő net (ami nem biztos hogy van), ráadásul duplán is, mert gyárilag nincs git kliens, tehát elsőként még azt is kell valahonnan telepíteni (*) - ellenben a lent általam leírt lépések mindegyike az alaptelepítés részeként elérhető parancsokat használ - már ha megvan a média.

De hogy egyértelműsítsem: nem az a baj, hogy le van írva, hogy hogy tegyem fel utólag a rendszer forrásait CSV-vel / SVN-nel / GIT-tel, hanem az, hogy az nincs leírva, hogy a rendszer natív eszközeivel (kb, ahogy maga a telepítőprogram teszi) hogyan lehet ugyanazt megcsinálni. (Nyilván a 15-ösre ez persze megint elavul, mert ugye most már istenbizonytényleg lesz pkgbase (azaz már az alap OS is csomagokból lesz összerakva).

(*) korábbi FreeBSD-verziókhoz volt cvsup, később svnup (meg alaptelepítésben svnlite) - és ugyan most is van minimalista git kliens gitup néven - de nincs fent, mert csak egy extra ports/csomag, nem alapeszköz.

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

Nyilván a 15-ösre ez persze megint elavul, mert ugye most már istenbizonytényleg lesz pkgbase (azaz már az alap OS is csomagokból lesz összerakva

Amikor én belefutottam a kérdésbe, én is azt vártam, hogy ez egy "pkg install" kérdése csak, és azon csodálkoztam, hogy miért nem lehet ezt egy csomagkezelővel feltenni.

A doksiba lehet, hogy be kellene akkor írni majd, ha kiderül hogy kell.

Szerintem az a kézikönyv aktuális. Egyrészt tapasztalat is, sokszor örültem már neki, hogy ami oda le van írva, az tényleg úgy van. (Szerintem ez a freebsd egyik nagy előnye)

Másrészt egy könnyebb belépési szint, hogy valaki kontributáljon. Nem kell a legelvetemültebb kernel developernek lenni hozzá, a felhasználók meg szívesen segítenek, aktív a közösség. Ha valami elavultá válna, változna, azt biztosan nem hagyják úgy.

Ha kétség lenne: https://cgit.freebsd.org/doc/log/?h=main&path=documentation/content/en/…

És nem csak beleírkálnak, hanem review rendszerük van: https://reviews.freebsd.org/D47017

A kézikönyv az egy futó projekt: https://www.freebsd.org/docproj/

A telepítőmédia megvan még? Igazából a bsdconfig kellene neked, de abban speciel pont ez a menüpont nincs benne, szóval marad a telepítőmédiáról kézzel kicsomagolás. (Vagy valaki elárulja, én sajnos évtizedek óta felrakom telepítéskor a kernel meg a teljes rendszer forrását.) 

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

Én ezt az oldalt találtam a kernel forrás kicsomagolásához:

 

https://forums.freebsd.org/threads/obtaining-source-from-installation-m…

 

Itt minden szép és jó, feltettem linux alatt ntfs formátumú külső hdd-re Freebsd-s gépbe bedug és kakukk: dmesg: GEOM_PART: Integrity check failed (da1, MBR)

                                                                                                                                                                        GEOM_PART: Integrity check failed (diskid/DISK-1234567890E, MBR)

 

Fel akartam csatolni a lemezt ez alapján mentem:

https://www.reddit.com/r/freebsd/comments/f17q08/mount_external_ntfs_dr…

 

"You want "sudo kldload fusefs" - after that ntfs-3g should work."

Aztán mount -t ntfs-3g /dev/da0s1 /media/disk_dir  de nekem da1 van, így da1 És... nincsenek partíciói a lemeznek a rendszer szerint, kiindulva a fenti dmesg infóból. Amúgy két partíció is van a lemezen...

Majd délután megpróbálom sd kártyán felrakni fat fájlrendszerrel, azzal talán menni fog, legalábbis nagyon reménykedem...

De minek kavarsz bele másik OS-t és másik diszket?

Most letöltöttem a FreeBSD-14.3-RELEASE-amd64-memstick.img fájlt, és ezt csináltam root jogokkal:

# mdconfig -o ro -f FreeBSD-14.3-RELEASE-amd64-memstick.img

md0

(Fentivel az IMG-ből csináltam egy md0 nevű virtuális diszket - ami csak olvasható - azaz biztos ami biztos alapon nem akarom még véletlenül se felülírni)

# gpart show -p md0

(Megnéztem, hogy mi van rajta, voilt egy db FreeBSD tipusú partíció - md0s2 néven)

# gpart show -p md0s2

(Azon pedig egy freebsd-ufs tipusú "slice", md0s2a)

# mount -t ufs -o ro /dev/md0s2a /mnt

(Felcsatoltam, szintén RO)

És némi keresgélés után meg is lett, ahogy a fórumszámban is olvasható,   az usr/freebsd-dist nevű mappában vannak az OS-komponensek:

# ls /mnt/usr/freebsd-dist

base.txz kernel-dbg.txz kernel.txz lib32.txz MANIFEST ports.txz src.txz tests.txz

- És már csak ellenőrzésként bele kell nézni:

# tar tvzf /mnt/usr/freebsd-dist/src.txz

Majd kicsomagolni a megfelelőt a / (azaz a root alá)

# tar xvzf /mnt/usr/freebsd-dist/src.txz -C /

És mint látható, nincs külön kernel forrás, de fenti kupacból amúgy az usr/src/sys alatti rész az érdekes.

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

Nekem van egy ilyen a /etc/freebsd-update.conf-ban:

# Components of the base system which should be kept updated.
Components src world kernel

Ez neked hogy van benne? Azért érdekes, mert úgy emlékszem, hogy git-tel checkoutoltam ki, de most frissítés után ott van a /usr/src, benne van, aminek kell, de nem git repo.

Tehát nem lehet hogy a freebsd-update fetch és freebsd-update install leszedi, ha ez így van a conf fájlban?

A kicheckout-álsa:

pkg install git-lite
git clone https://git.freebsd.org/src.git /usr/src
cd /usr/src
git checkout releng/14.3

Elvileg.

A kézikönyvben: https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-o…

# mv /usr/src /usr/src.bak
# git clone --branch releng/14.3 https://git.FreeBSD.org/src.git /usr/src

Ez a cikk most jött szembe: https://freebsdfoundation.org/blog/the-road-to-better-wi-fi-on-freebsd/

Improving Wi-Fi support is a community effort—and there are plenty of ways to get involved. If you’re using FreeBSD on a laptop, sharing your hardware details, reporting issues, or simply testing new drivers can make a real difference.

( jimmy399 v | 2025. 06. 16., h – 20:04 )

Csak nem bírtam ki holnapig :D

 

Itt a PCIconf kimenete:

https://pastebin.com/Npu8Kv6h

 

fwget parancs kimenete:

No package found for device 0xa011
No package found for device 0xa012
No firmware packages to install.
 

Az a011 és a012 a VGA-hoz köthető, ezekhez nincs driver szerinte.

 

kldload if_bwi

kldload if_bwn

erre a két parancsra se történik semmi, nem jelenik meg a beépített wifi a sysctl -n net.wlan.devices csak az usb-s realtek wifi. Azzal írok most is.

Okés, megtaláltam (már nincs használatban ez a laptop, de most feltöltöm, felfrissítem, és használni fogom. :) ).

@jimmy399:

Ez van a /boot/loader.conf-ban:

if_bwn_load="YES"
bwn_v4_lp_ucode="YES"

Az utóbbit a /usr/ports/net/bwn-firmware-kmod könyvtárban találtam meg, itt nem root felhasználóval: make, és root felhasználóvan make install-al lehet telepíteni.

Az if_bwn pedig /usr/src/sys/modules/bwn-ben van (szerintem ez az). A fordítás szerintem ugyanaz, mint a bwn_firmware-kmod esetén. (de ez nem biztos, hogy kell, mert már van elvileg)

Még annyi rémlik, hogy a kézikönyvből néztem, hogy tegyem fel a ports-ot. (ethernet kábelt dugva a gépbe, mert wifi nem volt)

Rákeresve most a bwn_v4_lp_code-ra ezt találtam: https://forums.freebsd.org/threads/bcm4312-issue-connecting-wirelessly… Ebben hivatkozik a man bwn-re, amiben ez van:

https://man.freebsd.org/cgi/man.cgi?query=bwn&sektion=4&manpath=freebsd…

This  driver  requires  firmware	to be loaded before it will work.  The
       ports/net/bwn-firmware-kmod  port  needs	  to   be   installed	before
       ifconfig(8)  will  work.	  In most cases	the bwn_v4_ucode kernel	module
       from the	port should be used.  However, if an LP	(low power) PHY	is be-
       ing used, the bwn_v4_lp_ucode module should be used.

(Tehát lehet, hogy ez kell majd: bwn_v4_ucode  nem az lp-s.)

---

Én arra emlékszem, hogy a telepítő alapból megtalálta, hogy az if_bwn-t kell használnia, de sehogy nem csattant fel a wifire. - És utána találtam ezeket, így megjavult.

( hunludvig v | 2025. 06. 18., sze – 08:38 )

De szépet ment ez a topic. :)