I've made some progress on the bootstrapping idea :) As a proof of concept I wrote a simple script which will download *all* the required RPM files for an installation of Fedora-Core 6. (i386) This downloads 348 .rpm files, which is about 700Mb. (I'm downloading way more files than I need, because I'm not using dependency-discovery yet....) However the proof of concept works. I can successfully chroot inside the unpackaged directory tree - so I think it is sufficient to persuade me that I can dynamically determine which RPM files need to be installed. This avoiding the problem which rpmstrap suffers from. (ie. having a static list of specific RPM version to fetch.) If you'd like to test my script, hardwired as it is, (did I mention ugly?), then feel free. In terms of requirements you'll need:

• wget
• rpm
• alien

Note: I'd expect this script to take in the order of 30-40 minutes to run. It is pretty noisy though, so you'll know it hasn't died! The script will live here for a day or two:

• http://steve.org.uk/Software/tmp/fc6

PS. Don't run this as root. Please.

Bootstrapping non-Debian distributions suck. The only available tool appears to be rpmstrap which quite frankly fails more often than it works. Since my xen-tools project needs to do carry out this kind of operation I've been pondering the idea of writing a tool which will install CentOS/Fedora/SuSE into a directory, in a similar fashion to debootstrap. If there's nothing out there that you can point to, then I think that will be my next project.

It turns out that if you want to use includes in your .spec file and want the files to be included in the .src.rpm you have to declare those scripts as supplemental sources.

So instead of:
Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....


You have to have:

Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Source101: foo.pre.sh
Source102: foo.post.sh
Source103: foo.preun.sh
Source104: foo.postun.sh
Source105: foo.changelog
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....

In case you want to have the scripts separated in different files and you use them all.

Note: the number in the "SourceXXX" is arbitrary but must be unique.

But mentioning the files as being Source... means you have to write:


%post
%include ../SOURCES/foo.post.sh

%preun
%include ../SOURCES/foo.preun.sh

%postun
%include ../SOURCES/foo.postun.sh


Instead of:


%post
%include foo.post.sh

%preun
%include foo.preun.sh

%postun
%include foo.postun.sh


Which should have been more reasonable...

RPM, please die... or grow some 21st century features... or some sense!!!


Update: Thanks to a few people, I was pointed out I am still not thinking in terms or RPM.
The proper way of writing the include without them looking odd is something like:

%post
%include % SOURCE102

Yesterday was the July meeting of the Cooperatives SW steering group. As usual, we started with introductions over a snack, including welcoming our new support worker, then reviewed developments on open topics from the last meeting, including production of the new promotional leaflet. We need some good quotes from relevant politicians or prominant local cooperators to finish it up, as well as a bit of data from Cooperatives UK. Other topics included planning for the October 2007 annual meeting, communications (if you want a Cooperatives SW newsletter and meeting details and you don't currently get them, please leave me a comment and I'll put you in touch with them), surveying and maybe an outward-facing event in 2007. We also happily accepted applications from Upstart and Radstock (no website? small pic) to join the steering group. I'm particularly happy to have another workers' cooperative there. Amongst other topics and announcements, there was some troubling feedback about RISE-SW not being talkative about this summer's social enterprise support bids. Does anyone know more about this bid?

I’ve been away from blogging. I’ve been away from doing Debian and Ubuntu work (although there has been a few package updates, as well as a new one.) I’ve been away from a lot of happenings (like how the excellent Knightlust got to convince my fellow townsfolk at Lourdes College Foundation to use FOSS,) but that’s fine, since I know there will be others who can keep up the flame burning. I’ve been away because I’ve been looking at stuff. Lots of stuff. Various stuff. Stuff like Plan 9 from Bell Labs, and Inferno, and dabbling into distributed computing, working on an implementation of Plan 9’s file protocol. Stuff like thinking about programming, meditating upon it as an art, exercising a discipline of simplicity, clarity and frugality. All that stuff. I first looked at Plan 9 last March, when I was wanting to go another round at the Google Summer of Code. While I was not selected, just getting Plan 9 to run on my machines (first as a qemu terminal, then as standalone CPU server replacing my old Ubuntu dapper install on my desktop) exposed me to that other side,’ and that got me thinking about how software ought to be good. Of course, I could have just chosen to drop it all (after all, I wasn’t selected, so…) but I knew that if I stick long enough, I might just learn something. And yes, I am learning something. Like how a lot of software isn’t really simple, just appearing to be. Or how sophisticated software development methodologies rob the clear picture gained from a well-thought, clear, and simple analysis of problems. Or when push comes to shove, I will have to make a choice, between tolerating software complexity and status quo, or facing it and attempt to simplify it. Well, there’s much to tell, but I’m lazy, and I’d rather tell stories in bits. Anyway, I think I’ll have some time to spare, especially as I have accepted a new job at an up-and-coming company that, I hope and endeavor, will rock the local and international tech scene. And, while doing that, get around to make great tools to get my job done, and other people’s jobs too. I’m getting back to the action.

debbie commented:

"I really appreciate finding somewhere that's giving info' on where to find the coverage on t.v. I've just looked through Sky t.v listings and coudn't find a damn thing at 9a.m. on Saturday.........unless I'm blind and stupid. So ITV4 sounds the best, then. I'm not subscribed to the larger SKY packages. It's such an excting time!!!! The Tour De France starting HERE in England!!!!"

I've also linked CTC's listing in the last few days, which is more complete. I'm not subscribed to Sky either and I don't think British Eurosport's coverage was as good as International Eurosport in the past. I would be quite annoyed if I paid for Sky's sports package and still only got such limited coverage when better is available free-to-air. Get a dish, point it at 19 east and enjoy the German, or 5 west and enjoy French. Maybe today, the weather here will be good enough for me to fix my dish. I'm still surprised by itv's bizarre decision not to promote their tour coverage properly and not to put the highlights on itv1. Wouldn't 2 million fans be worth sacrificing a little of their much-hated late-night phone-in game show that currently hogs itv1 after midnight?

I. Introduction

Today, the mid-term evaluations of the Google Summer of Code starts. It means it's a good for a comprehensive summary of what I've done so far.

For those who don't remember, My GSoC project is the Bug Triaging and Forwarding Tool, whose aim is to help triaging of Debian bug reports. On my proposal, I had included the following timeline:

• April - May: Study of the resources available for use in the project
  (Debian BTS SOAP/LDAP interface, Bugzilla interaction resources, etc)
  and the design of the tool. Request needed unavailable features,
  if any, with patches if possible


• May - July: Development of initial interface and code to interact with
  Debian BTS


• August: Development of Bugzilla plugin

During the proposals evaluations and the community bounding period, it was pointed to me that there's already a lot of good tools to handle bug reports, so I've changed this a bit and already started to work on BTS-Bugzilla interaction, which seems to be the more novel part of the
tool.

The development has been fragmented in three modules: btsutils, bzutils and bug-triage.

II. btsutils

The btstutils is a python module to interact with the Debian Bug Track System. Currently, it can query the bts by bug number, package, source package, maintainer, submitter and usertag. For each bug, it returns bug number, package, summary, status, severity, submitter and tags. Support for returning usertags is under way.

Ths btsutils can use html or soap to access the bug data, and has also a backend-agnostic module wwith tries the best method and, if that fails, tries the other.

Steffano Zacchiroli has offered me to include the btsutils on the debian-bundle, a bundle of python modules for dealing with Debian infrastrcture. I'm very excited by this idea, and believe that if all or at least some of the Debian tools which interact with BTS end using a standardized module for access, this might end up being the major contribution of my GSoC project for the Debian community.

III. bzutils

The bzutils is similar to the bzutils, but is to interact with bugzillas instead. Currently it can do queries based on GNOME's bugzilla boogle and the more generic boolean charts. The later works (at least) on GNOME, KDE and standard bugzilla (i.e., landfill). For each bug, it returns bug id,
product, component, status, resolution, reporter, assignee, summary, priority and severity.

IV. bug-triage

The bug-triage is the Bug triaging and forwarding tool. It's being developed using python, gtk and glade.

Currently, it can query the BTS using any of the btsutils' supported fields (even though the usertags aren't really accessible through the interface yet). It can also launch one of the returned bug reports in a web browser.

Integration with bugzillas is under development. It already has an interface to establish links between Debian packages and upstream bugzilla's address, product and component. The next steps will be to add an upstream button in the toolbar/menu and make it show the bugs selected through these info, allowing the user to mark the bug as forwarded to one of them.

V. The future

After that, I'll work on these features (in no particular order): filling a new upstream bug using the Debian bug data as a starting point, more advanced filtering options to filter the upstream bugs (such as filtering by words in the bug summary, and maybe through backtraces if available) and more ways to manipulate the BTS through the interface.

To be sincere, it seems this project won't be as advanced as I would like on the end of the GSoC. There are some new, unexpected (and good ^_^) things going on my life, which are taking some of the time I expected to dedicate to GSoC, which means I'll likely keep the current pace until the end of the project (I expected to increase it during July). Even so, I believe the
project is going on a good path, and I hope it'll be very useful for the Debian community.

Google has just announced the Recharge project. They are converting some of their own fleet of Prius and other hybrid cars to be “plug-in hybrids”, this means that the car can be plugged in to mains power to charge it’s batteries and petrol will only be used as a fuel of last resort. If a car is mostly used for short trips then the petrol use is dramatically reduced - but the car still has the 1000Km range that a full tank of petrol provides! Google is also going to invest $10,000,000 in companies that develop technologies related to hybrid vehicles. If you have some ideas for new technological developments related to power saving then you might want to check out what Google is doing.

Share This

For some time I have ignored my blog so I did not notice that when my co-admin upgraded our system from etch to lenny, it broke. When I found some time to look at it, it turned out to be because the blog was no longer running in production mode, so it pointed at the empty development database. This caused every URL to redirect to the login page, but since I didn’t have a valid user for that db, I couldn’t login. This, in turn, was due to the upgrade of mod_fcgid from the old 1.10 version in Etch to 2.1. Apparently, this used to work. Note the name of the module:

<IfModule mod_fastcgi.c>
   <Directory /var/www/vir/syn.theti.ca/typo>
    FastCgiIpcDir /tmp/fcgi_ipc/
    FastCgiServer /var/www/vir/syn.theti.ca/typo/public/dispatch.fcgi -initial-env RAILS_ENV=production -processes 15 -idle-timeo
ut 60
   </Directory>
</IfModule>

It’s strange that the section is called mod_fastcgi.c, not mod_fcgid.c. Either that was done to make it a “drop in” replacement for fastcgi, and later changed in the next release, or else this config was not actually used, but somehow my blog started in production mode before the upgrade anyway. In any case, the blog is back in production node with the new fcgid with the following module section (based on this one from the mod_fcgid home page).

<IfModule mod_fcgid.c>
   DefaultInitEnv RAILS_ENV production
   <Directory /var/www/vir/syn.theti.ca/typo>
     FCGIWrapper "/var/www/vir/syn.theti.ca/typo/public/dispatch.fcgi" .fcgi
   </Directory>
</IfModule>

Hope this is helpful to others making the upgrade.

Always when I have to deal with RPM systems I feel so handicapped and it feels so wrong from multiple PoV.

This is a rant and a dear lazyweb (not that lazy, actually) type of post.

I would like to be able to have a few things solved when dealing with RPMs:

1. I would like a pbuilder like builder for specs
• I know about mock, but
• it accepts only src.rpm files (I know about rpmbuild -bs, but is broken, read further for the groovy details)
  
• I have some specs that have %include directives for the maintainer scripts and when rpmbuild -bs is ran, guess what, the extra files are left outside the src.rpm;oh yes, the directives are processed correctly for the binary rpm
• mock relies on bootstrapping a system using fedoralegacy.org, which was recently discontinued
• I have a redhat-9 chroot tarball which I would like to use and tell mock to use that without caring about upgrades (since my packages are not at all that dependent on the build system)
• mock fails to bootstrap even for fedora-devel-i386-core with the message "Cannot find a valid baseurl for repo: extras"
• the older versions fail to bootstrap because, apparently, it "Could not find useradd in chroot, maybe the install failed?"
• plague (how's that for irony?) relies on mock, which is broken
• mach seems to be deprecated
2. I would like a simple repo creation and maintainance tool, something in the line of mini-dinstall, which should have apt4rpm and yum support, but it seems that repos are still the "new shiny thing" which has no proper tools
3. I would like to be able to know from which version I am upgrading from the current package, not only that I am upgrading (in case you didn't knew, the only way to know that you are upgrading in a post/pre install/remove script, is the wonderful $1 parameter which indicates the number of packages installed after the script finishes or something along that line..
   

So my question is, is there any way to fix any of the issues above in a sane way, without me reimplementing apt-like functionality in rpm land?

So iPlayer, the BBC's on-demand 7-days TV download service, launched as Microsoft-only, despite the feedback to the trial service. They come along to events like hackday pretending to be our friends, but they're really not. It's more BBC Backdoor than BBC Backstage. My IMDB-listed friend Martyn Drake estimates the cost of using iPlayer as at least 215 for GNU/Linux users and you can't do it with free software. It seems to be even more expensive for a Mac.

"The BBC should remain impartial, but they're currently having hot patootie with Bill Gate and his chums in Redmond. They continue to use OUR license fee regardless of our objections to their dimwitted decision to use DRM, and now say they'll review the situation is six months. Thanks, BBC. Thanks a lot. Can I get some of my license fee back to afford these additional costs, please?"

No wonder the Open Source Consortium says they'll complain to the European Commission - it's blatent bundled sales. TV has got away with worse in the past (for example, Channel4-satellite requires you to buy Sky), but the BBC's TV-tax-funded services had been getting progressively freer. This latest reversal of that makes me wonder whether Freesat will be fully-viewable with free software. Also, they're up against another big problem: given a choice between the expensive and inconvenient legal iPlayer and the free and easy illegal torrents (which I'm told have US imported shows earlier), which will users choose? Surely not even the BBC's advertising power will overcome iPlayer's 200 quid bundled sale and auto-delete? Let them know it won't: petition the Prime Minister to open iPlayer. The BBC is a Royal Charter Corporation and should act in the public interest.

Well, the last day in Greece went swimmingly. It was mostly just relaxing, playing on the Internet, chatting with lovely Di, and working out logistics of taking a long flight back to the United States. The only strange thing about it is that I haven't slept since the last post, which is away from the norm. It's a kind of forced all-nighter caused by the bad scheduling that I made for myself. The flight from to Athens happened at 10:20pm in the evening. This was the latest flight that I could get and assure that I could get to the Athens airport in time for my 7:20 flight to Madrid, which connects through Chicago and back to Minneapolis at last.

I've spent a total of 10 days outside of the United States now, the longest time since I have been alive, according to my knowledge. It has caused some interesting results. I realized that I am inextricably connected to the people who I am familiar with in my life, and being without them decreases my mood significantly, and without contact to them decreases my mood sharply.

I am not alone in this fact. There are many studies that show that people who have more social connections lead happier lives. I am lucky in that I am technologically ept and can connect to my near and dear in a number of ways, and be resourceful in finding other ways to contact them if necessary. I feel that I am lucky to live in a time which it is possible for me to spend so much time apart and still be in connection with people. I am also lucky that I was born in a geological area which enables me to be as such.

At the same time, I am sad to leave this place. It is a nice area, with good food and a very long history. As Nikos reminded me the other day, it is the birthplace of Democracy, which I hold to a fairly high regard. It is also the birthplace of modern medicine, and a significant portion of many early sciences. The wealth of the nation as a whole and as parts is clear to me, and I wish to return.

I've learned part of the language while I am here, and it has made me more cognizant of communication with other cultures. People in Athens seemed put off when I tried to talk in Greek, but in Kos they were at the worst amused at my attempts. The language may not be as romantic to learn as French or Italian, and may not be as useful in the long term as Latin, but it would be interesting to speak nonetheless. I am tempted to start working on some of the i18n Greek QA issues in Debian -- It would help me learn the language more, and also keep me aware of the issues in software when you start working with other countries' characters. I have been lucky to be using a MacBook this entire time with decent Greek support, allowing me to type at least some greek while I was here. It helped me understand even more of the language - I now know mostly the numbers 1-9 at least.

The trip has highlighted for me something which is highly lacking in airports: power. Every airport that I have been to has prominently displayed the signs of wireless access, and has people using their laptops in almost every direction you can look (I am one of those), but they are sorely without power points for people who are using those laptops. This may be a designed flaw in order to save energy, but I don't really believe that 50 or even 5,000 laptops at 65-150W will put a significant dent in the power grid at somewhere as large as an airport, where LCD screens are running 24/7 with ads and bright lights illuminate every corner for all to be seen. I won't even start talking about the airplanes themselves.

All in all, the trip has been a happy one, and I would very much repeat it. I will make different decisions on lodging at some places and probably plan a shorter trip. I however wholly endorse Greece as a vacation spot, and even would consider moving here if offered a position (that would depend highly on Diana as well, obviously). I find it entirely favorable. I hope that this small series on the site has caused you, the reader some pleasure at least, even if it was at my expense.

Now begins the long trip home, on three planes and with 14.5 hours in the airplane and 18 hours in total. It'll be only 10 hours counting local time, unfortunately -- the jet lag will, I'm sure, be horrible.

Comments: (0) Trackbacks: (0)

Comments

1. No comments

Trackbacks

1. No Trackbacks

I just got a call from a "Katherine" at Mantech IT (or Mantec -- they can't seem to get their domain name synced up with their business name), claiming that they've previously supplied Java developers on contract to "your organisation", and having another one to palm off onto us. Now, anyone who has the slightest bit of knowledge of the company I work for would know that's a laughable proposition. We Don't Do Java. We also don't do enough software development that hiring programmers of unknown capability from a dodgy agency is an effective proposition for us. With my "WTF?" antennae twitching, I asked what company she thought I worked for. She mumbled something that could have been plausible, but I didn't really catch it. I said "pardon?", and she said "oh sorry" and hung up. Suffice it to say, I don't think that Mantech is a company you want to be dealing with (either as a candidate or a company) if this interaction is anything to go by. Sigh. Yet another "all recruiters are scum" data point. I'm getting quite a file by now.

Ben Green writes:

"All welcome to demo or watch, or get stuck in. 10am-4pm at the Trinity Centre Radio Studio BS2 0NW this Sunday 8th July. Please bring laptops and pluggable linux compatible sound kit. Small sets of speakers an headphones also good. We'll have access to 3 AMD64 machines with 64Studio installed. Please ask if you have any question, contact me through email or call Bristol Wireless to get other contact details, such as my mobile number. Entrance to the trinity will be through the back door, please be patient once you have rung as it's a long way from the radio studio to the back door. Ooo, and it's free. Cheers all, see you there."

(Seen on BBLUG)

With the development of rebuildd and the fact that several people are interested in re-using my scripts, I feel the need to explain how this stuff works. Grid’5000 First, Grid’5000 is a research platform used to study computer grids. It’s not really a grid (it doesn’t use all the classic grid middleware such as Globus). Grid’5000 is composed of 9 sites, each hosting from 1 to 3 clusters. Inside clusters, nodes are usually connected using gigabit ethernet, and sometimes another high speed network (Myrinet, Infiniband, etc). Clusters are connected using a dedicated 1OG ethernet network. Grid’5000 is in a big private network (you access it through special gateways), and one can access each node from any other node directly (no need for complex tunnelling). Using Grid’5000 nodes When you want to use some nodes on Grid’5000, you have to use a resource manager to say “I’d like to use 50 nodes for 10 hours”. Then your job starts. At that point, you can use a tool called KaDeploy to install your own system on all the nodes (think of it as “FAI for large clusters”). When KaDeploy finishes, the nodes are rebooted in your environment, and you can connect as root. At that point, you can basically break the nodes the way you want, since they will be restored at the end of your job. Running Debian QA tasks on Grid’5000 None of that was Debian-specific. I will now try to explain how QA tasks are run on Grid’5000. The scripts mentioned below are in the debcluster directory of the collab-qa SVN repository. When the nodes are ready, the first node is chosen to play a special role (it’s called the master node from now on). A script is run on the master node to prepare it. This consists in mounting a shared NFS directory, and run another script located on this shared NFS directory to install a few packages, configure some stuff, and start a script (masternode.rb) that will schedule the tasks on all the other nodes. masternode.rb is also responsible for preparing the other nodes. Which consists in mounting the same shared NFS directory, and executing a script (preparenode.rb) that installs a few packages and configures some stuff. After the nodes have been prepared, they are ready to execute tasks. To execute a task, masternode.rb connects to the node using ssh and executes a script in the shared directory. Those scripts are basically wrappers around lower-level tools. Examples are buildpackage.rb, and piuparts.rb. Now, some specific details:

• masternode.rb schedules tasks, not builds. Tasks are commands. So it is possible, in a single Grid’5000 job, to mix a piuparts test on Ubuntu and an archive rebuild on Debian. When another QA task is created, I just have to write another wrapper.
• Tasks are scheduled using “longest job first”. This doesn’t matter with piuparts tests (which are usually quite short) but is important for archive rebuilds: some packages take a very long time to build. If I want to rebuild all packages in about 10 hours, openoffice.org has to be the first build to start, since building openoffice.org takes about 10 hours itself… So one node will only build openoffice.org, and the other nodes will build the other packages.
• I use sbuild to build packages, not pbuilder. pbuilder’s algorithm to resolve build-dependencies is a bit broken (#141888, #215065). sbuild’s is broken as well (#395271, #422879, #272955, #403246), but at least it’s broken in the same way as the buildds’, so something that doesn’t build on sbuild won’t build on the buildds, and you can file bugs.
• I use schroot with “file” chroots. The tarballs are stored on the NFS directory. Which looks ineffective, but actually works very well and is very flexible. A tarball of a build environment is not that big, and this allows for a lot of flexibility and garantees that my build environment is always clean. If I want to build with a different dpkg-dev, I just have to:
  • cp sid32.tgz sid32-new.tgz
  • add the chroot to schroot.conf
  • tell buildpackage.rb to use sid32-new instead of sid32
• Logs and (if needed) resulting packages are written to the NFS directory.

Comments and questions welcomed :)

Arnaud and I finally managed to release Ruby D-Bus “Almost live from DebConf 7” 0.2.0. The release was planned for DebConf 7. However, I didn’t manage to get it ready in between all the talks, meetings, and other social stuff. Ruby D-Bus is an implementation of the D-Bus protocol in pure Ruby. After starting the development in February, it soon became apparent that several other projects were out there with about the same goal, such as Pure Ruby DBUS and R-Bus. Our approach is to have an API that is close to the old Ruby D-Bus bindings. While the other, similar projects seem to have a slightly different goal, we still invite them to come to some sort of merging so that no duplicate effort is put into three or four separate projects with almost the same result. The 0.2.0 release is our first real public release. We have a large subset of the features working and documented. The main focus of this release was to improve the API documentation and the tutorial. The 0.2.0 release is a release for exploratory purposes. We invite everyone interested to have a look at the API and inner works and provide us with feedback and/or patches. This means that the API can still change a bit over time based on feedback and tweaks performed by ourselves. So don’t built a big application on it just yet if you’re not willing to make some changes later on. For more information, see our project (Trac) page.

This past week I've been looking at various methodologies for the requirements phase of web application development. I've looked at UWE, NDT, WebML, Design-driven requirements elicitation and OOHDM. My interest in these has been sparked by an opportunity to readdress and better the process at work. My post here is to basically elicit some feedback from others who build web applications for clients in a professional environment and tell me what works for them.

More weekend stories: on Friday, we had a Geek Lunch at La ka to welcome Tara Hunt to Montreal. She's in town for a few days for Montreal Jazz Fest, and she asked to meet some people in the local Web/BarCamp/hacker scene. Lunch was good and interesting people came. Austin Hill made it, as well as Patrick Tanguay, Fred Ngo and Ben Yoskovitz, and Niko. I was especially glad to see Seb Paquet, who I don't get enough time with. All in all a good time was had. tags: montreal barcampmontreal tarahunt

Rest of the weekend Friday night John Usher came over for our weekly Pizza Night and we had beers until very late indeed. Saturday I got a nice glass desk for my office, and we got a big square wooden coffee table off of Montreal Craigslist. We went down to the Pont Jacques Cartier to see the fireworks on Saturday night, part of the International Fireworks Competition. Except there weren't any fireworks on Saturday night. Doh! Long walk home. Yesterday, Canada Day, we had our new neighbours Jake and Magda over for a get-to-know-you brunch. Jake is a structural engineer, and Magda is a professor of history at UQ M. They're expecting a baby any day now, so we figured it was a good idea to hang out with them before the madness begins. I made a couple of quiches, a big green salad, and some banana bread. It was a good meal. tags: montreal fireworks johnusher canadaday

Eweek has an article on a new 1TB Seagate drive. Most home users don’t have a need for 1TB of storage (the only way I’ve ever filled a 300G drive is by using it for multiple backups) and enterprise customers generally want small fast drives (with 100G drives still being sold for servers). One interesting thing to note about this is the fact that the new drive is described as being able to sustain 105MB/s (although I suspect that is only for the first few zones of the disk - see my ZCAV results page for graphs of the performance of some typical disks). The previous disks that I have seen have topped out at about 90MB/s. However even if the drive could deliver 105MB/s over it’s entire capacity it would take almost 3 hours to perform a backup - increases in IO speeds have not been keeping up with capacity increases. Another interesting thing is the potential for using the same technology in low power 2.5 inch disks. While a 1TB disk isn’t going to be much use to me a 300G 2.5inch disk that uses less power will be very useful - and it might be possible to perform a backup of such a disk in a reasonable amount of time! The latest trend in PCs seems to be small form factor (SFF) and low power machines that don’t have space for two drives. If you want RAID-1 on your home machines for reliability then that isn’t very convenient. But two 2.5 inch disks can fit in less space than a single 3.5 inch disk and therefore all the SATA based SFF machines that are currently being shipped with a single 3.5 inch disk can be upgraded to a pair of 2.5 inch disks - this will be convenient for me when those machines start going cheap at auction next year! Even for servers the trend seems to be towards 2.5 inch disks. I recently bought a 2U HP server that supports up to 8 hot-swap SFF disks, I wonder how the performance of 8*SFF disks would compare to 4 of the bigger and faster disks. The next thing we need is a method of backing up large volumes of data. The 650M data CD came out when a 150M disk was considered big. The 4.7G data DVD started to become popular when 45G disks were considered big. Now almost everyone has 300G disks and 1TB disks are becoming available yet the best commonly available backup method is a double-layer DVD at 9.4G - it seems that the vast majority of home users that make backups are using cheap IDE disks to do so. Fortunately there are some new technology developments that may improve the situation. Call/Recall has developed technology that may permit multiple terabytes of storage on an optical disk. It’s yet to be seen whether their technology lives up to the claims made about it, but we have to hope. The current storage situation is getting unmanagable.

Share This

I just released new version of Gammu. This release adds various fixes to AT phones driver and fixes various other crashes. Full list of changes:

• Initial support for Motorola phones (bug #15 and #310).
• Avoid work on uninitialized buffer when checking firmware.
• Use HTTP/1.1 requests for getting firmware and version info.
• Improve charset handling for AT phones.
• Fix crash on broken CPMS response.
• Fix reading of memory not starting from 1 (thanks to drgerafe).
• Fix pressing of keys on phones who do not support IRA charset.