OpenBSD 7.0 BETA

OpenBSD

Theo de Raadt projektfőnök egyik újabb commit-je nyomán az OpenBSD -current ága elérkezett a 7.0-beta mérföldkőhöz:

VSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2021/08/17 09:03:56

Modified files:
	sys/conf       : newvers.sh 
	etc/root       : root.mail 
	share/mk       : sys.mk 
	sys/arch/macppc/stand/tbxidata: bsd.tbxi 
	usr.bin/signify: signify.1 

Log message:
7.0-beta

A végleges kiadás októberben érkezhet.

( Raynes | 2021. 08. 24., k – 16:59 )

Azt tudta valaki, hogy hogyan lehet ez a 7.0-ás current ágat telepíteni? Mert az utolsó telepítő, amit le is töltöttem, az a 6.9-es stable, de én szeretném a current ágat használni. Most van egy kis időm, tervezem feltenni egy harmadlagos, kísérletezős, régi Thinkpadre. Sose használtam még BSD-t, de most kedvet kaptam hozzá néhány videó alapján, tetszik a minimalizmusa, meg hogy nem mentek el bullshit, bloat, polkorrektkedés irányában, nincs CoC-uk, meg egyéb baromságot, állítólag a Intel és AMD GPU-k támogatottak rajta, így adok neki egy esélyt. Természetesen nem virtuális gépre teszem fel, meg nem szerverre kell, hanem desktopra, élesben, úgy ismeri meg igazán az ember a rendszert.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Kezdetnek. Nem használtam OpenBSD-t, az előbbi szerint telepíted az utolsó stable kiadást, aztán a sysupgrade -s visz a -current ágra, az utolsó snapshot-ra frissít. De, majd valaki obsd expert kijavít.

Amúgy én bsd vonalon nem mennék az os -current ágára, maradnék az utolsó stabilon (sec és bugfixeket az is kap, elvileg betonstabil), csak a csomagokkal mennék -current-re, abból jöhetnek a legfrissebbek, amik elérhetőek. De majd egy expert bsd-s ezt is rendbe teszi :)

Nem vagyok OpenBSD expert, de a sysupgrade -s alapból a latest snapshotra visz. Miután a rendszer rebootolt, még kell egy sysmerge, hogy a konfigokat rendberakja, majd utána egy pkg_add -u a csomagok frissítéséhez.

Legalábbis a release-to-release upgrade így zajlik (kivéve, hogy -r kapcsoló kell), itt a 6.8 to 6.9 útmutatója, ez alapján én éppen most frissítettem fel a 6.8-asomat 6.9-re. Probléma nem volt.

Oldschool Computer - http://oscomp.hu

Így tettem, before 6.9 GENERIC.MP#4, kicsit lassan töltötte le a sysupgrade, majd rebootolt és kb 5 perc alatt felrakta, after 7.0 GENERIC.MP#195, sysmerge 2 fájl q i (alap install + firefox, pkg_info | wc -l 44), Firefox 88-ból lett 91, pkg_add -u jó sokáig futott szintén (cdn az installurl, lehet közelebbi kellett volna).

# syspatch -c
syspatch: Unsupported release: 7.0-beta

nincs aláírásom

Amúgy én bsd vonalon nem mennék az os -current ágára

 

Hát nekem pl. FreeBSD-n nem sikerült megugrani, hogy az OS meg a service-ek egymástól függetlenül menjenek, de lehet, hogy csak én voltam béna (pl. az apache az OS -es openssl-t használja és az tavaly ősszel nagyon sokáig nem frissült, ports-ból forgatott postfix-et törte egy OS upgrade ami egy so file-ból hozott egy új verziót, stb.). Néha kicsit sajtreszelő az egész.

Fent van. Eddig nem tudom, hogy tetszik-e. Ami jó benne, hogy tényleg minimalista, x86_64-es telepítés után Wi-Fi driverestől, mindenestől tty-ban 29 mega memóriafogyasztást mutat, X11 + fvwm-mel 87 mega. Igaz x86_64-es Gentoo-val már voltam dwm-mel 96 megánál, és ott feh is volt háttérképpel, systemd azon se volt. Az Intel Wi-Fi firmware-t kézzel kellett a rendszere másolni, mivel az OpenBSD jogi okból nem terjesztheti. Amúgy ment minden elsőre, Intel Wi-Fi, Intel GPU gyorsítás, touchpad működik (bár utóbbi néha lebénul, gondolom palm rejection miatt, ami még nincs beállítva).

Ami nem tetszik benne: lassú. Mind a kernel, mind a boot (az init szekvenciálisan tölt be mindent, így ha egy service is várakozik, akkor a többi addig tölteni se kezd el), mind a fájlrendszer. Ezek köré a Linux köröket fut sebességben, minden téren, ugyanazon a hardveren (i5-2520M, 16 GB RAM, SATA3 SSD). A másik, ami nem tetszik, az a minimalizmus egy túlzó foka, ami a produktivitást öli meg. Se framebuffer konzol, se színek, se rendes konzolfont nem tölthető be, FAQ és man-jaik sokkal gyengébbek pl. a linuxos man-okhoz, meg Arch/Gentoo Wiki-jeihez képest. A ksh shell tudása is nagyon minimális, még egy alap Bash-sel összehasonlítva is. Egy csomó jó, hasznos linuxos és bashos megoldásnak nincs is párja, pl. lsblk, free, bash read -sn, stb.. Nagyon lyukkártya és abakusz érzése van tőle az embernek.

Az is igaz, hogy sok mindent nem lőttem be, kshrc, saját xinit, normális konzolbeállítások nincsenek kikísérletezve, lehet belakva azért kényelmesebb lesz ez, mint amilyennek out of the box tűnik. Legalábbis remélem. Egyelőre még csak elég fapados a rendszer, a bspwm-et is nehéz volt belőni sxhkd-vel, st-vel, feh-vel, polybar-ral, nehéz volt rávenni a xenodm-et, hogy ezt indítsa, végül a ~/.xsession-be kellett beleszerkeszteni, máshogy nem ette meg. Közvetlenül nem lehet normál felhasználóval xinit-et indítani, pedig az még jobb lenne. Fontok, hang sincs még beállítva.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Na igen, ez kb az összes BSD-n így van, teljesen zéró config-ot kapsz, mindent te raksz össze magadnak, nem seggkinyalós Linux. Én szeretem, mert a config összerakásával tanulsz is. Elérhető infók pedig igen kevesebb, FreeBSD-n több elérhető, OpenBSD kevesebb, NetBSD még kevesebb. Alapoznod kell a szürkeállományra erősen, ami nekem szintén bejövős :P

Ha összeraksz egy BSD-t az igényeidnek megfelelően, na az már valami, nem az Arch wiki-ről bemásolgatós szint. 

Mi köze a boot lassúságának az operációs rendszerekhez? Te itt a systemd párhuzamosított boot-ját mérted össze a BSDInit (vagy minek hívják) egyszálú boot-jával, márpedig nem csak ez a felállás létezik; tedd vissza a SysVInitet Linux alá és tegyél fel egy párhuzamos boot-ot lehetővé tevő initet OpenBSD alá (pl. nosh), aztán máris fordul a kocka. A fájlrendszer sebessége sem biztos, hogy az OS sara; ugyanazon gépen és ugyanazon - és ugyanolyan FS-re formázott - partíción mérted Linux és OpenBSD alatt is? A kernel lassúsága alatt mit értesz, konkretizálnád?
Van framebuffer konzol OpenBSD alatt, úgy cca. 2015 óta. Mit értesz a man-ok gyengesége alatt, konkretizálnád? A shelleknek sincs túl sok köze az operációs rendszerekhez; használhatsz ksh-t Linux alatt és használhatsz bash-t OpenBSD alatt (FYI: az OpenBSD-ben alapból van bash), akár default-tá is teheted őket.

BTW, milyen vasra raktad fel az OpenBSD-t?

Oldschool Computer - http://oscomp.hu

A boot is az OS része. A fájlrendszer sebessége nyilván különböző fájlrendszerekre értendő, Linux alatt ext4, de ezt az OpenBSD natívan, kernel szinten nem támogatja, csak userland fuse modul szintjén, de akkor meg a fuse overhead miatt nem lesz fair összehasonlítás. Kernel lassúságán azt értem, hogy a progik is lassan töltődnek be. Bár az kicsit segített, hogy az rc-ben beállítottam pár dolgot, pl. hw.smt=1 sorral engedélyeztem az Hyper Threading-t, így az összes prociszálat használja, meg kikapcsoltam az aslr-t, hogy ne random linkelgesse újra a kernelt, így érezhetően gyorsabb, de Linux mellett még mindig komótos. Azzal is tisztában vagyok, hogy egy biztonságilag ellenjavalt, mert fontos security feature-ök, de míg kísérletezgetek a rendszerrel, addig legyen legalább kicsit kevésbé csigatempójú.

A framebuffer konzolban valóban tévedtem, mert wsconsctl segítségével lekérdezve drm-et használ a konzol, de működő színeket, meg egyedi betűtípust így se tudok csiholni. A színek ugyan belőhetők, a TERM változó bizonyos értékre állításával (rcons-color, ansi, wsvt25, stb.), de akkor meg sok funkcióbillentyű nem működik. Terminus bináris pcf konzolfontot se veszi be, látszólag rendben lefut a wsfont vagy mi a parancs neve, nincs hibaüzenet, de a font nem aktiválódik.

Azt tudom, hogy használhatnék OpenBSD alatt is Bash-t (vagy akár zsh-t is), de akkor olyan lennék, mint a Windows Matyik, akik Linuxra áttérve is wine-ben erőltetik a windowsos megoldásaikat. Próbálom a rendszert BSD módjára használni, BSD-ként megszokni, ha elkezdem linuxosítani, meg bloatosítani, akkor az egész értelme veszik oda, azt csinálhatnám Linuxon is.

A Firefox mentési problémáját kinyomoztam, az állítólag az unveil miatt van, hogy csak a ~/Downloads mappába tud írni, de nekem oda se akar menteni. Grafikus felületről is nagyon nehezen műtöttem le a Log Console-t. Az is igaz, hogy sok problémám még az okozza, hogy BSD noob vagyok, és nem ismerem a rendszert, így eleinte az ember csak saját kútfőből gányol. Sok minden nincs még beállítva, ssd trim, hang, X font antialiasing/hinting, csomó csomag nincs fent, stb., sok munka lesz még vele. A ksh is belőhető kicsit jobbra, bár a Bash meg a zsh szintjét nem fogja akkor se elérni.

Ami még nagyon furcsa, ez a partícióktól független disklabel felosztás. Az elég poén, hogy sok év után újra van c: meghatóm, erre még Ballmer is kiosztana egy nagy vállveregetést :D Elég zavaró is egyben, mert azonos szinten mutatja a partíciókat és disklabeleket is (pl. a BSD rendszerpartíció egyben c: és egyben a: disklabelt is kapja, az egyik maga a partíció, a másik a / csatolási pont, ami a partíción belül van), ráadásul a default séma, amit telepítéskor felajánl, az nagyon ócska, hogy a partíció túl van szabdalva 1-2 gigás labelekre, én azokat egyesítettem, hogy a / legyen az egész partíció, és azon legyen minden, /var, /usr, /home, /stb., a /swap-ot megszüntettem, nem kell, 16 GB RAM-ja a gépnek overkill egy ilyen rendszernek. Ha majd belejövök, akkor a /home másik partíción lesz, de most még nem láttam szükségét. Szóval vannak benne furcsa dolgok bőven, amik vagy zavaróak, vagy félrevezetőek.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Itt nem az OS függvénye volt a bootsebesség, hanem a cserélhető inité. Te összemérted a systemd bootsebességét a BSDInittel, ahogy mondtam (már amennyiben ugyanarra a gépre raktad fel mindkettőt, különben még a gépek közti teljesítménykülönbség is belezavar) és ahogy kiderült a fájlrendszerek sebessége sem az OS függvénye volt.
Viszont nem válaszoltál arra a kérdésre, hogy milyen vasra raktad fel az OpenBSD-t. Ugyanazon a vason lassabb a programok betöltése OpenBSD alatt, mint Linux alatt? Összehasonlítani mindig azonos környezetben kell, különben nem ér semmit az egész.

Betűtípust betölteni a wsfontload-dal tudsz.

Miért is volna windózmatyizás-szerű, ha bash-t, vagy zsh-t használnál OpenBSD alatt, ha szabad tudnom? Mitől lenne ez linuxosítás? Mi köze van a bash-nak vagy a zsh-nak a Linuxhoz? A bash 1989-es, a zsh 1990-es, a Linux meg 1991-es. A BSD-ken már akkor volt bash és zsh, amikor a Linux még nem is létezett. Akkor mitől is volna linuxos privilégium a bash/zsh használata, mitől is lenne linuxosítás, ha OpenBSD alatt bash-t/zsh-t használnál? Ennyi erővel Linuxon bármilyen nem Linux alatt született shell használata BSD-sítés, Solarisosítás, AIX-esítés, urambocsá, POSIX-compliant shell esetén UNIX-osítás.

A Firefox egy az OpenBSD-től teljesen független projekt. Szerinted, ha szarul portolják OpenBSD-re, akkor az az OpenBSD-nek, mint rendszernek a hibája?

Hogy a disklabelek szokatlanok, azt megértem és aláírom, de a windowsos partíció betűjelekhez semmi köze nincsen. Nem, nincs c: meghajtód, mert a C disklabel az nem egy partíció, hanem több, konvencionálisan a root és swap partíciókon kívüli összes többi.
A swapot meg nem célszerű megszüntetni akkor sem, ha "sok" RAM van a gépben (BTW, FYI: a mai JS-sel torkigbaszott webkettős világban a 16 GB nem számít soknak), mert nem a rendszer falja fel a RAM-ot, hanem az alkalmazások. Olyan Linux alatt se nagyon van, hogy bebootolsz egy Linuxot és a konzol cseszegetésén kívül nem csinálsz vele semmit és mégis elszublimálna 16 GB RAM. A browser viszont fel fogja falni.
Ettől függetlenül a "furcsa", "zavaró", meg "félrevezető" kitételek szubjektívek; ez megszokás kérdése.

Oldschool Computer - http://oscomp.hu

Ez igaz, hogy az initet le lehetne cserélni. De a BSD-knek az az előnye, hogy a toolokat is a core team fejleszti, egységes egészet képez a rendszer, kernelestől, initestől, stb., így out of the box tapasztalatról írok, így nekem feltűnő volt a lassúság. Nem meglepetés, mert előre tudtam. A párhuzamos deamon-indítást már komolyabban kéne venni sysvinit vonalon is, mert egyrészt nem nagy szám megvalósítani, ha nem bonyolítják túl, mondjuk elég alap, vagy kézi függőségkezelés, és a felhasználói élményhez sokat ad hozzá.

A Bash-ban igazad van, a Linuxot megelező projekt, ami attól független, és mindig is elérhető volt a zsh-val együtt BSD-kre, még a MacOS is használta, de annyira összeforrt a GNU/Linux ökoszisztémával, hogy ma már szinte szinonim fogalmak. Az az érzésem, ha a Bash-t erőltetem, akkor azzal a Linuxot nem tudnám elengedni, a BSD-t meg pont azért fedezném fel magamnak, mert de.

A wsfontload-ot írtam, csak a neve nem jutott eszembe. Meg is eszi a fontot, nem ír rá hibát, de nem lépteti érvénybe, hatástalan marad. A neten azt írják, hogy csak VGA konzolon működik, drm-en nem, nem tudom mi ebben az igazság. Swap az meg nem kell, kösz szépen. A neten mindenkit ezzel ijesztgetnek, hogy kell a swap, megkeserüli, a pokol tüzén fog elégni, aki nem használja. Közben meg Linuxon sincs swapom (hibernálni se akarok természetesen) már vagy 4-5 éve, és egyszer se fogytam ki a memóriából, általában nagyrészt kihasználatlanul áll, főleg amiatt mert egyébként is terminálos, TUI, CLI progikat használok, meg kerülöm a bloatware-eket, soydev szoftvereket, amennyire csak lehet. OpenBSD alatt még ennél is minimalistább leszek, mert azon még Wine, Steam, systemd, játékok, stb. se fog futni, amit Linuxon meg használok, így még fele annyira se lesz kihasználva ez a 16 giga RAM se. Jelenleg a max. amit elértem most OpenBSD-n, Firefox jó pár füllel, 4 st/xterm terminál, 3 konzolos munkamenet, valami 3,8 giga RAM fogyasztás, erre jött még rá, kb. 1,5 giga cache (amit a rendszer eldob, ha kell a memória, fogytán lenne), az Intel IGP lefoglal 0,5 gigát, de a 16 GB RAM-ból marad még így is 10 giga kihasználatlanul, ha belakom, és mondjuk lesz kétszeres memóriahasználat, akkor is marad vagy 5 giga szabadon. Másik laptopon Arch bspwwm-mel, jelenleg ezen sorok írása közben 3 Alacritty terminál, Firefox 42 fülből 6 aktív füllel, foglal 1,1 giga RAM-ot, és 1,1 giga cache-t a 16-ból.

Hidd el, az a swap egy olyan mítosz, mint hogy Linuxon GRUB nélkül nem lehet bootolni, meg hogy networkmanager vagy netctl nélkül nem lehet netezni, ezek sem igazak. Ráadásul tegyük fel, hogy később mégis kell majd 100 év múlva egyszer valamihez swap, és szembesülök vele, hogy nincs. Semmilyen gondot nem okoz, csinálok swapfájlt, és felcsatolom swapként, azaz truncate -s 16G swapfile && mkswap swapfile && sudo swapon swapfile, és ennyi, SSD-n megvan néhány másodperc alatt, gondolom BSD-n lehet nem működik a truncate, hanem dd if=/dev/zero kell helyette és mkswap, swapon helyett máshogy hívják az utasítást. Túl van ez a swap-téma gondolva, meg vallási dogmákkal spiritualizálva. Ez egyébként még a régi időkből ered, amikor a gépekben még irtó kevés memória volt, meg lassú HDD-ken tartották a swapot, és trükközni kellett, hogy jajj, partíció legyen, ne fájl, mert akkor nem töredezik, meg a HDD tányér külső szélére tegyük, hogy gyorsabb legyen, stb..

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

A párhuzamos deamon-indítást már komolyabban kéne venni sysvinit vonalon is, mert egyrészt nem nagy szám megvalósítani, ha nem bonyolítják túl, mondjuk elég alap, vagy kézi függőségkezelés, és a felhasználói élményhez sokat ad hozzá.

Régebben én is így gondoltam, de szerintem azon a 20 másodpercen nem múlik (nálam a FreeBSD bootja a grafikus felület megjelenéséig). Az "ellenzői" szerint a párhuzamosításban sok potenciális problémaforrás van. Megjegyezném, hogy FreeBSD-ben az initszkripteknél van függőség és annak kezelése.

Az egy dolog, hogy a core team fejleszti az egészet, de ennyi erővel a Linuxnak meg még initje sincsen; akkor mivel hasonlítottad össze és milyen alapon? A lényeg, hogy te az initeket hasonlítottad össze a bootidőnél, nem a rendszereket. A SysVInit és a BSDInit egyébként nem ugyanaz az initrendszer (System V vs. BSD).

Nem, a bash és a Linux közel sem szinonim fogalmak, maximum neked. Csak mondom, hogy a 10.15-ig (Catalina) a macOS-ben is a bash volt a default shell és a macOS desktop részesedése 8-10x-ese a Linuxokénak, azaz ennyi erővel a bash a macOS-sel lenne szinonim, már, ha egy operációs rendszer és egy shell szinonim fogalmak lehetnének.

Kicsit bővebben is leírhatnád, hogy mit is csináltál, miket írtál be, mert az, hogy "nem működik", az nem bugreport...
Én nem ijesztgettelek semmivel sem, csak leszögeztem egy tényt: a webkettes browserek felzabálnak sok GB RAM-ot. Tehát hiába nem használsz sem Linux, sem OpenBSD alatt bloatware szoftvereket, mert egyet mindenképpen fogsz: a browsert. Hogy most épp nem eszik sokat, az lehet, hogy azért van, mert nem látogattál meg olyan bloated oldalt.
Hinni meg nem szokásom; nekem is 16 GB RAM van a gépemben és nekem sem szokott elfogyni, de volt már rá példa, amikor elfogyott (pl. sok GB-os lemezkép csesztetése, sok virtuális gép egyszerre, valami überbloated webkettes alkalmazás) és akkor bizony jól jött a swap.

Oldschool Computer - http://oscomp.hu

Amikor írom, hogy a Linux initje, azon a szokásos systemd-t értem. Amit nem szeretek, de azt el kell ismerni, hogy a bootolást eléggé meggyorsítja, kevés jó oldala közül ez az egyik. Nyilván azt nem is várom, hogy egy BSD olyan gyors legyen, de mondjuk egy Gentoo OpenRC-t azért közelítsen meg, ebbe érdemes lenne munkát fektetniük. Tisztában vagyok vele, hogy egy csomó security dolgot is csinál bootkor, szemben a Linuxszal, de pl. ezekből is kapcsoltam ki, ez segített is, de még mindig nem egy villám.

Akármit írsz, nekem a Bash mindig is Linux-ökoszisztémás lesz, mert emiatt terjedt el, hiszen mindenki innen ismeri. Írtam is, hogy MacOS-ben is volt, de hiába a nagyobb részesedés, azokat sose vette senki komolyan, úgyis GUI-s normik használják főként, mindig is így volt, ők meg nem sokat shelleznek. Ez csak a legutóbbi divat, az utóbbi néhány évben, hogy szabad tarisznyás hipszterek elkezdték komolyabban MacOS alatt nyomni, vim, Emacs, python, stb.-kel, most, tegnap este egy Rob Pike előadásos videón is azt láttam, hogy már az az ürge is Mac-kel nyomja, Plan9 wtf. Egyébként pedig szeretem a Bash-t, nem ekézni akarom, mert talán a legjobb shell, könnyebb benne scriptelni, meg interaktív shellként is jobb, tud egy csomó mindent, de cserébe meg messze nem olyan bloat, mint egy zsh. Egyelőre mégis a ksh-t szeretném belakni, kiderült, hogy tud vi módot is, de hiába lövök be mindent a ~/.kshrc-ben nem eszi meg a beállításokat, pedig kézileg kiadva működne. Majd beteszem a profiles-ba is, hátha segít. Konzolban annyit kiderítettem, hogy a wsfontload megeszi a fontot, mert -l kapcsolóval kilistázza, hogy fel van véve a betöltött fontok listára, és valami olyat möhög, hogy ez a wsdisplay-on múlik, de ott meg nem találtam meg a vonatkozó beállítást, amivel a fontot életbe lehetne léptetni.

Hogy írjak pozitívumot is: lapból ment a hang, nem kellett vele semmit csinálni, teljesen meglepett. Ráadásul ez az sndio (ami a jól tudom, régen volt Linuxra is) egy elég egyszerű valami, ALSA-nál is sokkal egyszerűbb, mixerctl-ben könnyű konfigurálni. Azért szépséghibája is van, mert mikor YouTube lejátszás alatt konzolból visszaváltottam a grafikus felületre, akkor reccsent, de ilyet ritkán művelek. A másik, ami tetszik, az a Ports egyszerűsége, bár ez egy kicsit ellene is szól, mert pl. az Openports-on azt írták, hogy a sysutils kategóriában benne van a vifm, az OpenBSD FAQ alapján leszedve a rendszerhez való 6.9-es Ports-ot, abban meg nincs benne. Amitől lementem hídba, Ports-ban sqlite3 lekérdezéssel kell keresni, erről nem tudom eldönteni, hogy most zseniális vagy elmebeteg, mindenesetre inkább felvettem egy alias-t, amivel a /usr/ports/-ban a find parancs kilistáz minden fájlt és mappát, ezt bepipe-olja fzf-be, és azzal keresek, ami sokkal egyszerűbb, sokkal gyorsabb, mint sqlite-ban SELECT blabla FROM möhöhő WHERE akármi kezdetű kisregényeket gépelni, amiben ráadásul a Tab-os kiegészítés se nagyon működik.

Egyelőre alakulgat a rendszer, óráról-órára egyre használathatóbb, de elég kicsi lépésekben haladok, pl. messze nem tűnik olyan nehéznek és reménytelennek, mint egy Gentoo. Swap továbbra se lesz, annak ellenére, hogy most a Firefox tegnap este produkált egy 5 gigás memory leaket, de még így se volt gáz, volt szabadon bőven memória. Ha majd kelleni fog, bekapcsolom, de nagyon meglepne, ha valaha szükség lenne rá. Eddig nem tűnik rossz rendszernek, de nem jobb, mint a Linux. Hiába minimalistább, amikor már komplett de minimalista desktopként fut, akkor mem fogyasztásban utoléri, sebességben elmarad, így nem lesz az ember előrébb. Aki már használt, tud telepíteni Arch, Void, Alpine, Gentoo minimalista rendszereket, minimalista WM-ekkel, szereti a suckless-es dolgokat, az azért eljátszhat vele, de nem lesz előrébb. Ilyen Xfce/Gnome/KDE, VSCode, Discord, egyéb Electron, Wine, Steam, OBS full desktop, raztáblás-bluetoothos, valamint Mac/Windows mindsetű normiknak viszont nagyon nem ajánlom, nekik nagyon keserű tapasztalat lenne, ők mindenképp maradjanak a Linuxnál, megspórolom nekik a köröket. Részemről még elreszelgetem, hajt a kíváncsiság, hogy mennyire tudom belőni, meg hosszú távon mennyire életképes a rendszer. Ha tetszik, lehet felteszem a fő notimra is, a 2. SSD-t be tudom áldozni, azon most egy úgyis haszontalan, régi Artix Linux Openbox rendszer pihen.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Van, akiknek a systemd sosem lesz "szokásos". Igen, a bootot meggyorsítja, azon initekhez képest, amik nem tudják a szolgáltatásokat párhuzamosan fellövöldözni, de vannak más párhuzamos indítást támogató initrendszerek is.
Hogy az OpenRC mennyire gyorsan kel fel, vagy sem, azt nem tudom, de újfent felteszem a kérdést: milyen vason használtad az OpenBSD-t? Ugyanazon, mint a Linuxot? Mert ezt már sokadjára kérdem, de egyszer sem válaszoltál.

Hogy neked mi micsoda, az egy dolog, de az a te perspektívád, nem a világé. Vö. "azokat sose vette senki komolyan"; hát nem, max. te nem vetted komolyan, de az legyen a te bajod. És nem, nem csak GUI-s normik használták, lévén a világ ~10%-a használja, ami - lássuk be - mély merítés, akárki előfordulhat benne és ez nem csak "a legutóbbi divat, az utóbbi néhány évben"; az Apple desktop részesedése mindig is nagyobb volt, mind a Linuxé.
Hogy melyik shell a legjobb, annak eldöntését meghagyom az egyes shellek rajongóinak, mert nekem fingom sincs; én még mindig POSIX-compliant shell kódot írok, az megy mindegyikben...

Nem, nem feltétlen kell SQLite a Ports-ban való keresgetéshez; olvasd el a manualt. Be is baszna, ha kéne, hiszen nem mindenki beszél SQL-ül.

Szóval pontosan az történt, amit jósoltam: a browser felfalt több GB-ot, mert csak, de csakazért se lesz swap, mert csak? Mert még így is volt elég RAM? És ha legközelebb nem lesz? Amikor már kelleni fog, akkor már hiába akarod bekapcsolni, gátat sem árvíz után építünk.
Ez a jobb, vagy nem jobb, mint a Linux, ez egy teljesen értelmetlen összehasonlítgatás; mire jobb? A fogyasztást és a sebességet megint csak nem sikerült konkretizálni, hogy ez mit is takar, meg azt sem, hogy ugyanazon a vason mértél-e, mint Linux alatt.
A végére - mert nem tudtam megállni - a "Mac/Windows mindsetű normik" miért maradjanak(?) a Linuxnál, nekik nem inkább a Mac-nél, meg windowsnál kéne maradniuk?

Oldschool Computer - http://oscomp.hu

Az OpenRC tud párhuzamosítást initkor, csak default nincs bekapcsolva. Engedélyezni kell egy sort a vonatkozó config fájlban, reboot, és akkor nem sokkal marad el a systemd initsebességétől. Kicsivel, de nem olyan lényegesen.

A manualt elolvastam, természetesen ne csak sqlite-tal lehet keresni, ilyen make search akármi= útvesztőkkel is, ami legalább olyan körülményes. find | fzf megoldástól hatékonyabb nincs, elég csak 1-2 karaktert megadni, még a szokásos regexp-nél is lazábban, és megtalálja, amit keresel.

Swap meg ilyen. Most se kellett, ezután se kell, ha majd valami postapokaliptikus esemény folytán kell, akkor a belövöm egy sorból. Mondom, ez túl van gondolva, úgy érzem, hogy több embernél már ilyen vallási kérdés meg hisztéria. Az 5 gigás memóriafogyasztás inkább csak úgy sokalltam, hogy ennyi tab-bal az Arch szintén bspwm-mel 2 giga alatt marad. Természetesen ugyanazzal a programokkal, ugyanazon a gépen, ezt magyaráznom sem kell.

Szegény normikat bántani nem akartam, de nekik nem való ez. Mert a bloat megoldásaik nem mennének. Azt kell érteni, hogy a „desktop” nem mindenkinek jelenti ugyanazt. Szerintem 90%-ban itt a HUP-on azokat a SwayWM, dwm, bspwm, no-logindm, no GRUB megoldásokat, scriptekkel, CLI/TUI programokkal, terminál + fzf + vim keyboard driven workflow-val teljesen használhatatlannak találnátok az itt megszokott Gnome, KDE, Xfce, Mac, stb. rendszerek után. Ezt az OpenBSD-set meg kb. 98%-ban, és még mielőtt kérdezed, ezek nem pontos értékek a KSH-tól, meg nem a ksh-ból, hanem ilyen hasra ütéses nagyságrendek, amiket én tippelek. Mert desktopon sem egyforma az emberek workflow-ja, már eleve a Windows is eltér a Mac/Gnome vonaltól, ami eltér egy MenuMakertől, ami nem is hasonlít egy tiling WM-es desktopra. Itt szoktak tévedni a nemjöttelaLinuxdesktopéve emberkék is, hogy őnekik a Windows/Mac=Linuxdesktopéve nem jött el, ami nem ugyanaz, azaz óriási csúsztatásról van szó. Amit persze eddig is tudni lehetett, mert sokunknak a Linux desktop éve eljött már ilyen 7-15 éve simán.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Éééés negyedjére sem sikerült leírni, hogy milyen vasra raktad fel az OpenBSD-t...

Ennyi erővel minek a find | fzf combo, amikor ott az ls | grep?

Neked az vallás, ha valaki tapasztalatból mondja, hogy swap nélkül kurwa nagyot lehet szívni? Épp most futottál bele abba, amire jó előre figyelmeztettelek és mégsem akarod a swap partíciót, mert csak; ki nem viselkedik itt racionálisan?

Az lehet, hogy a "normiknak" nem való az OpenBSD, de nekik a Linux se. Ami felületet és alkalmazásparkot fel tudsz rakni a Linuxra, annak az elsöprő többségét a BSD-kre is fel tudod rakni, lévén amikre ezek épülnek, azok crossplatform cuccok, úgyhogy, ha egyik nem jó nekik, akkor a másik se.

Oldschool Computer - http://oscomp.hu

Az ls | grep is jó, de a grep nem eszik meg annyira laza mintát, vagyis csak komolyabban megfogalmazott regexp esetén. Pl. fzf megtalálja úgy is a keresett kifejezést, hogy nem egymás melletti karaktereket gépelsz be belőle, ezt a hagyományos regexp megoldás nem tudja, hacsak át nem fogalmazod körülményesen. Na, fzf ezért gyors, nem kell regexpet sem befogalmazni, benyomsz néhány billentyűt és azonnal megtalál mindent, ha nem is csak 1 találat, akkor listázza a hasonlóakat is, anélkül, hogy km-es és tekervényes, tele spéci karakteres regexpet kéne szülni hozzá. A másik előnye az fzf-nek, hogy mikor viszed be a karaktereket, mindegyik után már menet közben látod, hogy hogyan alakul a találati lista, lehet 1-2 karakter után már nem is kell semmit gépelni, mert az utolsó 1-2 sorban már ott a találat. Nem véletlen van ott az OpenBSD tárolóiban az fzf, az egyik leghasznosabb tool ever. Ha nem ismered, nagyon melegen ajánlom, akár Mac-re, akár Linuxra.

Most belefutottam egy másik rossz pontjába az OpenBSD-nek. Nem támogat SSD-n TRIM-et. Ez azért elég gáz, azt javasolják, hogy ha FFS2/UFS2-őt használ az ember, hogy azt a FreeBSD kezeli, és tudja TRIM-elni. Esetleg használ az ember NVMe SSD-t, ott a TRIM-nek megfelelő utasítás a drive működésébe fizikai szinten van beépítve, anélkül, hogy az OS-nek szoftveresen kéne külön hívogatni. TRIM-nél még azt se tudom mondani, hogy de izé, nem desktopnak való, mert szerveren is kell szerintem. Ezt tényleg megoldhatták volna, nem nagy szám implementálni. Állítólag valamilyen szinten próbálkoztak vele, de teljesítményproblémákat okozott, meg titkosításnál adatmintázati támadhatóságot okoz, ezért hagyták.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Hát, ha valakit, engem nem lehet regex-overuse-zal vádolni, de ha az a baj, hogy nem egymás melletti karaktereket akarsz beütni, ott a karakterek közti regex az annyi, hogy: .*
Azért az csak nem olyan bonyolult. Aztán meg ha csak a fájlnevekben keresel, azt a find már alapból tudja.
De ez már off, tök mindegy mivel keresel; nem kötelező az SQLite.

Maximum akkor "gáz" a TRIM hiánya, ha nagyon régi SSD-t használsz.

Oldschool Computer - http://oscomp.hu

De, érted, most gépelgeted közé állandóan a .* toldalékokat, kényelmetlen. Minek kerülnénk, ha egy apró CLI toolal meg lehet oldani, az fzf sem egy bloat valami, pár KB-os alkalmazás, benne van minden unixlike OS tárolójában, nagyon hasznos máshoz is, nem csak a Ports-ban kereséshez. Nyilván csak a find parancs még minimalistább, meg ott lenne rá a find | less parancs is, vi billentyűkkel az is tud keresni, meg akár regexpet szóval számos megoldás van, ez a unixlike rendszerek előnye. Azt nem is írtam, hogy kötelező az sqlite, csak hogy meredek megoldás, az a szintű elvetemültség, amitől az én agyam is ledobja a láncot.

A TRIM-ben lehet egyébként igazuk van, és a modern meghajtóknak nem kell, de én azért napi szinten használt daily driver rendszernél nem kockáztatnék. Persze, be lehet bootolni FreeBSD-t hozzá, és havonta egyszer TRIM-ezni vele a meghajtót, de érted, az kb. olyan gáz, mint mikor hajbazer teszi ezt az XP-jével, hogy Linux meg újabb Windows alól kell TRIM-elgetnie. Valahogy rohadtul nem ideális megoldás. Pedig még Linux alatt is kézzel TRIM-ezek, mivel nem akarom, hogy állandóan szolgáltatásként fusson, és visszafogja a teljesítményt, ezért 1-2 hetente lefuttatok egy karbantartó scriptet, ami lekérdezi smartctl-lel és nvme paranccsal az SSD-k állapotát, kijjelzi a rendszeren a szabad helyet df -H -x blabla paranccsal, meg a végén fstrim -av kiadásával TRIM-ezi a felcsatolt partíciókat, nyilván csak a támogatott fájlrendszereken és meghajtókon.

Az is igaz, hogy kicsit az én hibám, mert azt eleve tudtam, hogy desktopozni inkább való FreeBSD, több mindent támogat, de ez az OpenBSD szimpatikusabb volt sok mindenben. Lehet még így se dobom, próbálkozok vele. Ha már egyszer fent van, rendesen próbálok neki esélyt adni. Egyébként nagy kár érte, mert jó rendszernek tűnik ez az OpenBSD, szerintem óriási benne a potenciál, csak ilyen apróságokkal kb. használhatatlanná teszik.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Egy szóval nem mondtam, hogy bloat az fzf; csak azt próbáltam mondani, hogy ez eléggé ilyen DirectTurkász fajta keresés, ami nem baj, de azért nem kell lehúzni az OS által adott lehetőséget; vö. a "make search akármi= útvesztőkkel"; FYI: ez az "útvesztős" megoldás is awk-kal turkászik a ports fában, csak éppen ő tudja is, hogy hol keres, te meg az "útvesztők" kihagyásával a teljes ports fát átnyálaztatod a turkászós cuccaiddal, úgyhogy hiába nyúlsz a legminimalisztikusabb cuccokhoz, így is nagyobb overhead-del fog járni.
Az SQLite-os megoldás nekem sem nyerte el a tetszésemet, de opcióként nincs vele baj.

De minek kéne TRIM-capable OS-t bootolni és manuálisan TRIM-melni, amikor a modern SSD-kben van garbage collection? A TRIM-support lehetett szempont 10 éve, de ki a túró vesz ma szándékosan 10 éves SSD-t direkt OpenBSD alá?

A drivereket leszámítva az OpenBSD ugyanúgy alkalmas desktopnak, hiszen ugyanazok a desktop környezetek érhetőek el rá, mint FreeBSD-re.

Esetleg nem akarod elárulni, hogy milyen vasra raktad fel az OpenBSD-t?

Oldschool Computer - http://oscomp.hu

De írtam, egy ThinkPad X220-ra (i5-2520M, 2×8 giga 1333 MHz DDR3L RAM, 525 gigás Crucial MX300 és egy 500 gigás Samsung 860 EVO SSD van benne) tettem. Elvileg ezek már modernebb SATA3/mSATA SSD-k, 4-5 évesek.

fzf-fel én is csak a Port-sban keresek csak a /usr/port/ útvonalon, nincs benne túl sok mappa, azonnal töltődik a megoldás. Már amennyire lehet beszélni OpenSD-ről azonnaliságól, mert mint írtam, azért kicsit komótos OS, nem kínzóan lassú, de nem tud olyan villám sebességeket, mint egy modern Linux. Előtte ezen a notin Arch Linux volt SwayWM-mel, ami az i3wm waylandes klónja, elég pattogós volt rajta a rendszer. Természetesen Ports nem volt Archon, de már ez alatt is mindent fzf-fel csináltam, gyors mappaváltás, kézileg indexelt plain text doksik elérése vim-ben, kézi felcsatolós script, online rádióhallgatós script (URL-ek + mpv), stb. mind-mind fzf-et használ nálam, minden gépen. Lehet kipróbálom a FreeBSD-t is, vagy újra Gentoo-zok rajta (arra nem a legjobb, mert a 2 magos régi mobilproci nem épp combos a sok kódforgatáshoz, 4 szál, 4 MB L3 cache, alacsony freki, alacsony IPC), de egyelőre még megnézem mik a lehetőségek ebben az OpenBSD-ben.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ott fent csak azt írtad, hogy tervezed feltenni egy ThinkPad-re, utána, amikor rákérdeztem, hogy mire raktad fel, akkor nem mondtad.

Bírom ezeket a konkrétum nélküli, hatásvadász megfogalmazásokat, hogy "komótos", meg "villám sebességek"...time paranccsal mit mértél egyik alatt és mit a másik alatt? Mik voltak az FS cache beállítások OpenBSD alatt és mik voltak Linux alatt?

Oldschool Computer - http://oscomp.hu

Kösz, ez a második link hasznosnak tűnik, meg fogom nézni ezeket a beállításokat, főleg CPU freki, fs cache, és egyebek, de csak holnap, mert ma már nyomtam 3+ órát, és elegem lett belőle. time paranccsal már nem tudok mérni, mert a Linux helyére ment fel, még a rendszert se mentettem el. De mondom, érzetre lassabb.

Léptem azért előre. Jók a színek tty konzolban, működik az export TERM=rcons-color, az mc bénázása miatt hittem, hogy nem jó. Leforgattam a weblapján lévő forráskódból a Vifm-et is. Megoldottam, hogy működjön vim-ben a Backspace, a .vimrc-be kellett a set backspace=2 sor. Működik a startx, de sajnos ha elváltok másik tty-ra, majd vissza arra, amin az X futott, akkor a grafikus driver beszarik, és Ctrl+C-vel kell lelőni az X-et. Megetettem végre a ksh-val a beállításokat, a trükk az volt, hogy nem a .kshrc-t olvassa be, hanem a .profile fájlhoz ragaszkodik.

Az mc még bénázik, hogy nem tudja kezelni a funkcióbillentyűket, igaz a Vifm sem tudja a nyílbillentyűket. Hiába van a billentyűzet magyarra állítva. Szerintem ez a vt100 emuláció miatt van, amit a rendszer default erőltet, még reszelek rajta.

Azt viszont továbbra is tartom, hogy a rendszer túl lyukkártya. Pl. az ls parancsnak hiányzik egy csomó kapcsolója a GNU ls-hez képest, pl. típus szerint rendezés, meg mappák rendezése a fájlok előtt, stb.. A find-nak is kevesebb kapcsolója van, stb.. Az egész kényelmetlenebb ilyen apróságok miatt, ez addig nem tudatosul az emberben, mikor Linuxot használ, de mikor BSD-n feltűnik a hiánya, akkor elég nagy keserűséget tudnak ezek az apróságok okozni, amikről az ember nem is gondolná, hogy hiányozni fog, mert adottnak veszi Linuxon, hogy van, alap. Most már kezdem érteni, hogy mi hívta életre a Bash-t, meg a GNU toolsetet. Ennek ellenére alakul a rendszer, de még mindig nincs használható szinten, túl sok apróság nem működik még, nagyon kényelmetlenül lehet még csak használni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

"Érzetre..." Arra szoktunk adni a reáltudományokban. :/

Szóval akkor mégis be lehet állítani azt a konzolt olyanra, amilyenre szeretted volna. Ki hitte volna. :P

Már megint egyes programok dolgait húzod rá a rendszerre és már megint egyes programokat mosol össze a Linux-szal. Ha a GNU ls és find kell neked, akkor miért nem rakod fel őket? A bash-t már tisztáztuk, hogy köze nincs a Linuxhoz, most akkor tisztázzuk, hogy a GNU toolsetnek se: egyfelől elérhető OpenBSD alá is, másfelől meg már a 80-as években is létezett, bőven a Linux előtt (a GNU ls konkrétan '85-ös, a find meg '90-es).

Oldschool Computer - http://oscomp.hu

Azért még nem egészen jó a konzol. Egyes alkalmazásokban nem minden billentyű működik. A fontváltás is felemás, mert már ugyan sikerült, wsfontload-dal be kell tölteni a fontot, de ez semmit nem csinál, csak előtölti a konzolkezelőnek, utána a wsconsctl display.font=/út/vonal paranccsal kell hivatkozni a wsfontload által betöltött fontra. Továbbra se jó, mert szétesnek a betűk, akár .pcf, akár pvf.gz fontot adok meg neki, de mégis félsikernek érzem, mert már van hatása a piszkálgatásnak.

A GNU ls, find-ot hagyom, mert vannak rá jobb klónok, exa, fd, stb., inkább csak kritikaként mondom, hogy a BSD-seknek nem kéne leragadni túlzottan ennél a POSIX kompatibilitásnál, ugyanis így nem lesz soha fejlődés. Egy-egy új kapcsolót, hasznos feature-t nem tart sokból implementálni, a hardverigényt se fogja mérhetően megdobni, ne feledjük, hogy itt pár KB-os CLI toolokról van szó, nem 100+ megás Electron appokról, amik bekajálnak 1+ giga memóriát.

Igen, ezeket a köröket lefuthatjuk, hogy GNU ls, find, Bash, egyelőre nem teszem fel. Nem csak azért se, hanem hogy rákényszerítsem magam, hogy a BSD toolsetet ismerjem, tanuljam meg használni, legyek tisztában a különbségekkel. Végül is nem kizárt, hogy később kényelmi okból felrakom a a GNU ökoszisztémát a rendszerre, de egyelőre vergődök a beépített BSD toolokkal. Ne feledjük, hogy a BSD-knek pont az az egyik lényege, hogy komplett megoldások, nem csak egy kernel, aztán hozzá valahonnan máshonnan guberált toolok, hanem az egészet az adott BSD fejlesztőcsapata fejleszti, tartja karban, hogy egységes ökoszisztéma, konzisztens OS legyen. Ha ebbe bele van barmolva mindenféle hipszter soyrustware-rel, meg GNU toolchainnel, Bash-sal, zsh-csel, stb., akkor az már tényleg majdnem olyan, mintha egy Linux disztró futna BSD kernellel (lásd Debian esete). Mert én magam is írtam, hogy a GNU nem csak Linuxon van használva, de az emberek 99,999%-a innen ismeri, ez a bélyeg már rajta van, akkor is, ha a Linux előtt is létezett, meg Mac-en, akármin is volt használva, meg BSD-kre is telepíthető. Ez épp olyan, mint a Putty, Visual Studio/Code, azokat is windowsos szoftvernek tartják, pedig elérhető több platformra is, ennek megint az az oka,, hogy 99,999%-ban windowsosok használják. Nem tudom, hogy mit olyan nehéz ezen érteni. Az senkinek nem újdonság, hogy konkrétan a Linuxhoz semminek nincs köze a systemd-n, pulseaudio-n, stb.-n kívül, mert csak egy kernel magában, ami tőle független projektekre épített mindig is, főleg olyanokra, amik már előtte is léteztek.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Nem a konzol nem jó, hanem a konfig.

Ezen a "a BSD-seknek nem kéne leragadni túlzottan ennél a POSIX kompatibilitásnál, ugyanis így nem lesz soha fejlődés" kitételen nem tudom, hogy sírjak, vagy röhögjek, vagy mindkettőt felváltva, vagy akár egyszerre. Remélem ez vicc volt. :P Ha elérhetőek a GNU toolok egy mozdulattal, akkor "leragadtak" a POSIX-kompatibilitásnál? Pont azért van így, mert nem szarják telibe a backward-compatibility-t, ha az kell, akkor ott a default toolset, ha meg az új feature-ök, akkor ott a GNU.

Az utolsó bekezdéseddel már majdnem kezdtem egyetérteni, hogy ebben tényleg van valami, amikor megint kilukadtunk oda, hogy ha felteszed az extended toolsetet, akkor az olyan, mint egy Linux disztró, BSD kernellel... Nos, a túrót. Van olyan Linux disztró, amiben nemhogy a GNU toolset, de semmi sincs, mert nem is kell, hogy bármi legyen benne, mert mondjuk valami embedded szart hajt meg. A GNU és egyéb - desktop/server Linuxok alatt megszokott - toolsetek használata nem "Linuxosít" el semmit, mert ezek a toolsetek nem ekvivalensek a Linux-szal, de még csak nem is Linux sajátosságok; a BeOS klón Haiku-ban is a bash a default shell.
Az meg, hogy az emberek 99.999%-a mit gondol, vagy mond, az miben releváns a kettőnk vitáját és a te az OpenBSD-ről alkotott és kommunikált véleményedet tekintve? Mi tudjuk, hogy GNU tools != Linux, nem? Én legalábbis tudom, te meg azt állítod, hogy tudod, de akkor miért csinálsz folyton úgy, mintha nem tudnád? Ezek mind cross-UNIX toolok, te pedig folyton Linux-privilégiumként tekintesz rájuk és úgy is érvelsz, mintha azok lennének. Én nem értem, hogy ezen mit nem lehet érteni, hogy ez miért hibás álláspont és invalid érv.
BTW, a Linuxhoz a systemd-nek és a pulseaudio-nak sincs köze, mert azok sem részei a kernelnek, ezek a userspace-t fertőzték össze. A pulseaudio ráadásul nem is Linux-only sajnos, pl. a Solarisokat is megfertőzte.

Oldschool Computer - http://oscomp.hu

Úgy értem a POSIX kompatibilitást, hogy a BSD-sek túl szigorúan veszik ezt és sok feature-t nem implementálnak, ami a GNU-ban és zsh-ban pl. ott van. Pl. az OpenBSD és NetBSD wscons megoldása nem támogat UTF-8-at, de még az ISO-ból is csak az ASCII 7 bites részt. Vagy pl. sok hagyományos tool, mint a find, vi, stb. nem támogat önmagában sem UTF-8-at, meg egy csomó modern feature-t (pl. a vi, nvi, elvis nem törli láthatóan egyesével a karakteret insert módban backspace-re, az utóbbi kivételével nem tud több műveletet visszavonni és kódot színezni, stb.). Meg az említett hasznos kapcsolók. Azzal az indoklással, hogy ezek nem teljesen POSIX kompatibilisek, mert nem legkisebb közös nevezők, mert az eredeti AT&T UNIX-okban, meg a hagyományos BSD-ken nem voltak jelen.

A GNU meg ilyen. Lehet te ezzel nem értesz egyet, de a legtöbb embernél összeforrott a Linuxszal. Annak ellenére, hogy még Linuxból is van, ami nem használja, mert BSD toolsetet meg busyboxot, stb.-t használnak. Így meg ez a bélyeg rajta marad a GNU-n. Azt viszont nem is tudtam, hogy Solarisra is van pulseaudio, LOL, ha nem vigyáznak, a systemd-t is az arcukba kapják :D Mármint nem a Solaris, mert annak hivatalosan vége van, hanem a FOSS klónjai, OpenSolaris, Illumnos és társai.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Dehát ennek pont az az oka, amit mondanak. Ha a GNU toolok funkcionalitása kell, akkor tedd fel őket, hiszen elérhetőek. Ha meg POSIX rendszer kell, akkor meg az van by default.

De itt most a kettőnk vitájáról van szó, nem a legtöbb emberről. Állításod szerint te tudod, hogy ez nem így van, csak akkor miért beszélsz úgy, mintha nem tudnád? BTW, ez a "legtöbb ember" kitétel is ilyen konkrétumok nélküli, levegőben lógó, minden számszerűséget nélkülöző légből kapott állítás. Mint kitárgyaltuk, macOS-ra is van GNU toolset és azok 6-8x annyian vannak, mint a Linuxosok; akkor miért is forrt volna egybe a legtöbb embernél a GNU a Linux-szal? A GNU-nak saját OS-e is van.
Igazság szerint már az Illumos sem húzhatja túl sokáig így, hogy a szarákül kinyírta a Solarist. :(

Oldschool Computer - http://oscomp.hu

Desktopra szerintem az OpenBSD (de talan az osszes BSD) sajtreszelovel rejszolas, de szivesen olvasom amiket irsz. :)

Azert a szabad shell valasztast hagyjuk mar meg BSD-n is, Linuxon sem kotelezo mindenbol a default-ot hasznalni, szoval egy bash-t feltenni meg nem szentsegtores.

Az viszont igen, hogy security feature-oket tiltogatsz le extra sebessegert. Security over everything.

Nekem legjobban a pf tuzfal tetszik benne amugy.

Mindíg is lassabb volt mint a többi rendszer, de nem ezért szeretjük.
2 évig használtam desktopra én is. 
Fluxbox-szal és KDE-vel is próbáltam, de végül lemondtam róla desktopon.
Használtam egy darabig fájlszervernek is, nameg tűzfalnak.
Mondjuk ez 2006-ban volt, akkor még volt a flash baromság is, ami miatt kellett az opera meg a linux emuláció.
Biztosan jobb már a helyzet, azóta nem próbáltam desktopon.
Lehet szeretni :-)

2006 óta azért sok minden változott, meg a BSD-k sokat zárkóztak felfelé. Meg hála az égnek, ilyen Silverlight, Flash, Java (böngésző szintjén), IE6 web substandardok (HTML/CSS nem szabványos gányolások, ActiveX), stb. mentek a levesbe, úgyhogy ezzel a részével nem kell szívni. Linux emulációt kerülni fogom amúgy is.

A Fluxbox jó választás, a KDE tudom, hogy megy, de nem való egy ilyen minimalista rendszerre. Mert ahogy felteszed, és hozza magával az összes bloatot, onnantól fogva el fog veszni a BSD soványsága és egyszerűsége. Azzal is tisztában vagyok, hogy a FreeBSD előrébb tart az OpenBSD-nél, nagyobb kódbázisú, több mindent támogat, de pont emiatt tetszik jobban az OpenBSD. Valahogy előnye, hogy a polkorrektkedők nem találták még meg maguknak, nincs CoC, nem támogatnak melegfesztiválokat, ilyen Red Hat, P5stering, Gnome-osok, MS, Google, Ó-rák-köl, stb. még nem tuszkolták bele a millió soros kreténségeiket, mert nem látják rá méltónak. Így meg csak hobbiszakkör jelleggel szakemberek fejlesztik maguknak, szakmai alapon, és nem az öltönyös-nyakkendős cégvezérek divatmajmolása dönt, ez is egy kifejezetten jó dolog benne.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az OpenBSD nem minimalista. A minimalista azt jelenti, hogy csak az a minimum van benne, ami a minimális működéshez kell, annál azért meg még az OpenBSD-ben is több van.

Ezzel viszont

Valahogy előnye, hogy a polkorrektkedők nem találták még meg maguknak, nincs CoC, nem támogatnak melegfesztiválokat, ilyen Red Hat, P5stering, Gnome-osok, MS, Google, Ó-rák-köl, stb. még nem tuszkolták bele a millió soros kreténségeiket, mert nem látják rá méltónak. Így meg csak hobbiszakkör jelleggel szakemberek fejlesztik maguknak, szakmai alapon, és nem az öltönyös-nyakkendős cégvezérek divatmajmolása dönt, ez is egy kifejezetten jó dolog benne.

maximálisan egyetértek. :)

Oldschool Computer - http://oscomp.hu

Novemberben lesz két éve, hogy OpenBSD-t (is) használok a közel 11 éves Asus X52F laptopomon (2 magos, 4 szálas 3. generációs i3 proci, 8 GB 1066 MHz-es RAM). Az OpenBSD-t egy 240 GB-os SSD-re telepítettem, de található a gépben egy 320 GB-os merevlemez is, amin FreeBSD 13 van.  Végig jártam én is a szokásos utat Windows 3.1/3.11-gyel kezdve, aztán 2005/06 körül jött a Linux (SUSE, Mandrake, Ubuntu, Uhu, Zenwalk, stb.). Közben egyre többet hallottam és olvastam a BSD-kről, míg nem 2017 augusztusában elhatároztam magam, és felraktam a FreeBSD-t. Használtam közel 2 és fél évig, semmi bajom nem volt vele. Persze először sokat kellett böngészni, doksikat olvasni, mire mindent beállítottam.  De valahogy izgatott az OpenBSD, mert sok jót olvastam róla. így 2019 őszén a CD-meghajtó helyére rakattam a gépbe  egy SSD-t, és arra telepítettem az akkor aktuális OpenBSD 6.6-ot (most 6.9).  Azóta az OpenBSD a main OS, a FreeBSD-t ritkán használom. Mindkettőt XFCE 4.16-tal futtatom. Mindegyiknek van előnye. hátránya a másikkal szemben.  FreeBSD-re sokkal több alkalmazás van, azon fut a VirtualBox is, így ott tudok Linux virtuális gépeket létrehozni, ha éppen kell. OpenBSD-re nem sikerült telepítem az Epson Stylus C62 nyomtatómat és HP ScanJet 3400C szkenneremet, FreeBSD-n gond nélkül működnek. A programozási nyelvek többsége működik OpenBSD-n, bár két kedvencem a D és a Julia sajnos nem. FreeBSD-n ezekkel sincs gond.  OpenBSD jobban ügyel a biztonságra, egyszerűbb az OS upgrade, a boot gyorsabb, mint a FreeBSD-nél, de amúgy a működése, programok futtatása valóban. lassúbb.  Összegezve elmondható, hogy mindkettő alkalmas általános desktop felhasználásra, a kettő együtt meg pláne jól kiegészíti egymást. Ahogy mondani szokták, it"s fun to use, nekem valahogy sokkal Unix-abb érzés, mint a Linux.