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
