sites

public wiki contents of suckless.org
git clone git://git.suckless.org/sites
Log | Files | Refs

index.md (6393B)


      1 Project ideas
      2 =============
      3 Please read our [philosophy](/philosophy) for background information.
      4 
      5 Peer review
      6 -----------
      7 The suckless.org community will act as a rigid reviewer of the progress.
      8 
      9 General ideas
     10 -------------
     11 Our project ideas in general intend to focus on our innovative development
     12 environment from bare hardware to the graphical interface.
     13 
     14 * Idiomatic interfaces for developers (such as more advanced concepts for mail
     15   clients, messaging clients, music players, text editors).
     16 * Simple protocol interfaces for developers.
     17 * General userland enhancements to UNIX-like operating systems.
     18 * Foundations of a new windowing system for UNIX-like operating systems.
     19 * Improvements to our existing software projects and infrastructure.
     20 * Replacements of bloated existing software and libraries in a suckless way.
     21 
     22 
     23 Current small tasks
     24 -------------------
     25 * Write a gopher back-end using build-page.c:
     26   <https://git.suckless.org/sites/file/build-page.c.html>
     27   This should use the geomyidae gopher server and the gph output format.
     28   Difficulty: medium-rare.
     29 * Fix broken patches on the wiki. Difficulty: trivial-medium.
     30 * Fix typos and formatting errors on the wiki. Difficulty: trivial.
     31 
     32 
     33 Concrete ideas
     34 --------------
     35 The listed ideas generally require good knowledge of C and experience with
     36 UNIX-like operating systems. The difficulty ranges from medium to high.
     37 
     38 
     39 ### Suckless font rendering library
     40 
     41 There is libdrw in suckless now, which still uses xft and fontconfig.
     42 Fontconfig and xft are ugly and require too much internal knowledge to be
     43 useful. The next logical layer evolved as pango and cairo. Both of course added
     44 HTML formatting and vector drawing. This is not needed to simply draw some text
     45 somewhere. And this is what a suckless font rendering library should do: Give
     46 it a font string and render at some position the given font without having to
     47 care about font specifics.
     48 
     49 [Some work](https://git.ekleog.org/leo/dtext) has already been done to replace
     50 libXft and Fontconfig. Real-world testing is however still needed.
     51 
     52 A simple solution is [Scalable Screen Font](https://gitlab.com/bztsrc/scalable-font2),
     53 which is a dependency-free, single ANSI C89 header file that can render bitmap,
     54 pixmap and vector fonts using the same API. Uses a very efficient font format and
     55 includes a multiplatform command line tool to convert virtually all font files
     56 into .sfn files. Comparable to professional font rendering engines, supports
     57 UNICODE, scaling, anti-aliasing, alpha-blending, kerning, ligatures etc.
     58 
     59 ***Requirements:*** C knowledge, some X11 knowledge and of course knowledge
     60 about the font formats and how to handle them.
     61 
     62 
     63 ### Write ld wrapper or replacement for static linking
     64 
     65 The GNU autotools such as automake and autoconf are completely unusable in
     66 non-chroot'ed cross-compile environments and often completely fail to produce
     67 statically linked libraries or executables. Also they are extremely slow and
     68 bloated.
     69 
     70 The stali build system is not using autotools for good reason, however many
     71 UNIX/Linux open source packages do. To create statically linked libraries out
     72 of the ld arguments we need an ld wrapper or re-implementation that creates
     73 static libraries or executables. This would enable us to build static libraries
     74 and executables out of any automake generated makefiles without the need to
     75 write make replacements or patching the build system of a particular package.
     76 
     77 The ld wrapper needs to be extended to also link against uclibc first and if
     78 that fails to fallback to glibc, in order to produce smaller executables in the
     79 general case.
     80 
     81 ***Requirements:*** Good C/UNIX knowledge is essential, knowledge about
     82 linking/linker internals are desirable.
     83 
     84 
     85 ### Write a decent mailing list Web archive system
     86 
     87 All web archive systems such as hypermail, pipermail, etc. have plenty
     88 drawbacks and are quite out-dated. This task requires to write a completely new
     89 web mailing list archiving tool that follows the thread view concepts found in
     90 the mutt MUA and which is designed with low footprint and efficiency in mind.
     91 
     92 We expect this tool as a stand-alone UNIX tool written in C or shell. To get
     93 started you could use [Dovecot](http://dovecot.org/) to produce a sanitized
     94 structure:
     95 
     96 	printf "1 select inbox\n2 thread references us-ascii all\n3 fetch 1:*
     97 	envelope\n4 logout\n" |
     98 	/usr/local/libexec/dovecot/imap  2>/dev/null
     99 
    100 * <http://www.codinghorror.com/blog/2012/12/web-discussions-flat-by-design.html>
    101 
    102 ***Requirements:*** Good C/Shell/HTML knowledge would be desirable. Must not
    103 use Javascript.
    104 
    105 
    106 ### Write cookie handler for surf
    107 
    108 The biggest disadvantage of [surf](//surf.suckless.org) is sloppy cookie
    109 handling. libwebkit and libsoup (which are used for HTTP) were never designed
    110 to run in multiple processes simultaneously.
    111 
    112 This task requires writing a new cookie handler in surf which:
    113 
    114 * creates a nice human-readable cookie file
    115 * is able to run in multiple concurrent processes
    116 
    117 ***Requirements:*** Good knowledge of C and POSIX file locking. Basic knowledge
    118 of GTK and its other evil friends.
    119 
    120 
    121 ### Gopher services
    122 
    123 Gopher is a sane protocol which has hierarchy in its design. It allows the
    124 abstraction of a mass of information in a filesystem. The goal of this meta
    125 project is to find ideas how to implement gopher services to easily access the
    126 web and new information.
    127 
    128 See the
    129 [protocol](https://en.wikipedia.org/wiki/Gopher_%28protocol%29#Protocol) for
    130 how easy it is to write a `menu`, which can be seen as a directory.
    131 
    132 * [gopherproject.org](http://www.gopherproject.org)
    133 * [gopher proxy](http://gopher.floodgap.com/gopher/)
    134 * [Gopher wikipedia article](https://en.wikipedia.org/wiki/Gopher_%28protocol%29)
    135 * [geomyidae](http://git.r-36.net/geomyidae/)
    136 
    137 Anyone creating a gopher interface to suckless.org will get a bonus.
    138 
    139 ***Requirements:*** Just some shell scripting and a way to setup a gopher
    140 daemon is required. Everyone can do this.
    141 
    142 
    143 ### A sane backend for surf
    144 
    145 There is dillo, netsurf and abaco which implement HTML. The problem is
    146 Javascript and extensions to replace webkit as the big dependency hell for web
    147 rendering in surf.
    148 
    149 If you prepare to work on this project, plan ahead in recruiting more
    150 developers. You will need them.
    151 
    152 ***Requirements:*** Very good C knowledge, a very good knowledge in web
    153 standards and how to strip them down to the suckless level. ***Difficulty
    154 level:*** Probably impossible.