Ian Murdock: Software installation on Linux: Today, it sucks

Linux

A Debian Linux disztribúció egyik alapítójának, Ian Murdock-nak blogján látott napvilágot néhány napja egy hosszabb írás, melyben a szerző a Linux néhány betegségéről, valamint a felhasználóbarátság fontosságáról ír, a feltehetőleg még 2007-ben elkészülő Debian Etch apropóján.

( ng | 2006. 12. 20., sze – 13:13 )

Monnyuk ezt nem értem. Egy windowsnál letöltöm a telepítőt és kattogok az exén hogy installuljon má. Linuxban meg apt-get install anyámkínja, vagy yum install izébigyó. Nincs ezzel gond. Csak azzal ha felrakódik egy fedora mysql-lel meg php-val, apachecsal, akkor miért kell keresgélnem hogy rájöjjek hogy kell még a php-mysql is? Olyan mint amikor visít egy windowsos program a telepítés után hogy kő neki a msvbvmdbm70.dll.

Mert akkor látnod kellett ezt is:

If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms.

A mondanivaló lényege éppen az élet apt-get nélkül.

És ha nem gondolt, akkor az ember tol egy bugreportot, és nemsok idő múlva a dependency jó lesz. Szerintem nincs ezzel baj.

Én legalábbis ritkán látok olyat, hogy egy apt-get akármi után dependency miatt ne működjön. (Mondjuk van olyan disztró, amit 1 ember tart karban, ott becsúsznak ilyenek, csodák nincsenek)

Tudom, hogy felesleges ilyenkor a feleségemet példának felhozni, mert van affinitása az infoprmaitikához, de soha a büdös életben nem fordult vele elő sem debianon, sem ubuntun, hogy ne tudott volna feltenni valamit.
Hozzáteszem, hogy nem akart saját kernel csomagot készíteni. És hogy általában synaotic-ot használ a csomagkezelésre.
De!
Egyik ismerősünknek sem okozott gondot a synaptic kezelése, és különböző csomagok felrakása. Sőt volt olyan, aki magától rájött, hogy nem is akarja valójéban azt a csomagot leszedni, amire azt írta a synaptic, hogy leszedi akkor az X-et is meg mindenféle mást is. Szóval aki egy kicsit is elgondolkodik azon, amit kiír a gép, annak megy az apt-get-es csomagkezelés szerintem.

A blogbejegyzes nem arrol szol, hogy milyen egyszeru v. bonyolult az alkalmazas-telepites csomagkezelo segitsegevel, hanem arrol, hogy egy ISV, aki fuggetlen(!) a disztribuciod szallitojatol nem tudja a Linuxot, mint egyseges platform megcelozni (es most nem binaris kompatibilitasra kell gondolni), hanem kulon kell csomagolnia a cuccat Red Hat, SuSE, Ubuntu, stb. disztrohoz, ami a) faradsagos = idoigenyes (ido=penz) b) elriaszthatja. Aki meg meg ezek utan sem fordult el a platformtol az ir sajat binaris/script telepitot, ami ha szerencses vagy eppen felmegy, de a rendszerednek - mint ahogy az egyszeru usernek sem - fogalma nem lesz arrol, milyen fileokat es hova telepitett az installer. Ez pl. feleslegesen megneheziti a dolgot uninstallkor.

Na ilyen, es ehhez hasonlo kerdesekre kerestek a fiuk a valaszt.

Ha már MS meg Windows. Egyet nem értek: miért nem csinál az MS egy disztribúciót? Azaz miért nem megy át a szervezeten az összes nem egyedi software? Tanusítványokat amúgy is osztanak, miért csak a pénzt szedik be. Miért nem próbálja ki valaki hozzáértő, hogy az adott cucc biztonsággal felrakható és le is szedhető egy Windowsról?

En meg azt nem ertem, hogy miert lenne az torvenyszeru, hogy ha felinstallod a mysql-t, apache-ot es php-t, akkor telepulnie kellene a php-mysqlnek is?
Ilyen alapon kb. kismillio hasonlo csomag felmehetne default - szerencsere nem igy van. Ha phpban akarsz mysqlt hasznalni, akkor installald. Rosszul neznenk ki ha a trendet kovetne a fuggosegi lista, csak azert mert manapsag mindenki php+mysql haxornak erzi magat es ontja magabol a secholeos programokat. De legalabb modern majeskuelben irta!!!!11 java es oracle meg wtf, de ez mar off

( uid_1526 | 2006. 12. 20., sze – 13:29 )

Igen, kb ez a helyzet. Azért vannak ma is működő példák, pl a Netbeans installerével nem volt gondom. De nagyon kellene egy egységes felület a külső szoftverek manageléséhez.

>> Itt a bejegyzes megnezesekor rogton melette van, a doksi.
természetesen, short desciption: (none) és long description: (none) formájában

>> Kulcsokhoz erteket rendel, mit kell meg tudnia ?
hozzáférési jogok finomhangolása kulcsonként, HKLM-nek megfelelő facility, policyzhető/kényszeríthető értékek, távoli hive becsatolása, ..., ...?

Melyik elemet nezted? Kulcs-ertek parok nekem dokumetaltak.

Hozza feresi jogok?? Minden usernek sajatja van.
gconf -nem rendszer bealito cuccokat managel, foleg Gnome bealitasai vannak benne.
Fent emlitett dolgok igy erdektelenk szamara.
Nem celja a /etc (teljes) kivaltasa.

Jogoknal arra gondoltal, hogy per alkalmazas legyen a jog bealithato? (win -en igy van?)

( mogorva v | 2006. 12. 20., sze – 13:40 )

2007 a [desktop] linux éve lesz!

( strogg v | 2006. 12. 20., sze – 14:20 )

ezen a témakörön többször vitáztam már linuxos emberkékkel. Nem tudta mevlük megértetni, hogy el kéne felejteni a csomi bohóckodást, grafikus installer, a programok meg .run- ba legyenek rakva. Klikk, telepedeik, és mindenki boldog. Egy letisztult, lib-ekkel feltöltött disztró kell, amivel a sikítás,hogy xy lib nem található a minimálisra csökkenthető. Mellesleg a disztró nem lenne túl nagy emiatt, mert 1. ha nem találja az adott libet még bekérheti a cd-t,másrészt a libek igen komoly százaléka csak azért született, mert xy programját szolgálja. Ezzel a fejelsztőket is lehetne ösztönözni, hogy ne egyéni külön libeket gyártsanak végeláthatalna sorban. Amíg ez nem megoldott az áltag user nem fog pöcsölni az apt-get egyik frontendjével sem, hanem hagyja a fenébe a linuxot. Magyarán ez már konvencióvá vált (lehet persze szakmailag vitázni,hogy mennyire über az apt-get) de emiatt a desktop-on a büdös életben nem fog elterjedni a linux. Márpedig amíg nem lesz tényező desktop-on, addig nem lesz rá sok játék, a gáyrtók által támogatott hardver driver, photoshop,dreamweaver, és sorolhatnám.
Nem azon kéne vitázni, hoyg upstart vagy initng-vel induljon, hanem ez lenne a leg égetőbb dolog.
Mondom. Enélkül Desktopon esélytelen a linux.

\ | /
°(>@)°
˘

Szerintem sokkal nagyobb problema a csomagok eltavolitasa.
Felszenvedni elobb-utobb mindenkinek sikerul...

---
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....

???

$ apt-get autoremove
E: Invalid operation autoremove

A doksijában sincs ilyen művelet. (0.6.44.2-es verzió)

Egyébként jelenleg az apt azért sem tud ilyet csinálni, mert a szükséges információ nem áll rendelkezésére. Annak a szolgáltatásnak, hogy eltávolítunk mindent, ami nem kell senkinek a csomagkezelő szerint, nincs különösebb értelme; ezt tuti össze lehet tákolni egy gusztustalan shell szkripttel a jelenlegi dpkg+apt köré.

Aminek lenne értelme, az az, hogy minden egyes telepített csomagra nyilván lenne tartva, hogy az az én explicit kérésemre került fel, vagy pedig csak függőség miatt. Természetesen utólag is minden telepített csomagra ezt a bitet lehetne oda-vissza állítgatni. És lenne egy olyan szolgáltatás, ami automatikusan eltávolítja mindazokat a csomagokat, amelyek csak függőség miatt kerültek fel, de immár nincs rájuk szükség.

Hogy ez miben különbözik az előzőtől? Abban, hogy ha a libfoobar csomag egyedül egy 3rd party, nem csomagból telepített (vagy például általam kézzel-lábbal fordított) programnak kell, akkor a függőségek alapján úgy tűnhetne, hogy nincs rá szükség, de én okosabb vagyok, én tudom, hogy van, és ezt meg tudnám mondani a csomagkezelőnek, hiszen a libfoobar ez esetben egy kifejezett kérésemre telepített csomag volna, és azt eszébe se jutna ennek az autoremove (vagy hívjuk ahogy akarjuk) feature-nek eltávolítania.

(Amikor az arch csomagkezelő doksiját átfutottam, úgy tűnt, hogy az tudja ezt. Persze az meg sok-sok mást nem tudott, amit fontosnak tartanék.)

talán túlságosan részletezem, de 1 bit meglátásom szerint nem elég. Ugyani ha felraksz egy csomagot, ami húz egy függőséget, aztán egy másikat is, aminek ua. a függősége, akkor ha leszedet az elsőt, ugorhat a második függősége, tehát;
vagy registry,
vagy egy száma van minden csomagnak, ami azt jelöli, h ki használja, és ha 0-ra csökken, kampec. Aki pedig kérésre vt rakva annak a száma NULL értékű.

Másik. ha felpakolsz valamit, foobaar, és húzza magával a foobar-data, foobar-doksi, foobar-lol-t, akkor ezeked vmi virtuális csoportba kéne szervezni a későbbi könnyű eltávolítás miatt.

jó dolog a csomagolás, csak jól kell használni.

> Ugyani ha felraksz egy csomagot, ami húz egy függőséget, aztán egy másikat is, aminek ua. a függősége, akkor ha leszedet az elsőt, ugorhat a második függősége

Épp arról van szó, hogy nem ugrik, hiszen a csomagkezelő éppen most lát egy csomagot, amelyiknek ez a függősége. Tehát nem akarja leszedni.

Akkor akarná leszedni (természetesen megerősítést követően), ha egyrészt nem explicit kérésemre került fel (erre szolgál az a bizonyos 1 bit), _és_ másfelől pedig egyetlen telepített csomag sem igényli. Az általad mutatott példában ez utóbbi nem teljesül.

viszont a dekstop elterjedtsegen jól látható, hogy nagyon kevesen hajlandóak "felszenvedni"
És azok közül is még kevesebben akarják "leszenvedni".

Ezt az egész install/uninstall dolgot fullra újra kell gondolni, és elfelejteni végre ezt a csomagkezelési baromságot. Egy ideig jó szolgáltatot tett, most viszont már teher. (méghozzá nagyon nagy.) Mi még elbohóckodunk vele, de a userek 97%-a nem fog. Márpedig nélkülük nekünk sem terem babér hosszú távon.
Utánna pedig a második égető gond: Egységes elemkészlet/gui/api megteremtése. Eléggé gáz, hogy több cég azért nem fejelszt linuxra, mert nem akarja qt/gtk -ra is megírni. Max egyre hajlandó. Persze csak ha látja, hogy lesz rá piaca. Magyarul a home user.

\ | /
°(>@)°
˘

Mint elmítettem: nem látják a piacot sem.
de még ha meg is próbálkozna vele: amíg a progi nem megy fel klikkre, és nem indul klikkre, addig az is mind1, minben írták. A user nem fog elmélyedni a csomagkezelésben, nem fog csomagkezelő progikal pöcsölni, pláne nem fog fordítgatni, konfokat editálni, "java -paraméter" sorokat írni a konzolba. Elvárja, a metódust. :) És helyenként nekem is jobban esne ez (meg még eléggé sokunknak). Mert most hogyan működik? Keresel progit. Oké. Mondjuk egy programot, hogy főzzön neked kv-t a gép. Elindít synaptic/yast/bármi és rákeres a szóra. Vagy talál, vagy nem. Ha talál, akkor mehet az apt-get, feltéve, hogy a függőségei is benne vannak a fában. Ha nem, akkor tároló vadászat indul. Ha nincs, akkor google. Google jobb esetben jó tárolót ad, rosszab esetben rpm-et. Vadászol tovább. Synapticnak beadod az új tárolót, frissítesz, és jobb esetben jó a tároló, rosszabb esetben újra az egész előről. ráadásul kurtára szűk a felhasználható elmeke listája is, hisz a disztródhoz, sőt a disztrón belül is verziószámnak mgfelelő tárolót vadászol. Aztán vagyvan, vagy nincsen. Ha nincsen, akkor próbálkozol előző verzióval/forrással/siten tudja mivel. Heggesztesz magyarán. Aztán 1 óra szöszmötölés után végre csak annyit értél el, hogy letölti, és felrakja neked a progit. mondom. Ezzel mi elvagyunk. A felhasználók 97%-a nem. Ő látja a linket, hogy kv főző progi, és a max idő amit rászán az az idő, amíg lejön a cucc a sávszélességén. Aztán klikk-> telepedik->klikk fut. Ennyi a történet.

\ | /
°(>@)°
˘

Őszintén szólva, nem érdekel, hogy mi kell átlag pistikének. Én így szeretem használni: Csomagkezelőben kijelölöm, hogy mi kell, aztán használom. Ha nem kell, csomagkezelővel leszedem. És nem telepítgetek mindenféle szart a gépemre. Disznót sem tartok a fürdőkádamban.

Disznot lehet nem raksz a furdokadban. De pl. tervezhetnel egy nagyfeszultsegu halozatot;)
Jah hogy nincs szoft linux ala? Es miert nincs? (mintha ezt feszegetnenk itt).

Gondolom nem akarod azt mondani, hogy legyen opensource. Ami ilyen retegprogram (ertsd nem a tomegeknek fejlesztik, hanem egy spec. teruletnek), ott nem lehet elvarni, hogy opensource legyen.
(ellentetben mondjuk a driverek problemajaval, ahol jogos koveteles az opensource)

Es ha mar nem opensource, akkor valahogy meg kene teremteni a lehetoseget, hogy konnyen lehessen telepiteni, egyseges api (pl. bongeszot hogyan nyitsz meg programbol? Hat mashogy gtk es qt alatt, persze vannak erre kezdemenyezesek (pl. portland))

---
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....

Ami ilyen nagyon elterjedt closed source, ahhoz csinalnak csomagokat is. Nvidiahoz pl. van .deb es .rpm csomag.

De ettol meg jogos koveteles, hogy a driverek legyenek nyiltak. (tudom, ettol meg mindig az erosebb kutya...)

Viszont a retegprogramoknak nincs akkor felhasznaloi bazisa, hogy csomagokat haxoljanak kore.
Meg igazsag szerint elsosorban ez a program szallitojanak lenne a feladata, de pont tole nem varhatunk el annyi fele csomagformatumot. (pl. mert alig van par fejlesztoje)

Noh jo, azt hiszem csontot ragok. leallok.

---
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....

En nem ertem ezt a problemat, de tenleg. Ott a /opt konyvtar hozza letre a sajat konyvtarat pakoljon oda minden libet meg ami kell neki es felejtse el amit a disztro hasznal, mi ebben a muveszet???
Nem kotelezo libeket se hasznalni fordits statikus binarist, ismet meg van oldva a problema.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

JAJ, itt arrol volt szo, hogy a kereskedelmi cuccok szivnak a linux csomag kezelok miatt, erre irtam 2 megoldast, es biztos van meg masik 1000 hatekonyabb. En nehezen hiszem, hogy 60-70 kereskedelmi progit hasznalnal... amugy meg 10GB az mai vilagban...

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Arról van szó, hogy egy kereskedelmi progi fejlesztője normálisan rendszerbe illeszkedő dolgot akar szállítani, de ez jelenleg nem megoldható a kismillió csomagkezelő meg ilyen-olyan eltérés miatt. Nos a cikk második része arról szól, hogy Ian összehozta a RedHat, a Debian, meg más fejlesztőit, egy csomó kereskedelmi fejlesztőt és kialakítottak egy API-t, amit a disztrók könnyen meg tudnak valósítani és a fejlesztőknek elég ahhoz, hogy olyan installereket készítsenek, amik működni is fognak.
Arra ugyanis már régen rájöttek, hogy az nem megoldás, ha egy fél disztrónyi libet hozzácsomagolnak az alkalmazásukhoz.
Szerintem olvasd el a cikket.

Szerintem a csomagkezelés amúgy nem gáz, mert egy grafikus felülettel lényegesen hatékonyabb, mintha neked kéne veszkődni a függőségekkel. Csak a harmadik féltől származó programokkal van a baj, amit nem a disztró szállít.
Igazából én el tudok képzelni egy olyan infrastruktúrát is, hogy az egyszerű user a böngészőjevel egy linkre kattintva egy sources.list sort állít be (sudo után), aztán automatán elindul mondjuk a synaptic a csomag telepítésére.

A gond ott van, hogy nincs egységes csomagkezelő. Csak példaként említem meg, hogy nekünk is van pl. egy egyszerű számlázó programunk, amit gond nélkül lefordítok Linuxra és gyönyörűen fut is. Mégsem vagyok biztos benne, hogy érdemes lenne kiadni ezt, vagy akár más ügyviteli progit Linuxra, mert előre beláthatatlan, mekkora munka karbantartani ennyi különböző csomag-formátumra meg disztróra. Nem beszélve arról, hogy még egy .deb vagy .rpm csomag telepítése sem egyértelmű a userek 90%-ának.

Szerintem a disztró a lényeg. A csomagformátum lassan kevésbé lesz érdekes. Pont, hogy egy minden disztro által támogatott és alkalmazott infrastruktúra kellene. Csakhogy az elég közel állna egy igen-igen utált rendszer filozófiájához. Valamint sokan elleneznék a szabadságtól való _vélt_ megfosztásuk miatt, mivel ez mindenképpen jelentene bizonyos megkerülhetetlen kompromisszumokat.

Szerk: mint azt lentebb láthetjuk is.... )c:

Példa egységes csomagkezelőre: http://www.openpkg.org/ van más is, nem olyan bonyolult az élet.

A baj inkább az, hogy minden disztró máshogyan képzeli el a programok. libek, doksik, konfig fájlok pozícióját és ebből a káoszból nehéz lesz egységet kovácsolni. Ha ez meglenne, akkor szinte zéró munka egy egyszerű, mindenki által kezelhető, installációs, csomagos bármilyen rendszer elkészítése.

Igen, erre irányul Ian kezdeményezése. Valami csomagkezelők feletti egyszerű és egységes megoldást szeretnének létrehozni, persze a nagyobb disztrók és és a független fejlesztők egyetértésével. Végülis a legfontosabb arcok benne vannak a csapatban, így van esély arra, hogy sikerüljön.

Dehogy. OSX alatt tudsz csomagot csinálni OSX-hez, OSX-hez és OSX-hez. Ez ám a csuda! Ahogy Windows alatt is csinálhatsz install anyagot Windows-hoz, Windows-hoz és Windows-hoz. Ezek überállat oprendszerek, hiszen ilyesmit lehet velük csinálni! :-D
A GNU/Linux alapú disztribúciók viszont szarok, mert ott nem lehet csomagot csinálni RedHat-hez, Debian-hoz, Gentoo-hoz és Ubuntu-hoz egyszerre. :-D
És akkor arról még nem is beszéltünk, hogy az AIX-es programok nem futnak HP-UX alatt és a Solaris-ra fejlesztett alkalmazások csak állnak és bámulnak ha Tru64 alá kerülnek. Eh, ezek is vacakok. :-D

Ave, Saabi.

Cipőt a cipőboltból. Én Zenwalk alá gyártok csomagokat. Eszembe se jut se deb se rpm csomit gyártani, mert nem ez az alaprendszer. A Windows és MacOSX viszonylagos homogenitása miatt könnyű rá csomagot gyártani. De a Linuxnál ne felejtsük, hogy a kernel maga a Linux a többi disztribúció. Van akinek ez hátrány van akinek előny, hogy válogathat. Én például Ubuntu vagy RedHat alatt nem tudnám elképzelni magam (próbáltam már vagy 30 disztrót idáig), de a Slack/Zenwalk vonal tökéletes számomra. Ennek a csomagkezelése igazán katasztrófális a többihez viszonyítva, de én akkor is szeretem. A Windowst kényszerűségből használom, de nem vagyok elégedett vele. A MAC-et is próbálgattam már. Van a cégnél 1-2 darab. A MAC Mini-t sikerült úgy kiakasztani, hogy egy taszkváltás 2 percbe telt, a felület számomra totál káosz, nem áll kézre. Ugyanezt tudom elmondani Linux alatt a KDE felületről is. Egyszerűen nem tudok "normálisan" dolgozni alatta. Tudom bennem van a hiba, de tudok választani és ez nekem jó.

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

talán annyi, hogy csomagokat nem az oprendszerrel szokás készíteni (mint ahogy helytelenül írtad), hanem erre szakosodott toolokkal (melyek szükséges esetben más rendszereken való ilyen vagy olyan módú futtatása nem kellene hogy különösebb problémákat okozzon)

Hol is írtam, hogy az oprendszerrel csinálják a csomagokat? :-O
Mindamellett igazad is lehet, csak arra probáltam rámutatni, hogy a csomagkezelők problémakörét nem igazán lehet olyan operációs rendszerek felől nézni, amelyek "egy disztribúciónak" számítanak. Hiszen hányféle disztribúció készül win32-re? (a win32-s debiánnal most ne foglalkozzunk) Vagy az Apple Macintosh gépeknek hányféle operációs rendszere van? A különböző verziókat lehetőleg ne tekintsük külön "disztribúciónak".
Egy RedHat és egy Debian között messze nagyobb a különbség mint egy XP és egy W2K között. Arról nem is beszélve, hogy a Windows és az OSX egy-egy gyártó kezében van, egy RHEL vagy egy SLES külön gyártók terméke.

Ave, Saabi.

Használj windowst, az pontosan ezt adja: egyféle GUI, egyféle API, nincs csomagkezelés. Sőt, másoljuk le a lehető legpontosabban a windowst, legyen start menü, meg paint, és legyen C:, meg D: meghajtó, mert az a jó, meg legyen "repülő ablakok" screensaver, és milyen szar már, hogy egy pingvin a logója, legyen inkább egy színes ablak...

a win-ben van csomagkezeles, start menu az ablakkezelok 90%-aban megtalalhato (including az osszes nagyot), paint is van ezer eves, es kekhalal screensaver is van, a meghajtokrol nincs tudomasom, pingvint ma mar igen keves distroban latsz mert mind dontoen a sajat logojat hasznalja, de szerintem a windows feeling mar igy is maximalis

Egyébként ebben van valami... Bár azért a Gnome, és a KDE menü is logikusabb felépítésű, mint a Start menü. Mondjuk engem már az is zavar, hogy ennyire másolják a windows felépítését. Jobb lenne több eredeti ötlet.

Csomagkezelés tényleg van win-ben is, de a programok általában installer-rel szeretnek telepedni. Ez nagyjából megfelel strogg javaslatának a .run fájlokkal.

A MAC OS X sikere is azt bizonyítja, hogy az emberek nem várják el, hogy feltétlen a windowst másolják, ha az új megoldások ötletesek és hatékonyak.

Szerintem a Gnome inkabb az Apple-t probalja masolni. Az elcseszett fileselector is egy szanalmas apple koppintas volt (jo, azota tobbe-kevesbe helyrehoztak), engem meglepett, hogy hogy a fenebe lehet ilyen marhasagot kitalalni. Aztan lattam egy macosx-et, hogy abban hogyan van megoldva...

Persze lehet harapni, de minek.;) Ez az egyszerusites, meg konnyu felhasznalhatosag (testreszabni meg ne lehessen), ez is kb. az appletol jon.
A gconf kb. az egyeduli windows registry koppintas;) (pl. meg sose sikerult rajonnom, hogyan lehetne kulcsokat *torolni* belole. Pl nem hasznalom mar a rhythmboxot, vagy szeretnem ha mindent elfelejtene, akkor a gconfbol nem torolhetem a kulcsait.) Ertelmesen ezt kb. ugy kellett volna megoldani, ohgy a gconf a vinyora xml-kent kiexportlja az osszes beallitasat, es szepen lehetne ott is torolni, meg kezzel szerkeszteni (ami megszokott unix alatt), es ezt o latna, es szepen ujraolvasna. Jah, ha egy fajl megvaltozik, akkor arrol nincs uzenete? (windows mintha szolna programnak, hoygha valtozik egy fajl), mindegy pollozhatna 3sec-enkent.

---
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....

Igen van szerkeszto: hogyan torolhetsz belole egy kulcsot?
Aham: nyisd meg vi-vel;)

dnotify/inotify-ban igazad van. Ezt nem tudtam, viszont nagyon sok progi megse hasznalja, es a doksijukban meg van magyarazva, hogy win alatt miert mukodik es lin alatt pedig miert poll-oznak 3sec-enkent.

---
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....

gconf+TAB nalad miket hoz fel? A poll-ozasrol meg mint irtam, linux alatt van *notify, dazuko, mashol a fam van hasznalatban, ... Kerdes, hany oprendszert tamogatnak, mi az, ami mindenhol van (ideertve azt is, milyen filerendszereken mukodnek, lasd pl. NFS), ill. egyaltalan ertenek-e hozza a programozok.

EGyszerubb lenne leirni, hogy te mire gondolsz. PErsze barchobazhatunk is.

En gconf-editorral szoktam butykolni. Es Te?
(pedig egyszerubb lenne egy konyvtarszerkezetben maszkalni, es fajlokat editalni. ehelyett van egy alig olvashato .xml ami nincs felkeszitve arra, hogy azt ember nezegesse, raadasul nincs is szinkronizalva a futo gconfd-vel)

A pollozasrol meg mint irtam beneztem. Egy program manualjabol indultam ki (ahol megmagyaraztak, hogy miert is igy van linuxon). Persze bocsanatot kerhetek meg parszor;)

---
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....

"(pedig egyszerubb lenne egy konyvtarszerkezetben maszkalni, es fajlokat editalni. "

Ez régebbi kiadásoknál így volt (sok kis xml a szerkesztőben látható könyvtárszerkezetben), csak aztán rájöttek, hogy egy nagy xml-t sokkal gyorsabban lehet beolvasni mint sok kicsit, ami a gnome indításakor nem mindegy. Úgyhogy kb. a 2.12 óta picit gyorsabban indul a gnome :)

Pedig az. Mondjuk nyilván nem egyszerű eltalálni egy csomagkezelő rendszernél, hogy mennyi szabadságot adjon és mennyire korlátozzon. Ha annyiféle third-party csomag lenne deb/rpm-ben, akkor ott is jobban kijönnének a problémák, mert több lenne az olyan eszetlen őrült, akik saját megoldásokat pakolnának a csomagokba, ahelyett, hogy követnék az előírásokat. Bár szerintem még így sem az MSI-vel van a legtöbb baj, hanem a mindenféle saját készítésű installerrel.

Ez az az egyseges dolog az, ami egy free opensource cuccnal nem fog mukodni, mert nem illeszkedik a filozofiajaba.
Ha vmi szervezet eldonti, hogy a KDE lesz az egyseges GUI/elemkeszlet, stb. Akkor az csomo embernek nem fog tetszeni (nekem se) es csinalnak vmi mast.
Tenyleg, az egyseges a jo, de akkor olyan egyseges legyen, ami nekem tetszik :))))

Biztos vagy te ebben?
A XAW megmaradt, mert... a franc tudja. Szinte semmit sem tud a többihez képest. Néhány embernek igénye van rá. Marad.
A motif (lesstif, openmotif) megmaradt, mert a CDE és a kereskedelmi UNIX-ok azt használták. Nosztalgia = létjogosultság.
A tcl/tk helyett senki sem írt tcl/gtk-t vagy tcl/qt-t (ahogy pythonnál, perlnél van GTK és QT binding is), mert nem volt igény rá. Igénytelen graphic toolkit, igénytelen scripteknek. Létjogosultság? Természetes, hiszen minimum 2 ember használja!
GTK/QT: ez már flametéma, nem részletezem...

Grafikus felület = totálkáosz. A KDE és a GNOME próbál rendet teremteni, persze minkettő a maga módján, ez pedig még nagyobb káoszt eredményez, plusz ha még hozzávesszük az elavult eszközkészleteket használó programokat (minjárt jön valaki hogy a tk miért elavult...), akkor ez teljes rendszertelenséget eredményez.
Ehhez még hozzájön, hogy a GNOME HIG agyrém, KDE-nél AFAIK ilyen nincs is, tehát a grafikus elemeket minden programozó a saját lázálmai szerint rendezi el.

Ja, és ezt valaki (pl. én) még használni is próbálja :D

(Gabu már másodszor találta fején a szöget, pedig csak szokás szerint agyatlanul fikázott... Ágyúval verébre? :D)

Én is kihaltnak tekinteném őket ha pl. a második legelterjedtebb Linux MSN kliens nem lenne tk-s :P
Meg mennyien használnak XAWtv-t is?
Elvétve maradt egy-két mammut, de ezek nem akaródznak kihalni.
Olyan feladatterületek tartják őket életben, ahol kevés az alternatívája az őket használó programnak => sokan használják őket, és még mindig fejlesztik.

A GTK/QT közt azért van fent erőegyensúly, mert mindkettőt egy, másikkal össze nem hasonlítható tulajdonság tartja fenn (GTK-t az LGPL, QT-t a rengeteg funkció), amiben a másik versenyképtelen, tehát nincs igazi, eldönthető konkurrálás.

(míg a QT kényelmes, de borzalmasan drága kereskedelmi sw-t írni hozzá, addig a GTK-ban egy rohadt konfigfile-ban vagy külső segédprogrammal lehet csak pl. widget- és betűszíneket változtatni, fapad az egész, a tk-tól jóformán csak a témaváltás lehetősége különbözteti meg......)

MonoDevelop integralt GTK gui szerkeszgetovel jon, szerintem igeretes. (Eleg hamar oszedobtam vele egy komolyabb GUI-s programot)

Nekem GTK -tetszik jobban. Most Gnomot hasznalok. De KDE4 -re kivancsi leszek.

Qt -kemeny penzei kicsit ilyesztoek. Ha megtanulok rendesen Qt-zni es kitallom, hogy egyszemelyes szoftverfejleszto ceg leszek, akkor nem fogok orulni a Qt aranak.

(Lehet meg igy is olcsobb, mint ha MS termekekkel fejlesztenek :) )

"es kitallom, hogy egyszemelyes szoftverfejleszto ceg leszek, akkor nem fogok orulni a Qt aranak."
Ezen mit nem ertesz?
"oss-hero foss-advokatna -k" ;-) is vennie kell valamibol a sort es szamitogepet.
Es adodnak olyan szituaciok, hogy zart kod tobbet hoz a konyhara. (1 megrendelo fizet a szoftverert, akkor masodik csak letolti ingyert,ami miatt lehet pont a megrendelo fog legkevesbe orulni,mivel igy a konkurencia ingyen jut hozza, ahhoz amiert o fizetett, ez nem lenne vele fer, De pl. ha megrendelo mindenki altal letolthetove akarja tenni a szoftvert, akkor dobom melle a kodot (pl. Abev))

Volt -ra egy 100 -asom, hogy valaki egy hasonlo megjegyzest tesz :)

>> vennie kell valamibol a sort es szamitogepet.
dehát anr már rég megírta többször is a Forradalom És Foss Hogyanjában, hogy az egyedüli szép új jövő az, hogy ingyen van a szoftver, mindenkinek jár a forrás, és te a supportból élsz, nem isszátok a szavait?
(más kérdés, hogy ezt ő másképpen csinálta a valóságban, biztosan csak véletlenül)

>> Volt -ra egy 100 -asom, hogy valaki egy hasonlo megjegyzest tesz :)
talán mert szúrja az ember szemét, hogy megy a mesélés, hogy így szarabb minőségű a zárt forrás, úgy vesszen a közigazgatás, így ez a jövő, úgy bazármodell, aztán kiderül hogy csak akkor, ha nem a saját szakálláról van szó a száj-foss-advokatnak

Enyire erthetetlenul fogalmaztam?

1-2 felhasznalos szoftvernel milyen supportbol eljel meg ?
Mit mondtam az olyan softverekrol, amit nagy kozonsegnek fejlesztek -> OSS a celszerubb. (En fizetos Open Source licensben is gondolkozok neha, mert ugye ilyet is lehet csinalni)

Mirol mondtam, hogy szarabb? Kernel modul es root jogokkal futo stuffbol nem szivesan hasznalok zart forraskodu dolgot. Ertheto okokbal. Pl. Tul fontoss ahhoz, hogy ki legyek szolgaltata akarkinek. Nagyban korlatozza, a kernel formazhatosagat. Biztonsagi resek javitasara varnom kell mindenkeppen valami cegre.
Az meg, hogy olyan rendszerek amirol elvaras, hogy csaknem mindenki hasznalja az orszagban, ne legyenek hordozhatoak verlazito.(Mac,BSD,Linux szerencstlenek azert vagyenek win-t, hogy ne buntessek meg oket, vagy adott esetben tantargyakat tudjanak felvenni (most nem a neptun-ra gondoltam, rdesktop van azokon is, a neptunt, most nem minositem))

pl. Zart forraskodu jatekok ellen nincs kifogasom!!! De, ha megnezel open source jatekokat inakbb a grafikat hianyolod beloluk, gyenge modelek texturak kepek hangok stb. Inakabb az "art" -resze amit ingyenes OSS jatekok nem tudnak hozni.
min. 20 fos grafikus csoportal (5*8h/het), par szabadilyeben rajozlgato emberke nem tudja fel venni a versenyt. Valahogy nepszerusiteni kene a kreavativ emberek (pl. diakok ) kozott, hogy tobben csainaljank art munkakat ingyenes jatekokhoz.
(Tobbszor tobb embernek mondtam engint csinalok, ha rajzol.., mint latjatok nem lett belole semmi, pedig jo kis platform jatek enginet takolgattam ossze meg TP-ben is :) anno (6 eve)) (Ha netan most, akarnank jelentkezni rajzolo emberek kozlom 6honap-ra teljesen le vagyok terhelve, sorry)

Tervezo szoftver pl. eagle. Program fejlesztesi eszkoz LabView, matematikai programok, ha van penzem-ra, vagy a cegnek license semmi baj nincs veluk, van support lehe zaklatni oket :) (Ezekhez legalisan, hozza ferek most)

Xilinx WebISE(ingyenes) -szofvereben a zart driverek az idegesitoek, a szoftvert ne minositsuk, de az az ami igazan boszanto.

(Bar fentebb emlitettek-re Open source dolgokat hasznalok.)

Kedves, hogy verben forgo szemu, linux zelotnak gondolsz.
Szeretem linuxot, szeretem a gentoo-t, igen erzelmi szalak is fuznek hozza.
5 eve nem nezem le a win usereket,
7 eve nem hulyezem oket csak ezert, mert wint hasznalnak. (Akkor meg nem forumoztam, fiatal es boho voltam ;-) )
Igen, fel szoktam hozni Free/Open lehetosegeket.

Miert jo nekem, ha teritek embereket?
Nekem az a jo, ha hivatal akarki nem kenyszerit windows hasznalatra, ha elegen leszunk ahhoz, hogy figyelembe vegyenek minket, onnantol kezdve nem erdekel teritos dolog.

Szerintem a csomag kezelés mint ötlet igenis kurvajó. A kattintós telepítésnek a legnagyobb baja az, hogy a rendszered újratelepítéséhez rossz esetben többezret kell kattingatnod, míg egy csomagkezelős rendszerben (legalábbis elvben) egyetlen paranccsal ugyanazok a szoftverek lesznek fenn (a telepítésnél amúgy megfordul az egyébként ideális user feeling: általában a gép vár az én parancsaimra, ott azonban én vagyok a gép szolgája. Minden telepítő folyamatnak két részből kellene állnia: egy interaktív beállítós(először), és egy autmatikus csakagépdolgozikos részből). Ráadásul a telepített csomagok listája elvben egy deklaratív(szeressük) leírása lenne annak, hogy a rendszered hogy néz ki, nem pedig valami ezer ponton hasraeső folyamat.

Ami a probléma(szerintem) az az, hogy a csomagok összevissza a gép minden zúgába kerülnek be minden külső kontroll nélkül. Azaz Linuxon is egyetlen szar csomag széjjel*@##%#$% mindent. Vagy egyetlen elrontott függőség. Igaz, régebben, és lama voltam, de hullott szét mindenem egy apt-get upgrade-től annyira, hogy újrahúzás lett belőle. Márpedig a user az lama, és kész.

A másik probléma a felület. Ubuntum van, Synaptic egész korrekt lenne, de: mi a halálon gondolkodik annyit??? Párezer csomag listába rendezése manapság nem kellene, hogy hosszú másodpercekig tartson. Ráadásul minden új nézetre újra...

A függőségek kezelésére a Microsoft talált megoldást(legalábbis javaslata van rá, nem tudom, élő példák vannak-e) a .NET-ben. Minden csomag(ott szerelvény, de nevezhetjük, aminek akarjuk) szépen azonosítja magát teljesen, és megmondja, hogy melyik csomaggal hogyan akar együttműködni. Végül az összes telepített csomag leírása szép adatbázisban van, nem ezer fájlban szétszórva. Ok, az .NET, de a GNU forrásokra is működhetne(c-s környezetben is). Annyit kellene megcsinálni, hogy a fordításhoz(és a futtatáshoz is) egy virtuális környezetet hozna létre a rendszer, amiben csak a megadott csomagok vannak benne. Így azonnal látná a vak fejlesztő is (bocs), ha elrontott egy függőséget. Ezt a szétpakolt káoszban elég nehéz lenne megcsinálni persze, de hasonlót már hoztak létre persze kicsit más környezetben (lásd Eclipse bundle-k). Érdemes volna ezen elondolkodni.

Mire akarok ezzel kilyukadni: hogy például nincs olyan, hogy én a libdvd.so-t akarom, hanem szépen megmondom, hogy melyik verziót, és hogyan. Egy fordításkor nem azt mondom, hogy stdio.h, hanem azt, hogy az stdio.h-nak az adott verzióját akarom, vagy esetleg az adott verziót, vagy újabbat, amíg felülről kompatibilis marad.
Ha ezek a meta-adatok rendelkezésre állnak, akkor lehet normálisan kezelni az egész függőségi fát automatikusan, addig csak hekkelgetés van. Sajnos a problémakör hatalmas, és egységes megoldást hatalmas kérdésre az OpenSource közösség magától nem biztos, hogy valaha képes lesz találni.
Szerintem a user felé adott felület kérdése ezeknél sokkal kevésbé lényeges, ugyanis egy ilyen utopisztikus környezetben már magától menne minden :-).

egységes megoldás, opensource: ezek egymást kizáró tényezők.
Én is ilyen szoftvert használok, de minél jobban belemélyedsz, annál jobban látod, hogy a rendszered mekkora egy gány f(/)os(s), és nem azért mert így tervezték, hanem mert a sok széthúzó, állandóan változó, a többit magasról lesz?ró komponens összehangolását majdnem lehetetlen feladat megoldani.

Tendencia (nevezzük el F/OSS idiopátiás ellenállási törvénynek):
+1 megoldás = +100 ellenző, akikből 50 azt se tudja mi az, csak a flame kedvéért ellenkezik, a másik 50 meg nem lát az orrán túl sem, hiszen "miért kell ez, ha a [random gánymegoldás] is működik nálam??"

Meg az alap hozzáállás: programozzon mindenki magának billentyűzetdrivert, én is megcsináltam, tehát más is meg tudja.

Nem értek hozzá, azért kérdem mert nem tudom. Tehát az így felmásolt szoftver indítója belekerül pl egy menübe, vagy az asztalra, hogy könnyen használni is tudd? Értesül róla a rendszer, hogy van itt egy szoftver, és ezek a file-ok tartoznak hozzá?

Legkesobb az elso inditasa utan igen. Az app dirjeben van egy (par) leiro file ami megmondja mire valo, stb.
Altalaban (de nem kotelezo) minden program a /Applications-ba "telepul" (fugg attol mikepp van megoldva, mert szo szoros ertelmeben vett installer is van), onnan hamar eloszedheto, egy Command+Shift+A-val, Spotlight-tal, rapakolhato a Dock-ra, ecetera. Olyan szo szerint vett "Start menu" nincs, de ha kell megoldhato az is.

---
pontscho / fresh!mindworkz

nincs sehol fuggoseg, az app-ok lehetnek statikusan es dinamikusan linkeltek is. ket dolog van ami az utobbit mukodteti:

1. egyreszt az alap OS lib-ek ugye apple keszitmenyek, tehat nyugodtan lehet rajuk fejleszteni az elkovetkezo 3 evre, igen ritkan fognak valtozni, nem ugy mint a glibc

2. ha openszorsz lib-ekre dependal az app, akkor ugye szarban van a keszito, tehat vagy statikus, vagy a sajat konyvtaran belul van beloluk 1-1 copy

/Applications/Freeciv.app/Contents/Resources/freeciv-x.y.z/lib/libpng12.0.dylib

lol/~

egyebkent ilyenbol nekem mindossze 1 van a 143 app-bol, osx koderek - ertheto okokbol - szarnak a f/oss cuccokra, leginkabb

architektura problema sincs, mert egy bin-ben vagy lib-ben jelenleg 3-4 architektura is talalhato (rohogok is mikor mondjak itt a nepek, hogy tartanak egy-egy chrootos 32 bites kornyezetet, meg tobb lib konyvtar, meg mittomen). x86-on pedig van transzparens ppc emulator is.

lib32 ill. lib64 konyvtarvan, az onnan szedi a libet, ahol megfelelo bitszamu van.
Itt kulon fileban van. (Neha kenyelmetlen, de kevesebb helyet eszik ez a megoldas)

glibc -nem a legjobb pelda. Qt/GTK foverzioszam valtozasa oriasi kulombsegeket takar. (Ritka esemeny)
De senki nem tiltja, hogy tobb verzioban is fent legyen.

http://hup.hu/node/33194 http://www.sg.hu/cikkek/49313/uj_photoshop_most_mar_macre_is
Kulso fejlesztok eleg lassan kovetik a valtozasokat. (sg -cikk sok MAC-es embert felboszntott, a cim miatt)

Neha kenyelmetlen, de kevesebb helyet eszik ez a megoldas

Mindamellett, hogy kenyelmetlen, miert eszik kevesebbet ?

De mondok egy egyszeru peldat, hogy miert tetszik jobban ez a unibin model: van a freshnek egy Android cimu introja. Elkezdtem vele jatszani, s megcsinalodott OSX-re is. Persze linux portja is van. Csakhogy, ami unibinnel elfer egy binarisban (x86,ppc, es ezek 64 bites vonultai), az addig linuxra 4 db binaris lenne, ami kozul az usernek kell valogatnia, hogy neki melyik kell... 1 vs. 4, automatikusan megoldja az OS vs. user benazik. Amit te emlitettel az csak egy fele architekturanal pofas... Felmerulhet a kerdes, hogy mi a feneert jo, hogy van egy PPC emulator OSX alatt, en ket okot latok (amit hasznaltam is):

- futnak a regi PPC-s szaraim, tapasztalatom szerint meg igy is kb. 10%-kal gyorsabban rohangal Android 1.83-as CoreDuo+Rosetta alatt, mint 1.42-es G4-en :)
- egy gepen ki tudok szolgalni ket architekturat es 3 platformot. Gyonyoruen tudtam fixalni indian bugokat a kodban ugy, hogy nem kellett mellette meg masik csomo gepet fentartanom. A tuskom ezek utan megy a levesbe...

S szerintem helyben szamolva is kevesebb, mivel minden file utan (fs-tol fuggoen) van nemi maradek a blokkmeretek miatt, annak az adminisztracioja, joval kevesebb file, atlathatosag... szoval szerintem nem.

SG-t meg hagyjuk. Ott meg tobb "szakerto" van, mint errefele...

A tobbivel egyetertek, ha linuxrol van szo.

---
pontscho / fresh!mindworkz

Nem 3-4 arhitektura filejai vannak igy a rendszeren, hanem csak (egy)Ketto ia32&amd64.
Es nem az osszes lib, csak a leggyakrabban hasznaltak vannak meg 32 bittesre is nekem. A problem akkor jonne elo, ha kene +1 32 bittes lib, mert azt vadaszhatom(net), vagy kezzel leforgathatom. Az user elvileg :) lehet olyan ertelmes, hogy tudja milyen arhitekturaja van (es azt tolti). Kereszt forditas, emulacios lehetosegek meg vannak linux alatt is (nekm van qemum). (Tudok pl. ia32-winre , arm-softfloat-linux-uclibc...stb. forgatni)

gentoon van egy crossdev -nevezetu csomag, ami segitsegevel egy parancsra terem nekem egy gcc+binutils+gdb+libc adott arhitekturara.

A futathato dolgaimbol 64bittes szinte minden ami open-source, nem open-source dolgok miatt kell a 32 bitt,azoknak meg eleg ami van 32bittesen lib.

Roseta tud ARM -et emulalni?, En arra hasznalom.
Meg ha lassu -is 3-10* masik architekturat emulalva, de arra jo, hogy megnezem fut -e a kod.
Rosatanal mennyi a sebbeseg veszteseg? Ha qemutol lenyegesn jobb, akkor milyen trukkot hasznal annak eleresere ? (En nem nagyon tudok qemutol, jobb technikat kitalalni, ami sok architekturan sok arhitekturat kepes emulalni)

Roseta tud ARM -et emulalni?, En arra hasznalom.

(En nem nagyon tudok qemutol, jobb technikat kitalalni, ami sok architekturan sok arhitekturat kepes emulalni)

Rosetta ? Ketlem. De mint ahogy PalmOS 5+ tud Motorola Dragonball procit emulalni, ugy Rosetta tudna ARM-ot is, ha igeny lenne ra. Viszont QEmu-hoz kepest van egy oltari elonye mindkettonek, csak egy HW-t emulal, a procit. Minden mas (a rendszer libjei, kernel, stb) nativ koddal kepes futni az adott rendszeren. Ezert volt az, hogy a fentebb emlitett intro gyorsabban futott nalam emulalt PPC-vel, mint egy echte G4-en.

S ha lenne egy egyseges API (mint amivel glibc/SDL probalkozik, mint egy elso balozo), akkor kurvara mindegy lenne, hogy milyen arch van alatta.

Rosatanal mennyi a sebbeseg veszteseg?

Kb. 20-30% a nativ x86 kodhoz kepest.

Ha qemutol lenyegesn jobb, akkor milyen trukkot hasznal annak eleresere ?

Lasd par sorral feljebb.

---
pontscho / fresh!mindworkz

nem hiszem hogy nem irtam le mar sokszor, erthetoen, hogy a rosetta nem osszehasonlithato a qemuval, mert nem egy multifunkcios userspace ize, hanem teljesen transzparens mukodesu, egy celra kifejlesztett kernelmodul, es nem 1000%-os hanem alkalmazastol fuggoen olyan 10-20% koruli sebessegkulonbseg van.

Nem 3-4 arhitektura filejai vannak igy a rendszeren, hanem csak (egy)Ketto ia32&amd64.

Abban a korban, mikor 23+afa-ert hozzam vagnak egy 250GB-os LAN Drive-ot, marhara nem erdekel az a plusz 1-2GB :)

mert azt vadaszhatom(net), vagy kezzel leforgathatom.

Ez az amibol kb. mar marhara elegem van. Meg pedig, hogy a szamitogep hasznal engem, es nem en ot. Ha leteszem a seggem ele, akkor mukodjon ahogy kell, vagy a csakannyal talalkozik. Nem erek ra azzal szarakodni, hogy "x.y.z. libbol mar megint miert nincs meg a megfelelo verzio, basszameg, most megint kereshetem napokig merre van, mert csomagban nincs, es forgathatom, s javithatom a rohadt sw bugokat, melyek miatt nem fordul le". A legutobbi ilyen csomag a unixodbc volt. Olyan trivialis bugok voltak, amik miatt nem fordult le, hogy sirva fakadtam... anno MPlayernel, s most a gyarban is a policy resze, hogy a CVS/SVN-be pakolt kodnak KOTELEZO lefordulnia es MUKODNIE.

Az user elvileg :) lehet olyan ertelmes, hogy tudja milyen arhitekturaja van (es azt tolti).

A szoftvergyartas elso es legalapvetobb szabalya az, hogy "userrol ne feltetelezz inteligenciat, kulonben igy jarsz." :)
Sajnos ezt szamtalan pelda igazolta :(

Kereszt forditas, emulacios lehetosegek meg vannak linux alatt is (nekm van qemum). (Tudok pl. ia32-winre , arm-softfloat-linux-uclibc...stb. forgatni)

Tudom. Anno (es most is meg van meg) forditottam linux alatt en is w32-re, palmos-ra (motorola es arm kodot is, sot, az elso full arm kod gyartasra alkalmas env-et en pakoltam ossze). Es ugyanezek megvannak nekem most OSX ala is. Azota van az a szabalyom, hogy "ha egy windowsra keszitett kodod fut wine-vel, akkor az barmely valos windows verzion mukodni fog."

---
pontscho / fresh!mindworkz

Remek, és minden 3rd party cucc (másképp, minden ami nem része valami alapistallnak, nincs benne a cucc árában) függőség kezelés nélkül megy fel rá?

Emlékeztet ez egy kicsit pl. a windows-os gnumeric-re. Valamiért kellett egy gnumeric Windowsra is (asszony ebben vezeti a házikönyvelést, elküldte magának e-mail-ben, de apósnál csak Win volt). Van one click installer, ~200M. Hoz magával valamennyit a gnome-ból. Ha csak kiváncsi a user, és ki akarja próbálni, OK. De gondolom egy halom másik gnome alapú cuccnak is ilyen a windows-os installere. Ebben az esetben tényleg nem kell függőség kezelés.

Mi a lényeg? Ha van valami nagyobb toolkit ami nem része hivatalosan pl. az OSX-nek, és valakinek ingere támad ezen alapuló cuccokat használni, akkor üdv a shared lib előtti időkben. Azaz ezek a cuccok, ebben az esetben tényleg csak kipróbálásra jók. Feltesz, megnéz, leszed, és nem b@sz szét semmit.

Persze ezt elkerülendő, gondolom az OSX-re fejlesztő cégek kerülik az OSX-en kívüli technológiákat. Legyen. Ez is ismerős valahonnét.

Szóval IMHO, az innováció egy elég fontos eleme egy normális csomagkezelő. A Linux-ban ez volt a második dolog, ami csodálkozásra késztetett (az első az volt, hogy lehet 64K-nál nagyobb memóriatömböt is normálisan lefoglalni, de ez még 95-ben volt Borland termékek használata után).

En ugy vettem eszre az innovacio igazabol az amikor mar csomagkezelesre sincs szukseg. Es lam-lam a bekovesedett debian pont az (eleg fos) csomagkezeleserol hires.

Mellesleg fent irtam a freeciv-es peldat, mivel abbol nincs Quartz port, igy ott oda van melle rakva a teljes gtk2, szoval nem okadja ossze a rendszert ilyen undorito szarokkal, eleg katasztrofa az is hogy ilyen UI-t kell hasznalni. Mivel mas gtk-s programom halistennek nincs, igy a helyfoglalasa (42Mb) kevesse erdekel.

/Applications/Freeciv.app/Contents/Resources/freeciv-x.y.z/lib/libgtk-x11-2.0.0.dylib

Hát mit mondjak, ha te reprezentatív minta vagy, akkor az OSX felhasználók pontosan akkora birkák mint az r=1 MS userek, már bocs. Ablakozó felületből az a tökély, amit szent és imádott Cégük a seggük alá tol. Minden más katasztrófa. Ilyen user környezetre könnyű OS-t csinálni, ugyanis eszik, nem eszik ez van. Nincs is igény másra. Cáfolj meg!

( egmont | 2006. 12. 20., sze – 15:32 )

Alapvetően totál egyetértek vele... de mégiscsak furcsa ezt pont a Debian fejlesztőitől hallani... Valahogy úgy érzem, ha sorba rakjuk a disztrókat, hogy mennyit tesznek ezen probléma megszüntetése érdekében, hát, szerintem enyhén szólva sem lesz az elsők közt a Debian.

Egy konkrét eset: minap valami 3rd party progi libtiff.so.4-et keresett. Hosszas vadászás után megállapítottam, hogy a hivatalos legújabb libtiff csomag libtiff.so.3-at szállít. Hát akkor vajon honnan jön a 4-es? Kiderült, hogy a mainstream fejlesztők elkövettek egy ABI-inkompatibilis változtatást a 3-as sorozat folyamán. A Debian ezért úgy tartotta korrektnek, hogy ők átpatchelik a progit, hogy immár .so.4-et szállítson. Ily módon egy egyszeri kellemetlen átállás helyett (amit már rég elfelejtettünk volna azóta) örökre elkötelezve magát a hivatalostól eltérő verziószám és ezáltal a többi disztribúcióval inkompatibilitás mellett. Pedig ha nagyon-nagyon ragaszkodtak volna a verzióváltáshoz, akár .so.3.1-es SONAME-et is belehegeszthettek volna. Attól most ugyan nem lenne jobb semmi, de legalább majd ha egyszer lesz hivatalos libtiff-4.0, akkor visszazökkenhettek volna.

Annak a célnak, amiről Ian álmodozik, 2 alap pillére van szerintem. Az egyik a többi disztribúcióval való minél jobb kompatibilitás, minél kisebb eltérés. A másik pedig az egész disztró rendszerszemlélettel történő fejlesztése, tehát nem azt csinálni, hogy mindenki más-más minőségben hegesztgeti a saját csomagjait, hanem koordinált módon, egységesen fejleszteni azokat és adott esetben egy-egy szempont szerint mindet átdolgozni egyik release-ről a másikra. E kettő közül egyikben sem érzem erősnek a Debiant.

En olyan megoldason gondolkook, hogy mi lenne ha, gentoo -emerge rendszeret ravennenk ,hogy .deb .ill .rpm csomagokat gyartson.

Egy ebuild, mind felett :)
Egy kicsit kozelitene a tobbi disztro a gentoo -hoz, ill. biz. emerge szabalyokat lehetne beletenni, ha az elekszulo csomagot mas rendszerre szanjuk.

abszolult igazad van, és debiantól nem is várható változás..

én állandóan szivok a rohadt függőségekkel, viszont forditva is van hogy néha meg hiányzik...
olyan nevetésgesnek tartom hogy szerver gépen(debian) kerülöm a csomagokat.
inkább forrásból teszem fel. persze mindjárt irtok hát ez a linux ez a geek.
szerintem meg nevetséges

persze nem lehet mindent forrásból mert a 20. rohadt libjét valaminek már beleörülök mire felkerül.
libek lennének csomagból de régiek..

nem linux, freebsd ott kiadom make install clean (persze reménykedhet az ember hogy nem ránt magával és nem fordit le valami gnome, stb szörnyűséget), de jobb mint 1esével felrakni..

+hány distnél van downgrade csomagoknál?

mekkora baromság a linux desktop év, én tippem sokáig nem is lesz.. és pont ezek miatt, mert nem változtatnak
ott kéne kezdeni hogy most egy dist rágyur a desktopra és akkor tényleg megoldja a csomagok dolgát, és nem csak azért hogy a "kezdő felhasználóknak "könnyü legyen hanem azért is hogy bárki aki gyorsan akar valamit csinálni meglegyen.

azért kiváncsi leszek hogy pár év mulva mi lesz, kell e keresni .so.x.x libet, hogy felmenjen valami.

Bár még nem rég vagyok linux felhasználó, de maximálisan igazat adok nektek az eddig felvetett hiányosságok terén.
Összefoglalva egy kezdő véleménye:
Sajna a csomagkezelés disztrónként különbözik és vannak problémái. (Mandrake, SuSe, Debian alapú disztrók...) --> Szerintem ezt egységesíteni kellene és a nagyon kezdőknek egy tényleg kattintgatós disztró lehetőségét felajánlani.
Forrásból fordítani időigényes (csak a kedvencs programjaimat fordítom :) viszont néhány progit csak így tudok igényeimnek megfelelően telepíteni.

Nekem egyelőre ennyi a véleményem.

( pakos | 2006. 12. 20., sze – 17:45 )

A klikrol itt meg hirbol sem hallott senki? OSX-szeru 'installalast' tesz lehetove: letoltod a cmg-t, katt ra, kesz. Nem kell, letorlod.

http://klik.atekon.de/wiki/index.php/What_is_klik

Nyilvan nem alaprendszer terjesztesere valo, de az ISV-k problemajat szepen megoldhatja.

Egyebkent nekunk, mint ISV-nek abszolut nincs problemank deb vagy rpm csomagok legyartasaval, ugy beszeltek rola, mintha ezt csak szabad szoftvereknek lehetne. Bar nekunk, mint ISV-nek speciel azzal sincs problemank, hogy 2 ev *garanciat* adjunk az altalunk elkeszitett szoftverek specifikacio szerinti mukodesere, szoval mi biztos csodabogarak vagyunk :)

( whitehawk v | 2006. 12. 20., sze – 18:15 )

Az apt/dpkg egy fos. Ha hibás a package nem írja ki, hogy checksum error vagy bármi, csak elhal. Biztos nem probléma, csak portagehez szoktam...

Software is like sex, it's better with a penguin. :D (r)(tm)(c)

Jó, tudjuk... Az a helyzet, hogy szar a dpkg-apt, utáljuk nagyon, de nincs olyan, ami egyértelműen jobb lenne; olyan pedig pláne nincs, amelyik annyival jobb lenne, hogy megérje átállnunk rá (ami nem kis munka, az RPM-es átállási kísérletbe 1-2 hónap melót már beleöltem, mire meg tudtam állapítani, hogy nem igazán érdemes folytatni).

Mert fontosabb dolgaink is vannak. Sőt, szinte csak fontosabb dolgunk van. Igyekszünk egy felhasználó-orientált disztribet csinálni. Felhasználó alatt ne rendszergazdára gondolj, hanem Gizikére. Minden olyan fejlesztés, ami a desktopot jobbá teszi, milliószor fontosabb, mint egy háttérben lévő komponens, amelyet Gizike jó eséllyel a telepítés után egyetlen egyszer sem használ.

A csomagkezelő pusztán egy eszköz. Szar, de működik, meg lehet vele oldani amit az ember meg akar oldani. Nem ez a cél. A cél egy felhasználói oldalról nézve jó rendszer. Jól működő, stabil, összecsiszolt alkalmazások, jó és kényelmes hardverkezelés stb stb stb...

Én például igen. Hibajelenség magyarázata, kódelemzés, hibás viselkedés megindoklása, patch. Mindez 2 éve. Azóta párszor megpingeltem őket. Használható hozzászólás egy sem érkezett. Ajánlom minden dpkg-apt-debian fanatikusnak! Volt már korábban pár egyéb dpkg vagy apt bugreportom, azoknál sem volt sokkal jobb a hozzáállásuk.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281057

..."If you continue developing with this
approach, all you'll reach is that I'm going to fix these bugs for myself
and not send any feedback at all. It's not worth it for me to spend my time
explaining the story if noone's listening to me. Is this what you want? I
hope not..."

Nem érdekel, akár fizetni is hajlandó vagyok(*), csak legalább böfögjenek már valamit abba a nyamvadt bugreportba, írják már meg, hogy fizess X dollárt és akkor hajlandóak leszünk átnézni és berakni...

(*) Hajnali 3 körül volt, amikor kb. 1 órányi keresés után végre megfogtam a bugot, és hosszú perceken keresztül könnyezve röhögtem rajta. Ilyen élményben még nem volt részem fejlesztés során. Jobb volt, mint egy jó mozi. Szóval egy mozijegy árát simán megéri :)

Asszem van egy sajátos humorérzéked a humorod mellé, így látatlanba'. :) Gondolom mezei halandók mint én, csak azon nevettünk volna hogy nevetsz. De azért majd írd le egyszer hogy mi is volt a nevetség tárgya, hátha! Ha meg lehet szokni pl. Russell humorát vagy Einsteinét, még nincs minden veszve. :)

Hát, amikor már alig bírod nyitva tartani a szemed az álmosságtól, és hirtelen megvilágosodsz, és átlátod azt a pár sornyi kódot, amiben több a hiba, mint a jó rész, mindez a Világ Legjobb Disztribúciójának Tökéletes Csomagkezelőjében, nos... lehet hogy kell hozzá egy sajátos humorérzék is, de valahogy nagyon jó érzés volt :-)

Ugy latszik, arrafele a 2 ev a minimum, az en egyik patch-em is kb. ennyit ult naluk, amig egy modositasat vegre integraltak. Pedig ott is vilagos volt, mekkora bug van a http metodusban, ami azert meglehetosen gyakran hasznalt :( Az apt/dpkg paroshoz nem nagyon mernek erdemben hozzanyulni, annyi durva hack van mar bennuk...

( sirkalmi | 2006. 12. 20., sze – 20:50 )

Elolvastam, jópár hozzászólást és szerintem nagy részét a problémáknak orvosolná az LSB elterjedése. Nagyon sok lib-et támogat már jelenleg is, és ahogy elnézem a jövőjét mégtöbbet fog. LSB Roadmap
Ha jól értelmezem itt az a lényeg, hogy ha LSB kompatibilis csomagot akarok gyártani akkor mindent statikusan bele kell forgatni a programba ami nem része az LSB-nek így függőségnek elég pl ezt megadni: PreReq: lsb >= 3.1
Ahogy egyre több lib kerül bele az LSB-be úgy egyre kevesebb dolgot kell statikusan beleforgatni a programunkba.
Itt egy Linuxvilágos cikk a témában. Fejlesztő eszközök is rendelkezésre állnak LSB kompatibilis programok készítésére.

--
sirkalmi

Személy szerint hányingert kapok az LSB-től. Persze, lehet hogy bizonyos szempontból (amiről most van szó) jó dolog, de szerintem a most tárgyalt problémát nem egészen ebből az irányból kéne megközelíteni.

Viszont nézzük meg, miről is szól az LSB. Arról, hogy dokumentálja, ahogy néhány nagy gyártó cuccai pár éve kinéztek (és még véletlenül sem azt, ahogyan logikus lenne), tehát kőbe rögzíti a harminc-iksz év alatt evolúciós úton kialakult megoldásokat (elegánsakat és fölöttébb gányakat egyaránt), és azt mondja, hogy na akkor mostantól ennek így kell lennie. Ezáltal szerintem segíti ugyan a 3rd party programok telepítését, de útját állja mindenféle innovációnak, lelassítja a fejlődést és szinte kizárja a gyökeresen új koncepciók megjelenését.

Azért ezt nem nevezném "néhány" nagyobb gyártónak: Members
Nem tudom mennyire demokratikus a Free Standards Group szervezet működése, remélem nem olyan fafejűek mint ahogy te felvázoltad. Az viszont szerintem természetes és talán kívánatos is, hogy minél nagyobb egy szervezet, vagy egy rendszer, annál nagyobb a tehetetlensége. Olyan ez szerintem mint egy nagy tanker hajó és a jet-ski esete. Utóbbi könnyebben irányt vált mert kevesebb rajta a teher. Azt hiszem az Uhu Linux egy jet-ski. Ja és szurkolok hogy tanker legyen! ;-) Hajrá magyarok! :-)

--
sirkalmi

Szerintem az LSB csak egy rövidtávú gyors hack.
Legalábbis a rendelkezésre álló könyvtárak kérdésében(maga a szerző is belátja részben szerintem).
Az API, amin keresztül ikonkát hozhatunk létre, meg reggelhetjük magunkat már jobb ötlet.
Amúgy kicsit nevetségesnek érzem azt, hogy van külön programozó, és külön csomagoló a Linux világban. Ugyanis egy normális program megmondja magáról, hogy mitől függ (legalább a dokumentációban), akkor meg a csomagolás már automatikus is lehetne disztribenként más szájízzel, automatikusan. Hülyeség???

Reszben igazad van a csomagolas kapcsan, de sajnos nem minden esetben mukodhetne a dolog. Foleg a verziozott fuggosegek kapcsan lenne nehez megmondania (ezek elsosorban persze nem libek, de ott is elofordulhat) a programozonak, hogy melyik disztribucio melyik csomagjanak melyik verziojatol fuggjon - nem is nagyon tudna kovetni... Szerencsere eleg sok esetben jol egyuttmukodik az upstream es a csomagolo, sokszor egybe is esik a ketto. Idonkent meg iszonyu hulyesegeket csinal a csomag karbantartoja, es nem lehet meggyozni arrol, hogy marhasagot csinal...

Egyebkent a csomagolas messze nem trivialis dolog, altalaban csak azok hiszik ezt, akik meg eletukben nem tartottak karban par tucat csomagot.

Nem tudom, hogy az OSGI-t ismered-e. Ott részben hasonló problémára adtak szerintem igen frappáns választ. Persze operációs rendszerre, meg teljes szoftverekre kivetíteni elég merész gondolat, de hát erre valóak a fórumok :-).
Egy nagyon jó felderítő eszköz lehetne szerintem a virtuális környezet: az operációs rendszer felügyelné, hogy az adott csomag tényleg csak a megadott csomagok erőforrásait érhesse el.

"Amúgy kicsit nevetségesnek érzem azt, hogy van külön programozó, és külön csomagoló a Linux világban."

Én meg ezt érzem nevetségesnek...
Egy programozónak miért kellene csomagot csinálni ~200 különböző disztribhez?

Nyílván neki ez nem dolga/érdeke, max a 2-3 népszerűbbhöz csinál.

Csomagot igazán a disztribútor tud készíteni, mert neki van meg az összes szükséges információ a saját kiadásához...

--
by Mikul@s

( Gabucino | 2006. 12. 21., cs – 14:24 )

latjatok azert szar a helyzetetek mert egy ilyen hotegyszeru temarol is ennyit tudtok pofazni.