6 ms·

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 fo

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.

Liquix 5y ago
>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.
- dangerface 5y ago
  > 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?
- overgard 5y ago
  And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?
  - Rygian 5y ago
    They<the package maintainer> ≠ They<the committee>
  - 2muchcoffeeman 5y ago
    They also mentioned how this could happen at the end of the article. In the end they are working on a distro with certain ideals and this illustrates how they can achieve things with their ideals in mind.
    - deleted 5y ago
      [deleted]
  - assbuttbuttass 5y ago
    Only in unstable
  - jjoonathan 5y ago
    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. That's the point of it.
    - overgard 5y ago
      I don't see how deprecating "which" helps any of that, or any stability in general.
  - cpuguy83 5y ago
    On Debian "unstable".
- throwaway984393 5y ago
  Slowly is right. Every time they release a package it's 2 years after the source code was published.
- cryptonector 5y ago
  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.
exporectomy 5y ago
> The amazing thing is 'which' was working perfectly fine for everyone. 'everyone' = existing users. New users are generally harmed by redundancy and mess.
- verve_rat 5y ago
  New users are also harmed by change. Our user manuals are the Google index, so change mean those manuals become outdated. As in all things, it is a balancing act.
  - exporectomy 5y ago
    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.
- Pxtl 5y ago
  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.
bachmeier 5y ago
> 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.
- pdimitar 5y ago
  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.
  - na85 5y ago
    >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.
akomtu 5y ago
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.
belorn 5y ago
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 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.

Liquix 5y ago

>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.

dangerface 5y ago
> 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?
overgard 5y ago
And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?
- Rygian 5y ago
  They<the package maintainer> ≠ They<the committee>
- 2muchcoffeeman 5y ago
  They also mentioned how this could happen at the end of the article. In the end they are working on a distro with certain ideals and this illustrates how they can achieve things with their ideals in mind.
  - deleted 5y ago
    [deleted]
- assbuttbuttass 5y ago
  Only in unstable
- jjoonathan 5y ago
  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. That's the point of it.
  - overgard 5y ago
    I don't see how deprecating "which" helps any of that, or any stability in general.
- cpuguy83 5y ago
  On Debian "unstable".
throwaway984393 5y ago
Slowly is right. Every time they release a package it's 2 years after the source code was published.
cryptonector 5y ago
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.

exporectomy 5y ago

> The amazing thing is 'which' was working perfectly fine for everyone. 'everyone' = existing users. New users are generally harmed by redundancy and mess.

verve_rat 5y ago
New users are also harmed by change. Our user manuals are the Google index, so change mean those manuals become outdated. As in all things, it is a balancing act.
- exporectomy 5y ago
  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.
Pxtl 5y ago
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.

bachmeier 5y ago

> 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.

pdimitar 5y ago
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.
- na85 5y ago
  >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.

akomtu 5y ago

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.

belorn 5y ago

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 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.