OSWatershed.org - melyik disztró mennyire elavult?

Linux

Scott Shawcroft nemrég bejelentette az OSWatershed.org-ot. "Az OpenSourceWatershed egy olyan projekt, amelynek célja megérteni a kapcsolatot a disztribúciók (downstream) és az egyes szoftverösszetevők (upstream) közt. Ez az alapja egy, a disztribúciókról és azok fejlődéséről szóló tanulmánynak. Ez a disztrológia. A jövőben további disztrókkal kapcsolatos statisztikák lesznek elérhetők. [...] Most keress a jobb felső sarokban a kedvenc csomagodra, hogy megláthasd mennyire friss az a különböző disztribúciókban."

Scott elkészített egy összegzett analízist egy általa összeállított, 20 csomagot tartalmazó csoporton (Scott's Chosen 20): 


alsa-utils      httpd (apache)
cups            kdebase
emacs           linux
firefox         NetworkManager
gcc             openssh
ghostscript-gpl pidgin
gimp            postgresql
glibc           python
gnome-desktop   ruby
gnupg           xorg-server

A csoport alapján készített két táblázatot, amelyek azt hivatottak mutatni, hogy a jelenlegi (current) és jövőbeli (future) disztrók mennyire (hány százalékban) "elavultak".

A táblázata alapján az Arch Linux a legkevésbé "elavult," mindössze csomagjainak 45%-a marad el a legfrissebb kiadásoktól. Ezzel szemben, az derül ki a táblázatból, hogy a Debian és az openSUSE csomagjai 95%-ban "elavultak".

A projektről bővebben a szerző OSCON-on tartott beszédét összefoglaló diasorban, illetve a projekt weboldalán. A weboldalon működő keresővel könnyen kereshetünk bizonyos csomagra, például a firefox-3.5-re.

Nem feltétlenül baromság. Nekem például webfejlesztés során többször okozott problémát, hogy a cég Debian linuxos szerverein a csomagok elavultak voltak, pedig szükségem lett volna a frissebbekre. Ez most a Lenny megjelenésével szerencsére javult, de félek, hogy most megint 1-2 év kényszerszünet következik.
--
kövi

"Ez most a Lenny megjelenésével szerencsére javult" persze a Lennyben elavult volt már pár csomag akkor mikor kijött, és nem is mindenki frissítette a szervert. azóta a helyzet romlik minden pillanatban :( pl kíváncsi leszek mikorra fog az 5.3-as php például odáig eljutni hogy alapértelmezett lesz az esetek 95%-ában.

Mondjuk a stabil debian kiadásba a hibajavításokat szépen backportolják.

Szóval biztonsági szempontból elméletileg nem marad el a nagyonfriss csomagoktól, csak esetleg feature-ökben.

Cserébe viszont nem változik a konfigurációs fájl formátuma, meg upgrade után is bootol a rendszer.

Nem véletlenül hívják stable-nek.

És persze ha valakinek a stabilitás nem szükséges, akkor tolhat unstable vagy experimental csomagokat, senki nem akadályozza meg.

igen. lehet backportolni is (ami egyébként egyáltalán nem olyan triviális, mint amilyennek tűnik, főleg ha nagy a rés a verziók között vagy nagy szoftverről van szó...), de az magától nem történik meg.

a másik, a stable/maintenance branch használata, ahol van.

vector viszont nem ezekről beszélt, csak szimplán azt mondta, hogy ne használjunk új verziót, és akkor az nekünk jó. ja nem, pontosabban azt mondta, hogy az új verzió öngyilkosság. márpedig pl. maintenance verziónál nem látom be, hogy miért ne a legújabbat használnánk.

na mindegy.

szerintem.

Ennek több oldala van. A blackPanther OS-ben, és szerintem egyik más disztróban sincs szükség a legújabb és legnagyobb verziójú programokra. Ezek a Windows-ról frissen áttért verzió-függők agymenései. Egy rendszerben a legjobb, legstabilabb -szerver környezetben pedig kiemelten a-, legbiztonságosabb programra van szükség. Az esetek nagyon nagy többségében ezek egyike sem mondható el a legújabb verziókra. Különös tekintettel az utolsó feltételre, ami aztán végképp nem jellemző, nem kiforrott, stb. Lásd: über új kernel, firefox, php, ....

A blackPanther-ben ettől függetlenül, a lehető legújabb, de használható csomagok vannak, és bár elérhető pl az új firefox-3.5.1, az nem kerülhet a repóba amíg biztonsági kockázatot jelent.

----- www.blackpanther.hu -----

"Ennek több oldala van."

kb. eddig van értelme a post-odnak. a többi meg a te egyéni preferenciád a disztró csomagolás bibliájaként beállítva (pl. kíváncsi lennék, mély bölcsességedben hogy tudod megállapítani az összes csomagnál, hogy melyik verzió a legjobb, legmegbízhatóbb, legkiforrottab, meg az a sok leg, amit még sikerült hirtelen felsorolni, illetve ha nem esik egybe, akkor mit csinálsz).

szerintem.

-1

A frissesség és a használhatóság nem mindig jár együtt. Ha ez így lenne, akkor senki nem használna RHEL-t, SLES-t, vagy Ubuntu LTS-t. Pl. hiába van már kint a 2.26-os Evolution, nem frissíthet mindenki arra, mert új Gnome kell hozzá. De egyrészt nem biztos, hogy az új Gnome jobb, mint a 2.22-es, másrészt millió más csomagot föl kell húzni, és bármelyikben lehet hiba.

"hogy tudod megállapítani az összes csomagnál, hogy melyik verzió a legjobb, legmegbízhatóbb, legkiforrottab"

Talán tesztelésekkel? És nem úgy ahogy a legtöbben elképzelik, hogy fogom a 0.1 release-val magasabb verziót és behúzom a disztri alá. Emiatt van az, hogy egy-egy programból akár 2-20-~ release is készülhet mire a rendszerbe bekerül. Feljebb van egy Evolution-os példa, de a gyakorlatban ennél sokkal durvább konfliktusok és problémák is felmerülnek. A fejlesztésekre jellemző, hogy újabb és még ismeretlen feature-val bővülnek a programok amelyek még ismeretlen hibákat eredményeznek. Ezek a felhasználóknál pont akkor jelentkeznek mikor elkezdenek frissítgetni eszement módon.

"illetve ha nem esik egybe, akkor mit csinálsz"
akkor van az, hogy egy előző verzióval vagy másik programmal kell megoldani a szolgáltatását a programnak.. Ismét Evolution példa: Az új evoban olyan bugok vannak (pl nem ment a címlista gomb a címmező mellett), ami miatt nem került be a disztribe, pedig évek óta az alapértelmezett kliens volt. Helyette Thunderbird testreszabott változata került be, amibe olyan dolgokat építettem ami megpróbálja pótolni az Evo-t...

----- www.blackpanther.hu -----

arra próbáltam rávilágítani, hogy ami szerinted így van, az krvára nem biztos, hogy a user szerint is így van (már ha beszélhetünk userről a bpos esetében:). pl. a user azt se díjazná különösebben, ha csak úgy kukázod az email kliensét, mert most így szerinted jobb.

a tesztelést meg áruld már el nekem, hogy milyen módon futtatod le x ezer csomag esetén, ami megmondja neked, hogy az n. verzió az a "legjobb", vagy hogyan döntöd el, hogy az m. verzió a "legbiztonságosabb" ? itt az lett volna a poén, hogy az általad felsorolt jelzők nem tesztelhetők, hanem max. egy egyénileg kialakult vélemény. te meg ez alapján csomagolsz. zsír.

szerintem.

"(már ha beszélhetünk userről a bpos esetében:"
?

"user azt se díjazná különösebben, ha csak úgy kukázod az email kliensét, mert most így szerinted jobb"
Nem jobb hanem jó és használható. De, hogy ne szenvedjen hiányt repóból elérhető, viszont a hibásan működő program nem jó, ha a core rendszer része...

"a tesztelést meg áruld már el nekem, hogy milyen módon futtatod le x ezer csomag esetén"
Az összes programot tesztelem, most csak négy különböző környezetben, de ha kell 10-ben is. Pl a kész rendszert ~30 helyen teszteltük mire kikerült a teszterekhez. Persze biztonsági oldalról én is a közösségi információkra hagyatkozom de feltétlenül igyekszem beépíteni olyat, ami már máshol is átment a szűrőn és pl. nem építek be 0.-k release-t (KDE-4.0 vagy Firefox 3.5.0, stb, stb)

"egy egyénileg kialakult vélemény"
Tény, de bevált. És ettől még amit az oldal erőltet, egy baromság. Szerintem

Ui: nálam is van példa egyébként olyanra, hogy bekerült hibás program, mert a kiadásig nem lett belőle final. K3B
----- www.blackpanther.hu -----

ahha jó, akkor hajrá, csomagolj ízlés szerint

"amit az oldal erőltet, egy baromság."

mit erőltet? és miért baromság? a válasz előtt ajánlom figyelmedbe ezeket, a DRY jegyében:

http://hup.hu/cikkek/20090721/oswatershed_dot_org_melyik_disztro_mennyi…
http://hup.hu/cikkek/20090721/oswatershed_dot_org_melyik_disztro_mennyi…

szerintem.

A szerver résszel egyetértek, de desktopon sajnos a biztonságot fel kell áldozni néha a használhatóság oltárán: sok végfelhasználói programból egyszerűen muszáj a legújabbat használni a Windows-os szoftverekkel való egyre jobb kompatibilitás miatt.

OpenOffice-ból pl. egyszerűen _kell_ a legújabb mindig, mert tetszik vagy sem, akárhová fordulsz, mindenhol .doc, .xls, .ppt meg legújabban .docx kiterjesztésű fájlokba botlasz. És az OOo tényleg fejlődik, érdemes mindig váltani.

A böngészők motorjai is folyamatosan fejlődnek, sokkal több oldalt képesek normálisan megjeleníteni a mostaniak, sokkal jobban követik a szabványokat is, mint akár másfél évvel ezelőtt.

Ami engem illet, az utóbbi 5-6(!) évben semmi okom nem volt magát az OS-t upgradelni, mégis mindenből feltettem a legújabbat, mert a végfelhasználói programok a Linuxokban annyira bele vannak drótozva az OS többi részébe, hogy képtelenség gányolás nélkül frissíteni őket. Ami leginkább fáj az az, hogy muszáj az LTS kiadásokat is eldobnom fél-egy év után a fenti problémák miatt. Ha lenne olyan disztró, ami _hivatalosan_ és _letesztelve_ támogatja a legfontosabb felhasználói programok backportolását long term support mellett, az nagyon jó lenne.

Persze, nem is úgy értettem, hogy használjunk KDE1-et mert az tutti jó. Dehogy, csak van egy határ amit most ez a portál erőltet és azt suggalja, hogy át kell lépni. Pedig nem szabad. Az OOo-ból, is tökéletes a 3.0 és akkor érdemes a 3.1.1-re frissíteni, ha meggyőződtél arról, hogy a frissítés nem-e az ellenkezőjét eredményezi mint amire számítasz. (pl valamelyik OOo release el sem indult, ha első alkalommal akartad indítani, mondjuk frissítésre jó volt :D))

----- www.blackpanther.hu -----

Kissé pontatlanul fogalmaztam:

Először is az elavultságszámlálásos dolog hidegen hagy, én mindig Debian-t vagy egyéb, LTS kiadásokkal is rendelkező disztrót használtam ha csak tehettem. Mindig csak 1-2 dologból kellett az újabb, a rendszer 99%-a pont úgy elműködött volna az 5 évvel korábbi csomagokkal is.

Másodszor, a legjobb az lenne, ha a backportolt programokat külön néven, külön csomagban szállítanák, és a régi mellé is lehetne telepíteni, nem csak helyette. Persze a konfig fájlokat külön helyre pakolnák, pl. így:
~/.progi/2.4/
~/.progi/3.0/
Ekkor már nem is olyan nagy gond, ha az aktuális verzió épp olyan hogy nem indul, addig ott a stabil, amit az OS egész élettartama alatt meg lehet tartani. Ha meg a lib-ek ütközése a gond, akkor az új verziót lehet a /usr/local-ba vagy az /opt-ba tenni azzal a felkiáltással, hogy az nem az alap kiadás szerves része, hanem csak egy kiegészítő amit a felhasználó a saját felelősségére használ.

Már többször bele akartam ásni magam a csomagkészítés rejtelmeibe, de a Debian-os doksi végigolvasása mindig elvette a kedvemet. Szóval lehet, hogy fentebb hülyeségeket írtam, amit nem is lehet így megcsinálni. :)

Szerk.: természetesen 2-3 hónapos csúszás a backportolásban bőven belefér, tesztelés meg egyebek miatt.

Az a baj, hogy annyira össze van drótozva, hogy pl egy régebbi gtk-s programra downgradelés egészen visszanyúlik a glibc-ig és visz magával több core alkalmazást, olyat mint a perl-t, python-t és ezekkel csomagok ezreit. (persze most nem a 2.26 helyett 2.25-re gondolok, hanem mondjuk 2.8-ra) Innentől kezdve meg már értelmetlen, szinte olyan, mintha egy külön disztrit futtatnál a local-ból, ráadásul voltak kódlap váltások, gcc cserék, stb. Erre van egy jó példa: pl kylix alkalmazások használata mára lehetetlenné vált..

----- www.blackpanther.hu -----

Nehéz ügy. Nekem már az is nagy könnyebbség lenne, ha konfig fájlok nem keverednének, mert akkor fel tudnám tenni közvetlenül az upstream változatot, amiből sokszor a program írója csinál all-in-one binárist vagy tarball-t. Csak sajnos gyakran a programok újabb verziói ugyanoda pakolják a beállításaikat mint a régiek, és beléjük van drótozva a hely, nem állítható át. Ha nem nekem kéne összevadásznom ezeket a dolgokat a forráskódban, aztán újrafordítani a programokat, az sok szívást megspórolna.

Bizonyos időközönként, alkalmazásoknál és disztrókban (pl. gentoo) van ilyen irányú hajlandóság, de az esetek jelentős részénél ez kivitelezhetetlen (lib-ek, glibc, stb. függelmek folytán). A "mindenből fenn lehet minden verzió" rendszer oltárán szvsz fel kellene áldozni a "nem kell mindenből kettő-három, ellenben használhatunk közös lib-eket" megoldást, no persze szubjektív, hogy kinek melyik áldozat kedvesebb, de valószínűleg az utóbbit többen elleneznék. (még mindig szvsz)

Hát ez mekkora felesleges baromság...

+1
Még ha érdekelne is, hogy melyik disztró a legfrisebb, akkor sem biztos, hogy pont az a 20 csomag lenne fontos. Pl. egy LAMP szerverhez kellő MP (MySQL + PhP) nincs benne a kiválasztott 20-ban. OpenOffice? Valami levelező? Compiz?
Meg aztán a lista alapján még a végén azt gondolnánk, hogy az Arch Linux hű de nagyon friss, és fasza. Pedig hát csak arról van szó, hogy az Arch Linux eléggé minimalista, mint pl. az LFS, vagy a CRUX.

( tiger | 2009. 07. 21., k – 22:10 )

disztrologia. lol. mar varom az egyetemi kepzeseket ezen a teren :D
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

( Csigaa | 2009. 07. 21., k – 22:16 )

Mert a legfrissebb kiadás kell mindig mindenhova? Mi ez a tehénség?

(és ha a Debian 95, akkor a RH hány százalékban elavult? rofl)

Nem az eredmény érdekelt, tudom hogy valami hihetetlen szám lenne. Pont a teszt értelmetlenségét akartam érzékeltetni: a RH-ban a csomagok verziója jó régi, mégis mindig patchelve vannak a legfrissebb hibák ellen is... innentől kezdve értelmét veszti az egész.
A többi disztro is tart fenn saját patch-setet, nem fejvesztve verziót vált mindenből, ha kijön egy javítás.

Ezt valami rolling release-n nevelkedett, nem túl körültekintő ember csinálhatta, ugyanis csak azok esetében van értelme a feltételeinek... de akkor a nem ilyen disztrokat ne tegye bele mert hibás eredményeket kap (ahogy kapott is).

( uid_1526 | 2009. 07. 21., k – 22:39 )

Remélem beleszámít majd az e-penis hosszába.

( kikke | 2009. 07. 21., k – 22:56 )

A letöltésszámláló-ünnepek és verzióbuzeránsok kora ez. Elmúlik.

( _Franko_ v | 2009. 07. 21., k – 22:57 )

Sok értelmét nem látom... :)

Fedora 11 55% obsolete, 8 hetes átlag csomagfrissességgel, 6 hete jött ki.
Ubuntu 9.04 70% obsolete, 11 hetes átlag csomagfrissességgel, 16 hete jött ki.
OpenSuse 11.1 95% obsolete, 27 hetes átlag csomagfrissességgel, 31 hete jött ki.

Hm... ránézésre megjósolható, hogy a Fedora szépen lassan hátrafelé fog mozogni, mivel átveszi a helyét egy éppen frissen kijött másik release alapú disztribúció... :)

A security fixek terjesztési/terjedési sebességéről már érdemesebb lenne ilyen statisztikát készíteni...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

packages.ubuntu.com-on pedig mindeh ubuntu-s látható
packages.debian.org-on pedig minden debian-os látható
archlinux.org/packages-en pedig minden arch-os látható
...

és? ennyi erővel minek distrowatch? a statisztika lényege bizonyos adatokból más adatok előállítása. ez az oldal is pontosan ezt csinálja. ha neked ez fáj, akkor így jártál.

szerintem.

( bervi | 2009. 07. 22., sze – 02:14 )

szerintem érdekességnek jó. egy disztrót úgy se (csak) a frissesség miatt választunk. azon meg nem kéne kiakadni, hogy a $insert_fav_distro_here elavult, mivel a valóság az, hogy tényleg. de ez törvényszerű.

amúgy vicces az 500-as oldaluk :)

Scott has screwed up again. Please try our homepage, send an email or file a bug in trac.

szerintem.

( Nickname | 2009. 07. 22., sze – 07:32 )

Ez az egész olyan, mint a nők
Fiatalt azért tart az ember, mert friss,üde,ropogós egy csomó dolog érdekes benne, mindig meglep(het), sokszor kér j ruhát, sok pénzbe kerül de van amikor néha pánikba esik és az ember csak néz, hogy vajon mit rontott el, de csak mosolyog, mert:
Idősebb esetén tudja mit várhat el, mit kaphat, kevesebb a meglepetés és izgalom ugyan, de néha elmegy fitness-szalonba, kozmetikushoz és akkor kivirul, viszont tud már jól főzni, mosogatni és ne kérdez örökké, tud mindent magától...

A tanulság: két disztró kell, egy olyan, ami 1-2 release ciklussal régebbi és kiforrott no és persze egy friss üde, ami izgalmat és kihívást ad.. :)

( trey | 2009. 07. 22., sze – 08:55 )

Az LWN-ről:

'elavult' ?

Hadd fogalmazzam úrja:
Distro : a disztró %-a tartalmaz bleeding edge & potenciálisan teszteletlen kódot
Arch: 55%
Fedora: 40%
Slackware: 5.89%
Debian: 5%

:) Így is értelmezhető.

--
trey @ gépház

Ez az értelmezés nekem jobban tetszik, de azért rém idegesítő a PHP-t folyton újrafordítani, mert a Debian policy-jébe nem fér bele hogy a PHP-sek forkolták a GD-t, ezért van néhány képkezelő függvény amit a hostolt weboldalak használnának de a standard disztribúcióban nincs benne... :-(

Inkább az a fura, hogy a top5-be nem került bele a Gentoo.

---
;-(

( msandor v | 2009. 07. 22., sze – 08:59 )

nekem nem fáj, hogy valaki erre pazarolta az idejét :-)
véletlenül nem Britt tudós? :-)

ami viszont szemet szúrt, hogy a fedora mindkét esetben 2. lett...

van egy olyan érzésem, hogy ha lényegesen több csomagot vizsgált volna, akkor más lett volna az eredménye

--
by Mikul@s

Ezt most nem egészen értem...

Nyilván egy release alapú disztribúció a kiadásakor a legfrissebb és a következő kiadás előtt a legelavultabb. Nincs igazán köztes állapot, bugfixek nem kerülnek backport-ra, de security fixek igen.

Ebből adódóan éppen most a Fedora a legfrissebb release alapú distribúció, októberben az Ubuntu lesz, novemberben pedig az openSuse.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Továbbra sem értem, miért baj, ha egy szoftver release ciklusa sűrűbb, mint a rá dependáló szoftverek release ciklusa, illetve a disztribúciók release ciklusa. A disztribúcióban lévő gnome az adott gtk-t használja, ha megfelelő a régebbi gtk is, akkor nincs gond, ha nem felel meg, akkor - megfelelő tesztelés után - megoldható backport vagy akár teljes GTK frissítés.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Mit értesz lassabb fejlesztés alatt? Minden projektnek megvan a maga fejlesztési és release ciklusa. Természetszerűen ezek eltérnek, ezzel együtt kell élni.

Továbbá azért találták ki az (OSGi) verziózást, hogy el lehessen dönteni ránézésre a változás jellegét. Lehet hatalmas változás, lehet apróbb javítás, lehet apró bugfix halmaz és lehet security fix. Az alapos teszteléssel és ellenőrzéssel csak a bugfix halmaz mennyiségét tudod csökkenteni, a security fixek jó eséllyel szintén csökkennének, de a felhasználói igények (CR-ek) azonos intenzitással jönnének, és nem feltétlen akar mindenki fél évet várni arra, hogy egy apró igény belekerüljön a szoftverbe.

Létezik olyan release ciklus, amely négyhavonta ad ki egy jelentősebb improvement csomagot, havonta egy jelentősebb bugfix halmazt és hetente apró kis módosításokat, illetve azonnal security fixet. Ez hetente jelent új verziót, és a felhasználók el tudják dönteni, hogy hetente, havonta vagy négyhavonta akarnak frissíteni.

Attól, hogy valamiből újabb verzió jön ki, nem kötelező frissíteni és kipróbálni.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

"Attól, hogy valamiből újabb verzió jön ki, nem kötelező frissíteni és kipróbálni."

Na ez a lényeg, viszont ennek a portálnak nem ez a célja, hanem pontosan azt erőlteti, hogy ha tolod be a nagy verziókat "akkor te über friss vagy".
Egyébként itt és még sok helyen az a baj, hogy emiatt a tempó miatt mire kiforrná magát egy szotver, egyszerűen teljesen más irányt vesz a fejlesztés és a kiforrott vonalat felváltja egy még új, de járatlan "út". (lásd pulse, xorg, stb)

----- www.blackpanther.hu -----

Szerintem a xorg nemhogy időben jött, hanem már sokkal korábban kellett volna nekikezdeni. Így is bűnlassú és bűngány az X, és az Xfree86 időkben mégintkább az volt. Szóval a változás nem mindig hoz rosszat.

A gtk teljesen más tészta, kezdik átportolni bele a mindenféle gnómos dolgokat, ami annyira nem tetszik, de ahogy mondani szokás, ha nem tetszik, forkolj és vidd tovább az eredeti elképzelést.
---
;-(