BeOS/Haiku: Thread ufficiale

[trapanator]

Originariamente inviato da hexaae

Spiega come e quando hai avuto problemi di dll dependency hell con Windows che da XP in poi gestisce la cosa tramite il SideBySide. Forse su Win 2000 e precedenti....

un banale esempio: 2 programmi che usano una libreria TIFF.

Windows XP dà la priorità a quella che si trova in system32, ignorando quella nella cartella (con una versione più nuova) dell'applicazione (ad esempio un'applicativo portabile), ecco il problema.

[hexaae]

Originariamente inviato da trapanator

un banale esempio: 2 programmi che usano una libreria TIFF.

Windows XP dà la priorità a quella che si trova in system32, ignorando quella nella cartella (con una versione più nuova) dell'applicazione (ad esempio un'applicativo portabile), ecco il problema.

Veramente funziona esattamente al contrario il meccanismo di caricamento delle dll condivise da WindowsXP in poi: dà la priorità alla dll nella homedir del programma e poi a System32, come ho già detto. Windows, questo sconosciuto (da un punto di vista tecnico)...
Scriviamo cose vere, grazie.

[Kanon]

Originariamente inviato da hexaae

Veramente funziona esattamente al contrario il meccanismo di caricamento delle dll condivise da WindowsXP in poi: dà la priorità alla dll nella homedir del programma e poi a System32, come ho già detto. Windows, questo sconosciuto (da un punto di vista tecnico)...
Scriviamo cose vere, grazie.

Può dipendere dalle chiamate dell'eseguibile? Ho avuto a che fare tempo fa con dei programmi che solitamente davano la priorità alle .dll interne alla cartella, poi di punto in bianco da una versione all'altra hanno cominciato a far riferimento alle .dll in system32 (ma non saprei dire se un windows update ci ha messo lo zampino).

[hexaae]

Originariamente inviato da Kanon

Può dipendere dalle chiamate dell'eseguibile? Ho avuto a che fare tempo fa con dei programmi che solitamente davano la priorità alle .dll interne alla cartella, poi di punto in bianco da una versione all'altra hanno cominciato a far riferimento alle .dll in system32 (ma non saprei dire se un windows update ci ha messo lo zampino).

No che non può. Mi sembra molto improbabile questo fatto dato che l'OS funziona in un certo modo e basta. Non ho idea però di cosa sia successo su quel sistema... C'è anche gente che usa spesso i cosiddetti pulitori di registro su Win che fanno casini pazzeschi e non servono a niente...

-Cmq stiamo andando off-topic, torniamo a parlare di Haiku e delle sue scelte...-

[pabloski]

oh ma a proposito, se ho capito bene ( non ho letto la notizia ufficiale però ) quelli di haiku parlano di package manager e non di come hanno intenzione di operare la gestione delle dipendenze

voglio dire, un package manager lo puoi mettere pure su mac os x, ti scarica i file .dmg e ti installa i programmi, ma alla fine la logica di gestione dell'installazione rimane la stessa

[hexaae]

Originariamente inviato da pabloski

oh ma a proposito, se ho capito bene ( non ho letto la notizia ufficiale però ) quelli di haiku parlano di package manager e non di come hanno intenzione di operare la gestione delle dipendenze

voglio dire, un package manager lo puoi mettere pure su mac os x, ti scarica i file .dmg e ti installa i programmi, ma alla fine la logica di gestione dell'installazione rimane la stessa

Infatti.... Ci sono link per i dettagli di come verrà implementato?

[trapanator]

Originariamente inviato da hexaae

Infatti.... Ci sono link per i dettagli di come verrà implementato?

http://www.haiku-os.org/blog/zooey/2...nt_first_draft

[fano]

Originariamente inviato da pabloski

oh ma a proposito, se ho capito bene ( non ho letto la notizia ufficiale però ) quelli di haiku parlano di package manager e non di come hanno intenzione di operare la gestione delle dipendenze

voglio dire, un package manager lo puoi mettere pure su mac os x, ti scarica i file .dmg e ti installa i programmi, ma alla fine la logica di gestione dell'installazione rimane la stessa

Purtroppo lo vogliono fare nel modo sbagliato... niente dmg/bundle, ma pacchetti dipendenze file sparsi ovunque per il fs... più un ulteriore incasinamento sti pacchetti vengono montati (?) e son pure RO... per modificare un file di configurazione in /etc devi praticamente ricreare il pacchetto da capo!
Comodo, no?

I linuxiani saranno orgogliosi di loro

Come complicare a dismisura una cosa che poteva essere semplice: non dovrebbero esistere dipendenze

[BeBarrett]

Originariamente inviato da fano

Purtroppo lo vogliono fare nel modo sbagliato... niente dmg/bundle, ma pacchetti dipendenze file sparsi ovunque per il fs... più un ulteriore incasinamento sti pacchetti vengono montati (?) e son pure RO... per modificare un file di configurazione in /etc devi praticamente ricreare il pacchetto da capo!
Comodo, no?

A me sembra che lo stiano implementando nel modo giusto, la directory /boot/common/jailed ospiterà i package che verranno montati in una sottodirectory, il vantaggio sta proprio nel fatto che basta smontare tutti i package per ripulire il sistema da qualunque app, cosa attualmente impossibile con un qualunque package manager linaro.
Inoltre i package montati appariranno subito in /boot/apps (e presumibilmente nel menu della Deskbar) che sarà un link a /boot/common/pkg-tree/apps. La cosa sembra complessa in realtà all'utente basterà scaricare il file hpkg, copiarlo in jailed ed il sistema si occuperà di montarlo, e da subito sarà possibile utilizzarlo lanciandolo da /boot/apps, oppure dal Terminale, o da dove è più opportuno. Per quanto riguarda il discorso dei bundle è altrettanto semplice, i package che si prestano ad utilizzare le lib del sistema non includeranno lib, altri progetti le includeranno. Il problema non si pone, semplicemente per il fatto che se un package "sporca" di file la sottodirectory basterà smontarlo, inoltre va considerato che generalmente su Haiku si punta al software nativo.

http://www.haiku-os.org/blog/zooey/2...ly_near_future

ciao

[fano]

Mah comunque lo si voglia mettere complicato è complicato... poi sta cosa delle librerie in galera (poverine ) riuscirà davvero a proteggere dal dependency hell o se apllicazione xyz vuole la libreria strafic@.so e quindi Haiku la aggiorna non c'è il rischio che tutto il resto delle applicazioni portate (o peggio se modifica una libreria del SO tutto Haiku, ma questo non credo sia permesso!) smetterà di funzionare? Almeno finché qualcuno non dice a package manager che sono incompatibili e allora vanno a prendersi la libreria imprigionata

Il rischio per me c'è... il package manager incrementa la possibilità di depency hell e forse ancora peggiore quella che io chiamo la dipendenza ricorsiva (una volta ho tentato di togliere CUPS in una CentOS e il package manager mi ha detto che la applet della rete dipendeva da esso non l'incontrario... e comunque se insistevo veniva via l'intero GNOME mi son tenuto CUPS su una macchina che non avrà mai una stampante collegata )

Personalmente se fossi uno che crea applicazioni commerciali (e bhe nel mio piccolo lo sono ) quando sento parlare di Package Manager penso che l'OS non sia TRUSTED... se mi baso sulle librerie del sistema posso rischiare che la mia applicazione non vada più al primo update?
Ma io compilo tutto statico e buona notte
O peggio come ho visto fare ad alcune applicazioni mi installo in /opt e mi creo un mio fakeroot (lib, bin, ecc...)

Alla faccia del vostro risparmio di 10 MB

L'unica cosa che mi sembra migliore rispetto al draft precedente è che ora sembra che:

As a result, ports would have to follow some set of Haiku policies, defining where any package may (and may not!) put files. There will be a tool that will check any package against these policies and only packages complying with them will be made part of the official Haiku repositories.

Quindi i ports si adattano ad Haiku non viceversa (banalmente i setting non si mettono in directory dal nome criptico come /etc ma in /boot/settings!)

[trapanator]

Originariamente inviato da fano

Mah comunque lo si voglia mettere complicato è complicato... poi sta cosa delle librerie in galera (poverine ) riuscirà davvero a proteggere dal dependency hell o se apllicazione xyz vuole la libreria strafic@.so e quindi Haiku la aggiorna non c'è il rischio che tutto il resto delle applicazioni portate (o peggio se modifica una libreria del SO tutto Haiku, ma questo non credo sia permesso!) smetterà di funzionare? Almeno finché qualcuno non dice a package manager che sono incompatibili e allora vanno a prendersi la libreria imprigionata

Ho dato una rapida lettura a quelle specifiche, e mi sembra di aver capito che nulla vieta ad un package di portarsi TUTTE le librerie necessarie, senza altre dipendenze.

Il rischio per me c'è... il package manager incrementa la possibilità di depency hell e forse ancora peggiore quella che io chiamo la dipendenza ricorsiva (una volta ho tentato di togliere CUPS in una CentOS e il package manager mi ha detto che la applet della rete dipendeva da esso non l'incontrario... e comunque se insistevo veniva via l'intero GNOME mi son tenuto CUPS su una macchina che non avrà mai una stampante collegata )

In questo caso la colpa NON è del gestore pacchetti, ma di chi ha scritto (coi piedi) le informazioni sul pacchetto. Comunque in ArchLinux il pacchetto CUPS non dipende assolutamente da Gnome, come si evince qui:

http://www.archlinux.org/packages/extra/i686/cups/


Comunque non so se l'avete notato, nel link postato da BeBarret (che avevo già letto in precdenza) c'è, in cima, un blocco del codice di .PackageInfo, che somiglia in modo incredibile al PKGBUILD di ArchLinux. Un esempio lo trovate qui:

http://aur.archlinux.org/packages/burn/burn/PKGBUILD

hanno cambiato solo i nomi dei parametri, ma la sostanza è la stessa

[fano]

Originariamente inviato da trapanator

Ho dato una rapida lettura a quelle specifiche, e mi sembra di aver capito che nulla vieta ad un package di portarsi TUTTE le librerie necessarie, senza altre dipendenze.

Sì, ma sarà l'eccezione non la norma la maggioranza dei pacchetti farà affidamento sul Package Manager se no cosa lo facciamo a fare?
Diciamo che questo varrà utilizzato solo per i software commerciali che non si fideranno, ovviamente, dell'OS

Originariamente inviato da trapanator

In questo caso la colpa NON è del gestore pacchetti, ma di chi ha scritto (coi piedi) le informazioni sul pacchetto. Comunque in ArchLinux il pacchetto CUPS non dipende assolutamente da Gnome, come si evince qui:

http://www.archlinux.org/packages/extra/i686/cups/

Sì, probabilmente hanno abusato del concetto di dipendenze oltre ogni limite... del resto si parla di CentOs probabilmente tra le distribuzioni Linux la peggiore... peccato che per motivi a me incomprensibili sia lo standard aziendale: sono costretto a metter questa sulle macchine! Impazzendo poi con tutte le menate che si porta dietro

Originariamente inviato da trapanator

Comunque non so se l'avete notato, nel link postato da BeBarret (che avevo già letto in precdenza) c'è, in cima, un blocco del codice di .PackageInfo, che somiglia in modo incredibile al PKGBUILD di ArchLinux. Un esempio lo trovate qui:

http://aur.archlinux.org/packages/burn/burn/PKGBUILD

hanno cambiato solo i nomi dei parametri, ma la sostanza è la stessa

Beh zooey ha ammesso, candidamente, di essersi guardato intorno e di aver scopiazzato da Linux... io personalmente avrei preferito copiare qualcosa che funziona (MAC OSX, cioè), ma ognuno ha i suoi gusti

[trapanator]

Originariamente inviato da fano

Beh zooey ha ammesso, candidamente, di essersi guardato intorno e di aver scopiazzato da Linux... io personalmente avrei preferito copiare qualcosa che funziona (MAC OSX, cioè), ma ognuno ha i suoi gusti

più che Linux, ArchLinux e devo dire che lo sto usando da 2 anni e passa sul mio PC di casa e da 2 mesi su quello di lavoro, abbandonando Win 7...

[hexaae]

Originariamente inviato da fano

Beh zooey ha ammesso, candidamente, di essersi guardato intorno e di aver scopiazzato da Linux... io personalmente avrei preferito copiare qualcosa che funziona (MAC OSX, cioè), ma ognuno ha i suoi gusti

Tornando seri, faccio notare che i package o application bundle alla MaxOSX sì, evitano i problemi di dipendenze ma tutto va a pesare sullo spazio occupato su HD (tra l'altro a quel punto perché non linkare staticamente le librerie in fase di compilazione poi...?).
Ancora mi devono spiegare perché l'approccio Amiga-style non poteva andare bene su Haiku (che non soffre di frammentazione) che prende da BeOS che si ispirava a sua volta ad Amiga, guarda caso...

[Herod2k]

Originariamente inviato da fano

del resto si parla di CentOs probabilmente tra le distribuzioni Linux la peggiore... peccato che per motivi a me incomprensibili sia lo standard aziendale: sono costretto a metter questa sulle macchine!

Facile, te lo dico io, CentOS è praticamente RedHat RHEL ricompilata senza software proprietario.
In pratica hai RHEL gratis con CentOs.

[fano]

Originariamente inviato da hexaae

Tornando seri, faccio notare che i package o application bundle alla MaxOSX sì, evitano i problemi di dipendenze ma tutto va a pesare sullo spazio occupato su HD (tra l'altro a quel punto perché non linkare staticamente le librerie in fase di compilazione poi...?).

OK, ma se poi il rischio che non funzioni nulla io un po' di occupazione superiore su HDD per me non è un problema... in fondo le applicazioni che necessiteranno di librerie esterne NON dovranno essere la norma vorrebbe dire che ci son troppi porting e nessuno sta usando i KIT di Haiku... quindi che differenza ci sarebbe con Linux?

L'approccio è lo stesso di Apple non vuoi usare le feature del mio figosissimo OS? Peggio per te la tua bratta la metti dentro al programma NON mi inquini il SO!

Originariamente inviato da hexaae

Ancora mi devono spiegare perché l'approccio Amiga-style non poteva andare bene su Haiku (che non soffre di frammentazione) che prende da BeOS che si ispirava a sua volta ad Amiga, guarda caso...

Il problema è che per come sono le librerie opensource l'approccio Amiga (che poi era quello corretto) mal si sposa... sembra che lo facciano apposta a togliere la retrocompatibilità ad ogni nuova versione... per far quello che chiedi con il sistema attuale si dovrebbe pensare a qualcosa tipo fatLibrary quindi libPUPU.so conterrebbe al suo interno libPUPU.so.1.0 e ibPUPU.so.1.1 ecc, giusto?
O pensi che andrebbero proprio riscritte per ri-intergrare la retro-compatibilità mentre quelli di Linux la tolgono? Un discreto sbattimento

[pabloski]

la soluzione amiga non va.....avete presente quante modifiche vengono fatte alle librerie linux?

e il kernel? amiga era/è stabile come interfaccia dell'os, linux cambia in continuazione....alla fine comunque è necessario avere una libc che segue l'os passo-passo

e non oso immaginare che succederebbe se si avessero tante versioni delle stesse librerie....la versione 1 della lib X richede la versione 3 della lib Y che dipende dalla versione 2.4 della lib Z e così via

avremmo milioni di file solo per le librerie....sarà per quello che windows 7 richiede 8 gb e passa di spazio su disco appena installato?

[darkbasic]

Originariamente inviato da fano

del resto si parla di CentOs probabilmente tra le distribuzioni Linux la peggiore... peccato che per motivi a me incomprensibili sia lo standard aziendale: sono costretto a metter questa sulle macchine! Impazzendo poi con tutte le menate che si porta dietro

Questa l'hai sparata grossa, equivale a dire che Red Hat Enterprise linux è la peggiore distro

[trapanator]

Originariamente inviato da darkbasic

Questa l'hai sparata grossa, equivale a dire che Red Hat Enterprise linux è la peggiore distro

forse parlava in ambito desktop.

[pabloski]

effettivamente rhel e quindi centos sono ritenute le migliori distribuzioni insieme a sles in ambito server

ovviamente su un pc chi diavolo metterebbe una distribuzione pensata per i server?