Search Results: "ron"

18 April 2007

Ben Armstrong: The children of Debian

Who are the next generation of Debianists? Are they all still coming to us out of different OS backgrounds, or do we now have the significant beginnings of a home grown generation, born and raised in Debian-using families and now making their voices heard? I hope that Debian Jr. will encourage this kind of generational growth of the project. When recently I rewrote the guiding principles of Debian Jr., my vision was a Debian that children would identify as their own. I expect they will be eager to add their own ideas as they grow up with it. It was pointed out to me today that there is some evidence that this is already happening (thanks for the link, Matthew Wilcox). As for my own kids, ages 16, 15, 12, 9 and 5, only the oldest have ever used some system at home other than Debian1. They all comfortably use our Debian systems daily, discussing regularly with me what they need. This leads to filing bugs and patches on their behalf2, and inspires further development of the Debian Jr. project. So, in at least this sense, the children of Debian are already contributing members of Debian, if not voting members. The ideas of families are improving Debian for everyone. As the project grows, I expect the ways in which families will change Debian will be more significant, not only technically but also in Debian’s character.

1 Before we started using Debian in 1995, the family system was a VT-420 terminal connected to the Solaris system running our community freenet. At that time our kids would sit in my lap and play at typing into pico for their amusement.

2 For instance, I was pleased to discover the other day that my egoboo patch was accepted. That was a direct result of my kids asking me to make it work for them.

Joey Hess: tour of the Debian 4.0 CDs

A complete set of Debian 4.0 on CD and DVD consists of 292 CDs and 39 DVDs. If you've downloaded or bought all 331 discs, here's how you can throw 324 of them away. Or, how to pick the right ones to get in the first place. First, the one disc that is all you really need for Debian 4.0: The multi-arch DVD! This is the neatest disc available for etch, it can boot on x86 systems, both 32 bit (i386) and 64 bit (amd64), as well as on powerpcs. It will detect the architecture and automatically boot the right one. It contains enough software to install a nice desktop using only the DVD, no network needed. And it includes the source code to all that software on the same DVD. This DVD is perfect for giving out at conferences, or to friends, or for that desert island scenario, and it's really the only Debian disc you need. If you want a second Debian disc, I recommend the netinst CD. This disc is under 200 megabytes in size and is designed to be written to a 3" mini-CD. Much easier to carry around than a full-size CD, so it's great for those Debian installs that you didn't expect. It's also a handy rescue disc (just boot with "rescue"). Four other CDs are of some interest, to round out your collection. The multi-arch CD has the same software as the netinst CD, but it's a full-size CD, that supports the same three architectures as the multi-arch DVD. The first CD from the CD set can install a Gnome desktop system without accessing the network and is a good general-purpose CD. The KDE CD and XFCE CD provide some choice in which desktop environment you install. Finally, one other CD merits mention. The businesscard CD is a tiny but full-featured Debian CD that can be written to a square or "hockey rink" shaped disc that is sized the same as a business card. This can be an eye-catching giveaway, if you can get the businesscard CDs produced in bulk on the cheap (if you do, please let me know). My experience with putting them in a wallet though is that they won't last more than a few weeks. If you want to have Debian installation/rescue media you can carry with you everywhere, you'll have better luck with an inexpensive bootable USB keychain. The other 324 discs are only of interest to archivists, completists, and those in certian oddball scenarios.

17 April 2007

Gunnar Wolf: Init-related ideas BoF submitted for Debcamp

Ok, so it just seems like a hot topic - I just submitted a BoF for Debcamp to talk about the init-related ideas we've been discussing. As Debconf's Pentabarf conference management system does not like disclosing talk details before the talks are accepted, I'll reproduce here my short blurb:
This BoF comes out from several ideas posted in Planet Debian by Erich Schubert, Sven M ller, Joachim Breitner, Mike Homey and myself (so far). It's not to be "chaired" by any of us particularly, but I expect an interesting brainstorming session.
There are several different init systems present in Debian - However, we are only supporting currently one of them, good ol' sysv-rc - We have close to a thousand packages providing init scripts suitable for it, and close to none for all of the other systems.
In current systems, full of hot-pluggable devices, changing network configurations and so on, however, I think this situation is quite prone to change - sysv-rc and its runlevels are better suited for stable server-like systems, and is hard to adapt for future needs.
We will talk about the potential difficulties Debian will face in order to better support more init schemes, and discuss some ideas to solve them.
This should be a brainstorming session, not much material will be prepared (maybe some sketches by each of us, but nothing formal). If you plan on attending, take a look at the messages linked to in the 'links' section.
Note that, following Nomeata's suggestion, I'm presenting this for Debcamp - If you are not attending Debcamp and are interested, we will try to set this up via some sort of videoconferencing (or at least the usual video feed + IRC feedback), and I do hope we can have something showable (at least a broken concept) after Debconf.
In not-so-closely-related topics, I just learnt there is a shadow of doubt regarding my presence in Edinburgh - I will do my best to dispell the threat. I just don't want to miss a Debconf!

Marc 'Zugschlus' Haber: UTF-8 on a shell

Dear Lazyweb, can you please explain how to properly credit a frenchman in a changelog without mangling his name? I do not consider it acceptable to use a different editor, make sure that my terminal was started with the proper environment variables set (run-time configuration does not seem to do it) before I can correctly enter non-english characters in a text mode editor. I guess I need to make the UTF-8 transition on the desktop. Are there any docs about how to do this? It is just incredibly frustrating to spend an hour on IRC just to create a changelog entry for a patch that took a minute to make and five minutes to test.

John Goerzen: Conferences Suggestions

At work, we use Linux (and Debian, in specific) for a lot of different things: everything from our phone system (running on Asterisk) to file serving and running some proprietary applications. I'm one of the people that finds, sets up, and maintains these systems, and I write code for our in-house use as well. I like to learn from others, and get to know others that may have things in common with me and with our environment. So going to conferences is a useful thing to do.

I'm hoping that some reader out there will have a good suggestion for a conference I ought to attend. Here are some that I've looked into and my thoughts on them:



My leading candidates are probably Usenix and OSCon. I'm interested to hear what people think, especially those that have attended some of these conferences.

Nico Golde: Fun with copyright

Today I stumbled over the copyright file for Debian for revoco because of an RFS (request for sponsor).

To quote from http://mentors.debian.net/debian/pool/main/r/revoco/revoco_0.3-1.diff.gz

License:
In revoco.c is written, a bonobo has written the code,
so no copyright applies.

I got the following mail from the owner of the bonobo, after asking
about the licence of the code (the mail is in German, English tranlation
follows):

[...]
English translation:

> In revoco.c it's written:
> Written November 2006 by E. Toernig's bonobo - no copyrights.
> For German law that is wrong, you have written it,

Why do you think so? It was written by my bonobo!

> so it is your copyright.

No. If any, so of the bonobo. But because the creations of animals
are not "protected" by the copyright-laws,
it is public domain (or maybe "bonoboware?).

[...]

> Would it be possible, to put revoco under the BSD (oder GPL, LGPL) licence,
> so all the Linux-users can use it?

My bonobo does not know anything about liences. If you want to
enter something for Debian, "public domain" would be the best.


Thanks E.Toernig, this made my morning :-)

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?)

Gustavo Franco: Quitting full time job, new uploads.

Just quit my full time job, (hopefully) I'll just work for them keep leading the Sacix (www.sacix.org.br) development and not also in front of a team maintaining our ISP in parallel as I was. Sacix is yet another Debian/Ltsp based distribution but unlike many others from this camp we aren't focused on education. Yes, 0-200 age range! There's GNOME by default and regular apps (including gcompris, but as i wrote, education isn't the primary goal), we're also a custom Debian distribution and we've multiple profiles (artwork and set of packages). In other words almost any community telecenter project or lab can fit over our infrastructure. Sacix has more than 100,000 end users!

Sacix was all over the place during FISL in Porto Alegre, Brazil. Three setups running and the feedback of our upcoming Etch based release called Sagui was great! Arara (Sagui-1) supported only pt_BR, with Sagui we wanted to make sure that we weren't turning the life harder for English and Spanish speakers. Unfortunately, the website is over trac and I would like to hear about sane solutions on how to handle bugs in these three languages and a good plugin to start translating the wiki pages. Comments?

Thanks Paulo for contributing with usbfloppy drivers support (yes, this weird stuff really exists), tons of tests and ideas! We've been working very hard during the last two years releasing minor stuff here and there and nobody seemed to care, when we put the pieces together they finally get it and recognize it as something. ;-) Thanks for the others contributors, you know who you are and 'Sacis' wiki article too.

Btw, I'm just having a break from a 'code merging' session with Vagrant Cascardian. New ltsp package coming soon! It will be on the pile of my recent uploads: python-gdata, pyspf (thanks ScottK) and alacarte.

Randall Donald: PHP IDE

Dear Lazyweb,

The company I work is going through a merger of sorts and the amount of our php development will probably be up. We have our Java environment working pretty good now with Netbeans and subversion in both Linux and Windows so we'd like the same features for php, specifically:

1) Both Windows and Linux support
2) Debugging
3) Not too ugly an UI ;)

Somehow I figure eclipse may work its way into this but I'm not sure I want that.

So what recommendations do you have?

P.S. I'm gonna do some NVIDIA stuff on the weekend if not sooner.

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…)

Alastair McKinstry: Looking for Planets, by Alan Boss

Looking for Earths: The Race to Find New Solar Systems is an excellent introduction book, as a scientific story of exploration and summary of the science of planetary discovery. Alan Boss is a planetary scientist and adviser to NASA on the search for extrasolar planets. He has had a front-row seat in the revolution over the last two decades that has led to the discovery planets outside our Solar system for the first time, leading to 215 known planets at last counting. The book is written in an first-person style that reflects the race to discover the first exoplanets in the 1990s. He describes historical searches for planets in the early 20th Century: the hunt for evidence of planets around Barnards Stara and the meticulous work over decades of Peter Van de Kamp, a good summary of the challenges in proving the case for planets in Astronomy, and explains the techniques used to determine other planets. The heartbreaking difficulties of proving the discovery are well expressed, as well as documenting the leaders of the field at the time. Along the way, he describes the discovery of the first Brown Dwarfs, the border cases between Stars and Planets, and the bureaucratic and other challenges involved in setting up large observatories such as the Keck interferometers capable of doing this work. This is ironic, as the first discoveries were actually made by ground-based observatories. Boss describes the race between the main teams, Geoffrey Marcy and Paul Butler of Lick observatory. The race was finally won by Michel Mayor and Didier Queloz of Geneva Observatory, who discovered the first extrasolar planet around a sun-like star, 51 Pegasi, by looking at radial velocity measurements of nearby stars. This turned out to be a close race, as the planet they had found had a short period of 4.23 days, implying the planet was what we now call a "hot Jupiter", orbiting very close into the Sun. Most teams had been looking for copies of our Solar system, looking for large planets such as Jupiter with orbits of around a decade, and had hence not started to analyse the data they had in hand, expecting to need years of measurements: examining the data showed that, had they analysed data in hand, they could have won. Looking for Earths does a good job of explaining the field of exoplanet research as it was evolving over Boss's careeer and particularly 1995-2005, with theoretical and computer models evolving as data arrived with new puzzles. In some places, the need to give a clear explanation of a topic such as the formation of planets from solar disks slows the pace of the biography, but the book does an excellent job of describing both the science and the life lived by those doing the work. Few books I've read have offered such a good summary of the field to date, along with a good bibliography and I would heartily recommend it both as an introduction to the field and as a model for science writing.

Alastair McKinstry: Measuring Power Consumption

Following a previous thread on Planet Debian (allowing for kids delaying projects, as usual), I borrowed a power meter to see what the consumption of various computers and electronics around the house was. An interesting and worthwhile exercise. Computers My main gateway system (hosting this blog, mail, etc. on a static IP) is a Pegasos PowerPC; it is on 24 x 7, and pulls approx. 60W. Other computers around the house include a Dell 2.5 GHz P4, which is my main development machine (with multiple disks, etc. onboard) pulling 72W. Downstairs, for family use we have an Intel MacMini pulling approx. 30W. Peripherals add up: on the Pegasos there is an ADSL router and a Linksys Wifi router, pulling approx. 5 W each continuously, and a UPS which consumes around 10W (I'm not sure if this is continuous, or high because its recharging a battery which was drained by pulling power plugs to measure the power usage ...). The LCD monitor upstairs (used by Pegasos and Dell) draws 20W. If I was purchasing again, I'd get a MacMini for the gateway. The current setup costs, I estimate, 7.50 Euro /month, which is probably worth it to have a 24x7 server (I'm not sure if moving to a hosting facility would be worth it, as it has advantages for running bittorrent, etc. that a remote server wouldn't, as well as being able to host content without the legal threat that a hosted server would have: with the current setup, if anyone challenges the content of stuff on my server, my ISP is not legally involved (as I host it), and hence won't (or shouldn't) pull the plug. This is worth something to me, even if I don't spend my days in court defending libel actions). One surprise was the CRT monitor used with the MacMini draws 10W when powered off, not on standby. Turn it off at the mains switch rather than the monitor button. Wall warts (chargers, etc.) draw around 1-2W due to eddies when nothing is connected. Conclusions: Swapping the Pegasos and MacMini are not an option as the family prefer the convenience of the fast start-up OS X. (This has made me think fast booting and suspend-to-disk are good priority goals for Debian.) I might however replace the Pegasos with an old pentium-class laptop, which would, at 25W, drop 40-50W as I would no longer need the UPS for 24x7 use. Put all peripherals, wall warts, etc. on a separate power strip that can be easily turned off together when not in use. TV We have a TV with the growing set of set-top-boxes: a DVD Player, Satellite unit and VCR, along with a SCART switch to connect them all together. Between them, they pull 86W. With the TV turned off, the boxes draw 20W. (TV pulls 10W on standby). I've been looking at getting an "Intelligent" mains lead, which cuts the power to the peripherals when the main item (e.g. the TV) is powered down, either totally or on standby. At nearly 40 Euro, however, it will take over a year to pay for itself. The alternative is just turning them off by hand, but of course as in most houses, the main switch is buried behind the TV cabinet out of reach. I'll swap the power strip with one with a single main switch that can be reached easily at the end of the evening instead. Other Big Users The house was designed with energy-efficiency in mind, and theres not much scope for savings elsewhere. The main users are underfloor electric heating, water heating, washing machine and dryer (condensor type). The water heating we hope to replace / augment with Solar over the summer; ditto the drier, with an outdoor shed /gazebo for drying clothes in the rainy Galway days. While the drier consumes a lot of electricity, at least the hot air is recycled via a heat-exchanger to heat the house in winter when its most used. Its worth keeping an eye on the drier and washing machine, though. We mostly use these at night, using cheaper Night-rate electricity, so while our usage patterns may not change, keep an eye on the energy consumption of these devices: as they grow old the bearings, motor, etc. begin to wear and energy consumption goes up. Look out for when to replace them. The other big niggle I have is a light fitting in the main living room. This is expensive, with 3 x 60 W spotlight bulbs in it. The kitchen, which is approx. half the size of the living room, gets lit by a single 20 W CFL. Swapping the spotlights with CFLs is not an option, and replacing it means replacing a ceiling mounted fitting: as the wires are embedded in the ceiling, moving it is not trivial. Any recommendations ?

Matt Brubeck: 15 Apr 2007

A hacker remembers This story by David Humphrey from last week really hit home:
She told about how my grandfather made his living repairing radios, toasters, fans–anything and everything electrical. He’d only received a 4th grade education in Scotland, before he had to start earning a living to support the family. She described how their entire house, with its mechanical and other systems, was kept working through his creativity and persistence. When the well pump went, he made a new one out of parts from three others…
David could have been describing my own grandfather, who died last month. I knew him as Ojiichan ("Grandpa"). A child of immigrant farmers, his formal education stopped after the sixth grade. As a young man during the internment, he took a correspondence course in radio repair, and after the war started a life-long career in electronics. He worked on electronics at home too, building projects like a cruise control for his own car. Almost up until his death at 93, he lived alone, still drove, and still flew every year to keep his pilot's license up to date. At his memorial service, his family remembered his love of tricky, hard-to-solve problems. Many of Ojiichan's children and grandchildren have grown up to be engineers, but few of us could do some the things he did. He was a lively embodiment of the hacker spirit.y embodiment of the hacker spirit.

15 April 2007

Wouter Verhelst: Belgian eID proxy code

I was recently (at FOSDEM) made aware of the fact that apart from the client-side software, Zetes also provides some server-side software to allow one to verify electronic ID card certificates on an HTTP server. I didn't know about that, since nobody ever told me about it; and none of the eID sites that I know of mention it, either. So today I had a first look at the code to see what I'd need to do to properly package it. The code does contain a few WTFs, though.
-    if (!r->proxyreq   !r->filename   strncmp(r->filename, "proxy:", 6) != 0)
+    if (!r->proxyreq)
+        return DECLINED;
+
+    if (!r->filename)
+        return DECLINED;
+
+    if (strncmp(r->filename, "proxy:", 6) != 0)
         return DECLINED;
This one is especially silly if you know that the above is the only change to mod_proxy.c. They do extensive changes to apache's mod_ssl, since that is where most of the needed work is done. The changes include the following stuff:
 #ifndef BOOL
-#define BOOL unsigned int
+#define BOOL int
 #endif
It's a boolean. By definition, that needs to keep only 2 values. The ability to set it to negative values doesn't matter. But, well; the above two could be explained by compilers having strange ideas about what should be warned about. So let's ignore those. The code should be sane then, right? Well, almost.
--- httpd-2.0.54/modules/ssl/mod_ssl.h  2005-02-04 21:21:18.000000000 +0100
+++ httpd-2.0.54-beid-proxy/modules/ssl/mod_ssl.h       2007-04-15 13:45:27.0000
00000 +0200
@@ -74,7 +74,7 @@
 #include "apr_global_mutex.h"
 #include "apr_optional.h"
 
-#define MOD_SSL_VERSION AP_SERVER_BASEREVISION
+#define MOD_SSL_VERSION AP_SERVER_BASEREVISION "+OCSP (1.0.8)"
 
 #ifdef HAVE_SSLC
   
@@ -152,7 +152,7 @@
That's okay, sure? If you change mod_ssl to include OCSP support, you may want to change its version number to reflect that? Yes, indeed. But if you set the version number like above, and spread the rest of the mod_ssl code with patches like...
+#ifndef NOOCSP
(...)
+#endif
...and...
+ifndef NO_OCSP
(...)
+#endif
... then my guess is something's wrong with your processes. Anyway. The modified SSL code for apache will be coming to a Debian mirror near you some time. But not soon.

14 April 2007

Thomas Viehmann: VoIP via SIP

Accentuation of foreign language by combination with acronyms and general technical idom. So now I can use the linphone software telephone in order to get cheaper rates for calls to a country where they speak yet another langue étrangère. The service provider only mentions kphone, but I had some problems getting the sound to work properly. Also, disabling the esound daemon esd works better than using esddsp as far as latency is concerned. Maybe I'll do a better writeup later.

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.

13 April 2007

Pete Nuttall: Cheap laughs from ars

I'm busy reading this, which outlines a concern that lots of Europeans have, which is how to comply with EU data protection laws and the US court system at the same time. SWIFT appear to be dealing with the problem, which is good. Ars then gives an example of a similar American massive surveillance system, Echelon, and how it feels the US has abused the system to catch Airbus bribing people. Now, I'm naive, but I feel that bribing people is wrong. And while two wrongs don't make a right, I'm not happy with the idea that Europe's main complaint about Echelon is that it was used to catch Europeans breaking their laws. This would be similar to UK drivers complaining about speed cameras by complaining that they catch speeders, rather than them causing accidents or being used as a way to make money. So could ars use a better example of abuse in the future, as I'm sure there must be one? Sorry for moaning, I'll return you to your normal diet of interesting stuff from DDs

Ingo Juergensmann: Should m68k drop the Debian distribution?

Debian Etch has been released lately, as you may know, and the work on Debian Lenny is already starting. For some of the DDs the work is way much different than for the rest of the DDs: the good ol' brave porters of m68k.
Stephen Marenka asked on debian-release what is needed to get back and be able to release with Lenny?
The answers are shaking:

1. To get back to testing: Basically, the release team didn't mind the
state we had with m68k in testing recently - basically, we just ignored
it, but it was still there. The release team didn't asked for full
dropping from testing, we just didn't mind either way. We also wouldn't
mind for m68k to be back in testing - as long as we can just continue to
ignore it.

2. To get released (or a realistic chance to): Basically, make sure that
the toolchain works (see the other mails), and get really fast buildds
(otherwise, the security team would probably veto the inclusion). The
second might happen with Coldfire, but - the how is your part, not ours
(i.e. if you do it some other way, that's ok as well of course).

Having said that, I can understand if the ftp-masters don't want to have
an architecture be in testing unless there is reason to believe it is
possible to include it in the next stable release, but that's not the
domain of the release team.


ad 1)
Ah, ok... as long as we are ignored, everything is fine. But how will testing m68k get updated when the testing scripts ignore m68k? Pardon me, but isn't this a little bit strange, at least?

ad 2)
Getting really fast buildds - good joke, indeed! Or is this a Friday, 13th habit like April Fools Day?

Conclusion)
Let's summarize: we can release with Lenny, when we get back in shape - but testing is needed for this, where we're ignored for. And without faster buildds for an arch such as m68k, there's simply no way back to make it into a release again - because of this.
Describing Coldfire as such a possibility for faster machine seems a little bit strange to me. CF is totally new, there's not progress yet on the CF front to my knowledge and a combined m68k/CF port may introduce other drawbacks, which nobody can predict for sure today. Do you really believe that ftp-masters or release team will allow such a port to get released? I don't.
Getting faster buildd in a reasonable amount of time is illusory for m68k. We can get more buildds online, but not "really fast buildds". Despite one older blog post of me, I'll receive just another '060 m68k soon (to be hosted by a fellow DD). A few days ago, two other m68k buildds were added to the m68k buildd rotation list. That will make 3 more buildds for the m68k.

Anyway, in most cases your first impression is the correct one and my first impression of the Vancouver Massacre/Proposal was: this is a plan to drop m68k!
Well, the lastest incidents confirm this impression, IMHO.
After all, I think that the m68k port would be best served by dropping Debian instead of being dropped by the project. The m68k port - de facto - has been dropped already. I'm disappointed.

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!

Christian Perrier: Running etch (2)

A coupld of glitches appeared lately during my sarge->etch upgrade for my home server: There are probably a few others things to tweak, still. But I had no problem with the samba server, the squid cache, the postfix settings, IMAP server, which means that the entire family can still use their computers without hassle, which was the major challenge in this migration.

Next.

Previous.