Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
paludis vs portage vs pkgcore
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano
View previous topic :: View next topic  
Author Message
lucapost
Veteran
Veteran


Joined: 24 Nov 2005
Posts: 1415
Location: <ud|me|ts> - Italy

PostPosted: Sat Oct 11, 2008 10:57 am    Post subject: paludis vs portage vs pkgcore Reply with quote

Portage negli ultimi mesi ha fatto diversi passi avanti, dovrebbe essere imminente il rilascio della versione 2.2.
Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.

Ai tempi bui di portage, utilizzai per diversi mesi anche paludis, che poi abbandonai in quanto era in pieno sviluppo e "conveniva" stare dietro i troppo frequenti aggiornamenti.

Invece, no strumento che non ho mai provato ma che tutt'ora mi incuriosisce è pkgcore.

Queste sono le versioni disponibili oggi:
Code:
[I] sys-apps/portage
     Available versions:  [P]2.0.51.22-r3 [P]2.1.1-r2 2.1.4.4 2.1.4.5 ~2.1.5.6 ~2.2_rc11 (~)2.2_rc12 {build doc elibc_FreeBSD elibc_glibc elibc_uclibc epydoc linguas_pl selinux userland_GNU}
     Installed versions:  2.2_rc12(01:12:56 PM 10/10/2008)(-build -doc -epydoc -linguas_pl -selinux)
     Homepage:            http://www.gentoo.org/proj/en/portage/index.xml
     Description:         Portage is the package management and distribution system for Gentoo

* sys-apps/paludis
     Available versions:  ~0.26.2 ~0.28.0 ~0.28.1 ~0.28.2 ~0.30.0 ~0.30.1 {bash-completion doc glsa inquisitio pink portage python qa ruby vim-syntax visibility zsh-completion}
     Homepage:            http://paludis.pioto.org/
     Description:         paludis, the other package mangler

* sys-apps/pkgcore
     Available versions:  ~0.4.7.4 ~0.4.7.5 ~0.4.7.6 ~0.4.7.7 ~0.4.7.8 ~0.4.7.11 ~0.4.7.12 {doc}
     Homepage:            http://www.pkgcore.org
     Description:         pkgcore package manager


Avete opinioni/commenti/esperienze da riportare?
_________________
LP
Back to top
View user's profile Send private message
Peach
Advocate
Advocate


Joined: 08 Mar 2003
Posts: 3686
Location: London, UK

PostPosted: Sat Oct 11, 2008 12:22 pm    Post subject: Reply with quote

io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.
che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?

gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom
Back to top
View user's profile Send private message
topper_harley
Guru
Guru


Joined: 05 Apr 2006
Posts: 363
Location: Treviso / Udine (Italy)

PostPosted: Sat Oct 11, 2008 1:40 pm    Post subject: Reply with quote

Peach wrote:
io ho letto la GMN e parlava proprio EAPI-2 e oggi ero quasi in procinto di installarlo, ma dopo aver visto che è ancora in rc mi sono bloccato.
che parere puoi dare a riguardo? apparte la lentezza solita nella risoluzione delle dip.?

gli altri due non so, sono incuriosito anche io da pkgcore nn l'avevo mai sentito.


Stando a sentire ciaranm pkgcore è terribilmente rotto, porta alla devastazione del sistema, diarrea, vomito, peste e tifo... (a dire il vero pensa lo stesso anche di portage, peste compresa)

http://www.nabble.com/EAPI-2-is-brokened-:(-td19905090.html
_________________
http://topperh.ath.cx
Jabber: topper_harley@jabber.org
ICQ: 224179391
MSN: Topper_Harley80@gmail.com
Last FM
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Sat Oct 11, 2008 10:42 pm    Post subject: Re: paludis vs portage vs pkgcore Reply with quote

lucapost wrote:

Comunque noto ancora un'eccessiva lentezza nella risluzione delle dipendenze.

secondo me, portage non sarà mai veloce.
guai se lo fosse: la velocità nella risoluzione delle dipendenze decresce esponenzialmente con il numero degli ebuild disponibili.
una sua piccola variazione determina un rallentamento sensibile di emerge.

se vuoi un segnale, come chiedevi nell'altro post, gentoo comincerà davvero il proprio declino il giorno in cui emerge sarà diventato un programma veloce.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
bandreabis
Advocate
Advocate


Joined: 18 Feb 2005
Posts: 2361
Location: イタリアのロディで

PostPosted: Sun Oct 12, 2008 8:50 am    Post subject: Reply with quote

Sarò io, ma non la vedo tutta sta lentezza di emerge. :oops:
_________________
Il numero di post non fa di me un esperto! Anzi!
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Sun Oct 12, 2008 7:21 pm    Post subject: Reply with quote

bandreabis wrote:
Sarò io, ma non la vedo tutta sta lentezza di emerge. :oops:

ma infatti, la questione è controversa.
la cosa dipende da troppi fattori diversi dalla qualità del software.

oltre ai problemi di efficienza dell'accesso fisico al filesystem (portage, volutamente, è un database collocato nei file), emerge rallenta in particolare se il file world contiene troppe voci, o peggio, ne contiene di superflue a causa di qualche pacchetto riemerso senza l'uso dell'opzione -1.
oppure se la cartella /etc/portage e la variabile USE di /etc/make.conf sono particolarmente complesse.
cose queste che interessano chi conserva la propria installazione da lungo tempo, magari da anni, senza reinstallare e modificando frequentemente il proprio assetto e aggiungendo di continuo nuovi overlay.

in pratica, la lentezza di portage è figlia della propria versatilità e della propria stabilità.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Sun Oct 12, 2008 7:38 pm    Post subject: Reply with quote

ehm... non per fare il bastancontrario ed indulgere nella mia solita crociata anti-prof... :lol: ma hai torto :twisted:

python non è certo performante quanto un eseguibile; avere quel marasma di file e subdirectory non aiuta:
se inserisci il supporto a psyco, pysql e metti portage su squashfs e la differenza ti salta all'occhio già al primo emerge system, non su una "vecchia" installazione desktop;
se poi (a parte la locazione quantomeno infelice) metti /var/db/pkg su ram (per test, non è una operazione raccomandabile) ti spaventi della differenza.
per non dire del fatto che se vedi cosa c'è in /var/db/pkg/categoria/pacchetto restyi un tantino basito dall'uso di un file per ogni variabile e finezze simili.

Per non dire delle rogne che comporta avere python come dipendenza (a questo punto si poteva pensare, per il gorsso della struttura a bash+eseguibili dedicati per la ricerca, sul modello di q, almeno sarebbe stato assolutamente portabile).

Non sono un fanatico di paludis ma ci sono i problemi. Di certo non mi pare che nessuno si preoccupi di risolverli e si pensa ancora a chi è più bello e più figo.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
lordalbert
l33t
l33t


Joined: 26 Nov 2006
Posts: 832
Location: Italy

PostPosted: Sun Oct 12, 2008 10:28 pm    Post subject: Reply with quote

ma per lentezza intendete soltanto la risoluzione delle dipendenze?
In quel caso l'ho notata anche io.... ma per il resto...

Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage? Intendo, se si fosse usato un linguaggio compilato probabilmente sarebbe stato un poì più veloce....
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Sun Oct 12, 2008 10:34 pm    Post subject: Reply with quote

djinnZ wrote:
se inserisci il supporto a psyco, pysql e metti portage su squashfs

questi sono fatti noti, soprattutto per lucapost.
ma lui forse non desidera sbattersi a fare lo script che comprime di notte lo squashfs, oppure apprezza la comodità del database rw nei files.
ora, l'unica alternativa attuale è probabilmente proprio paludis, che però è troppo votato allo sviluppo, che dicono non essere così miracoloso nelle situazioni complesse, nemmeno sul piano della velocità e che lui comunque afferma di avere spontaneamente abbandonato.
pkgcore ... è scritto in python.

perciò al momento è necessario rassegnarsi al fatto che gentoo non è solo portage, fermo restando che comunque portage non è neppure strumento così rudimentale da doversene sbarazzare troppo di fretta.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Mon Oct 13, 2008 7:20 am    Post subject: Reply with quote

lordalbert wrote:

Una curiosità, come mai è stato scelto proprio python per lo sviluppo di portage?

Drobbins ha voluto un linguaggio di scripting.
lo riteneva più flessibile e maneggevole. e probabilmente riteneva effimero ed irrilevante il vantaggio legato all'adozione di un linguaggio compilato, tant'è che non ha mai considerato seriamente di discutere di questa scelta.

per quanto riguarda la collocazione nel file system, prima di tutto, risolve un problema di dipendenze più grave che quello del python.
ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?
ma soprattutto, hanno avuto un peso le attese che Robbins nutriva nello sviluppo dei filesystem di Reiser (e dei filesystem linux in generale). perciò le "finezze simili" che dice djinnZ, come riservare un file per ciascuna variabile non sono ingenuità imperdonabili di un programmatore in erba, ma rappresentano l'esperimento di qualcuno che spingeva la sguardo un passetto più in là di quanto noi stessi, tutt'oggi, sappiamo vedere.

piuttosto che impegnarsi a riscrivere portage, gli sviluppatori di gentoo farebbero bene a spingere lo sviluppo in questa direzione: quella dei filesystem.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
Kernel78
Moderator
Moderator


Joined: 24 Jun 2005
Posts: 3652

PostPosted: Mon Oct 13, 2008 12:04 pm    Post subject: Reply with quote

ognuno ha le sue priorità e se qualcuno si lamenta di qualcosa allora questa rappresenta un problema, almeno per lui.

Io me ne frego altamente della velocità di risoluzione dipendenze, tanto sul tempo di compilazione non influisce che per una frazione insignificante ...

Per quanto riguarda gli aggiornamenti avevo scritto un post su come ottimizzare il sync notturno e mi invio via mail il diff-eix (così vedo quali pacchetti sono aggiornati) e anche un pretend dell'aggiornamento così posso valutare se devo sistemare qualche USE, mascherare o smascherare qualche pacchetto prima di procedere. Poi prima di andare in ufficio lancio l'aggiornamento effettivo e tanti saluti al tempo di risoluzione dipendenze.

Mi rendo conto che magari questa latenza possa costituire una noia per chi sperimenta, prova e riprova nuovi pacchetti più volte al giorno ma oggettivamente non mi sarei immaginato che questi costituissero una fetta così abbondante ...
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con
Code:
grep -vE '(^[[:space:]]*($|(#|!|;|//)))'
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Mon Oct 13, 2008 7:33 pm    Post subject: Reply with quote

@kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.

@cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.
In generale il python si è evoluto peggio del perl e comunque non sto a giudicare a posteriori le scelte di robbins ma la mancata revisione del database e della cache da parte di chi è venuto dopo di lui (e dal non voler affrontare l'incogruenza di certe impostazioni tradizionali della destinazione di var home tmp ed etc).
Usare un singolo file per le variabili è un esempio (e non credo che shell o da python complichi le cose, anzi).
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
Kernel78
Moderator
Moderator


Joined: 24 Jun 2005
Posts: 3652

PostPosted: Mon Oct 13, 2008 10:13 pm    Post subject: Reply with quote

djinnZ wrote:
@kernel78: usiamo più o meno lo stesso metodo per aggiornare quindi non è che ci faccia molto caso però quando devo aggiungere un pacchetto singolo mi scoccia aspettare.

personalmente anche quando installo nuovi sw il tempo di risoluzione delle dipendenze mi risulta trascurabile se confrontato con quello della compilazione ...
oggettivamente penso che la maggior parte del tempo d'uso di un sistema gentoo non sia dedicato all'installazione di nuovi sw quindi il tempo dedicato alla risoluzione delle dipendenze sia irrisorio (a meno che non usiate una macchina solo per creare pacchetti binari ma anche in quel caso ...)
_________________
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall).
Prima di postare un file togli i commenti con
Code:
grep -vE '(^[[:space:]]*($|(#|!|;|//)))'
Back to top
View user's profile Send private message
Peach
Advocate
Advocate


Joined: 08 Mar 2003
Posts: 3686
Location: London, UK

PostPosted: Mon Oct 13, 2008 10:17 pm    Post subject: Reply with quote

djinnZ wrote:
@cloc3: Sarò tradizionalista ma per me la vecchia accoppiata sh(che può essere compilato all'occorenza)+piccoli binari dedicati resta la più valida.

guarda secondo me non è questione di "tradizionalismi"
parlando seriamente, considerando gentoo nel suo insieme ( e quindi non solo come un Desktop-OS ) secondo me, meno dipendenze ci sono meglio si sta. Voglio dire: se anche rimuovi gcc un eseguibile va sempre, ma se rimuovi python... ah sono razzi amari!
Dal suo canto python ha effettivamente la facilità e la comprensibilità paragonabile a quella di un linguaggio naturale, e questo non fa altro che favorire la diffusione di gentoo e quant'altro...
Trovare una via di mezzo? Così come stanno cercando di fare per baselayout? a me non sembra una idiozia, ma è anche vero che io non c'ho mai provato a guardarci dentro.
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom
Back to top
View user's profile Send private message
oRDeX
Veteran
Veteran


Joined: 19 Oct 2003
Posts: 1308
Location: world

PostPosted: Tue Oct 14, 2008 7:55 am    Post subject: Reply with quote

Premetto che non programmo in Python (anche se stanno cercando di convincermi :P).
Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.

EDIT:
Da una veloce ricerca mi pare di aver capito che c'è chi ha sviluppato alcuni tool per la compilazione del python in linguaggio macchina: http://starship.python.net/crew/atuining/cx_Freeze/
Non ho finito di leggere il README ma non mi pare ci siano controversie. Ovviamente così si risolverebbero mediamente i due problemi di prima: performance (almeno un minimo) e dipendenza (dall'interprete).
Back to top
View user's profile Send private message
morellik
l33t
l33t


Joined: 03 Feb 2003
Posts: 629
Location: Firenze

PostPosted: Tue Oct 14, 2008 11:08 am    Post subject: Reply with quote

oRDeX wrote:
Premetto che non programmo in Python (anche se stanno cercando di convincermi :P).
Se non sbaglio esiste la possibilità di compilare il python in byte code (stesso procedimento di java quindi) producendo un .pyc (partendo da un .py) che ovviamente, in quanto byte code, deve essere eseguito tramite l'utilizzo del comando python ma potrebbe comunque giovare in qualche modo alle performance. Non è eliminato il discorso della dipendenza dall'interprete, ma penso sarebbe già un passo avanti.


Ti devo contraddire perche' internamente, il codice sorgente Python viene sempre convertito nella rappresentazione in bytecode, e questo viene dopo eseguito nella macchina virtuale di Python. Non c'e' nessuna differenza a livello di prestazioni una volta che il file .pyc e' stato caricato, come del resto il bytecode letto dal file .pyc e' lo stesso di quello creato dalla conversione diretta. L'unica differenza e' che il caricamento di codice dal file .pyc e' più veloce dell'analisi e conversione di un file .py, per cui la presenza di file .pyc precompilati migliora il tempo di avvio degli script Python.

L'unica alternativa potrebbe essere l'uso di psyco, mi pare di aver postato come fare, ma non so se e' sempre compatibile con l'ultima versione di emerge.
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Tue Oct 14, 2008 3:52 pm    Post subject: Reply with quote

Mettendo /var/db/pkg in ram la differenza è notevole, più che usare psyco, pysql e squashfs (o è meglio cram? Non lo ho mai usato per questo chiedo, già che mi trovo).
Però il fatto che debba attendere sempre almeno quei 30 secondi quando lancio un emerge ltrace (l'ultima cosa che ho fatto) mi scoccia, e non poco, più perchè intuisco che scelte frettolose, fatte da drobbins in una fase iniziale, si sono cristallizate.
Non sto dicendo che drobbins ha sbagliato, solo che ha operato alcune scelte, valide in fase di prima implementazione, che non dovevano rimanere tali.

Per non dire del fatto che avere sulla stessa partizione i file temporanei usati per compilare ed il database dei pacchetti è una spada di Damocle che mi impensierisce non poco; su filesystem come xfs ti ritrovi a terminare il flush della cache e cancellare i file temporanei (e su xfs è da sempre lenta come operazione) e scrivere il database contemporaneamente. Vero che avevo formattato con impostazioni eccessive, tanto era il disco di prova, ma mi sono trovato più volte con il database irrecuperabile, lo ripeto.
Però per quanto riguarda var ci sarebbe da discutere che log, fax e via dicendo non hanno la stessa importanza ed utilità di cache e temporanei vari, ma se penso a quel che sono le espressioni regolari (sia sempre maledetto l'idiota che si è inventato "* *" nella linea di comando) non mi stupisco più di tanto.

Se il python si fosse evoluto senza incompatibilità e problemi (o meglio se non si fosse mai evoluto come il bash scripting) poteva anche andar bene.
Di sicuro elementi come l'init (motivo per il quale non sono passato ad einit, la dipendenza da expat), il gestore dei pacchetti nelle sue funzioni principali (ovvero aggiornare il sistema ed installare/disinstallare), la shell etc. devono avere dipendenze minime o nulle, sia a runtime che in compilazione.

Per esempio a cosa serve la funzione di ricerca in emerge? Non è una cosa che è meglio lasciare ad un pacchetto esterno come eix/q?

Paludis mi pare che voglia ripercorrere lo stesso errore (anzi peggiorarlo e senza la facilità di un linguaggio interpretato) e quindi mi piace poco.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
lucapost
Veteran
Veteran


Joined: 24 Nov 2005
Posts: 1415
Location: <ud|me|ts> - Italy

PostPosted: Wed Oct 15, 2008 9:04 pm    Post subject: Reply with quote

...
_________________
LP


Last edited by lucapost on Thu Oct 16, 2008 6:50 am; edited 1 time in total
Back to top
View user's profile Send private message
lucapost
Veteran
Veteran


Joined: 24 Nov 2005
Posts: 1415
Location: <ud|me|ts> - Italy

PostPosted: Wed Oct 15, 2008 9:08 pm    Post subject: Reply with quote

cloc3 wrote:

ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

e cosa ci sarebbe di così male? per gestire quasi 13000 pacchetti..., finchè il necessario mi passa in 700mb per l'installazione....

se da qualche parte si andrà a finire, IMHO, si finisce ad un database oppure si spezzerà l'albero di portage perlomeno in overlays di progetti minori. chi vivrà vedrà...
_________________
LP
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Wed Oct 15, 2008 10:05 pm    Post subject: Reply with quote

8O :? una lettura del buon vecchio knuth o del buon Nick Wirth non farebbe male.
Prima si progetta la struttura dei dati e poi si inizia a scrivere il programma, soprattutto quando si aggiunge.

Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol non c'era neppure il C64 in commercio e quando scrissi l'ultimo in c M$ non era ancora imposta per legge, un tantino arretrato lo sono) ma non ho mai letto niente da parte dei devel sul portage, solo implementiamo questo, implementiamo quello.
Ammetto che c'è chi spinge il discorso solo in quella direzione ma in ogni caso non va.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
Peach
Advocate
Advocate


Joined: 08 Mar 2003
Posts: 3686
Location: London, UK

PostPosted: Wed Oct 15, 2008 11:09 pm    Post subject: Reply with quote

vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?
_________________
Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom
Back to top
View user's profile Send private message
morellik
l33t
l33t


Joined: 03 Feb 2003
Posts: 629
Location: Firenze

PostPosted: Thu Oct 16, 2008 7:59 am    Post subject: Reply with quote

Peach wrote:
vogliamo parlare del futuro? e che dire dell'uscita di Python 3.0? che rompe la compatibilità con le versioni precedenti? beh è sempre un rischio che si ha con qualsiasi linguaggio di programmazione, per carità, però qui si parla di qualcosa che potrebbe affliggere l'intera piattaforma, o dico una scemenza?


E' vero, Python 3.0 non sarà retrocompatibile (non starò a discutere su una strategia che secondo me è giusta. Ogni tanto occorre dare un colpo di spugna per far funzionare al meglio le cose.). Ma Python non è M$ che decide da un giorno all'altro smettere di darti un SO in favore di un altro. I developer Gentoo avranno tanto di quel tempo per adattarsi ai cambiamenti che ci potrebbero invecchiare. Oltretutto più versioni di Python possono convivere tranquillamente senza alcun fastidio.

Il tutto IMHO.

djinnZ wrote:
Datemi pure del rudere arcaico e tradizionalista (in effetti quando scrissi il mio programma in cobol ...


Cobol 8O Quanti ricordi....Il mio primo corso di programmazione...... Grande djinnZ, allora non sono l'unico "vecchio" in questa baracca. :oops:
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Thu Oct 16, 2008 2:21 pm    Post subject: Reply with quote

lucapost wrote:
cloc3 wrote:

ci immaginiamo una distribuzione che dipende dal database prima ancora di essere installata?

e cosa ci sarebbe di così male?

me lo chiedi?

intanto, il database non rende più celere il calcolo delle dipendenze. il database sveltisce solo l'accesso ai dati necessari per risolvere le dipendenze...

ma come minimo, se i dati sono inclusi in un database, serve un programma per navigarlo.
al momento il mio browser preferito per navigare portage è ls, in linea di comando.
sono sicuro che sia molto più facile scoprire un programma nuovo così che usando synaptics o qualunque altro gestore di pacchetti strafico della distro più in voga.

e al di là di ogni giudizio tecnico, apprezzo in questo un valore immenso di libertà.
infatti, il database chiuso impone un rapporto privato con l'utente che gentoo risolve con straordinaria leggerezza.

infine, considerato che stiamo parlando di gentoo, è evidente che quel browser non potrebbe funzionare meglio di un certo installer grafico di nostra infelice memoria :roll: .
anche un pizzico di realismo e/o di sano umorismo... quando ci vuole ci vuole.
:)
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Thu Oct 16, 2008 4:06 pm    Post subject: Reply with quote

cloc3 wrote:
intanto, il database non rende più celere il calcolo delle dipendenze
una base dei dati decente ben strutturata rende più veloci le operazioni. Per età ed in virtù del lavoro knuth e wirth li devi conoscere...
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4649
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Thu Oct 16, 2008 5:00 pm    Post subject: Reply with quote

djinnZ wrote:
cloc3 wrote:
intanto, il database non rende più celere il calcolo delle dipendenze
una base dei dati decente ben strutturata rende più veloci le operazioni.

la struttura del database di portage è decente. infatti tu dici che, caricato in ram, è una scheggia.

knuth e wirth? purtroppo no. la mia è una cultura di nubbio maneggione.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum