Southeast LinuxFest 2012

All of you Linux folks: it's almost time again. Southeast LinuxFest 2012 is coming up on June 8-10, 2012, in Charlotte, NC. Go register to attend (there are both free and paid (supporter) options available) and/or submit a proposal to present if you're so inclined/qualified. Either way, if you want to spend a few days hanging out with other linux folks and learn some stuff in the process, plan to attend. :)

Suds of the South 2012

If you're in/around the Tuscaloosa area and like good beer, you should consider the 3rd annual Suds of the South event on Saturday, March 10th, 2012. Representatives from many breweries across the southern USA (including several from here in Alabama) will be on hand, and they'll each have two or three (or maybe even more) kegs with samples of their craft beers. Attendees get a beer stein and unlimited sampling of the various beers (well, until they run out, of course). Tickets are limited, and if last year is any indication, you won't be able to get in if you don't have a ticket already - they'll sell out and won't be able to allow more people in due to fire code compliance.

So, I haven't posted in a while (it's been almost a year), and this seems to be a pattern. I think Facebook has become my "blog" of choice, but to be honest, I really don't like having to sign in via google and/or jump through other hoops to make blog entries. I'll be looking into the software that alienBOB uses for his blog soon, but for the time being, I have an important entry to make. I received a mail from Mikhail Zotov a few days ago, and rather than resummarize what is essentially a summary already, I'm going to post (more of) the entire email (with his permission).

*begin message*

This time, I am bothering you with a request. Grant Coady, a long-time Slacker, an AOLS regular, the author of a few patches for the kernel, the author and maintainer of http://bugs.id.au, and just a nice, intelligent and open-hearted person was taken to a hospital around two weeks ago in a critical condition, which has not improved much since then.

The MRI indicates Grant has severe brain damage. The diagnosis is not fully clear but the docs say the long term prospects for Grant can be very bad. His arms and legs have not moved to this day, he doesn't talk, however his neck is getting stronger, he is moving his head now and focusing his eyes on you, not staring aimlessly past you, and even smiles at jokes.

Grant is 55, doesn't have a family but a brother and sister who live in other places and haven't been found by the police yet. It seems the only friends of Grant are John Sharkey who lives there nearby (Bendigo, AU) and the Net community. John visits Grant in the hospital every day and spends as much time with him as possible.

John has found us via AOLS. He has asked if we, the Slackware community, to which Grant belongs for years, can support Grant with a little gesture of (Linux) friendship by sending him a postcard or some funny Linux stuff, e.g., Tux.

I have made a post on AOLS and wrote to a number of LUGs in Australia (w/o any of them having replied). I would like to ask you to post something on the subject in your blogs, if you find this appropriate.

The postal address of the hospital is as follows:

Attention I.C.U.
Mr. Grant J. Coady
Bendigo Health hospital campus
Lucan Street
(PO Box 126, Bendigo 3552)
Bendigo Vic 3550
Australia

All enquiries (03) 5454 6000

Personally, I have found some cheap Linux toys at

http://www.bytelove.com/
http://www.thinkgeek.com/
http://www.kleargeargeektoys.com/

And, surely, there is store.slackware.com :-)

Best regards,
Mikhail

*end message*

GuruPlug - Part 3

Well, the GuruPlug has been modded. It's ugly, and it's loud, but it works. Pics are here, but really - it's ugly.

If I had it to do over again, I'd get a bit larger case, and I'd be a bit more, um, careful and such. For example, a broad-tipped soldering iron is not ideal for tinkering with a power supply (which is why there's a new one in there).

rworkman@guruplug:~$ uname -a
Linux guruplug 2.6.33.5-kirkwood #2 PREEMPT Thu May 27 14:47:11 BST 2010 \
armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell GuruPlug Reference Board GNU/Linux
rworkman@guruplug:~$ cat /etc/slackware-version 
Slackware 13.1.0

GuruPlug - Part 2

Once your GuruPlug is up and running, you might notice that it seems to run really hot. You're not alone - there are quite a few reports of heat issues with the GuruPlug. For me, enabling the wireless module in client mode while doing anything constructive with the plug is enough to trigger a thermal overload and lockup; connecting the plug to a gigabit switch ends the same way. Based on several forum posts, it's possible that the gigabit NIC issue is not (only) heat related, but time will tell.

I don't have all of the components on hand yet, but I plan to transfer the innards of the GuruPlug to a slightly larger plastic project box, add two or three heat sinks to the metal plate on the bottom of the board, and add a couple of 30mm fans to the project box. Since I don't intend to use either the wireless or bluetooth capabilities, the included power supply (which doesn't appear to have had much love in its creation) should be able to handle the two 30mm fans (each should draw approximately 0.1 amps). If not, I know where to find a 25W (5V/5A) power supply for it :-)

I'll post pics and such when I'm done - stay tuned...

GuruPlug - Part 1

Well, after a successful trial of the SheevaPlug, which is now in use as a firewall (sharing a 3G connection via the onboard ethernet), I purchased a GuruPlug Server Plus back in April. I've just now had time to do much with it, but I'm not terribly impressed overall. Granted, the SheevaPlug was a "developer preview" and thus is expected to be more easily "tweakable" and such, while the GuruPlug seems to be aimed more at end users who just plug it in and use it, but I hadn't expected the GuruPlug to be quite as crippled as it is. That's probably not a fair use of the term "crippled" since it's not intentionally limited by the manufacturer and/or vendor, but it's the only term that comes to mind - basically, it's not easily (if at all) possible to load the kernel from usb or mmc devices, and the uboot (bootloader) shipped on the plug is unable to read ext* partitions at all. I tested some other uboot builds (including one by Philippe Kehl of Debian) and even compiled one myself, but it still wouldn't replicate what I was able to accomplish with the SheevaPlug (load the kernel and initrd from /boot partition on mmc and use / on mmc). Perhaps there was a hefty dose of PEBKAC involved, but eventually, I found it easier and less time-consuming to just put the kernel and initrd on the embedded NAND.

For those who stumble across this blog post, here's the process (but note that this WILL wipe the root filesystem off of /dev/mtd2, so you will no longer be able to boot the OS shipped on the plug). Make the kernel and initrd images and such available via tftp and configure the uboot environment as detailed in INSTALL_KIRKWOOD.TXT and then do something like this:

>> tftp 0x6400000 uImage-kirkwood
>> nand erase 0x100000 0x400000
>> nand write.e 0x6400000 0x100000 0x400000
>> tftp 0x6400000 uinitrd-kirkwood
>> nand erase 0x500000 0x1fb00000
>> nand write.e 0x6400000 0x500000 0x800000

Now, verify that it did what you think it did: :-)

>> nand start
>> nand read.e 0x00800000 0x100000 0x400000
>> nand read.e 0x01100000 0x500000 0x800000
>> iminfo 0x00800000
>> iminfo 0x01100000

Both of those 'iminfo' lines should end with "Verifying Checksum ... OK"

Now you'll want a uboot environment something like this:

>> printenv  
bootdelay=3
baudrate=115200
ethact=egiga0
eth1addr=02:50:43:eb:75:43
ethaddr=00:50:43:01:5D:EA
arcNumber=2659
mainlineLinux=yes
filesize=759688
fileaddr=6400000
ipaddr=192.168.13.50
serverip=192.168.13.11
stdin=serial
stdout=serial
stderr=serial
bootargs_root=root=/dev/sdb2 waitforroot=10 rootfs=ext4
bootargs_console=console=ttyS0,115200
bootcmd_slack=bootm 0x00800000 0x01100000
bootcmd_usb=usb start;
bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); \
  run bootcmd_usb; run bootcmd_nand; run bootcmd_slack; 
bootcmd_nand=nand start; nand read.e 0x00800000 0x100000 0x400000; \
  nand read.e 0x01100000 0x500000 0x800000

Environment size: 629/131068 bytes

NetworkManager on Slackware

Yes, you read that right. :-)

Since I've got a 10 day old infant (as of 10 June 2010) at home, I've been pulling a lot of sleepless nights lately. I've never been one to waste time, so I found a nice project to work on between feedings and diaper changes, and that was NetworkManager. I'm not quite ready to throw any packages out for public consumption, but I'm close - I think I've got all of the major kinks worked out of it, and the only thing left to do now is some final touchups and resolve some issues in Slackware itself that affect the result.

Stay tuned! :-)

Update (20100622): All of it available on http://slackbuilds.org :-)

SYN?

ACK. Yes, there's still potential for real content here, but a combination of Real Life (tm), Slackware devel, SlackBuilds.org devel, and Google deciding to kill the old support for hosting blogs on external domains has not fared well for ye olde blog.

Anyway, Slackware 13.1 should be out in the relatively near future, and school's almost out, so maybe I can find some extra time lying around somewhere... :-)

Slackware 13.0 Released!

Yep, Slackware 13.0 is out, and finally we have both an x86 (32bit) and x86_64 (64bit) version available.

On a related note, my package repository and SlackBuilds.org have new goodies for 13.0 available.

Enjoy, everyone!

Slackware 01000000

To quote the homepage:

[tap tap tap]... Is this thing on? ;-)

Ready or not, Slackware has now gone 64-bit with an official x86_64 port being maintained in-sync with the regular x86 -current branch. DVDs will be available for purchase from the Slackware store when Slackware 13.0 is released. Many thanks go out to the Slackware team for their help with this branch and a special thank you to Eric Hameleers who did the real heavy lifting re-compiling everything for this architecture, testing, re-testing, and staying in-sync with -current.

We've been developing and testing Slackware64 for quite a while. Most of the team is already using Slackware64 on their personal machines, and things are working well enough that it is time to let the community check our work.

We'd like to thank the unofficial 64 bit projects for taking up the slack for us for so long so that we could take our time getting everything just right. Without those alternatives, we would have been pressured to get things out before they were really ready.

As always -- have fun!

Pat and the Slackware crew