Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Operating Systems Red Hat Software Linux

Red Hat's Linux Changes Raise New Questions 433

itwbennett writes "Last month two Red Hat developers proposed to replace the 30-year-old syslog system with a new Journal daemon. Initial reaction was mostly negative and 'focused on the Journal's use of a binary key-value form of data to log system events,' says blogger Brian Proffit. But now, says Proffitt, it seems that the proposal to replace syslog has less to do with the fixing syslog's problems than with Red Hat's desire to go its own way with Linux infrastructure."
This discussion has been archived. No new comments can be posted.

Red Hat's Linux Changes Raise New Questions

Comments Filter:
  • by tomhudson ( 43916 ) <barbara,hudson&barbara-hudson,com> on Thursday December 01, 2011 @03:09PM (#38229724) Journal

    Keep on fragmenting each distro ... at a certain point, people will just get tired of distro-hopping and dump the whole mess.

    And people ask when the Year f the Linux Desktop will be. It's things likie this, and the constant breakage because of change for the sake of change or to "be different", rather than focusing on stability, that drive people to non-free vendors.

  • by LordLimecat ( 1103839 ) on Thursday December 01, 2011 @03:12PM (#38229758)

    There are advantages to not having everything in ascii text, or else we would never see relational databases used for anything. You are right that we will see. I like plain text logs because I am still learning the ins and outs of the major Linux breeds, and not having to learn a special tool for every config file and log makes things easier; but I wont say that there couldnt be benefits to a more robust system.

  • by Anonymous Coward on Thursday December 01, 2011 @03:28PM (#38230050)

    WTF does NEGFFBIBM mean? Google fails me on this one :(

  • by LordLimecat ( 1103839 ) on Thursday December 01, 2011 @03:38PM (#38230190)

    Looks like they're pulling the same shit Ubuntu pulled with upstart (init replacement). "Let's replace something simple and elegant with something complex, incomplete, and very difficult to fix when it goes wrong".

    One could make that argument about solid-state electronics, the move away from punch-cards, the move from paper-based filing, the move to journaled filesystems, etc.

    Sometimes progress means letting go of the past, and sometimes it takes a while to fully bake; thats why RedHat doing the QA, testing, and development for the rest of us is a good thing. If it sucks, it will die, and noone really has to acknowledge that it ever existed.

  • by Tomato42 ( 2416694 ) on Thursday December 01, 2011 @04:46PM (#38231092)
    Just yesterday I was debugging why my syspreped Win 7 images weren't installing properly. So I go to sysprep directory and start reading the text log. It didn't have any useful info. So I grabbed the binary log and tried to import it on the same machine in pre-exec environment. It couldn't do it. So I copied it to different computer and tried to open it there, the system claimed that the file was damaged. After 4 hours of struggle to read, copy or convert the bloody thing I went the "Microsoft recommended way" (seriously, that's the solution they suggest in MSKB) and bisected which program caused the install failure. In "only" 6 reinstalls I finally found the culprit.

    If it was a Linux distro, a simple cat or tail would have sufficed and it would have been a 15 minute job, not 2 days. If they want my text logs they will have to pry it from my cold dead hands.
  • by Anonymous Coward on Thursday December 01, 2011 @04:52PM (#38231154)

    Yeah, but you add a bunch of overhead to get back to text.

    Yes, you get the overhead when you as a human try to read the log. In plain text you have the overhead whenever it is used by the system.

    There are plenty of arguments for using ascii, efficiency is not one of them.

  • by The Moof ( 859402 ) on Thursday December 01, 2011 @05:29PM (#38231566)
    In a severely abbreviated, off the top of my head, fill in the blanks on your own fashion:

    CREATE TRIGGER `database`.`TailToFile` BEFORE INSERT on `database`.`table`
    FOR EACH ROW BEGIN
    /* manipulate data and print to file or pipe it elsewhere */
    END

    You could have config options, piped to /dev/null when not in use, etc.

    I've actually used PL/Perl in postgresql to do some pretty interesting stuff with the filesystem via triggers.

  • by alcourt ( 198386 ) on Thursday December 01, 2011 @07:03PM (#38232526)

    Actually, I work in security logging in a very large environment. The last thing we permit is ripping out syslog on generic systems. We do send a copy of the logs to a central system, but we don't allow the client systems to be touched.

    The central copy cannot be tampered with. The local copy is not for security, but stability and immediate usage.

    There is no such thing as a secure local log, and pretending otherwise is shameful. As to reliability, you get to pick between two evils. The possibility of logs not being delivered, or the possibility of logs not being delivered. The more complex the protocol, the more likely it is that a message gets devoured by the system. Simple protocols may not have guaranteed delivery, but their simplicity has actually helped ensure things just Don't Go Wrong.

If you have a procedure with 10 parameters, you probably missed some.

Working...