Man I gotta lay off the [SAS] dynamic room clearing. It’s like bam, bam, bam, bam bam bam – 2 story building with 30-40 contacts clear in the blink of an eye.

I feel like doing back flips, lol

Categories SAS

So, where have I been lately?

I haven’t been keeping up with my journal lately, things have been hopping quite a lot recently.

Wednesday night, my mother had to be taken to the hospital. I spent the night on the couch, trying to keep the dogs sane; Willow & Coco have been bark happy! Thursday was basically spent on a mixture of travel, hospital, and chores. Got to spend some time with my brother after we visited our mother, I was there about three times during the day. Another night on the couch lol, and Coco doesn’t exactly like to *share* that much!!! For years my mothers thought that she may be diabetic, so finally being in a doctors care for, I guess the first time in 21 years; ma was diagnosed with type 2 diabetes. Friday saw the conclusion of testing, and it appears the main problem is Diverticulitis. Who would’ve thought having a high(er) fiber diet in your 30s and 40s was going to be important twenty to thirty years later? So far, things seem to be pretty good. Ma should be coming home tomorrow, eh today, or at the latest Sunday.

For what hours I haven’t been in a hospital room, I’ve basically been home with the dogs. I don’t mind being alone as much as I would’ve thought, but I am really glad to hear that ma is coming home soon. It’s too quite without her, and the dogs are not used to just having me around the house.

Two things that I have learned, is if I ever had to live alone, two fundamentally important things are a good radio (that gets 94.9) and gloves ^_^. Actually, I think this was the first time in my life, that I really had to wash dishes—I’m not about to have her come home to a kitchen full of crap. For some reason, without my mothers constant interruptions the day time has passed much slower then I’m accustomed to; so rather then quickly flying by days and slow nights, things are on a more natural pace. It will be nice to be able to sleep in my own bed again as well, rather then taking the nights on the couch. While Willow will hog my bed at night, Coco doesn’t care much and won’t often venture that far away from the living room, unless she wants to hide in my closet lol (oft’ during thunderstorms).

Getting a little drowsy now, and I should be getting to sleep, only GOD knows when the phone is going to start ringing in the morning. Heh, and actually that is an interesting thing that coems to mind now that I write this; although I’ve probably spent as much time on the phone in the past three days, then I have in the past three years. One thing I have noticed is that while ma has been in the hospital, there hasn’t been tons of calls from creditors all freaking day; there’s only been two or three at the most. Anything else would have to of come through when I was visiting at the hospital.

Spooky, ain’t it?

EPI, the facts.

Since it has been brought up recently, I’ve decided to air out the facts about the “Top secret community project” [sic] known as EPI. It is also my request, and being that I am an Admin here, one that I will enforce — that any comments about this go into a separate thread. First to start one has my blessings for collecting comments.

[color=blue]This post will be locked along with the thread; everyone shall respect this. A copy will also be retained else wheres.[/color]

Project Status?

Stalled (i.e. postponed until further notice), because of “Real life” taking priority for the developer.

4 people were involved in the project at it’s height, and provisions made to approach 2 or 3 others at a later date. In answer to some peoples questions, Yes Graedus and Myself were involved; the “One guy” tasked with all the coding tasks was none other then myself. I enjoyed it greatly while off-work hours permitted.

EPI, what the heck is that?

EPI is short for “Encapsulated Pacakge Installer”. It is a method for integrating existing FreeBSD software management systems with an easier to use means for distributing third party packages (like PBI) and the ability to integrate with any desktop environment or user interface system.

EPI Project Goals?

[*]Remove the need for the user to deal with the “Package, Port, or PBI” question.
[*]Make creating “EPI” files a snap with a minimal of fuss on the maintainer, and trivial to automate the build (but not like PBIs build system)
[*]Allow support of console, and desktop environment agnostic installation without inconvenient to maintainers.
[*]Create something that could be owned, managed, and operated by the community as a whole; not the PC-BSD developers: who proved to be incompetent and incapable with their miss management of PBI, at least in our (4 sets of) eyes.[/list]

It was intended that once the system was developed, that it would be further refined by the community and someday replace the PBI system, becoming the [i]de facto[/i] standard way of managing software on PC-BSD. Like wise, it was also intended that once the EPI system matured, it would become the means by which PC-BSD itself would manage system software – instead mucking with peoples ports.

While EPI is not my concept of what kind of package management system PC-BSD needs, it is our concept of what PBI should have been in the first place, and what [i]PBIs[/i] could have become if properly managed by PC-BSDs developers.

How does it (EPI) work?

First a FreeBSD port is created for the given program; this has been done for most software that is worth running on FreeBSD and should be done for anything else. There are is approaching 21,000 programs in the ports tree, so much of that is done for us all.

Second a maintainer writes out a description of the particulars. This basically amounts to stating:

[*]What port(s) does this EPI provide?
[*]What EPI does this EPI depend on?
[*]Who are you?
[*]Special Needs Hook[/list]

By stating what ports to be provided, for example “www/firefox35”. The build system would then automate the process from there on without maintainer intervention. Firefox would be fetched, built, and stripped down to the minimal required dependencies. This would all be done inside of a private jail on a build server, where in there is nothing else to interfere with the process (that is, inside the jail).

The “Firefox EPI” would depend on several other EPI, in this case it would depend on the following ones: EPI Core Services (the EPI system tools), X Windows System, and GTK+ Runtime. Because of this issues relating to X and GTK dependencies are removed from the Firefox EPI, creating a *much* smaller download and more manageable interface for people who just want to install Firefox, and have it just freaking work without trouble! Because of this design decision, unlike with PBI; the issue of dependencies are automated and can be checked. PBI does not support that. An advantage of EPIs way of doing it, results in ease of maintenance, more effective use of disk space, and more effective integration with FreeBSD. Another great perk is it makes writing things like Flash or MPlayer plugin EPIs much less painful then with PBIs.

For security reasons the EPI file would be digitally signed during the creation process. Every maintainer has their own “Key” that is used for signing EPIs that they create. This allows a package to be traced back to its creator, who must manage their reputation within a “Web of Trust” distribution model.

In case of “Special Needs”, there is a special Encapsulated Package Installation Language, or “EPIL” for short. EPIL is a simple declaratory way of scripting the installation process. This is analogous to the various ‘PBI.*.sh’ Bourne Shell scripts used in PBI. [b]Unlike PBI, the EPIL system is designed for use by non-programmers and is rarely required[/b]. Every thing that can be done for you, will be done for you, in order to create the best possible encapsulation of work, minimize your hardship, and make life easier on both users and maintainers. By contrast creating a PBI requires an understanding of UNIX shell scripting and programming, and employs a flawed Application Programming Interface, which usually results in poorly created PBI and fewer maintainers. EPI solves this problem by applying sound software engineering practices, and makes creating an EPI a snap. [b]Under normal conditions the maintainer has to never write an EPIL script, and even then it is less trouble then writing a forum post[/b]. The maintainer has no need to worry whether the installation is text, graphical, attended, or unattended; all standard needs are done by magic; that is the massive opposite of traditional PBIs.

After creation, the EPI file makes its way to a sacred repository for evaluation; a way of downloading it is provided to the author. Trained people inspect the maintainer serviceable parts, i.e. no hidden delete all files on your system kind of bug. Both those trained folk and regular but trusted people then test the individual EPI to make sure it works as advertised. A simple check list is used to note that down correctly, reports shall be publically posted and the maintainer notified.

If no show stoppers were found and the maintainer is in good standing with the community authority, their package is then hosted for public download in accordance whatever community policy is deemed appropriate. The community website (think like the PBI Directory) would then host a download link and all necessary data, so that end users may download the created EPI.

If enough end users complain or have problems with EPIs created by a specific maintainer, that maintainers rights to use the community systems will be temporarily revoked (permanently if need be), and the maintainers “Key” will become untrusted by the EPI Community Authority – thus invalidating our trust in that maintainers EPIs safety for general consumption; individual end users have the ability to ignore the communities decision and install those EPI anyway.

A end user then downloads the EPI file, it could be from the Community Authorities website, from a friend, or even direct from the third parties website! (E.g. Adobe, KDE, Gnome, etc.)

The end user chooses the installation method: graphical or textual.

To install via graphical mode, simply double click the .epi file on your desktop and it will begin a graphical installation wizard. The wizard run is user servicable with a default based on your environment; i.e. Gnome & Xfce users get a GTK+ based wizard, KDE users get a Qt based wizard. Users and Developers could create their own wizards.

To install via textual mode, simply run the installation program in the shell:

sample# epi-install ./Mozilla_Firefox-3.5.3-i386.epi

Both methods invoke the same program, but with different arguments.

The epi-install program updates its understanding of “Trusted Keys” published by the Community Authority, or any other source the user chooses to trust; the user can even skip this step.

Assuming all has went well, epi-install then unpacks Firefox accordingly, verifies the maintainers signature and the packages integrity. If found, the compiled EPIL script is run – the user can choose not to run the script. Normally this is a moot point, because there shouldn’t be any script needed. Of course, the EPIs installation is recorded in a database.

What the user sees depends on how it was run. In text mode they get a console friendly way of doing the installation. In graphical mode, they get a GUI install wizard like PBI. Environment variables and command line switches are provided override behaviour – for example, choosing to run the Qt wizard under Gnome. All this is so easy because the EPI maintainer was never arsed with dealing with it, it was done automatically for them.

Firefox is now installed, the end user can run it from its locatiion in $EPI_ROOT. The default $EPI_ROOT would likely be /usr/epi if adapted by PC-BSD. When “Installed as a third party product” on FreeBSD or PC-BSD, the default $EPI_ROOT would likely be /usr/local/epi.

Our way of doing things would enable both shell users and desktop users a fairly painless way of accessing firefox, without favoritism to KDE or Gnome.

Ok, so how does this relate to PBI?

PBIs are managed by the PC-BSD developers, and the people trusted with watching over the safety of end-users are either corrupt, derelict, or incompetent. [i]EPI[/i], would instead be placed into community hands, so that no one person or entity has total control.

As a format, how they work is very different. An EPI is a compressed archive containing program files and meta data; an external program located on the users machine is used to handle the installation procedure. This is how many package management systems designed for UNIX work, Microsoft’s own Windows Installer is not to far off either. APT, DPKG, RPM, and FreeBSD Packages work this way as well. The PBI format on the other hand, is a self extracting executable with an embedded archive containing additional meta data, program files, and an embedded installation wizard. The PBI system is dependant upon the FreeBSD version, KDE version, and the presence of system programs — PBI is written in C++ but done like a shell script. Internally, PBI is both ugly and non-unix like. [i]EPI[/i] instead provides a more platform and version independent way of doing things.

The format of PBI files, how they work, what they do, and how they are managed by the system is generally undocumented. [i]EPI[/i] would provide a totally documented system, making it easy for developers, system administrators, end users, and businesses. Heck, you could even create your own EPI system that is totally compatible – you can’t do that with PBI, unless you read a lot of bad code and kuddle up to a nasty API.

In order to make a PBI, you need to know quite a bit about shell script and do a lot of leg work that should be done for you automatically; end result is most PBI install scripts are bad, even Kris Moore’s are shotty. [url=]I found an old PBI script that I wrote a while back[/url], that is done ‘properly’.

Because [i]EPI[/i] files are throughly checked at install, it tries to ensure that what you download is exactly what the maintainer created. By contrast the PBI file you download is not guaranteed to be what the maintainer created, there is no safe guard against tampering with the files on the mirror – the user is on their own without so much as a checksum of the actual .pbi file that was sent to the mirror!

[i]EPI[/i] has a simple and documented dependency model. If you don’t have GTK+ Runtime EPI installed, Firefox EPI should warn you. The EPI Core Services provides as a contract, a set of ultra-common dependencies used by many programs. This reduces disk space waste and allows EPI to work across differing versions more easily. Our decisions would have created a more robust system then PBI, while minimizing dependency hell to the same level. The way PBI does things creates more work on the maintainers and cause more interoperability/integration problems that the PC-BSD developers simply don’t care to address. PBI with hidden or undocumented dependencies are also not uncommon, because the only ‘standard’ of what the PBI can depend on is the release notes for PC-BSD X.Y.Z and the PBI “Guidlines” as they have become, which used to be rules that were just often thrown in the trash can.

OK, OK, enough already, but who the heck are you Terry?

I am a person who has used computers almost since he learned how to walk. Someone that loves software engineering, and shares his grandfathers work ethics, that if it has your name on it, then it has to be GOOD.

Several years ago, I encountered UNIX and embraced it with an open heart.

The first date with PC-BSD was 1.0RC1, a release candidate shipped in 2005. I have since various versions of PC-BSD on home servers, desktops, and laptops. During the 7.0Alpha testing cycle, before KDE4 had even entered the picture, I had made the decision to transition my personal-workstation to FreeBSD, and never looked back.

As a part of this forum, I joined to see if I could help people and learn a thing or two from my superiors. Even after they left, I remained, eventually becoming a Moderator and later an Forum Administrator at the request of Kris Moore – likely because I shouted loudest of all about the spam problems. My activity on the forums over the past ~two years has rubber banded with my work schedule and the rest of living.

For a time, I created PBIs of programs that interested me, such as Blackbox, which was the first alternative to KDE to be had in PBI form. After a while, flaws in the PBI design and the developers disregard for their own rules caused me to “Give up” on creating and maintaining PBIs. I have seen everything to be seen with PBI, down even to the point of Charles breaking the PBI rules, PBI developers publishing their own PBI without testing, Kris Moore changing the rules after breaking them for Win4BSD, Kris changing them back over community outcry (and increasing lousy PBIs lol). Throughout it all, the process of getting PBIs published has made me sicker then watching a corrupt Government at work.

I’ve generally kept a safe distance from PC-BSD development, this is why I never became involved with the development team; their actions over the years also do not give me desire to “Volunteer” my services.

When the question that PBIs could be created automatically was brought up many moons ago, it was shot down, most strongly by none other then the (then) host of the PBI Directory website (Charles). I supported the idea and it was generally held in contempt as something “Impossible”, only later to see it become a part of PC-BSD. Exploring it ahead of everyone else, was actually how I learned much about shell scripting.

My skill set includes C, C++, Java, Perl, PHP, Python, and all the way to parts of X86 assembly, Scheme, and Common Lisp. More task specific issues such as SQL, HTML, LaTeX, sh, bash, batch/cmd, AWK, SED, and indeed, even [i]ed scripting[/i], are apart of my abilities.

I think no one will debate that I know a thing or two about that which I speak.

A look at a *good* PBI install script from 2007.

In looking around my ~/Projects folder, I found an old PBI install script I wrote a couple years back. When I was working on a TexLive PBI (only me and Oko were interested), I wrote a very robust script. Most PBI that use install scripts should be nearly like this but normally, they only handle the GUI case and screw you if you use text mode or have special need.

This script was written to the published API at the time, which basically amounted to $INSTALLMODE being set to tell you if you were in a GUI or not; a variable to tell you what name your PBI would have inside /Programs. This was an improvement over using “$1” everywhere, as was required in previous versions of the PBI API.

Here is my old script:


# the year of this release, e.g. 2007, 2008 e.t.c. -> This should be equal to
# the Program Version we set in PBC.

# the size of all our installed files in $PBI_BASE/texlive/$YEAR/
TEXSIZE="1.1GB" # as a string

# compat check.. should be unecessary but I don't trust PC-BSD. Since users can
# now override our install location and documentation does not talk to us about
# coping with it not being /Programs/$PROGDIR/, abort install rather then risk
# performing undefined/undocumented behavior should /Programs/$PROGDIR be
# overrided.

if [ -d "/usr/Programs" ]; then
elif [ -d "/Programs" ]; then
elif [ -d "/usr/local/MyPrograms" ]; then
if [ $INSTALLMODE = "GUI" ]; then
kdialog --sorry "Can't find PBI Installation Directory... aborting"
echo "Can't find PBI Installation Directory... aborting"
exit 255

# set the path

# XXX check if we are already installed or improperly installed

if [ -d "$PBI_BASE/texlive/$YEAR" ]; then
if [ $INSTALLMODE = "GUI" ]; then
kdialog --sorry "$PROGDIR appears to be already installed, aborting"
echo "$PROGDIR appears to be already installed, aborting"
exit 255

# give the user a chance to abort the installation
if [ $INSTALLMODE = "GUI" ]; then
kdialog --warningyesno
"The installation requires approximatly $TEXSIZE of disk space Continue?"
if [ $? -gt 0 ]; then
exit 1
echo "The installation requires approximatly $TEXSIZE of disk space"
echo -n "Continue?[yes/no]"; read GO
echo $GO | grep -i "no"
if [ $? = 0 ]; then
exit 1

# Do installation
echo 'MSG: Setting up TeX Live directory'
mkdir -p $PBI_BASE/texlive/$YEAR

echo "MSG: Installing TeX Live files..."

# extract our texlive installation
cd /$PBI_BASE/texlive/$YEAR/ &&
lzma d texlive${YEAR}.tar.lzma -so | tar -xpf -

# prompt for a default paper size
if [ $INSTALLMODE = "GUI" ]; then
PAPER=`kdialog --combobox "Select default paper size"
"A4 Paper" "US Letter"`
echo -n "default paper size [A4 Paper, US Letter]: "; read PAPER

echo $PAPER | grep -i "Letter"
if [ $? -eq 0 ]; then
texconfig-sys paper letter

echo $PAPER | grep -i "A4"
if [ $? -eq 0 ]; then
texconfig-sys paper a4

echo "MSG: Updating TeX filename databases"
texconfig-sys rehash

if [ $INSTALLMODE = "GUI" ]; then
kdialog --yesno
"Congratulations! Installation complete -- test installation?"
if [ $? = 0 ];then
cd /tmp/
$MY_TEX_PATH/pdflatex sample2e.tex && kpdf /tmp/sample2e.pdf
if [ $? -gt 0 ]; then
kdialog --error
"The test may have failed to load, please report any errors: $?"
echo "MSG: Displaying readme file"
# I don't know a programa off hand to use for console output.

What is wrong with that script? Nothing compared to what is wrong with the PBI script API.

$PROGDIR should expand to /Programs/ProgNameVer instead of ProgNameVer.

The maintainer shouldn’t have to treat GUI and TEXT mode differently – the API should do it. In fact, that was the main impetus for the EPI spec creating platform independence. In an EPI, people would have said ask the user a question. Not have to understand shell script and massive toggles for GUI/TEXT mode install.

I believe PBI now also do similiar idiocy in regards to fonts handling that should be done at a higher level. However, according to the officially published documentation, my old script is still the correct way to go with a PBI.

One of the reasons I gave up on Kris Moores PBI, was the brain damaged design, the other reasons were the total miss management of PBI…

Under the draft spec’s I wrote for EPI, the above script would have become something like this:

# optional EPIL script for EPI

define question dialog with
title = "TextLive EPI"
message = "Please set a default paper size"
default = "A4 Paper"
options = ['A4 Paper', 'US Letter']
launch as paper_size

if paper_size == "A4 Paper" then do
execute "texconfig-sys paper a4"
execute "texconfig-sys paper letter

Now I ask you, if you were not a programmer, which one do you understand? Then let me ask you, if you just want to get on with your life, which would you rather write?

Both the PBI sh and EPI EPIL scripts would result in a simple dialog asking you to choose from one of two options. If you know how to use TexLive, the EPIL script would be totally unnecessary because you already know how to change paper sizes. That means you don’t even have to write a script at all in a normal case.

End result? Oh so simpler.

Marley & Me

Tonight I was watching a movie called Marley & Me. The films an excellent glimpse into what life can be like, for anyone who hasn’t bee living with their head so far up their arse to notice 8=) It’s about a couple of newly weds, who trade the winter for a warmer location in Ft. Lauderdale, south Florida. In order to stave off his wife’s plans for a family for a few years, journalist John Grogan springs an early birthday present on his wife Jenny: they adapt a yellow Labrador Retriever, the clearance puppy. While successful in his intentions, Johns plan backfires when young Marley proves to be one of the worlds most hyper destructive dogs, yet too much of a lovable lug to just get rid of anytime soon. The movie charts a course that I would call “A slice of paradise” with all of it’s pitfalls to go along with it. Marley & Me follows the lives of the Grogan family, and dear but incorrigible Marley, If you love dogs, you’ll love Marley, if the exact opposite is true, well you’ll be relieved not to be in such deep doggy waters >_>. I love animals, always have and likely always will; having dogs, I can also be sympathetic to the whole ruckus caused by Marley. Hmm, for some reason I can’t help but remember a dog named Milo, that I used to help look after years ago as part of this business; he too failed obedience school (horribly lol).

For me, I would say it is fair to say that I feel a bit of a personal connection with this film. Fort Lauderdale is the city that I grew up in as a child, so Broward county is a name I’d know anywhere, and the news paper in South Florida, is also one that my parents used to deliver for… it’s a small world, isn’t it? Even closer to home then that, their first sons name, Patrick was also the name of one of my elder brothers: most people that know me fairly well, also know that I have an older brother but there’s more to my families history then that. In short, my brothers Reese and Patrick were twins, but only Reese survived. My father also had a son, long before I was born, but Jeffery never quite made it into this world :'(. Whatever the afterlife holds, one thing that I have always hoped, is that someday I’ll see us all together in heaven.

As everything must someday, life on earth eventually comes to an end, and Marley is no exception to that rule. Years role on, and take their toll: Marley grows old, as we all will some day. The ending is very sad, but I would have to say that he had a very good life, and it was one full of much chewing too ;). I think that perhaps, this line from the film sums up best what it’s like to have someone like that in your life:

John Grogan:

A dog has no use for fancy cars, big homes, or designer clothes. A water log stick will do just fine. A dog doesn’t care if your rich or poor, clever or dull, smart or dumb. Give him your heart and he’ll give you his. How many people can you say that about? How many people can make you feel rare and pure and special? How many people can make you feel extraordinary?

If anyone can watch Marley & Me, and take the ending without drawing a tear along the way: I truly feel sorry for any animals in that persons care.

We all have people in our lives, animals as well, that are such an integral part of our life, of every thing that makes it worth living. You can’t hope for more then that.

of passwords and tags

Having some spare time, I set to updating my code books while I wait on the Google Wave video to reload; I had to pop off at ~55min for a Live Operation ;). Ahh, crud! Now it looks like I’m going to be interrupted by dinner 8=).

Around late April, I devised a new schema for how I handle my password management—yes I am insane. I actually do have an encoding system for increasing password strength, that is tied to how my brain functions. It’s built from a system of standard passwords that are pseudo-salted with mnemonics that are tied to both the schema and how my brain internally organizes data. The end result, a systematic password that is more difficult to brute force, and hard to guess unless you are me ;).

I’ve just converted about 50% of my core services to the new password system, and I’ll do the rest tonight.

At the moment, my bookmarking has been focused around delicious. The pattern I have chosen for tagging is roughly the same as what I’ve been using in Gnolia; Category/Sub-Category/… and in place of larger meta tags (e.g. Programming/Perl) I’ve bundled the tags. It’s an informal hierarchy but rather nifty. Gnolia lacks bundles which I dislike about it, but honestly the only thing Delicious’s method offers in improvement, is you can’t forget to add the meta tag along side the regular one (e.g. Programming/Perl/Frameworks).

The tags I’ve arranged are strongly organised, I like keeping things tidy. There is a simple “Personal” tag for things connected with me, Services/ for various services: Services/Webmail for example contains marks for Google and Live mail. Programming/Language/{Distributions,Documentation,Modules,Frameworks, …} is also in use

For some reason, I love organizing crap…. lol.

Something about this song just grows on me

Mister Officer, I didn’t mean to speed
No I didn’t know I was pushing 90
Mister Officer it’s such a pretty day
Can’t you let me go with just a warning

Mister Officer, I’m so sorry
Yes I know that this is not the autobahn
Mister Officer this isn’t like me
Yes sir, yes I have a reason

I had the top down the radio blaring through the speakers
I think I blew a speaker out
I wasn’t trying to be reckless
I wasn’t even in a hurry
I just can’t stop thinking bout him
Can’t stop thinking about him
Shouldn’t be thinking while I’m driving but I can’t stop

Mister Officer I didn’t see you
And I guess I didn’t hear your siren
Mister Officer I know you’re serious
I can’t help it if I can’t stop smiling

I had the top down the radio blaring through the speakers
I think I blew a speaker out
I wasn’t trying to be reckless
I wasn’t even in a hurry
I just can’t stop thinking bout him
Can’t stop thinking about him
Shouldn’t be thinking while I’m driving but I can’t stop

I had the top down the radio blaring through the speakers
I think I blew a speaker out
I wasn’t trying to be reckless
I wasn’t even in a hurry
I just can’t stop thinking bout him
Can’t stop thinking about him
Shouldn’t be thinking while I’m driving but I can’t stop
Can’t stop thinking bout him
Can’t stop thinking about him
Shouldn’t be thinking while I’m driving but I can’t stop

Mister Officer, I didn’t mean to speed
No I didn’t know I was pushing 90
Mister Officer it’s such a pretty day
Can’t you let me go with just a warning

— Mister Officer, Jypsi

Bugs can be fun, as long as I didn’t write them

In order to make optimal use of tonight, I did a portsnap and fed a list of ports to be updated, into my script; then went to work on playing with pthreads. A short while later, when things got to ImageMagick, I got the shock of my week—pkg_delete crashed during a make deinstall!

In looking through the code, I’ve found the reason why, there’s a package name passing through the code as a null by the time it finishes passing through pkg_do in src/usr.sbin/pkg_install/delete/permform.c. From the looks of things, it goes bonkers once Plist is setup via read_plist(). Hmm, well well, the Package (_pack) structure being passed to it has rather interesting contents at the time.

I just don’t have much more time to fiddle with this damn thing! I’ve got to be up for another groaning day of work tomorrow.

OK, found it, there’s some funkyness here. When it hands off to add_plist (basically every damn thing in the bloody +CONTENTS), it has NULL’d the dohicky that gets copied in later. read_plist() sucks a file line by line, looks like if the trailing character is a space, read_plist() sets it to the null character ().

That creates a bit of a problem, because the +CONTENTS file for ImageMagick has a line ‘@pkgdep ‘, which results in pissing off the whole damn thing… lol.

So… how to handle this problemo? I see two things: 0.) pkg_delete should NEVER FUCKING CRASH!!!! No matter what is in a +CONTENTS file, at least, that is my opinion!!! And 1.) if ‘@pkgdep ‘ is not valid in a +CONTENTS file, whatever causes ImageMagick/ports to be shoved there needs to be found and fixed. Digging into +CONTENTS file creation is a beast for another hour. Why the pkg_delete program chooses to pass a NULL through I have no bloody idea, maybe shifting through CVS logs might hold the answer to that mystery. The pkg_install suite has some rather ugly and quickly hacked together parts, that really makes me wish they had used shell or (like OpenBSD) imported Perl into the base for the job, rather then doing it in C. Don’t get me wrong, I like C, but please don’t write functions with over 1,000 Lines Of Code ;). Either way, when it comes to fixing the pkg_install issues… that’s something I’m not going to touch unless a developer suggests what they would like to see in a patch, because whomever is maintaining it, should have a better overview of things then I do at the moment; I’m in no shape to do any more thinking tonight. Perhaps I’ll just file a bug report on it and see what comes of it.

Right now I just need to get some freaking sleep before work. Ugh, stairs here we come…….

Interesting tidbit: Twitter Talking Separately to Microsoft and Google About Big Data-Mining Deals

Shared from Google Reader

Twitter Talking Separately to Microsoft and Google About Big Data-Mining Deals—BoomTown

If this is how they plan to make a crappy search engine (Microsoft’s) better, by trusting in Twit’wits, oh boy and I glad that Mage introduced me to Google all those years ago lol.

I’ve used several search engines over the years, in the end I have no respect for Microsoft’s offering (Hotmail has improved, search has not) and some respect for the one over at; which I was introduced to when some program (thankfully) changed my default search provider in IE. Since I’ve never used Yahoo! For searching, I generally skip commenting on them. Microsoft how ever, I used there search engine for many many years, dating all the way back to WebTV—at least Google tries to find what I’m looking for ;).

Notes over lunch

Work yesterday was fairly uneventful, so it left me time to concentrate on programming, doubt Friday will be so lucky… lol.

I worked out the basic architecture for pipin’s daemon, and have had the details on my mind for most of time since ~1400Q yesterday. Current on the hit list, is a pair of prototypes: one built around libpurple, that is to deal with the issue of a bare bones get connected task, the other is an experiment in moving the “Gatekeeper” component into its own thread. Once both prototypes are done, I’ll look at merging them and re-evaluate how they play together versus mucking around with GLib’s main loop. Conceptually, pipin-imd consists of three units: purple, dispatcher, and gatekeeper. The purple unit deals interfacing libpurple into our own kit; the dispatcher in mapping between purple/pipin-im events and notifying all registered clients; and a gatekeeper to manage incoming data from pipin-im clients. I also have an idea of how the communications protocol between daemon and server might work, not to mention the fact that I want a simple net command shell that would allow communicating with the daemon via a shell or batch script lol.

The plan is for the daemon to be written in C and licensed under the GPL, since purple forces use of GLib, there is no reason to use C++ for sake of the Standard Template Library. Whatever the legality of using Python ctypes based or SWIG generated code to interface with libpurple is, I doubt it would be in the spirit of the damn blasted GPL, even if the license was less restrictive >_>. The client unit, I plan to write in Python using whichever widget toolkit proves most appropriate (Qt, GTK, Wx). The daemon is a pretty simple program, the client side stuff gets all the fun, and a license more in line with my ideals of freedom, then the uglicious GPL.

Originally I had planned to work on the threaded gatekeeper prototype during the time before dinner and afterwards, but never got around to it. It wasn’t a good nights sleep, but at least I went to bed early for a change…. lol