SuPz.orG

Yesterday an article was on the front page of digg, regarding fighting climate change by leaving your computer turned on, and it piqued my interested (after all, your computer being turned on is wasting electricity, so how could it possible counter that horrible effect?), so I took a look and it was just an pseudo advertisement for participating in BOINC for climateprediction.net. Now, while I normally don’t participate in any distributed computing projects, simply because I hate having my server bring up room temperature by multiple degrees, I figured I’d give it a try for the pure challenge of trying to limit the CPU it uses.

So I did some due diligence and found an application for Linux called cpulimit, which lets you specify a process by name, PID or by full path, and this program will limit it to a certain amount of CPU utilization, so I can tell the BOINC client to only use 25% of my CPU, for example. Now, while cpulimit is a pretty neat application, it has one problem, and that is its inability to limit the CPU usage of child processes spawned from one of your existing limited process. This means that in the case of BOINC, I can’t just start it and then tell cpulimit to limit the boinc_client process, since that process kicks off any number of additional processes.

However, what you can do is write a script that will find all processes being run by your boinc user (I did an apt-get install boinc-client, and the Debian package automatically creates a boinc user and runs all of the processes as that user), and throttle them, then just toss that into cron and make sure that none of the processes use more than your specified limit.

Take a look “after the jump” for the bash script that does the above. It’s quite simple, but amazingly I couldn’t find any off-the-shelf ones on Google.

 (more...)

					

I picked up a Slingbox Solo the other day. It’s a cool device that let’s you do what they market as “place shifting”… pretty much, you stream your cable box or Tivo or whatever through your broadband connection to anyplace you may be, that has an internet connection.

It’s funny that I even spent money on it, since I had written something that did the same job using a TV card under Linux, and ffmpeg’s ffserver to stream content from the TV card using V4l and xawtv to change channels, etc. It did a pretty good job, however since it was a bit of a hack job it had it’s issues. It was all web based and fun. Slingbox takes out all the work and puts it all into a nice appliance, with no associated service fee — w00t!

So anyway, I installed the software on my MacBook, and went through the setup assistant and everything, until I got to the last step where it tells me its registering or something, at which point it crapped out and gave me an error saying it couldn’t register. So, I said whatever, I’ll try launching SlingPlayer to see if that will work. SlingPlayer also gave me the same crap, with some associated nondescript error message along the lines of “We’re really sorry but the application must quit. You can restart and try again later.”

This wasn’t cool, so I tried over and over again, but to no avail. Re-ran the setup assistant, and it gave me the same error… so being a resourceful hax0r I busted out Wireshark (which is now available in a Leopard all-in-one package) to see if it was trying to get something over the internets or what… I found that yes, indeed it was, and it was opening an HTTP connection with 157.22.2.7 (spas.slingmedia.com), and sending an HTTP GET for mac_register.php?VersionNo=1.0.4.214&uuid=<removed>&OS_Identifier=SP_MAC&FinderId=<removed>

The problem is that this HTTP GET never got a response… after about 2 minutes, it eventually got a FIN from the server, and the connection got torn down, at which point SlingPlayer complained and told me I had to restart the application. So, I went ahead and modified my /etc/hosts on my Mac to resolve spas.slingmedia.com to 192.168.0.1 (my server’s IP), instead of the real IP, and then I created a dummy PHP script on my server called mac_register.php that simply returned the posted data. After doing this, SlingPlayer started up just fine, and was able to stream and do all of that fun stuff.

Of course, a while later it eventually started complaining that my copy of SlingPlayer hadn’t been activated, so I went and reverted the /etc/hosts changes, and fortunately by this time, SlingMedia had fixed their mac_register.php script to work again, so it was able to register and activate and all that fun stuff… but while it wasn’t functional, I wasn’t oppressed by the man! Huzzah!

The list of supported hardware for VMware ESX 3.5 is about 5 devices long, which means that if you want to use local SATA for storage on a VMware server, and don’t feel like buying new servers, or doing some weird cross-NFS storage model with multiple gigabit ethernet links between the boxes, you have to hax0r ESX.

I found a really good thread on the VMware forums where a number of people are trying to get ESX 3.5 running on their unsupported SATA based devices and a lot of them are actually able to do it. I, on the other hand, am unsuccessful so far, but I’ll keep trying. Regardless, If you’re seeing the following after installing and booting up into ESX 3.5, head over to the forum and see if the scripts provided there can lend you a hand:

Mounting root failed. Dropping into basic maintenance shell.
To collect logs for VMware, connect a USB storage device and
run 'bin/vm-support <devicename>'.
Machine will be rebooted when you exit from this shell.

And make sure to post a comment if you get your unsupported SATA-based server working.

Update: One of the guys participating in the thread has created a list of unsupported SATA controllers and motherboards that are known to work with ESX 3.5, and the necessary hacks to get them working. I love the internets.