You know, GNOME Shell and I are not really strangers to each other for a long time now. I have been using it almost daily as my main desktop since late 2009, when I started shipping it to Debian experimental. That means that I had ample opportunity to both get used to it and witness the huge improvements it had with every new release. My general feeling towards GNOME 3 is this: . Yes, I love it! I love the new themes, I love the window borders, I love the top panel, the overview, the dynamic workspaces, I love the Me menu, I love the clock and the calendar, the system indicators with the beautiful symbolic icons, being able to search for applications in such a nice way, the window animations, the multi-screen support, the new nautilus, the dash, looking glass. It s hard for me to even express how thankful I am and how much admiration I have for the awesome folks who helped bring this to life. Thanks so much! After all this time, there are only two things I can say I dislike about GNOME3, apart from some minor wishlists: the alt-tab behaviour and the message tray. Let me expand on those. Message Tray Of the very few things I dislike, there is only 1 I hate and cannot see myself living with: the accordion animation in the message tray. No, really, it s such a terrible, terrible idea. Every single time I try to use that thing I overshoot while moving the mouse to the left, then overshoot again moving the mouse to the right because the frigging icon has moved. It s no good knowing that I can click in the text or in the empty area to its right, it feels wrong. It s terrible that my actual target is moving at all. Every single time I use it is a small frustration for me it s as if the message tray was playing games with me, laughing at me for not having good enough mouse pointer driving skills even more than the infamous sub-menus used to. And I had to go through that penance whenever I wanted to find the person I was chating with to resume the conversation. I wrote an extension that disables the accordion animation by simply not showing the title at all when you hover the icon, and I patched GNOME Shell s CSS to make the icons a bit bigger, so that it s easier for me to hit them with the mouse. It s clearly not ideal, and you still have to click the various people icons to figure out which of your friends who were lazy enough to not add a picture to their IM profiles is that one, but it s still much better than chasing the (smaller) ones around to figure that out. Perhaps we should have the icons be bigger and always have the title bellow them? I don t know, I trust the awesome designers who designed the awesomess that s everywhere else will come up with a great idea. Alt Tab The number 1 feature of workspaces for me has always been locality being able to not see all of the other applications and windows that are open elsewhere. This lowers the amount of noise when I m trying to find something. The overview is very nice in this matter only windows in the current workspace are shown, and even when you have an extra screen, the windows in there appear in that screen. The alt-tab behaviour, on the other hand, of showing all windows and apps, even with the separator, bothers me. It s really useful to have when you want to go to a specific window no matter where it is (I usually use the dash for that, though), but it adds noise when you want to go to a specific window _in this_ workspace, which is the most common use case for my usage. So I copied the alt-tab code over to an extension and modified it so that only windows in the current workspace would be considered. In addition to that, with the windows in the extra screen always being there no matter what workspace you re in (which I think is an awesome idea), they are effectively in all workspaces, so they add constant noise even with my extension. It s also weird to have to look at the main screen to switch to a window in the extra screen. There s a huge discontinuity. What I would prefer is having alt-tab to follow the mouse regarding screens only show windows in the extra screen if you hit alt-tab in there, making sure the selector thing appears in there as well.

LightDM's a from-scratch implementation of an X display manager, ie the piece of software that handles remote X connections, starts any local X servers, provides a login screen and kicks off the initial user session. It's split into a nominally desktop-agnostic core (built directly on xcb and glib) and greeters, the idea being that it's straightforward to implement an environment-specific greeter that integrates nicely with your desktop session. It's about 6500 lines of code in the core, 3500 lines of code in the gtk bindings to the core and about 1000 in the sample gtk greeter, for a total of about 11,000 lines of code for a full implementation. This compares to getting on for 60,000 in gdm. Ubuntu plan to switch to LightDM in their next release (11.10).

This is a ridiculous idea.

To a first approximation, when someone says "Lightweight" what they mean is "I don't understand the problems that the alternative solves". People see gtk and think "Gosh, that's kind of big for a toolkit library. I'll write my own". And at some point they have to write a file dialog. And then they need to implement support for handling remote filesystems. And then they need to know whether the system has a functioning network connection or not, and so they end up querying state from Network Manager. And then they suddenly have a library that's getting on for the size of gtk, has about the same level of complexity and has had much less testing because why would you want to use a lightweight toolkit that either does nothing or is 90% of the size of the alternative and crashes all the time.

Adding functionality means that code gets larger. Given two codebases that are of significantly different sizes, the two possible conclusions are either that (a) the smaller one is massively more competently written than the larger one, or (b) the smaller one does less. The gdm authors have never struck me as incompetent, even if some people may disagree with some of their design decisions, and the LightDM authors don't seem to have argued on that basis either. So the obvious conclusion is that LightDM does less.

And, indeed, LightDM does less. Part of this is by design - as the proposal to the Gnome development list shows, one of the key advantages of LightDM is claimed as it not starting a Gnome session. And from that statement alone, we can already see that there's been a massive failure of understanding the complexity of the problem.

Let's go back to the comparisons of code size. LightDM's simple GTK greeter is about 1000 lines of code. gdm's greeter is almost 20,000. Some of this is arbitrary shiny stuff like the slidy effects that occur, but a lot of it is additional functionality. For example, some of it is devoted to handling the interface with AccountsService so gdm can automatically update when users are created or deleted. Some of it is providing UI for accessibility functionality. Some of it is drawing a clock, which I'll admit may be a touch gratuitous.

But if your argument is that your software is better because it's doing less, you should be able to ensure that you can demonstrate that the differences aren't important. And the differences here are important. For example, one of the reasons gdm starts a local gnome session is that it wants gnome-power-manager to be there to handle power policy. Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not. LightDM takes a different approach. Because there's no session, it has to take care of this kind of thing itself. So the backend daemon code speaks to upower directly, and the greeters ask the daemon to implement their policy decisions.

This is pretty obviously miserable. Now you've got two sets of policy - one at the login screen, and one in your session. How do I ensure they're consistent? The only sane solution is to ignore the functionality the backend provides and have my greeter run gnome-power-manager. And now how about accessibility preferences? Again, if I want to have the same selection of policy, I need to run the same code. So you end up with a greeter that's about as complex and large as the gdm one, and unused functionality in the backend. Lighter weight through code duplication. We have always been at war with Eurasia.

The entirety of LightDM's design is based on a false premise - that you can move a large set of common greeter functionality into a daemon and just leave UI presentation up to the greeter code. And if you believe that, then yes, you can absolutely implement a greeter in 1000 lines of code. It'll behave differently to your desktop - the range of policy you can implement will be limited to what the daemon provides, even if your desktop environment has a different range of features. It'll have worse accessibility for much the same reason. And eventually you'll end up with a daemon that's absolutely huge in order to attempt to provide the superset of functionality that each different desktop makes use of.

The only real problem LightDM solves is that it makes it easier to write custom greeters, and if you're really seeking to differentiate your project based on your login screen then maybe your priorities are a little out of line. I'm sure that Ubuntu will release with a beautiful 3D greeter that has a wonderful transition to the desktop. It's just a shame that it won't do any of the useful things that the existing implementations already do.

And if you think that when LightDM finally has the full feature set of gdm, kdm and lxdm it'll still be fewer lines of code and take less memory - I hear the BSD kernel is lighter weight than Linux. Have fun with it.

1. Find a shift where the meal break is later than average. These are especially common in the afternoon, where there's a lot of trains to drive during the peak to get everyone home. Make sure to execute your fiendish plan on the last run before the meal break.
2. Buy a big helping of hot chips, making sure to load up on the delicious condiments like malt vinegar.
3. Sit right behind the driver's cab with your deep fried basket of deliciousness. With a battery operated fan, you can increase deliciousness penetration considerably, but it's something of a "nuclear option".
4. Put your ear to the cab door to hear the loud growling sounds coming from the driver's stomach.
5. ...
6. PROFIT!
The only thing saving me from bursting out the cab door screaming "The chips! I wants them!" was the fact I had a nut bar in my bag. They were particularly delicious smelling chips.

IPv6 adoption is increasing, and along with it come a new set of behaviours and defaults that system administrators and users must learn and become familiar with. I was recently caught out by Linux s handling of IPv6 router advertisements (RAs) when forwarding is also enabled on the interface. It took me a while to figure out and searching for obvious terms (such as those in the first half of the title of this post) didn t immediately yield useful answers, so here is my attempt to help shed some light on the subject. By default Linux will ignore IPv6 RAs if the interface is configured to forward traffic. This is in line with RFC2462 which states that a device should be either a Host or a Router. If you re forwarding packets you re a router and you re therefore expected to be sending RAs, not receiving them. This policy does make a certain amount of sense but there are obviously situations where it can be useful to accept RAs and still forward packets over the interface[0]. The confusing part is that the Linux IPv6 stack allows the accept_ra sysctl to be set to 1 (enabled) at the same time as the forwarding sysctl is set to 1, yet all incoming RAs are ignored with no hint as to why. If you re not aware that the default behaviour is to ignore RAs when forwarding is enabled it looks very much like autoconfiguration has simply broken. The key piece of information is that makes everything as clear as mud is realising that the forwarding and accept_ra sysctl s are not simple boolean enabled/disabled flags like many of their brethren. There are instead three possible values for each, all clearly documented in sysctl.txt, when you take the time to read it. Ironically the documentation states the type of the values as BOOLEAN even though they re not at least it helped me to feel better about my hasty assumption that the sysctl s were boolean values.

accept_ra BOOLEAN
Accept Router Advertisements; autoconfigure using them. Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled. Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled.

The documentation for forwarding is similar, but much longer, so you can refer to the link above to see it. Conclusion: If you want to autoconfigure IPv6 addresses on an interface that you re also forwarding IPv6 traffic over, you need to set accept_ra to 2. No doubt there are more IPv6 quirks and defaults like this waiting to trap me in the future [0] Arguably you really don t want to be autoconfiguring addresses on your router ever, but that s a philosophical debate that isn t really relevant to this post.

I did not write much code or merge much of my prototype code, but some things happened since the last blog post about APT2 specific things in August and I forgot to write about them. First of all, I dropped the GVariant-based cache. The format strings were simply getting ugly long and were not very understandable, performance was just much too slow (needing more than a few nanoseconds for a package lookup is obviously too slow for solving dependency problems); furthermore, building the cache was also slow and complicated because we needed all attributes of an object at once to pass them to GVariant, leading to ugly API. I replaced the GVariant cache with one that can be easily mmap()ed and is described completely in C. It s derived from APT s cache design (but more robust, as it includes the size of the cache and we can thus detect to small files, although that s scheduled for the next ABI break in APT as well), but has fewer duplicate data, and uses arrays where APT uses linked lists. The reason for arrays is simple: They take up less space and can be represented naturally in Python and other languages using array-based lists. The cache also contains a coalesced hash table which does use a linked list, but that one is a bit different, as it is for searching only and not exposed. Everything non-stringy is 64-bit aligned in order to keep things as simple as possible. All integers are fixed size, thus the format is architecture-independent if you fix byte orders. The format is described at http://people.debian.org/~jak/apt2-doc/apt-Cache-Format.html. I stole one more idea from cupt and changed the configuration system to verify types of variables. APT2 s configuration system knows more types than cupt s, though, including regular expressions, directory and filenames (i.e. it does not let you store a value /d/ in a file variable), strings (which store everything), unsigned and signed integers, and boolean options; all of which are checked when parsing files (producing warnings) or command-line options (producing errors). I have also simplified the type world by removing all iterator types except for one, replacing them with get_thing() and n_things() functions in the objects holding the arrays. Makes cool bindings slightly harder, but makes the C API much easier to use from C. Most things expected from a package manager are still missing, but what is there looks good in most cases (especially AptConfiguration has a nice API, and no complaints from valgrind anywhere). Currently I am working on Python bindings so I can interact with the functions easily and check things in an interactive fashion; and I am also writing a document explaining the concepts behind APT2, drafts at http://people.debian.org/~jak/midlevel.pdf. I also have some more code pending further thoughts (including complete index parsing), but it might still take some time before I have something usable in the wild. On other package managers: From time to time I also use Cupt, look at Cupt code, hack Cupt code, and report bugs against Cupt. I still do not really understand the (extreme) nesting of directory structures in the source code, why there are so (extremely) many source files split all over them, or the general concepts of Cupt, but I can hack together what I need for my personal testing. I also play with yum whenever I end up on a Fedora system (which happens from time to time).
Filed under: APT2

As everyone should know, underscores in C are not cool, as they cause undefined behavior per 7.1.3:

All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
[...]
If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

Yet, they are widely used everywhere. Here are some examples:

• inclusion guards in GLib: __G_VARIANT_H__
• internal Python functions: _PyUnicode_AsString
• various macros in APT: __deprecated, __hot

All of this triggers undefined behavior and is thus uncool. Of course in APT, it s most stupid, as we do not have any namespace and could thus
end up redefining things we should not much more likely then the other two. But why were those solutions chosen in the first place, and what is the alternative? I cannot answer the first question, but for the second one, the obvious alternative is to use trailing underscores:

• inclusion guards, defined behavior: G_VARIANT_H__
• internal functions, defined behavior: PyUnicode_AsString_
• various macros, defined behavior: deprecated__, hot__

Then there is another class of reserved identifiers with underscores:

All identifiers that begin with an underscore are always reserved for use as identifiers
with file scope in both the ordinary and tag name spaces.

Meaning that everything except for parameters, local variables and members of structs/unions that starts with an underscore is reserved. So, if you happen to create a variable _mylibrary_debug_flag, you trigger undefined behavior as well. And while we re at it, do not think you can create a type ending in _t: POSIX reserves all identifiers ending in _t for its own use. In summary, whenever you write C and want to be 100% safe of undefined-behavior-because-of-naming, do not start any identifier with an underscore and do not end any identifier with _t.
Filed under: General

Today, Marc has released phpMyAdmin 3.4.0. This is huge step and introduces lot of new features. The most noteworthy are:

• User preferences
• Relation schema export to multiple formats
• ENUM/SET editor
• Simplified interface for export/import
• AJAXification of some parts
• Charts
• Visual query builder

As you can see, many of new features come from last GSoC, it took us almost half year to stabilize all new stuff and make it work nicely together. Thanks to last minute improvements in Japanese, it is fully translated to 15 languages, other translations are little behind, but you can still help improving them for future releases. The master branch is now open to development and we will start to merge patches accumulated in patch tracker for addition after feature freeze. PS: I forgot to mention that this release fixed largest number of feature requests and bugs ever - over 160 issues from sf.net tracker got closed. This can be nicely seen on tracker stats. PS2: Package with new version was just uploaded to Debian.

Filed under: English Phpmyadmin 8 comments Flattr this!

Software in the Public Interest (the organisation behind debian and many more) will hold a public board meeting later today (Wednesday) at 20:30 UTC (=21:30 BST, 22:30 CEST or date -d @1305145800 to you). SPI meetings are held in #spi on irc.spi-inc.org (the OFTC network). The agenda for the meeting is available at http://www.spi-inc.org/meetings/agendas/2011/2011-05-11/ At the time of writing, there s a single resolution regarding Jenkins joining as an SPI associated project. Jenkins (formerly known as Hudson until the Oracalypse) monitors execution of jobs like software builds or scheduled tasks. Its website is http://jenkins-ci.org/ Why not come along and wish Jenkins well? Or just see if I m awake after a #koha meeting at 3am UK time?

For each and every bit of trite business advice, there is an equal and opposite bit of trite business advice "Fail fast" vs "be persistent" "The first person to mention a number in a negotiation loses" vs "by saying a number, you frame the negotiations" "Ideas don't matter" vs "the Number One startup killer ... making a product for which there is no interesting market" "Do something you're passionate about" vs "where there's muck, there's brass" "Business plans are a waste of time" vs "failure to plan is planning to fail" There's some valuable lesson behind all of these; I'm not saying these are bad advice. What I'm saying is that if it were so easy, more people would be doing it successfully. In reality, it's very difficult. What are some of your favorite equal and opposite bits of business advice?

(this post was going to be about something else, but after getting this far, I think it stands on its own as an introduction to dynamic linking) The shared library is an integral part of a modern system, but often the mechanisms behind the implementation are less well understood. There are, of course, many guides to this sort of thing. Hopefully this adds another perspective that resonates with someone. Let's start at the beginning - relocations are entries in binaries that are left to be filled in later -- at link time by the toolchain linker or at runtime by the dynamic linker. A relocation in a binary is a descriptor which essentially says "determine the value of X, and put that value into the binary at offset Y" each relocation has a specific type, defined in the ABI documentation, which describes exactly how "determine the value of" is actually determined. Here's the simplest example: The value of foo is not known at the time you make a.o, so the compiler leaves behind a relocation (of type R_386_32) which is saying "in the final binary, patch the value at offset 0x4 in this object file with the address of symbol foo". If you take a look at the output, you can see at offset 0x4 there are 4-bytes of zeros just waiting for a real address: That's link time; if you build another object file with a value of foo and build that into a final executable, the relocation can go away. But there is a whole bunch of stuff for a fully linked executable or shared-library that just can't be resolved until runtime. The major reason, as I shall try to explain, is position-independent code (PIC). When you look at an executable file, you'll notice it has a fixed load address This is not position-independent. The code section (with permissions R E; i.e. read and execute) must be loaded at virtual address 0x08048000, and the data section (RW) must be loaded above that at exactly 0x0805ff88. This is fine for an executable, because each time you start a new process (fork and exec) you have your own fresh address space. Thus it is a considerable time saving to pre-calculate addresses from and have them fixed in the final output (you can make position-independent executables, but that's another story). This is not fine for a shared library (.so). The whole point of a shared library is that applications pick-and-choose random permutations of libraries to achieve what they want. If your shared library is built to only work when loaded at one particular address everything may be fine until another library comes along that was built also using that address. The problem is actually somewhat tractable you can just enumerate every single shared library on the system and assign them all unique address ranges, ensuring that whatever combinations of library are loaded they never overlap. This is essentially what prelinking does (although that is a hint, rather than a fixed, required address base). Apart from being a maintenance nightmare, with 32-bit systems you rapidly start to run out of address-space if you try to give every possible library a unique location. Thus when you examine a shared library, they do not specify a particular base address to be loaded at: Shared libraries also have a second goal code sharing. If a hundred processes use a shared library, it makes no sense to have 100 copies of the code in memory taking up space. If the code is completely read-only, and hence never, ever, modified, then every process can share the same code. However, we have the constraint that the shared library must still have a unqiue data instance in each process. While it would be possible to put the library data anywhere we want at runtime, this would require leaving behind relocations to patch the code and inform it where to actually find the data destroying the always read-only property of the code and thus sharability. As you can see from the above headers, the solution is that the read-write data section is always put at a known offset from the code section of the library. This way, via the magic of virtual-memory, every process sees its own data section but can share the unmodified code. All that is needed to access data is some simple maths; address of thing I want = my current address + known fixed offset. Well, simple maths is all relative! "My current address" may or may not be easy to find. Consider the following: So foo will be in data, at a fixed offset from the code in function, and all we need to do is find it! On amd64, this is quite easy, check the disassembly: This says "put the value at offset 0x2002b2 from the current instruction pointer (%rip) into %eax. That's it we know the data is at that fixed offset so we're done. i386, on the other hand, doesn't have the ability to offset from the current instruction pointer. Some trickery is required there: The magic here is __i686.get_pc_thunk.cx. The architecture does not let us get the current instruction address, but we can get a known fixed address the value __i686.get_pc_thunk.cx pushes into cx is the return value from the call, i.e in this case 0x414. Then we can do the maths for the add instruction; 0x115c + 0x414 = 0x1570, the final move goes 0x18 bytes past that to 0x1588 ... checking the disassembly i.e., the value 100 in decimal, stored in the data section. We are getting closer, but there are still some issues to deal with. If a shared library can be loaded at any address, then how does an executable, or other shared library, know how to access data or call functions in it? We could, theoretically, load the library and patch up any data references or calls into that library; however as just described this would destroy code-sharability. As we know, all problems can be solved with a layer of indirection, in this case called global offset table or GOT. Consider the following library: Note this looks exactly like before, but in this case the foo is extern; presumably provided by some other library. Let's take a closer look at how this works, on amd64: The disassembly shows that the value to be returned is loaded from an offset of 0x200271 from the current %rip; i.e. 0x0200828. Looking at the section headers, we see that this is part of the .got section. When we examine the relocations, we see a R_X86_64_GLOB_DAT relocation that says "find the value of symbol foo and put it into address 0x200828. So, when this library is loaded, the dynamic loader will examine the relocation, go and find the value of foo and patch the .got entry as required. When it comes time for the code loads to load that value, it will point to the right place and everything just works; without having to modify any code values and thus destroy code sharability. This handles data, but what about function calls? The indirection used here is called a procedure linkage table or PLT. Code does not call an external function directly, but only via a PLT stub. Let's examine this: So, we see that function makes a call to code at 0x4d0. Disassembling this, we see an interesting call, we jump to the value stored in 0x200382 past the current %rip (i.e. 0x200858), which we can then see the relocation for the symbol foo. It is interesting to keep following this through; let's look at the initial value that is jumped to: Unscrambling 0x200858 we see its initial value is 0x4d6 i.e. the next instruction! Which then pushes the value 0 and jumps to 0x4c0. Looking at that code we can see it pushes a value from the GOT, and then jumps to a second value in the GOT: What's going on here? What's actually happening is lazy binding by convention when the dynamic linker loads a library, it will put an identifier and resolution function into known places in the GOT. Therefore, what happens is roughly this: on the first call of a function, it falls through to call the default stub, which loads the identifier and calls into the dynamic linker, which at that point has enough information to figure out "hey, this libtest.so is trying to find the function foo". It will go ahead and find it, and then patch the address into the GOT such that the next time the original PLT entry is called, it will load the actual address of the function, rather than the lookup stub. Ingenious! Out of this indirection falls another handy thing the ability to modify the symbol binding order. LD_PRELOAD, for example, simply tells the dynamic loader it should insert a library as first to be looked-up for symbols; therefore when the above binding happens if the preloaded library declares a foo, it will be chosen over any other one provided. In summary code should be read-only always, and to make it so that you can still access data from other libraries and call external functions these accesses are indirected through a GOT and PLT which live at compile-time known offsets. In a future post I'll discuss some of the security issues around this implementation, but that post won't make sense unless I can refer back to this one :)

DebConf11 program, the FOSS way I'm going to DebConf11 and, once more, I'm thrilled at idea of living for about 2 weeks immersed in a very very very, very Debian-ic life. DebConf10, DebConf edition of last year, has been for me one of the most intense DebConfs ever, it would be hard to match it. But one of the nice things about DebConf, no matter the edition, is that it's very "open source" and do-ocratic in they way it is organized: everyone could contribute into making it even better than the previous edition. For one thing, there is no "event organizer" company behind DebConf. Rather, most of the hard work that goes into making a DebConf possible is done by the DebConf team, a volunteer team formed by a mixture of Debian contributors, local team members, and DebConf enthusiasts. But while they take care of most of the work and hence deserve the thanks of all DebConf attendees for that they do not account for all that makes a DebConf a great DebConf. For instance, having a great program is up to DebConf participants and the event proposals they submit: talks, BoF, panel discussions, film projections, contests, you name it. Today, in deadline frenzy mode (read on), I've submitted for review the following events for DebConf11:

• bits from the DPL, the traditional "state of the union"-like address
• Test Driven Development BoF, about DEP-8 and autopkgtest (co-authored with Tom Marble)
• sprint and money BoF, to review one year of the Debian sprint program and further discuss how we use donations to the Debian project
• Debian dErivatives eXchange BoF, about DEX and other initiatives to improve collaboration with Debian derivatives
• DebConf in Debian BoF: one year later the "DebConf vs Debian" BoF, what's the state of integration of DebConf in Debian? (spoiler: good!) how can we improve it further? (co-authored with Gunnar Wolf, Holger Levsen, and Moray Allan)
• DPL wannabe BoF: inspired by a discussion during this year DPL campaign, an attempt to explain what the "DPL job" is about and, who knows, collect "training" material for wannabe DPLs
• rolling BoF: let's summarize the monster thread about Debian rolling for those we lost half-way through and present the advancements of more recent and consensual proposals (this event is actually not by me: I've just prodded some of the rolling proponents on IRC and Raphael Hertzog has kindly agreed to submit and organize the BoF)

That's it from me, how about you?
Are you going to DebConf and willing to attend a conference with a great program? Great, then start submitting a great event yourself! Anything you are working on in Debian or you are excited about qualifies. And don't worry if you've never attended DebConf either, video archives from past DebConfs can give you more than a feeling of typical DebConf events. While the first deadline for events submission expires today, submissions will be open all the way to the end of the conference, but you should better hurry up as the early birds get the best scheduling slots (and missing the deadline, you'll miss the round of the review for the main program ... but you still have a few hours left :)). Good luck and see you in Banja Luka.

One of my last blog suggested a way to systematically clean up versioned dependencies in packages. Given the comments posted thereafter, it s clear that the one-size-fits-all strategy is ill-advised. Sorry about that. So, should these versioned dependencies be cleaned up or not ? Well It depends. Cleaning up versioned dependencies will hurt people when the package you re working on may be back-ported to old version of Debian. In corporate world, upgrading a machine may cost a lot, so you can still find production machine running etch. I would not be surprised to hear about older systems still used in production. In consumer world (mostly desktop or multimedia), people will mostly run more recent versions of Debian. All in all, the following elements must be considered before removing old versioned dependencies:

• Is the package likely to be installed on server ? or is it more targeted to consumer world ?
• What is the policy of the maintenance group of this package ? For instance, Debian perl group policy is to clean up versioned dependencies older than old-stable.

Unfortunately, there s no universal strategy. In case you want to clean up old dependencies, the latest version of Dpkg::Control model for Config::Model will be helpful. The last version of this models provides a bunch of meta Dpkg parameters. These parameters are used to customize the behavior of the Dpkg editor tool to suit your needs (For more details, see Config::Model::models::Debian::Dpkg::Meta). The dependency meta parameters will enable you to tune the behavior of config-edit to your needs. There are 3 dependency parameters, from the most global to the most specific ones:

• dependency-filter: your personal general policy
• group-dependency-filter: the policy of the maintainer group of your package
• package-dependency-filter: filter policy specified per package

Before applying a cleanup, config-edit will check the policies in the above order. The most specific one will be applied. Ie. the group policy will supersede your personal policy and the package specific policy will override the group policy. Here s a screenshot of config-edit GUI invoked on a package: From the parameters set in the GUI above, you can see that a warning will be raised for :

• perl package with versioned dependencies older or equals than lenny
• any other package with versioned dependencies older or equals than etch

Last but not least, if you want to use config-edit without any dependency filtering, just make sure that all these filter parameters are empty. You will still benefits from other features, like warning if a package dependency is unknown, which is useful to catch typos. All the best

Steve Langasek has been contributing to Debian for more than a decade. He was a release manager for sarge and etch, and like many former release managers, he s still involved in the Debian release team although as a release wizard (i.e. more of an advisory role than a day-to-day contributor). Oh, and he did the same with Ubuntu: on the picture on the left, he just announced the release of Ubuntu 10.04 from his Debian-branded laptop. He has also been maintaining PAM in Debian for as long as can I remember and does a great job at that. He s very knowledgeable and fully deserves his place within the Debian Technical Committee. I m glad he still has the time to participate on several important Debian mailing lists because his contributions are always very useful. I m sure you ll notice this just by reading his answers below. My questions are in bold, the rest is by Steve. Who are you? I m 32 years old, have been running Linux since my first year in college back in 96, and have been a Debian developer now for ten years. Along the way I ve been involved in maintaining a variety of server packages, worked on the Alpha port for a while, did a stint as a release manager for a couple of years, and serve on the technical committee. This year I m also celebrating my ten year anniversary with my lovely wife Patty, who many know as an erstwhile front-desk volunteer at DebConf. God only knows why she puts up with my late-night hacking! These days in my day job I m a manager on the Ubuntu Platform team at Canonical, working to help make Ubuntu a daughter distribution that the Debian community can be proud of. What s your biggest achievement within Debian or Ubuntu? There s no doubt that my biggest achievement in Debian has been overseeing the release of two Debian releases as release manager. On the other hand, the scope of a release is so huge, and it represents the output of so many developers working together, that it would be arrogant to claim the release itself as an achievement of my own. Also, sarge and etch have long since been rotated off of the mirrors so no one cares about them anymore. For a more personal and lasting contribution in the distro itself, I m very proud of writing pam-auth-update. It s a small piece of code, but one that Debian was missing for a long time it s made a big difference to PAM module integration in packages! What are your plans for Debian Wheezy? My top priority for this cycle is to see multiarch through. We re still not far enough along in Debian for most developers to see any difference and once we are, the first thing people are going to see is a fair bit of breakage when we start breaking a lot of assumptions about paths that have been hard-coded upstream. But I m still excited by the progress that is being made here. We should be able to ship wheezy without any ia32-libs package. We might even be able to get rid of all the biarch library packages, including those used by the toolchain itself. 54 packages in testing build-depend on gcc-multilib right now, in order to build 32-bit code to ship in the amd64 package; a bunch of those should go away with absolutely no reduction in functionality, saving us a bit of space in the archive and saving the maintainers a lot of complexity in their packages, while at the same time giving us much better support for cross-compilation than we ve ever had before. It s a tall order, certainly, but the pieces are falling into place one by one. My second priority is to get a policy in Debian around packages integrating upstart jobs. It would of course benefit Ubuntu to have many packages back in sync with Debian, but if all we wanted was to sync with Debian, we could mostly just make debhelper ignore upstart jobs in Debian, prefer them in Ubuntu, and call it good. I m interested in making sure Debian also gets the benefits of being able to use upstart, because as Linux has become increasingly asynchronous (doing more in parallel at start up), the traditional sysvinit has not been able to keep up. There are all kinds of bugs now related to network startup, for instance, that we don t have a good answer for in a sysvinit model but that we can fix with an event-based system. Upstart has been around for a while now, but we ve been slow to integrate it into Debian because it only works on Linux. It would be a shame if right after the first Debian GNU/kFreeBSD technology preview, packages all stopped working on kFreeBSD because they started to assume the availability of upstart! Unfortunately, having been so cautious we now have systemd on the scene, which not only doesn t support non-Linux but seems to be in the process of trying to gobble up other, non-Linux-specific components of the desktop stack. So I have to wonder what the future holds for the free desktop on non-Linux kernels. If you could spend all your time on Debian, what would you work on? Well, based on my previous experiences when I did spend all my time on Debian, I think the answer here is QA / release work. Otherwise, I don t know. My hands are full enough now with multiarch that it s hard for me to see what the Next Thing would be. You re a member of the technical committee. In the interview of Bdale Garbee, I have argued that it s not working well. What s your point of view on this topic? Well, I feel a constant low level guilt about my own poor level of activity in the TC; but that doesn t translate into a belief that the system is broken. This is, after all, the decision making body of last resort for technical disputes in Debian, and as such it should really be used sparingly. And if a reputation for glacial deliberation means more developers work out their disputes on their own rather than asking the TC to step in, I think that s actually a healthy thing! I do still wish we were more effective at resolving those issues that do come our way, but there s no silver bullet for this. Though the funny thing is, I ve noticed that the majority of issues that get referred to the TC nowadays never even need us to make a decision; a short conversation with the disputants is often enough to get them to come to an agreement. What s the biggest problem of Debian? By and large, I think Debian is still doing a great job at what it s best at delivering a rock-solid distribution that users can rely on. If I would highlight one problem in Debian, though, it would be that I think we re becoming less innovative as time goes on. Part of that comes from being such a large project that we re bound to be more conservative as an institution; but even though the three pet Debian projects of mine that I mentioned above are fairly innovative (multiarch, pam-auth-update, upstart), each of these has landed first in Ubuntu rather than in Debian. Always with a clear intent of pushing back up into Debian, of course, but it just wasn t possible to do this work within Debian for the first cut without much longer delays. I worry that if Debian is no longer the place to try new things, that we re going to miss out on attracting contributions from the folks who are inspired to make Free Software better and not simply to make it stable. I m not sure how to address this, though. Maybe improved conversations with derivatives such as (but not limited to) Ubuntu, about what crack of the day is being tried where and how that can be integrated into Debian once it s proven to work? I don t think that team-based maintenance or low-threshold NMUs do anything to address this, though, as the kinds of innovation that matter most are ones that require discussion and consensus-finding not just routing around inactive maintainers. Do you have wishes for Debian Wheezy? Well, I d like to see the armhf port get on its feet and become an official port. Over the lifetime of the arm and armel ports, the state of the art on ARM has changed quite a bit; it would be great to see Debian taking advantage of this richer platform, to let people make better use of their hardware via Debian. As a former release manager, you re now a release wizard . I guess you have seen it on debian-devel, there are proposals to not freeze testing and to use another distribution starting as a snapshot of testing to finalize the new stable release. According to your experience, what needs to happen to make this possible? Frankly, I ve stayed out of that discussion because I don t think what s being asked for is possible. I think proponents of a freezeless release have seriously underestimated the amount of work required on the part of the release team to wrangle testing into a releasable product, and that anything that makes propagation of fixes into the pending release more time consuming will make Debian worse on the whole, not better. If people really want to avoid long freezes for the Debian release, the best way they can help this happen is by making Debian more releasable on an ongoing basis, by helping to hold our packages to our shared standards for quality (i.e., by fixing RC bugs!). The biggest factor in long freezes for Debian is the slow rate at which we bring the RC bug count down during the freeze. Back in the sarge, etch days we used to have really great bug squashing parties that would get people together on weekends to hack through RC bugs by the dozens. I don t see that happening as much anymore. I d really like us to get back to that, but my few attempts at this so far since retiring as release manager have led me to think I m really terrible at organizing parties of any kind. On the other side, as seen at http://bugs.debian.org/release-critical/, the RC bug count for testing at the beginning of the release cycle keeps getting higher and higher. I d love to know why that is so we can address it. I know we ve gotten better at detecting some classes of RC bugs; that s part of it, but I don t think it explains the whole trend. Is there someone in Debian that you admire for their contributions? Wow, what kind of arrogant jerk would I be if I didn t admire anyone in Debian for their contributions? Debian is and always has been an amazing community of top-notch developers; there are certainly too many I admire to list them all here. Joey Hess certainly makes the list, for his longstanding example of code speaking louder than words and for his ability to get to the heart of common problems and come up with elegant solutions. So does Russ Allbery, who by all accounts had his ability to feel anger in response to email burned out of him at a young age in a flame-related accident on Usenet. The list goes on, but here I think I have to follow Joey s example and cut the words short.

---

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. 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, Twitter and Facebook.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

This June, soon after my seventh anniversary with Canonical, I will finish my job as Ubuntu CTO at Canonical. You can read my official announcement on the Canonical blog. It s sometimes hard to believe that it s been that long since we first envisioned a Linux desktop for human beings . When I look at how far we ve come, at the difference we ve made to so many people, it s easy to see how the time passed so quickly. It s been an incredible experience for me to play a part in building Ubuntu and Canonical. Whether building a decentralized company of hundreds of people, to a global community project of tens of thousands of members, I m grateful for all of the learning opportunities along the way. It has been a privilege to work with so many brilliant, passionate and thoughtful people under such auspicious circumstances. There is much I will miss, and I have many memories to enjoy, from all-night global hacking sessions driving toward a ship date, to casual singing and playing music at our many face-to-face events Nonetheless, it is time for me to seek out new challenges and stretch myself in new ways. I ll be moving back to the US, closer to old friends and family, and starting a new job with a different type of company. I am leaving behind a capable and dedicated team at Canonical, who I am confident will achieve even greater things in the years to come. I will remain active in the free software community as a volunteer. I intend to continue to participate in Ubuntu, and to serve on the Technical Board. I will also be continuing my work with Debian and the DEX project. This year, I ve accepted advisory positions with the Ada Initiative and the Freedom Box Foundation, and will continue to support those organizations and their missions. I ll be in Budapest at the Ubuntu Developer Summit for the next week, and look forward to seeing my friends in Canonical and the Ubuntu community. I ll have more to say soon about what I ll be doing next professionally. Watch this space for updates!

After almost 10 years the Americans finally found Osama bin Laden, unfortunately they were unable to take him alive. The Reid Report has a good summary of what happened [1]. Sam Varghese wrote an interesting analysis of the political aspects of this event in Pakistan [2], and he s a lot less positive about it than most people. Later he wrote about the inconsistencies in the reports, it seems that bin Laden was executed while unarmed [3]. When dealing with someone who is no stranger to suicide attacks and who has stated an intention to never be taken alive it s not unreasonable to shoot quickly, it s just a pity that they couldn t have been honest from the start. Dr. Pamela Gerloff wrote an insightful article for Psychology Today titled Why We Should Stop Celebrating Osama Bin Laden s Death [4]. She asks the rhetorical questions What kind of nation and what kind of species do we want to be? Do we want to become a species that honors life? Do we want to become a species that embodies peace? and suggests that we should mourn the series of tragedies that led up to this situation and to feel compassion for anyone who, because of their role in the military or government, American or otherwise, has had to play any role in killing another . Daniel R. Hawes wrote an insightful article for Psychology Today that s quite different from Dr. Gerloff s article [5]. He is quite glad that bin Laden is dead. But he considers how the people who have lost friends and relatives on 9-11 might feel about this and says that the shouts and celebratory chants that rang around America today seemed to me to carry a certain element of irreverence for those affected most deeply by the September 11 attacks and the entire military operations that followed . To represent the people who are partying now there is a post by Jenny Lind Schmitt that is totally unworthy of a site such as Psychology Today [6]. Jenny told her small children about al Quaeda: They hate you because you are American. Their god is destruction, and they would kill you, a little child, if they had the chance, just because you are American. She also describes al Quaeda as lunatics . Describing all your enemies as lunatics is quite common in general conversation, but it s not suitable for a web site that discusses psychology (where some respect for people with mental health issues is expected). Teaching children to be bigoted against Islam is a bad thing too. It seems to me that a factor in the violence that comes from the middle-east is a result of women just like her telling their children similar things but with country names and religions switched. Finally some capacity for empathy is required for someone to have any insight into psychology, someone who can t understand such things can t be competent to discuss psychology. In stark contrast to Jenny (who bears an irrational hatred in spite of apparently not having any close connection to the events in question) there is a TED talk by Phyllis Rodriguez (who s son was killed in the 9-11 attacks) and Aicha el-Wafi (who s son is in jail for being a member of al Quaeda and was accused of being part of the 9-11 plot) [7]. The two women became friends after 9-11 and work together in the cause of peace. From reading some interviews that Google turned up Aicha seems like a very intelligent woman, I think that the TED talk with her section translated from French to English didn t seem to show this. Perhaps people who speak French and English would get more from the TED talk than I did. Also perhaps if she gave a talk to a French audience and it was subtitled then the result would be better. Now of course the less intelligent people on the right-wing are trying to spin this to say that Bush deserves credit for getting bin Laden. The Reid Report has a good analysis of the history of the hunt for bin Laden and it doesn t make Bush look good [8]. Also the Reid Report has an interesting analysis of the operation to get bin Laden and the possibility for peace now that he s gone [9]. LA Times has an article about the use of the name Geronimo as a code-word for bin Laden [10]. But compared to the use of words such as crusade and paladin by the US armed forces this hardly rates a mention.

• [1] http://blog.reidreport.com/2011/05/behind-the-operation-to-get-osama-bin-laden/
• [2] http://wildcard.gnubies.com/?p=574
• [3] http://wildcard.gnubies.com/?p=611
• [4] http://www.psychologytoday.com/collections/201105/the-demise-bin-laden-and-the-future-terrorism/revenge-nothing-celebrate
• [5] http://www.psychologytoday.com/collections/201105/the-demise-bin-laden-and-the-future-terrorism/is-not-america
• [6] http://www.psychologytoday.com/collections/201105/the-demise-bin-laden-and-the-future-terrorism/what-bin-ladens-death-means-our-kid
• [7] http://www.ted.com/talks/9_11_healing_the_mothers_who_found_forgiveness_friendship.html
• [8] http://blog.reidreport.com/2011/05/dead-or-alive-the-sorry-history-of-george-w-bush-and-the-hunt-for-osama-bin-laden/
• [9] http://blog.reidreport.com/2011/05/10-things-we-now-know-about-the-operation-that-got-bin-laden/
• [10] http://latimesblogs.latimes.com/washington/2011/05/congress-to-discuss-use-of-geronimos-name-in-bin-laden-mission.html

liw recently wrote about test-driven development:

This all sounds like a lot of bureaucratic nonsense, but what I get out of this is this: once all tests pass, I have a strong confidence that the software works. As soon as I've added all the features I want to have for a release, I can push a button to push it out

To my mind, this is only one of the benefits. He doesn't describe another major benefit, which is the confidence with which you can take on re-factoring in projects with well-developed test infrastructure. If your project has no test infrastructure at all, and you make a deep and/or potentially invasive change, you might well produce something that is heinously broken for users who have a different pattern of using the tool than you do. But if you have a well-developed, reasonable test suite with fairly wide coverage, you can make a deep or invasive change, and be confident that -- if the tests all pass -- the stuff you release isn't going to be too horrific. And if you do break something with a change which the test suite didn't cover, that's an indication that the test suite is lacking. Hopefully, you can factor out a problem report into its own test, so that future changes will ensure that the behavior doesn't regress too. The upshot of more-confident re-factoring is that your development can be much bolder, you can roll out new features more quickly, and you can spend less time agonizing about whether you've got the various abstraction layers exactly right the first time through. These are all good things (though i do think the agony of abstraction perfectionism is well-warranted in some contexts, like API definitions, and wouldn't want test-driven development to make people give up on that necessary task). when testing can't cover everything Some things are just hard to test well. for example, if you have 20 different boolean options to a command-line tool, you can't realistically test them in all combinations and permutations; that would be over a million tests. User experience is also notoriously difficult to test, as are tools that rely heavily on network interaction, which can be flakey and unpredictable. other downsides Test suites themselves require maintenance, as the components they rely on can change over time. More than once, i've had a test suite failure that was really a failure of the test infrastructure, not the code itself. But in those same projects, that's usually followed or preceded by a test suite failure that picks out a particularly nasty or subtle bug in the tested code that might have persisted for quite a while unnoticed. So the test suite does in some sense create more work all around. more and better testing is good for Debian Even when we know that coverage isn't perfect, and even with its additional overhead, well-integrated tests (at the unit level and more generally) are worth the tradeoffs. It's worth doing because of the robustness and guarantees that we can give each other with regularly-tested code. It's a more stable foundation which surprisingly also gives us more flexibility going forward. This is good for free software in general. It also helps us find our bugs before our users do, so it's better for our users. So more and better testing directly supports the two main priorities outlined in the Debian Social Contract.

This is my monthly summary of my Debian related activities. If you re among the people who support my work, then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. GNOME 3 packaging Right after the GNOME 3 release, I was eager to try it out so I helped the pkg-gnome team to update some of the packages. I did some uploads of totem, totem-pl-parser, gvfs, mutter, gnome-shell, gnome-screensaver. I also kept people informed via my blog and prepared a pinning file for adventurous users who wanted to try it out from experimental (like me). One month later, I m still using GNOME 3. There are rough edges still, but not so many. And I m starting to get used to it. Debian Rolling planning Debian Rolling is a project on my TODO list for quite some time. I decided it was time to do something about it and started a series of articles to help clarify my ideas while getting some early feedback. My goal was to prepare a somewhat polished proposal before posting it to a Debian mailing list. But as usual with Murphy s law, my plan did not work out as expected. Almost immediately after my first post the discussion started on debian-devel:
At this point it s a discussion thread of several hundreds of messages (there are several screens of messages like the one above). Many of the sub-threads have been interesting, but the general discussions mixed too many different things so that there s no clear outcome yet. Lucas Nussbaum tried to make a summary. Obviously I must adjust my plan, there s lots of feedback to process. I accepted to drive a DEP together with Sean Finney to help structure the part of the discussion that focuses on allowing development to continue during freezes. But I m also eager to fix the marketing problem of testing and have the project recognize that testing is a product in itself and that end-users should be encouraged to use it. Package Tracking System maintenance The Package Tracking System is an important tool for Debian developers, and it has been broken by some change on the Bug Tracking System. I worked around it quite quickly so that few people noticed the problem but Cron kept reminding me that I had to properly fix it. I ended up doing it last week-end. While working on the PTS, I took the opportunity to merge a patch from Jan Dittberner to enhance the news RSS feed that the PTS provides. And I also integrated information from backports.debian.org (thanks to Mehdi Dogguy for reminding me #549115). Multiarch update Not much new this month. I fixed two bugs in the multiarch dpkg branch thanks to bug reports from Ubuntu users (LP 767634, LP 756381). I m still waiting on Guillem Jover finishing his review of the multiarch branch. I m pinging him from time to time but it looks like multi-arch is no longer in his short term priority list. I ve been running this code for more than 2 months and it works fine. I want to see it merged. I m ready to update my code should anything need to be changed to please Guillem. But without any feedback we re in a deadlock. Misc dpkg work While fixing a bug in update-alternatives (found in one of the valid reports on launchpad), I noticed that there was room for improvements in the error messages output by update-alternatives. I changed them to reuse the same strings that were already used in other parts of dpkg. The result is that there are a few strings less to translate (always a nice thing for the poor translators who have to deal with the thousands of strings that dpkg contains). I also tried to fix some of the most cryptic error messages in dpkg (see #621763) but that work is stalled at the request of Guillem. Book update We (me and Roland Mas) are almost done with the update of our French book for Debian Squeeze. It will hit the shelves in July or September. I m starting to prepare the fundraising campaign to make an English translation of it. We ll use ulule.com for this. On my blog I have been pleased to interview Meike Reichle, it s the first women that I have interviewed in the series but it s certainly not the last one. I also interviewed Adam D. Barratt, one of our tireless release managers. Thanks Many thanks to the people who gave me 180.35 in March and 235.37 in April. That represents 1.5 and 2 days of work for those months. See you next month for a new summary of my activities.

8 comments Liked this article? Click here. My blog is Flattr-enabled.

When building a user space binary, the -lc that gcc inserts into the final link seems pretty straight forward link the C library. As with all things system-library related there is more to investigate. If you look at /usr/lib/libc.so; the "library" that gets linked when you specify -lc, it is not a library as such, but a link script which specifies the libraries to link, which also includes the dynamic linker itself: On very old glibc's the AS_NEEDED didn't appear; so every binary really did have a DT_NEEDED entry for the dynamic linker itself. This can be somewhat confusing if you're ever doing forensics on an old binary which seems to have these entries for not apparent reason. However, we can see that that /lib/libc.so itself does actually require symbols from the dynamic linker: Although you're unlikely to encounter it, a broken toolchain can cause havoc if it gets the link order wrong here, because the glibc dynamic linker defines minimal versions of malloc and friends -- you've got a chicken-and-egg problem using libc's malloc before you've loaded it! You can simulate this havoc with something like: Depending on various versions of things, you might see that assert or possibly just strange, corrupt output in your logs as syslog calls the wrong malloc. You could debug something like this by asking the dynamic linker to show you its bindings as it resolves them: Above, because the dynamic loader comes first in the link order, libc.so.6's malloc has bound to the minimal implementation it provides, rather the full-featured one it provides internally. As an aside, AFAICT, there is really only one reason why a normal library will link against the dynamic loader -- for the thread-local storage support function __tls_get_addr. You can try this yourself: Thread-local storage is worthy of a book of its own, but the gist is that this support function says "hey, give me an address of foo in libtls.so", the magic being that if the current thread has never accessed foo then it may not actually have any storage for foo yet, so the dynamic linker can allocate some memory for it lazily and then return the right thing. Otherwise, every thread that started would need to reserve room for foo "just in case", even if it never cares about moo. But looking a little closer at the symbols of libc.so is also interesting. libc.so doesn't actually have many functions you can override. You can see what it is possible to override by checking the relocations against the procdure-lookup table (PLT). i.e. instead of jumping directly to the malloc defined in the libc code section, any internal calls will jump to this stub which, the first time, asks the dynamic linker to go out and find the address of malloc (it then saves it, so the second time the stub just jumps to the saved location). This is an interesting list, seemingly without much order. feof, for example, stands out as worth checking out a bit closer why would that be there when fopen isn't, say? We can track down where it comes from with a bit of detective work; knowing that the value of the symbol feof will be placed into 0x35b018 we can disassemble libc.so to see that this address is used by the feof PLT stub at 0x1e870 (luckily, objdump has done the math to offest from the rip for us; i.e. 0x1e876 + 0x33c7a2 = 0x35b018) From there we can search for anyone jumping to that address, and find out the caller: Which turns out to be part of a local patch which probably gets things a little wrong, as described below. The sysconf relocation is from a similar add-on patch (being used to find the page size, it seems). libc, like all sensible libraries, uses the hidden attribute on symbols to restrict what is exported by the library. The benefit of this is that when the linker knows you are referencing a hidden symbol it knows that the value can never be overridden, and thus does not need to emit extra code to do indirection just in case you ever wish to redirect the symbols. In the above, it appears that feof has never been marked as hidden, probably because no internal glibc functions used it until that add-on patch, and since it is not considered an internal function the linker must allow for the possibility that it will be overridden at run time and provide a PLT slot for it. There are consequences; if this was on a fast-path then the extra jumps required to go via the PLT may matter for performance and it may also cause strange behaviour if somebody had preloaded something that took over feof. Note, this is different from saying that your library can override symbols provided by libc.so; such as when you LD_PRELOAD a library to wrap an open call. What you can not override is the open call that say, the internal libc.so function getusershell does to read /etc/shells. Having the malloc related calls as preemptable seems intentional and sane; although I can not find a comment to the effect of "we deliberately leave these like this so that users may use alternative malloc implementations", it makes sense so that libc.so is internally using the same malloc as everything else if you choose to use something such as tc-malloc. tl;dr? Digging into your system libraries is always interesting. Be careful with your link order when creating toolchains, and be careful about symbol visibility when you're working with libraries.

A few days ago I did an interview for the People Behind Debian series that, among other things, covered my Debian press work and asked what it's like to do that kind of work for Debian. Here's a little addendum: Sometimes Debian Press Work is great: All these people do all this amazing stuff and it's a pure pleasure to talk about it. Our last release was such an experience for example. I was clamped to my laptop for almost 20 hours straight and I had a great time! There was this great common feeling of community, achievement and pride in our work and I was proud and happy to be a part of it. And then there are times like the last few days, where Alex and I went South for 4.5 precious and long-awaited days of vacation and ended up spending the first two of them working on an obituary for a dear and much valued member of our community and once this was done spent the remaining days of our holidays nervously watching the net and drafting and re-drafting press announcements because some <bleep> thought it might be oh-so-hilarous to send out faked cease and desist orders to a Debian user, ostensibly as a funny prank but along the way causing a huge amount of completely unsubstantiated FUD that we'll probably spend weeks clearing up. Somewhere in between these events is what Debian press work is like.

As you might know, I m of one the people who promote the idea of having a Constantly Usable Testing (CUT). I will post a set of articles on this topic to help me clarify my ideas and to get some early feedback of other Debian contributors. I plan to use the result of this process to kickstart a broader discussion on debian-devel (where I hope to get the release team involved). Let s start by defining my own objectives with Debian CUT. I won t speak of the part of Debian CUT that plans to make regular snapshots of testing with installable media because that s not where I will invest my time. I do hope other people will do it though. Instead I will concentrate on changes that would improve Debian testing for end-users. I consider that testing (in its current form) is largely usable already but there are two main obstacles to overcome. Testing without freezes = rolling The first one is that testing is no longer testing during freezes. The regular flow of new upstream versions that makes testing so interesting for many users is stalled because we re using testing to finalize the next stable version. That s why I d like to introduce a new suite called rolling that would work like the current testing except that it never freezes. Testing would no longer be a permanent suite, it would only exist during the freeze and it would be branched off from rolling. Rolling should be a supported distribution The second obstacle is not really technical. We must advertise rolling as a distribution that ordinary people can use but we should make it clear that it s never going to have the same level of polish that a stable release can have. And to back up this assertion, we must empower Debian developers to be able to provide good support of their software in rolling, this probably means using rolling-proposed-updates more often to push fixes and security updates when the natural flow of updates is blocked by transitions or other problems. Some maintainers won t have the time required to provide the same level of support as they currently do for a stable release and that s okay, it s not worse than the current testing. The goal is to treat it on a best-effort basis and to try to gradually improve the situation. My goal for wheezy This is the the minimal implementation of CUT that I would like to target in the wheezy timeframe. Having testing as a temporary branch of rolling is not a strict requirement, although I d argue that it s important to not waste resources towards maintaining two separate yet very similar distributions. Should Debian embrace those goals? Ignoring all possible problems that will surface while trying to implement those goals, can we agree that Debian should embrace those goals because it means providing a better service to a class of users that is not satisfied by the current stable release? I will come back to the expected problems in a subsequent post and we will have the opportunity to discuss them. Here I just want to see whether we can have broad buy-in on the principles behind Debian rolling and CUT.

23 comments Liked this article? Click here. My blog is Flattr-enabled.