Below are the 20 most recent journal entries recorded in ewtroan's LiveJournal:

[ << Previous 20 ]

Thursday, May 22nd, 2008
4:46 pm	USB Power I'm sitting at Houston Hobby airport waiting for a flight home, and while I was looking for power I saw these pedestals between a lot of the seats at the Southwest gates. Not only does it have one 120V outlet between each seat, but it has one powered USB plug between each seat! Time for all of those manufacturers who think proprietary power plugs still make sense to grow up and realize custom wall warts are not a feature. (Comment on this)
Monday, March 3rd, 2008
10:37 am	Recipe Factories For a while now I've been struggling with how to get recipes out of source components. In many cases, our superclasses are now smart enough to eliminate the need for them altogether, leaving just a stub recipe. For binary tarballs, a single addArchive rule is all that's needed in the recipe (you end up putting a version in there as well, but it's almost always encoded in the filename itself making even that spurious). I've been hoping to get to the point where you can check in (say) a single binary tarball and cook without having to have a recipe at all. For this to work well, the cook process would need to look in the repository for the right cook rules, just like it does for superclasses already. We'd also want to be able to leverage the work which has already been done with superclasses, so whatever we added needs to be compatible with those. We came up with the idea of a recipe factory, and I just finished up a working implementation for the next version of Conary 2. The basic idea is that a source component can now have a type, and that type tells the cook process to go look in the repository for help building that source component. For example, if testtar:source has type archive, Conary will look for a factory-archive:source component, and use the recipe in that component as the starting point for building the testtar package. The factory-archive:source component itself must be of type factory, and it is not a normal recipe. It instead provides a recipe factory, which is a class derived from the Factory superclass. Conary instantiates an object of that class and calls that object's getRecipeClass method. That method returns a Recipe class (not an object!), often descended from the PackageRecipe superclass. If the original source component, testtar:source in this case, does not provide it's own recipe, the recipe class returned by the recipe factory is used to build the package. All of the normal recipe rules apply for that class; it must have the right name attribute, it must specify a version string, and so on. From this point on, it's just a normal build. If the source component did include it's own recipe, the class returned by the factory gets called FactoryRecipeClass and the source component's own recipe is then loaded. The source component's recipe file will then create it's own recipe class using FactoryRecipeClass as it's superclass, which will be used to drive the build. One last point: the factory knows a bit about the recipe it's supposed to build. The name of the package being built (testtar in this case) is available as self.name and the path to all of the source files is self.sources. It can also open any of the source files by using self.openSourceFile(path), so it can inspect the files in the source component to decide how to proceed. An example of a very simplistic recipe factory is in oot.rpath.org as factory-archive:source, and a source component which uses it is in the same repository as testtar:source. Factories could be used in a large number of different ways, and I think it will take some experimentation to find out what works well and what doesn't. Get all of this? I know it's a bit complicated, but it's really very powerful. (2 Comments |Comment on this)
Thursday, January 17th, 2008
2:26 pm	Update on the tilt I've had my Windows Mobile-based AT&T Tilt for a couple of months now; here's an update on how well it's doing for me. First off, it's gotten very stable. When I first got the device I did registry hacking and the like and got the phone off the tracks somehow. Before Christmas (I don't remember when) I reinstalled it and it's been solid ever since. I've given up on most registry tweaking, but I'm running more third party apps than I did before (and a ton more than I used on my old PalmOS Treo) and it's been just fine. I leave lots of apps running in the background and it stays responsive. Score one point for Windows Mobile. Now to take one point away from Microsoft. Almost uniformly, their apps are terrible. I say "almost" because there might be one I like that I can't remember off the top of my head. Outlook is probably the least bad of them, and it can be safely described as adequate. Fortunately, there are tons of high quality third party apps available for Windows Mobile. After spending a bit, the phone is incredibly useful. I interact with purchased applications almost entirely, and the phone is a joy to use. Here is a list of the apps I consider must-haves. Spb Software makes a pile of apps which every phone should have. Spb Pocket Plus is the first of these. It gives you great control over the home (Today) screen on the phone with an easy to configure launcher. It does a pile of other things (like multiple tabs for IE), but the Today plugin in is a must-have. Spb Phone Suite gives a dial-by-photo plugin for the Today screen, but it's real value is support for multiple phone profiles. My phone now switches itself to vibrate during meetings (which it knows about because it syncs my calendar with Zimbra), and turns off the ringer at night (while allowing time-based alarms to still go off). No more getting up to ignore a text message at 2am! Finger Friendly Friends is an alternate contact lookup tool which makes dialing by name a breeze. It shows a qwerty keyboard on the screen, but it's not picky about how close you get to the letter you meant. As long as you're near, it finds the right name in your contact list. I can't imagine life without it. Garmin Mobile· XT makes the Tilt a great GPS. Reception is good, voice callouts work well, data entry is pretty easy... In short, it makes carrying a separate GPS worthless. Microsoft Live Search is really good at finding addresses and phone numbers. It's also free, which makes it a must-have. I'm still evaluating Opera Mobile over Internet Explorer. There are also replacements for Outlook I may take a look at. I also have other bits (a Sudoku game, Google maps, etc) which I've installed but aren't critical. Overall, after spending some cash on apps this phone works great. Kudos to Microsoft for encouraging such a vibrant development community. Shame on Microsoft for needing it to make their phones usable. (1 Comment |Comment on this)
Tuesday, January 15th, 2008
9:03 am	Open Wireless I've left my personal wireless network wide open for as long as I had it. I always appreciate finding a network connection to use, and felt like I should reciprocate. I've had neighors thank me, and I don't have to hand out keys to house guests. Once in a while I wonder if I'm crazy doing this, so it's nice to see Bruce Schneier defend the practice. (Comment on this)
Monday, January 7th, 2008
10:05 am	Nathan and I went out for dinner Friday night and tried a restaurant which got great reviews in the local paper. Red Palace is in a mediocre area in a crumbling strip mall, and focuses on Szechuan food. I thought it was a good sign that it claimed one style of Chinese cooking instead of the normal everything under the sun approach, so off we went. In case you don't live in central North Carolina, take my word for it that the Chinese food around here is pretty mediocre (I used to think it was awful, but after moving to Charlottesville for a year I realized it wasn't all that bad). I've eaten out enough in New York and San Francisco to know this, but it's not so bad here that I avoid it. When I was in Shanghai last year, I had two good Szechuan meals which gave me something to compare against. With that background, let me say that Red Palace held it's own. It was easily the best Chinese food I've had in Raleigh, some of the best I've had in the United States, and right in between the two restaurants I went to in Shanghai. We shared the chicken corn soup, stir fried green beans, kung pao chicken, and shredded pork in garlic sauce. The soup was forgettable, but the entrees were uniformly excellent. If you find yourself in Raleigh, give Red Palace a try. (Comment on this)
Tuesday, December 4th, 2007
5:34 pm	Kindle Brilliant. (Comment on this)
Friday, November 2nd, 2007
5:02 pm	Faster is better After watching my Delta flight pull away from the gate in JFK without me (Delta: thank you for letting me watch the door close on my international flight because you got me there more than three hours late and couldn't hold the connection 90 seconds for me) I wound up with a free week in Raleigh. I mean free. I had one eight minute meeting all week. So, what did I do with all of this time? Primarily, I got to work on code. Gafton came down to Raleigh for the tail end of the week, so on Thursday we huddled and did more code. The results? The Conary 2.0 tree is now faster. Dramatically faster. For instance, a simple glibc clone has dropped from 90s to 30s (yes, a 200% improvement). Group commit operations were sped up by 75%. Table sizes in the database were reduced (which should help the "looking up pathIds" slowness). Shadows times were sliced by about half. What did we do? Lots of stuff. Turns out that Conary didn't represent unchanged files properly. Fixing this in a backwards compatible way was a bit of a hack, but doing it avoided a ton of file stream merging on commits. We didn't use bulk loads in postgres, which led to *lots* of round trips. Gafton opened up that API for us. Committing absolute changesets for shadows and promotes led to a lot of unnecessary work. Fixed that. Promote was getting individual files (lots at a time, but still) so it now gets changesets when that looks like a better choice. Promote was recompressing file contents. No good reason for it other than our not having the right API's in place to avoid it. I'm sure I missed stuff, but the bottom line is we're feeling pretty motivated to get Conary 2.0 out the door! (Comment on this)
Sunday, October 21st, 2007
9:45 am	Tilt After six months of waffling, I took the plunge and switched mobile phones. My Treo has long since become a source of constant irritation, mostly (if not entirely) due to Palm OS. A few months ago I tried a BlackBerry and returned it after two days (and knew I was going to return it after one) and since then I've been just carping about my cell phone. Inspired by Gafton's lead, two days ago I went to the AT&T (Cingular) store and bought a Tilt (HTC's Kaiser). This meant switching away from Verizon, which I had mixed feelings about. Verizon's network has always been great, their EVDO coverage (which I used constantly while I traveled) has been quite good, and they're the first cell phone company I didn't hate (having been through BellSouth (yes, now AT&T), Sprint, SunCom, and AT&T (the old TDMA network). The wide range of GSM phones available and the international compatibility of GSM have just become overwhelming. I don't know how Verizon is going to continue to compete with their much more limited phone selection. So what do I think? Well, in no particular order It's heavy. It's listed as 0.3oz heavier than my 700p and I have to pay attention to tell the difference between it and my Treo when I'm holding both, but somehow it just seems heavy. Gafton's description of it as dense holds. It's big. It's a tad thicker than my old Treo (and I mean a tad; it's hard to see) and it's size is almost the same as the Treo without the antenna. Somehow, it feels bigger. The screen is great. Having that much screen real estate while browsing and reading email is really nice. The keyboard is okay. Not nearly as good as the Treo's. I can't reach across it with my thumbs so I have to change my typing pattern though. Mobile IE blows. Blazer blows too, but seemingly less. The phone is a little laggy on some operations, but not overwhelming so. I notice but it doesn't annoy me (mostly when opening and closing the keyboard). The phone ships with 100MB of free RAM. What a joke (6 gig microSDHC card is being shipped Monday). The available apps are overwhelming. I'll have to start digging through it. Voice quality makes the Treo seem like a two cans and a string phone. Bluetooth pairing is a little touchy. I've always had to refresh a couple of times during the device scan, which I never had to do with the Treo. Coverage at home is about the same as Verizon, which is to say 3G is questionable. I'd rather fall back to EDGE than 1xRTT though! Cingular 3G is less laggy than EVDO. GPS on the phone is just cool. A little slow to find satellites, but works well once it's locked on. WiFi setup is annoyingly complex, involving running a magic program to avoid AT&T's proxy. Seems like there is a better answer waiting to be found. The UI of PalmOS is so nice. The UI of Windows is so, well, Windows. Overall, I expect to keep the phone. I little part of me thinks the Blackjack might have been a better choice given the size. I'm still learning the Windows mobile thing (I can't believe they've been actively developing it for 8 years and it still sucks while Apple managed the iPhone on their second try [I'm counting the Newton as their first]), but we'll see how I adjust. As for my wife, she got a KRZR. Nice form factor and plays music well (which she wants for work). It's a little odd putting the microSD card in with the battery, but I don't expect to change it much since the phone will give USB mass storage access to the card. (Comment on this)
Tuesday, October 16th, 2007
1:26 pm	Rain Not only is it weird to see rain (living in the midst of an extreme drought as I do), but it's even weirder to watch it rain out one window of a Starbuck's but not the other. (okay, this is twittery, but I was up at 4am to catch a flight) (Comment on this)
Monday, October 15th, 2007
10:35 am	Verizon Privacy Intrustion If you're on Verizon Wireless, make sure you read this. Verizon wants to share your call records with any company in it's ownership web. Not total minutes, but who you called and who called you. After AT&T's own gaffe I was hoping Verizon wouldn't do anything this stupid. At any rate, you need to call 1-800-333-9956 to opt out of this. At least that part was easy; just press some buttons on the telephone to avoid it. If Google means they're not evil and restrains themselves from these sorts of privacy incursions (not that there record is any good) I'm rooting for them in the upcoming bandwith auction. (1 Comment |Comment on this)
Wednesday, September 19th, 2007
5:18 pm	Gadgets New and Old A couple of weeks ago I visited a prospect who had an old fax machine in their office. Old as in 1974. It was the first digital fax machine every made. It was a freestanding machine coming from the floor so a bit more than counter height. All in all, a pretty impressive piece of machinery. My favorite part? Easily the rotary dial. Just to prove to myself that technology has come a long way in the last 33 years, I went out and bought an mp3 player this week. Rather than join the unthinking masses (you know who you are!) and buy an iPod I thought a bit, and realized that: I'm likely to use this thing only at the gym The gym broadcasts TV signals I own a bluetooth headset I don't use iTunes This list made it pretty obvious that I wanted something with an FM receiver and bluetooth. I'd been looking for ages, but it turns out that bluetooth mp3 players are extremely rare. Samsung has had one for a while, but it's not available in the US (somehow Canada gets it though; go figure). The answer? Of all places, Best Buy has a house brand, Insignia, which just came out with a bluetooth enabled mp3 (and ogg, etc) player with an FM receiver. Always one to try new technology which can't possibly work well I ran right out and bought one. Not only was it $20 cheaper for some reason, but the thing actually works! The bluetooth worked right away, it appears as a USB mass storage device, and it works as advertised. Nice screen, nice form factor, lightweight... I couldn't have asked for much more. I haven't tried the FM receiver yet (I don't go to the gym that often!) but it was nice to get something that lived up to it's promise. (Comment on this)
Friday, August 24th, 2007
9:25 am	Palm Amazing. Engadget took the time to write a well thought out open letter to Palm suggesting some reasons the company's performance has been seen as less than impressive. The final thought was to "Stop keeping us in the dark" so that the loyal legions of Palm users would have some idea when the next generation device was going to become available, and when an update which doesn't break people's phones would become available. To their credit, Palm did take the time to respond, but they said absolutely nothing in their response other than "Nothing to see here, move along". I've been using Palm products since he Palm VII ages ago, and I've gone through Treo 650p and now a Treo 700p. The update Palm gave barely works, the email program syncs horribly, the phone will freeze up for no reason, and... Oh, never mind. If Palm doesn't care about making smartphones that work I don't know why I do either. Mark me down in the "anything but Palm" category. (Comment on this)
Friday, January 19th, 2007
12:17 am	California Driving I made a swing through silicon valley this week, visiting customers, partners, and prospects. I haven't been out here in a while, and the list of people to see really piled up. I ended up having fifteen meetings in two and a half days. From the start of the first meeting to the end of the last was 52.5 hours (including sleep!). Pretty good productivity! I owe a big thank you to google maps for getting me to all of my meetings. Running it across Verizon EVDO on my Treo 700p made sure I knew where I was going more often than not. Rushing to the car after a meeting, typing in the next address, and following the map proved incredibly practical. GPS synchronization would be ideal of course, but until that happens, google maps was really pretty incredible. (Comment on this)
Monday, January 15th, 2007
2:51 pm	Derived Packages Michael Johnson and I spent a good hunk of last week finishing off derived packages. It finally got pushed into the Conary 1.1 tree Friday afternoon and should make it into a released Conary soon. Since I think this is one of the most interesting things to make it into Conary in a while, let me talk about what it does. Derived packages are meant to answer the “I just need to change foo; why do I need to recompile the whole thing?” question. That could be “I just want to remove some of these scsi modules from the kernel” or “how do I change /etc/httpd/httpd.conf?”. Our standard answer to this has been to shadow the trove, make those changes in the recipe, and rebuild. Of course, rebuilding all of apache to change a config file was a bit heavy handed, and rebuilding the kernel is even worse. To address these needs (and it turns out, others as well), we added a new kind of package which inherits everything from another package, and then allows modifications to the inherited contents. When it's all done, a new package gets spit out with those changes. This should be much easier to see with an example. I'm going to walk you through the steps of changing httpd.conf since that's such a common case. First of all, we still need to shadow apache. I want to show the merge here, so I'm starting with an older version of httpd to let that step work. bash# cvc shadow oot.rpath.org@oot:devtest httpd:source=conary.rpath.com@rpl:1/2.0.55-7 bash# cvc co httpd=oot.rpath.org@oot:devtest bash# cd httpd Now I'm going to erase the files we don't need anymore. We're going change httpd.conf and the recipe, so those can stay. bash# cvc remove index.html Makefile.ssl modssl-req.conf httpd.init.patch Go ahead and edit httpd.conf. Make whatever changes you like; I'm just changing a comment at the top to prove I did something. The recipe needs to be modified as well since it's not building from source anymore. It's now a DerivedPackageRecipe which does nothing but install a new httpd.conf. class Httpd(DerivedPackageRecipe): name = 'httpd' version = '2.0.55' def setup(r): r.addSource('httpd.conf', macros=True) r.Install('httpd.conf', '%(sysconfdir)s/httpd/conf/') Most of the magic here is in the changed class of the package; making it a DerivedPackageRecipe tells conary to look for the latest httpd 2.0.55 on the parent branch of this shadow. The rest of this (all two lines) add httpd.conf as a source file and then installs it into the derived package. Committing and cooking this as normal gives an httpd package with our new config file. If you're curious, here are some links: Source Package Modified recipe Built httpd trove Modified httpd.conf (look at the top of the file to see the change) So, two lines to change the config files. A little bit easier than rebuilding the entire package from source. A nice feature of this is file versions make it easy to see what files have changed: bash# conary rq httpd:runtime=oot.rpath.org@oot:devtest --file-versions --full-versions /etc/httpd/conf/httpd.conf /conary.rpath.com@rpl:devel//1//oot.rpath.org@oot:devtest/2.0.55-7.0.1-1 /etc/httpd/conf/magic /conary.rpath.com@rpl:devel/2.0.54-2-2 (Yeah, I snipped that output a bit) You can see from this that httpd.conf is a local modification while the magic file is inherited from upstream (unfortunately there is a bit of a problem in how file versions are calculated for files which multiple flavors on a shared path which makes this less impressive; Mihai is fixing!). Merging to a new upstream version is pretty easy with this model. Since the recipe is completely new, there is no patch merging that needs to be done. Instead, conary just updates the version to reflect the new version we're deriving from. bash# cvc merge bash# cvc diff (working version) Mon Jan 15 14:00:39 2007 (no log message) httpd.recipe: changed Index: httpd.recipe ==================================================================== contents(sha1) inode(mtime) --- httpd.recipe /conary.rpath.com@rpl:devel//1//oot.rpath.org@oot:devtest/2.0.55-7.0.1 +++ httpd.recipe @NEW@ @@ -1,6 +1,6 @@ class Httpd(DerivedPackageRecipe): name = 'httpd' - version = '2.0.55' + version = '2.0.59' def setup(r): r.addSource('httpd.conf', macros=True) Commit, cook, and you have rPath's new httpd package with your configuration changes. Right now the actions and policy objects which derived packages support are a bit limited. You can create new component (but not packages), move files between components, remove, install, and patch files in the build root, change file requirements, and a few other things. That list will certainly grow in the future though! (1 Comment |Comment on this)
Tuesday, January 2nd, 2007
11:20 am	Conary Journaling First off, happy new year to everyone. 2006 was certainly a momentous year for me both personally and professionally, with a new baby arriving at home and momentum starting to build for rPath. I hope everyone reading this had a good 2006 and has a great 2007 lined up. Right before the Christmas holiday (literally; at about 3:30 the Friday before Christmas) I committed a set of journaling patches to Conary. While this sounds boring, it's actually really important. Conary, just like every other packaging system out there, has to deal with Unix filesystems lacking any atomic operations which work on multiple files simultaneously. What this means is that if you're halfway through a updating a package and the user's doberman trips over the power cord and shuts off the machine, some of the files in that package will have been updated and some will not have been. As for the database, whether it reflects the new package or the old one isn't really important; either way it doesn't reflect what's on the filesystem. Without vastly different atomic properties in the filesystem, this isn't all that easy to fix. On standard servers, this is not normally that big of a deal (a sysadmin just logs in, redoes the operation which he was in the middle of, and life goes on). For an appliance, however, it could be a much bigger problem. These types of catastrophic failures leave depenendeny problems (so conary might not run any more!) as well as internal inconsistencies (a half conary 1.0.31/half conary 1.1.12 system simply won't work). In short, there are open windows for unrecoverable package installation inconsistencies. Unrecoverable is never a nice word. A while ago, msw, dugan, and I were tossing around some ideas on how to fix this. We realized that a basic journal would help a lot, where only invertible operations were performed and those operations were recorded in the journal. If something failed unexpectedly (out of disk space, etc) we'd roll back the journal and the filesytem would return to normal. If a catastrophic failure occured, the journal would be left on the system and conary would know not only that something went awry, but how to fix it. While I was out sick with something-or-other, I started working on this. It actually went pretty quickly, with most of the work done in less than a day and another day being spent on test cases. The result is you can kill -9 Conary at a random point in the update, run conary revert (which conary will tell you to do), and your filesystem will be put back however it was. How cool is that? (Comment on this)
Tuesday, December 12th, 2006
6:12 pm	Extreme Flextime BusinessWeek has a great article this week on how Best Buy is changing it's internal culture to move away from a traditional workday to flextime on steroids. They're calling it ROWE, or Results Only Work Environment. The basic idea is as long as you can measure what's people are accomplishing, where and when they accomplish it doesn't matter. So far, they're seeing good productivity growth, a great increase in retention, and enormous increases in job satisfaction. A pretty good set! I've never been a hard-nosed boss when it comes to schedules and vacations, but I admit that I haven't gone nearly as far as ROWE. I think a big reason for it is I've found it hard to measure performance and productivity for developers, so face-time has meant something to me. Reading this recent article has me thinking more about about how rPath could measure developers to give them more choices in how they divide up their lives. I spent the afternoon with my four year old today (my excuse is a much-needed recovery from the return trip from Shanghai) and realized that I'd trade some afternoon time at work for more evening time at work, and I'd welcome others to do it, if I was convinced all of our goals would be met as well as (or better than!) they are now. I think our JIRA deployment will be the lynch pin of any of our efforts, since it has the basic tools for letting us quantify performance. (Comment on this)
Saturday, December 9th, 2006
5:33 am	Shanghai Monday morning I left Raleigh; a mere 24 hours after taking off I landed in Shanghai (okay, so maybe it was a bit more). That made it around 7:00 Tuesday night. Xiaowen was waiting for me at the airport, and she got me to a hotel and we had dinner. Four days later I'm sitting on the 37th floor of my hotel in Pudong (the new business district on the eastern side of the river from "classic" Shanghai), and while I miss my family terribly, I've had a great time. First, I have to say that all of the people I've interacted with have been great. While the English hasn't always been top notch, it's been consistently better than my Chinese! If weren't for the nearly constant escort I'd probably still be sitting at the airport looking for something to eat! Instead, I've had huge meals (which I'm sure I'll regret in a few days) and seen at least a little bit of the city. The highlight was today's trip to see the Shanghai Acrobats. It was a Cirque du Soleil style show; less theatrical but probably a little more impressive physically (I'm not entirely sure how to really judge that though). It was really amazing to watch the performance. If you're ever in Shanghai, I strongly recommend it. Buy tickets ahead of time though; I waited until the last minute and was fortunate that someone was trying to return a single ticket when Xiaowen went to buy ours. She graciously bought the ticket for me, helped me get to the show, and gave me her cell phone in case I got hopelessly lost on the way back. Someone I managed (following the flood of people turned out to be a good plan!) and now consider myself a veteran of the city. I'm here one more day, and while I'm looking forward to going home I sure hope to come back to Shanghai. Thanks to Xiaowen and the rest of my hosts (who, unfortunately, I can't really mention without breaking an NDA) for helping me enjoy my week here. (Comment on this)
Tuesday, December 5th, 2006
7:58 pm	Email clients, rMake, and blog notice Last week I did my biannual review of email clients looking for something to replace pine. Everything I look at seems to be harder to use, slower, or not much better than the client I've ben using since 1992. After getting annoyed at something pine did, I stated looking around to see if anything had changed. The first stop was mutt. Frankly, it can probably do everything I need if I spend enough time learning to configure it. After playing with it a while though, I didn't find anything it did that I hadn't already configured pine for. There just didn't seem to be enough bang to bother. The other mail client I spent some time with was sylpheed. I'd used sylpheed for a few months back in 2002 and generally liked it; I don't really remember why I stopped using it. It is easy to configure for multiple mailboxes, handles imap over ssh nicely, will use the mailbox layout I want, has an offline mode, uses gtkhtml for reasonable html mail rendering, and seems fast. While I was playing with sylpheed-claws, a feature-rich fork of the main branch, I decided to build the latest version (mostly to get the gtkhtml plug in working). Updating the recipe was easy; that took all of two minutes. The bigger questions was, how to build the recipe for contrib? You have to understand something here -- I'm incredibly lazy with my home system. I almost never update it, so it's running an *ancient* version of rPath Linux (so old it was called Specifix Linux). It's had updates applied here and there, but it's mostly on conary.rpath.com@rpl:devel and is a real hodgepodge; not the ideal system to build packages for contrib! Enter rMake, an rPath project I hadn't actually used. It works on top of Conary, and provides clean builds in a carefully constructed chroot. Needless to say, I didn't expect it to work on the out of date system I had to tru it on. I can't being to tell you how surprised I was to see "conary update rmake; rmake build sylpheed.recipe" just work. It literally just worked. A full chroot environment was installed, sylpheed was built, I could instlall the test build easily, and commit it when I was done. Dugan is really doing a fantastic job with rMake; if you haven't tried it yet, you should. As for my email client? I do have sylpheed-claws installed, and it works fine. I still seem to be using pine most of the time though; old habits die hard. On a completely unrelated note, one of the things which I find hard about finding the time to blog is the feeling that I'm talking to myself. Of course, this is a chicken and egg thing as who bothers to read a blog which is mostly quiescent? In any case, it's nice to be noticed once in a while! (2 Comments |Comment on this)
Thursday, October 26th, 2006
7:04 pm	Of Oracle and Linux I just can't resist adding my voice to the cacophony surrounding Oracle's announcement of enterprise support for a Red Hat compatible Linux distribution. My take is a little different then what's being written. I don't disagree with many of the comments which are coming out, but I do think they miss the big picture a bit. I think there is a bigger message in all of this than Oracle being annoyed that Red Hat bought JBoss. Like it or not, Oracle's application server has hardly been a resounding success in the marketplace (two minutes on google dug up a resounding 2.4% market share in 2005); it just doesn't make sense for Oracle to alienate a partner over a product which competes with such an insignificant portion of their revenue stream. This could be a warning shot to Red Hat not to buy a database business like MySQL (which Red Had is an investor in). This is certainly possible, and I don't doubt that the powers that be at Oracle would hate to see such a matchup, but this move likely made such a pair up more likely since Red Hat has very little to lose now. After all, what's Oracle going to do about it now, enter the Linux business? So what is the answer? Well, I haven't been receiving fat consultation dollars from anyone in California, so this is just a guess, but I think Oracle doesn't feel like they can compete with Microsoft without having full control over their stack. Now, I'm hardly alone in thinking this; this was such a popular idea over the last few months I'm a bit shocked that this idea got lost in all of the "Oracle to Kill Red Hat" sensationalism. Let's spend a little time in Oracle's shoes. Think about who you worry about competing with. Red Hat who has never taken a dime in revenue from you and you've built a pretty good partnership with? Probably not. How about Microsoft, who has the number two SQL server in the world, and full control over the world's most popular development and deployment environments and could probably buy you if they tried hard enough? Right, probably Microsoft. Microsoft keeps entering markets which are important to Oracle. How is Oracle supposed to compete with them for developers and installations? All of a sudden having a full solution stack starts to look pretty important. Not just to run Oracle apps (which a software appliance product would address, but to give Oracle sales reps the ability compete product for product with Microsoft in the enterprise. Partnering with Red Hat gave them some of that, but this is a clash of the Titan's and Red Hat just isn't in that league. Besides, who would trust a third part with something so strategic to their future? So Oracle was left with a buy versus build decision. You can argue all you want about which would have been better, why they chose to build, and so on. Once they did decide to build though, I can't imagine Larry Ellion's competitive juices allowing the goal be anything but the number one position in the enterprise Linux market. How often do we see Oracle play for second? Finally, what does this mean for everyone else in the software industry? To me, this highlights that building products on somebody else's stack leaves you vulnerable. Oracle products running on Microsoft left them vulnerable to SQL Server (and now Microsoft Dynamics). This logic applies to every other ISV; trusting someone else's platform just opens the door for them to compete with you. Does anyone think BEA is excited about running on Red Hat Enterprise Linux now that Red Hat competes with them using JBoss? Who wants to sell a directory server on Suse Linux Enterprise Server knowing that Novell has Novell Directory Services right behind it? Like it or not, controlling the full stack provides a stronger competitive position then trusting someone else's platform. Linux is the perfect system software component of an ISVs stack. It's robust, well maintained, and has a license which means that it can never be taken away from you. Nobody can hold an ever-increasing royalty rate over an ISVs head backed by the threat of taking away a core piece of their solution. Linux is Open Source, which lets people use it and breathe easily. I think Oracle's announcement yesterday was another step towards software vendors taking control over their solutions. (Comment on this)
Tuesday, August 29th, 2006
1:21 pm	Good month It's been a good month for us here at rPath. We won an award for grid computing at LinuxWorld. While that might seem a bit different from how you think of our stuff, it actually matches up nicely with some work we're doing with the Department of Energy. We also announced a couple of customers. Just today, we've gotten great press in a couple of places, with Network World calling rPath us one of the top ten open source companies to watch and eWeek having some nice things to say about us as well. Finally, Desktop Linux mentioned the eWeek article and added some kind words of their own! It's nice to be noticed. The next version of Conary will handle files moving between troves properly. This turned out to be a big deal, as troves are being built in distros independently of where they were derived from, breaking updates. Conary now detects that case and handles to transparently thanks to work Dave and I did over the last couple of weeks (he works fast, I work slow). (Comment on this)