Free hobbies software for linux

abcpp is a simple yet powerful preprocessor designed for, but not limited to, ABC music files. One of my hobbies is music: I play flute, recorder, whistle and clarinet, and I sing as a tenor in a choir. I find that the ABC music notation language is a wonderful tool to typeset sheet music. ABC is one of the best designed, easy to use, well-thought out, and nicely implemented notation formats Ive ever seen: IMHO, it surpasses other good notation languages like GNU Lilypond or MusiXTeX. (Philips Music Writer is a serious contender though.) You can write music in a very simple ASCII format and convert it to MIDI, or typeset it to make professional-looking scores.

The only serious problem with ABC is that it was originally designed for melody, not for harmony. In simple words, this means that you can only write music for a single instrument or voice. This is an example of what ABC can do; it sounds like this. Although it works beautifully for simple tunes and folk music, it can be not enough for Western classical music.

Some ABC applications implement unofficial extensions to the ABC language that make it possible to write polyphonic music. The purpose of the ABC Plus project is to provide software and documentation for this extended ABC. Here is an example of classical music written in ABC Plus; it sounds like this.

All RPMs available from this site were built on a Mandriva 2006 GNU/Linux machine.

VinoBase project is a documentation and management tool for hobby winegrowers.
It helps you manage your different preparations, recipes, yeasts, etc., and exports your results to different file formats.
Main features:
- Managing of preparations, yeasts and recipes
- Creating of a progress for every preparation
- Adding of evaluations
- Adding of labels
- Export as text file and as PDF document

Module::Install::Philosophy Perl module contains the concepts behind Module::Install.

SYNOPSIS

This document describes the personal philosophy behind the creation of CPAN::MakeMaker (the predecessor of Module::Install). The views expressed here belong to Brian Ingerson; if they are not of interest to you, you can safely ignore this document.

The above is obviously a mutation of the monumental speech by great Martin Luther King (http://web66.coled.umn.edu/new/MLK/MLK.html). While the contexts are vastly different, I feel that there are some serious parallelisms.
The CPAN has become a place that is not free of injustice. This situation has arisen not out of directed oppression, but from a failure of our community to keep its tools sharp. It is the culmination of many small decisions made in the name of practicality. This is a sad state for an institution that was created to allow all interested people to contribute equally to the best of their ability.

This assertion is rooted in my personal experience as an author. When I created my first Perl module, Inline.pm, I knew that I had done something important. But how was I to make a dent in vast Perl community?

As a complete unknown in the Perl community, my voice did not travel far. I repeatedly tried to get even an acknowledgment from the gurus familiar with XS. No success. I resorted to sending messages with ridiculous subjects to modules@perl.org. (http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-08/msg00078.html) No response. Through sheer determination and shameless self-promotion I eventually got the word out, and I hope the world is a slightly better place for it.
Since then, Inline has won awards and I have had the privilege to meet almost all of Perls finest. But I still remember the pain of starting out, and want to help invite more people into this wonderful world.

One thing I have learned from experience is that the Perl community (and throw in the Python and Ruby people as well) is a small drop in the vast ocean of programming. Its a giant pot of Java out there; and a sea of C. Perl may not be the biggest fish, but with some care and cunning we could become a much bigger school.

These are the current problems that I see with CPAN and the core modules:

New Modules dont help Older Perls
If I were to guess what percent of all Perl5 installations were at the current release level (5.8.0 in October 2002) I would say 3-5%. That may even be generous. Id say that over 40% of installations might still be at 5.005 or earlier.
The biggest problem with adding a module to the core is that it only helps a small subset of Perl users for a long long time. Worse yet, a good module author will still probably avoid using the core additions as prerequisites, because they want their new module to work as well on 5.005 as on 5.8.
CPAN::MakeMaker should be able to help in this regard. For example, instead of putting Inline.pm into the core for 5.9, I can now effectively get it into the core for every version of Perl that Inline supports.
Author Exclusiveness
Not just anybody can get a module into the core. It seems you have to know people in high places. If I were a brilliant new talent with a great new module, it would have a harder time getting the ear of the pumpking, then if I were, say, Damian Conway. In fact, I probably wouldnt even know where to start.
Reduced Competition
One comment Ive heard from some very good Perl programmers is "Everything important has already been done". Their feeling is that even though a module is suboptimal, it would be a waste of time to write a competing module. Who would use it instead of the one already in the core?
When I write a competing module, I know that I have to make it at least twice as good as the existing one to even get noticed. Thats not a bad thing, but should everybody be forced into that situation?
For example, lets say that you have created a really useful CGI script. Lets also say that it makes use of your own CGI::Special module, because CGI.pm doesnt meet your needs. Even though your script might be generally useful and worth sharing, the fact that it requires a non-standard module can only negatively affect its acceptance. Trying to get general acceptance for the superior CGI::Special module will be harder still.
Core modules are assumed by the general public to be "Best of Breed". While this may be true for some modules at some point in time, it keeps talented people from attempting to "breed" something better.
Core Bloat
Every time we add a module to the core it gets bigger and bigger. And we cant ever remove modules from the core, once theyve been added.
If I had my druthers, wed remove all modules from the core that werent necessary for either running Perl or installing modules. Of course, wed need to set things up so that installing modules was so easy, that it could be done on the fly if necessary. Is this easily accomplishable? Nope. Is it impossible? Nope. We have the best language in the world to help us do it!
Maintenance Bitrot
Believe it or not, Perl authors can sometimes acquire a "Life Beyond Perl". They get families or new hobbies or even hit by a bus. (This would be a "Death Beyond Perl".) The fact is, that once somebody writes a piece of code and shares it with the world, they are expected to maintain it for all time.
That is being generous. There are others that think that once their module has become popular or made it into the core, they dont need to keep fixing and improving it. I have personally been guilty of this sin.
And then theres the Damian Conway Effect. This plagues the exceptional authors who are so innovative and prolific they simply dont have time to maintain everything they have written.

I initially formalized these opinions at the YAPC (Yet Another Perl Conference) in June 2001. Since then I have been trying to think of technological solutions to fix these social problems.

One idea was dubbed NAPC. NAPC is CPAN backwards. It is a large system of precompiled modules that can be installed on the fly, with the goal of reducing the number of modules in the core. NAPC hasnt got started yet. Id still like to do it someday, but its a big problem with a lot of issues.

CPAN::MakeMaker (and now Module::Install) on the other hand, is simple and ultimately flexible. It should work with all of the existing CPAN processes without requiring any changes from them. And new features can be continuously added. Even though it doesnt scratch all of my philosophical CPAN itches, its a good start.

Large projects usually already have some type of mechanism for build numbering, because keeping track of which build is the latest can be very important information. However, even small hobby projects can benefit from a self-maintaining build numbering system.
BuildNumber project is a utility to add auto-incrementing build numbers to C and C++ projects. BuildNumber will create and maintain a single header file called buildnumber.h for your project which you can #include to access the current build number. BuildNumber is written in pure C for maximum portability, but the binary can also be used with C++ projects, and the source should compile with almost any C/C++ compiler.
The entire contents of a sample buildnumber.h are displayed below:
/* Generated by BuildNumber version 0.8 */
#ifndef BUILD_NUMBER_H_
#define BUILD_NUMBER_H_
#define BUILDNUMBER 53
#define BUILDNUMBER_STR "53"
#endif /* BUILD_NUMBER_H_ */
Every time you rebuild your project, BuildNumber will automatically update this file for you: set it up once, and it just works. You can compile individual files (to confirm syntax, etc) without incrementing the build number, because it only updates when you actually build or make your project.
Main features:
- Written in pure C for maximum portability
- Simple concept, simple solution, simple code
- Works seemlessly in C and C++ projects
- Sets up in minutes, then its entirely automated
- Works with virtually every C/C++ compiler on virtually every system
- BSD License for maximum freedom, even in commercial projects

Palace is a nifty visualization plugin for XMMS. Palace plugin works by reading the Fourier frequency analysis given by XMMS, and activating particular pins on the parallel port based on the frequency analysis and configuration options.
Palace is based on the XPLSISNJASP software project. For examples of hardware useful with Palace, see Discolitez or e-mail me at the e-mail address in the README file from the latest Palace version.
What will Palace become?
Palace is currently an XMMS plugin to control a light show connected to the parallel port. The eventual goal of palace is to provide a generic device control infrastructure for hobby (and possibly commercial) use. Over time Palace will be transitioned to a fully modular design, so that clients (applications trying to control something) and servers (libraries that act as an interface to an actual device) will be able to interact through a generic plug-in interface.
Palaces first goal is to become an XMMS parallel port light show plugin at least as good as the DiscoLitez (http://www.discolitez.com/) light show plugin for WinAmp, and then evolve into a full-fledged control system.
Possible server plugins would include:
- DMX-512 output to control professional lighting equipment
- Laser/stepper motor
- Parallel port
- Generic DAC
Possible client plugins would include:
- XMMS visualization plugin
- Security system control software
- Other automation software

Mediainlinux is a complete Linux distribution targeted at multimedia production, wich consist in a live cd (knoppix derived) containing more than 200 graphical application and thousands of command line tools for:

* Acquisition
* Conversion
* Editing
* Compression
* PostProduction in the Audio, 2D and 3D graphics and Video domain.

Mediainlinux distribution is a working prototype of a Debian Multimedia Distribution, based on the last version (3.4) of the Knoppix Linux Live Cd.

Our CD supports most of the graphic, audio and tv/satellite computer card on the consumer and prosumer market GNU/Linux compatible and has more than 200 graphical applications and hundreds (nearly 1000) of command line tools for covering all the complexity of the multimedia process of production: acquisition, conversion, compression and mastering.

Most of the Multimedia in the GNU/Linux world is covered, but there are some tools which we dont want to distribute together with Mediainlinux for legal reason and mainly because we are not sure about the integrity of the code, which could be stolen or covered by copyrights and so on.

You can install this applications after Mediainlinux is installed on the hard disk, because they will be present in the Synaptic interface (because we added the sources to the sources file).

Technical Goals:

1.Multimedia Kernel (modified to gain more reactivity from the system) and especially in the graphic (drivers for consumer and prosumer video cards) and audio (firmware for professional audio cards) subsystems, applying many patches like the low latency, preemption, real time e capabilities patches and reach a better recognizing of peripherals.

2.Boot splash: cover the Knoppix Live Cd initialization (which is oldish and bad looking, in our opinion) with an animation and some informations about the project.

3.Develop customized multimedia cd and application.

4.OpenMosix enabled kernel to make distributed rendering with Blender and Yafray.

Non technical goals:

1.Include applications which are not already part of the Debian distribution: speed in the free software world creates a situation in which hundreds of projects starts in a year and the ones which survive with an active development the first year and get developed for two or three years have a good chance to continue and be included in the major distributions. Sometimes it needs to anticipate this process and “discover” some applications which are not already shipped with a major distribution, before they become famous and encouraging their diffusion putting them in Mediainlinux. This has a double effect: makes the software better testing it and reporting bugs, suggestions and ideas and making better the whole Mediainlinux itself.

2.Support package maintainer to promote the diffusion of applications that havent already been debianized: programmers that transform the source code of a certain software in a Debian .deb, ready to be installed on a computer with a Debian GNU/Linux distribution (or a Debian compatible one like Mediainlinux) are often volunteers doing this work just as an hobby. For some other software there are already some sponsorships from some facilities and one of the goals of Mediainlinux is to find economic support for this programmers in the multimedia field of application.

3.Organizations: we had contacts with some organizations like ONU and UNESCO and with Italian (Turin, Padova, Bologna, Siena) and international (Bristol, Oslo, Zlin, Tampere, Georgia) universities and with some other organizations in the audio and video fields like FESTPACO or African Women Media Center. In all this places Mediainlinux has been introduced and in some also experimented, still limiting to single tests. With all this entities we would like to set up a collaboration that goes from simple testing and reporting of bugs, to requests for new characteristics and development of additional software.

4.Art Academies: many institutions like MULTIDAMS of Turin, the school of Art and Media of Tampere or the Brera Academy of Art in Milan has a double role: public places for experimentation (and so contamination between technology and art) and possible producers of demonstrations and examples of use, artist and collaborators.

User side goals:

1.Make Mediainlinux a better looking distribution: the look of Mediainlinux is a key aspect of the whole project. The more the distribution will be stylish (from the cd to the manual, from the Internet site to an exhibition stand) in the design and in its graphic and artistic ideas, the more it will gain success between the Linux Artists and the Macintosh community. Then we need to surpass the look of proprietary systems, using all the widgets that can simulate the most stylish looking applets and so we must need graphics to create icons, desktop themes, wallpapers, screen savers and audio video materials (like desktop sounds or video tutorials).

2.Make Mediainlinux simpler: we need to do more integration between different applications, in the way that for a .ogg vorbis file we will have a contextual menu to play, edit, record it etc. etc. This should be done for most of the file formats in the multimedia field and its an operation very intensive of configuring, programming, experimenting and daily use.

3.Make better configuration tools: most of all we need a good configuration of auto mounter to create automatically the icons of peripherals on the desktop.

4.Documentation: we need a manual for the primary applications (mostly done) and its translation in English, French, Spanish and German.

5.Training: we are organizing many courses on subsystems included in Mediainlinux and especially for audio and video streaming, 2D and 3D graphic, musical composition and less common training lessons in multimedia installations and physical and acoustic simulation.

6.Support: make concrete a way to support our users with a mailing list, a forum and a satellite program with tutorials, examples and demonstrations of creativity.

nwcc is a small C compiler for Unix systems that I wrote in my freetime, for fun and to prove to myself that I could. I started the project in August 2003, but because I had a job and a life and a few other hobby code projects, it took me until autumn 2005 to make it work with various constructs of the C language.
So what new does nwcc bring to the table? Most importantly, new code: I wrote everything from scratch - including the lexer, parser and backend.
The code of nwcc is written in C, is currently around 25.000 lines in size, and Im releasing it under the BSD license.
This release is not intended for serious use, but at least nwcc is strong enough to compile itself (the result of which can compile nwcc as well) and should thus be capable of dealing with at least some small programs. There are still some things missing/broken, but things are improving almost every day (I upload my changes to SF whenever I add/fix something of interest.)
Main features:
- There are some C language features missing; Most notably support for floating point, bitfields and a few other things. Many other things are broken (there are probably bugs in pretty much every language feature implemented by nwcc)
- There are no features a power developer used to established mainstream compilers would consider interesting, yet (apart from, maybe, the stack protection feature.) Sorry. There is nothing beyond plain dumb compilation; No support for creating shared libraries, no support for debugging or profiling, no nothing
- There is currently only a backend for 80x86 processors (which generates code for the NASM Netwide Assembler and works on Linux, FreeBSD and OpenBSD)
- There is absolutely no optimization, meaning the generated code is very slow compared to the output of established compilers. I will work on this soon, but you should understand that my primary concerns right now are code correctness and portability rather than speed (its hard enough to make slow code work!)
It takes a lot of work to get even a subset of the C language to compile, so the fact that something is missing or done wrong in nwcc does not mean that I dont care about that particular area of the C language or compiler design; It only means that I havent gotten around to doing it right, or indeed at all, yet.
Enhancements:
- Most floating point support for x86 and AMD64 has been rewritten.
- Many floating point bugs were also fixed on PPC32 and PPC64.
- Various other severe bugs were fixed on all supported platforms.