UFFICIALE L'OT di Linux e altri OS

Pubblicità
Mai usato snappy, per cui non so dirti. Un package manager deve fare quello che é il suo compito, ovvero gestire l'installazione/rimozione dei programmi. Se uno ci mette 20 anni, mentre l'altro 5 secondi, per me il migliore é il secondo(e non sono l'unico a dirlo)
Ripeto, non c'è questa differenza di prestazioni tra package manager... Poi su Debian e Ubuntu è abbastanza veloce, non vedo sta lentezza, forse su Btrfs rispetto a ext4, può perdere prestazioni su HDD meccanici.
Te lo dico perché con molti utenti Arch, abbiamo tirato fuori questo flame APT vs pacman, e li abbiamo testati anche in performance e sono il per li.
Sai che APT è uno dei motivi del perché hanno scelto Ubuntu in casa Google sui desktop dei dipendenti?
That said, Bushnell was asked why Ubuntu instead of say Fedora or openSUSE? He replied, “We chose Debian because packages and apt [Debian's basic software package programs] are light-years ahead of RPM (Red Hat and SUSE's default package management system.]” And, why Ubuntu over the other Debian-based Linux distributions? “Because it's release cadence is awesome and Canonical [Ubuntu's parent company] offers good support.”
Tradotto:
Detto questo, Bushnell è stato chiesto il motivo per cui Ubuntu, invece di dire Fedora oopenSUSE ? Egli rispose: “Abbiamo scelto Debian perché i pacchetti e apt [programmi del pacchetto software di base di Debian] sono anni luce più avanti di RPM (Red Hat e SUSE del sistema di gestione dei pacchetti di default.]”

Fonte:
http://www.zdnet.com/article/the-truth-about-goobuntu-googles-in-house-desktop-ubuntu-linux/
 
Ripeto, non c'è questa differenza di prestazioni tra package manager... Poi su Debian e Ubuntu è abbastanza veloce, non vedo sta lentezza, forse su Btrfs rispetto a ext4, può perdere prestazioni su HDD meccanici.
Te lo dico perché con molti utenti Arch, abbiamo tirato fuori questo flame APT vs pacman, e li abbiamo testati anche in performance e sono il per li.
Sai che APT è uno dei motivi del perché hanno scelto Ubuntu in casa Google sui desktop dei dipendenti?

Tradotto:


Fonte:
http://www.zdnet.com/article/the-truth-about-goobuntu-googles-in-house-desktop-ubuntu-linux/
Beh, non c'é da sorpendersi. Apt é decente ed Ubuntu é la più "affidabile". Mi pare quasi una scelta obbligata.
Ripeto, ci ho messo molto ma molto meno ad installare xfce, lxdm ed un'altra cosa con xbps che xfce con apt( non mi é nemmeno sembrato reale)
E' come fare un paragone fra una tartaruga ed un cavallo..
 
Beh, non c'é da sorpendersi. Apt é decente ed Ubuntu é la più "affidabile". Mi pare quasi una scelta obbligata.
Ripeto, ci ho messo molto ma molto meno ad installare xfce, lxdm ed un'altra cosa con xbps che xfce con apt( non mi é nemmeno sembrato reale)
E' come fare un paragone fra una tartaruga ed un cavallo..
Non conosco questo package manager, però da quel poco che ho letto è scritto da 0, uno dei suoi obbiettivi sono la velocità... quindi secondo me è da paragonare a snappy.
Un package manager prima di tutto deve essere affidabile, poi se è veloce ok, ma quante volte installi un DE intero?? download finito con APT a installare xfce ci metti meno di 5 minuti.
PS: APT supporta le installazioni DELTA, cosi come snappy...
 
Non conosco questo package manager, però da quel poco che ho letto è scritto da 0, uno dei suoi obbiettivi sono la velocità... quindi secondo me è da paragonare a snappy.
Un package manager prima di tutto deve essere affidabile, poi se è veloce ok, ma quante volte installi un DE intero?? download finito con APT a installare xfce ci metti meno di 5 minuti.
Affidabile? Mi installa un programma? Sì? Bene, é affidabile. Beh, se il risultato é il medesimo, vado a privilegiare é la velocitá(anche perché negli upgrade massicci si sente)
 
Poi non hai idea di quante cose puoi fare con APT, puoi anche compilare il kernel con APT: apt-build o i pacchetti che vuoi, o tutti i pacchetti...
Ok, tu vai a vedere la velocità, ma di certo non scelgo una distro con un nuovo package manager, dove ci sono pochissimi pacchetti, dove ha un terzo delle funzionalità, alla fine non mi frega se per installare un pacchetto ci metti 1 secondo in meno...
A me snappy piace non perché è molto è piu veloce degli altri package manager, ma per come gestisce i pacchetti: sicurezza, senza dipendenze, le app le puoi creare con tutte le dipendenze incluse o condividi le librerie con il framework, aggiornamenti delta, rollback, compressione (gli snap sono su file system squashfs) etc etc
 
Ultima modifica:
Poi non hai idea di quante cose puoi fare con APT, puoi anche compilare il kernel con APT: apt-build o i pacchetti che vuoi, o tutti i pacchetti...
Ok, tu vai a vedere la velocità, ma di certo non scelgo una distro con un nuovo package manager, dove ci sono pochissimi pacchetti, dove ha un terzo delle funzionalità, alla fine non mi frega se per installare un pacchetto ci metti 1 secondo in meno...
A me snappy piace non perché è molto è piu veloce degli altri package manager, ma per come gestisce i pacchetti: sicurezza, senza dipendenze, le app le puoi creare con tutte le dipendenze incluse o condividi le librerie con il framework, aggiornamenti delta, rollback, compressione (gli snap sono su file system squashfs) etc etc
Xbps può compilare pure i pacchetti, tranquillo.
Void é nuova, per cui, salvo imprevisti, il numero di pacchetti crescerá, così come le migliorie(personalmente non ho trovato alcuna mancanza fino ad ora ;)).
Flatpak dovrebbe arrivare "presto" ovunque, per cui.....(ah, su void c'é :D)
 
@lele.deb anche io trovo estremamente lento apt. ogni volta che devo aggiornare il server oppure il pc di mia sorella o degli amici che hanno ubuntu, ci metto sempre il doppio del tempo.

riguardo la compilazione del kernel, poco mi importa. apt avrà pure mille funzioni belle che magari altri gestori non hanno, ma... chi se ne frega se poi non le utilizzo? xD

per quello che faccio io, avere mille funzioni ed essere decisamente più lento della concorrenza nelle operazione quotidiane, non ha senso... e non lo fa di certo essere il migliore.

che poi, questa presunta instabilità di pacman, io ancora la devo vedere/capire
 
@rebellion Così com'è e abilitando il timer senza dar lo start, al riavvio mi cambia lo sfondo. Funzionava anche prima della modifica che ho fatto ora perché leggendo il man, il wantedby nel .service (in presenza di un timer) non serve. Un wantedby .target non ha questa grande funzione.
cambiato il fuorilegge ricercato (WantedBy=timers.target :asd: nel servizio e nel timer) e tutto funziona a meraviglia anche al reboot. @e_ale92 : :P
 
cambiato il fuorilegge ricercato (WantedBy=timers.target :asd: nel servizio e nel timer) e tutto funziona a meraviglia anche al reboot. @e_ale92 : :P
ho reinstallato snapper e.... snapper-boot.timer non funziona ahahahah

ora, siccome quel service/timer non l'ho creato io, com'è possibile che non funzioni? nonostante risulti attivo, non crea nessuno snapshot al boot.

a questo punto o mi sfugge qualcosa, oppure boh. sicuro è che devo fare dei test, magari usando i vostri script... dato che a voi funzionano
 
Xbps può compilare pure i pacchetti, tranquillo.
Void é nuova, per cui, salvo imprevisti, il numero di pacchetti crescerá, così come le migliorie(personalmente non ho trovato alcuna mancanza fino ad ora ;)).
Flatpak dovrebbe arrivare "presto" ovunque, per cui.....(ah, su void c'é :D)
Snappy ad oggi è molto più avanti di flatpak, molto piu semplice, Già esiste un Os interamente basato su Snap: Ubuntu core, che domina su IOT.

Installazione LibreOffice snap:
Installare LibreOffice dallo store
Le versioni correnti di LibreOffice sono disponibili nello store di Ubuntu per amd64.

Se snapd è già installato nel vostro sistema, tutto ciò che dovete fare per installare LibreOffice dallo store è:

sudo snap install --channel=beta libreoffice
Se il comando snap non viene riconosciuto, dovete prima installare snapd.

Eseguire la versione di LibreOffice installata come snap
Dopo l'installazione, la versione snap di LibreOffice può essere avviata con il seguente comando:

/snap/bin/libreoffice
Omettendo il percorso completo è probabile che venga avviata, se presente, la versione di LibreOffice installata dalla distribuzione.

Installazione LibreOffice flatpak:
  • $ wget https://sdk.gnome.org/keys/gnome-sdk.gpg
    $ flatpak remote-add --user --gpg-import=gnome-sdk.gpg gnome https://sdk.gnome.org/repo/
    $ flatpak install --user gnome org.gnome.Platform 3.20

    Se utilizzate una lingua diversa dall'inglese (en-US), e volete che LibreOffice utilizzi automaticamente l'interfaccia localizzata nella stessa lingua, aggiungete:
    $ flatpak install --user gnome org.gnome.Platform.Locale 3.20
  • Poi, con il file LibreOffice.flatpak scaricato dal pulsante “Scaricate”, eseguite:
    $ flatpak install --user --bundle LibreOffice.flatpak
    per installarlo. (Non preoccupatevi, questa installazione non interferisce con nessun'altra installazione di LibreOffice già presente sulla vostra macchina, come ad esempio quella fornita con la vostra distribuzione Linux.)
  • Ora potete eseguirlo, sia dalla riga di comando
    $ flatpak run org.libreoffice.LibreOffice
 
ho reinstallato snapper e.... snapper-boot.timer non funziona ahahahah

ora, siccome quel service/timer non l'ho creato io, com'è possibile che non funzioni? nonostante risulti attivo, non crea nessuno snapshot al boot.

a questo punto o mi sfugge qualcosa, oppure boh. sicuro è che devo fare dei test, magari usando i vostri script... dato che a voi funzionano
il mio script non esegue comandi che necessitino di privilegi per la qual cosa ho messo nella mia home il timer e il servizio. per quel poco che ho letto forse potresti avere problemi di permessi o devi aspettare che prima si avvii qualche servizio?
mi posti nei CODE il servizio e il timer che nei vari post li ho persi?
 
il mio script non esegue comandi che necessitino di privilegi per la qual cosa ho messo nella mia home il timer e il servizio. per quel poco che ho letto forse potresti avere problemi di permessi o devi aspettare che prima si avvii qualche servizio?
mi posti nei CODE il servizio e il timer che nei vari post li ho persi?
service e timer di snapper sono in /usr/lib/systemd/system, quindi nessun problema di permessi :look:

cmq appena accendo il pc te li posto :)

edit.
ho trovato l'inghippo. io snappo in un subvol dedicato che viene montato in /.snapshots prima di eseguire lo snapshot. se non lo monto, lui snappa in /.snapshots che però è "vuota" dato che il subvol non è stato montato. insomma, lui snappa, ma di fatto gli snapshot "non ci sono"
gli script sono questi:

Codice:
[Unit]
Description=Take snapper snapshot of root on boot

[Service]
Type=oneshot
ExecStart=/usr/bin/snapper --config root create --cleanup-algorithm number --description "boot"

Codice:
[Unit]
Description=Take snapper snapshot of root on boot

[Timer]
OnBootSec=1

[Install]
WantedBy=timers.target

devo solo capire come montare @snapshots in /.snapshots... e poi come smontarlo :asd:
il passo successivo sarà modificare OnBootSec=1 in OnUnitActiveSec=1w tempo permettendo :asd: :rock:
 
Ultima modifica:
Io sta cosa di @Snapshots non l' ho ancora capita. :doh:
Come lo hai creato 'sto subvol, durante l' installazione del sistema? Ho visto nei precedenti che sta in /dev/sda2, la stessa partizione di @ e @home, quindi al tempo dell' installazione hai dato il comando ''btrfs subvolume create /mnt/@Snapshots'' oppure in post installazione, cioè con sistema avviato e funzionante?
Non è che sotto / c'è una cartella di nome /@Snapshots (magari l' hai cancellata)?

EDIT. sono ritornato al tuo vecchio sistema ma non mi trovo. credo che in questi casi non sapere cosa succede sotto al cofano sia meglio :sisi:
sbaglio o il tuo sistema
- Creo la cartella in /mnt/btrfs per montare @;
# mkdir /mnt/btrfs
- Monto la radice / dando per scontato che il disco/partizione sia /dev/sda1;
# mount -t btrfs -o subvol=/ /dev/sda1 /mnt/btrfs/
- Creo un subvol ove andrò a depositare gli snapshots e lo chiamo snap;
# btrfs subvolume create /mnt/btrfs/snap
- Snappo la radice / che sappiamo essere nel subvol @;
# btrfs subvolume snapshot -r /mnt/btrfs/@ /mnt/btrfs/snap
- Smonto /mnt/btrfs che sappiamo essere il punto di mount del subvol=/.
# umount /mnt/btrfs
non permette snapshot multipli? mi spiego: creato uno snapshot di @ non me ne fa creare un'altro perché dice che è già presente. snapper creava le cartelle 1 2 3 4 .. N in cui salvava i vari snapshot. timeshift-btrfs le rinominava addirittura con la data.

Sì, ma quello era uno schemino per spiegare come facesse timeshift-btrfs s/montare la directory per gli snap.
Non ricordo la tua configurazione e ho riletto un po' i tuoi topic, ma avrei più domande che risposte. Il fatto stesso di voler usare usare @Snapshots no lo capisco.
Ti mostro come faccio quella morte di papa che snappo.
Codice:
.1 Ho creato una cartella /mnt;
# /mnt/btrfs/
.2 Monto la radice /, non sto lì a montare @ o solo @home, io monto tutto;
# mount -o subvol=/ /dev/sda3 /mnt/btrfs
.3 Ho creato un paio di cartelle tanto per avere un po' di ordine;
# mkdir -p /mnt/btrfs/snap-home /mnt/btrfs/snap-root
.4 In base a ciò che voglio snappare (@ oppure @home), lancio il comando
# btrfs subvolume snapshot /home /mnt/btrfs/snap-home/home-$(date +%H.%M-%d-%m-%y)
oppure
# btrfs subvolume snapshot / /mnt/btrfs/snap-root/root-$(date +%H.%M-%d-%m-%y)
.5 Smonto il tutto e tutto scompare;
# umount /mnt/btrfs
Il risultato è questo:
Create a snapshot of '/home' in '/mnt/btrfs/snap-home/home-00.29-06-06-17'
Create a snapshot of '/' in '/mnt/btrfs/snap-root/root-00.29-06-06-17'

Ovvio che lo snap non può avere lo stesso nome di uno snap (o file) esistente, infatti inserisco nel nome data compresa di ore e minuti.

A parte la creazione delle cartelle, il resto può finire dentro uno script semplice.
Script:
Codice:
#!/bin/bash

mount -o subvol=/ /dev/sda3 /mnt/btrfs
btrfs subvolume snapshot / /mnt/btrfs/snap-root/root-$(date +%d-%B-%y_%T)
btrfs subvolume snapshot /home /mnt/btrfs/snap-home/home-$(date +%d-%B-%y_%T)
umount /mnt/btrfs
exit 0

Timer settimanale
Codice:
[Unit]
Description=Snap Settimanale - Ogni Venerdì alle 00:00:00

[Timer]
OnCalendar=Fri *-*-* 00:00:00
Persistent=true

[Install]
WantedBy=timers.target

Service:
Codice:
[Unit]
Description=Snap Settimanale

[Service]
Type=oneshot
ExecStart=/path/to/script-snap

Non avendo queste grandi esigenze, io faccio tutto a manina. :P
 
cut.

Non avendo queste grandi esigenze, io faccio tutto a manina. :P

momy... non mi fare tutte ste domande perché mi mandi in crisi :lol: ho già detto che sono nabbo e che quello che faccio è sicuramente sbagliato. non ho capito come gestire bene sti cavolo di snapshot e quindi mi sono affidato un po' all'istinto, un po' alle prove.

@snapshots l'ho creato al momento dell'installazione... poi l'ho rimosso... ricreato... rimosso e ora ricreato xD è un subvol con id 5, quindi è a monte di tutto... in pratica ho:

@ @home @snapshots

quando snappo, monto @snapshots in /.snapshots (cartella creata da snapper per la configurazione "root") e ci snappo dentro. quando ho finito, smonto /.snapshots

praticamente è la stessa cosa che fai tu, solo che io la faccio con snapper. le mie cartelle di snapshot si chiamano 1 2 3 4 etc. mentre le tue root-(data). altra differenza, se do "snapper list" ottengo una tabella con numero-data-descrizione della lista degli snapshot fatti... cosa che btrfs non so se fa o come dà in output.

ma i funzionamenti sono gli stessi :sisi:

ah, tu hai creato il service a mano, snapper li crea di default, insieme ad uno utile per gestire la pulizia automatica dei vecchi snapshot, secondo delle regole impostate in un file config.

ora, siccome la tua soluzione mi piace di più perché:
1. gli snapshot hanno la data anche nella cartella
2. non utilizzi un'applicazione esterna
potresti darmi l'output di
Codice:
btrfs subvolume list -p /
magari su un sistema contenete qualche snapshot

p.s. grazie! :)
 
Pubblicità
Pubblicità
Indietro
Top