A jelenlegi helyzet messze van az ideálistól a Google számára: jelentősen le vannak maradva az aktuális kernelkiadástól és ebből kifolyólag problémás a kernelfejlesztői közösséggel a problémáikról beszélni.
Körülbelül 30 mérnök dolgozik a Google-nél az általa használt kernelen. Jelenleg úgy dolgoznak, hogy betolják a változtatásaikat a forrásfába, majd elfeledkeznek róla az elkövetkező 18 hónapban. Ez a módszer egyes esetekben valós karbantartási problémákhoz vezet. Gyakran előfordul, hogy a fejlesztőknek kevés fogalmuk van arról, hogy mi is van a Google-féle kernelfában.
Amiben azért jócskán van minden. A Google a 2.4.18-cal kezdte, de megfoltozott benne több mint 2 000 fájlt, hozzáadva a vanilla kernelhez kb. 492 000 sornyi kódot. Egyebek mellett visszaportolták a 64 bit támogatást. Aztán váltottak a 2.6.11-re, főként a SATA támogatás miatt. Ezt követte a 2.6.18, most pedig a 2.6.26-ra váltást tervezik.
Jelenleg 1 208 patch-ük van a 2.6.26-hoz, ezek körülbelül 300 000 sornyi kódot adnak a kernelhez. A változtatások durván negyede új szolgáltatások visszaportolása.
Ezen az egészen akar változtatni a Google. A Google kernelcsapat jobban együtt akar működni a kernelfejlesztőkkel. Git-re váltanak, a fejlesztők saját fában tartják majd a változtatásaikat. Ezek a fák negyedévente az aktuális mainline kernelre állnak majd át, s ez feltehetően motiválja majd a fejlesztőket arra, hogy a kódjuk még karbantarthatóbb és még mainline kernel-közelibb legyen.
Linus feltette a kérdést, hogy miért nem az upstream kernelben tartják karban ezeket a patch-eket? Talán azért, mert a Google zavarba jönne miattuk, vagy mert titkos anyagok vannak bennük, amelyeket nem akar közreadni, vagy ez belső folyamati problémák kérdése? A válasz egy egyszerű "igen" volt. Vannak benne ronda kódok, amelyek még a 2.4.18-tól jöttek. Vannak kétségek náluk afelől, hogy mennyire lenne a világ számára hasznos ezen kódok kiadása. De végső soron ezen kódok fele feltolható lenne az upstream kernelbe.
További részletek az LWN cikkében.
- A hozzászóláshoz be kell jelentkezni
- 6191 megtekintés
Hozzászólások
Arra azért kíváncsi leszek, hogy a Google milyen hatással lesz a kernelre. Mennyiben fognak megváltozni a mostani erővonalak (Ingo - RedHat, IBM fejlesztők).
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Szerintem annak kijelentése, hogy a mostani fejlesztési modell egy kín elég nagy pofon. :)
suckIT szopás minden nap! 2010 az IPv6 éve lesz
- A hozzászóláshoz be kell jelentkezni
Csak nekem jött le úgy hogy a Google kernel klubban fejetlenség és káosz uralkodik? Ejnye..
_______________________
Ubuntu
- A hozzászóláshoz be kell jelentkezni
nem csak neked, mindenkinek, aki mostanában szívott a gmail kiesések miatt. legfeljebb ők nem tudták, hogy konkrétan mit kellene hibáztatni.
ez így kupleráj, amit írtak...
- A hozzászóláshoz be kell jelentkezni
Én azon lepődtem meg, hogy kiállt és szétkürtölte, hogy milyen szarul csinálják. Igaz, már tervezik a változtatást, de azért ezt akkor sem szokás.
Vagy ez az alázás a konkurencia felé, hogy még így is legyűrik őket? (lol) :-)
- A hozzászóláshoz be kell jelentkezni
nem értem miért meglepő, nem akarok példákat hozni de mindig is bevált, divat volt szidni magunkat bizonyítva ezzel hogy ettől jobb lesz a marketingben, politikában, üzleti életben, mindenhol
- A hozzászóláshoz be kell jelentkezni
a bazar is kupleraj :)
--
B+ - http://pozor.hu
- A hozzászóláshoz be kell jelentkezni
loal
nemtudom olvastad-e, h mi volt a gmail kieses oka, normalisan elmagyaraztak. es bar nem tisztem vedeni a googlet, ez igy, amit irtal, eros FUD
- A hozzászóláshoz be kell jelentkezni
Bocs, félreérthető voltam. Nem a google nem tudta, hogy kit kell hibáztatni, hanem azok az átlag userek, akik nem érték el a gmail accountjukat és éppen nem olvastak it hírportálokat a problémával kapcsolatban.
- A hozzászóláshoz be kell jelentkezni
es meg igyis jobb az SLAjuk, mint a pistike mailszerverenek, ami adslen csung ;-)
btw, google apps premier SLA 99.9%, es en nem tapasztaltam apps allast mostanaban
- A hozzászóláshoz be kell jelentkezni
szeretném hinni, hogy Steve Blood, Inc, és google mail vagy google apps között van még arany középút. és osztom mások véleményét, hogy céges infót nem rakunk gugliba.
- A hozzászóláshoz be kell jelentkezni
ok, akkor nincs mirol beszelnunk. :)
- A hozzászóláshoz be kell jelentkezni
Szeretem az ilyen hozzászólásokat. Valaki elmondja, hogy hogyan csinálják, tudják, hogy mi a szar vele. Tudják, hogy merre tovább és jön valaki és zsigerből leszarozza... Szép. Szép. Nem szeretnék veled dolgozni. :)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
A 2.4.18 nem mostanában volt... és ha már a google annyi mindent lenyúl az emberektől, azt a megfoltozott 2000 fájlt, a beleölt tudást miért nem lehet visszaadni a linuxos közösségnek, ha már betegre keresik magukat linuxra alapozott technológiával?
Értem én, hogy a licenszek betűjét nem sérti, de nem tudok szabadulni a gondolattól, hogy a szellemét igen...
- A hozzászóláshoz be kell jelentkezni
mert nincs szukseguk arra, hogy aztmondjak nekik hogy szar az otlet, a google utana fel evig reszelje, hogy a fejleszto
urasagok minden perverz vagyat kielegitse, aztan megse olvasszak be...
...majd egy het mulva ingo bejelenti a szuperinnovativ otletet, ami lenyegeben ugyanerre jo, csak veletlen sem kompatibilis :-)
- A hozzászóláshoz be kell jelentkezni
Ez fincsi volt. :)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
akkor a bugreportokat küldjék be, a feature requesteket meg oldják meg házon belül. engem már ez is segített volna.
- A hozzászóláshoz be kell jelentkezni
olyan bugreportokra gondolsz, mikor megirjak hogy szar a scheduler desktopra, ingo meg leteszteli a 4/8/whatever magos szerveren, majd kijelenti hogy "nincs itt semmi baj"?
- A hozzászóláshoz be kell jelentkezni
NagyZ, neked nagyon a bögyödben van Ingó tesó. :) Bár, kétségtelen, hogy védi a mundér becsületét rendesen :)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Nem csak neki :(
- A hozzászóláshoz be kell jelentkezni
Nekem semmi bajom vele. Ő is csak valakinek az utasításait hajtja végre. :) Bár, az, hogy a ck kernel miatta halt meg én se tudom feledni. Eléggé sokáig használtam azt a kernelt, és nagyon szépen muzsikált tőle a gép. Sokkal szebben, mint a normális kerneltől.
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
Engem zavar az, ahogyan bánik ck-val (lásd pl BFS esetét). A -ck kernelt nagyon sajnálom, sok-sok évig futott nálam, és használtam nagy megelégedéssel.
- A hozzászóláshoz be kell jelentkezni
Tudsz nekem linkelni valamit? Igazán érdekel a dolog.
Tudom hogy a Google a barátom de nem biztos hogy elmondja amit szeretnék.
- A hozzászóláshoz be kell jelentkezni
eleg a hupon visszanezned, vagy ck blogjaban..
- A hozzászóláshoz be kell jelentkezni
lehet, hogyha a gugli reportolna valamit, más lenne a leányzó fekvése, nagyobb nyomatéka lenne... btw, amikor én bugreportoltam Ingónak, azokat megoldotta... mondjuk azt, amit a 2.6.18-as kernelnél mondtam rájuk, nem tették volna ki az ablakba, ha megtudják:)
- A hozzászóláshoz be kell jelentkezni
Igen, mondjuk amikor én reportoltam, az is megoldódott. Csak az volt kicsit fura, hogy azt a commitot, amiben elromlott, azt is egy benchmark támasztotta alá, azt a commitot, amiben megjavult, azt is egy benchmark (másik fajta benchmark egyébként), arról meg nem volt szó a commit szövegben, hogy egyébként ez azt is bugot is fixálja, hogy ne ragadjanak le egy CPU-n a processzek...
Szóval jó ez a mérjük az eredményt hozzáállás, csak nem egy benchmarkot kéne nézni, hanem valahogy különböző fajta komplex workload-okat...
- A hozzászóláshoz be kell jelentkezni
In the area of CPU scheduling, Google found the move to the completely fair scheduler to be painful. In fact, it was such a problem that they finally forward-ported the old O(1) scheduler and can run it in 2.6.26. Changes in the semantics of sched_yield() created grief, especially with the user-space locking that Google uses. High-priority threads can make a mess of load balancing, even if they run for very short periods of time. And load balancing matters: Google runs something like 5000 threads on systems with 16-32 cores.
lwn-es cikkbol ;)
___
info
- A hozzászóláshoz be kell jelentkezni
Az irónia benne, hogy a O(1) ütemezőt is Molnár Ingo írta.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Te biztos, hogy az én postomra válaszoltál?
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
- A hozzászóláshoz be kell jelentkezni
igen, arról szerettem volna írni pár gondolatot, hogy az kevés, hogy tudják, mi nem stimmel, ha ezt már 2002. február 25. óta, a 2.4.18-as kernel kiadása óta tudják, ezt 2009-ben elismerni számomra nem előrelépés. 7 és fél évet ülni egy ekkora ügyvitelszervezési tévedésen, nekem furcsa.
az is furcsa, hogy kiderült, ők belepiszkálnak a kernelbe és ennek eredményét én nem élvezhetem. pedig biztosan hasznomra vált volna, hogyha több százezer, ekkora terhelést elviselő gépből leszűrt tapasztalatok a kernel forrásba visszapakolás során nálam is megjelennek az én szerveremen.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
az is furcsa, hogy kiderült, ők belepiszkálnak a kernelbe és ennek eredményét én nem élvezhetem
gondolom neked is a pinceben egy nem tudom hany csillio node-os server van ...
iszonyat tudnad hasznalni, amint meg mar feljebb is irtak - talan NagyZ - amire be lehetne olvasztani a kernelbe, annyi ido alatt google-ek lekodolnak egy masik problemara egy megoldast, es a nem mar letezo megoldast kell minden egyes valtozashoz hozzaigazitani. ha megfigyeled a cegek nem a verjuk a faszunk a legujabb linux-next-next-next kerneleket hajtjak, hanem valami regebbi verziora portolnak vissza csomo dolgot, lasd google pl-ja, de akar Red Hat vagy barmelyik production ceg, ubuntu nem jatszik, mert az egy vicc..
amugy ha meg annyira kellenek azok a patchek, akkor irj a google-nek, nagy valoszinuseggel odaadjak, _ha_ latjak, hogy valoban szukseged van rajuk....
___
info
- A hozzászóláshoz be kell jelentkezni
"hany csillio node-os server"
A Google nem használ szuperszámítógépeket a híradások szerint, csak átlag alatti PC-ket.
"amugy ha meg annyira kellenek azok a patchek, akkor irj a google-nek, nagy valoszinuseggel odaadjak, _ha_ latjak, hogy valoban szukseged van rajuk"
Ezt te sem gondolhattad komolyan.
suckIT szopás minden nap! 2010 az IPv6 éve lesz
- A hozzászóláshoz be kell jelentkezni
node alatt a dzsunka pc-t ertettem ebben az esetben
___
info
- A hozzászóláshoz be kell jelentkezni
Aha. A pincémben tényleg van belőle egy csomó. Ami működik 500 ezer mezítlábas trágya pécével, az működik tízzel is.
suckIT szopás minden nap! 2010 az IPv6 éve lesz
- A hozzászóláshoz be kell jelentkezni
egy módosított energiaellátású, egyébként mezei gigabyte alaplapot használnak, amit saját tervezésű és gyártású dobozkába tesznek. számítógép háznak nem nevezném a kinézete alapján, bár a funkciója az. van melléhekkelve egy akksi.
kinézetre eléggé dzsunka pc-nek néz ki, le is köpködhetné az ember, ha nem tudná, hogy az energiahatékonysága jobb, mint a szokásos cuccoknak.
A fontosabb szervereim ibm x3650-esek, most cseréltük áprilisban őket. pusztán a kinézetet tekintve sokkal profibbak, mint a gugli gépei. A kevésbé fontos gépeim is ibm szerverek, nem hiszem, hogy joggal lehetne dzsunkapc-zni a rendszert...
- A hozzászóláshoz be kell jelentkezni
Pedig technikailag valószínűleg az. :)
http://www.kislexikon.hu/dzsunka.html = kínai. Pécé=8086 leszármazott.
Dzsunkapécé. :)
suckIT szopás minden nap! 2010 az IPv6 éve lesz
- A hozzászóláshoz be kell jelentkezni
1. gyalog pc-ket használnak (pontosabban majdnem gyalog pc-ket)
2. hagy döntsem el én, tudnám-e használni
3. simán találhatnak olyan kernel-részterületen bugot, ami nem google specifikus és esetleg engem is érint.
- A hozzászóláshoz be kell jelentkezni
http://lwn.net/Articles/357658/ :
" Google has a number of "pain points" which make working with the community harder. Keeping up with the upstream kernel is hard - it simply moves too fast. There is also a real problem with developers posting a patch, then being asked to rework it in a way which turns it into a much larger project. Alan Cox had a simple response to that one: people will always ask for more, but sometimes the right thing to do is to simply tell them "no." "
Szerintem ez egy elég korrekt válasz a kérdésedre.
- A hozzászóláshoz be kell jelentkezni
Értem én, hogy a licenszek betűjét nem sérti
Én még abban se vagyok biztos, hogy nem... Tekintve, hogy továbbra is kétkedve fogadom, hogy a Google Appliance vanilla kernelt futtat.
- A hozzászóláshoz be kell jelentkezni
Vegyünk egyet, és köpjük be őket a terrorkommandónak. :)
Ja, az nem jó, mert akkor ők keresnek vele. Pereljünk akkor mi.
suckIT szopás minden nap! Van-e a Google-nek szerverparkja Magyarországon?
- A hozzászóláshoz be kell jelentkezni
lehet különböző kernel a kis dobozon meg a nagy szerverfarmon...
- A hozzászóláshoz be kell jelentkezni
az nem vitás, sőt 100% biztos, hogy így is van... a kérdés csak az, hogy a kis dobozon olyan kernel van-e, amelyet még a fejlesztői is csak egy nyers alapanyagnak tartanak és a disztribúciók készítőira hagyják a komolyabb tesztelést és stabilizálást.
- A hozzászóláshoz be kell jelentkezni
A 2.6.18-as egy jól sikerült kernel volt. A RedHat is arra épít, a Google is arra épít.
Vajon melyik lesz a következő ilyen?
- A hozzászóláshoz be kell jelentkezni
Arról a 2.6.18-as kernelről beszélsz, amiben akkora raid bug volt, mint ide Hanoi? Erre csak olyan jelzőket tudnék mondani, ami az én itt megszokott stílusomhoz képest is alpári...
Konkrétan (nem így jelölik, de most a pontosság kedvéért): a 2.6.18.0-ról beszélünk, ugye?
Abból az időszakból a 2.6.16-os sorozat volt jó, nem véletlen, hogy 62-ig patkolták, ha jól emlékszem.
hivatkozás: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18.1 fájlban a raid szó első előfordulására kéretik rákeresni.
- A hozzászóláshoz be kell jelentkezni
ezek után kíváncsi lennék, hogy az MS-nél egy hasonló fejlesztői kinyilatkozás alkalmával mekkora fejetlenségekre derülne fény? Persze lehet, hogy ott minden rendben és sorról-sorra dokumentált és a felsőbb irányítás viszi rossz felé a projekteket...
- A hozzászóláshoz be kell jelentkezni
Az MS-nél sokkal nagyobb a rend, és azt sem mondanám, hogy rossz irányba mennek a projektjeik.
- A hozzászóláshoz be kell jelentkezni
szerintem erre ne igen fogadj. a projektes kijelentésedet most nem érintem, mert kinek ez, kinek az a jó irány. de a sokkal nagyobb a rend kijelentés szerintem erős túlzás. főleg így, kibökve a tutit ;)
--
xterm
- A hozzászóláshoz be kell jelentkezni
Szerintem Stallman meg röhög a markába.
Ha v3-ra váltott volna a kernel, akkor ezt most nem lehetne.
Csakhogy a v2 nekem is szimpatikusabb.
- A hozzászóláshoz be kell jelentkezni
lol, stallmant ide keverni...
- A hozzászóláshoz be kell jelentkezni
A microsoft má úgyis itt van. :) Jó társaság lesz ez. :)
--
Fight / For The Freedom / Fighting With Steel
- A hozzászóláshoz be kell jelentkezni
Milyen különbség van a v2 és a v3 között, ami itt számít?
- A hozzászóláshoz be kell jelentkezni
wait, nem vagyok nagy licencguru, de így hirtelen illogikusnak hat számomra, hogy ha valaki magának írogat a kódba, miért is kéne publikálnia?
—-—-—
int getRandomNumber() {
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni