Distro Independet Packaging

[pabloski]

Originariamente inviato da Slayer86

Però è la via intrapresa dai 2 sistemi operativi più diffusi, su osx e su windows le librerie a parte quelle di sistema (librerie grafiche ecc...) sono tutte linkate in maniera statica all'interno degli applicativi e la situazione non è tanto male.

E' il vantaggio di poter imporre un qualche cosa. Windows e OS X ti dicono: "io, versione X.Y.Z del sistema operativo, ti offro queste librerie con versioni A, B, C, ecc...". Il resto ce lo metti tu sviluppatore dell'applicazione, che sia linkato dinamicamente o staticamente sono affari tuoi.

Ma su Linux come fai? E soprattutto c'e' una caratteristica che Linux ha da sempre aborrito, ovvero la retrocompatibilita'. C'era un articolo di alcuni anni fa, del capo progetto di Windows prima di Sinofsky, dove descriveva i salti mortali che avevano dovuto fare per mantenere la retrocompatibilita'. Penso ci ricordiamo tutti delle funzioni dell'API Win32 che vogliono come ultimo parametro la dimensione della struct che gli stai passando.

Ovviamente ad un certo punto il sistema e' imploso e MS ha detto basta e si e' inventata WinRT.

Originariamente inviato da Slayer86

Sinceramente credo sia molto più semplice per gli sviluppatori distribuire SW affidabile e ben testato indipendentemente dalla distribuzione e dalle versioni delle librerie che hanno nei repository.

Certamente e' un vantaggio. Pero' ci sono anche svantaggi, come la mancanza di controlli e che potrebbero portare software non proprio onesto sui pc della gente. Un maintainer alla fin fine il programma che va a pacchettizzare se lo guarda, lo usa, eventualmente riesce a scovare magagne ( che so, telemetria, attivita' sospette di manipolazione dei dati dell'utente ). Si otterrebbero tutti i vantaggi e gli svantaggi gia' noti nel mondo Windows.

Originariamente inviato da Slayer86

Che poi a dirla tutta secondo me il futuro vero per linux sono le web app e framework tipo electron.

Le webapp purtroppo saranno un male con cui convivere, visto che i colossi ormai puntano tutti a queste. Evidentemente la NSA ha bisogno di raccogliere altri dati.

Electron e' interessante, almeno per quanto riguarda la facilita' con cui si possono realizzare applicazioni stand-alone. Ed e' pure un vantaggio perche' l'API a cui fare riferimento diventa quella di Webkit e non piu' quella del sistema operativo.

In pratica il programma della retrocompatibilita' si sposta di un livello, ma con la certezza che chi sviluppa gli engine per il web ci tiene alla retrocompatibilita'.

Originariamente inviato da Slayer86

Non mi ci vedo a studiare le librerie GTK o QT per un market share del 1/2% piuttosto o posso realizzare un'applicazione che giri su tutti i sistemi operativi oppure la faccio per Windows e OSX escludendo Linux.

QT e' multipiattaforma ed e' un framework decisamente di alto livello. E' un po' mancante sul versante dei controlli Qt Quick, ma il tempo sanera' anche questa pecca.

E considera che comunque Electron et similia ti fanno pagare un prezzo abbastanza alto in termini di performance. Per cui non si ritorna al problema che gli sviluppatori mobile devono affrontare costantemente, ovvero valutare il trade-off tra performance e facilita' d'implementazione.

Ci sono applicazioni che devono essere performanti, per quelle Electron non e' una soluzione accettabile, cosi' come React Native non lo e' per alcune applicazioni mobile.

[Slayer86]

Originariamente inviato da pabloski

E' il vantaggio di poter imporre un qualche cosa. Windows e OS X ti dicono: "io, versione X.Y.Z del sistema operativo, ti offro queste librerie con versioni A, B, C, ecc...". Il resto ce lo metti tu sviluppatore dell'applicazione, che sia linkato dinamicamente o staticamente sono affari tuoi.

Ma su Linux come fai? E soprattutto c'e' una caratteristica che Linux ha da sempre aborrito, ovvero la retrocompatibilita'. C'era un articolo di alcuni anni fa, del capo progetto di Windows prima di Sinofsky, dove descriveva i salti mortali che avevano dovuto fare per mantenere la retrocompatibilita'. Penso ci ricordiamo tutti delle funzioni dell'API Win32 che vogliono come ultimo parametro la dimensione della struct che gli stai passando.

Ovviamente ad un certo punto il sistema e' imploso e MS ha detto basta e si e' inventata WinRT.



Certamente e' un vantaggio. Pero' ci sono anche svantaggi, come la mancanza di controlli e che potrebbero portare software non proprio onesto sui pc della gente. Un maintainer alla fin fine il programma che va a pacchettizzare se lo guarda, lo usa, eventualmente riesce a scovare magagne ( che so, telemetria, attivita' sospette di manipolazione dei dati dell'utente ). Si otterrebbero tutti i vantaggi e gli svantaggi gia' noti nel mondo Windows.



Le webapp purtroppo saranno un male con cui convivere, visto che i colossi ormai puntano tutti a queste. Evidentemente la NSA ha bisogno di raccogliere altri dati.

Electron e' interessante, almeno per quanto riguarda la facilita' con cui si possono realizzare applicazioni stand-alone. Ed e' pure un vantaggio perche' l'API a cui fare riferimento diventa quella di Webkit e non piu' quella del sistema operativo.

In pratica il programma della retrocompatibilita' si sposta di un livello, ma con la certezza che chi sviluppa gli engine per il web ci tiene alla retrocompatibilita'.



QT e' multipiattaforma ed e' un framework decisamente di alto livello. E' un po' mancante sul versante dei controlli Qt Quick, ma il tempo sanera' anche questa pecca.

E considera che comunque Electron et similia ti fanno pagare un prezzo abbastanza alto in termini di performance. Per cui non si ritorna al problema che gli sviluppatori mobile devono affrontare costantemente, ovvero valutare il trade-off tra performance e facilita' d'implementazione.

Ci sono applicazioni che devono essere performanti, per quelle Electron non e' una soluzione accettabile, cosi' come React Native non lo e' per alcune applicazioni mobile.

Concordo praticamente con tutto, e non avevo mai considerato la problematica relativa alla possibilità di includere software malevolo, qui sarà necessario operare una serie di controlli per garantire l'affidabilità sugli "store" ufficiali... snap flatpack che sia...

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

[pabloski]

Originariamente inviato da Slayer86

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

Di sicuro e' un enorme shift nel modello di gestione del software. Consideriamo pure cosa implica il sandboxing, ovvero una cosa a la Android, dove un word processor non puo' mettere il becco nelle foto delle vacanze. E' un bene da un lato, ma dall'altro crea barriere che possono impattare sull'esperienza d'uso dell'utente ( es: bisogna autorizzare il programma ogni volta si voglia includere una foto in un documento ).

Quel che e' certo e' che era necessario un cambiamento. Credo che invece di strillare al complotto, bisognerebbe mettersi tutti a migliorare questo nuovo modello di gestione del software, in modo da renderlo il piu' efficiente possibile.

Con assoluta certezza si eliminera' l'ultima scusa che i produttori di software avevano per non portare i loro software su Linux.

[GTKM]

Originariamente inviato da Slayer86

Concordo praticamente con tutto, e non avevo mai considerato la problematica relativa alla possibilità di includere software malevolo, qui sarà necessario operare una serie di controlli per garantire l'affidabilità sugli "store" ufficiali... snap flatpack che sia...

Comunque sia questo a cui stiamo assistendo è un cambiamento, e notevole. Com'è stato fino ad ora non mi pare che abbia funzionato un gran che... staremo a vedere dove si andrà a finire.

Secondo me l'ideale sarebbe stato sfruttare il più possibile le librerie condivise, ma questo richiede alcune cose che non sono proprio facili da attuare, tra cui scriverle come si deve.

[Slayer86]

Originariamente inviato da GTKM

Secondo me l'ideale sarebbe stato sfruttare il più possibile le librerie condivise, ma questo richiede alcune cose che non sono proprio facili da attuare, tra cui scriverle come si deve.

eh bhe! Purtroppo l'ideale non esiste!

Detto questo, primo tentativo con snap (visto che sono su ubunut) ho provato krita, ma non funziona con i driver proprietari nvidia...

[IngMetallo]

Ho appena letto un articolo molto interessante, scoprendo l'esistenza di un altro software in grado di fornire pacchetti funzionanti su multiple distro. Si tratta di Appimage e a quanto pare è molto più maturo rispetto a Snap e Flatpack.
https://distrowatch.com/weekly.php?i...160704#opinion

Se volete provare qualche appimage:
https://github.com/probonopd/AppImageKit/wiki/AppImages
https://bintray.com/probono/AppImages
ho provato con successo Krita, usando Debian Testing

[Slayer86]

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme

[pabloski]

Originariamente inviato da Slayer86

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme

Senza contare che offre pure maggiori funzionalita' https://github.com/probonopd/AppImag...ster/README.md

L'unica che mi pare manchi e' il sandboxing ( purtroppo ).

Il problema di Linux e' che ci sono due colossi, Redhat e Canonical, che mirano al dominio dell'ecosistema e soffrono di una fortissima sindrome NIH.

Per ora la guerra la sta vincendo Redhat, visto che e' riuscita ad imporre tecnologie chiave come Pulseaudio e Systemd.

[Slayer86]

Come si suol dire vittorie di Pirro...
Perchè sicuramente non è l'ambiente Linux ad averci guadagnato, basti vedere la pagliacciata per sostituire Xorg.

Ad oggi ne Mir ne Wayland sono utilizzati / supportati (ma nemmno pronti per essere distribuiti)

Il problema è che i sistemi operativi "concorrenti" sono andati avanti notevolmente negli ultmi anni mentre tra le solite spaccature e divisioni il monto Linux è rimasto parecchio indietro perdendo anche parte di quelle quote di mercato tanto faticosamente guadagnate...

Questa potrebbe diventare l'ennesima occasione sprecata

[Slayer86]

Cmq sono curiosissimo per questo AppImage, lo proverò il prima possibile

[IngMetallo]

Originariamente inviato da pabloski

Senza contare che offre pure maggiori funzionalita' https://github.com/probonopd/AppImag...ster/README.md

L'unica che mi pare manchi e' il sandboxing ( purtroppo ).

Se leggi il readme verso la fine, dice proprio che per il sandboxing si può usare Firejail: https://github.com/probonopd/AppImag....md#sandboxing

Ovvio che poi rimane sempre il problema Xorg.

Originariamente inviato da Slayer86

Chissà come mai hanno sentito il bisogno di farne altre 2 di piattaforme

Beh di differenze implementative ce ne sono molto, Flatpack sarà sicuramente più efficiente grazie ai runtime.
Snap, da quando ho scoperto che la parte server è closed-source, rifiuto di prenderlo in considerazione. Canonical mi sta deludendo anno dopo anno.
Di fatto però AppImage è l'unico che funziona, quindi rappresenta sicuramente il presente a proposito, anche Atom 1.8 ha funzionato a primo colpo!

[Slayer86]

Lo stai provando su Ubuntu?
Servono repo extra immagino...

[Slayer86]

Ok, capito... in pratica scarichi solo il file .appimage gli dai i permessi di esecuzione e sei pronto! Non c'è una sorta di store da cui scariare i file... cmq ottimo davvero Krita parte senza problemi!

[pabloski]

AppImage mi ricorda tantissimo Slax/Porteus. E parliamo di roba che si faceva gia' nel 2007. Potere di squashfs

[Slayer86]

Non le conosco come distro.
Comunque sia senza un mezzo (portale web o applicazione) centralizzato da cui scaricare i pacchetti è un disastro maggiore rispetto alla gestione classica da repository XD

Per esempio oggi cercavo Atom.io ma non l'ho trovato.

[IngMetallo]

Vero, infatti avrebbero dovuto pensare anche ad una soluzione centralizzata con relativo tool per scaricare i binari ufficiali. Attualmente puoi trovare i binari qui: https://github.com/probonopd/AppImageKit/wiki/AppImages. In pratica sono tutti link che portano al profilo bintray.com di probono (lo sviluppatore di AppImage).

A proposito di "probono", ha appena scritto qualcosa di interessante riguardo Electron e AppImage, appena ho letto ho pensato subito a te Slayer
https://plus.google.com/105493415534...ts/C1Mo1m5Muin

Originariamente inviato da Slayer86

Lo stai provando su Ubuntu?
Servono repo extra immagino...

Non uso Ubuntu. Solo Arch e Debian sui pc di casa

[Slayer86]

I programmi realizzati con Electron ne gioveranno tantissimo di questo nuovo modo di distribuire il software. Se si affermerà una piattaforma unica gli sviluppatori saranno estremamente agevolati anche nella creazione dei pacchetti finali da distribuire.

Detto questo, ho appena creato un nuovo repo privato su bitbucket con git kraken ed è fantastico, funziona meglio si Source Tree su Osx!

Ha ancora qualche problema di gioventù e su Osx (non so su windows) è lentissimo (colpa di electron credo) ma ragazzi che SW che hanno sfornato. Spero non lo facciano diventare a pagamento in futuro.

p.s. mi sa che a breve piallo il pc in ufficio e passo (torno) ad Arch con KDE...

[Slayer86]

Tra l'altro ragionadoci... AppImage lo usavo da tempo con Franz.
Franz è sempre un'app electron che in un'unico contenitore permette di aprire le web app di tutti i più comuni servizi di chat (messenger, whatsapp, telegram...)

Ci ho ragionato ieri, mi sono chiesto come facesse a funzionare ed ho fatt 1+1

Ho poi provveduto a configurare un link in gnome-shell... ecco questa è un'altra parte carente.

Le mancanze cruciali di appimage sono 2:

1. distribuzione dei programmi centralizzata
2. Installazione nei più comuni DE

[IngMetallo]

Non conoscevo Franz, sembra carino ma se non sbaglio è closed-source vero? Come Git Kraken che sembra molto carino, ma per il mio semplice workflow continuo a preferire git (da terminale) + gitg

Comunque sono felice di vedere che AppImage sia realmente utile per la distribuzione del software!
Ai punti negativi che hai citato, aggiungerei che di fatto è ancora poco utilizzato

Riguarda il link in Gnome a cosa ti riferisci di preciso ? Vorresti aggiungere un'icona avviabile nel menù ?

[Slayer86]

Originariamente inviato da IngMetallo

Non conoscevo Franz, sembra carino ma se non sbaglio è closed-source vero? Come Git Kraken che sembra molto carino, ma per il mio semplice workflow continuo a preferire git (da terminale) + gitg

Comunque sono felice di vedere che AppImage sia realmente utile per la distribuzione del software!
Ai punti negativi che hai citato, aggiungerei che di fatto è ancora poco utilizzato

Riguarda il link in Gnome a cosa ti riferisci di preciso ? Vorresti aggiungere un'icona avviabile nel menù ?

Si esatto ho aggiunto una cartella Apps nella mia home, ho poi creato il file .desktop e l'ho copiato nella cartella da cui gnome shell va a pescare (non ricordo quale sia...).

Concordo poi sul fatto che non sia diffuso, ma cacchio nemmeno lo conoscevo non è stato spinto per nulla! In pieno stile linux hanno semplicemente copiato l'idea in altri 2 o 3 progetti che si fanno la guerra tra loro...