# [POLL] Cosa vorreste di nuovo in Gentoo/FreeBSD

## drizztbsd

Ragazzuoli,

ora che sono vicecapo di Gentoo/FreeBSD vorrei proporre un POLL.

Cosa vorreste di bello in Gentoo/FreeBSD?

----------

## riverdragon

Ma con gentoo/freebsd intendi il progetto che fa andare gentoo su kernel bsd o è un modo per chiedere "cosa volete di nuovo in gentoo e/o freebsd"?

----------

## Scen

 *riverdragon wrote:*   

> Ma con gentoo/freebsd intendi il progetto che fa andare gentoo su kernel bsd o è un modo per chiedere "cosa volete di nuovo in gentoo e/o freebsd"?

 

Da http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml:

 *Quote:*   

> 
> 
> An effort to provide the complete Gentoo/Linux facilities on BSD operating systems, allowing users to use their knowledege of Gentoo's services and utilites with BSD userlands and kernels.
> 
> 

 

Riguardo al poll, premetto di non aver ancora provato Gentoo/FreeBSD (solamente un'installazioncina di test direttamente di FreeBSD 6.qualcosa), per cui voto per un LiveCD, penso mi spingerebbe più facilmente a provare questo intrigante progetto  :Wink: 

----------

## randomaze

 *Drizzt Do` Urden wrote:*   

> ora che sono vicecapo di Gentoo/FreeBSD vorrei proporre un POLL.

 

Hai fatto carriera  :Mr. Green: 

Dimmi se vuoi lo stiky a questo post....  :Wink: 

----------

## djinnZ

LiveCD, emulazione linux,

soprattutto una guida un poco più dettagliata che comprenda l'installazione da linux (compresi gli avvertimenti per gli scemuniti sui diversi nomi dei device)...

Insomma farlo diventare facile come installare linux ex novo da una gentoo esistente e non (mica posso riavviare e lavorare da bsd...).

Così finalmente mi decido a provarlo seriamente.

----------

## lucapost

Farebbe molto comodo un liveCD...

Ma con quali tempi si potrebbe ottenerlo?

----------

## drizztbsd

 *lucapost wrote:*   

> Farebbe molto comodo un liveCD...
> 
> Ma con quali tempi si potrebbe ottenerlo?

 

Beh ora come ora bisogna usare FreeSBIE, stavo pensando di fare un livecd contenente magari lo stage3, la guida ed eventualmente uno snapshot di portage (come il livecd linux).

Una bozza di livecd la posso buttare fuori in tempo quasi 0 (però usando una FreeBSD vanilla come partenza) anche se volevo modificare catalyst (se possibile) per generarlo da gentoo/freebsd o cmq fare uno script ad hoc

----------

## !equilibrium

voto anche io per l'installazione da linux, in quanto chi vuole fare testing a Gentoo/FreeBSD al 99.9% ha già una gentoo installata e passare da FreeSBIE è un po una palla al piede (IMHO).

----------

## .:chrome:.

 *djinnZ wrote:*   

> LiveCD, emulazione linux,
> 
> soprattutto una guida un poco più dettagliata che comprenda l'installazione da linux (compresi gli avvertimenti per gli scemuniti sui diversi nomi dei device)..

 

ehm... credo che questo sia impossibile.

FreeBSD non è Linux e non penso proprio che il sistema sia compilabile da Linux. Drizzt mi smentisca se sbaglio

comunque sia io ho votato per il LiveCD, nonostante abbia già sperimentato con soddisfazione l'immagine minimale di Drizzt stesso, che è molto più comoda di Freesbie.

penso sarebbe interessante, ma questo dipende solo dai forum admins, anche avere un forum dedicato a Gentoo/FreeBSD

----------

## djinnZ

intendevo via qemu...  :Confused:  od altro sistema per virtualizzare. Compilare un binario BSD da linux dovrebbe essere possibile come l'inverso, emergere i pacchetti non credo.

Dovrebbe essere possibile (spero) altrimenti quando lo trovo il tempo di compilare BSD.

tanto sul server l'ottavo nano (HD da 80) al momento lo uso solo per l'immondizia. Oppure uso l'HD USB.

Forse potrebbe essere anche interessante pensare ad un cd di installazione minimale dual boot, per il futuro.

----------

## .:chrome:.

 *djinnZ wrote:*   

> intendevo via qemu...  od altro sistema per virtualizzare

 

allora non usi Linux e torniamo a quello che dicevo io  :Wink: 

----------

## djinnZ

In realtà è più un problema di limiti di portage (sarebbe simpatica a prescindere come feature, poter scegliere un percorso di destinazione senza passare per il chroot, risolverebbe non pochi problemi del genere phyton o gcc KO) perchè in teoria (ripeto, in teoria, perchè l'unica prova in tal senso la feci con il link di un coff sco gcc&c non hanno solo la capictà di cross compiling ma anche di cross linking) ci si dovrebbe riuscire e l'inverso dovrebbe comportare i medesimi problemi.

Cero l'ìdea di avere un dual boot dove l'emerge --sync -DNu world può essere lanciato indipendentemente da uno dei due sistemi è forse troppo complicata al momento (c'è sempre il problema dei filesystem. Però...

Via qemu manca una immagine piccola ed efficiente (mica posso lanciare il cd da quemu e da quello il chroot, è mostruoso) ed una guida più immediata su cosa fare (però ammetto che non mi sono impegnato per niente).

Ma forse discende tutto dal trauma di aver provato la prima volta con il malefico open.

----------

## .:chrome:.

scusa, ma io non riesco proprio a capire cosa intendi.

 *djinnZ wrote:*   

> In realtà è più un problema di limiti di portage (sarebbe simpatica a prescindere come feature, poter scegliere un percorso di destinazione senza passare per il chroot, risolverebbe non pochi problemi del genere phyton o gcc KO) perchè in teoria (ripeto, in teoria, perchè l'unica prova in tal senso la feci con il link di un coff sco gcc&c non hanno solo la capictà di cross compiling ma anche di cross linking) ci si dovrebbe riuscire e l'inverso dovrebbe comportare i medesimi problemi.

 

non ho capito

 *djinnZ wrote:*   

> Cero l'ìdea di avere un dual boot dove l'emerge --sync -DNu world può essere lanciato indipendentemente da uno dei due sistemi è forse troppo complicata al momento (c'è sempre il problema dei filesystem. Però...

 

Gentoo/FreeBSD è esattamente così come la descrivi: esattamente come Gentoo/Linux, solo che ci sono sotto uno userland BSD invece che GNU e un kernel FreeBSD invece che Linux.

 *djinnZ wrote:*   

> Via qemu manca una immagine piccola ed efficiente (mica posso lanciare il cd da quemu e da quello il chroot, è mostruoso)

 

hai provato a guardare quel liveCD che ho linkato qualche post più sopra?

----------

## Kernel78

Io seguo la discussione ma non saprei cosa votare per il semplice motivo che dal fondo della mia ignoranza non ho nemmeno idea di cosa potrebbe offrirmi freebsd e quindi non saprei cosa quale caratteristica potrebbe interessarmi di più.

Discutere almeno brevemente dei motivi che potrebbero spingere, se non a scegliere, almeno a provare freebsd quando uno ha già linux installato sarebbe troppo OT qui ?

----------

## djinnZ

Dunque, gcc/binutils hanno la capacità di cross-compile, ovvero puoi creare (teoricamente, in pratica so che non è molto seguita la cosa e quindi non so fino a che punto funziona) binari per differenti architetture. Quindi anche se non puoi eseguirli puoi creare binari bsd da linux e viceversa (dove puoi pure eseguirli se non erro).

Quindi è possibile lanciare un make su uno dei due os istruendo il compilatore a creare binari per l'altra piattaforma.

La cosa è di per se stessa interessante perchè aprirebbe la prospettiva di trasformare gentoo in qualcosa di più consentendo la creazione di installazioni satellite minimali prive degli strumenti di sviluppo ed il ripristino nei soliti casi di python danneggiato e semplificare la vita per aggiornamenti critici come gcc4.

Mettiamo che durante l'emerge di glibc il computer crasha durante la fase di scrittura: il chroot non funziona, l'unica è preparare un tbz2 da un sistema libero, scompattarli manualmente e poi riemergere il sistema e verificare i file rimasti indetro dall'aggiornamento fallito.

Potendo dire ad emerge di prendere a riferimento l'albero di root del sistema di destinazione ma continuando ad usare make, automake e gcc dell'host ti limiti ad un emerge glibc e risolvi.

Non dico che è facile, sarebbero necessari dei pesanti rimaneggiamenti agli ebuild, modificare sandbox, rivedere buona parte del portage e soprattutto il patching sui pacchetti dovrebbe diventare molto più pesante visto che non tutti i pacchetti gestiscono correttamente (spesso non lo gestiscono per niente) path di ricerca e path di destinazione separati, idem per i path di destinazione. Poi ci sono quegli automake e quei pacchetti che per ragioni loro vanno ad estrarre informazioni dal sistema in uso che ovviamente non funzionerebbero senza apposite patch (come esempio penso ad un ntfs3g che va a verificare quali moduli sono caricati od a tutti quegli automake in linux che determinano da proc o sys informazioni sul buffer, dimensione massima della riga di comando etc.)

Ovviamente è "just an idea" e lo so che implementarla sarebbe abbastanza duretta.

ma visto che siamo tutti utenti di gentoo un minimo di masochismo ci deve contraddistinguere...  :Twisted Evil: 

ed è più che altro un cosa vorrei in gentoo linux e freebsd per fare il verso a riverdragon.

Per quanto riguarda il metodo classico l'immagine nuova è già un inizio, appena trovo un poco di tempo provo.

----------

## .:chrome:.

 *djinnZ wrote:*   

> Dunque, gcc/binutils hanno la capacità di cross-compile, ovvero puoi creare (teoricamente, in pratica so che non è molto seguita la cosa e quindi non so fino a che punto funziona) binari per differenti architetture. Quindi anche se non puoi eseguirli puoi creare binari bsd da linux e viceversa (dove puoi pure eseguirli se non erro).
> 
> Quindi è possibile lanciare un make su uno dei due os istruendo il compilatore a creare binari per l'altra piattaforma.

 

non avevo mai valutato questa opportunità, e se hai ragione è davvero interessante.

ho un dubbio: un conto è la cross-compilazione per un altra architettura, ma sempre sulla stessa libreria (glibc) un altro conto è la cross-compilazione per la stesa architettura, ma un altro sistema operativo, con diverso userland e diverse librerie di base (libc invece che glibc) che per di più mi risultano essere incompatibili a livello ABI. sicuro che sia possibile?

quanto al resto delle modifiche che "suggerisci" ho visto molti cambiamenti ai pacchetti proprio in questo senso... sempre che non stia prendendo un abbaglio

----------

## djinnZ

Il problema è proprio quello, gcc può creare un eseguibile facilmente ma mettiamo che vuoi compilare il classico hello.c

Linux x linux: gcc -o hello hello.c ed è tutto fatto.

linux x altro (supponendo il sistema destinatario in mnt/gentoo): gcc -march=athlon64 -I/mnt/gentoo/usr/src/include -L/mnt/gentoo/lib -o hello hello.c

apparentemente banale... ma in un make le cose sono differenti perchè in genere i percorsi di include sono definito per path relativi -Iinclude/sys ed in questo caso già hello.c ti darà errore perchè non puoi linkare un oggetto in codice a 64 bit ad una libreria a 32 e viceversa (ne sanno qualcosa gli utenti di gentoo64).

Il problema è che molti automake fanno cose del genere leggere da proc/sys o quant'altro informazioni sui limiti configurabili del sistema o compilano un piccolo programma per verificare se determinate opzioni del compilatore funzionano etc. ed ovvimente fallibbero perchè bsd e linux sono piuttosto diversi in questo.

Poi se nel make ho un -Llib/libqualcosa è ovvio che fallirà a tentare di linkare un binario bsd con una libreria elf.

In piùl'utilità dell'automake è che si occupa di fare la scansione in base al path corrente mentre in questo caso deve fare la scansione su un albero differente ma non si può cambiare il path perchè deve trovare i suoi eseguibili.

Non mi apetto che drizzt sia contento di una proposta del genere (sarebbe veramente un lavoraccio infame) ma chiedere non costa nulla.

----------

## cloc3

un livecd dimostrativo stile knoppix, da far girare su linux in emulazione, con xen  o vmware.

----------

## drizztbsd

Ci sono un alcuni problemi per la cross-compilazione linux2bsd.

Uno di questi è il fatto che linux non può scrivere UFS2 (sì nel kernel è markato come experimental ma l'ultima volta che l'ho usato mi ha dato una cifra di kernel panic), un altro è che cmq pochissimi pacchetti supportano cross-compilazione (moltissimi pacchetti fanno i test a runtime e ovviamente linux non può eseguire un elf BSD).

Invece l'opposto è fattibile (BSD ha l'emulazione binaria per linux)

----------

## Ic3M4n

anche io ho votato per un livecd anche se personalmente preferirei avere un quadro maggiore, inteso come informazioni per l'installazione, rispetto a quello attuale che fa moltissimi rimandi. Onestamente pur non avendo problemi nell'installare gentoo/linux ho trovato alcuni problemi utilizzando i tool di freesbie e non avendo una macchina dedicata avevo paura di fare un po' di casini e fottermi i dati.

----------

## djinnZ

 *Drizzt Do` Urden wrote:*   

> Ci sono un alcuni problemi per la cross-compilazione linux2bsd.

 

Come ho detto è solo un'idea che mi è frullata per la mente, non la vedo fattibile a breve, piuttosto cercare di portare gli ebuild verso il cross-compile generico potrebbe essere interessante a prescindere, anche solo linux2linux o bsd2bsd, in attesa che il supporto UFS diventi più decente.

Sempre automake balordi permettendo... ma qui credo che sarebbe più questione di cercare di sensibilizzare i devel dei singoli progetti a cambiare mentalità.

Per alcuni test (parlando di linux2linux, non mi azzardo su bsd) basterebbe uno snapshot di sys e proc quanto poi all'utilità di cose del genere

opt=-O6

[gcc $opt prova.c] || opt=-02

avrei qualcosa da ridire... anche in termini di sicurezza, come è già capitato in passato.

----------

## X-Drum

 *Drizzt Do` Urden wrote:*   

> Ragazzuoli,
> 
> ora che sono vicecapo di Gentoo/FreeBSD vorrei proporre un POLL.
> 
> Cosa vorreste di bello in Gentoo/FreeBSD?

 

diego!!! :PPP

scherzi a parte un livecd ufficiale non sarebbe male (anche se comprendo quanto difficoltoso sia realizzarlo)

Per il resto io avrei intenzione di usare gfbsd sui miei server quindi sono molto interessato a tutto quel software

che tipicamente si impiegherebbe su un server (firewall,mta,webserver,ecc) a che punto siete con la stabilizzazione?

ho visto che in questo periodo state lavorando sodo

----------

## Peach

 *X-Drum wrote:*   

> Per il resto io avrei intenzione di usare gfbsd sui miei server quindi sono molto interessato a tutto quel software
> 
> che tipicamente si impiegherebbe su un server (firewall,mta,webserver,ecc)

 

quoto  :Smile: 

----------

## lucapost

ci sono sviluppi a riguardo?

----------

## lucapost

si sa ancora niente? ci sarà un giorno uno stage3 per amd64?

----------

## drizztbsd

Quando uscirà la 7.0 che compila ovunque con gcc 4.2 vi faremo sapere

----------

## lucapost

Magari ci sarà paludis e non portage come gestore dei pacchetti? è plausibile?

----------

## drizztbsd

 *lucapost wrote:*   

> Magari ci sarà paludis e non portage come gestore dei pacchetti? è plausibile?

 

Da boss dico di no  :Razz: 

----------

## lucapost

 *drizztbsd wrote:*   

>  *lucapost wrote:*   Magari ci sarà paludis e non portage come gestore dei pacchetti? è plausibile? 
> 
> Da boss dico di no 

 

Sarebbe stato interessante...complicarsi la vita ancora un pò!

Mandi.

----------

## lucapost

Che shell usa di defaults gentoo/freebsd? bash o che altro?

ps: da poco ho messo sul fisso la freebsd-6.2, tcsh è veramente una figata!

----------

## drizztbsd

gentoo/freebsd usa la stessa configurazione di default di gentoo/linux.

fra cui bash come shell di default

----------

## lucapost

notizie?

----------

