User:Micahwelf
Current projects I am working on:
- IPad HTC Charger: IPad Charger is someone elses work in C. It is lovely and the source is so short and simple there is almost no chance for it to not compile and work. I modified it to recognize HTC devices. I am still adding HTC and other Android devices, but you could say I am a little impatient and, as usual, very busy my own work and life. You can contribute as much as you feel like. My modifications consist of raising the Amps setting to 2A instead of 1.6A, and adding all the varieties of HTC phones that I believe to be able to support charging with custom settings. If I could change the voltage safely on the average USB hardware, I might try a more exclusive option to rapid charge HTC One (M8, M9, ...) phones with 9 volts 1.67A, and 12 volts 1.25A, the same as the HTC Rapid Charger. As always, only use such modifications when you are sure what you are doing and at your own risk! If successful, then you don't have to pay $35 to get the safer, warranty-covered, and more portable item from HTC. ( ;) )
- Password Encode (passwordencode): Password Encode is simply an encryption program that uses one or two passwords as a variable length key to encrypt standard input or files given as arguments. I have ideas, but maybe you would like to add to them. A version supporting stdin/stdout written in C# is completed, but I am not a fan of C# chaotic library structures, and large executable sizes, and dependencies on Microsoft based libraries to run. I have therefore started over in Ada. Despite all good things said about Ada, and how much I like it, I am finding it very challenging to comprehend what I need to do and what I can do in the language in order to make it work. Ada is much more simple, and has better "package" structures, better ability to compile and be used across different computers, and lastly ~ to my generally disliking the inconvenience ~ it requires well thought structures with everything typed and matching once in a spec file and again in the body file, making bugs easier to track and less likely in the first place. Anyway, in the new language, which I am learning along the way, I plan to make this program helpful to bank correspondents. I want to make it possible to send and receive files with a bank or credit union via email or any common file transferral system that is secure and safe as if they were working on the highest level of an encrypted login (HTTPS/SSH). The password(s)/key(s) are regular UTF8 character strings disallowing tabs,new-lines,etc. The content is first converted to base64 57 bytes at a time, then with the first password (defaulting to a single space if not specified) each character of the base64 string is shifted through its modular 64 values by the internally defined value of each password character, then with the second password each password character defines where bytes are swapped between areas in the stream, and finally the string of base64 is decoded back into binary data. Even with the insecure practice of using the built-in default password, the contents of whatever is encrypted is visually quite unrecognizable, and the encryption is difficult to break or detect because the keys are variable length (can possibly be even longer than the file being encrypted), and the data is encrypted six bits at a time instead of in whole bytes. Because of the modular looping of the sixty-four possible shifting values the same value can be achieved with several different characters, a person can use Text strings that are easy to remember or unique between them and their bank or credit union. I hope when this is completed it can be made available through the AUR to everyone with their own use in mind.
- FFmpeg Composer: Have you ever been perturbed by the lengthy difficulty of composing and modifying FFmpeg commands to the command-line. Graphical solutions are great, but all that I have seen available require a lot of work still, or are unmaintained. The problem is that their effort is divided from the extensive and beautiful work done on the transcoding tool provided with FFmpeg. I know I am not the first person to come up with a simpler model for the interface, but I believe this project may be the first to provide a complete, very simple command-line-syntax based approach to using the library. The idea is to compose "ffmpeg" command from a few very basic settings (like verbosity and scaling-method) defined in an initial configuration, the input files added in as initial arguments or post-initialization by user, and almost everything else being done with colorized drop-down lists, adding or modifying filters and options based on what is available at the given point in the commandline. Such a graphic program capable of saving and recalling various composed command-lines will make composing good video/audio settings faster, easier, and will be much more maintainable than trying to re-implement a direct graphical interface to the Audio/Video library. This I plan to do in Ada with GTK as well. Any start attempts I have made in other languages stopped when I realized how un-portable the code was going to be. Hopefully Ada will be fully supported on the machines where people want to build from source.
Projects I am not actively working on:
- makeselflzo: Modified from makeself, which is an extremely portable script for creating self-extracting packages, to support executing as if it were a program (easier use and customization of JAR files, installers, or run-without-installing programs), and with faster LZO compression. With a self-extracting archive made with this version lzop is required in addition to sh, gzip, and tar. Also, using xz compression, the program can be distributed efficiently -- when the lzop-compressed program is extracted from the xz archive and run, it extracts so fast that the delay-to-start is hardly ever noticed. This extra layer of compression is suggested because lzop is simply not compression-efficient enough to allow distribution of the LZO archive/executable directly.
- libaskm: a ZSH library of functions, aliases, and variables that allow faster, better program/script writing. It is designed to allow more convenient access to modern ZSH functionality and even faster and more readable lines of embedded foreign scripts, PCRE/Regex expressions, and byte-code manipulation/reading/writing. It had so many meaningful math and parsing functions for me to work on that I simply didn't have time to make it complete enough to distribute. Ask me if you want what I have. Later I may rename it and complete it.
- aura: A total rewrite of some-one else's program with the same name to access, Sync, Build, Package, and Install AUR projects. It has worked reliably for me and saved me a bunch of time. It accesses the HTML AUR wiki, parses, and goes from there. It worked fine, then I made a few changes that have not been tested, and lately I am a little concerned whether it will yet be compatible with the AUR version 4. We will see when it becomes necessary. The advantage to using a script like this is that you can make your own features, like automatic installation of dependencies that lie in AUR rather than the standard repositories, and you can quickly test how a package will work for someone else just after submitting it.