Search Results: "cas"

5 June 2013

Lior Kaplan: Getting patches into PHP

One of the various ways to measure an open source project is the way it encourages and accepts patches from community members (or future members). The various open source projects I m involved with have many ways to send patches: mailing list, bug tracking systems and more recently pre-commit tools for peer review (such as gerrit). Another popular option is to use github s pull request feature for this. Personally, I find it too complex for simple patches and would prefer gerrit over it. As part of my work at Zend, I try to make sure patches are sent back upstream. Comparing to other open source projects I know, it seems to me that PHP isn t open enough for contributions. This might be just my private case, but if not, it would be discouraging people to contribute and blocking the community from expanding. 6 Months ago I submitted patch to #36103 (patch is at #63767), but no response. A month ago I submitted a simple patch to FPM s shell script (#64764), and no response there as well. To ease things up, I ve created a github fork of the php-src repository and sent pull requests with each of the patches (as suggested at http://php.net/git-php.php). Even edited the bugs reports with the pull request details (as they provide such integration). I m waiting to see if this will trigger a more rapid review process from the project. For the simple patch, I got a response very fast from a user, but still waiting for a core member to check it. Going over the pull requests (both open and closed), I m not too optimistic about having the patches merged, judging by past merged patches (most of them are at least 2 months) and by the open patches (e.g. a typos fix patch is waiting for month).
Filed under: PHP

4 June 2013

Raphaël Hertzog: My Free Software Activities in May 2013

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (70 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. The Debian Administrator s Handbook Spanish translation completed. The Spanish team finished the translation of the book. The PDF build process was not yet ready to build translations so I had to fix this. At the same time, I also improved the mobipocket build script to make use of Amazon s kindlegen when available (since Amazon now requires the use of this tool to generate Mobipocket files that can be distributed on their platform). Once those issues were sorted I made some promotion of this first completed translation because they really deserve some big kudos ! Plans for the French translation. You know that the Debian Administrator s Handbook came to life as a translation of the French book Cahier de l Admin Debian (published by Eyrolles). This means that we currently have a free translation of a proprietary book. It s a bid of an odd situation that I always wanted to fix. I discussed with Eyrolles to find out how we could publish the original book under the same licenses that we picked for the English book and the result is that we setup a new crowdfunding campaign to liberate the French book and then make it an official French translation of the Debian Administrator s Handbook. Read the rest and support us on the ulule project page (a kickstarter like for people who are not based in the US). Liberate the Debian Handbook Debian France I updated our membership management application (galette) to version 0.7.4.1 with numerous bug fixes but the true highlight this month was Solutions Libres et Opensource , a tradeshow in Paris where Tanguy Ortolo, me, and other volunteers (C dric Boutillier, Arnaud G., and some that I have forgotten, thanks to them!), held a Debian booth for two consecutive days (May 28-29). For once we had lots of goodies to sell (buffs, mouse pad, polos, stickers, etc.) and the booth was very well attended. The Debian Booth (Tanguy on the left, Rapha l on the right) Google s Summer of Code Last month I was rater overwhelmed with queries from students who were interested in applying for the Package Tracking System Rewrite project that I offered to mentor as part of Google s Summer of Code. In the end, I got 6 good student applications that Stefano and me evaluated. We selected Marko Lalic. The Community Bonding Period is just starting and we re fleshing out details on how we will organize the work. We ll try to use the IRC channel #debian-qa on OFTC for questions and answers and weekly meetings. Misc Debian packaging I packaged zim 0.60 and with the release of Wheezy, I uploaded to unstable all the packages that I staged in experimental (cpputest, publican). I sponsored the upload of libmicrohttpd 0.9.27-1. I filed a couple of bug reports that I experienced with the upcoming dpkg 1.17.0 (#709172, #709009). In both cases, the package was using a wrongly hardcoded path to dpkg-divert (the binary moved from /usr/sbin/ to /usr/bin/ a while ago and the compatibility symlink is dropped now). I also dealt with #709064 where the user reported upgrade issues related to multiarch. I also filed an upstream bug report on publican to request some way to avoid so much duplication of files (actually I filed it as a response to the Debian bug #708705 that I received). Kali work I had to update OpenVAS for Kali but some parts failed to build in a Debian 7 environment. I diagnosed the problem and submitted a patch upstream. I also got in touch with the Debian OpenVAS maintainer as I wanted to contribute the package back to Debian, but timing issues have pushed this back for a little longer. Thanks See you next month for a new summary of my activities.

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

3 June 2013

John Goerzen: Two boys, shrimp, and stars

I recently made a routine analysis of my kitchen. (Of course I make a routine analysis of my kitchen; don t you?) In it, I discovered these items, still usable, but approaching that magic throw it out date: So, I thought, what can I make that would use all of these? And I realized I had some shrimp in the freezer, so: a shrimp boil! I tossed it all, plus some various seasonings and a few other veggies, into the Dutch oven, and boiled. Jacob and Oliver watched the activity with interest. Well, except for the potato-peeling part. For that, they went and played with their toy school buses. But the rest was good. They carefully observed me adding some spices, some vegetables, the shrimp, and watched it all simmer. Then it was time to eat. Excitement! Of course, it did take a few minutes to boil, so Jacob got down his whiteboard while Oliver looked on. They enjoyed learning how to peel the shell from the shrimp and devoured their food. And another night recently, Jacob unexpectedly showed up in the kitchen at 10PM. He said he was thirsty, so I got him some water. He asked, Dad, did you make ice cream? Earlier that day, I had prepared ice cream with Oliver, but it was a kind that had to be cooked (lemon with pureed strawberries and peaches) and it wasn t cool enough to finish before their bedtime. I did let them help add the ice and salt to the ice cream freezer just before they went to bed. So I told Jacob that yes, the ice cream was done. He stood there, tiredly, considering, with this oh he ll never say yes to ice cream at 10PM look on his face. So I said, would you like one bite right now? The look of delight on his face was amazing; a broad smile, a twinkle in his eyes, and a clap. So I got out the big bowl of ice cream and scooped up one big spoonful. He loved it. Then I said, should we go look at the stars? I carried Jacob outside to the porch. We stood there, looking up. I used to do this with him periodically, but it had been about a year. So he was thrilled. It was a partially overcast night, but there were still some stars visible. He had no idea there were some stars missing. To him, it was amazing and wonderful and infinite. Oh dad, there are way too many stars to count! He stayed there, arms around my neck, for a minute or two, then was ready to go back inside. I set him down, gave him a hug, said Goodnight, Jacob. And off he trotted, back upstairs, wearing a contented smile, and he fell asleep almost immediately. All it takes to delight children is a bit a shrimp or some stars. And those things delight me, too.

2 June 2013

Thomas Goirand: dtc-xentop: monitoring of CPU, I/O and network for your Xen VMs

What has always been annoying me with Xen, is that xentop is well a piece of shit! It just displays the current numbers of sectors or network bytes read / write. But as an administrator, what you care about, is to know which of your VM is taking all the resources, making your whole server starve. The number of sectors read/write since the VM has started is of very low importance. What you care about is to have an idea of the current transfer rate. And the same apply for networking. So, tonight, within few hours, I hacked a small python shell script using ncurses to do what I needed, which tells how much resources have been used over the last 5 seconds (and not since the VM started). This way, it is easy to know which VM is killing your server. dtc-xentop The script is adapted to my own needs only. Which means that it works only for DTC-Xen VMs of GPLHost. In my case, VM uses exactly 2 partitions, one for the filesystem, and one for the swap, which means that I display exactly that. I m sure it wouldn t be hard to adapt it so that it would work for all cases (which would mean finding out what device uses a VM and getting the statistics from /sys using that information, instead of determining it using the name of the VM). But I don t need it, so the script will stay this way. Before writing this tonight, I didn t know ncurses. Well, it s really not hard, especially in Python! It took me about 2 hours to write^Whack the script (cheating on the dtc-xen soap server which I already had available).

Vagrant Cascadian: debian alarm clock

I finally used my new alarm clock for it's intended purpose, to wake up far earlier than I would normally be inclined. I set the alarm with the "at" command, playing an ogg file previously downloaded off of libre.fm... and groggily awoke to music of my choosing. Admittedly, my search began looking for a replacement for an aging music player, which had no built-in speakers, so didn't work as an alarm clock. Some time ago, the headphone jack broke, so it had kind of functioned as a glorified clock with 6GB of storage and a very little screen... I wanted something more capable; one of my requirements was that it would be feasible to run Debian a well as being relatively portable. I ended with something a little overpowered for an alarm clock... Hello, openpandora! Sporting a 1GHz ARMv7, 512MB of ram, 512MB built-in storage, two SD card slots, wifi, nearly full keyboard, 800x480 touchscreen, useable mouse nubs, 10 hours of battery life under active use... so it's nearly a netbook replacement. Yay, feature creep! It's far lighter than my netbook and fits in the palm of my hand. It fits in my pocket, but barely. Didn't spend much time using the OS it came with, ngstr m. There was already a wiki page about running Debian squeeze using the armel port, but the hardware looked like it could run armhf. Used qemu-debootstrap to build a Debian Wheezy armhf image on an SD card, and figured out the relatively simple process of booting the kernel shipped with it with an alternate root device. And it worked! But the kernel was a litle bit older than what's was in Wheezy, at the time, so I spent a couple days getting the kernel to build from the latest linux sorce package in Debian. There was a pandora git reposiory for linux 3.2.39, and most of the patches applied cleanly(those that didn't seemed already applied with the newer version). After a few build cycles, managed to get a working kernel, though haven't yet trimmed down the kernel config to my liking. Ideally, it'll get sufficiently upstreamed to be able to use the omap kernel variant. Also put together a package that configures the keyboard map, touchscreen and some cpu frequency scaling settings. Still need to document all that. Spent a week without a laptop or other computer while traveling... and the openpandora running Debian Wheezy held up pretty well.

31 May 2013

Julien Danjou: OpenStack Ceilometer Havana-1 milestone released

Yesterday, the first milestone of the Havana developement branch of Ceilometer has been released and is now available for testing and download. This means the first quarter of the OpenStack Havana development has passed! New features Ten blueprints have been implemented as you can see on the release page. I'm going to talk through some of them here, that are the most interesting for users. Ceilometer can now counts the scheduling attempt of instances done by nova-scheduler. This can be useful to eventually bill such information or for audit (implemented by me for eNovance).
People using the HBase backend can now do requests filtering on any of the counter fields, something we call metadata queries, and which was missing for this backend driver. Thanks to Shengjie Min (Dell) for the implementation. Counters can now be sent over UDP instead of the Oslo RPC mechanism (AMQP based by default). This allows counter transmission to be done in a much faster way, though less reliable. The primary use case being not audit or billing, but the alarming features that we are working on (implemented by me for eNovance).
The initial alarm API has been designed and implemented, thanks to Mehdi Abaakouk (eNovance) and Angus Salkled (RedHat) who tackled this. We're now able to do CRUD actions on these. Posting of meters via the HTTP API is now possible. This is now another conduct that can be used to publish and collector meter. Thanks to Angus Salkled (RedHat) for implementing this. I've been working on an somewhat experimental notifier driver for Oslo notification that publishes Ceilometer counters instead of the standard notification, using the Ceilometer pipeline setup. Sandy Walsh (Rackspace) has put in place the base needed to store raw notifications (events), with the final goal of bringing more functionnalities around these into Ceilometer. Obviously, all of this blueprint and bugfixes wouldn't be implemented or fixed without the harden eyes of our entire team, reviewing code and advising restlessly the developers. Thanks to them! Bug fixes Thirty-one bugs were fixed, though most of them might not interest you so I won't elaborate too much on that. Go read the list if you are curious. Toward Havana 2 We now have 21 blueprints targetting the Ceilometer's second Havana milestone, with some of them are already started. I'll try to make sure we'll get there without too much trouble for the 18th July 2013. Stay tuned!

30 May 2013

Steve Kemp: First binary release of lumail

Give me a few days and I'll stop writing about Lumail, but tomorrow I intend to make the first stable source & binary release. From that point onwards you'll not need to track the github repository to getu pdates. The website has had an overhaul in advance of the release, but could still benefit from a logo. As usual I've written the website using my templer static-site generator. I hacked up a couple of plugins to make it easy to generate the pages of Lua primitive documentation, and handle cross-links suitably. (The source is available for reference.) The first binary release of the mail-client is obviously something of a big deal. I've been using the client daily for the past week or so, as a read-only mail-viewer. But now that the compose() and reply() primitives are present it is usable "for real". Having real scripting present is also allowing me to do interesting things, which are kinda/sorta demonstrated on the examples page. Now its a case of fixing up a couple of display-related glitches, and implementing things that are both missing and desirable. Happily the list of missing things is actually surprisingly small. I think the biggest outstanding issue is that the defaults are Steve-friendly, for example the colour-setup should probably be configurable. Beyond the personal-defaults I think the next biggest issue is the lack of threading support. Messages are displayed in oldest->newest order. Always. The other omission is that it is impossible to tag-things, in the mutt-sense, so you can't reply to two messages at once. That's a design decision I might have to revisit. The balance of course is that you can open multiple folders at once, and that rocks! Happy days.

29 May 2013

Daniel Pocock: Comments are back, spammers are not

After a few more queries, I've tried enabling blog comments again, so please jump in and feel free to make a contribution. Thanks to the earlier feedback from Gunnar Wolf, I'm trying a combination of the Drupal modules CAPTCHA, Blogspam and moderation to keep out those pesky spammers. I understand people hate CAPTCHAs, so do I. The previous rate of spam was so high (over 100 spam comments per day) that it would not be feasible for me to moderate manually, so CAPTCHA is the lesser evil in this case.

Russell Coker: Nexus 4

My wife has had a LG Nexus 4 for about 4 months now so it s time for me to review it and compare it to my Samsung Galaxy S3. A Sealed Case The first thing to note about the Nexus 4 is that it doesn t support changing a battery or using micro-SD storage. The advantage of these design choices is that it allows reduced weight and greater strength compared to what the phone might otherwise be. Such choices would also allow the phone to be slightly cheaper which is a massive advantage, it s worth noting that the Nexus 4 is significantly cheaper than any other device I can buy with comparable specs. My wife s phone has 8G of storage (not RAM thanks Robin) and cost $369 at the start of the year while the current price is $349 for the 8G version and $399 for the 16G version. Of course one down-side of this is that if you need 16G of storage then you need to spend an extra $50 on the 16G phone instead of buying a phone with 8G of storage and inserting a 16GB micro-SD card which costs $19 from OfficeWorks. Also there s no option of using a 32G SD card (which costs less than $50) or a 64G SD card. Battery etc The battery on the Nexus 4 isn t nearly big enough, when playing Ingress it lasts about half as long as my Galaxy S3, about 90 minutes to fully discharge. If it was possible to buy a bigger battery from a company like Mugan Power then the lack of battery capacity wouldn t be such a problem. But as it s impossible to buy a bigger battery (unless you are willing to do some soldering) the only option is an external battery. I was unable to find a Nexus 4 case which includes a battery (which is probably because the Nexus 4 is a lot less common than the Galaxy S3) so my wife had to buy an external battery. If you are serious about playing Ingress with a Nexus 4 then you will end up with a battery in your pocket and cable going to your phone from the battery, this is a real annoyance. While being a cheap fast phone with a clear screen makes it well suited to Ingress the issue of having a cable permanently attached is a real down-side. One significant feature of the Nexus 4 is that it supports wireless charging. I have no immediate plans to use that feature and the wireless charger isn t even on sale in Australia. But if the USB connector was to break then I could buy a wireless charger from the US and keep using the phone, while for every other phone I own a broken connector would render the phone entirely useless. Screen Brightness I have problems with my Galaxy S3 not being bright enough at midday when on auto brightness. I have problems with my wife s Nexus 4 being too bright in most situations other than use at midday. Sometimes at night it s painfully bright. The brightness of the display probably contributes to the excessive battery use. I don t know whether all Nexus 4 devices are like this or whether there is some variance. In any case it would be nice if the automatic screen brightness could be tuned so I could make it brighter on my phone and less bright on my wife s. According to AndroSensor my Galaxy S3 thinks that the ambient light in my computer room is 28 lux while my wife s Nexus 4 claims it s 4 lux. So I guess that part of the problem is the accuracy of the light sensors in the phones. On-Screen Buttons I am a big fan of hardware buttons. Hardware buttons work reliably when your fingers are damp and can be used by feel at night. My first Android phone the Sony-Ericsson Xperia X10 had three hardware buttons for settings, home, and back as well as buttons for power, changing volume, and taking a photo which I found very convenient. My Galaxy S3 has hardware buttons for power, home, and volume control. I think that Android phones should have more hardware buttons not less. Unfortunately it seems that Google and the phone manufacturers disagree with me and the trend is towards less buttons. Now the Nexus 4 only has hardware buttons for power, and volume control. One significant advantage of the Galaxy S3 over the Nexus 4 is that the S3 s settings and back buttons while not implemented in hardware are outside the usable screen area. So the 4.8 1280*720 display is all for application data while the buttons for home, settings, and back on the Nexus 4 take up space on the screen so only a subset of the 4.7 1280*768 is usable by applications. While according to specs the Nexus 4 has a screen almost as big as the Galaxy S3 and a slightly higher resolution in practice it has an obviously smaller screen with fewer usable pixels. Also one of the changes related to having the buttons on-screen means that the settings button is often in the top right corner which I find annoying. I didn t like that aspect of the GUI the first time I used a tablet running Android 3.0 and I still don t like it now. GPS My wife s Nexus 4 seems to be much less accurate than my Galaxy S3 for GPS. I don t know how much of this is due to phone design and how much is due to random factors in manufacturing. I presume that a large portion of it is due to random manufacturing issues because other people aren t complaining about it. Maybe she just got unlucky with an inaccurate phone. Shape and Appearance One feature that I really like in the Samsung Galaxy S is that it has a significant ridge surrounding the screen. If you place a Galaxy S face-down on a desk that makes it a lot less likely to get a scratch on the screen. The LG U990 Viewty also had a similar ridge. Of course the gel case I have bought for every Android phone has solved this problem, but it would really be nice to have a phone that I consider usable without needing to buy such a case. The Nexus 4 has a screen that curves at the edges which if anything makes the problem worse than merely lacking a ridge around the edge. On the up-side the Nexus 4 looks and feels nice before you use it. The back of the Nexus 4 sparkles, that s nice but when you buy a gel case (which doesn t seem to be optional with modern design trends) you don t get to see it. The Nexus 4 is a very attractive package, it s really a pity that they didn t design it to be usable without a gel case. Conclusion Kogan is currently selling the Galaxy S3 with 16G of storage for $429. When comparing that to the 16G version of the Nexus 4 at $399 that means there s a price of $30 to get a SD socket, the option of replacing a battery, one more hardware button, and more screen space. So when comparing the Google offers for the Nexus 4 with the Kogan offer on the Galaxy S3 or the Galaxy Note which also has 16G of storage and sells for $429 the Google offer doesn t seem appealing to me. The Nexus 4 is still a good phone and is working well for my wife, but she doesn t need as much storage as I do. Also when she got her phone the Galaxy S3 was much more expensive than it is now. Also Kogan offer the 16G version of the Nexus 4 for $389 which makes it more appealing when compared to the Galaxy S3. It s surprising that they can beat Google on price. Generally I recommend the Nexus 4 without hesitation to anyone who wants a very capable phone for less than $400 and doesn t need a lot of storage. If you need more storage then the Galaxy S3 is more appealing. Also if you need to use a phone a lot then a Galaxy S3 with a power case works well in situations where the Nexus 4 performs poorly.

Russ Allbery: Review: The Making of the Indebted Man

Review: The Making of the Indebted Man, by Maurizio Lazzarato
Translator: Joshua David Jordan
Publisher: Semiotext(e)
Copyright: 2011, 2012
Printing: 2012
ISBN: 1-58435-115-2
Format: Trade paperback
Pages: 199
This is a continuation of my effort to catch up on Marxist thought while pondering workplace governance, this time following the recommendations of a friend after a related conversation (about pension systems and basic income guarantee in a Usenet group Usenet isn't dead yet). As opposed to Democracy at Work, which is a popularization, The Making of the Indebted Man has more of the density of a scholarly text. The version I'm reading is also in translation, which I suspect makes it even harder going in places. The basic thesis, though, is clear: debt is far more central to the way that we construct not only economic systems but social systems and even internal models of our own nature than is often realized. We prefer to think of societies as structured around mutual exchange, but in practice they're more often constructed around concepts of debt and credit that have been fully internalized and used to construct a moral code for a responsible debtor. And this is not a neutral construction; rather, it is a key support mechanism of capitalism and of the financial and economic status quo, used (both intentionally and accidentally) to reduce uncertainty and to support exploitation and economic domination. This is one of those perspectives that didn't occur to me prior to reading this book but which is startlingly obvious in retrospect. Once Lazzarato starts pointing it out, the prevelance and universality of debt as a basic structure of social and economic life is striking. The creditor and debtor concept extends not just to obvious examples, such as consumer credit or mortgages, but also to education (via student loans), law enforcement ("pay one's debt to society"), employment (most employers, particularly during economic downturns, have successfully inverted the natural direction of the creditor relationship and have made employees feel in debt to the employer for having a job), and social services (unemployment and welfare benefits come with significant, if often unstated, debt-like requirements). Debt is also the great leveller. It now cuts across race, gender, and social class. Apart from a small handful of extremely rich individuals and corporations, Lazzarato claims, convincingly, that nearly everyone is enmeshed to some extent in a network of debt, or at least in in attitudes and moral pressures of a debtor. Nor is this a static situation. The role of debt in our social lives seems to be constantly increasing. The past fifteen years in particular have seen drastic increases in debt during a debt-funded economic boom combined with debt-funded asset bubbles. Even after the financial collapse, much of that growth of debt persists. Lazzarato, probably in part because he's Italian, focuses on national debt (more on that in a moment); as an American, I'd identify student loan debt as a more compelling example in the United States. Other countries probably have their own examples. For a system to be this widespread, it must serve some social purpose. Lazzarato sees it as an instrument of control. Debt has been very effectively built up as a moral obligation, and (unlike a society of mutual support) it's a very one-sided moral obligation that strongly favors existing power. The debtor is held to a tight moral standard of repayment of debts, and is morally condemned by all of society, including their peers, for a failure to repay. But there is little or no corresponding moral pressure on the creditor: perhaps a half-hearted dislike of high interest rates or occasional pressure to not change previously agreed terms, but nothing like the moral pressure applied to the debtor. To be a creditor is to have an agreed-upon, one-sided right to dictate to the debtor the terms on which they must conduct a portion of their life, and the larger the debt, the larger the portion. The debtor is expected to realign their life, at least in part, around paying off the debt, including choice of profession, decisions about when to quit a job, about how to prioritize personal spending, and so forth. This is all so automatic and so deeply ingrained that, even while writing this, I'm nodding along and thinking "well, of course." Lazzarato offers an opportunity to take a step back and think about the implications, particularly of the deeply one-sided web of obligations this creates. A Marxist analysis adds another level of consideration. One of the basic questions of Marxist thought is why workers put up with exploitation by capitalists. In a Marxist analysis, workers provide the productive output of society, which is then redirected and controlled by a relatively small capitalists. The workers massively outnumber the capitalists. Why would they be content for this situation to continue? Marx, of course, thought they wouldn't be, that the periodic crises of capitalism would eventually result in a socialist revolution by the workers. But by and large this hasn't happened. Why? Lazzarato offers debt as a partial explanation. The profits redirected by capitalists are returned to workers to some extent, but as debt rather than payment. This allows workers to participate to some extent in the growth of societal wealth from constantly increasing productivity, while simultaneously entangling workers in a system of moral control. Company stores, starvation wages, and other confiscatory practices are clear mechanisms of external control that provoke directed outrage. Debt is something that the debtor has nominally agreed to (however much the situation is manipulated to make that agreement almost inevitable), and to which attaches a deep tradition of moral responsibility. The worker has respected grounds on which to object to inequitable treatment; the debtor is wholly responsible for repayment, and is rarely considered to have grounds to complain about the debt. Most of the historical attempts to balance those scales, such as laws and religious rules against usury or the historical Jewish rule of Jubilee, have fallen by the wayside. This is a rather extended summary of what I got out of the book. I'm doing that in part because the book itself is somewhat heavy going. Lazzarato makes extensive use of specialized terms (often not defined) and fills the book with references to other works without much in the way of useful summary. It's the sort of book where, if you're not already well-versed in the field, you may need to just keep reading through some passages to find a point of reference that makes the argument retroactively make sense. I had a particular difficulty with "subjectivation," a term that Wikipedia tells me is from the writings of Michel Foucault (a major source for this book), which Lazzarato uses extensively but never adequately defines. Some external research indicates that this is a very difficult term to define, which explains why I was never quite comfortable with my understanding. I think Lazzarato is using it to get at the process of internalization of the morality of debt and the way that a debt society forces individuals into a mode of economic individualism in which many of their personal choices are bent towards making themselves better (more reliable, more trustworthy) debtors. But I'm not completely sure. There are also places in which I think Lazzarato takes his argument too far, although one of those, I think, reflects a difference in national economic status. He makes quite a lot of national debt in this book, placing it in the universal position of the overarching debt that turns every citizen into a debtor even if they've avoided other debts. This is possibly true in countries whose national debts are held in other currencies, or in countries like Italy that are part of the Euro (which, if one is not Germany or France, amounts to much the same thing). It's a dubious assertion for countries like the UK, Japan, or the United States, where the national debt is held in their own free-floating currency and is largely owed domestically, and partly plays into some frustratingly incorrect political rhetoric. One of the key dynamics of debt, namely the extreme power imbalance between debtor and creditor, is missing in countries with sovereign debt in their own currency, since those countries can always (if they're willing to pay the inflation price) simply print money to pay off national debt. Creditors know this, and therefore interest rates are much lower, the amount of leverage the creditor has is quite limited, and the sorts of debt crises seen in Italy and elsewhere in the Euro periphery are not seen. Lazzarato is understandably writing from the Italian perspective, but I think he weakens his argument by lumping national debt so completely into the same category as the other types of exploitative debt he discusses. The principle does feel universal to me, but the best examples of debt vary by country, so one has to be careful about generalizing specific examples. Another place where I simply disagree with his conclusions is around some of the more dramatic presentations of subjectivation. Lazzarato talks, at one point, about how debt reduces debtors to mechanical components, and uses as an example an ATM machine, which he portrays as uniquely dehumanizing through the mechanical process that someone has to follow to withdraw money. There may be some point here about the dehumanization of debt and its subsumption into the foundation of day-to-day social interaction, but he lost me entirely with the unwarranted technophobia of the specific example. The idea that machines and automation make us less human is an old argument that's orthogonal to the thrust of his argument. It reminded me of old contentions that human relationships made on-line aren't real, which is nonsense. Overall, this is a fascinating and insightful discussion hampered by a difficult and sometimes overly elliptical presentation, a bit too much drama and grand theorizing, and a few poor choices of examples. I found the basic idea extremely valuable, but the amount of work required to extract it occasionally irritating. (This could be partly due to the limits of translation, but I suspect most of the difficulty was present in the original.) I'm not sure that I would recommend the book, but I definitely recommend considering the underlying ideas. Debt now works alongside the employment relationship as a primary means of reinforcing economic and social control and hierarchy. This is likely via accidental development rather than any grand plan, but it's now being actively exploited by the creditors of society, large corporations most notably. Viewed in that light, the explosive growth of student loan debt in the United States is particularly frightening. After Lazzarato's extensive examination of the distortive effects of permanent debt, not just on economics and society but on our own conceptions of our selves and our duties and roles in life, the idea of trapping a generation in debt from the moment of their financial independence is deeply troubling, even nauseating. Rating: 6 out of 10

28 May 2013

Matthew Garrett: Secure Boot isn't the only problem facing Linux on Windows 8 hardware

There's now no shortage of Linux distributions that support Secure Boot out of the box, so that's a mostly solved problem. But even if your distribution supports it entirely you still need to boot your install media in the first place.

Hardware initialisation is a slightly odd thing. There's no specification that describes the state ancillary hardware has to be in after firmware OS handover, so the OS effectively has to reinitialise it again. This means that certain bits of hardware end up being initialised twice, and that's slow in some cases. The most obvious is probably USB, which has various timeouts as you wait for hardware to settle. Full USB support in the firmware probably adds a couple of seconds to boot time, and it's arguably wasted because the OS then has to do the same thing (but, thankfully, can at least do other things at the same time). So, looking for USB boot media takes time, and since the overwhelmingly common case is that users don't want to boot off USB, it's time that's almost always wasted.

One of the requirements for Windows 8 certified hardware is that it must complete firmware initialisation within a specific amount of time, something that Microsoft refer to as "Fast Boot". Meeting these requirements effectively makes it impossible to initialise USB, and it's likely that certain other things will also be skipped. If you've got a USB keyboard then this obviously means that your keyboard won't work until the OS starts, but even i8042 setup takes time and so some laptops with traditional PS/2-style keyboards may not set it up. That means the system will ignore the keyboard no matter how much you hammer it at boot, and the firmware will boot whichever OS it finds.

For a newly purchased device, that's going to be Windows 8. It's not too much of a problem with a fully installed Windows 8, since you can hold down shift while clicking the reboot icon and get a menu that lets you reboot into the firmware menu. Windows sets a flag in a UEFI variable and reboots the system, the firmware sees that flag and does full hardware initialisation and then drops you into the setup environment. It takes slightly longer to get into the firmware, but that's countered by the time you save every time you don't want to get into the firmware on boot.

So what's the problem? Well, the Windows 8 setup environment doesn't offer that reboot icon. Turn on a brand new Windows 8 system and you have two choices - agree to the Windows 8 license, or power the machine off. The only way to get into the firmware menu is to either agree to the Windows 8 license or to disassemble the machine enough that you can unplug the hard drive[1] and force the system to fall back to offering the boot menu.

I understand the commercial considerations that result in it ranging from being difficult to impossible to buy new hardware without Windows pre-installed, but up until now it was still straightforward to install an alternative OS without agreeing to the Windows license. Now, installing alternative operating systems on many new systems will require you to give up certain rights even if you want nothing other than to reach the system firmware menu.

I'm firmly of the opinion that there are benefits to Secure Boot. I'm also in favour of setups like Fast Boot. But I don't believe that anyone should be forced to agree to a EULA purely in order to be able to boot their own choice of OS on a system that they've already purchased.

[1] Which is a significant and probably warranty-voiding exercise on many systems, and that's assuming that it's not an SSD soldered to the motherboard

comment count unavailable comments

Lars Wirzenius: On the usefulness of wishlist bugs

Almost every bug tracker for free software projects has a section for wishlist bugs. Often this results in ever growing lists of wishes, most of which will never be fulfilled. A long list of bugs, even if it is wishlist bugs, is rarely useful. It's hard to keep track of what is there, and so the information is not kept up to date when things change. Even if a wishlist bug gets implemented, the bug is often overlooked, and remains on the list. Joel Spolsky calls this a software inventory. Carrying a large inventory has costs, and usually results in slowed-down development. It increases the friction of doing things in a project. I have some quite old wishlists for my own projects. I have even more wishlists hidden in my own GTD system. I am not happy about either, and I'm going to have to do something about that. Just closing all wishlist bugs immediately would be bad manners. Keeping them open indefinitely, just in case someone will some day decide to look through the list in order to hack on something, is wishful thinking: that rarely happens. So I'm thinking of a compromise: keep wishlist bugs open for a while, perhaps a few months, and if nothing is happening to them, close them with an apology.

Daniel Pocock: The BBC and a confused concept of what is free and open

One of the top 10 read pages on the BBC website today is a feature article by acclaimed computer scientist and inventor Jaron Lanier (inventor of the term virtual reality) urging the middle class to Sell your data to save the economy and your future This particular quote stands out:
"The medicine of our time is purported to be open information. The medicine comes in many bottles: open software, free online education, European pirate parties, Wikileaks, social media, and endless variations of the above."
While Lanier makes some legitimate points about the way people share their personal data (everything from relationships to medical records) his writing in this instance seems to put concepts such as "open software" and free online education in the same basket as the abuse of medical records and the systematic collection of fingerprints and DNA samples by new-age tyrants. Various thoughts come to mind:
  • Would he make these same claims against software that is distributed under a strong copy-left license such as the GPL?
  • Is he arguing that software engineers should work for royalties on use of our code rather than salaries paid to developers who produce free, open source software?
  • Is centralised computer power a black-and-white issue? What is to stop the middle class from pooling their resources into distributed clusters that can compete with data-center owners like Facebook? SETI@home is one particularly well known example. By joining the cloud of their choice, the public is, in a way, democratically exercising control over the way computing power is used.
  • How does he define the difference between "free online education" and the free public libraries that we all know and love? If free online education, research papers and other materials are not available, then does he also believe libraries should start charging door fees?
  • Was this article edited by the BBC in such a way that it no longer coherently represents what he aimed to say? Editing errors are not unheard of in the press.
Of course, this type of confusion is not out of place for a country that has multiple broadcast services promoted under the names Freesat, Freesat and Freeview while none of them are actually free of charge due to a controversial tax on watching TV that a whopping 22% of the population refuse to pay.

Russell Coker: SCSI Failures

For a long time it was widely regarded that SCSI was the interface for all serious drives that were suitable for Enterprise Use or for anything else which requires reliable operation. On the other hand IDE was for cheap disks that were only suitable for home use. The SCSI vs IDE issue continues to this day but now we have SAS and SATA filling the same market niches with the main difference between the current debate and the debate a decade ago being that a SATA disk can be connected on a SAS bus. Both SAS and SATA have a single data cable for each disk which avoids the master/slave configuration on IDE and the issue of bus device ID number (from 0-7 or 0-15) and termination on SCSI. Termination When a high speed electrical signal travels through a cable some portion of the signal will be reflected from any cable end point or any point of damage. To prevent the signal reflection from the end of a cable you can have a set of resistors (or some other terminating device) at the end of the cable, see the Terminator(electrical) Wikipedia page [1] for a brief overview. As an aside I think that page could do with some work, if you are an EE with a bit of spare time then improving that page would be a good thing. SCSI was always designed to have termination while IDE never was. I presume that this was largely due to the cable length (18 for IDE vs 1.5m to 25m for SCSI) and the number of devices (2 for IDE vs 7 or 15 for SCSI). I also presume that some of the problems that I ve had with IDE systems have been related to signal problems that could have been avoided with a terminated bus. My first encounter with SCSI was when working for a small business that focused on WindowsNT software development. Everyone in the office knew a reasonable amount about computers and was happy to adjust the hardware of their own workstation. A room full of people who didn t understand termination who fiddled with SCSI buses tended to give a bad result. On the up-side I learned that a SCSI bus can work most of the time if you have a terminator in the middle of the cable and a hard drive at the end. There have been two occasions when I ve been at ground zero for a large deployment of servers from a company I ll call Moon Computers. In both cases there were two particularly large and expensive servers in a cluster and one of the cluster servers had data loss from bad SCSI termination. This is particularly annoying as the terminators have different colours, all that was needed to get the servers working was to change the hardware to make them look the same. As an aside the company with no backups [2] had one of the servers with bad SCSI termination. Heat SCSI disks and now SAS disks tend to be designed for higher performance, this usually means greater heat dissipation. A disk that dissipates a lot of heat won t necessarily work well in a desktop case with small and quiet fans. This can become a big problem if you have workstations running 24*7 in a hot place (such as any Australian city that s not in Tasmania) and turn the air-conditioner off on the weekends. One of my clients lost a few disks before they determined that IDE disks are the only option for systems that are to survive Australian heat without any proper cooling. Differences between IDE/SATA and SCSI/SAS In 2009 I wrote about vibration and SATA performance [3]. Rumor has it that SCSI/SAS disks are designed to operate in environments where there is a lot of vibration (servers with lots of big fans and fast disks) while IDE/SATA disks are designed for desktop and laptop systems in quiet environments. One thing I d like to do is to test performance of SATA vs SAS disks in a server that vibrates. SCSI/SAS disks have apparently been designed for operation in a RAID array and therefore will give a faster timeout on a read error (so another disk can return the data). While IDE/SATA disks are designed for a non-RAID situation and will spend longer trying to read the data. There are also various claims about the error rates from SCSI/SAS disks being better than those of IDE/SATA disks. But I think that in all cases the error rates are small enough not to be a problem if you use a filesystem like ZFS or BTRFS but they are also large enough to be a significant risk with modern data volumes if you have a lesser filesystem. Data Loss from Storage Failure In the data loss that I ve personally observed from storage failures the loss from SCSI problems (termination and heat) is about equal to all the hardware related data loss I ve seen on IDE disks. Given that the majority of disks I ve been responsible for have been IDE and SATA that s a bad sign for SCSI use in practice. But all serious data loss that I ve seen has involved the use of a single disk (no RAID) and inadequate backups. So a basic RAID-1 or RAID-5 installation will solve most hardware related data loss problems. There was one occasion when heat caused two disks in a RAID-1 to give errors at the same time, but by reading from both disks I managed to get almost all the data back, RAID can save you from some extreme error conditions. That situation would have been ideal for BTRFS or ZFS to recover data. Conclusion SCSI and SAS are designed for servers, using them in non-server systems seems to be a bad idea. Using SATA disks in servers can have problems too, but not typically problems that involve massive data loss. Using technology that is too complex for the people who install it seems risky. That includes allowing programmers to plug SCSI disks into their workstations and whoever it was from Moon computers or their resellers who apparently couldn t properly terminate a SCSI bus. It seems that the biggest advantage of SAS over SCSI is that SAS is simple enough for most people to be able to correctly install it. Making servers similar to the systems that the system administrators use at home seems like a really good idea. I think that one of the biggest benefits of using x86 systems as servers is that skills learned on home PCs can be transferred to administration of servers. Of course it would also be a good idea to have test servers that are identical to servers in production so that the sysadmin team can practice and make mistakes on systems that aren t mission critical, but companies seem to regard that as a waste of money apparently the risk of down-time is cheaper.

Russ Allbery: Review: Advanced Perl Programming

Review: Advanced Perl Programming, by Sriram Srinivasan
Publisher: O'Reilly
Copyright: August 1997
ISBN: 1-56592-220-4
Format: Trade paperback
Pages: 392
The problem with buying lots of books is that one frequently doesn't read them soon after purchase. And while nearly all fiction and most non-fiction doesn't have a time limit, technical books are more of a problem. As you might have guessed from the publication date and subject matter of this book, it's one I waited too long to read. I picked up Advanced Perl Programming not too long after it was first published in 1997. I bought it primarily for the chapters on XS programming, since I was just starting to develop and help maintain code that built Perl interfaces for C libraries. And then it sat on my bookshelf in the office, and then at home, until it was 16 years old. That's problematic for a general Perl programming guide; it's particularly troublesome for a book that dives deep into internals. That said, I still got some interesting information from it. Advanced Perl Programming is something of a grab bag of different and largely unrelated topics. It starts with a data structures overview (which is mostly about references), covers typeglobs and the Perl symbol table, briefly discusses closures, and then dives deeper into eval. That's followed by an overview of modules and object-oriented programming in Perl. The general Perl topics close with a solid (if outdated) discussion of tied objects and a somewhat rambling and remarkably general discussion of persistance. Srinivasan then covers some recommended module APIs for networking and graphics (Tk, specifically) while working through some complex examples, takes a deeper dive into eval and code generation, and concludes with three chapters on XS and embedded Perl interpreters. This is all solid material, but a lot of it is at least partly obsolete. The chapters on modules and object-oriented programming fare the worst; you'll find much better guides to those topics elsewhere. Data structures also fare poorly, partly because Srinivasan is still happy to use symbolic references, now considered bad style due to lack of compile-time checking. (That does mean, though, that this is one of the best introductions to symbolic references that you'll find, since few other Perl programmers discuss them.) But the rest of the book is fairly solid, if limited by age. If I'd read it when I first started with XS, it would have indeed helped. Advanced Perl Programming contains a succinct and clear overview of Perl internals and data representation (assuming, of course, it's not changed drastically, but I didn't notice any significant issues from what I know of internals from quite a lot of XS programming), particularly when combined with the earlier chapter on typeglobs and the symbol table. It is interesting, though, to see how much accepted Perl style has changed. Srinivasan is quite fond of eval with a scalar argument to construct code at runtime, something that most current authors recommend against when it can be avoided. The loss of static syntax checking means the technique is often hard to debug and can cause surprising runtime errors. Several of the more advanced tricks in this book are built on that framework, including a moderately interesting templating system that he constructs from scratch in this book. The examples here are also missing the focus on use strict, warnings, and avoiding special variables and unusual constructs that you see in more recent Perl books. This is a very thoughtful book, with several structural techniques that I appreciated and would like to see more technical writers use. One is the comparisons to the approaches of other languages at the end of most chapters. It puts Perl's approach in a broader context and encourages thought about alternative ways to view a particular feature and implementation tradeoffs in Perl's choices. Another is the careful discussion of design approaches and possibilities during the construction of larger examples. I think there's a tendency in technical books to spend a lot of time developing the best possible implementation of something and then show that completed example. Even with a detailed analysis of its construction, this can be less useful than a broader discussion of possible approaches, including dead ends. The problem, of course, is that 16 years is a long time, even for a relatively mature programming language, and Perl has changed. There are significant improvements not only to the standard library but to Perl core functionality that have happened since this book was written. The chapter on tying, which is otherwise excellent, is badly out of date on what functionality and methods are available and is no longer a reliable guide to using that feature except for simple cases. Similar problems plague the chapter on persistence, which develops the concept from basics that most programmers reading an advanced book no longer need, and which has been rendered mostly obsolete by further developments in the Perl module ecosystem. I think the best parts of this book, the ones that cover material that I think is still relatively accurate and that are not well-covered by other resources, are the chapters on typeglobs and on XS. The typeglob discussion is both clear and informative, covering material and techniques that are used in a few core Perl modules and that I've never seen adequately addressed elsewhere. I'd subsequently picked up XS and Perl embedding the hard way: lots of trial and error and reading difficult POD documentation. I wish I'd read this book earlier, since Srinivasan does a great job of basic orientation. He doesn't go far enough for me (the book I probably wanted was Extending and Embedding Perl by Jenness and Cozens, published five years later), but I would have been up and running with basic XS much faster by starting here. If this were 1997, or even 2000, I would probably recommend this book, albeit with a few caveats. Higher Order Perl is the place you should go for discussion of closures, rather than here (although of course it didn't exist then). I wasn't fond of string eval even in 1997, and I still think it produces code that, while efficient and quite powerful, is horribly difficult to understand. And the introduction to modules is adequate but not compelling; most other introductions to object-oriented programming and module construction in Perl are better. But even discarding those chapters (and the mostly unnecessary Tk reference), there's a lot of great material here that would have been quite helpful in 2000. Unfortunately, this is not the sort of technical book that ages well, and while I did pick up some useful background knowledge and a much better understanding of typeglobs, I mostly read this book because I wanted to salvage some knowledge from a book that sat for far too long on my shelves. There's really no reason to buy it today. If you run across it in a library, there are a few chapters that are still worth reading, but by and large if you know enough Perl to know where to be careful of landmines due to changes in Perl since the book was written, you also know enough Perl to not really need this book. Rating: 5 out of 10

27 May 2013

Michael Stapelberg: Results of the Debian systemd survey

A week ago, we started the Debian systemd survey. The goal was to figure out a few trends and answer the following two questions:
  1. Do our subjective impressions from the discussions on debian-devel reflect the general sentiment about systemd?
  2. What are the main concerns that most people have?
Thank you all for your participation! General I am happy to tell that 2113 people had a look at the survey and 573 people actually participated. Of those, 45.7% said they are a DD, DM or otherwise maintaining packages. 74.5% said they actually booted and used a computer running systemd. With regards to having systemd in Debian at all, not necessarily as the default init system, answers are as follows: 43.9% said they personally want systemd as the default init system in Debian, while 32.2% don t want that. The remaining 23.7% don t know yet. Top concerns About 50% of participants provided one or more concerns. Evaluating this part of the survey is obviously the hardest, since the answers were provided as free text. I tried categorizing the feedback into a few buckets. Each bucket comes with a number which is a weighted (!) count, i.e. the top concern counts 3 times, the second concern counts 2 times and the last concern just once. If you cannot find your personal concerns, that is because those which were just voiced by less then five people are not listed here. As I said, we cared about trends in this survey, not individual opinions.
  1. systemd is too complex, or bloated, or it does too many things, or has too many dependencies (weight: 217)
  2. systemd is not portable to non-linux systems, e.g. Debian/kFreeBSD or HURD (weight: 199)
  3. Debugging the boot process is harder than in sysvinit (weight: 106)
  4. I have a problem with systemd upstream and/or Lennart in particular (weight: 87)
  5. systemd violates the UNIX philosophy (weight: 35)
  6. I dislike binary logs and/or the journal in general (weight: 30)
  7. systemd is too new, still untested, unstable and experimental (weight: 24)
  8. I cannot find enough documentation in general or about the transition from sysvinit to systemd in particular (weight: 20)
  9. People need to learn new commands/how the new system works (weight: 20)
  10. I don t know what problems systemd solves and/or have no problems with sysvinit currently (weight: 19)
  11. I think the configuration is binary and/or the configuration format is weird (weight: 13)
  12. systemd s code is not good (memory leaks, performance problems) and/or upstream s development lacks best practices such as long-term stable branches (weight: 9)
  13. There are problems with systemd in Debian (e.g. Debian-specific extensions to /etc/fstab not supported, system doesn t boot) (weight: 9)
  14. Customizing the boot is harder than with sysvinit (weight: 8)
  15. systemd is not compatible with sysvinit (weight: 8)
I realize that the choice of buckets is somewhat broad and there are many different, finely nuanced opinions out there. Again, this is for seeing a trend, not accounting for every single individual opinion. In case you strongly believe that I did something wrong when evaluating the survey results, please contact me and we can work something out. Conclusions/Actions I know this is a controversial topic. Please don t start yet another systemd discussion on debian-devel. We, the systemd Debian maintainers, will try to come up with good answers to all listed concerns and communicate them in a friendly and concise way soon. Furthermore, we have recognized the need for more documentation/information about how things are supposed to work with regards to the transition (and systemd in general) and will address that, too. Raw questions/numbers
Total records in survey: 573
Are you a Debian Developer (DD) or Debian Maintainer (DM) or otherwise currently maintaining Debian packages?
262 Yes
311 No
Did you ever boot and use a computer running systemd? It does not matter whether that computer was running Debian or a different operating system.
427 Yes
146 No
What is your general sentiment towards having systemd in Debian (not necessarily as default)?
358 I welcome systemd in Debian, everything is fine.
 81 I am not sure yet.
 46 I don t care.
 88 I don t want systemd in Debian.
Would you personally want systemd as the default init system in Debian?
252 Yes
136 I don t know
185 No

Daniel Pocock: Upstream packaging and Debian: Drupal third-party libraries API

Many large, successful, de-centralised software projects have a suite of their own packages maintained with their own platform-independent tools. Typical examples are Drupal's collection of module and theme packages, the R Project packages (CRAN) and the Central Repository for Maven packages (Java). In the case of Drupal:
  • Debian only really packages the core Drupal system and not the modules and themes
  • Gunnar's dh-make-drupal can easily Debianize many of the modules from Drupal's collection
  • Drupal has strict rules about the contents of packages distributed from their official collection. In particular, they must all be 100% compatible with the GPL v2 or later.
  • Another rule that is particularly exciting for Debian is that Drupal's hosted modules may not duplicate code (particularly JavaScript) from other projects/repositories: everyone installing a module must download and unpack the required JavaScript, often adding many steps to the module installation.
This is a particular opportunity for Debian to demonstrate it's strengths. Debian's pkg-javascript team has been busy packaging a huge collection of popular JavaScript libraries in a 100% free manner that guarantees adherence to the Debian Free Software Guidelines. This means that they have already done a lot of the groundwork to weed out minified (obfuscated) code that isn't accompanied by readable source code and ensure that there is a mechanism for conveniently and promptly distributing security fixes. The Drupal Libraries API module has now been packaged for Debian and is available in the unstable archive. The goal of this package is to facilitate the automated use of Debian's high-quality JavaScript packages to fulfill the dependency requirements of Drupal modules. Exact details of how these components fit together is currently explained in the README.Debian file distributed in the package. People packaging JavaScript for use by Drupal modules need to consider making a small glue' package to help Drupal's Libraries API discover the JavaScript. In many cases the glue package needs to do little more than creating a symlink from /usr/share/javascript to /usr/share/drupal7/libraries - this process can also potentially be automated by a future version of dh-make-drupal

24 May 2013

Yves-Alexis Perez: Xfce 4.10, part 2

This is an update on the Xfce 4.10 transition to unstable. Most desktop components have been uploaded, built and installed to the archive. We're now currently building and uploading the various goodies, and especially panel plugins. There's a lot of them so it takes some time. Once we'll have finished to build and upload all the goodies, we'll ask for binNMUs on the packages which don't need a sourceful upload but need to be rebuilt against libxfce4util or xfce4-panel 4.10. You can follow the transition status using the release team page. In any case, please be patient while we upload all the packages. Again, no need to report installability issues in unstable for now, we are aware of it and don't need more warnings. We'll fix the fallouts in due time.

22 May 2013

Lisandro Damián Nicanor Pérez Meyer: Debian/Ubuntu packages caching and mobile workstations

Not so long ago I read Dmitrijs' blog post on how to configure apt-cacher-ng to advertise it's service using avahi. As I normally use my laptop in my home and at work, and both networks have apt-cacher-ng running, I decided to give it a try.

I have been administering apt-cacher-ng for three networks so far, and I really find it a useful tool. Then, thanks to the aforementioned blog post, I discovered squid-deb-proxy. I don't use squid, so it's not for my normal use case, but some people will surely find it interesting.

But I found it's client package to be really interesting. It will discover any service providing _apt_proxy._tcp through avahi and let apt use it. But then the package wasn't available in Debian. So, I contacted Michael Vogt to see if he was interested in putting at least the client in Debian's archive. He took the opportunity to upload the full squid-deb-proxy, so thanks a lot Michael :-)

I then filled a wishlist bug against apt-cacher-ng to provide the avahi configuration for publishing the service, which Eduard included in the last version of it. So thanks a lot Eduard too!

tl;dr
You know only need apt-cacher-ng >= 0.7.13-1 and avahi-daemon installed on your server and your mobile users just need squid-deb-proxy-client. Then the proxy autoconfiguration for apt will just work.

One again, thanks a lot to the respective maintainers for allowing this into Jessie :-)

Gotchas
Yes, there are still some rough edges. On one of the networks I'm behind a proxy. While configuring my machine to use apt-cacher-ng's service as a proxy trough apt.conf, apt-listbugs would just work. But now, using the service as discovered by squid-deb-proxy-client, apt-listbugs just times out. Maybe I need to fill some other bug yet...

Keith Packard: Altos1.2.1

AltOS 1.2.1 TeleBT support, bug fixes and new AltosUI features Bdale and I are pleased to announce the release of AltOS version 1.2.1. AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based micro-controller firmware and Java-based ground station software. The biggest new feature for AltOS is the addition of support for TeleBT, our ground station designed to operate with Android phones and tablets. In addition, there s a change in the TeleDongle radio configuration that should improve range, some other minor bug fixes and new features in AltosUI AltOS Firmware Features and fixes There are bug fixes in both ground station and flight software, so you should plan on re-flashing both units at some point. However, there aren t any incompatible changes, so you don t have to do it all at once. New features: Bug fixes: AltosUI Easier to use AltosUI has also seen quite a bit of work for the 1.2.1 release. It s got several fun new features and a few bug fixes. New Graph UI features: Other new AltosUI features: Bug fixes:

Next.

Previous.