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?

  • 2125 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?

( 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.

( 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.”