- A hozzászóláshoz be kell jelentkezni
- 2022 megtekintés
Hozzászólások
Akkor most mi lesz a napi release-ekkel ;)
- A hozzászóláshoz be kell jelentkezni
Szia
Gondolom, ha hibajavitasokra allnak ra, akkor surobben jonnek a releasek, kb. orankent ;).
York.
------------------------------------------------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."
- A hozzászóláshoz be kell jelentkezni
Vegre nem szolt le senkit.Be latta hogy nem csak neki lehet igaza :).
- A hozzászóláshoz be kell jelentkezni
Neki igaza van, hisz ő is egyetért vele :)
- A hozzászóláshoz be kell jelentkezni
Mindenkinek igaza van szeirntem.
Bar, nem vagyok kernel guru, de eszrevettem, hogy ez az ize egyre nagyobb. A kernel VALOBAN nagy. Tele van mindenfele dolgokkal, mint architektura tamogatasok, hang es videokartyak, mindenfele hw hutyu, tehat elegge homogen izenek latszik. Egyre tobb kod persze egyre tobb bugot eredmenyez. Fel se tetelezem, hogy 1-2-3 ember a patch-ek berakasakor ki tudja szurni ezeknek a hibajat, vagy meglatja a lehetseges bugok nagyreszet. Megteszik, amit tehetnek, de ez ugy latszik keves. A modulok iroinak kellene jobban atnezni, amit csinalnak. Az persze nem lenne butasag.
Valahogy ugy kepzelem a windoz es linux kozotti idoszakos bug aranyt, hogy a windozban kifejezetten kulonallo rendszerekben van a hiba, mint media player, exploder, kernel. Linux-ban meg jobban egyben vannak a dolgok, ami megneheziti a hibak kereseset. Mintha a windoz alatt egy nagy monolitikus 20MB-os EXE-ben lenne a kernel, media player, explorer, levelezo, es ebben kell megtalalni es javitani a hibakat. Valahogy igy maskepp kell erlemezni a hibakat a ket rendszerben szerintem.
Az othoni felhasznalonak egy linux kernelben kevesebb kritikus hiba van, ugy erezem. Ebbe belejatszik az is, hogy altalaban a rendszerek i/o dolgait (firewall, levelezo, services) kulso emberek tartjak karban, es emiatt kevesbe erzekenyek a linux kernel hibaira is.
Masik dolog, pedig hogy a git-be talan nem egyszeru implementalni valami issue tracking rendszert, Linusek meg gondolom, ragaszkodnak a git-hez, es nem akarnak ketfele sem adminisztralni.
- A hozzászóláshoz be kell jelentkezni
Na, ebből egy szót se értettem. :-) Vagy inkább remélem, hogy csak félreértettem.
- A hozzászóláshoz be kell jelentkezni
En is elkezdtem alahuzigalni alanyt-allitmanyt-miegymast, de nem jottem ra a lenyegre. :)
- A hozzászóláshoz be kell jelentkezni
Na, most en elvesztettem a fonalat feluton... :-)
Egy dolog, hogy elszaporodtak a bugok; most hadd ne reszletezzem, hogy miert alltak at uj fejlesztesi modszerre, a hirarchivumban van ra valasz boven.
1. Szerintem ne keverjuk ide a windoze-t, az olyan lenne mint ha buzakapalas kozben, a gorog filozofia nagy dilemmait a bengali tigris szabadidos tevekenysegeivel magyaraznank. :-)
2. Tokmindegy, hogy mekkora a "merete", sokkal inkabb fontosabb, hogy a kernel egyre osszetettebbe valik, amire a fejlesztok szamanak a novelese sem ad megoldast. Sot, ilyenkor altalaban tovabb rontja azt. Elarulom, hogy mas szoftverek is kuzdenek hasonlo problemakkal, de ezekre a problemakra meg nem nagyon van bevalt, kiprobalt, hosszutavu megoldas. Workaround az viszont van: lassitani kell a fejlesztes utemet, figyelni a felhasznaloi visszajelzeseket es reagalni, az erintett szoftver kiadasi rendszeret at kell dolgozni, a fejlesztocsapat boviteset pedig lassu utemben folytatni/engedni, meg meg sokminden mas. A fejlesztesre hasznalt eszkozoket pedig folyamatosan fejleszteni, hogy azok minnel hatekonyabban teljesitsek a feladatot. :-)
3. Csak egy jotanacs: arra figyelj, hogy ne valtogass egyetlen hozzaszolasban 10 tema kozt szaporan, mert sajnos minden forumon (a hupon is) vannak akiknek kimondottan erre faj a foga, hogy mielobb talalni valakit akire ra lehet csimpaszkodni egy-ket hozzaszolas alkalmaval, tovabb provokalni, majd visszajarni forumozni, ratapadni a jeloltre es agyba-fobe marni ahol csak lehet. Erre figyelj, mert egy ilyen hozzaszolas az egyik legjobb celtabla nekik. :-)
---------------------
Ригидус а бетегадьбол
- A hozzászóláshoz be kell jelentkezni