Free chronic pain demographics software for linux

Open Admin for Schools is a School Administration Program. It is a freely available, open source software package and is licensed under the GNU General Public License.
Open Administration for Schools project is entirely web based and can run from a centrally located division wide server or a single computer in a school. It is designed to support an entire division on one or more central computers but can also work just fine for a single school.
Currently several school divisions use this approach and have 15+ schools on a single central server. This is because it is designed to be lightweight both in server resource requirements and in communication bandwidth.
It is secure. Each school has two or more virtual websites and each is protected with password(s). One site, the admin site, is used by the school office and another, the teacher site, is used by teachers in the classroom.
The teacher site also has password access for entering attendance by teachers and also uses cookies that expire in a short period, further limiting access. Another site, a parent/student site, is controlled by parent/student userids and passwords. A fourth virtual site may be used by school liason officers from outside agencies to give them a slightly different access to school information. (Community Schools)
Main features:
- Demographics - It stores student and family information that can be viewed and printed in a variety of ways.
- Attendance - Attendance can be entered either by secretaries in the school office or by teachers in the classroom. It features the ability to do different numbers of periods per day for elementary grades vs high school and middle years. This will allow elementary classes to have 2 classes per day (AM/PM) with a homeroom teacher while higher grades can have attendance done on a per subject period basis (and be subject based). Attendance reports are integrated with report cards/progress reports. A variety of attendance reports are available. A variety of attendance entry methods are available for use by teachers and/or secretaries to allow it to integrate with normal school practice.
- Discipline - A simple discipline module to track student discipline events and track outcomes, etc. Behaviours may be categorized and statistical reports may be printed. Enrollment changes are also posted into this system.
- Report Card System - a flexible reporting system with per subject objectives (up to 20), integrated attendance reporting, etc. All report cards are printed as PDF reports and may include a school logo. All subjects may have unlimited length text comments, and can have any desired ordering. Attendance reporting will now do days open, days enrolled, days absent, and times late as standard.
- IEP (Special Needs) Site that is integrated at the division level that allows special needs teachers to tailor individual student programs that can be viewed from each schools teacher site. This includes the ability to add student medical history, testing done, student teams (and responsibilities), and objectives chosen from lists of thousands, categorized in a variety of ways. There can be up to 32 objectives per subject and each subject is specific to that particular child. His/her program would consist of a variety of subjects in areas such as fine motor control, etc.
- This system can generate progress reports (for use with the report card system) as well as a comprehensive IEP report containing the yearly plan for the child. This IEP can also viewed from the teacher site, to ensure compliance throughout the year.
- Export/Import Modules - to allow students to easily transfer schools within divisions without re-entry of demographic information. Export of data to other programs. Export of data to Provincial authorities via an automated XML based transfer mechanism.
- Saskatchewan SDS support for direct XML transfers of student demographic, subject and enrollment marks to provincial authorities.
- Online Gradebook to allow teachers to enter marks and assessments onine from school or home. It can group and weight assessment items and post directly into the report card system.
- Parent Viewing scripts to allow parents to view attendance, gradebook(where allowed), and report card marks. This is easily integrated into existing school sites.
- Upcoming: Family functions, Parent-Teacher Interview Scheduling, Wherever schools want to go...
- Further out... Multi-language support (demand for a Spanish version exists currently), Student timetabling.
Enhancements:
- A new Fees System to allow fee charging (predefined or new, with various groups), invoice printing, payments and receipts, and the ability to export summary journal transactions to an external accounting program.
- A new teacher logout to remove session data has been added.
- There is a new 70 page User Documentation PDF and a 40 page Administration Documentation PDF (also available in HTML versions).

THC-Dialup Login Hacker is a tool for penetrating dialup modems.

All you need is UNIX and minicom. Have fun with this little release!

The internet is not the only door into a network. In this new days, wavelans are becoming popular, in old days, there were dial-in modems. But today, dial-in modems are still present in any company.

While tools for wardialing (scanning phone numbers for modems by dialing every number and checking if theres a carrier) are available for all operating systems for years, there were only a very few tools for trying to guess login/passwords against modem carriers, and they were all for MS-DOS only. Years ago, I wrote such a tool called LOGIN-HACKER, which is still in use by many people, just because theres no real choice.

About 5 years ago I completely moved from MS-DOS to UNIX (Linux and OpenBSD) so executing penetration tests became a pain in the ass for modem login hacking. Finally I wrote some scripts to hack into modem carriers for Unix as well.

To make it flexible and portable, I chose not to write my own terminal program and scripting language, like I did with LOGIN-HACKER. I just use simple Minicom scripts. And they are very effective! Also they could include more commands to interact with the operating system while the script is running, I made it possible, to autodetect almost any prompt, and detect if a login/password, or password only prompt was successfully passed or not.

PAiN project is a new MUD code base written in Java.
PAiN is a new MUD codebase written in Java. It provides a general purpose persistence engine (PAiN DB) and the ability to do dynamic code reloading.
Main features:
- Pure Java database engine (transparent constant-time object access, tracking of the dirty state, transactions and savepoints support).
- Static server code (connection handling, support for code reloading and base interfaces).
- Dynamic reloadable set of action classes and plugins (virtual world logic code and plugins).
- Graphical tool to administrate server and database
Enhancements:
- PAiNDB: Collections could be saved separately from object image.This option should be used if collection is not the only field of dbobject, it has size of 20-40 items and dbobject fields are changed often. Saving collection separately will reduce flushing and object backup time inside transactions.
- PAiNDB: DbObject.provideSchema() is now static method and required for all non-abstract DBObject impls. This allows to import class schema into db without object instantiation.
- GUITool: fully rewritten, modules concept added.
- Codebase: more admin console commands.
- Tinylyb: roles removed: Reset, ResetGroup. SpaceGroup was renamed to Area.
- Tinylib: more shell implemented(this shell should be used to show multipage output)
- Tinylib: online builder bugfixing.
- PAiNDB: fixed bug with error on objects removal with non-empty StringMap type fields.
- Tinylib: bugs in @build mode fixed. More complete visualization for array-type fields
- Tinylib: number of small enhancements.

Trac is an advanced tool for tracking software development projects. It provides a simple wiki, issue tracking system and tight integration with the Subversion revision control system. Trac/Subversion Development JumpBox bundles Trac 0.10.4 and Subversion 1.3.1.

WHY USE A JUMPBOX

Its Simple

Open Source applications are great. The applications are powerful, inexpensive and get the job done. But installing and configuring those applications can be a pain. A JumpBox delivers Open Source applications in a way that makes them simple to try, run and operate.

Its Quick

Actually downloading a JumpBox will take the most time. Once thats done, youre just a few minutes from having a working application that can serve multiple users.

Its Portable

A JumpBox collects the application, application dependancies and all application data into a single bundle that can easily be moved from one computer to another. This allows you to start running the application on your desktop and then as usage grows move it to a server without needing to reinstall or reconfigure. Plus with support for Mac OS X, Windows and Linux you can even move the application between platforms with little effort.

Its Safe

Manually installing Open Source applications not only takes a lot of time and effort, but when youre done its still left to you to figure out how to protect the data the application manages. With a JumpBox its easy to add automatic backups of the entire state of the application.

Its Virtual

A JumpBox application is a virtual appliance that bundles the open source application and all its runtime dependancies into a single package that runs on top of virtualization software from VMWare, Parallels or Xen. This means all JumpBox applications automatically gain the benefits of traditional server virtualization and can be dropped into existing virtualization infrastructure when available.

Its Comfortable

JumpBox provides a consistent runtime environment for all applications that we bundle. The applications may differ considerably, but their installation and operation will be familiar no matter which JumpBox you choose.

GladePyC is a Python code generator tool, from Glade XML save file, to the low-level part of "PyGtk", the Python - Gtk+ binding. Glade is a GUI builder for the Gtk+ GUI toolkit. PyGtk is the gateway between Python and Gtk+.
Why:
Those who know surely have already made the remark: "But why on earth doesnt he use libglade ?"... Here is what I think of it:
- There is roughly two approaches to working with Python and Glade: a run-time one (libglade) where UI descriptions are loaded during execution, and a compile-time one where UI descriptions are statically compiled into target language source code. Both have strong and weak points (I wont debate here), but for python the code generation option was not enough developped since GLC (advertised on Glades links page) is not object oriented. GladePyC aims to fill this little gap.
- The python binding of libglade loads the GUI using the high-level, object-oriented layer (gtk.py), not the basic layer; This means at least 3 objects per widget are present in memory (Gtk+, libglades XML and gtk.pys) which I find is a waste of memory for things we dont need once loaded (and by adding layers it may slow down things notably).
- If you need dynamic interfaces, where multiple instances of the same window class are created, you have to reload the UI description (analyzing XML and all) because libglade doesnt know how to make a new actual widget tree from the in-memory, XML represented, UI description. Additionally you have to reload from a file: loading from a string in memory is unusable because a function is missing in the Python binding.
- It requires an additional library ! Ok its not a pain to install it, but its always better if you dont need it; Actually I want OpenVMS as a potential target, and it is lacking libglade.
Additionally gladepyc has some features I wanted, that are not found in libglade nor GLC:
- Object-orientedness (1): windows and widget subtrees have their building code generated as classes, so that multiple, independant instances of them can be created.
- Individual widgets are accessible by their name as attributes of instanciated objects.
- Object-orientedness (2): signal connections are made to methods of so-called "controller" objects (Java calls them "listeners"), not functions. There is support for connecting a whole set of signals at once, based on the name of callbacks, which presence is checked as methods of the controller. This allows each window (or subpart) to be managed by a separate controller without having to pass additional arguments to callbacks.
- Object-orientedness (3): data classes can be made, to serve as quick access method to data stored at runtime in widget instances. Each value is accessed as an attribute of the instanciated object, through an attribute with the same name as the corresponding widget.
- and there is a lot more: see README. I will write documentation when things have matured.
- As you can see, there are some benefits to static code generation approach, which are difficult to achieve with a run-time library (though in our case it would be able to, since Python is interpreted and can dynamically define new classes and functions)

ROMBrowser project is a tool for organizing emulator ROMs.
It will identify rom files by their CRC, give information about their characteristics (game title, parent rom, etc), and organize those ROMs with different filters.
If you like to play with emulation and emulators, you know the pain of keeping track of your thousands of ROM files, not to mention figuring out what it is youve just downloaded. Thats what ROMBrowser is for. Eventually I hope to have a system that works somewhat like romcenter, but is java based and GPLd.
I also am planning on developing a schema for storing meta-data related to ROM files. There are currently several databases out there that have information about ROM files, usually keyed by the files CRC32. Part of the ROMBrowser project will be to develop an open standard for that kind of data (probably an XML DTD) and a plan for the distributed classification of ROM files, so users can classify unknown ROMs and distribute that information.
Enhancements:
- Added Super Nintendo rom handler for SMC files. It doesnt handle interleaved files yet.
- Separated out datafiles from main distribution, added credits tag to xml database, to give credit to the rom database maintainers (just using conversions of cowerings goodtools for now).
- Changed rom info viewer to table view. Added ability to modify rom data, changes will be saved in knownfiles.xml
- Changed how file searching works, now only files that have romhandlers (nes and smc currently) get processed, all others are ignored.
- Made file converter work better for converting romcenter dat files (use net.sourceforge.rombrowser.util.ROMDatabaseFileConverter
- Deleting specific roms from the treeview will remove them from knownfiles, and will also delete them from the filesystem if delete-on-remove is true.
- Deleting folders from the treeview will still not remove their child entries from knowfiles or delete the foders or their children.
- Changed the way rominfo files are handled, now if the datafile property has colons in it, it will treat it as a list of datafiles, eg: "goodnes.xml.gz:goodsnes.xml.gz" would look for both goodnes and goodsnes in the rombrowser home folder

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.