3 ms·

So? How do you tell between commercial and OSS projects in journald? And about that "quick" part, I'd rather have a way to do that that's either easy to recall

by dozzie 9y ago

So? How do you tell between commercial and OSS projects in journald? And about that "quick" part, I'd rather have a way to do that that's either easy to recall or easy to re-develop. journald's magical incantations that don't compose to any consistent language (unlike Vim or Emacs keybindings, for instance) nor are the same as in virtually any other software are not convenient by any stretch. I have my memory cluttered enough by half a dozen of different languages I use, their runtimes, runtimes of languages I don't write in but need for some software I run, twice that of DSLs and specialized languages, options and functions of dozens of services, wire formats of network protocols, management procedures of various Linux subsystems, and so on. I don't need an option to a command to tell me what you ask, I can work my way through grep/sed/awk faster than you read man page, thank you very much.

lclarkmichalek 9y ago
I feel like journalctl -u foo is easier to type than that rant.
oblio 9y ago
Those were just random examples to prove a point (daemons/services can have very varied origins). The real question is: > I have two service from totally different origins. What do I type in my terminal to see their logs, with syslog or other widely used init systems currently in use, except for systemd? So? :)
- fiddlerwoaroof 9y ago
  `less /var/log/<service>.log` or `ag <service> /var/log` or something similar usually works pretty well. I’m not sure why I need a command line utility to do something that the filesystem+standard Unix utilities does just fine. The whole point of Unix is to compose general purpose utilities to get the job done rather than to create a special tool for each task.
  - oblio 9y ago
    Cause they don’t. Every service puts stuff wherever it wants, especially poorly written services. At least with systemd services do the right thing, by default. At some point Unix will learn that in the wild opt-out is better than opt-in. When you make doing the right thing easy, everyone will do it. When you don’t, everyone does what they want, which is generally bad. The fact that we have to ag or grep -R is a kludge. There’s NO technical reason the folder structure shouldn’t be flexible but standardized and also NO reason why there shouldn’t be some system scaffolding to help with that. Call it systemd or whateverd, it should be there.
    - fiddlerwoaroof 9y ago
      But syslog already solved this problem (as others have said): you pipe all your output to syslog (even via TCP/UDP) and then syslog determines where the output should go via the entries in syslog.conf. And you can even write a simple utility that wraps an arbitrary executable and redirects its stdout/stderr to syslog as well, solving the problem for 90% of the applications that don't have builtin syslog support.
      - oblio 9y ago
        I feel like I'm having the same discussion, here, on HackerNews, when I talk to people about Emacs. Yes, technically we can do anything. In the end it's all code, if my time was free I could just do anything :) But sensible defaults are important. Software design is important. Unix basically skirts the issue by throwing all these decisions in the user's lap. I can take these decisions, but I don't always want to have to do it. And there's many situations where you can't necessarily do it, either due to technical limitations, political limitations, budget constraints, etc. In short, I'm glad systemd is winning. Sure, the average user loses a bit on the purity front but he gains a lot on the practical front.
JdeBP 9y ago
Not everyone is the same. Some people have learned such stuff. Some people need cheatsheets. * http://jdebp.eu./Softwares/nosh/guide/logging-cheatsheet.html http://jdebp.eu./Softwares/nosh/guide/logging-cheatsheet.htm...

by dozzie 9y ago

lclarkmichalek 9y ago

I feel like journalctl -u foo is easier to type than that rant.

oblio 9y ago

Those were just random examples to prove a point (daemons/services can have very varied origins). The real question is: > I have two service from totally different origins. What do I type in my terminal to see their logs, with syslog or other widely used init systems currently in use, except for systemd? So? :)

fiddlerwoaroof 9y ago
`less /var/log/<service>.log` or `ag <service> /var/log` or something similar usually works pretty well. I’m not sure why I need a command line utility to do something that the filesystem+standard Unix utilities does just fine. The whole point of Unix is to compose general purpose utilities to get the job done rather than to create a special tool for each task.
- oblio 9y ago
  Cause they don’t. Every service puts stuff wherever it wants, especially poorly written services. At least with systemd services do the right thing, by default. At some point Unix will learn that in the wild opt-out is better than opt-in. When you make doing the right thing easy, everyone will do it. When you don’t, everyone does what they want, which is generally bad. The fact that we have to ag or grep -R is a kludge. There’s NO technical reason the folder structure shouldn’t be flexible but standardized and also NO reason why there shouldn’t be some system scaffolding to help with that. Call it systemd or whateverd, it should be there.
  - fiddlerwoaroof 9y ago
    But syslog already solved this problem (as others have said): you pipe all your output to syslog (even via TCP/UDP) and then syslog determines where the output should go via the entries in syslog.conf. And you can even write a simple utility that wraps an arbitrary executable and redirects its stdout/stderr to syslog as well, solving the problem for 90% of the applications that don't have builtin syslog support.
    - oblio 9y ago
      I feel like I'm having the same discussion, here, on HackerNews, when I talk to people about Emacs. Yes, technically we can do anything. In the end it's all code, if my time was free I could just do anything :) But sensible defaults are important. Software design is important. Unix basically skirts the issue by throwing all these decisions in the user's lap. I can take these decisions, but I don't always want to have to do it. And there's many situations where you can't necessarily do it, either due to technical limitations, political limitations, budget constraints, etc. In short, I'm glad systemd is winning. Sure, the average user loses a bit on the purity front but he gains a lot on the practical front.

JdeBP 9y ago

Not everyone is the same. Some people have learned such stuff. Some people need cheatsheets. * http://jdebp.eu./Softwares/nosh/guide/logging-cheatsheet.html http://jdebp.eu./Softwares/nosh/guide/logging-cheatsheet.htm...