Back in February, I wanted a new laptop for my work, so I bought a fancy Dell Latitude E6540 laptop. Bad luck, it was giving my sore eyes and horrible headaches, to the point I couldn't work more than a dozen minutes with it. As in my work, we were not allowed to buy PC laptops with any other vendor, my boss convinced me to get a 15'' macbook pro retina (yes that's about as expensive a laptop as you can get). Although quite reluctant at first, I did need a new laptop, so I gave in. Of course, I had to install debian on it. I booted once or twice on macos to leave enough space for Debian and install rEFIt so that I could boot into it. I had to use version 3.9 of linux else it wouldn't boot.After about 8 month, I must say I'm quite pleased with the beast. The retina display is very neat (a 2880x1800 resolution!), and it is pretty fast. There are two annoyances though:

• I never managed to get either the non-free NVIDIA drivers or the integrated intel graphics to work. The NVIDIA driver give blank screen on X startup, while it doesn't even start with the intel drivers (and I've tried all the tricks I could find around). The fine point is that I don't have any hardware 3D acceleration !
• The wireless network is pretty unstable.

Another point is the update of GRUB: Debian's post-install scripts don't play nice with the EFI setup, so here is what I have to do to update to a newer version of grub, (and it's also what I had to do initially to install GRUB):

# mount /dev/sda1 /mnt
# grub-install --efi-directory=/mnt

The /dev/sda1 partition is the so-called EFI partition. I think it is created by rEFIt and it is essentially empty.

Wireless mesh networks are self organising and self healing networks that can be used to connect computers across small and large areas, depending on the radio technology used. Normal wifi equipment can be used to create home made radio networks, and there are several successful examples like Freifunk and Athens Wireless Metropolitan Network (see wikipedia for a large list) around the globe. To give you an idea how it work, check out the nice overview of the Kiel Freifunk community which can be seen from their dynamically updated node graph and map, where one can see how the mesh nodes automatically handle routing and recover from nodes disappearing. There is also a small community mesh network group in Oslo, Norway, and that is the main topic of this blog post. I've wanted to check out mesh networks for a while now, and hoped to do it as part of my involvement with the NUUG member organisation community, and my recent involvement in the Freedombox project finally lead me to give mesh networks some priority, as I suspect a Freedombox should use mesh networks to connect neighbours and family when possible, given that most communication between people are between those nearby (as shown for example by research on Facebook communication patterns). It also allow people to communicate without any central hub to tap into for those that want to listen in on the private communication of citizens, which have become more and more important over the years. So far I have only been able to find one group of people in Oslo working on community mesh networks, over at the hack space Hackeriet at Husmania. They seem to have started with some Freifunk based effort using OLSR, called the Oslo Freifunk project, but that effort is now dead and the people behind it have moved on to a batman-adv based system called meshfx. Unfortunately the wiki site for the Oslo Freifunk project is no longer possible to update to reflect this fact, so the old project page can't be updated to point to the new project. A while back, the people at Hackeriet invited people from the Freifunk community to Oslo to talk about mesh networks. I came across this video where Hans J rgen Lysglimt interview the speakers about this talk (from youtube): I mentioned OLSR and batman-adv, which are mesh routing protocols. There are heaps of different protocols, and I am still struggling to figure out which one would be "best" for some definitions of best, but given that the community mesh group in Oslo is so small, I believe it is best to hook up with the existing one instead of trying to create a completely different setup, and thus I have decided to focus on batman-adv for now. It sure help me to know that the very cool Serval project in Australia is using batman-adv as their meshing technology when it create a self organizing and self healing telephony system for disaster areas and less industrialized communities. Check out this cool video presenting that project (from youtube): According to the wikipedia page on Wireless mesh network there are around 70 competing schemes for routing packets across mesh networks, and OLSR, B.A.T.M.A.N. and B.A.T.M.A.N. advanced are protocols used by several free software based community mesh networks. The batman-adv protocol is a bit special, as it provide layer 2 (as in ethernet ) routing, allowing ipv4 and ipv6 to work on the same network. One way to think about it is that it provide a mesh based vlan you can bridge to or handle like any other vlan connected to your computer. The required drivers are already in the Linux kernel at least since Debian Wheezy, and it is fairly easy to set up. A good introduction is available from the Open Mesh project. These are the key settings needed to join the Oslo meshfx network:

Setting	Value
Protocol / kernel module	batman-adv
ESSID	meshfx@hackeriet
Channel / Frequency	11 / 2462
Cell ID	02:BA:00:00:00:01

The reason for setting ad-hoc wifi Cell ID is to work around bugs in firmware used in wifi card and wifi drivers. (See a nice post from VillageTelco about "Information about cell-id splitting, stuck beacons, and failed IBSS merges! for details.) When these settings are activated and you have some other mesh node nearby, your computer will be connected to the mesh network and can communicate with any mesh node that is connected to any of the nodes in your network of nodes. :) My initial plan was to reuse my old Linksys WRT54GL as a mesh node, but that seem to be very hard, as I have not been able to locate a firmware supporting batman-adv. If anyone know how to use that old wifi access point with batman-adv these days, please let me know. If you find this project interesting and want to join, please join us on IRC, either channel #oslohackerspace or #nuug on irc.freenode.net. While investigating mesh networks in Oslo, I came across an old research paper from the university of Stavanger and Telenor Research and Innovation called The reliability of wireless backhaul mesh networks and elsewhere learned that Telenor have been experimenting with mesh networks at Gr nerl kka in Oslo. So mesh networks are also interesting for commercial companies, even though Telenor discovered that it was hard to figure out a good business plan for mesh networking and as far as I know have closed down the experiment. Perhaps Telenor or others would be interested in a cooperation? Update 2013-10-12: I was just told by the Serval project developers that they no longer use batman-adv (but are compatible with it), but their own crypto based mesh system.

Review: 2312, by Kim Stanley Robinson

Publisher:	Orbit
Copyright:	2012
ISBN:	0-316-19280-5
Format:	Kindle
Pages:	563

Swan Er Hong is a native of Mercury, granddaughter of one of the most influential women in the solar system. Alex, known as the Lion of Mercury, has just died as the story opens, and Swan is mourning. But she's also discovering that something else has been going on, something that Alex had not confided in her. Something that involves an inspector from the asteroids, a scientist from Titan, and a message Alex left in the event of her death, asking Swan to convey something personally to another scientist on Io. And then Mercury is attacked and the situation becomes much more complicated. 2312 is, like most Robinson novels, built on top of monumental world-building. The date is given away by the title; the setting is a solar system full of terraforming, habitats, and explosive human colonization. There are human settlements on every world that could possibly sustain them, including a terraformed Mars and a vast in-progress terraforming project on Venus. Mercury, Song's home, supports the city known as Terminator, a shielded habitat that travels around the planet on rails, pushed forward by the thermal expansion of metal at sunrise. Humans have scattered across the solar system and changed everything they've touched, even the asteroids. Many of those have been repurposed as long-haul shuttles: self-contained habitats on carefully-designed routes on which people live for months or years until they get to their destinations. Parts of this book are gorgeous. One of Robinson's strengths is creating images of the vastness of space, science, and human endeavor that feel plausible and inspiring at the same time. The setting of 2312 frees him to go wild with mega construction projects, and he takes full advantage. Parts of the book inspire the same sense of awe as the Hoover Dam or the Great Wall of China, transplanted into space and backed with neat scientific ideas to ponder. (Even if the more skeptical will note certain human habitation hazards, such as prolonged weightlessness and radiation, are mostly hand-waved away.) Unusually for a Robinson novel, 2312 also features an interesting and vibrant protagonist. Usually I can barely remember Robinson's protagonists five minutes after I finish the book, but Swan is so impulsive, erratic, and emotionally intense that I doubt I'll forget her. Her past is stuffed with outrageous risks and intense creativity: having songbird neurons transplanted into her brain, ingesting extraterrestrial bacteria, designing habitats in the asteroid belt, and creating art on the plains of Mercury. As the story gets underway, she meets the oversized and mellow Wahram; at first, she finds him boring, but then they're thrown together by one of the best set pieces of the book, and both they and the reader discover they work well together. Wahram serves as a straight man and as a stand-in for the reader's opinion, showing Swan all the more clearly in contrast. All this sounds quite promising. Unfortunately, what makes 2312 an ambitious failure rather than an excellent story is the story part. Robinson has built an amazing world, but he doesn't seem to know what to do with it. His economy, at least outside of Earth (and more on that in a moment), is essentially post-scarcity. Few of the characters we meet seem to have any concept of fiscal or practical limitation. They head across the solar system on a moment's notice, take vacations in habitats, or head to favorite spots for the view. It felt like Robinson was trying to write a Culture story. Unlike Banks, however, he struggles with generating a plot. 2312 is, in structure, a murder mystery. The characters witness a crime, survive it, and then intend to investigate it, and the crime appears to grow and link to fault lines in their society. This could have worked, but it has two problems: their society is only barely coherent enough for the reader to perceive the potential fault lines, and Robinson seems to have no idea how to construct a mystery plot. There is no sense of coherence to Swan and Wahram's approach, no sense of a gathering of clues, and very little sense of drama. All of the plot revelations are either dropped in Swan's lap by another character at a convenient moment or generated by Swan refusing to take the plot of the book seriously. The characters do essentially no meaningful investigation on-camera and show almost no investment in the outcome of the plot. When the climax comes, it's all weirdly forgettable. There are also large sections of the book that appear to have nothing to do with the rest of the plot, and that's where the unfortunate interval on Earth comes in. Robinson takes advantage of the scenes on Earth to do a bit of alienation and shows how foreign and strange and stifling Earth feels to someone who grew up outside of its atmosphere. Parts of this work, but he puts the plot on hold to do it. And parts of it do not work at all. The most glaring example is Swan and Wahram's bizarre bit of attempted charity in Africa, which comes across as stunningly high-handed and arrogant. This could be in character, particularly for Swan (who is not long on empathy), but, if so, the book doesn't signal to the reader that it should be read that way. Instead, there are some side (or snide) comments that seem to indicate Robinson knows nothing about the economic arc of Africa from the past twenty years. And when their absurd, botched, condescending charity plan fails for all the obvious reasons, the characters, and apparently the novel, throw up their hands and write Earth off as a stagnant lost cause that can't accept the imposition of a good idea and go back to the plot, never apparently caring about Earth again. Almost as frustrating is the way that these interludes are tied back into the story, which is usually through Swan getting ridiculously lucky on her random encounter rolls. It felt like whenever Robinson needed to make progress in the plot, Swan would just accidentally run into exactly the right person or situation to bring up the next plot point or to have some investigation make sense. (Not that Swan usually figured this out. Normally, the inspector explains it to her.) The author's finger was planted so firmly on the scales that it destroyed my suspension of disbelief and made a mockery of the idea that the characters were actually investigating anything. 2312 is built around a skeleton of a plot, but the lack of engagement with it, the lack of tension and emotion, the way the next developments are generally narrated to the protagonists and the reader, and the repeated use of random encounters to steer it left me without much reason to care. Robinson tries a few twists, but since the story never felt committed to its plot anyway, those twists feel less like planned complications and more like another random veer in the road. It didn't help that the final outcome was more prosaic and forgettable than the book had been implying it would be. There is a lot to like here. I'm very pleased to see Robinson finally write a memorable protagonist, and he's very good at both world-building and set pieces. But it needed a plot, and it needed a more coherent and complete cultural backdrop for its characters. Without both, it fell back into the typical Robinson trap: gorgeous moments separated by a whole lot of boring, and an overall impression of a construction tour rather than a story. There are bits of it I loved and still remember, particularly Song and Wahram in the tunnels of Mercury (which is possibly the best extended characterization Robinson has ever written). But the book as a whole is a mess, and I can't recommend wading through it for the good parts. Rating: 5 out of 10

Review: Grimspace, by Ann Aguirre

Series:	Sirantha Jax #1
Publisher:	Ace
Copyright:	March 2008
ISBN:	0-441-01599-9
Format:	Mass market
Pages:	312

Sirantha Jax is a jumper: a person with the rare genetic ability to jump spaceships through the shortcut dimension of grimspace. It's a science fiction idea with a long pedigree. It creates a separate in-group for the characters to belong to, a society with its own rules, and sets up tension with the rest of the institutions of the world. In Aguirre's version, jumpers can provide the transition but direction in grimspace has to be done by a pilot, and the jumper and the pilot develop a deep psychic bond. Jax had been jumping with her husband piloting, but on their last trip their ship crashed, killing everyone on board except her. As Grimspace opens, Jax is in a treatment facility that's much more like a prison. In theory, they're trying to figure out whether she's still able to (and safe to allow to) jump. In practice, something quite a bit more sinister is going on, a fact that the reader senses early but only learns more about after Jax is helped to escape. Scarred, deeply depressed, and nearly suicidal, she's pulled into the subversive plans of a small ship of renegades who are trying to break open the Corp monopoly on grimspace travel and their tight hold over every jumper. But she's not sure whether she trusts them, or whether she cares enough about their crusade to truly join in. Grimspace follows well-trod SF paths of special cadres of pilots and navigators, lawless corners of space with local warlords, and rebellion against smothering centralization, but its first-person protagonist and point of view have more in common with urban fantasy. It's written in first-person and, at times, nearly stream of consciousness from Jax's perspective, and Jax displays plenty of profanity, acidic commentary, and emotional angst. If her special ability were shapeshifting or magic instead of jumping spaceships, one could easily see her as the typical burned-out urban fantasy detective. I liked that. It's a fun point of view when it's written well, and it felt fresh when applied to a science fiction background instead of the more typical fantasy. That said, Grimspace has a rather rough start. Jax isn't sure what's going on at first and also isn't sure she cares, and I thought that carried over to the reader's experience. The first section of the book is rough and jagged, with staccato bursts of character introduction, world-building that doesn't quite cohere, and an extended stop on a very odd outback planet that felt to me like a repurposed stage from a western. Part of the early problem is that Jax and the reader are being intentionally kept in the dark about the real goal of this group, but part of the problem is also that none of the characters start off as very likable. That includes Jax, who is a complete mess and who is both scared and despairing to the point of being almost nihilistic. The world-building unfortunately does not carry the reader through that part of the story, and at about eighty pages in I wasn't sure I was going to like this book. It does, however, get much better. For one, Jax calms down and starts making emotional connections with the rest of the crew, and that lets her demonstrate skills as a fearless problem solver. For another, while the goal of the group of people she's fallen in with isn't exactly deep, it does make sense and it does slowly become a cause the reader (and Jax) can believe in. The frenetic pace of introduction and discovery also slows down, the cast stabilizes, and the surroundings get a bit less weird (and a bit more conventional for a science fiction novel). I didn't care for the alien baby subplot I rarely do but the rest of the story slowly pulled me in. One thing Aguirre did extremely well was surprise me. There are several points later in the book where Jax gets put in a fairly typical high-stress position and does something very atypical in reaction to it, twisting the story into a shape quite a bit unlike what I had been expecting. That made Jax feel like a true free agent, establishing her independence and her desire to control her own life, and that appealed to me. Aguirre also palms one card exceptionally well, setting up an ending that I thought was the best set of scenes in the whole book, and that had me thoroughly engrossed. One can see the bones of the urban fantasy heroine inside Jax's character, but they're fresh and interesting in an SF world, and they work better than I would have expected. There is a romance, in fitting with the urban fantasy inspiration, and it didn't quite work for me, but Aguirre also builds in a reason why it might not make sense and makes it spiky and fragile without being too cliched. By the end of the book, I was, if not entirely persuaded, at least willing to go along for the ride. And that's the best summary of Grimspace, I think. Parts of it don't make a great deal of sense, and parts of it are quite choppy. But I liked Jax once she starts getting a handle on her trauma, the other characters grew on me, and the plot surprised me in some interesting ways. It's not the smoothest or most polished SF novel I've read, but it has a lot of energy and an unusual genre mix. I think I'll stick along for the ride. Followed by Wanderlust. Rating: 7 out of 10

not much activity around RC bugs on my side in the last weeks; & the ones I worked on were all in the Debian Perl Group:

• #722332 libcommon-sense-perl: "libcommon-sense-perl: common::sense runs into trouble with Perl 5.18, eg. no say()."
  ensure same version of perl at build and runtime (pkg-perl)
• #723917 src:libcatalyst-dispatchtype-regex-perl: "FTBFS: Module::Build version 0.4004 required--this is only version 0.4003 at Build line 41."
  fix build dependencies (pkg-perl)
• #723927 src:libdancer-plugin-auth-extensible-perl: "FTBFS: POD error"
  add patch to fix POD (pkg-perl)
• #723933 src:libemail-mime-perl: "FTBFS: test failures in t/ct_attrs.t"
  upload new upstream release (pkg-perl)
• #724109 src:libmoosex-getopt-perl: "libmoosex-getopt-perl: FTBFS: Tests failures"
  upload new upstream release (pkg-perl)
• #724111 src:libtemplate-declare-perl: "libtemplate-declare-perl: FTBFS: Tests failed"
  upload new upstream release (pkg-perl)
• #724196 src:libmldbm-sync-perl: "libmldbm-sync-perl: FTBFS: make[1]: *** No rule to make target /usr/local/lib/perl5/5.6.1/i686-linux/Config.pm', needed by Makefile'. Stop."
  re-create Makefile in clean target (pkg-perl)
• #724235 src:libio-compress-lzma-perl: "FTBFS: IO::Compress::Base version 2.061 required--this is only version 2.060"
  fix alternative dependencies (pkg-perl)
• #724303 src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: fails t/99kwalitee.t: no license information"
  don't run author tests during build (pkg-perl)
• #725393 libhttp-server-simple-psgi-perl: "libplack-perl and libhttp-server-simple-psgi-perl: error when trying to install together"
  add versioned Breaks/Replaces (pkg-perl)
• #725585 src:libhttp-request-params-perl: "libhttp-request-params-perl: FTBFS: Tests failed"
  add patch from CPAN RT (pkg-perl)

on an unrelated note: following the discussion on debian-project, I finally revoked my old opengpg key 0x00F3CFE4 which served me well from 1998 until 2009. since then, I've only been using 0x8649AA06 anyway ...

I wish I had known about that quote from Michael Graves before now. I would have perhaps had an answer to some recent visitors to makespace.

There are regular scheduled visits to makespace where people can come and view our facilities, and perhaps start the process of becoming a member if they decide they like what they see.

However, we sometimes get people who just turn up at the door. If a member feels charitable they may choose to give a short tour rather than just turn the person away. I happened to be in one Friday afternoon recently varnishing a folding chair when two such people rang the doorbell. There were few other members about and because watching varnish dry was dull I decided to be helpful and do a quick tour.

I explained that they really ought to return for a scheduled event for a proper tour, gave the obligatory minimal safety briefing, and showed them the workshops and tools. During the tour it was mentioned they were attending a certain local higher education establishment and were interested in makespace as an inexpensive studio.

Before they left I was asked what I was working on. I explained that I had been creating stools and chairs from plywood. At this point the conversation took a somewhat surreal turn, one of them asked, well more demanded, who my principle influence had been in designing with plywood.

When I said that I had mainly worked from a couple of Google image searches they were aghast and became quite belligerent. They both insisted I must have done proper research and my work was obviously influenced by Charles and Ray Eames and Arne Jacobsen and surely I intended to cite my influences in my design documents.

My admission that I had never even heard the names before and had no design documents seemed to lead to a distinctly condescending tone as they explained that all modern plywood design stemmed from a small number of early 20th century designers and any competent designers research would have revealed that.

At this point in proceedings I was becoming a bit put out that my good deed of showing off the workshop had not gone unpunished. I politely explained that I designed simply by generating a requirement in my head, maybe an internet search to see what others had done, measuring real things to get dimensions and then a great deal of trial and error.

I was then abruptly informed that my "design process was completely invalid and there were well established ways to design furniture correctly and therefore my entire design was invalid" and that I was wasting time and material. I thanked them for their opinion and showed them out, safe and well before anyone gets any ideas.

I put the whole incident out of my mind until I finished writing up the final folding chair post the other day. It struck me that perhaps I had been unknowingly influenced by these designers. It was certainly true I had generated ideas from the hundreds of images my searches had revealed.

I did some research and it turns out that from the 1930s to the 1950s there were a string of designers using plywood in novel ways from the butterfly stool by Sori Yanagi through formed curvy chairs by Alvar Aalto and eero saarinen.

While these designers produced some wonderfully iconic and contemporary furniture I think that after reviewing my initial notes that two more modern designers Christian Desile and Leo Salom probably influenced me more directly. Though I did not reference their designs beyond seeing the images along with hundreds of others, certainly nothing was directly copied.

And there in lies an often repeated observation: no one creates anything without being influenced by their environment. The entire creative process of several billion ape descendants (or Golgafrincham telephone sanitisers if you prefer) is based on the simple process of copying, combining and transforming what is around us.

I must accept that certain individuals at points in history have introduced radical improvements in their field, people like Socrates Galileo Leonardo Newton Einstein. However, even these outstanding examples were enlightened enough to acknowledge those that came before. Newtons quotation "If I have seen further it is by standing on the shoulders of giants" pretty much sums it up.

In my case I am privileged enough to live in a time where my environment has grown to the size of the world thanks to the internet. My influences, and therefore what I create, is that much richer but at the same time it means that my influence on others is similarly diminished.

I have joined the maker community because I want to create. The act of creation teaches me new skills in a physical, practical way and additionally I get to exercise my mind using new techniques or sometimes things I had forgotten I already knew. I view this as an extension of my previous Open Source software work, adding a physical component to a previously purely mental pursuit.

But importantly I like that my creations might provide inspiration for someone else. To improve those chances in the wider world I force myself to follow a few basic rules:

Release

Possibly one of the hardest things for any project. I carefully avoided the word finish here because my experience leads me to the conclusion that I always want to improve my designs.

But it is important to get to a point in a project where you can say "that is good enough to share", this is more common in software but it really applies to any project.

Share

If your aim here is to improve your society with your contribution sharing your designs and information is important. I think there is nothing better than someone else taking one of your designs and using it and perhaps improving on it, remember that is what you probably did in one way or another better to make it less hard for that to happen.

Ensure your design files are appropriately licensed and they are readily accessible. I personally lean towards the more generally accessible open source licences like MIT but the decision is ultimately yours.

Licencing is important, especially in the current copyright happy society. I know it sounds dull and no one takes that seriously, right? Sorry, but yes they do and it is better for you to be clear from the start, especially if there is a software component to your project. Oh one personal plea, use an existing well known licence, the world simply does not need another one!

Write about it

The blog posts about the things I have made sometimes take almost as much time as the creation. The clear recording on my thoughts in written and photographic form often gives me more inspiration for improvements or other projects.

If someone else gets pleasure from the telling then that can only be good. If you do not do this then your voice cannot be heard and you wasted an opportunity to motivate others.

Feedback

If you do manage to get feedback on your creation, read it. You may disagree or not be interested for the current project but the feedback process is important. In software this often manifests as bug reports, in more physical projects this often becomes forum or blog comments.

Just remember that you need a thick skin for this, the most vocal members of any society are the minority with inflammatory opinion, the silent majority are by definition absent but there is still useful feedback out there.

Create again

By this I simply mean that once you are satisfied yourself on a project move on to the next. This may sound a little obvious but once you have some creative momentum it is much easier to keep going project to project than in you leave time between.

Also do not have too many projects ongoing, by all means have a couple so you do not get stuck waiting for materials or workshop time but more than three and four and you will never be able to release any of them.

Those students were perhaps somewhat misguided in how they stated their opinions, but they are correct that in the world in which we find ourselves we are all influenced. Though contrary to received wisdom those influences are more likely to be from the internet and our peers in the global maker society than historical artists.

The problem: You want to have a critical section of code where concurrent read operations are permitted but exclusive access for write operations multiple readers may read data in parallel but only a single writer is allowed to write data at any one time. Here's an implementation using the eventlet library:

This week's lesson on the Arte y cultura en circulaci n: crear y compartir en tiempos digitales course talks about piracy and the circulation of culture, a topic that over time has been debated over and over. And a topic, yes, that can always lead to interesting discussions. This time, we are requested to choose one among ten ideas among the media groups' discourse on what piracy is and means for the "cultural industry". There are tons of material written already on several of those ten lines (i.e. piracy disincentivates creativity, or two that can be seen as two faces of the same argument, If a consumer can have free access to cultural products, he will stop spending his money on them and Every time a consumer has access to an illegal copy, the industry loses a sale), and some are quite obvious (i.e. Piracy makes job positions be lost... Just look at the amount of people the unauthorized distribution industry feeds! Or possibly, Piracy is a prosper industry that gives money to people distributing illegal products Of course, that is true. The problem is, what causes said products to be illegal to begin with? Should they be so?). Some other ideas talk about harsher penalties and ways to punish illegal copying in order to drive actors out of that sector (and into the... void?) So, I chose item #4: Cultural products have a high cost because their production is complex (and a tag could be made, linking complex with expensive). I think this item can lead to a long discussion as to what does this complexity and cost mean. Some cultural products do require quite a bit of investment, yes. Others don't. How do content producers make the jump to produce expensive works? If I am a new programmer/artist/writer/screenplayer/whatever, most likely, my products will be not very complex or expensive. I will start small. And if I excel at my work, somebody will look at me and, in some way, become my patron, my sponsor. Being a sponsor might mean that, based on the results of my good work, I could get hired as a software developer at a large company, or an editorial company would buy the patrimonial rights of my book/music (be it for a fixed fee or for a percentage of sales), or whatever. But the leap is not made quantically A newcomer to the cultural scene will at first, most likely, have a hard time selling his products. At first, it takes convincing just getting people to take a shot at looking at your work ( Hey, please take a look at my program and tell me what you think about it! , Would you be interested in listening to my latest song? And those two are by far ahead of the first attempts where the interactions would more likely be Turn off that $#^#!^ computer, it's well past bedtime or stop murdering that guitar, I'm having a headache ). Maybe the toughest part is to get people to agree to read/hear your work. And there, you start into a continuum Selling your CDs while performing on the street, then getting to play to a bar, then getting somebody to want to produce (maybe even "discover"!) you. Publish some short stories in your school magazine, then in a "From our audience" section in a larger magazine, then a collective book, your self-published book, yet-unwritten books by contract... The same story over and over again, in each different field. Ok, yes, but... This logic succession still leaves space for the Important Producers with the Mighty Big Pockets for the most wanted/largest productions, right? And were unauthorized distribution (piracy) to be the norm (as it currently is, dare I say), wouldn't they stop producing an important portion of cultural works? I'd be tempted to say so. However, a different actor comes into play. When Mighty Big Pockets comes into play, they no longer worry only about getting money from each cultural creation, but from all derived uses of it. And the cultural creation industry (when seen as an industry) goes very much hand in hand with the advertising, marketing industries They end up blending with each other. So, the biggest best sellers will most likely have a hit from illegal copiers. Books are still a great business, but hey An even better business is (usually) movie making. And when you make a movie out of a great story, you will surely link some advertising into it (or at the very least, push advertising/product pushing campaigns to go after it). And there, illegal distribution actually helps the money circle to grow stronger. In the early 1990s, the link between dinosaurs and carbonated drinks was a top seller (because Pepsi was a Jurassic Park sponsor). Although I have always loathed the madness around the World Cups (and basically anything that involves football of any kind), I can perfectly remember several of the theme songs for most of the world cups played during my lifetime. So, in short... No. Illegal distribution does marginally little harm to the money income to the cultural business, at any level. And where it does get some direct harm, it increases the money flux given the auxiliary channels.

Along with the Rcpp 0.10.5 release yesterday, a new minor release 0.3.920.1 of RcppArmadillo came out. It is based on Conrad's Armadillo 3.920.0 plus a minor fix, and uses some of the new Rcpp features. Both package is now on CRAN and also in Debian. This releases contains both a nice set of new Armadillo features as well as some nice additions to RcppArmadillo, due again mostly to Romain. Some of the changes tie into the changes changes in Rcpp 0.10.5 as for example the ability to pass const and const ref more efficiently (and we seem to have forgotten an entry in the NEWS file). The complete list of changes is below.

Changes in RcppArmadillo version 0.3.920.1 (2013-09-27)

• Upgraded to Armadillo release Version 3.920.1 (Agencia Nacional Stasi)
  • faster .zeros()
  • faster round(), exp2() and log2() when using C++11
  • added signum function: sign()
  • added move constructors when using C++11
  • added 2D fast Fourier transform: fft2()
  • added .tube() for easier extraction of vectors and subcubes from cubes
  • added specification of a fill type during construction of Mat, Col, Row and Cube classes, eg. mat X(4, 5, fill::zeros)
• Initial implementation of wrap<subview>
• Improved implementation of as<>() and wrap() for sparse matrices
• Converted main vignette from LaTeX style minted to lstlisting which permits builds on CRAN; removed set BuildVignettes: FALSE.

Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

A new version of Rcpp is now on the CRAN network for GNU R; binaries for Debian have been uploaded as well. Once more, this release brings a large number of exciting changes to Rcpp. Some concern usability, some bring new features, some increase performance; see below for the detailed list. We have now released three updates on a quarterly cycle; if we keep this up the next version ought to be ready at the end of December. As in the past, we tested the release rather rigorously by checking against all packages I could (relatively easily) built on my server: this time it successfully passed \code R CMD check for all 107 packages I can build locally out of a total of 136 packages. (Two failed: one for an error in \code Makevars , and one for the need of an X11 server during tests; this may get addressed in the in test script next time). As all of these 107 packages passed, we do not expect any issues with dependent packages. Should there be issues we would appreciate a note, preferably with reproducible code, to the rcpp-devel mailing list. The complete NEWS entry for 0.10.4 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.5 (2013-09-28)

• Changes in R code:
  • New R function demangle that calls the DEMANGLE macro.
  • New R function sizeof to query the byte size of a type. This returns an object of S3 class bytes that has a print method showing bytes and bits.
• Changes in Rcpp API:
  • Add defined(__sun) to lists of operating systems to test for when checking for lack of backtrace() needed for stack traces.
  • as<T*>, as<const T*>, as<T&> and as<const T&> are now supported, when T is a class exposed by modules, i.e. with RCPP_EXPOSED_CLASS
  • DoubleVector as been added as an alias to NumericVector
  • New template function is<T> to identify if an R object can be seen as a T. For example is<DataFrame>(x). This is a building block for more expressive dispatch in various places (modules and attributes functions).
  • wrap can now handle more types, i.e. types that iterate over std::pair<const KEY, VALUE> where KEY can be converted to a String and VALUE is either a primitive type (int, double) or a type that wraps. Examples :
    • std::map<int, double> : we can make a String from an int, and double is primitive
    • boost::unordered_map<double, std::vector<double> >: we can make a String from a double and std::vector<double> can wrap itself
    Other examples of this are included at the end of the wrap unit test file (runit.wrap.R and wrap.cpp).
  • wrap now handles containers of classes handled by modules. e.g. if you expose a class Foo via modules, then you can wrap vector<Foo>, ... An example is included in the wrap unit test file.
  • RcppLdFlags(), often used in Makevars files of packages using Rcpp, is now exported from the package namespace.
• Changes in Attributes:
  • Objects exported by a module (i.e. by a RCPP_MODULE call in a file that is processed by sourceCpp) are now directly available in the environment. We used to make the module object available, which was less useful.
  • A plugin for openmp has been added to support use of OpenMP.
  • Rcpp::export now takes advantage of the more flexible as<>, handling constness and referenceness of the input types. For users, it means that for the parameters of function exported by modules, we can now use references, pointers and const versions of them. The file Module.cpp file has an example.
  • No longer call non-exported functions from the tools package
  • No longer search the inline package as a fallback when loading plugins for the the Rcpp::plugins attribute.
• Changes in Modules:
  • We can now expose functions and methods that take T& or const T& as arguments. In these situations objects are no longer copied as they used to be.
• Changes in sugar:
  • is_na supports classes DatetimeVector and DateVector
• Changes in Rcpp documentation:
  • The vignettes have been moved from inst/doc/ to the vignettes directory which is now preferred.
  • The appearance of the vignettes has been refreshed by switching to the Bistream Charter font, and microtype package.
• Deprecation of RCPP_FUNCTION_*:
  • The macros from the preprocessor_generated.h file have been deprecated. They are still available, but they print a message in addition to their expected behavior.
  • The macros will be permanently removed in the first Rcpp release after July 2014.
  • Users of these macros should start replacing them with more up-to-date code, such as using 'Rcpp attributes' or 'Rcpp modules'.

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.4. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

I've just released qcontrol 0.5.2. Changes since the last release:

• Fix memory corruption bug (Debian bug #708376).
• Ignore code 0x43 from PIC, avoid spamming log.
• Implement hysteresis for fan speed (Arno via Debian bug #709095).
• Support for systemd socket activation and added systemd service files (both from Michael Stapelberg).

Get it from gitorious or http://www.hellion.org.uk/qcontrol/releases/0.5.2/. The Debian package will be uploaded shortly.

The BBC coverage of the UCI Women Road Race World Championship wasn t starting until 3pm, BBC Radio 5 Live had football and Sports Extra was playing an advert loop (really BBC?), Eurosport wasn t covering the race at all, RAI Sport 2 had coverage which was fine while I was watching the TV, but my Italian isn t good enough to follow the commentary and I wanted to get some other stuff done. So the obvious thing is to have the computer watch for changes to the great http://live.cyclingnews.com/ ticker and read them out, right? Well, it was to me. Here s the script I used:

#!/usr/bin/rc
# Send updates to live cycling news reports to the speech synth
# initialise
url=http://live.cyclingnews.com/
if (~ $1 *:*)  
  url=$1
 
last=""
while (true)  
    # download the update and strip html - if you don't have html2text try
    # sed -e '1,/<ol/d;s/<br[^>]*>/n/g;s/<[^>]*>//g;s/ / /g;s/[[:space:]]*$//'
    next= () curl -s $url   html2text -width 9999   sed -e 's/^ *[0-9]*. //'  
    # look for some added lines in the update section - timezone will need changing for non-European races
    say= () diff -u < echo $last  < echo $next  
        sed -ne '/^+/!d;s///;s/**//g;/ CES*T/,/^ *$/p'   head -9  
    # feed them to the speech synth in reverse order
    echo $say '
      Race Update'   tac   spd-say -e
    # update variables, pause and loop
    last=$next
    # set this to a prime number over 60, like 61, 67, 71, 73, 79, 83, 89
    sleep 67
 

Any questions, comments or improvements? I could have done more, like not saying Race Update even when there was no update, but I wanted to start listening as soon as possible!

It has taken just over two weeks for blogspam to reject 1 million SPAM comments. I'm not sure how paranoid I should be about false-positives now, (I accept false-negatives easily enough). Using node.js is pretty good for making toy servers, and on that basis here's another toy server:

• https://github.com/skx/sysadmin-logs

This is a small server which is designed to accept HTTP-POSTs containing a payload of a message, these are stored and later retrieved. Seems like a simple thing, right? Imagine how it is used:

root@server1:~# record-log Upgraded mysql
root@server2:~# record-log Tweaked /etc/sysctl.conf
root@server3:~# record-log Added user 'bob'
root@server3:~# record-log Added user 'steve'

Later:

root@server3:~# get-recent
1.2.3.4 2013-09-28T08:08:09.211Z
root:Added user 'bob'
1.2.3.4 2013-09-28T08:08:10.211Z
root:Added user 'steve'

In short it makes it easy to record "activity", and later retrieve it. A host can only fetch the entries it stored, but if you've got access to the remote server then you can get all logs. I suspect a more standard solution is to use syslog-ng, and logger, or similar. But it is a cute hack and I suspect if you've the discipline to record actions then this is actually reasonably useful.

---

• Mahout k-Means took 51 minutes on average per iteration (The raw numbers are 38:24, 62:29, 46:21, 56:20, 52:15, 45:11, 57:12, 44:58, 52:01, 50:26, so you can see there is a surpisingly high amount of variance there).
• ELKI k-Means on a single CPU core took 4 minutes 25 seconds per iteration, and 45 minutes total, including parsing the input data from an ascii file. Maybe I will try a parallel implementation next.

---

• ELKI is quite well optimized. The Java Hotspot VM does a good job at optimizing this code, and I have seen it to be on par with R's k-means, which is written in C. I'm not sure if Mahout has received a similar amount of optimization yet. (In fact, 15% of the Mahout runtime was garbage collection runtime - indicating that it creates too many objects.)
• ELKI can use the data in a uniform way, similar to a column store database. It's literally crunching the raw double[] arrays. Mahout on the other hand - as far as I can tell - is getting the data from a sequence file, which then is deserialized into a complex object. In addition to the actual data, it might be expecting sparse and dense vectors mixed etc.
• Size: this data set fits well into memory. Once this no longer holds, ELKI will no longer be an option. Then MapReduce/Hadoop/Mahout wins. In particular, such an implementation will by design not keep the whole data set in memory, but need to de-serialize it from disk again on each iteration. This is overhead, but saves memory.
• Design: MapReduce is designed for huge clusters, where you must expect nodes to crash during your computation. Well, chances are that my computer will survive 45 minutes, so I do not need this for this data size. However, when you really have large data, and need multiple hours on 1000 nodes to process it, then this becomes important to survive losing a node. The cost is that all interim results are written to the distributed filesystem. This extra I/O comes, again, at a cost.

---

As a maintainer of several software packages I often find myself copying text snippets from the README file into different places (savannah, github, freecode, emails, etc). Recently I had a need to generate a list of software packages that included every project s name, brief summary, license and URL. I could have generated that list manually by copying the text from every project s README and COPYING files. However then I would have to maintain my list manually to keep it in sync with all the projects. This easily leads to stale information, so I thought a better approach would be to put the information I needed into each projects source code version control system. The advantage is that the manual work to extract the information may be automated by a script, since the data is in a usable format. I ll explain here how my solution works. To be able to find the information using only the URL to the repository, I needed a filename convention. The filename I chose was BLURB; for the etymology, see Wikipedia s page about Blurb. The data format in the file is similar to normal email headers. An example illustrate the principles well. Below is the BLURB file for one of my projects.

Author: Yubico
Basename: libyubikey
Homepage: http://opensource.yubico.com/yubico-c/
License: BSD-2-Clause
Name: Yubico C low-level Library
Project: yubico-c
Summary: C library for manipulating Yubico YubiKey One-Time Passwords (OTPs)

The format is simple: UTF-8 text with each line starting with a header followed by a colon ( : ), some whitespace, and some content. If a line starts with whitespace, it is a continuation of the previous line s content (trim leading whitespace). The following table describes the fields that I use. I may update this blog post in the future with new fields or improved explanations (for reference, current date is 2013-09-24).

Header	Meaning
Project	Short identifier for the project (e.g., gcc , emacs )
Name	Official name of the project in English
Summary	Brief one-line summary of the project s purpose in English
Author	Origin of the project
Homepage	URL to the project s website
License	License keyword, preferrably using one of the SPDX license identifiers
Basename	The tarball basename, if different from the project name

Finally some reflection of the solution. After quick design, I thought that I couldn t be the first one with this problem, and I tried to find other similar efforts. I haven t been able to find any standardization effort that have the following properties:

• Stores the information inside each upstream project s own source code repository
• Provides a filename convention so that it is possible to find the data with only the source code repository link
• Encode data in a format that is easy to extract using simple command line tools
• Not encode information about releases (i.e., what happened in a particular version)

The related efforts that I found were SPDX which at first look seemed to offer what I wanted. However on closer examination it failed to deliver on all the requirements above, and appeared to have somewhat different goals. However I found the SPDX license list useful and refer to it. Another effort is Eric S. Raymond s freecode-submit and shipper but its primary focus is to encode information about each release. The design of the BLURB file is clearly influenced by these tools. Another influence has been Debian s specification for machine-readable copyright information. The Free Software Foundation s list of software projects seemed like another candidate, but it doesn t suggest any way to store the information in the upstream project itself.

It s been a while since I posted anything to my personal site, but I figured I should update with the news that I m leaving Brighton (and the UK) after nearly nine years living by the seaside. I ll be sad to leave this city, which is the greatest place to live in the country, but I have to opportunity to go explore the world and I d be crazy to let it pass me by. So what am I doing? In ten short days, I plan to sell all my possessions bar those I need to live and work day to day and will be moving to Spain for three months. I m renting a flat in Madrid, where I ll continue to work for my software development business and set about improving both my Spanish and my fitness. If you want to follow my adventures, or read about the reasons for my change, then check out the Experimental Nomad website. The post A New Chapter appeared first on David Pashley.com.

The third lesson of the Arte y cultura en circulaci n: crear y compartir en tiempos digitales course was quite easy, at least for me, as it's one of the topics I've been involved with for a long time: Authors' rights and ways to exercise them. This lesson starts by talking about the paradoxes created in the reality beneath copyright mostly due to the zero-cost-for-perfect-copy reality we live in today, and then goes on to introduce the most widely spread licensing schemes for cultural works nowadays: The Creative Commons licensing schemes. What I felt very interesting is that the lesson tackles the most common issues raised by authors choosing CC licensing: The Non-Commercial and Non-Derivatives restrictions. While authors are usually not very hard to convince about the virtues (and their personal benefit) in CC licensing, it's usually hard for authors to accept and relinquish the "locks" on non-derivability and non-commercial-use. Now, as to the homework: This time, I have to admit it was a no-brainer to me. The homework was to take part of a "Licenciat n": Publish some work under a open or free license (a work of any kind; it can be text, photo, video, etc.; it can be a new or a pre-existing work) and argue as to why did you choose said license. Even the act of writing this blog post means I'm releasing some work. The bottom of my blog reads, All the material found at this site is freely available, and you can use it as you wish, except when the document mentions explicitly different conditions. Yes, this is not a widely known, preexisting licensing scheme, and more or less goes along the lines of CC0 There are some good things I have posted in this blog, some things I am proud about. This post goes more towards the average quality: Not adding anything of great value to the world, just reiterating/reposting what is already said. But I know this blog is syndicated over several different places, and its content might be copied over to other places. I don't need to know or be notified about it. I just care for people to be able to reach back if they want to do it. But, of course, if I'm asked to do a homework, I prefer not to have it so self-referential. What else to license? We are over halfway across the Wiki Loves Monuments contest for 2013. This year I am clearly not as active on it as I was last year, but yesterday I uploaded about 60 photos from our recent trips, from historical monuments in some towns/cities within ~150Km of Mexico City: Puebla, Tlaxcala, Cacaxtla, Toluca, Santiago Tianguistenco. I intend to upload more. Those photos are licensed CC-BY-SA. Why? Mainly, because it is the defaul for the contest. One of the lessons learned working on Debian is that the less the license I choose deviates from what the upstream authors of a larger project prefer, the more useful my work will be. And being Wikimedia a host of many related projects, I prefer to completely abide by their recommendations unless there is a real, strong reason not to do so. Also, I know that at least most the photos I am uploading are not of contest quality (although some are quite nice, but we don't take that long to take a shot, and our camera is probably too basic to get a quality shot, if not by mere chance). I am using the WLM contest as an excuse to categorize and upload my pictures Of course, I'm not including personal photos, but... If I found a building, place or landscape interesting enough to take a photo of, why not make said photo available for whoever needs it, in a canonical, easy to reach media repository (as Wikimedia Commons) is)? And finally, I think it's time to start getting more open and forward-going with a project that I have been giving a lot of work during the past year, a project that has been even eating quite a bit of my Debian time: My upcoming book. While this book is not yet freely licensed (it is freely distributed online, but does not yet have an explicit license, and I mention it on my teaching/project page. Why? Because it still has some figures and data which are not mine, and which I have to re-elaborate to be able to legally license it. But anyway I am writing a book on the subject of Operating Systems, and am basing my teaching on it. The first semester was basically hell for me, as I was working almost full time on it, and needed to allocate some time as well to the rest of my formal work. This second semester has been quite smoother. And there is a very important (to me) initiative to which I (or should I now start saying, we) submitted this work: The LATIn Project: An initiative to collaboratively create quality, freely redistributable text books for the university level, natively in Spanish, for their use in Latin American countries. I was not able to propose this book due to some formalities Projects have to be proposed by professors in participant universities, and UNAM is not one of them. However, I offered this work to people in the Universidad Nacional de Rosario, Argentina, and they managed to push the project forward. Together with people from Universidad Aut noma de Aguascalientes (M xico) and Universidad del Cauca (Colombia), the project was approved by LATIn. And this LATIn project can also be seen as a why do you agree to license your work this way? candidate: I have already written most of what I'd be happy to call a full book. Of course, I do expect my colleagues to chime in with more content, and I expect us to produce a true collaborative project. But as I am not part of the member universities, they will get paid for their contribution And not me. What do I have to gain from this? More than anything else, the circulation of my work. I'm sure that, were I to publish from UNAM, I would have a good projection. I was (am!) thinking of looking for opportunities to present the book to teachers on the subject, as well as to computing engineering/science students, but the most attractive part (for me) for LATIn is that part of the prize will be that the book will be used to base work on for teaching at least during 2014 in the three said universities And of course, my/our work will only start then, as we will have to further circulate the work. Anyway... I expected this post to be small. But as you can see, I am happy with important work perspectives :-)

On a regular basis, I find myself the odd-man-out when it comes to talking about how to work with Python on Debian systems. I'm going to write this and post it so that I might be able to point people at my thoughts without having to write the same email in response to each thread that pops up. Turns out I don't fit in with the Debian hardliners (which is to say, the mindset that pip sucks and shouldn't exist), nor do I fit in with the Python hardliners (which is to say apt and dpkg are out of date, and neither have a place on a Development machine). I think our discourse on this topic has become petty and stupid in general. Let's all try to step back and drop a bit of the attitude. pip doesn't suck, and neither does apt. The truth is, both sides are wrong. As with any subject, the real answer here is much more nuanced than either side presents it. I'm going to try and present my opinion on this, in the way that both my Pythonista self and my Debianite self see the issue. Hopefully I can keep this short, to the point, and caked with logic. The case for dpkg (the Debianite in me) In defense of dpkg and apt, imagine having to install python-gnome2 on all your systems when you install. It'd be hell on earth. Imagine having a user try to do this. It's insane to assume that end-users will be using pip for this purpose. pip is fun and all, but it's also installing 100% untrusted code to your system (perhaps as root, if you're using pip with sudo for some reason), and hasn't been reviewed for software freeness, which is something Debian (and Debian users) take seriously. This isn't even to mention the hell that pip wreaks on dpkg controlled files / packages. Try to remember how much of your system running (yes, right now) is running because of Python or Python modules. Try to imagine how much of a pain in the ass it'd be if you couldn't boot into GNOME to use nm-applet to connect to wifi to pip install something. I'm sure even the most extreme pip'er understands the need for Operating System level package management. Debian also has a bigger problem scope - we're not maintaining a library in Debian for kicks, we're maintaining it so that end user applications may use the library. When we update something like Django, we have to make sure that we don't break anything using it (although, to be honest, the fact that we package webapps is an entire rant for later) before we get to update it to the newest release. Hell, with a few coffees, I could automate the process of releasing a .deb with a new upstream release, 100% unattended. I won't, however, since this is an insane idea. Let's go over a brief list of things I do before uploading a new package:

1. Review the entire codebase for simple mistakes.
2. Review the entire codebase for license issues.
3. Review the entire codebase for files without source, and track down (and include source for) any sourceless files (such as pickle files, etc).
4. Get to know the upstream, get to know open bugs, write something using the lib, in case I need to debug later.
5. Install the package.
6. Test the package.
7. Work out any Debian package issues (this is easy).

Now, a brief list of things I do before I update a package:

1. Review the changes between the last uploaded version (in diff format, if it's sane, otherwise get the VCS and review), ensure all the above are still OK.
2. Review for Debian-local issues (such as how it will upgrade, using piuparts, and adequate, etc).
3. Check to make sure it won't break any reverse dependencies.
4. Review for bugfixes that I might need to bring back to the stable release.
5. Figure out if I should (or even can) backport the package, if API is stable.
6. Review for bugs (upstream or in Debian) that I need to mention in the debian/changelog.

Clearly, this isn't a quick-and-dirty task. It's not a matter of getting a package updated (technically), it's a much more detailed process than that. This is also why Debian is so highly regarded for its technical virtuosity, and why the ISS decided to deploy Debian in space, despite other commercial distros such as Red Hat, or Ubuntu, and community distros, such as Fedora or Arch. It's also not Debian's job to package the world in the archive. This is an insane task, and it's not Debian's place to do it. We introduce libraries as things need them, not because we wrote some new library that someone may find slightly useful at some point in the future. maybe. Upstream developers and language communities (not only Python here) tend to lose sight of why we're doing this in the first place, which is our users. This isn't some sort of technical pissing contest to see who can distribute the software in the best way. Debian-folk always keep end users as our highest priority. I quote the Debian Social Contract, when I say that Our priorities are our users and free software. No one's trying to get developers to use dpkg to create software. In fact, as you'll see below, I actively discourage using system modules for development. The case for pip (the Pythonista in me) In defense of pip, the idea that Debian will keep the latest versions of packages is insane. The idea that we can keep pace with upstream releases is nuts, and the idea that every upstream release on pypi is ready to ship is bananas. b-a-n-a-n-a-annas. As a developer, I don't want to support every release, and I surely don't want other people depending on some random snapshot. Often times, I'll put stuff up on pypi as a preview, or to release often, and solicit feedback without having to give out instructions on using a git checkout (it's also easier to have them try a version from pypi so I can cross-ref the git tag to reproduce issues when they file them) pypi is easy, ubiquitous and works regardless of the platform, which means less of my development time is spent packaging stuff up for platforms I don't really care about (Arch, Fedora, OSX, Windows), even though I value feedback from users on those systems. The effort it takes to release something is limited to python setup.py sdist upload, and it's in a place (and in a shape) that anyone can use it without having 10 sets of platform-local instructions. Even ignoring all the above, when I'm writing a new app or bit of code, I want to be sure I'm targeting the latest version of the code I depend on, so that future changes to API won't hit me as hard. By following along with my dependencies' development, I can be sure that my code breaks early, and breaks in development, not production. Upstreams also tend to not like bug reports against old branches, so ensuring I have the latest code from pypi means I can properly file bugs. Lastly, I prefer virtualenv based setups for development, since I'm usually working on many things at once. This often means version mismatches in libraries, which brings in API changes (another whole rant here as well). I don't want to keep installing and uninstalling packages to switch between the two projects, and using a chroot(8) means a lot of overhead and that it's disconnected from my development environment / filesystem, so I resort to virtualenv to isolate my Development environment. Final notes I don't want to keep arguing about this. Just accept that the world's a big place and that there exist use-cases that both apt and pip need to exist and work in the way they're working now. At the very least, try and understand there exist smart people on both sides, and no one is trying to screw anyone over or keep their own little private club to themselves. Hopefully, going forward, we can make sure that the integration between these two tools gets better, not worse. Help make this dream a reality. Contribute to a productive tone, not a destructive one. In short:

• Use pip without sudo always. Don't tell people to use sudo.
• Use apt or dpkg when deploying system-wide.
• Understand people are going to package, and they will be more concerned about software using your library then keeping your library up to date.
• Understand Debian Developers and package maintainers have to do a lot of work when updating or sponsoring an upload.
• Understand upstream developers can't be bothered to fix every issue with every release (release early, release often) with some snapshot you introduced into unstable.
• Use pip and virtualenv in development setups, so we can upgrade your app when we upgrade the lib.

I wrote up some potential penances a long time ago, here is what I thought of (or what I've had to do :):

First merge conflict from whitespace: Use a code review tool like gerrit that shows trailing whitespac

First merge conflict from whitespace: Add pre-commit hooks that remove whitespace

First time a feature is broken: Add a test for the feature, including the infrastructure for the test.

First time the client and server releases get out of sync: Run client tests against the released server and server code at top of tree.