Random MacBook Pro notes

Some things I have had in my mind for a while but for which I'm lazy to post full-blown posts:

• Updated the internal Hitachi 160GB 5400RPM drive to a Seagate Momentus 7200.2. There is a lot of people who say that the difference between 5400RPM and 7200RPM is negligible in laptop disks. Screw that. For daily tasks (browse the network, read your mail, etc.) it may not be too noticeable, but for disk intensive operations it really is.
  
  Some numbers: Half-Life 2 now takes 20 seconds less (from a total of 1'50") to start. A NetBSD build.sh sets now takes 1'52" compared to the 4'15" it took before. A NetBSD build.sh release with already-built sources (i.e. a release build that does no CPU-intensive operations) has been cut down to half the total time: 11'53" now as opposed to the old 23'10". And I didn't "benchmark" iPhoto, but it surely starts up much faster now. Quite a bit of a difference I say!
  
  
• The video card, an ATI Radeon Mobility X1600 128MB, is starting to show its limits. Been trying some game demos and they are barely playable at the native resolution, 1440x900, which is the lowest I have found at the 16:10 aspect ratio. I refuse to play with an aspect ratio that does not match the physical screen...
  
  BioShock is usable but with game detail set to a minimum, and even then some scenarios feel slow. I feel that this game should look gorgeous with high detail settings. F.E.A.R. is certainly playable (finished it) but with details set to a relatively low level. Lost Planet: Extreme Conditions is simply unusable.
  
  
• Silent computing... well, the machine is truly silent when doing light operations, but I hate doing heavyweight tasks on it such as building NetBSD, encoding video or playing games. Not because it is slow, but because the fans spin up to their maximum speed (around 6000RPM) and they make a damn lot of noise. Maybe this noise would not be that noticeable on a desktop computer, but as we are talking of a laptop, we are very close to the fans during usage.
  
  
• Been using the external Apple USB keyboard I have (not the new flat model, which by the way looks cool) with the laptop for a while. That keyboard is crap after some months of usage. It does not feel smooth to the touch any more. The MacBook Pro's built-in keyboard is much, much better.
  
  
• /me considering a Mac Pro in the not-so-distant future.
  

SoC: Second preview of NetBSD with ATF

Reposting from the original ATF news entry:

I have just updated the first preview of NetBSD-current release builds with ATF merged in to match the ATF 0.1 release published today. As already stated in the old news item: These will ease testing to the casual user who is interested in this project because he will not need to mess with patches to the NetBSD source tree nor rebuild a full release, which is a delicate and slow process. For the best experience, these releases are meant to be installed from scratch even though you can also do an upgrade of a current installation. They will give you a preview of how a NetBSD installation will look like once ATF is imported into it; we are not sure when that will happen, though.

By the way, ATF 0.1 is also in pkgsrc as devel/atf. This may be an easier way for you to try it, even though you will not get the NetBSD-specific tests.

For more details see my post to the NetBSD's current-users mailing list.

Enjoy!

SoC: Some statistics

Here go some statistics about what has been done during the SoC 2007 program as regards ATF:

The repository weights at 293 revisions, 1,174 certificates (typically 4 per revision, but some revisions have more) and 221 files. This includes ATF, the patches to merge it into the NetBSD build tree and the website sources. (mtn db info will give you some more interesting details.)

The clean sources of ATF 0.1 (not counting the files generated by the GNU autotools) take 948Kb and are 20,607 lines long (wow!). This includes the source code, the manual pages, the tests and all other files included in the distribution.

The patches to merge ATF into NetBSD, according to diffstat, change 209 files, do 6,299 line insertions and 4,583 line deletions. Aside merging ATF into NetBSD, these changes also convert multiple existing regression tests to the new framework.

As regards the time I have spent on it... I don't know, but it has been a lot. It should have been more as I had to postpone the start of coding some weeks due to university work, but I think the results are quite successful and according to the expectations. I have been able to cover all the requirements listed in the NetBSD-SoC project page and done some work on the would-be-nice ones.

I am eager to see the results of the other NetBSD-SoC 2007 projects as there was very interesting stuff in them :-)

SoC: ATF 0.1 released

To conclude the development of ATF as part of SoC, I've released a 0.1 version coinciding with the coding deadline (later today). This clearly draws a line between what has been done during the SoC program and what will be done afterwards.

See the official announcement for more details!

I hope you enjoy it as much as I did working on it.

SoC: Status report

SoC's deadline is just five days away! I'm quite happy with the status of my project, ATF, but it will require a lot more work to be in a decent shape — i.e. ready to be imported into NetBSD — and there really is no time to get it done in five days. Furthermore, it is still to unstable (in the sense that it changes a lot) so importing it right now could cause a lot of grief to end users. However, after a couple of important changes, it may be ready for a 0.1 release, and that's what I'm aiming for.

I have to confess again that some parts of the code are horrible. That's basically because it has been gaining features in an iterative way, all which were not planned beforehand... so it has ended up being hack over hack. But, don't worry: as long as there is good test coverage for all the expected features, this can easily be fixed. With a decent test suite, I'll be able to later rewrite any piece of code and be pretty sure that I have not broken anything important. (In fact, I've already been doing that for the most inner code with nice results.)

So what has changed since the preview?

• All files read by ATF as well as all data formats used for serialization of data have now a header that specifies their format (a type and a version). This is very important to have from the very beginning so that the data formats can easily be changed in the future (which will certainly happen).
• Rewrote how test programs and atf-run print their execution status. Now, the two print a format that is machine-parseable and which is "sequential": reading the output from top to bottom, you can immediately know what the program is doing at the moment without having to wait for future data.
• Added the atf-report tool, which gathers the output of atf-run and generates a user-friendly report. At the moment it outputs plain text only, but XML (and maybe HTML) are planned. The previous point was a pre-requisite for this one.
• Merged multiple implementation files into more generic modules.
• Merged the libatf and libatfprivate libraries into a single one. The simpler the better.
• Added build-time tests for all public headers, to ensure that they can be included without errors.
• Implemented run-time configuration variables for test programs and configuration files.

Wow, that's a lot of stuff :-)

And talking with my mentor five days ago, we got to the following list of pending work to get done before the deadline:

1. Configuration files. Already done as of an hour ago!
2. A plain text format that clearly describes the results of the test cases (similar to what src/regress/README explains). I haven't looked at that yet, but this will be trivial with the new atf-report tool.
3. Would be nice: HTML output. Rather easy. But I'm unsure about this point: it may be better to define a XML format only and then use xsltproc to transform it.
4. Manual pages: A must for 0.1 (even if they are not too detailed), but not really required for the evaluation.
5. Code cleanups: Can be done after SoC, but I personally dislike showing ugly code. Unfortunately there is not enough time to spend on this. Cleaning up a module means: rewriting most of it, documenting each function/class and adding exhaustive unit tests for it. It is painful, really, but the results are rewarding.
   
6. Keep the NetBSD patches in sync with development: I'm continuously doing that!

Let's get back to work.

SoC: First preview of NetBSD with ATF

Reposting from the original ATF news entry:

I have just uploaded some NetBSD-current release builds with ATF merged in. These will ease testing to the casual user who is interested in this project because he will not need to mess with patches to the NetBSD source tree nor rebuild a full release, which is a delicate and slow process. For the best experience, these releases are meant to be installed from scratch even though you can also do an upgrade of a current installation. They will give you a preview of how a NetBSD installation will look like once ATF 0.1 is made public, which should happen later this month.

For more details see my post to the NetBSD's current-users mailing list.

Waiting for your feedback :-)

Edit (Aug 20th): Fixed a link.