"akkora kuplerájnak tartom [az unixos konyvtarszerkezetet] továbbra is"

Ha mar poliverzum kommentjenel tartunk, egy erdekes idezet a CLR via C# konyvbol:

The second reason that contributed to the aforementioned reputation of Windows is instal- lation complexities. Today, when most applications are installed, they affect all parts of the system. For example, installing an application causes files to be copied to various directories, updates registry settings, and installs shortcuts on your desktop and Start menu. The prob- lem with this is that the application isn’t isolated as a single entity. You can’t easily back up the application since you must copy the application’s files and also the relevant parts of the registry. In addition, you can’t easily move the application from one machine to another; you must run the installation program again so that all files and registry settings are set properly. Finally, you can’t easily uninstall or remove the application without having this nasty feeling that some part of the application is still lurking on your machine.

The third reason has to do with security. When applications are installed, they come with all kinds of files, many of them written by different companies. [...]

Assemblies don’t dictate or require any special means of packaging. The easiest way to package a set of assemblies is simply to copy all of the files directly. For example, you could put all of the assembly files on a CD-ROM and ship it to the user with a batch file setup program that just copies the files from the CD to a directory on the user’s hard drive. Because the assemblies include all of the dependent assembly references and types, the user can just run the application and the runtime will look for referenced assemblies in the application’s directory. No modifications to the registry are necessary for the application to run. To uninstall the application, just delete all the files—that’s it!

Szerk: lehagytam egy picit belole az ejjel, potoltam.

( zaphodb v | 2012. 11. 03., szo – 09:12 )

egy könyvtár, egy exe, meg egy ini. ennél többre nem lehet szükség :-)

--
nincs aláírásom

( Luther | 2012. 11. 03., szo – 10:02 )

Ahogy mindennek ennek is megvan a logikája. Nem értem miért lenne kupi...
--------------
“If there were no hell, we would be like the animals. No hell, no dignity.”

( poliverzum | 2012. 11. 03., szo – 11:42 )

Bocs de az angol tudásom nem a legjobb... Szegényes inglis ismereteimmel mintha azt hüvelyeztem volna ki az általad idézett részből, hogy azt hányja a windows "szemére", hogy abban nem lehet könnyen megtalálni/áthelyezni/uninstallálni a telepített programot (illetve annak fájljait).
Ha nem tévedek és valóban erről van szó, akkor fogalmam sincs, ennek mi köze van a GoboLinuxhoz! Ott ugyanis épp ellenkező a helyzet. Vagy félreértettelek volna és nem a gobót akartad ezzel szapulni? Ha így van bocs és a legalázatosabban elnézésedet kérem (bár akkor nem voltál elég egyértelmű asszem). Ugyanis a fentebb vázolt helyzet épp nem a GoboLinuxra érvényes, hanem a hagyományos unixos könyvtárszerkezetre.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Es pont ez valtozik meg a .NET-es programoknal, ahol jellemzoen a programmal jon minden, ami neki kell (legalabbis az alapkoncepcio ez, aztan neha vannak kivetelek), nem irogat ezer helyre a registrybe, egy helyen van minden.

Ossze lehet hasonlitani ezt, valamint az OSX-es alkalmazastelepitest a Linuxos csomagkezeleses mokaval.

Szerk: ah, megvan mi a gond, az ejjel lehagytam egy bekezdest, amit akartam. Igy remelem erthetobb a kulonbseg.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( uzsolt v | 2012. 11. 03., szo – 18:23 )

Tehát igazából a gond, hogy nincs szabvány. Míg linuxéknál van, amit csomagkezelőnek hívnak.

Persze ha ugyanazt a libet használja 100 program, akkor az a lib 100-szor lesz fenn? :) Mondjuk amíg egy rendes csomag/programkezelés nincs windows esetében, addig ennél jobb és bolondbiztosabb (és helypazarlóbb) megoldás nincs.

Erre talaltak fel .NET eseten a GAC-ot. De amugy igen, alapbol fenn lesz 100x. Masreszt meg egy csomo problemara ad kesz megoldast a .NET FW, amire mas program eseten valoszinuleg kulon libre lenne szukseged.

Csomagkezeles meg nem oldja meg az eltero verzioju libek problemajat, csak nagyon kenyelmesen feltetelezi, hogy minden programnak jo lesz az, ami a csomagkezelobol jon, aztan ha megse, akkor majd a karbantarto sziv vele.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Erre talaltak fel .NET eseten a GAC-ot."
Ami ugyebar a sytem classpath Java eseten :)
"Masreszt meg egy csomo problemara ad kesz megoldast a .NET FW, amire mas program eseten valoszinuleg kulon libre lenne szukseged."
Mint a Java SE API :)

Nem veletlen, hogy ezek az enterprise frameworkok ugyanazt a megoldast hasznaljak ugyanazokra a problemakra. De hat a nagy enterprise Linux system nem tanul ebbol, mert ok okosabbak.

Igen, nyilvanvaloan ugyanaz Java-ban is. Csak Java-t kevesbe ismerem.

Szerk: de hogy ne jojjon senki azzal, hogy bezzeg mar megint a menedzselt nyelvekkel jovunk. OSX-en van egy - szerintem - szep megoldas az egyes libekre, Frameworks cimszo alatt. Lenyege, hogy a [~]/Library ala bepakolhatoak az ilyen libek. Ezeknek van egy fix konyvtarszerkezete, lehet tobb verzio (+symlink a "current"-re) fenn + a C/C++/ObjC -s headerek is ott szerepelnek. Na meg persze a binarisok meg az egyeb szuksegletek.

Mindez gyakorlatilag ugyanaz, amit a .NET is megcsinal (es gondolom a Java is): ott minden assembly hordozza magaval a magaban foglalt modul(ok) metaadatait, amivel fel lehet epiteni a publikus interface-jat az adott assemblynek. OSX-en, ha XCode-ban hasznalni akarok egy frameworkot, akkor csak fogom, kibokom a listabol, oszt' csokolom. Nem kell .h fajlokat vakaraszni, .lib fajlokat berantani, stb. Az XCode fogja, behuzza magatol a framework altal szallitott .h fajlokat es a kesz binaris hasznalja a telepitett binarisokat. Mennyivel szebb megoldas mar.

Viszont a nagy kulonbseg: nem kell semmifele csomagkezelo egy-egy ilyen framework tutujgatasahoz, akar siman Finderbol meg lehet oldani mindent.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

.NET kornyezet ala minden CLI-kompatibilis programozasi nyelven tudsz szoftverr kesziteni. Van par ilyen nyelv, nem csak a C#.
Masreszt minden szabvany nyilvan azok szamara elonyos, akik betartjak. Pont abbol van a gond, ha letezik egy problemara szabvanyos megoldas, de van aki leszarja a szabvanyt.
Aki nem szabvanyos megoldast csinal, az magaval es az ugyfellel is kitol: az ugyfelnek vendor lock-in, a szallito meg elesik azoktol a megrendeloktol, akik szabvanyos megoldast varnak el.

A dependency hellt nem a platformot alkotok (azaz a Sun/Oracle mernokok) keszitettek, ok adnak egy jo infrastrukturat.
Azonban a sok fejleszto ezt keresztbeszarja, es ossze-vissza kodol, ami persze tud engem is idegesiteni, voltam is emiatt ideges, mert sokan meg azokat az eszkozoket, amiben van beepitett fuggosegkezeles (OSGi, Maven) sem tudjak hasznalni. Lasd uDIG es 4 nap szivas.
Masreszt: munkaban a keszitett szoftverek egyaltalan nem Windows gepeken futnak. Ami jo dolog. Ha Windowson fejlesztek es tesztelek, de nem Windowson fog futni elesben a rendszer, akkor a programozo is kenyszeritve van a platformfuggetlen kodolasra. Egy platformfuggetlen nyelven elony az, ha heterogen rendszereken fejlesztenek ra :)
Csak egy pelda: alap volt, hogy Windows XP-n fejlesztek es lokalisan tesztelek, a ceges tesztkornyezet Windows Server, az ugyfel tesztkornyezete egyfajta Linux disztribucio, de az eles kornyezet egy masik Linux disztribucio. Mukodtek is a dolgok rendesen.

"Csak egy pelda"

Erről eszembe jutott az, ami előző melóhelyemen volt: alapvetően mindenki XP-n fejlesztett, vége felé néha belerondítottam a képbe OSX-el, volt egy megrendelők felé publikált teszt oldal, az Linux, végleges meg általában szintén Linux.

Aztán mit ad Isten, egyik rendszernél fel is merült, hogy az user jobb szeretné, hogy ha nem Linuxon, hanem Windowson futna, mert se emberük, se akarat nincs +1 Linuxos OS-hez.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Míg linuxéknál van, amit csomagkezelőnek hívnak."
Ahány csomagkezelő, annyi "szabvány".
Meg ahány disztribúció, annyi szabvány.
Van ugye a Linux Filesystem Hierarchy Standard, ami annyit is ér. Van aki betartja, van aki nem.
Linuxéknál mi a szabvány, amit mindenki betart, de tényleg?
Hol vannak az initscriptek? rc.d alatt? init.d alatt? Esetleg máshol?Az apache-ot httpd-ként vagy apache2 néven konfigoljk (Red Hatnál ugyebár httpd a neve).
És hasonlók.
Ebben hol a szabvány?
"Mondjuk amíg egy rendes csomag/programkezelés nincs windows esetében"
MSI. Az infrastruktúra adott. De nem kötelező használni, és ez ugyanúgy baj, mint Linuxnál. A Windows 8-as RT alkalmazásoknál nem lesz 3rd party út. És ez jó.
"Persze ha ugyanazt a libet használja 100 program, akkor az a lib 100-szor lesz fenn"
Na mert aztán Linuxnál ez nincs meg. Minden komolyabb program az általa hazsnált libeket csomagolja magával, mert nem tudhatja, hogy a rendszer, amin fut, mit nyújt. Ún. self-contained alkalmazások.

Röviden és tömören: a szabványok disztrónként változhatnak. De legalább egy disztrón belül egységes.
Windows alatt "csomagtelepítés" esetén pedig semmi egység nincs. Össze-vissza dobálják be magukat a programok a start menübe, a különféle könyvtárakba mappákba, registry-be, aztán eltávolításkor továbbra is ott maradnak a nyomok, stb. MSI... cseszhetem, ha csak az MS-es progik használják, és az egyebek nem. És nem is tudom rákényszeríteni. Míg linux esetében a csomagolók kényszerítik bele a progikat a csomagszabványba.

Az általad említett további kérdésekre a válaszom: RTFM :) A legtöbb disztró dokumentációjában ezek a specifikus dolgok benne vannak. Amikben meg nincs... szóval ha ezeket a konfigokat és initszkripteket keresed, könnyen megtalálod (ui. ha már egyáltalán eszedbe jut keresni, akkor már van valami fogalmad a dolgokról :) ).

"Na mert aztán Linuxnál ez nincs meg. Minden komolyabb program az általa hazsnált libeket csomagolja magával, mert nem tudhatja, hogy a rendszer, amin fut, mit nyújt. Ún. self-contained alkalmazások."
Hm? Én speciel mindent csomagból telepítek, és egyik függőségi listája se üres (na, jó, de igen, de azok az alapdolgok).

"Össze-vissza dobálják be magukat a programok a start menübe, a különféle könyvtárakba mappákba, registry-be, aztán eltávolításkor továbbra is ott maradnak a nyomok, stb. "

RTFA. Ezt akarja tobbek kozott felszamolni a .NET-ben az MS. Persze, ha hulye a programozo, azzal nem lehet mit kezdeni.

Btw. registry. Ha eltavolitom a Firefoxot, le fogja nekem szedni minden usertol a ~/.Firefox-ot? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Értem, hogy ezt akarják felszámolni, csak persicsb hozzászólására reagáltam - márhogy az eddigi windows programtelepítői szabványhoz képest a linux felhasználói el vannak kényeztetve.

A registry-ben nem csak user-specifikus dolgok vannak (emlékeim szerint), és sokszor találtam már olyat, hogy ottmaradt. Persze ez a programozó hibája, igaz. Persze a RegCleaner progi csodákat művelt ilyenkor :)

Valoban nem csak az, hanem pl. COM objectek is oda voltak bejegyezve. (Ez is kiesik .NET-tel). Alkalmazasszintu beallitasok detto. Jo, Windows rendszerbeallitasok meg maradnak, de az mar csak elfer ott.

Viszont nem valaszoltal a kerdesemre. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Egy 3rd party, urambocsa esetleg nem szabadon terjesztheto szoftver (mint pl. Oracle JDK, JRockit, Oracle DB) fejlesztoje mit csinaljon? N+1 db disztrora csinaljon telepitot?
Nem, ott is egyedi installerek vannak. Es akkor mas kesz, szet is van szedve a nagy szabvany koncepcioja.
Windows alatt is van ajanlas arra, hol mit kell tarolni, van aki betartja, van aki nem.
Linux alatt ugyanez igaz.
Az egy dolog, hogy az adott distrohoz csomagot keszitok a szabadon terjesztheto szoftverekkel mit csinalnak.
De a kereskedelmi szoftverek eletet ugyanugy nem konnyitik meg. Vagy azt mondjak, tessek, itt a csomag Ubuntura meg Red Hat-ra, a tobbiek meg elmehetnek a fenebe. Melyik a jobb?

Ne csodálkozzunk, hogy a Linux-közösség panaszkodik sokszor, hogy nincs proprietary szoftver normálisan Linuxra. Akár userspace, akár kernelspace (device driver).
Igazi szabványok, központosított fejlesztés nélkül nem is lesz.
Amúgy ez megint az, hogy aki tényleg dolgozni szeretne Linuxszal, ott alap a proprietary szoftver. Mondjuk egy tudósnak és mérnöknek Matlab, Mathematica. Ott is egyedi installerek vannak.

,,De legalább egy disztrón belül egységes."

Ez nem igaz. Ha jól emlékszem a hírekre, az elmúlt néhány időn belül az arch, a bubi, a fedora, az etc is variálta a könyvtárszerkezetét.
Arra is van példa, hogy egy disztró két kiadás között csomagkezelőt váltott (ha más nem, akkor puppy)

Puppy linux felhasználó

Uzsolt, te messze tájékozottabb vagy ilyen téren mint én, kérlek mondd meg nekem miért nem fordítva csinálták, hogy az /usr/lib legyen symlink a /lib -re? Nekem az messze logikusabbnak tűnt volna.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Igen, hát ha a libeket egy könyvtárba pakolták, akkor megtehették volna ezt a binekkel is, továbblépve így a gobósodás útján. Semmi értelme a külön könyvtáraknak. Ha azt akarják hogy valami binárist csak a root futtathasson, akkor egyszerűen úgy kell beállítani rá a chmodot és kész.

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Tegyük fel, hogy a /usr-t egy nfs mountra teszed. Normális esetben az init eljut a /etc/fstab-ban felsorolt fájlrendszerek felmountolásáig úgy, hogy addig csak a /bin és /sbin alatti binárisokat futtatta, majd a mount után már használhatja a /usr/bin és /usr/sbin alatti binárisokat is. Viszont ha az nfs mount nem elérhető, akkor az init hibára fut, és ekkor jó lenne diagnosztizálni, mi volt a hiba. A ping egy elég fontos diagnosztikai eszköz ebben az esetben, ezért a /bin alá került, hogy ilyen hiba esetén elérhető legyen. De a traceroute már kevésbé lényeges (hiszen a saját hálózatod topológiáját valószínűleg amúgy is ismered, vagyis pár ping-gel kiváltható), ezért az nfs mountra is kerülhet, ahol könnyebb karbantartani. Ugyanis ami a /bin és /sbin alatt van, azt minden gépen külön kell karbantartani, ami az nfs mounton van, azt elég egyszer, körpontilag.

Nem vagyok tájékozottabb, csak ezt a rendszert használom, és követem az eseményeket :)
Egyébként nem tudom, miért pont ez az irányú linkelés történt. Talán azért, mert a /usr/lib-ben több dolog van, így ő az erősebb, ő marad talpon, és a /lib könyvtárat elnyomta :)

Szerk.: szerintem innen indult a dolog.