Melyik volt a legmegbízhatóbb FreeBSD kiadás?

Címkék

< 3.0-RELEASE
5% (8 szavazat)
3.0-4.5-RELEASE
3% (5 szavazat)
4.5-RELEASE
3% (5 szavazat)
4.6-RELEASE
6% (10 szavazat)
4.7-RELEASE
8% (12 szavazat)
4.8-RELEASE
22% (34 szavazat)
4.9-RELEASE
23% (35 szavazat)
5.0-RELEASE
2% (3 szavazat)
5.1-RELEASE
5% (8 szavazat)
5.2-RELEASE
14% (22 szavazat)
-CURRENT
8% (12 szavazat)
Összes szavazat: 154

Hozzászólások

Kérdés: Szavazatot hogy lehet megváltoztatni? Hülye voltam nem olvastam el rendesen a kérdést és 5.2-release-ra raktam holott, azzal volt bajom a saját ftp daemonja miatt.

Hát akkor így jártam.

Amúgy másnak is történt már olyan, hogyha nagy (mondjuk pár száz MByte-os) file-t ftp-zet le az 5.2-rol, amelynek a sajat ftpd-je ment es kozben azon dolgozott valamit, akkor kifekudt a rendszer? A PureFtpd-vel ezt nem tapasztaltam.

Azoktol kerdeznem, akik a FeeBSD 5.2-RELEASE-re szavaztak:

mibol derult ki a megjelenes ota eltert kemeny 2 hetben, hogy az a legmegbizhatobb? :-)

Lehet hogy rosszul tudom, de a FreeBSD sajat ftpd-je az az alap rendszer resze, namarmost ha ennek mukodesebol adodoan borul a rendszer, akkor az a stabilitast elegge karosan befolyasolja. Nem? En csak kerdezem a dolgot? Es ha az I/O miatt lenne, akkor ugyanez lenne a helyzet ha a 4.9-cel csinalnam ugyanezt, de az vigan megteszi, sot 5.1-nel sem volt semmi gond ez egyedul az 5.2 eseteben jelentkezett es amiota kikapcsoltam a sajat ftpd az inetd.conf-ban es pureFtpd hasznalok helyette nem jelentkezik ez a dolog.

a 2.2.6-os :-)

egy általam használt gépen még mindig az fut 6 éve :-D

Tehat akkor. Egy rendszer hw hibat leszamitva ugye egyetlen modon fektetheto meg: kernel 'tamogatassal'. Ha jo a kernel, akkor ugyse enged semmi olyat, amibol baj lehet. Egy ftpd pl csak akkor okozhat borulast, ha a kernel megenged neki olyan dolgokat, amit nem kene. I/O/halozati terheles alatt megint a kernel hianyossagait ertem. 5.x egyebkent meg mindig csak technikai kiadas, ha valaki igazi FreeBSD-s stabilitast akar, akkor 4.x. Mindenhol 100x le van irva, hogy az 5.x meg nincs kesz, vannak meg benne szep szammal teljesitmeny/stabilitasi hianyossagok. Persze hoz rengeteg ujdonsagot, olyanokat is, amiket 4.x alatt eddig nem lehetett megoldani, de ha valaki egy ilyen rendszer hasznalatara vallalkozik, akkor ezzel automatikusan felvallalja egy fejlesztes alatt allo project velejaroit.

Ertem! Innentol kezdve viszont nem kerdeses, hogy 5.x-re nincs ertelme szavazni hisz ez meg egy fejlesztes alatt allo rendszer :)))), tehat a stabilitast tekintve mindekeppen alatta marad a korabbi verzioknak. Az uj technologiaknak amugy is ido kell, hogy kiforrjanak illetve kellokep tesztelve legyenek. No mostmar eldugulok.

Ja megegy kerdes: ha en viszont kellokep felhergelem magam ezen a dolgon, akkor hogyan tudok utana menni (gondolom valamifele hibakereses vagy figyeles utjan), hogy mi is okozhatja ezt? Nem csinaltam meg ilyet ezert kerdezek ilyen "balgasagot". Tehat ha tudom reprodukalni a hibat, a korulmenyeket, akkor hogy tudom elkapni a "farkat" a dolognak illetve hogy lehet ezt jelenteni. Tudom ez konkretan nem tartozik ehhez a temahoz, de gondoltam megkerdezem.

legegyszerubb (es leghasznosabb) az ha reprodukalhato hibat talalsz az alaprendszerben, hogy jelzed a fejlesztoknek. hiszen mindenkinek erdeke, hogy az ilyen bugok (ha vannak) mihamarabb kideruljenek.

Azt nem mondom, hogy magad allj neki debugolni, mert ha nem tudod mivel, akkor minek? :-)

Szoval a legjobb egy reszletes bugreport.

Mhhm, koszi! Amugy azt sejtem, hogy valoszinuleg a kernel-t es a vilag reszeit debug modban forditva valamint gondolom itt is mint GNU/Linux alatt hibas mukodes utan core.dump-t a gdb-vel vizsgalva ki lehet talalni mi is a ludas a dologban, de ez azert nem olyan egyszeru. :))).

Nos koszonom az infokat, remelem nem voltam tul faraszto.

egyaltalan mit jelent az hogy ,,kifekudt'' a rendszer? ha kernel panic, akkor forditasz egy debug kernelt

(ha 5.x-et hasznalsz, akkor amugy is ajanlott) in-kernel debuggerrel (BSD-knel ez ugye alap feature),

aztan vagy ddb-vel, vagy panic utan rebootolsz es gdb-vel nezel egy backtrace-t (h coredumpot gyartson

az rc.conf-ba rakj egy dumpdev= es dumpdir= opciot). utana vagy fixalod a bugot, vagy reportolsz

(es rajossz, h -CURRENT-ben mar javitva van ;-)

A "kifekudt" annyit jelent, hogy mikozben ment a letoltes rola, en ep a nagyobbacska Qt-ben irodot progimat forgattam, plusz ment a Mozilla, meg alapbol: natd, sshd, lpd, postmaster (postgresql ez kell a progihoz) es egyszer csak kep kifagy, HDD LED allando voros, billentyuzetre/egerre nem reagal, tavolrol (ssh, ftp) sem elerheto. Csak a csunya "RESET" gomb segit rajta. No gondoltam nezzuk meg ujra: ugyanaz. 4-szer probaltam ujra ezt az egyuttallast mindig ez lett a vege. Ezutan lecsereltem az ftpd --> pureftpd, proba es nem volt semmi gubanc. Innen gondolom, hogy valami disznosag lehet az ftpd-ben az 5.2 eseten.

Amugy pedig koszonom a segitseget, megprobalom a -CURRENT-et, lehet abban mar nincs ez benne.