After my last experience, you'd think I'd have learned. But nope, when my girlfriend needed a new desktop system, I enthusiastically offered to build one for her. Hey, this time it's desktop hardware, and I know desktop hardware, right? I built my last machine myself, and I've replaced a couple motherboards and done various other work on computers since then.

Well, it seems there were a few changes since my last computer. First of all, there's the whole business of heatsinks. I don't remember spending any time on the heatsink last time around. I suppose this is because it was pre-attached to the chip or because the assembly process was "place the heatsink on top of the CPU", but I don't remember which. For the Athlon 64s, the heatsinks are so ginormous that you couldn't place the CPU into its slot if it was attached to the heatsink. So there's no option but for them to ship the two separately and have the user assemble them.

Problems? Well, consider the documentation. The store sold us a supposedly complete CPU box packaged by AMD which, when I opened it, contained a stern warning not to attach the heatsink without first applying a thermal material. Contradicting this, though, was the fact that there was something that looked suspiciously like thermal material already on the heatsink, and after quite a bit of research I decided that the warning was for people who want to overclock their systems or replace the stock thermal compound. Nowhere in the documentation does it say whether the heatsink comes pre-treated with thermal compound, though, and since I have no desire to let the magic smoke out, I wasted a lot of time checking up on this.

A second problem with the documentation is that it suffers from severe Lowest Common Denominator syndrome: the installation instructions are entirely word-free. For simple purposes this might suffice, but it took me a lot of squinting and several incorrect tries to figure out WTF the diagrams were telling me to do; in fact, I didn't really figure out what to do until I found an annotated version online with actual words. AMD, there's a reason we quit using cave paintings and invented written language. Please use the stuff, it'll make the rest of us much happier.

On to the practical problems: it's apparently necessary to attach the heatsink so tightly that you need a latching mechanism the size of Wyoming to hold it onto the motherboard, and actually activating it seems to take several metric tons of force. OK, I exaggerate, but just this step (attaching the heatsink assembly to the CPU) took me at least an hour of prying at the latch mechanism to lock it down. In fact, I didn't finish until I finally gave up using my fingers and used a screwdriver to apply a good portion of my weight. Predictably, of course, the screwdriver slipped as I secured the latch, bouncing off the motherboard. More on that in a moment.

The motherboard (an Abit K8N) had better documentation than the CPU, but not by much (this is apparently a pattern with computer components that most consumers never mess with). I had to make educated guesses about the orientation of several connectors, especially some of the case connectors, and it took me at least a dozen reads to understand what I was doing wrong with the power cable.

Once I got all my initial stupidity worked out, I flipped the switch and watched some of the fans turn on and the hard drive spin up...and that was it. Nothing. Nada. No beeps. No POST. Not even a blank video signal (although the video card's fan runs just fine).

So, my best guess is that I killed the motherboard dead with my screwdriver, which means I get to go buy a replacement and install it. And, of course, disassemble all the stuff I carefully assembled already. Including the CPU assembly. And the thermal material on that probably won't be good any more, so I'll have to replace it with what's left over from when I rebuilt my laptop. And there's always the possibility that it's actually the CPU that's dead (although I can't imagine why)...in which case I could waste a lot of time and effort replacing the motherboard needlessly. Blah.

I begin to think that it might be worthwhile to pay the store to install the critical components for me, or even just buy from a real PC vendor. At least then I'd avoid wasting my time and (presumably) get my money back if they screwed up.

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

It's been a little while since I wrote about Asterisk. It's about time to update the story. I've been using Asterisk at home for awhile, but now we're going to use it at work. The need We have approximately 150 internal extensions here, and they are being supported by a Nortel PBX. This PBX is being end-of-lifed, and it would cost well over $100,000 to replace it, once the cost of the two required Windows servers (!) was factored in. Not only that, but it still isn't as flexible as Asterisk. Along with that, we have a need for internal wireless phones. We have a large manufacturing area, and we have people that would like to be able to use a wireless phone anywhere on the shop floor or office areas. No single cellphone company provides a signal that is strong enough to reach everywhere in the building -- not to mention that there would be big airtime fees. So we are planning to deploy 802.11b wireless phones for this purpose. Hardware The decision was made to go ahead with Asterisk. We will be replacing all office phones with Polycom IP501 units. This means running about 90 new runs of CAT5 to people's desks. For our Asterisk server, we got a HP DL385 2U server with dual dual-core Opteron 2GHz CPUs. We've really had good luck with Linux on these DL385s, and with HP's support. We got redundant power supplies, disks, fans, etc. on that machine. The CPU on here is probably more than we need, but telephones are very important to us and we wanted to make sure that we don't have any issues down the road. We purchased two A104d quad-T1 interface cards with hardware echo cancellation. Very nice cards. The drivers have been a little troublesome. But Sangoma's tech support is awesome. They logged onto our box and I was watching as they were hacking on the kernel module right there. Tech support like that is rare. I highly recommend Sangoma. We really need only one of those cards, but they're the only component of the Asterisk server that isn't completely standard. So the second is on hand as a spare. For our analog phones, we are using two Adtran TA 750 channel banks. Each has a T1 interface and a 50-pin telco ("Amphenol") connector for a punch block. So we can run 24 channels off each of those. Our consultants (see below) suggested getting them used from Colspar Communications. We found them fully loaded with FXS cards for $250 each. We bought three -- two for production use and one for a hot spare. These are very solid and nice units. The only problem we had is that the voicemail indicator lamps (MWI lights) on our old analog phones wouldn't light up. Turns out that Asterisk with a T1 channel bank uses digital FSK lamp, whereas our older analog phones expected a certain line voltage to indicate messages waiting. After some Googling, I found add-on FSK lamps from American Science & Surplus for $1.50 each. Nice. In our other building, we have a gigabit fiber-optic link, so we purchased an AudioCodes MP124 SIP-analog gateway. It's working well so far, except it's not working with voicemail indicator lamps at all. It seems to be a firmware issue that is incompatible with Asterisk in some way. We're investigating now. For wireless phones, we're using the Hitachi IP5000. We're not terribly pleased with the quality of wifi phones in general, but this one seems pretty solid. And it doesn't crash every few minutes like the Zyxel model we tried. The Telco Our current phone system has about 23 analog lines for interaction with the outside world. We wanted to get a voice T1 with PRI channel for the Asterisk system. Our local telephone company is Sprint, and this has been the annoying part. First they tried to quote us an Internet connection. Then it took a very long time for them to even get us a quote for the voice T1. And now we have signed the contracts but are still waiting for an install date. Consultants While I had used Asterisk before, it was in a home setting. Not exactly business-critical, and not dealing with hundreds of extensions, T1 lines, and all the rest. So it seemed reasonable to get someone experienced with that sort of thing to help us out and make sure we weren't making mistakes that would cost us down the road. I posted on the asterisk-biz mailing list describing what we would like to do. I got a bunch of supplies from consultants, and we wound up selecting Asteria Solutions Group. At the beginning, we wanted some advice about server sizing, phones that work well in business settings, etc. I think that most consultants are not used to working with people that have significant Linux experience, and a good deal of Asterisk experience, already. Asteria was a little surprised with our situation at first, I think, but has been very helpful. They've educated us on the ins and outs of T1 technology, pointed us to Colspar (which saved us a ton of money on analog gateways), and helped us with some obscure questions. They were also fine to have a much smaller involvement with our project than they would probably normally have. I highly recommend them. Surprises You'll never believe just how hard it is to buy phones from Polycom. They won't sell directly to people, nor will they even list authorized retailers on their website. You have to call them, leave a message, and in a few days they'll let you know where to go. Some online retailers such as atacomm sell Polycom phones, but they're not authorized to do so, so you don't get any warranty or have the right to get firmware from Polycom. What's more, Polycom usually expects people to need configuration assistance with their phones. But I think that when I told them we need 90 IP-501s, had already configured 5 on our network, and needed no assistance, they were happy to work with us. Reactions We've deployed desk phones all over by now. So office workers have two phones on their desk right now (one from the old system, one from the new). We've heard a lot of positive comments from people about the new phones. And all the features of Asterisk -- music on hold, flexible queues, etc -- will be really helpful here. Cost Even with the cost of all new phones, new CAT5 runs and labor for that, consulting time, etc., we still expect Asterisk to be far cheaper than the latest Nortel PBX. Also... I recently wrote an article about Asterisk for Free Software Magazine. I'll let you know when/if it gets published.

As mentioned in my last entry, Livejournal have changed their url scheme to get around a problem in mozilla. The trouble is down to the -moz-binding CSS property. I'll repost a copy of the short lived posting to the lj_dev community earlier.

Discussing the URL Change As we recently announced in [info]news, we have changed the canonical URL of most journal, community, and syndicated content. While we did offer subdomains to Paid users in the past, this is now the canonical URL that we will link and redirect to for all journals. However, all communities are located at http://community.livejournal.com/username and syndicated accounts at http://syndicated.livejournal.com/username. Due to the way certain proxy servers are configured, and the fact that the HTTP RFC prohibits it, the canonical URL for journals with a username starting with an underscore will be http://users.livejournal.com/username. We are however offering a free rename if you fall into this group. So now the technical side of all of this and why it was a required change; bear with me as its 3am my time and I'm sitting in John F. Kennedy Airport after a five hour flight. Late last week we become aware that it was possible to use the "-moz-binding" CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. We immediately altered our cleaner to strip this attribute from entries and comments, though also realized that wasn't even half the battle. As we allow custom CSS in many of our styles, as well as the ability to link to an external stylesheet in a variety of fashions, it was quite possible to take advantage of this exploit and hijack the session cookie of any user who views your journal. As we, along with many other sites, used one cookie to authenticate a user, this cookie was quite powerful if stolen. If the user had not chosen to bind their cookie to their IP address, a malicious user could steal it, login as that user, deface the account and SPAM with it, as well as modify that user's style to include the exploit thus causing this problem to spread much like a virus. Borrowing the idea from another development team within Six Apart, we decided we needed to break our cookies into three categories. One cookie would be our application management cookie, this cookie would only be accessible on www.livejournal.com where we will not display untrusted content. A second cookie will be accessible on all subdomains of livejournal.com, though it only will say if you are logged in or not; it is solely for optimization. We then will issue one cookie for each journal you visit. This cookie will be only accessible on username.livejournal.com or community.livejournal.com/username as it is limited to a single journal. This cookie will only grant you the permission to read protected entries and post in the particular journal. This means that if the journal owner steals your cookie, they will be able to do nothing more than view their journal and comment upon it as if they are you. In the end you will have n+2 cookies, with n being the number of journals you visit. Due to the fact that we cannot clean every external CSS stylesheet linked to every time we generate a journal page, this change is required. While it does not fully protect us from some new cross site scripting vulnerability that can be exploited via entries or comments, they are much easier to block, patch, and recover from quickly. With Mozilla deciding to allow the execution of arbitrary JavaScript via CSS, there is no other viable solution than the one we have undertaken. We developed a plan to phase all of this in over the next week, URL change first and then followed by the cookie change, though this morning we were made aware that this was being actively exploited. As such we took our week time line and shortened it to about twelve hours. While URLs have been changed at this time, our cookie handling change has not yet happened. This should however be expected to take place within the next day or two as well as various other cleanups and fixing bugs we've already encountered. Please feel free to let us know if you have any questions and open a support request if you find a bug or encounter a problem. Sorry all of this came with just about zero warning, but in the end we could not wait longer to fix this problem.

Thanks to Daniel Silverstone for providing me with a cache copy of the text.

So, what’s with all the broken laptop hard disks?! I have two laptops running almost all day (one as a cheap simple server with built-in UPS) and one as workstation. But in the last, say, 2 years I had to replace the 2.5” (laptop) hard disk drives 4 times! Since laptop HDDs cost a lot more per megabyte than normal 3.5” drives, this was becoming an expensive issue for me. So, I geared up S.M.A.R.T on both machines and did some investigating. The major issue seems to be the load/unload system that is integrated into more and more of these drives nowadays. The heads will automatically be retracted (parked) after some idle time to decrease the risk of shock damage and reduce power consumption. However, this seems to be a bad combination with Linux. I have not done any research into the specific implementation of the journaled file systems that I use (ext3, XFS), but it can something to do with it. It seems the heads of almost all laptop disks I encounter are continuously unloaded and loaded instead of around 5 times per hour. It seems a hard disk drive is made to allow for 300.000 load/unload cycles, after that the mechanism wears of so that inaccurate moving can occur and the platters can be damaged because of a small miss. Now, my drives had 650.000, 1.2000.000 and 900.000 before bad sectors and completely erratic behaviour start to occur, but this was within a year. My most recent broken drive had about 3 load cycles per minute, this means 180 per hour. With things going bad at 600.000, the disk thus had a lifetime of 3333 hours (138 days). This is ridiculously short. So I’ve turned APM of all my drives off (hdparm -B254). Better a small risk of bad sectors when dropping my laptop than having to replace my disk within the year. Also note that my brand new Western Digital disk has spent 14.000 of its load cycles within the first 15 hours that I was busy with installing Debian and recovering backups! If someone has more information about this, please let me know.

Hm, more food for my video iPod which hasn't arrived yet. Revver ("a Flickr for video") is a new video publishing community site which allows you to upload, share, watch, and tag videos for free. You need a special upload tool for uploading videos (there's a Windows version, a MacOS X version, and a Java version which probably works on Linux). They intend to give the creators of the videos some money by attaching a clickable advertisement frame (the so-called RevTag™) at the end of each video. Everytime a viewer clicks the ad, the video creator gets some money. While this might be a great idea, it still leaves me with a strange feeling (the ad is not on a webpage, it's appended to the video itself!)... Some noteworthy details:

• They currently have a size limit of 100 MB per video.
• They don't censor the videos except for obvious copyright violations (porn yes, illegal stuff no).
• You get 50% of the money and Revver gets the other 50%.
• You need a PayPal account to get the money.
• "Your videos stay on Revver for as long as they generate a reasonable amount of revenue" (no unlimited hosting, it seems).
• The videos are automatically put into iTunes and formatted to work with the video iPod.
• All videos are automatically converted into the mov format.
• The default license for the videos is the Creative Commons ShareAlike license (you can probably choose others, I didn't check).

More information is in their first blog post, and in the FAQ. A final quote from the blog post:

It s a new game, we re thrilled to be in it, and we tip our hats bigtime to the Ourmedia crew, the YouTube crew, the Participatory Culture crew, the Creative Commons crew, and all the other crews that came before us.

All in all this looks quite promising, and I'm curious how it will develp and grow... (via Boing Boing)