# [BINMERGE] Pacchetti binari per Gentoo

## Benve

Ciao.

Io Marco Fabbri, Matteo Bertoni e Enrico D'Angelo dell'università di Bologna, stiamo lavorando su un progetto universitario.

Il nome di sviluppo del progetto è binmerge.

Binmerge è un sistema di gestione dei pacchetti binari per Gentoo GNU/Linux.

L'idea non è nuova e varie volte è stata esposta da me e altri sul forum.

Il tutto parte dalla considerazione che avere un repository di binari di Gentoo non è possibile. Ci sono troppi binari e sono ingestibili, anche se si restringono i binari ad una sola architettura (x86) e con ottimizzazioni generiche (i686). Il problema è dato dalle USEFlags: ogni ebuild infatti può essere compilato in 2^n modi diversi, con n = numero di USEFlags.

Una soluzione al problema è usare i pacchetti che quotidianamente gli utenti compilano sulle proprie macchine. Ora ognuno compila per se i software, se quello che compila lo condividesse, altri potrebbero usarlo.

Binmerge vuole essere un sistema che permette il p2p tra utenti dei pacchetti compilati.

Al momento siamo in fase "planning". Presto vi passo il link a un po di documentazione.

----------

## fedeliallalinea

L'idea mi pare ottima cosi' si possono anche condividere pacchetti compilati su altre arch. L'unica cosa che mi sfugge e' come sapere prima come e' stato compilato un pacchetto?

----------

## randomaze

 *Benve wrote:*   

> Io Marco Fabbri, Matteo Bertoni e Enrico D'Angelo dell'università di Bologna, stiamo lavorando su un progetto universitario.
> 
> Il nome di sviluppo del progetto è binmerge.
> 
> Binmerge è un sistema di gestione dei pacchetti binari per Gentoo GNU/Linux.

 

Non so come mai ma mi era venuto questo sospetto  :Rolling Eyes: 

Naturalmente verrà presentato ufficialmente sabato al GDay, vero?  :Twisted Evil: 

----------

## Benve

 *randomaze wrote:*   

> 
> 
> Naturalmente verrà presentato ufficialmente sabato al GDay, vero? 

 

Purtroppo ancora non ho niente di funzionante da presentare. Posso illustrarlo a voce  :Smile: 

----------

## gutter

Mi pare davvero una buona idea  :Smile: 

Tienici aggiornati.

----------

## randomaze

 *Benve wrote:*   

> Purtroppo ancora non ho niente di funzionante da presentare. Posso illustrarlo a voce 

 

Mi sembra un'ottima cosa   :Cool: 

Il tuo turno inizia alle 17.15, di quanto tempo hai bisogno?

Ti servono le slides vuote?

----------

## Benve

 *randomaze wrote:*   

>  *Benve wrote:*   Purtroppo ancora non ho niente di funzionante da presentare. Posso illustrarlo a voce  
> 
> Mi sembra un'ottima cosa  
> 
> Il tuo turno inizia alle 17.15, di quanto tempo hai bisogno?
> ...

 

Io pensavo ad una chiacchierata tra di noi, non ad una conferenza  :Embarassed: 

Ancora non abbiamo definito bene tutte le parti del progetto. Al limite posso spiegare cosa avevamo in mente con un paio di lucidi.

----------

## =DvD=

heeh io son sempre a fare il criticone, me ne rendo conto, ma...

Come faccio a sapere che il binario che mi mandano non sia corrotto con del codice cambiato? (tipo troiani o similia)?

E poi considera che si può compilare con varie versioni di gcc...

----------

## gutter

 *=DvD= wrote:*   

> 
> 
> [CUT]
> 
> Come faccio a sapere che il binario che mi mandano non sia corrotto con del codice cambiato? (tipo troiani o similia)?
> ...

 

A questo credo non ci sia soluzione pernso che ti debba fidare.

----------

## randomaze

 *Benve wrote:*   

> Io pensavo ad una chiacchierata tra di noi, non ad una conferenza 
> 
> Ancora non abbiamo definito bene tutte le parti del progetto. Al limite posso spiegare cosa avevamo in mente con un paio di lucidi.

 

Perfetto... hai appena vinto un Minitalk di 15 minuti circa  :Wink: 

----------

## Benve

 *=DvD= wrote:*   

> 
> 
> Come faccio a sapere che il binario che mi mandano non sia corrotto con del codice cambiato? (tipo troiani o similia)?
> 
> 

 

Ogni pacchetto verrà firmato da chi lo crea, questo garantirà l'integrità dello stesso e permetterà di rintracciare l'autore.

Se si crea un pacchetto con un troian, chi lo crea si prende le sue responsabilità. Come minimo viene radiato dal sistema.

 *=DvD= wrote:*   

> 
> 
> E poi considera che si può compilare con varie versioni di gcc...

 

Già considerato  :Wink: 

----------

## fedeliallalinea

 *randomaze wrote:*   

> Perfetto... hai appena vinto un Minitalk di 15 minuti circa 

 

Quando lo aggiungi fammi sapere che lo metto anche sul forum gechi

----------

## =DvD=

 *gutter wrote:*   

> 
> 
> A questo credo non ci sia soluzione pernso che ti debba fidare.

 

Va bene, ma io non mi fido.

Mi spiego: Dovessi fidarmi di uno del forum anche a ochi chiusi, a xchis diedi root in ssh  :Smile:  ...

Ma fidarmi di un utente qualsiasi di p2p... voglio dire il primo malitenzionato che passa potrebbe usare binmerge per mettere suo codice nelle macchine altrui.

Preciso che dico queste cose per aiutarvi ad avere un oggetto migiore alla fine!!! =D

non voglio essere antipatico!!

----------

## fedeliallalinea

Vabbe e' solo in planning mode binemerge. Magari benve trova il modo per fare tutto questo in modo sicuro

----------

## randomaze

 *fedeliallalinea wrote:*   

> Quando lo aggiungi fammi sapere che lo metto anche sul forum gechi

 

Fatto.

=DVD=, Benve é da un pò di mesi che pensa questa cosa (dovrebbero esserci un paio di thread).... secondo me ha qualche idea in proposito  :Wink: 

----------

## Benve

 *=DvD= wrote:*   

> 
> 
> Va bene, ma io non mi fido.
> 
> Mi spiego: Dovessi fidarmi di uno del forum anche a ochi chiusi, a xchis diedi root in ssh  ...
> ...

 

Il sistema all'inizio sarà chiuso. Non tutti potranno sottomettere pacchetti. Solo gli utenti registrati, dove si possa associare ad una persona la propria firma gpg con cui si firmano i pacchetti.

Tutti queste cose sono state bene o male già pensate. Ora mi metto a scrivere come funziona il tutto, altrimenti è inutile scrivere frasi staccate nel forum.

----------

## fedeliallalinea

 *Benve wrote:*   

> Ora mi metto a scrivere come funziona il tutto, altrimenti è inutile scrivere frasi staccate nel forum.

 

bene aspettero le specifiche del progetto  :Very Happy: 

----------

## faber

se uno inserisce un trojan nel sistema benve, noto praticante di kung fu, viene e ti carica di mazzate..

A parte questo non e' possibile sapere se c'e' un trojan, ma NON e' parimenti a priori possibile sapere se il distfile che stiamo scaricando per poi essere compilato e' corrotto, o c'e' qualche trojan dentro. E' una fiducia che tu dai a chi fa il digest e chi fa il sorgente. 

E' comunque molto piu' facile distribuirne tramite pacchetti precompilati, ma credo che firma digitale del pacchetto, sistema di trusting in stile PGP siano dei buoni deterrenti affinche' gli utenti maliziosi (come direbbe il mio prof di sicurezza) siano scoraggiati, in quanto ricordo che e' un bel reato danneggiare e/o intromettersi in sistemi informatici altrui.

Infine, binmerge (nome di sviluppo, il finale sara' Longhorn XP 2005), se funzionera' come PGP, ovvero a buonsenso della comunita', ha buone possibilita' di rimanere in media sulla retta via, seguendo le orme del modello a cui si ispira.

Per concludere:

quando sara' pronto vi aspettiamo tutti al nostro banchettino da Certification Authority: gazzosa gratis.

----------

## Benve

 *faber wrote:*   

> 
> 
> Per concludere:
> 
> quando sara' pronto vi aspettiamo tutti al nostro banchettino da Certification Authority: gazzosa gratis.

 

Vi chiederete perchè gazzosa.

Voi non lo sapete ma Fabbri è astemio   :Very Happy: 

----------

## theRealMorpheu5

 *faber wrote:*   

> A parte questo non e' possibile sapere se c'e' un trojan, ma NON e' parimenti a priori possibile sapere se il distfile che stiamo scaricando per poi essere compilato e' corrotto, o c'e' qualche trojan dentro. E' una fiducia che tu dai a chi fa il digest e chi fa il sorgente. 

 

Stavo per dirlo io :clap:  :Very Happy: 

----------

## Dhaki

Doh questa si che é una buona idea, pittosto e anzicheno!

Sono proprio curioso di vedere come evolve la cosa.

----------

## Jecko_Hee

 *Dhaki wrote:*   

> pittosto e anzicheno!
> 
> 

 

[OT]

... mi ricorda un certo Lord Wells, mi sbaglio?

[/OT]

e per non dire solo cose OT,  complimenti per il progetto, mi sembra una buona idea.

----------

## Raffo

ottima idea, aspetto di leggere e/o vedere qualcosa di più. coraggio   :Smile: 

----------

## Cazzantonio

Mi sembra un'idea grandiosa!   :Very Happy:   :Very Happy:   :Very Happy: 

----------

## SteelRage

se risucite a usare bittorrent per il tutto... sarebbe ancora meglio

(fra l'altro ricordo che i developers avevano discusso riguardo all'ipotesi di usare bittorrent per mettere a disposizione i distfiles, in modo da alleggerire il carico dei server... poi non so come sia andata a finire, ma suppongo cha la cosa sia morta lì, per i problemi di sicurezza intrinseci a bittorrent... peccato)

----------

## gutter

 *SteelRage wrote:*   

> 
> 
> [CUT]
> 
> (fra l'altro ricordo che i developers avevano discusso riguardo all'ipotesi di usare bittorrent per mettere a disposizione i distfiles, in modo da alleggerire il carico dei server... poi non so come sia andata a finire, ma suppongo cha la cosa sia morta lì, per i problemi di sicurezza intrinseci a bittorrent... peccato)

 

Lo usano ancora   :Wink: 

http://torrents.gentoo.org/

----------

## Benve

In effetti per ora abbiamo pensato a bittorrent.

----------

## faber

infatti l'idea e' di usare bittorrent, dopo un pomeriggio a capire come funzionava (w la documentazione solo per windows)

il fatto di usare bittorrent, e di conseguenza un tracker nostro, ci darebbe la possibilita' di creare una rete di reti di pacchetti binari, espandibile a piacere, fino alla conquista del globo

----------

## gutter

 *faber wrote:*   

> 
> 
> [CUT]
> 
> il fatto di usare bittorrent, e di conseguenza un tracker nostro, ci darebbe la possibilita' di creare una rete di reti di pacchetti binari, espandibile a piacere, fino alla conquista del globo

 

Piccole manie di grandezza  :Wink: 

Vi auguro di riuscire a creare un bel progetto   :Very Happy: 

----------

## drakkan

l'idea dei binari mi sembra ottima però la userei solo per velocizzare la procedura di installazione, mi spiego se fosse possibile avere un livecd con un'interfaccia minimale che ti permette di installare velocemente il sistema secondo me sarebbe ottimo.

Una volta che il sistema è in piedi ed è possibile lavoraci si può benissimo lasciare il sistema a compilare di notte con le flag di ottimizzazione personalizzate

----------

## gutter

 *drakkan wrote:*   

> 
> 
> [CUT]
> 
> Una volta che il sistema è in piedi ed è possibile lavoraci si può benissimo lasciare il sistema a compilare di notte con le flag di ottimizzazione personalizzate

 

Per questo ci sono già i GRP   :Wink: 

----------

## randomaze

 *drakkan wrote:*   

> l'idea dei binari mi sembra ottima però la userei solo per velocizzare la procedura di installazione, mi spiego se fosse possibile avere un livecd con un'interfaccia minimale che ti permette di installare velocemente il sistema secondo me sarebbe ottimo.

 

Stage3+GRP non risponde ai tuoi requisiti?

----------

## drakkan

 *randomaze wrote:*   

>  *drakkan wrote:*   l'idea dei binari mi sembra ottima però la userei solo per velocizzare la procedura di installazione, mi spiego se fosse possibile avere un livecd con un'interfaccia minimale che ti permette di installare velocemente il sistema secondo me sarebbe ottimo. 
> 
> Stage3+GRP non risponde ai tuoi requisiti?

 

intendevo qualcosa che automatizzi il processo di installazione senza fare tutto manualmente

----------

## klaudyo

Secondo me l'idea di fare un client p2p per i binari è ottima.

Mettete on line le vostre idee? Così se ne può discutere!

Certo, fare un buon sistema p2p non è così facile come sembra. Al di la delle questioni di sicurezza (il pacchetto che installo è veramente quello?), che certo non sono trascurabili, credo che servano buoni algoritmi per fare un sist. ben funzionante e scalabile....

Se ne può parlare!!!!

----------

## klaudyo

(mentre scrivevo mi hanno buttato fuori dall'aula computer all'università...... erano strani tizi dotati di scale......)

Dicevo, sicuramente non è banale fare un sistema decente per il p2p. Sicuramente sarebbe il caso di capire i principi fondamentali che fanno funzionare kazaa o emule, no? Insomma è inutile stare a reinventare la ruota........

----------

## randomaze

 *klaudyo wrote:*   

> Sicuramente sarebbe il caso di capire i principi fondamentali che fanno funzionare kazaa o emule, no? Insomma è inutile stare a reinventare la ruota........

 

 *Benve wrote:*   

> In effetti per ora abbiamo pensato a bittorrent.

 

klaudyo, BitTorrent anche se non é un esattamente p2p come emule dovrebbe andare abbastanza bene per gli scopi del progetto ed é anche ampiamente documentato sul sito...

----------

## =DvD=

Attendo con ansia la descrizione...

Sono dubbioso su un paio di cose, ma ne posto dopo le specifiche  :Wink: 

In bocca al lupo!

----------

## Benve

Sto preparando qualche slide per sabato...

Se le finisco prima le metto online

----------

## motaboy

Anch'io sono molto curioso... anche se mi sorgono alcuni milioni di dubbi.

----------

## =DvD=

 *motaboy wrote:*   

> Anch'io sono molto curioso... anche se mi sorgono alcuni milioni di dubbi.

 

Io di più   :Laughing: 

----------

## tuxer

sarebbe veramente un'idea grandiosa...

eh eh mi immagino la scena, dai passami xorg con hardened per pentium 3 che ti passo firefox  :Very Happy:   :Very Happy: 

I problemi più grossi in effetti riguardano la sicurezza, ma per curiosità un md5sum di un pacchetto binario fatto da due macchine con uguali architettura, flags vari (use, cfags etc) sarebbe uguale?

----------

## =DvD=

Se gcc è lo stesso e configurato (e compilato forse) in maniera uguale si...

Ma forse anche no, ci son talmente tante cose in ballo...

Sarebbe da vedere. =D

----------

## Benve

 *tuxer wrote:*   

> ma per curiosità un md5sum di un pacchetto binario fatto da due macchine con uguali architettura, flags vari (use, cfags etc) sarebbe uguale?

 

In teoria si, in pratica non credo.

----------

## klaudyo

Stavo pensando,

ma è proprio necessario un sistema p2p? Insomma, tutto sommato si tratta di fare un repository di file. 

Non sarebbe più facile (ma ugualmente utile) gestire una sorta di database?

Mi spiego: su una macchina viene tenuto un DB con tutti i dati dei pacchetti disponibili (arch, flags, etc....). Tra questi c'è anche la locazione del pacchetto stesso (potrebbe essere locale al server ma anche sul sito personale di qualcuno).

Uno tramite un'interfaccia (Web o client locale) fa una ricerca indicando come deve essere compilato il pacchetto e gli viene restituita una URL.

Quindi un sistema centralizzato e non p2p.

Sarebbe una bella cosa creare un Web Service per l'interazione con il servizio. Tipo API di Google. Così, usando una tecnologia standard come il SOAP (xml), si potrebbe mettere su un API che fondamentalmente si interfacci con il DB. A questo punto chiunque potrebbe fare la GUI: in java, in .NET, in HTML, da linea di comando, etc.....

Spero di essere stato chiaro!

Certo il rpoblema è: chi mette su il server? Ad ogni modo, all'inizio di potrebbe prevedere di non gestire uno spazio per i binari veri e propri (che sarebbero molti MB.... GB!!!). Solo un data base di "meta" informazioni su ciò che è a disposizione. E questo lo si fa con poco.

Per quanto riguarda il discorso Web Service, non ci vuole molto a farlo!

Che ne dite?

----------

## =DvD=

Io dico: lasciamoli lavorare e guardiamoci gli slides!!

----------

## faber

 *klaudyo wrote:*   

> Stavo pensando,
> 
> ma è proprio necessario un sistema p2p? Insomma, tutto sommato si tratta di fare un repository di file. 
> 
> Che ne dite?

 

Se ci fornisci macchina e connessione sottoscrivo subito.

Le pretese sono poche, solo 2expN differenti binari per ogni use, per un ulteriore N di architetture, N di compilatori, N di header del kernel, N di cflags

Come vedi prevedere TUTTI i pacchetti in un repository e' una cosa impraticabile.

----------

## klaudyo

 *faber wrote:*   

>  *klaudyo wrote:*   Stavo pensando,
> 
> ma è proprio necessario un sistema p2p? Insomma, tutto sommato si tratta di fare un repository di file. 
> 
> Che ne dite? 
> ...

 

Il fatto è che il DB conterrebbe solo quello che gli utenti (registrati) inviano. Ciò che hai detto tu è un limite superiore solo teorico.

E poi ognuno si deve preoccupare di fornire la URL al pacchetto distribuendo su tutti gli utenti la necessità di spazio su disco (insomma il server potrebbe non tenere neanche un pacchetto binario, ma solo il DB con le URL ai pacchetti). 

Il database dovrebbe contenere solo poche info relative al pacchetto stesso. Ce la farebbe pure Access a gestire tali info (anche nel caso peggiore che hai detto tu)!!!!!!!

----------

## faber

quello che hai descritto si chiama tracker bittorrent + base di dati per ricerca dei torrent, ed e' esattamente quello che binmerge fara'. Cio che NON e' e' un repository centrale di pacchetti

cmq si', deve funzionare proprio cosi'

----------

## motaboy

Avete dimenticato di calcolare i programmi/librerie linkati a liberie con versioni (.so) differenti. in questo caso l'unico modo per saperlo e' una analisi di tutte le librerie/programmi per vedere a cosa sono linkate e un controllo sul sistema che tali link siano soddisfatti.

----------

## =DvD=

Vero! Non ci avevo pensato a questo...

Mi sa che sia un ostacolo bello forte...

----------

## mambro

Secondo me l'unica cosa veramente fattibile sarebbe un serverone (o vari piccoli server) che autogenera pacchetti binari con cflags generiche (-mcpu=i686 -O2) e con use flags generiche. Questo non penso sia difficile da fare..

----------

## zUgLiO

 *mambro wrote:*   

> Questo non penso sia difficile da fare..

 

Difficile no, ma i server e lo spazio e il traffico costano  :Smile: 

Comunque a pagamento questo servizio esiste gia.

----------

## klaudyo

 *faber wrote:*   

> quello che hai descritto si chiama tracker bittorrent + base di dati per ricerca dei torrent, ed e' esattamente quello che binmerge fara'. Cio che NON e' e' un repository centrale di pacchetti
> 
> cmq si', deve funzionare proprio cosi'

 

Vabbè, chiamalo come vuoi. Di fatto c'è un punto centrale nell'architettura  del sistema.

Non sapevo di BitTorrent.... 

In bocca al lupo!   :Wink: 

----------

## Benve

 *motaboy wrote:*   

> Avete dimenticato di calcolare i programmi/librerie linkati a liberie con versioni (.so) differenti. in questo caso l'unico modo per saperlo e' una analisi di tutte le librerie/programmi per vedere a cosa sono linkate e un controllo sul sistema che tali link siano soddisfatti.

 

Questo è il vero problema.

Per ora la nostra bozza di db gestisce solo il gcc e le glibc.

Ma appunto è solo una cosa provvisoria. Ci stiamo pensando in questi giorni.

PS. Le slide sono così in ritardo perchè quà da noi in facoltà è scoppiato un casino e dato che da lunedì non avremo più la connessione ci stiamo attrezzando per sopravvivere senza internet per qualche tempo.

PPS comunque ora vado a lezione e le slide le finisco li  :Smile: 

----------

## gutter

 *Benve wrote:*   

> 
> 
> [CUT]
> 
> PPS comunque ora vado a lezione e le slide le finisco li 

 

Lezione interessante vero   :Wink: 

----------

## SteelRage

 *=DvD= wrote:*   

> Se gcc è lo stesso e configurato (e compilato forse) in maniera uguale si...
> 
> Ma forse anche no, ci son talmente tante cose in ballo...
> 
> Sarebbe da vedere. =D

 

qualche mese fa, dopo un paio d'ore di discussioni su #gentoo, su azzurranet, sotto la supervisione di bsolar, abbiamo constatato che se gcc è compilato con CFLAGS diverse.... l'MD5sum dei binari prodotti è diverso...

ragazzi... in bocca al lupo   :Confused: 

----------

## xchris

non credo che md5sum sia una buona idea...

meglio controllare per quale arch/proc e con quali USE e' stato compilato un pacchetto.

ciao

----------

## Benve

Mi ero scordato una cosa...

Dato che il sistema si basa sulle chiavi di Gpg, il GDay può essere un'occasione per scanbiarsi la propria chiave.

Servono:

- Una persona fisica

- Un documento di riconoscimento

- Una chiave pubblica

Chi non la ha la può creare sul momento

Serve avere un documento per essere sicuri di associare una chiave ad una persona vera  :Smile: 

----------

## gutter

 *Benve wrote:*   

> 
> 
> [CUT]
> 
> Servono:
> ...

 

E il fingerprint della chiave   :Wink: 

----------

## =DvD=

 *SteelRage wrote:*   

> qualche mese fa, dopo un paio d'ore di discussioni su #gentoo, su azzurranet, sotto la supervisione di bsolar, abbiamo constatato che se gcc è compilato con CFLAGS diverse.... l'MD5sum dei binari prodotti è diverso...
> 
> ragazzi... in bocca al lupo  

 

Beh... se non fosse così a cosa servirebbe lo stage1? =D

----------

## cloc3

mi piace. In bocca al lupo.

----------

## Peach

cmq in riferimento a quello che si diceva sabato sera, ovvero facendo due calcoli sul numero di pacchetti diversi e di flag disponibili c'è da dire che il sync considera attualmente 101.000 pacchetti (in crescere) che dovrebbero essere tutte le versioni di tutti i pacchetti disponibili per tutte le categorie, sbaglio? ...qualcuno ha voglia di azzardare una stima sulle flag medie dei pacchetti?

----------

## Cazzantonio

io ne avevo contati circa 16.000 solo delle versioni più recenti x86 (non masked)

Le flag medie non sono tantissime perchè molti pacchetti hanno poche o punte use flag (se escludi le flag raramente usate "doc", "static", "bootstrap" etc...)

Il fatto è che se vai a considerare le cflag che puoi variare su ogni pacchetto raggiungi una cifra di possibili combinazioni enorme. Conta che molti usano cflags anche solo leggermente diverse, ma sufficienti a diversificare i pacchetti.

I casi sono due: ho viene imposto uno standard di cflags per compilare i pacchetti, oppure si accettano "quasi" tutte le cflags (a parte le cflags eccessivamente spinte che possono risultare instabili)

----------

## zUgLiO

Secondo me  :Smile:   dovreste raggiungere un compromesso e decidere voi di compilare i pacchetti con certe CFLAGS e certe USE. Poi l'utente finale decide se accettare il compromesso oppure se arrangiarsi.

Io pensavo ad una cosa del genere:

 Programma esplorativo per vedere quali sono le USE e CFLAGS + utilizzate dagli utenti di questo forum

 Utilizzare solo pacchetti stabili

 Accettare solo pacchetti generati con l'ultima versione stabile di gcc glibc headers e dipendenze varie dell'ebuild( alla fine la maggior parte degli utenti non installano librerie fondamentali instabili)

Se ho detto troppe cavolate ignoratemi   :Smile: 

----------

## Peach

 *Cazzantonio wrote:*   

> I casi sono due: ho viene imposto uno standard di cflags per compilare i pacchetti, oppure si accettano "quasi" tutte le cflags (a parte le cflags eccessivamente spinte che possono risultare instabili)

 

col benve si ipotizzava pure, per quanto riguarda le CFLAGS, quantomeno di poter impostare un range di cflags minime e una flessibilità nella ricerca dei precompilati.

Tipo:

il mio sistema compila con: 

CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer -fprefetch-loop-arrays -falign-functions=4 -fforce-addr"

quando vado da "binmerge" gli chiedo di cercarmi tutti i pacchetti ove:

march <= "pentium3" nella classe processore (quindi teoricamente "i586" "i686" "pentium" "pentium-mmx" "pentiumpro" "pentium2" e chiaramente "pentium3")

O == "3" || "2"

e che siano presenti almeno: "-pipe" e "-fomit-frame-pointer"

Poi magari voglio pure che se trova pacchetti compilati aggressivamente scarti quelli che hanno "-fkeep-inline-functions" e qualcos'altro... (anche se sappiamo che poi certi pacchetti per le flag di compilazione si arragiano e strippano quello che non gli serve o altro ancora)

in questo modo si dovrebbe migliorare la ricerca e non limitare la selezione (anche se ipoteticamente uno potrebbe)

----------

## gutter

@Peach: l'idea mi pare buona   :Very Happy: 

----------

## motaboy

 *Peach wrote:*   

> cmq in riferimento a quello che si diceva sabato sera, ovvero facendo due calcoli sul numero di pacchetti diversi e di flag disponibili c'è da dire che il sync considera attualmente 101.000 pacchetti (in crescere) che dovrebbero essere tutte le versioni di tutti i pacchetti disponibili per tutte le categorie, sbaglio? ...qualcuno ha voglia di azzardare una stima sulle flag medie dei pacchetti?

 

sono 101000 files. i programmi sono di meno, togli i metadata.xml, i digests, i changelogs, i Manifests, le patches, le eclasses etc...

----------

## ultimodruido

ciao! secondo me un sistema del genere è utile se volgio compilare Xorg oppure openoffice con le cflags che voglio io, ma non ho voglia di passarci una giornata! quindi io credo che i pacchetti che poi effettivamente saranno utilizzati sul circuito saranno quelli "bastardi" dal punto di vista della compilazione e quindi il numero si ridimensiona notevolmente! e in questo caso cercherei comunque una versione compilata con le use e cflags molto vicine alle mie!

ovviamente IMHO

ciaus nic

----------

## Benve

Certo che se non si trova il pacchetto che corrisponde esattamente alle proprie esigenze si può usarne uno che ci si avvicina.

Abbiamo un Database apposta per fare ricerche complesse.

Per quanto riguarda le ottimizzazioni spinte, se io compilo il software X con stringhe mirabolanti passate al mio gcc e funziona sul mio pentium4, non vedo perchè quello stesso programma non dovrebbe funzionare sul pentium4 di un'altro.

----------

## Cazzantonio

 *Benve wrote:*   

> Per quanto riguarda le ottimizzazioni spinte, se io compilo il software X con stringhe mirabolanti passate al mio gcc e funziona sul mio pentium4, non vedo perchè quello stesso programma non dovrebbe funzionare sul pentium4 di un'altro.

 

Se solo l'informatica fosse deterministica... il fatto è che può capitare che il programma risulti instabile per determinati utilizzi che il creatore non ha mai sfruttato mentre quello che si scarica il pacchetto si...

in ogni caso l'idea di fare una ricerca sulle cflags accettabili rimuove alla radice questo problema.

Si potrebbe semplicemente creare una sorta di CFLAGS_REQUIRED="" dove inserire le cflags che si richiedono al pacchetto (magari anche accettando dei >,<,= come proposto da peach) e una voce CFLAGS_ACCEPTED="" dove indicare tutte le cflags che tolleriamo, anche se non ne facciamo esplicita richiesta.

Il problema, anche se non risolto, risulta in questo modo quantomeno semplificato   :Smile: 

Ci sta che abbia detto cazzate, o magari ovvietà, in tal caso ignoratemi   :Very Happy: 

----------

## Peach

 *Benve wrote:*   

> Certo che se non si trova il pacchetto che corrisponde esattamente alle proprie esigenze si può usarne uno che ci si avvicina.
> 
> Abbiamo un Database apposta per fare ricerche complesse.
> 
> Per quanto riguarda le ottimizzazioni spinte, se io compilo il software X con stringhe mirabolanti passate al mio gcc e funziona sul mio pentium4, non vedo perchè quello stesso programma non dovrebbe funzionare sul pentium4 di un'altro.

 

si il fatto è che bisogna poter prevedere i comportamenti anomali, una sorta di bugzilla sarebbe fondamentale in determinati casi, anzi, come succede con i .torrent o con emule, avere la possibilità di aggiungere un commento al file...

----------

## Benve

 *Peach wrote:*   

> avere la possibilità di aggiungere un commento al file...

 

A questo si era pensato

----------

## Benve

quì ci sono le slide del GDay:

http://www.cs.unibo.it/~benvenut/binmerge/binmerge.html

----------

## gutter

 *Benve wrote:*   

> quì ci sono le slide del GDay:
> 
> http://www.cs.unibo.it/~benvenut/binmerge/binmerge.html

 

L'idea non sembra male. Se avete bisogno di uno sviluppatore fatemi sapere   :Wink: 

----------

## Benve

 *gutter wrote:*   

>  *Benve wrote:*   quì ci sono le slide del GDay:
> 
> http://www.cs.unibo.it/~benvenut/binmerge/binmerge.html 
> 
> L'idea non sembra male. Se avete bisogno di uno sviluppatore fatemi sapere  

 

Per ora fa parte di un nostro corso universitario ma appena si può, certamente

----------

## gutter

 *Benve wrote:*   

> 
> 
> [CUT]
> 
> Per ora fa parte di un nostro corso universitario ma appena si può, certamente

 

Per che corso?

Ok, buon lavoro allora  :Wink: 

----------

## randomaze

 *gutter wrote:*   

> Per che corso?

 

"corso" é una parola grossa... a giudicare da quello che ci ha detto al GDay dovrebbe coprire i tre quarti degli esami di informatica, la metà di ingegneria edile, un paio di lettere e, forse, anche uno di storia dell'arte  :Rolling Eyes: 

----------

## gutter

 *randomaze wrote:*   

> 
> 
> [CUT]
> 
> "corso" é una parola grossa... a giudicare da quello che ci ha detto al GDay dovrebbe coprire i tre quarti degli esami di informatica, la metà di ingegneria edile, un paio di lettere e, forse, anche uno di storia dell'arte 

 

Ma che sono i misteri del nuovo ordinamento  :Question:   :Question:   :Question: 

----------

## codadilupo

[quote="randomaze"]hai dimenticato "statistica", se prendono detro anche uno studio delle probabilità che due utenti abbiano realmente gli stessi pacchetti  :Laughing: 

Coda

----------

## chiapil

 *gutter wrote:*   

> 
> 
> Per che corso?
> 
> 

 

In teoria sarebbe per il corso di sistemi operativi ma credo che Benve stia cercando di spacciarlo pure come progetto di sicurezza( vista la questione delle chiavi).

e bravo Benve!  :Very Happy: 

----------

## matteo*

 *chiapil wrote:*   

>  *gutter wrote:*   
> 
> Per che corso?
> 
>  
> ...

 

non dimentichiamo l'imponente parte per lab di basi di dati feat. postgresql

 :Cool: 

----------

## Benve

Dopo un po di suspense (si scrive così ?), vi aggiorno sulla mia situazione universitaria:

Bimberge vale sicuramente come:

Progetto di Laboratorio di basi di dati

Progetto avanzato di sistemi operativi

Molto probabilmente varrà anche come:

Progetto di sicurezza

Progetto dell' [app|adm]staff (http://caristudenti.students.cs.unibo.it/)

Se siamo miracolati (cioè se entro marzo funziona qualcosa) vale anche come

Progetto di tecnologie web

Open Source Contest del prossimo anno (questa me la sono inventata ora)

PS. sto studiando basi di dati ed ho scoperto di odiare profondamente i DBMS

----------

## gutter

@Benve: in pratica se tutto va bene ti laurei con questo progetto   :Cool: 

----------

## multix

Vediamo... osno finito in questo thread perché avevo proposto di usare la "nuova" sun e3500 come repository GRP per pacchetti per sparc32 o altre architetture poco usuali per cui non esistono dei repository abbastanza "ufficiali".

Allora mi sono sciroppato tutto il thread alla svelta e pure le slides.

A parte un fastidioso inizio delle slides... che sostengono che gentoo non abbia un sistema di pacchetti binari come BSD... quando GRP poi è la stessa cosa di ports binari... I pacchetti compilati con dei flags che vanno bene per tutti! Anche sotto BSD posso modificare le opzioni per ogni pacchetto se ne ho voglia e compilarmeli tutti... Ma capisco che l'introduzione serviva per tirare l'acqua al proprio mulino...

Per delle architetture alternative vedrei in ogni caso di buon occhio la presenza di un repository GRP.

Elenco qualche punto di perplessità in ordine sparso

- bit torrent. Non lo vedo come buona cosa per dei file che devono "permanere" nel tempo. Suppongo che noi utenti sparc32 saremmo in pochi, i files invecchierebbero presto ed inoltre dovrei metterlo in condivisione dalla mia macchina. 

- dei pacchetti GRP li posso usare da livce-cd in fase di installazione

- l'idea di avere dei pacchetti "di riferimento" è proprio una cosa che può tornare utile. Voglio dire useflags standard e pacchetto provato da diverse persone. Suppongo di avere dei problemi sulla mia macchina, che è lenta nel compilare. Sono alla caccia di un problema ocn un porgramma di X11. Se come "test" devo avere una versione di X11 "affidabile" o se devo prvare con Xfree e Xorg.. installare un pacchetto pronto è l'unica soluzione se non voglio passare 3 settimane di compilazione con tentativi vari.

Non vorrei quindi certo togliere l'entusiasmo ai creatori di binmerge e anzi li incoraggio nel loro sviluppo. Ma non la vedo come una "panacea" e come un rimpiazzo di GRP.

Per supportare qualche diversa combinazione baase, basterebbe creare diversi repository GRP che poi a ben vedere per sparc32 si ridurrebbero a pochi probabilmente. Per x86 vi divertite molto di più... ma alla fine non tutti i flags sono significativi (ad es. -pipe non dovrebbe infulenzare minimamente il binario) mentre altri posson causare sì un problema nel binario, ma difficilmente solo su alcuni sistemi (mettiamo O2/O3 anche se non è vero in assoluto) altri potrebbero precluderne l'utilizzo (istruzioni/schedulazione per una certa cpu). Altri invece infine non dovrebbero creare problemi di incompatibilità, ma sono scelta personale. Io preferisco compilare gvim con lesstif, altri potrebbero volere gtk, quindi dipendenze diverse. Silla mia sparc tra l-'altro uso -X... per cui  :Smile: 

QUalcuno qui sul thread ha preso queste differenze abbbastanza alla leggera, spero che gli sviluppatori di binmerge non l'abbiano fatto. Più di una volta ho sbattuto la testa con gli useflags, in quanto sono generici e controllano una marea di cose diverse.

----------

## gutter

 *multix wrote:*   

> 
> 
> A parte un fastidioso inizio delle slides... che sostengono che gentoo non abbia un sistema di pacchetti binari come BSD... quando GRP poi è la stessa cosa di ports binari... 

 

Non è che siano esattamente la stessa cosa; i GRP sono nati per installare su macchine lente o per avere un sistema funzionante in breve tempo. Poi in ogni caso devi semprecompilare non appena escono le versioni nuove dei programmi  :Wink: 

----------

## Benve

Ciao. Premetto alcune cose:

- Non ho mai messo le mani su una sparc.

- Ho usato FreeBSD solo per due mesi alla fine del 2002.

- Quando dico BSD intendo FreeBSD, se ci sono differenze sostanziali nel sistema di gestione del software non le conosco.

- Le slide sono state fatte in un pomeriggio ed erano solo un supporto ad una "chiaccherata" fatta alle 22 al GDay.

Per cominciare posso dire di aver capito male riguardo i pacchetti di sparc32/64. Pensavo volessi semplicemente tenere una collezione di pacchetti, non fare una GRP, come quelle ufficiali. In effetti una GRP è una cosa diversa e sono d'accordo che non può essere sostituita da binmerge.

 *multix wrote:*   

> 
> 
> Allora mi sono sciroppato tutto il thread alla svelta e pure le slides.
> 
> A parte un fastidioso inizio delle slides... che sostengono che gentoo non abbia un sistema di pacchetti binari come BSD... quando GRP poi è la stessa cosa di ports binari...
> ...

 

Come ho detto sopra, non conosco bene BSD.

Mi sembra comunque di aver capito che la GRP è qualcosa di molto diverso dai packages di BSD.

In BSD per installare un software si può usare un package o un port.

Gli ebuild di gentoo funzionano come i ports, mentre package è un pacchetto compilato. Quindi i package sono più vicini ai pacchetti di altre distribuzioni linux come i Deb o gli RPM.

(multix non lo sto spiegando a te, tu lo sai molto meglio di me, è per chi magari segue il tread e non ha voglia di leggere doc su BSD)

Per quello che ho capito ad ogni port di BSD corrisponde un package.

Ogni volta che esce una versione di un software e se ne fa un port, poi viene creato anche il rispettivo package.

La GRP è qualcosa di diverso.

Per prima cosa i pacchetti sono pochissimi rispetto agli ebuild. Mancano addirittura pacchetti fondamentali come dhcp o i demoni cron. La GRP esce insieme ad una versione di Gentoo, non segue le versioni dei software ma di Gentoo.

Questo perchè la GRP serve solo per avere un'installazione base in rapido tempo. Una volta che qualcuno avrà installato Gentoo usando una GRP, si dimenticherà che questa esisite sino alla prossima installazione.

Mentre i packages di BSD vengono usati quotidianamente per aggiornare software, i pacchetti della GRP servono solo durante l'installazione.

 *multix wrote:*   

> 
> 
>  I pacchetti compilati con dei flags che vanno bene per tutti! Anche sotto BSD posso modificare le opzioni per ogni pacchetto se ne ho voglia e compilarmeli tutti... Ma capisco che l'introduzione serviva per tirare l'acqua al proprio mulino...

 

Quel lucido mi sembrava scontato. Mi sembrava scontato che non esistesse in Gentoo "la possibilità di usare pacchetti binari al posto dei compilati".

Se qualcuno li usa, come userebbe i packages di BSD, me lo faccia sapere che li vorrei usare.

 *multix wrote:*   

> 
> 
> Per delle architetture alternative vedrei in ogni caso di buon occhio la presenza di un repository GRP.
> 
> 

 

Come dicevo sopra binmerge non ha niente a che fare con la GRP.

Se devo fare un'installazione non uso binmerge ma GRP. Se dopo aver installato voglio openoffice in italiano o kdevelop uso binmerge.

Se la GRP per alcune architetture manca, è molto positivo che qualcuno la crei, anche non ufficiale.

 *multix wrote:*   

> 
> 
> Elenco qualche punto di perplessità in ordine sparso
> 
> - bit torrent. Non lo vedo come buona cosa per dei file che devono "permanere" nel tempo. Suppongo che noi utenti sparc32 saremmo in pochi, i files invecchierebbero presto ed inoltre dovrei metterlo in condivisione dalla mia macchina. 
> ...

 

Binmerge è un software che può adattarsi a vari tipi di utilizzo.

Se lo si vuole usare sulla propria macchina client, allora si creeranno i propri pacchetti e si condivideranno per gli altri utenti.

Ma nulla vieta di usarlo per condividere una GRP. L'unico a condividere può essere il server e i pacchetti vengono usati da tutti gli altri.

Questo è un discorso ampio e complicato. Magari ne discutiamo più avanti.

 *multix wrote:*   

> 
> 
> - dei pacchetti GRP li posso usare da livce-cd in fase di installazione
> 
> - l'idea di avere dei pacchetti "di riferimento" è proprio una cosa che può tornare utile. Voglio dire useflags standard e pacchetto provato da diverse persone. Suppongo di avere dei problemi sulla mia macchina, che è lenta nel compilare. Sono alla caccia di un problema ocn un porgramma di X11. Se come "test" devo avere una versione di X11 "affidabile" o se devo prvare con Xfree e Xorg.. installare un pacchetto pronto è l'unica soluzione se non voglio passare 3 settimane di compilazione con tentativi vari.
> ...

 

Grazie per l'incoraggiamento.

Ribadisco GRP != Binmerge ma Binmerge può essere usato anche per diffondere i GRP.

 *multix wrote:*   

> 
> 
> Per supportare qualche diversa combinazione baase, basterebbe creare diversi repository GRP che poi a ben vedere per sparc32 si ridurrebbero a pochi probabilmente. Per x86 vi divertite molto di più... ma alla fine non tutti i flags sono significativi (ad es. -pipe non dovrebbe infulenzare minimamente il binario) mentre altri posson causare sì un problema nel binario, ma difficilmente solo su alcuni sistemi (mettiamo O2/O3 anche se non è vero in assoluto) altri potrebbero precluderne l'utilizzo (istruzioni/schedulazione per una certa cpu). Altri invece infine non dovrebbero creare problemi di incompatibilità, ma sono scelta personale. Io preferisco compilare gvim con lesstif, altri potrebbero volere gtk, quindi dipendenze diverse. Silla mia sparc tra l-'altro uso -X... per cui 
> 
> 

 

Credo che una sola GRP sarebbe più utile. Già sarà difficile gestirne una. Si dovrebbero concentrare gli sforzi.

 *multix wrote:*   

> 
> 
> QUalcuno qui sul thread ha preso queste differenze abbbastanza alla leggera, spero che gli sviluppatori di binmerge non l'abbiano fatto. Più di una volta ho sbattuto la testa con gli useflags, in quanto sono generici e controllano una marea di cose diverse.

 

Putroppo sino ad ora abbiamo ragionato "ad alto livello", i problemi ci saranno e saranno molti ed enormi. Appunto per questo vogliamo il prima possibile creare qualcosa di usabile per evidenziare i punti deboli del progetto.

Spero di non essere stato troppo polemico o scortese.

Se lo sono stato mi scuso.

Qualcuno mi corregga se ho fatto errori tecnici.

Grazie, Ciao.

----------

## gutter

@Benve: credo che hai sottolineato bene le differenze.

----------

## multix

No la precisazioni che hai fatto erano doverose e non erano polemiche. Almeno si parte da basi solide.

comunque da quanto ne so non c'è una grande differenza fra un GRP e un repository di quickpg.

Essenzialmente catalyst ti crea un "ambiente pulito" dove crea il pacchetto con delle configurazioni standard e degli useflags standard e poi usa quickpg egli stesso.

Non sono però al corrente se esegua altre cose essenziali, gli sviluppatori gentoo saranno più informati di me di certo.

In ogni caso il thread per un GRP per sparc è stato splittato, per chi vuole proseguire di là la discussione, benvenga  :Smile:  Sparc users, fatevi avanti!

----------

## Benve

Si in effetti sarebbe bello sapere con che impostazioni vengono costruite le GRP. Poi queste impostazioni sono unguali per ogni architettura ?

Ci vediamo nell'altro post (anche se non ho una sparc).   :Very Happy: 

PS. Tu hai sempre usato FreeBSD sulle sparc ?

----------

## rota

ba troppo luigo da leggere ...  :Embarassed:   :Embarassed:   pero vi dico questo ...

1 )  per qunato riguarda la vericita dell programma ...potete mettere i file.md5  isnieme all programma .. e uno verifiha la vercità andando sull sito da qui lo scaricha ecc..

2 ) per quanto rigurada come sapere come è stato compilato ecc .basta  mettere un  file nell pacchetto dovve contiene delle infromazzione ecc.

----------

## multix

 *Benve wrote:*   

> 
> 
> PS. Tu hai sempre usato FreeBSD sulle sparc ?

 

no, nonl'ho mai usato... ho usato NetBSD, OpenBSD, Solaris e gentoo. Ho provato anche debian una volta, ce l'ho su un disco "volante" in alternativa a netbsd per fare dei test.

----------

## silian87

Fatto progressi? Io ed alexbr saremmo interessati... e forse in futuro avremmo un piccolo server casalingo per scambiare qualche binario.   :Very Happy: 

----------

## emix

 *Benve wrote:*   

> Per quello che ho capito ad ogni port di BSD corrisponde un package.
> 
> Ogni volta che esce una versione di un software e se ne fa un port, poi viene creato anche il rispettivo package.

 

Da quello che ho capito io invece (ho usato FreeBSD per un mesetto a novembre) i package vengono fatti soltanto con l'uscita di una nuova release (ad esempio la 5.3). Se vuoi aggiornare un pacchetto dai binari devi aspettare la release successiva (5.4), altrimenti ti devi compilare il port. Se così fosse sarebbe esattamente come i GRP, ma potrei anche sbagliarmi  :Rolling Eyes: 

----------

## silian87

Cmq l'idea che ogniumo si fa i pacchetti per i cavoli suoi e poi li da in giro non e' male.... credo che appena avro' il server provero' a fare un mirror dei miei pacchetti ... anche perche' ho gia' impostato la dir su /var/packages ed i distfiles su /var/distfiles... Al limite si fara' anche un sistema per le cflag e le use (soprattutto le cflas).

----------

## gutter

 *silian87 wrote:*   

> Cmq l'idea che ogniumo si fa i pacchetti per i cavoli suoi e poi li da in giro non e' male.... 

 

Rimane sempre il problema della sicurezza, ovvero quanta fiducia dai a chi ti fornisce il pacchetto?

----------

## silian87

 *Quote:*   

> Rimane sempre il problema della sicurezza, ovvero quanta fiducia dai a chi ti fornisce il pacchetto?

 

Hai ragione.... l'ho anche letto nelle slides... Beh.. il discorso di gpg non e' male... solo che e' un bel casino...    :Confused:   :Confused: 

----------

## gutter

 *silian87 wrote:*   

> 
> 
> Hai ragione.... l'ho anche letto nelle slides... Beh.. il discorso di gpg non e' male... solo che e' un bel casino...    

 

Il discorso di gpg può risolvere a mio avviso solo in parte il problema.

----------

## Benve

Ciao, al momento il progetto è fermo causa esami, ma devo necessariamente fare qualcosa di funzionante entro marzo (mi serve per completare un esame). Quindi presto si potranno fare test.

silian87, quello che mi serve più di tutti è un tracker per bittorrent, che connessione avete?

----------

## silian87

 *Quote:*   

> silian87, quello che mi serve più di tutti è un tracker per bittorrent, che connessione avete?

 

Beh... una adsl domestica.. sia che lo facciamo a casa mia o da un mio amico abbiamo sempre 256 di upload   :Sad:  . cioe' al max 30-35kb/sec ... Lo so che non e' molto....

----------

## Benve

La banda non serve, quello che serve è la continuità del servizio.

Comunque a ogni pacchetto si possono associare più torrent per essere sicuri che almeno un traker sia online ma si perde il vandaggio del download contemporaneo da più utenti

----------

## Dece

Mi sono imbattuto per caso in questo post:

https://forums.gentoo.org/viewtopic-t-302064.html

http://genux.org/about.php

mi sembra qualcosa di molto simile a binmerge, conoscevate già?

----------

## Tiro

magari potrà essere interessante per una ditta dove il tempo è denaro...ma per 10$ al mese me li compilo da solo i pacchetti...  :Laughing: 

----------

## gutter

Non conoscevo questo sito. 

Dimostrazione di come si possono fare soldi con l'open source.

----------

## Benve

E' rassicurante vedere un servizio del genere.

Significa che Binmerge si può fare, cioè è possibile usare i binari con Gentoo

----------

## rust5

benve ci sono novità sul progetto?

----------

## neryo

 *Dece wrote:*   

> Mi sono imbattuto per caso in questo post:
> 
> https://forums.gentoo.org/viewtopic-t-302064.html
> 
> http://genux.org/about.php
> ...

 

interessante  :Laughing: 

----------

## Raffo

ci sono capitato per sbaglio e quasi non ricordavo questa discussione... il progetto è morto?

----------

## youth against youth

ho paura di si..

ma per sicurezza adesso "scrivo agli sviluppatori"   :Laughing: 

----------

## =DvD=

ma non potrebbero usare il motore del seti@home per avere piu' pacchetti binari disponibili..?

gentoo@home ghghg

http://boinc.berkeley.edu/

----------

