Chakra Linux Italia Forum

Comunità => Chakra Bar => Topic aperto da: Lazy - 31 Marzo 2016 ore 21:22

Titolo: Chakra brainstorm
Inserito da: Lazy - 31 Marzo 2016 ore 21:22
Sempre in accordo con Almack apro questo topic per invitarvi a segnalare consigli idee e suggerimenti, per Chakra, in particolare Almack seguirà questo topic, eventualmente per prendere spunto dai vostri consigli e suggerimenti per le prossime iso di Chakra
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 31 Marzo 2016 ore 21:38
Inizio io con alcuni piccoli suggerimenti, da domani ci penserò meglio ma per ora le prime cose che mi vengono in mente sono le seguenti  ;D
Nella prossima iso riguardo ai software proporrei di mettere Cantata + Mpd di default come player musicale al posto di Tomahawk in quanto anche se Tomahawk è sicuramente un'ottimo player non si integra molto bene col resto delle applicazioni kde (dal punto di vista grafico intendo) inoltre Cantata oltre ad integrarsi molto bene credo sia pure più leggero!
Siccome Kget mi pare che non funzioni al meglio userei come farà Kaos questo programma al suo posto http://fatrat.dolezel.info che dovrebbe ben integrarsi con Qupzilla!
inoltre anche se so che forse ci sarà una iso minimal nella iso normale eviterei comunque di mettere software troppo specialistici come Digikam o Krita, magari lasciando spazio per qualche stupido giochino tipo Kpatience o kMahjongg!
Come player video Bomi lo ritengo un'ottima scoperta anche se di default userei il tema Breeze che meglio si accorda con le altre applicazioni, inoltre ha delle impostazioni di default un pò strane cmq niente che non si possa aggiustare!
per ora non mi viene in mente altro ma sono sicuro che non mancherò XD
Titolo: Re:Chakra brainstorm
Inserito da: sim0161 - 01 Aprile 2016 ore 16:58
Quando usavo Puppy la cosa che in assoluto apprezzavo più di tutte era la possibilità, in qualunque momento, di trasfomare il proprio sistema "as is" con i pacchetti installati e le loro impostazioni, in una ISO. Potrei così installare il MIO chakra sul computer di qualcun altro, oppure tenermelo salvato come backup. Sarebbe più comodo della guida per il "felice" backup, che è macchinosa e mi ha dato un sacco di errori.
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 01 Aprile 2016 ore 17:00
Una funzione abbastanza utile che non ricordo se l'ho vista su Gnome Shell con fedora oppure in Elementary OS è la notifica di sistema nel momento in cui sono terminate le operazioni in corso sul terminale
ad esempio, lanci un aggiornamento sul terminale oppure installi un pacchetto che richiede tempo, tipo libreoffice, nel frattempo fai altro tipo navigare nel browser, quando il download è finito ti arriva la notifica, così eviti ogni tot di controllare il download in corso sul terminale, sembra una cazzata ma nell'uso quotidiano l'ho trovata un'ottima cosa!
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 01 Aprile 2016 ore 17:06
Una roba così nella start page di Qupzilla non sarebbe male
http://orig06.deviantart.net/704f/f/2014/065/a/3/elementary_start_page_by_sunkotora-d7956fe.png
Inoltre nell'ultima iso che non era la minimal iso ricordo che nella home mancavano le cartelle predefinite (Documenti,Immagini,Video etc.) siccome la iso non è minimal credo sarebbe giusto averle di default!
Post-installazione mi piacerebbe trovare il Plasmoide Folder View classico che si trova solitamente di default in tutte le installazioni di kde preimpostato in modo da puntare ad una cartella con all'interno link alle pagine del sito con le prime info su chakra oppure un link ad un pdf con una guida post installazione sempre aggiornata, oppure il plasmoide browser che punta ad una pagina con il link in varie lingue della guida da scaricare
Titolo: Re:Chakra brainstorm
Inserito da: sim0161 - 01 Aprile 2016 ore 21:34
Post-installazione mi piacerebbe trovare il Plasmoide Folder View classico che si trova solitamente di default in tutte le installazioni di kde preimpostato in modo da puntare ...

quoto.

Nella live c'è, sono rimasto deluso quando dopo l'installazione non me lo sono trovato sulla scrivania. L'ho sempre usato, e lo trovo comodissimo. Il "vizietto" me lo diede kubuntu nel 2008: lo trovai lì, che puntava alla home. Imparai subito a cambiarci la cartella "visualizzata" (prima "documenti", poi "download"), e così via. Insomma: trovarne uno è un ottimo modo per ambientarsi
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 01 Aprile 2016 ore 22:45
Nella live c'è, sono rimasto deluso quando dopo l'installazione non me lo sono trovato sulla scrivania.

A quanto mi risulta nella live c'è il plasmoide di benvenuto di Chakra, non quello "Vista delle Cartelle"
Titolo: Re:Chakra brainstorm
Inserito da: sim0161 - 01 Aprile 2016 ore 23:04
A quanto mi risulta nella live c'è il plasmoide di benvenuto di Chakra, non quello "Vista delle Cartelle"

errore mio. Va detto che gli somiglia...
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 01 Aprile 2016 ore 23:06
A quanto mi risulta nella live c'è il plasmoide di benvenuto di Chakra, non quello "Vista delle Cartelle"
Esatto, nella live c'è quello di Chakra, mentre post installazione c'è quello vista delle cartelle, di solito vuoto, potrebbe essere utile farlo puntare ad informazioni simili a quelle che da il welcome Plasmoid della live
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 05 Aprile 2016 ore 01:19
Allora ci sono diverse cose che mi piacerebbe vedere su Chakra.

-supporto per l'installazione di web-apps
ci sono molte applicazioni che mancano su linux, specie client di servizi web, sarebbe carino avere una cosa del genere.
Questo è scritto in Gtk3, si potrebbe provare a fare un porting in Qt.
https://github.com/peppermintos/ice

-supporto per le gesture touch screen
ma questo lo dovrebbe implementare Plasma, quindi non è un problema nostro

-supporto per gli schermi HiDPI
una volta aggiornato il kernel almeno alla 4.3 (quindi a breve)

-tema heritage più completo
1-dovrebbe essere impostato di default appena installi Gtk2 o 3
2-dovrebbe essere fatto un porting per Gtk, in realtà le applicazioni Gtk usano attualmente Breeze
che è incompleto (i tooltip sono bianchi su sfondo trasparente, praticamente non si vedono).

-supporto per le schede grafiche ibride

-supporto per il secure boot

-eliminare pacchetti obsoleti e importare quelli nuovi
ho già aperto innumerevoli ticket sul bugtracker per questo

-riscrivere il centro di controllo Nvidia in Qt

-unire [core] con [lib32]
si possono unire i PKGBUILD delle librerie a 64 bit con le loro controparti a 32
cosi non si manca di aggiornare i pacchetti a 32 bit (che ogni tanto capita) e si risparmia la metà del tempo.
Inoltre non vedo molta utilità nell'avere i due repo separati

-avere un firewall manager grafico e il firewall abilitato di default
sul programma credo di aver già trovato qualcosa in Qt

-possibile passaggio da systemd a openrc
(è solo un'idea ma si può fare e il secure boot è implementabile anche su openrc)

-installatore applicazioni .deb
già scritto e funziona il più delle volte https://github.com/gnastyle/deb-installer

-migliorare il testing dei pacchetti di sistema
appena esce una nuova versione di systemd o altra roba di sistema
metterla subito su staging in modo che possa essere testata più a lungo.

-passare da openssl a libressl
un giorno, non subito
(per farla breve libressl è più sicuro)

-sandboxing per applicazioni
uno sviluppatore kde ci sta lavorando comunque

Per ora solo queste poi vediamo se me ne vengono in mente altre.
Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 05 Aprile 2016 ore 09:52
Mera curiosità: perchè passare a openrc?
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 05 Aprile 2016 ore 11:18
openRC è un'alternativa, ci sono persone che non "digeriscono" systemd e vivono il passaggio a systemd come un imposizione privando l' utente della libertà di scelta.
C'è stata una scissione anche all' interno di Debian per questo motivo, e sta nascendo il progetto Devuan libero da systemd ... 
https://devuan.org (https://devuan.org)
Titolo: Re:Chakra brainstorm
Inserito da: Cylon - 05 Aprile 2016 ore 11:21
io invece non digerisco openrc.. se chakra passasse a openrc la eradicherei dal pc sedutastante.. :D


per tornar in topic.

- creare un app che al primo avvio aiuta ad impostare varie cose come quella che c'era ai tempi di KDE 3.x... o riscrivere kapudan o creare qualcosa ex-novo in QML
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 06 Aprile 2016 ore 21:12
@Cylon
Interessante, non lo sapevo mica che anche KDE3 aveva una specie di kapudan.
Per te quali sarebbero le cose necessarie che questo programma dovrebbe aiutarti a configurare?
(magari rispetto a quelle che già erano presenti in kapudan)

Perchè non digerisci openrc?
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 06 Aprile 2016 ore 22:58
@Cylon
Interessante, non lo sapevo mica che anche KDE3 aveva una specie di kapudan.
Per te quali sarebbero le cose necessarie che questo programma dovrebbe aiutarti a configurare?
(magari rispetto a quelle che già erano presenti in kapudan)

Perchè non digerisci openrc?
kapudan era un'ottima idea di Pardus importata in Chakra, unico neo che da utile strumento di post-installazione, era diventato una roba che serviva solo a scegliere il tema e poco più, che considerando che chakra aveva una propria artwork alla fine aveva poco senso, secondo me, kapudan sarebbe un'ottimo strumento, ma se proprio si dovesse riscrivere andrebbe studiato bene cosa veramente potrebbe essere utile d aconfigurare a volo post installazione, una cosa che invece mi piace molto di Gnome shell, e qui se Cylon lo ha provato su Fedora(non so se c'è pure su altre distro), Gnome Shell post installazione ha una sorta di guida interattiva con dei video brevi ed esplicativi sulle principali funzini dell Shell, sui tasti di scelta rapida e cose così, molto leggera e minimale, secondo me Kapudan dovrebbe avere un pò quello stile, facendo impostare all'inizio all'utente quelle cose che kde solitamente tralascia e che poi solitamente l'utente deve andare a spulciare nelle varie configurazioni e perdersi, forse si dovrebbe poter scegliere il tipo di menù, il tema dark o light di breeze,il click doppio o singolo delle cartelle,ma anche cose più profonde tipo demoni attivi al primo avvio da disattivare e cose così
Titolo: Re:Chakra brainstorm
Inserito da: Cylon - 07 Aprile 2016 ore 01:31
@Lazy .. fedora??? io uso ho solo 2 distribuzioni e uso solo quelle.. arch e chakra... il resto non mi interessa. :D
in kde 3 l'applicazione di cui parlavo ,se mi ricordo bene, permetteva di impostare tutto, praticamente al primo avvio di kde 3 si apriva solo l'applicazione e una volta completate le impostazioni ti si presentava il desktop con tutte le impostazioni 'di contorno'.. purtroppo una cosa del genere dovrebbe essere sviluppata da KDE non da una distro, ma come tutte le cose sviluppate da KDE la iniziano la portano a metà e poi si buttano su un nuovo sfavillante progetto...  :-X :-X :-X

@gnastyle ... no no era kapudan una specie dell'applicazione che c'era in kde 3 (di cui non ricordo il nome) .. perchè non digerisco openrc?.. è una perdita di risorse... dal mio punto di vista systemd è quasi perfetto, mi permette di fare cose che con il 'vecchio sistema' mi facevano arruginire i capelli in modo semplice... il passaggio a openrc sarebbe un passo falso, come considero anche il passaggio da pacman all'utopico akabei (o come si chiama)
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 20 Aprile 2016 ore 21:32
Scusate se rispondo in ritardo ma sono stato molto occupato ultimamente.

Allora sono daccordo con Lazy, cioè kapudan va usato per impostare le cose importanti del sistema e non solo temi e poco altro.

Comunque non mi interessa più poter installare i pacchetti .deb su Chakra.
Alla fine devi combattere con la traduzione delle dipendenze e comunque certi programmi non funzionano perchè sono compilati con librerie di ubuntu (che non rispecchiano le versioni in Chakra).
Ma ho trovato di meglio!
Ora ubuntu oltre ai .deb supporta ufficialmente anche i pacchetti .snap.
Non sono altro che pacchetti che contengono tutte le dipendenze al loro interno.
Per chi volesse saperne di più. https://insights.ubuntu.com/2016/04/13/snaps-for-classic-ubuntu/
Appena riesco a mettere le mani su un pacchetto .snap modifico lo script per supportare questi pacchetti.
E comunque Canonical dice che entro ottobre tutti i programmi commerciali verranno convertiti a .snap.
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 20 Aprile 2016 ore 22:04
Ora ubuntu oltre ai .deb supporta ufficialmente anche i pacchetti .snap.
Non sono altro che pacchetti che contengono tutte le dipendenze al loro interno.
Per chi volesse saperne di più. https://insights.ubuntu.com/2016/04/13/snaps-for-classic-ubuntu/
Appena riesco a mettere le mani su un pacchetto .snap modifico lo script per supportare questi pacchetti.
E comunque Canonical dice che entro ottobre tutti i programmi commerciali verranno convertiti a .snap.

Le dipendenze cioè le librerie? Come accadeva con i nostri bundle, in sostanza
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 21 Aprile 2016 ore 12:35
Questo implicherà però una maggiore necessità di spazio sulla partizione di root, perchè le dipendenze verranno comunque scaricate insieme all' applicazione anche se sono già presenti sul sistema  :-X
 
E poi se più applicazioni necessitano delle stesse dipendenze, quanti doppioni si avranno ?
Titolo: Re:Chakra brainstorm
Inserito da: paolomi - 21 Aprile 2016 ore 13:08
-possibile passaggio da systemd a openrc
(è solo un'idea ma si può fare e il secure boot è implementabile anche su openrc)
Ora come ora, il passaggio per tutti a openrc direi proprio di no, ma la possibilità per chi vuole di passare a openrc direi proprio di si.


-sandboxing per applicazioni
uno sviluppatore kde ci sta lavorando comunque
Spero non stia reinventando la ruota perché c'è firejail (https://firejail.wordpress.com/) e funziona bene. Altre informazioni qui (https://l3net.wordpress.com/). Buttatelo subito in core senza passare da ccr ;D
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 21 Aprile 2016 ore 13:14
Spero non stia reinventando la ruota perché c'è firejail (https://firejail.wordpress.com/) e funziona bene. Altre informazioni qui (https://l3net.wordpress.com/). Buttatelo subito in core senza passare da ccr ;D

Firejail con la sua interfaccia grafica "Firetools" funziona benissimo, lo utilizzo anch'io su Chakra quotidianamente.
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 21 Aprile 2016 ore 23:46
Allora riguardo al sandboxing/bundle credo ci siano delle cose da chiarire.

VANTAGGI BUNDLE
-Funzionano sempre, anche per anni (niente errori del tipo "libcoso.so.1 non trovato")
-Gli sviluppatori non devono compilare il loro programma direttamente per Chakra (chi ha provato deb-installer si sarà accorto che certi pacchetti sono stati compilati contro le librerie di Ubuntu e non possono funzionare su Chakra.)
-Se non trovi il programma che ti serve sui repo o sui CCR puoi scaricarlo direttamente dal sito web come si usa su Windows o gli .apk con android. (utile nel caso di programmi proprietari o poco conosciuti come quelli che cerca sempre Dinolib  :P)
-Sono indipendenti dal sistema e non vanno a "sporcare" o a creare malfunzionamenti o interferenze con il resto del sistema.

SANDBOX
Firejail (e credo anche xdg-app) sono sandbox, cioè non integrano tutte le dipendenze al loro interno ma semplicemente impediscono all'applicazione di accedere ai file di sistema (cosa che è importantissima per la sicurezza).
Sarà una cosa utile (e credo si debba fare) creare un sandbox di default per le applicazioni distribuite sui repo di Chakra (vediamo se xdg-app andrà in porto).
Gli .snap hanno il loro sandbox integrato di default.

REPOSITORY
-Scarichi software a portata di mano (niente ricerche su internet per cercare il programma che cerchi).
-Sei sicuro che il software sia autentico (niente malware in bundle come su sourceforge o adware come su Windows).
-Sei sicuro che usi librerie che non sono affette da vulnerabilità conosciute.
-Non sprechi spazio con dipendenze duplicate.
-I programmi vengono aggiornati insieme al sistema (con gli .snap (come su Windows) devi controllare se ci sono aggiornamenti e scaricare il programma manualmente)
-I pacchetti possono avere patch ed essere integrati meglio con Plasma (vedi firefox-kde).


Come potete vedere ci sono pro e contro. Personalmente credo che gli .snap siano un'opportunità per aumentare il software disponibile su Chakra (che non è molto) senza dover pacchettizzare tutto da soli (anche se i repo rimangono il metodo principale per installare i programmi).

@Franzmari
Gli .snap sono simili ai bundle di Chakra, ma sono più flessibili e permettono anche di definire script all'interno di un solo pacchetto e anche di avere più programmi insieme (andate a vedere il wiki di ubuntu per maggiori info).
Titolo: Re:Chakra brainstorm
Inserito da: Lazy - 22 Aprile 2016 ore 16:57
Unica domanda sugli .Snap (mitico gruppo musicale anni90 XD) Ma sono universali?Cioè sono compatibili con tutte le distro o eventualmente potrebbero esserlo?Se si sarebbe una gran cosa e spingerebbe le aziende di software che stanno lontane da linux a causa della frammentazione a fare pacchetti universali per tutte le distro
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 22 Aprile 2016 ore 17:46
@Lazy
No non sono universali, ma credo che si possa usare deb-installer (ovviamente leggermente adattato).
I punti debole di deb-installer sono che certi programmi usano versioni di librerie diverse da Chakra (e quindi il programma non funziona) e che ci sono migliaia di dipendenze da tradurre da Debian a Arch.
Gli .snap risolvono entrambi, perchè tutte le librerie sono in bundle e non ci sono dipendenze da soddisfare (se non il kernel).
Quindi possono facilmente essere universali e credo anche io che sarebbe nell'interesse di tutti se anche le altre distro lo adottino.
Vi farò sapere se si può fare uno snap-installer appena riesco a mettere le mani su uno .snap.
A quel punto basterebbe installarlo di default su Chakra e sulle azioni predefinite collegare il formato .snap a snap-installer e con un semplice click partirebbe l'installazione del programma.
Un pò come funziona con gli .apk di android.
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 27 Aprile 2016 ore 19:13
"downgrade" non sarebbe niente male, un semplice script già presente su AUR in Arch e nei repo di Manjaro che facilita il downgrade di un pacchetto se quest'ultimo non dovesse funzionare "a dovere"
Per Arch e Manjaro esiste anche l'opzione di scaricare la vecchia versione dall' Arch Linux Archive, su Chakra faciliterebbe la vita a molti, soprattutto ai nuovi utenti che non sanno dove andare a recuperare la vecchia versione che avevano installata prima dell' aggiornamento ( /var/cache/pacman/pkg )
Volendo si potrebbe implementare un' interfaccia grafica ...
Non so, è solo un' idea.

https://wiki.manjaro.org/index.php?title=Downgrade (https://wiki.manjaro.org/index.php?title=Downgrade)

https://aur.archlinux.org/packages/downgrade/ (https://aur.archlinux.org/packages/downgrade/)
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 28 Aprile 2016 ore 11:44
Mi sono ricordato del problema che dinolib ha riscontrato con la nuova versione di hplip, quindi ho voluto provare un downgrade con il comando downgrade hplip, vi posto l'output del comando:

Codice: [Seleziona]
[teo@r2 ~]$ downgrade hplip
Available packages:

   1) hplip-3.16.3-1-x86_64.pkg.tar.xz (local)
   2) hplip-3.16.3-1-x86_64.pkg.tar.xz (remote)
   3) hplip-3.16.2-2-x86_64.pkg.tar.xz (remote)
   4) hplip-3.16.2-1-x86_64.pkg.tar.xz (remote)
   5) hplip-3.15.11-2-x86_64.pkg.tar.xz (remote)
   6) hplip-3.15.11-1-x86_64.pkg.tar.xz (remote)
   7) hplip-3.15.9-2-x86_64.pkg.tar.xz (remote)
   8) hplip-3.15.9-1-x86_64.pkg.tar.xz (remote)
   9) hplip-3.15.7-2-x86_64.pkg.tar.xz (remote)
  10) hplip-3.15.7-1-x86_64.pkg.tar.xz (remote)
  11) hplip-3.15.6-1-x86_64.pkg.tar.xz (remote)
  12) hplip-3.15.4-1-x86_64.pkg.tar.xz (remote)
  13) hplip-3.15.2-3-x86_64.pkg.tar.xz (remote)
  14) hplip-3.15.2-2-x86_64.pkg.tar.xz (remote)
  15) hplip-3.15.2-1-x86_64.pkg.tar.xz (remote)
  16) hplip-3.14.10-2-x86_64.pkg.tar.xz (remote)
  17) hplip-3.14.10-1-x86_64.pkg.tar.xz (remote)
  18) hplip-3.14.6-1-x86_64.pkg.tar.xz (remote)
  19) hplip-3.14.4-1-x86_64.pkg.tar.xz (remote)
  20) hplip-3.14.3-2-x86_64.pkg.tar.xz (remote)
  21) hplip-3.14.3-1-x86_64.pkg.tar.xz (remote)
  22) hplip-3.14.1-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  23) hplip-3.14.1-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  24) hplip-3.13.11-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  25) hplip-3.13.11-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  26) hplip-3.13.10-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  27) hplip-3.13.10-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  28) hplip-3.13.9-3-x86_64.pkg.tar.xz (remote)                                                                                                                               
  29) hplip-3.13.9-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  30) hplip-3.13.9-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  31) hplip-3.13.8-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
                                                                                                                                                                               
select a package by number:                                                                                                                                                   
                                                                                                                                                                               
                                                                                                                                                                               
                                                                                                                                                                               
                                                                                                                                                                               
                         
Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 28 Aprile 2016 ore 12:10
Mi sono ricordato del problema che dinolib ha riscontrato con la nuova versione di hplip, quindi ho voluto provare un downgrade con il comando downgrade hplip, vi posto l'output del comando:

Codice: [Seleziona]
[teo@r2 ~]$ downgrade hplip
Available packages:

   1) hplip-3.16.3-1-x86_64.pkg.tar.xz (local)
   2) hplip-3.16.3-1-x86_64.pkg.tar.xz (remote)
   3) hplip-3.16.2-2-x86_64.pkg.tar.xz (remote)
   4) hplip-3.16.2-1-x86_64.pkg.tar.xz (remote)
   5) hplip-3.15.11-2-x86_64.pkg.tar.xz (remote)
   6) hplip-3.15.11-1-x86_64.pkg.tar.xz (remote)
   7) hplip-3.15.9-2-x86_64.pkg.tar.xz (remote)
   8) hplip-3.15.9-1-x86_64.pkg.tar.xz (remote)
   9) hplip-3.15.7-2-x86_64.pkg.tar.xz (remote)
  10) hplip-3.15.7-1-x86_64.pkg.tar.xz (remote)
  11) hplip-3.15.6-1-x86_64.pkg.tar.xz (remote)
  12) hplip-3.15.4-1-x86_64.pkg.tar.xz (remote)
  13) hplip-3.15.2-3-x86_64.pkg.tar.xz (remote)
  14) hplip-3.15.2-2-x86_64.pkg.tar.xz (remote)
  15) hplip-3.15.2-1-x86_64.pkg.tar.xz (remote)
  16) hplip-3.14.10-2-x86_64.pkg.tar.xz (remote)
  17) hplip-3.14.10-1-x86_64.pkg.tar.xz (remote)
  18) hplip-3.14.6-1-x86_64.pkg.tar.xz (remote)
  19) hplip-3.14.4-1-x86_64.pkg.tar.xz (remote)
  20) hplip-3.14.3-2-x86_64.pkg.tar.xz (remote)
  21) hplip-3.14.3-1-x86_64.pkg.tar.xz (remote)
  22) hplip-3.14.1-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  23) hplip-3.14.1-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  24) hplip-3.13.11-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  25) hplip-3.13.11-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  26) hplip-3.13.10-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  27) hplip-3.13.10-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  28) hplip-3.13.9-3-x86_64.pkg.tar.xz (remote)                                                                                                                               
  29) hplip-3.13.9-2-x86_64.pkg.tar.xz (remote)                                                                                                                               
  30) hplip-3.13.9-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
  31) hplip-3.13.8-1-x86_64.pkg.tar.xz (remote)                                                                                                                               
                                                                                                                                                                               
select a package by number:                                                                                                                                                   
                                                                                                                                                                               
                                                                                                                                                                               
                                                                                                                                                                               
                                                                                                                                                                               
                         

Ma l'hai fatto da Arch o Chakra?

PS.OT: alla fine basta spegnere e accendere la stampante, attendere qualche minuto, scaricare il firmware manualmente e la stampante funziona. Ad ogni aggiornamento nuove sorprese :)
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 28 Aprile 2016 ore 12:25
Ho fatto da Chakra con "downgrade" preso da AUR, ovviamente i pacchetti che vedi contrassegnati con ( remote ) sono quelli dell' archivio di Arch e non di Chakra, quindi bisogna stare attenti.
Però diciamo che se si hanno delle versioni precedenti nella cache vengono visualizzate subito, certo, sarebbe il massimo poter avere anche per Chakra un archivio come quello di Arch.  :'(
Titolo: Re:Chakra brainstorm
Inserito da: whoami - 28 Aprile 2016 ore 14:00
Sarò io ma ci vedo un gran casino a fare downgrade di pacchetti come procedura "abituale" per risolvere problemi... Alla fine i pacchetti core di chakra vengono rilasciati apposta dopo quelli di arch per cui gli errori sono troppo sporadici per mantenere un repo di archivio e dover risolvere non solo i problemi dei pacchetti stabili ma anche quelli di dipendenze fallite causate dal downgrade...
Titolo: Re:Chakra brainstorm
Inserito da: Teo - 28 Aprile 2016 ore 15:57
No certo, non deve essere una cosa "abituale" assolutamente
Meglio evitare il downgrade se si può risolvere in altro modo.
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 05 Giugno 2016 ore 20:46
Salve gente,
allora volevo discutere di un possibile porting di Kapudan in Qt5.
E' già stato avviato, l'unica cosa di cui volevo discutere sono le impostazioni che secondo voi dovrebbe avere.
Per prima cosa io proporrei le seguenti:

-chiedere all'utente se vuoi abilitare [gtk] (ovvio)
-chiedere se si vuole usare il click singolo o doppio per le cartelle
-abilitare o meno baloo (è migliorato tantissimo ma è ancora avido di risorse, su alcuni laptop disabilitarlo comporta un miglioramento della reattività del sistema)
-aprire di default delle porte nel firewall per permettere l'utilizzo di KdeConnect
-scegliere se il bottone di accensione dovrebbe essere usato per aprire il dialogo di spegnimento del pc o sospendere il sistema
-chiedere se si vogliono installare delle applicazioni utili per il sistema (android-file-transfert, fingerprint-gui ecc.)
-chiedere se si vuole abilitare automaticamente il backup di sistema (forse)

Avete altri suggerimenti?
Grazie  :beer:
Titolo: Re:Chakra brainstorm
Inserito da: alex - 06 Giugno 2016 ore 16:10
Se ricordo bene Kapudan permetteva anche di scegliere alcune personalizzazioni per il tema, il wallpaper ecc...
Permetteva anche di scegliere se vedere le proprie cartelle sul desktop (documenti, video, ecc... ).

Sarebbe figo anche vedere una sorta di breve video che indica le funzioni principali, tipo le guide che compaiono sulle app al primo utilizzo (tipo questo è il pannello, questi sono i plasmoidi, questo è il menu di default, ecc... ).

Poi boh, cosa configurate sempre dopo aver installato Chakra? (oltre alle cose già indicate nel post prima... )   
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 14 Giugno 2016 ore 22:15
Allora buone notizie!
Per quanto riguarda i due tipi di bunlde/container come li volete chiamare xdg-app (ora chiamato flatpack) e snap di Ubuntu saranno disponibili su Chakra.
Per gli snap si userà un tool da riga di comando snapd (sto lavorando a farlo installare su Chakra) ed quindi tutti i pacchetti pubblicati su snapcraft.io saranno disponibili anche agli utenti di Chakra.

Per quanto riguarda i flatpak c'è uno sviluppatore KDE che sta lavorando a un backend per Discover, quindi CREDO dovrebbe essere implementabile anche su Chakra (però ci vorrà ancora del tempo).
Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 15 Giugno 2016 ore 07:47
Allora buone notizie!
Per quanto riguarda i due tipi di bunlde/container come li volete chiamare xdg-app (ora chiamato flatpack) e snap di Ubuntu saranno disponibili su Chakra.
Per gli snap si userà un tool da riga di comando snapd (sto lavorando a farlo installare su Chakra) ed quindi tutti i pacchetti pubblicati su snapcraft.io saranno disponibili anche agli utenti di Chakra.

Per quanto riguarda i flatpak c'è uno sviluppatore KDE che sta lavorando a un backend per Discover, quindi CREDO dovrebbe essere implementabile anche su Chakra (però ci vorrà ancora del tempo).
questa cosa degli snap sembra molto interessante.
Curiosità: come (zippone/file) e dove vengono salvati i programmi? sarà personalizzabile, o finisce dentro /opt o /usr/bin o cose del genere?
Titolo: Re:Chakra brainstorm
Inserito da: alex - 15 Giugno 2016 ore 10:24
Si, in effetti è una bella novità. Ma se funzionano bene ha poi ancora senso tenere i pacchetti della comunità? o tanto vale tenere solo i pacchetti ufficiali come sono ora e utilizzare i bundle per il resto? immagino che il sistema rimanga più pulito e che si evitino i vari problemi con dipendenze ecc...  ma forse non ho capito qualcosa e le due cose non sono complementari  ;D
Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 15 Giugno 2016 ore 12:36
Si, in effetti è una bella novità. Ma se funzionano bene ha poi ancora senso tenere i pacchetti della comunità? o tanto vale tenere solo i pacchetti ufficiali come sono ora e utilizzare i bundle per il resto? immagino che il sistema rimanga più pulito e che si evitino i vari problemi con dipendenze ecc...  ma forse non ho capito qualcosa e le due cose non sono complementari  ;D
semmai, alcuni pacchetti gtk possiamo trasformarli in snap...
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 15 Giugno 2016 ore 19:09
Sto leggendo la documentazione e, per adesso, mi pare che siano sostanzialmente uguali ai nostri vecchi bundle
Titolo: Re:Chakra brainstorm
Inserito da: whoami - 15 Giugno 2016 ore 21:06
Però li pacchettizza direttamente lo sviluppatore...  magari vi allevia un po' il lavoro...

ma in ogni caso non mi convincono...
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 15 Giugno 2016 ore 23:34
Però li pacchettizza direttamente lo sviluppatore...  magari vi allevia un po' il lavoro...

ma in ogni caso non mi convincono...
Non necessariamente, chiunque può realizzarli e distribuirli (se la licenza lo consente, ovviamente).
Per alcuni pacchetti magari sì, ma per quelli a cui dobbiamo applicare delle patch o passare parametri di compilazione particolari sarebbe comunque necessario ricreare lo snap.
Senza considerare il discorso della moltiplicazione delle librerie e delle prestazioni (si tratta pur sempre di filesystem squashfs).
Tra l'altro pare che la parte server non sia open e questo sarebbe veramente assurdo.
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 15 Giugno 2016 ore 23:50
Allora vi vedo un pò confusi  :P
Per cui farò un pò di chiarezza.

Gli snap non vanno a sostituirsi ai pacchetti dei repository e non credo che dovremmo distribuirli.
Sono solo un modo per essere sicuri che un determinato programma funzioni a prescindere dal sistema (comunque Linux-based) e dalle librerie installate.
E' estremamente utile nel caso di applicazioni commerciali o comunque proprietarie.

Il problema delle applicazioni proprietarie su linux è che se sviluppo un programma e lo compilo contro delle librerie, basterà che in un sistema una di queste librerie sia di una versione differente da quella con cui l'ho compilata e il programma non funziona.
Ora immaginate quante combinazioni di librerie ci sono in tutte le distro linux.
E immaginate una distro come Chakra/Arch che aggiorna le librerie di tanto in tanto (non come ad esempio Ubuntu che lo fa ad ogni release).
Quante probabilità ci sono che il programma funzioni?
Allora i dev di Ubuntu hanno deciso che se vogliono aprire Linux al mondo delle applicazioni commerciali c'è bisogno di un sistema di distribuzione del software che non tenga conto del sistema sottostante.
Per cui sono nati gli .snap (che poi tra l'altro non sono differenti dagli .exe di win o dagli .app di OS X).

Ovviamente non tutti nel mondo Linux le vedono di buon occhio perchè le vedono come uno spreco di spazio (visto che contengono librerie già presenti nel sistema) ecc.

Però per una distro come Chakra questo apre le porte a tantissimo software che altrimenti non sarebbe stato possibile avere!
Per ora gli .snap possono essere installati dallo store di Ubuntu (serve un account comunque) o si può scaricare il pacchetto e installarlo localmente (un pò come avviene per Steam).


Gli snap sono complementari con i CCR perchè non vanno a toccare il sistema sottostante (sono installati su /tmp su una cartella ad hoc per ognuno di questi che in realtà è un sistema squashfs ad hoc per ogni programma).
Comunque possono essere richiamati da riga di comando e compaiono automaticamente nel menu start.
Secondo me sono più orientati ad applicazioni proprietarie che open (anche se non fa differenza la cosa).


Sto lavorando per ora a farlo funzionare su Chakra (già funziona comunque) ma vorrei mettere altre funzioni, tipo che se clicchi su un pacchetto .snap parte automaticamente l'installazione (tipo come avviene per gli .apk su android).

Se avete altre domande o curiosità non esitate a chiedere  ;)
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 16 Giugno 2016 ore 00:10
Allora vi vedo un pò confusi  :P

Ma anche no! XD

In sostanza sono come i nostri vecchi bundle e temo che possano portarsi dietro gli stessi problemi che si avevano in passato con i suddetti.
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 16 Giugno 2016 ore 00:44
Che problemi c'erano?
Non lo so che ancora non usavo Chakra.
Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 16 Giugno 2016 ore 07:01
Ma anche no! XD

In sostanza sono come i nostri vecchi bundle e temo che possano portarsi dietro gli stessi problemi che si avevano in passato con i suddetti.
beh Franz, una piccola differenza c'è: i bundle erano un mondo chiuso e a parte di Chakra. Gli snap sembra che al momento stiano riscontrando molto interesse in tutta la comunità linux, arcieri compresi (fatto fondamentale). Avere quindi un'infrastruttura in grado di gestire gli snap (come sta cercando di fare gnatyle) renderà la vita facile a chi vorrà installare pacchetti di terze parti o pacchettizzarsene uno.
A prescindere dal fatto che alcuni GTK vengano messi o meno in snap, il fatto di poterli utilizzare IMHO è fondamentale per mantenersi al passo con altre distro molto utilizzate.
Titolo: Re:Chakra brainstorm
Inserito da: alex - 16 Giugno 2016 ore 09:04
Per alcuni pacchetti magari sì, ma per quelli a cui dobbiamo applicare delle patch o passare parametri di compilazione particolari sarebbe comunque necessario ricreare lo snap.
Ma se le applicazioni sono rese più indipendeti dal resto del sistema serve comunque metterci mano?

Citazione
Senza considerare il discorso della moltiplicazione delle librerie e delle prestazioni (si tratta pur sempre di filesystem squashfs).
A parte che quello dello spazio è oggi un problema secondario, leggevo che se delle librerie sono già usate da uno snap non vengono aggiunte di nuovo ma solo linkate. Non so però se attualmente già lo faccia o se è una cosa che si vuole implementare in futuro.

Citazione
Tra l'altro pare che la parte server non sia open e questo sarebbe veramente assurdo.
Qui mi sa che è il punto debole per un eventuale adozione da parte di tutto il mondo linux, che diventerebbe troppo ubuntucentrico. Una specie di market gestito da Canonical....

Ora onestamente non ricordo quali fossero effettivamente i problemi con i vecchi bundle di Chakra, anche se non penso che siano proprio la stessa cosa, comunque quando c'erano li avevo utilizzati per quelle due o tre applicazioni in più che mi servivano.

E oltre che per i software commerciali credo che siano utili anche per quelli open, visto che non sempre le applicazioni vengono aggiornate all'aggiornarsi delle librerie e comunque non con gli stessi tempi.

Ho quotato @Franz per comodità ma sentitevi pure liberi di rispondere alle mie domande da ignorante  ;D

In ogni caso penso che sia un ottima cosa che @gnatyle se ne stia interessando.
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 16 Giugno 2016 ore 12:11
Che problemi c'erano?
Non lo so che ancora non usavo Chakra.
Probabilmente il punto 1 sarà sempre meno un problema, considerando il trend di diffusione degli SSD e l'aumento generale delle prestazioni e per quanto riguarda il 4 gli snap dovrebbero fornire una migliore integrazione a livello di sistema (mi riferisco più che altro agli eseguibili).
Il 2 è un problema serio (rispondo anche ad @alex): per fare un esempio, lo snap di LibreOffice 5.2-beta pesa 1 Gb, contro i 229 Mb del deb: immaginate quanto potranno pesare gli snap di applicazioni già di per sé più grandi di LibreOffice. Lo spazio non è un problema se si usano dischi HDD, ma per gli SSD il prezzo/Gb è ancora troppo alto per rendere accessibile a tutto l'acquisto di dischi con capacità superiori ai 480GB.
Inoltre, tenere la cartella /tmp sulla RAM (come faccio io) diventerebbe possibile solo con enormi quantitativi di memoria.
Il 3 accadrà anche con gli snap: possiamo considerarlo un compromesso.

beh Franz, una piccola differenza c'è: i bundle erano un mondo chiuso e a parte di Chakra. Gli snap sembra che al momento stiano riscontrando molto interesse in tutta la comunità linux, arcieri compresi (fatto fondamentale).
Chiuso non direi, visto che il codice è sempre stato (ed è ancora) a disposizione di tutti.
Chakra, te lo ricorderai, era nota per il sistema dei bundle, ma non mi pare che venissero considerati una gran cosa; adesso invece sembrano l'invenzione del secolo.
Tra parentesi, Arch non li supporta ufficialmente: il porting è stato fatto da alcuni utenti e, infatti, è su AUR.

Avere quindi un'infrastruttura in grado di gestire gli snap (come sta cercando di fare gnatyle) renderà la vita facile a chi vorrà installare pacchetti di terze parti o pacchettizzarsene uno.
A prescindere dal fatto che alcuni GTK vengano messi o meno in snap, il fatto di poterli utilizzare IMHO è fondamentale per mantenersi al passo con altre distro molto utilizzate.

Questo indubbiamente, non sto mettendo in dubbio l'utilità del lavoro di gnastyle.

Quello che non mi convince è il sistema in sé e personalmente non credo che Chakra dovrebbe supportarlo ufficialmente


Ma se le applicazioni sono rese più indipendeti dal resto del sistema serve comunque metterci mano?
Se vuoi applicare delle patch o delle ottimizzazioni che chi ha realizzato lo snap non ha previsto, sì.
Ad esempio, noi applichiamo una serie di patch a Firefox per l'integrazione con KDE, il motore di ricerca, ecc., che sicuramente Mozilla non includerà.
Stesso discorso per LibreOffice, o per altre applicazioni nelle quali disabilitiamo i componenti gtk. Per tutte queste andrebbero comunque ricreati gli snap.


leggevo che se delle librerie sono già usate da uno snap non vengono aggiunte di nuovo ma solo linkate. Non so però se attualmente già lo faccia o se è una cosa che si vuole implementare in futuro.
Se le librerie sono incluse nello snap, questo deve essere montato perché un altro snap possa utilizzarne le librerie, quindi o avvii due snap per usarne solo uno o ne crei uno apposta per la libreria (ma a quel punto non ha più senso lo snap); a meno che gli snap non vengano montati automaticamente all'avvio.
Personalmente penso che sarà difficile implementare questa funzione, ma magari mi sbaglio.

Qui mi sa che è il punto debole per un eventuale adozione da parte di tutto il mondo linux, che diventerebbe troppo ubuntucentrico. Una specie di market gestito da Canonical....
Questo sì che sarebbe un problema, anche considerando che Canonical non sempre si comporta bene con il mondo del software libero

Titolo: Re:Chakra brainstorm
Inserito da: dinolib - 16 Giugno 2016 ore 13:13
Grazie franz x il tempo dedicato a rispondere.

Concordo con le tue osservazioni. Ribadisco che forse l'unica vera importanza degli snap oggi è che per la prima volta si ha la possibilità di pacchettizzare in un formato unico e compatibile su tutte le distro e versioni dei sistemi. I bundle non erano stati seguiti da altre distro forse perchè Chakra da alcuni veniva snobbata per le limitate dimensioni e la scarsità (di numero  ;D) dei dev.
Oggi se prenderà piede il discorso snap sarà utilissimo sia per app acquistate, sia per mantenere retrocompatibilità di vecchi programmi, sia per provare programmi disponibili su altre distro e difficilmente portabili sul nostro.

Comunque direi di attendere i primi risultati e tornarne a parlare. Forse il discorso è un po' prematuro.  ;)
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 16 Giugno 2016 ore 13:42
Concordo con dinolib, gli snap sono utili perchè aprono le porte del software commerciale anche su Linux.
Se ci pensate bene i giochi su Linux hanno preso piede solo perchè c'è un store unico che li distribuisce,
altrimenti pensate che fatica per ogni sviluppatore supportare tutte le distro.

E aiuterebbe tutti gli sviluppatori di software open poco conosciuti, perchè non avrebbero bisogno di pacchettizzare il programma per 3453453 distro diverse ma gli basterebbe un formato solo (e i CCR non possono sempre aiutare perchè non tutto il sofwtare è disponibile li e non tutti hanno il tempo di compilare il programma da installare).

Si, penso anche io che il problema con i bundle di Chakra fosse che erano una cosa a parte mentre gli snap vengono fatti direttamente dagli sviluppatori.

@FranzMari
Per quanto riguarda i problemi con i bundle:
1-ho provato solo qualche programma leggero ma non mi sembrano lenti, forse il fatto di usare un fs a parte aiuta l'applicazione. Dovrò testarlo con qualche app più pesante.
2-sicuro che sono più pesanti. Libreoffice credo sia un'eccezione perchè è molto esagerato.
3-sicuramente
4-si questo credo sia ancora un problema, forse devono essere i dev dell'app a doversi preoccupare di questa cosa

poi comunque ripeto che i gli snap servono in determinati casi. Mozilla ad esempio ha detto che distribuirà firefox con gli snap per permettere di usare l'ultima versione di firefox pure su piattaforme (tipo debian stable) che non hanno librerie abbastanza aggiornate.

Ma in molti altri casi il software dei repo è da preferire sicuramente per i motivi che ha elencato Franz.
Questo è più un aiuto per il SW commerciale o non contenuto nei repository.

Quella storia delle librerie linkate non la so e non so se sia vera. Comunque per ora mi limito a preoccuparmi che tutto funzioni.

Si poi il market gestito da canonical è troppo ubuntucentrico, ma sicuramente è necessario.
Probabilmente ci ritroveremo in una situazione come Android (parlo solo per gli snap ovviamente, non per le altre applicazioni) dove c'è Ubuntu  che gestisce lo store, ma allo stesso tempo nessuno vieta di aprire altri store (magari solo con software open come F-droid) o di distribuire gli .snap come si faceva con i .deb o gli .rmp.


Un'ultima cosa: i flatpak sono un altro modo di avere i sofwtare in bundle (l'idea è di Gnome e ora anche KDE la sta seguendo), ma c'è una piccola differenza con gli .snap. I flatpak hanno delle dipendenze (si chiamano runtime) e anche quelle sono multipiattaforma e sono gestite da chi le crea (tipo il runtime di KDE è gestito da KDE ecc.).
Anche se solo le dipendenze più grandi diventano runtime (le librerie saranno in bundle esattamente come per gli .snap).
Però questo dovrebbe ridurre la ridondanza e lo spreco di spazio.
C'è un dev di KDE che ci sta lavorando ma credo che ci vorrà ancora qualche altro mese.
Titolo: Re:Chakra brainstorm
Inserito da: alex - 16 Giugno 2016 ore 14:40
Un'ultima cosa: i flatpak sono un altro modo di avere i sofwtare in bundle (l'idea è di Gnome e ora anche KDE la sta seguendo), ma c'è una piccola differenza con gli .snap. I flatpak hanno delle dipendenze (si chiamano runtime) e anche quelle sono multipiattaforma e sono gestite da chi le crea (tipo il runtime di KDE è gestito da KDE ecc.).
Anche se solo le dipendenze più grandi diventano runtime (le librerie saranno in bundle esattamente come per gli .snap).
Però questo dovrebbe ridurre la ridondanza e lo spreco di spazio.
C'è un dev di KDE che ci sta lavorando ma credo che ci vorrà ancora qualche altro mese.
Quindi sarebbe più coerente per Chakra orientarsi sui flatpak, se KDE si orienta su questi.
Alla fine ho capito solo che il tutto è ancora in alto mare, vedremo cosa salta fuori  :)
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 19 Giugno 2016 ore 12:45
Allora snap funziona (quasi) perfettamente su Chakra!

Intanto un paio di precisazioni. Gli snap non vengono installati su /tpm ma su /snap.
Poi (purtroppo) sono una tecnologia ancora giovane, quindi ancora non tutto funziona perfettamente.
Un problema è che quando installi un programma, non sempre l'icona appare sul launcher oppure devi aspettare un riavvio. Probabilmente questo problema verrà risolto in futuro. Nel caso per provare un programma basta andare su /snap/bin e cliccare sul programma desiderato.

Per il resto funziona più o meno tutto, basta scaricare uno .snap, cliccarci sopra, dare la password e il programma verrà installato.
Solo la prima volta ci vuole più tempo che deve scaricare ubuntu-core, ma per il resto ci vogliono solo pochi secondi.

Per chi volesse provare ecco lo .snap di libreoffice http://people.canonical.com/~bjoern/snappy/libreoffice_5.2.0.0.beta2_amd64.snap

@Franz
Dici che lo dovrei importare direttamente su [desktop] invece di passare per CCR?
Per me è pronto (tranne qualche piccolo bug) per essere utilizzato in maniera continua.
Titolo: Re:Chakra brainstorm
Inserito da: gnastyle - 19 Giugno 2016 ore 12:50
@Alex
Per rispondere alla tua domanda.
Allora non è proprio vero che è tutto in alto mare. Per ora gli .snap ci sono e funzionano.
Per i flatpak dovremo aspettare ancora.
Comunque Chakra non deve orientarsi su niente.
Questi nuovi formati sono per uso esterno al package manager, e servono per lo più per programmi commerciali (secondo me).
Io mi limiterei a supportare entrambi i formati, poi saranno gli utenti a decidere se e quando usarli.
Comunque KDE ha deciso di fornire sia .snap che .flatpak quindi entrambe vanno bene.

Poi magari quando comincerà ad arrivare qualche snap in più fateci sapere come vanno  ;)
Titolo: Re:Chakra brainstorm
Inserito da: FranzMari - 19 Giugno 2016 ore 23:37
@Franz
Dici che lo dovrei importare direttamente su [desktop] invece di passare per CCR?
Per me è pronto (tranne qualche piccolo bug) per essere utilizzato in maniera continua.

Assolutamente no!
Intanto caricalo su CCR.
L'importazione nei repo ufficiali deve essere discussa con tutti gli altri.
Titolo: Re:Chakra brainstorm
Inserito da: alex - 20 Giugno 2016 ore 14:48
@gnastyle  grazie  :)