Once again Debian is close to release. And once again we're trying to find ways to avoid doing so. Using a technique we've employed before; firmware.
Social Contract #4 states that "Our priorities are our users and free software". The hard liners believe that it's in our users' best interests that we ensure Debian is 100% Free, whether that be regarding software, documentation or firmware. In the long run I think they're right. Access to firmware source (assuming that there's also access to
suitable tools for building it and producing an image the hardware will accept, which is a fairly big assumption) enables us to continue supporting and improving hardware support long after a manufacturer has discontinued a device. It enables us to understand the behaviour of a new device better (allowing better support which makes it a more attractive purchase). It potentially lets us appropriate a device for new and exciting purposes the manufacturer never imagined (which may again increase the sales of the device). Access to firmware source is a good thing in the long term, for the consumer, the driver author and the manufacturer.
In the short term we I think we need to be pragmatic. We can say that we won't release until all non-free firmware is purged, but who knows how long that will take, and once we've done so how much hardware will we actually be able to support out of the box? What benefit is it to our users if we ship them a distribution that doesn't support their hardware and is already out of date because we spent so long removing that support? Wouldn't we be better to say "We're aware of some firmware issues. We're going to keep working on spliting such blobs out to their own easily installable packages that live outside main. We promise to continue improving the situation for each release (as we have already done since etch), but in the interests of our users we will not hold up a release at this stage of the process." Obviously plenty of people disagree with that, but I don't believe that pragmatism is against the Social Contract and I'd like to think that even our users who are fervently against firmware blobs would accept that there's a tradeoff to be had against release dates.
Anyway. I doubt I've changed anyones mind with the above, so I'm going to go and destack the dishwasher and reply to the latest mail from my NM.

Ingo blogs about the current vote, and wonders whether we did not have enough time in two years to do something about the fact that there were firmware blobs in the kernel. Well, we did, and we did. It's just that in two years, several new kernel releases came out, and that also resulted in some new firmware blobs entering the kernel. This, in a way, is a relatively new issue. Having said that, I do agree with his sentiment; even if they're new issues, they could and should have been fixed ages ago. As I said in my 'no more hitting' post, too. Speaking of which, Jorg did not understand why that post did not show up, either. So I've just moved it into /en/computer/debian (where it belongs, really); perhaps that will fix it. Having been the maintainer of Planet Grep for a few years, I know now that this kind of strange behaviour would not be beyond planetplanet...

That is, the python software which runs a blog planet; not a particular planet instance. Case at hand: I wrote a rather extensive piece on the current Debian vote, but it's not showing up on Planet Debian for one reason or another that I can't immediately find out. I wouldn't even have know if not for Kurt, who noticed that it did show up on Planet Grep, but not on Planet Debian. I contacted the planet people, hopefully this will get resolved. Perhaps it's related to the fact that I semi-accidentally also committed that blog post about gnodbify-gtk, which I still had to proofread. Oh well...

Next semester I am teaching a new undergraduate course tentatively titled Technology, Society, and Media: The Body under Transition, in Movement, and under (Massive) Transformation(s). As designed, the course should address technology and media in fairly broad stokes (which I do) but I narrow and control what is a truly unwieldy subject by framing the issues/readings in relation to the human body. Generally speaking, we will interrogate the ways in which technology engenders or erases bodily/human possibilities/capacities and especially the ethical and political ramifications that precipitate from the use/abuse of technology. We traverse a wide range of topics from the telegraph (and how it was used to speak with the dead) to the role of human enhancement technologies of today, to questions of surveillance and privacy, among many other topics. I am pretty far along with the syllabus and pretty happy with it. So far I think I have struck a nice balance between fun/light/accessible readings and some which are bit more theoretically dense. I am still looking for one or two pieces, perhaps one on tattoos and body modification and another about karaoke. If anyone knows any great articles on these topics, do pass along the information. I am probably most excited about the cluster of issues that address eugenics (and most students know next to nothing about America s central role in unleashing the Eugenics movement), disability rights activism, human enhancement technologies, and transhumanism. Considering human enhancement in light of previous efforts to enhance our population brings into relief the similar and distinct ethical issues that haunt this field. One of the most hot button issues of today concern the use of human enhancing drugs. The prestigious journal Nature has just published an editorial on the topic of cognitive enhancement drugs,Towards responsible use of cognitive-enhancing drugs by the healthy, which is a fairly interesting read and covers some of the main controversies. For me, however, the interesting issue is not only whether human enhancement is right or wrong though this is certainly important but what our embrace of these drugs tell us about the conditions under which our bodies live and labor. That is, I think we are actually missing out on posing some other important questions simply by framing this int terms of human enhancement. I suspect, and this is where ethnography would really help out, that many people turning to enhancement drugs may not be medically sick, in the technical sense but I don t think they are healthy either. Many who turn to these drugs feel pretty worn, pretty exhausted, pretty frazzled (the perfect word, I think, is agotado, Spanish for exhausted) and use these drugs as crutches, as band-aids, as an elixir to help out one preserver in tough work circumstances. I am sure there are folks who take these drugs feel fine and are just trying to push their limits and capacities but I troll many many many patient support sites and it also seems to me that many people live under a state of low-grade chronic state of unwellness. Given the pace of society, given what and how we eat, given the extraordinary rates of depression in our society ,given the fact that babies are born with 200 + chemicals in their bodies (what a way to start out life) I am skeptical that enhancement really captures what is going on with these drugs. I have not yet come up with the right term, but I am trying to come up with a phrase that would reflect the ways in which these drugs are not used as therapies for a discrete condition (Type 1 diabetes) but how they are a collective response to a state of low grade chronic unwellness that seems to mark the lives of a whole lot of people. This, I think, would be one responsible approach to human enhancement technologies that would contextualize their use within a much broader frame, one that is attuned to how bodies have been made, remade, and limited under actual material conditions of labor and life in the 21st century.

One of the things I have noticed running http://www.langpop.com is that, pulling data from different sources, the odds are surprisingly hight that at any given point in time, one of the sources will be out of wack, often in a subtle way that's hard to see in the results. For instance, in the December 2nd run, the Amazon results were a bit wonky, and Delicious has been gradually falling out of the Yahoo search results (weird, that). I decided to go with screen scraping for Delicious, even though, frustratingly, Delicious can't tell the difference between C, C++ and C#, so while we wait and hope that that gets fixed, those languages are all going to show nearly identical results. I have updated the site.

* Mooch will stay at my place for a month. He brought me back my smile when he landed in MAD
* Shopping for cool tshirts always makes me feel good!
* New antidepressants, working great form day-1

Yes, humans are^W^WI am quite simple after all.

Regarding the ballot currently before the Developers, Christian Perrier writes:

Moreover, the proposal is worded and was pushed in a way that all (but one) options that would allow us to release lenny will need a 3:1 majority, which is obviously very hard to achieve (and as, there are several such proposals, the vote will be spread out among all of them). So, those folks who make the release of lenny their priority are now facing an interesting tactical choice: how the ..... should we vote for this to happen? I personnally did choose to vote this way: 5462371.

I agree with Christian's goals, but in my opinion, the ballot he has cast actually makes less likely that the winning option will allow us to release lenny. In Debian, we run a two-round election using a single ballot. In the first round, any options that need a 3:1 majority must defeat the default option by a 3:1 majority. Options which fail this test are eliminated and dropped from further consideration. In the second round, a winner is chosen from the remaining options using a Condorcet method as usual. The upshot of this is that the votes for the 3:1 majority cannot be spread out, unless people habitually place only one of the 3:1 options over Further Discussion. Furthermore, voting everything below Further Discussion benefits the options that don't require a 3:1 majority over the ones that do. For a real example, let's say that we have a ballot like this:

[ ] Choice 1: Omelette [3:1]
[ ] Choice 2: Quiche [3:1]
[ ] Choice 3: Toast
[ ] Choice 4: Further Discussion

Suppose that we don't like the ballot at all, but we want an egg-based breakfast. What happens if we vote like this?

[2] Choice 1: Omelette [3:1]
[3] Choice 2: Quiche [3:1]
[4] Choice 3: Toast
[1] Choice 4: Further Discussion

This ballot can be read as: I don't think that omelettes or quiche should pass the 3:1 majority requirement. But if they do, I prefer them to toast. Unless 75% of the remaining voters vote omelette and quiche above toast, those two options will be thrown away, and the vote will be determined by whether half the voters placed toast over further discussion. If you want to make sure that toast doesn't win, you have to vote (insincerely) like this:

[1] Choice 1: Omelette [3:1]
[1] Choice 2: Quiche [3:1]
[3] Choice 3: Toast
[2] Choice 4: Further Discussion

Sadly, there is no way to vote against the vote without effectively also voting for toast!

---

I wonder if it was a mistake to combine the supermajority vote and the Condorcet vote on a single ballot. Maybe it would be better to write both ballots out explicitly:

Some options on this ballot must be approved by a 3:1
supermajority of the electorate.  Please enter 'Y' next to the
options that you approve of and 'N' next to those you disapprove
of.  Ballot options on which 75% of voters vote 'Y' will proceed
to the next round (below).
[ ] Choice 1: Omelette [3:1]
[ ] Choice 2: Quiche [3:1]
Rank the ballot options below:
[ ] Choice 1: Omelette [3:1]
[ ] Choice 2: Quiche [3:1]
[ ] Choice 3: Toast
[ ] Choice 4: Further Discussion

That would allow people who want to vote against the vote without privileging any of the options over the others to do so: vote Y to all 3:1 options, then vote 2221 on the rest. On the other hand, I suspect people would be confused in different ways by a voting system that was this complicated, voting Y in places where they should write a number and writing numbers where they should write Y or N. I guess all this mess is why we still use First Past the Post for votes in the real world...

A variety of Debian tasks all lined up in the top priority - get it done now or not at all - work queue this morning. Two GR's, one RC bug fix and one long overdue experimental upload.
All I'm saying about the first GR (the "anti-ganeff" vote) is 2212. That was the most ridiculous GR I've come across so far, until vote3 which is just politics gone insane. My own opinion? 7235146 which disagrees quite a lot with bubulle even though I have the same aims as bubulle - that alone indicates the nature of the vote. The options are illogical, the vote is pointless, the subject matter is moot, the initial proposal doesn't have any understanding or relation to the real world and the amendments have been unnecessarily divided in such a way to make it all but impossible to be logical in the vote priorities. The abuse of votes by a vocal minority undermines the process itself. All in all, we desperately need an option that basically says stop being pathetic and get something useful done in all future GR's - as well as making it harder to make a GR in the first place. Over use of referenda is as poisonous to democracy as under use - just ask Ireland.
After all that political spin and muck spreading, I had to just do something useful as a partial compensation. So, after a ping from the MIT BSP I've fixed 507316.
I've also made the tslib experimental upload that has been quietly developing on my own system for a few days.
Right, now I'm getting back to adding more packages to Emdebian Grip - so far, we have enough packages for a basic XFCE/Gtk system with an email client, a blog client, a few GPE games and Thunar as file manager. Now need to add iceweasel and dependencies. Once that is done, I'll be switching my Acer Aspire1 from Debian Lenny to Emdebian Grip unstable and creating a testing repository for Grip. Once I've got some figures from that switch, I'll post some more details to debian-embedded@lists.debian.org.
Sigh. Emdebian Grip was meant to go alongside Debian Squeeze - it looks now as if Emdebian Grip will be released before Debian Lenny - it's even likely to use the Lenny installer and debian-live support. I hope the pedants are happy because I'm not.

Hmm, again another general resolution. Yes, but this one seems to be really tricky. During discussion, several almost unrelated options have been merged into single vote, what really does not make it easy to understand and choose preferred option. Yes they are related in the way that they will affect time of Lenny release, but I think splitting it into several votes would make more sense. On the other side, Lenny release is getting delayed more and more and boycotting this vote also does not seem as a good choice to me. Such choice will practically delay Lenny release after another decision will be made or all firmware issues will be solved. And neither of these choices seems to be possible to happen in a timely manner...

I agree, this vote is one of the worst formulated I can remember. I think votes should be as easy as possible to understand, so that the voter is absolutely clear about what he s going to vote. The current vote is the perfect example how not to design such a vote. Reading and understanding the ballot is very exhausting, the wording sounds polemic and given the options, it somehow feels like a trap. Example: The first option is Reaffirm the social contract . Sounds nice, of course we want that, but in the footnotes it says

[ ] we will delay the release of Lenny until such point that the work to free the operating system is complete (to the best of our knowledge as of 1 November 2008).

So you re actually voting on delaying the release of Lenny until some technical details are cleared. This is really crap, why not name the option Delay Lenny until foo in the first place? I guess to motivate people a bit more to rank this option above all others. I m very disappointed. Next vote, fever options and clearer wording please.

Christian notes, and rightly so, how much this vote sucks, for various reasons. There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be. For this vote to succeed and be meaningful, it s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the Let s release Lenny and give the finger to the zealots options at the same level. Be careful when voting on this one. IT S A TRAP.

I am somewhat under the feeling that the Debian project is currently facing a critical moment of its history. The development momentum has slowed down a lot during last months (approximately since Debconf and even more since October. I feel just like we're facing a moment where either we release Lenny (which is technically a great progress over Etch and, being a little bit more than 18 months after Etch, well suited wrt "modernity")....or we delay it for several months and will suffer more and more from the long freeze process (remember sarge). The momentum is then very likely to continue moving elsewhere (should I say Ubuntu or did everybody understand already?). And now we have to vote about firmware blobs, a proposal that popped up because a few (*very* few) vocal folks who (in my opinion) live on a planet that has no connection with the real world, think that we should triple check the freeness of each and every bit that is likely to be run on a Debian machine. Moreover, the proposal is worded and was pushed in a way that all (but one) options that would allow us to release lenny will need a 3:1 majority, which is obviously very hard to achieve (and as, there are several such proposals, the vote will be spread out among all of them). So, those folks who make the release of lenny their priority are now facing an interesting tactical choice: how the ..... should we vote for this to happen? I personnally did choose to vote this way: 5462371. Yes, I ranked "reaffirm the Social Contract" after everything, which makes me sad....and I blame the play on words by the zealots who pushed that proposal for forcing me to do this. I think this is the best "tactical" choice for those (and I hope we are a strong majority) who still make the *release* of the best possible and most possibly free operating system their priority. Believe me or not: if we don't release lenny soon, we will die slowly and rot peacefully. We will rot being 150% free and proud to be 150% free on our little planet, outside the solar system and the real world. *This* is the choice we are facing. Ah, and before I forget: film at 11, of course. PS: no comment system on my blog (I don't want to deal with spam and put complicated systems there). Please comment in public in your own blog. I very much prefer this over private comments which will be mostly ignored.

David Welgon has a nice post regarding his opinions on pros and cons on running a startup in Europe (Italy) and the USA (SF/Bay area). The first of the Italy cons got my attention:

Less of a startup culture and mentality. It's more typical to get a "job for life" and hang on to it for all you're worth. Many Italians are tremendously creative, industrious, inventive people, but are going to find it more difficult to express that in some form of business.

I know I am unlike many people, specially in this field... But anyway. I live in Mexico. Many factors in The Way Things Work are pushing people towards having an enterpeneur mentality - And what you see as a point against, I see as a very big advantage.
Some people have what it takes to run a business, and that's great. However, I think it is wrong to assume most people will benefit from running their own business - And specially in a country as mine. I cannot speak much about Europe, but from what you say, it confirms it is a good model of what I'd like Mexico to morph into.
Too many people start their companies with dreams of glory, thinking they have something to differentiate from the rest of the marketplace - and they lack it. So instead of enriching an existing company with more, and better focused, technical talent, they will end up making it poorer with yet another generic company with nothing new to offer, paying famelic wages to their employees, finding a way to skip the social security payments. And there are lots of legal ways to do so in Mexico - and a growing segment of the population has neither health care nor retirement savings, as this makes their day-to-day incomes substantially more juicy... But the future will bite them hard. Well, not only them - It will bite all of us. I still think we will inevitably, sooner or later, evolve into a more caring society, a society where the strong protects the weak, where it (via the State, the government) ensures nobody has under the minimum needed to have a decent life.
And, although I am essentialy a Socialist at heart, I do recognize there is place for people getting more money than others - After all, courage and creativity should be encouraged, and true enterpeneurs should get compensed for what they give to the society - But the ridiculous, stupid differences we get to see, specially in third world countries (remember that the world's richest man, Carlos Slim, lives on the same city I do, and around ~15 years ago even lived less than five blocks away from me... But I do have close family where having food daily on the table is far from a fact) are something that should disappear for good.
Loyalty to your employer and long-term job commitment are two values I hold very dear, and hope to be able to practice. So far, I have worked for eight years for UNAM (1999-2003 and 2005-present), and I hope to continue here for many years to come. I was just talking about this with a friend - The payment itself is far less than what I could get somewhere else, but the work conditions and long-term viability are more than enough to repay for the difference. And I am sure many of my friends and acquintances would be much better off if they stopped prioritizing getting more money now in respect to leading a better, richer life - And, of course, if we all valued more giving back to the society, as we will probably all need to ask from it sooner or later.

I just updated the Software behind Planet Debian to Planet Venus, away from PlanetPlanet. The major benefit right now is the threading, we are now using 15 threads to download the various feeds instead of just one. For all the rest it is currently the same as the old PlanetPlanet, as we use the same templates. But we might switch to something different, we now have the option. The reason for that switch, beside a little more recent code, was the faster updates which was driven by a request we got recently. Language based Planet Debian, ie. a spanish, a german, one. This is now doable without trashing the machine it runs on and will be there soon. I m not yet sure what the exact rules for the language planets will be, but I guess something along the following will do (have to discuss with the other Planet maintainers, this is just my 2 on it):

• Same content as you would put on planet.debian.org, ie. mostly Debian related.
• Special feed with only the language for this planet.
• At least 10 feeds have to be there before a new language gets added.
• Language planets will appear as planet.debian.org/$LANGUAGE, where $LANGUAGE will be the two-letter code for it.

While I was doing this I also went and disabled a large number of non-working feed entries in our Planet config. A diff is available, if you find yourself in it, feel free to reactivate our entry as soon as it is reachable again. [Update] Planet now also features an Atom feed, in case you prefer that.

Now, check your pockets and take stock of what resources are available. If you have a cell phone, see if you can get reception. If you get through to a friend, dispense with pleasantries quickly and state the situation calmly and clearly. The newer cell phones have GPS function, which will aid greatly in directing him or her to the right place. If you re worried about using valuable phone minutes, try texting, but keep it to essentials. HLY SHT BD ALV. GT HLP, BRG SHVL, OXY, BR (NT PBR)

Now these are the kinds of tips we need more of.

Now we have seen what per-process namespaces and shared subtrees are and how to operate them, we can try to combine these two features. We ll be using our newns tool from this earlier post to create new namespaces. And for practical reasons, let s say you have a terminal with a 1$ prompt and a second terminal with a 2$ prompt (that will allow me to skip go to the second terminal phrases). In the kernel, per-process namespaces are a bit like bind mounts, such that shared subtrees work with namespaces like they do with bind mounts. As with standard bind mounts, the default shared subtree mode is private, which means mounts done on either namespaces will be private to the namespace. Only mount points active at the time of the new namespace creation will be in both namespaces:

1$ ./newns
1$ mount /dev/sda1 /mnt
1$ ls /mnt
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
2$ ls /mnt
2$ mount /dev/sda1 /cdrom
2$ ls /cdrom
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
1$ ls /cdrom
1$ umount /mnt
1$ exit # Exit from newns
2$ umount /cdrom


shared mode allows both namespaces to share subsequent mounts. As with bind mounts, and for obvious reasons, you need to change the subtree mode before creating the new namespace:

1$ mount --make-rshared /
1$ ./newns
1$ mount --bind /usr /mnt
1$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
2$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6


Like with shared bind mounts, the new mount point can be unmounted from either namespace:

2$ umount /mnt
1$ ls /mnt
1$ exit # Exit from newns

A slave subtree will have mount points under its master (shared) subtrees propagated, while propagation won t happen in the other direction. Again, very much like bind mounts:

1$ mount --make-rshared / # For completeness, we already did that earlier
1$ ./newns
1$ mount --make-rslave /
1$ mount --bind /usr /mnt
1$ ls /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
2$ ls /mnt
2$ mount --bind /usr /cdrom
2$ ls /cdrom
bin games include lib lib32 lib64 local sbin share src X11R6
1$ ls /cdrom
bin games include lib lib32 lib64 local sbin share src X11R6
1$ exit # Exit from newns
2$ umount /cdrom


Contrary to shared and slave, unbindable doesn t add value when used in two different namespaces. This is only something that will have impact on the current namespace:

1$ mount --make-rshared / # For completeness, we already did that earlier
1$ ./newns
2$ mount --make-runbindable /
2$ mount --bind /usr /mnt
mount: wrong fs type, bad option, bad superblock on /usr,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg tail or so
1$ mount --bind /usr /mnt
bin games include lib lib32 lib64 local sbin share src X11R6
1$ exit # Exit from newns
1$ mount --make-rprivate # Set back to default

Now we ve seen what can be done with namespaces and shared subtrees, let s see what nice features can be implemented with both. As Russell revealed, pam-namespace is able to polyinstanciate some directories following rules set in /etc/security/namespace.conf (see namespace.conf(5)). The sad thing is that it apparently can t just create a new namespace without polyinstanciating a directory, which could be useful if you only want separate namespaces, but no polyinstanciated directory. Russell s recipe goes as follows:

• At boot time, / is put in shared mode and /tmp in private mode.
• When opening a session, pam will create a new namespace, and bind mount /tmp-inst/$USER to /tmp.

What this means is that in the newly created namespace, a user reading in /tmp will actually be reading in /tmp-inst/$USER without the user knowing. Also, if root mounts something on the parent namespace, it will be propagated (/ being shared) to the user namespace. This means that mounting USB storage, for example, will be propagated to the user namespace. This also means that something mounted from the user namespace will also be propagated to the parent namespace. In both cases, this only applies to mounts occuring outside of /tmp, for which mounts don t get propagated. Note that without setting /tmp as private, when PAM would be mounting /tmp/inst/$USER, it would propagate as well, setting /tmp to /tmp/inst/$USER for everyone. So setting /tmp as private is mandatory. There is, however, a flaw in Russell s recipe: If any of the user mounts something under a submount of /, under /var for example, if /var is mounted, it won t be mounted to a user that already had a session opened. For that to be possible, you have to use --make-rshared instead of --make-shared in Russell s recipe. Some nice setup that can be done with all these, is the following: Add the following to /etc/security/namespace.conf:

/tmp tmpfs tmpfs root

Add the following to /etc/pam.d/common-session:

session required pam_namespace.so

Until here, it is pretty much the same as Russell s, except /tmp is a tmpfs instead of a real directory in /tmp-inst/, which can have some advantages. It doesn t seem to be possible to give pam-namespace a size for the tmpfs, though. Add the following to /etc/rc.local:

mount --make-rshared /
mount --bind /tmp /tmp
mount --make-private /tmp

Here again, this is the same as Russell s except for the correction for --make-rshared as seen above. If /tmp is already a mount point (on my systems, it is a tmpfs), you can remove mount --bind /tmp /tmp from above. Add the following to /etc/security/namespace.init:

mount --make-rslave /

Now, this is where it gets interesting: we re setting the whole tree as slave in the user namespace which means that if a user mounts a file system anywhere, it will only be seen in his session. Which means the user can more safely mount encrypted volumes: they won t be available to other users (root can still go wandering in /dev/kmem, though). And you don t even need SE linux for that. The caveat is that if you open a root session with su, from the user session, you are still inside the user boundaries, and don t have access to the virtual filesystem as it is for init. And if you mount something as root then, while it will appear in the user namespace, it won t appear neither in other users namespace nor in init s, which can be a good thing in some cases, but a burden in others. It means you may need to setup a special user that won t get a new namespace in /etc/security/namespace.conf. An alternative model would be to only set the user s home as slave, which means anything mounted by the user in his home directory would stay private in his namespace, while anything mounted outside would be shared with other namespaces. For that, you may want to replace the lines we added to /etc/security/namespace.init with the following:

HOME=$(getent passwd $3 cut -d: -f6)
mount --bind "$HOME" "$HOME"
mount --make-rslave "$HOME"


Either way, the remaining problem is that a root session opened with su from the user session won t get access to the original /tmp. As we saw, there are various use cases for namespaces and shared subtrees. I ll follow-up again on these features soon, as I ll be using them in yet another way to achieve a very different purpose.

Michael Arrington of Techcrunch comments on the US vs Europe in terms of startups: Joie De Vivre: The Europeans Are Out To Lunch It's a pretty rough and coarse-grained view of things, but there's a grain of truth there. I've written about this a little bit before. It's something that I feel qualified to talk about, having lived and worked in both the US and Europe (Italy and Austria to be precise), and in that time, generally gravitated towards startups. Here's my quick take on a list of what's good and bad about each. Please note that these are of course not true for everyone, that things are changing, but are still things I think are generally true, even when I could think of several counterexamples for some of them myself. Also, it's very important to keep in mind how diverse "Europe" is, so most of what I write is really about Italy, and to a much smaller degree, Austria. I'd be very curious to hear your own experiences in the comments. Europe Bad

• Less of a startup culture and mentality. It's more typical to get a "job for life" and hang on to it for all you're worth. Many Italians are tremendously creative, industrious, inventive people, but are going to find it more difficult to express that in some form of business.
• The side effects of this mean that there are fewer people to talk with, and network with, fewer potential employees willing to risk a startup, and so on. For instance, people are at times more suspicious of a new company - both clients and suppliers.
• As I mentioned in my other article, it takes a lot more money to get started in many European countries - something like 10,000 Euro in Italy. Other places like the UK are cheaper, and apparently Germany is introducing some legislation to ease the burden on new companies. I really hope this changes in Europe because it's such an easy change to make: don't extract money from companies until they're making it.
• More bureaucracy. I think that higher taxes, once you are profitable, might be worth paying for the social system you get in Europe, but the cost of sorting out paperwork falls inordinately on smaller, newer companies. Big, established firms can hire people to deal with all the rules and regulations, and probably have contacts in the government that can help them out in some cases. Smaller firms are the ones whose time is really going to be wasted running around to different offices trying to figure out what they have to do.
• Smaller, fragmented markets. Localization is not a lot of fun in some ways, and trying to translate everything into all the languages of the European Union is a huge undertaking. In the US, you get a huge market with just English and the US Dollar. Even beyond language issues, the culture changes less in the US from place to place, meaning that you have a more homogeneous target.
• Lack of acceptance of failure, both culturally and institutionally. If you go bankrupt in Italy, it's a very serious problem. Apparently (although this is second hand, I'm not 100% sure of it - maybe someone can confirm whether it's actually true?), you can even lose the right to vote. Plenty of people in the US try several times before they get it right.

Good

• Even if your undertaking fails, you still have health care. Likewise, there are other bits and pieces of social support (that change from country to country) that mean you're probably not going to land quite so hard on your rear if things go wrong.
• Lots of smart, educated people. I never lacked for plenty of smart people to talk shop with in Padova, and didn't miss the California bay area at all from that point of view. Open source is really big in Europe - perhaps, in part, because for many people it's a better avenue for their talents than creating a business, when doing so is difficult and less common.
• Work/life balance. Sorry Mike, but the amount of people who are truly going to strike it rich is pretty small. If they want to work hard, great, but it's nice to have some other options, in terms of good, lasting friendships (rather than everything revolving around work), knowing plenty of people from outside your field, people living in and belonging to a community (how many people spend their whole lives in the bay area?). When I moved from San Francisco to Padova in 2000, I went from a world gone mad with money and the dot com craze to one where there were rich and poor, families, young people, old people, and many people who were not working for some dot com. That's not to say that people don't work quite hard in Italy - two hour lunches are a thing of the past for most anyone I know.
• Smaller fragmented markets can be an advantage, too. By the time some valley-based startup finally gets around to noticing that languages other than English exist, it's possible to capture a smaller market. Ok, so you won't be the next Google that way, but there's good money to be had in doing so.
• In some ways, the staid, established, don't rock the boat way of doing things in some industries may present big opportunities for outsiders to come in and pull the carpet out from under everyone. This is especially true of internet/web companies that can get started quickly and cheaply.

US Bad

• If you're not careful, you can get completely sucked in to work - your life revolves around it, your friends are mostly work friends, and if something happens to your job, a lot of that goes poof. This is especially true in places like the bay area, where so many people are 'transients' - just there for a few years, without any real roots in the area. This is ok if you'll potentially make a big pile of money, but long term it's unhealthy.
• Less of a sense of building for the long term. Personally, I don't want a "job for life", but I think there is some value in loyalty (the genuine sort, not the sort created by legally not being able to lose a job) between employer and employee that has been lost in the US. Being able to count on someone growing with your company, and as an employee, knowing that your company will do what it can to help you out even in tough times are things that capture some value. The US seems to be heading towards a "Coasian" world where everyone is a freelancer, and while that efficiency is hard to deny, I wonder what is lost in the process.
• The competition is tough. Sure, it is in Europe too, but in Europe everyone may compete quite hard during the year, but still all take that one month vacation (although that is becoming a bit less common, especially amongst people my age), whereas in the US almost no one gets that kind of benefit - even if you wanted to take unpaid time off, people would look askance at that kind of behavior. That said, if you need to stay open in, say, August, in Italy, to compete, you are in big trouble, because for many businesses it's simply impossible because it's a chain reaction: all your suppliers and clients shut down, so you really have no choice.

Good

• There are certainly bureaucratic obstacles in the US, but are much more maneageable, and don't hit smaller/newer companies quite so badly.
• It's cheap to get started. As per my other article, the actual state filing fee in Oregon for an LLC is $55, and that's all you really need.
• The culture is definitely there, especially in the right places like the Bay Area, but even in plenty of others.
• You aren't bound to employees for life, and it's easy to find freelancers. I know I'm contradicting myself, but I think it's actually a complex issue, and there are definite advantages to not having people who expect or at least want to find that job for life.
• A large target market. Go online in one state, and you can, for the most part, deal with customers all over the US, in one language.
• Things turn around faster. I have more of a sense that when there are problems, they get fixed. Companies (the debacle of the automakers notwithstanding) are more often allowed to fail, or at least put in Chapter 11. Sometimes this means that when things are bad, they get really bad, but also turn around and get better sooner.

Conclusions An interesting example of all this from my own experience was Linuxcare. The company was, culturally, a Bay Area startup, with the headquarters in San Francisco, founded by very startup oriented guys (one of whom, Dave Sifry, went on to do technorati, and is currently working on yet another venture). However, most of the actual open source talent was in our satellite offices, in Australia, Italy and Canada, places where, perhaps, people were not so distracted by the prospect of "make money fast!!! hurry!!!" that they had time to work, learn, and create some really great open source code. To be honest, I find myself torn. Business-wise, I prefer the US. However, outside of that, there's a lot to be said for Europe. I also think that some of what's good about business in the US is coming to Europe, albeit slowly in some cases, in Europe. People my age here can see what's going on elsewhere, and try and copy what they like. A lot of what's good about Europe, though, might be more difficult to import into the US, especially the livability of the cities. In any case, I can conclude that it's a complex, difficult topic best discussed over a glass of wine.

As reply to my previous post about per-process namespaces, Russell wrote about pam-namespace and shared subtrees. As he reports, pam-namespace (that I discovered by the occasion) can do what I was suggesting would be nice for pam-tmpdir. Anyways, I was actually already planning to write about shared subtrees and how they can be useful with namespaces. In this first post, I will introduce shared subtrees, while in a follow-up post I will introduce how they can usefully be used with namespaces. As a preliminary note, you should know that while etch’s kernel supports shared subtrees, etch’s mount doesn’t support the necessary options. Lenny’s mount is unfortunately uninstallable on etch due to its dependency on a newer libc. But you can find a smount utility’s source code in Documentation/filesystems/sharedsubtree.txt in the kernel source, where other explanations about the feature are available. So, you can either backport lenny’s util-linux to etch, or build smount to replicate what I will be doing below. If you are using smount, just replace

mount --make-type path

with

smount path type

As seen in my previous post, bind-mounting allows to attach a file hierarchy at some other place in the virtual file system.

mount --bind / /mnt

will make all the contents of / (/bin, /etc, …) available through /mnt (/mnt/bin, /mnt/etc, …). On the other hand, sub-mounts will be ignored in such a case. For instance, /usr is usually a different mount point from /. It means /mnt/usr will be empty (provided it is empty in the underlying physical filesystem), instead of containing the same as /usr:

$ mount --bind / /mnt
$ ls /mnt/usr
$ ls /usr
bin games include lib lib32 lib64 local sbin share src X11R6
$ umount /mnt


If you also want /usr to be bind-mounted, you must use --rbind instead of --bind:

$ mount --rbind / /mnt
$ ls /mnt/usr
bin games include lib lib32 lib64 local sbin share src X11R6
$ ls /usr
bin games include lib lib32 lib64 local sbin share src X11R6


Obviously, sub-sub-mounts will also be propagated. Since recursively bind-mounting will create a bunch of mount points, unmounting can become a hassle. You can use the following command to unmount everything:

$ awk '$2 ~ /^\/mnt/ print $2 ' /proc/mounts sort -r xargs umount

Now, this is where shared subtrees come in. After the bind mount has been done, if you mount something on either side of the bind mount, the new mount is not propagated. This is called private subtrees, and is the default. But before doing anything else, let’s setup our testing environment:

$ mkdir -p /a/a /b
$ touch /a/b /a/c
$ ls /a
a b c
$ ls /b


After, bind-mounting /a onto /b, let’s see what happens when mounting something under /a, then under /b:

$ mount --bind /a /b
$ ls /b
a b c
$ mount --bind /usr /a/a
$ ls /a/a
bin games include lib lib32 lib64 local sbin share src X11R6
$ ls /b/a
$ umount /a/a
$ mount --bind /usr /b/a
$ ls /a/a
$ ls /b/a
bin games include lib lib32 lib64 local sbin share src X11R6
$ umount /b/a


As I said earlier, these new mounts are not propagated. Note that I used bind-mounts as sub mounts, but it would work all the same with other kind of mounts (device, fuse, etc.). There are 2 other modes that allow to have some propagation: shared and slave. shared allows mounts on both ends to be shared. Note you need to set the mode before bind-mounting:

$ umount /b
$ mount --bind /a /a # This is needed because /a is not initially a mount point and you can only apply subtree modes to mount points.
$ mount --make-shared /a
$ mount --bind /a /b
$ mount /dev/sda1 /a/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /a/a
$ mount /dev/sda1 /b/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /b/a


You can even mount on one end and unmount from the other:

$ mount /dev/sda1 /a/a
$ umount /b/a
$ ls /a/a


slave allows mounts on the “master” end (/a in our case) to propagate to the “slave” end (/b), but not the other way around. The “master” end need to be shared :

$ umount /b
$ mount --make-shared /a # Only for completeness, we already set /a as shared earlier.
$ mount --bind /a /b
$ mount --make-slave /b
$ mount /dev/sda1 /a/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /a/a
$ mount /dev/sda1 /b/a
$ ls /a/a
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /b/a


There is a third mode, unbindable, that does something different:

$ umount /b
$ mount --make-unbindable /a
$ mount --bind /a /b
mount: wrong fs type, bad option, bad superblock on /a,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg tail or so
$ mount --bind /a/a /b
mount: wrong fs type, bad option, bad superblock on /a,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg tail or so


As you can see, it disallows bind mounting of /a and its subdirectories to some other place. Finally, to put back the default mode, you can use:

$ mount --make-private /a

Similarly to --bind, there is also a recursive version of each: rshared, rslave, runbindable and rprivate, to apply these to sub-mounts.