On Thu, Oct 02, 2014 at 05:23:39PM -0700, Kartik Agaram wrote:
> > Here is a list of things I think are suckless-specific in practice:
FRIGN did cover it in detail but I'd like to point out some further
details that I've noticed.
> > - C code (most often) written in a plan9 like style.
If you want to write idiomatic code it relies on having a bag of tricks
around all the time. Some code is inspired by Plan9, other code follows
some BSD style conventions and idioms. Other code doesn't exactly fit
into any existing category.
> > - Most often only one C file.
It most often is a single file but there are no hard rules. For example
some projects include things like queue.h from BSD which is obviously
a separate file. In sbase and ubase we have a util/ directory for common
operations which are built into an archive util.a and used by various
tools. If it makes sense to modularize, then it should be done.
> > - One config.h (config.def.h for defaults) for compile time options.
Again, a common misconception is using config.def.h for *everything*. This
simply doesn't make sense. config.def.h is mostly useful to set up
the permanent and static settings for a program. The program should be
entirely usable from the command-line as well or in some cases through an
external configuration file (see scron[0]). They may also be some overlap
in what's defined in config.def.h and what can be tuned at runtime.
In that case config.def.h acts more like setting the default behaviour for
a common operation.
> > - One simple makefile, no GNU make.
The makefiles we use mostly work on many systems even if not strictly POSIX
compliant. I am not a make expert so can't comment further.
> > - MIT license.
MIT for consistency. ISC is also a possibility but all projects are under
MIT so it makes sense to keep using it. The two licenses are equivalent
except that ISC has simpler wording.
> > - Sometimes line count limits, feature creep avoided (except in st IMO).
SLOC is only a hint, or rather a heuristic to provide a bit of confidence
into an unknown codebase. Writing clean code is far more involved
than minimizing SLOC.
> > - Releases (numbered) are meaningless, you must always use git HEAD.
Always test on HEAD before reporting issues or start writing patches.
Other than that you can use any of the released versions.
> > - Patches can be out of date, you are expected to adapt it and contribute back.
There's no hand-holding for forward porting patches (or backporting for that matter).
You are expected to care about the software you use and make it
better. It assumes you are a programmer and know how to code. If
this is not the case then learn how to program.
> > - Code reviews are thorough, patches are very sane IMO.
That's because the maintainers are sane too. For non-trivial things, you'll
see the maintainer posting a patch to get feedback from others.
> > - Except harsh comments if you suggest new things (true for everybody).
Not true. If you don't know what you are talking about then don't
waste time and go research it yourself. Come back with a patch and request
feedback.
> > - Do not expect support (even though you might get useful info by asking).
Again, learn how to program and send a patch.
> > - No users/customers, only programmers.
I am glad you realize this by now.
> > - People are picky about what system you use, if you use chrome/gnu, hide it.
Hide it well.
Cheers,
sin
[0]
http://git.2f30.org/scron
Received on Fri Oct 03 2014 - 11:05:50 CEST