Search Results: "pm"

25 February 2009

Theodore Ts'o: Binary-only device drivers for Linux and the supportability matrix of doom

I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn t feel he could do that. In his words:
I m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack. Which makes it painful to both me and my customers to regularly upgrade the kernel. Not to mention the EMC supportability matrix of doom.
That pretty much sums it all up right there. The good news is that I ve been told that dm-multipath is almost at the point where it has enough functionality to replace PowerPath. Of course, that version isn t yet shipping in distributions, and I m sure it needs more testing, but it ll be good when enterprise users who need this functionality can move to a 100% fully open source storage stack. About the only thing left to do is to work in a mention of the Frying Pan of Doom and the recipe for Quick After-Battle Triple Chocolate Cake into the mix. :-) Related posts (automatically generated):
  1. Tip o the hat, wag o the finger Linux power savings for laptop users It s interesting to see how far, and yet how much...
  2. How active are your local Linux User s Groups? At the Linux Foundation, I recently had been brainstorming with...

Theodore Ts'o: Binary-only device drivers for Linux and the supportability matrix of doom

I came across the following from the ext3-users mailing list. The poor user was stuck on a never-updated RHEL 3 production server and running into kernel panic problems. He was advised to try updating to the latest kernel rpm from Red Hat, but he didn t feel he could do that. In his words:
I m caught between a rock and a hard place due to the EMC PowerPath binary only kernel crack. Which makes it painful to both me and my customers to regularly upgrade the kernel. Not to mention the EMC supportability matrix of doom.
That pretty much sums it all up right there. The good news is that I ve been told that dm-multipath is almost at the point where it has enough functionality to replace PowerPath. Of course, that version isn t yet shipping in distributions, and I m sure it needs more testing, but it ll be good when enterprise users who need this functionality can move to a 100% fully open source storage stack. About the only thing left to do is to work in a mention of the Frying Pan of Doom and the recipe for Quick After-Battle Triple Chocolate Cake into the mix. :-) Related posts (automatically generated):
  1. Tip o the hat, wag o the finger Linux power savings for laptop users It s interesting to see how far, and yet how much...
  2. How active are your local Linux User s Groups? At the Linux Foundation, I recently had been brainstorming with...

Andrew McMillan: Conference Audio: Problems, Procedures & Suggestions for the Future

I was going to reply to this in the mailing list, but after I spent half an hour furiously typing this, I thought it might be better to put it into a blog, for a slightly wider audience, perhaps a more permanent life and partly in an effort to end this thread on a more or less constructive note. The backchat for this is that the LCA 2009 video has started to go up on the web, and some talks have some gaps in the audio stream... Russell Coker wants to make a constructive suggestion, as follows: On Wed, 2009-02-25 at 18:02 +1100, Russell Coker wrote:
>
> I've pasted in the below paragraph (the third time I've included it in this
> thread) to reiterate my point. Note that I am not asking you to re-do any
> videos, I am making a suggestion for future people.
>
> # I suggest that in future when preparing such videos the sections with no
> # sound be omitted and replaced by a short note explaining the omission,
> # something like "sorry, due to technical difficulties four minutes of sound
> # were not available". Having a second ogg file for the lip-readers would be
> # an option although I expect that the demand would be minute.
> As someone who has not been at all involved with the production of the LCA videos, but who has been intimately involved with the process of streaming DebConf 6, 7 & 8, I think this sort of additional effort will only happen if people voluntarily do it themselves. Just the task of *watching* all of the produced videos is a huge job for one individual, but as a community of individuals it is quite likely that at least one individual in the community watches each video. If each person who was offended by the quality of post-production work took it upon themselves to fix up only one video then it is probable that we would see some changed. Otherwise I'm afraid it is unlikely. Further in his e-mail, Russell Coker wrote:
>
> My observation was that the microphones were put down AFTER they ceased
> operating. A non-functional lapel microphone is no better than a non-
> functional hand-held microphone.
>
> Having a large supply of new batteries would be one way of alleviating the
> problem (I believe that some of the instances were due to flat batteries).
> Another possibility is having two microphones on hand so that if one died the
> other could be turned on.
>
> A wired microphone that doesn't rely on battery power would probably be the
> most reliable option. That of course might not fit with OH&S issues. Most speakers are uncomfortable / unfamiliar with wired microphones. Spares are essential, of course, but the problem can usually be avoided by having a checklist for the audio person to confirm several things: Before the start of the talk: At the start of the talk: At the end of the talk: There are probably a couple of things that I've missed, but if you start with a checklist you pretty soon modify it into a *good* checklist, and it *really* helps when people are under fire. In fact lapel mics are not the best microphones for these kinds of presentations. The best mics are the ultra lightweight 'headset' models which place a the mic near to the speakers mouth. These do not suffer when the speaker turns their head hard to the left or right, at which points a lapel mic stops getting their speech. They also work well with that more hirsute minority so over-represented in our particular community (alas, that this set no longer includes Bdale :-) Of course DebConf has a large team of volunteers for streaming the conference, and has developed these kinds of procedures over a number of years. At DebConf there are usually only two main streams, each of which involves: Ideally that really is 7 people (times two streams), and you can get by if you can't find all of the last three, but the other four are increasingly desirable. We mostly manage to do that with volunteers for two streams at DebConf, but for five or more streams at LCA it is inevitably a lot harder, and the quality necessarily has to be cut back to match the resources available. While it is true that sound is critical to this communication, it is unfortunately also true that most people's (even most geek's) eyes glaze over when presented with a mysterious box with a mere 6 sliding potentiometers, let alone when there are 36 of them, each associated with another 8 rotary knobs, and a rats nest of cables worthy of the worst network nightmare they've seen, and where everything appears to be literally held in place with duct tape. So it is not so surprising then that while it is relatively easy to find a gadget mad geek capable of operating a camera, or even experienced with operating a camera, finding people with experience operating a sound mixer is an order of magnitude harder. At LCA the operation appears superficially to often involve a (single) speaker camera operator with a very basic sound mixer which has been configured once by an overworked person who is unobtainable during the actual talk to solve any audio problems. These people are volunteers, and are doing their best, but it simply isn't possible to get a consistently high quality of video and audio in those circumstances. So as one of the organising committee for LCA 2010 in Wellington I will be watching what we do, and although I don't intend to get personally involved in the video production (I've got plenty of other stuff on *my* plate :-) I do intend to provide what advice and assistance I can. I know that we hope to have some professionals involved (as volunteers), but how many volunteers, and with what levels of skill & experience, we are unlikely to know until much closer than the date. I'll also personally try and get a run-down on all of the audio equipment so that in an emergency, if I happen to be available, I can sub as a sound mixer operator. So we will try and do better in Wellington in 2010. Come to the conference, though, because we can make no guarantees, and if you do come to Wellington, and you see a single cameraman, and you know something about running a sound mixer, then perhaps you can come and volunteer to help out in that capacity, for the talks you are attending anyway. We'd really appreciate the help. And finally I must say thanks, in particular, to Holger Levsen for all the learning I have gained since joining the videoteam at DebConf5 in Helsinki in 2005. And too, to all of those past conference teams (LCA, DebConf and otherwise) who have put their best efforts into providing videos of the talks I couldn't see in person. I know it's a bloody hard job, and often a less high profile one, so:

Thank You.

24 February 2009

Manoj Srivastava: Manoj: Rethinking ucf

There has been some discussion on the Debian development mailing list Tortured activity diagram about adding hooks into ucf, to allow people to do things like committing files into different SCM branches. So, I thought I would help people out by letting them tell me where hooks would be useful, and so decided to do an activity diagram for ucf. Gawd, what a mess. I mean, I wrote this thing, and it boggles even my mind. See the figure for how horrendous code can get when it grows organically. So, I decided to re-factor/redesign ucf, see if I could create a less complex activity diagram. On analysis, it turns out that ucf has just five actions it may perform, and which action it takes depends on which of eight possible states the configuration file is in. Gory details follow

Michal Čihař: Email easier than Google?

I really do not get, while people rather email somebody to ask question, which Google can answer in few seconds. Today I got question that some body was not able to find phpMyAdmin demo:
Hello, I ran your phpMyAdmin demo from some link, but I unfortunately do not know where it was. Could you please send me link to this demo.
Is it really that hard to find it? Typing phpMyAdmin demo into Google, does give correct result on first place to me... PS: I got to reading this email after five days, so that guy definitely did not save much time.

23 February 2009

Michal Čihař: Gammu stable version 1.23.0

After two months of heavy development, new Gammu stable release is out. There are quite a lot of changes and I'm not really convinced it makes sense to include full list of almost 150 lines from ChangeLog, so here are the most important changes (I'm sure I missed something, but I think the list is already too big): You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in unstable soon, SUSE, Fedora and Mandriva users can check repository in OpenSuse Build Service and Ubuntu in my PPA.

Theodore Ts'o: Reflections on a complaint from a frustrated git user

Last week, Scott James Remnant posted a series of Git Sucks on his blog, starting with this one here, with follow up entries here and here. His problem? To quote Scott, I want to put a branch I have somewhere so somebody else can get it. That s the whole point of distributed revision-control, collaboration. He thought this was a mind-numbingly trivial operation, and was frustrated when it wasn t a one-line command in git. Part of the problem here is that for most git workflows, most people don t actually use git push . That s why it s not covered in the git tutorial (this was a point of frustration for Scott). In fact, in most large projects, the number of people need to use the scm push command is a very small percentage of the developer population, just as very few developers have commit privileges and are allowed to use the svn commit command in a project using Subversion. When you have a centralized repository, only the privileged few will given commit privileges, for obvious security and quality control reasons. Ah, but in a distributed SCM world, things are more democratic anyone can have their own repository, and so everyone can type the commands git commit or bzr commit . While this is true, the number of people who need to be able to publish their own branch is small. After all, the overhead in setting up your own server just so people can pull changes from you is quite large; and if you are just getting started, and only need to submit one or two patches, or even a large series of patches, e-mail is a far more convenient route. This is especially true in the early days of git s development, before web sites such as git.or.cz, github, and gitorious made it much easier for people to publish their own git repository. Even for a large series of changes, tools such as git format-patch and git send-email are very convenient for sending a patch series, and on the receiving side, the maintainer can use git am to apply a patch series sent via e-mail. It turns out that from a maintainer s point of view, reviewing patches via e-mail is often much more convenient. Especially for developers who are just starting out with submitting patches to a project, it s rare that a patch is of sufficiently high quality that it can be applied directly into the repository without needing fixups of one kind or another. The patch might not have the right coding style compared to the surrounding code, or it might be fundamentally buggy because the patch submitter didn t understand the code completely. Indeed, more often than not, when someone submits a patch to me, it is more useful for indicating the location of the bug more than anything else, and I often have to completely rewrite the patch before it enters into the e2fsprogs mainline repository. Given that, publishing a patch that will require modification in a public repository where it is ready to be pulled just doesn t make sense for many entry-level patch submitters. E-mail is in fact less work, and more appropriate for review purposes. It is only when a mid-level to senior developer is trusted to create high quality patches that do not need review that publishing their branch in a pull-ready form really makes sense. And that is fairly rare, and why it is not covered in most entry-level git documentation and tutorials. Unfortunately, many people expect to see the command scm push in a distributed SCM, and since git pull is a commonly used command for beginning git users, they expect that they should use git push as well not realizing that in a distributed SCM, push and pull are not symmetric operations. Therefore, while most git users won t need to use git push , git tutorials and other web pages which are attempting to introduce git to new users probably do need to do a better job explaining why most beginning participants in a project probably don t need their own publically accessible repository that other people can pull from, and which they can push changes for publication. There is one exception to this, of course, and this is a developer who wants to get started using git for a new project which he or she is starting and is the author/maintainer, or someone who is interested in converting their project to git. And this is where bzr has an advantage over git, in that bzr is primarily funded by Canonical, which has a strong interest in pushing an on-line web service, Launchpad. This makes it easier for bzr to have relatively simple recipes for sharing a bzr repository, since the user doesn t need to have access to a server with a public IP address, or need to set up a web or bzr server; they can simply take advantage of Launchpad. Of course, there are web sites which make it easy for people to publish their git repositories; earlier, I had mentioned git.or.cz, github, and gitorious. Currently, the git documentation and tutorials don t mention them since they aren t formally affiliated with the git project (although they are used by many git users and developers and the maintainers of these sites have contributed a large amount of code and documentation to git). This should change, I think. Scott s frustrations which kicked off his git sucks complaints would have been solved if the Git tutorial recommended that the easist ways for someone to publicly publish their repository is via one of these public web sites (although people who want to set up their own server certainly free to do so). Most of these public repositories probably won t have much reason to exist, but they don t do much harm, and who knows? While most of the repositories published at github and gitoriuous will be like the hundreds of thousands of abandoned projects on Sourceforge, one or two of the new projects which someone starts experimenting on at github or gitorious could turn out to be the next Ruby on Rails or Python or Linux. And hopefully, they will allow more developers to be able to experiment with publishing commits on their own repositories, and lessen the frustrations of people like Scott who thought they needed their own repositories; whether or not a public repository is the best way for them to do what they need to do, at least this way they won t get as frustrated about git. :-) Related posts (automatically generated):
  1. Git and hg John Goerzen recently posted about Git, Mercurial and Bzr that...
  2. Batches of patched batches of patches I found the following from the Risks Digest, authored by...

Theodore Ts'o: Reflections on a complaint from a frustrated git user

Last week, Scott James Remnant posted a series of Git Sucks on his blog, starting with this one here, with follow up entries here and here. His problem? To quote Scott, I want to put a branch I have somewhere so somebody else can get it. That s the whole point of distributed revision-control, collaboration. He thought this was a mind-numbingly trivial operation, and was frustrated when it wasn t a one-line command in git. Part of the problem here is that for most git workflows, most people don t actually use git push . That s why it s not covered in the git tutorial (this was a point of frustration for Scott). In fact, in most large projects, the number of people need to use the scm push command is a very small percentage of the developer population, just as very few developers have commit privileges and are allowed to use the svn commit command in a project using Subversion. When you have a centralized repository, only the privileged few will given commit privileges, for obvious security and quality control reasons. Ah, but in a distributed SCM world, things are more democratic anyone can have their own repository, and so everyone can type the commands git commit or bzr commit . While this is true, the number of people who need to be able to publish their own branch is small. After all, the overhead in setting up your own server just so people can pull changes from you is quite large; and if you are just getting started, and only need to submit one or two patches, or even a large series of patches, e-mail is a far more convenient route. This is especially true in the early days of git s development, before web sites such as git.or.cz, github, and gitorious made it much easier for people to publish their own git repository. Even for a large series of changes, tools such as git format-patch and git send-email are very convenient for sending a patch series, and on the receiving side, the maintainer can use git am to apply a patch series sent via e-mail. It turns out that from a maintainer s point of view, reviewing patches via e-mail is often much more convenient. Especially for developers who are just starting out with submitting patches to a project, it s rare that a patch is of sufficiently high quality that it can be applied directly into the repository without needing fixups of one kind or another. The patch might not have the right coding style compared to the surrounding code, or it might be fundamentally buggy because the patch submitter didn t understand the code completely. Indeed, more often than not, when someone submits a patch to me, it is more useful for indicating the location of the bug more than anything else, and I often have to completely rewrite the patch before it enters into the e2fsprogs mainline repository. Given that, publishing a patch that will require modification in a public repository where it is ready to be pulled just doesn t make sense for many entry-level patch submitters. E-mail is in fact less work, and more appropriate for review purposes. It is only when a mid-level to senior developer is trusted to create high quality patches that do not need review that publishing their branch in a pull-ready form really makes sense. And that is fairly rare, and why it is not covered in most entry-level git documentation and tutorials. Unfortunately, many people expect to see the command scm push in a distributed SCM, and since git pull is a commonly used command for beginning git users, they expect that they should use git push as well not realizing that in a distributed SCM, push and pull are not symmetric operations. Therefore, while most git users won t need to use git push , git tutorials and other web pages which are attempting to introduce git to new users probably do need to do a better job explaining why most beginning participants in a project probably don t need their own publically accessible repository that other people can pull from, and which they can push changes for publication. There is one exception to this, of course, and this is a developer who wants to get started using git for a new project which he or she is starting and is the author/maintainer, or someone who is interested in converting their project to git. And this is where bzr has an advantage over git, in that bzr is primarily funded by Canonical, which has a strong interest in pushing an on-line web service, Launchpad. This makes it easier for bzr to have relatively simple recipes for sharing a bzr repository, since the user doesn t need to have access to a server with a public IP address, or need to set up a web or bzr server; they can simply take advantage of Launchpad. Of course, there are web sites which make it easy for people to publish their git repositories; earlier, I had mentioned git.or.cz, github, and gitorious. Currently, the git documentation and tutorials don t mention them since they aren t formally affiliated with the git project (although they are used by many git users and developers and the maintainers of these sites have contributed a large amount of code and documentation to git). This should change, I think. Scott s frustrations which kicked off his git sucks complaints would have been solved if the Git tutorial recommended that the easist ways for someone to publicly publish their repository is via one of these public web sites (although people who want to set up their own server certainly free to do so). Most of these public repositories probably won t have much reason to exist, but they don t do much harm, and who knows? While most of the repositories published at github and gitoriuous will be like the hundreds of thousands of abandoned projects on Sourceforge, one or two of the new projects which someone starts experimenting on at github or gitorious could turn out to be the next Ruby on Rails or Python or Linux. And hopefully, they will allow more developers to be able to experiment with publishing commits on their own repositories, and lessen the frustrations of people like Scott who thought they needed their own repositories; whether or not a public repository is the best way for them to do what they need to do, at least this way they won t get as frustrated about git. :-) Related posts (automatically generated):
  1. Git and hg John Goerzen recently posted about Git, Mercurial and Bzr that...
  2. Batches of patched batches of patches I found the following from the Risks Digest, authored by...

22 February 2009

Rudy Godoy: software development practices for personal development

Often I happen to come with some pretty crazy ideas about anything in life. That s me. Some of them may work, that s why I adventure to share them with the world. Working with computers, software in particular, for almost 12 years have brought interesting views regarding life. For the past 3 years I ve progressively improved the human being am I, and also the improvement process. The other day I was heading to the uni and I ve just noted that some practices of my profession can also be applied to my personal improvement. So, here I m sharing some of them. Hope you find them useful.
  1. Spot your bugs and kill em. While it s important to want to improve yourself. It s more relevant to the fact of real improvement that you spot your personal bugs . This is a crucial part of it all. Once you are aware of you personal bugs you ll be able to take action on them. So, when you do, just kill them and don t let stink until you are not able to manage it at all and all your code taints and breaks.
  2. Let process run on the background. Life has a limitation, which is time. Time is a scarce resource. You must be aware of it, really. While we might want to do many different things life presents to us, is not really responsible to engage on all. However, we can hack this. Here technology is our ally. There are many different ways to be able to do some things in the background while on the foreground you focus on what really matters to you at the time.
  3. Outsource services that are not key for you. Delegation and distributed architecture come to mind. Professions and specialization are an evolution of humanity. Please take advantage of it. You don t need to know or do everything. Karen Sthepenson s connectivism axiom is illustrative: I store my knowledge in my friends .
  4. Focus on what matters. This is somehow like the unix tradition of doing one thing and doing it well. Identify what makes you unique, special and relevant on your ecosystem. What value you can offer to others, and work on that direction. Hard work pays.
  5. Release early and release often. Once you have spot bugs and managed to fix them, release a new version of yourself!. Tell the world by showing an improved version of yourself. Make this incremental and iterative, just like a software development framework. For instance I currently run a 3.1 version of myself. Just released a point version last week :)

Andre Luis Lopes: Debian : a virtualization friendly platform

It s no secret for those who follow me on Twitter/identi.ca that I have been toying with virtualization technologies for some time now. I have been using Xen in production for some time and, apart from not thinking it s the way to go for future virtualization, it s quite usable right now, specially if you are going to use Debian Lenny as the dom0, as it now has a more modern kernel than the dreaded 2.6.18 we Xen users were forced to keep using. However, I have been keeping my eyes on KVM as well, as I always liked how much simpler and well integrated into the Linux kernel it is. I m even subscribed to the KVM development mailing list, even not understanding most of the things the developers are talking about there. It s no problem for me, I just want to know what s being worked on and what s on the pipeline. As a KVM fan, I m also using it intensively as a tool for prototyping servers. It s easy enough to set up a new Debian server to test things on and learn new technologies, as well as troubleshoot problems without intefering with production environments. Althought KVM is not as good as Xen when it comes to performance, it s quickly improving every single day. And, for those of you who still believes KVM is only about full virtualization, I m happy to say that it has come a long way and paravirtualization has started to infiltrate KVM land as well. Today, KVM already sports paravirtualized clock (pvclock), paravirtualized memory management unit (pv MMU) and VirtIO drivers. Actually, it seems that KVM these days is the biggest user of VirtIO, maybe only loosing the leadership to Rusty s lguest. By using VirtIO s disk and network drivers (virtio_blk and virtio_net, respectively, and its associated modules), KVM can deliver a much improved I/O experience than when using QEMU s emulated drivers. For this reason, it s always preferable to use VirtIO drivers whenever possible when setting up your KVM guests. During the Etch lifetime, one will need to do some tricks in order to use VirtIO when using Etch as a guest under KVM. However, when preparing Lenny s d-i, the developers were smart enough to add to it virtual disk detection support. What it means is that now, starting with Lenny, d-i will recognize that it s being given a VirtIO block device and automatically load the needed kernel modules to support it. Also, the disk detection and partition modules (partman et all) were modified to show a detected virtual disk (i.e. /dev/vdX) and let the user partition it, as well as grub-installer was changed to allow GRUB to be installed onto a virtual disk s MBR, effectively making d-i a really powerful virtualization aware installer. Here you can see Lenny s d-i showing a detected virtual disk, named vda :
lenny-vdisk-partitioning-english

lenny-vdisk-partitioning-english

Brazilian Portuguese readers could see the version using brazilian portuguese texts on the screen here. Sure, d-i also received a lot of improvements and special support for installing Lenny as a Xen domU was added as well, but I haven t played with it yet, so I won t comment on that right now. And, hey, one can even use virt-install and virt-manager to deploy KVM guests under Lenny :-) And you know what gives me even more confidence that KVM will be a first class citizen inside Debian ? The fact that Steve Kemp is toying with the idea to change his xen-hosting.org project so it would become a new kvm-hosting.org project. Maybe I m praying for the preacher here, but Steve is very well well know for being the author of xen-tools and xen-shell, as well as being the creator of a number of other nice free softwares. And, judging by the comments on his post about the future kvm-hosting.org project, it seems that Steve maybe will need to update xen-tools and xen-shell to account for KVM or create a new set of tools dedicated exclusively to KVM based on his past experience creating the current tools for Xen. Good times ahead for those of us who are surfing the Debian Virtualization wave, indeed :-)

17 February 2009

Adrian von Bidder: Bowflex machine

After dropping all (pretense at) regular exercise after leaving high/grammar/secondary school (the german word is Gymnasium) and doing more or less nothing for more than 10 years, I've taken up weight training (after a not very successful attempt at volleyball; I like the sport but the team fell apart) two years ago. Since I actually managed to work out regularly (twice a week) in the first year, and since membership in a gym is not cheap, and since I moved and thus had to find a different solution anyway, I decided to buy a Bowflex Sport home gym. I can't compare it to other home equipment, and it apparently it has been discontinued by Nautilus, but nonetheless, a few thoughts: The conclusion first: Would I buy it again? No. Was it a waste of money? No, it's not that bad. In detail: Closing remarks: I'll probably keep it for quite a while. I've thought about spending much less money and just getting a bench and a few weights, but I really like to have a lat tower. Overall I can do what I want to do with the exception of cardio workouts. The other angle is that there is quite a bit of bad press around about the founder of Nautilus, Arhur Jones. I can't comment on how trustworthy these articles are, and I can't comment on Nautilus' business practices today (Mr. Jones seems to be dead), so take this with a large pinch of salt before making a buying decision based on moral/ethical standards.

Matthew Palmer: Depressing, yet Inspiring

If you're not reading The Daily WTF, today's soapbox article, Programming Sucks! Or At Least, It Ought To is a good reason to at least give it a glance now and then. Essentially, it's a wake-up call to all those programmers who think that their working life isn't complete unless every project is implemented in a new language, with a new framework, or at the very least using a bunch of the latest whizz-bang techniques that they read about on the back of their weeties blog this morning. My favourite rule, and one that I really need to re-learn myself, is:
Serve the Business. Every tradesman wants to use the latest, greatest, and most powerful tools, but rarely are they appropriate for the job. Likewise, there's hardly ever a business case to immediately upgrade all platforms/libraries/languages. That 10-year old "Classic ASP" code hasn't gotten worn out, just much less fun to maintain.
The rest of his rules are also useful, and should probably be printed out and stuck up around the offices of every IS development shop.

15 February 2009

Holger Levsen: FOSDEM videos released

In a nice coincedence with the release of Lenny (cheers!!1), the low-quality versions of the videos from the Debian DevRoom at FOSDEM 2009 are available now!

Better quality versions will be encoded and uploaded by Ben over the next days. I'd also like to collect the slides from the talks there, so if you had a talk there, please send them to Wouter and/or me, and Wouter, please send me the slides you collected on the presetation computer ;-)

Basically I'm very happy with our results, excpet for two things: sadly the computer running dvswitch wasn't powerful enough to do picture in picture (and due to time constraints we weren't able to switch to a more powerful one), so we'll have to plan this better next year. And second, I have no real clue how useful our streaming efforts are, I believe the recordings are useful, but in both cases feedback from people who find them useful is appreciated! Covering FOSDEM is certainly a lot of fun, but it's also a lot of work and leaves not much room for seeing other parts of the conference. So a short reply (I'll post this to d-d-a with reply-to set to -project) will be very much appreciated! :)

Big thanks go to Womble2, edrz, xerrako, Q_, danielsan, DaCa, tokkee, luca, Yoe, Ganneff, franklin, huhn, luk, CarlFK, daven and some more volunteers I cannot remember right now! Also not to be forgotten the FOSDEM crew & volunteers for an awesome event and the people from CCC Hamburg who came by car and took a lot of audio/video/computer equipment for us (and left 90min later than planned! Thanks again!)! And also Debian (via the DPL) for some 120 Euros to rent equiqment and for buying batteries and the always needed duct-tape!

Michael Prokop: Debian GNU/Linux 5.0 codename Lenny - News for sysadmins

Alright, Debian GNU/Linux 5.0 AKA as Lenny has been released. Time for a Debian unstable unfreeze party! 8-) What does the new stable release bring for system administrators? I ll give an overview what news you might expect when upgrading from Debian GNU/Linux 4.0, codename Etch (released on 8th April 2007) to the current version Debian GNU/Linux 5.0, codename Lenny (released on 14th February 2009). I try to avoid duplicated information so make sure to read the release announcement and the official release notes for Lenny beforehand. Noteworthy Changes Virtualisation Virtualisation related new tools: Desktop oriented packages like virtualbox and qemu are available as well of course. Noteworthy Updates This is a (selective) list of some noteworthy updates: New packages Lenny ships over 7000 new packages. Lists of new/removed/replaced packages are available online. I ll name 238 sysadmin related packages that might be worth a look. (Note: I don t list addon stuff like optional server-modules, docs-only and kernel-source related packages. I plan to present some of the following packages in more detail in separate blog entries.) Further Ressources

Mike Hommey: Testing small upgrades with namespaces and unionfs

If you are following this blog, you probably remember per-process namespaces. Today, I m going to tell you how I did use them in the process of preparing this server to be upgraded to Lenny. I must say I was not using the most recent stuff on this server, and this is why I needed such preparation. First, this server is still running with php4. And well, the following line in the apt-get dist-upgrade output got my full attention (emphasis mine):
The following packages will be REMOVED:
cacti libapache2-mod-php4 libarchive-tar-perl libcurl3-openssl-dev
libgssapi2 libpci2 librpm4 libssp0 linux-kernel-headers modutils php4-mysql
While this server is not important enough not to be broken for a couple hours, I do like to test procedures that could help on servers that are. The first thing I needed to do on this server was obviously to upgrade php. But we all know how php applications are not fully compatible with all versions of php, so I also needed to test the upgrade was not breaking anything. On a server you don t care much about, you can just upgrade, test if all is okay, and be done with it. Obviously, if all is not okay, your visitors will see it, and you may also have a bad time downgrading. Another way to perform the upgrade is to have a similarly installed server on the side, test and validate the upgrade there, and replicate the upgrade on the production server if everything is fine. However, that does require additional resources, and possibly to setup them if they don t already exist. A cheaper way to do the above is to do it on the production server, both in-place and on the side (you ll see what I mean), using unionfs and per-process namespaces. Full containers could be used instead of per-process namespaces (such as openvz, vserver or lxc), but they still require much more setup, especially when you don t use them in the first place. Chroots could work just as well as per-process namespaces, but one of the ideas here is to expose the per-process namespaces feature, and allow for improvement of this procedure with pid and network namespaces, which are not available in Etch (where I m starting from), but are in Lenny. Unionfs allows to merge several directories into a single one, accessing some read-only, and others read-write. Installing unionfs is as easy as running the following command:
apt-get install unionfs-modules- uname -r
I won t describe all the kinds of setups that are possible with unionfs, but only one typical use case, which is what we will be using here:
# mkdir /tmp/root-cow
# mount -t unionfs -o dirs=/tmp/root-cow:/=ro none /mnt
The first thing we do here is to create an empty directory. Next, we merge it with the root filesystem (/), that we will keep read-only (meaning unionfs won t allow itself to write there), and mount the merged filesystem under /mnt. none could just be anything, as there is no device to be mounted. The result, in /mnt, is just something that looks like the root filesystem:
# ls /
bin boot dev etc home initrd lib media mnt opt proc root sbin srv sys tmp usr var
# ls /mnt
bin boot dev etc home initrd lib media mnt opt proc root sbin srv sys tmp usr var
But creating or modifying a file will do so in /tmp/root-cow:
# echo a > /mnt/a
# cat /a
cat: /a: No such file or directory
# cat /tmp/root-cow/a
a
# echo foo.com > /mnt/etc/mailname
# cat /etc/mailname
glandium.org
# cat /tmp/root-cow/etc/mailname
foo.com
# find /tmp/root-cow
/tmp/root-cow
/tmp/root-cow/etc
/tmp/root-cow/etc/mailname
/tmp/root-cow/a
Keep in mind that it doesn t include submounts, though:
# ls /var
backups cache lib local lock log mail opt run spool tmp www
# ls /mnt/var
This means we ll have to also mount /var, /proc, /dev, and /sys. That s enough testing for now, and we ll first do some cleanup before going after the real job:
# umount /mnt
# rm -rf /tmp/root-cow
Using the newns utility from my first post on per-process namespaces, let s create a new namespace to keep our testing private, and populate it with the necessary mount points:
# newns
# umount /tmp
# mount -t tmpfs tmpfs /tmp
# mkdir /tmp/root-cow /tmp/var-cow
# mount -t unionfs -o dirs=/tmp/root-cow:/=ro none /mnt
# mount -t unionfs -o dirs=/tmp/var-cow:/var=ro none /mnt/var
# cd /mnt
# pivot_root . mnt
# mount --move /mnt/proc /proc
# mount --move /mnt/sys /sys
# mount --move /mnt/lib/init/rw /lib/init/rw
# mount --move /mnt/tmp /tmp
# mount --move /mnt/dev /dev
The second and third statements are useful to avoid sharing /tmp with the main namespace, which means the directories we create in the fourth statement won t be visible in /tmp outside this namespace. The fifth and sixth statements put the union filesystems in place. As my system only has a separate /var filesystem (no /usr, and I don t care about /home here), I only need to setup these two. Feel free to add more union filesystems as necessary. The pivot_root call allows to switch to the unionfs ed root: everything under /mnt (/mnt and /mnt/var in our case) will be remounted under /, while what was under / is remounter under /mnt under the new root.
This means, in our case, that we have / and /var as union filesystems, while the old / and /var are respectively in /mnt and /mnt/var. It also means /dev, /proc, /sys and other filesystems are remounted as /mnt/dev, /mnt/proc, /mnt/sys, etc., which is why we next mount --move all of them to a better place in our namespace. Once all this setup is done, we are ready to do our php upgrade test. As Etch doesn t have support for neither PID namespaces nor network namespaces, we ll still have some conflicts with the main namespace for TCP port binding and process handling, so we need to be a little careful:
# rm /var/run/apache2.pid
# echo Listen 8080 > /etc/apache2/ports.conf
With these changes, we can now safely start apache2 in this namespace, at the same time the main apache2 runs in the main namespace:
# /etc/init.d/apache2 start
Now, there are actually 2 problems showing up in apache in this setup. The first one is that displaying static files doesn t work. At all. It appears unionfs doesn t support sendfile(). Which is fine. But apache doesn t check for sendfile() s error cases and doesn t fallback to a working solution when sendfile() doesn t work. So we have to manually disable it:
# echo EnableSendfile off > /etc/apache2/conf.d/sendfile.conf
The second one is that access to the mysql socket doesn t work properly under the unionfs. I didn t want to investigate further, so I only worked around the issue by forcing to use the socket outside the unionfs:
# mount --bind /mnt/var/run/mysqld /var/run/mysqld
Finally, we can test and validate our php upgrade:
# apt-get install php5-mysql php5-cli php5-snmp libapache2-mod-php5
# /etc/init.d/apache2 restart
# apt-get remove --purge php4-common
Note that installing libapache2-mod-php5 will remove libapache2-mod-php4, and apache2 gets restarted, taking into account this change. But the php modules (php5-mysql and php5-snmp) install is only going to happen after that, and no apache2 restart is triggered then, which leaves a half working php setup
Also note that the cacti setup in etch supposes php4 is installed, using a IfModule statement against mod_php4.c and none for mod_php5.c, which means a part of its setup doesn t work out of the box (most notably, the DirectoryIndex). Once all is validated, all we need to do is to stop apache2 and exit from the namespace. The union filesystems and temporary filesystems are then automagically cleaned-up and the namespace disappears as well as all modifications we just did, since all processes using the namespace ended. We are now free to upgrade on the production server, as we know all the side effects. I ll now be able to upgrade to Lenny without php getting removed.

Ingo Juergensmann: Lenny released, next to come: Squeeze

Congrats and thanks to all people involved into releasing Lenny! Keep on the good work!

Now everyone can concentrate on the next release of Debian called Squeeze. My wishlist for the new, upcoming release:

  1. no political, show-stopping discussions or GRs anymore.

  2. more members in core teams such as ftpmaster, DAM, debian-admin, ... - don't wait until someone will eventually join, but look actively for new members and train them, so that the workload for everyone involved will be less at the end.

  3. please forget your personal dislike when working with other people. You don't need to be friends, but you should be able to work together like professionals and concentrate on the topics.

  4. please introduce sub-releases for desktop, multimedia, kernel stuff while having a base of core packages for a longer term for servers. Release desktop related stuff more often than the base core packages.

  5. acknowledge the work of contributors and find a way to let them some part of Debian without following the long and often unnecessary, unwanted and boring path of NM.

  6. and finally: have fun! :-)



So, now it's up to upgrade my machines to Lenny in the next days... I hope everything will be as smooth as everyone is expecting it. :-)

14 February 2009

Biella Coleman: Joe Reagle on Wikipedia

In this age of bits and bytes, there are many virtual organizations and networks which produce all sorts of stuff we use on a daily basis. My two favorite institutions are Debian (not a surprise) and Wikipedia, not just because they oh-so-useful to me and many others, which they are, but because the social organizations behind these two entities are so (at times maddeningly) complex and full of nuance, they provide for endless analytical fascination. One of my friends, Joe Reagle, who has recently graduated from my home department, is presenting is work on Wikipedia and I thought some local New York geeks might be interested. Information below:
All welcome 4:30 - 6:00 PM, Tuesday February 17
206 Vanderbilt Hall, 40 Wash. Sq. So. Wikipedia: Nazis and Norms Joseph Reagle, NYU Department of Media, Culture, and Communication Abstract: In 1990 Mike Godwin coined his Law of Nazi Analogies to capture the common devolution of Usenet discourse into insulting comparisons with Nazis or Hitler. Eleven years later, Jimmy Wales wrote that it was important that the Wikipedia community preserve and extend our culture of co-operation, with all of us standing as firmly as possible against the culture of conflict embodied in Usenet. I argue Wikipedia is a realization even if flawed of a long-held vision for a universal encyclopedia: a technology inspired vision seeking to wed increased access to information with greater human accord. And I claim Wikipedia s collaborative culture is a big factor for this success: the norms of Neutral Point of View ensures that the scattered pieces of what we think we know can be joined and good faith facilitates the actual practice of fitting them together.

Biella Coleman: Joe Reagle on Wikipedia

In this age of bits and bytes, there are many virtual organizations and networks which produce all sorts of stuff we use on a daily basis. My two favorite institutions are Debian (not a surprise) and Wikipedia, not just because they oh-so-useful to me and many others, which they are, but because the social organizations behind these two entities are so (at times maddeningly) complex and full of nuance, they provide for endless analytical fascination. One of my friends, Joe Reagle, who has recently graduated from my home department, is presenting is work on Wikipedia and I thought some local New York geeks might be interested. Information below:
All welcome 4:30 - 6:00 PM, Tuesday February 17
206 Vanderbilt Hall, 40 Wash. Sq. So. Wikipedia: Nazis and Norms Joseph Reagle, NYU Department of Media, Culture, and Communication Abstract: In 1990 Mike Godwin coined his Law of Nazi Analogies to capture the common devolution of Usenet discourse into insulting comparisons with Nazis or Hitler. Eleven years later, Jimmy Wales wrote that it was important that the Wikipedia community preserve and extend our culture of co-operation, with all of us standing as firmly as possible against the culture of conflict embodied in Usenet. I argue Wikipedia is a realization even if flawed of a long-held vision for a universal encyclopedia: a technology inspired vision seeking to wed increased access to information with greater human accord. And I claim Wikipedia s collaborative culture is a big factor for this success: the norms of Neutral Point of View ensures that the scattered pieces of what we think we know can be joined and good faith facilitates the actual practice of fitting them together.

Joerg Jaspert: Lenny Release

I just finished most of my jobs for the Lenny release. I started, together with Mark Hymers, at 10:23 UTC. This was ahead schedule, which said 12:00 UTC, but better early than late. After disabling all our ftpmaster cronjobs, setting up our work environment and whatever else we needed and at 10:43 UTC we got the Release Teams GO. All of what we did got logged from screen, as we intend to write a dak tool doing such releases. Anyway, I won t bore you with a detailed set of actions we had to took, way too much for now, just some few moments (All times in UTC): While writing this entry people are still doing work for the release. For example the cd building will take time, after all there are well over 500 images (and 36 live cds). Current plan seems to be that we ftpmaster push the archive mirrors around 23:00 UTC, so it has time to sync everywhere. Some while later the cd mirror will get a push, and then the official announcement will happen. Thanks go out to everyone involved in preparing this release, be it in the past by fixing bugs, uploading packages, doing whatever was needed, as well as doing the work today.

Brice Goglin: Debian/X.org notes - Howto get DRI2 on Debian?

Now that the final Mesa 7.3 is available in experimental (and built on most architectures), it is actually easy to get DRI2 in Debian if you have an Intel board. First, make sure you have a recent kernel, otherwise it may fail miserably. I am running 2.6.29-rc here, and I am not even sure 2.6.28 would be enough. Hopefully, one day the driver/server will properly detect and report problems when it runs on a old kernel :) Enable the new UXA acceleration architecture with Option "AccelMethod" "UXA" in the device section of your xorg.conf. Restart X. You should see DRI2 enabled in the log. Now start Compiz and it works. You can see a wobbly glxgears! Well, on my i945, Compiz was very slow by default. I add to disable Sync to-VBlank in the display settings in Compiz' general options. If you don't want Compiz, you may also try running xcompmgr -a and then play with transset to put transparency on 3D applications. Update: Added kernel requirements, added how to make Compiz not slow.
(Permanent link)

Next.

Previous.