[kristopolous]

You're fundamentally misunderstanding things.

If every person has the same point of confusion than they are not the problem, it's the thing they're confused by.

There's better ways to do things and calling people naive for suggesting the obvious is the problem.

And about your side note: no. For example, when people checkout a branch, they want to track the remote branch 99.9% of the time. It should be the default.

The default journalctl should show where things have failed, that's why people are invoking it.

Also there's plenty of counterexamples that do these things. "ping host" genuinely pings the host. "ssh host" genuinely ssh's into the host.

You don't need to specify say, the encryption algorithm, that you want a shell, use say, "--resolve=dns" to specify the hostname resolution... It has sensible defaults that do what most people intend.

Under the model you advocate for "ssh host" would simply open up a random socket connection and then you'd have to manually attach a virtual terminal to it and request the invocation of shell separately, stacking each piece on top of the other, before you log in.

This design could be defended in the same way: Some people do port mapping, tunneling, SOCKS proxies, there's too many use cases! How can we assume the user wants a shell? Answer: because they do.

Most things are reasonable like certbot, apt, tune2fs, mkfs, awk, cut, paste, grep, sort, so many reasonable things. Even emacs is reasonable.

But systemd and git are not and the users are not the problems. Choices were made to be hostile to usability and they continue to be defended by being hostile to usability. Things like lex and yacc are inherently complicated and there's nothing to do there. Other things are intentionally complicated. Those can be fixed.

[godelski]

  > The default journalctl should show where things have failed

How? What do you filter for? Emergency? Critical? Error? Alert? (see `dmesg -l`). What's the default? Do you do since boot? Since a certain time? Since restart?

FWIW, I invoke it all the time for other reasons. I am legitimately checking the status. Is it online? Do I have it enabled? What's the PID? Where's the file (though I can run `sudo systemctl edit foo.service`)? What's the memory usage? When did it start? And so on. The tail of the log are useful but not the point of status.

If I'm looking to debug a service I look at the journal instead. I hope this helps

  # Show 10 most recent logs (you don't know what service to debug)
  journalctl -r -n 10
  # Show recent logs for a known service (can tab complete)
  journalctl -r -n 10 --unit foo.service
  # Some useful flags
  -S, -U
    Since and until. Time filtering including keywords {now, yesterday, today, tomorrow}
  -b
    Since boot. You can even do since a specific boot! Or even `--boot=-1` for the last 2 boots
  -p, --priority
    You can use the numbers 0-7 representing {emerg,alert,crit,err,warning,notice,info,debug} respectively
  -g, --grep
    No comment needed 
  -f, --follow
    This is the tool while debugging since it'll update.
  -e, --pager-end
    Start at the end of the pager 

  > that's why people are invoking it.

That's why __you're__ using it, but don't assume that your usecase is the general. Remember, linux has a large breadth in types of users. But their biggest market is still servers and embedded systems. There's far more of those than PC users.

  > Choices were made to be hostile to usability and they continue to be defended by being hostile to usability.

Idk, when systemd became the main thing I hated it too. But mostly because it was different and I didn't know how to use it. But then I learned and you know what? I agreed. This took awhile though and I had to see the problems they are solving. Otherwise it looks really bloaty and confusing. Like why have things like nspawn? Why use systemd jobs instead of using cron? Why use systemd-homed instead of useradd?

Well a big part of it is security and flexibility.

I write systemd services now instead of cron jobs. With a cron job I can't make private tmps[0]. Cron won't run a job if the computer is off during the job time. Cron can't stagger services. Cron can't wait for other services first. Cron can't be given limited CPU, memory, or other resource limitations.

Nspawn exists to make things highly portable. Chroot on steroids is used for a reason. Being able to containerize things, placing specific capabilities and all that. This is all part of a systemd job anyways. It really makes it a lot easier to give a job the minimum privileges. So often nspawn is a better fit than things like docker.

Same goes for homed. You can do things like setting timezones unique to users. But there's so much more like how it can better handle encryption. And you can do really cool things like move your home directory from one machine to another. This might seem like a non-issue to most people but it isn't. That whole paradigm where your keyboard is just an interface to a machine (i.e. a terminal, and I don't mean the cli. There's a reason that's called a terminal "emulator"). This is a really useful thing when you work on servers.

Look, there's a reason the distros switched over. It's not collective madness.

[0] https://www.redhat.com/en/blog/new-red-hat-enterprise-linux-...

https://systemd.io/

[kristopolous]

I'm not assuming I'm the default. I've worked countless jobs where I'm the "linux guy". These are the most common points of failure for everyone.

You have yet again showed how you are one of the 0.1%.

Why should the defaults be to accommodate for you?

I've been using linux for over 30 years. I'm in that group photo on the Debian.org homepage, given Linux conference talks spanning decades...

I know I'm in a very small minority and don't expect everyone to be me.

I work a support shift at a cloud hosting company and constantly deal with our customers struggling with linux on the same pain points over and over and over again. We have a bunch of auto-replies to explain things because everyone trips over the same broken sidewalk and people insist it's not broken but instead, it's beautiful design. Alright, whatever. Keeps me employed. Cool.

This is the same problem that mathematics has. Elite mathematicians insist that they should give zero shits about trying to explain things and their convoluted impenetrable explanations are elegant - it's an ultra-exclusive nerd club and most people aren't invited regardless of their interest.

Making things more approachable is somehow, cognitively unavailable to them or against some deeply held constitution. Whatever it is, it's not happening.

Some people think iOS is successful and some people think Mobian should be. I try to understand the first group and not insist everyone be in the second.

[godelski]

  > Elite mathematicians insist that they should give zero shits about trying to explain things and their convoluted impenetrable explanations are elegant

I'm here trying to explain...

I'm very much not trying to be like the Arch userforum and say that this problem was solved 3 years 7 months, 22 days, 9 hrs, and 13 minutes ago but will also not provide you a link or any more reference to this because I'm closing the topic. There 100% are elitists. But not everyone who agrees with their point is an elitist. That experience is always frustrating because a noob doesn't know what questions to ask or what terms to search. It's true that in any domain that a task is literally easier for the domain expert than the noob because the noob doesn't even know where to start looking.

As for users, I do agree that there's a lot of common stumbling blocks. But I also notice (the same problem exists in math) that a holistic view is not taught with or before specifics. These things have to be taught together, but if you try to just learn linux a command at a time (math an equation at a time or programming a function/algorithm at a time) you're going to be stunted for a very long time. The abstractions matter.

But why are aliases and functions disallowed? I've thought the TUI boom has been a great thing for users, although I wish TUI developers would spend just a bit more time doing design and understand that "has vim movements" means more than h,j,k,l arrow keys... There's lots of great alternatives to the most common coreutils. But I am still a firm believer that people should be making their own rc files. Especially today where it is trivial to carry them around with you. Hell, I even throw notes in my dotfiles. The whole thing is 84M and 81M of that is vim plugins, so not even part of the git repo.

  > Some people think iOS is successful

Well I still don't know how to get my iPhone to stop correcting two words back. You'd think turning off General > Keyboard > Auto-Correction would do it. Nope. Maybe Predictive Text? Also no. But then again, you'd think that Auto-Capitalization would capitalize the letter I when it is used as a single character but again, no, and you can always recognize an iPhone user because their "i"'s are never capitalized.

I'll tell you this. Linux is a pain. All of software is a pain. 90% of software is a pain and has no fucking reason to be. I can give you a hundred examples where trivial things make a huge difference. From fucking Meta's download for Llama not telling you how much disk space it uses and hard coding the destination (2 problems), how calendard won't merge holidays and instead you have 5 instances of MLK Jr's day, or how I can't disable Apple Music or remap my media keys so I can stop the god damn Music player app from opening or get it to stop playing some random youtube video in a lost tab rather than play the song on spotify that I literally just paused. But the reason I choose linux is because I can fucking fix those things. I hate it. So much of it. You're so right that so many things don't have to be this way. But at least with linux and it's design choices, I can fucking fix things. It isn't just the open source aspect that makes that possible and it isn't just documentation, it is the mentality that things should be small and simple. To really take to heart the concept of monads.

[kristopolous]

here's another for the list:

systemctl reboot -f should be the default for "reboot".

People generally already make sure there's nothing they care about running and then issue a reboot often because something is broken.

It's already mostly a manual override. The default makes it not a manual override but instead yet another operation of a system that is, under most reboot conditions, assumed to be tainted in some way.

If you want reboot to potentially require IPMI or some kind of manual intervention, it should be an option like

reboot --ask-everything --stall-on-crash-ok --wait-indefinitely-ok

or something that makes it very very clear what you're asking it to do.

Because how it currently is, reboot does not reboot, instead it inquires a potentially malfunctioning system what its opinion is on rebooting.

It effectively assumes every system is always in pristine condition and that users reboot out of boredom. If someone’s issuing a reboot, it's because something is wrong, and the system should treat that as the primary assumption.

[godelski]

  > systemctl reboot -f should be the default for "reboot".

I very much disagree. This is not what I want and certainly you can recognize that this is an unsafe operation, right? Less safe operations should ALWAYS require more work. Not everyone checks and it is also easy to forget or miss something.

  > reboot --ask-everything --stall-on-crash-ok --wait-indefinitely-ok

I like the --ask-everything option but I'm not sure how the other 2 can work. A crash, especially during shutdown, can have no guarantees of being caught. Or do you mean crashing user programs? Well then that's --force, right? The --wait-indefinitely-ok seems a bit weird too. Shouldn't that be configured in your boot options (or bootctl)? I do think there's reasons you might want this in one situation but not another so flag sounds good.

  > If someone’s issuing a reboot, it's because something is wrong

On personal machines: >9/10 times I'm rebooting because I installed a new kernel. Granted I'm usually running an arch distro, but even on other machines it's pretty similar.

On servers, yes, you're right, I reboot far less and am usually rebooting because a specific GPU server has a defective GPU that is often a pain to solve with rmmod and resetting manually, being just far easier to reboot the entire machine.

But I still think it's clear that what you think is "average" or "usual" is not. Literally the fact that you and I disagree on what our typical use cases is proof of this (note: I'm not saying _my average_ use case extrapolates, nor your average use case, nor anyone else I know or even don't know. I'm saying _average_ is not a meaningful thing. I mean this in the same way as taking the average of 2 samples from a normal distribution; doing so gives you a number that is not representative of the distribution).

[kristopolous]

Average is not the advocacy, it's plurality.

Some behavior has to be chosen for some invocation.

I continue to express what countless people struggle with and potential usability fixes, and you continue to insist your personal preference is supreme and unilaterally invalidates everyone's frustration.

It's like insisting all cars should have tillers, manual chokes, and hand cranks because you personally like them and then handwaving some "average" argument when someone advocates for easier systems.

And that's the attitude what keeps Linux useful but not usable.