Pagine web da aggiornare

2023-04-28 Per discussione Debian WWW translation watch
Buongiorno,
questo messaggio automatico è inviato in quanto sei responsabile
della traduzione in italiano di alcune pagine del sito web Debian.
Hai richiesto di inviare le seguenti informazioni:
  summary: settimanale
  logs: mai
  diff: mai
  tdiff: mai
  file: mai

Puoi cambiare:
  - la frequenza dei messaggi (mai, quotidiana, settimanale,
mensile) ;
  - le informazioni che vuoi ricevere:
* il riassunto dei file da aggiornare
* i messaggi del log tra la versione aggiornata e l'ultima tradotta
* le differenza tra la versione aggiornata e l'ultima tradotta
* i file completi da aggiornare
  - il tuo indirizzo di posta elettronica

Per qualsiasi domanda su questo messaggio, invia un email alla
lista debian-l10n-italian@lists.debian.org
NeedToUpdate italian/devel/debian-live/index.wml from revision 
8377a51d59273f2581a58118cb3505bcdc6fce1c to revision 
f341c54f97dcf8aecbb46b46c516c2d8a1d51d96 (maintainer skizzhg)
NeedToUpdate italian/doc/vcs.wml from revision 
bf1a0486dfbf35e11a7ff98a29d9e2e4f2eda3f3 to revision 
e6e987deba52309df5b062b1567c8f952d7bd476 (maintainer skizzhg)
NeedToUpdate italian/intro/search.wml from revision 
821d2af3a565be7b911813a3fb1a5543be4391e6 to revision 
6686348617abaf4b5672d3ef6eaab60d594cf86e (maintainer Johan Haggi)
NeedToUpdate italian/mirror/list.wml from revision 
c1ef6c3811be792e129656bbfcf09866d9880eb5 to revision 
b554c22abdbc4a6253951c9bf9610405d0c4f2cd (maintainer skizzhg)
NeedToUpdate italian/social_contract.1.0.wml from revision 
5477c3c791fabf2db59622d9eec1061b6f73aa57 to revision 
79d1ad80a8ac84afa8c8a224b81fb50c327e6b4f (maintainer Johan Haggi)
NeedToUpdate italian/social_contract.wml from revision 
c505e01dd6ca2b53d9a229a691d0c2b20c48b36b to revision 
79d1ad80a8ac84afa8c8a224b81fb50c327e6b4f (maintainer Johan Haggi)


Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Marco Ciampa
On Fri, Apr 28, 2023 at 02:20:44PM +0200, Diego Zuccato wrote:
> Il 28/04/2023 13:35, Marco Ciampa ha scritto:
> 
> > No non lo è. E zfs ha seri problemi di licenze (e altri problemi tecnici
> > che btrfs non ha e viceversa, vedi RAID)
> Scusa, potresti articolare meglio?

Si scusa...

> btrfs ha problemi col RAID?

con alcune tipologie di RAID si. Sto parlando di funzionalità
_integrate_, _non_ uso di RAID con SOPRA btrfs. Quest'ultimo funziona
SEMPRE.

> O intendevi che non ha la funzionalità RAID integrata come ZFS?

No intendo cha ha _alcune_ funzionalità RAID integrate (RAID 5 e 6 mica
poco...) ma che alcune _non_ funzionano in maniera affidabile come con
ZFS o il RAID software di Linux o il RAID integrato nelle ultime versioni
di LVM.

Ma le cose stanno (lentamente) evolvendo...

https://btrfs.readthedocs.io/en/latest/Status.html

> Adesso oltre tutto mi hai messo la pulce nell'orecchio e mi tocca indagare
> sulla compatibilità ZFS-Gluster... :)

Ma no, credo che lì non avrai problemi. Mentre ZFS ha altre rogne.

1) la licenza, fatta "apposta" per "rompere" (al)la comunità Linux 

https://itsfoss.com/linus-torvalds-zfs/

2) la gestione dei volumi con ZFS è "primitiva" a dir poco. Leggetevi la
differenza con btrfs qui per esempio: 

https://markmcb.com/2020/01/07/five-years-of-btrfs/

Sto aspettando che sistemino il RAID5 e 6 per passare definitivamente ad
un sistema btrfs _only_ senza RAID software e senza LVM di mezzo.

-- 

Amike,
Marco Ciampa



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Marco Ciampa
On Fri, Apr 28, 2023 at 10:35:13AM +0200, Diego Zuccato wrote:
> Seee... magari! Comunque ho già visto i 20T CMR e i 22T SMR... in server che
> ne portano 90!
> Ora sto scancherando proprio con quei dischi: se usati singolarmente vanno
> benissimo (con dd leggo a 190M/s di media su tutto il disco, con punte di
> 250M/s), ma se metto in RAID i primi 5 dopo un po' si blocca o segnala due
> dischi guasti :(

SMR chiaro, e con qualsiasi fs ci monti sopra. Per NAS sono tabù...
ricostruzione / check di ARRAY / RAID / RAIDZ che durano settimane... In
realtà la segnalazione di guasto deriva dal fatto che il NAS dopo un po'
di ore (giorni) va (giustamente) in timeout e dichiara forfait segnando
il disco come guasto ...

Chi %%% ha inventato i dischi SMR... utili solo in ambiente desktop...

-- 

Amike,
Marco Ciampa



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Piviul

On 4/28/23 15:11, Piviul wrote:

On 4/28/23 07:54, Diego Zuccato wrote:
Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle 
mie macchine, finché un aggiornamento non le ha brickate (supporto 
reiserfs rimosso dal kernel). Problema limitato per root e home, più 
rognoso per i dischi dati... :(


Quello che non mi convince molto del disabilitare il check è: cosa 
trova se lo abiliti e fai uno shutdown pulito? Non vedere gli errori 
è un po' come ignorare un memory leak... Su un desktop può non essere 
grave, ma su un server è meglio evitare. Se xfs_repair -L ha 
impiegato più di 4 ore per il controllo di *un* disco da 12T, quanto 
ci avrebbe messo l'equivalente fsck.ext4 ?


Scusa ma chi è che usa un disco da 12T con un'unica partizione? In 
ogni caso un fsck.ext4 anche su un volume di pochissimi tera mette a 
dura prova... ma btrfs o xfs hanno un sistema di filesystemcheck molto 
più veloce?


comunque ho fatto una prova, volume di  3T non cachato su disco 
meccanico da 12T:


# date && fsck.ext4 -f /dev/backup-server-vg/nas1-backup && date
Fri 28 Apr 2023 03:21:12 PM CEST
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/backup-server-vg/nas1-backup: 5688300/201326592 files (0.6% 
non-contiguous), 731688406/805306368 blocks

Fri 28 Apr 2023 03:24:35 PM CEST
# mount -a
# df -h /dev/backup-server-vg/nas1-backup
Filesystem   Size  Used Avail Use% 
Mounted on
/dev/mapper/backup--server--vg-nas1--backup  3.0T  2.7T  138G  96% 
/srv/backups/nas1

# lvs /dev/backup-server-vg/nas1-backup
  LV  VG   Attr   LSize Pool Origin Data% 
Meta%  Move Log Cpy%Sync Convert

  nas1-backup backup-server-vg -wi-ao 3.00t

poco più di 3 minuti... mi sembra ad occhio accettabile; xfs o btrfs 
farebbe di meglio?


Piviul




Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Piviul

On 4/28/23 07:54, Diego Zuccato wrote:
Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle 
mie macchine, finché un aggiornamento non le ha brickate (supporto 
reiserfs rimosso dal kernel). Problema limitato per root e home, più 
rognoso per i dischi dati... :(


Quello che non mi convince molto del disabilitare il check è: cosa 
trova se lo abiliti e fai uno shutdown pulito? Non vedere gli errori è 
un po' come ignorare un memory leak... Su un desktop può non essere 
grave, ma su un server è meglio evitare. Se xfs_repair -L ha impiegato 
più di 4 ore per il controllo di *un* disco da 12T, quanto ci avrebbe 
messo l'equivalente fsck.ext4 ?


Scusa ma chi è che usa un disco da 12T con un'unica partizione? In ogni 
caso un fsck.ext4 anche su un volume di pochissimi tera mette a dura 
prova... ma btrfs o xfs hanno un sistema di filesystemcheck molto più 
veloce?


Piviu





Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Diego Zuccato

Il 28/04/2023 13:35, Marco Ciampa ha scritto:


No non lo è. E zfs ha seri problemi di licenze (e altri problemi tecnici
che btrfs non ha e viceversa, vedi RAID)

Scusa, potresti articolare meglio?
btrfs ha problemi col RAID? O intendevi che non ha la funzionalità RAID 
integrata come ZFS?
Adesso oltre tutto mi hai messo la pulce nell'orecchio e mi tocca 
indagare sulla compatibilità ZFS-Gluster... :)


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Marco Ciampa
On Fri, Apr 28, 2023 at 09:48:45AM +, Paride Desimone wrote:
> Il 27-04-2023 14:55 Marco Ciampa ha scritto:
> 
> > e comunque io preferisto btrfs anche se aspetto che Ubuntu lo metta di
> > default come OpenSuse per averne tutti i vantaggi "di sistema". Per ora
> 
> Credo che aspetterai all'infinito ed oltre. Ubuntu si sta indirizzando da
> tempo su zfs.
> Che poi per soluzioni desktop, non vedo l'utilità. zfs per funzionare al
> pieno delle sue capacità, ha bisogno di ram, tanta ram. Ovviamente deve
> essere ecc. btrfs, non lo conosco, ma suppongo che se abbia funzionalità
> simili, anch'esso sia "ramgivoro".

No non lo è. E zfs ha seri problemi di licenze (e altri problemi tecnici
che btrfs non ha e viceversa, vedi RAID)

-- 

Amike,
Marco Ciampa



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Diego Zuccato
Seee... magari! Comunque ho già visto i 20T CMR e i 22T SMR... in server 
che ne portano 90!
Ora sto scancherando proprio con quei dischi: se usati singolarmente 
vanno benissimo (con dd leggo a 190M/s di media su tutto il disco, con 
punte di 250M/s), ma se metto in RAID i primi 5 dopo un po' si blocca o 
segnala due dischi guasti :(


Diego

Il 28/04/2023 10:29, Marco Ciampa ha scritto:

On Fri, Apr 28, 2023 at 07:54:30AM +0200, Diego Zuccato wrote:

Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle mie
macchine, finché un aggiornamento non le ha brickate (supporto reiserfs
rimosso dal kernel). Problema limitato per root e home, più rognoso per i
dischi dati... :(

Quello che non mi convince molto del disabilitare il check è: cosa trova se
lo abiliti e fai uno shutdown pulito? Non vedere gli errori è un po' come
ignorare un memory leak... Su un desktop può non essere grave, ma su un
server è meglio evitare. Se xfs_repair -L ha impiegato più di 4 ore per il
controllo di *un* disco da 12T, quanto ci avrebbe messo l'equivalente
fsck.ext4 ?



L'unica è provare... non hai un disco da 12T che ti avanza per caso?

:-))



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Paride Desimone

Il 27-04-2023 14:55 Marco Ciampa ha scritto:


e comunque io preferisto btrfs anche se aspetto che Ubuntu lo metta di
default come OpenSuse per averne tutti i vantaggi "di sistema". Per ora


Credo che aspetterai all'infinito ed oltre. Ubuntu si sta indirizzando 
da tempo su zfs.
Che poi per soluzioni desktop, non vedo l'utilità. zfs per funzionare al 
pieno delle sue capacità, ha bisogno di ram, tanta ram. Ovviamente deve 
essere ecc. btrfs, non lo conosco, ma suppongo che se abbia funzionalità 
simili, anch'esso sia "ramgivoro".


/paride
--
https://keyserver.gnupg.org/pks/lookup?op=get=0xf14cd648d16d33c82a7d2ac778c59a24690431d3

Chi e' pronto a rinunciare alle proprie liberta' fondamentali per 
comprarsi briciole di temporanea sicurezza non merita ne' la liberta' 
ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, 
Assemblea della Pennsylvania, 11 novembre 1755)




Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Marco Ciampa
On Fri, Apr 28, 2023 at 07:54:30AM +0200, Diego Zuccato wrote:
> Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle mie
> macchine, finché un aggiornamento non le ha brickate (supporto reiserfs
> rimosso dal kernel). Problema limitato per root e home, più rognoso per i
> dischi dati... :(
> 
> Quello che non mi convince molto del disabilitare il check è: cosa trova se
> lo abiliti e fai uno shutdown pulito? Non vedere gli errori è un po' come
> ignorare un memory leak... Su un desktop può non essere grave, ma su un
> server è meglio evitare. Se xfs_repair -L ha impiegato più di 4 ore per il
> controllo di *un* disco da 12T, quanto ci avrebbe messo l'equivalente
> fsck.ext4 ?
> 

L'unica è provare... non hai un disco da 12T che ti avanza per caso?

:-))

-- 

Amike,
Marco Ciampa



Re: PC Desktop nuovo: Grub e dischi

2023-04-28 Per discussione Diego Zuccato
Brutta storia quella di Hans Reiser... Anche io usavo reiserfs sulle mie 
macchine, finché un aggiornamento non le ha brickate (supporto reiserfs 
rimosso dal kernel). Problema limitato per root e home, più rognoso per 
i dischi dati... :(


Quello che non mi convince molto del disabilitare il check è: cosa trova 
se lo abiliti e fai uno shutdown pulito? Non vedere gli errori è un po' 
come ignorare un memory leak... Su un desktop può non essere grave, ma 
su un server è meglio evitare. Se xfs_repair -L ha impiegato più di 4 
ore per il controllo di *un* disco da 12T, quanto ci avrebbe messo 
l'equivalente fsck.ext4 ?


Diego

Il 28/04/2023 06:47, Piviul ha scritto:

On 4/27/23 11:29, Diego Zuccato wrote:

[...]
Con XFS, fintanto che non ci sono problemi HW (soprattutto con la 
RAM), non ho mai avuto problemi. E boot sempre in tempi accettabili. 
Finora ho avuto problemi solo con una mobo che talvolta leggeva male 
dalla RAM (stessi problemi dopo la sostituzione della RAM, risolti con 
la sostituzione della mobo) e ovviamente quando ci sono stati problemi 
al disco (ma spesso si riescono a recuperare gran parte dei dati).


Scusate, per amore d'onestà devo fare una piccola precisazione. Sono 
andato a ripassare il problema avuto nel 2011, il filesystem era 
raiserfs e non xfs ricordavo male. Comunque in tanti anni ext3/ext4 non 
mi ha mai tradito ed in effetti ho tolto anch'io da tempo il fsck 
periodico automatico al boot e non ho mai avuto alcun problema.


Buona giornata

Piviul





--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786