Re: politica stable
On Thu, 19 Dec 2019 21:40:19 +0100 Lucio wrote:
> Ogni tanto preferisco reinstallare per eliminare le librerie
> installate da programmi che poi ho rimosso nel tempo...
>
Per quello però ci sono programmi come deborphan e comandi come
apt purge `deborphan`
aptitude purge ~c
http://guide.debianizzati.org/index.php/Pulire_Debian
peterpunk
--
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/ printf("Mai un giorno senza una riga\n");
Re: uso di GID molto alti
Il 19 dicembre 2019 21:12:09 CET, Davide Prina ha
scritto:
>On 19/12/19 10:11, Federico Di Gregorio wrote:
>> Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere
>come
>> id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1)
>
>$ grep UID_T /usr/include/bits/typesizes.h
>#define __UID_T_TYPE __U32_TYPE
>
>$ davide:~# grep '#define __U32_TYPE' /usr/include/bits/types.h
>#define __U32_TYPE unsigned int
>
>---8<8<8<8<- a.c ---8<8<8<8<8<-
>#include
>#include
>
>int main( void )
> {
>printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) *
>8);
> }
>---8<8<8<8<8<8<8<8<8<8<-
>
>$ gcc a.c
>$ ./a.out
>uid_t: 4 bytes (32 bits)
>
>quindi non dovrebbe essere 2^³²-1?
>
>Però andando a leggere in giro ho trovato che:
>
>$ cat /etc/login.defs | grep UID
>UID_MIN 1000
>UID_MAX6
>
>Quindi il massimo UID per l'utente è impostato a 60.000 di default.
>
>$ man 5 login.defs
>[...]
>UID_MAX (numerico), UID_MIN (numerico)
>Intervallo di ID utente da utilizzare nella creazione degli utenti
>normali tramite useradd o newusers.
>Il valore predefinito per UID_MIN (rispettivamente UID_MAX) è 1000
>(rispettivamente 6).
>[...]
>
>valori maggiori sono usati da SUB_UID (tra 100.000, 600.100.000)
>
>$ man 5 subuid
>...
>
>Poi non so...
>
>
> >> Il 19/12/19 08:38, Leonardo Boselli ha scritto:
>
A chi ha provato: ci sono problemi a usare dei GID molto, molto
>alti
> >>> (diciamo sopra il miliardo), soprattutto in temini di prestazioni?
> >>> (igruppi sarebbero diverse centinaia di migliaia, in genere con 2
membri, e potrebbero anche essercene alcuni (qualche centinaio) con
centinaia di membri. ) (servono per dare accesso a singoli gruppui
> >>> di file)
>
>I subuid sono usati in Debian:
>
>$ cat /etc/subuid
>
>L'uid max usabile in teoria è 6, se usi i comandi per la creazione
>di utenti.
>
>Se gestisci tu numeri più alti di 600.100.000, non so se puoi avere
>problemi... e non so come puoi fare a creare tanti utenti, scavalcando
>il limite sopra indicato.
>
>Se invece hai utenti limitati, ma sono le combinazioni elevate, allora
>penso che per i GID penso valga lo stesso discorso
>
>$ cat /etc/login.defs | grep GID
>
>$ cat /etc/subgid
>
>$ man subgid
>
>Inoltre dovresti avere che ogni utente appartiene probabilmente a
>migliaia di gruppi... e questo penso che possa rallentare parecchio
>solo
>per il parsing del file.
>
>Forse puio fare qualcosa con namespace e cgroups
>
>Ciao
>Davide
secondo me, per una gestione così capillare di tanti utenti, ti converrebbe
avere la gestione su dominio, con autenticazione da dominio. AD è Microsoft,
credo che smb simuli qualcosa, forse kerberos può gestire la cosa, ma non ho
esperienza, noi abbiamo tantissimi utenti, ma siamo su AD Microsoft, e la
maggior parte delle macchine sono winzoz (purtroppo).
byez
--
gollum1
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli
errori, maledetto correttore automatico.
Re: stampa
Un saluto "trasformativo" si propaga a tutti i partecipanti alla lista ... :-)) Il 19/12/2019 21:31, Davide Prina ha scritto: [...] come già indicato più volte puoi risolvere questo problema trasformando i pdf in ps tramite il comando pdftops e poi stampando da evince il ps [...] Ciao Davide, ma forse si potrebbe usare Evince per trasformare direttamente il file pdf in ps, dalla pagina di stampa scegliere "stampa su file" e si sceglie ps o svg, poi si visualizza con Evince il file ps così ottenuto sempre con Evince e, sempre dalla pagina di stampa si scegli di stamparlo inviandolo alla propria stampante .. C'est plus faciles! :-) Apprezzo tantissimo le psutils che ho usato per molto tempo ma se si può saltare un comando meglio ... :-) Io ho visto che questo problema è presente soprattutto su come e da cosa sono stati generati i PDF e il problema non è specifico di GNU/Linux, ma comprende anche altri sistemi operativi proprietari (infatti ad alcuni colleghi che usano m$ stampo io i loro pdf dopo averli trasformati in ps). Con i colleghi che usano M$ non c'è possibilità di fargli conoscere ed usare Linux, almeno secondo la mia esperienza. Appena provo a parlare di Debian o altre distro di Linux nei migliori dei casi si mettono a ridere non vi dico nel peggiore dei casi ... :-)) Au Revoire Hugh Hartmann
Re: politica stable
Il 19 dicembre 2019 21:28:05 CET, Davide Prina ha scritto: >On 19/12/19 20:46, Lucio Marinelli wrote: > >> Io sto usando testing da più di un anno (reinstallata dopo l'uscita >> dell'ultima stable) > >perché mai hai reinstallato? > >Potevi semplicemente cambiare /etc/apt.sources.list se non avevi già >indicato il generico "testing" Ogni tanto preferisco reinstallare per eliminare le librerie installate da programmi che poi ho rimosso nel tempo... -- Lucio Marinelli
Re: stampa
On 19/12/19 20:17, andrea biancalana wrote: Pero' tempo fa, sempre con testing, mi sono trovato ad avere difficolta' a stampare pdf da evince su una stampante di rete olivetti/kyocera quando contenevano grafica. La stampa rallentava ai limiti dell'impossibile. come già indicato più volte puoi risolvere questo problema trasformando i pdf in ps tramite il comando pdftops e poi stampando da evince il ps Io ho visto che questo problema è presente soprattutto su come e da cosa sono stati generati i PDF e il problema non è specifico di GNU/Linux, ma comprende anche altri sistemi operativi proprietari (infatti ad alcuni colleghi che usano m$ stampo io i loro pdf dopo averli trasformati in ps). Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Perché microsoft continua a compiere azioni illegali?: http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: politica stable
On 19/12/19 20:46, Lucio Marinelli wrote: Io sto usando testing da più di un anno (reinstallata dopo l'uscita dell'ultima stable) perché mai hai reinstallato? Potevi semplicemente cambiare /etc/apt.sources.list se non avevi già indicato il generico "testing" , faccio apt update && apt dist-upgrade quotidianamente e non ho mai avuto problemi... sto sbagliando qualcosa? io preferisco fare in più fasi: # apt update # apt -u upgrade # apt -u dist-upgrade in questo modo il passo: 1) aggiorna la lista dei pacchetti disponibili 2) aggiorna i pacchetti che non richiedono rimozioni o installazioni di altri pacchetti 3) aggiorna ciò che richiede installazione/rimozione di altri pacchetti Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Database: http://www.postgresql.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Compilare Linux (ERA: Re: cortese domanda su apt-listbugs)
On 19/12/19 11:30, Portobello wrote: Il 16/12/19 20:12, Davide Prina ha scritto: On 16/12/19 15:20, Portobello wrote: Evviva, Eureka. Ho ricompilato tutto da capo. Ora funziona tutto. finalmente :-) real 392m28,165s user 248m36,405s sys 47m21,837s real sarebbe il tempo reale impiegato ? 392 minuti perchè sono 392/60= 6,53 ore sì, più o meno Però mi sembra strano che ci abbia messo così tanto. A me impiega circa 45-50 minuti (però io ho un 4 core) Ad occhio ora non vedo grandi differenze come prestazioni. se hai impostato quello che ho detto io dovrebbe essere più reattivo. Nel senso che il sistema dovrebbe risponderti subito quando è sotto attività lavorativa pesante, i processi possono impiegare più tempo ad essere eseguiti, ma l'uso del PC da parte dell'utente dovrebbe essere più fruibile. C'è qualche modo per misurare e confrontare le performance, tra l'immagine generica e quella specifica per Amd64 che ho appena compilato ? Misurare le prestazioni di un PC è sempre complesso... dovresti avere gli stessi processi attivi ed usare il "tester" esattamente nelle stesse condizioni. Ma questo è davvero poco fattibile... infatti se riesegui il test più volte hai risultati sempre un po' di versi ed alle volte molto diversi perché magari è partito qualcosa che ha usato risorse... All'inizio quando ho dato il comando di compilazione ho visto che ha dato dei messaggi di warning ma nel terminale non li vedo più e non so dove andare a cercarli. sì all'inizio probabilmente ti dice che è installato il pacchetto encrypt, ma tu non stai compilando con encrypt e altre cose del genere... ma sono solo avvisi. Forse si può dare un comando del tipo : time make -j 2 deb-pkg > warning.txt time make -j 2 deb-pkg > warning.txt > messaggi.out 2> errori.out Infine, tieni conto che ogni volta che arriva una nuova versione di Linux dovresti ricompilarlo se vuoi avere la tua versione compilata in esecuzione. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki I didn't use Microsoft machines when I was in my operational phase, because I couldn't trust them. Not because I knew that there was a particular back door or anything like that, but because I couldn't be sure. Edward Snowden
Re: uso di GID molto alti
On 19/12/19 10:11, Federico Di Gregorio wrote:
Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere come
id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1)
$ grep UID_T /usr/include/bits/typesizes.h
#define __UID_T_TYPE__U32_TYPE
$ davide:~# grep '#define __U32_TYPE' /usr/include/bits/types.h
#define __U32_TYPE unsigned int
---8<8<8<8<- a.c ---8<8<8<8<8<-
#include
#include
int main( void )
{
printf("uid_t: %d bytes (%d bits)\n", sizeof(uid_t), sizeof(uid_t) * 8);
}
---8<8<8<8<8<8<8<8<8<8<-
$ gcc a.c
$ ./a.out
uid_t: 4 bytes (32 bits)
quindi non dovrebbe essere 2^³²-1?
Però andando a leggere in giro ho trovato che:
$ cat /etc/login.defs | grep UID
UID_MIN 1000
UID_MAX 6
Quindi il massimo UID per l'utente è impostato a 60.000 di default.
$ man 5 login.defs
[...]
UID_MAX (numerico), UID_MIN (numerico)
Intervallo di ID utente da utilizzare nella creazione degli utenti
normali tramite useradd o newusers.
Il valore predefinito per UID_MIN (rispettivamente UID_MAX) è 1000
(rispettivamente 6).
[...]
valori maggiori sono usati da SUB_UID (tra 100.000, 600.100.000)
$ man 5 subuid
...
Poi non so...
>> Il 19/12/19 08:38, Leonardo Boselli ha scritto:
>>> A chi ha provato: ci sono problemi a usare dei GID molto, molto alti
>>> (diciamo sopra il miliardo), soprattutto in temini di prestazioni?
>>> (igruppi sarebbero diverse centinaia di migliaia, in genere con 2
>>> membri, e potrebbero anche essercene alcuni (qualche centinaio) con
>>> centinaia di membri. ) (servono per dare accesso a singoli gruppui
>>> di file)
I subuid sono usati in Debian:
$ cat /etc/subuid
L'uid max usabile in teoria è 6, se usi i comandi per la creazione
di utenti.
Se gestisci tu numeri più alti di 600.100.000, non so se puoi avere
problemi... e non so come puoi fare a creare tanti utenti, scavalcando
il limite sopra indicato.
Se invece hai utenti limitati, ma sono le combinazioni elevate, allora
penso che per i GID penso valga lo stesso discorso
$ cat /etc/login.defs | grep GID
$ cat /etc/subgid
$ man subgid
Inoltre dovresti avere che ogni utente appartiene probabilmente a
migliaia di gruppi... e questo penso che possa rallentare parecchio solo
per il parsing del file.
Forse puio fare qualcosa con namespace e cgroups
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Client di posta: https://www.thunderbird.net
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: politica stable
Il giorno gio 19 dic 2019 alle ore 07:34 Paolo Redaelli < paolo.redae...@gmail.com> ha scritto: > Per l'uso Desktop di tutti i giorni testing è perfettamente usabile. > L'unica accortezza che suggerisco è di aggiornare alla bisogna i singoli > pacchetti che interessano anziché "tutta la baracca" e limitare la > frequenza di quest'ultima azione a 3-4 volte l'anno. > Io sto usando testing da più di un anno (reinstallata dopo l'uscita dell'ultima stable), faccio apt update && apt dist-upgrade quotidianamente e non ho mai avuto problemi... sto sbagliando qualcosa? -- Lucio Marinelli
Re: stampa
il giorno Thu, 19 Dec 2019 19:49:40 +0100 Davide Prina ha scritto: > se con alcuni applicativi stampa e con altri no... allora è davvero > molto strano. e' vero, e' strano. Pero' tempo fa, sempre con testing, mi sono trovato ad avere difficolta' a stampare pdf da evince su una stampante di rete olivetti/kyocera quando contenevano grafica. La stampa rallentava ai limiti dell'impossibile. A suo tempo avevo risolto installando cairo e caricandolo in printers.conf Mesi dopo la stessa stampante ha smesso di stampare i pdf finche' ho rimosso cairo: adesso mi sembra che stampi anche quelli con molta grafica. Saluti
Re: politica stable
On 19/12/19 01:48, Sabrewolf wrote: Piuttosto il mio dubbio riguardava la politica della distro, stavo cercando di capire se debian è adatta all'uso desktop o se passare ad altre distribuzioni. la politica di stable è quella di aggiornare i pacchetti solo per coprire bug, soprattutto di sicurezza; mantenendo le versioni che erano presenti al rilascio della stable (tranne alcune eccezioni). Con la possibilità di prendere dai backport alcuni determinati software aggiornati). La stable può essere usata per uso desktop per chi vuole avere un sistema che sia usabile per un periodo lungo di tempo e che permetta di sutare per tale periodo esattamente le stesse versioni di software. Se invece vuoi poter accedere a software aggiornato recentemente e quindi sobbarcarti anche possibili cambi di versione (questo può voler dire cambi di interfaccia, usabilità, modalità d'uso, funzionalità, configurazione, dipendenze, ...) allora penso che la scelta migliore sia la versione testing di Debian Ti faccio un esempio banale. Se usi per lavoro un determinato applicativo complesso, vuoi che funzioni e tu sia in grado di usarlo senza problemi sempre e non sei disposto a vederti installata da un giorno all'altro una nuova versione che modifica l'interfaccia e le funzionalità che potrebbero rallentarti o impedirti di effettuare una determinata attività in tempi stretti (ad esempio, se non erro blender ha di recente cambiato l'interfaccia e imparare ad usare la nuova può richiedere un po' di tempo). In questi casi è meglio usare una stable, mentre se si usa la testing si potrebbe cercare di posporre l'aggiornamento di tale pacchetto (es: tramite pinning), ma tale operazione potrebbe risultare impossibile da attuare nel lungo periodo perché si potrebbe arrivare a bloccare l'aggiornamento dell'intero sistema... Il pacchetto youtube-dl è un caso limite, forse più unico che raro, dove le versioni vecchie non funzionano più dopo X giorni/mesi dal loro rilascio per alcuni siti... a causa delle modifiche dei siti stessi. Come indicato, puoi chiedere che questo pachetto venga messo su backport in modo regolare, per avere una versione recente... e se il DD acconsente... Se guardi le altre distro o sono tipo la stable di Debian o la testing. Inoltre non penso vi sia un'altra distro che ti offra un repository ufficiale così fornito come quello di Debian. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Elenco di software libero: http://tinyurl.com/eddgj GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: politica stable
On 19/12/19 07:33, Paolo Redaelli wrote: Per l'uso Desktop di tutti i giorni testing è perfettamente usabile. L'unica accortezza che suggerisco è di aggiornare alla bisogna i singoli pacchetti che interessano anziché "tutta la baracca" e limitare la frequenza di quest'ultima azione a 3-4 volte l'anno. però così ti perdi tutti gli aggiornamenti di sicurezza. Io consiglio l'aggiornamento giornaliero di tutto, con l'installazione preventiva di apt-listbugs e apt-listchanges Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Fate una prova di guida ... e tenetevi la macchina!: http://linguistico.sf.net/wiki/doku.php?id=usaooo2 Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: stampa
On 18/12/19 19:59, Pol Hallen wrote: (sia con la stable che con testing) come stampanti di prova ho una HP1536 (laser), una epson xp-215 (inchiostro) e una samsung E460DN (laser) sia tramite cups sul server (con le stampanti condivise) sia con stampanti in locale (in lan) quando stampo file pdf tutto ok ma non ho capito che applicazione utilizzi per stampare. Ad esempio Libreoffice ed Evince? se stampo da qualsiasi altra cosa (thunderbird, pluma, firefox) esce una pagina di errore (purtroppo ora non ho sottomano i codici errori) ma trattasi di una problematica di driver se con alcuni applicativi stampa e con altri no... allora è davvero molto strano. Io, se non erro, ho configurato, ad un utente, due stampanti laser epson e samsung. Entrambe configurate in locale e su entrambe le stampe sono effettuate con diversi applicativi senza problemi. Se non erro sulla Epson e collegato un PC con la stable attuale, sull'altro una versione vecchia di Debian. Ho usato e uso personalmente con testing altre marche di stampanti in rete e non ho mai avuto dei problemi del genere... Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki I lati oscuri del secure boot: https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Petizione contro il secure boot: https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: Compilare Linux (ERA: Re: cortese domanda su apt-listbugs)
Il 16/12/19 20:12, Davide Prina ha scritto: On 16/12/19 15:20, Portobello wrote: Mi sembra che manca soltanto il modulo di debug. però avevo indicato di disabilitare le informazioni di debug $ scripts/config --disable DEBUG_INFO Ciao Lista, Ora ho disabilitato le informazioni di Debug. magari sono queste che ti causano un uso eccessivo del disco e fanno impegare così tanto la compilazione. Evviva, Eureka. Ho ricompilato tutto da capo. Ora funziona tutto. Ha occupato circa 5 Gb di spazio disco. Ma per il tempo è cambiato poco. Alla fine metto i messaggi che mi ha dato. Comunque ha impiegato più di 6 ore per compilare tutto. Ho installato i tre pacchetti senza errori. ho ri-avviato e funziona. Ma ho visto che ha creato tre pacchetti .deb, nella dir src : linux-headers-4.19.87-xx-20191215_4.19.87-xx-20191215-1_amd64.deb linux-image-4.19.87-xx-20191215_4.19.87-xx-20191215-1_amd64.deb linux-libc-dev_4.19.87-xx-20191215-1_amd64.deb In pratica ha occupato tutti i 21 Gb liberi che c'erano ieri nella mia home. Ma oggi ho allargato la partizione e quindi ho aggiunto altri 35 Gb. Quindi ora vorrei capire due cose. 1) Posso provare ad installare quei tre pacchetti, per vedere se funzionano ? in teoria sì... a meno che l'errore l'ha dato mentre generava il pacchetto "linux-image-4.19.87-xx-20191215" e quindi non hai un .deb installabile/funzionante 2) Se provo a compilare per la seconda volta, lasciando la src così come è stata creata ieri, dovrebbe riutilizzare i dati già creati e quindi impiegare meno tempo ? in teoria sì, bisogna vedere, però, se non esegue un "clean" e quindi cancella tutto quello che è già stato compilato, prima di iniziare Qui ho visto, che nel mio caso, ogni volta che inizia una compilazione lui da il comando make clean, anche se io non lo do da terminale. Se non avevi disabilitare le informazioni di debug, allora ti consiglio di rifare tutto disabilitandole. Così verifiche se sono quelle le risponsabili dei tuoi problemi... Io ho compilato con meno di 10 GB disponibili nella partizione e non ho mai avuto problemi di spazio. Questi sono i messaggi che ha dato alla fine: INSTALL debian/headertmp/usr/include/linux/usb/ (13 files) INSTALL debian/headertmp/usr/include/linux/wimax/ (1 file) INSTALL debian/headertmp/usr/include/asm/ (62 files) dpkg-deb: generazione del pacchetto "linux-headers-4.19.87-xx-20191217" in "../linux-headers-4.19.87-xx-20191217_4.19.87-xx-20191217-1_amd64.deb". dpkg-deb: generazione del pacchetto "linux-libc-dev" in "../linux-libc-dev_4.19.87-xx-20191217-1_amd64.deb". dpkg-deb: generazione del pacchetto "linux-image-4.19.87-xx-20191217" in "../linux-image-4.19.87-xx-20191217_4.19.87-xx-20191217-1_amd64.deb". dpkg-genbuildinfo dpkg-genchanges >../linux-4.19.87-xx-20191217_4.19.87-xx-20191217-1_amd64.changes dpkg-genchanges: warning: package linux-image-4.19.87-xx-20191217-dbg in control file but not in files list dpkg-genchanges: info: including full source code in upload dpkg-source -i.git --after-build . dpkg-buildpackage: info: full upload (original source is included) real392m28,165s user248m36,405s sys 47m21,837s real sarebbe il tempo reale impiegato ? 392 minuti perchè sono 392/60= 6,53 ore Ad occhio ora non vedo grandi differenze come prestazioni. C'è qualche modo per misurare e confrontare le performance, tra l'immagine generica e quella specifica per Amd64 che ho appena compilato ? All'inizio quando ho dato il comando di compilazione ho visto che ha dato dei messaggi di warning ma nel terminale non li vedo più e non so dove andare a cercarli. Forse si può dare un comando del tipo : time make -j 2 deb-pkg > warning.txt per indirizzare tutti i messaggi in un file di testo, per poi andarli a vedere dopo la compilazione. Ciao Davide Grazie Saluti
Re: uso di GID molto alti
On 12/19/19 9:21 AM, Paolo Redælli wrote: Il 19/12/19 08:38, Leonardo Boselli ha scritto: A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) Beh, credo che GID e UID siano sempre "maneggiati" come un int che sulle macchine attuali è "comunque veloce". Non mi sorprenderi di scoprire che ora nel nucleo e nelle utility connesse si usi un int64. Ad ogni modo no, non dovrebbero esserci problemi e non dovrebbero in particolare essercene di prestazioni Linux usa uid di 32 bit. Non c'è alcuna differenza nello scegliere come id 5 oppure 19711019. (Ovviamente non puoi andare oltre 2^31-1). federico -- Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it I did appreciate the irony that I was whining about encoding issues on a mailing list that was unable to show those chars, too. -- Antti S. Lankila to mono-devel-list@
Re: politica stable
+1 anch'io seguo lo stesso criterio, x il desktop testing, mai avuto problemi, per i server stable Il gio 19 dic 2019, 06:40 Marco Bodrato ha scritto > > Prima di "passare ad altre distribuzioni", chiediti se il tuo problema è > Debian o Debian stable. Certamente la distribuzione stabile ha ottime > qualità in termini di sicurezza e (come dice il nome) stabilità; qualità > che la rendono molto adatta ai server. > Personalmente, per "l'uso desktop" l'ho sempre ritenuta troppo poco > dinamica (come è giusto che sia una distribuzione che si chiama stabile) > ed ho sempre preferito testing (anche sid, in periodi in cui avevo più > tempo per star dietro ai rari problemi). > > Ĝis, > m > > -- > http://bodrato.it/papers/ > >
Re: uso di GID molto alti
Il 19/12/19 08:38, Leonardo Boselli ha scritto: A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) Beh, credo che GID e UID siano sempre "maneggiati" come un int che sulle macchine attuali è "comunque veloce". Non mi sorprenderi di scoprire che ora nel nucleo e nelle utility connesse si usi un int64. Ad ogni modo no, non dovrebbero esserci problemi e non dovrebbero in particolare essercene di prestazioni
uso di GID molto alti
A chi ha provato: ci sono problemi a usare dei GID molto, molto alti (diciamo sopra il miliardo), soprattutto in temini di prestazioni? (i gruppi sarebbero diverse centinaia di migliaia, in genere con 2 membri, e potrebbero anche essercene alcuni (qualche centinaio) con centinaia di membri. ) (servono per dare accesso a singoli gruppui di file) -- Leonardo Boselli
