On 12/26/2011 1:00 AM, Rajko M. wrote:
On Sunday, December 25, 2011 08:31:18 AM Peter Nikolic wrote:
On Sunday 25 December 2011 04:46:49 Rajko M. wrote:
On Wednesday, December 07, 2011 08:24:06 AM Peter Nikolic wrote:
plain text log files please ..
I liked that argument and repeated it a lot, but what means plain text.
Ok lets try another way round that then shall we hows about Human Readable not containing any of the upper 128 Chars of the Character set .
No it is not. Human readbale is what you can see with your eyes, not with a help of the computer programs; just as stated in previous email:
Log is not paper copy, which requires only eyes to read it.
If you need text editor, bash and kernel to read something, then what is the difference to use specialized, a little bit more complicated editor that will output text that you can read, but that text will be stored in way that is convenient for computer to handle it, and it take lesser space on a disk.
What you loose? 1) Ability to use primitive interface between you and logs that have to be huge just to satisfy that primitive interface. 2) Need to learn log file format. 3) Need to compress log every now and then with logrotate. 4) Need to expand logs when you want to read archived copies created with logrotate.
What you gain? 1) Ability to store more information in the same space. 2) Ability to write and read logs faster then before. 3) Ability to scan for events faster then before.
...
Nope just plain old boring no special tools text please the only way lets get away from this darn windowsisation of Linux and head back to a more friendly way of life
"Darn windowization" :) Ideologists are in general detached from reality. There are good and bad ways get work done with huge gray zone between them. Is it forbidden to go forward, use better way to do a job, just because it resembles on some other (proprietary) solutions?
Pete .
logs are a thing that need to be acessible in minimalist and/or emergency situations. When a device or server is having a problem, that is not the time you want your diagnostic ability to rely on special tools that might not be available for any number of reasons. - not present on special boot image - broken library dependency - broken file format compatibility - not applicable for redirecting to special consoles, (serial, parallel, net, custom logger/watchdog script, custom loger/watchdog hardware, that might not be modifiable enough to build and install special binary log reader) Sure there are advantages to logging to a database. And they are conveniences that make the "everything is fine" case better at the expense of making the "everything is not fine" worse. The "everything is not fine" case comes along less frequently, but it _always_ comes along, and when it does, it's already bad enough without the complication of your diagnostic tools maybe suspect. On that day, you do not give a tenth of a rats crap for "increased efficiency" of being able to query logs from a db. Being able to sed/grep/awk etc from the file is valuable, and being able to read it directly with anything, even lowly cat or dd, let alone any of a bezillion editors/viewers that already exist everywhere on all platforms all cpus all versions since long before even the damned time_t epoch. Unless the format is human readable, then how do you really know that when you query it and get nothing, that it was really beacause nothing was there that matched and not merely that your human inscrutable special tool didn't simply fail to read the human inscrutable special file in some way? shells, editors, sed/awk/grep/perl etc do not suffer the same impossible burden of garanteeing to always work perfectly, because you can always look at a file directly using an uncountable number of other tools if any one is suspect. there are countless shells, cats dds vis etc... if I run some grep command on a text file and suspect the results, i can simply vi it or cat it or echo it through th shell itself, all 4 utils will not be broken at the same time and my eyes will not be subject to failure due to mere unexpected formatting. You can't demand "what situation will occur that you won't be able to use the log reader util? ". That is backwards thinking that leads to garbage non robust systems. You can't predict specific problems, or predict the impossibility of them. You can only design things so that, as much as possible, you avoid the _possibility_ of being without the ability to access something as important as syslog and dmesg, or fail to, and allow that possibility. "liklihood" isn't the important factor here. possible vs not-possible is. Even if you built the special log reader right into the kernel itself so it can't ever not be available & compatible, that still doesn't help all the examples of logging to devices that expect simple text. You want more efficient access to log data under normal circumstances? Feel free to _copy_ it to the db of your choice. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org