- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Én sem akarok flamelni. Imho ez egy szakmai "kúltúrált vita", már amennyiben még létezik még ilyen manapság:-)
A beteszek egy könyvtárba egy scriptet imho nem összevethető avval a szintel, hogy az egészről van
- LSB-ben állásfoglalás, hogy hova kell
- Szól róla a debian policy, és debhelpereket ad a postinst script segítségére
- ha nem tetszik, akkor az összes symlinket eltávolítod az update-rc.d -f remove scriptnév parancsal
- ha meg általad meghatározott sorszámot akarsz neki adni, hogy pl. biztos később induljon el egy másik szolgáltatáshoz képest, akkor meg update-rc.d scriptneved start 25 2 3 4 5 . stop 15 0 1 6 .
- stb.
Ill. a BSD-ben a runleveleknek megfelelő dolgot sem láttam. Ha már itt tartunk, de lehet, hogy én nem voltam elég alapos, és én nem tudom ehhez a .sh-hoz elképzelni, hogy hogy adom meg, hogy melyik runlevelben fusson, és melyikben ne.
- A hozzászóláshoz be kell jelentkezni
Nem ertek a BSD-khez, de biztos vagyok benne hogy a dolog ennel sokkal osszetettebb :)
Van valahol van valahol ertelmes osszehasonlitas a Linux es a BSD-k kepessegeirol? Egyaltalan mit nem tud a linux, amit egy BSD tud?
Laci
- A hozzászóláshoz be kell jelentkezni
Például olyan szintű jail-t nem tud a Linux mint a BSD.
Vagy a linuxos portmappere épülő szolgáltatások mint az NFS úgy kaki ahogy van, és emellé még olyan lukas mint egy tésztaszűrő. A BSD-ken ugyanez frankón, és megbízhatóan megy.
A BSD-ben tudsz Linuxos kódot futtatni de a Linuxban nem tudsz BSD-s kódot futtatni.
De hogy hátrányt is mondjak:
A BSD-re elég gagyi állapotban vannak az Xfree86 szerverek (Legalábbis a 4.5 Release-nél próbáltam utoljára), olyan értelemben, hogy a vacak nvidia Geforce 2 MX-esemen havazik a kép, és xv-ről nem is álmodhattam alatta.
Hirtelen ennyi jutott eszembe :-)
- A hozzászóláshoz be kell jelentkezni
Az hogy ettől még a BSD kernele nem biztos, hogy beszél a linux agpgart moduljának megfelelő "protokollal". Sőtt tuti nem.
Jah, és még egy különbség: Állítólag a linuxnak van az egyik legjobb randomgenerátora, ha már a kernel által közvetlenül (deviceokon keresztül) nyújtott szolgáltatásokra gondolunk.
Amúgy Desktop rendszeren én is, sőtt imho még bra is abszolúte Debianpártiak vagyunk. Viszont én a BSD-vel csak apró kisérleteket tettem, ő pedig komoly szervereket üzemeltet BSD-n.
- A hozzászóláshoz be kell jelentkezni
A kettõ azért nem ugyanaz. A BSD-k a Linux kernelhívásait emulálják, gyakorlatilag teljesen transzparens, hogy mit futtatsz.
Például elindíthatsz egy linuxos bash-t és abból meghívhatod a FreeBSD-s mc-t. Ha pld. a NetBSD-t nézzük, akkor ehhez még hozzáadhatod azt is, hogy a FreeBSD-s mc-bõl meghívod a NetBSD-s vi-t :)
Mivel ez kernel szinten megy, sokkal gyorsabb, mint a vmware (nem virtuális gépet szimulál).
A VMWare egyébként FreeBSD-n is mûködik valamilyen szinten.
Tavaly az LME konfon volt a BSD Egyesületnek egy demo gépe, amelyiken FreeBSD futott. Az egyik konzolon guestként be lehetett jelentkezni a FreeBSD-re, a másodikon rootként egy RO FreeBSD jailbe, a harmadikon egy komplett Debian GNU/Linux volt. X is futott rajta, amiben a Linuxos VMWare ment és abban pedig egy Windows 98.
Elég impresszív volt :)
- A hozzászóláshoz be kell jelentkezni
"szerintem a BSD nem mint kernel hanem mint disztribucio (pl ports) nem eri el a debian szintjet."
Szerintem meg igen. Nekem tetszik, hogy a gépem fordítja a csomagokat és ha úgy akarom megadhatok fordítási opciókat (pld. gcc 3.2 állítson elõ athlon XP optimalizált kódot).
Szerinted miért nem éri el a Debian szintjét? A minõséggel, vagy az elvvel van inkább baj?
"Osszessegeben szvsz a ket kernel fej-fej mellett halad (marmint ami egy szerverbe kellhet)"
Kérdés ki melyik részt használja. Ha valaki nagyon ki akarná hozni a maximumot a gépébõl, nagyon kéne ismernie az adott architektúrát, kernelt, userspace-t és feladatot ahhoz, hogy tökéletesen tudjon választani.
A szabad BSD-k pld. el vannak picit maradva SMP ügyileg a Linuxtól (ezen FreeBSD fronton az 5.x megjelenése segíteni fog, de még annál is egy nagy lock védelme alatt lesz a hálózatkezelés, Linuxnál meg ha jól tudom ez már a múlt). De ha az SMP-t más oldalról nézem, az OpenBSD bár csak egy processzort képes meghajtani, egyszerre több kriptokártyát is el tud látni feladattal, Így a Linux FreeS/WAN-jához képest az OpenBSD magasan veri SMP-ben azt...
Egyik ebben jobb, másik abban. Még a szabad BSD-k is nagyban eltérnek egymástól (a FreeBSD-ben például nincs is kripto hardver támogatás)
- A hozzászóláshoz be kell jelentkezni
Megfontolásra érdemes válasz :)
Az init scriptekre reagálnék csak röviden (idõ hiányában):
Az 5-ös kiadásban lesznek
A mostani rendszernek én annyi elõnyét azért látom (ha mást nem is), hogy a démonok paranccsori opciói megadhatók az rc.conf-ban, illetve egy sorral engedélyezhetem, tilthatom az indulásukat.
A Debianban ezt (elképzelhetõ, hogy hibásan) az initscript elejére biggyesztett exit 0-val szoktam megoldani.
A többivel nagyjából egyetértek, valószínûleg ezeknek az okát az aktív fejlesztõk alacsony számában lehet keresni. (és a feladat is megoszlik. Míg a Debiannál inkább "csomagolnak" az emberek és erre van egy jól bejáratott módszer, addig a BSD-knél inkább kódolnak és a csomagok karbantartását gyakorlatilag "külsõsök" végzik).
- A hozzászóláshoz be kell jelentkezni
bra@scribble$ man update-rc.dés voila :-)
Egyébként nem tudom, hogy mi ez az rc hülyeség mostanában. A BSD-ben át akarnak álnni a sys v típusú scriptekre ha jól értem. A DWN-ben meg azt írják, hogy a következőkben be kéne hozni a BSD stílusú rc scripteket. broáf! :-)
BTW.: Az update-rc.d miatt és a /etc/init.d/skeleton, start-stop-daemon és egyéb ilyen debian eszközök miatt nekem a sys v stílusú rc jobban tetszik. Sokkal modulárisabb, és ha fejlesztek vmit, akkor nem egy rc scriptbe a "megfelelő" helyre kell be-patch-eljem magam, esetleg egyezkednem egy csomó más démon karbantartójával, hanem regisztrálom magam az update-rc.d-vel, stb.
Szóval imho a debianban ez szebb.
- A hozzászóláshoz be kell jelentkezni