When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.
>I can't help but wonder how anything ever even gets done on this project
Slowly, methodically, and with minimal user impact.
As mentioned at the end of the article, what first appears a waste of time for a small issue could also be seen as a beautiful illustration of the democratic process that makes Debian so stable/widely adopted.
They destabilize it less than other packaging ecosystems.
I tried Manjaro the other day -- out of the box, wake from sleep was broken, bluetooth was broken, and 3/3 printers were broken. I eventually got sleep working with an older kernel version, I got bluetooth working with config file hacking, and I got the printers working with CUPS wrangling -- but on Ubuntu, all of this Just Worked for me.
Removing which(1) is NOT "minimal user impact". Evidently it's also not minimal maintainer impact. All this sturm und drang of which(1) is completely unjustified and far exceeds the work of including that BSD option or deciding to not include it.
> Slowly, methodically, and with minimal user impact.
I am confused. Isn't the article about an individual just randomly deciding to deprecate which and the resulting fallout that impacted all of Debians users?
The standard approach is to let the maintainer make all decision in their own supported packages. This works in 99.99% of the time and if someone else wants to do the work of supporting a package then there are always alternatives. Being asked to do the work of supporting a whole package is generally a rather large commitment and Debian developers tend to be busy enough that fighting over being the maintainer of larger packages isn't that common, especially if the contention is over a small thing.
That is how things get done. If you do the work you get to decide.
In the 0.001% that an issue get taken up by the technical committee as being important for the whole project, then after usually a long time they make a decision that in special cases may overrule the maintainer. That happens about once or twice a year? I am unsure how often a decision actually goes against the maintainer, and there is only a few cases a year (https://www.debian.org/devel/tech-ctte).
This naturally doesn't stop anyone from being too active on the mailing lists and arguing over small things, but I would think people are wasting less time there than they do arguing lesser important topics on social media.
> When I read stuff like this I can't help but wonder how anything ever even gets done on this project.
Many years ago, I posted that stable was too old. All the Debian users were quick to tell me to run testing, that it wasn't a bad experience in spite of the name. Well, after converting all my machines to Debian, a package that was critical to my work was broken and I was not at all impressed with the handling of the situation, so I moved on. I can definitely see something like the story in the article playing out.
I moved on from Debian some 9-10 years ago and I haven't regretted it once. Many sysadmin acquaintances and former colleagues of mine complained that upgrading Debian is often like rolling a dice (yes, even the stable and thus fairly old variant). An innocent "apt-get upgrade" moves configuration files and/or expectations where they are, or, what's even worse, changes the config files and silently moves the previous ones to another file. This is sensible but obviously a 99% automated process run on a fleet of servers cannot detect this and those acquaintances of mine regularly had to fight with the consequences. Some even resigned when management refused to let them move to another distro. Other were more lucky and managed to move.
I am not a sysadmin and very far from an expert so my take on this is entirely anecdotal and likely partially wrong.
But ever since I moved to Manjaro (after briefly trying Arch and deciding that I don't want to build my own house brick by brick) I've only had 1-2 problems ever and they were fixed literally the day after with the next system-wide update command. The one and only exception is the last problem I had: namely an OpenSSH upgrade hard-deprecated a few signing algorithms so I was unable to SSH into my servers. And that was solved with half a minute of search on ManjaroForum. Smooth sailing.
For all the BS surrounding the "systemd vs. whatever-else-the-other-thing-was", I found the former made my life as a mid-tier Linux user and home-grown server admin much easier, too.
>or, what's even worse, changes the config files and silently moves the previous ones to another file.
I run Debian on my servers because I like not having to wrestle with Yast2 or deal with the constant churn for churn's sake of certain RPM-based distros.
The above quote hasn't really been a thing since at least Debian 8, and possibly 7. Certainly when it came time to upgrade to 11, if package configs were being overwritten I was presented with a diff and asked what I wanted to do.
My Debian 10 box updated last week and now its down. Its probably just a config file has changed but no mail for me till I get it fixed. Centos never had this issue I wish it was still a thing so I dont have to use Debian
> For all the BS surrounding the "systemd vs. whatever-else-the-other-thing-was", I found the former made my life as a mid-tier Linux user and home-grown server admin much easier, too.
Yeah, I'm sympathetic to some of the anti-systemd stuff, but I've found writing systemd units so much easier and more reliable than upstart or sysv init scripts. And sd_notify is great.
I moved to Debian (almost 20 years ago) because the upgrade was the _least disruptive_.
YMMV, Debian isn't for everyone, but it's been rock solid for me with very few exceptions, far fewer than I've seen from other folks with other distributions.
Oh yeah, and I do that 99% of the time. Only if somebody asks or if I want to make a point on HN.
As time goes by (I am 41) I really find it less and less appealing to argue with people, on HN included. People can tell you "just do X, you won't regret it!" or "use Y, most of your problems will go away" but you are there happily doing A and using B and they serve you perfectly.
So if I am asked about what would I recommend as best practices, I always say: "if you have needs X, Y and Z, then using A and B is perfect".
Just saying "use Arch, it's best Linux eva duuuuude" is of course unproductive.
For a perfectionist like that dude, the imperfect "which" is nails on chalkboard. He also gets to scratch his ego which justifies any amount of time wasted by others.
Sure, there's balance. The idea that it was working fine so why change it leads to gigantic bloated software that nobody can really understand.
As an anecdote. I developed a product in a field where the main players were extremely well established with codebases dating back to punch card days. Their software could do everything you might imagine wanting it to do. But it was also so complex, you had to take a training course to learn it. But what's interesting is there were customers of those competitors who also bought my product because it was quicker and easier to get common things done. All that power actually let to a worse product in some ways.
Except new users are coming from other platforms that have a "which", and also new new users have to learn the commands and it helps if they have intuitive terminology like "which" instead of opaque names like "command -v" which at a glance I'd assume fetches version info of the given command.
