Ubuntu a Linux disztrók királya 2006-ban?

Ubuntu

Az OSNews szerint az Ubuntu a 2006-os év Linux disztró királya. A Google Trends szerint biztos, de régóta az első helyen áll a DistroWatch látogatottsági statisztikájában, és az OSNews belső felmérése szerint is. Ezt látszik megerősíteni a HUP Olvasók Választása Díj szavazása is, ahol az Ubuntu szintén az első helyen áll jelenleg.

( atya | 2006. 12. 10., v – 13:21 )

trey, hogy jelenhetett meg ez a cikk délután 2:08-kor, amikor most még csak 1:21 van? Vagy ez nem magyar idő?

( ng | 2006. 12. 10., v – 13:31 )

Éljen a nagy kerál! Csak most már jó lenne ha menne rajta a tv kimenet meg a wifikátya. Egyéni szocproblem.

Nekem ugyanez tök jól megy edgy-vel csak olyan progit nem találok ami kde-n csatlakozik staikus ip-s wlanra.
Leszeded ezt:
http://prdownloads.sourceforge.net/ieee80211/ieee80211-1.1.14.tgz?downl…
meg ezt:
http://prdownloads.sourceforge.net/ipw3945/ipw3945-1.1.2.tgz?download

leszedhetsz frissebbet is de nem biztos hogy fog menni. Néha annyira nem kompatibilisek a driverek hogy örülj ha találsz egy párt ami működik. az 1.1.2 és az 1.1.4 egy működő duett =)

kiszedsz a kernelből mindent ami ieee80211 (még modulban se legyen ott)

kitömöríted mindkét tgz-t. Az ieee80211-ben make;make install utána ugyanez az ipw3945-ben is. Majd beírod hogy load és már megy is az eth1 vagy amennyi hálókártyád van +1 =)

de megértelek én is napokat szívtam vele mert kevés volt a türelmem

ja igen és ha így sem megy nyiss meg szerkesztésre az ipw3945-ben minden olyan fájt ami .c vagy .h kiterjesztésű és töröld ki a #include sort amiben találsz. nem emlékszem hogy a ieee80211-ben is meg kellett-e csinálni

( toros | 2006. 12. 10., v – 14:04 )

Érdekes, hogy én egyetlenegy Ubuntu-s cikkre sem emlékszem az indexen. Hmmm, úgy látszik, ezek tényleg csak akkor írnak valamiről, ha megkenik őket. Talán nem véletlen, hogy a SUSE-ról is csak azóta olvashatunk ott, amióta Novell egyengeti az útját, és még arról is négy cikk jelenik meg, ha valamelyik Apple boltban újfajta, citromos illatú tisztitószerrel mossák fel a padlót.

( sas | 2006. 12. 10., v – 16:47 )

aki SUSE-val foglalkozik nem mondaná meg, hogy nem lehetne-e az, hogy a a SUSE is dpkg alapúvá váljon?

amúgy szerintem Debian a best.

egmont már jópárszor beszélt érről a HUP on, pl itt

És itt egy kiragadott idézet, amikor az rpm csomgakezelés előnyeiről írt:

"Csomagkezelő legyen képes _ellenőrizni_ telepítés helyességét. Végigellenőrizni, hogy a telepített fájlok tartalma, meta-adatai (tulaj, jog, időcímke stb.) rendben vannak-e, függőségek rendben vannak-e stb.

Ezekre az RPM amióta az eszemet tudom, képes, míg a dpkg nem (nem is tárolja el a fájlok metaadatait). Nálam (millió szempont mellett) ez az legkomolyabb vízválasztó, ami miatt az RPM-et csomagkezelőnek tartom, míg a dpkg+apt párost csak összetákolt bohóckodásnak egy .tar.gz kitömörítése körül.

Számtalan alkalommal felmerül olyan probléma, hogy valami egy darabig működött, aztán nem. dpkg-n nevelkedett emberektől mindig a "telepítsd újra" megoldást hallom, ami vagy bejön - vagy nem, de ha bejön, akkor sem derít fényt arra, hogy mi okozta a hibát, és mit lehetne tenni újbóli előfordulása ellen. RPM-en nevelkedett emberektől viszont sokkal inkább a hibamegelőző hozzáállást láttam: ellenőrizzük le a fájlokat, keressük meg hogy melyik nem stimmel, ha megtaláljuk, akkor nemcsak megoldani tudjuk a problémát, hanem fény derülhet arra is hogy ki-mi okozhatta. Volt már pl., hogy RPM alapú rendszeren betörés nyomait kerestük (megváltoztatott fájlok), és bizony az rpm hatalmas segítségünkre volt, egy szem parancs végignézte az egész rendszert és kiköpte a nem stimmelő fájlok listáját, dpkg-ban nyoma sincs ilyen funkciónak. (Jó, tudom, az rpm adatbázisát is manipulálhatta az illető...)"

Én úgy tudom, hogy tervben volt az átállás (vagy már be is fejeződött?), ebben nem vagyok biztos, régen használtam már Uhu-t...

pl a linkben amit beidéztem:
"Szerző: egmont
Dátum: szo, 2005-05-21 20:28

> De akkor miért a deb-el kezdtetek? Ez már a ti saratok szerintem.

- Szerintem úgy általában semmi kivetnivaló nincs abban, ha valakik esetleg egyszercsak úgy vélik (és nem sumákolnak hanem ezt felvállalják) hogy egyszer régen - most úgy látják - rosszul döntöttek.

- Az UHU fejlesztői csapata is jelentős mértékben változott a kezdetek óta.

- Négy évvel ezelőtt senki nem tudhatta, hogy ezen négy év alatt az rpm (főleg az apt-jellegű frontendek terén) hatalmasat fog fejlődni, míg a dpkg+apt szinte semennyit. Négy évvel ezelőtt az rpm-hez nem volt használható apt-jellegű frontend, ezért most visszanézve én úgy vélem, hogy akkor a csapat (amiben akkor én még nem voltam benne) az akkor rendelkezésre álló információk birtokában jól döntött a dpkg+apt választással. A világ azóta megváltozott, a kérdés az, hogy megéri-e nekünk ennek fényében váltanunk."

Tehat ha belenyulok a rencerbe halottnak a csok... vagy modositod a configot ujra rpm es ujra felrakod hogy eltarolja a metaadatokat? Vagy ez is olyan mint a windows ha default-ban hagyod muxik? Apropo ha csak a metaadatoktol csomagkezelo (mer janelkul ugye egy idezem "osszetakolt bohockodas") egy csomagkezelo akkor miert nem metaadatkezelonek hijjak? Mink videken igy hijnank akkor... ;o) Azert ez rohejes de erosen... sztem sokak elott ne hangoztasd amig korbe nem rohognek. ;o) rotfl

Apropo csomagkezelo rpm okoska a draga ami ugy mint fennebb megtuttuk ellenorzni a fuggosegeket. Akkor mondd mar meg neki oldja is fel.. Nehanyszor jolesett volna anno... hal istennek regota max AIX-on latok rpm-et...

Es a kedvencem: nekem a bugyuta dpkg+apt parosnal ha feltettem egy progit sosem 10 perccel utana vinnyogott hogy ugyanmar van am frisebb csomag is a neten hiaba raktad be a cd-t es szenvedted fel 10 perc alatt azert ujra eljacchatod am neten at is...

"Azert ez rohejes de erosen... sztem sokak elott ne hangoztasd amig korbe nem rohognek. ;o) rotfl"

Ha megnézed, fent ng hozzászólását (amire reagáltam), akkor rájössz, hogy arra próbáltam választ adni, hogy miért nem jó az UHUéknak a .deb formátum - ez nem az én véleményem volt, hanem egmonté. Én csak idéztem, amit eléggé feltünően ki is emeltem. Szakmai kritikákkal és kérdésekkel pls fordulj hozzá.

"Apropo csomagkezelo rpm okoska a draga ami ugy mint fennebb megtuttuk ellenorzni a fuggosegeket. Akkor mondd mar meg neki oldja is fel.."

A dpkg feloldja? Elég rég használtam Debian alapu disztrót de akkor még egy dpkg -i nem rakott fel semmi függőséget.

Nem, de a rendszert remekul el lehet vele kefelni. Vagy ha nem vagy biztos a dolgodban, akkor apt-t kell hasznalni :). A dpkg szvsz semmivel sem jobb, mint az rpm parancs, a yum, yast, es tarsai inkabb az, ami az rpm-et valamivel korszerubbe tette, es most mar egy fedora ebben is konkuralni tud egy debiannal.

A dpkg szvsz semmivel sem jobb, mint az rpm parancs, a yum, yast, es tarsai

hagyjuk most az elméleti vagy inkább filozófiai okfejtéseket. a gyakorlat az, hogy még a dpkg meg tudja/tudta mondani már a kezdetektől, hogy egy csomagnak milyen más csomagokra van szüksége, méghozzá verziószámmal együtt, addig az rpm erre képtelen. helyette a hiányolt fileok listáját adta meg, amivel általában nem sokra lehetett menni. többek között az rpm csapnivaló függőség kezelésének volt a következménye az, hogy a Mandrake megszületett.
az első Mandrake nem volt más mint egy Redhat 6.2 KDE felülettel. a Redhat akkoriban qt licencel kapcsolatos problémák miatt kihagyta a kdet a disztribjeiből. így tett a debian is, csak dpgkval simán meg lehetett csinálni azt, amit rpmel szinte lehetetlen volt.

ugyanakkor deb csomagot nehezebb készíteni mint rpmet.

Hogyan mondja meg? Mi az a kapcsolo?
Az rpm fuggoseg kezeleserol nem erdemes beszelni, mert nincs :( ezert van "ujabban" a yum, ami szerintem nem olyan reg ota lett igazabol hasznalhato, legalabbis par honappal ezelottig inkabb rpm alapu apt-t hasznaltam helyette.
A konfigot, bar nem kevertem ide, a redhat kicsit maskeppen kepzeli el, mint a debian, mindenfele konfiguralo scripteket csinalnak, amik az altalanos dolgokra jok /pl, bind, apache, samba/, olyan, mint a debben valoban nincs, messze el van maradva a .deb-hez kepest.

Edit:
Kozben rajottem mire gondolsz, es azt tudja az rpm, kiveve ha nem :) szeretem mikor kiirja, hogy hianyzik neki a libakarmi.so, vagy a /bin/netuddmi :(

pontosan az a baj az rpmel, hogy csak azt írja ki, hogy libakarmi.so kell neki, utána találgathatod hogy az a libakarmi.so melyik csomagban van benne és melyik verzió is kell abból a csomagból. ma már persze van google, rpmfind ezek 1998ban még nem léteztek, amikor pont emiatt váltottam red6rol debianra. ha egy új programot akar feltelepíteni valaki, akkor ráadásul még nem is ismeri előre, így nagyrészt nem tudja fejből sem melyik lib hova tartozhat. a dpkg -i valami.deb viszont csomagnév/verzió módon megmondja mire van szüksége. disztrószinten pedig még az apt előtti időkben ott volt a dselect is, red6ban ennek sem volt megfelelője

Nem vagyok nagyon bufe az rpm belsejeben, de asszem pont Egmont (*) irta, hogy *tud* az RPM is csomag fuggoseget, nem csak fajl fuggoseget.
a) nincs igaza annak, aki ezt irta, akkor meg kell dorgalni
b) igaza van, akkor meg kell tole kerdezni, hogyan (vagy utana kell keresnie annak, akit a dolog erint)

(*) Ha nem, akkor is UHU fejlesztotol olvastam ezt az infot. De utana tenyleg nem jartam

Hogy mikor, mi hianyzik neki, azt nem tudom, hogyan totozza ki, biztos van vmi logika benne :) rpm keszitesnel latszodik a vegen, hogy csomag, vagy file dependency lesz-e a vegeredmeny, ha file, akkor kezzel beirom, hogy kell neki. Ez se jo megoldas, mert a verziok igy nem lesznek valodiak, amik kellenek neki, de meg mindig jobb, mintha vadasznod kellene vmelyik csomagot. Erre is, megoldast kinal mar a yum, mert az megmondja, hogy melyik csomagban van a hianyzo hivatkozas.

( pepo v | 2006. 12. 10., v – 19:54 )

Nekem is bejött. Akkor kerültem kapcsolatba velem, mikor egy olyan új hardwerre kellett szervert tennem, amit egyetlen akkori "gyári" kernellel ellátott disztrib sem tartalmazott. Nem akartam keverni, meg időt elszúrni azzal, hogy image kernelből bootoljak. Az edgy éppen akkor jelent meg és tartalmazta a kernelt ahhoz a VIA-s SATA RAID-hez a támogatást.
Ekkor megtetszett. Egy azonban bántja a lelkem: tegnap lefagyott a szerver! Na, az igazsághoz hozzátartozik, hogy nem frissítettem semmi csomagot sem a telepítés óta, viszont a Kernelt azóta néhányszor frissítették a szervereken.
Korábban Mandrivából csináltam szervereket, azokkal sosem volt baj. Az egyik szerver 3 évig futott mikor áthelyezés miatt le kellett állítani. Na, ez persze nem világrekord, csupán azért írtam le, mert félek, hogy nem lesz elég stabil az *ubuntu. Kissé mintha elhamarkodva adnák ki a csomagokat... Nem tudom. Egyelőre elég szimpi: rengeteg csomag van, jók a függőségi kezelése, a konfigfájlokat a disztribútor nem variálta át különböző alkalmazásoknál (pl.: /etc/../interfaces a Mandrivánál), vagy nem jelemzi elbaszott patchelések. Azért vannak szarjai, pl. ha nem kapcsolom ki a grubban a splash-t, akkor tuti fagyás konzolra váltáskor, vagy kikapcsoláskor (fglrx)...

( sakic | 2006. 12. 10., v – 21:23 )

A körülötte lévő hype-ot tekintve igaz :)

( gUHU | 2006. 12. 10., v – 22:55 )

Inkább a Debian legyen a király (ha mág a Gentoo nem lehet...). Azt nem próbáltam még és nem csalódtam benne. illetve nap mint nap bizonyítja, hogy működik. Ubuntu csillagról meg ez nem mondható el...

( khiraly | 2006. 12. 12., k – 02:22 )

gyorsan tegye fel a mancsat, aki gtk-2.10 -et hasznal.

Es akkor ennyit a disztro-harcrol. Jo fel napos szenvedes volt mire debian+ubuntu forrascsomagokbol sikerult ujraforgatnom a fel rendszert. Pedig a 2.10 nem ma jott ki, hanem valamikor augusztusban. Es csomo okossag van benne (csak kettot emlitenek meg: fileselector vegre hasznalhato, es nem kell egg.trayicon-t hasznalni, mert van nativ)
Tok fura, ekkor tunt fel, hogy vannak metacsomagok. Es gtk meg a gimp utkozik (debianban). Meg jo, hogy a .deb fajl sima .ar fajl, igy kicsom, benne levo tar.gz-eket szinten es modositani a fuggoseglistat. (jah es ilyenkor apt is szinte hasznalhatatlan)

Ezt csak azert irtam le, mert gyakorlati haszna (szamomra) szinte semmi.

Viszont az ubuntueknak jobb a bug-kezelesuk, es van nehany hasznos patchuk is nehany .deb-re.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Pl. sokkal szebbek a programok abrai, csak hogy egyet mondjak:
deluge es ott a network statistic (a cairo miatt ugye)

Ha irtal mar eletedben kissebb python programocskakat, akkoris baromira orulhetsz neki.

A fileselectort mar masok is emlitettek. Lenyegesen gyorsabb is az elozonel (bar lehet hogy csak erzeki csalodas)

Szoval szerintem igen.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az Edgy-ben 2.10.6-os GTK van, az Arch Linux-ban pedig már a nyár végén az volt, és ez azért fontos, mert végre valahára van "Location" opció a "File Selector"-ban. Vagyis nem kell kretén mozdulatsorozattal végigklikkelgetni az egész fát ahhoz, hogy eljuss a megnyitni szándékolt fájlhoz, hanem egyszerűen begépeled az útvonalat, és ilyenkor az automatikus hosszabbítás is működik. Egy baj van mindössze, egy "ici-pici" hibácska: mikor működik, mikor nem működik, teljesen előreláthatatlanul :-D. Hiába, fene jó választás a GTK és a GNOME. Állítom, hogy ha az Ubuntu a KDE-re összpontosítana, még nagyobb sikere volna, még nagyobb "király" lenne. Ez a "mellékes" ficsör már rég benne van a KDE-ben, és egyáltalán nem bugos.

Node senki nem akadályoz abban, hogy kubuntut használj.

Én a feleségem és édesanyám gépére kubuntut tettem, mert a gnome az általad is említetthez hasonló tervezési eltérések miatt szerintem kényelmetlen.

Az más kérdés, hogy a kubuntu által a debianhoz képest leegyszerűsített menüket nem bírom elfogadni. Illetve nem az a baj, hogy van egy kisebb menü, hanem az, hogy kell egy feature, tudom, hogy a program tudja, csak a kubuntu változat nem ajánlja fel. Grrr

Én erre a problémára a windows ritkán használt menüpontokat eltüntető menüit tartanám alkalmasnak. És azt hiányolom is erősen.

G