In my never ending quest to make the Penn State ACM’s website as automated and as useful as possible, I wanted a page that allowed a user to enter his name and email and automatically be added to our listserv. With a little HTML, PHP, and a touch of the Drupal API (our website runs on Drupal), it was up and running in a little under an hour. Code incoming.
<?phpif(isset($_POST["name"])){$name=$_POST["name"];$email=$_POST["email"];if(mail("[email protected]","Listserv Subscription","SUBSCRIBE L-PSU-ACM ".$name,"From: ".$email)){drupal_set_message("Subscribe confirmation sent to ".$email.". Thanks for signing up!","status");}else{drupal_set_message("Error sending subscribe request to ".$email.". Email [email protected] if problem persists.","error");}}echo'
<form method="POST" action="">
<b>Name:</b>
<input type="text" class="form-text" name="name" size="60" value="" />
<b>Email:</b>
<input type="text" class="form-text" name="email" size="60" value="" />
<input class="form-submit" type="submit" value="Submit"/>
</form>
';?>
As you can see all it is an HTML form that calls the PHP mail function which sends an email to Penn State’s listserv server on behalf of the user requesting that he be added to our listserv. From there, the ListServ server sends a confirmation email to the user and all that need be done is to click a confirmation link. That’s it! Simple, no?
One note however. I would have preferred to have put the PHP in a separate file in order to keep the HTML and PHP away from one another, but I needed to use the drupal_set_message function meaning it had to be called from within a Drupal node. I’m sure there are ways to call it from outside a Drupal node, but given the scope of this project, this solution works just fine.
After the incredible show put on by TEDxPSU 2010 last year, I was compelled to volunteer for TEDxPSU 2011 this year. So over the past few months I had been in charge of organizing the student expo, or Xpo as we branded it. The goal was to showcase some of the groups and clubs around campus that do cool stuff to the attendees of TEDx before the main event starts. At first, I had trouble getting enough interest from clubs to want to participate in the Xpo. However, given enough time and persistence that changed. From there, everything was fairly straightforward. On the day of TEDx I show up, the groups show up, they present their work to the attendees, and they pack up, all while I simply supervise and take care of any problems that arise. The Xpo went so smoothly that I actually had plenty of time to help other volunteers with their jobs. After everything was said and done, the speakers had presented their topics, and Alumni Hall fell silent all the volunteers and I had the task of tearing down the entire hall (see below pictures!) in just over three hours.
I wanted to add a timer to my Linux compile script so I could see how it took to compile the kernel. However, Bash does not support floating point precision. Now seeing as kernel compiles take some time this shouldn’t matter. I could use the date command to get the hour, minute, and second before and after the compile and subtract them, adjust for difference in hours, days, etc. This way I wouldn’t need any type of precision. But that’s a lot of work, and I want to know exactly how long it took; not rounded to the nearest minute.
Rather, why not just get the seconds from 1970 before and after the compile, subtract the two, and divide by 60? Much easier! Except, I need floating point precision. The solution: the bc program. It’s like a command line calculator that supports all the precision I could ever need. Let’s take a look:
Compiling Linux yourself is one thing. Actually using the kernel you just compiled is another. Here’s my latest debacle with the hell I put upon myself by compiling my own kernels.
The problem: Compiling any kernel modules against a custom compiled kernel would begin to fail after an unknown amount of time had past after compiling the kernel.
I also compile my own video driver kernel modules. At first when I compiled and installed a new kernel the module installer would work fine. But then if I went to do it again for whatever reason say, a week later, it would fail. Programs like VMware and Virtualbox would complain about not being able to find the kernel headers as would dkms.
But I thought that if I installed the kernel image and kernel headers packages that everything would work? That’s how it seemed to work anyway.
Well, was I wrong. I always assumed that the kernel headers should be in /usr/src/ and any program that needed them would look in there. That is, I assumed it was the standard directory for kernel headers. Maybe it is, but there’s more to the story.
As it turns out, there are two symlinks, build and source, in /lib/modules/$(uname -r) that points to the directory the kernel was built in as can be seen in the directory listing below.
In my case, I would build the kernel in my home directory and then tar up the source and move it to long term storage once the system was playing nicely with the new kernel. That is, after I had all my kernel modules built. The undetermined amount of time it would take to stop building modules successfully was the time until I archived the kernel source and deleted the build directory.
So here’s the bottom line/solution to the problem: You must keep the kernel source in the same location as you built it or you need to update the build symlink in /lib/modules/$(uname -r). In my case, that meant creating a directory in /usr/src/ where I’ll be keeping all the sources from now on (or at least the current and previous one).
Now, what I’m curious about is how the kernel packages from the software repos work. They don’t distribute the full kernel source, only the headers. Checking in an old module kernel directory, say, /lib/modules/2.6.38-11-generic shows the build symlink pointing to the kernel headers and the source symlink is not even present. Does this mean I don’t even need to install the headers if I have the full source available? In theory, no, since the source includes the headers. But then why couldn’t I change the build symlink to point to my custom headers and delete the source? If you know, email me with some clarification. Until then, I’ll continue to experiment.
A few months ago I started compiling Linux on my own. Not for any particular reason, just to do it myself. By nature, the commands to compile the kernel are repetitive which means it’s the perfect thing to write a script to do!
Just give it the kernel source directory and let it do it’s thing. Once done, it creates two deb packages, the compiled kernel and the kernel headers (this also makes it only work on Debian-based distros). From there, it’s trivial to install a deb package.
Note that this script will most likely continue to evolve and the copy below may become outdated. Thus, the most copy can always be found on its GitHub repo.
