An ncurses-based multiplayer/multispecies space conquest game, supporting complex star systems and ship types. Defeated enemy craft can be looted for spare parts or added to one's own fleet. Multiple players can colonize a single planet/moon/star (in the latter case, only if their species[es] actually can deal with the surface temperature of said star). Not 100% feature complete yet.
Yeemp is a decentralized instant messaging system. It uses GPG over SSL for encryption, and UTF-8 to enable non-Latin text to be transferred. The X client can request and receive webcam feeds. The clients include support for Japanese, Cyrillic, and Ogham input, as well as direct UTF-8. Yeemp includes a command-line client, an X client, a server, and a simple Web-based client. The clients can also use the AIM and ICQ protocols.
Lluzhionne is a very configurable Webcam program that can apply randomly selected captions, dates, and filters to images before uploading them. It comes with a default set of filters that use NetPBM and ImageMagick; others can be easily added. It can upload images using SCP. It supports Casio digital cameras, YUV420P Video4Linux devices, and grabbing images supplied by an external Webcam program. It does not require X11. It has been tested using the Casio QV-10A digital camera and the Phillips (pwc driver) Logitech QuickCam Pro 4000.
Vertica Smile is an expressive programming language combining the low level machine access and portability of assembler with the readablity of Brainfuck. The Vertica Smile language supports soft tokenization and token redefinition. Assembly, Brainfuck, F*ckf*ck, and Ook! code can be inserted inline as desired. The compiler generates small, fast statically linked executables with small memory footprints.
Nematocyst is an active counter-measure for the spamforo trojan botnet. Spamforo makes the infected machines send piles of spam; nematocyst emulates an infected machine, but doesn't send any spam. The intent is to make the trojan network useless by loading it with fake slave clients.
Yuri no Yume is a hentai romance game starring two young girls caught up in dark mysteries: Phoebe, sweet and innocent and strangely obedient, and Chelomnya, haunted by dreams that creep into the waking world. The story features original art by Papillon and soundtrack by Choronzon.
Tentacularity is a hentai puzzle game. The gameplay is similar to that of various pipe puzzle games, with a couple of new twists. The game adds double-penetration levels and rotatable tentacle segments. It's recommended for mature audiences. Other features include a CG gallery, the ability to start from higher levels once they've been reached, and adjustable difficulty.
Date Warp is an anime-style branching visual novel game with eleven different endings and five datable characters. The story starts with Janet and Bradley, who become stranded at a mysterious mansion in the woods while on their first date. The plot thickens when they realize that a mad scientist is hiding something in the basement.
Cute Knight Kingdom is a multi-ending RPG in which a girl named Sorami searches for her destiny. In the game, you travel the kingdom to meet new friends, find treasure, and encounter monsters. You must choose your weapons or craft them yourself, work at jobs, and take classes to raise the skills that you need for success. You could become a hero, find true love, discover the truth of your origins, or embrace villainy as an evil warlord. Dozens of endings are available, depending on your choices.
Re: You are wrong!
> And, by the way, making a system with no
> INHERENT ASCII compatibility doesn't
> nearly mean making a system with
> ABSOLUTELY no ASCII compatibility. ASCII
> is a very simple code, and writing a
> conversion module is more than easy. I
> think dropping the inherent
> compatibility wouldn't even be apparent
> to the simple user, he could still load
> and save ASCII files like before, all
> the work could be done by transparent
> filters on a kernel level.
User-transparent character set conversion is a Bad
Thing - it requires that *all* data carry encoding
markers, and allows plenty of room for seamless
data corruption (what happens when you save a file
after pasting data in a different encoding in? Does
the UCS-4 Han supplemental plane glyph in
someone's name get saved in /etc/passwd as UTF-8,
or does /etc/passwd become a UCS-4 or UTF-16
document when you're not looking? Or does it get
translated into ASCII or UTF-7? What if the translation
Character set conversion in the kernel is a Terrible
Thing. It opens up room for all sorts of problems
(like those IIS path traversal bugs that use overlong
UTF-8 sequences to take advantage of someone's
broken UTF-8/UCS-2 converter.), wastes resources,
and will probably slow down many operations that
have no business knowing or caring what character
set you use.
32-bit text format
(Of course, this appears right as I'm uploading
a UTF-8-native version of Yeemp...)
Problems - first off, everything has to be
audited and recompiled - malloc(strlen(src)+1)
needs to become malloc(strlen(src)+sizeof(char))
everywhere it appears.
Second: Confining things to 7bit seems wasteful.
The only reason to use 7bit is to transfer data
cleanly over 7bit-only links. 7-bit protocols
will require that the commands be in 8-bit chars,
even if the data are in 32-bit chars. To deal
cleanly with many 7-bit protocols, you'll need to
avoid using a large number of control and ASCII
glyphs in the 32-bit chars. Worse, the glyphs
to avoid differ from protocol to protocol.
Embedded nulls and CRs or LFs will break almost
any 7-bit protocol; @ signs in the wrong place
will choke SMTP; . will confuse domain resolvers;
space will confuse webservers. The characters
remaining for your encoding (and that's just after
chopping the ones that I think'll cause problems)
will probably make Base64 look pleasant. Further,
parsing a glyph index composed of discontiguous
septets in a 32-bit word will be a nuisance to
any program which has to deal with them. If
you're changing the char size, it breaks enough
stuff as-is that there's no point in trying to
get it 7-bit-clean *too*.
However, I do want one single giant character set, whether
it's 16-bit, 32-bit, or something else. Having
to tag every bit of content with encodings is
annoying (when it's text files), infuriating
(when it comes to files with multiple chunks of
data in different encodings), unfeasible (how
am I supposed to indicate the encoding for
email@example.com, where 'host' is in Devanagari
and 'user' in Hangul?), and unreliable (when every
web browser comes with a list of every encoding
that any other web browser ever claimed to support...).
IMO, display, character sets, and input are
things that should be semi-independant - I don't
want to put the BFF on my emergency boot
disk, and input methods that are great for one
language may be suboptimal or terrible for