Below are the 10 most recent journal entries recorded in rh_web_guy's LiveJournal:

Saturday, November 4th, 2006
1:20 am	Nobody's going to buy Red Hat Usual disclaimers apply: I speak for myself and not Red Hat, don't know anything special about Red Hat's acquisition opportunities, and won't reveal anything here that anyone couldn't find out by paying attention to public information. I'm sick of hearing the speculation, so let's just put it to rest right now. None of the current players in the market are going to acquire Red Hat. Not Oracle. Not Microsoft. Not Sun. Not IBM. Not even Google. Why not? It's a simple matter of motivation. Why would a company buy Red Hat? I can only think of two motivations: 1) To acquire our assets, or 2) To kill us. Red Hat is in a position unfamiliar to most of the tech industry, in that very few of the products we offer actually belong to us. Especially our flagship, Linux. Everyone in the world already can benefit from those for free, so they're not an asset. I think this is why most of the pundits don't "get it." The main assets of the company are its people and its brand. And those are exactly the assets that would be lost in a buyout by any company that has the ability to make a bid. The people that make Red Hat an exceptional company -- the proponents of and contributors to free software -- are exactly the ones who would be out the door the moment one of the proprietary dinosaurs gobbled us up. And the Red Hat brand would immediately drop in value as soon as it was associated with one of these dinosaurs. Red Hat is worthless to those with the ability to buy it. The only company I can conceive of acquiring Red Hat without devaluing it is Google. And I don't really see their motivation either. They already have plenty of Linux expertise and already benefit (like everyone else) from the work Red Hat does on Linux. They're making tons of money from their core competency, search. What would they gain by getting into our business? So unless someone with a heck of a lot of money is feeling foolish and capricious, I think it highly unlikely Red Hat will be bought for the purpose of augmenting another business. Now, what about buying Red Hat to kill it? Leaving aside antitrust issues, this would be a costly and futile exercise. This is the flip side of not owning our own tech. Kill Red Hat, and anyone can pick up where we left off. The very same people could form a new company, use their funds from the buyout to lease some hardware and office space, and be back in business with the same software. All the buyout has done is spent a lot of money, created a lot of ill will, and temporarily slowed the business adoption of Linux. It would be at most a small blow to free software itself. Again, I cannot see anyone rational blowing this kind of money for so little return. Now let's drop the wild speculation and get back to the business of making and supporting great free software. (6 Comments |Comment on this)
Monday, April 10th, 2006
1:30 am	Dipping my toe in Xen I got around to trying Xen this weekend. OK, I'm probably the last geek at Red Hat to give it a go, but I bet I'm still the first in my neighborhood :-) My oldest server died recently (looks like motherboard issues... the thing is ancient) and my normal desktop is full of stuff I need to archive properly so I don't want to touch it. My newest server is sitting there basically idle, waiting for me to get swinging on my long-delayed big project. That left me with only an old laptop for a development box, and it is sort of laughable for that purpose (besides, its wireless card is quirky). So I thought -- hey, I haven't really done much with my server yet, and it's got plenty of space and RAM sitting there unused... why not upgrade to Fedora Core 5 and try out Xen to make myself some virtual dev boxes? Well, everything went pretty smoothly. The directions on the wiki for creating VMs are pretty straightforward, at least if you've done a kickstart before. I've actually never tried a graphical install over VNC before so that was pretty cool. This is definitely not vmware-console -- you get a laughable python script to kick off the VM creation, and then only a command line console for direct access to the VM. Yes, I realize you can VNC to it, at least if the VM has a network connection, but that's not quite the same. I don't really care, though, as I'm just looking for lightweight servers and I'm used to doing all my work with ssh, screen, and vim. But there's something to be said for a nice GUI to manage all your VMs. In any case, I found Xen very easy to work with and I can't tell that the servers are VMs rather than actual boxes. With VMWare I've always noticed the VM system clock runs laughably slow (worse than 10:1 -- possibly operator error?), so this is a nice change. I'll have to see what happens when I put some load on these things. Then I need to archive and upgrade my desktop so I can fiddle with transferring the VMs between machines. And I'd kind of like to understand the bizarre network interfaces being created! I'm very psyched about this coming out in RHEL 5 -- I can see why virtualization is going to be a big deal. Beyond the "that's cool!" factor, you can basically turn cheap stuff like RAM and disk space into a fluctuating herd of machines that can be created, moved, snapshotted, rolled back, or banished all without leaving your cushy seat. Sweet. (Comment on this)
Sunday, December 11th, 2005
9:35 am	Misdirection in journalism I came upon this article on open source: In open source, an unexpected trap As open-source software spreads to personal computers, servers and Internet networking equipment around the world, so too is the misuse of the rules governing the software - a product that is commonly but often mistakenly thought to be free and unprotected. Did you pick up on what this article is about? That opening paragraph certainly left me scratching my head. The article is actually about how companies are violating the GPL by incorporating GPL'ed code without releasing the source -- whether deliberately or through failure to understand or account for the GPL's conditions. I'm not sure whether this journalist is crafty or just incompetent. This is violation (not "misuse") of the rules, and they don't govern the software, they govern software developers. Just saying "software license" would have made this summary a whole lot clearer. Open source software is not a "product" in the sense of typical software, and it is indeed free, though not "unprotected" (by a license, he means, though that's not obvious on a first reading). What have we heard so far? It's an Admiral Akbar moment. Someone is "misusing" the rules to lay a "trap" in open source software, which everyone thought was free and "unprotected". CEOs, run for your lives! Open source is a trap! The main point of the GPL is that it is viral, meaning you can't incorporate GPL'ed source code without the end result being GPL'ed as well. Calling this a "trap" is misleading; the word implies some kind of deception, a hidden snare that draws someone in unawares for nefarious purposes, when in fact the provisions of the GPL are as much in plain view as they could conceivably be. The GPL is almost certainly a better-known license than any other software EULA in the world. If we're expected to read and abide by the shrink-wrap licenses on every piece of software we purchase, is it too much to ask the creators of that software to be aware when they're using GPL'ed software and abide by its provisions? Typically notice of the GPL license is stamped into the header of every source file it covers, and the license (along with exposition on its implications) is easy to find on the internet. The GPL's agenda is as clear and public as it could possibly be. A company "accidentally" violating the GPL has not been "trapped" -- they are hypocrites, clear and simple. To depart from the main point of this post, why is it that journalists constantly feel a need to use bad metaphors for "source code"? While it is true that the software's source code - its binary DNA, so to speak [...] First of all, anyone who is interested in this issue either already knows what source code is, or doesn't care. The rare exception either will never get it or can look it up on Google. There's no need to confuse the issue. "Binary DNA" -- what in the world is that? I'm not even going to hazard a guess. The closest metaphor I've heard for source code is "blueprint", but even that is pretty far off -- you use a blueprint as instructions to make a physical object, but software is not a physical object. The source code itself might be the software (with interpreted languages) or be directly translated into the software, but in either case, once the source code is written, the software is complete. There isn't a single other technology that is anything like this, and I don't think there's a better phrase to describe source code than "source code", even for someone who's never heard of it. This journalist's bad metaphor just tells me I can safely discount any technological content he produces. (Comment on this)
Thursday, September 15th, 2005
12:29 am	Adventures with system administration At last, my new server is working. First I found that the motherboard I'd put in it had a long Linux rap sheet (as well as some complaints under Windows); I really must learn to research these things before building a system! I'm not a hardware guy, so rather than spend a lot of time tweaking a questionable setup, I put in a different board (this time after due diligence). But this setup was even worse -- I tried installing five different OSes and all of them hung at varying stages; so figuring it must be a hardware problem, I tried selectively removing RAM, and suddenly all was well. Now I wonder if the original board might have worked out after all. I have 4x160GB disks in this box. Originally I set these up in a software RAID 5 array (with one spare for paranoia) which gave me a 300GB device to work with. But this took a long time to create, and when I tried removing a drive, rebuilding parity took about two hours, on an otherwise idle system. So I thought, why not just create the size volume I need now and use LVM to partition it out? With a 30GB RAID device it would only take a tenth the time to rebuild, and I can always create more as I need them and add them in with LVM. Does anyone think this is a stupid idea? The LVM Howto advises against having multiple physical volumes on the same drive, but the only performance problem it mentions would be if I were striping the logical volumes. I'm not doing that (RAID should handle striping) so I don't see that it applies. But I could be silly for even bothering to avoid a long rebuild. Come to think of it, rebuilding a bunch of devices in parallel on the same drive would probably be really slow. Unless the partitions were all actually on separate platters... hmm... maybe I should not get out of my depth here :-) (Comment on this)
Wednesday, August 31st, 2005
11:15 am	Website annoyances What is with websites that restrict the length of your password to, say, fewer than 10 characters? I mean, I understand having a minimum length, because that's for your own good. I even understand the ones that make you include numbers or symbols, though it seems like overkill for most websites (and upsets my lame password scheme for such sites). Forcing your users to have non-dictionary passwords is annoying but at least it cuts down on complaints about accounts being stolen. But, restricting password length? That's just pathetic. The only reason I could think of for doing that is if the site is actually storing the password in the database, and has a stupid limit like 10 characters on the column. That's just wrong on so many levels. Mainly, because sites shouldn't be storing the password at all; they should hash the password (with MD5, SHA, etc) and store the hash only. Then the password can be any length, and the hash is fixed-length so it's easy to figure out what size to make the database column. For a little extra security, since there are already hash dictionaries for common passwords, hash the password along with the account number or some other unchanging piece of data, so when hackers (or disgruntled employees) break into the site and steal the user database, they'll have to work that much harder to figure out what the passwords were. Protecting site users like this isn't much extra work, and should be common courtesy. Password hashing has been around since at least the 70's; there's no excuse in 2005 for building a site that doesn't do this. So remember kids, if the site restricts your password to 10 letters, it's probably storing it in cleartext where anyone with database access can see it. And if the site designers were that short-sighted, don't expect security or good design in any other aspect of the site. Also, what about asking for a 16-digit account number and not allowing spaces and dashes? This is such bad usability -- makes it harder to check for typos -- and it's completely unnecessary. It's trivial to just filter the field when it comes into the server. It's a one-liner in Perl: #filter out anything that's not a number $credit_card_number =~ s/\D//g; Dead easy; and then the user can enter anything in there that would help them get the number right. You'll never find stupid restrictions like "No dashes or spaces, please" on any site I've written. I suspect some sites do this so they can validate the entry with Javascript before the browser submits it. But why bother? It just has to be re-validated on the server anyway, in case the user disabled Javascript or is really a bot or whatever. Javascript should do no more than check that the user put something in there, and let the real check happen server-side. That also makes it unneccessary to split the number entry field into several little entry boxes. The most annoying form of this is when Javascript "helpfully" moves your cursor for you when you're done typing each part of the number. Look, I know how to use the tab key, and if I'm typing the number, I'm probably looking at the number, not paying attention to where my cursor is being magically transported. I hate having to backtrack and re-enter part of the number in the right field after tabbing past it. Again, not a design you'll ever find on one of my applications. (1 Comment |Comment on this)
Thursday, August 25th, 2005
3:49 pm	First CPAN module I have officially uploaded my first CPAN module! Someone please hand me the sword +8 of w00tness! Be sure to check it out for esoterica about object encapsulation and serialization in Perl :-) For some reason this is inordinately exciting to me. It's the first piece of code I've ever published publicly, so I guess it's a little like seeing your first short story in print :-) I thought to run some stats on the code: $ wc Storable.pm.* 01.cloning.t 107 347 3586 Storable.pm.code 36 212 1458 Storable.pm.com 262 1545 10363 Storable.pm.doc 147 485 4449 01.cloning.t 552 2589 19856 total So yeah, about 100 lines of actual code, about 450 lines of comments, documentation, and test cases. Seems about right. Next project already cut out for me: fix Class::Std itself so that classes can be created correctly at runtime and even reloaded. (2 Comments |Comment on this)
Thursday, June 2nd, 2005
9:20 am	szulik sings gospel I thought this was hysterical. One of the details mentioned in this article about the Red Hat Summit -- our CEO got up with a gospel choir and sang "Change in my life." One thing you have to say for Matthew, he's always human. He'll do something goofy just because it's fun. Sure it was a gimmick, but it wasn't planned out painstakingly balancing all PR aspects. I'm sure it was just something he thought would be fun to do. Now, if someone would just post the video in a non-windows format! Oh wait, that should be us, right? Well, we can't post content we don't get :-( (Comment on this)
Thursday, May 26th, 2005
11:30 am	Filling that primary key field One of the things you need to do universally with databases also has no standard implementation among the various products: inserting a new row with a unique ID. The problem, of course, is guaranteeing that your ID really is unique without having to lock out any other database accessors that might want to do the same thing at the same time. I used to work with MySQL as my primary database. MySQL's solution to this problem is pretty simple: you specify that the primary key column is "auto-increment" and then you insert new rows without specifying that column and MySQL automatically fills in the column with an incrementing counter. There's a special variable you can select in order to find out what ID was assigned to the row you just inserted -- or with Perl and DBI, I believe it's a property associated with the database handle so you don't even need to select it. That's pretty handy. Now that I'm in the Oracle world, however, things are done differently. There is no auto-increment column with implicit counter -- you have to provide the ID yourself. However, Oracle supplies a database object type called a sequence which can be used for the same basic function -- to provide incrementing, unique IDs without locking. To accomplish the same thing as MySQL, you select a new ID from the sequence, and then insert your new row with that ID specified. So it's a two-step process instead of a single insert. Unfortunately, I've been working on some legacy code which clearly had the MySQL mindset. In a way, it's understandable; having to do those two steps seems like extra work, and unnecessary work if you don't need to know what the ID you inserted was. So in order to get the MySQL effect, the authors created a trigger on the table which at insert time selects the latest value from the sequence and fills it in. Let me detail why I think this was an incredibly bad idea. First of all, there is no reliable way to find out what ID you just inserted, unless you lock the whole table before doing this, which would be absurd. Now, when you start down this path, maybe you didn't need the ID. But what if you later decide you need the ID? You can't get it. I have actually run across a place where the author has followed this method and then used some nasty hack to find the row -- fortunately it worked "well enough" but it was far from bulletproof. Worse, if you decide you want to start doing the insertion in the two-step fashion, you can't, because the trigger will overwrite the ID you explicitly insert. You have to drop or disable the trigger if you want to change methods. It doesn't follow the Oracle paradigm, so it's confusing to someone who reads your code and wonders how the ID is getting in there. Having to look through schema to figure out how something works is no fun. I avoid triggers in general for this reason. Finally, chances are you ended up writing more code anyway. Often you only insert into a table in one place in your code (especially if you're using good OO design). You've traded a quick select in your app code for a full trigger in your schema -- seems like a bad deal to me. If you really don't care about getting the ID back and you want to do the insert in one step, it's easy just to incorporate the select from the sequence into the insert statement, like so: insert into my_table ( primary_column, column2, column3, ... ) values ( my_sequence.nextval, ?, ?, ... ) This should be easy to do even if you're building the statement dynamically (which I pretty much always do). And if you later decide you wanted to know the ID you just inserted after all, it's easy to separate this code into two steps. While it might seem like a little more work to make the ID column explicit with a sequence, it also allows a lot more flexibility. For instance, you could use a sequence to provide unique IDs for multiple tables, not just one. You can also set up the sequence to increment to your specifications -- for instance, I have set up sequences that increment by 13 or some other "off" number, so that if someone needs to type in the number, their chances of getting a false hit on a typo are slim. Also, because you know the ID beforehand, you can easily insert complex cross-referencing data. If you tried to insert into two tables that cross-reference each other in MySQL, you would have to do one insert, get the ID, do the second insert referencing the first ID, get the second ID, and then update the first insert to reference the second ID. Ick. All of which is to say, embrace the Oracle way if it's available to you. It's a good thing. (4 Comments |Comment on this)
Thursday, May 19th, 2005
11:22 am	Plenty of work Our web engineer position is now open. If you are web-programming-clued, go and apply. There's always plenty of work around here. Today, I'm trying to drag our web forms into the 21st century. Ever tried to read a bunch of whitepapers on redhat.com? You have to keep filling out forms. Well, we've heard the complaints, and now I finally have time to do something about it. You'll have to fill out a form once, but after that you shouldn't need to. Seems obvious, no? But as with so much else, there are complications. Anyway, that should be out in a few weeks. If we're lucky, I might have single sign-on with RHN working at that point too -- though, the RHN guys may be too busy working on their next release to complete that circle just yet. (Comment on this)
Thursday, May 5th, 2005
2:39 pm	A day like many other days. I have a little down time since we just finished a release on Tuesday and most of the issues have shaken themselves out. Thought I'd go ahead and create this little blog to journal the kind of stuff I'm working on. Still getting problem reports from the dang web forms, as well as one product subscription that has managed to confuse my code somehow. Still the mysterious early morning failures of order syncs. But otherwise, things seem pretty quiet. Major items for the next release will probably include major webform fixes, laying the groundwork for the next generation of web store and subscription management, and maybe getting single sign-on with RHN to work in the other direction. Maybe I'll finally figure out what causes the sporadic Academy breakage -- I think I've got it narrowed down now. I should probably also spend some time writing howtos on working on the website. With any luck we'll have a few more engineers working here in the next few months. Any power Perl/Java website hackers looking for a job at Red Hat? We need you! :-) (Comment on this)