6 ms·

My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but n

My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately. Not to mention unless the problem with the service completely prevented it from running (it advises some commands to run in that case) you're supposed to just always remember "journalctl -xeu $SERVICE" was the incantation, less you want to go look up the flags again or manually parse the entire "journalctl" output. Overall I generally like systemd though. The syntax can just be a burden sometimes.

Denvercoder9 2y ago
In case you don't know, you can use the `-n` argument to `systemctl status` to tweak the log output, e.g. `-n0` to disable the log output and `-n40` to get more than the default 10 lines.
- zamadatix 2y ago
  That's a great option to tweak the behavior and I hadn't known about it (or if I ever had, I'd well forgotten). Thanks! From the man page it ?looks like? if you want reverse or full then it's still off to the journalctl command and arguments but at least "-n9999" is better than "always 10 lines".
  - godelski 2y ago
    FWIW, I don't want that behavior. 10 lines is great for my usage. And IIRC you can change the default behavior. In the worst case, just alias it if it is bothering you that much.
    - zamadatix 2y ago
      Glad you like it! I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias and be even more lost when I don't have it or am working with someone else though. At least for the super common tools like git, systemctl, grep, and the like.
      - godelski 2y ago
        > I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias I highly encourage you to learn the commands. But it seems like you did. I would not call something so stylistic as `git branch -vv` as "sticking your head in the sand". Your fallback is not going to really confuse you or put you at risk of not knowing what's going on. I can totally understand if we were talking about aliasing something much more complicated, but at that point it's a script...
- kai-tub 2y ago
  Nice! I didn't know that was an option. Definitely something I should make configurable in `isd` :+1:
SJC_Hacker 2y ago
> My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately. How about systemctl status foo | tail
kristopolous 2y ago
it's the same mentality that brought us the git design - the easiest, least typing options are rarely, if ever the thing you want to do. Instead, these invocations give cryptic messages, throw errors, or sometimes, even break things. The most common and helpful things are hidden deep behind multiple flags and command line arguments in manuals that read like dictionaries more than guides. I'm always at a complete loss as to how such decisions are made. For instance, "git branch -vv" is the useful output you would like to see, every time, that should be "git branch". Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... I know people defend this stuff, but as a senior engineer in programming pits for 30 years, they're wrong. Needless mistakes and confusions are the norm. We can do better. We need to stop conflating elitism with fucked up design.
- godelski 2y ago
  > Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... Yes, it is too much. You have the wrong mentality, and I hope this can help make your life easier. Programs are made so that the simplest option is the base option. This is because there is a high expectation that things will be scripted AND understanding that there is a wide breadth of user preference. There's an important rule DON'T TRY TO MAKE A ONE SIZE FITS ALL PROGRAM Customization is at the root of everything. We have aliases that solve most of the problems and small functions for everything else. You default to an non-noisy output, showing only __essentials__ and nothing more unless asked. Similarly, you do no filtering other than hidden files. This way, everyone can get what they want. Btw, this is why so many people are upset with default options on things like fdfind and ripgrep. For your problem with git, there are 2 solutions you have. # alias git branch using git git config --global alias.branch 'branch -vv' # write a simple function and add to .bashrc or .zshrc or .*rc git() { case "$1" in branch) shift command git branch -vv "$@" ;; *) command git "$@" ;; esac } > We need to stop conflating elitism with fucked up design. The design isn't fucked up, it is that you don't understand the model. This is okay. You aren't going to learn it unless you read docs or books on linux. If you learn the normal way, by usage, then it is really confusing at first. But there is a method to the madness. Things will start making more sense if you understand the reason for the design choices. (In a sibling comment I wrote the abstraction to command patterns that makes the gp's confusion odd. Because systemd follows the standard) Side note: if you try to design something that works for everyone or works for the average person, you end up designing something that is BAD for most people. This is because people's preference is not uniformly distributed, meaning the average person is not representative of any person in the distribution. This is because anything that is normally distributed has its density along the shell while a uniform distribution has a uniform density all throughout it.
crabbone 2y ago
In my experience, most of the times a service fails, it fails on startup (misconfiguration, missing resources). So the status is OK. Also, you can always request more lines, if you think that's helpful. This wouldn't be my problem with systemd. Not by a long shot.

Denvercoder9 2y ago

In case you don't know, you can use the `-n` argument to `systemctl status` to tweak the log output, e.g. `-n0` to disable the log output and `-n40` to get more than the default 10 lines.

zamadatix 2y ago
That's a great option to tweak the behavior and I hadn't known about it (or if I ever had, I'd well forgotten). Thanks! From the man page it ?looks like? if you want reverse or full then it's still off to the journalctl command and arguments but at least "-n9999" is better than "always 10 lines".
- godelski 2y ago
  FWIW, I don't want that behavior. 10 lines is great for my usage. And IIRC you can change the default behavior. In the worst case, just alias it if it is bothering you that much.
  - zamadatix 2y ago
    Glad you like it! I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias and be even more lost when I don't have it or am working with someone else though. At least for the super common tools like git, systemctl, grep, and the like.
    - godelski 2y ago
      > I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias I highly encourage you to learn the commands. But it seems like you did. I would not call something so stylistic as `git branch -vv` as "sticking your head in the sand". Your fallback is not going to really confuse you or put you at risk of not knowing what's going on. I can totally understand if we were talking about aliasing something much more complicated, but at that point it's a script...
kai-tub 2y ago
Nice! I didn't know that was an option. Definitely something I should make configurable in `isd` :+1:

SJC_Hacker 2y ago

> My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately. How about systemctl status foo | tail

kristopolous 2y ago

it's the same mentality that brought us the git design - the easiest, least typing options are rarely, if ever the thing you want to do. Instead, these invocations give cryptic messages, throw errors, or sometimes, even break things. The most common and helpful things are hidden deep behind multiple flags and command line arguments in manuals that read like dictionaries more than guides. I'm always at a complete loss as to how such decisions are made. For instance, "git branch -vv" is the useful output you would like to see, every time, that should be "git branch". Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... I know people defend this stuff, but as a senior engineer in programming pits for 30 years, they're wrong. Needless mistakes and confusions are the norm. We can do better. We need to stop conflating elitism with fucked up design.

godelski 2y ago
> Why not make the current output, "git branch -qq"? Is a humane interface too much to ask for? Apparently... Yes, it is too much. You have the wrong mentality, and I hope this can help make your life easier. Programs are made so that the simplest option is the base option. This is because there is a high expectation that things will be scripted AND understanding that there is a wide breadth of user preference. There's an important rule DON'T TRY TO MAKE A ONE SIZE FITS ALL PROGRAM Customization is at the root of everything. We have aliases that solve most of the problems and small functions for everything else. You default to an non-noisy output, showing only __essentials__ and nothing more unless asked. Similarly, you do no filtering other than hidden files. This way, everyone can get what they want. Btw, this is why so many people are upset with default options on things like fdfind and ripgrep. For your problem with git, there are 2 solutions you have. # alias git branch using git git config --global alias.branch 'branch -vv' # write a simple function and add to .bashrc or .zshrc or .*rc git() { case "$1" in branch) shift command git branch -vv "$@" ;; *) command git "$@" ;; esac } > We need to stop conflating elitism with fucked up design. The design isn't fucked up, it is that you don't understand the model. This is okay. You aren't going to learn it unless you read docs or books on linux. If you learn the normal way, by usage, then it is really confusing at first. But there is a method to the madness. Things will start making more sense if you understand the reason for the design choices. (In a sibling comment I wrote the abstraction to command patterns that makes the gp's confusion odd. Because systemd follows the standard) Side note: if you try to design something that works for everyone or works for the average person, you end up designing something that is BAD for most people. This is because people's preference is not uniformly distributed, meaning the average person is not representative of any person in the distribution. This is because anything that is normally distributed has its density along the shell while a uniform distribution has a uniform density all throughout it.

crabbone 2y ago

In my experience, most of the times a service fails, it fails on startup (misconfiguration, missing resources). So the status is OK. Also, you can always request more lines, if you think that's helpful. This wouldn't be my problem with systemd. Not by a long shot.