After a long hiatus for various reasons, I finally had the chance to try my
hand at loading a TeleMetrum
board today!
Sadly, I wasn't able to completely load any boards, because I somehow ended
up with the wrong Digi-Key part numbers for 4
capacitors, one of which is a critical value. I placed an order for the
missing parts and a few other bits we'll need eventually, hopefully they'll
be here in a couple days and I can try to load a board with all the parts.
Instead, what I did today was a a partial load of a board with the goal of
testing the various power supplies. Seemed like a good idea, since I've
had my share of odd problems with power supplies in the past. This also
gave me a chance to try out my solder paste stencil, get some experience
hand-placing the tiny 0402 passive parts, and an excuse to see if I could
hit the solder reflow temperature profile adequately with my electric
cooking skillet and IR non-contact thermometer.
The good news is that it all worked right the first time! We're successfully
charging a LiPo battery from USB power, and successfully making 3.3 volts for
the electronics from that. The resistor divider designed to allow the LiPo
battery voltage to be sampled by the CPU's analog to digital converter is
also working fine.
A few observations are in order, however.
Getting the right amount of solder paste down on the board requires some
finesse with the spreading blade and the stencil. I think the paste was a
bit heavy around the CC1111 footprint, as I ended up with some bridged
pads. Since I didn't load the actual CPU part, it could just be that not
having something real there to wick up some solder meant there was enough
to form the bridges. Don't know. The amount of solder on the ground pad
in the middle of the chip looks good, though!
The 0603 sized LED in the power supply circuit was the only part that didn't
self-align correctly. I may have had it a bit too far to one side. The pads
on the part have notches in the end, and it looks like one side of each is
more or less centered, so I think surface tension did the best it could with
what I gave it to work with. The LED soldered ok, isn't shorting to anything
else, and clearly works fine... but I'd be happier if it were aligned better.
Found and fixed a solder bridge between two pins on the surface-mount USB
connector before first application of power. Could be further data that the
paste layer was a bit too thick. On the other hand, I had to wiggle the
connector around a bit to get it aligned correctly, so I may have smudged
the paste into a bridge while doing that.
I also note that there's some visible flux left on the surface of the solder,
particularly on big paste areas like the feet of the USB connector. I
suspect this means I didn't dwell long enough at either or both of the preheat
or ultimate reflow temperatures. Since all the parts clearly soldered
adequately to function, I'm still pretty happy... but since the rockets we
fly experience violent accelerations during boost, this is something I'll
play with on future reflows.
All in all, a great way to spend an afternoon, and a big step forward for
the TeleMetrum project!
| Operation | with journal | w/o journal | percent change |
| git clone | 367.7 | 353.0 | 4.00% |
| make | 231.1 | 203.4 | 12.0% |
| make clean | 14.6 | 7.7 | 47.3% |
| Operation | with journal | w/o journal | percent change |
| git clone | 367.0 | 353.0 | 3.81% |
| make | 207.6 | 199.4 | 3.95% |
| make clean | 6.45 | 3.73 | 42.17% |
| Operation | with journal | w/o journal | percent change |
| git clone | 366.6 | 353.0 | 3.71% |
| make | 216.8 | 203.7 | 6.04% |
| make clean | 13.34 | 6.97 | 45.75% |
| Operation | ext3 | ext2 | percent change |
| git clone | 374.6 | 357.2 | 4.64% |
| make | 230.9 | 204.4 | 11.48% |
| make clean | 14.56 | 6.54 | 55.08% |

A new version of WebKit s GTK+ port is here, as also announced by Xan! Before I start listing the new features and fixes, let me give you a download link =).
For this version we have changed the binary interface slightly, which requires a soversion bump, so rebuilding applications is in order. The API is still stable, though.
Another major change worthy of note is that we have made libsoup the only HTTP backend available for WebKitGTK+, removing the CURL related code from our port (the CURL backend remains in the tree, though, as it is used by other ports). This should simplify implementation and allows us to expose Soup objects in the API, reducing the amount of wrapping code that is necessary. We are already exposing the SoupSession we use internally, providing yet more power and flexibility to applications using our API.
In this release we finally get to see the official debut of the Web Inspector in the GTK+ port. Can t wait to see releases of our dear browsers featuring the inspector =). Numerous improvements to hading policy decisions regarding navigations and window creation requests to the application have also come with this release.
We worked hard on finding and fixing crashes for this release, but also numerous fixes for those pet peeves that bother us just a bit, but enough to add up got landed. There are more of those to kill, but things look promising. We are hoping to release again in two weeks, so expect more fixes soon.
So, that s it. Grab the new version, test it, report bugs, and enjoy!
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
The times were fairly regular: once just before the hour, most 2 minutes
after. I fetch mail at around that time, but also at other times, so
possible but unlikely. The 2 minutes after was the first real clue:
some cron job maybe? After disabling logcheck the messages no longer
appeared in the log. Enable it again, and they were back.
Additional confusion was caused by the fact that the domain had "debian"
in its name, but it was somewhere obscure. So why was logcheck causing
a lookup for that domain? This did confuse me enough to waste some time
looking for some silly weird (default) configuration problem in some package.
Enter spamassassin. Apparently that was parsing the message body, recognized
"somedomain.org" as a host name, and proceded to do a DNS lookup as validity
check.
So we have the following loop, started off by something causing an initial
DNS lookup for the domain, which fails and gets logged:
logging
category lame-servers null; ;
;
Anyway, now I just no longer pass logcheck mails through spamassassin.
(Although filtering out these DNS errors in bind9 can be perfectly valid.)
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
The times were fairly regular: once just before the hour, most 2 minutes
after. I fetch mail at around that time, but also at other times, so
possible but unlikely. The 2 minutes after was the first real clue:
some cron job maybe? After disabling logcheck the messages no longer
appeared in the log. Enable it again, and they were back.
Additional confusion was caused by the fact that the domain had "debian"
in its name, but it was somewhere obscure. So why was logcheck causing
a lookup for that domain? This did confuse me enough to waste some time
looking for some silly weird (default) configuration problem in some package.
Enter spamassassin. Apparently that was parsing the message body, recognized
"somedomain.org" as a host name, and proceded to do a DNS lookup as validity
check.
So we have the following loop, started off by something causing an initial
DNS lookup for the domain, which fails and gets logged:
logging
category lame-servers null; ;
;
Anyway, now I just no longer pass logcheck mails through spamassassin.
(Although filtering out these DNS errors in bind9 can be perfectly valid.)
Earlier this week, Tom Watson, Cabinet Office Parliamentary Secretary, published the Open Source, Open Standards and Re Use: Government Action Plan. It s had a pretty mixed reaction, with mild scepticism (niq s soapbox: Is gov.uk going open-source?) being the average reaction from what I ve read. I particularly liked the kind offer by Bristol Wireless to debianise Tom Watson s laptop.
I think commentators are bang-on that the procurement process needs to change and that this sounds positive. I ll love it if I m wrong, but this looks like the lip service as usual which I ve seen in the last 10 years working on FOSS in the UK. I want to see the action that comes from this plan! When government actually starts buying FOSS from typical FOSS service providers and not just the IBMs of this world, then I ll believe it.
My suspicion is re-ignited by some of the activites around this action plan. For example, does anyone know why the Cabinet Office didn t select FOSS to run their special public FOSS Aggregation page? (Actually, what s the best FOSS tag aggregator web service out there? I know we can set them up in Wordpress widgets, but what hosted services are there?)
I m also a bit bemused that their page requires users to accept cookies until they expire, yet its privacy policy explicitly says You may suppress cookies after your visit or configure your Internet browser to prevent them. Yes, I can prevent them, but then it does nothing useful!
(Based on a comment I made at the OSS Watch team blog and discussions with a few user groups.)
I've not had that many problems with network-manager, until now. The new version in unstable is just completely broken on my machine. Sadly, I can't report why it failed as I inadvertently closed the terminal with the relevant output. | Pass | ext4 old allocator | ext4 new allocator | |||||||||
| time (s) | I/O | time (s) | I/O | ||||||||
| real | user | system | MB read | MB/s | real | user | system | MB read | MB/s | ||
| 1 | 6.69 | 4.06 | 0.90 | 82 | 12.25 | 6.70 | 3.63 | 1.58 | 82 | 12.23 | |
| 2 | 13.34 | 2.30 | 3.78 | 133 | 9.97 | 4.24 | 1.27 | 2.46 | 133 | 31.36 | |
| 3 | 0.02 | 0.01 | 0 | 1 | 63.85 | 0.01 | 0.01 | 0.01 | 1 | 82.69 | |
| 4 | 0.28 | 0.27 | 0 | 0 | 0 | 0.23 | 0.22 | 0 | 0 | 0 | |
| 5 | 2.60 | 2.31 | 0.03 | 1 | 0.38 | 2.42 | 2.15 | 0.07 | 1 | 0.41 | |
| Total | 23.06 | 9.03 | 4.74 | 216 | 9.37 | 13.78 | 7.33 | 4.19 | 216 | 15.68 | |
For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM.
In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!
| Pass | ext3 | ext4 old allocator | |||||||||
| time (s) | I/O | time (s) | I/O | ||||||||
| real | user | system | MB read | MB/s | real | user | system | MB read | MB/s | ||
| 1 | 108.40 | 13.74 | 11.53 | 583 | 5.38 | 6.69 | 4.06 | 0.90 | 82 | 12.25 | |
| 2 | 5.91 | 1.74 | 2.56 | 133 | 22.51 | 13.34 | 2.30 | 3.78 | 133 | 9.97 | |
| 3 | 0.03 | 0.01 | 0 | 1 | 31.21 | 0.02 | 0.01 | 0 | 1 | 63.85 | |
| 4 | 0.28 | 0.27 | 0 | 0 | 0 | 0.28 | 0.27 | 0 | 0 | 0 | |
| 5 | 3.17 | 0.92 | 0.13 | 2 | 0.63 | 2.60 | 2.31 | 0.03 | 1 | 0.38 | |
| Total | 118.15 | 16.75 | 14.25 | 718 | 6.08 | 23.06 | 9.03 | 4.74 | 216 | 9.37 | |
| 312214 | inodes used (14.89%) |
| 263 | non-contiguous files (0.1%) |
| 198 | non-contiguous directories (0.1%) |
| # of inodes with ind/dind/tind blocks: 0/0/0 | |
| Extent depth histogram: 292698/40 | |
| 4388697 | blocks used (52.32%) |
| 0 | bad blocks |
| 1 | large file |
| 263549 | regular files |
| 28022 | directories |
| 5 | character device files |
| 1 | block device file |
| 5 | fifos |
| 615 | links |
| 20618 | symbolic links (19450 fast symbolic links) |
| 5 | sockets |
| 312820 | files |
| Pass | ext4 old allocator | ext4 new allocator | |||||||||
| time (s) | I/O | time (s) | I/O | ||||||||
| real | user | system | MB read | MB/s | real | user | system | MB read | MB/s | ||
| 1 | 6.69 | 4.06 | 0.90 | 82 | 12.25 | 6.70 | 3.63 | 1.58 | 82 | 12.23 | |
| 2 | 13.34 | 2.30 | 3.78 | 133 | 9.97 | 4.24 | 1.27 | 2.46 | 133 | 31.36 | |
| 3 | 0.02 | 0.01 | 0 | 1 | 63.85 | 0.01 | 0.01 | 0.01 | 1 | 82.69 | |
| 4 | 0.28 | 0.27 | 0 | 0 | 0 | 0.23 | 0.22 | 0 | 0 | 0 | |
| 5 | 2.60 | 2.31 | 0.03 | 1 | 0.38 | 2.42 | 2.15 | 0.07 | 1 | 0.41 | |
| Total | 23.06 | 9.03 | 4.74 | 216 | 9.37 | 13.78 | 7.33 | 4.19 | 216 | 15.68 | |
For comparison s sake, here is a comparison of the fsck time of the same collection of files and directories, comparing ext3 and the original ext4 block and inode allocator. The file system in question is a 32GB install of Ubuntu Jaunty, with a personal home directory, a rather large Maildir directory, some linux kernel trees, and an e2fsprogs tree. It s basically the emergency environment I set up on my Netbook at FOSDEM.
In all cases the file systems were freshly copied from the original root directory using the command rsync -axH / /mnt. It s actually a bit surprising to me that ext3 s pass 2 e2fsck times was that much better than e2fsck time under the old ext4 allocator. My previous experience has shown that the two are normally about the same, with a write throughput of around 9-10 MB/s on for e2fsck s pass 2 for both ext3 file systems and ext4 file systems with the original inode/block allocators. Hence, I would have expected ext3 s pass2 time to have been 12-13 seconds, and not 6. I m not sure how that happened, unless it was the luck of draw in terms of how things ended up getting allocated on disk. So I m not too sure what happened there, but overall things look quite good for ext4 and fsck times!
| Pass | ext3 | ext4 old allocator | |||||||||
| time (s) | I/O | time (s) | I/O | ||||||||
| real | user | system | MB read | MB/s | real | user | system | MB read | MB/s | ||
| 1 | 108.40 | 13.74 | 11.53 | 583 | 5.38 | 6.69 | 4.06 | 0.90 | 82 | 12.25 | |
| 2 | 5.91 | 1.74 | 2.56 | 133 | 22.51 | 13.34 | 2.30 | 3.78 | 133 | 9.97 | |
| 3 | 0.03 | 0.01 | 0 | 1 | 31.21 | 0.02 | 0.01 | 0 | 1 | 63.85 | |
| 4 | 0.28 | 0.27 | 0 | 0 | 0 | 0.28 | 0.27 | 0 | 0 | 0 | |
| 5 | 3.17 | 0.92 | 0.13 | 2 | 0.63 | 2.60 | 2.31 | 0.03 | 1 | 0.38 | |
| Total | 118.15 | 16.75 | 14.25 | 718 | 6.08 | 23.06 | 9.03 | 4.74 | 216 | 9.37 | |
| 312214 | inodes used (14.89%) |
| 263 | non-contiguous files (0.1%) |
| 198 | non-contiguous directories (0.1%) |
| # of inodes with ind/dind/tind blocks: 0/0/0 | |
| Extent depth histogram: 292698/40 | |
| 4388697 | blocks used (52.32%) |
| 0 | bad blocks |
| 1 | large file |
| 263549 | regular files |
| 28022 | directories |
| 5 | character device files |
| 1 | block device file |
| 5 | fifos |
| 615 | links |
| 20618 | symbolic links (19450 fast symbolic links) |
| 5 | sockets |
| 312820 | files |
The TSC, IA32_MPERF, and IA32_FIXED_CTR2 operate at the same, maximum-resolved frequency of the platform, which is equal to the product of scalable bus frequency and maximum resolved bus ratio.
For processors based on Intel Core microarchitecture, the scalable bus frequency is encoded in the bit field MSR_FSB_FREQ[2:0] at (0CDH), see Appendix B, "Model-Specific Registers (MSRs)". The maximum resolved bus ratio can be read from the following bit field:In summary, TSC increment = (scalable bus frequency) * (maximum resolved bus ratio). This implies the TSC is incrementing based on some external bus source (any hardware engineers explain what happened for Core here?), and is a departure from simply assuming that the TSC increments once for each CPU cycle. The interesting bit is that if XE operation is disabled, the bus ratio is assumed to be the maximum qualified frequency. This seems to mean that if you overclock your CPU and your processor is running at higher than the qualified frequency, attempts to measure the CPU speed by counting TSC ticks over a given time may yeild the wrong results (well, will yield the rated result; i.e. the speed of the processor you bought out of the box). While interesting, this divergence is probably has little practical implications because using the TSC for benchmarking is already fraught with danger. You have to be super careful to make sure the compiler and processor don't reschedule things around you and handle other architectural nuances. If you need this level of information, you're much better using the right tools to get it (my favourite is perfmon2).
- If XE operation is disabled, the maximum resolved bus ratio can be read in MSR_PLATFORM_ID[12:8]. It corresponds to the maximum qualified frequency.
- IF XE operation is enabled, the maximum resolved bus ratio is given in MSR_PERF_STAT[44:40], it corresponds to the maximum XE operation frequency configured by BIOS.
Last week, I couldn't resist and bought myself an Acer Aspire One (AOA 150Ab) netbook. It has 1G RAM, 120G HDD, unfortunately needs a fan, and is the model without 3G modem. It comes with Linpus Linux pre-installed. Looks quite nice, but is obviously ultimately the wrong OS ... Besides, it's locked down quite a bit, there's not even an easy way to start a terminal :-) I still have kept it, in a dual-boot configuration, to play around or show to people.
Installing Lenny went very well, and to make things more fun I'm running quite a few things from experimental: KDE 4.2, xorg 7.4 (1:7.4~5 right now) and Oo.org 3. And, to get DRI2, also the 2.6.28 kernel from the newer-than-sid repository of the kernel team (2.6.28-2~snapshot.12850, but I hear 2.6.28 has now been uploaded.) While the whole thing is fun to use and didn't make any real problems, there are a few remaining issues (yes, this is a Dear Lazyweb posting, feel free to comment. I'll try to add updates to this article as this progresses):
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.layout" type="string">ch</merge>
<merge key="input.xkb.variant" type="string">de</merge>
</match>
</device>
</deviceinfo>
I now realize that just installing hal-info from squeeze or sid might also fix the issue.
I was very pleased to wake up this morning to the news that National has delayed the introduction of S92A via an order-in-council. It s a nice short-term victory, but I ll save the champagne until the law is fundamentally rewritten.
The most pleasing aspect of the decision is simply that it was made at all. Within two weeks, a small band of protesters were able to harness the power of the Internet to direct international attention and place enough pressure on a Government, whose Prime Minister admitted to not having read the bill prior, that he then took the time to understand the issues and personally announce the delay in implementation of the law. We owe much thanks to the Creative Freedom Foundation for all the effort they put into co-ordinating the protest and ensuring that a single coherent message was presented. Just a little bit of my cynicism and belief that politicians never listen to public opinion outside of election campaigns was chipped away today.
The reason I m not breaking out the champagne yet is that we ve only achieved a temporary reprieve in the commencement of the law. While those present at the press conference seem somewhat confident that John Key didn t like what he found in the law and would have repealed it if given the chance, all that has actually been done is delay it in the hopes of an agreement between the TCF and the rights holders (aka big media companies) on how to implement the still fundamentally broken law. The Government has given until late March for that to occur.
To put this into a more global context. My happiness as I took the bus to work after reading about the decision to delay the law was short lived as the front page of the local paper declared that Eircom (Ireland s equivalent of Telecom) has voluntarily agreed to block sites such as The Pirate Bay upon request by the media companies (this comes a week after they also announced an agreement to, again voluntarily , implement a 3-strikes S92A style policy). Now, with the biggest ISP in their pocket (so to speak), the media companies have sent threatening letters to the remaining ISPs in the country demanding they implement the same procedure.
To me, this illustrates one of the fundamental problems with S92. The concept that an ISP is liable for the conduct of its users, or for policing where on the Internet users should and shouldn t be able to connect to does not belong in our laws. Most ISPs already have provision to disconnect customers for illegal activity in their terms and conditions. If an end-user is doing something illegal, that is an issue between the rights holder and the end-user to take up in the courts just like every other sector of society must do when wronged, at which point the existing ISP terms and conditions can be invoked and access terminated.
The big media companies, having decided that it is too expensive/hard/inconvenient to follow standard legal procedures to resolve their grievances are launching multi-pronged attacks to shift the playing field in their favour. In countries like New Zealand, where our politicians yearn for a Free Trade Agreement with America, they use their lobbyists to ensure that S92 style laws are part of the conditions. In other jurisdictions, like Ireland, they use strong-arm, divide and conquer style bully tactics outside of the political and legal process.
I don t support copyright infringement. I rely on copyright to protect much of the work I place on the Internet, I want strong laws that protect me when my rights have been infringed. I don t believe that such laws should come at the expense of due process, our legal tradition and the basic principle of fairness! I don t believe that copyright infringement is such a heinous crime that it demands punishments stronger than those we deliver to paedophiles, stalkers or any other class of criminal who uses the Internet to enable their crimes.
To me, today s (yesterday s - depending on your timezone) decision is only the first step in clawing New Zealand back from the dangerous path that the big media companies have been leading our law makers down. From here we need to press on and demonstrate to the Government over the next month that even if the TCF and rights holders are able to come up with some sort of workable code of practice, the law is still fundamentally flawed. It is based on premise that we are guilty by accusation.
Even if guilt were to be proved by a competent legal body (eg. court or copyright tribunal) we don t need laws placing further liabilites onto ISPs (and remember the definition of ISP under this amendment act includes businesses who provide Internet access to staff, libraries, schools and hospitals) when their existing terms and conditions already prohibit illegal activity.
Finally, and most importantly of all, we need to remember that laws exist to serve all sectors of society. Yes, copyright infringement is against the law and rights holders are reasonable in expecting the law to protect their content and allow them to make a fair profit. On the other side of the fence, average New Zealanders are not being unreasonable in their desire to have media available electronically, on demand and non-inhibited by DRM following a legal purchase. The failure of the media businesses to adequately cater to this change in market demand and usage of technology is obviously a contributing factor to the widespread copyright problems that they are facing today.
Obviously, I m not condoning copyright infringement simply because the media companies are failing to address demand. Even stupid laws must be obeyed (and the concept of copyright is far from stupid). What I want to see is the Government acknowledging that the problem is not solely with consumers infringing copyright for malicious purposes, and therefore that the solutions do not lie solely in increasing the enforcement and punishments available.
Copyright has always been a balancing act between the rights of content producers and consumers. S92 and the act it is contained within are taking us far too far down the road of catering to big business and their outdated business models with far too little concern for the rights of the individual consumer.
Despite the many submissions made on this act last year when it was first passing through parliament, there was no comprehensive debate on what copyright means and how it should balance the rights of content producers and consumers in our digital century where copying is a zero-cost, zero-thought activity. Without such a debate we re doomed to continue wasting time arguing over the symptoms of the problem, like S92.
So, I m saving my champagne for the day when we as a country address these issues and come up with a fair and workable interpretation of what copyright means today.
Presently, volume and content is of a low volume, but expecting to ramp up. I do however find 90% of disk volume in one table called watchdog ;
Looking at just 1 random second of SQL logging shows 1200+ SELECT statements.
355 are SELECT changed FROM node
[...]
There is plenty of information regarding monitoring the Slow Queries in MySQL, but I have also promoted that s it not the slow queries that ultimately slow a system down, but the 1000 s of repeating fast queries.
MySQL of course has the Query Cache to assist, but this is a course grade solution, and a high volume read/write environment this is meaningless.
There is a clear need for either a application level caching, or a database redesign to pull rather then poll this information, however without more in depth review of Drupal I can not make any judgment calls.
I've been dying to upgrade my MythTV
setup to use Lenny
for ages, ever since I got a HD HomeRun and
discovered my primary MythTV front end couldn't play back the HD recordings
for some reason (I just got a blue box and the audio, and a lot of errors in
the X server log).
I figured it was either the kernel or X, and I hadn't been able to get
the lirc kernel module to build against anything newer than Etch's
2.6.18 kernel (as I discovered today, that was because of some contamination
in module-assistant's build directory, so I could have tried a newer kernel
ages ago - drat), so I was unable to determine if it was the kernel or X.org
itself.
An added bonus of upgrading X was it talks to the TV better. I've got the PC
hooked up to the TV's VGA input, and previously, the best I could do was get
it to talk 1024x768, with the TV set to a 4:3 aspect ratio. When I initially
upgraded, for whatever reason, the TV was very unhappy with what it was
receiving on the VGA input and wouldn't display anything, so in desperation,
I tried ditching the xorg.conf entirely, and then everything just
worked. X came up with a 1280x768 resolution, I think despite the TV
thinking it's getting 1024x768, so now we can have the TV in 16:9 mode, and
things don't look all stretched, even when the playback is only 4:3.
And HD, oh it looks glorious. We just watched the Oscars, and it completely
filled the TV and looked absolutely fantastic. Playing back HD content seems
to really peg the CPU though. The playback was unbearably choppy until we
paused the commercial flagging job that was madly trying to flag commercials
in the same recording we were currently watching (i.e. the Oscars).
The only thing that seems to be acting a bit weird is notification pop ups
from the D-Bus notification
daemon. I've got a Griffin
PowerMate that runs a home-grown script to re-pair the Bluetooth
keyboard and mouse, and that uses the D-Bus notification system to provide
feedback while it's running. It seems that while the MythTV front end is
running, those pop ups aren't displaying correctly. I haven't gotten to the
bottom that one yet.
I also had some problems with a couple of init scripts and splashy
causing bootup to hang, but I'm not sure that's completely reproducible (I
don't reboot this machine all that often) so it may have been operator
error.
Overall, very happy with the outcome. The upgrade was fairly smooth, and
I've got the additional functionality I've been waiting for.
Next.