Adobe Photoshop con supporto ad Apple Silicon è disponibile in beta

Adobe Photoshop con supporto ad Apple Silicon è disponibile in beta

di Mattia Speroni, pubblicata il

“Adobe Photoshop è ora disponibile in versione beta per i sistemi Apple Silicon con chip Apple M1. Mancano molte funzionalità e sono stati segnalati limitazioni e bug, ma è un inizio prima del rilascio della versione definitiva.”


Commenti (19)

Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - Info
Per contattare l'autore del pezzo, così da avere una risposta rapida, si prega di utilizzare l'email personale (vedere in alto sotto il titolo). Non è detto che una domanda diretta inserita nei commenti venga verificata in tempi rapidi. In alternativa contattare la redazione a questo indirizzo email.
Commento # 11 di: Mr_Paulus pubblicato il 21 Novembre 2020, 19:02
Originariamente inviato da: demon77
Come detto, lo so che funziona così. Non è che dico di no.
Il 2% è una nicchia troppo piccola e giustamente se ne frega.

Quello che dico è che è un peccato perchè è anche per il fatto che se ne frega che quel 2% non divneta 3% o 4%.
Adobe come molti altri ovviamente.

Sarebbe bello che almeno le software house più grandi tipo Corel, Adobe, Autodesk facessero uno sforzo per garantire una versione del loro software scegliendo di supportare ufficialmente almeno una major distribution del pinguino.

Magari non ci guadagneranno (sul subito) ma non credo che la cosa li faccia finire in perdita.


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.
Commento # 12 di: demon77 pubblicato il 21 Novembre 2020, 19:21
Originariamente inviato da: Mr_Paulus
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.
Commento # 13 di: Mr_Paulus pubblicato il 21 Novembre 2020, 20:06
Originariamente inviato da: demon77
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
Commento # 14 di: lollo9 pubblicato il 21 Novembre 2020, 23:24
Originariamente inviato da: demon77
Non so niente di programmazione. Quindi più che plausibile che abbia detto castronerie.

Ma in pratica mi stai dicendo che convertire un software da X86 ad ARM.. quindi una CPU con istruzioni e logiche differenti è una cosa gestibile mentre invece convertire lo stesso identico software da WIN a LINUX è molto più complicato?
La cosa mi sembra difficile da credere soprattutto per il fatto che su linux già adesso tramite wine, photoshop gira senza problemi.
Ma ripeto, non so nulla di programmazione.


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
Commento # 15 di: demon77 pubblicato il 21 Novembre 2020, 23:39
Originariamente inviato da: lollo9
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 è..
Commento # 16 di: lollo9 pubblicato il 22 Novembre 2020, 10:18
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)
Commento # 17 di: NickNaylor pubblicato il 22 Novembre 2020, 17:38
Originariamente inviato da: Mr_Paulus
il discorso di adobe è:

windows -> >70% dell'utenza mondiale
mac -> circa 20% dell'utenza mondiale, e una consistente(*) parte dell'utenza professionale
linux -> < 2% dell'utenza mondiale (ai pari di chromeOS)

(*) secondo i dati di adobe che la invogliano a sviluppare per apple


perché mai dovrebbero sviluppare per linux? (dal loro punto di vista ovviamente)

(le percentuali le ho prese dal primo sito a caso scrivendo su google linux market share)


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.
Commento # 18 di: NickNaylor pubblicato il 22 Novembre 2020, 17:38
Originariamente inviato da: Mr_Paulus
il discorso di adobe è:

windows -> >70% dell'utenza mondiale
mac -> circa 20% dell'utenza mondiale, e una consistente(*) parte dell'utenza professionale
linux -> < 2% dell'utenza mondiale (ai pari di chromeOS)

(*) secondo i dati di adobe che la invogliano a sviluppare per apple


perché mai dovrebbero sviluppare per linux? (dal loro punto di vista ovviamente)

(le percentuali le ho prese dal primo sito a caso scrivendo su google linux market share)


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.
Commento # 19 di: dontbeevil pubblicato il 24 Novembre 2020, 09:50
"Adobe Photoshop con supporto ad Apple Silicon e a Windows on ARM è disponibile in beta"

fixed
« Pagina Precedente     Pagina Successiva »