# Troppi standard su GNU/Linux rendono lo sviluppo difficile?

## CarloJekko

bhè come da post... Ecco un esempio preso da http://www.kaourantin.net/2005/08/porting-flash-player-to-alternative.html

```
.......

So rather than just do a quick and dirty port for Flash Player 8 I would really like to get it done right. The kicker is this: It's damn hard. Much harder than even supporting OS X. While porting command line applications to Unix is beyond trivial, porting media applications (which the Flash Player essentially is) is a real nightmare. This starts with sound support where we have to support many different sound standards (ALSA, OSS, aRTs, ESD etc.), framework support (X11, QT, GTK for copy&paste support f.ex.), IMEs (is there such a thing?), font support which is almost beyond comprehensible and many other quirks and forked 'standards'. 

.......
```

----------

## Peach

trovo che sia una mezza verità: nel senso, è vero che ci sono tanti standard, e sono particolarmente incasinati specialmente se vieni da fuori; dopo un anno di uso continuo di linux hai già una idea di cosa va e cosa non va, e soprattutto in che direzione si sta muovendo la massa; se poi inizi a lavorarci come programmatore, sono convinto che una conoscenza di parte e parziale sia inutile (vedi il dibattito gtk qt, giusto per dirne uno). 

Ci sono aspetti progettuali che fanno porre l'attenzione su determinati aspetti che spesso un programmatore novello non ha: uno per tutti la portabilità. Inoltre, mi sembra che troppo spesso si punti più alla realizzazione di un widget che alla realizzazione di codice funzionante, non so se mi spiego. Poi non voglio nemmeno fare di tutta un'erba un fascio, ci sono bei programmi, scritti bene e ottimamente funzionanti.

Tornando invece a parlare di flash, è un accrocchio quel programma... funziona, ma non vorrei metterci le mani neanche se viene giù il padreterno. Basta pensare che le "prestazioni" sotto MacOsX sono nettamente inferiori rispetto a quelle sotto Win32.

----------

## earcar

 *Peach wrote:*   

> trovo che sia una mezza verità: nel senso, è vero che ci sono tanti standard, e sono particolarmente incasinati specialmente se vieni da fuori; dopo un anno di uso continuo di linux hai già una idea di cosa va e cosa non va, e soprattutto in che direzione si sta muovendo la massa; se poi inizi a lavorarci come programmatore, sono convinto che una conoscenza di parte e parziale sia inutile (vedi il dibattito gtk qt, giusto per dirne uno). 
> 
> Ci sono aspetti progettuali che fanno porre l'attenzione su determinati aspetti che spesso un programmatore novello non ha: uno per tutti la portabilità. Inoltre, mi sembra che troppo spesso si punti più alla realizzazione di un widget che alla realizzazione di codice funzionante, non so se mi spiego. Poi non voglio nemmeno fare di tutta un'erba un fascio, ci sono bei programmi, scritti bene e ottimamente funzionanti.

 

Quoto e aggiungo che il software libero è bello perché è vario  :Very Happy: 

cioè ti da libertà di scegliere

tutto ciò (compreso il quote) IMHO

**earcar  :Wink: 

----------

## CarloJekko

 *earcar wrote:*   

>  *Peach wrote:*   trovo che sia una mezza verità: nel senso, è vero che ci sono tanti standard, e sono particolarmente incasinati specialmente se vieni da fuori; dopo un anno di uso continuo di linux hai già una idea di cosa va e cosa non va, e soprattutto in che direzione si sta muovendo la massa; se poi inizi a lavorarci come programmatore, sono convinto che una conoscenza di parte e parziale sia inutile (vedi il dibattito gtk qt, giusto per dirne uno). 
> 
> Ci sono aspetti progettuali che fanno porre l'attenzione su determinati aspetti che spesso un programmatore novello non ha: uno per tutti la portabilità. Inoltre, mi sembra che troppo spesso si punti più alla realizzazione di un widget che alla realizzazione di codice funzionante, non so se mi spiego. Poi non voglio nemmeno fare di tutta un'erba un fascio, ci sono bei programmi, scritti bene e ottimamente funzionanti. 
> 
> Quoto e aggiungo che il software libero è bello perché è vario 
> ...

 

Il mondo è bello perchè è vario.. non gli standard... questo gli ingegneri lo sanno bene...IMHO bisogna sedersi attorno ad un tavolo è decidere... questo va bene, quest'altro no... Forse una riorganizzazione nel mondo Open Source ci vuole...

----------

## GuN_jAcK

concordo.. unificando un pò i vari standard ci sarebbe un po più di ordine in tutto... forse aiuterebbe anche a terminare molti proggetti già iniziati e non a crearne sempre di continuo di nuovi... una perdita di tempo e basta.

oltretutto uno non sarebbe costretto sempre ad avere una tonnellata di librerie per solo un'applicazione che magari usa anche di rado..  :Smile: 

----------

## randomaze

Rispettare gli standard rende sempre lo sviluppo più difficile. Questo perché per "rispettare" si é costretti a implementare feature non indispensabili, oppure ad utilizzare meccanismi che, secondo lo sviluppatore di turno, non sono adeguati al problema.

Usare gli standard invece é l'esatto contrario. Più si usano implementazioni standard e più é facile capire cosa serve e dove.

Ovviamente occorre mediare tra le due posizioni.

----------

## funkoolow

Gli standard sono utili se non indispensabili. Basti pensare allo standard HTML senza il quale non ci sarebbe stata una regola collettiva utile a contribuire allo sviluppo del mondo web che tutti oggi conosciamo. Solo uno standard in quanto tale garantisce una base interoperabile di sviluppo e, per dirla tutta, solo standard "contronatura" chiudono se stessi al mondo e il mondo a se stessi, impedendo l'evoluzione e l'implementazione di nuovi sviluppi: lo standard nasce per la cooperazione e lo sviluppo reciproco, non per affermarsi come leader in un qualche settore. Certo, decidere per un certo standard porterà necessariamente a delle esclusioni ma, se fatto con criterio, permetterà eventuali nuove implementazioni che si riveleranno utili.

Come al solito non è lo strumento il male in sè stesso, ma l'uso che se ne fa.

----------

## earcar

Non credevo di generare un flame, quindi chiarisco la mia "concisa" e scherzosa risposta (noto che non avete considerato il quote) che è stata evidentemente fraintesa.

Peach parlava di esigenze progettuali differenti, ad esempio come un widget può essere meglio di un'altro in una situazione o in un'altra, aspetti che molto spesso vegono messi da parte a causa di una specie di partitismo (gtk/qt ad esempio) che non può fare altro che generare altra ignoranza e tante altre "guerre di religione"...

Nel mio post volevo solo rafforzare questo concetto, dicendo che IMHO è bello avere vari widget (multipiattaforma tra l'altro) alla quale appoggiarsi dato che ognuno ha le sue peculiarità.

PS: aggiungo però che ogni caso va trattato in maniera differente, uno per tutti il campo audio dove esistono decine di implementazioni che fanno tutte più o meno la stessa cosa [arts, esd, openal, sdl, jack, alsa, oss, ecc (ordinati per caratteristiche)] dove basterebbe una soluzione alla macosx (coreaudio)

**earcar  :Wink: 

----------

## funkoolow

 *earcar wrote:*   

> Non credevo di generare un flame [...]

 

flame? è già un flame? a me non pare...

----------

## earcar

 *funkoolow wrote:*   

>  *earcar wrote:*   Non credevo di generare un flame [...] 
> 
> flame? è già un flame? a me non pare...

 

Ora lo è  :Laughing:   :Laughing: 

----------

## silian87

Non vorrei fare il pignolo... ma:

 *Quote:*   

>  [arts, esd, openal, sdl, jack, alsa, oss

 

oss: vecchia porzione di gestione dell'audio a LIVELLO KERNEL, rimpiazzata da alsa

alsa: nuova gestione dell'audio in kernelspace, ma con demoni userspace che gestisce un minimo di mixing audio

arts: quasi deprecato ed in via di estinzione da quando alsa ha il mixing integrato. Era nato quando c'era solo OSS.

esd: lo stesso discorso di arts... peccato che lo si usi ancora

jack: demone audio nato per gestire molti altri sotto sistemi, ma utile sopratutto per l'audio professionale

sdl: mm so poco (se non che anche lui usa sotto sistemi)

gstreamer: un po' come l'amico jack ,ma piu' general purpose

Dopo questi chiarimenti si puo' vedere come il numero delle robe duplicate ancora attive sia in diminuzione.

In ogni caso e' vero. Molte cose vengono rifatte piu' volte "per il cavolo".

Gli standard sono molto importanti, e' per fortuna c'e' tanta buona gente che scrive dei simpatici wrapper che ci aiutano a risolvere in parte questi problemi  :Very Happy: 

----------

## gutter

 *silian87 wrote:*   

> 
> 
> Gli standard sono molto importanti, e' per fortuna c'e' tanta buona gente che scrive dei simpatici wrapper che ci aiutano a risolvere in parte questi problemi 

 

Per caso questa è una velata pubblicità al tuo wrapper   :Question:   :Wink: 

----------

## earcar

Dobbiamo fare i pignoli? Ok...  :Smile: 

 *silian87 wrote:*   

> oss: vecchia porzione di gestione dell'audio a LIVELLO KERNEL, rimpiazzata da alsa

 

oss anche se deprecato è tutt'ora utilizzato in molte applicazioni e in particolare in quelle proprietarie che lo ritengono uno standard ormai totalmente affidabile e consolidato. (primo fra tutti enemy territory)

 *silian87 wrote:*   

> alsa: nuova gestione dell'audio in kernelspace, ma con demoni userspace che gestisce un minimo di mixing audio

 

alsa non è una gestione dell'audio, ma un insieme di api e drivers (stessa cosa per oss). Non ha assolutamente demoni userspace, ma può essere compilato come modulare e caricato come qualunque altro modulo del kernel. Il mixing audio viene effettuato nei driver stessi

 *silian87 wrote:*   

> arts: quasi deprecato ed in via di estinzione da quando alsa ha il mixing integrato. Era nato quando c'era solo OSS.
> 
> esd: lo stesso discorso di arts... peccato che lo si usi ancora

 

Di questi due server audio non so pressoché nulla  :Wink: 

Forse perché li odio  :Very Happy: 

 *silian87 wrote:*   

> jack: demone audio nato per gestire molti altri sotto sistemi, ma utile sopratutto per l'audio professionale

 

Jack è un buon server audio a bassa latenza (non necessariamente). In quanto server audio mi sembra piuttosto normale il fatto che diriga l'output a oss o alsa... È ottimo per il fatto che da la possibilità di collegare virtualmente varie applicazioni come se fossero un rack di effetti o quant'altro (è riduttivo però rende l'idea)

 *silian87 wrote:*   

> sdl: mm so poco (se non che anche lui usa sotto sistemi)

 

Simple Directmedia Layer è una libreria multipiattaforma per avere accesso all'audio, al video e all'input ed è stato sviluppato espressamente per giochi e applicazioni multimediali.

openal è anch'essa una libreria multipiattaforma specializzata in audio.

 *silian87 wrote:*   

> gstreamer: un po' come l'amico jack ,ma piu' general purpose

 

Anche gstreamer è una libreria (non un server audio!! quindi gstreamer != jack) per l'accesso alle risorse multimediali del sistema ed ha un'architettura a plugin che gli permettono di fare un'infinità di cose (`emerge -s gst-plugins` provare per credere)

 *silian87 wrote:*   

> si puo' vedere come il numero delle robe duplicate ancora attive sia in diminuzione.

 

Mi dispiace ma tutto ciò che ho detto prima è ancora in uso, compreso oss (non come driver)  :Rolling Eyes: 

 *silian87 wrote:*   

> Gli standard sono molto importanti, e' per fortuna c'e' tanta buona gente che scrive dei simpatici wrapper che ci aiutano a risolvere in parte questi problemi 

 

Io più che scrivere "simpatici wrapper" (che invece odio) farei cose serie con alsa prendendo esempio come dicevo prima da coreaudio

**earcar  :Wink: 

----------

## =DvD=

Io penso che non se ne esca.

Seguendo l'esempio del post precedente:

Da un lato si può imporre alsa per avere uno standard unico.

Dall'altro sarebbe una imposizione!

----------

## silian87

Uffa che cattiveria... earcar mi ha distrutto   :Crying or Very sad: 

 *Quote:*   

> Per caso questa è una velata pubblicità al tuo wrapper  

 

No, anche se amo i wrapper e vorrei scriverne molti  :Very Happy: 

----------

## earcar

 *silian87 wrote:*   

> Uffa che cattiveria... earcar mi ha distrutto   

 

È stato solo un ragionamento del tipo [ -> essere pignolo = puntualizzare -> puntualizzare = sapere | informazioni sbagliate -> sapere -> essere pignolo ]  :Laughing: 

Più che cattiveria la definirei correttezza, se puntualizzo una cosa è perché conosco l'argomento, tutto qui.  :Rolling Eyes: 

Comunque dai su non te la prendere  :Wink: 

EDIT: sono d'accordo con =DvD= però (almeno in campo audio dove c'è questo casino e non esistono scuole di pensiero contrastanti alla gtk/qt) prima o poi bisognerà uscirne. Non dico un'api unica linux, ma un paio (driver "normali" e a bassa latenza come esistono su piattaforma m$) penso che bastino, o no?

----------

## CarloJekko

 *earcar wrote:*   

> oss anche se deprecato è tutt'ora utilizzato in molte applicazioni e in particolare in quelle proprietarie che lo ritengono uno standard ormai totalmente affidabile e consolidato. (primo fra tutti enemy territory)
> 
> 

 

questo è vero... c'è anche questo simpatico topic https://forums.gentoo.org/viewtopic-t-221779.html

----------

## SilverXXX

L'unificazione è impossibile (e dmix se non ricordo male mi pareva permettesse solo di accedere alle voci hw simultanee, ma non ci giurerei)

----------

## thewally

IMHO gli standard sono una buona cosa, mantenendo ben saldi due punti:

1) Lo standard deve essere deciso democraticamente da tutti (lo so che è un'utopia).

2) Si deve fare in modo che gli standard non si contrastino l'uno con l'altro (come alcune leggi italiane   :Rolling Eyes:  ).

----------

## gutter

 *thewally wrote:*   

> IMHO gli standard sono una buona cosa

 

Concordo con il fatto che gli standard siano un buon mezzo per la cooperazione tra entità diverse e permettano la nascità di strumenti che in genere possono interoperare tra di loro senza problemi. 

Comunque credo che in generale non siano una panacea. Capita che uno standard fossilizzi l'ambito cui viene applicato dal momento che spesso frena lo sviluppo di soluzione alternative.

Mi permetto di sottolineare che sono a favore degli standard; ci tenevo solo a sottolineare il punto precedente   :Wink: 

----------

## CarloJekko

 *gutter wrote:*   

> Comunque credo che in generale non siano una panacea. Capita che uno standard fossilizzi l'ambito cui viene applicato dal momento che spesso frena lo sviluppo di soluzione alternative.
> 
> 

 

Bhè io aggiungerei : cfr IPv4 vs. IPv6 ...  

P.S. anche io sono a favore degli standard  :Wink: 

P.P.S. l'opzione si/no ma... significa che va specificata all'interno di questo thread perchè si o no ma... vedo che ci sono 11 si/no ma... senza altrettanti posts   :Rolling Eyes: 

----------

## thewally

 *gutter wrote:*   

> Comunque credo che in generale non siano una panacea. Capita che uno standard fossilizzi l'ambito cui viene applicato dal momento che spesso frena lo sviluppo di soluzione alternative.

 

Sono pienamente d'accordo anche su questo, bisognerebbe tenere costantemente aggiornati gli standard, visto che a volte si aprono nuove possibilità non contemplate alla stesura dello standard stesso. Riconosco, tuttavia, che questo sia un lavoro immane, che andrebbe messo in mano ad un'ente specifico.

 *CarloJekko wrote:*   

> P.P.S. l'opzione si/no ma... significa che va specificata all'interno di questo thread perchè si o no ma... vedo che ci sono 11 si/no ma... senza altrettanti posts 

 

La pigrizia colpisce ancora! eh ?!   :Laughing:   :Laughing: 

Se vi sta bene mi iscrivo come altri 3-4 utenti differenti, non voto, ma posto solamente, così colmiamo il vuoto   :Laughing:   :Laughing: 

----------

## jubushi

bho....io ho votato no perchè credo che questi standard tendano a rafforzare il codice rendendolo più solido e robusto.

----------

## federico

Io ho segnato che troppo standard rendono difficile lo sviluppo.

Il fatto che ci sia uno standard e' buono, il fatto che uno non sappia quale seguire, se ci sono piu' standard per la stessa cosa, e' male. Vengono a crearsi programmi che fanno simili cose, basati su standardi diversi, e cosi' gli sviluppatori si disperdono e gli utenti non ci capiscono un tubo.

Fe

----------

