Re: [dev] suckless indicators?

From: Nikita Zlobin <nick87720z_AT_gmail.com>
Date: Thu, 8 Jul 2021 14:47:19 +0500

In Thu, 8 Jul 2021 10:42:57 +0200
Страхиња Радић <contact_AT_strahinja.org> wrote:

> On 21/07/08 12:30, Nikita Zlobin wrote:
> > Perhaps because user wants :P
> [...]
> > Writing to window title is primary function of my approach. It
> > could be done by main app (best), but this time it's dedicated
> > script, designed to run parallel and write to window title, while
> > main app displays it content. How can it be more minimal?
> [...]
> > - Main app, doing it themselves? Better of has. Or find better
> > point to add this feature for app, that doesn't support that.
>
> Catering to user desires is a pitfall which leads to bloated
> software. It is easy for the users of suckless software to customize
> it, so there's no need to include those customizations in the main
> repositories, except maybe as patches. The drawbacks of doing the
> opposite outweigh the benefits.

People don't serve machines - machines serve people.
Reason for bloatness I could mention - uncarefullness in design,
coding, patching, searching easiest solution way (workarounds). Adding
some features in progress may be impossible due to design limitations.

I always understood suckless way to be such, when workarounds are
unacceptable, with everything only made as optimal as possible.
Otherwise it looks like people suck, machines rule.
I already pointed example about uncareful symbols naming in arg(3)
interface, implemented by plan9 libc header - this is right case, where
design-level development is not complete (sucks).

Btw, I could note, that current way of configuration via patching is
not perfect (using term "sucking" is unspecific):
- patches must be optimized for perception if they are to be checked by
  all, who just want to build. Perhaps, it's problem of diff viewers -
  e.g., they may add gaps without reason among all strange decisions
  about how to visualize diff.
- single patch per feature may be not okay for review if one such
  feature requires multiple different change stages, each deserving
  separate patch. Well, this time I have no certain idea, which would
  be sure current suckless paradigm. If I were to add optional feature,
  then neares to suckless configuration way I know is using env vars:
  make PARAM=VAL.
Received on Thu Jul 08 2021 - 11:47:19 CEST