- A hozzászóláshoz be kell jelentkezni
- 7139 megtekintés
Hozzászólások
Alan Cox: Its incredibly hard to keep a stable kernel side API/ABI by just backporting fixes. Fortunately you can pay vendors to do this for you and provide support, or if you just want the bits run stuff like Centos
Tenyleg a vendoroke a piszkos munka. :)
- A hozzászóláshoz be kell jelentkezni
Tehát a Linux egyik leginkább csodált fejlesztője szerint incredibly hard az, amit az összes Linux disztribúció csinál: megpróbál egy adott kernelverzión maradni és azt patchelni a legújabb kernelekben megjelent hibák ellen.
Mi következik ebből?
a. a disztribútoroknál komoly kernelfejlesztői tudás van és képesek egy néha teljesen más környezetből (hint: két minor verzióval későbbi STABIL kernel -gyorsan felejtek, ismét elmagyarázhatná valaki végre, hogy itt a stabil mit is jelent, merthogy API-t nem, és lévén, hogy ezen fejlesztenek, működési stabilitást sem) vett módosításokat úgy az ő ezeréves (a Linux terminológiában) kernelre portolni, hogy azzal nem rontanak a helyzeten és nem hoznak be új hibát
b. azon disztribútorok nagy többsége, amelyik képtelen megfizetni hozzáértő dióbélcsákányosokat csak úgy a vakvilágba vi kernel.c-zik, kvázi olyan szinten, hogy: diff nekemvan linusnakvan | patch, és ha ez nem megy, akkor megpróbálja -a környezet értése nélkül- addig módosítgatni, amíg a patch hiba nélkül le nem fut. Ha ezután fordul a kernel.c, akkor jó, ha esetleg be is bootol, mégjobb.
Kivétel talán persze a Red Hat és hasonlók, akiknek ténylegesen van pénze olyanokat fizetni, akik vesznek egy adott kernelt (az ftp.kernel.org LATEST-IS-HUDESZUPER fájl alapján), majd fél évet dolgoznak rajta, hogy átmenjen a QA-n és végül kiadják a legújabb 6.0-ás OS-t, ami ha jól megy 6.4 környékére már nagyjából minden ismert hibától mentes lehet.
Persze a tömegnek megfelel a -lt, -ac, vagy -ck, esetleg -tfu (totally fucked up) kernelpatch széria, hiszen a kernel még viszonylag működőképesnek mondható az általános hardveren, ami a Pistikéknek van. Gentoot, Debiant pedig általában ezeken futtatnak, tehát az még talán használható szinten van.
Red Hatet viszont már lehet, hogy némileg szofisztikáltabb környezetben, emiatt tehát ők sokkal többet dolgoznak a kernelen, hogy az ügyfeleiknek megfelelő legyen.
Néha persze nem sikerül és abból jönnek a debianos, gentoos alapokosságok: a Red Hat szar, a benne lévő kernel szar, bezzeg az enyémmel (2.6.99-bleedingedgerc3alpha3subminor2) minden klappol.
És akkor a jövő: a Red Hat és hasonlók megunják, hogy a már ma is milliárdos Linux üzletükben a növekedés legnagyobb gátja a software engineeringről sosem hallott (sőt, büszkén elutasító) pattanásos kamaszból lett open source evangelista (mellékesen néha patchet olvaszt be, nácizik, vagy a Sunt szidja és persze még szuperrambóként gyerekfürdetés után hajnalig kódol is félálomban) félistenek és csinálnak egy forkot. Vagy maguknak (hiszem ezt teszik most is) és felvesznek még több embert, akik fölé tesznek egy (remélhetőleg) hozzáértő menedzsmentet, vagy szövetkeznek a többi nagyobbal, akik szintén belátták már, hogy ez így nem mehet tovább és megszületik a kétpólusú Linux:
- enterprise edition, ami lassan fog haladni, talán évekig is stabil lesz, egy, vagy több gyártó közösen, tervezve, gondolkozva gondozza
- developer edition (de hívhatnám home editionnak is, de ezen biztos megsértődne a sok tapasztalt, minden új kernelverziónál az -ac, -ck patchsetet grsec-kel, nf-hipac-kal és pre6-rmap15l-gyel összeházasítani próbáló Linux guru), amely megmarad a nagyemberek játszótere és amitől -ki tudja- adott esetben évekkel leszakadva, vagy éppen elhúzva lesz az enterprise edition
- A hozzászóláshoz be kell jelentkezni
Én nem látok ebben semmi rosszat, ellenben a választás lehetőségét igen.
- Ha cég vagyok, akkor van lehetőségem enterprise disztrót venni szupporttal. Akár a Microsoft-tól is, hogy (fals) biztonságérzetem legyen. Nekem a stabilitás fontos, pénzem is van megfizetni egy hozzáértőt, hogy akár az én problémámmal is foglalkozzon. Stabilitás, hosszú távra tervezés.
- Disztró használó vagyok. Rábízom magam olyanokra, akik valószínűleg nálam jobban értenek ahhoz (kevesebb tapasztalattal rendelkező, kisebb disztrók, is dolgozhatnak a nagy disztrók munkái alapján), hogy mi a jó. Használom az általuk összeállított kernelt. Senki sem mondta, hogy a BikkMakk Linux-ot kell használnom. Vannak olyan disztrók szabadon, amelyek mögött ott a Novell, a Red Hat, és a többi. De használhatom a CentOS-t is, ami egy az egyben a RHEL szabad megfelelője.
- Dióbélcsákányos vagyok. Mindenkinél mindent jobban tudok. Azt csinálok amit akarok. Majd én összepancsolom magamnak. Nekem senki nem mondja meg, hogy mi a kotta.
- Wannabe vagyok. Ugyanaz mint a dióbélcsákányos, csak tudás nélkül, de az arc legalább akkora.
Van miből választani.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
;_;
- A hozzászóláshoz be kell jelentkezni
Azt magyarázd el a tisztelt vendorok, miért nem 2.6.16 ágat tolják ? (Vagy újabbat esetleg)
Tisztelt kernel fejlesztők lényeges változáskor átnevezéssel is bosszantják a closed source fejlesztőket.
Van egy cég akinek ha fizetsz, ad neked egy stable API -t, amit hozzáforgathatsz a driveredhez, ha kernel változok, megszerezheted a következő kernelel működő stable API -t a zárt driverek ezt használják.
A stable API-d ráadásul még win driver szerű is lesz, így könnyen hassználhatod a win drivered kódját.
2.6.16 -nál nem kell dióbél csinálókat alkalmaznod, hogy stable 2.6.16 -od legyen :)
- A hozzászóláshoz be kell jelentkezni
Miért, nem azt tolják?
http://www.redhat.com/rhel/compare/
- A hozzászóláshoz be kell jelentkezni
A levél írója 2.6.10 esről és régebbi vendor supported kernelről hallott.
- A hozzászóláshoz be kell jelentkezni
Szerintem sokat segítene a helyzeten, ha a driverek és a kernel egyszerűen szétválasztható lenne. Sajnos sikerült már olyanba belefutnom, hogy egy adott program (kernel modul, ha tetszik) x kernelt támogatott csak, viszont a gép, amin használni akartam az egészet olyan alkatrésszel rendelkezett, amelyik csak az x+2-ben volt támogatott.
Persze meg is próbálhattam volna visszapakolni az újabb kernelből a drivert, ha éppen nem használ olyat, ami csak ott elérhető...
A user kapna (akár bináris, a forrás ettől még elérhető) drivert, amit egyszerűen be tudna tolni, függetlenül attól, hogy milyen verziójú kernele van.
Nekem leginkább ez hiányzik.
- A hozzászóláshoz be kell jelentkezni
Könnyen lehet, hogyha Linux kernel fejlesztő lennék, direkt szopatnám a zárt drivereket :) És azzal tömném a vendor fejét, ha nyiltá teszi akkor nem kell szopnia.
Ha nagyon akarnák a Linux fejlesztők adhatnának stabil API -t a third parti drivereknek, és az újításokat is vihetnék.
De ezzel a "csak nyílt drivert a kernelbe" törekvést szopatnák.
"csak nyílt drivert a kernelbe" -törekvést fontosabbnak tartom. Én is szoptam API változás miatt, de inkább szopok miatta, minthogy ennek a törekvésnek ellensége legyek.
- A hozzászóláshoz be kell jelentkezni
Hány olyan -egyébként nyílt, forráskóddal rendelkező- eszköz van, amelyik a Linux előző verzióiban még működött, a mostaniakban azonban nem?
Ilyen környezetben nem látom, hogy segítene az, hogy elérhető a driver forrása.
Persze, könnyű mondani, hogy javítsam meg magamnak, ha tudom.
De én is könnyen mondom, hogy ha egyszer megvettem a hardvert hadd tudjam már használni is.
- A hozzászóláshoz be kell jelentkezni
Hány olyan -egyébként nyílt, forráskóddal rendelkező- eszköz van, amelyik a Linux előző verzióiban még működött, a mostaniakban azonban nem?
Rengeteg... Hogy csak néhány saját tapasztalatot említsek:
- Egyes Eicon Diva ISDN kártyák csak 2.2-es kernel szériával hajlandók működni, 2.4-essel vagy 2.6-al nem.
- Xircom CEM28 driver 2.2-vel megy, 2.4-el nem.
- Tigon3 GbE NIC driver nem működött se 2.4, se 2.6 alatt jó ideig (jelenleg nem tudom mi vele a helyzet)
De szerintem kicsit eltöprengenék, akkor eszembe jutna még jópár eset...
- A hozzászóláshoz be kell jelentkezni
Mas kategoria, de nekem nagy szivfajdalmam, hogy miutan belegyogyitottak a v4l driverekbe a taviranyitok kezeleset a tunerkartyam eseten megszunt mukodni a taviranyito, ami korabban a LIRC modullal siman ment.
- A hozzászóláshoz be kell jelentkezni
Reportoltad ?
- A hozzászóláshoz be kell jelentkezni
Igen, patchet is kuldtem a v4l listara, de nem igazan reagaltak ra az emberek. En meg nem eroskodtem, hogy olvasszak be. Eleg marginalis problema ez, mivel egy tiz eves hardverrol van szo.
- A hozzászóláshoz be kell jelentkezni
Riszpekt
- A hozzászóláshoz be kell jelentkezni
Ezeket fos kőkori levlistás baromságokat el kéne már felejteni.
Bug trackerek, is elég szarok.
Nem tudom miért nem látok törekvést ezek lecserélésére.
Hogy megnövekedett felhasználó/hardware/program/feature/kódméret .. stb. mellett is jól kezelhető legyen egy projekt bazaar módra :).
- A hozzászóláshoz be kell jelentkezni
Did you drink too much gin too today?
- A hozzászóláshoz be kell jelentkezni
Mi alapján kapnak priolitást a bugok/patchek ?
- A hozzászóláshoz be kell jelentkezni
A bugtracker sem megoldas onmagaban, pelda erre a laptopom alsa-drivere. Kb. fel eve figyel a bugtrackerben egy patch, ami megoldana a problemat, de valahogy nem igazan akar bekerulni a javitas.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2581
Legalabbis az 1.0.14_rc2-r1 verzioval jelolt alsa driver meg biztosan nem tartalmazza.
ui.: Most esik le, hogy te sem a bugtrackerek mellett ervelsz. Mindegy azert jol esett panaszkodni. :)
- A hozzászóláshoz be kell jelentkezni
Nem illik újra reportolni és verni az asztalt egy bugtrackeren/levlistán, hogy kerüljön m`a be.
De fejlesztők így nem tudják, hogy hány embernek is van szüksége arra a patchre, mennyien gondolja jónak rossznak.
Véletlenül átugorhatja, vagy más fejlesztő rossz priolitást adott neki.
Nem lehet jól megmondani, hogy pl. x,y verzió érintett ebben, z,w nem, mind mind egy-egy levél lenne, ami így floodolná a rendszert.
Nem lehet megmondani, hogy mennyire egyedi eset, esetleg disztró specifikus vagy projekten kívüli dolog okozza. Elég rosszul követhető egy bugtrackeren, hogy ha más(másik project) okozza hibát akkor akiknél jelentkezik miben egyezik az ő rendszerük és miben tér el azoké akiknek megy.. (pl. akiknek baja van lofasz.so.123.0.1 -at használnak mindenki másnak jó)
Hiányos bug reportoknál jön az infó kérés, ami gyakran a fejlesztőt várakozásra kényszeríti, nincs egy egységes mód, hogy küld el milyen rendszeren szopsz kérdésre. (h-inventory scriptjei talán használhatók erre, de az sem egységes)
Egy n00b főleg nem tud szelektálni mivel lehet összefüggésben..., hogyan adjon értékes infót így ? (Még több üzenet váltás)
Van egy csomó olyan dolog amit ki lehetne gyűjteni és egy jóféle bugtracker ezt kezelné, nem szétterhelve smtp szerverekt :)
(Ezt e kérdést még elő fogom venni valamikor, és rendesen kifejtem)
- A hozzászóláshoz be kell jelentkezni
Speciel kapásból csökkentené a bugreportolások számát, ha például a tesztelést nem boldog-boldogtalanra bíznák, aki
a) vagy reportol
a.1) vagy ad használható reportot
a.2) vagy nem
b) vagy nem
Erre lenne jó, egy tesztkörnyezetek felállítása, valamint szakképzett emberek ráállítása a témára. Persze ez mind munka, pénz, idő, szervezés és ez se garantálja a tökéletes kódot, de ez is olyan, mint a biztonság: "yet an another level".
Másik meg, ha valaki küld patchet, akkor azzal talán foglalkozhatnának egy picit, mert csak előrébb vannak egy - elvileg - kész megoldással, mint egy egyszerű bejelentéssel.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Verzió követést majd máskór ócsárolom, ill. bug reportolással patch küldéssel való kohézióját.
"Erre lenne jó, egy tesztkörnyezetek felállítása, valamint szakképzett emberek ráállítása a témára. Persze ez mind munka, pénz, idő, szervezés és ez se garantálja a tökéletes kódot, de ez is olyan, mint a biztonság: "yet an another level"."
Ez nem jó, ellentétes a FLOSS működési elvekkel. (Bár, ha csak a kernelröl beszélsz az más)
Csak mondjuk 10000 projekthez sem kivitelezhető, még billinek sincs ennyi pénze.
Nekünk olyan rendszerre van szükség ami meglévő anyagi javakkal (tárhely/internet/CPU) jobb megoldást kínál, pénz nincs tudás van elvet követve.
Mert lehetne jobban is csinálni.
- A hozzászóláshoz be kell jelentkezni
"Ez nem jó, ellentétes a FLOSS működési elvekkel."
Na igen, Az Nagy Csodálatos Elvek. Sajnos/szerencsére (nézőpont kérdése) nagyon úgy néz ki, hogy a linux eljutott arra a pontra, ahol meg kell nézni, hogy tulajdonképp mit is akarnak elérni.
Viszont egyre inkább úgy látom (szigorúan szvsz), hogy a jelenlegi modell sokaknak nem tetszik és többen szeretnék, ha valaki komolyabb kiteszteltebb valamit kapnának kézhez. Igen, ellentmond a FLOSS elveknek, de lehet, el kellene gondolkozni, hogy ezek az elvek nem állnak-e a fejlődés és/vagy a minőség útjában.
"(Bár, ha csak a kernelröl beszélsz az más)"
Kernelt kell tesztelni, de pl egy OOo-t nem? Na nee, minden nagyobb projectre ugyanúgy ráfér a tesztelés, mint minden egyébre. Persze, komolyabb tesztkörnyezetet csak nagyobb projectekhez éri meg felállítani, de lenne bőven olyan project, amihez megérni. Van nem egy fontosabb OS project, amihez jól jönne.
"Nekünk olyan rendszerre van szükség ami meglévő anyagi javakkal (tárhely/internet/CPU) jobb megoldást kínál, pénz nincs tudás van elvet követve."
Akkor tessék feltalálni a Seti féle elosztott teszt-rendszert. Biztos lenne bőven linux fan, aki futtatná. De látom nem érted, mire akarok kijukadni: a linux és még néhány project kinőtte magát. Szép meg jó ez a hobbyproject hozzáállás, de ezen a szinten már nem tartható. Ld. feljebb: el kell dönteni, hogy elveket/hagyományt akarnak követni vagy jobb rendszert készíteni.
Szerk.: Egyébként van elég cég, akik a linuxból élnek meg, nekik is érdekük lenne, hogy legyen erős minőség-ellenőrzés a fontosabb projecteknél. Tessék szépen támogatókat keresni.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Sokban egyet értünk, de te nem értesz.
A fejlesztési elvek működő képesek.
Az eszközökkel van a baj amik nem igazodnak a fejlesztési elvhez, főleg nagyobb projektek esetén, tűnik ez fel.
"Hülye aki nem gitet használ" :)
git lehet jó irány, de hozzá kéne igazítani a többi infrastrukurális elemet.
Itt főleg a fejlesztők között , fejlesztő-felhasználó közötti kapcsolattartást értem.
Probléma az információ morzsák szétforgácsolódása és rosszul kezelése,
disztrók miatti tovább forgácsolódás a problémák kezelésekor.
Mindig vannak emberek akik a disztróba kerülések előtt kipróbálják a szoftver így vannak ingyen teszterek. A disztrók kicsit késve olvasztják be és akkor nem az ő userik vannak az első teszt vonalban.
Még a gentoo is késve tesz dolgokat a portage be, testingnek jelölve is.
Van valmi cég/hivatal, ami teszterkedésre veri, és több száz open source projektben is keres hibákat, talán itt volt hír. Van valami tesztelő cumója.
- A hozzászóláshoz be kell jelentkezni
Coverity-re gondolsz?
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Meglehet.
- A hozzászóláshoz be kell jelentkezni
"Van valmi cég/hivatal, ami teszterkedésre veri, és több száz open source projektben is keres hibákat, talán itt volt hír. Van valami tesztelő cumója."
Igen, de az csak tipikus programozói hibákat keres. (Tömb túlindexelése pl.) Hasznossak ezek is, tényleg sok mindent lehet vele javítani, de viszont ezekkel az eszközökkel nem igazán lehet ellenőrizni azt, hogy a kód tényleg azt csinálja-e ami a tervekben volt. Máshol meg nagy farmokat építenek csak arra, hogy ilyen szimulációkat végezzenek.
A másik probléma meg az általad említett információkezelés. Ez valahol köszönhető az általad említett elveknek is, mert ugyebár senki nem kötelezhet arra, hogy én karbantartsak valamit.
Asszem bra írta valahol lejjebb, hogy ő mint cég, nem alapozna ilyen instabill valamire. Szóval lehet, hogy tényleg nem ártana egy erős vezetés az ilyen open source projectekhez, akik meg tudnák oldani azt, hogy az ilyen patchek ne keveredjenek el, mindig mindenre legyen megfelelő karbantarto, teszet, stb. Ezért mondom, hogy kinőtte magát. Eddig lehetett követni ezeket az információkat, most már viszont túl sok van belőle. Eddig is szét kellett osztani a munkát, úgy látszik már ez se elég. (Persze totláis bürokráciát se kell bevezetni).
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Már nem csak bra írta, hanem egy olyan ember is -igaz egyelőre csak magánvéleményként- aki jobban belelát a Red Hat működésébe.
Azt hiszem kezd megdőlni az a pont, miszerint csak a hupperek egy kisebbségének nem tetszik ez a modell és egyre inkább úgy tűnik, hogy azok, akiknek ebből van a kenyerük sem teljesen elégedettek.
- A hozzászóláshoz be kell jelentkezni
Red Hat, ha valóban külön utakon kezdene el járni, az pont rontana azokon a problémákon amit írtam.
Roszabb lenne RH -nak és mindenki másnak is.
Az összes lényeges projekt forkolására nincs ereje, egyik cégnek sem.
- A hozzászóláshoz be kell jelentkezni
Érdekes ezt pont a te szádból hallani, aki megrögzött Linux és jelenlegi fejlesztési modell hívő.
Az, aki leírja, hogy szerinte vannak problémák ezzel az agyatlan baromkodással, amit a tisztelt fejlesztőurak művelnek troll, de most, hogy végiggondoltad a dolgot, kiderült, hogy ez az egész rossz mindenkinek?
Hogy is van ez?
- A hozzászóláshoz be kell jelentkezni
Van egy apró különbség.
Engem alapvetően jó szándék vezérel, nem hobby szinten kötök bele valamibe.
Megnevezem a problémák vélt forrást.
Van némi megoldási javaslatom is rá (remélem a szövegből is kitűnik mikre gondolhatok), az itt felvázoltakra is. Pontosabb leírást tervezek, némi tanulmányi kirándulás után. Azt remélem, hogy ezek megfogalmazása után mások is keresnek rá megoldást.
A bazaar modell olyan, mint a fizikábol ismert önszerveződő folyamatok modellje. Modellek jó egyzést mutatnak.
Én azt állítom, hogy a bazaar modell működik és, hogy ez modell hatékony.
A folyamat jellegéből adódóan nehezen megjósolható a végkimenetel, de a célnak megfelelő lesz.
- A hozzászóláshoz be kell jelentkezni
Mr. Red Hat CEO a befektetőknek:
Kedves Befektetők!
A SOX szerinti negyedéves tájékoztatóm következik. A szoftver- és supporteladásaink jól haladnak, idén várhatóan 23,4%-ot bővül a részesedésünk, x, y és z céget tervezzük megvásárolni. A szoftverfejlesztéseinkkel sincs semmi gond,
"A folyamat jellegéből adódóan nehezen megjósolható a végkimenetel, de a célnak megfelelő lesz."
Köszönöm a figyelmet és kérem a részvények eladásával legalább addig várjanak, míg én kiszállok az üzletből!
- A hozzászóláshoz be kell jelentkezni
A két modell keresztezéséböl nagy dolgok születnek, születtek.
Commerical Vendor, tudja a felhasználó számára biztosítani a kiszámíthatóságot.
Hobbysták cserélnek kódot/tapasztalatot a vendorokkal is. (Közvetve, közvetlenül)
A hobbysta nem igényli ezt a fajta kiszámíthatóságot.
milestone -ok megnevezése, már bőven elég nekik. (Nagyobb projektetk, felvázolnak célokat vendorok/vevők számára is értékelhető módon)
A hoppysták sok mindent kiprobálnak/kitalálnak, ami egy vendror számára is hasznos.
- A hozzászóláshoz be kell jelentkezni
"nem tetszik ez a modell és egyre inkább úgy tűnik, hogy azok, akiknek ebből van a kenyerük sem teljesen elégedettek."
Ezek kik? A fejlesztők, akik kitalálták az egészet?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Túl sok katedrálist tanult az iskolában .
Az a meglepő, hogy ilyen szar infrastruktúrával is működik a bazár :)
Pont ezért jó ez a modell, mert még így is jó.
- A hozzászóláshoz be kell jelentkezni
Van egy gyanúm hogy nincs is modell.
Vagy legalábbis annyira alakul a fejlesztés nagy vonalakban egy általános elv alapján, mint ahogy a konkrét kódolás igazodik rendszertervekhez. Semennyire.
Csak valamit mégis kell mondani hogy hogyan működik az egész, meg lehet róla könyvet is írni. Utólag.
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Ki gondolná, hogy van egy folyadékod egy edényben mondjuk legyen víz.
Elkezded erősen mellegíteni alul.
Lent melegebb lesz mint fent, a hő szépen terjed felfelé, nem mozgatod a az edényt.
A hő csere gyorsulni fog, kis örvényléseken keresztűl.
http://www.atomki.hu/kornyezet/f06.pdf
A doksi arról szól. hogy nyílt rendszer jobb mint a zárt :) (Szoftverről szó sincs benne)
"Fizikai modellek alkalmazása társadalomra" -dolognek is tekinthető.
- A hozzászóláshoz be kell jelentkezni
Leírhatjuk a tapasztalati tényeket egy projekt esetén. Egy másik projekt esetén teljesen másként működhet. Na ezen még csiszolni kell.
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
A modell működésének vannak feltételei. Ez adottak a nyilt szoftvereknél.
Interakció száma javítja kódot.
Minnél több ilyen van annál jobb.
Olyan eszköz rendszer kell, ami kölcsönhatásokat elősegíti. És lezajlásái idejét csökent.
Ezáltal a kölcsönhatás/sec nő ami gyorsabb, jobb fejlődést eredményez.
- A hozzászóláshoz be kell jelentkezni
Ilyen egy éves reakcióidőkkel, amiket emlegetnek, szerintem akár zárt is lehetne..
(Nem mondom hogy az opensource rossz, sőt, jó kéne hogy legyen. De ha a fejlesztőnek nincs ideje foglalkozni a külső kérésekkel, mert örül ha a saját ötleteire jut idő? Akkor valahol nem igaz az egész, amit sugall.)
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Nagy az idő szórás.
Az átlag 3-4 nap körül lehet.
svn/cvs nem igazán jó patch -ek fogadására (nincs irás jogod). Az e-mail kliens és vim között hosszú az út.
Nincs az, hogy azt mondja fejlesztő na ma kedd van lássuk milyen patcheket kaptunk, és pár perc alatt hozzá tolja kódhoz ami tetszik. Sok egyéb mail között kell kibányászni, hogy mi a patchek, nem látszik a mailből, hogy esetleg másik írás joggal rendelkező esetleg már be tette volna.
mail -t el kéne felejteni, mint patch management tool :)
bugtrackerek egy fokkal jobbak, de ez sem az igazi.
- A hozzászóláshoz be kell jelentkezni
Akkor mi a jó patchek fogadására?
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Messenger?
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Olyan eszköz ami:
Mindenki számára hozzáférhető, ugyan úgy mint egy levlista vagy egy mezei bug tracker, forum. stb.
Mindenki csinálhat elágazást egy patchel.
Mindenki értékelheti a -5..+5 ig mondjuk a patchet, lehet tudni hányan használják azt az ágat.
Minden patchez tartozik leírás.
Minden elgazáshoz tartozik fórum (kommunikációs szál).
Ugyan abban a reposity -ben vannak a disztrók patchei.
Van main ág (projek maintaner), distró ágak, és ezeknek patch ága, új feature ágak, ezek függőségeit, összeolvadásait kezeli.
Bug reportokkal kapcsolatban van. Tehát egy bug reportal kapcsolatba kerül (link), ha patch születik rá.
Ha összes main branchez jogosult elmegy nyaralni, és közben mások fejlesztgettek, hamar main ágá válhat valamelyik ág, mikor vissza jöttek.
Ehhez hozzá jöhet egy dokumentálást segítő rendszer wiki/doxygen jeleggel.
így nagy vonalakban.
- A hozzászóláshoz be kell jelentkezni
És ember legyen a talpán aki ezen majd eligazodik. :)
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
ez ugyanolyan mukodeskeptelen lenne, mint a wikipedia es a demokracia (marmint az az ize, amit mostanaban annak neveznek)
--
Those who do not understand Unix are condemned to reinvent it, poorly
- A hozzászóláshoz be kell jelentkezni
Olvasd el megint.
Valamit nem vettél észre.
"hamar main ágá válhat valamelyik ág, mikor vissza jöttek."
A main ághoz jogosultak választnak, egy ágat, ha nem lett volna tiszta.
- A hozzászóláshoz be kell jelentkezni
Esetleg nem lenne egyszerűbb, ha csak szimplán nagyobb prioritást élveznének azok a bugreportok, amikhez a beküldő szerint van kész megoldás? Kicsit egyszerűbb lenne...
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Nekem tetszik ez az ötlet. Kicsit emlékeztet az openscope-ra és a mandolinra, amin most Kéménczy Kálmánék és connorhuék dolgoznak...
Érdemes lenne továbbgondolni és ütni a vasat.
- A hozzászóláshoz be kell jelentkezni
"mandolinra" link ?
- A hozzászóláshoz be kell jelentkezni
http://workshop.connor.hu/mandolin/
esetleg:
http://mandolin.midian.hu/
Ez picit más, mert ők a fordításra koncentrálnak, de mégis érzek valami hasonlóságot a te öteteidben.
- A hozzászóláshoz be kell jelentkezni
Szerintem jó egy mezei bugtracker is, csak a fejlesztők lusták ezzel pöcsölni, inkább kódolnának. De hát az élet nem egy habostorta, elvtársak. ;-)
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
A Linux vendorok?
De majd az idő megmondja.
- A hozzászóláshoz be kell jelentkezni
Akinek az emberei (Alan Cox (Red Hat), Arjan van de Ven (a Red Hat kernelcsomagjainak karbantartója), GKH (Novell), Rik van Riel (Red Hat)), ..., kitalálták? Lehet. Egyelőre ők azt mondják, hogy nem tudnak jobbat. Majd kiderül. Én is azt mondom.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én nem tudom mi van a háttérben, lehet, hogy nekik így kényelmesebb, illetve olyan szerződésük van a cégekkel, hogy azok nem szólhatnak bele a kernelfejlesztéssel kapcsolatos munkájukba.
Ez esetben viszont lazán elképzelhető, hogy mint fejlesztő az az érdekük, hogy kontrollálatlanul öntsék kifelé a szart az ablakon, hiszen ez a legegyszerűbb, míg céges (stílszerűen piros) sapkában valamit összetákolnak és eladják mint stabil kernelt.
Az sem biztos, hogy Coxnak van céges sapkája. Én el tudok képzelni olyan szituációt, amit fent írtam, azaz szimplán azért fizet a Red Hat neki, hogy dolgozzon, de ennek a számonkérésével ki is múlik a munkakapcsolatuk.
Nem tartom teljesen kizárhatónak, hogy valami ilyesmi történik, a szerződésüket és a céggel kapcsolatos viszonyukat ugyebár nem teregetik a nyilvánosság elé.
- A hozzászóláshoz be kell jelentkezni
Nézzük meg egyes problémák Friction tényezőjét.
Vala egy problémád.
Mennyi ideig tart kideríteni másnak is van -e ilyenje ?
Mennyi ideig tart kideríteni született -e rá megoldás ?
Szerncsés esetben google első 100 találatában benne van, de ha nincs akkor hol, hogyan keresel ?
Minden disztró bug trackere, project bug trackere, minden open source forum.
Ez után lehet bugreportolni.
Lebányászod a kódot, ez hamar meg van egy checkouttal, vagy ilyesmi.
Hol essél neki a kódnak, kérdés jön most látod először . Gyakran nincs egy "general concept" leírás, tehát olvassol kódot, meg kódbeli megjegyzéseket.
Tételezzük fel lokalizálod a hibát.
Megoldod.
Na most jön az a rész hogy patchet kéne küldeni, és a fejlesztés/hibakeresés közben keletkezett szemetet kitisztítani. Neked megy a program, már nincs akkor motiváció a patch küldésre, mert ahhoz nem ártana némi tisztítás.
Alszol rá egyet és mégis csinálsz egy normális patchet.
Elküldöd mondjuk a e-mail ben a pathet.
Jön a másik oldal.
A fejlesztő gárda pont elmegy sörözni jol berugnak és kitalálják, hogy implementálják a kurva jó feature III -mat.
Mire készen vannak lehet elfelejtkeznek a leveledről.
Ha eszükbe jut, akkor fogják a mailt,kiszedik belőle a patchet és alkalmazzák elolvassák kiprobálják.
Azt senki nem tudja, hogy közben hányan alkalmazták saját maguk otthon a patchet (és keresgéltek a neten), esetleg melyik disztróba került bele hamarabb. Nem tudja a fejlesztő gárda, hogy a patch miközben ők a kurvajó feature III -at implementálták, azoknak akik kiprobálták segített -e, mert senki nem küldött olyan levelet nekik, hogy "ez a patch kurva jó", de a neten 20 forumra beírták.
Szerencsés eset:
Észreveszel egy problémát. Megnézed a disztród bug trackerét és ott van/vagy hamar válaszolnak rá mivel a projekt egyik fejlesztője ugyan azt a disztrót használja mint te. Reprodukálja, és mivel ő ismeri kódot szinte azonnal előáll a javítással.
patchek valahány százléka felett elsiklanak ez tény. De többség érvényre jut. Mondjuk ez azt nem vigasztalja aki érintett.
- A hozzászóláshoz be kell jelentkezni
Még lóf... projecteknél is dívik a nightly ISO build system.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Linux alatt tesztkörnyezet: all users. És tényleg vagy bugriportolnak, vagy nem, és ha igen, akkor is értékelhető vagy sem... Olyan ez, mintha Debianból a mostani unstable lenne a standard Debian...
A kereskedelmi disztrók pont a tesztkörnyezetet, teszttervezést, szakértő tesztelői és bogfixáló csapatot adják, amiből lesz az aktuális "stable"-nak nevezett, erősen fejlesztői Linux 2.6.x.y.z-rc-23-b4-mx/x verzióból termékszintű kernel.
- A hozzászóláshoz be kell jelentkezni
Véletlenül átugorhatja, vagy más fejlesztő rossz priolitást adott neki.
Turul, nem priolitás, hanem prioritás. Már többször elírtad, ezért gondoltam szólok. :)
Hiányos bug reportoknál jön az infó kérés, ami gyakran a fejlesztőt várakozásra kényszeríti, nincs egy egységes mód, hogy küld el milyen rendszeren szopsz kérdésre.
[...]
Van egy csomó olyan dolog amit ki lehetne gyűjteni és egy jóféle bugtracker ezt kezelné
[...]
(Ezt e kérdést még elő fogom venni valamikor, és rendesen kifejtem)
Amikor így beröffented a fantáziádat és elkezdesz álmodozni, hogy mennyivel jobban is lehetne ezt csinálni, akkor mindig azon röhögök, hogy amiket elképzelsz, azokat már má$ok rég megoldották, csak neked ugye ők se tetszenek... ;)
Természetesen kétélű fegyverről van szó. Egyrészről sokkal jobb lenne egy egységes, a fejlesztőket a lehető legjobban kielégítő bug report, amely központosítottan van tárolva, automatikusan futnak be a felhasználóktól és mindenféle tulajdonságok alapján lehet őket gyorsan és hatékonyan csoportosítani, feldolgozni. Ugyanakkor jön a másik szemlélet - természetesen joggal kétkedve -, hogy a részletesség miatt előfordulhat, hogy személyes információk is bekerülnek a bug reportba és vajon ezzel nem élnek-e vissza... Nyilván ezt 100%-ra sose lehet tudni és ígérni, ezért is teszik azt egye$ek, hogy számodra teszik választhatóvá, döntsd el te, hogy vállalod-e ezt a rizikót vagy pedig reménykedsz abban, hogy mások bátrabbak lesznek és nekik köszönhetően ki lesz majd javítva a téged bosszantó hiba. ;)
- A hozzászóláshoz be kell jelentkezni
Sosem hittem abban, hogy a Microsoft az így beküldött információk alapján ténylegesen csinál is valamit. Aztán még az IBM notebookomon volt egy érdekes hiba, a firefox (de nem csak az, jellemzően olyan programok, amik sok képet tettek a képernyőre) állandóan ledöglött és én minden alkalommal, akárhol is voltam rányomtam a bugreport küldésére.
Rohadjon meg az MS.
Később jött az ismerős ablak, hogy van öt percem a reboot előtt (automatikus frissítés telepítés). Rebootoltam és azóta nem találkoztam a hibával.
Lehet, hogy mégis csinálnak vele valamit, vagy csak beképzelem magamnak?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, de szerintem ez egy jó irány. Megadni a lehetőséget arra, hogy a user problémája megoldásra kerülhessen. Ha él vele (annak a rizikónak a tudatában, hogy esetleg személyes információkat is tartalmazhat az automatikusan létrejövő egységes bug report), akkor meg van az esélye arra, hogy a hiba javításra kerül. Ha többen jelzik (ezáltal többször fut be a probléma a központi bug tracking rendszerbe), akkor valószínű, hogy nagyobb figyelmet kap és hamarabb kerül megoldásra. Szerintem hosszútávon (és nagyban) csak ez a megoldás működőképes és kifizetődő.
Persze biztosan sok Linux user szeret levelezni a nagy kernel fejlesztőkkel és jó érzéssel tölti el, hogy "személyesen" foglalkoznak a problémájával, de ha elvonatkoztatom a dolgot a kis és nagyvállalati helpdesk működésre, akkor ott is az látható, hogy a kis cégeknél még működőképes, hogy Gizike felhívja a "számítástechnikus Gézát" (azért nem a Pistát, mert Gézának szebb a hangja és kedvesebb, meg egyébként is jobban áll rajta a farmer ;), viszont nagyvállalati szinten nem túl optimális ez a módszer, mert így egyrészről nem egyenletes az erőforrás eloszlás (többen szeretik Gézát hívni a problémákkal, mint Pistát), másrészről a nem központosított support miatt sokkal nehezebb követni a menedzsment részéről, hogy mennyi és milyen jellegű kérések futottak be, mennyi ideig tartott a probléma megoldás, stb. Nyilván épp ezért is nem véletlen, hogy ilyen területeken csak a legvégső esetben telefonálgathatnak a userek a problémáikkal, minden esetben a szabályzatban lefektetett előírások alapján kell eljárniuk. Ez sokszor egy direkt erre létrehozott speciális helpdesk weboldal, ahova beírhatják a panaszukat, aztán majd a rendszer másik oldalán ezt valaki magára vállalja és elkezdi az ügyintézést, felveszi a kapcsolatot a felhasználóval, stb.
Egyébként a notebookos példáddal kapcsolatban nekem is eszembe jutott egy érdekesség. Nem rég kaptam új céges laptopot és ennek köszönhetően (márhogy amiért új) már nincs rajta soros port, amely részemről kicsit fájó pont, mert néha szükség van még mindig rá. A másik fájdalmas dolog az volt, hogy PCMCIA hely sincs rajta (csak az új PCI Express foglalat), ezért a másik lehetőség sem működött, hogy RS232 kártyát dugjak bele. Maradt az USB-s átalakítós megoldás, amelyről viszont elég sok rosszat hallottam és mint kiderült nem is alaptalanul... A USB->Serial kábelhez kapott CD-n természetesen nem volt még Vista driver és a rajta lévő XP-s sem volt hajlandó működni (mint később kiderült XP-n sem működőképes a CD-n adott gyári driver). A sok probálkozás után végül egyelőre hanyagoltam a témát, de egy problem report elment végülis az MS felé. Ez volt néhány hete és pont a mai nap egyszer csak feljött egy "buborék", hogy 'solution' érkezett a problémámra. Rákattintottam és az alábbi ablak fogadott. Úgy látszik, hogy idő közben kikerültek a Vista driverek a gyártó weboldalára, így azt a javaslatot kaptam, hogy töltsem le és telepítsem azokat. :)
Erről egyébként egy bash.hu quote jutott eszembe és az, hogy márpedig MS-nél is van support... :P
- A hozzászóláshoz be kell jelentkezni
"Kb. fel eve figyel a bugtrackerben egy patch, ami megoldana a problemat, de valahogy nem igazan akar bekerulni a javitas. "
A FreeBSD-nek 2006. március 29-én bugreportoltam egy problémát az előírásoknak megfelelően. Leírás, hogyan lehet reprodukálni, és egy lehetséges megoldás patch formájában. 2007. március 15-re megszületett a javítás.
Jelzem, hogy semmi köze a Linux kernelfejlesztési modellhez. 1 évbe tellett. Szóval ne akarjunk ezekből bármiféle következtetést is levonni. Továbbá megjegyzem, hogy valószínűleg ez volt az első és az utolsó FreeBSD-s bugreport-om is egyben.
(A FeedBurner-nek lassan egy hónapja elküldtem a magyar fordítás egy részét, még válaszolni sem válaszoltak.)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
>> Szóval ne akarjunk ezekből bármiféle következtetést is levonni
illetve hát dehogy ne akarjunk: a bazármodell valódi milyenségére vonatkozólag
- A hozzászóláshoz be kell jelentkezni
Van szerencsém belelátni kereskedelmi rendszerek fejlesztésébe. Hasonló illetve más természetű problémák garmadája. Lehetne érveket felsorakoztatni pro és kontra. Nem tudom melyik lenne a jobb a végén.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Most ez csak diplomatikusság vagy tényleg soktényezős, ezért nem tudod mi a jobb?
Vagy lenne ötleted, hogyan lehetne megoldani, hogy ne egy évig tartson kommittálni egy javítást?
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Nem tudom mi a jobb. Ezért nem kritizálok olyat, amihez nem értek, illetve tudom, hogy nem tudnám jobban csinálni. Leírtam, hogy máshol is vannak problémák, olyan helyeken ahol véletlenül sincs Linux fejlesztési modell. Ebből adódik, hogy nem lehet mindet ennek a nyakába varrni.
(BTW: itt a HUP olvasók közt is van mindig olyan, aki tudja, hogy mit és hogyan kéne nekem jobban csinálni. De mégse igazán látom, hogy ezek az okostóbiások konkurens oldalt indítva megmutatnék, hogy mi a pálya. Dumagépek.)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem mindenki kritizálja azt amibe nincs belelátása, de ötleteket adhat. Például hogyan lehetne hatékonyabb a hibajelentések nyomán a javítás.
(A zárójeleshez meg képzelj el szerepcserét, sose lesz olyan hogy mindkét fél elégedett legyen, max. te, ha belátod hogy értelmetlen azt elvárni ami (be)tarthatatlan.)
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Azzal, hogy a másikra mutogatunk ("máshol is így megy", "másik oldal se jobb", stb.), attól nem lesz jobb.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Jobb nem lesz, csak talán eloszlódik az a sztereotípia, hogy a Linux fejlesztési modell miatt van minden probléma.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én se Linuxon szembesültem ilyennel. Ami igazán bosszantó volt.
- A hozzászóláshoz be kell jelentkezni
Könnyen lehet, hogyha Linux kernel fejlesztő lennék, direkt szopatnám a zárt drivereket :) És azzal tömném a vendor fejét, ha nyiltá teszi akkor nem kell szopnia.
Én meg HW fejlesztőként azt mondanám, hogy pusztulj meg a neved napján, nekem azért 0.1%-os piacért nem éri meg szarakodni.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Az évi 2 fuggvény átnevezés nagy szopás :)
Add ki a forrást és nem kell szarakodni.
- A hozzászóláshoz be kell jelentkezni
Lásd kettővel feljebb.
- A hozzászóláshoz be kell jelentkezni
FUD
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
RESOLVED
- A hozzászóláshoz be kell jelentkezni
lol @ you:
"Set to Resolved later, this is low priority and will not be worked on at the
moment."
- A hozzászóláshoz be kell jelentkezni
there's a newer version of the driver, and several people made it
work under different Linux distributions, see.
- A hozzászóláshoz be kell jelentkezni
WORKSFORME-sirám (c) litch
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ébn is erről beszéltem.
"In a nutshell, download the sources, extract them, patch them and apply them to your kernel. The actual instructions are farther down the page."
In an even smaller nutshell, you have to start h4x0ring obscure things in your system, the only alternative is to wait until all your bases belong to GKH.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Igen ugyanis a (fogalmazzunk így) nem hivatalos közösségi driverből van (állítólag) ami bizonyos újabb kernelkiadásokkal működik. Ez hurrá meg minden, kivéve ha ugye épp olyan disztrókiadást fogsz ki amiben éppen a nem supportált verziók vannak.
Gondolom ennek semmi köze nincs ahhoz a fejlesztési modellhez ami mostanság (?) a linuxot jellemzi, és még véletlenül sem b*szunk ki egyetlen nyílt forrás felé tendáló kis gyártóval.
- A hozzászóláshoz be kell jelentkezni
Van az úgy, hogy egy döntést nem lehet fájdalom nélkül meghozni. Olyan döntést, ami mindenkinek jó, még olyan kis jelentőségű projekt esetében sem lehet hozni, mint amilyen a HUP. Ez nyilvánvaló. Ha valamifelől döntök, akkor érdekek sérülhetnek itt-ott. Pedig itt alig van néhány "felhasználó". Ezért próbálok úgy dönteni, hogy a legkisebb legyen az elégedetlen réteg.
Na, akkor most ezt vetítsd ki egy Linux kernel méretű dologra, több millió user-ről, sok sok cégről beszélünk, más-más érdekekkel. Úgy kell dönteni, hogy az a lehető legkisebb fájdalommal járjon. Ez marha nehéz dolog lehet. Fenn kell tartani a techológiai fejlődést, haladni kell a versenytársakkal, mégis figyelni kell a "kicsikre" is. Jóban kell lenni a multikkal, hiszen nélkülük valószínűleg le lehetne húzni a rólót, vagy legalábbis komoly mértékben megsínylené a projekt a távozásukat.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Csakhogy ez a végfelhasználót nem érdekli. Őt az érdekli hogy ha a szomszéd Pistikének megy akkor neki miért nem (holott megközelítőleg ugyanannyit költött az adott cuccra). Innentől minden már csak a "bizonyítvány magyarázása".
- A hozzászóláshoz be kell jelentkezni
Vannak olyan emberek, akiknek egyszerűen nem való a Linux. Tény. Nekik nagyszerű más operációs rendszerek érthetőek el. Használják őket egészséggel.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
véletlenül felcserélted a linux és windows szavakat
- A hozzászóláshoz be kell jelentkezni
ROTFL
Winböl sok van.
De Linux sokkal több féle környezetben van.
- A hozzászóláshoz be kell jelentkezni
hát persze, logikus
- A hozzászóláshoz be kell jelentkezni
Nézd, én alig használok Linuxot, de több helyen olvastam már, hogy bizonyos dolgok nem működnek a 2.6-os kernelben, amik a 2.4-esben még mentek. Ezzel kapcsolatban sincsenek illúzióim, egy Windows Longhorn sem valószínű, hogy elmenne EISA-s SCSI kártyával, vagy egy mca-s ethernet kártyával.
Mindössze csak arra akartam célozni, hogy attól, hogy a gyártó kiadja a forrást még nem garantált, hogy a driver használható marad, vagy azzá lesz.
- A hozzászóláshoz be kell jelentkezni
rossz a matek. mivel csak akkor lenne igaz ha 1 db hw gyar uralna a piacot. a 0,1 inkabb legyen 1, es annak a gyartonak aki jelenleg az 1 %-ot sem eri el ez 100%-os piaci novekedesi lehetoseg lenne. mar csak fel kellene ismerni.
- A hozzászóláshoz be kell jelentkezni
"Én meg HW fejlesztőként azt mondanám, hogy pusztulj meg a neved napján, nekem azért 0.1%-os piacért"
Viszont egy olyan szerver szegmensre, amely folyamatosan növeli a piaci részesedését, lehet, hogy előbb-utóbb érdemes odafigyelni. Aki meg elfelejt, az lehet, hogy később bánni fogja.
Egyébként az a 0.1%, amit említettél, az IDC szerint a szerver piacon jó 12.7%-nak is:
"Linux servers posted their second consecutive quarter of double-digit growth and now represent 12.7 percent of the overall server market, or $1.6 billion for the first quarter of 2007."
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ja meg pusztuljon meg az user is, mert kaphatna valami olyat, ami működik, elheyet kaphat olyat, ami szép meg szabad, meg nyílt, csak épp ez nem érdekli.
Nekem semmi bajom nem lenne a bináris driverekkel, ha hiba nélkül tudom vele használni a gépem.
Első a felhasználó. Az átlagfelhasználókat meg nem érdeklik az ilyen-olyan "kifogások". Ubuntusok már kezdik látni, hogy az átlagusernek egyszerűen használható rendszer kell - szop(at)ás nélkül. Terjed is.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Átlag user nem használ NI mérő kártyát.
Ő nem találkozik az stable -api nonsens-el.
- A hozzászóláshoz be kell jelentkezni
"Ő nem találkozik az stable -api nonsens-el."
Ezt azért ne hirdesd túl sok helyen.
- A hozzászóláshoz be kell jelentkezni
Igaza van. Végfelhasználónak egyáltalán nem kell foglalkoznia semmilyen API-val. Azt sem kell tudnia, hogy ez mit jelent. Szerinted egy Windows végfelhasználó tudja mi az az API? vagy a dll (tapasztalatom szerint a legtöbb már azt sem tudja, hogy mi az a "My Computer" mert el van előle rejtve (helyesen))? Mi a véres monynak kéne tudnia?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha talán azt is megnéznéd amit belinkeltem fentebb.
Segítek win alatt még szaros unsupported win2k-val is menne a fent említett integrált fos. Linux alatt meg gyenge 2-3 év minor változása betett az "átlag user" próbálkozásainak hogy netán a gépét használja desktop célra olyan extrákkal mint Net. Persze igaz: nem kell tudnia a usernek az API-ról és társairól..elég ha azt látja hogy X rendszeren megy gond nélkül, Y rendszeren nem.
- A hozzászóláshoz be kell jelentkezni
Kalandozunk, kalandozunk. Más, kereskdelmileg támogatott OS-nél még rosszabb a helyzet. Ott a Solaris. Nem ilyen modell szerint fejlesztik, mégis jóval kevesebb a támogatott hw, mint a Linux alatt. Gyerünk, fogjuk rá a fejlesztési modellre.
Egy dolgot kéne megérteni. A végfelhasználónak semmiről nem kell tudnia. Annyit kell tudnia, hogy az ő választott operációs rendszere Fedora 8, Ubuntu 7.04 vagy Debian 4.0. Azt sem kell tudnia, hogy abban milyen kernel van. Én sem tudom, hogy Vista Enterprise-om (vagy mi a bánat) hányas build, mert nem érdekel.
Ha tudja, hogy milyen OS-e van, akkor meg tudja nézni annak a HCL-jét. Abból kell neki válogatnia hardvert. Ez a "power user". Már össze tudja rakni a gépét.
A sima user-nek még ennyit sem kellene tudnia. A sima usernek annyi lenne a feladata, hogy eldönti, hogy Linux, majd bemegy egy integrátorhoz (boltba), és megmondja, hogy nekem ez az igényem. Kap egy hardvert, amire az integrátor rápasszírozza a rendszert úgy, hogy az támogassa a hardvereit.
Ha az usernek olyan igényei vannak, amit Linux-szal nem lehet kielégíteni (az integrátor sem tudja), akkor annak az user-nek nem a Linux az üdvözítő megoldás. Nem kell erőltetni. Neki mást kell adni.
Én ezt így látom. A baj ott van, hogy a számítástechnika olyan mint a foci. Mindenki (azt hiszi, hogy) ért hozzá.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hehe..user bemegy a boltba és kérdi a kiválasztott rendszeréhez mondjuk kaphatna-e neki megfelelő vasat. Mondják: igen, ez az. User boldog és fizet, hazaviszi a gépet használja és örül..az első dist-upgradeig (ami eestünkbne 2 év mert ennyi durván a válaszott rendszerének a support ideje). Ezutáűn pedig kapja a pofájába: sajnos a választott rendszerének új kiadása nem támogatja a vasat, mert most sajnos nem érünk rá drivert hekkelni ..és kész.
Userünk ugyan biztosan rájön hogy trey mester bölcsességei igazak,és szépen el is tanácsol mindenkit az adott rendszer használatától mert neki meg csak ennyit kell tudnia. :)
Én így látom.
- A hozzászóláshoz be kell jelentkezni
Ezt az érvelést most nem értem, egy újabb kernel nem támogatja a régebbi vasat? (Mondjuk lehet, legutóbbi sysresccd-kipróbálásom úgy végződött, hogy kihajítottam, mert egy 8 éves gépben nem ismerte fel az integrált nic-et. :-DD)
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Ha elolvasod a linket akkor megérted: Volt egy gyártó által kiadott _nyílt forrású_ driver ami adott kernelverziókkal tökéletesen fordult, és ment. Aztán jön újabb kiadás és hipp-hopp kedvenc vasunk drivere nem fordul le.
Tudom:
a, FUD
b, Mié' pont Linux?
- A hozzászóláshoz be kell jelentkezni
Ja, hát vasat venni tudni kell. Ez igaz Windows-ra is. Egyik kollégám Windows 2000-ről nem tud frissíteni Windows XP-re, mert van egy szkennere, amihez nincs XP-s driver. Cumi. Legközelebb majd olyan vasat vesz, aminek a gyártója nem áll át mezőgazdasági gépgyártásra, mert a szkenner nem jött be.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ismerős probléma (gondolom parallel scanner). Csak sajna az ilyen esetek az eleve árérzékeny vevőknél nem éppen fogják növelni a bizalmat az adott rendszer irányába..főleg ha megtudják hogy bezzeg a másik OS-nél az adott vason semmi gondjuk nem lett volna. Persze tudom: ilyen esetek elő fordulnak pro- és kontra, csak ilyenkor szembesülni velük tényleg cumi. :/
- A hozzászóláshoz be kell jelentkezni
ugyanezt éltem át vindóz xp-mel
- UMAX 1600U USB-s szkenneremmel
- PCTV tv kártyával (rettenetes szenvedések és haxolások után lehetett XP alatt életre lehelni)
- A hozzászóláshoz be kell jelentkezni
Vegyél apple g3-at.
Weee!
- A hozzászóláshoz be kell jelentkezni
a kontakthibás sorozatból? ;)
- A hozzászóláshoz be kell jelentkezni
Mindegy, csak azt akartam érzékeltetni hogy pl. az elitosztály oprendszere sem támogatja a házon belül fejlesztett régebbi hardvereket.
;)
Weee!
- A hozzászóláshoz be kell jelentkezni
És a G3 mikori vas? '97?
- A hozzászóláshoz be kell jelentkezni
Eleje igen de a vége az érdekes, 2001. Mondjuk a dell meg 5 év után fosik a hw-támogatásra a microsofttal karöltve, holmi aero ürügyén.
Weee!
- A hozzászóláshoz be kell jelentkezni
Egen'..az általam említett vasnak meg szerintem az _eleje_ volt úgy 2005-2006 magasságában.
- A hozzászóláshoz be kell jelentkezni
Attól még, hogy valaki beszopatta magad valami normális ember által nem hallott NIC-kel, még igaz amit leírtam. Átlag felhasználónak nem kell tudnia semmit arról, hogy mi az az API. Az meg, hogy te kit hova tanácsolsz, az a te dolgod. Egyébként választhatott volna olyat is, aminek 5 év a szupport ideje, és ahhoz is válogathatott volna hardvert.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Az adott NIC egyébként egy neves gyártó (ASUS) gépébe van integrálva. És nem is hinném hogy a tanácsom a felkínált lehetőségek közül a legrosszabb lett volna.
Konkrétan milyen OS-re gondoltál 5 év support idővel (PC-re)? :)
- A hozzászóláshoz be kell jelentkezni
Ezek szerint az Asus is integrál szart.
"Konkrétan milyen OS-re gondoltál 5 év support idővel (PC-re)? :)"
PC-re három éves szupportot simán tudok "ingyenes" disztróval. 5 éves az már vállalati szint, és pénzbe kerül. Ott a pl. Red Hat Enterprise Linux WS sorozat szerintem 5 év, míg a RHEL szerver 7 év támogatással bír. De talán a Red Hat Enterprise 5 Desktop is 5 évre van támogatva.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
asusnak mar van olpc-je :) nem a beszalloszintet kell megvenni kerem szepen es akkor nincs szopika.
- A hozzászóláshoz be kell jelentkezni
Jah, hát nem low-end esetén simán kiajánlok egy Mac-et és peace. :)
- A hozzászóláshoz be kell jelentkezni
Igazából azzal a konfiggal, amiből a MacBook van, kiajánlhatnál Linuxot is. Nem egy gyártótól megkapod azt a hw összeállítást. Semmi extra nincs benne. Simán támogatja a Linux kernel. És fogja is. Ja, mert abban Intel alaplap van? Intel vezérlővel? Nem "nevenincs" NIC. Te is látod a problémát. Ha Intel NIC lett volna példatörténetedben, a mai napig támogatott lenne. De mondhattam volna az Intel helyett más nagyobb gyártót is.
Egyébként valószínűleg azért nem törték magukat az Agere által gyártott NIC támogatásával (ez az Agere nem winmodemeket gyártott?), mert kurva kevesen használhatják.
Szerkesztés: most nézem, hogy az Agere cég, aki a problémás NIC-edet gyártotta, meg is szűnt. Csodálod, hogy nincs támogatás a vacak chip-jéhez? Megvette az LSI, beolvadt abba.
"Sorry, the page you requested no longer exists.
On April 2nd, 2007 Agere Systems merged with LSI. All the former Agere Systems content has been absorbed into the new LSI Web site. Take a closer look as LSI focuses on the storage, networking and consumer markets to deliver the spark that brings people and information together. "
Egy driver nincs hozzá. Azt kell mondjam, hogy a hibát az követtel el, aki tudta, hogy Linux-szal akarja használni a nevezett notebook-ot, de ennek ellenére megvett egy olyat, amiben ilyen gagyi chip (ET1310) van. Körül kellett volna nézni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha árban kéne hasonlítani akkor inkább a Macmini-t mondtam volna kb. Abban meg semmi meglepő nincs hogy egy nagy gyártónak nagyobb támogatottsága van. Csakhát _gép_gyártó ugyebár nem "nevenincs", user pedig ezt nézi mert sem API, sem dll, sem NIC, sem chipset nem mond neki semmit. :)
- A hozzászóláshoz be kell jelentkezni
Asus notebook, benne a legendás winmodem gyártó Agere-től származó szutyok NIC, az micsoda, ha nem "messziről elkerülendő" kategória? Messziről süt a konfigról, hogy a "budget" kategória, abból is a legrosszabb.
Azon se csodálkoznék ha rajta lett volna egy "Designed for Windows XP only" matrica.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hol írtam hogy laptop? Ellenben írtam hogy az adott választási lehetőségek közül, illetve árérzékeny. Lehet rá mondani hogy pff, meg húhát az ilyen számológépet vegyen, csakhát mint mondottam volt, ha nem low-end akkor nyilván bepattan egy Mac vagy hasonló és akkor már minek szegényt Linuxal szívatni (mert minő meglepetés akkor már long-time supportot is kap még a ratyibb vasához is, és nem csak a sajnálkozás megy).
- A hozzászóláshoz be kell jelentkezni
Ezeknek tökmindegy. Ma jött egy update, már öten sikoltoznak hogy jajbelassult a gép. Röhögni járok oda.
Weee!
- A hozzászóláshoz be kell jelentkezni
"Hol írtam hogy laptop?"
Ha nem laptop, ellenben árérzékenység miatt megvetted ezt a szemetet, akkor mi a szomért' nem teszel bele kemény 1 790 forintért egy realtek NIC-et és élsz boldogan? Legyél már egy kicsit kreatívabb...
:)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
valószínűleg ez lesz. ;)
- A hozzászóláshoz be kell jelentkezni
ASUS-ról nekem nincs jó véleményem.
Sokan hypolták, addig amíg nem szoptak vele, winen is.
-Dehát az nem lehet hogy a HW/Driver szar ASUS -t vettem ami király.
Hány naív user..
- A hozzászóláshoz be kell jelentkezni
Na úgy látom ma még egyet is fogok érteni veled :)
Notim Wifi progija elég fos, ami azt illeti (Asus A6U 5001, valami Asus-s minipci-s kari van benne, pontossan nem tudom, megy, nem érdekel), viszont legalább megy XP alaptt. Linux alatt még nem próbáltam, nem érdekelt. (Mondjuk maga a kari nem gáz, csak a driver az hozzá.) Meg notiból is láttam már jobbat.
Másik "kedvenc" Asus termékem a K8N jelzésű alaplap, amivel találkoztam. Valahogy nem érzem benne azt a nagy Asus minőséget, ami miatt annyian dicsőítik.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Asus P4S800-nál kevés nagyobb trágya van.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
A probléma nem az, hogy gyorsan fejlődik, hanem az, hogy nincs kontroll, és a felhasználókat nézik tesztelőnek.
Ha visszatekintünk még a 2.0/2.1 időkben az volt a gyakorlati tapasztalat, hogy x.y.5 előtt nem tesszük fel a "stabil" kernelt olyan helyre, ami fontos nekünk. Aztán 2.2/2.3 és 2.4/2.5 alatt ez tovább tolódott, x.y.10+ (mások szerint 20+) környékére... Ennek az az oka, hogy nincs megoldva a kernel QA folyamata, konkrétan a tesztelés. Van egy "bleeding edge"-t használó csoport, akiknek egy részhalmaza még reportol bugokat, amik vagy elvesznek a levlistán, vagy nem.
Nyilván az emberek többsége 2.0 óta nem fog "development" kernelt használni, mivel a "stabil" is "elég jó". Az, hogy ipfwadm-ból ipchains lesz aztán meg iptables, az "igazi" felhasználót nem izgatja, fontosabb neki, hogy működjön a rendszere. Ennek egyenes folyománya, hogy egy új 2.x.0-ás "stabil" változatnál, hirtelen ingyen áldozati bárányok^W^W tesztelők hada (10000-100000 db) áll a fejlesztők rendelkezésére, akik gondolkodás nélkül forgatják, és pakolják fel a most már "stabil" kernelt. És persze jönnek a hibák... amik vagy kijavulnak, vagy nem.
Szerintem egyszerűen ezt ismerték fel a dióbélcsákányosok: ha "stabilnak" neveznek egy kernelt, nagyságrendekkel több tesztelőt kapnak. Mivel az igazi dióbélcsákányosnak ciki meg unalmas tesztelni...meg egyáltalán átgondolni az egyes változtatásokat. Így eljutottunk a jelenlegi szituációhoz, ahol a dióbél-propagandával ellentétben már a user-space ABI-t sem tudják vagy akarják stabilan tartani: http://lwn.net/Articles/233819/
A másik oldal viszont, hogy a rendszer még mindig "elég jól" működik, főleg a nagyobb disztrógyáraknak. A "komolyabb" alkalmazások úgyis csak bizonyos disztribúciókat támogatnak: RHEL4,5 SLES9,10 és kész. A Novell illetve a RedHat pedig egymással versenyezve kínálja ügyfeleinek az ABI kompatibilitást mint mennyei mannát. Ha én kereskedelmi szoftvert gyártanék Linuxra vállalati célközönséggel, én is ugyanazt tenném: csak bizonyos "Enterprise" disztrókat támogatnék, ahol nem kell azon aggódnom, hogy éppen melyik csákányos legújabb játékának a beolvasztása okoz majd jó sok supportköltséget nekem.
A jelenlegi rendszerben ami szerintem jó, az a különböző feature / stabilitás igényeknek megfelelő disztribúciók közötti választási lehetőségek:
- Gentoo és egyéb "hackelős"
- Fedora, Ubuntu ... stb. a fél éves kiadási ciklusokkal
- RHEL, SLES ahol fontos a támogatás (mind OS mind alkalmazás területen)
- CentOS ha RHEL-t akarsz ingyé'.
Ami szerintem nagyon rossz az a dióbélcsákányos kemény mag látható igénytelensége a QA / tesztelés terén. Pedig abban a pozícióban vannak, hogy _bármit_ megtehetnének, bármilyen minőségi szigorítást, kötelező automatizált tesztek stb. Az LWN adatai szerint kb. 20 ember és néhány nagy cég kezében fut össze a mainline kernel fejlesztése: http://lwn.net/Articles/237196/
Nekik azonban úgy tűnik, hogy megfelel a jelenlegi rendszer, de legalábbis "good enough", ők már befektettek a saját QA infrastruktúrájukba, és nincs arra üzleti igényük, hogy összefogjanak ezen a téren.
Elolvastam a threadet is, úgy tűnik egy magyar(?) kolléga indította. Megnyugodva láttam, hogy nem vesztek sokat azzal, hogy nem követem az LKML-t, és csak összefoglalókat olvasok. A sok-sok törzs-LKML-flamelő máris ráugrott a szokásos szövegekkel, amiket a nagy hackerektől lestek el. (Kedvencem a "miért vettél olyan HW-t aminek nincs nyílt drivere"...)
Hozzáteszem, hogy szerintem sem a "development" és a "stable" branch szétválasztása a megoldás, hanem a kemény mag minőség iránti igényének a növelése / megteremtése...
Üdv,
Gergely
- A hozzászóláshoz be kell jelentkezni
Milyen eszközök vannak közkézen, amik a miőség ellenörzést segítik ?
- A hozzászóláshoz be kell jelentkezni
gcc, make, reboot binárisok
- A hozzászóláshoz be kell jelentkezni
A teljesség igénye nélkül:
- statikus kódellenőrző eszközök
- automatizált teszt keretrendszerek
Ezekre mind vannak Linux specifikus eszközök, pl. LTP.
A probléma ott van, hogy nincsenek kellő fegyelemmel használva ezek az eszközök.
Mindenki, aki már dolgozott szoftverfejlesztésben tudja, hogy a tesztelésnek akkor van értelme, ha (a) állandó, (b) az eredmények nincsenek figyelmen kívül hagyva. Tehát a "known regressions" lista az közelíti a 0-át, sőt, bizonyos iskolák szerint minden release-nél 0-án kell állnia. Ha emlékszünk éppen most kellett "known regressions" karbantartó embert váltani, mivel az előzőnek elege lett abból, hogy senkit nem érdekel a munkája.
De a dolog ennél mélyebben gyökeredzik. Amig nem lehet egy (1) darab bug tracking rendszert bevezetni a mainline kernelre, amit minden fő fejlesztő elfogad, addig nem érdemes a fenti, jóval több önfegyelmet igénylő eszközök használatáról beszélni.
- A hozzászóláshoz be kell jelentkezni
a QA dologgal egyetértek, viszont a kernel annyira szerteágazó driver téren, hogy elképzelhetetlennek tartom hogy a szűk kernel-fejlesztői körben minden hardver meglegyen, így nem is nagyon tudják másképp letesztelni mint a patch-release-patch-release módszerrel.
--
hege
- A hozzászóláshoz be kell jelentkezni
Erre a megoldás rendkívül egyszerű: El kell készíteni egy olyan teszt menedzsment rendszert ami áll
(1) központi adatbázisból az eredményeknek
(2) build szerverekből amik kernel image-eket fordítanak megadott konfigurációkban
(2) egy bootolható CD-ből (illetve egyéb médiából) ami lehúzza és teszteli a különböző kerneleket.
Elég sok Linux szimpatizáns lenne hajlandó éjszakánként bebootolni ezt a CD-t, ami aztán automatikusan, a központ utasításai alapján lefuttatja a teszteket. Természetesen a rendszer fő bástyája nem a Linux wannabe Pistike lenne, hanem a hardver/szoftvergyártóknál futó tesztfarmok, amiket ezzel a rendszerrel minimális befektetéssel és költséggel tudnak üzemeltetni.
Persze egy ilyen rendszernek olyan elhanyagolható előnyei is lennének, mint pl. teljesítmény trend analízis: itt van egy új CPU scheduler, mi volna ha futtatnánk néhány tesztet mondjuk az összes szupportált architektúrán lehetőleg 10-20000 féle konfigurációban...és nem "érzésekre" meg "nekem az Y scheduler gyorsabbnak tűnikre" hagyatkozva döntenék el, hogy melyik a jobb.
A mighty kernel hackereknek akik pár nap alatt megírják a világ legjobb SCM rendszerét (http://www.youtube.com/watch?v=4XpnKHJAok8) egy ilyen rendszer összedobása sem tarthatna sokkal tovább...már ha érdekelné őket. Ez talán egy gonosz megjegyzés, de mint az előbbi videóból tudjuk, mindenki hülye, aki nem Gitet használ. Aki meg azt használja, az maga is egy *git* lesz? :)
- A hozzászóláshoz be kell jelentkezni
hi,
áldozati bárányok^W^W
óvatosabban gépelj:
United States Patent 4905007:
The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. A character input/pointing and positioning device for a computer, comprising: [...]
3. A character input device as defined in claim 1, wherein said selection recognition means is comprised of a plurality of switches.
[...]
The reduced base character sets are of such importance to the operation of the device that copies of character sets from base 2 to base 8, are contained in TABLES 1 through 7, respectively, which are annexed as a schedule to this specification in order to make a complete disclosure of the invention.
TABLE 1
23 ! 0!!! Ctrl W
CONTROL W 87 !0! 0!!!
- A hozzászóláshoz be kell jelentkezni
Tehát a Linux egyik leginkább csodált fejlesztője szerint incredibly hard az, amit az összes Linux disztribúció csinál: megpróbál egy adott kernelverzión maradni és azt patchelni a legújabb kernelekben megjelent hibák ellen.
Nem. Szerinte az uj driverek backportolasa incredibly hard, a disztrok altal is keszitett bugfixek nem.
- A hozzászóláshoz be kell jelentkezni
Ez a szál ey gondolatot érlelt meg bennem.
Nézzük a tényeket:
- a kernel 90%-ért fizetett, cég által szponzorált vagy nagy gyártónál dolgozó fejlesztő felel, fejleszti
- a fentieknek fogalmuk kell legyen a változáskezelésről, folyamatszervezésről, Q&A-ról
- a fentiek alapján a vanilla kernelnek betonstabilnak kellene lennie és teszteltnek
Kezdem megérteni Linus álláspontját és azt, hogy a cégeknek miért jó az, hogy a disztrók felelőssége stabilizálni.
A cégeknek azért jó, mert gyorsan kerülnek bele az újdonságok. Az újdonságokat sok ember használja, aki forgat nem mission critical helyen használja (remélhetőleg). Elég sok a visszajelzés, ők pedig a fontos újításokat, javításokat backportolják.
Ez jó a disztróknak, akik kereskednek a supporttal, mert van új featuréknak tesztje, fejlődik is a kernel, de ők tudnak egy stabil rendszert adni. Az Oracle és hasonló cégeknek jó, mert egy-egy kernel verzióhoz kell csak alkalmazkodni. RedHat EL, SLES, Ubuntu LTS(!nem félévente megjelenő), esetleg Debian utolsó stabil verzió, ha HP-ról beszélünk. Amit a disztrók nyújtanak, az olyan, mint a FreeBSD egysége. El lehetne érni azt a szintet, de az meg nem feltétlenül a kereskedelmi disztrók célja, hiszen, ha lenne egy stabil rendszer mindenkinek, akkor nagyobb lenne a konkurencia. Több disztró, akkor meg a nagy szoftvergyártóknak is esetleg több felé kell figyelni. Az meg nekik sem jó.
ÉS elérkeztünk ahhoz, hogy miért jó ez a FreeBSD és OpenBSD-nek. Sok új lehetőség és sok új driver megjelenik a linux kernelben, ami előtte nem volt elérhető, esetleg a fejlesztők, cégek rendelkeznek NDA-val, eszközzel stb. A forrás és a látott működés, hibák alapján a tapasztalt fejlesztő nem csak, hogy implementálni tudja, de esetleg jobb megoldást is tud adni a saját rendszerébe. jó példa, hogy mennyire gáz tud lenni linux alatt a kliens oldali wifi kapcsolat, ami freebsd alatt szebben van megoldva, akkor is, ha linux alatt több driver van vagy előbb jelenik meg a lehetőség.
Jó lenne felismerni az ekoszisztémát. ha nem lenne linux, akkor a freebsd sem tartana itt. nem csak a fentiek miatt, hanem például egészséges verseny, figyelem az oss felé stb. A cégek amennyit ártanak, annyit segítenek is. Az IBM, Intel, Oracle stb. nélkül nem tartana ott a linux és a többi oss rendszer (itt gondolok olyanokra is, mint az pl. IBM által is szabaddá tett forráskódok, pl. javadb és fejlesztők), de nem is jelent volna meg pár drótozott megoldás.
hát, röviden ennyi imho, ezért nincs külön fejlesztői ág.
- A hozzászóláshoz be kell jelentkezni
"- a kernel 90%-ért fizetett, cég által szponzorált vagy nagy gyártónál dolgozó fejlesztő felel, fejleszti"
Maradjuk inkább a "felel, tartja karban" mellett, mert a "fejleszti" az nem igaz. Sok-sok ember fejleszti (sokuk senki által nem fizetett) aki beönti a munkáját a tölcsérekbe (cégek által fizetett karbantartók), akik majd egyengetik a további sorsát a munkának.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Na melyik trollunk volt ?
2.6.16 -tól régebbi kernelre nincs közösségi support. :D (Legalábbis én nem supportálom)
Melyik NI -deviceot nem sikerült működésre bírnia a Power userünknek ?
Miért nem az NI -nak ír ? és Mondja el Hogy már 2.6.16 több, mint egy éve van, vagy ilyesmi.
- A hozzászóláshoz be kell jelentkezni
Ilyenkor mindig felmerül bennem a kérdés: hogy a francba lehetséges, hogy a Windows úgy képes egész használható lenni, hogy 2-3-5 évig lényegében azonos verzió az utolsó és nincs naponta új release?
Aki erre azt mondja, hogy egy mai gépre XP-t telepíteni elég szánalmas eredménnyel jár (szinte alig támogat valamit), az rossz helyen tapogatózik, mert míg a Windows telepítőjéből csak ritkán ad ki frissítést a Microsoft, addig ugyanezt egy Linux vendor megtehetné sűrűbben is, úgy, hogy a kernel verziója akár változatlan marad.
Aki meg azt mondja, hogy dehát a Windows szar, nem változik, a Linux meg mint a villám úgy fejlődik, azt sem tudom megérteni. Ha a Linux tényleg ilyen ütemben fejlődik, mára mindenben a legfejlettebbnek kellene lennie, sőt, olyan technológiákat kellene tartalmaznia, amik sehol máshol nem elérhetők, amiket ők találtak fel.
De ezt sem látom. Még mindig van értelme Windows vs Linux, vagy Solaris vs Linux benchmarkoknak, sőt néha még a dying BSD-k is odab...nak neki, ami ezután a "űrrepülő sebességgel fejlődik, míg a többiek még csak a kereket próbálják feltalálni" szöveg után kicsit érthetetlen.
Szóval akkor mi van?
A Linux fejlesztők összevissza kapkodnak, az este a kádban kitalált újdonság reggelre már benne van a kernelben, hogy aztán holnap kidobják (magyarul a Linux egy nagy kísérleti platform, változó eredményességgel)?
- A hozzászóláshoz be kell jelentkezni
Igazad van. Szar az egész. Szerintem hamarosan belátják a Linux kernel fejlesztői, hogy tévúton vannak, és elmennek fejleszteni valami mást.
Én tudod mit nem értek? Hogy akinek csak a problémája van vele, az mit kínozza magát vele? Elmegy a boltba, vesz magának egy Windows Server 2003-at, vagy letölti a FreeBSD 7-CURRENT-et (ZFS included), esetleg felbohóckodja az OpenSolaris-t, vagy vesz szupportot a Sun-tól és él boldogan :)
(A muszáj nem válasz. Ebben az életben semmit sem muszáj. Ha valaki annyira saját maga ellensége, hogy muszájból dolgozik egy olyan dologgal, amihez nincs kedve, az vagy a.) óriási nagy lúzer b.) mazopista)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
c.) megtévesztett áldozata a hypenak
Weee!
- A hozzászóláshoz be kell jelentkezni
Magyarul pancser?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A pancser ennél általánosabb. Rosszul informált, félretájékoztatott, megtévesztett.
Weee!
- A hozzászóláshoz be kell jelentkezni
Tegyük fel valaki bedől egy hype-nak.
Szerintem az, aki bedől egy hype-nak, és érzi, hogy valami nem jó neki, de mégse tesz ellene, az egy pancser. Ezt lehet szépíteni, de minek. Van választása. Nagyszerű operációs rendszerek érhetőek el. Vehet magának Windows-t, Mac OS X-et, ott vannak a Solaris-származékok, a BSD-k, ... Van itt kérem választási lehetőség.
Én például nem érzem, hogy azért használnék desktop-on Linux-ot, mert bedőltem volna bármilyen hype-nak is. De nem is sírok folyamatosan, mint a fürdősk..va.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Akkor ez a LKLM-es power user egy fürdősk..va? Meg is nézem, beletolták-e ugyanezt a választ az arcába. Mert megérdemli.
Weee!
- A hozzászóláshoz be kell jelentkezni
Az. Elmondták neki, hogy ott a hosszú karbantartású kernelsorozat. Lehet használni. Stabilitás!
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
In-
Weee!
- A hozzászóláshoz be kell jelentkezni
Tessék?
Egyébként kacagtam a p0w3r user-en:
"or if you just want the bits run stuff like Centos"
"PS: Centos ? WTF ?"
Most neki akarod elmagyarázni, hogy mit tehetne, ha stabilitást akarna? Fogalmatlan...
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Instabilnak kéne hívni és rögtön elmúlna a zavarodottság.
Ja, én is épp ott tartok.. :)
> Please consider that we are living in a REAL world, and not
> Disney-Land.
Well, I don't know about that so much; I've always thought Linus bears a
striking resemblance to Mickey Mouse.
---
No végülis elmagyarázták neki hogy ne akarjon fogalmi tisztázást. Ami régen volt fejlesztői azt most stabilnak hívják, ha "stabilt" akar akkor a 2.6.16-t kell keresnie ami longtimesupported. Vagy ha van pénze, vegyen supported linuxot. Vagy valamit félreértettem?
Weee!
- A hozzászóláshoz be kell jelentkezni
1. A kernel.org-os kernel nem neki (végfelhasználónak, power user-nek) jelenti, hogy "stable", hanem a disztribútoroknak. Azt jelenti, hogy a disztribútor az állandóan aktív fejlesztés egy olyan "snapshot"-ját kapja (az -rc-k után), amivel elkezdhet dolgozni. Nekiállhat becsiszolni a disztribúciójába. Soha senki sem reklámozta azt, hogy a kernel.org-os kernellel a végfelhasználónak bármit is kellene kezdenie.
2. Ha a végfelhasználónak stabilitás kell akkor több választása is van:
- pénzes disztrók (sok sok évnyi támogatás (RHEL, SLES, és ezek desktop cuccai)
- pénzes disztrók nem pénzes megfelelői (pl. CentOS - ami egy az egyben RHEL, csak eltávolították belőle brand infókat)
- nem pénzes disztrók, long term support-tal (pl. Ubuntu LTS - 3 / 5 év szupport, stabilitás)
3.) Ha ragaszkodik a stable API-hoz, de mégis kernel.org-os kernel kell neki, akkor Adrian Bunk féle "hosszú karbantartású vonal"
4.) Ha neki stabil API kell ___és egyben a bleeding edge funkciók is___, akkor fel kell valakit fogadnia, aki pénzért visszaportolja neki az új dolgokat egy pontra.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ezt remélem power user is olvasni fogja. :) Asszem itt merült ki a téma, de jól, mert van válasz, magyarázat, konklúzió.
Weee!
- A hozzászóláshoz be kell jelentkezni
Szerintem érik lassan valami változás, de majd meglátjuk.
Nem mondtam, hogy szar az egész, csupán azt fejtegettem, hogy a hozzánk hasonló viccrendszergazdáknak megfelelhet -és nekem néha úgy tűnik, hogy ehhez a mentalitáshoz igazodnak a fejlesztők is-, viszont egy bizonyos ponton túl gátja lehet a terjedésnek, fel kell nőnie az egésznek ahhoz, hogy komolyabban vegyék, hogy nagyobb legyen a támogatása.
- A hozzászóláshoz be kell jelentkezni
Két dolgot nem lehet egyszerre: "stabil kernelt" csinálni és ezzel egyidőben a latest hardverek széles skáláját is támogatni. Meg kell találni az egészséges egyensúlyt, ami nem egyszerű. Természetesen ez a kernel.org-os vanilla kernelre vonatkozik.
Sőt, továbbmegyek:
"Jót, olcsón, gyorsan. Ebből kettőt választhat."
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez hülyeség. A Windowsnak stabil kernele van és a latest hardverek széles skáláját támogatja.
A drivertámogatásnak koránt sem feltétele, hogy a kernel naponta változzon, sőt, inkább ellensége.
- A hozzászóláshoz be kell jelentkezni
Ja, hogy neked a "stabil" == "stabil API". Jól értem?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ebben a kontextusban igen, azt értettem alatta, hogy a kernel verziója változhat, de a tegnap használt drivert ma is fogom tudni használni.
De ha a működési biztonságot nézzük szerintem úgy is megállja a helyét. Nem hinném, hogy mondjuk a Windows 2003 magja kevésbé lenne megbízható, mint a Linux.
- A hozzászóláshoz be kell jelentkezni
A stabil API nonszensz, mondják a Linux kernel jelenlegi fejlesztői. Hogy miért? Az leírják a Linux/Documentation/stable_api_nonsense.txt-ben. Ezeket nem tudod elfogadni?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Jobb lenne ennél a masszánál egy egységes api. Más rendszerekben miért lehet? Mert ott terveznek, dokumentálnak.
Weee!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Amíg az NVIDIA akár kéthetente tud friss drivert kiadni a Linux kernelhez, addig a stabil API hiánya nem lehet kifogás. Ha valakinek a stabil API hiányzik, tegye a driver-ét a Linux kernelbe. Ha valakinek a változtatásai majd break-elik a driver-t, majd az fixálja, aki a problémát okozó változtást véghezvitte.
Ja, hogy egyes gyártók nem akarják kiadni a driver-ek forrását? Az nem a kernelfejlesztők hibája.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Azt nem lehet elfogadni (azért, hogy tudjuk javítani, amit elrontottuk, meg különben is add ki a forrást GPL alatt).
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Nem kötelező. Se állandóan sírni sem. Az NVIDIA nem sír. Frissíti a driver-eit. Akár egy hónapban kétszer is. Érdekes neki megy.
Amúgy megnéztem egyszer, hogy milyen borzasztóan nagy változtatásokat kell ilyenkor elkövetniük a GPL-es glue kódon (ugye az érdemi bináris rész, az nagyrészt platformfüggetlen valami, nem nagyon kell ilyenkor piszkálni - "NVIDIA's drivers for all the supported OS's consist of about 95% platform independent code (the actual driver), and 5% platform dependent code (OS bindings, etc.)."). Borzasztóan kemény 2-3 soros diff-ek ezek. Nos, 2-3 havonta jön ki egy új Linux kernel. Ez bizony nagyon kemény meló.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nezd meg ugyanakkor az ATI-t, ok bizony kemenyen dolgoznak, es minden verzional meggyozodnek rola, hogy a driveruk mukodik a kb haromnegyed evvel ezelotti kernelekkel! :D
- A hozzászóláshoz be kell jelentkezni
Oké, de a AMD/ATI fejlesztői impotenciáját ne varrjuk már a Linux kernel fejlesztőinek nyakába. Ahogy kijön egy új kernel, amin mondjuk nem perdül el az ATI driver, egyes online fórumokon szinte azonnal megjelennek (sőt már az -rc szakaszban) azok az 1-2 soros patch-ek, amelyek ahhoz kellenek, hogy az új ATI driver lepörögjön. Ez azt jelenti, hogy kb. öt perc meló kellene ahhoz (jelzem, mindez egy külsősnek, aki nem láthat annyira bele, mint a fejlesztők), amit az ATI fejlesztőknek sok-sok hónap alatt sikerül elérniük. Egyébként az a rotfl, egyes fórumokon és az ATI bugtracker-jében is rendre ott vannak a patch-ek, amit az ATI fejlesztőknek csak be kellene emelniük (na jó, meg tesztelniük), de nem. Sok hónappal később az ember még azon bosszankodik, hogy nem tették meg.
Mondjuk amióta disztró kernelt használok, azóta ezt a bosszúskodást elvégzik helyettem gondolom az Ubuntu csomagkészítői :))
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Elfogadni éppen el tudom, viszont ha elolvasom nekem az jön le, hogy a Linuxot tanuló programozók írják, akik trial and error elven fejlesztik a kernelt, minimális, vagy nulla tervezéssel, ad hoc módon.
Megírnak valamit, rosszul működik, ebből tanulnak, faragnak rajta, majd mikor már rájöttek, hogy használhatatlan megoldást írtak, kidobják az egészet és újraírják, amely újraírásnak persze ugyanaz lesz a sorsa.
A helyzetet rontja, hogy adott esetben több párhuzamosan versengő megoldás is van.
Engem ez gyártóként elriasztana.
- A hozzászóláshoz be kell jelentkezni
"Elfogadni éppen el tudom, viszont ha elolvasom nekem az jön le, hogy a Linuxot tanuló programozók írják"
Illetve, korlátozott hardverkészlettel rendelkező fejlesztők, akiknek sok esetben pénzük és lehetőségük sincs kipróbálni a kódot. Marad a kipróbáltatás mással.
"Engem ez gyártóként elriasztana."
Mint említettem, a választás mindenki előtt ott van.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"Simple, get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here,
if your code doesn't fall under this category, good luck, you are on your own here, you leech...) If your driver is
in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place."
Példa: az egyik kernelfejlesztő megmódosítja az egyik függvényt, mert hogy neki valahol kell még egy paraméter... és persze sorra minden érdekelt drivert megpatchelnek.
De ugye, arra már nincs idő, hogy minden anyámtyúkja drivert újrateszteljenek, tehát kiadják a rc-t, teszteljék a felhasználók. De a normál felhasználók nagy többsége nem fog bugreportot küldeni, csak elkönyveli, hogy na megint nem megy az XXX driver.
Nagyon értékelendő, hogy átveszik az illető driver fenntartását, ha az bekerül a main kernel tree-be. De szerintem ez az egyik oka annak, hogy az egész linux kernel is 'getting buggier'.
Tehát, félreértés ne essék: egyetértek azzal, hogy a stabil API nonszensz, de hozzátenném, a stabil API-ra való törekedésnek igenis van értelme.
Ez a probléma komplex. Windows alatt sem könnyű fenntartani egy drivert. Anno volt egy ilyen driver projektem, egy kártyához drivert kellett írni, meg is volt, wdm driver lett belőle (ami ugye arra volt csinálva, hogy ne kelljen teljesen más drivert írni 98-ra és nt-re). A "stabil"-nak mondható api önmagában nem ér egy zseb sz..-rt, mert ugyanaz a kernel függvény másképp viselkedik win98 alatt mint 2k alatt, netalán xp alatt, tehát agyon kell tesztelni így is, úgy is mindenféle platformon. (Legutóbb meg szóltak, hogy 64 bites XP-vel vannak valami gondok).
Na jó, hogy 98 manapság kiütve, de akkor még fontos volt.
A másik hátulütője a 2.6-os kernel vonalnak, hogy ha pl. csak kismennyiségben gyártok valami spécibb hardvert, ami nem annyira nyilvános felhasználású, akkor azt nem fogják belerakni a kernel main tree-be. Akkor viszont rá vagyok kényszerülve, hogy magam fenntartsam a driveremet, mert a kedves kliensemnek épp az a tikkje, hogy a legújabb ubuntut használja.
- A hozzászóláshoz be kell jelentkezni
Azt hiszem turul már leírta: a fejlesztőknek nincs meg minden hardver. Ellenben ha a drivert nyílt forrásúvá teszed ÉS bekerül a kernelbe, utána -ezt gkh is megerősítette- már nem lesznek problémák.
Ez a kettő együtt azt jelenti, hogy a srácok annyira jók, hogy egy compile teszttel meg tudnak győződni a driver működéséről.
Konkrétan a FreeBSD-nél is lehet ilyen commit logokat látni: módosítottam, átírtam minden driverben, lefordul, de fogalmam sincs, hogy jól működik-e, kérlek tesztelje, aki tudja. Ott azért ez annyira nem gyakori (de azért nem is ritka), viszont nem egyszer előfordult már, hogy pár órára rá jött a következő commit, miszerint xyz reportolta, hogy bár fordul, de mégsem jól működik, így javította.
És a következtetés (mielőtt más vonná le helyettem): a FreeBSD fejlesztők bénák (Linus nem írt ilyet?), a linuxosok meg istenkirálycsávók, mert annak ellenére, hogy ott sokkal több hardver és platform támogatott, mégis mindig hibátlanul abszolválják a feladatot.
Na erről ennyit.
- A hozzászóláshoz be kell jelentkezni
Persze ennek a széles skálának a támogatásához az OS gyártójának nem feltétlen van köze, mert a driver-eket az eszközök gyártói írják. Olyat, amilyet. Én pl. ezért nem tekintem a Windows-t stabil operációs rendszernek.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
A két véglet között (mindent a (hardver)gyártó csinál és már a hardvert sem egy gyártó állítja elő, ahogy a szoftvert sem) azért széles a skála.
Nyilván ha egy kézben van minden, könnyebb jót csinálni, bár ma már szerintem nem létezik olyan vas, ahol ez teljesülne.
Még az is lehet, hogy sosem létezett.
- A hozzászóláshoz be kell jelentkezni
Talán ezért van az, hogy az igazán stabil és megbízható operációs rendszerek csak meghatározott hw platformon érhetőek el.
Nem értem, hova lett az a fejlesztési model, amit a DEC a VAX-ok és a VMS kifejlesztésekor követett. Miszerint a vasat és a operációs rendszert egyszerre, egymásra figyelve fejlesztették. Így az oprendszer és a számítógép egymást segítve működtek. Persze, ez nem volt "iparági standard" de legalább működött.
Most a sok "open" meg mifaszom csak az instabilitást hozta magával meg nyilván egy kis látszólagos szabadságot.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ez valahol egyértelmű. Ha kiszámítható működést akarsz, még a HDD firmware-e is számít.
Én egyébként nem feltétlen tartom jónak ezt az elképzelést. Mivel a végén nekem kell fizetnem, szerintem jobb, ha az alkalmazást készítik fel arra, hogy egy megbízhatatlanabb platformon is megbízhatóan működjön.
- A hozzászóláshoz be kell jelentkezni
Hogy hová lett? Fölzabálta a piac, mert életképtelen volt.
Bocsánat, pontosabban a VAX-ot maga a DEC állította le és kihozta helyette az Alphát, mert rájöttek ugye, hogy az előbbi teljesítmény szempontjából zsákutca.
--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.
- A hozzászóláshoz be kell jelentkezni
Ellenben én pl örülök annak, hogy nem 5 év múlva egy következő nagy kiadásba kerül bele a dynticks meg hasonlók...
Software is like sex, it's better with a penguin. :D (r)(tm)(c)
- A hozzászóláshoz be kell jelentkezni
OK, desktopon nyilván lehet értelme, ott legfeljebb lerohad, vagy hibás lesz a keménypornó .avi gyűjteményed. Senkit nem izgat.
Én inkább a szerveroldalon gondolkoztam, ott sem a legalján, hanem azokon a területeken, ahol a Linuxról ma még hallani sem akarnak.
- A hozzászóláshoz be kell jelentkezni
A levél írója, valami NI cumót említett, ami méréstechnikai cumó, gondolom LabView -ben programozgat.
"Also, the 7 National Instruments cards I'm using for a
deformable mirror in Adaptive Optics in an industrial PC
are "certified" for SuSE 9.3 only."
- A hozzászóláshoz be kell jelentkezni
Nem olvastam el a levelezést, csak a fenti hírt.
De akkor ezekszerint valami hasonlót ugatunk. (nem, nem én írtam a levelet)
- A hozzászóláshoz be kell jelentkezni
A NI-rol nem iagzan szeretnek nyilatkozni. Amit ok win-re is elkovetnek un driver cimszo alatt az a lelek megkisertese... Az egesz igazabol borzadaly. Hal istennek nem kell veluk fejlesztenem ambator a szoftvereiket/drivereiket igen gyakran muszalybol installalom. Nem egyszer a win teljes ujrahuzasa utan eledtek fel az eszkozok. Arrol nem is beszelve hogy a "jol dokumentalt" driverek (adtak hozza 4 darabot de hogy mi melyik vagy minek halal f@..a se tudja) neha a tamogatott kornyezetben sem mukodnek rendesen. Komolyan sajnalom azt az embert aki ilyen eszkozzel fejlesztett autoalkatreszt vasarol...
- A hozzászóláshoz be kell jelentkezni
A hardvergyátók (tisztelet kivételnek) Windowshoz "igazítják" a hardverüket, nem a Windowst igazítják a hardverekhez.
- A hozzászóláshoz be kell jelentkezni
A mondat másik fele az esetek nagy részében igaz lehet, bár azért tudnék ellenpéldát hozni (például úgy tudom, hogy a Microsoft több módosítása is a Unisys ES7000-es gépéhez kötődik, ahol tehát a Windowst igazították a hardverhez, de nyilván nem egyedi a példa).
Viszont kíváncsi lennék, hogy a mondat elejére milyen bizonyítékod van. (remélem itt nem a videókártyákra gondolsz)
Mit jelent az, hogy a hardvergyártók többsége (a fentiből nekem ez jött le) a Windowshoz igazítja az általa gyártott terméket?
- A hozzászóláshoz be kell jelentkezni
Sztem nem konkrétan a videokártya, hangkártya, alaplap gyártókra gondolt, hanem a szerver összeállítókra. Valóban van egy enyhe tendencia arra ,hogy a hardver kevés olyan elemet tartalmazzon, amihez third-party driver kell. Nem mondom, hogy ez a tendencia minden körülmények között tetten érhető, de létezik.
- A hozzászóláshoz be kell jelentkezni
Ő azt mondta, hogy a hardvergyártók a Windowshoz igazítják a termékeiket.
Én azt mondom, hogy nekem inkább úgy tűnik, hogy a hardvergyártók kb. olyanok, mint a Linux fejlesztők: ész nélkül haladnak előre, aztán a szoftver (user) meg kövesse őket.
Nem látom, hogy fordított lenne a dolog, azaz a Microsoft megcsinál valamit és a hardvergyártók teljes egyetértésben bevezetik, használják azt.
Nem a hardver fut a szoftveren, hanem fordítva.
- A hozzászóláshoz be kell jelentkezni
Xy kínai gyártó csinál egy mp3 lejátszót. Összehányja a sarokban talált alkatrészekből a prototípust. Teszt Windows alatt. Nem működik. Addig reszelik, amíg vhogy fel nem ismeri az a szerncsétlen Windows pendriveként. Örülnek. Mehet a gyártósorra. Így készülnek az ilyen eszközök.
- A hozzászóláshoz be kell jelentkezni
Értem. És ebből általánosítottál a gyártók nagy többségére.
Azaz pld. szerinted az EMC úgy gyárt Symmetrixet, hogy megcsinálja, kipróbálja Windows alatt, ha nem megy, addig reszeli, amíg fel nem ismeri SCSI diszkként. Örül, megy a gyártósorra.
Nem is úgy, hogy implementálják a szabványt, rádugják a pár tízmillióba kerülő protokolltesztert és végigjáratják az egész stacket, aztán és csak aztán küldik Kínába gyártani. (figyelem: a tervezés nem ott történt! :)
- A hozzászóláshoz be kell jelentkezni
Azaz pld. szerinted az EMC úgy gyárt Symmetrixet, hogy megcsinálja, kipróbálja Windows alatt, ha nem megy, addig reszeli, amíg fel nem ismeri SCSI diszkként. Örül, megy a gyártósorra.
Néha bizony van ilyen érzésem. ;-)
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Mit mondjak, nekem is (bár nem éppen Symmetrix-szel), de ettől még tudom, hogy első körben nem Windowson próbálják ki (najó, második körben lehet :).
- A hozzászóláshoz be kell jelentkezni
Jól sejtem, hogy ezekkel a hardverekkel* nincs is gond linux alatt?;)
* az általad leírt módon tervezett
- A hozzászóláshoz be kell jelentkezni
Van olyan marha, aki egy ilyen storage-re linux-os gépet kapcsol?
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Öööö. Nem, rosszul sejted.
http://www.suse.de/~garloff/linux/scsi-scan/scsi-scan-blist-update
Mint sok más helyen, természetesen itt is csak nyűglődnek az interoperábilitás nevű varázslat megidézésével, néha több, máskor kevesebb sikerrel.
- A hozzászóláshoz be kell jelentkezni
Akkor most valaki rosszul implementált szabványt:) Kicsoda?
- A hozzászóláshoz be kell jelentkezni
Az, hogy ilyen kivételeket kell betenni, nem biztos, hogy azt jelenti, hogy elkefélte a gyártó a terméket. Lehet az is, hogy a Linux egy konzervatívabb megoldást választott, ami szerintük több esetben eredményes, mint nem és a kisebbségnél teszt különbséget.
Ezek tipikusan ilyennek tűnnek, a nagyobb storage-okra jellemző paraméterek, amik nyilván a Linuxnál később jelentek meg, mint az ultra low end gagyi szar, amihez eredetileg """tervezték""" a SCSI rendszerüket.
- A hozzászóláshoz be kell jelentkezni
Első feléhez:
De Windows alatt ilyen blacklist elképzelhetetlen. Nem azért mert a Windows tökéletesen implementál mindent. Egyszerűen nem kerülhet gyártásba olyan hardver, amit az aktuális Windows nem támogat. Itt kerül a hátrányba a linux, itt jönnek be az ilyen gyönyörű blacklistek, erre akartam rámutatni.
Második felét sajnos nem értem, de sztem ez az én szakmai hiányosságom.:(
- A hozzászóláshoz be kell jelentkezni
De Windows alatt ilyen blacklist elképzelhetetlen.
WHQL az kutyaf*sza?
Egyszerűen nem kerülhet gyártásba olyan hardver, amit az aktuális Windows nem támogat.
Nem, csak XP-n érdekes múdon 7-8 éves driverek is simán mennek, nem kell havontakétdzsíforszdrájver(TM).
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
"havontakétdzsíforszdrájver(TM)"
Windows-ra is havonta jönnek a dzsíforszdriverek. Ha másért nem, azért, mert megjelenik bennük az új chip-ek támogatása és a bugfixek. A "nagy változtatásokról", ami az Linux API change miatt kellhet 2-4 havonta (kb. ennyi idő alatt jön ki egy új kernel, de akkor sem biztos, hogy van olyan változás benne, amit le kéne követni) fentebb értekeztem. 1-2 soros patch-ek (általában átnevezett függvénynevek lekövetése).
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ennel mokasabb a dolog - a drivereket patchelik, hogy a userspace alkalmazasok mukodjenek. Hint: erdemes a driver changelogjat megnezni ;-)
- A hozzászóláshoz be kell jelentkezni
"általában átnevezett függvénynevek lekövetése"
Teszem hozzá, olyan függvényeké, amelyek a Documentation/feature-removal-schedule.txt-ben évek óta szerepelnek/szerepeltek. Azaz, a vendor-nak évek állnak rendelkezésre az API változtatás előtt, hogy lekövessék azokat. Volt olyan változtatás, ami 2 éves bejegyzés volt ebben a file-ban. Mikor bekövetkezett, az ATI még nem volt képes lekövetni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
WHQL az kutyaf*sza?
Ha ezt komolyan vennék, akkor jó lenne.
Kár hogy az első-második generációs windows pista ati, nvidia driverek is megkapták a minősítést. userek meg anyáztak javában... (joggal).
/ azért mondtam a windows pistát, hogy ne lehessen azzal vádolni, hogy mindig csak régi "rém"történetekkel állok elő /
csak XP-n érdekes múdon 7-8 éves driverek is simán mennek
Mutass nekem 7-8 éves Windows XP drivert. Ami WHQL-es mondjuk. XP ugye 2001ben jelent meg. Ma 2007.06 van. Tehát olyan WinXP-s drivert mutass ami mondjuk 1999.07-2000.06 között jelent meg. köszi. :-)
------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Jogos, 6-7 akart lenni, csak mindig keverem a 2k-t (1999) meg az XP-t (2001). Akkor már ha itt vagyok, a korrigált állításomat alá is támasztom (bár szerintem 2k-s driverek elvileg akár mehetnének is XP alatt): Detonator 29.90 megy XP SP2-n 2007 június végén, és 5 éves.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
bár szerintem 2k-s driverek elvileg akár mehetnének is XP alatt
próbáld ki. mondjuk kezdetnek az alaplapi driverekkel.. ;-)
http://archive.debian.org/debian-archive/pool/contrib/n/nvidia-glx-src/…
Szerintem meg ez az 5 éves driver is menne mondjuk "debian sarge" alatt 2.4.27es kernellel. ami még ugye supportált. :-)
-----------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Jah, de kérdés az, hogy az a 2.4.27-es kernel támogat-e egy mai gépet normálisan.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
A "problémád" túlkoros gépekre vonatkozott, ha jól értettem, nem pedig mai motyókra.
Most döntsd el a linuxot mire telepíted fel... ;-)
A túlkoros gépedre a 2.4.27es mondjuk / 2.4.3x , a maira meg 2.6.16, vagy egy disztró kernele.
Szerencsére nem kell leragadni egyetlen bebetonozott kernelnél mint az MS féle rendszereknél.
Azt kell kiválasztani ami az adott HW-re a legmegfelelőbb (ez nem feltétlenül a legújabb kernel).
Ha már egyszer van bőségesen választási lehetőség ahány disztró annyiféle 2.6os kernel, ill. a 2.4es fa, akkor ezt ki kell használni szerintem. Meg kell találni az adott HW-re a legmegfelelőbbet. A vanilla 2.6ot szándékosan nem említettem . :)
---------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Már miért lenne elképzelhetetlen? Hidd el ott is megvan ugyanez.
Azért lősz mellé, mert a Microsoft NEM akar minden hardvert támogatni. Ők adnak egy interfészt, ami ahhoz kell, hogy te drivert tudj írni és kész.
A gyártók megírják a drivert.
Na ez hiányzik a Linuxból, mert míg Windowsnál jó esetben 2000-től felfelé mindenen működik valami, addig Linuxnál már a minor verzió is számít egy stabil kernelszériában.
Erre mondják, hogy szopjon az a gyártó, aki nem akar forráskódot kiadni, viszont szerintem akkor is szopás van, ha kiadja a forráskódot, csak ezesetben a user szopja be, nem a gyártó.
Tfh, a gyártó kiadja a drivert, ami valami csoda folytán átmegy a Linux high quality standardokra épülő elfogadási rendszerén és bekerül a kernelbe. Mondjuk a 2.6.10-be.
Ezután jön az északamerikai linugz vendor, fogja a 2.6.10-et és kiad vele egy OS-t.
Eközben már 2.6.22-nél tartunk, tehát a driver kb. köszönőviszonyban sincs a 2.6.10-essel, mert közben a nagytapasztalatú kernelfejlesztők rájöttek (nem kevesebb, mint kétszer), hogy az adott terület úgy szar ahogy van és átírták az egészet.
Más lett az API, hogy divatos legyek.
Persze közben a driver írója is fejlesztett, amely fejlesztései bekerültek a kernelbe.
Na és ezen a ponton van:
- egy user (te), akinek van egy 2.6.10-es kernele, amibe vagy visszaerőszakolja a Linux vendor a driver módosításait, vagy nem. Inkább nem, csak ha nagyon kritikus és sokan anyáznak már miatta.
- van egy driver, amelynek szinte mindegyik kernelhez készült verziója inkompatibilis az előtte és az utána jövővel
- van egy gyártó, aki azt mondja: anyátok picsája, én kiadtam a forrást, folyamatosan karbantartom, követem a kernel napi szintű változásait, még tartsam karban a 2.6.10-est (nem a vanillát, hanem azt, amit az északamerikai linugz vendor csinált belőle), a 2.6.14-est (illetve azt, amit egy másik északamerikai csinált belőle), a 2.6.4-est (mert a Debian stable-ben ez van), és így tovább
A vége az lesz, hogy te, mint user szembesülsz egy komoly problémával:
van egy fontos rendszered, amiben ismert és már javított hibák vannak. Ezeket a javításokat a vendor nem igazán tudja áttenni a te kerneledbe, mert azzal lényegében azt kellene csinálnia, hogy egyre nagyobb részeket kell átemelnie az OS-ében lévő 2.6.10-be az épp aktuális 2.6.14-ből, amiben x hiba javításra került (de közben átdesignolták az API-t), aztán két hónap múlva a 2.6.16-ból, amiben y hibát javítottak, de azt megint nem lehet önmagában átemelni, mert -vigyázat, szintén divatos szót fogok használni, bár ilyen környezetben ritkán használják- a függőségei túl szerteágazóak a kernelben.
Trey erre azt mondja, hogy ez a vendor hibája, ha már egyszer "eladott" neked egy OS-t, akkor annak a supportjáról gondoskodjon úgy, hogy ezeket a hibákat elhárítsa.
Én meg azt mondom, hogy ha ezt megteszi (amihez gyakorlatilag olyan szakembereket kell foglalkoztatnia, akik adott esetben még szakmailag magasabb színvonalon állnak, mint a kernel fejlesztői, hiszen a taknyot könnyű felkenni a falra, de abból festményt varázsolni nehezebb), olyan frankeinstein kernelek születnek, amikben a végén lehet, hogy olyan hibák jönnek létre, amelyek sem az eredeti (vanilla) kernelben, sem az adott javítás miatt visszaportolt részben nincsenek meg.
A kernel egyik vendor tulajdonában sincs, mindegyik csak egy fejlesztői snapshotból dolgozik, azt gányolja tovább, hogy két év múlva egy újabb fejlesztői snapshottal kezdhesse újra.
- A hozzászóláshoz be kell jelentkezni
Elég jól leírtad a probléma lényegét, ha valaki ez alapján se érti meg, akkor szerintem nem kell tovább erőltetni... :)
- A hozzászóláshoz be kell jelentkezni
Van olyan EMC termek amin win fut, no comment.
- A hozzászóláshoz be kell jelentkezni
És olyan is, amin Linux.
Mit bizonyít ez? Ők is inkább megveszik a low end, midrange-ben, mintsem sajátot írjanak?
- A hozzászóláshoz be kell jelentkezni
En azt latom, hogy a Linux (es akik ezt akarjak tolni, most lehet egy ceg is) manapsag azzal akarja eladni magat, hogy "bleeding edge", mindig uj jon ki stb. Mert ha nem igy lenne, miert nem lehetne megartani egy adott pl 2.6.16-ot kernelnek, es csak security fix, max _igazan_ fontos feature backport stb. En azt latom, hogy az a szellemiseg van itt, ami amugy persze eddig is jellemzo volt: dinamikus fejlodes, mindig mutassunk ujat. A problema az, hogy a Linux kezdi (kezdi?) elerni a kritikus hatart Enterprise teren is, ahol mar lehet kicsit mas gondolkozas (is?) kene nem feltetlen csak ez a filozofia. Ez nehez kerdes, foleg ugye, mivel ez nem fetletlen full technikai problema mar, hanem filozofiai, szervezeselmeleti stb stb stb stb. Eddig a Linux alapvetoen mint 'technikai' kihivas volt jelen (ugye eleve Linus azert kezdte el fejleszteni a Linux kernelt, sok ember azert kapcsolodott be a fejlesztesbe, azert terjedt elsosorban egyetemeken regebben csak, stb stb), az uzeleti kihivas egy viszonylag ujabb problema, de ez amugy nem csak itt jelentkezik: itt vannak a jogi oldalrol torteno tamadasok is, lasd ez a patent cirkusz, SCO, miegymas. Szoval az 'Enterprise' elet minden oldalarol razudult a cuccra a sok problema, nem csodalom hogy nehez ehhez hirtelen alkalmazkodni, foleg ha arra gondolunk hogy egy open source modelnel ez bonyolutabb is, mintha pl az MS-nel azt mondja vki "na akkor ez igy lesz mert en vagyok a fonok".
- A hozzászóláshoz be kell jelentkezni
BTW, csak egy dolog ehhez: ez a kritikus hatar latszik pl ott is, hogy mondjuk MS reszerol ment eddig a FUD stb, de ha megnezzuk egyre tobbszor latni hogy mar nem egyszeru 'o vacak hobby OS, ezt senki nem gondolja komolyan' a mondas, hanem komolyan veszik. Marpedig lehet szidni MS-t stb, de uzlethez megis van erzekuk kulonben nem itt tartananak, szerintem ezt senki nem vitatja :)
- A hozzászóláshoz be kell jelentkezni
"Mert ha nem igy lenne, miert nem lehetne megartani egy adott pl 2.6.16-ot kernelnek, es csak security fix, max _igazan_ fontos feature backport stb."
Elnézést kérek, de ilyen van jelenleg is. Adrian Bunk pontosan a 2.6.16 kernel alapján hozott létre egy "hosszú karbantartású" kernelfát. A mai napig "üzemel". Lehet használni. Csak tudod mi a probléma? Hogy Wannabe Pistike ezt használva megkérdi, hogy "jááááj, de hát a zsír új áláplápom mír nincs támogatva?"
Ja, erre mondtam, hogy "stabil"-t is, meg bleeding edge-t is egyszerre ne akarjunk már. Nem igazán fog menni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Akkor most a Wannabe Pistikékhez igazodik a kernelfejlesztés?
Weee!
- A hozzászóláshoz be kell jelentkezni
esetleg nezd meg a stable/linux-2.6.16.y.gitbe meg a torvalds/linux-2.6.gitbe mennyi patch kerul be naponta :)
- A hozzászóláshoz be kell jelentkezni
wrong.
aki stabilitást szeretne supportolt hardveren annak ott az enterprise disztró. ha nem fizet ki disztróért pénzt, ott a vanilla-2.6.16.y ami security-fixeket fogad még jó sokáig (már több mint egy éve támogatják). aki még ennél is konzervatívabb, azoknak ott a 2.4.x, azt is támogatják még.
aki otthoni felhasználásra szeretne linuxot új hardveren annak ott a 2.6.sok, ez megpróbál bleeding edge lenni, többé-kevésbé stabilan.
mindkét megközelítéshez megpróbálnak igazodni.
Csak hogy érthetően fogalmazzak: ha nincs a sok wannabe pistike meg nincs a sok -rc kernelt tesztelő ráérő geek, akkor soha a büdös életben nem lesz új driver stabil a kernelben, nem lesz új ütemező, de nem lett volna usb stack újraírás sem.
--
hege
- A hozzászóláshoz be kell jelentkezni
ja és még annyit, hogy ha a 'szar a kernel' -mondások legalább az 5%-a normális bugreportban manifesztálódna, már sokkal-sokkal előrébb tartana a fejlesztés minőség terén.
--
hege
- A hozzászóláshoz be kell jelentkezni
jó jó csak fogalomzavar van akkor. Ami régen test volt azt most stabilnak hívják. Már csak egy "in-" előtagot kéne beszúrni és mindenki értené.
Weee!
- A hozzászóláshoz be kell jelentkezni
Zavar az maximum nálad lehet. Vannak, akik levágják, hogy miről van szó. Egyébként ha angol, akkor az "in" helyett egy "un" jobb lenne.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
-
Az un-t inkább a szimpatikus elé gondolom ezentúl veled kapcsolatban.
Weee!
- A hozzászóláshoz be kell jelentkezni
Nem nálam volt a zavar hanem a power usernél. Fogalmi. Ha nálam volt is zavar, csak addig míg rá nem jöttem mit akar Hubert Zoltán, mondjuk teljesen logikusan.
(Ha már lehet finomítani, követem azért a lelkiállapotom változását az írásban is.. Ha nem lehetne, talán megfontoltabb lennék.)
Weee!
- A hozzászóláshoz be kell jelentkezni
És ha angol, akkor nem stabil, hanem stable. ;-)
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Mindegy, farkas és a bárány effektus.
Weee!
- A hozzászóláshoz be kell jelentkezni
akár. de aki kernel.org -ról töltöget kerneleket az szerintem tudja hogy mire számíthat. a disztribúciók általában jelölik hogy szerintük melyik a stabil, és ami náluk stabilra van jelölve az valószínű hogy a legtöbb hardveren stabil. aztán hogy "dióbélcsákányos" gentoo karbantartókban bízol-e jobban vagy novelles vagy piroskalapos inges-nyakkendős karbantartókban, az rajtad áll.
--
hege
- A hozzászóláshoz be kell jelentkezni
Így van. A kernel.org-os vanilla kernel nem a végfelhasználónak szól. Ezt kéne tudatosítani jobban.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egyet ertek. Es ne sirjanak az 'enterprise distro' keszitok (nemreg volt vmi ilyen) hogy jajj, de igy milyen nehez dolguk van, mas closed source modelnel meg ugye MINDENT nekik kene megcsinalni (kvazi. vagy megvenni) ;-)
- A hozzászóláshoz be kell jelentkezni
Miért is? Szerinted az MS minden egyes hw drivert lát?
Nem mindenhol divat a legyen monolitikus nagy massza az egész (jó, tudom, linux is hibrid kernel), amibe csak úgy lehet belerakni egy új drivert, hogy 3x újrafordítjuk.
Simán megoldható lenne, hogy a kernelből kiszednék az összes drivert és mindegyiket külön modulként töltse be. Viszont ezeknek a moduloknak biztosítva lenne egy egységes interface, ami nem változna (vagy nem túl gyakran, mondjuk 1-2 évente).
Csak persze ehhez át kellene gondolni a fél kernelt, hogy ez kivitelezhető legyen így ilyen formában. Jahogy, akkor sok lenne a bináris driver. Ha ez az ára a linux terjedésének, akkor szerintem legyen.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
At kene gondolni az lehet teny, mert sokan hibasan azt gondoljak hogy van barmi ABI/API modulok fele. Oke, persze valami van, de messze nem arra valo mint sokan hiszik. Valojaban a kernel modulok celja az volt 2.0.0 stable megjelenesekor, hogy ne kelljen fixen kernelbe forditani mindent pl disztroknal, hanem lehessen modulba, azt csak akkor betolteni ha kell. Mint mutatja ez a leiras is, annak ellenere a modul valojaban a kernel resze, a betoltse egyfajta (runtime) linkelesi folyamat, nem pedig arra keszult hogy 3rd party cuccok legyenek igy hozzakapcsolva, ez mar a dolgok megeroszakolasa. Persze azt lehet (akar jogosan is!) mondani, hogy ez szar, de akkor eleve mas utat kene valasztani es nem azert sirni hogy a _jelenlegi_ modul API miert valtozik, hiszen annal mindegy ha valtozik, nem arra van kitalalva amire hasznalni akarjak.
Ebben igazad lehet, hogy at kene gondolni, hogy akkor ugy csinalni, hogy az jo legyen valakinek pl. Hiszen az open source, Linux eseteben "legyen minden GPL" elvbe belefer hogy ugyis kernel resze minden, minek ilyesmi. Csak itt megint jon hogy az Enterprise <-> eddigi dolgok ellentet.
Amugy en meg nem hiszek benne hogy MINDENARON kell terjeszteni a Linuxot ("Jahogy, akkor sok lenne a bináris driver. Ha ez az ára a linux terjedésének, akkor szerintem legyen"). Szerintem aki nem akarja, ne hasznalja, inkabb minthogy emiatt teljesen elkorocsodjon az egesz. A lenyeg a valasztas szabadsaga ne probaljuk mar eroszakkal atalakitani. Akinek nem tetszik hasznaljon mast, vagy csinaljon mast stb, de ne sirjon hogy jajj ez szar, az szar ...
- A hozzászóláshoz be kell jelentkezni
Igen, azt tudom, hogy a linux kernelmodulok nem egyenlőek, pl a Windowsos driverekkel és mint írtad, sokszor nem arra használják, amire kitalálták. Akkor ezzel az erővel készíthetnének egy ilyen réteget is.
"Amugy en meg nem hiszek benne hogy MINDENARON kell terjeszteni a Linuxot"
Jó, te nem. Én sem. De vannak sokan, akik azt szeretnék, hogy mindenhol egy pingvin köszönjön vissza. Részemről viszont szimplán beérném, hogy ha veszek egy hw-t, ne kelljen azzal szopnom, hogy most megy-e rajta x/y, vagy sem.
"elvbe belefer hogy ugyis kernel resze minden"
Szvsz egy ilyet meg lehetne írni úgy is, hogy a driver részben lévő kernelmodul mondjuk LGPL legyen és akkor nem sért GPL-t, ha valaki nem akarja kiadni a forrást. Más kérdés, hogy pl RMS álmában a closed-source csak rémálom.
Egy ilyen egységes driver rétegből nem csak a linux profitálhatna. Ld. Haiku-OS. A hálózati drivereknél készítettek egy FreeBSD kompatibilitási réteget (nagyon helyesen), így szinte módosítás nélkül menni fognak a FreeBSD-s driverek.
Ugyanígy meg lehetne oldani egy egységes driver-réteget, aztán egyszerűbb lenne a végfelhasználóknak is és a gyártóknak is (sztem a gyártók is nagyobb kedvel készítenének drivereket). Kompromisszum kell, nem csak az elvekhez való makacs ragaszkodás.
Ez a "ne sírjon, használjon más" hozzáállás is milyen már? Ha valami nem jó, akkor nem jó. Csinálják meg jóra. Honnan veszem, hogy valami nem jó? Onnan, hogy nem lenne rendszeressen ekkora flame, ha minden szép és jó lenne.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
itt nem csak monolitikus/mikrokernel/stabil api divatról van szó.
-a szabadidőben kernelt fejlesztők nem fognak azért szopni hónapokat/éveket hogy félig átdolgozzák a teljes kernelt, úgy hogy igazából nekik ebből az ég világon semmi hasznuk sincs
-a nagy vendoroknál dolgozó kernelfejlesztők, enterprise disztribúció készítők sem fognak sokat tenni ugyanezért a célért, amit ők supportálnak az működik, amit meg nem, azzal meg hadd ne szopjanak már
-stabil api/abi azt okozná, hogy még kevesebb hw gyártó adna ki specifikációkat, forráskódot; egyre több lenne a bináris driver... jó ez bárkinek is a hardvergyártókon és az egzotikus, most még nem támogatott hardvereket használókon kívül?
mindezen felül valószínű hogy hosszú idejű instabilitást vinne a kernelbe egy ilyen átdolgozás, és elvenné az erőforrást a jelenlegi fejlesztésekről. egyébként ha valakinek nem tetszik: tegyen javaslatot rá (tessék, itt a lehetőség a hőn áhított 3.0-ás kernelre), forkolja, menjen el HURD-ot/PLAN9-ot fejleszteni, stb.
--
hege
- A hozzászóláshoz be kell jelentkezni
Igen, ez jól jellemzi némelyik embernek a hozzáállását: minek nyúljunk hozzá, eddig is elment...
Kérdés, mi a jobb: ha az "egzotikus hw"-t:
- legalább rá lehet szedni működésre, még ha zárt, bináris driver van
- nincs rá driver egyáltalán és a felhasználó szop emiatt.
És nehogy azt mondjátok, hogy csak az egzotikus hw-kkel van problémája a linuxnak. Ja tudom, vegyek támogatott hw-t. Rendben. Megoldja ez a problémát? Nem.
Szvsz, többet ér az, ha van működő - de akár zárt - driver, mint az, hogy néhányan örömtáncot járhatnak, hogy jajdejó van n+1 opensource driver, aztán használja az örömködők közül 2.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Ez a "vegyél támogatott hardvert"-mizéria az adott HW driverének bekerüléséig (és a járulékos huphype-ig) tart.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Azért a "dióbélcsákányos" Gentoo karbantartók se most másztak le a falvédőről. Ami peccset publikussá tesznek a piros N vagy a veres kalap fejlesztői azt azért ők is figyelembe veszik.
Mondjuk azt már csak ugye remélni lehet hogy ezek a peccsek valahogy belekerülnek a mainstream kernelbe is.
- A hozzászóláshoz be kell jelentkezni
Hat ezt mondom en is. Senki nem mondta, hogy Enterprise juzer toltson le kernelt meg minden forrast stb, hanem hasznaljon 'enterprise distro'-t amiben olyan kernel van amit elvileg stabil. Ami eleve nem feltetlen az utolsot jelenti. Csakhogy neha distro kiadok kozott is szinte versenynek tunik hoogy 'nalam mar 2.6.x' van, ami amolyan szamhaboru, ertelme sincs, foleg ha egyik-masik ezt-azt backport-ol stb, akkor nehez osszehasonlitani sima verzioszamokat.
- A hozzászóláshoz be kell jelentkezni
Wannabe Pistike a kiejtése alapján inkább Kolompár. :)))
--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.
- A hozzászóláshoz be kell jelentkezni
Kolompár Adolf.
---off én beszóltam---
- A hozzászóláshoz be kell jelentkezni
Nade mégis mi a műszaki akadálya annak, hogy a 2.6.16-on is használhatók legyenek azok a driverek, amelyek az újabbakban működnek?
Az átgondoltság és a tervezés hiánya.
- A hozzászóláshoz be kell jelentkezni
best. post. evar.
- A hozzászóláshoz be kell jelentkezni
Bra,
Figy, en azon kevesek közzé tartozom akiknek ez a fejlesztesi modell megfelel. A win* meg nem. Lehetseges persze, hogy lehetne jobba tenni. Ez nincs kizarva, de az elgondolasodbol hianyzik a kovetkezo:
win* hany platformon erheto el?
win* meghajtoadatbazisa hogyan epul fel? (probaltal mar 64 bit-es win*-ot?)
win* alatt nem fordul elo soha, hogy a driver "osszeakad" egy masikkal, vagy kimunkalt telepitesi eljaras eredmenyekent mukodhet csak?
Linux ala letezik 5-6 nagyobb es 30-40 kisebb disztribucio, 20-22 arch supportja folyik aktivan, vagy kevesbe aktivan. Ha errol levalasszuk a sok butasagot, es nezzuk azt az 5-6 meghatarozo terjesztest, illetve azt a sok sosemhasznalt platformot es csak az x86 szeru dolgokkal foglalkozunk akkor is elismerheto, hogy picit nagyobb falat.
A masik, hogy igen sw design teren lehetne belevinni a linux kernelfejlesztesbe hatekonysagot, viszont a most mukodo modelt teljesen kerekbetorne ie: az egyeni kontribucios fejlesztesek lassan megszunnenek.
Teljesen megfelel, hogy egy disztribucioban allando kernel legyen minimalis valtoztatasokkal, ez alatt adjanak ki tamogatott hw listat, ez alatt vizsgaljak a programok mukodokepesseget. Ez szerintem igy tok jol van.
Kicsit talan fajdalommentesebb lenne, ha nem lenne ennyi api/abi/lof@sz valtas, de akkor kizarjuk az otletszeru javitasi modelt.
Nincs tiltva a fork, es en hasznalok olyan eszkozoket amelyre ugy gondolta a ceg(tobb), aki ezt forgalmazza, nem jo neki ez a modell, ezert minden branch-bol kivalasztja maganak a szimpi kernelt, majd tovabbforkolja sajat celra. Nos nem jellemzoen nem jutnak az egyrol a kettore. Konkretan: pl egy ceg 2.2.x el kezdte terjesztette a sajat boot imaget majd egy ido utan elfogyott a szusz, el voltak maradva kb 2 evvel, ugy dontottek lets 2.4 majd 2 ev support utan most ternek at a 2.6 ra, mivel a 2.4 mar keves nekik(nem 2 fejleszto van a cegnel aki megunta a fejlesztest). Megiscsak lehet ertelme a fenti kernelfejlesztesi ceconak?
- A hozzászóláshoz be kell jelentkezni
nem
- A hozzászóláshoz be kell jelentkezni
de
- A hozzászóláshoz be kell jelentkezni
koszonjuk a nagy szakertelemmel rendelkezo felhasznalonknak az ervekben, es tenyekben bovelkedo hozzaszolasat.
tovabbi sok sikert kivanunk az ovoda minel elobbi befelyezesehez.
- A hozzászóláshoz be kell jelentkezni
>> az ovoda minel elobbi befelyezesehez
a befejez szót kerested hup-digg-gw gplsértő b0rkedsoft
- A hozzászóláshoz be kell jelentkezni
Willy, szeretem mikor a lényeget sikerül megragadnod a mondandómból. Fentebb leírtam más megközelítésből, olvasd el, talán abból jobban megérted.
Nem azt mondom, hogy a Windows tökéletes, vagy akár jobb minden szempontból (vagy akár a szempontok nagy részéből).
Azt mondom, hogy minél több Linux vendor van és minél szélesebb körben használják, annál nagyobb fragmentációt jelent ez a kernelnek és annál nagyobb terhet ró a végfelhasználóra és a vendorra.
Tudom, nehéz elfogadni, de szar mondjuk egy olyan hibával szívni egy Red Hat 2.6.9-ben, amit kettő, vagy három kernelverzióval később kijavítottak, de ez a cég vagy nem olvas 100 megás changelogot és nem elemzi line-by-line, hogy az adott hiba érintheti-e az ügyfeleit és ha igen, azonnal portolja (portolja!) vissza, vagy pedig egyszerűen ez még egy ekkora cégnek is megterhelő lenne.
- A hozzászóláshoz be kell jelentkezni
Nem veletlenul reagaltam a fenti leirasodra. Megertem a hozzaallasodat, sot nem is akarom befolyasolni. Viszont amire valaszoltam az pont az a hozzaszollas, ami torzithatja az olvaso latasmodjat a problemarol. Ezert vettem ki ezt a reszt es aki mindkettot olvasta, mas nezetet is lathat.
Ja es kiterve a lenyegre: Attol, hogy letezik a problema, meg nem biztos, hogy a megoldas az, hogy a fejlesztesi modelt megvaltoztatod. Talan van mas alternativ megoldasi lehetosegek.
- A hozzászóláshoz be kell jelentkezni
vagy pedig egyszerűen ez még egy ekkora cégnek is megterhelő lenne
Nem lehet, hogy esetleg azért nem backportolják, mert mondjuk ezer más dolgot is érinthet, ami tovább eszkalálódhat?
- A hozzászóláshoz be kell jelentkezni
Bármi lehet. De nehezen tudom elhinni, hogy a Red Hat nagyon boldog lenne ezzel a helyzettel.
Bevallani pedig nyilván túl ciki lenne.
- A hozzászóláshoz be kell jelentkezni
Pedig hidd el, hogy egy javítást csak akkor raknak a fix EL kernelbe, ha az tutibiztosan nem fog semmit agyoncsapni.
- A hozzászóláshoz be kell jelentkezni
Ilyenkor mindig felmerül bennem a kérdés: hogy a francba lehetséges, hogy a Windows úgy képes egész használható lenni, hogy 2-3-5 évig lényegében azonos verzió az utolsó és nincs naponta új release?
Nagyjából sehogy.
Az említett probléma win alatt is létezik. Egynémely s4ervice Packnál, hotfixnél elég keményen belenyúlnak a rendszerbe, és vagy a használt rendszerszintű összetevővel rendelkező programokból kell újabbat beszerezni, vagy pedig HW driver kell újabb mondjuk egy méregdrága lézernyomtatóhoz és ha itt közli a gyártó hogy az adott termék nincs supportálva továbbiakban, akkor megcseszheted a windowst is, vagy hotfix, ill. problémás SP nélkül használod.
Mert linux alatt még esetleg belehekkel valaki az eszközhöz egy drivert valamilyen kernelbe, de ha ez a jelenség win alatt jelentkezik esélyed sincsen.
Amiről írsz az nem linux specifikus dolog. A windows kernelét legalább ugyanolyan mértékben "basztatják".
-----------------
Nem a zsömle kicsi, a pofátok nagy...
- A hozzászóláshoz be kell jelentkezni
Felejtsd el a windowsos példát, félrenyúltam vele. Leírtam máshogy, az talán érthetőbb.
- A hozzászóláshoz be kell jelentkezni
Hát igen, van benne igazság, csak teljesen megvannak ezzel kernel dologgal az emberek tévedve. A linux kernel eletének minden rezdülése nyilvános és valamiért azt feltételezik, hogy ezek mind stabilak is, holott messze nem kész termékek. Késznek mondjuk talán az utolsó 2.4.xx kernel tekinthető, bár az se. Másik oldalon, meg csak a kész termékekkel találkozunk (2.4.xx-es win kernel:)). Mivel a linux kernel önmagában nem jó semmire és nem is kötődik semmihez, igy egyféle mindig valtozó képlékeny állapotban van. Én kétféle megoldást tudok elképzelni:
Első amiről itt is szó van. A disztribútorok kiemelnek erről a széles palettárol egy nekik megfelelő alapanyagot és a termékükhöz igazitják és gyúrják amig el nem éri a kivánt szintet. Persze ez sok idő és pénz, ezért csak a nagyobbak tudják megtenni. De nyilván ezért van a RH-nál a Fedora, a Novellnél az OpenSuSE. Ami ott működik abbol lesznek a kereskedelmi termékek kb. egy éves késéssel.
Másik, de nem tökéletes megoldás, hogy valahogy rávenni a kernelfejlesztőket, hogy mondjuk évente adjanak ki, egy stabil kernelt, ami nem kötődik szorosan az épp aktuális verzióhoz, hanem az előző stabilhoz képest az kerül bele amit jónak, megbízhatónak találnak. Szerintem könnyen belátható, hogy ez NEM tudja 100%-ig helyettesíteni az első megoldást, max. megkönnyiti lerövidíti. Igazándiból ez a megoldás azoknak kedvezne, akik az ugynevezett csináldmagad free disztribúciók hívei. Kérdés, hogy ez motiválja-e elégge a kernelfejlesztőket, vagy kimondhatjuk, hogy ez a FOSS ára, hogy sosincs egy stabil megszilárdult végleges termék (linuxról van szó), hanem mindig új és valtozó. :)
- A hozzászóláshoz be kell jelentkezni
> valahogy rávenni a kernelfejlesztőket, hogy mondjuk évente adjanak ki, egy stabil kernelt,
Van olyan is, hogy munkamegosztás. A kernelfejlesztőknek jut a kernel fejlesztése, a tesztelők feladata a tesztelés, stb., a stabil kiadások kiadása pedig a kiadók munkája.
:-)
--
hup.user.js
- A hozzászóláshoz be kell jelentkezni
Az, hogy az új fícsörök csak a bleeding edge-ben vannak meg, és szükség esetén külön effort visszaportolni őket a stable ágba, ez természetes velejárója a stable/devel bontásnak. Nyilván minden technológiai választásnak megvannak a maga gondjai. Nem ez a baj.
Azt nézzük meg inkább, hol hibádzik az az egybevetés, hogy mondjuk
(FreeBSD STABLE, FreeBSD CURRENT) =~ (RHEL kernel, Linus kernel)
Ott, hogy a FreeBSD STABLE is egy nyíltan, a CURRENT-tel egyező infrastuktúrában fejlesztett ág, míg
az RHEL kernel egy kívülről átláthatatlan módon összerakott valami, csak a Red Hat mérnökei vannak képben, pontosan mit pakoltak bele, miért (erre nem válasz, hogy ott vannak a peccseik, végig lehet olvasni őket).
Az RH kódra támaszkodni vendor lock-in. (Mégha a Cementoson kereszül teszem, akkor is.)
És ez nem lenne így, ha lenne egy kernel.org által karbantartott, hivatalos stabil ág.
- A hozzászóláshoz be kell jelentkezni
> És ez nem lenne így, ha lenne egy kernel.org által karbantartott, hivatalos stabil ág.
Gondolom ha valakik elkezdenének egy ilyen "stabil ág"-at karbantartani, és idővel látszana, hogy jól csinálják, akkor a kernel.org örömmel adna helyet az anyag terjesztéshez.
Ja, csakhogy ehhez valakiknek dolgozni is kéne, nem csak álmodozni róla. :-)
- A hozzászóláshoz be kell jelentkezni
Ennyi erővel már saját disztribet indítanának ezek a valakik. :S
Weee!
- A hozzászóláshoz be kell jelentkezni
És akkor ott leszünk, ahol most. Hogy mé nincs egy központi stable ... :-)
- A hozzászóláshoz be kell jelentkezni
Akkor már legyen egy központi disztrib is..
Weee!
- A hozzászóláshoz be kell jelentkezni
Jobb ha lehet választani, ha van verseny, stb.
Úgyhogy inkább legyen több központi disztrib, meg néhány nem központi.
:-)
- A hozzászóláshoz be kell jelentkezni
Aki most akar linuxra átállni (switcher) lehet hogy elbizonytalanodik e topic láttán.. Huhh..
Weee!
- A hozzászóláshoz be kell jelentkezni
Aki autót akar venni, az is könnyen elbizonytalanodhat. Akkor nekik se kéne autós topikokat olvasniuk? :-)
- A hozzászóláshoz be kell jelentkezni
Miért, akartak már meggyőzni téged suzukis topicban arról hogy vegyél mercedest?
Weee!
- A hozzászóláshoz be kell jelentkezni
Az elbizonytalanodás gondolkodásra késztet :-)
- A hozzászóláshoz be kell jelentkezni
Aki mosr akar átállni Linuxra, nem hiszem, hogy sokat tudna a kernelről, ezért valószínűleg nem is olvassa ezt a szálat.
- A hozzászóláshoz be kell jelentkezni
Ez a szokásos "ha nem tetszik, ott a forrás, írd át"-szöveg, ennél nincs jobb? ;-)
@dzsekijo: te meg légyszi ne 12 éve egy helyben toporgó OS-ekkel gyere 2007-ben.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Nem, ez az "iparági összeesküvés akadályozza a fejlődést" szöveg bevezetője.
- A hozzászóláshoz be kell jelentkezni
Szerintem a linuxkernel fejlődésének akadályozását nem bízzák idegenre, be van az is olvasztva. ;-)
(Meg ne kérdezd, hogy kik nem bízzák idegenre, mert falra mászok.)
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Kik azok az idegenek?
Weee!
- A hozzászóláshoz be kell jelentkezni
Biztos ilyen izzadós hónaljú kopasz lények, akiknek az a hívójelük, hogy "DIVEEEEELOPÖRZ". De erről Poliverzumot kérdezd.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Ő mindig BULIzik a MUFFokkal.
Weee!
- A hozzászóláshoz be kell jelentkezni
@dzsekijo: te meg légyszi ne 12 éve egy helyben toporgó OS-ekkel gyere 2007-ben.
Azért mondtam a FreeBSD-t, mert egy közismert példa a stable/devel leosztásban fejlesztett OS-re. Nem "jöttem" vele sehova.
Tipikusan a buta+ravasz emberek érvelési technikája, hogy x mond egy konkrét példát, érzékeltetendő egy absztrakt dolgot, és az illető a példa esetleges tökéletlenségeibe köt bele, eltereleve a vita vonalát a lényegről. Ill. archaisztikus párbeszédekben szoktak ilyen fordulatok lenni:
- Ha nem adod nekem a lányom, seregeim úgy fogják országod letarolni, mint sáskák a zsenge tavaszi vetést!
- Hm, időjósaim épp azt jelentették, hogy olyan fagyok jönnek a tavasszal, hogy a sáskák úgy fognak potyogni, mint az érett cseresznye nyári viharok alkalmával.
- Az én időmágusaim ezek szerint kicsit többet tudhatnak a tieidénél, mert megsúgták a fülembe, hogy olyan nyarunk lesz, hogy a Níluson is száraz térddel lehet majd átgázolni és úgy fog állni a levegő, hogy piramisokat lehetne építeni rá!
- Bár nem vennék mérget az időmágusaidra sem, az mégiscsak jobban aggaszt, hogy miket hallhattál félre a te füleddel, ami olyan süket, hogy ágyút is durrogtathatnék mellette álmodban, arra se rezzennél fel!
- Méghogy te, ágyút? A te mérnökeid még egy faltörő kost se bírnak rendesen összerakni!
Téged nem tartalak se buta+ravasznak, se pedig nem ezer évvel korábban élsz, úgyhogy nem tudom mire vélni a 12 év toporgásod.
Most amúgy, hogy már leírtam ezt így... ami a nagy átalánosságot illeti, nem tudom nem észrevenni a HUPon folyó eszmecsere hasonlatosságait a fenti párbeszéddel :)
- A hozzászóláshoz be kell jelentkezni
Te észrevenni? Csoda hogy azt észrevetted hogy új komment van!
- Egyébként +1.
Weee!
- A hozzászóláshoz be kell jelentkezni
Te észrevenni? Csoda hogy azt észrevetted hogy új komment van!
+1.
Off és lehet hogy nagyon beégek ezzel a kérdéssel, na de tényleg... szerinted hogy lehet normálisan követni a válaszkommenteket? Legalább a beállítások között lenne olyan, hogy értesítés küldése válasz esetén... én legalábbis nem látok. Ez se lenne tökéletes szolúsn, de talán jobb, mint a semmi.
Ui: válaszolj nyugodtan és ne szívd mellre, ha nem nézem meg :) [De majd törekszem]
- A hozzászóláshoz be kell jelentkezni
Bocs, nem vettem észre a kérdést! ;)
hupuntu© - e örő e bódottá
- A hozzászóláshoz be kell jelentkezni
Elnézésedet kérem, hogy nem érezted az iróniát, kellett volna szmájlit tennem.
OFF: Amúgy meg kapcsold már be légyszi a privát üzenetküldést, akarok küldeni egy levelet.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Elnézésedet kérem, hogy nem érezted az iróniát, kellett volna szmájlit tennem.
Ja, mondjuk igaz, hogy nekem is az volt szignatúrám egy időben, hogy
My sense of humour is often too subtle to cope with getting smileyd. Please don't take it personal.
Ill. még mindig az (mármint mélben), csak mindig kitörlöm :) Viszont mér ne rakjam be a HUPra...
OFF: Amúgy meg kapcsold már be légyszi a privát üzenetküldést, akarok küldeni egy levelet.
Ack.
- A hozzászóláshoz be kell jelentkezni
Ezek a Linux vendorok által agyonpeccselt kernelek.
- A hozzászóláshoz be kell jelentkezni
A Linux vendorok összeállhatnának egy stabil ág karbantartására, back portolgatásra, stb., senki sem tiltja nekik.
Viszont semmi sem ösztönzi/kényszeríti rá őket, hogy így tegyenek.
Talán majd GKH. :-)
- A hozzászóláshoz be kell jelentkezni
Sőt, Solaris kernelt is használhatnának.
- A hozzászóláshoz be kell jelentkezni
Az egyik stabil disztrib lehetne a debian sid. http://hup.hu/node/40528#comment-375867 Itt azt mondják nem is unstable.
Weee!
- A hozzászóláshoz be kell jelentkezni
az RHEL kernel egy kívülről átláthatatlan módon összerakott valami, csak a Red Hat mérnökei vannak képben, pontosan mit pakoltak bele, miért (erre nem válasz, hogy ott vannak a peccseik, végig lehet olvasni őket).
Az RH kódra támaszkodni vendor lock-in. (Mégha a Cementoson kereszül teszem, akkor is.)
Pontosan így szokott az beszélni, aki:
a) sárga az irigységtől
b) életében nem nézett még rhel kernel/patch source-ot vagy changelogot
- A hozzászóláshoz be kell jelentkezni
Kíváncsi lennék, hogy neked, mint RH közeli embernek mi a véleményed a mostani helyzetről. :)
- A hozzászóláshoz be kell jelentkezni
Megtisztelsz érdeklődéseddel, előrebocsájtom, hogy ez magánvélemény és nem hivatalos kinyilatkoztatás :)
Az üzleti világban teljesen logikus, hogy az erősebb kutya élvezi a koituszt. Nem meglepő, hogy - mint egy másik cikkben is volt róla szó - az enterprise fejlesztőcégek befolyásolják komolyabban a kernelbe bekerülő technológiák egy részét; hiszen mégiscsak ők pénzelik azokat a fejlesztőket, akiknek a legtöbbet köszönhetjük. Viszont a jelenlegi helyzet tarthatatlan és kiszámíthatatlan. Itt: http://kernelslacker.livejournal.com/82610.html pl. azt írja a bácsi, hogy hosszú hónapokig bugtalanítják a kiszemelt kernelpéldányt, mielőtt bekerül az enterprise családba.
Ezért az lesz, hogy a nagy vendorok (Novell, Red Hat, talán Ubuntu) saját forkkal fognak előrukkolni. Nem kell őket félteni (legalábbis a RH-et nem), hiszen Mingo meg AC is ott van, meg jópáran, így lesz egy letisztult, hosszú távon (!) supportálható kernel. A vanilla meg megmarad hobbyist meg home kernelnek. Ráadásul ezt én 2 éven belülre saccolom.
- A hozzászóláshoz be kell jelentkezni
Szerinted akkor több cég is forkol, és mindegyik külön fejlesztési irányt kíván képviselni, és veszik át egymástól a cuccot?
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Igen, valószínűleg erről lesz szó.
- A hozzászóláshoz be kell jelentkezni
Ezt én annyiban látom problémásnak, hogy semmi köze nincs a közösségi fejlesztőmodellhez. Ez egyrészről érthető, mert a cég magának fejleszti, másrészről viszont nem. Miért:
Ugye a Linux kernelt alapvetően nem 1-2-3 disztró használja hanem elég sok. Ha a patchek házon belül maradnak, és a kernel.org-osok nem tesznek meg mindent a beolvasztásért, akkor minden egyes disztrónak kb. újra fel kell találnia a meleg vizet. Tény és való, hogy a kölcsönös bizalmatlanság sokszor előny, de nem egy ilyen projektnél. Szerintem az lenne a disztrógyáraktól a szerencsés hozzáállás hogy visszanyomnák mainstream-ba a patcheket, a kernel.org-osok részéről meg az, hogy a stabil verzió kiadása előt átnéznék a stabilizálási patcheket, amit a disztrógyártók nyújtanak be.
Emberek, össze kéne tenni amink van, és nem csak ülni a saját babérjainkon. Mert ha jól tudom, erről (is) szól a linux.
Persze ez erőforrást igényelne a kernel.org-osoktól is, de hát mindenhez erőforrás kell, és ez a dolog megérné az áldozatot.
Persze szigorúan szvsz
- A hozzászóláshoz be kell jelentkezni
Köszönöm, valami ilyesmire számítottam. Ha jól értelmezem a szavaidat, akkor lényegében egy állásponton vagyunk, a különbség csak annyi, hogy nekem leginkább semmi közöm a Linuxhoz, neked meg azért mégiscsak több. :)
- A hozzászóláshoz be kell jelentkezni
Tisztelem LAcit, de nem az ő véleménye fog dönteni :-) IMHO megölné a RedHat-et egy ilyen lépés. Szerintem inkább a már említett és jól működő menedzsment csapat segítene a dolgokon és szerintem a disztribútorok is ezt fogják szorgalmazni. Azzal megmarad a user bázis, de lehetne tisztább a kód. kisg jókat írt. Egyébként van is erre projekt, nem tudom miért nem használják kódkiadás _előtt_.
- A hozzászóláshoz be kell jelentkezni
Mint elhangzott, most is rengeteg energiát kell befektetnie egy kernelbe, mielőtt kiadhatnak vele egy OS-t.
Kíváncsiságból meg is néztem:
rpm2cpio kernel-2.6.18-8.el5.src.rpm | cpio -ivmud
rm linux-2.6.18.tar.bz2
du -k *.patch | awk '{ sum += $1; } END { print sum; }'
18174
18 MB-nyi patch van a kernel.org-os kernelen egy olyan OS-ben, ami nemrég jött ki (talán idén márciusban, azaz kb. három hónapos).
Nézzük a 4.5-öset, az picit régebbi (2.6.9-es kernel):
du -k *.patch | awk '{ sum += $1; } END { print sum; }'
61134
60 MB-nyi patch!
- A hozzászóláshoz be kell jelentkezni
Nekem ebből az tűnik ki, hogy egyre kisebb a patch :-) Egyébként a patcheket a gyártók által fizetett fejlesztők hagyják jóvá, nem? Az esetek 90%-ban, legalábbis. Ők a commitoló emberkék. Elvileg át is nézhetik a kódot, mielőtt beengedik a kernel fába. Szerintem a tempóból kellene visszavenni. Lasabb kiadások, több teszt. Engem nem zavarna, ha 1 év alatt jutnánk el a 2.6.1-től a 2.6.2-ig.
- A hozzászóláshoz be kell jelentkezni
Értem. Tehát a több éves 4-es szériánál, a 4.5-re felhalmozódott 60 MB-nyi patch és a frissen kiadott (három hónapos) 5-ös szériában lévő KEZDETI, ELSŐ VERZIÓBAN LÉVŐ 18 MB-nyi patchből azt a következtetést vonod le, hogy csökkenő tendenciát mutat a dolog.
Grats Ago. :)
ui: felkeltetted az érdeklődésemet és megnéztem, hogy mennyi patch volt a 4.0-ban: 12 MB.
Tehát akkor gyk:
4.0: 12 MB
[...]
4.5: 60 MB
5.0: 18 MB
[...]
5.5: ?
- A hozzászóláshoz be kell jelentkezni
Mondhatnám, hogy smiley, de benéztem :-) Illetve kerekítettem. Azt azért vegyük figyelembe, hogy az első 2.6-os kernel sorozatú kiadásuk volt a 4-es EL. És azt sem árt megnézni, hogy mennyi új hw, feature van benne. Az sem biztos, hogy mind javítás. Lehet, hogy van amit azért kell átírni, mert egy másik helyen változtattak valamit, ami nem is biztos, hogy javítás miatt, hanem egységesítés stb. valami miatt történt. Látni kellene a folyamatot. Esetleg a kernel team vezetőjét megkérdezni a helyzetről. Egy e-mail interjú?
- A hozzászóláshoz be kell jelentkezni
Érdekelne a véleménye, bár szerintem azt nem mondaná el nyilvánosan. :)
- A hozzászóláshoz be kell jelentkezni
> Ezért az lesz, hogy a nagy vendorok (Novell, Red Hat, talán Ubuntu) saját forkkal fognak előrukkolni.
Ha komoly megtakarítást, vagy bevételnövekedést hoz, akkor tegyék csak nyugodtan. :-)
- A hozzászóláshoz be kell jelentkezni
A kiszámíthatóság anyagi előnyt is jelent.
Weee!
- A hozzászóláshoz be kell jelentkezni
Ezt meg hogy kell érteni?
Az említett vendorok (novell, redhat, ubuntu) jelenleg nem kiszámíthatóak? Vagy csak kevéssé kiszámíthatóak?
Ellenben a kernel feltételezett forkolása után valamennyivel jobban/nagyon kiszámíthatóak lesznek?
- A hozzászóláshoz be kell jelentkezni
Csak én érzem enyhe logikai bukfencnek, hogy épp az általad is említett Red Hat-os fejlesztők érvelnek leginkább a jelenlegi fejlesztési modell mellett? Ebben az esetben pl AC az LKML-en.
- A hozzászóláshoz be kell jelentkezni
AC másként érvelhet szombaton otthonról és másképp hétfőn, a cégnél :)
- A hozzászóláshoz be kell jelentkezni
akkor viszont elérhetjük azt a szintet, hogy lesz egy teljesen külön kernel, amit kevesebben fognak használni vagy a disztrók mind átállnak rá. Szerintem ez megölné azt a rendszert - most nem a kernel fejlesztésről beszélek egyedül -, ami miatt ezek a cégek létezhetnek. Személy szerint nekem is jobban tetszett, hogy volt külön fejlesztői vonal. Viszont mennyiben lesz más a dolog akkor, mint most? Azaz forkoljak pl. a 2.6.32-t, lesz belole rh-kernel (gondolom linux nem lehet a copyright miatt) és az új drivereket ők rakják hozzá? Saját különutas fejlesztések lesznek hozzá? Az akkor már nem Linux lesz. Legalábbis nem az, ahogyan elért erre a szintre. Persze nem maradhat minden állandó, változik a világ. Csak a fenti esetben fennáll a veszélye, hogy teljesen fragmentálódik az, ami most laza szövetségben van. Az RH-nak is veszélyes lehet, ha nem használják annyian a kernelét, mint most a linux.org-ét amiből látják mi a szívás. Ha meg évenként, kétévenként megnézik hol tart a linux kernel és fogják a forrást, átveszik, akkor megint ugyanott tartanak, mint ma. Ha külön út, akkro a fent említett szabad forráskód nyújtotta előnyöket veszítik el. Szerintem vissza a fejlesztő verzióval :-)
- A hozzászóláshoz be kell jelentkezni
ez az opció amennyivel tovább nézem, annyival kevésbé tetszik. Az a sors fogja ez esetben elérni a linuxot, mint a régi kereskedelmi unixokat: nulla kompatibilitás, fragmentált piac, emiatt kevesebb felhasználó, végül az SCO sorsa.
Vannak persze olyan rendszerek amik ezt is túlélték, de imho azért, mert olyan helyen vannak, ahol nagyobb nyűg váltani, mint a seggemen felnyúlva kinyúlni a számon. (jó példa a RPG és FORTRAN rendszerek mai napig élnek pár helyen és nem azért mert nem találtak ki jobbat az ott lévő rendszereknél).
Ami a helyzeten segítene, az a legerősebb disztrók és a nagy vendorok által kijelölt menedzsment/engineering board, akik megszabják az irányt és lemondani arról, hogy ilyen sebességgel jelenjenek meg kernelek. Mi a cukros fasznak minden hónapban valami újdonság miatt egy újabb kernel verzió (kis túlzással élve). Szívesen várnék fél évet egy kitesztelt kernelre. Szóval ez itt menedzsment probléma kérem szépen.
- A hozzászóláshoz be kell jelentkezni
Váltás nehézségének ecsetelése: ROTFL, Old-style cuccok esetén ne felejtsük el a COBOL-t sem, illetve a VAX-VMS-t, ha már OS-ek sorsáról van szó...
A menedzsment/board által kijelölt irányok, mint (ördögi) felállás mintha ismerős lenne valahonnan... :-P
- A hozzászóláshoz be kell jelentkezni
És ki mondta, hogy az rossz? Azt sem jelenti, hogy egyszerűen adaptálható. És nem mondasz le a bazár modellről sem. Igenis lássák közben is a forrást, mindenki, aki csak akarja. Csak legyen egy vezeői réteg. Alatta a tesztelők sokasága. A fentebb említett tesztfarmok. Egyébknét a sok nagy cég, akiknek dollármilliárdok függnek tőle mi a búbánatos f***ért nem képes megvenni egy egy hardver elemet? Tegyük fel van 5000 hardver a világon (hálókártya stb.) ha a chipsetet, biost stb nézzük. Akkor most képzeljük el, hogy ezek mennyibe kerülnek. Nézzük meg, hogy ha a cégek akiknek pénz folyik be a linuxból, ha pénzt adnak mennit kell belinveszálni? 50.000 dollárt, talán? Nagyszerű. Mennyibe kerül nekik a 3 hónapnyi teszt, fejlesztés stb.? Akkor talán meg kellene nézni, hogy megérné-e fenntartani egy ilyen tesztfarmot _közösen_ ezeknek a cégeknek. Akkor lehet, hogy mondjuk 5 mega lenne a patch set RH-nál és Novellnél is. Mindjárt szebb lenne. Lehet, hogy alulbecsültem a hardverek számát, a bekerülési költséget stb. de szerintem közösen adakozva megoldható lenne. Ha az a módi, mint sokszor itthon, hogy tényleg jó lenne valami, de csinálja meg helyettem más, az nem fog működni.
- A hozzászóláshoz be kell jelentkezni
Nem mondtam, hogy rossz, sőt... Az "ördögi"-vel egészen másra céloztam :-)) A közös tesztfarm IMHO jó ötlet -- lenne, csak azért tegyük hozzá, hogy egyelőre a Novell, a RedHat egyaránt a vállalati piacot célozza, és ott is a nagy gyártók vasait -- amikre komolyan tesztelik a cuccokat, azok ezek, a dzsunkapécé egyelőre nem érdekli őket.
- A hozzászóláshoz be kell jelentkezni
Éppen ezért kellene pl. a vanilia kernelt berakni tesztelésre (vagy más széles körben elérhető/használható projectet), mert azzal azzal mindenki jól járna, nem csak az enterspájz cégek.
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
oo azert anno a Redhatos gcc 2.96 az akkor mi volt ? :)
Stabilitas ? :)
Udv
-krix-
- A hozzászóláshoz be kell jelentkezni
Egyrészt az 7 évvel ezelőtt volt (akkor még nem létezett az Enterprise Linux vonal), másrészt:
- A hozzászóláshoz be kell jelentkezni
és így szokott válaszolni, aki RH munkatárs vagy hívő :-) van igazság abban amit mond. Valóban nem lehet átlátni 1x1 usernek vagy nekem. Vagy neked. A commenteket el tudom olvasni, a kódot is, de azt is látni kell, hogy akik csinálják azok:
1.) nem egyedül vannak
2.) sokat kommunikálnak egymással
3.) egyeztetik, hogy az esetleges patchek miért x és nem y módon vannak megoldva, hogy Bra-t idézzem: figyelnek a szerteágazó függőségekre :-)
Nyilvánvaló, hogy ott a forrás, lehet dolgozni, de az összes forrás _rendszerben_ történő átlátáshoz vagy RH kernel fejlesztőnek/mérnöknek kell lenni vagy egy másik hasonló méretű cégnél/közösségben kell dolgozni.
Egyébként nem értem hol a baj.
- A hozzászóláshoz be kell jelentkezni
és így szokott válaszolni, aki RH munkatárs vagy hívő :-)
Hátizé :)
2.) sokat kommunikálnak egymással
Na itt a lényeg! Normális szoftvert szerintem csak úgy lehet csinálni, ha nem százfelé dolgoznak lone warriorként, hanem igenis elosztják a melót és terveznek, terveznek, terveznek.
Egyébként ha gonosz, offenzív ember lennék, azt kérdezném: "vazz, ott a forrás, kommentekkel, más szervem nem kellene?", de nem teszem, mert egyrészt én sem tudom, melyik patch mit csinál (illetve volt már rá példa, hogy megértettem egy RH kiegészítést :D ) másrészt tudom, hogy ez nem segíti az átlagusert.
De a nagy szoftver- és hardvergyártóknak legyen elég ennyi is.
- A hozzászóláshoz be kell jelentkezni
Na itt a lényeg! Normális szoftvert szerintem csak úgy lehet csinálni, ha nem százfelé dolgoznak lone warriorként, hanem igenis elosztják a melót és terveznek, terveznek, terveznek
vs. bazármodell :-/
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Linux vs. BSD fejlesztés Linus szerint. Szerinte a BSD-s fejlesztés a magányos harcos ("mindenki magáért"). A Linux fejlesztését mindig a "közösség összetartó ereje lám mire képes" példájaként szokták felhozni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A bazár csodálatos, de itt már dollármilliárdokról van szó.
- A hozzászóláshoz be kell jelentkezni
A bazár modell nem feltételezi, hogy nem tervezed meg amit meg akarsz írni. Azt sem feltételezi, hogy nem kommunikáltok egymással. ESR szerint a bazár modellben végig látod a kódot, részt vehetsz a fejlesztésben, míg a katedrális modellnél csak a végtermék kódját látod. Amiről beszélünk nem ugyanaz. Jó, ha látják a kódot, kis patcheket tudnak adni, tudnak közben tesztelni, reportolni. Aztán, hogy egy patchet beolvasztasz-e az a Te dolgod. Ebből a szempontból a BSD-k is bazár modell szerint működnek. A bazárban szabadon nézelődhetsz, ha van hely van lehetőséged neked is részt venni a bazár életében stb. A katedrális építését viszont egy ember vagy megfelelően kevés ember vezérli.
- A hozzászóláshoz be kell jelentkezni
b) életében nem nézett még rhel kernel/patch source-ot vagy changelogot
Vannak dolgok, amiket látatlanban is meg lehet mondani. Nem vitatom: az RH kódminőségét,
mérnökei hozzáértését, QA-jának alaposságát, a fejlesztési metodológiáik kiforrottságát,
a rendszer dokumentáltságát, üzleti etikájukat, a közösségben játszott szerepüket.
Csak annyiról van szó, hogy szerintem a forrás nyíltsága nem ott végződik, hogy mi a licensz.
Eléggé fontos tényező, hogy legyen publikus SCM, meg publikus fejlesztői levlisták. Ezek közül:
http://www.redhat.com/mailman/listinfo melyikből mennyire derül ki, mit mi végett pakolnak a
kernelükbe? Mint alább írod, van egy összecsiszolt fejlesztőgárda a cégen belül. Cool. De az
egyszeri ember számára, gondolom, nem hozzáférhetők a diszkusszióik -- ugyanúgy nem, mint ahogy
te se tudhatsz arról, mint annál a cégnél, ahol én dolgozom, mik a termékkel kapcsolatos problémák,
vagy bármely más cégnél.
Persze mondhatod, hogy a stabil kernel fő célközönségének, az enterprise-nak ezek a dolgok nem
érdekesek, és nem teszi ez számukra kevésbé megfelelőnek a (Red Hat) Linuxot. OK. A másik oldalon
viszont nem csak az én esetleges személyes preferenciáim vannak, hanem hogy a nyílt forrásnak a
"tudás" hozzáférhetőségét és továbbéltetését propagáló ideáinak mennyire felel meg ez a helyzet.
Valamelyik evangelista -- talán maga a battely poweled, vagy Linus? -- mondta, hogy a zárt forrás
halott forrás. Evolúciós terminológiával élve: zsákutca, meddő, génjei továbbadására alkalmatlan.
Ehhez visz egy kicsit közelebb, ha a "stable" egy explicitté nem tett szellemi folyamatból eredő
patchsetben manifesztálódik. S nemigen látom, hogy ezt hogy lehetne elkerülni a
stable kernel == vendor kernel koncepció mellett. Talán nem véletlen, hogy a disztrók terén
a legnagyobb ötlettenger a Debian lába nyomán fakadt, és nem a Red Hat vagy más cég általi
terjesztés kapcsán.
My sense of humour is often too subtle to cope with getting smileyd.
Please don't take it personal.
- A hozzászóláshoz be kell jelentkezni
"És ez nem lenne így, ha lenne egy kernel.org által karbantartott, hivatalos stabil ág."
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.52.tar.gz
- A hozzászóláshoz be kell jelentkezni
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.52.tar.gz
Hát ez azért nem ilyen egyszerű. Pontosan ki fejleszti eztet? És hol? Hol a git fa?
OK, I'm doing my homework: http://lwn.net/Articles/236392/. De akkor
ez: hup://38889 mi? És ez: hup://39869? Nem is beszélve erről:
$ w3m -dump http://git.kernel.org/ | grep -A1 stable
linux/kernel/git/chrisw/ 2.6.12-stable Chris Wright months shortlog
linux-2.6.12.y.git kernel tree ago | log |
--
linux/kernel/git/chrisw/ 2.6.13-stable Chris Wright months shortlog
linux-2.6.13.y.git kernel tree ago | log |
--
linux/kernel/git/chrisw/ 2.6.14-stable Chris Wright months shortlog
linux-2.6.14.y.git kernel tree ago | log |
--
linux/kernel/git/chrisw/ 2.6.15-stable Chris Wright months shortlog
linux-2.6.15.y.git kernel tree ago | log |
--
linux/kernel/git/chrisw/ 2.6.11-stable Chris Wright years shortlog
release-2.6.11.git kernel tree ago | log |
--
linux/kernel/git/chrisw/ -stable patch Chris Wright months shortlog
stable-queue.git queue (pending ... ago | log |
tree |
--
stable-queue.git Kroah-Hartman ago | log |
tree |
--
linux/kernel/git/mkrufky/ 2.6.15-stable Michael Krufky months shortlog
v4l-dvb-2.6.15.y.git kernel ... ago | log |
--
linux/kernel/git/mkrufky/ 2.6.17-stable Michael Krufky months shortlog
v4l-dvb-2.6.17.y.git kernel ... ago | log |
--
linux/kernel/git/mkrufky/ 2.6.20-stable Michael Krufky months shortlog
v4l-dvb-2.6.20.y.git kernel ... ago | log |
--
linux/kernel/git/mkrufky/ 2.6.x.y-stable Michael Krufky weeks shortlog
v4l-dvb-2.6.x.y.git backports ago | log |
--
linux/kernel/git/stable/ 2.4.33-stable Willy Tarreau months shortlog
linux-2.4.33.y.git kernel tree ago | log |
--
linux/kernel/git/stable/ 2.4.34-stable Willy Tarreau weeks shortlog
linux-2.4.34.y.git kernel tree ago | log |
--
linux/kernel/git/stable/ linux-2.6-stable Chris Wright days shortlog
linux-2.6-stable.git kernel tree ago | log |
tree |
--
linux/kernel/git/stable/ 2.6.11-stable Greg years shortlog
linux-2.6.11.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.12-stable Greg months shortlog
linux-2.6.12.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.13-stable Greg months shortlog
linux-2.6.13.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.14-stable Greg months shortlog
linux-2.6.14.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.15-stable Greg months shortlog
linux-2.6.15.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.16.x kernel Adrian Bunk weeks shortlog
linux-2.6.16.y.git tree ago | log |
--
linux/kernel/git/stable/ 2.6.17-stable Greg months shortlog
linux-2.6.17.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.18-stable Greg months shortlog
linux-2.6.18.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.19-stable Chris Wright months shortlog
linux-2.6.19.y.git kernel tree ago | log |
--
linux/kernel/git/stable/ 2.6.20-stable Greg days shortlog
linux-2.6.20.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ 2.6.21-stable Greg days shortlog
linux-2.6.21.y.git kernel tree Kroah-Hartman ago | log |
--
linux/kernel/git/stable/ -stable patch Greg days shortlog
stable-queue.git queue Kroah-Hartman ago | log |
tree |
--
linux/kernel/git/wtarreau/ stable GIT repos Willy Tarreau months shortlog
linux-2.4-stable.git ... ago | log |
tree |
Hány stable is van akkor? Írjam amolyan jóféle Gabu stílusban, hogy stable is linugz-2.6.19.23.45-m3izthal33tkernalh4x0r-stable? Most akkor mégsem építette le magát a Bunk gyerek? És mi van a Piotrowski fószerral? És -- mindamellett, hogy kétségtelenül örül a kernel közösség az efféle erőfeszítéseknek -- mennyire van elfogadva ez (melyik ez?) mint autentikus stable?
Mennyire bevett "ez" a disztróknál mint a saját vendorkernel alapja?
Nem mondom, hogy adott esetben ne lehetne mindezekre a kérdésekre megnyugtató választ adni, de akkor:
- jöjjön valaki és mondja meg az igazat, ne csak a valódit
- azt legalább ismerjük be együtt, kézenfogva, hogy a Linux development névtér kezelése vicc
My sense of humour is often too subtle to cope with getting smileyd.
Please don't take it personal.
- A hozzászóláshoz be kell jelentkezni
week ago.
A kijelentés arról szólt, hogy nem ő írja hiba listát, 2.6.16 -ot viszi tovább.
"Mennyire bevett "ez" a disztróknál mint a saját vendorkernel alapja?"
Nem tudom.
De sokan használják, akik nem vendortól szerzik a stable kernelt. (Én is, van ahol ezt használom)
- A hozzászóláshoz be kell jelentkezni
Koszonom annak, aki beirt vmi csodalatos url-t es harom kepernyore szelesre huzta szet a topicot :(
Gondoltam, atolvasom, de kurvara semmi kedvem minden hozzaszolasnal scrollozni :(((
- A hozzászóláshoz be kell jelentkezni
Bocsi!
Weee!
- A hozzászóláshoz be kell jelentkezni
Koszi :)
(Nem tudtam ki volt, de par perc mulva ujra ranezve a topicra, mar szepen olvashato volt)
- A hozzászóláshoz be kell jelentkezni
Szerintem dzsekijo történelmi párbeszéde a pre tagek között tette ezt, nem a link. Gyanítom trey írta át utána döltre... ;)
- A hozzászóláshoz be kell jelentkezni
Én voltam, nem linkkel, hanem "egybefüggősokszóval".. :) Már alig fértünk. De hát inkább olvasható legyen.
Weee!
- A hozzászóláshoz be kell jelentkezni
+1
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
Így van.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Najo, hat latom, sikerult ezzel a forkkal kicsit elvennem a stable agtol a bugreportot, de mint kiderult, a tracker jol mukdott es kiderult a hiba oka+ azonnal szuletett ra megoldas :)
- A hozzászóláshoz be kell jelentkezni
Elég népszerű ez a thread (300 hozzászólás), pedig Gabu még itt sincs. :)
- A hozzászóláshoz be kell jelentkezni
Es mennyivel emeszthetobb, emberibb formaja van a hozzaszolasoknak, nyugodtabb es ervekkel teli. BTW megint elertuk, hogy keves a max. 300-as limit drupalban. Sosem fogom megerteni miert kell ilyen hardlimiteket kitalalni...
- A hozzászóláshoz be kell jelentkezni
Én átállítottam valami ezerre, azóta nincs gondom.
Viszont igen hasznos lenne, ha az új hozzászólások gomb valóban csak azokat mutatná...
- A hozzászóláshoz be kell jelentkezni
[off]Bocs, az offért, de be lehet állítani valahol, hogy fix 1000 legyen mindig? Már kerestem, de nagyon még nem találtam.[/off]
___
A backup olyan mint a sör. Egy backup nem backup, két backup fél backup, három backup egy backup. Egy backup nem backup...
- A hozzászóláshoz be kell jelentkezni
Nem is tudom hol állítottam. Az biztos, hogy egy legördülő menüből lehetett választani. De olyan sajnos nem volt, amilyen nekem kellett, úgyhogy kézzel paramétereztem fel a beállítóoldalt (bemenet ellenőrzés rulez) és azóta jó.
- A hozzászóláshoz be kell jelentkezni
En az elobb probaltam wget-tel postolni (cookie-t is kuldtem), es 300 alatt teljesen jo, am 300 felett mar nem engedi beallitani. Most mar mintha lenne bemenet ellenrozes... :-/ (ami amugy jo, csak most bosszanto)
- A hozzászóláshoz be kell jelentkezni
Bárcsak forkolná valaki a projektet. Lehetne a neve Stabilux:)
- A hozzászóláshoz be kell jelentkezni