Archive for March, 2010

Intel/AMD CPU catchup

Sunday, March 28th, 2010

So I decided roughly a decade too late that the POWER/PowerPC/SPARC RISC fanboy in me probably needed to (reluctantly) accept that x86 won the war, which means I’ve been brushing up on my x86-64 assembler (by poking in head_*.S, which is correctly written in AT&T syntax, and not that other syntax I shall not name) and trying to catch up on what the heck Intel and AMD are working on in terms of roadmaps, etc. I now know how REX prefixes work on “Intel 64″, for example. And I’ve read the recent changes to the ABI (Fortran support included!). I shall poke at the recent SVM/nested page tables stuff sometime for fun. Oh, and I don’t care that I’m not an IA32 assembly guru, I shall focus on flat 86-64 and forget about last century’s segmentation and other ye olde bank switching inspired hacks.

This weekend, I’ve gone over all of the recent models and public announcements, read some IDF bits, and learned about Intel’s QPI (as opposed to the one I knew, AMD HT – QPI is basically trying to throw off the FSB, but it does some nice failover things HT does not include AFAIK). I’ve concluded that the model numbers used by these guys these days are way, way too confusing. Even more so than when I last really cared about this stuff – determining which “Xeon” has Intel-VT or AMD-V is a game of looking up lots of 4 digit model numbers where a simple naming formula somehow including reference to the microarchitecture used in the model “name” would suffice to convey far more useful information). But, none of this stuff is your grandfather’s x86. It’s every bit as capable (in x86-64 anyway) of taking on the other Big Endian arches I have always personally preferred.

I expect to do a lot more to keep up with x86 development rather than letting my own personal academic fondness for cleaner ISAs limit my exposure. I’m thinking about getting another older Xeon build/test box for playing with x86 stuff and for speeding up kernel compiles at home – perhals a used Dell PE1950 or Precision 490 as these have the best bang for buck ratio at the moment. What I would like to know, from anyone who bothered to read this far, is where should I be going to get the very latest information on x86 developments? I’m on the k.o lists, and I am specifically not a game playing weenie who cares about that stuff – I want to know about roadmaps, things like the new AES extensions, etc. I don’t care that the “whizzbang X1234 blah blah would look uber l33t in this plexiglass case I just bought on eBay”.


On Fedora updates

Sunday, March 14th, 2010

There’s been a lot of talk recently about Fedora’s policy (or lack thereof) for shipping updates to existing stable releases. Rather than keep repeating the same points on the mailing lists ad nauseam, let me give my own $0.02 here. Keep in mind that these are my own personal opinions, and nobody else’s.

First off, I know in using Fedora that I am not using an “Enterprise” distribution that is intended to remain rock solid and stable for a long time without substantive changes. I’m ok with having to upgrade every 6 or 12 months, and I’m willing to deal with fixing breakage when that happens (though obviously in a perfect world the upgrade would be entirely seemless). What I am not ok with is updates shipping that cause any breakage or behavioral changes to my perfectly working system when I have not asked to perform a major upgrade. I expect that, if I upgrade my laptop system ten minutes before a meeting, then it will still work exactly as it did before. I don’t want to have to delay doing any updates – as I do now – for fear of the result.

Since time doesn’t stand still following a release, and bugs and regressions are found – and security issues are raised – a flow of updates to a “stable” release is both necessary and healthy to any distribution. But updates should be just that: updates. And also “necessary”. To me, an “update” is not shipping a major version bump on an existing piece of software, or replacing an entire stack (complete with all manner of behavioral changes – no matter how “small”: it does matter if that menu item moves around mid-release) – after the release. That’s called a new release. Or rawhide. Or whatever. The point is that a release has to have some kind of meaning for it to even be worth having a release. Otherwise, you may as well just call it “Forever Rawhide”.

Now I’m not saying there can’t be flexibility. For example, I don’t personally care at all about KDE update frequency. I’m sure the people who work on it (many of whom I have met over the years) are very nice people, and I know they do good work. But I don’t use KDE (other than a few specific pieces of software, such as k3b), and I haven’t for years. So if KDE is updated ten times a day, I’m not going to even notice. I’d rather, for the sake of the users have a consistent policy, but perhaps that stack could be excluded since its maintainers are quite vocal about being able to make a lot of updates. I would rather an exemption were made for their specific stack rather than have the rest of the distribution need to following the same rolling update trend.

What I am going to notice, however, is if any of the critical path components that I rely upon is broken, has a behavioral change, or is needlessly updated way too often to make any real sense. Needless includes pulling in some minor upstream bits that aren’t materially warrented by actual or likely bug reports. Those things are best done in rawhide where they belong, and where those who are more than willing to test as they go will happily help shake out issues. I myself run rawhide also, but on dedicated real or virtual machines that are only for testing and not intended to be used or relied upon for daily work. Even in the case of rawhide, I think things should be at least reasonably tested on a standalone system (more than just compile tested) before pushing if they stand a chance of breaking something fundamental in the distribution.

Think about it this way. The Fedora development cycle is about 6 months. If you are a user and really, badly need some major new feature, you might have to wait an average of 3 months. Even if that’s hardware enablement that makes the distribution otherwise inaccesible to you, I would rather that you have to wait 3 months for the new version (during which time you are free to try the pre-releases, alphas, betas, etc.) than ship an intrusive update that may negatively affect other users who already have working systems that can already make full use of what they have available. It’s simply not worth inconveniencing existing users of a stable release for the possible benefit of those who are not already using it and can wait until the next time.

Anyway. I think Fedora needs an update policy, and it needs a strong one. If you know me, you know I am far from a conservative guy, but I do think that stable Fedora updates should have a fairly conservative update policy for at least all critical path components. Those should never be updated unless necessary to fix specific bugs, and only in a fashion not likely to cause regressions for other users not affected by those bugs, or who rely upon specific behavior not to change (i.e. not a whole major version bump). The components not in the critical path can have more wiggle room if necessary, but I would still like to see far fewer updates in the stable releases.