Re: Debian systemd maintainer resigns due to online bullying + risultati votazione DD
Grazie per la disponibilità.
Il giorno 20/nov/2014, alle ore 09:54, Gian Uberto Lauri <saint@eng.it> ha scritto:
> gerlos writes:
>
>> 1. Come si fa a “spezzare” un file binario? “dove” si fa? Con che
>> logica dovrebbe funzionare un clone di logrotate che funziona su un
>> log binario?
>
> Una utility per fare a pezzi un file binario è split. Aveva il suo
> perché ai tempo di memorie rimovibile piccoline.
>
> Quanto a logrotate, il sistema dovrebbe attendere la fine di una
> entry, bloccare la scrittura mentre linka il vecchio file ad un nuovo
> nome e ne prepara uno vuoto al suo posto, sbloccare la scrittura e
> continuare a lavorare sul vecchio log off-line.
>
> In questo modo ci si garantirebbe la scrittura per record completi.
Domanda ignorante (ho un sospetto, ma mi piacerebbe avere conferma in proposito): c’è un modo “universale” per sapere quando finisce la scrittura di un record in un file binario, o per farlo devi sapere anche com’è strutturato quel particolare file binario?
>
>> 2. Il fatto che il log sia binario elimina la necessità di ruotarlo
>> e comprimerlo? Come?
>
> Forse si avrebbe meno guadagno a comprimerlo, perché un file binario
> può contenere meno ridondanza.
Lo immaginavo.
Ad ogni modo ad un certo punto potrei volerlo ruotare comunque, magari perché voglio spostare altrove i vecchi log non più rilevanti, o perché vorrei cancellarli proprio perché non mi servono più.
>
>> 3. Perché dovrei indicizzare un file di log? Cosa c’è che non va
>> nelle ricerche fatte ad esempio con grep semplicemente quando
>> serve? Come potrebbe un file binario agevolare il lavoro di tool
>> come logcheck, per esempio? (tempo fa ho “greppato” un log di 30MB
>> da un server con un problema hardware che rendeva il kernel
>> logorroico, e sono sopravvissuto senza avere indici…)
>
> Un'indicizzazione serve solo quando sai cosa cercare e quando ripeti
> la ricerca.
[CUT]
> Non c'è nulla che non va nelle ricerche con grep e awk. Semplicemente
> sono ricerche che fai in "full table scan" - per usare il gergo dei DB
> relazionali - e ogni volta che la fai ne paghi il costo completo.
Beh, se lo faccio occasionalmente (per esempio ogni 12 h tramite logcheck) potrebbe essere un costo dopo tutto sostenibile. Quanto peserà al confronto la scrittura continua di quelle strutture più complesse?
>
>> 4. Abbiate pazienza, non capisco neanche perché dovrebbe essere più
>> semplice o più efficiente appendere contenuti ad un file binario
>> rispetto ad appendere una riga ad un file testuale.
>
> Scrivere 4 byte è sicuramente più veloce che convertire i 4 byte in
> una stringa di caratteri che ne rappresenta il valore in decimale. Non
> parliamo dell'aumento di velocità nello scrivere un time_t
> direttamente o trasformarlo in un timestamp leggibile.
>
> Ti voglio vedere però a prendere il valore binario, trasformarlo in
> giorni, ore, minuti e secondi e trasformare questi valori in una data
> che parte dal 1 gennaio 1970.
Tu dici insomma che togliamo complessità da un lato e la spostiamo altrove?
>
>> 5. In condizioni assurdamente disperate, potrei copiare un file log
>> sul computer di mio cugino ;-) su cui gira Windows, con
>> l’intenzione di esaminarli. Come faccio se sono binari? (se sono
>> testuali, in assenza di meglio, posso usare il buon vecchio
>> Wordpad).
>
> Per esaminarli se sono binari, o funzionano i tool che te lo leggono o
> sei uno übergeek che si è imparato il formato dei file e riesce pure a
> leggerlo nell'output di od. Altrimenti... picche, tamburi e cornamuse.
Ecco, questa è una delle che mi lasciano più perplesso.
Però devo ammettere che ormai da anni nel mio ecosistema ci sono molti più sistemi unix (Debian, derivate Debian e OSX) che non Windows, quindi in effetti potrebbe non essere mai un vero problema…
Ad ogni modo, la cosa rimane controversa.
grazie per le utili risposte!
gerlos
--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do more
of what works. If it works big, others quickly copy it. Then you do something
else. The trick is the doing something else."
< http://gerlos.altervista.org >
gerlos +- - - > gnu/linux registred user #311588
Reply to: