5 ms·

I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.

by blueflow 12y ago

blackle 12y ago
really unix philosophy, isn't it?
- andrewstuart2 12y ago
  I'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was. Not that I agree, but I believe that's what they said.
  - agumonkey 12y ago
    Lennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').
    - blueflow 12y ago
      Something like systemd except being ONLY an init system would be really great.
      - rascul 12y ago
        http://uselessd.darknedgy.net http://uselessd.darknedgy.net
        mercurial 12y ago
        This looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?
        chris_wot 12y ago
        I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
        mercurial 12y ago
        I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.
        chris_wot 12y ago
        You can turn these services off :-) http://0pointer.de/blog/projects/three-levels-of-off http://0pointer.de/blog/projects/three-levels-of-off
        mercurial 12y ago
        I know, but I still don't think they belong under the same umbrella.
      - chris_wot 12y ago
        I challenge you to show me what part of systemd isn't directly related to inititialization of services.
        agumonkey 12y ago
        Maybe the parameters and interface will simplify over time. Patterns emerge with use.
        chris_wot 12y ago
        Yeah, that doesn't answer my question. What isn't necessary?
        agumonkey 12y ago
        I don't know all of systemd but : - journal - networkd - console Are already far from generic system config/init parts. These components are very nice and cleaner than older alternatives but it feels like unnecessary coupling. Also every release added magic variables to handle corner cases. They're proficient but complexity is increasing.
        blueflow 12y ago
        journald, logind. chrooting (nspawn). tty-ask-password-agent.
        chris_wot 12y ago
        nspawn inits. journald - fair point. logind inits. systemd-tty-ask-password-agent is a password agent that handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime.
      - andor 12y ago
        That's just not their plan. They want to modernize and standardize (to reduce fragmentation) the whole userspace. Replacing init is a big, but far from the only part of the process.
  - pdkl95 12y ago
    Most of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent. Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it. Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3]. /Sigh/ "Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer) [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html [2] Slackware was already on version 3.0! [3] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
    - vezzy-fnord 12y ago
      In all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago. GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier. The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
      - rpcope1 12y ago
        >The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then. This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
- chris_wot 12y ago
  Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
  - mveety 12y ago
    That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.
    - chris_wot 12y ago
      Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.
  - mbrubeck 12y ago
    Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy": > Write programs to handle text streams, because that is a universal interface. ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming: > Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. > Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. (And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
    - danieldk 12y ago
      Well, I guess you are also against SQL databases, aren't you ;). grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.
the_why_of_y 12y ago
Sorry, I don't get it - systemd-cat(1) only writes into the journal, it does not read from it, so it is more a replacement for logger(1) than for cat(1) - if you do cat foo >> /var/log/messages, how do you get timestamps on the log entries, and won't your syslog implementation just overwrite that? Does anybody actually do that?

I really like that you can now use systemd-cat with logfiles because regular cat doesn't fit anymore.

blackle 12y ago

really unix philosophy, isn't it?

andrewstuart2 12y ago
I'm not sure the systemd guys want to build with the unix philosophy. I don't have a definitive source (maybe SE radio podcast?) but I seem to remember one of the authors saying as much. They're more interested in what Linux can become than what unix was. Not that I agree, but I believe that's what they said.
- agumonkey 12y ago
  Lennart Poettering has a different view on Unix philosophy, it's more 'make it interesting and do what you need to'. I think nobody is right or wrong. This is all growing pain and, as I often say, at the right time I'm sure there will be tinier systemd-like built to be more Unixy (as in 'small set of smaller composable tools').
  - blueflow 12y ago
    Something like systemd except being ONLY an init system would be really great.
    - rascul 12y ago
      http://uselessd.darknedgy.net http://uselessd.darknedgy.net
      - mercurial 12y ago
        This looks surprisingly tempting. I agree with a lot of the ideas behind systemd, but at the rate it is growing, I'm going to type this in systemd-firefox in systemd-xmonad in six months. How stable is it in practice?
        chris_wot 12y ago
        I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
        mercurial 12y ago
        I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.
        chris_wot 12y ago
        You can turn these services off :-) http://0pointer.de/blog/projects/three-levels-of-off http://0pointer.de/blog/projects/three-levels-of-off
        mercurial 12y ago
        I know, but I still don't think they belong under the same umbrella.
    - chris_wot 12y ago
      I challenge you to show me what part of systemd isn't directly related to inititialization of services.
      - agumonkey 12y ago
        Maybe the parameters and interface will simplify over time. Patterns emerge with use.
        chris_wot 12y ago
        Yeah, that doesn't answer my question. What isn't necessary?
        agumonkey 12y ago
        I don't know all of systemd but : - journal - networkd - console Are already far from generic system config/init parts. These components are very nice and cleaner than older alternatives but it feels like unnecessary coupling. Also every release added magic variables to handle corner cases. They're proficient but complexity is increasing.
      - blueflow 12y ago
        journald, logind. chrooting (nspawn). tty-ask-password-agent.
        chris_wot 12y ago
        nspawn inits. journald - fair point. logind inits. systemd-tty-ask-password-agent is a password agent that handles password requests of the system, for example for hard disk encryption passwords or SSL certificate passwords that need to be queried at boot-time or during runtime.
    - andor 12y ago
      That's just not their plan. They want to modernize and standardize (to reduce fragmentation) the whole userspace. Replacing init is a big, but far from the only part of the process.
- pdkl95 12y ago
  Most of the systemd people arguing about the unix philosophy have no idea what that philosophy is[1]. A common argument is to insist that breaking up systemd into a separate binaries made "not monolithic", while ignoring that the design is still totally interdependent. Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it. Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3]. /Sigh/ "Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer) [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html [2] Slackware was already on version 3.0! [3] http://0pointer.de/public/gnomeasia2014.pdf http://0pointer.de/public/gnomeasia2014.pdf
  - vezzy-fnord 12y ago
    In all honesty, people who want a working Unix would have went to a BSD or Solaris variant a while ago. GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier. The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
    - rpcope1 12y ago
      >The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then. This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
chris_wot 12y ago
Sounds exactly like the Unix philosophy - cat is to concatenate files or standard input to standard output. If you took the binary format of systemd log files then it would output binary data to stdout. Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
- mveety 12y ago
  That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.
  - chris_wot 12y ago
    Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.
- mbrubeck 12y ago
  Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy": > Write programs to handle text streams, because that is a universal interface. ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming: > Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. > Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. (And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
  - danieldk 12y ago
    Well, I guess you are also against SQL databases, aren't you ;). grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.

the_why_of_y 12y ago

Sorry, I don't get it - systemd-cat(1) only writes into the journal, it does not read from it, so it is more a replacement for logger(1) than for cat(1) - if you do cat foo >> /var/log/messages, how do you get timestamps on the log entries, and won't your syslog implementation just overwrite that? Does anybody actually do that?