# Linux x86 non é come Linux PPC in fatto di software...

## Detronizator

Non tutto il software infatti é "doppiamente portato": un esempio?

Unreal Tournament 2004 non lo si vedrà per Linux PPC => Devo usarlo su Mac => ... mi spiace veramente.

Approposito. Conoscete store SERI di software/games per MacOSX?

----------

## fedeliallalinea

 *Detronizator wrote:*   

> Non tutto il software infatti é "doppiamente portato": un esempio?
> 
> 

 

Beh ma questo e' abbastanza ovvio.

 *Detronizator wrote:*   

> Approposito. Conoscete store SERI di software/games per MacOSX?

 

Non andiamo troppo OT.

----------

## X-Drum

E' proprio questo il problema.

Quello dei PPC (nel tuo caso) è un'altro mondo, differente architettura,l'instruction set...Potenza (e che potenza)!!!!

la mia ragazza ha un Power MacG5 dual processor (2 bestie da 1800 mhz ciascuno a 64 bit!!!!!!!!, 1,5 gb di ram ecc....)

(io ma solo io!) ci installerei volentieri gentoo per il solo gusto di vedere schizzare le compilazioni a 400km/h 

Fino ad ora non avevo mai utilizzato una Macchina cosi' potente!

lavoglioooooooooooooooooooooooooooooo

----------

## Detronizator

 *fedeliallalinea wrote:*   

>  *Detronizator wrote:*   Non tutto il software infatti é "doppiamente portato": un esempio?
> 
>  
> 
> Beh ma questo e' abbastanza ovvio.
> ...

 

Mica tanto: in fondo ci sono un sacco di software OS che si compilano su x86 e non su PPC ed il problema é che...??? Cioé, i compilatori ci sono, il codice sorgente anche? A parte i casi in cui si sfruttano tutte le features di una determinata architettura (più raro) il codice dovrebbe essere compilabile ovunque (più ovvio). Invece tutto ciò non accade (più realistico).

Sarà che molti programmatori non sanno fare il proprio lavoro?  :Wink: 

E che i processori PPC, essendo maggiormente di nicchia di x86, sono "manovrati" in direzioni ancora più "protezioniste" dalle società di riferimento (vedi Apple, vedi IBM)?

La domanda che quindi mi porrei é: stò dominio incontrastato di Bill sull'x86 proprio non vogliamo farlo finire? Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)? E che, ancor meglio, se l'architettura di riferimento cambiasse inizierebbe una nuova era dell'informatica? x86 é OBSOLETA!!!

E lo scenario diventa ancora più desolante se si pensa ad Opteron e altre architettura a 64 bit, ancora basate sul set di istruzioni x86.

Per fare un parallelo (forse un pò azzardato) é la stessa storia della benzina: non si cercano REALMENTE alternative, perché c'é ancora tanto petrolio da sfruttare.

 *fedeliallalinea wrote:*   

> 
> 
>  *Detronizator wrote:*   Approposito. Conoscete store SERI di software/games per MacOSX? 
> 
> Non andiamo troppo OT.

 

Il problema é correlato secondo me: quanti negozi per software per PPC conoscete? Insomma: in qualsiasi store, se cerchi software, danno per scontato che lo cerchi per Windows e, se siamo proprio fortunati, Linux, ma sempre PPC. Per avere uno store completamente orientato a PPC? A parte il sito di Apple (che un pò ti "guida" a comprare quello che vendono solo loro) avete altre idee?

Si, lo so, forse é un post un pò polemico, ma la discussione é secondo me seria: non mi piace accettare le cose perché "così sono".

----------

## fedeliallalinea

 *Detronizator wrote:*   

> Mica tanto: in fondo ci sono un sacco di software OS che si compilano su x86 e non su PPC ed il problema é che...??? Cioé, i compilatori ci sono, il codice sorgente anche? A parte i casi in cui si sfruttano tutte le features di una determinata architettura (più raro) il codice dovrebbe essere compilabile ovunque (più ovvio). Invece tutto ciò non accade (più realistico).
> 
> Sarà che molti programmatori non sanno fare il proprio lavoro? 

 

Se fosse cosi' facile come dici non ci sarebbero tutti questi problemi.

 *Detronizator wrote:*   

> Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)?

 

E allora perche' apple non lo fa?

 *Detronizator wrote:*   

> La domanda che quindi mi porrei é: stò dominio incontrastato di Bill sull'x86 proprio non vogliamo farlo finire?E che, ancor meglio, se l'architettura di riferimento cambiasse inizierebbe una nuova era dell'informatica? x86 é OBSOLETA!!!

 

Si e' visto che fine ha fatto alpha... il fatto che intel sara' opsoleta ma costa poco e fa il suo lavoro... e poi in informatica dimmi che c'e' stato di cosi' innovativo negli ultimi 10 anni. Gli os piu' usati si basano tutti su tecnologie studiate 20 anni fa (UNIX e VMS).

----------

## X-Drum

secondo me stai tralasciando degli aspetti fondamentali

non puoi affermare :

 *Quote:*   

> Mica tanto: in fondo ci sono un sacco di software OS che si compilano su x86 e non su PPC ed il problema é che...??? Cioé, i compilatori ci sono, il codice sorgente anche? A parte i casi in cui si sfruttano tutte le features di una determinata architettura (più raro) il codice dovrebbe essere compilabile ovunque (più ovvio). Invece tutto ciò non accade (più realistico).
> 
> Sarà che molti programmatori non sanno fare il proprio lavoro?

 

effettuare il porting di un'applicazione da un SO ad un'altro o da un'architettura ad un'altra o anche entrambe le cose simultaneamente non è mica semplice!

bisogna anche vedere come è stata concepita l'applicazione in questione!

quello che intendo dire è: se non ti portano un'app sotto macosx non è mica colpa di "programmatori cattivi" o che so io....

purtoppo è anche questo che influenza i porting scond me non è mancaza di volontà!

hai visto comè fatto macOSX ad esempio? non è mica semplice lavorare ad un porting... eri ho provato il porting di mplayer per macosx, e devo dire che è un po lontano dalla versione per linux

----------

## Detronizator

 *fedeliallalinea wrote:*   

> 
> 
>  *Detronizator wrote:*   Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)? 
> 
> E allora perche' apple non lo fa?
> ...

 

Perché M$ paga perché ciò non accada...

 *fedeliallalinea wrote:*   

> 
> 
>  *Detronizator wrote:*   La domanda che quindi mi porrei é: stò dominio incontrastato di Bill sull'x86 proprio non vogliamo farlo finire?E che, ancor meglio, se l'architettura di riferimento cambiasse inizierebbe una nuova era dell'informatica? x86 é OBSOLETA!!! 
> 
> Si e' visto che fine ha fatto alpha... il fatto che intel sara' opsoleta ma costa poco e fa il suo lavoro... e poi in informatica dimmi che c'e' stato di cosi' innovativo negli ultimi 10 anni. Gli os piu' usati si basano tutti su tecnologie studiate 20 anni fa (UNIX e VMS).

 

Secondo me PPC é un esempio di questo cambiamento.

Indubbio che M$ ha saputo diventare dominatrice del suo mercato... ma presto tutto ciò é diventato monopolio.

----------

## pascalbrax

 *fedeliallalinea wrote:*   

> 
> 
>  *Detronizator wrote:*   Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)? 
> 
> E allora perche' apple non lo fa?
> ...

 

il progetto di portare darwin su x86 esiste gia' da tempo e pare sia stabile,

il progetto di portare TUTTO macosx su x86 era in allestimento ma e' stato insabbiato, dicono, per motivi contrattuali con la piccolasoffice.

aggiungo una mia piccola nota personale: ho seri dubbi che faccia realmente faville su x86... ricordiamoci dell'esperienza solaris.

----------

## fedeliallalinea

 *Detronizator wrote:*   

> Perché M$ paga perché ciò non accada...

 

E vuol dire che ad apple sta bene cosi' e non fa niente per cambiare....

 *fedeliallalinea wrote:*   

> Secondo me PPC é un esempio di questo cambiamento.

 

I ppc ci sono da anni e non hanno mai preso piede cosi' tanto.

 *fedeliallalinea wrote:*   

> Indubbio che M$ ha saputo diventare dominatrice del suo mercato... ma presto tutto ciò é diventato monopolio.

 

Si ma con dei giochi sporchi (es: window malfunzionate su DR-DOS).

----------

## Detronizator

 *X-Drum wrote:*   

> secondo me stai tralasciando degli aspetti fondamentali
> 
> non puoi affermare :
> 
>  *Quote:*   Mica tanto: in fondo ci sono un sacco di software OS che si compilano su x86 e non su PPC ed il problema é che...??? Cioé, i compilatori ci sono, il codice sorgente anche? A parte i casi in cui si sfruttano tutte le features di una determinata architettura (più raro) il codice dovrebbe essere compilabile ovunque (più ovvio). Invece tutto ciò non accade (più realistico).
> ...

 

Hai preso l'esempio di "caso particolare" a cui mi riferivo: con software per la "multimedialità" o il "calcolo massiccio" il problema é ovviamente sentitissimo, perché PPC, per esempio, non ha MMX o SSE2.

Ma il software é molto più che questo.

E del resto, se analiziamo MacOSX, si basa su Unix (Darwin infatti é OS) e lo stesso kernel sarebbe portabilissimo su x86.

Inoltre, quì possiamo anche prendere in considerazione un kernel già esistente: linux appunto.

E' sempre l'interesse delle società dietro un eventuale "espansione" verso nuove prospettive: il punto é che PPC é più che una buona prospettiva... perché non la si alimenta?

Ho una idea: convinciamo Apple a rilasciare Quartz. In una sola mossa Linux avrebbe il suo Desktop DEFINITIVO, faremmo piangere M$ tanto si troverebbe dietro e la battaglia per l'OS sarebbe più che vinta (si lo so, stò diventando esagerato... mi modero...).

Che gli costava alla Epic compilare UT2004 anche per Linux PPC?  :Sad: 

ps Non sono un utente PPC... ancora!  :Wink: 

----------

## Detronizator

 *pascalbrax wrote:*   

>  *fedeliallalinea wrote:*   
> 
>  *Detronizator wrote:*   Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)? 
> 
> E allora perche' apple non lo fa?
> ...

 

Solaris é per Server-Mainframe.

Quì si parla di un sistema in pieno scontro con l'XP di turno: e io dico che XP perde 20 a Zero!

Volete l'informatica semplice e senza intoppi (io no, ma chi non é informatico sì)? Passate a Mac.

Con pochi soldi in più, state tranquilli per tantissimo tempo (i pc x86 li devi costantemente aggiornare... Longhorn quanta memoria vorrà? 1GB andrà bene?)

----------

## pascalbrax

li scrivi tu i 45'000 driver per macosx per supportare l'hardware che supporta XP? (male, ma lo supporta)

----------

## X-Drum

Detronizator:

allora mettiamola cosi' sarà una questione di target:

La maggior parte degli utenti di Apple apprezza tali prodotti perche' particolarmente indicati e concepiti per usi quali: maniploazione di immagini,video/audio editing,anche 3d ultimamente, anche se noi (almeno io) vedo in quelle macchine un enorme potenziale (scusate la frase, ma quello spot ridicolo....) anche per altre applicazioni.

se Apple dota i PowerMac G5 di Nvidia FX lo fa perche' pensa ad elaborazioni grafiche(3d) , non ai giochi....

Secondo me quel target di utenti non gli interessa punto...

----------

## Detronizator

 *X-Drum wrote:*   

> Detronizator:
> 
> allora mettiamola cosi' sarà una questione di target:
> 
> La maggior parte degli utenti di Apple apprezza tali prodotti perche' particolarmente indicati e concepiti per usi quali: maniploazione di immagini,video/audio editing,anche 3d ultimamente, anche se noi (almeno io) vedo in quelle macchine un enorme potenziale (scusate la frase, ma quello spot ridicolo....) anche per altre applicazioni.
> ...

 

Io credo di no: basta osservare bene il sito di Apple e vedere che cmq cerca di mantenere il suo target ampio: dal bimbo che deve imparare, fare ricerche, giocare, al manager che deve gestire dati e contatti, al programmatore (Cocoa é na bomba), al grafico 2d, al pubblicitario, al grafico 3d.

Mi farò portatore del messaggio "pro PPC"!!!   :Very Happy: 

----------

## Detronizator

 *pascalbrax wrote:*   

> li scrivi tu i 45'000 driver per macosx per supportare l'hardware che supporta XP? (male, ma lo supporta)

 

ok!   :Cool: 

I driver se li scrivono le aziende, mica M$. Se MacOSX prende piede, tutte le aziende produrranno driver di qualità. Ed essendo un sistema UNIX Based, saranno anche parecchio meglio di quell'ammasso di DLL casinare che ci propinano.

Installo i driver del Mouse e la scheda di rete va a put***e! Ma si può mai sopportare? E poi M$ parla di potenziale... si, della potenzialità che c'é nel fatto che cresco e li riempio di calci!

W l'OS.

----------

## X-Drum

 *Detronizator wrote:*   

> 
> 
> Installo i driver del Mouse e la scheda di rete va a put***e! Ma si può mai sopportare? E poi M$ parla di potenziale... si, della potenzialità che c'é nel fatto che cresco e li riempio di calci!
> 
> 

 

ahahha  :Very Happy: 

su questo non posso fare altro che darti ragione!

anche per questo motivo sono brutalmente passato a linux da anni...

----------

## shev

Questo topic è una provocazione, vorrei ribattere punto punto ma cercherò di trattenermi, si rischia il flame classico da guerra di religione. Anche perchè sarei spudoratamente di parte  :Laughing: 

Imho solo entrando nel mondo mac si ha risposta a tutte le domande e dubbi che avete sollevato. Certe cose non si possono spiegare, bisogna viverle.

Dico solo, per tornare alla domanda iniziale, che di store per mac ne esistono diversi, italiani e non. Semplicemente non li si nota/conosce finchè non si ha un mac e se ne sente dunque il bisogno  :Smile: 

p.s.: come giustamente diceva fedeli si va troppo ot, quindi se serve qualche link chiedetemeli in pvt

/me che dopo aver usato seriamente un mac ha visto la luce ed ora sorride sentendo chi ancora inconsapevole si dibatte nell'ombra  :Twisted Evil: 

----------

## blackfede

Quoto precisamente le ultime righe di shew   :Very Happy: 

Per questo motivo ho in dirittura di arrivoil nuovo iBook   :Cool: 

Detronizator, tu per programmi che non si trovano per PPC intendi tutti quei sowtrware proprietari tipo i giochi, oppure tutti quei programmi opensource?  :Question: 

----------

## silian87

Vorrei approffittarne per fare una proposta. Mi sono accorto che molti programmi in portage senza la keyword ppc, funzionano benissimo su ppc. Perche' non segnalare agli sviluppatori che il loro pacchetto va anche su ppc? 

Secondo me spesso molti pacchetti non hanno ppc perche' nessuno li ha mai provati con quel tipo di hardware. Altri, tipo gambas, non vanno comunque; ma certi, tipo xbattbar, vanno benissimo.

 :Wink: 

----------

## iDarbert

 *fedeliallalinea wrote:*   

> 
> 
>  *Detronizator wrote:*   Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)? 
> 
> E allora perche' apple non lo fa?

 

Secondo un'articolo di MacWorld Spagna Jobs non vuole portare MacOS X alla piattaforma Intel semplicemente perchè "si trovano bene con IBM"   :Rolling Eyes: 

----------

## shev

 *silian87 wrote:*   

> Secondo me spesso molti pacchetti non hanno ppc perche' nessuno li ha mai provati con quel tipo di hardware. Altri, tipo gambas, non vanno comunque; ma certi, tipo xbattbar, vanno benissimo

 

Infatti sarebbe quello che va fatto  :Rolling Eyes: 

Non ricordo dove l'ho letto, ma la mancanza di flag per ppc ha proprio il senso da te indicato, quindi se qualcuno scopre pacchetti funzionanti su ppc ma che non hanno la flag relativa deve segnalarlo allo sviluppatore.

----------

## emix

 *fedeliallalinea wrote:*   

>  *Detronizator wrote:*   Perché M$ paga perché ciò non accada... 
> 
> E vuol dire che ad apple sta bene cosi' e non fa niente per cambiare....

 

Certo che ad Apple sta bene così... così continueranno a vendere sia hardware che software. La Apple è una delle poche aziende informatiche che hanno chiuso l'ultimo bilancio in attivo... e questo non grazie alle vendite di MacOS, ma a quelle degli iPod e dei *book. 

Inoltre sviluppare un s.o. per una architettura non proprio chiusa, ma comunque controllata, è un gran vantaggio.

----------

## emix

 *Shev wrote:*   

> /me che dopo aver usato seriamente un mac ha visto la luce ed ora sorride sentendo chi ancora inconsapevole si dibatte nell'ombra 

 

Sottoscrivo in pieno  :Wink: 

----------

## fedeliallalinea

 *emi wrote:*   

> Certo che ad Apple sta bene così... così continueranno a vendere sia hardware che software. La Apple è una delle poche aziende informatiche che hanno chiuso l'ultimo bilancio in attivo... e questo non grazie alle vendite di MacOS, ma a quelle degli iPod e dei *book. 

 

Questo lo se era per rispondere alla domanda di Detronizator "Ma ci si rende conto che MacOSX su x86 farebbe faville (altro che Longhorn)?"

----------

## silian87

Apple si tiene la sua fetta di mercato stabile. Non aumenta e cerca di inglobare tutti, non diminuisce, ma sta' tranquilla con i suoi clienti.

Anche questa e' una tecnica di mercato.

----------

## blackfede

 *emi wrote:*   

> 
> 
> Inoltre sviluppare un s.o. per una architettura non proprio chiusa, ma comunque controllata, è un gran vantaggio.

 

Altrochè se è un vantaggio!! E' uno dei motivi per cui apple (imho) riesce a produrre sofware così valido. Sa perfettamente che tipo di chipset, memorie, processore, ecc sarà utilizzato per far girare il suo SW!!   :Smile: 

----------

## doom.it

A parte che darwin per x86 c'è, e netbsd ha un layer di compatibilità binaria con mac os X. Credete veramente che apple non abbia gia in mano un mac os X che gira su x86??? stolti.

C'è una ragione per cui non rilacia mac os X per x86.... fallirebbe.... qualcuno si ricorda i Mac-Clones? hanno portato al fallimento apple una volta, e la riporterebbero ancora, visto che apple crea profitto sull'hardware, che viene trascinato anche dalla validità del software che l'accompagna.

La visione di Jobs è di un "digital hub" cioe il computer come fusione di hardware e software di qualità che interagisca bene, e crei un esperienza di utilizzo che, come diceva shev, va oltre la qualità di un software o di un hardware, sia uno stile di vita...( che poi piaccia o no ma è il concetto verso il quale vanno le corporation nel mndo del branding per fare profitti )

Morale regalare il software al mondo x86 se anche gli desse un po di soldi dalle vendite dirette, distruggerebbe il branding e l'esperienza di utilizzo integrata. Aumentare le quote di mercato è un obiettivo che a jobs non interessa (a mio avviso giustamente) gli interessa avere una base di utenti fedeli, ed essere l'unico a vendere hardware e software di tale qualità nel complesso.

----------

## silian87

Ricordiamoci che Macosx funziona cosi' bene anche perche' e' progettato apposta per "girare" su hardware di cui si conosce ogni cosa. Non deve andare su moltissimi computer diversi... 

Credo che su X86 non sarebbe un granche'.

 *Quote:*   

> stolti.

 

 :Laughing:   hehehe devo offendermi?   :Laughing: 

----------

## Cerberos86

Quoto doom.it.

Secondo me apple si sta "accontentando" degli utenti che ha già...e arrotondando con gli ipod!!!

Tanto per fondare un po' quello che dico:

ho letto decine di post con pc users "convertiti" alla casa di cupertino e che (almeno per i prossimi 10 anni) NON TORNERANNO INDIETRO.

Apple vivrà sugli acquisti che questi (e i veterani) utenti faranno sia in HW che SW. Creare una distrubuzione mac Os X per x86 andrebbe a distruggere questa logica di macchina perfetta che CREA DIPENDENZA. Ogni giorno leggo flame di amanti del PC che vogliono sotterrare di infamia i g5 in quanto a potenza di calcolo. Forse è vero, ma se qualcuno sceglie mac è per cambiare il modo di fare informatica. Il mio primo mac (ibook 12" 1ghz) dovrebbe arrivare in settimana e spero, come dice shev, di vedere la luce....

----------

## emix

 *Cerberos86 wrote:*   

> Il mio primo mac (ibook 12" 1ghz) dovrebbe arrivare in settimana e spero, come dice shev, di vedere la luce....

 

Gran bella macchina... Peccato che ho già comprato l'ibook a dicembre  :Rolling Eyes: 

----------

## shev

 *doom.it wrote:*   

> La visione di Jobs [...] crei un esperienza di utilizzo che, come diceva shev, va oltre la qualità di un software o di un hardware, sia uno stile di vita...

 

Quoto questa frase perchè imho riassume benissimo le risposte a diverse domande che ho letto in questo topic: lo stile apple ammirato e imitato ovunque è dovuto in gran parte proprio a tutti quelli che i più ritengono difetti o errate scelte strategiche. Avere un bacino di utenti limitato ma fedele ed entusiasta, pieno controllo sull'hardware e di conseguenza sull'aspetto estetico e sulla qualità delle macchine e così via permette ad apple di mantenere inalterati i propri tratti distintivi, il proprio fascino. Permette ad apple di continuare ad essere apple. 

Io approvo in toto questa visione, non vedo perchè si debba necessariamente avere il controllo dell'intero mercato. A me piace far parte di un elite spocchiosa, alternativa e "fighetta"   :Mr. Green: 

Anche perchè il mercato non sembra dar torto al diabolico Jobs  :Smile: 

----------

## Cerberos86

```
Chi troppo vuole nulla stringe...(a parte m$)
```

Penso che se apple si buttasse alla disperata ricerca di conquistare il mercato con mac os x su x86 o hw menu curato per una maggiore economicità....beh, rischierebbe solo un FLOP     :Rolling Eyes: 

Se ci riuscisse.... beh, fanta-informatica  :Shocked: 

----------

## Detronizator

...con i soldi che cmq ha apple... e col fatto che si basa su una architettura Unix... potrebbe trarre giovamento da Linux stesso... offrendo quindi una "fascia di hardware supportato" in continua espansione...

Secondo voi é una idea così pazza?

----------

## shev

 *Detronizator wrote:*   

> Secondo voi é una idea così pazza?

 

Se avessi capito cosa intendi risponderei  :Razz: 

Se intendevi parlare di apple che si apre all'architettura x86 la risposta (mia) è: si, è assolutamente folle. I motivi sono scritti nel mio precedente post e quello di doom che ho quotato.

----------

## Detronizator

 *Shev wrote:*   

>  *Detronizator wrote:*   Secondo voi é una idea così pazza? 
> 
> Se avessi capito cosa intendi risponderei 
> 
> Se intendevi parlare di apple che si apre all'architettura x86 la risposta (mia) è: si, è assolutamente folle. I motivi sono scritti nel mio precedente post e quello di doom che ho quotato.

 

No, il discorso era un pò più "tecnico": dato che Darwin é OS ed é, a tutti gli effetti, UNIX, per quanto riguarda la "compatibilità hardware limitata", il problema si risolverebbe sfruttando la comunità dietro il Kernel.

Apple avrebbe a disposizione una MANOVALANZA ENORME!

Capisci?

----------

## fedeliallalinea

 *Detronizator wrote:*   

> No, il discorso era un pò più "tecnico": dato che Darwin é OS ed é, a tutti gli effetti, UNIX, per quanto riguarda la "compatibilità hardware limitata", il problema si risolverebbe sfruttando la comunità dietro il Kernel.
> 
> Apple avrebbe a disposizione una MANOVALANZA ENORME!
> 
> Capisci?

 

Ho capito pero' cosi' facendo non avrebbe il controllo lei. Poi visto che l'hardware che deve sopportare e' ristretto i driver sono di qualita' mentre su x86 non tutto funziona a dovere.

----------

## Detronizator

 *fedeliallalinea wrote:*   

>  *Detronizator wrote:*   No, il discorso era un pò più "tecnico": dato che Darwin é OS ed é, a tutti gli effetti, UNIX, per quanto riguarda la "compatibilità hardware limitata", il problema si risolverebbe sfruttando la comunità dietro il Kernel.
> 
> Apple avrebbe a disposizione una MANOVALANZA ENORME!
> 
> Capisci? 
> ...

 

Abbé, ho capito. Ci dobbiamo sopportare zio bill sino alla morte...   :Crying or Very sad: 

----------

## xdarma

se intendevi dire che l'unione kernel linux + interfaccia grafica mac avrebbe generato il paradiso in terra...

1) sono d'accordo con te  :-D

2) forse e' quello che pensava Torvalds quando nel suo libro-biografia ha criticato pesantemente il kernel di Mac OSX

xdarma

----------

## Detronizator

 *xdarma wrote:*   

> se intendevi dire che l'unione kernel linux + interfaccia grafica mac avrebbe generato il paradiso in terra...
> 
> 1) sono d'accordo con te  
> 
> 2) forse e' quello che pensava Torvalds quando nel suo libro-biografia ha criticato pesantemente il kernel di Mac OSX
> ...

 

Si, anche se mi ero più posto come "integrare linux in macos".

Il contrario sarebbe fantastico: magari quartz extreme dentro il kernel. Altro che XFree...

----------

## Cerberos86

 *Detronizator wrote:*   

> Secondo voi é una idea così pazza?

 

Si, davvero pazza...

Ricordiamoci che apple vende soprattutto HARDWARE....

Immagina di poter avere un S.O. dalle potenzialità di Mac Os X, gratuito o persino sotto licenza GNU/GPL, che funziona bene sotto la tua ultima macchina x86 apena comprata... Andresti a regalare $ alla apple?

Certo, chi ha vissuto fino ad adesso con 1 PBook è difficile che cambi, ma immagina tutti i nuovi potenziali acquirenti...che se ne vanno!!!   :Laughing: 

----------

## akiross

Scusate per questa mia interruzione nel discorso, ma ora che ho preso l'iBook mi sento chiamato in causa  :Very Happy: 

Vorrei ricordarvi che C naque per non avere problemi nel porting dell'hardware. Non per niente Unix (che e' il vero motivo della nascita del C), ha una piccola interfaccia con l'hardware in assemby e il resto e' in C.

Detto questo tiratene fuori le conclusioni, ma io sostengo che:

1. MacOSX dovrebbe andare anche su x86. Se non ci va diamo la colpa a M$ e a office (e ai suoi traffici piu' o meno leciti). Secondo me Apple non sta bene cosi', puntava all'x86, ma M$ l'ha bloccata visto che Office lo fa solo la micrashoft, ed e' attualmente usato da molti utenti apple (quindi non si puo' rinunciare ad una fetta cosi' grossa)

2. Un programma fatto in C, che non usa ASM o routine di basso livello (ma si appoggia, chesso', alle SDL) e non va su un PPC mentre su un x86 si, mi sa tanto di contraddizione, o di programmatore un po' incapace (o incoscente. Il C dovrebbe essere sinonimo si portabilita', ma ci si dimentica di questo).

Magari avevo altro da dire... ma sono le 3.50 del mattino, e ho appena fatto una vaccata sull'ibook (ho fatto ripartire il bootstrap da 0!!!)

Ciao  :Very Happy: 

----------

## Detronizator

 *akiross wrote:*   

> Scusate per questa mia interruzione nel discorso, ma ora che ho preso l'iBook mi sento chiamato in causa 
> 
> Vorrei ricordarvi che C naque per non avere problemi nel porting dell'hardware. Non per niente Unix (che e' il vero motivo della nascita del C), ha una piccola interfaccia con l'hardware in assemby e il resto e' in C.
> 
> Detto questo tiratene fuori le conclusioni, ma io sostengo che:
> ...

 

Dimentichi un pò di cose:

1) non tutto é scritto in C (C++, Java, C#, VB...)

2) TUTTE LE SOCIETà di software si scrivono tantissime librerie sfruttando l'hardware sottostante per avere il massimo delle prestazioni

3) Non tutti i software sono portabili: le API/System Call dei sistemi non sono quasi mai "uguali" (anzi, mai) => a meno che non si vogliano riscrivere anche quelle daccapo...

4) spesso alcune cose scritte per x86 non funzionano su ppc, non perché il programmatore é idiota, ma perché il compilatore fa cose su alcune architetture che su altre non può.

----------

## n3m0

 *Detronizator wrote:*   

> 3) Non tutti i software sono portabili: le API/System Call dei sistemi non sono quasi mai "uguali" (anzi, mai) => a meno che non si vogliano riscrivere anche quelle daccapo...
> 
> 

 

Standard Posix non ti suona nuovo vero?

E ormai quale OS non è Posix Compliant?

MacOSX fornisce system call Posix, Linux, System V.

E ti diro' di piu', anche Windows supporta lo standard Posix, e mi sa che, a tutt'oggi, lo supporti pure al 100%.   :Wink: 

 *Detronizator wrote:*   

> 
> 
> 1) non tutto é scritto in C (C++, Java, C#, VB...)
> 
> 

 

C++ è standard ANSI, quindi se non ti metti ad usare le MFC et similia, è portabilissimo

Java, è in teoria portabile, ma la questione della JDK per Linux-PPC è tragica. Fortuna che Juergen di Blackdown ha detto che stanno lavorando alla 1.5 (aka Java 5) per Linux PPC (e altre arch).

C#, hai Mono, e, WinForms a parte, dovresti essere parato, ma tanto difficilmente avrai l'esigenza di usare un programma scritto per Win con VS .NET e framework MS. Se sto programma sarà sviluppato con l'intento di essere davvero x-platform, lo sarà.

VB...ma non stavi parlando di linguaggi di programmazione? in VB fino al 6 non ci potevi scrivere di piu' che quattro stupidate con Access, Con VB.NET, come ben sai, è come programmare in uno degli altri linguaggi della suite .NET: sempre in bytecode .NET vengono compilati e sempre le stesse librerie usano.

----------

## Detronizator

 *n3m0 wrote:*   

>  *Detronizator wrote:*   3) Non tutti i software sono portabili: le API/System Call dei sistemi non sono quasi mai "uguali" (anzi, mai) => a meno che non si vogliano riscrivere anche quelle daccapo...
> 
>  
> 
> Standard Posix non ti suona nuovo vero?
> ...

 

Certo che non mi suona nuovo... ma Windows standard Posix a 100%...  :Question: 

Devo vederlo per crederci.

Di MacOSX lo sapevamo già: é un BSD!!!

E come la metti in fatto di API? Come pensi di  usare DirectX sotto MacOSX? O Linux? (e non dire WineX che vengo fino a Villaricca per picchiarti).

La portabilità "teorica" c'é quasi sempre... solo che nella pratica risulta assurdo anche solo lontanamente pensarle certe cose: moltiplica tutto per 100000 se parli di software Windows. Lì devi cominciare dalla base a salire.

Ripeto: dimentica Wine che se vogliamo fare "porting" introducendo dei Layer di compatibilità stiamo freschi.

 *Nemo wrote:*   

> 
> 
>  *Detronizator wrote:*   
> 
> 1) non tutto é scritto in C (C++, Java, C#, VB...)
> ...

 

Scimità, certo che sono tutti linguaggi portabili. Ma poi, andavo ad indicare tra linguaggi "non portabili" Java, C# e compagnia bella?

Era perché akiross aveva parlato di C come se fosse l'unico linguaggi in cui si programma... quando ormai stà sempre più diventando un "linguaggio dedicato" (questo discorso non lo approfondiamo se no ci picchiano perché finiamo OT).

----------

## n3m0

 *Detronizator wrote:*   

> 
> 
> Certo che non mi suona nuovo... ma Windows standard Posix a 100%... 
> 
> Devo vederlo per crederci.
> ...

 

Il supporto POSIX è iniziato in NT4, con il process-handling e il layer di networking.

Ora dovrebbe essere concluso.

 *Detronizator wrote:*   

> 
> 
> E come la metti in fatto di API? Come pensi di  usare DirectX sotto MacOSX? O Linux? 
> 
> 

 

Quando parli di portabilta' e' ovvio che devi parlare di standard.

Non ha senso parlare di un'applicazione DirectX portabile se poi DirectX è proprietario e implementato solo su Win.

Ha senso invece parlare di portabilita' di un applicazione OpenGL.

 *Detronizator wrote:*   

> 
> 
> moltiplica tutto per 100000 se parli di software Windows. 
> 
> 

 

Il software Windows difficile da portare e' quello legato al sistema, e, verosimilmente, se legato così tanto al sistema, non ha una motivazione intrinseca per essere portato, poichè probabilmente pensato per cose specifiche di quella piattaforma.

Se invece il software Windows è potenzialmente portabile, ma agli atti pratici non lo è affatto, allora sono varie ipotesi: 

1. Programmatori/Aziende di 50 lire, che potendo fare la stessa cosa con gli standard e senza, la fanno senza, perche' nemmeno sanno cos'e' uno standard.

2. Scelta commerciale (volonta' a rendere NON portabile il software)

3. Disinteresse al porting da parte della societa'.

----------

## Detronizator

 *n3m0 wrote:*   

>  *Detronizator wrote:*   
> 
> Certo che non mi suona nuovo... ma Windows standard Posix a 100%... 
> 
> Devo vederlo per crederci.
> ...

 

Ripeto: devo vedere per credere.... e non ci credo!

 *Quote:*   

> 
> 
>  *Detronizator wrote:*   
> 
> E come la metti in fatto di API? Come pensi di  usare DirectX sotto MacOSX? O Linux? 
> ...

 

Ma ti sei fumato il cartone della CPU stamattina? Ma ti pare che M$ sviluppi "standard"? E con essa TUTTE le società che sviluppano per M$/Winsozz?

A me pare PROPRIO DI NO!

 *Quote:*   

> 
> 
>  *Detronizator wrote:*   
> 
> moltiplica tutto per 100000 se parli di software Windows. 
> ...

 

Ma ti rendi conto che é "quasi tutto così" il software che gira su Winsozz?

E che in quel sistema PRIMA vengono le scelte commerciali, POI il Software.

Io non parlo di software come un EMule di cui addirittura hanno fatto il porting.

Io parlo di "software grande", di "suite" di roba come Office, McAfee Suite, Norton Anti-Tutto ecc... quella roba che usa un utente medio.

Nemo, ma mi stai sfottendo vero?   :Evil or Very Mad: 

----------

## akiross

A parte il fatto che windoze lo esludo a priori dal discorso, e' un mondo a se.

Qui si parlava di x86 e ppc (e con Linux su entrambi), con windows sappiamo com'e' la solfa.

Io sto solo dicendo che se un programma e' fatto con criterio, dovrebbe essere assolutamente portabile su 2 linux con architetture diverse. Mi spiego: se faccio KDE e GTK portabili, le funzioni di interfaccia saranno le stesse sia su un PPC che un x86. Se non lo sono allora non vale la pena di usare KDE e GTK... se magari c'e' qualche funzione per feature speciali e' un conto, ma a meno di questo l'applicazione dovrebbe essere portabile.

Comunque vi faccio anche presente che nel mondo OpenSource la maggior parte delle applicazioni (e soprattutto librerie) e' fatta per essere portabile. Lo stesso Unix (Linux) sono fatti per questo, quindi se un programma non compila su ppc mentre su x86 si, non e' fatto molto bene (a meno che, come al solito, non usi caratteristiche proprie dell'architettura, ma si dovrebbero evitare nella maggior parte dei casi), quindi le applicazioni OpenSource dovrebbero essere solitamente portabili.

EDIT:

Io parlo di C perche' e' attualmente il linguaggio piu' usato nel mondo Linux e OpenSource. So bene che non e' l'unico, e so bene che non deve essere l'unico. Ritengo comunque che C non debba essere un linguaggio dedicato. Il fatto che sia versatile lo rende ottimo anche per questo scopo, ma non si deve assolutamente dimenticare che C ha una natura portabile. Quindi (personalmente, come programmatore) disprezzo chi dice "Eh no, Python e' piu' portabile di C", perche' e' una fesseria: se il programmatore non e' da 50 lire  :Smile:  C fa tutto (o quasi), ed e' portabilissimo.

EDIT2:

Inoltre vorrei farvi riflettere su una cosa (io ho dubbi, quindi chiedo a voi). Se prendete una libreria come SDL, questa va su piattaforme diverse (BSD, Linux, ecc ecc), ma non e' specificato il processore, quindi mi viene questo dubbio: e' perche' se lo compilo su PPC funziona, o e' solo per x86? O va su tutte le architetture? 

Secondo voi?

----------

## max_1975

Portabilità e prestazioni non sempre sono compatibili...dipende dalla scelta progettuale del programma

Alcuni programmi non funzionano addirittura sulla stessa architettura (ovvero funzionano solo su uno specifico processore), figuriamoci su architetture diverse. 

Dico questo per esperienza personale, infatti sto sviluppando una libreria per il calcolo in C++ (ANSI) utilizzando le MKL di Intel, invece della Standard Library per questioni di performance...su x86 (Intel) e su ia64 il programma funziona ed è una scheggia, su x86 (AMD) non funziona...nel mio caso rendere portabile il programma è un'utopia (a meno che non disponga dell'analogo delle MKL per gli altri processori)  :Sad: 

----------

## akiross

Ecco, questo programma puo' essere un esempio: perche' non creare delle funzioni "generiche" da implementare per ogni architettura?

Voglio dire: creiamo delle interfacce generiche, che fanno cio' che ci serve, e poi le adattiamo per ogni architettura.

Io la faccio un po' semplice, visto che la prima cosa che faccio prima di creare un programma e' vedere se le sue librerie sono partabili, e non ho mai fatto cose (a parte ASM puro per scuola) dipendenti strettamente dall'architettura.

Pero' secondo me si dovrebbe stare piu' attenti a queste cose... magari un po' di sbatti in piu', ma se si vuole adattare il programma si fa (spero) meno fatica.

----------

## silian87

Intendi dire che facciamo un set di funzioni che dovrebbero fare le stesse operazioni ovunque cosi che il programma si deva solo interfacciare con esse e siano SOLO esse a pensare alla comunicazione con l'HW? Penso che w' quello che stanno cercando di fare, ma solo per il fatto che linux nasce su x86 e che per le altre architetture risulta solo e sempre un port e' impossibile che non si verifichino problemi di compatibilita'...

----------

## max_1975

 *Quote:*   

> Ecco, questo programma puo' essere un esempio: perche' non creare delle funzioni "generiche" da implementare per ogni architettura?
> 
> 

 

Avevo iniziato con una versione portabile (senza utilizzare le MKL), ma a discapito delle prestazioni (anche un fattore 10, in certi casi), per il semplice motivo che durante certe applicazioni (per esempio la moltiplicazione tra matrici), le MKL sfruttano pesantemente la cache invece della normale (e più lenta) RAM...

Proprio per questo fatto (ovvero la gestione della cache, che dipende dal processore) il programma è più veloce ma non portabile

----------

## akiross

Finalmente ho messo su gentoo sul PPC (installato 2 volte, e ora per colpa di MacOSX (!!#@!$$@ò_é) preferisco rifarlo ancora)

Mi e' crollato il mondo addosso quando GRUB mi ha detto: CPU non supportata  :Sad:  Poi ho visto yaboot  :Very Happy: 

Comunque, non dico di rinunciare alle performance, e' che io farei qualcosa del genere:

ci si aspetta che due architetture anche se diverse, possano avere funzioni simili, e se proprio non ne hanno, ce le implementiamo noi con metodi meno performanti.

Ora ne sparo una grossa  :Smile:  ma e' solo per fare un esempio:

il programma usa su Intel le MLK (che non ho la bencheminima idea di come possano funzionare), allora facciamo cosi':

```

int Mult_Matrix_generica(Matrix m1, Matix m2)

{

#ifdef __Intel__

MLK_Moltiplica_Matrici(m1, m2);

#elif __PPC__ // sempre che sia giusto

int a, b, c; // immaginiamo di dovere adattare la situazione

PPC_Moltiplica(m1, m2, a = b, c);

#elif __SPARC__

Moltiplica_Normale_RAM(m1, m2);

#endif

}

```

In questo modo la funzione per la moltiplica e' una sola: Mult_Matrix_generica() utilizzabile su 3 architetture. Si, e' assurdo  :Smile:  ma potrebbe essere una soluzione. Anche se a questo punto sarebbe pero' necessario definire strutture dati e metodi per la manipolazione degli stessi completamente indipendenti dalla struttura, adattandoli come sopra.

Ho chiarificato un po' le mie idee? Un meccanismo smile l'ho sempre applicato nelle mie app Linux/Win, non credo (dal basso della mia immensa ignoranza) che sia impossibile con architetture diverse, o mi sbaglio?

Ciao!

EDIT:

Ops, era MKL  :Very Happy:  MLK e' Martin Luther King   :Embarassed:  L'importante e' il concetto   :Wink: 

----------

## max_1975

Secondo me sarebbe più comodo avere direttamente le librerie (a basso livello) implementate per le diverse architetture ma con le stesse identiche funzioni...in modo da dover scrivere una sola interfaccia indipendente dal sistema...poi sarebbe compito del makefile linkare le librerie giuste in base all'architettura...tra l'altro le MKL sono praticamente un'implementazione particolare per processori Intel delle BLAS e delle LAPACK, utilizzando per le funzioni gli stessi nomi e gli stessi argomenti...

----------

