Review: Agile Project Management with Scrum, by Ken Schwaber

Publisher:	Microsoft
Copyright:	2004
ISBN:	0-7356-1993-X
Format:	Trade paperback
Pages:	153

Ken Schwaber is one of the two original developers of Scrum and one of the signatories to the Agile Manifesto. Agile Project Management with Scrum is an introduction to Scrum by him that feels aimed primarily at business people (project managers, executives, line managers) rather than at technical people. There's very little about agile software development in general; the emphasis is on business process, team organization, and how the Scrum process looks to the rest of the organization. After an introductory chapter laying out the basics of Scrum, the remainder of the book is primarily case studies. Schwaber presents some principle and then discuss an anonymized case study that illustrates the principle. Each major Scrum role (ScrumMaster, Product Owner, and Team Member) gets their own chapter, interspersed with chapters on planning, reporting, and scaling. Finally, there are some concluding appendices laying out the rules of Scrum in more detail, adding a brief (and very disappointing) discussion of fixed-term, fixed-price contracts, and providing some other supplemental information. This is only the second regular book that I've read about Scrum, but my reading has been a bit out of order. We've been using Scrum for various projects for about a year and a half, I've played both team member and product owner roles, and we've been thinking hard about how to integrate Scrum more into the way we do development. My impression of this book is that it's intended as more of an introduction for people who aren't yet comfortable with Scrum or who are still struggling to make the pieces fit together. I'm therefore possibly not the target audience. Much of this book is a rehash of things someone who has studied Scrum will already know. I'm of two minds about the case study presentation style of this book. On one hand, it does help to make the points Schwaber discusses more concrete, and it's difficult to talk about business process in any other way. They're also more interesting and engaging than Schwaber's straight rule descriptions. But I had difficulty digging into most of the ones here. They're very simple and a little shallow, and I had trouble applying many of them to practical situations I might be in. I would have liked somewhat more detailed stories with more analysis and possible alternatives within the situation, rather than simple illustrations of how Scrum solves the problem that Schwaber had just said it would solve. What I did like about this book is that it provides the background and theory of Scrum as empirical process control much more clearly than any material I'd previously read. Schwaber is good at explaining what empirical process control is and why it's a superior approach, and he gave me new vocabulary and basic concepts to use to talk about Scrum. I also liked the high-level look from a management perspective without getting into the details of story points and velocity estimation (Schwaber doesn't use them at all in this book, relying instead on traditional "days of work" estimates). Much of my previous experience with Scrum was tightly focused on its advantages for estimation and responsiveness to changes, and it's nice to see some of the other advantages of Scrum (developer job satisfaction, improved focus, incremental deployment) highlighted more. Another part of this book I appreciated was the discussion of sprint length. Schwaber doesn't go into the possible alternatives, largely assuming that a month is the best interval, but the discussion of the impact and implications of a month sprint length helped me see the advantages of longer sprints. (To date, we've been doing either one week or two week sprints.) I came away with the feeling that a hybrid model where longer sprints are used for business purposes and then subdivided into shorter sprints for developer coordination might be particularly effective, although that's not an idea that Schwaber presents. This is not a particularly compelling read, particularly if, like me, you're not a huge fan of genericized case studies. Schwaber's writing is clear, but wooden and occasionally awkward, and the book is often dry. But it talks about Scrum from a management angle instead of a developer angle, which is an additional perspective that I found valuable. Possibly worth taking a look if you want more detail about Scrum from a high-level management perspective, although I don't think you're missing a lot by not reading it. Rating: 6 out of 10

long life to notmuch-mutt

• Bad news: I've just killed mutt-notmuch
• Good news: mutt-notmuch has been integrated upstream as a notmuch contrib script under the name notmuch-mutt
  (note the word switch, due to uniformity with other tools of the notmuch suite)
• Good news (for Debian users): starting with next notmuch upload there will be a Debian notmuch-mutt package. It will work out of the box with Mutt, without requiring any ~/.muttrc fiddling

As a consequence, no further separate releases of mutt-notmuch will be made. Future releases (of notmuch-mutt) will happen as part of notmuch. In other news, several changes have been implemented in notmuch-mutt wrt mutt-notmuch 0.2:

• move cache dir to ~/.cache/notmuch/mutt/ by default
  (Note: given that, from the point of view of notmuch, the next one will be the first release, no migration code from the previous cache location is present. Please switch to the new version and get rid of ~/.mutt-notmuch* manually.)
• support for XDG basedir, allowing to override the cache dir
• switch to String::ShellQuote for proper shell escaping in all notmuch calls
• system-wide Mutt configuration snippet for /etc/Muttrc.d/ (Debian-specific) or /etc/Muttrc

---

Many thanks to David Bremner (for shepherding my changes in) and to Ben Boeckel (whose desire to package mutt-notmuch in Fedora made me kick Debian bug #628018, this time for real).

Some Random WTFs The Daily WTF is an educational and amusing site that recounts anecdotes about failed computer projects. One of their stories titled Remotely Incompetent concerns someone who breaks networking on a server and is then granted administrative access to someone else s server by the Data Center staff [1]! In one of the discussions about that I saw people make various claims about Data Center security, such as claiming that having their own locked room helps. My experience indicates that such things don t do much good, I have often been granted access to server rooms without appropriate checks. My experience is that security guards on site generally don t directly do any good. I once had a guard hold a door for me when I was removing a server from a DC without even bothering to ask for ID! On another occasion in the Netherlands I had a security guard who didn t speak English unlock the wrong server room for me, I used hand gestures to inform him that I needed access to the room with the big computers and he gave me the access I needed! It seems that the benefit of security guards is solely based on scaring people who don t have the confidence needed to bluff their way in. Preventing children from thieving is a good thing, On another occasion I showed ID and signed in for access to a DC owned by my employer and I used my security key to go through a locked door with a sign that promised many bad consequences if I failed to lock the door behind me. Then I discovered that the back door was wide open for the benefit of some electricians who were working in the building. Presumably the electricians who had no security training were expected to act as ad-hoc security guards if someone tried to enter through the back door presumably they would not have been good at it. When a company uses part of their own office for a server room then many of these problems disappear. But a common issue in such ad-hoc DCs is the lack of planning and procedures, I have lost count of the number of times I ve seen doors (and even windows) propped open to allow ventilation because there were too many servers for the air-conditioning to cope. The most ironic example of this is the company that had a walk-in safe (think of a small bank vault with concrete walls and thick solid steel door) used for storing servers but with it s door propped open to allow cooling. The advantage of a serious hosting company is that they will have procedures for cooling etc and will be very unlikely to do strange and silly things. Having a locked room in a DC makes some sense, but if security guards have the master keys and are allowed to use them then it might not do much good. The one time I locked my keys in such a room I had a guard let me in without verifying my ID or the claim that there were actually keys locked in the room. Presumably anyone could just claim to have forgotten their keys and get the door unlocked just like a cheap hotel. Locking a rack sounds like a good idea, but the racks I ve seen have had locks which are quite easy to pick. On the one occasion when I had to pick a lock on a rack (due to keys being too difficult to manage for the relevant people) the security guards didn t investigate, so either the security cameras were not supervised or they just didn t care about people picking locks in a shared server room. Also if you allow people to do things freely in a shared server room they could install devices to monitor network traffic. A locked cage in a server room should work well. In the one case where I worked for a company that used such a cage I found it to mostly work well apart from the few weeks when the lock was broken. One company that I worked for had scales before the door between a server room and the car-park to prevent people from stealing heavy servers. Of course that wouldn t stop people stealing hard drives full of data which is worth more than the servers! Also an over-weight colleague had to have the scales disabled for him (as they were based on absolute mass not unexpected changes in an individual s mass) which presumably means that any skinny employee could steal a 2RU server and still be below the mass threshold. How to Solve some of these Problems Computers are subject to all manner of security problems. But they tend not to do arbitrary things for no apparent reason and they will never give in to someone who is charming, attractive, or aggressive unlike humans. I have servers running on Hetzner, Linode, and the Rackspace Cloud. I am always concerned about possible security compromises. But I am not worried about someone climbing in a window of a server room or convincing a security guard to let them in through the door. All three of those hosting companies have the vast majority of interactions automated. I can change many aspects of the servers without involving ANY human interaction. Out of the three of those companies I have had some human interaction with Hetzner (who provide managed servers) when a hard drive needed to be replaced obviously replacing a disk in the wrong server would have been a significant system integrity issue even though everyone would be running RAID-1 and if Hetzner improperly disposed of the broken disk then there could be security issues but this is an unlikely mistake in the face of a rare occurrence. With Linode and the Rackspace Cloud (and the previous Slicehost hosting that was purchased by Rackspace) the most common interactions I have with employees of those companies are when my clients don t pay their bills on time and that s an administrative not a technical issue. When I do have to contact the support people about a technical issue it s usually something that s not immediately connected to the virtual server (EG a loss of routing to the DC). It seems most likely that there are a fairly small number of people who are allowed in the DCs for companies like Hetzner, Linode, and Rackspace. Those people would probably be recognised by the security guards and their work would be restricted to replacing failing hardware and not involve granting access requests. There are some unusual requests that they can process (EG one of my clients recently transferred a virtual server between business units) but even in those cases the administrative software controls who gets access. This is much better than just handing hardware access to what seems to be the correct physical server to a client. If you have software running a few computers and operating correctly then you can probably scale it up to run thousands of computers and have it still work correctly. But if you have a team of people controlling access requests and want to scale it up significantly then there are huge problems in hiring skilled people and training them correctly. There is a real risk of security flaws in such administrative software, if someone managed to exploit the automated management system for one of those three companies then they could probably gain access to the private data of any of their customers. But the risk of this seems a lot less than the risk of general incompetence among humans who perform routine and boring tasks which have the potential for great errors.

• [1] http://thedailywtf.com/Articles/Remotely-Incompetent.aspx

Related posts:

1. The Security Benefits of Being Unimportant A recent news item is the hacking of the Yahoo...
2. Security Lessons from a Ferry On Saturday I traveled from Victoria to Tasmania via the...
3. Public Security Cameras There is ongoing debate about the issue of security cameras,...

I received the email yesterday and was like wow, I m in . I would like to thank:

• Raphael Hertzog and Roland Mas who motivated me to contribute to the Debian project in the first place.
• Sandro Tosi, who taught me a lot while I have been working on Reportbug.
• A huge, huge thanks to Piotr O arowski, who patiently sponsored all the packages I asked him to review.
• Xavier Oswald who allowed me to start the NM process.
• And finally a huge thanks to Martin Zobel-Helas and Holger Levsen who were my application managers.

Sorry for the other readers who will find this post boring, but it means a lot to me

One of features I wanted to introduce with Weblate is ability to do some quality checks while translating. We want contributors to have easy access to translating, but still we need to ensure some quality of translations. That's why Weblate comes with set of quality checks which are performed on every translation unit. The current set of checks (see documentation) is pretty basic and more might be easily added in the future pretty easily. There are two ways how checks are used in Weblate. During translating, if any of checks fires, translator stays on current translation with warning that something might be wrong. This is not a hard error as he still can be correct, but should at least prevent accidental mistakes like corrupted format strings or missing trailing colon. The other way is to do review of a translation. Failing checks are shown on each translation page or you can browse them by project to give you overview what can be wrong. For example with phpMyAdmin this helped me discover that there were few languages where almost half of translated strings are actually not translated but simply copied from English. There were also other problems like inconsistent translations across branches. All in all using these features helped me to improve quality of translations in phpMyAdmin quite a lot and I hope we will keep it for the future.

Filed under: English Phpmyadmin Weblate 2 comments Flattr this!

I own a DAS Ultimate S keyboard, and am very happy with it. Yes, the price tag is pretty high, especially when compared to those cheap keyboards you'll find in every bakery shop these days; but the difference in quality isn't something to be ignored. A while back, I got three PowerMac G4 machines from someone, so I could work on them for Debian. They'd been gathering dust for a while, since I'd been busy with other things, but this week I had a look at them. One of the three was incomplete; it lacked a video card. The other two, however, were quite usable. They came with MacOS 10.4.something, and one of them had a 40GB hard disk, while the other had an 80GB one. The disks were quite noisy, but I've already replaced them with a CF-IDE adapter, so now they're running off some solid-state storage, which should be at least somewhat faster, if not entirely efficient. However, installing a quality operating system on them proved to be somewhat harder than expected. When I connect the DAS keyboard to the PowerMac, put the Debian CD in the drive, and reboot the machine, it will eject the CD rather than trying to boot off of it. When I disconnect the keyboard, it will boot off the CD fine, but since OpenFirmware apparently doesn't support USB hotplugging, that means yaboot will sit there forever waiting for me to enter "install" and hit enter. When I replace the high-quality, 130-euro DAS keyboard with a cheap crappy "I don't know what a proper ISO layout looks like" 5-euro Logitech "keyboard", suddenly everything works as it should. Except that my hands hurt from trying to type on that thing, of course. I swear, Apple hates quality.

Conrad is readying his fabulous Armadillo C++ template library for linear algebra for a new 3.0.0 release, and started to make pre-releases. His version 2.99.1 came about a good week ago, it took us a few days to make a small required change in RcppArmadillo (which is our R package providing Armadillo to R via Rcpp) but our release 0.2.37 was ready last weekend. But then the good folks at CRAN did not want it. That is at the same time disappointing to us as developers / maintainers: work we do will not get pushed to largest number of users immediately. On the other hand, we do understand that CRAN is under a lot of strain. Years ago John Fox demonstrated exponential growth of packages at CRAN, the rate was then around 40% per year. Right now the number of packages exceeds 3600, and there are often several dozen daily updates (which you can follow with the CRANberries service for html and rss I had set up years ago). And the three CRAN maintainers all have full-time jobs as academics, and they also happen to be busy R Core members. Plus the new R version 2.15.0 is to be released at the end of the week, and this usually entails a number of package changes, putting extra strain on CRAN right now. For more on new or updated CRAN policies, see this long thread. Now, as I wrote on the rcpp-devel list, there is of course always install.packages("RcppArmadillo", repos="http://R-Forge.R-project.org") for a direct installation from R-Forge. But as I just put 0.2.38 there, it may take the running of the batch updates on the site so if you want it now, follow this link to my local Rcpp archive. All that said, here are the NEWS entries for these two last releases:

0.2.38  2012-03-28
    o   Upgraded to Armadillo release 2.99.2 "Antarctic Chilli Ranch (Beta 2)"
          * added .i()
          * much faster handling of .col() and .row()
          * expressions X=A.i()*B and X=inv(A)*B are automatically converted
            to X=solve(A,B) 
0.2.37  2012-03-19
    o   Upgraded to Armadillo release 2.99.1 "Antarctic Chilli Ranch (Beta 1)"
          * added non-contiguous submatrix views
          * added hist() and histc()
          * faster handling of submatrix views
          * faster generation of random numbers
          * faster element access in fixed size matrices
          * better detection of vector expressions by sum(), cumsum(),
            prod(), min(), max(), mean(), median(), stddev(), var() 

As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

I have a few thoughts based on the yet another round of debate where marketing clashes with free software advocation and technical details. Nothing new in the debate itself, but I'm adding a couple of insights.

Marketing is not highly respected by many technical people, and neither by the people wanting more advocating than the messing up with facts and feelings that the marketing does. I'm all for advocating free software, but it's currently not something you can use for marketing to win big markets. If we advance to a world where free software is as wanted as the green values today are, it can be used in marketing as well similar to all the ecological (according to the market department at least) products today, but alas the benefits of free software are not yet as universally known. Since it doesn't say much that touches the masses, advocating has a negative marketing effect since it takes space away from the potentially "hitting" marketing moves, in those cases where you target the big masses in the first place. "Open" this and that has some marketing power in it nowadays, but it's a mess of different meanings that probably doesn't advance libre software freedoms as such. Wikipedia has probably been the biggest contributor to advancing general knowledge of software and culture libre. Disclaimer: I'm not a proper marketing person, some more professional might have better insights in this area. If I'd be a proper marketing person, I'd decorate this blog post with fancy pictures so that more people would actually read it.

Some of the marketing can be done without sacrificing any of the advocation. The fabulous Fedora campaigns, graphics, slogans and materials are a great example of those and do an important job, even though Fedora isn't reaching the big masses with it (and Fedora isn't targeted for OEMs to ship to millions either). But they do hopefully reach a lot of level people on the grassroots level. I hope as a Debian Developer that more people valuing the freedoms of free software would help also Debian as a project to reach more of its advocation potential and developers from the more proprietary world. But I'm happy that at least some free software projects have nowadays true graphical and marketing talent. Even though not as widely known, freedoms of the software users including for example privacy aspects are a potential good marketing tool toward a portion of the developer pool.

Let's not forget that Android conquered the mobile market without using the brand power of Linux. The 30+ million people who know Linux a bit deeper than just "I've heard it" already run a Linux distribution like Ubuntu, but we need hotter brands than a project name of a kernel to reach the bigger masses. Call it Ubuntu, Fedora, or something, but no matter do what it needs to ship it to millions. AFAIK mostly Ubuntu and SUSE are shipping currently via desktop/notebook OEMs, and more Ubuntu than SUSE. Others aren't concentrating on the market, which is a very difficult one. Ubuntu is doing a lot more mass population advocating for free software than Android has ever done. Note for example the time any user tries to play a video for the first time in a non-free format - Ubuntu will tell the user about the problems related to those formats and asking a permission to install a free software player for those (or buy licensed codecs), and the Ubuntu Help texts describe a lot of details about restricted formats, DRM et cetera. Not to mention what happens if the person actually wanders into the community, discovering Debian, other free software projects, free software licenses and so on. Meanwhile Android users never notice anything being wrong while watching H.264 videos or watching DRM Flash videos. Granted, like Boot2Gecko debate shows, it may be a partially similar situation on shipping desktop Linux variants as well, in order to actually ship them via partners.

Anyway, the best example of brands is MeeGo. Even the LWN editor does not get into dissecting the meaning of MeeGo on Nokia N9, because "there has been no real agreement on that in the past", but just uses the brand name as is. That is the power of brands. Technical people debate that it's not really MeeGo, it's maemo GNU/Linux with a special permission from Linux Foundation to use the MeeGo brand name, and then counter-argument with that the MeeGo is an API and maemo matches the MeeGo 1.2 API which is actually just Qt 4.7 API. And actually, as proven by the LWN example, it's not even "technical people". For most of technical people Nokia N9 is MeeGo as well. Only the people who have actually worked on it plus the couple of other people migrated from maemo and MeeGo.com communities to Mer project understand the legacy, history and the complete difference between the Maemo Harmattan platform and what MeeGo.com was. Yet at the same time like all GNU/FreeDesktop.org/Linux distributions, they are 95% same code, just all the infrastructure and packaging and polishing and history is different.

For 99.9% of people who know what MeeGo is, MeeGo is the cool Nokia smartphone, one of its kind and not sold in some of the major western markets, and/or the colorful sweet characters of meego.com shown at one time on a couple of netbooks. That is the brand, and the technical details do not matter even to the technical people unless they actually get into working on the projects directly.

To most people, the Linux brand is a mess of a lot of things, while other brands have the possibility at least to have a more differentiating and unique appearance.

And a personal reboot. <article> All my life, so far, I've always prided myself on not having any regrets. I've told people that if I had to live my life over again, I would not change how I had acted or anything I had done. Over the last few days I've come to regret my actions. They have caused me to hurt a dear friend and, then, ultimately lose them. It all stems with not being honest. To my friend. And to myself. By not telling myself the truth about how I feel, or what I want, it has meant I have not told others the truth either. They have then acted on what I said, and when I've changed my tune or wanted more (or less), they are rightly upset. I wish I could say that this was a new thing. Like some kind of habit I picked up because it was shiny. Unfortunately as I review my life, and the various people who have come into and out of it, I can see that my inability to be truthful has been mostly constant. To be unable to articulate my needs has caused various amounts of pain to others. Sometimes that pain has come back to me, as with my friend, magnified. Other times I have escaped it. This is a personal apology from me to all that I've hurt. Some of those people are (now) deceased. Some of them no longer talk to me / interact with me at all. For what it is worth. Sorry. For those of you who are still with me, on this journey, thank you for putting up with how I have been in the past. The journey is not over but I hope the rest of it will be more truthful and, ultimately, less hurtful. Anand </article>

Today we released Epiphany 3.4. It includes all the fixes, enhancements and new cool features that we build since September 2011. That is 6 months of cool stuff! Xan already explained the bigger picture but I want to highlight some details in the spirit of Every Detail Matters. Improved location bar, and the new history backend The location bar suggestions now load extra-extra-fast, thanks to our new SQLite backend. Besides being extra fast, SQLite allows us to make complex queries to offer better results in the completion. Goal for 3.6: to successfully handle searches like that page, with the dog, you know, that one with the funny one . This also makes possible to have a cool Overview start page for 3.6. Much like Chrome or Opera do. An awesome UI: cleaner toolbar, loading progress That is all the chrome you are getting, kid! Less distractions, more web! All the usual tools are still available in the gear menu: Oh, and this other one is a pretty one. Check out the new load progress indicator: You might have already noticed the combined stop/reload button. Some other niceties like the new link tooltips are all over the place. I will not ruin the surprise . Reliable download icons This is my friend Juanjo:
He is always happy. One day he said: Diego, my PDF documents are shown as boxes while downloading. It makes me mad! I want Juanjo to keep that happy hacker smile. So I decided to fix this. Downloads now have a better idea of the icon they should show: Page icons, now a WebKitGTK+ feature Do you notice something? Yeah, icons for every of the loaded pages. The support for this is now in WebKitGTK+, available to other applications. This means it is better supported and maintained! Redesigned about: pages For a time now we have had some geeky about: pages. One for memory (about:memory), one for plugins (about:plugins), and perhaps the most useful one, one to manage applications (about:applications): And, last but not least Less lines:

$ git diff --shortstat 3.2.0..3.4.0
328 files changed, 73211 insertions(+), 104528 deletions(-)

Unlike other browsers, Epiphany does not have dozens of engineers behind the project. This means that the more code we have to maintain, the less time we have to develop new features and to even maintain that code! Also, this makes Xan happy. But luckily Igalia has hackers like Martin Robinson who are willing to show us how hacking should be done: Epiphany 3.4.0, alias, Web. Is an awesome release. It will soon be in your distro of choice. Thanks Allan for the screenshot help!

phpMyAdmin 3.5 should be released on April 7, 2012, so let's again look at translations status. Here comes sixth round of translation status update. Since last update we have two more translations summing up to 11 translations at 100%:

• Czech
• English (Great Britain)
• Estonian
• French
• Greek
• Japanese
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are few which are really close to 100% and I hope they will get there soon:

• Chinese
• Danish
• Dutch
• German
• Italian
• Polish

As you can see, there is still lot of languages missing, this might be your opportunity to contribute to phpMyAdmin. Also you are welcome to translate phpMyAdmin 3.5 using translation server.

Filed under: English Phpmyadmin 0 comments Flattr this!

Until recently I've had a Canon EOS 1000D, my starter-camera, and a Canon EOS 40D which is my real-camera. The 40D is older, but it probably counts as a "semi-pro" body, albeit an old mid-range one. From an image size point of view there isn't too much to tell them apart - both produce 10MP images. But from a hardware and ease of use sense the 40D has several key features which made it a compelling upgrade:

• Dual controls. So we can use one wheel for shutter speed, and one for aperture size.
• Better feeling body, which is slightly larger and more solid.
• Top display for instantly obvious settings.

Anyway both these cameras have been my friends for the past year or two, although I did buy a toy camera for those times when I didn't want to carry the DLSR around. I've made sure I only bought "posh" lens, including the fabulous and horrifically expensive 70-200 f/2.8 MK 2 lens (Just short of 2000) and I'd been wanting to use those on a full-frame camera. Now it is upgrade time once more and I've just bought the EOS 5D MK II - a full-frame camera which means I don't have to worry about crop-factors any more. So far I've only had it a couple of days but I'm in love. The output images are 21MP so I get far fewer to a (CF) card. But the detail is sublime. Future portraits and photos of people will be wonderful - although I hope they already are to a large degree! This upgrade was a hard choice. The 5D is a full-frame, but a little slow. (Faster than my 40D by a hairs-bredth) The alternative would have been a 7D which is fast, and wonderful, but still uses a cropped sensor. Given that I have fast lenses and don't do sports (often) the 5D seemed like the sanest approach. For my reference - my Canon serial numbers:

EOS 1000D	1780312242
EOS 40D	1230734041
EOS 5D MK II	4131916951

ObQuote: "Courage is only required when facing that which you fear. " -Stargate: The Ark Of Truth

The last release of vmfs-tools (0.2.1) was almost 2 years ago. It was about time to bring some of the changes that have been available in the git repository in an official tarball. So here it is. It brings some limited VMFS 5 support and experimental extent removal, as well as some deep changes to the debugvmfs tool and various fixes. Next release (0.2.6) will have a fixed fsck, which, while it still won t fix file system inconsistencies, should at least report actual inconsistencies (which is far from being true currently). I won t give any estimation as to when this will happen, though.

This is an annoucement that I am moving to my 4096 bit RSA GPG key AA544AA1, henceforth please try and use this.

I created and have (sparingly) been using this key ever since SHA1 was found to be weak, and larger RSA keys and stronger signatures began to be the norm. There weren't many signatures on the key and the WOT was not strong but it looks good now. The older key in the Debian keyring (1D389887) has also been replaced with the new key and I will revoke it when the number of signatures on the new key crosses those on the old key (that might be in an year or two, I suppose).

Fingerprint information:

Current key:

pub 1024D/1D389887 2006-04-08
Key fingerprint = 5B6B F223 B769 63E9 E2CB 0A3F E1EB BEA5 1D38 9887
uid Y Giridhar Appaji Nag <giridhar@appaji.net>
sub 2048g/73EAF0B5 2006-04-08
sub 2048R/DBBECADC 2009-04-04

New 4096R key:

pub 4096R/AA544AA1 2009-05-22
Key fingerprint = BF81 3A99 E07C D0F8 653D 9666 A8D2 CD13 AA54 4AA1
uid Y Giridhar Appaji Nag <giridhar@appaji.net>
sub 4096R/843A5776 2009-08-08

If you're in the habit of doing sudo debi at the end of a build, it's worth noting a complication with Multiarch.

Sometimes, it's tempting to rebuild (and install) a shared library with a few untested changes, however, if (like me), you have multiarch packages installed, this can cause a surprise:


dpkg: error processing ../libqof2_0.8.4-2_amd64.deb (--unpack):
trying to overwrite shared '/usr/share/doc/libqof2/changelog.Debian.gz', which is different from other instances of package libqof2:amd64


Bumping the changelog doesn't help:


dpkg: error processing libqof2:amd64 (--install):
package libqof2:amd64 0.8.4-3 cannot be configured because libqof2:armel is at a different version (0.8.4-2)
dpkg: error processing libqof2:armel (--install):
package libqof2:armel 0.8.4-2 cannot be configured because libqof2:amd64 is at a different version (0.8.4-3)


The fix for this is, of course, to remove libqof2:armel and all it's reverse dependencies and the packages can't be put back until you've built an armel version of your changes.

The way to backout the test change is a bit longwinded, depending on the complexity of your library:


sudo apt-get --reinstall install libqof2:amd64=0.8.4-2 libqof-dev:amd64=0.8.4-2 libqof2-backend-qsf:amd64=0.8.4-2 libqof2-backend-sqlite:amd64=0.8.4-2 libqof2-dbg:amd64=0.8.4-2 libqof2:armel=0.8.4-2


Hmm. I think a helper tool could be needed in the medium term here.

This also means that cross-building Emdebian Crush packages from a Wheezy / Wheezy+1 base is again looking as if it will need to happen inside a chroot, albeit with problems for the packages which are dependencies of the build tools (or the cross toolchain) itself, as the Crush packages will inevitably contain modified files. (For example, Emdebian Policy differs from Debian Policy by requiring - not forbidding - compression of debian/copyright.)

Cross-building packages which are intended to be binary compatible with Debian without conversion (including cross-built packages to use on top of Emdebian Grip) shouldn't be too affected. You just need to ensure that where the package exists in two or more versions, all installed architectures are built before any architecture is installed.

This is an additional burden compared to the world of dpkg-cross but it is key to how Multiarch allows cross-building to use sensible dependency resolution.

So, what I think we'll need is an enhancement to debi which can be passed an architecture (possibly an architecture list), debi then looks for both the native arch and the requested architecture(s), fails> if the .changes file for the extra architecture(s) isn't found or proceeds to install all packages for the native arch and arch-dependent packages for the second architecture in the same dpkg operation. As a further enhancement, debi might be able to check dpkg --print-foreign-architectures, check the output of $package:$arch against dpkg -l and either complain or automatically use the Multiarch support to look for the relevant .changes files. debi may even want to check the package (as it's working in the package top directory usually) for Multiarch support before accepting the architecture list option.

Think I need to do some reading of the debi source and see if a patch is workable...

During the last month I worked as upstream maintainer of LADI Tools and now I m happy to introduce the first stable release! So, to answer the usual question What s new? , here is a short description of the changes introduced (taken from the NEWS file included in the release tarball): Laditools 1.0 Lady O Apart from wladi and g15ladi, most of ladi* tools have been renamed:

• ladicontrol -> ladi-control-center
• ladilog -> ladi-system-log
• laditray -> ladi-system-tray

Moreover, a new component has joined the LADI Tools suite: ladi-player. LADI Player is a convenient, graphical VLC-style application providing an all-in-one control interface to start, stop and monitor JACK as well as the session handler. It also provides basic controls for managing studios. Goodbye PyGTK! All the code was ported to GTK+ 3 and the new GObject Introspection mechanism. Code refactoring and cleanup The code has been reorganized in order to allow the use of Python objects by 3rd party applications. To start writing code using the classes provided by laditools, simply do the following: from laditools import * Two-in-one solution for LADI System Tray Formerly laditray was an implementation of GtkStatusIcon to put a nice right-clickable icon into the system tray to allow users access JACK controls easy way. It s been mostly rewritten and now it shows an AppIndicator icon (if the library is available), or fall back to the Freedesktop.org s old-fashioned System Tray Protocol Spec-compliant icon. Project s new homepage The project s homepage is now hosted by Launchpad.net, the code is hosted by repo.or.cz and it s available here for browsing.
Please use the following links to contact the development team:

• Bugs and patches
• Translations

New up-to-date packages will hit both Debian and Ubuntu soon!

There were no big updates from me on Weblate this week. I decided to settle down a bit and focus on bringing it close to 1.0 release. I plan to release 0.8 in one or two weeks, which should include all features. After it receives some testing and bug fixes, 0.9 will be released and if no major problems occur 1.0 will follow shortly. Right now most of the core for all features is prepared, just some user interface is missing for most of them. The 0.8 release will come with rewritten full text search (now is based on Whoosh), changes tracking (for possible review of changes made by others) and built in dictionary for frequently used terms. Along with these changes there are smaller ones as well like improvements to various consistency checks, cleaned up translate page or faster loading of translation services. Anyway if you feel something is done wrongly, it is now last chance to complain so that it is possible to do some bigger change for 1.0 release.

Filed under: English Weblate 0 comments Flattr this!

There are some really good Network Attached Storage (NAS) devices on the market. NetApp is one company that is known for making good products [1]. The advantage of a NAS is that you have a device with NVRAM for write-back caching, a filesystem that supports all the necessary features for best performance (NetApp developed their own filesystem WAFL to provide the features they needed), and a set of quality hardware that has been tested and certified to work together. If you want a cheap NAS then you end up with something running Linux with GPL filesystems. This isn t a bad thing as such, but some of the best performance and data integrity features are available in ZFS (which isn t GPL) and BTRFS (which isn t ready for production use). Not to mention WAFL which has been providing ZFS/BTRFS type features for more than a decade. A cheap NAS will generally be sold without disks as this is the best way to keep costs down. Selling with disks either means selling lots of different variations (which means it can t be sold off the shelf) or selling packages that don t quite suit some customers (thus causing people to buy the device and replace the disks which means extra costs). This means that the vendors can t provide the guarantees about disk quality and suitability that NetApp can provide. One major problem with a NAS is that you typically can t get shell access. Commands such as rm -rf and cp -rl which are typically rather quick when performed locally can take ages when run over NFS. Also commands such as grep -R which can perform reasonably well over NFS will always perform better when run locally. Also tasks such as compiling big programs which require good disk speed as well as some CPU time can be run locally if you have a file server system that also has local accounts (IE a typical multi-user Unix server configuration), but a dedicated NAS will prevent that. I have never used a NetApp device due to my clients deciding (sometimes correctly and sometimes incorrectly IMHO) that they are too expensive. But when considering what my clients do the down-sides of lacking local code execution on a NetApp would be more than compensated in many cases by the significant performance and reliability advantages that they offer (see my post about the reliability issues in standard RAID implementations [2]). A server class system (with ECC RAM as a minimum criteria) running RAID-6 can be a fairly decent file server. That requires hardware RAID with NVRAM for the write-back cache for decent write performance, but when write performance isn t required software RAID does the job quite well. A Dell tower system will typically hold at least 4 disks which means 6TB of RAID-6 storage and is quite cheap it can be under $2000. also such a system can be easily expanded with extra Ethernet ports etc. NetApp doesn t sell products directly and doesn t list prices, but they do have some adverts for products being under $7500 . That s not really cheap but not THAT expensive when you consider the features. A hidden cost in running a NAS is having someone perform sysadmin work on it. For a relatively expensive device that offers significant features such as a NetApp Filer this expense probably isn t too great. But for a device that does what any PC running Linux can do it s noteworthy that more training or experimenting time is required. There are some special cases where small and cheap NAS appliances really make sense, such as the Apple Time Capsule for home network backups. But apart from that I don t think that cheap NAS appliances make sense. It seems that cheap NAS devices provide the biggest down-sides of expensive NAS devices (in terms of lacking local access and having a different administration interface to servers) while also having the biggest down-sides of PC servers (lacking the advanced features of WAFL and performance of a NetApp). Earlier today I started a process of reorganising some backups which included backups to a cheap NAS. I have been very unimpressed by the time taken to copy and rm files over NFS. I m sure that the job would have been completed hours ago if I had local root access to the NAS.

• [1] http://www.netapp.com/
• [2] http://etbe.coker.com.au/2012/02/06/reliability-raid/

Related posts:

1. big and cheap USB flash devices It s often the case with technology that serious changes occur...
2. Insider Threats and Small Storage Devices Danny Angus writes about the potential threat posed by small...
3. Some RAID Issues I just read an interesting paper titled An Analysis of...

J rg is a very active contributor within Debian, and has been for a long time. This explains why he holds so many roles (FTPmaster and Debian Account Manager being the 2 most important ones) Better known as Ganneff (his IRC nick), he s not exactly the typical hacker. He has no beard and used to drink milk instead of beers. Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager. Raphael: Who are you? J rg: My name is J rg Jaspert and I m 35 years old working for a small company doing system administration and consulting work for our customers. I m married for a little while now and sometime soon a little Ganneff will be crawling out of my wife. (Whoever didn t think of the movie Alien now is just boring). Raphael: How did you start contributing to Debian? J rg: I started using Debian somewhere around 2000, 2001. Before that I had the misfortune to try SuSE and RedHat, both with a user experience that let me fully understand why people think Linux is unusable. (Due to my work I m in the unfortunate situation to have to use RedHat on two machines. Funny how they are still utter crap and worse than bad toys). And all of this lets get a Linux running here came up because I was trying to find a replacement for my beloved OS/2 installation, which I had for some years. So after I got Debian installed, good old Potato, I got myself active on our mailing lists, starting with the German user one. A bit later I replied to a question if someone can help as staff for a Debian booth somewhere. It was the most boring event I ever visited (very nice orga, unfortunately no visitors), but I got a few important things there:

• a signature from a DD on my key (Hi grisu),
• a discussion with an upstream author with some useful piece of software to package and
• an impression that this can be fun, if there are just some visitors for an event. So I tried again and did help as staff on a LinuxTag booth a while later.

The software I packaged, found me a sponsor and voila, maintainer I was. Some more packages got added and at some point my sponsor turned out to be my advocate. The NM process run around 2 months, and mid April 2002 I got THE MAIL. Raphael: Some Debian developers believe that you have too many responsibilities within Debian (DAM, FTPMaster, Debconf, Partners, Planet Debian, Mirrors, ). Do you agree that it can be problematic, and if yes, are you trying to scale down? J rg: It s DebConf, tssk. And yes, I do have some extra groups and roles. And you even only list some, leaving out all I do outside Debian. But simply counting number of roles is a plain stupid way to go. Way more interesting is how much work is behind a role and how many other people are involved. And looking at those you listed I don t see any I am a SPOF. Let s look at those you listed: DAM: Here I did start out assisting James to get the huge backload down which had accumulated over time. Nowadays I am merely the one with the longest term as DAM. Christoph Berg joined in April 2008 and Enrico Zini followed during October 2010, both very active. Especially Enrico, lately with the redesign of the NM webpages. FTPMaster: The basic outline of the FTPMaster history is similar to the DAM one. I joined as an assistant, after the oh-so-famous Vancouver meeting in 2004. Together with Jeroen, we both then got the backload down which had accumulated there. He did most of the removals while I had a fun time cleaning up NEW. And we both prepared patches for the codebase. And in 2007, as the last action as DPL, Sam made me FTPMaster. Since then I haven t been alone either. In fact we have much more rotation in the team than ever before, which is a good thing. Today we are 3 FTPMasters, 4 FTP Assistants and 1 Trainee. Though we always like new blood and would welcome more volunteers. DebConf: I am very far outside the central DebConf team. I am not even a delegate here. Currently I am merely an admin, though there are 4 others with the same rights on the DebConf machines. I ve not taken any extra jobs this year, nor will I. Probably for next year again, but not 2012. Planet: I am one of three again, but then Planet is mostly running itself. Debian developers can just edit the config, cron is doing the work, not much needed here. Occasional cleanups, every now and then a mail to answer, done. In short: No real workload attached. Mirrors: My main part here is the ftpsync scriptset. Which is a small part of the actual work. The majority of it, like checking mirrors, getting them to fix errors, etc. is done by Simon Paillard (and since some time, Raphael Geissert is active there too, you might have heard about his http.debian.net). Having said that, there is stuff I could have handled better or probably faster. There always is. Right now I have 2 outstanding things I want to do a (last) cleanup on and then give away. Raphael: You got married last year. I know by experience that entertaining a relationship and/or a family takes time. How do you manage to combine this with your Debian involvement? J rg: Oh well, I first met my wife at the International Conference on OpenSource 2009 in Taiwan. So OpenSource, Debian and me being some tiny wheel in the system wasn t entirely news to her. And in the time since then she learned that there is much more behind when you are in a community like Debian, instead of just doing it for work. Even better that she met Debian people multiple times already, and knows with who I am quarreling Also, she is currently attending a language school having lots of homework in the evening. Gives me time for Debian stuff. How that turns out with the baby I have no idea yet. I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject), but it might take a day or twenty before it gets so far. Raphael: Thanks to the continuous work of many new volunteers, the NEW queue is no longer a bottleneck. What are the next challenges for the FTPmaster team? J rg: Bad link, try this one. Also, no longer sounds like its recent. It s not, it s just that people usually recognize the negative only and not the positive parts. Well, there are a few challenges actually. The first one, even if it sounds simple, is an ongoing one: We need Debian Developers willing to do the work that is hidden behind those simple graphs. Yes, we are currently having a great FTP Team doing a splendid work in keeping that queue reasonably small this is a/THE sisyphean task per excellence. There will always be something waiting for NEW, even if you just cleaned the queue, you turn around and there is something else back in already. Spreading this workload to more people helps not burning one out. So if one or more of the readers is interested, we always like new volunteers. You simply need to be an uploading DD and have a bit of free time. For the rest we do have training procedures in place. Another one is getting the multi-archive stuff done. The goal is to end up with ONE host for all our archives. One dak installation. But separate overrides, trees, mirrors, policies and people (think RMs, backports team, security team). While this is halfway easy to think of in terms of merging backports into main it gets an interesting side note when you think of merging security into main . The security archive does have information that is limited to few people before public release of a security announce, and so we must make sure our database isn t leaking information. Or our filesystem layer handling. Or logs. Etc. Especially as the database is synced in (near) realtime to a DD accessible machine. And the filesystem data too, just a little less often. There is also a discussion about a good way to setup a PPA for Debian service. We do have a very far developed proposal here how it should work, and I really should do the finishing touches and get it to the public. Might even get a GSoC project on it. So far for some short to middle term goals. If you want to go really long term, I do think that we should get to the point where we get rid of the classical view of a source package being one (or more) tarballs plus the Debian changes. Where a new version requires the full upload of one or more of those parts of the source package. I don t know exactly where it should end up. Sure, stuff like one central DVCS, maintainers push there, the archive generates the source tarballs and prepares the mirrors do sound good for a quick glance. But there are lots of trouble and pitfalls and probably some dragons hidden here. Raphael: The Debian repositories are managed by DAK (Debian Archive Kit) which is not packaged. Thus Debian users pick tools like reprepro to manage their package repositories. Is that how things should be? J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does, though yes, DAK is not exactly a quick-and-easy thing to install. But nowadays it is a trillion times easier than the past thanks to Mark s work people can now follow the instructions, scripts and whatever they find inside the setup directory. Still, it really depends on the archive size you are managing. A complex tool like dak does not make sense for someone who wants to publish one or a dozen of his own packages somewhere. Thats just like doing a finger amputation with a chainsaw it certainly works and is fun for the one with the chainsaw but you probably end up a little overdoing it. I myself am using dpkg-scan[packages sources] from a shell script but also mini-dinstall in places (never got friend with reprepro when I looked at it). Works, and for the few dozen packages those places manage it is more than enough. Also, using dak forces you into some ways of behaviour that are just what Debian wants but might not be what a user wants. Like inability to overwrite an existing file. One of the reasons why mentors.debian.net won t work with dak. Or the use of a postgres database. Or that of gpg. Sure, if you end up having more than just a dozen packages, if you have many suites and also movement between them, then dak is sure a thing to look at. And how should things be : however the user and admins of that certain install of reprepro, mini-dinstall, dak, whatever want it. This is not one-tool-for-all land Raphael: What is the role of Debian Account Managers (DAM)? Do you believe that DAMs have a responsibility to shape Debian by defining limits in terms of who can join and what can be done within Debian? J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:

The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.

Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Or my current job. Or a GR against me. Not many running around with that badge, though I m still missing my own personal Serious problems with Mr. Jaspert thread. Bad you all.
Or visited so many places. Think of all the DebConfs, QA meetings, BSPs and whatever events.
Or met so many people.
Or learned so many things I would never even have come near without being DD. Raphael: Is there someone in Debian that you admire for their contributions? J rg: Yes.

---

Thank you to J rg for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.