Adobe Photoshop con supporto ad Apple Silicon è disponibile in beta

in perdita no di certo, ma guadagnerebbero meno..il problema è andare a spiegarle ai reparti marketing queste cose.

l'unica soluzione è la creazione di tool di sviluppo che facilitino la creazione di software multipiattaforma.

una volta c'era java, oggi cosa c'è?

forse l'unica che sta spingendo (non ufficialmente) è apple, con swift, che supporta mac, windows e linux. (ma qua ammetto la mia ignoranza, quindi correggetemi pure)

ma anche fosse, come base di partenza è davvero molto molto poca.

Non saprei proprio rispondere.. posso solo dire che ci spero. Magari un giorno Adobe o altri si decideranno.

Per la questione java.. mah.. è vero chè per chi produce software è molto comodo ma è altrettanto vero che avere java di mezzo (o similare) ammazza le performance in modo importante.

Insomma.. se devi fare un tool del cacchio va bene.. ma se si parla si software di una certa importanza non è pensabile che viaggino al 75% o meno della potenza perchè devono stare in piedi su java o chi per esso.

Tutto questo sempre a intuito perchè ribadisco, non so niente di programmazione.

esattamente, per questo non è una tematica di facile soluzione

demon77, dipende da tantissimi fattori.

per il porting oggigiorno dipende molto dal target che il codice ha.
c'è codice fatto per essere multi-os, multi-arch e scritto velocemente (es. il client di spotify usa chrome embedded. electron e binding dotnet. è quasi una webapp), ed altro codice fatto per essere leggero ad alte prestazioni (i render engine di firefox e chromium sono scritti rispettivamente in rust e C++, ottimizzati per OS e per architettura. idem gli engine 3D dei videogiochi. lavori titanici)

in generale, nel 2020 portare da win a linux a pari arch è più dispendioso che non portare da x86 ad arm a pari OS. pensa alle app del ms store, andare su x86 o arm per loro è indifferente perché ci pensa MS a tenere allineate le librerie di riferimento. o le app android/intel android/arm, stessa cosa.
trent'anni fa era senz'altro l'opposto, oggi ogni software ed ogni framework di sviluppo usa le peculiarità del SO target o del runtime target e le funzionalità da esso offerte a piene mani. è il vendor del SO/runtime che ti mappa la funzionalità software X sull'implementazione hardware Y. il programmatore di turno va raramente a fare ottimizzazioni di così basso livello, salvo casi particolari.
il programmatore scrive per un target, sia esso win, osx, dotnet, android o altro. non per x86 o per arm. l'architettura è stata astratta molto bene, il SO molto meno, linux meno di tutti (dico linux desktop)

la difficoltà del porting dipende da quanto sia già stato portato il tuo target. nessuno si mette a riscrivere le migliaia di strati software intermedi per far funzionare tutto, nemmeno adobe, costa semplicemente troppo.
se PS è in beta su M1 è perché apple ha già fatto il lavoro sporco nel portare i suoi framework (senz'altro poi adobe ha canali preferenziali)

java desktop è bello che morente da un pezzo
dotnet è opensource e va benone su win/mac/linux e x86/arm, ma non può darti tutta la prestazione che serve per programmi come PS, come non può java per lo stesso motivo.
certo alcune parti del programma le scrivi usando tecnologie multipiattaforma (in photoshop ci sono un botto di javascript, python, lua, nessun problema il porting), ma il core che ti fa fare il rendering in 30sec invece di 30min lo devi scrivere puntando dritto al SO, e nal caso di PS anche puntando all'architettura (almeno così storicamente era su mac ai tempi dei powerpc).
una volta che ti sei legato a doppio filo ad un SO, poi legato ci resti. è un lavoro enorme fare SW ad alte prestazioni multi-OS. ne esistono per carità, ma costa parecchio caro. il multi-arch è relativo, nessuno scrive in assembly, un minimo di astrazione dobbiamo concedercela sennò non si va avanti

Grazie, questo senz'altro da un quadro più chiaro della situazione.
Non è un quadro positivo ma almeno è un quadro..

Mi restano però dei dubbi più specifici..
Photoshop su WINE gia piuttosto bene. Che trucco usano?
Mac OS è comunque un sistema unix like e la sbatta per sciverlo per mac la hanno fatta.. pensavo che partendo da quello girarlo su linux sarebbe stato fattibile.. evidentemnente non lo è..

Eeeh, Wine è magia nera

Wine fa credere programma.exe di girare su Windows.
Non è proprio un’emulazione , è “quasi” un ambiente Windows intero, wine intercetta le chiamate a sistema e laddove esista un omologo Linux usano quello Linux, e se non esiste quelli di Wine l’han reimplementata da zero. in più simulano le directory win stile c:\qualcosa\, reimplementano lo strato grafico delle maggiori librerie win (wpf, winform, dotnet ecc) su Linux, il registro e un po’ di altre robe.
alla fine a prestazioni perde pochissimo, ma è tutto un castello di reverse engineering a inseguire windows.
personalmente spero che man mano che win va sempre più verso l’open source, prima o poi avremo su Linux un sottosistema Windows vero e proprio, come il Linux subsystem for Windows ufficiale MS (la versione 2 gira meravigliosamente bene).

Il discorso unix-like è abbastanza irrilevante sai. di solito oggi il programmatore non va più a fare direttamente le chiamate specifiche win/mac/linux, si programma ad uno strato intermedio che poi in fase di compilazione viene “tradotto” in chiamate native per il sistema. solo laddove il compromesso prestazionale non sia accettabile s’interviene a mano (molto molto raro), e qui Mac e Linux hanno filosofie simili ma la differenza è comunque tanta.
Linux nei framework multi-SO è lasciato indietro. Finché si fanno webapp impacchettate in un app ok le soluzioni comode ci sono, ma per i framework ad alte prestazioni non c’è niente sul mercato cross-SO (esiste giusto xamarin per mobile), le ditte se li devono fare quasi a mano questi tool.
Guarda il boom di giochi su Mac e Linux negli ultimi anni, c’è stato principalmente perché qualcuno (Steam) ha deciso di creare uno strato condiviso che comprendesse altri SO oltre a Windows. Ci pensano loro a farti agganciare il driver video, directx piuttosto che opengl/vulcan, gestire l’installazione del programma sul sistema, offrire un engine multipiattaforma ecc. Il programmatore scrive “per Steam”, ed il gioco magicamente è multipiattaforma. Questo è quello che manca per i software generalisti che abbiano qualche velleità in più di una webapp o di un’estensione per chrome.

MS la sua parte la sta facendo da anni ormai, Apple se ne sbatte per lo più come al solito, e su Linux c’è sempre caciara per convergere su uno standard (qualcosa pare muoversi con IBM/RedHat, ma tutto di là da venire ancora)

adobe è un caso un po' particolare e quelle quote che metti non corrispondono al loro core business, cioè adobe fattura più con apple che non con win, è quella la loro piattaforma di riferimento.

adobe è un caso un po' particolare e quelle quote che metti non corrispondono al loro core business, cioè adobe fattura più con apple che non con win, è quella la loro piattaforma di riferimento.