Free jiddu krishnamurti philosophy software for linux

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.

dynamic window manager or dwm is a dynamic window manager for X11.
As founder and main developer of wmii I came to the conclusion that wmii is too clunky for my needs. I dont need so many funky features and all this hype about remote control through a 9P service, I only want to manage my windows in a simple, but dynamic way.
wmii never got finished because I listened to users, who proposed arbitrary ideas I considered useful. This resulted in an extreme CADT development model, which was a mistake. Thus the philosophy of dwm is simply to fit my needs (maybe yours as well). Thats it.
Main features:
- dwm has no Lua integration, no 9P support, no editable tagbars, no shell-based configuration, no remote control, and comes without any additional tools like printing the selection or warping the mouse.
- dwm is only a single binary, its source code is intended to never exceed 2000 SLOC.
- dwm is based on tagging and dynamic window management (however simpler than ion, wmii or larswm). It manages windows in tiling and floating modes. Either mode can be applied dynamically, depending on the application in use and the task performed.
- dwm doesnt distinguishes between layers, there is no floating or tiled layer. Wether the clients of currently selected tag are in tiled mode or not, you can re-arrange all clients on the fly. Popup- and fixed-size windows are treated floating, however.
- dwm is customized through editing its source code, that makes it extremely fast and secure - it does not process any input data which hasnt been known at compile time, except window title names and status text read from standard input. You dont have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C to customize it for your needs, you only have to learn C (at least editing header files).
- Because dwm is customized through editing its source code, its pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.
- dwm uses 1-pixel borders to provide the maximum of screen real estate to clients. Small titlebars are only drawn in front of unfocused clients.
- dwm reads from standard input to print arbitrary status text (like the date, load, battery charge). Thats much simpler than larsremote, wmiir and what not...
- It can be downloaded and distributed under the conditions of the MIT/X Consortium license.
- Optionally you can install dmenu to extend dwm with a wmii-alike menu.
Enhancements:
- This release contains certain major bugfixes, especially regarding banning/unbanning client windows.

Hidden Linux is designed to meet the need of a robust and easily managed security infrastructure that must satisfy a demanding set of organization requirements, while ensuring performance and security. Hidden Linux addresses the needs of organizations wishing to develop a secure internet presence in any form of Internet activity.

Features

Robust, and improved security and easy to manage. Hidden Linux is built on the latest stable technology and includes all the components necessary to manage all internet functions.

Overview

Issues involving availability, performance, integrity, and privacy have been addressed with Hidden Linux; it improves the security of existing versions of Linux in several critical areas with the following features.

Design Philosophy

Security involves tradeoffs. Mitigating the risks with finding the right level of functionality and performance is always a challenge. Hidden Linux utilizes the principle of least privilege.

The secure design employed in Hidden Linux acknowledges the possibility of undiscovered flaws, and takes steps to minimize the security impact these flaws can have. read more

Smutty project is a MVC PHP framework.

Smutty is yet another PHP MVC based framework. Ive tried a few that are out there and none really satisfied exactly what I was expecting.

Smutty is meant to be as simple as possible, not bogging you down with understanding the philosophy of the framework, just letting you get on with things.

The name smutty comes from the fact that one of the bases for this project is the completely wonderful smarty templating engine.

Fruit Show is a minimalist forum package based on the forums at joelonsoftware.com. Fruit Show is based on the philosophy that social atmosphere is a by-product of software design.
Theres no registration and very few features for visitors. Its skinnable and easy to install. It also contains some unique moderation features.
Fruit Show is intended for small sites that need an easy to use and accessible forum.
Enhancements:
- This release of FruitShow fixes a large number of issues and makes a few improvements to IIS support and support for PHP5.
- Smarter topic locking and improved optimization were added.

Mustajuuri (Black salsify, Scorzonera hispanica) is an audio signal processing application and toolkit. It is designed to meet wide range of needs.
The first and foremost is real-time effects processing. Mustajuuri can process guitar, vocals or any instrument with ease. It is also useful if you have a virtual reality system with more than 10 loudspeakers and you wonder how to control them all.
The basic philosophy is to combine the good features of many existing applications - not to simply copy one. Apps Id like to surpass are ProTools, CuBase and all the others. To make this possible Mustajuuri has an extremely flexible and powerful plugin model.
Mustajuuri acts as a core framework upon which applications can be built. One can build applications directly as plugins (quite easy) or use the Mustajuuri libraries and plugins as a class library.
Usages:
- Sound file editing
- Mixing
- Real-time effects processing
- Real-time sound analysis
- Sound processing for virtual reality system
Main features:
- Graphical user interface
- Good real-time operation
- Plugin-based system
- LADSPA plugin support (both import and export)
- Plugins for audio file I/O and MIDI I/O
- Openness - both as open source and as open for different uses
- Platfrom-agnostic
- Internationalization
- Multiple user interface options
- Easy-to-program plugin API with powerful support libraries
Enhancements:
- This release adds some ALSA-related bugfixes, compiles cleanly on GCC 4, and adds documentation about Mustajuuri to LADSPA plugin conversion.

DrakLive is a live distribution mastering tool.
draklive builds a live distribution according to a configuration file, creates a master image, and optionally installs it on a device.
Why a new live mastering tool?
Mandriva Move
The Move1/Move2 technology is quite deprecated now, it was about loading writable files in RAM, and using dnotify to monitor file modifications and copy the modified files on the USB key.
It required a specific boot process, and a complex mastering process. It is better replaced by something like unionfs, which allows transparent filesystem overlay (and makes possible files removal).
mklivecd
mklivecd already allows to create live distributions, but its not easy to keep it in sync with latest hardware or technical updates. mklivecd needs its own long initrd script (linuxrc), as well as a new rc.sysinit file. It makes the boot very complicated, and its not easy to maintain all these three programs (linuxrc, rc.sysinit, mklivecd) together.
linux-live / Slax
The linux-live scripts are quite similar, but they also requiresome additional library in the initrd, and they dont provide a good hardware drivers list in their initrd.
Advantages
draklives philosophy is to keep the live distribution as close as possible to a normal Mandriva Linux distribution. All specific live tweaks are done in a very tiny initrd script. Since this one is generated on the fly, its very small, and gets quite easy to debug.
The list of drivers included in the initrd is adjusted during the live distribution creation, according to the medium type. draklive uses the DrakX libraries to have an up-to-date drivers list.
Once the initrd script is done booting, the root device will be used transparently by the distribution, without any additional tricks.
Hardware detection is done with harddrake, providing a reliable integration.
Main features:
- live CD
- live distribution on USB key
- easy to test over NFS
- uses the Mandriva installer to create the live system
- fully read-write live system (using unionfs)
- automatic hardware configuration (using harddrake)
- generic code structure to make new technical choices usable quickly