Search Results: "ema"

18 April 2007

Meike Reichle: Blog Birthday

I recently read through my blog's archive and guess what, today is its official second birthday! :) Its very first post was exactly two years ago and dealt with the upcoming LinuxTag. Thinking back, this blog has come a long way: from a simple list-like page without any navigational elements in my student webspace (constantly being in trouble with my 20Mb quota), to my first forays into php, to a rather horrible nested tables fest hosted on a friend's server, to today when I finally got my own server and domain and returned to simple handwritten html + css and blosxom. Its choice of content has mainly remained the same though: Debian, uni, personal life and the the occasional rant when there was nowhere else to complain ;)

Biella Coleman: The Importance of Celebration

Recently a Debian user left a really nice note letting me know “It makes
me happy and proud to learn that boricuas are Debian developers! (Hopefully you are not the only one). This is for me the best Debian News since Etch released. Proud and happy for you.” Here I have to confess, however that I am neither a DD nor really a true Boriqua. I have studied Debian for many years, but have never officially joined. In terms of PR, none of my family is originally from there as my father is Jewish American and my mom was born in Russian, wandered as war refugee for many years in Europe and eventually landed in Venezuela, where I was born. But I have made my home in PR for many years and do consider it one of my many homes. Speaking of many homes, I also feel, even though I am not a DD, that Debian is an important touchstone in my life. It reminded me of a conversation I had with Manoj recently related to this topic, who almost mistook me for a DD: [biella] who is that DD that wrote an anthro thesis on debian? [08:55]
[biella] he is brazilian [manoj] I was gonna say that the dd who did an anthro thesis on debian
was you, then it struck me that you are not a dd, but I still
think of you as one now, and then it struck me further that
making you a dd might compromise your postiion as an observer After many years following the project, I have grown quite attached to it, and every year, a few months before Debconf I am reminded of this attachment. I have managed to make Debconf only every other year, and usually when I face this fact, a sense of melancholia and slight sadness sets in, especially when I hear of everyone making plans to go. I always start to question my decision to stay back, then hit all sorts of websites for cheap tickets, and start to wonder if I can perhaps manage to complete some work there, which is the main reason this year I am staying away. I then make myself confront REALITY and remind myself that the whole reason I love attending Debconf is because of its extreme vitality, which after a week, leaves you wrung out and tired, because you put so much of your attention and mind, soul and heart in the events. So even if I go for a week, or longer, you usually need a week ore more to recover. I am not sure I can spare such time this year, especially since less than a month after Debconf, I am packing my bags and moving back to the east coast of the United States. And as I learned last year and the year before and two years before, these sorts of long-distance moves take a lot of your time. My longing reminds me of how important it is to celebrate those things in life you love. And while there is more to Debconf than a celebration, much of it is just that, a chance, a space, a place by which and where you celebrate. And since I sit only in the shadows of Debian, I imagine the pleasure and joy runs deeper and wider for those who sit at its heart. So if you are on the fence on whether to go, this is your friendly public service announcement that it is, indeed, so worth your while.

Jordi Mallach: Debian's GNOME 2.18: are we there yet?

The short answer is no, but as our status page easily reflects, there has been lots of work going on during the last two weeks, once etch's release unblocked the way to upload new versions to unstable. This post intends to resume the trend of updating on the status of GNOME in Debian, after we ended up deciding we'd ship etch with 2.14 for a number of reasons, most notably some complications with the GTK 2.10 transition at that time. You'll be able to find other related news items in Debian GNOME team's website. What has the Debian GNOME team up to during the last 6 months? Our first priority was to focus on unstable's GNOME 2.14 packages again, in an attempt to fix any outstanding remaining bugs from our packaging, and get them in the best shape possible to deliver a polished GNOME desktop for etch. I think the result is really good, and Debian's default GNOME desktop is both very usable and attractive. In parallel, the preparations for a complete set of GNOME 2.16 packages continued in our Subversion repository and kept appearing, little by little, in experimental. The most visible consequence of our 2.16 efforts translated into nobse's backport of 2.16 for etch, which can be found in the corresponding repository. And then, with etch deep frozen and nearly ready to be released, GNOME 2.18 was released, and of course the GNOME team didn't wait too much to start working on it. Our current status is looking good: the Developer Platform is already available in unstable, although buildd's are fighting the builds on various architectures. When the dust settles (GTK 2.10's landing has generated quite a big cloud; we have a list of packages that still haven't completed the GTK+ 2.10 transition), we'll be able to prepare and upload the more complex Desktop components like the panel, nautilus, evolution or control-center. Unstable users should probably be seeing daily progress on this front, so keep an eye on your package managers! Although Debian 4.0 released with an old version of GNOME, vast amounts of time and work have been invested to release it with the necessary backported fixes and enhancements. The newer GNOME versions have been available in Debian official ftp archives in very reasonable timeframes; this has only been possible thanks to the restless efforts of the (fortunately) growing Debian GNOME team members: giskard, feedback, HE, lool, np237, slomo, shaka, sjoerd, xaiki and not forgetting our incredible bug triager, svena. Thanks! On the behind the scenes department, it's a pleasure to report that Lo c Minier and Jordi Mallach very recently joined the GNOME Foundation's board of advisors in representation of the Debian Project, replacing Matthew Garrett, who has been representing us for the last few years until he left the project. Thanks, Matthew!

17 April 2007

Meike Reichle: Incommunicado

Those who have recently tried to reach me, may have noticed that at least during the day I am mostly offline at the moment. The reason for this is, that I am currenty a bit more than half through the six months I got for the final thesis of my M.A. degree, and while the first "half time" was rather easy going with mostly empirical work, preperation and planning, the second half is now much more work intensive with the actual implementation and getting the whole thing on paper. So, since the beginning of this month I've sentenced myself to a kind of "voluntary solitary confinement". In practice this means that I usually get up in the morning, have breakfast, read up on email, irc etc, pack some fruit and our largest insulating teapot and leave for the university. There I move into one of the less popular student working rooms, spread all my stuff and work on my thesis until about 6 in the evening, return home, again read up on my backlog, have dinner, watch a movie and then go to bed. Although this sounds (and in fact is) rather monotonous, it is also a very productive modus operandi, since the student working rooms are literally bare of any distraction. There are a few tables, a few chairs and occasionally someone else comes in, quietly works for a while and leaves again. Leaving my wireless card at home gives me additional protection from the three gazillion distractions the dreaded internet has to offer. I don't know yet for how long I'll keep this up, but for the moment it works quite nicely and I produce a few pages (almost) every day. So please excuse that my e-mails are somewhat laggy at the moment, and if you want to talk to me on irc or the phone, try between 19:00 and 23:00 CEST.

Masayuki Hatta: Becoming the official GNU a2ps maintainer

I've been using GNU a2ps from ancient days. I prefer to print out things prettily and read them on papers (with highlighters at hand) rather than on computer displays. You may safely say I'm a caveman. Unfortunately, the upstream development of GNU a2ps is basically dead. I know there are some promising replacements (most notably Cedilla), but the problem is, I got used to the good ol' GNU a2ps too much. It still works for me. And to make it worse, I'm a Lisp illiterate (do not throw stones at me, please). So, I finally took over the official maintainership of GNU a2ps, and now preparing a new maintenance release. No flashy new features (such as the much needed UTF-8 support), but most of easy bugs are fixed. You can obtain the current tarball: http://people.debian.org/~mhatta/a2ps-4.13c-rc3.tar.gz (I'd like to upload this to alpha.gnu.org, but GNU sysadmins don't give me the needed permission yet). Or, you might want to obtain it through the anonymous CVS:
cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/a2ps co -r a2ps-4-1x a2ps
Note that specifying the tag "a2ps-4-1x" is important. So, at least you have someone to blame w.r.t. GNU a2ps now. Please give it a try and tell me how you think (Debian packaging is underway). The a2ps mailing list is also revived, it's not yet another spam honeypot anymore. Join there if you want. Or, if you are kind enough, please join the development at Savannah.

Tag this post with del.icio.us!

16 April 2007

Neil Williams: QA logjam

Nico's post on creating RSS feed for a website page cited the Debian QA page for Orphaned packages with wrong maintainer and so I thought I'd stop by.

Turns out that the method for fixing the issues on that page is problematic. If a package is orphaned it may be because it has RC bugs. Many RC bugs are FTBFS. The way to fix the issues on the QA page is to - you guessed - change debian/control and debian/changelog then build from source.

Hmm.

Note to self and anyone else interested: When working through the QA page, check the bug reports for each package. Note to anyone more involved in Debian QA: it may be an idea to highlight such packages on the page.

How much of a problem is it that the maintainer field is wrong? Is there another method for changing the maintainer field? (Directly in the Debian records maybe?)

Biella Coleman: On the Caveat, Better than Well, and HOT Latino Bodies

So, yes these three topics, the caveat, the book Better than Well and Hot Latino Bodies are related. You just have to stick with this long post to find out why… *** As I progress slowly but surely with my book manuscript, I am really coming to see how a dissertation and book are quite different creatures. I think one of the most important and noticeable differences is that a book has a lot more short caveats and warrants than necessary in a dissertation. I think there are two main reasons for this. One of which is has to do with your committee members, the primary and (usually only readers) of the dissertation. They are a lot more prepared and adept to ingest complex ideas than lets say undergraduate students, because that is what they are trained to do and because most of them are much more familiar with your topic because they have been with it nearly as long as you have. In a dissertation you are also allowed to (and often expected) to go on and on, ad naseum, with your theoretical explanations that help substantiate what are otherwise shakier, initial claims. For various reasons, for a book, especially if you are not some FFT (Famous French Theorist), you are strongly encouraged to dump most of the theory in favor of providing a streamlined version (which really, is preferable of course, but extraordinarily hard to pull off). I have been thinking a lot of the caveat because I have just finished re-reading a book Better than Well that is not only fascinating in its own right but brings the caveat to a stunning art form. The author, Carl Elliot, is a philosopher/bio-ethicist and the topic of the book, broadly speaking, examines how the rise of new enhancement technologies (prozac, plastic surgery, sex change surgery) is bound tightly with longer-standing, distinctly American ideals, such as the autonomous, self-directed and authentic self. It is one of those rare books that can be read by your father, aunt and uncle, tossed over to a willing teenager, and assigned in all sorts of college courses and still manage to impress all sort of academics in all sorts of fields. Part of the reason for his broad appeal is because the book is thoughtful and clever and so chock-full of really interesting examples that you are hooked and want more of his tasty intellectual Kool-Aid. So while he has one main focus, which largely triangulates between enhancement technologies, selfhood, and consumerism, in the process of exploring them, you learn about a bunch of other really neat topics: suburbia, the history of cosmetics and childhood, odd social phobias, long-gone and culture- bound disorders like dissociative, fugue, amputee wanabee’s, extreme blushing, and so much more. Along with crystal clear writing, he also throws in some classically funny lines, my favorite one currently being: For better or worse, suburbia has come to stand for something than can be survived only with minor tranquilizers. Another reason he manages to pull this Houdini-like feat is because of his judicious and artful use of the caveat, which is really the only way he can bring forth complex ideas, in a fashion that is much more accessible than is usually done in a purely academic book. To take on example, when he introduces the usefulness theories of Thorstein Veblen, an economist usually known (and only barely), by academics, he opens in the following way, because in many ways, if you just decided to pick up a copy of Veblen, his style make strike outdated:
Reading Veblen nearly a century after he wrote The Theory of the Leisure Class, it is not easy to know which parts of the book to take seriously. It comes off as equal parts intellectual theory, social satire, and crackpot polemic, (and goes on for a full more paragraph) and then says Where Veblen is prescient, however, is his sense that in a consumption economy, consumer goods would become markers of who we are. p. 103
In this way he can say, ok Veblen is useful because of this specific reason” and yet communicate to his academic readers that he knows the limits of Veblen. No matter how much I love the book, and now matter how I think his use of the caveat is stunning, there are two problems I have with it. In one case, I think he fails to give one of the most important caveats. He paints a picture in which all of American society is ensnared in dominant social codes and mores (which somehow all point back to consumerism and capitalism and a desire to improve the self). While there are points he seems to back away from that sort of statement, and a few rare points where he ascribes his insights to the group I think he should mainly be sticking to white, liberal-leaning middle-class Americans I think there are more instances where he paints a picture of America as far more uniform than it actually is. According to his account, no one is immune to the forces he so eloquently writes of and so in the end the environmentalist activist, is as caught up in the traps of consumer life-style as is the investment banker on Wall Street. It lead hims to say such statements as
Many Americans today learn who they want to be by listening to a Methodist minister or a civics teacher but by watching advertisements for The Gap.
Ok while he bit about the civics teacher may be true, any consideration of lets, say… the religious right in this country, which, as we know from recent elections, don’t represent a teeny-tiny itsy-bitsy minority (and for a fascinating glimpse into the world, I would recommend Jesus Camp), would bring holes, and sizable ones, to that sort of statement. Many Americans do in fact listen to their minster. And this does not only help explain the deep divisions in this country, but I bet because they do listen to their pastors, their notions of the good, the self, etc, are going to be pretty distinct from those he describes (and gain see Jesus Camp to get at this point) It is not that the religious right exists outside of the web of consumerism we are all at least partially caught in, and indeed, a lot of the new Protestant religious movements here and elsewhere as Jean and John’s Comaroff’s work has shown can be all about securing a more robust middle class lifestyle. But we must remember that even something as powerful as consumer capitalism or dominant ideals of an authentic, beautiful self though powerful and more often than not work in concert with each other do not quite have the power to efface all meaningful difference between lets say a white, liberal middle class woman and let’s say, many Latinos, who, do, let’s not forget, comprise a huge portion of America. Many Americans have a very different picture of the ideal female body than the picture he explores, which is skinny and lanky and forever youthful (and hence the appeal of botox and lipo). Let me provide just one example drawn from the annual Puerto Rican day parade and this hold true for the one held either in NYC or Chicago. Along with a blizzard of Puerto Rican flags, what you may also notice is the abundance of really bright spandex being donned on ladies that are not by any standard of the word slim. I am sure that any middle class lady (you know, the type who spends 5 days of the week working out at the gym, wishing her thighs were just a little thinner), would feel morally repulsed in seeing that sort of image, that is if they even bothered to go to the parade. But among many Puerto Rican men (not all) a sexylicious and extra-curvy, meaty Puerto Rican woman, decked out in tight & bright spandex, will like bring on a loud HAY MAMITA, ven ac ”………………… which roughly translates into You are HOT… Like I want you NOW. (more…)

Jonathan McDowell: In search of a HDTV PVR

As mentioned in the past I got a new TV this year. It's an LG 32LCD2DB with a native panel resolution of 1366x768. As well as the usual SCART/component inputs it has VGA and HDMI. Currently my homebrew PVR outputs to the TV via a full featured DVB card with onboard MPEG2 decoder, but this limits me to 720x576 output and a basic OSD. My current box is a PIII-800 with a basic onboard SiS graphics chipset, so it's not got the grunt to drive the TV directly itself. I'm thus on the lookout for an upgrade. Let's start with my constraints. I have a Silverstone LC-02 case. I'd previously planned to upgrade to something bigger, but the discovery that LinITX can provide a variety of riser cards to suit PCI-E/PCI as needed means I don't have to. The LC-02 will take a MicroATX board and provide me with 2 slots, one of which is taken up by the PCI DVB card. This box lives in my living room, so it needs to be quiet - the current incarnation is a bit too loud but I believe that's mainly due to using a standard heatsink+fan assembly, so I'm hoping that something specifically designed to be quiet will be better. An lirc dongle and wireless keyboard/mouse are already sorted. I'd like to expand the use of the PVR to be a more general PC as well; up until now it's just been a PVR, but being able to check email/IRC would be nice, as would the ability to play games. Up until now I've run VDR, which takes full advantage of the MPEG2 decoder, but I'd like to give MythTV a decent try. All of this points to wanting more than just a HD hardware MPEG2/MPEG4 decoder. First lets start with the graphics chipset options. The contenders seem to be ATI, Intel, nVidia and Via. From my reading ATI lack any form of XvMC support in both their Free and binary blob drivers, so we can discount them. nVidia have support, but only in their binary drivers. The Nouveau project have support on their TODO list, but I can't see any sign of it yet. I'd really rather avoid non-free drivers, so that leaves us with just Intel and Via. I really like the look of the Intel G965/X3000. They've opened up their driver development and it seems to be quite active from reading the Xorg mailing lists. However they don't have any XvMC support; Keith Packard on the xorg list in February says "For media purposes, the current drivers aren't taking full advantage of the hardware yet", though later on does say "XvMC is on several of our lists; I don't know when someone will pick it up and implement it". Unfortunately I get the feeling it's not a high priority; I've seen/heard several comments about the fact that any processor that'll get hooked up to this chipset will be more than fast enough to cope without the assistance. That may be true, but I don't want my CPU to be spending all its time trying to decode MPEG2 or MPEG4 at 1920x1080i while the GPU sits mostly unused. I'd much rather the GPU was used to the full giving me spare CPU cycles, or perhaps the ability to clock it a bit slower for common use cases, reducing power and heat. I'm keeping Intel on my list because I hope they do get round to proper support sooner rather than later. They've also talked about the fact the GPU is programmable which would make it perfectly possible to add MPEG4 acceleration to the chipset; that would be pretty sweet. It's a bit odd to end up with Via on the list. I mainly think of them as associated with MiniITX boards, but they do also produce various motherboards for Intel/AMD CPUs with integrated graphics. They managed to shoot themselves in the foot for a period of time by limiting the maximum accelerated resolution to 1024x1024, but recently they've released the CX700M /P4M900 chipsets which appear to do 2048x2048. The OpenChrome project have these up and running to a basic level from what I can tell, but work on XvMC support appears to be progressing with various patches and reports flying about on the list. So currently it looks like Via has the best option (albeit through the Free software community, rather than a concerted effort on their part), while Intel has something that could be very appealing if the driver was more complete. The other factor is the CPU. 3 contenders this time; AMD Intel and Via. My current PIII-800 is rated at 20.8W TDP. Modern processors are in general a lot hotter, but I need to keep in mind that I'm looking for a quiet machine, and that the case doesn't have a huge amount of room for big cooling systems. AMD's dual core chips all start at 89W or more, though some of their single core lower end CPUs are more like 67W. Of course the Intel graphics won't work with it and I'm not 100% sure Via has a suitable Athlon chipset at present either (the 2 I found were for Intel/Via). Intel's P4 offerings aren't much better for power consumption, with many of the highest end chips being over 100W. Core 2 Duo looks promising; 65W, so more than the current CPU, but a lot more grunt. Via come out tops here; 20W for their 2GHz top end processor. However this is only single core and compares poorly to the equivalent clock speed of Core 2 Duo. A MiniITX board with a 2GHz C7 and a CX700M would probably make a fine PVR, but I'm not convinced about there being enough grunt for anything else. The Via chipsets appear to have more active in-progress support for media acceleration, which suggests a P4M900 + Core 2 Duo. That's contrasted with what looks to be the more powerful X3000, that actually has a manufacturer who seems to want to get full Free support out there. I'm probably a couple of months off actually making a decision; partly because I want to watch how it all plays out in the hope that the Intel chipset will get some more support, or that the Via chipset will be proven to be reliable in operation. And assuming I do make a video chipset/CPU decision I then get the joys of trying to find a motherboard with DVI + SP/DIF. I know the G965 can do DVI out with an ADD2 card in the PCI-E slot, but I don't know if the P4M900 supports the same thing. I can't see an Intel MicroATX 965 board with SP/DIF out - there's an HD audio header, but this doesn't seem to be a direct mapping. Can I get a converter?

Biella Coleman: Wikitravel in Puerto Rico

Wikitravel has organized an informal trip to Puerto Rico and I am of course reading the Puerto Rico blog entries as they are posted. Here are my suggestions for what to do there, which I passed over to them. One day I will update it and spend more than half an hour on the writing. I am eager to see what they say. I love the island but know that it can be a little hard to travel in, unlike let’s say some tropical paradise like Thailand. It is just a little too formalized and expensive perhaps and you need to know a lot since there are not droves of informal travels to tell you that sort of information. But it is a neat place with lots to do. I wish them happy and safe travels.

Ian Murdock: First impressions (or: is every Fortune 500 company like this?)

It’s been a crazy few weeks. I’ve heard the phrase “drinking from the fire hose” many times, and while I’ve never actually tried to do that, I suspect the experience is something like this. I’m having a blast though. A few quick first impressions:
  1. First things first: The lead up to the announcement was remarkable—not at all what I expected from a big company. As Jim Grisanzio pointed out, the PR people did a great job coordinating everything, but the bloggers were very much in the lead here. In fact, I was given so little (OK, no) guidance on what “the message” was supposed to be that I sent a draft of what I was going to post to Jonathan, and he replied, no one is allowed to run their posts by me, just speak your mind, that’s what we all do. The message: Sun really is as transparent as it appears from the outside perspective.
  2. In the other direction, the people here are not only open to the outside perspective, they want to hear it. That’s a big part of the reason I’m here now. Solaris has lost a lot of developer mindshare to Linux over the past 5-10 years. There are important lessons to be learned from that, and we (yes, I feel like it’s “we” already) are intent on doing just that.
  3. Maybe it’s just the people I’m working with, but this place feels like a startup. There’s a lot of positive energy, a real sense of urgency, and people genuinely seem to love what they’re doing. The difference: It’s a startup with actual resources. You know, like 30,000+ people. A potent combination indeed.
Regular blogging should resume shortly.

15 April 2007

Russell Coker: failure probability and clusters

When running a high-availability cluster of two nodes it will generally be configured such that if one node fails then the other runs. Some common operation (such as accessing a shared storage device or pinging a router) will be used by the surviving node to determine that the other node is dead and that it's not merely a networking problem. Therefore if you lose one node then the system keeps operating until you lose another.

When you run a three-node cluster the general configuration is that a majority of nodes is required. So if the cluster is partitioned then one node on it's own will shut down all services while two nodes that can talk to each other will continue operating as normal. This means that to lose the cluster you need to lose all inter-node communication or have two nodes fail.

If the probability of a node surviving for the time interval required to repair a node that's already died is N (where N is a number between 0 and 1 - 1 means 100% chance of success and 0 means it is certain to fail) then for a two node cluster the probability of the second node surviving long enough for a dead node to be fixed is N. For a three node cluster the probability that both the surviving two nodes will survive is N^2. This is significantly less, therefore a three node cluster is more likely to experience a critical second failure than a two node cluster.

For a four node cluster you need three active nodes to have quorum. Therefore the probability that a second node won't fail is N^3 - even worse again!

For a five node cluster you can lose two nodes without losing the cluster. If you have already lost a node the probability that you won't lose another two is N^4+(1-N)*N^3*4. As long as N is greater than 0.8 the probability of keeping three nodes out of four is greater than the probability of a single node not failing.

To see the probabilities of four and five node clusters experiencing a catastrophic failure after one node has died run the following shell script for different values of N (0.9 and 0.99 are reasonable values to try). You might hope that the probability of a second node remaining online while the first node is being repaired is significantly higher than 0.9, however when you consider that the first node's failure might have been partially caused by the ambient temperature, power supply problems, vibration, or other factors that affect multiple nodes I don't think it's impossible for the probability to be as low as 0.9.
echo $N^4+\(1-$N\)*$N^3*4 bc -l ; echo $N^3   bc -l
So it seems that if reliability is your aim in having a cluster then your options are two nodes (if you can be certain of avoiding split-brain) or five nodes. Six nodes is not a good option as the probability of losing three nodes out of six is greater than the probability of losing three nodes out of five. Seven and nine node clusters would also be reasonable options.

But it's not surprising that a google search for "five node" cluster high-availability gives about 1/10 the number of results as a search for "four node" cluster high-availability. Most people in the computer industry like powers of two more than they like maths.

Christian Perrier: Back on shadow

Today, Nicolas "nekral" Fran ois and I spent some time on the remaining issues of the shadow package. As the package is part of the base system, it was frozen for a while now. Thankfully for us, our upstream was nearly inactive in the meantime (no new version) and the issues reported in the BTS in the meantime were pretty minor (indeed, several of them are unreproducible, often errors in users' PAM settings). So, now we're back on duty to make the bug count for that package down to 0 (there are 17 opened bugs as of now). Our upstream seem to come back to life so we will probably do our best to lower the size of the Debian diff.gz file which raised again in the last months of the sarge->etch release cycle.

14 April 2007

Ben Hutchings: ACCU Conference

I've been meaning to attend the ACCU Conference for some years and finally decided to pay my own way for a couple of days this year. It was an opportunity to hear world experts on C++ and other programming topics and to a smaller extent to meet and socialise with other professional programmers. I attended the following sessions: Keynote: Improving Collaboration in Open Source Projects, Mark Shuttleworth This was a somewhat surprising choice of speaker and subject since I think most attendees work on proprietary software, but I think any sensible developer in the proprietary world will try to build on free libraries under non-copyleft licences, where appropriate. Mark talked about governance and leadership in "open source" projects (actually praising Debian for having a clear constitution) and about the need for good communication between projects, for example about release schedules. He seems to have accepted that Launchpad cannot be a single hub, and called for standard formats for, for example, exchanging information about related bugs between bug trackers. But it doesn't sound like he's ready to take the lead on that. Choose your Poison: Exceptions or Error Codes, Andrei Alexandrescu Andrei looked at the strengths and weaknesses of various error reporting mechanisms in C++ and introduced a technique for making error handling more flexible. Normally a function is designed either to indicate errors through its return value or to throw an exception on error. If a function returns an error indicator, it's easy for callers to ignore it. If it throws an exception on error, then a caller that provokes errors more often than the called function's author anticipated pays a high cost in processing time for those errors. Andrei's solution involves a class template Likely<typename T> whose instances hold either a return value of type T or an exception. A function that can fail has a specialisation of this template as its return type. The caller can check for failure if it knows how to handle it, or it can ignore it - in which case the conversion to T or the destructor will throw the exception. This is clever but doesn't seem to be entirely satisfactory. The destructor which throws does first check that no exception is already being processed, avoiding collision of the two exceptions and consequent abrupt termination of the program, but this can result in errors being unexpectedly ignored. Introduction to Component-Level Testing, John Lakos A marathon 3-hour talk on designing and testing software, particularly C++ programs (the subject of his well-known book) as a set of well-defined components. Lakos first defined these components as being "physical" i.e. sets of source files - normally a header file defining an interface, an implementation file, and a test driver file. They may also include metadata for the build system. He talked about the value of reusable components (as if this wasn't obvious!) and the risk of introducing circular dependencies - which essentially turn many components into one and reduce reusability - if we fail to keep track of dependencies. Software built out of components can be viewed as a hierarchy or stack defined by dependencies. In a large system, components with similar dependencies and dependents can be grouped together into packages or package groups to simplify a view of these dependencies. He explained that the test driver's dependencies count just as much as the implementation's, because we cannot reasonably test a component until we have tested its dependencies. Test drivers should also be written to avoid depending on environmental settings and configuration, so far as possible. Finally, and perhaps most importantly, he spent a long time talking about how to construct test cases and test data. I might try to summarise this in a later entry if anyone's interested. The Appliance of Science: Things in Computer Science that every practitioner should know, Andrei Alexandrescu Andrei began by complaining that OpenOffice Impress was even worse than PowerPoint, but being able to use Linux (specifically Ubuntu) more than made up for the pain. He briefly presented four key ideas that he believes programmers should understand and be ready to make use of: Writing for ACCU (BoF) I think I've been convinced to write an article about standardisation of multithreading in C++. C++ Threads, Lawrence Crowl Crowl gave an overview (similar to this) of the extensive work that's been done on standardisation of multithreading in the C++ language and library. This is one of the most important features in C++0x due to the increased parallelism mentioned above. The current semantics of multithreaded programs are not standardised, resulting in subtle but potentially serious differences between current C++ implementations that support multiple threads, and in the need for assembly-language code in programs that use lockless synchronisation. Much of this is also relevant to C and is being considered by the C standard committee. C++0x Initialisation: Lists and a Uniform Syntax, Bjarne Stroustrup Stroustrup recapped the 4 forms of syntax for initialising objects in C++, some inherited from C and some necessarily invented for C++, none of which are entirely generic. He noted the lack of a simple syntax to initialise the elements of containers, which violates the general principle that class types should have the same status as built-in types in C++. He then introduced a new initialiser syntax that he and others have defined for C++0x, which is a brace-enclosed comma-separated list of values, similar to that used for arrays and C-style structures (aggregates). Container types can define a constructor with a parameter of type const std::initializer_list<T> & and when constructed with this new form of initialiser they will receive this wrapper for a constant array of element values. For types that do not, the values in the list are treated as arguments to some other constructor, if one matches. Otherwise, for compatibility, this may be treated as aggregate initialisation. C++ Standard Library report, Alisdair Meredith There was far too much information here for me to even begin to summarise. Suffice to say there are lots of good things coming bu the library committee will have its work cut out to get them all properly specified in time for the Committe Draft coming late this year.
I also met old friends and new, put faces to names from newsgroups and books, and got too little sleep.

Adam Rosi-Kessel: Google Reader is the Solution

I was a long-time hold-out user of standalone RSS aggregators (SharpReader for Windows and Straw on GNU/Linux, both of which have been somewhat stagnant over the last couple of years). I’ve finally thrown in the towel and switched to Google Reader. It was a great decision. The key factor is mobility. I check email and blogs from my personalGoogle Mobile Image laptop; our kitchen computer; my office workstation; and, perhaps most significantly for Google Reader, from my cell phone. The Google Reader cell phone app is quite good (handy “keyboard” shortcuts, efficient presentation), and allows me to catch up during time that is difficult to use for other purposes: waiting for the train, standing in line at Starbucks, on the elevator. The only real downside is the lack of offline support (although I don’t think it would take a rocket scientist to create it), but this is far outweighed by the mobile functionality. As “access anywhere” becomes more important than “offline access,” I predict we’ll see more users of all applications make this sort of switch.

13 April 2007

Sven Mueller: Init HackFest / New init systems in Debian

In his “Init followup” post, Erich posted a reference to his Debian-Wiki post about a proposed Debian HackFest after Etch was released (which would be about 5 days ago<smile />). Anyway, since that page at the wiki is protected, which means I can’t edit it, I’m posting my thoughts here. I agree with Erich and some other commentors at Gunnar Wolf’s blog post that it doesn’t make sense to add X init-script-only-packages for any daemon to support X init systems. Instead, each package containing one or more daemons should contain the meta information needed to create all init scripts. Basically, this would probably include script snippets which do the following operations: Additionally, some control information would be needed including, but probably not limited to: The script snippets listed above should allow basically any operation on a daemon, including the force-reload and try-restart commands not yet implemented by all current sysv-initscripts.

John Goerzen: And we're off!

Yesterday afternoon, we started our information meetings with employees about our Linux on the desktop project. We're underway on our migration.

But before I talk about that, I need to back up and describe what the project is.

We are converting approximately 80% of our 150 or so PC users to Linux desktops. They're Debian etch (4.0) running Gnome, Firefox (Iceweasel), Evolution, NFSv4, and SystemImager. Over the coming days and weeks, I'll be writing about why we're doing this, how we're making it happen, things we've run into along the way, and the technology behind it.

Today I'd like to start with a high-level overview of the reasons we started investigating this option.

It became apparent that Vista was going to be a problem for us. Most of our desktop PCs are not very old, but Vista meant a significant degradation in performance from the Windows XP Pro that most people were running. A performance dip so significant, in fact, that it would have created a significant negative impact on employee productivity.

We tend to buy PCs with Windows licenses from the vendor (Windows preinstalled). As such, we knew it wouldn't be long before XP-based machines would be hard to find. If we stuck with Windows, we'd be running a mixed-OS network -- which we knew from experience we did NOT want to do. The other option would be to replace all those old PCs. The direct costs of doing that, with the associated Vista and Office licenses, would have been more than $200,000.

So we started to look at other options -- changing the way we license Windows, sticking with XP for awhile, or switching away from Windows. This last option sounded the most promising.

I took a spare desktop-class machine, representative of the hardware most end users would have, and installed etch (then testing) on it. I spent a bit of time tweaking the desktop settings, making things as transparent to the user as possible. We liked what we saw and started pursuing it a bit more. We knew we had some Windows apps we couldn't discard, so we tested running them off a Windows terminal server with the Linux rdesktop client. That worked well -- and the appropriate Server 2003 licenses plus CALs would still be far cheaper than a mass migration to Vista.

To make a long story short, we are getting quite a few benefits out of all this. One of the most important is a single unified system image. Excepting a few files like /etc/fstab, every system gets a bit-for-bit identical installation from the server, updated using rsync. /home is mounted from the network using NFS (v4). So our users can sit down at any PC, log in, and have all their programs, settings, email, etc. available. A side benefit is that hardware problems become minor annoyances rather than major inconveniences; if your hard disk dies, we can just bring up a different PC. We had tried numerous times to make roaming profiles work in Windows, but never really achieved a reliable setup there -- perhaps because it seemed virtually impossible to assure that each Windows PC had the exact same set of software, in the exact same versions, installed.

More to come.

Daniel Burrows: coq's -ness-nesses

In response to Stefano's reply to my post about Coq:

toy-ness

Usually such pieces of software are more seen as academic toys, seeing it promoted as a geeky software is a joy to me.


I really hate to detract from your happiness -- but I definitely had the word "math" implicitly stuck before "geek toy". :) Most coders that I've met are, at best, indifferent to mathematics, outright hostile at worst, so I doubt that coq will get far outside of small niches where the benefits are irresistable (security software, maybe? -- and of course pure math). I read up on this stuff despite it being utterly useless for anything I'm likely to be paid to do (unless I return to academia) because I'm a hopeless weenie loser who likes math. :P

programming-language-ness

Coq is not really a programming language (even if the CoqArt book says so, to attract the developer community), it is mainly a proof assistant; i.e. a software in which you give definitions, state theorems and prove them.


Well, this all depends on how you define programming language, which is one of those never-ending definitional questions. But using my general conception of what a programming language is, I actually have noticed two programming languages inside Coq.


  1. The more interesting one (IMO) is the proof language they call "Gallina" and the "Vernacular", in which you construct proofs by reducing your goal to a tautology. The goal here seems to be to compute a well-typed term in Coq's core calculus, and you generally construct programs interactively: Coq shows you the current program state (expressed as one or more goals and a set of local hypotheses) and you manipulate it by (e.g.) applying lemmas to yield new known facts.

    I think this language is fairly weak viewed as a programming language. It's completely unreadable and the proofs generated don't correspond to the reasoning process one normally follows when working out a proof. I am less annoyed by it now that I've learned how to do forward reasoning :), but it seems like backwards reasoning is really pushed, and that just seems .. well .. backwards to me. There's also a strong tendency to use implicitly generated names for things and to just "know" what the state of the system after issuing a command will be; as far as I can tell, the only way to understand a Coq proof is to step through it in coqide.

    While it's nice to be able to "trust the kernel", it would also be nice to be able to "read a proof" directly. Among other things, their inscrutability makes me think that Coq proofs would be annoying to maintain over time. This is not necessary for stuff that's part of Principia Mathematica, but seems likely if you're developing a new theory -- in particular, I would shudder (theatrically) at the mere thought of including embedded Coq proofs in my programs.

    Some additional brief comments on this were written by Nick Benton and put on the Web under the title of Machine Obstructed Proof.

  2. The other sense is that Coq directly embeds a strongly normalizing variant of System F (I think? -- at least the simply typed LC with some type parametricity) with primitive recursion over inductive structures. This isn't Turing-complete (of course!), but I would certainly call it a real programming language.

    As you note, though, this is less interesting unless you want to prove facts about your programs.


OCaml-ness

Regarding the synergy of Coq with OCaml: yes, you can prove in Coq the correctness of OCaml program, but actually not more than you can do with programs written in other programming languages


I was specifically thinking about Concoqtion; I have no idea how other projects compare, and I apologize if I incorrectly summarized it!

Erich Schubert: Init followup

Gunnar Wolf commented on my recent series of init script posts. Thanks for the feedback.The thing is that I've been doing a lot of Debian stuff these days (such as our GSoC coordination, and lots of stuff you saw in this blog). But I shouldn't... instead I should be trying to finally get my diploma thesis done.I had my exams last july. If I had been focused, I could have been finished with my degree last christmas. Now it will likely by this fall. :-( All that is remaining is my final thesis. It should be written in 6 months, but I still havn't submitted my topic yet. So if you are wondering what took me 8 months already: I investigated two topics, but they didn't work out. Then I started researching for my 'current' topic, and I have a vision for it, but I still havn't managed to convince my professor (which of course is largely due to me not being able to convey this idea, and that the topic is in information management and representation, where it's probaly often hard to find a solid theoretical part. I have examples I'd like to do, and I hope they are actually convincing, but I have no idea how to 'prove' something here; it's too much about social aspects and human perception I guess, and I'm not really qualified or capable to do solid research in that field.)(And as you can probably imagine, I'm pretty fed up with studying now. A year ago, I'd have considered to go for a PhD afterwards, but now I just want to get out, and work on my projects.)Anyway, I got distracted. Back to the init topic.I already posted this link: Init Hackfest, as well as a pointer to the initscripts-ng mailing list. I'd really like to get this topic on it's way for lenny. So please, join this effort. While I'd like to push it, I shouldn't; on contrary, I should suspend my Debian efforts.As for your (Gunnar) suggestion on how to handle multiple inits: what's wrong with just including multiple init scripts in one package? They are not particularly large and compress well. A single init script package might already be bigger than all the init scripts.The problem is more on how to write these init scripts; by the time we're done with this project, we might actually have hit 1000 init scripts. Yes; I didn't just make up this number: packages.debian.org has 890 hits for /etc/init.d; the init-like scripts in /etc/dbus-1/event.d not included. So if just want to add support to 5 alternate init systems, this means we would need to write 5000 new init scripts. Ouch. So we maybe should convert them to 1000 meta-init-scripts instead, and generate the 6000 real init scripts from them.Please join the discussion, and lets get this project going, despite having to face such scaringly high numbers...

Evan Prodromou: 22 Germinal CCXV

A lot of people have asked me about the Tim Wu piece in Slate about Wikitravel. I've commented already about the article in Wikitravel's Logbook: 8 April 2007. The upshot: Wu got a lot of things really wrong about Wikitravel (like saying we didn't have any hotel listings for Bangkok). But if our readers get things wrong, that means Wikitravellers need to do some more work to help them get things right. User errors are developer errors writ large; we can do better. But I think Tim Wu missed the main reason Wikitravel guides will always be better than proprietary guides: they are Free Cultural Works. Where I come from, that means a lot. I wrote to Tim about his article, and he responded really kindly. The thing I liked most is that when he got home, he updated Wikitravel with the information he picked up on his trip to Thailand. That is pretty cool. I'm not taking others' responses to the article too seriously. Wikitravel got a Webby Award nomination for Best Travel Site the same week. As Tom Wolfe said, "The lead dog is the one they always try to bite in the ass." And Oscar Wilde: "The only thing worse than being talked about is not being talked about." (Thanks to Hugh!) tags:

Off to San Juan We're getting prepared this morning to head out to Puerto Rico for the first annual World-wide Wikitravel Get-together. Our flight leaves at 2:20PM, so we've got kind of a leisurely morning to get ready. As usual, we're pretty tense: what are we forgetting? And I usually get hung up on unnecessary stuff to deal with. I should probably print out the Spanish phrasebook from Wikitravel, because my Spanish is pretty rusty. And I should download all the WT pages about Puerto Rico destinations to my laptop, just to know where we should fill in. And we can't find the charger for our camera's battery. And I want to bring a certain pair of cargo pants, but there's a button missing. Do I have time to sew on another? Of course, all these anxieties melt once we get out of the house and into a taxi to the airport. Once you can't do things, you stop worrying about what you should do. I think. The more I learn about Puerto Rico, the more fascinated I am. San Juan (Puerto Rico)'s Old Town is a UNESCO World Heritage site. The giant telescope at Arecibo is world-renowned as the SETI site. The islands of Vieques and Culebra are isolated and fun, and Fajardo and Rincon has world-class surfing. My friend Biella Coleman gave me a great list of travel tips for San Juan and Culebra, which have been a big help in our planning. OK, enough blogging: gotta get to work sewing on that button. (I've been stalling long enough for Maj to have found the camera charger under a baseball hat. Yay!) tags:

12 April 2007

Biella Coleman: On My Aunt Enid, Cars, and History

Those who know me even moderately well (as well as every doctor I have ever seen), knows that my real first name as “Enid.” That is the mysterious E. that sometimes precedes the Gabriella. My mom’s intention was to call me Gabriella, the first name of some famous Italian Cabaret singer, Gabriella Ferranti. But when Enid, my aunt on my fathers side, passed away a few months before I was born, I was given the name Enid Gabriella. We have always used Biella or Gabriella but I like that I have Enid in there and have fancied from time to time to start using the name Enid. By all accounts, Enid was an amazing and energetic woman, who reared her four kids with passion, was very open to friends and family, and who, despite living a solidly upper middle class Jewish life, was also involved in interesting political work(like helping Americans doge the draft by escaping to Canada). My mom held a special fondness for her because, well, honestly I think she was one of the only members of my dad’s family who she deeply loved. And Enid always went out of her way to show her care and concern, as when she immediately went to Caracas after my mothers first child unexpectedly died of a high fever at the age of five months. Today as I was writing away, I received an email from my father that he sent to me and a bunch of cousins and other siblings where he attached a 9 page document of remembrances and memories of Enid. My dad, though in no way as bad off as my mother (health wise), is no spring chicken. And I think as he fast approaches 80 years old, he is committing a lot to writing and thus, keeping his memory alive for us. In fact, this reminded me of a really beautiful quote I recently came across on memory:
“You have to begin to lose your memory, if only in bits and pieces, to realize that memory is what makes our lives. Life without memory is no life at all, just as an intelligence without the possibility of expression is not really an intelligence. Our memory is our coherence, our reason, our feeling, even our action. Without it, we are nothing.” Luis Bu uel
But what was a little odd (but nonetheless very endearing) about most of the account is that it was not organized by stories, or date, but by car models. Yes, by technology. My dad organized the stories about Enid by virtue of the cars they had, which struck me a little strange because it is not like he was a car buff or anything (growing up we always had the most unsexy cars, like Ford Tauruses). The cars he covers are the following: The Model A Ford Convertible
The 1941 Oldsmobile
The 1948 Buick Convertible
A Chevy Convertible Once you read his little tribute, it becomes immediately clear that his choice of talking about cars is also way for him to talk about history which is my dad’s great love (he can talk to you straight for 5 hours about some odd event in WW II and why he should have become a historian) as it is about Enid. Case in point here:
This was the first General Motors car with automatic drive. It was called Hydromatic and even though this car had a powerful 8-cylinder engine, this first automatic drive was very sluggish. Forget about 0 to 60 miles an hour in 7 seconds. This was in minutes. It was the car that Abe used to teach both Enid and I to drive. We both had to have additional lessons with a stick shift car, because the driving test was only given on stick shift cars. I learned to drive in 1944, when I was 16. Enid took lessons from Abe and learned to drive in 1945 when she was fifteen. This was against the law, but the law in the name of Tom, the policeman that covered our neighborhood, liked Enid and looked the other way.
For those who care to read more (it may only be amusing to me and those few people that are into American car history), I have included all the cars and here are the main cast of characters. Ruth = My Grandmother
Abe = Grandfather
David = Dad
Enid = My Aunt, David’s sister (more…)

Next.

Previous.