Search Results: "will"

3 November 2006

Benjamin Mako Hill: Noodles & News

/copyrighteous/images/someny_noodles-small.jpg

Someny noodles, so little time.

If you live in the bay area and you are still willing to talk to me after that pun, please get in contact with me. While it's been a while since I've been in San Francisco, I've got a flight out Saturday for the Ubuntu Developer Summit in Mountain View. I will have some time especially next weekend to hang out.

Adrian von Bidder: Microsoft and Novell

Joint press release from Novell and Microsoft. Took me by surprise, thanks for the link, Dani. Diagnosis: Microsoft is very afraid. It lost Massachusetts on the Office front, it lost M nchen on the Desktop front (financially, both cases are no big deal. But they created quite a media stir.), and Xen is the big buzzword in the server rooms, while I can't even remember if Microsoft has a similar offering... What will happen? Microsoft will remember that selling MS Office licenses, even if they run on their arch-enemy-OS, is better than not selling MS Office licenses. Dito for Xen. If played right, I think Novell might be in a very good position here. On the other hand, there are many, many companies who did business with Microsoft once and don't exist anymore. And probably Novell needs the money. Disclaimer: I can call myself Industry Analyst if I want to. Others do, and probably know less than I. Others don't but know a lot more. Update: After reading the coverage on Groklaw: Novell is a business, and it's their business decision. Maybe they end up as roadkill. And I'm not talking about the Linux market, but about Linux as a piece of software. And Microsoft officially investing in Linux technology (even with the goal to embrace and extend it) will still lead to wider Linux adaptation and the eventual breaking of the Microsoft monopoly.

Adrian von Bidder: Microsoft and Novell

Joint press release from Novell and Microsoft. Took me by surprise, thanks for the link, Dani. Diagnosis: Microsoft is very afraid. It lost Massachusetts on the Office front, it lost M nchen on the Desktop front (financially, both cases are no big deal. But they created quite a media stir.), and Xen is the big buzzword in the server rooms, while I can't even remember if Microsoft has a similar offering... What will happen? Microsoft will remember that selling MS Office licenses, even if they run on their arch-enemy-OS, is better than not selling MS Office licenses. Dito for Xen. If played right, I think Novell might be in a very good position here. On the other hand, there are many, many companies who did business with Microsoft once and don't exist anymore. And probably Novell needs the money. Disclaimer: I can call myself Industry Analyst if I want to. Others do, and probably know less than I. Others don't but know a lot more. Update: After reading the coverage on Groklaw: Novell is a business, and it's their business decision. Maybe they end up as roadkill. And I'm not talking about the Linux market, but about Linux as a piece of software. And Microsoft officially investing in Linux technology (even with the goal to embrace and extend it) will still lead to wider Linux adaptation and the eventual breaking of the Microsoft monopoly.

Maximilian Attems: Early Userspace Fun

History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.

2 November 2006

Ben Hutchings: How to fix www.royalmail.com in Firefox for Linux

The front page of www.royalmail.com displays wrongly in Firefox on Linux (though apparently not Windows). Worst of all, it is impossible to focus the input fields near the top of the page by clicking on them. However, I worked out some style rules that will fix it. These have been tested in Firefox 1.5 on Debian etch and Fedora Core 5. To apply these, you need to copy/add the following text to ~/.mozilla/firefox/profile/chrome/userContent.css and then restart the browser. Perhaps someone who knows about GreaseMonkey can work out a rule for that, which would make it easier to install them.
@-moz-document url-prefix(http://www.royalmail.com)   
  div.Content-Region    position: static !important;  
  div.Content-Region div    position: static !important;  
  div.List-Container   height: auto !important;  
  div.hpBottomWide   clear: left;  
 

Gunnar Wolf: Oaxaca on fire

Before anything else: Please excuse some grammatical mistakes I've made in this post. You should understand the topic is really upsetting, and typing while searching for links, listening to news, and gathering the basic information for a five month old conflict is not exactly compatible with me spewing out proper English ;-)
Just to re-state the obvious: Mexico is, once again, on fire. This posting is mainly written with the Debian people in mind - An important number of them, after Debconf 6, went to visit Oaxaca - In late May, during the first weeks of this incredible, stupid and scary conflict we are now facing.
I've written in my blog every now and then about our political situation. Many of us had high hopes on our current government. We thought that the authoritarian regimes were a thing of the past, we hoped for real democracy, we hoped for a government that would honor human rights and solve long-standing topics for our society - Yes, we all knew president Fox came from a right-wing party, and didn't expect much advance in the social agenda -which many of us perceive as the real problem in Mexico- but still, hoped for openness and reconciliation with the past.
I won't repeat what I've extensively said over and over - The thing is, Fox's government continues to amaze us with its stupidity, with its near-sightedness, with its hypocresy. Fox's term is really close to an end - In one more month, the govt. will change hands to the first de-facto president since Carlos Salinas (going over another story we hoped to forget).
As some of you wittnessed, there was a popular protest taking place mainly in Oaxaca - Basically, the State's public elementary school teachers demanding better payment for their work. Such a protest is already a common occurrence in Mexico, as public school teachers are among the worstly paid workers (no wonder, then, our country is still undeveloped - Make public education worse, and you have the warranty of an unprepared, ignorant population). The teachers went on strike in early May, briefly returned to classes on late June to properly close the 2005-2006 lective year, but went back on strike afterwards.
Of course, the local government (Mexico is a federative republic, each state is autonomous and makes decisions independently) took a very long time to act - and acted the worst way possible: By sending policemen to forcefully throw the teachers from their camps in the downtown streets, with no negotiation, no answer, not a drop of common sense.
That led to the formation of the (pleonasmicaly named) APPO: Popular Assembly of Oaxaca's People - A group of people, partly formed by the unhappy teachers, mainly demanding the Oaxaca state governor to step down, after he proved he is inept for his office. And yes, I'm oversimplifying here, but I don't want to dig too much - There is fortunately plenty of available information in this regard.
That happened over four months ago. APPO kept control of the city. Nobody denies that this has caused Oaxaca, a city that attracts national and international tourism like few others in the country, a great deal of economic damage - Oaxacan people are, however, still sympathetic to APPO's demands. Governor Ulises Ruiz (from PRI, the party that ruled the country for over 70 years) has not been able to be seen in public in his state for some months already. The legislative power has also been unable to work properly, and the judicial power is half-dead, doing only its most basic tasks. Renowned jurists, such as Miguel ngel Granados Chapa, have repeatedly stated that this is enough for the Federal Senate to declare the governing powers in Oaxaca have disappeared - This would put an end to the conflict, leading to immediate elections, but the Senate has denied taking this course of action. Not only that, but the Federal government took the command of the local security forces, tacitly recognizing the local government is unable to coherently excersise their authority. After almost five months, last week they issued an unanymous -but mild- exhort, asking Ulises Ruiz to consider stepping down.
So far, 15 people have been killed in the different represive actions taken, first by the local police under local command, later by the local police under federal command, and starting last week, by the federal police. Today, it seems the army is getting in the conflict as well, despite promises of not doing so by the federal authorities - Of course, they have become masters in the art of breaking promises.
Why is the federal government upholding Ulises Ruiz? Simple: After the undeniable electoral fraud we had some months ago, there are too many indicatives pointing out that our (supposedly) elected president Felipe Calder n (FeCal, as he is better known as) will have a hard time becoming the president, and many people doubt he will be able to hold the authority for the six years. So far, he has shown no better aptitude as a statesman than Vicente Fox: Instead of boldly facing the claims of fraud, he just chickened out and has spent many months hiding from the public, appearing only for selected, friendly audiences. For many months already we have heard "Ulises ya cay , le sigue Calder n" (Ulises has fallen, Calder n is next). This country has not been so badly shaken in decades - Of course, Great Statesman Vicente Fox insists the country is in peace and there are no red spots. Fox even was stupid/blind enough to state that the problems in Oaxaca would be dealt with easily and successfully, just as the problems in Chiapas and Atenco were doing his term. During Fox's campaign, he promised to solve the centuries-old Chiapas problem (that resulted in the EZLN uprising in 1994) in just 15 minutes - He just has not had time to do so. Atenco? Yes, in 2002 an angry people made him step back from the most important project of his term (a new airport for Mexico City). In May 2006, Atenco sprang again to the news because of a massive repression - I'm not going into details on Atenco right now, as it would be off-topic, but you can look at my article in FeCal.org.mx or watch a very strong video by Canal Seis de Julio (both in Spanish only) for further details.
Last Friday, however, something was different. In a repressive action, a USA citizen, the Indymedia reporter and cameraman Brad Will was killed by a paramilitary group. Even more, he was killed while doing his work, and we can clearly see this evidence on his last tape. Of course, the US ambassador issued a warning, asking the US citizens not to go to Oaxaca. And, as Lorenzo Mayer says, hay de muertos and muertos - There are different categories of dead people. A highly visible US citizen is more important than the other 14 dead Mexicans, and now the Federal Preventive Police is clashing in Oaxaca.
What should be shocking, but is not so much to those of us who know this beaten country, is the attitude of the authority when taking the city. After five months of occupation, the Oaxacan people have got used to living with APPO - be it for good or for bad. Tourism has diminished, but the people's living sources have not been attacked. Of course, as soon as the Federal Police took the downtown areas, all sorts of reports of looting have been reported. The policemen are robbing even sodas and chips, and up to TVs and microwaves. As many people state, this is a very Kafkian country.
Of course, we don't know what will come next. Most of the city has been "freed", and the APPO is holding at the University. The University is autonomous, and the PFP commands have promised not to break its autonomy - but we don't believe that. There are fights very close to the University. The Rector himself spoke a couple of hours ago at Radio Universidad, the main broadcasting point for real news on this subject (I am following on the news thanks to KeHuelga, 102.9MHz FM in Southern Mexico City, or at their webpage, from where they link to many other underground or Internet radio stations joining in the broadcast), and the reports are dramatic. Dramatic, as well, is the way all of the commercial news sources are ignoring the facts.
I want to keep you updated, as one of the very few reasons things are not worse is the public opinion and, even more, the international pressure. I'm sorry I'm not giving more links right now, but I will soon. I don't want, of course, to flood people that read my blog through the different syndications with a technical profile, so updates via my blog will be quite sparse. If you can read Spanish, we have posted many articles at FeCal, and many other individual sites are also joining in. A couple of links, and I'm off for now.

Edd Dumbill: XTech 2007 is go!

I've just published the call for participation for XTech 2007.The theme for this year’s conference is “The Ubiquitous Web”. As the web reaches further into our lives, we will consider the increasing ubiquity of connectivity, what it means for real world objects to be connected with the web, and the increasing blurring of the lines between virtual worlds and our own.XTech will have its usual four tracks: Applications, Browser Technologies, Core Technology, Open Data. Keynotes addresses will be given by Adam Greenfield, author of “Everyware: The Dawning Age of Ubiquitous Computing”, Gavin Starks of Global Cool and designers of the future Matt Webb and Jack Schulze.Head over to the call pages and submit your proposal. The deadline is 15 December 2006. The conference itself is in Paris, France, 15-18 May 2007.
ExpectnationThe publication of the XTech call is doubly exciting for me. XTech 2007 will be the first conference to be managed completely from Expectnation, the software I've been building over the course of the last year.Expectnation is a web-based system for managing conferences and training events. Right now we're conducting tests with some customers, and are working hard on readying the system for a public trial.The particular strengths of Expectnation include the management of speakers, proposals and delegates. If you would like to stay informed of our progress, there's a place to sign up for news on the Expectnation home page.

Daniel Stone: input hotplug merged to master

So, I finally merged the input-hotplug branches on master. Basically, this means that instead of attempting to hide behind one device (/dev/input/mice, the console keyboard), and hacking around it with gash and tape when we actually expose multiple devices[0], we finally expose multiple devices in a useful way. This is consistent through out the Xorg and KDrive servers; Xnest and Xvfb also have support, but that's not the most useful thing ever.

This required a huge overhaul of the old input code, much of which dates back to the mid-80s; the bits that don't were sticky-taped on the side, working more in spite of our core input code than with it. So, in addition to being generally useful and providing things like multiple keymaps on different keyboards and different acceleration (and so) on different pointer devices, it also actually caused a net removal of code.

So, once you've set yourself using evdev for the drivers, you can also now dynamically add and remove devices. Last night, not long before I released all the components, I removed all the input devices from my configuration file, told X not to add any, and added 'respeclaration --daemon' to my session: completely dynamic input. I've been using the core bits (the whole input API rework) for quite a long time, along with Zepheniah's evdev driver, but this is the first time I've been using a session with completely hotplugged input, as opposed to adding and removing devices every now and then to test the hotplug capabilities, which was actually a piece of cake, compared to reworking all our core input code to deal with devices appearing and disappearing.

Still, this all needs good desktop integration. Keyboard and mouse applets need to become aware of multiple devices[1], and allow people to configure them separately. The desktop should also take over the role currently filled by respeclaration, which works perfectly well, but shouldn't be generally deployed; management of input devices thus turns into a session management issue, which leaves the desktop to dictate policy.

There are still some nits in the D-BUS policy to sort out (right now, only root can reconfigure the devices), but I believe it's fundamentally the right model: it's machine-oriented, rather than session-oriented. There are still some minor changes that need to be made, but working out who should be trusted to add input devices was more or less impossible in the X security model.

xserver 1.3 (for Xorg 7.3) should be good fun.

[0]: Key presses/releases from your second device will just magically appear from your first device. Useful, huh?
[1]: In brief: check for inputproto 1.4 at build time, check DEVICE_CORE on whatever appears as the core pointer, and if 'iscore' is 1, then you have a virtual core pointer. Anything that sets status to 1 for DEVICE_CORE will also generate core events. Setting controls on the core keyboard or pointer will propagate those changes down to all the devices which also send core events. I'm going to document this soon.

Stefano Zacchiroli: flickr download

Flickr_download (.rb): Flickr batch downloader A while ago I decided to give Ruby a try. And of course the best way to do that on a programming language you don't know is write something in it. The result is flickr download.rb: a batch downloader of Flickr! photo sets. It handles all the stuff of Flickr! authentication/authorization via the shared secret, API key and so on (see the Flickr! API). Then, specifying the username of a photoset owner and the photoset (either by title or id) it downloads in a batch fashion the best available size of contained photos. Command line interface of course. Despite its simplicity and how useful it looks to me, I was unable to find a similar tool already available somewhere. Maybe because the usefulness of such an utility is diminished by the requirement imposed by the Flickr! API that the owner of a photoset must first authorize the tool before it can be used, but I still found it very useful to download my photos batchly ... Requirements Sample usage
$   # let's try on my Debconf6 photo set
$ flickr_download -u zacchiro -i 72157594247689892
will download 53 photos(s)
starting download of http://static.flickr.com/73/222421262_38df10594a_o.jpg ...
starting download of http://static.flickr.com/91/222420881_3b49a57f11_o.jpg ...
starting download of http://static.flickr.com/61/222420518_b2ad6ddf1a_o.jpg ...
<snip>
starting download of http://static.flickr.com/72/222392122_80b8041c47_o.jpg ...
waiting for all downloads to complete ...
all done.
$

Download

Lars Wirzenius: Debian: Something Positive and vocal minorities

R.K. Mulholland, author of Something Positive, one of my favorite web comics, writes something that seems pretty relevant to Debian:
People assume most Debian developers are heavy-handed, pushy, intolerant bigots bent of dominating any other culture or idea and supplanting it with their own whims because, for the most part, the ones who speak up the most ARE heavy-handed, pushy, intolerant bigots bent on dominating any other culture or idea and supplanting it with their own whims. It sucks. It's horrible. And it's the what everyone of any faith, political idea, or lifestyle has to deal with. People always focus on the loud minority who ruins everything. And like any other group, the only way you can combat this is making your views and, in this case, your kindness and actual testimony louder than the hateful prattle of those hurting your beliefs.
Mulholland actually writes about Christians, but I took the liberty of substituting the words "Debian developers" instead. I wonder if I should reconsider my policy of shutting up and going away when people start quarreling or otherwise behaving badly inside Debian. Perhaps participating more actively in such a situation would be helpful, if only to make it clear that those most vocal do not always represent the majority. Mostly such participation should be to do constructive things: offering solutions to technical problems, pointing out good things others do. Sometimes it would have to be to help Debian make some of the very difficult decisions it needs to do. For example, what should the project do in the case of Sven Luther? This is a good example of a problem that Debian as a project is very ill equipped to handle. I'm not sure I will do anything about this, but now that it's two hours past midnight, I feel I should. When I wake up, I expect to regret this.

1 November 2006

Simon Richter: Debian and/or Ubuntu in five years

So, the following package exists in Debian:

Package: update-manager
Version: 0.42.2ubuntu22-5

Now, what is this abomination? What does the "ubuntu" tell us? That this package was stolen from Ubuntu? That it has Ubuntu specific patches? Branding? Or that it simply is the same package that is in Ubuntu, and the maintainers saw no good reason to use a different version string in Debian? I prefer the last explanation, and believe this to be part of a greater trend. There have been a number of REJECTs because Debian simply does not have any releases codenamed "dapper" or "edgy", and people simply uploaded the package to the wrong upload queue. I believe the Ubuntu side also had a few uploads to "unstable" that their archive maintenance software could not process. Quite a number of packages are maintained by the same people in both distributions, and in most cases, it does not make sense to have packages differ at all. Even more disturbing, Ubuntu has been built for more architectures than they released edgy for, while some people in Debian are trying to reduce the number of architectures in the hope of getting towards a shorter release cycle, which Ubuntu has just admitted to be suboptimal for server installations by preparing an "LTS" release. So Debian and Ubuntu are becoming more and more alike. Now, is this a good thing, or would we all prefer that both keep a strong "profile"? And: if they are to grow together, where should we meet? I think most of us can agree on an installer with a big "expert" switch, and a lot of eye candy as long as you can deinstall it, but we'd also have to merge the respective communities, which is what I'd consider the more difficult part. Debian's NM process is quite different from the MOTU programme, and on both sides there will be "hardliners" (I consider myself one) who will push for their respective community's standards. Still to be filled remains the spot of the end user friendly distribution. I just got a call asking me to fix a printer setup, and, frankly, this stuff is *way* too complicated. Maybe a joint project, by members of the Debian and Ubuntu communities can tackle this?

Wouter Verhelst: Hello 2.9.0!

No, not the Linux release of that version (that's still far away, if it will ever be developed, and I don't think I'll be wanting to run that if/when it does). Instead, I'm talking about the NBD userland tools of that version, which I just released. Today we're only a few weeks after the release of 2.8.7—sorry for all you packagers out there who now have to throw away your work. But it's well worth it; nbd-server now finally functions like a real UNIX daemon: you specify exports in a configuration file, you can export more than just one export from the same server, and it has some interesting new features today. If you ever looked at nbd-server and decided that the way it's implemented is too hackish for your taste, then 2.9.0 may be a good time to revisit that opinion. Of course, I should note that 2.9.0 is a .0 release, so does still need some testing in the wild, so might not yet be ready for your production server. But other than that, it should be pretty much okay and usable. Give it a try! In related news, Ronnie Sahlberg, one of the wireshark developers, has made my day by writing an NBD dissector, which I've been wanting to have for quite a while now. Happy happy, joy joy.

Andrew Pollock: [opinion] On Australia's non-ratification of the Kyoto agreement

Australia's continued refusal to sign-on to the Kyoto agreement made the BBC World news tonight, and it got me thinking. After seeing An Inconvenient Truth, and learning that Australia just doesn't rank when it comes to carbon dioxide emissions, it's really a moot point whether we get on board or not (but for the record, I think we should anyway, to put more pressure on the US). Beazley's taken the opportunity to say that if he got into office, he'd sign the agreement. But here's the deal: there are coast-to-coast Labor governments at the state-level. So what if Howard won't sign the agreement at the Federal level? If every state independently decides to legislate such that carbon emission levels are restricted to those of what the Kyoto agreement would require, then Australia has in essence signed on to it, whether Howard wants to or not. So all Beazley has to do is show a bit of political will, and that the states can tell the Federal government what to do. I'd like to see it happen.

Joerg Jaspert: DebConf7 dates announced

After a long time of waiting, and a lot of work from the localteam, Moray just announced the dates for next years DebConf7. So Edinburgh will have to deal with some hundred Debian people next June, from 10 June until 23 June, where 10-16 is DebCamp, 16 also the Debianday and 17-23 is DebConf time. Thanks to everyone who helped making this announce possible and to all that help to make the event possible!

31 October 2006

John Goerzen: Renovation: Week 18

Well, it's been awhile since I've posted a renovation update. Things have been going on, but not much that is all that impressive with photos.

We've had electrical work going on. The new water and propane lines have been trenched in. New ductwork is in progress. New electrical and phone service will be trenched in this week or next.

In the past week, the new siding has started going up, and the sheetrock is supposed to start going up on Monday.

So there is some quite visible change going on now! Click here for the pictures.

30 October 2006

Russell Coker: Xen and serial ports

Currently there is a serious problem with Xen. Fedora Core 5 with kernel 2.6.18-1.2200.fc5xen and Debian/unstable with kernel 2.6.18-1-xen-686 will not recognise both PC serial ports, and it appears that the one port that is recognised is only usable for a console not for a modem.

The Fedora bugzilla #204825 covers this and I have just filed Debian bug #396169.

The PC serial port is a fairly significant piece of hardware that is used for many things. The total lack of support for it in Xen builds is a significant impediment to Xen use. I believe that one of the potential benefits of Xen is to have applications that are exposed to attack run in a domU so that if a compromise is suspected then the memory can be dumped. Implementing this requires running Xen almost everywhere, which will not be possible if essential hardware is not supported.

I have also discovered a couple of other bugs in Xen in FC5 which I am in the process of verifying and reporting. One is that on a P3 system the plain-text console displays as black on black and the other is that Xorg on a PentiumD system will go into an infinite loop when OpenOffice is started.

Christian Perrier: If you have problems committing to alioth/svn.d.o...

...then check the number of projects you're part of on Alioth. Depending on the number of projects still using CVS among them, your problems might start if you are part of more than 15 projects and you will definitely have problems if you belong to more than 32. This, thanks to a glibc group limit bug in sarge... That make a good reason to release etch, indeed.

Mark Brown: Ecartis SMTP client

As Steve found Ecartis isn’t terribly informative about problems it encounters injecting mail via SMTP:
2006-08-14 21:40:25 1GCk6m-0006ZH-Vu == /usr/lib/ecartis/ecartis -s xen-tools-commits R=vdom_aliases T=address_pipe defer (0): Child process of address_pipe transport returned 75 (could mean temporary error)
from command: /usr/lib/ecartis/ecartis
with nothing in the Ecartis log by default. Along with a general failure to talk SMTP like Steve found you should also watch out for address checks tripping up on some of the addresses in the list - recipient verification callouts were what bit me. Ecartis will be a lot happier if it can just pump mail into an unquestioning server and have any problems reported via injection of bounce messages.

Lars Wirzenius: Debian: BSP @ Helsinki

We're going to have a little Bug Squashing Party in Helsinki, on the 11th and 12th of November. See the wiki page for more information. The location is still open: we have a tentative place, but it's not ideal, so we're looking for something better. If you can offer some place, please mail me, thanks. We will have the BSP in any case, so if you're interested in coming, start making your plans now.

Benjamin Mako Hill: Software Freedom Curriculum

About a year ago, I was working on OLPC during most of the time and thinking a lot about software freedom in the context of the project. My blog post on OLPC and Charges of Technological and Cultural Imperialism from last December is a great example of my thinking out loud about some of the issues. The attractive thing to me about OLPC was the idea of students getting a real, free software, free hardware, truly open platform unlike phones, calculators, and eBooks: closed paternalist platforms that seem to be the only real alternatives. This is a goal that OLPC has not achieved yet but has already come quite close to. People say that because modifying technology is often difficult, only a small percentage of users -- especially young users -- will take advantage of the malleability or "hackability" of a product. They are probably right. But part of why this happens is because when computers are employed in education, we use them as tools to accomplish predefined and preprogrammed tasks. Even when students learn to program, it's in a window (quite literally in a box) separate from the rest of the things that the computer does. And for someone working on a project in part so that they can spread technological freedom, this is a problem. Consider the fact that with only a small number of exceptions, the only advocates of software freedom I know are programmers or hackers. I don't think that this is because of some "programmer's sensibility" but rather because programmers understand a set of things about the malleability of software and the nature, effect, and context of computation that gives them perspective to understand how a concept like freedom might apply to something like software. In other words, to understand software freedom, you must first understand -- really understand -- what software is and what it is not, how it makes things possible and impossible, and how changing it can have important effects. The mentality I've described is currently a "hacker's sensibility" but I don't believe that you need to be a hacker to understand why software freedom is important. Proof, I think, is the fact that people think that a free press is important even if they don't publish or write very well. As an exercise, I took it on myself to write the beginning of a curriculum that teachers could use to teach students about software freedom and the concepts that I think are key to understanding it. It tries to come up with models for framing discussions and a series of activities to help teachers teach relatively young (i.e., middle school students) about issues of computation, information goods, and ultimately about software freedom. I wrote the curriculum about a year ago, showed it to a few teachers and colleagues, and then sat on it because I wasn't sure what to do with it and because I was concerned by my own lack of experience teaching outside of Universities. I'm still not entirely sure about incredibly basic things like what form a curriculum should take for this age group. I noticed recently that Wikiversity launched in August and it seems like the perfect place to put my curriculum for consumption by the world and for collaboration, discussion, and further development. You can see what I've got from this page and the pages linked from it:
http://en.wikiversity.org/wiki/Software_Freedom
The project still needs lots of work. It needs to be threshed out on its own terms and it needs to be broken down and integrated into Wikiversity as a series of learning projects, learning activities, etc. I've looked at the documentation around Wikiversity and I can neither understand how to do this nor find examples of large curricula in Wikiversity to which this has already been done. If you have experience on Wikiversity, your help would be welcome. If you are interested in using part of the curriculum, I would love to hear from you and to see your edits on the wiki.

Next.

Previous.