I always have time to think while mowing the lawn. And today while mowing the lawn, I got the notion that it would be great fun to play Colossal Cave and other early text adventure games on a teletype. And, of course, since Linux has teletype support in its genes, if I played my cards right, I could probably get a login prompt to my workstation with the teletype, too.

Now, at this point, I am compelled to take a small diversion and explain just what a teletype is -- for those of you, like me, who are too young to remember them. (I will graciously omit comment on those of you too old to remember them!) Teletypes have been around since about the 1930s or so, but the ones I have in mind are the ones that were used to interact with computers in the 1960s and 1970s. Instead of a keyboard and monitor, you'd have a keyboard and printer. Believe it or not, surplus teletypes were the interface of choice for teletypes even in the later years because they were so much cheaper than video terminals.

So anyhow, back to the plot. Teletypes operated at speeds ranging from about 40bps to 110bps, but it seems that the most common protocol was Baudot-coded 50cps 5N2 serial format -- that is, 5 data bits, 2 stop bits. Amazingly, the serial UART in modern PCs is still capable of communicating with these devices (though it may take some circuitry to tweak the voltages), and at least one person has made it work with Linux.

So I zip on over to eBay to look for teletypes. What do I find? NOT A ONE! A few manuals, and apparently there is a GPS named the teletype. And some company that has something they think *might* be compatible with a teletype, but they don't know.

eBay has sorely let me down. An antique geeky item should be right up their alley, and zilch. They can sell everything from cars to advertisements on some guy's bald head, but not a teletype? C'mon!

So anyhow, I am afraid I will have to improvise. Perhaps I can find a dot-matrix printer with a serial port (or, I guess, a parallel port would do too) and an unbuffered printing mode. Then the trick would be getting keyboard input. Perhaps I could rig up a pty to do this, input from /dev/console, output to /dev/ttyS0. It would still be old, but not quite the real deal.

So if any of you have a working teletype you'd like to get rid of, do please let me know. I'll send you a photo of the printout of me getting lost in Colossal Cave.

Oh, and for those keeping track at home, I guess you can add this to the list of old technologies I'm interested in: Gopher, typewriters, teletypes... they're all alike, right?

Andrew, as already mentioned in the first comment of Eddy s post you re referring to: Ganneff announced that snapshot.d.o will become an official service (ETA: some months). Reference: 20080814211643.GA12330@xanadu.blop.info

Me and Ail arrived at Buenos Aires on saturday. A member of the local team was waiting for people at Ezeiza, and we gave away our 2130 bus reservations in order to take a combi to Mar del Plata with Clint, four fellow german debianites and some venezuelans. The trip was quite long, around six hours IIRC. We arrived in the early morning, and slept past noon. I have no words to describe my particular experience with this year’s conference, but I do agree with our DPL: this has been the best DebConf I’ve ever attended. In general, the Annual Debian Conference is one of the most attractive events for me, since it provides us with the opportunity to share and define a little bit of the future of the universal operating system. I use, develop for and work with this operating system, so there’s the importance of this conference for me. That said, DebConf is a unique event. Some people that I know back in Venezuela are used to a different, more academic style of event, which features a tight schedule and no specific provision of group networking. They are not used to an event like DebConf, and when they attend it they feel they’ve lost their time in an event they don’t understand. And they ask for a participation certificate :) In that respect, besides the very interesting talks and events in the conference, DebConf offers an excellent opportunity for group development and general networking. On the other hand, both the local team and the venue have striked me in many good ways. I’m aware of LatAm limitations for some of the particularities of DebConf such as connectivity, provision for special food needs, special usage of the venue and general receptivity for a bunch of 24/7 geeks. The local team has made a huge effort putting this together in such a special and organized way. I don’t think the Venezuelan DC8 Bid would have made this much success in the same timeframe. Congratulations, Argentina! We will leave Mar del Plata on saturday (at 2200) and then we will spend some more days in Buenos Aires, particularly to attend Debian Day, where I’ll be giving a talk in spanish. Therefore, we’ll be writing a little more (in spanish) about Argentina later, since we loved our time in this country.

a) Situation

During the last few years team-maintaining groups of packages has become
more and more widespread in Debian; the exact number of packaging teams is
unknown, estimates vary between 42 and 893 -- reality is probably somewhere
in between. [0]

Although the challenges for all teams are similar, there is a lack of
communication between those groups which leads to a situation where many
are "reinventing the wheel".

b) Objectives

- bring members of different packaging teams together
- get an overview of different work flows, tools, and challenges
- compile generally useful 'models of good practise'
- define possible areas for cooperation / tasks of mutual interest

c) Methods

Should the proposal for the BOF be accepted, a short questionnaire covering
"typical questions" for packaging teams will be prepared before Summer that
allows interested participants from packaging teams to prepare a short
overview of their team's situation and work flow.

This will allow the BOF to begin with short and structured presentations
dealing with common aspects of team packaging. From these presentations
common points of interest will be collected to form the "agenda" for the
next part of the BOF.

Ideally the session will conclude with a summary of "best practises,"
ideas for improving individual groups' work flows and ideas for
improved cooperation between teams. -- Findings will be made public in
the hope that they will be helpful to others.



[0]
http://wiki.debian.org/Teams lists 42 "Packaging teams";
http://krum.ethz.ch/ddc/teams-of-2007.txt has 218 entries;
http://alioth.debian.org/ talks about 789 "hosted projects", looking in
/home/groups on alioth shows 893 directories in general and 387 pkg-*
directories.
Full event details

a) Situation

During the last few years team-maintaining groups of packages has become
more and more widespread in Debian; the exact number of packaging teams is
unknown, estimates vary between 42 and 893 -- reality is probably somewhere
in between. [0]

Although the challenges for all teams are similar, there is a lack of
communication between those groups which leads to a situation where many
are "reinventing the wheel".

b) Objectives

- bring members of different packaging teams together
- get an overview of different work flows, tools, and challenges
- compile generally useful 'models of good practise'
- define possible areas for cooperation / tasks of mutual interest

c) Methods

Should the proposal for the BOF be accepted, a short questionnaire covering
"typical questions" for packaging teams will be prepared before Summer that
allows interested participants from packaging teams to prepare a short
overview of their team's situation and work flow.

This will allow the BOF to begin with short and structured presentations
dealing with common aspects of team packaging. From these presentations
common points of interest will be collected to form the "agenda" for the
next part of the BOF.

Ideally the session will conclude with a summary of "best practises,"
ideas for improving individual groups' work flows and ideas for
improved cooperation between teams. -- Findings will be made public in
the hope that they will be helpful to others.



[0]
http://wiki.debian.org/Teams lists 42 "Packaging teams";
http://krum.ethz.ch/ddc/teams-of-2007.txt has 218 entries;
http://alioth.debian.org/ talks about 789 "hosted projects", looking in
/home/groups on alioth shows 893 directories in general and 387 pkg-*
directories.
Full event details

Like each year, we will discuss possible DebConf 10 venues.Full event details

This keynote reports on the current state of collaboration between Debian and Ubuntu, reports back on progress made since previous DebConf's, and looks forward to new opportunities for collaboration and development.

Debian's derivatives are a powerful part of the Debian family. They bring Debian technology and, usually, Debian values to a broader audience than Debian itself will reach. At the moment, Ubuntu is the derivative with the largest reach, bringing millions of new users to GNU/Linux and Debian specifically. Ubuntu has shifted the commercial Linux landscape from one focused on RPM-based distributions to one where DEB-based distributions have much greater commercial and consumer acceptance. In this keynote, the leader of the Ubuntu project will discuss the state of current collaboration between Debian and Ubuntu developers, articulate the roadmap of Ubuntu in the coming years, and explore ways in which Ubuntu's work can improve the state of Debian.

The talk will cover:

* Current areas of collaboration
* Toolchain, Java, Python, Debian Installer,
* OpenOffice, X.org
* GNOME and KDE
* Security
* Roadmaps and transitions

* Challenges and obstacles to collaboration
* Cultural and organisational differences
* Divergent goals and priorities
* Release management and coordination

* Frameworks for collaboration
* Patch management and submission processes
* Package review, merging and delta management
* Version control interchange
* Leadership meetings and dialogue
* Bug coordination and collaboration
* Translation coordination and management

Ubuntu is only one of many derivatives - and others are achieving tremendous success in their own ways, too. The eeePC ships a derivative of Debian, and Debian is at the heart of many excellent free software solutions. The goal of this talk will be to celebrate some of those achievements and also to look for ways to make the "family" feel more cohesive. In short, to ensure that innovation which happens in derivatives has a natural pathway back to Debian. If the leaders of other derivatives are present at DebConf, this would also be an opportunity to seek comment from them, perhaps in the form of a panel for Q&A at the end of the keynote.
Full event details

This talk will briefly explain what Debian Edu is, how we develop our distribution, how we differ from Debian, how we work on bridging the gaps that still exist and what our plans for the future are.

In July 2007 the Debian Edu project released its third release, codename "Skolelinux 3.0 Terra". Debian Edu is probably the most widely known and most widely used Custom Debian Distribution - at least if you follow the official criteria for a CDD, which we aim to finally fulfill 100% for Lenny: all packages are taken unmodified from Debian main.

This talk will explain the development process of Debian Edu and the various differences to a default Debian install. An overview of the planned features for Lenny will be given as well as a list of current showstoppers will be presented. To explain to the audience, what challenges have been overcome since Debian Edu was started, the history of how 100% inclusion in Debian was achieved, will also be explained. (Debian Edu used to be a seperate distribution! Now we have become a part of Debian!)

Using wiki.debian.org to write a fine manual will be explained briefly too: our documentation is written in a wiki, then exported as docbook and translated using .po files, then transfered back into docbook, to generate html and PDFs versions, which are made available in the debian-edu-doc package, which is installed on a webserver again.

In the end, releasing with Lenny will not be the end of the process of becoming part of Debian. Currently it looks like we might release with Lenny, but then do point releases on our own. Whether this is a sensible strategy or if there are others, will (hopefully) become clearer in future. Until & after the talk - it's a long and winding road!Full event details

One goal of Custom Debian Distributions is to form a group of Debian
developers who care for a specific set of packages that are used in
the day to day work of a certain user group. The fact that Debian has
grown to the largest pool of ready to install packages on the net has
led to the side effect that it is hard to maintain for
beginners. A Custom Debian Distribution adds some substructure
to the currently flat pool of 15000+X packages without a real
structure. These substructures are intended to put a focus on
special user interest. These substructures are not oriented on
technical matters like Debian installer team, porting teams or teams
that are focussing to implement programming language policies.

There are some similarities to Debian-i18n which also has the pure
goal to serve the needs of certain end user groups with the difference
that the users are grouped not according to their field of work but
according to their language. In fact it makes even sense to create
CDDs for languages that require certain technical means to optimally
support the language regarding direction of writing, special fonts
etc. It is known that some countries in Asia builded Debian
derivatives for this purpose but in principle it is not necessary to
derive - the better solution is to make Debian more flexible by
starting a CDD effort inside Debian.

The talks will give some examples from the success of CDDs like
Debian-Edu and Debian-Med. One very important outcome of the CDD
effort is the ongoing reunification of Linex - the Debian derived
distribution that is used in all schools in Extremadura - with
Debian-Edu. This step means that Debian gets a very large
implementation in all schools of Extremadura while on the other hand
the effort of development for the people who invented Linex will be
reduced. Debian featuring Debian-Edu now has a very good chance to
become a really good international school distribution because it has
roots in five countries (Norway, Spain, France, Germany and Japan) and
might become attractive for many more.

The success stories of CDDs would not have been possible outside
Debian and thus leaving the path to build Zillions of Debian
derivatives that reach a very small user base and working together
inside Debian is the main idea of the talk. To make this idea more
attractive in the second part of the talk a description of tools that
were developed in the CDD effort will be presented. Especially the
newly developed web tools that give a good overview about the
packages that are useful for a certain field of work and the QA tools
that enable the CDD team members to easily get an overview about
packages that need some action. So if people are not yet convinced
that a CDD for their purpose makes sense we will catch them by the
tools they might get for free if they follow the proposed strategy.
Full event details

The Debian-Med CDD was started in January 2002 and has evolved a lot
since this time. Debian now becomes the distribution of choice for
people who are working in the field of medicine. On the one hand this
can be obtained from the increase of pure numbers of packages in the
field of medicine.

On the other hand - which is even more interesting for general Debian
development - a group was formed that has developed a certain way of
cooperation which might serve as an example for other teams. Debian
knows a lot of technical teams focussing onto technical issues
(pkg-perl, pkg-python, d-i, etc.). An important part of the project is
to involve people who call themselves "pure users" or "non-developers"
(whatever this might mean) as it is done at a certain amount by the
i18n and Debian Edu team.

So this talk is not about boring the audience by mentioning medical
Free Software - it exists at a certain amount out there as other
specific software does as well - but rather how to attract people to a
topic where FLOSS is not common but should. It will give examples for
our way to advertise Free Software in medicine which is heavily
dominated by proprietary software, which tools we developed inside the
CDD framework to be always up to date with our web pages that are
intended to attract users to Debian and last but not least the lessons
we have learned in the project that might be of high interest for
other CDDs (or potential CDDs). Examples are given for project
management, attracting people by working techniques and making sure
that medical software finds a good home in Debian.
Full event details

Since 2005, the talks at Debconf have been recorded on video, to be
published online. Beginning in 2006, talks have also been streamed
live. One of the goals is to get recordings in high quality online
immediately, with little or no post-production work. The video
switcher dvswitch, realized in software, and a disk-based recording
workflow is bringing us closer to that goal. Tape is still used as
backup in case of failures, but we expect those to become rarer as
the system matures. A large part of the post production work is
restoring failed recordings.

Dvswitch was developed by Ben Hutchings just in time for the Debconf7
in Edinburgh. It enabled a multi-camera live production using cheap
cameras and modest laptops. The laptops relays DV streams over
TCP/IP. This avoids any degradation due to long cable stretches, and
makes cabling cheap and convenient. The output is DV straight from
the cameras, producing a very crisp master video.

Dvswitch works with sources and sinks. The sources send video from a
file or a firewire port to a listening instance of dvswitch, which can
run on a remote machine.
dvswitch listens to several sources and displays a scaled down black
and white preview image of each one. One of the sources is displayed
at full resolution in colour; this is the outgoing stream, which is
sent to the listening sinks. Each sink may send the stream to disk or
to an encoder for live streaming. It is common to do both; store the
raw master to disk, and forward the master to an encoder, and
subsequently to a streaming server.

While dvswitch saves us a bundle in hardware, the video team is still
heavy on manpower. Remotely operated cameras would help, and we are
still looking for affordable solutions that work well on Linux.


The talk will cover the hardware, software and manpower required for
a typical dvswitch usecase. Some caveats and challenges regarding
sound, lighting and rigging will be discussed. A live demonstration
of dvswitch in use will be given. We would also like to offer
rehearsal sessions with the demo rig for those who are interested.Full event details

Since 2005, the talks at Debconf have been recorded on video, to be
published online. Beginning in 2006, talks have also been streamed
live. One of the goals is to get recordings in high quality online
immediately, with little or no post-production work. The video
switcher dvswitch, realized in software, and a disk-based recording
workflow is bringing us closer to that goal. Tape is still used as
backup in case of failures, but we expect those to become rarer as
the system matures. A large part of the post production work is
restoring failed recordings.

Dvswitch was developed by Ben Hutchings just in time for the Debconf7
in Edinburgh. It enabled a multi-camera live production using cheap
cameras and modest laptops. The laptops relays DV streams over
TCP/IP. This avoids any degradation due to long cable stretches, and
makes cabling cheap and convenient. The output is DV straight from
the cameras, producing a very crisp master video.

Dvswitch works with sources and sinks. The sources send video from a
file or a firewire port to a listening instance of dvswitch, which can
run on a remote machine.
dvswitch listens to several sources and displays a scaled down black
and white preview image of each one. One of the sources is displayed
at full resolution in colour; this is the outgoing stream, which is
sent to the listening sinks. Each sink may send the stream to disk or
to an encoder for live streaming. It is common to do both; store the
raw master to disk, and forward the master to an encoder, and
subsequently to a streaming server.

While dvswitch saves us a bundle in hardware, the video team is still
heavy on manpower. Remotely operated cameras would help, and we are
still looking for affordable solutions that work well on Linux.


The talk will cover the hardware, software and manpower required for
a typical dvswitch usecase. Some caveats and challenges regarding
sound, lighting and rigging will be discussed. A live demonstration
of dvswitch in use will be given. We would also like to offer
rehearsal sessions with the demo rig for those who are interested.Full event details

Maintaining one of the largest set of packages in Debian, the Debian Perl Group
needed a tool for sorting the work, showing progress made by other
members and easing the sponsoring of uploads, as many active members of the
group aren't DDs.

Based on previous ad-hoc scripts, PET was written almost from scratch with the
idea of making it usable by other packaging groups, and it even is useful
for individuals tracking their own packages. It separates completely
presentation from data retrieval, and its modular structure allows to create
easily new sources of data and checks. (For more information, see
http://wiki.debian.org/Teams/DebianPerlGroup/DebianQA)

Today it helps a small group of people maintain over seven hundred packages (we
passed the 666 mark recently, so the joke is already old) without going insane.

Main functions:
* track new upstream versions
* show which packages prepared by non-DDs are ready for upload
* highlight several problems with packages and repo organisation
* follow uploaded packages' journey to the archive
* and lots of information packed in one place

This talk will introduce this tool, show how it's best used and a bit about its
internals so you can customize it (and contribute patches!).
Full event details

A lot of Debian is already using version control for the task, but everyone cooked up something of their own, more or less. We think the situation is similar in the other distros: the current approach to package maintenance doesn t scale too well, given today s needs (teams, offline work, increasing number of users and increased use of the bug trackers), and discussions of how to improve things are on the way, but have not yet carried fruit.

Furthermore, maintainers of a specific package in all distros basically have the same task. We could benefit from each other if we joined forces: less workload, improved access to patches in use by other distros, more structured communication, a wider spread of innovation, etc..

The goal of the vcs-pkg.org project is to integrate version control with distro package maintenance. We want to recognise all involved in the process, from upstream, the package maintainers of the various distributions, their security and release teams, and power users, who aren t afraid to fix their own bugs, and give maximum flexibility to them.

vcs-pkg.org is a (D)VCS-agnostic effort, so you don't have to fear advocacy. Instead, I would like to deliver to you the status quo and hope to get your valuable feedback. We've made good progress, but we haven't reached our goal, so your input will make a difference.Full event details

Like last year, we have a feedback system available again. If you attended an event during DebConf and want to give feedback on it, including free-form text to the presenter, this is your chance! As an attendee To give feedback please look at the schedule and select the event you want to comment on. You will notice a box saying Did you attend this event? Give Feedback, follow its link and fill out the form. As a speaker If you want to see what feedback your event got, please log in to the submission system and select the event you want to know more about. You will see a tab named Feedback, behind which you can find all the newly-written love letters.

Statically detecting FTBFS with edos-builddebcheck Here at DebConf8, after my talk about Mancoosi, I got in touch with several people interested in the QA implication of the EDOS/Mancoosi tools. Me and Ralf have for example been contacted by Ubuntu people which are setting up theirs equivalent of http://edos.debian.net. A guy working on a mirroring tool made an interesting hack using edos-debcheck: out of a mirror with broken dependencies he can mirrors a subset of packages which do not suffer of the same problem. But now to the more interesting development, following a bug report by Atomo and discussions with Lucas (the RC-bug-filing-master), me and Ralf implemented edos-builddebcheck. You can invoke it on a pair of Packages/Sources package list, and it will check whether some packages will FTBFS due to unsatisfiable dependencies. The results on Lenny main/amd64 as of today are, ... erm ..., scary : 49 packages will FTBFS. The RC-bug-filing-master and Ralf are working on filing them, "don't worry". You can find edos-builddebcheck in the edos-debcheck package, starting from version 1.0-7 (in incoming at the time of writing). Update yes, ATM edos-builddebcheck does not know anything about P-A-S packages, so there are some false positive. Still, 33 source packages are proper hits.

Not the plastic kind, the squishy furry kinda that need to GET THE HELL OUT OF MY HOUSE.

GRRR

Yesterday was visit 4? 5? from the exterminators. We got them to lay more traps. And this morning (I love my son dearly. Especially the opportunity to cuddle him to sleep at 4am. *sigh* I'm actually mostly serious. I've only been able to hold him for a few weeks now, and weaning means that I'm getting to do a lot more with him that only auzure_skies could do before. And how long will a child let himself be cuddled to sleep? This is just mixing poorly with the jetlag from the recent trip) I had the joy of watching the mouse run out from beside where one trap is, and behind the couch where another trap is, triggering neither of them.

What I really need is a flame thrower and a forgiving insurance company.

GRRR

Argh! Our beloved leaders have just started a consultation on making it mandatory for internet service providers to keep email and web logs for a year and deliver them to local councils and police on request. Large ISPs have already been doing this, in order to make friendly-friendly with gov.uk, (do their customers know they are being watched?) but requiring it of all ISPs might put some small user co-operative hosting services out of business because it will drive up costs (need more disk to store that data and staff time to distribute it on request). Not what I expected from a Labour and Co-operative Party government. Fortunately, the Lib Dems and Tories are speaking sense like this:-

“Ministers have proven time and time again that they are not to be trusted with sensitive data, but they seem intent on pressing ahead with this snoopers’ charter. ” (Source: BBC)

However, I’m pretty sure when the EU-level parts of this were being discussed, the Lib Dems and the Tories agreed with it. Something I’ll ask Neil Parish MEP when asking him about the progress of the promised reply to my three strikes by the backdoor questions. You can see why I’m sceptical about the “but it doesn’t mean what it appears to say” assurances, can’t you? They were worthless last time, and the time before that, and the time before that (yes, I’ve been doing this so long that I supported ST@ND). The consultation closes after this year’s Parliament and the Internet conference, which could also be an interesting place to ask questions about it. And it’s another consultation I should ask the Phone Co-op (aff) about. Please reply to the consultation and give a loud “NO” - if you have particularly good reasons, please let me know in a comment. I’ve no argument against policing, but a year’s logs? Local councils? There are too many holes in this to let it pass unchallenged. Thanks.

Some people asked me during the group photo why I brought a pirate flag to the group picture. One explaination is is pretty simple, but not the real answer: since DebConf5 there always has been a pirate flag at DebConf. The real answer to me is, that if the content mafia wants to label the cultural technique of copying, which is as old as humankind and the base of all our inventions as "pirating", them I'm very proud and happy to be a pirate.

A somewhat longer answer will give you the films "steal this movie", part 1 and 2, which are available (under a CC licence) for direct download on homer at DebConf8 (please use the wired network..) or via torrents on their website.

The first part mostly tells the story of the raid of the piratebay servers in Sweden, while the second part tries (and IMO succeeds very well) to paint the bigger picture. My favorite quote from the movies is "when the winds of change are blowing, some people are building shelters and others are building windmills".

Another insightful (and scary) quote is "you can't stop filesharing without a police state", and if you look around, that's what's being tried. So why is the content mafia afraid of file sharing? It's not really because of us consumers being consumers and "stealing" some content. I'm sure they can live with the "loss", that's not the reason. What they can't stand (nor survive) is millions of consumers becoming producers (and sellers of content). That's the threat they need to prevent.

And that's in very short why I think a pirate flag is appropiate at DebConf. We are producers and if free production of ideas and art is only possible for pirates, I say allrrrrrright ;-)

I very much recommend these two movies to everybody who is slightly interested in this topic and look forward for part 3, which should be in production by now. I hope this blog post made you curious to watch them, even though I feel that I couldn't summarize the movies as good as I would like to. DebConf8 took some tolls on me. I haven't even blogged about this wunderbare conference yet :-)

I also plan to bring a Debian flag to DebConf9 :-) If you happen to be an artist and want to create a design, I'd be very happy. At the moment I'm not fully sure if the flag will be printed or embroidered so the design should probably pretty basic. A red swirl on white (or black?) background, maybe accompanied with the letters "Debian". Other ideas or comments?

Although far from winning the war against Azeredo s bill, we finally won a battle. Chamber-of-Deputies IT Committee approved the request [pt-BR] for a public hearing [pt-BR]. Although a small step forward, all people involved with entities and NGOs interested in blocking this bill will have a chance to speak their minds. This comes in a very special timing. A pool was published early this week [pt-BR] run by Vox Populi revealing that more than a half of the Brazilian voters distrust e-voting and about 20% think it s possible to spy on their choices. This is a election year in Brazil, and all this setting can end up helping our case. More than 106-thousand already signed the petition and I think with all those signatures adding to this setting this is going to be a very interesting hearing. At least people supporting this bill will have to stand up and say they are for it And who knows what damage this can cause to them in a election year. Some public hearings are broadcast through Internet. I ll let you know if this one will be.