Hi everyone!
Today I make an announcement I thought I would never ever make. But things changed.
Discussion about this has a long history, starting as a non-serious suggestion at DesktopSummit 2011, continued with people on IRC, but it was decided back then that it wouldn t be worth the effort. This has changed too, and a small team has formed to work on it.
We hereby announce
Tanglu, a new Debian-based-Linux distribution.
Why do we need another one? Let me explain the concepts of that distro:
Tanglu will be based on Debian Testing and follow the Debian development closely. It will have a 6-months release-cycle and it s target audience are Linux desktop users. We will make installing and setting up the distro as easy as possible.
Tanglu will be usable for both developers of upstream software and the average Linux user and Linux newbie. This is possible because in our opinion developers and users don t have different needs for a desktop system. Both kinds of users like a polished desktop which just works . We will, hwever, not apply any kind of fancy modification on upstream software, we will basically just distribute what upstream created, so users can get an almost pure GNOME and KDE experience.
Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can t make new upstream versions available for testing easily. During a Debian freeze, DDs can upload their software to the current Tanglu development version and later start the new Debian cycle with already tested packages from Tanglu. The delta between Tanglu and Debian should be kept as minimal as possible. However, Tanglu is
not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu.
Ideally, Tanglu and Debian should be working well together in mixed environments, where you for example have Debian servers and multiple Tanglu desktops with the new software, targeted at desktop user. Since the differences between Tanglu and Debian should not be very high, administering both systems should be very easy (if you know Debian).
Tanglu will be an open project, driven by community. At the beginning of each cycle, people can make suggestions for release goals they want to implement (similar to Fedora, but without FESCo). These proposals are discussed in public and are rejected if there are major technical concerns. If consensus about a certain proposal is lacking, a vote is done for it. The proposal can be accepted with absolute majority. If this does not happen, the proposal is postponed for the next release, where people can vote for it again. If nobody wants that function, it is rejected. In general, decisions made by Debian are superior and have to be followed.
We don t think we know every package and every software better than the original upstream. That s why it makes much sense to rely on feedback from others and to have a community-based and peer-reviewed distribution, instead of secretly developing stuff and dumping it on the community. Tanglu will have a highly predictable set of features, defined at the beginning of a cycle, so you will know what you can expect from the next release as soon as possible and plan for it.
Tanglu will make it easy to deploy applications for it. It will contain a software-center, similar to what Ubuntu has. We will also try to establish a solution for a Linux-AppCenter , a place for Linux applications, which will be open not only for Tanglu, but can be implemented in any other distribution too. Possible income will flow back into development of the platform.
Now, let s answer the FQA (Future Questions Asked):
Why don t you contribute to Debian directly and create yet another distribution?
First of all, we contribute to Debian
And for me, I can say that I will contribute to Debian even more. The point is that Debian can not cover all possible use-cases, and with Tanglu we want to make a distro which solves this. You might ask why we have to create a new distro for that, instead of creating improvements
inside Debian? Creating a new distro allows us to do stuff we can never do in Debian. For example, we will include proprietary firmware in that distro, we will make installations of proprietary stuff possible easily (but don t ship with it by default) and we will have a time-based release cycle. These are already things which are a no-go for Debian, and that s fine. We don t want Debian to support these cases, as it is already a great distribution. We want to offer a distro as close to Debian as possible, but with a few modifications for use-cases which are not covered by Debian itself. Of course we will participate in
DEX.
If Debian Developers contribute to Tanglu, freezes will take even longer!
This is an often-heard concern, it comes up on every mailinglist discussion about continuing development while freeze. I would disagree here, packaging new upstream stuff is not slowing down testing and improving of packages in Testing. Also, Tanglu is an offer for Debian developers to participate (we will sync privileges for their packages) we don t expect anyone to work on it, but as we think DDs know their packages best, we will make it possible for them to participate without extra barriers. We hope that Tanglu can add value to Debian and that Debian cycles can start with better-tested packages.
You said you are a small team you cannot develop a whole distribution with it!
Let s put that to the test!
All people working on this are well aware of the issue that the project can not survive without much community-involvement on the long run. But we see a chance that many people are interested in it and that there is a high demand for it.
At the beginning, we will just start with a small set of packages. We will also sync many packages from Ubuntu, to reduce workload. For example, it is planned to use the Ubuntu-Kernel and KDE packaging. By doing this, we keep the workload at the beginning low. We also reduce duplicate work with that.
We even have some possible sponsors for the new distribution. But nothing is set in stone yet, so just wait for it to happen.
Why not participate in Arch, OpenSUSE $other_distro?
These are not Debian
. I know, it sounds odd, but if you like the Debian way of doing things, you want to use a Debian-based distribution. There is nothing wrong with OpenSUSE. And Debian has issues too. But we want to be close to Debian and use it s tools and way of doing things.
I hate you!!! You are doing it wrong!! The project is useless!
Well, that s fine. But there is no reason for hating us. If you dislike our idea, there are basically two options: First, you hate us but the project is successful. In that case, you have been wrong with hate, as there are definitely people who liked the project and contributed to it. Second, you hate us and we fail. In this case, there is no reason for hate, as the project will just vanish and you don t have to worry about it. So hating it would ve been just a big waste of energy.
Also keep in mind that forking is a way to keep development healthy and to adapt software to new use-cases which it didn t target before. And we are not introducing incompatibilities here (like e.g. writing our own display server could). Instead, we want to stay close to Debian and reuse as much code as possible.
Which desktop will you use?
Everyone can add a new desktop to Tanglu, as long as the desktop-environment is present in Debian. Long term, we will have to offer Linux-newbies a default flavour, probably by setting a default download on the website. But as long as there is a community for a given desktop-environment, the desktop is considered as supported.
At the beginning, we will focus on KDE, as many people have experience with it. But adding vanilla GNOME is planned too.
Can you say something about the software used in Tanglu?
Yes, but this is still in flow, so I can t promise final decisions here. On the server, side, we will try to use the Dak for repository management, as soon as we have enough server capacity. We will also use the standard Debian repository GUI and basically reuse most of the software there, to diverge less from Debian.
The distribution itself will use a Linux Kernel from Ubuntu and systemd as the primary init system, as well as the login manager logind. It will be based on current Debian Testing with some fresh packages from Unstable and Experimental. We might also use the Ubuntu driver packages and KDE packaging. We expect to have a very rough start with the first release, but there will be enough time to polish Tanglu.
Nice idea! How can I help?
Well, you can help with basically anything at time from writing manuals, over designing logos and pages to administering a webserver and create packages. We are at an early stage of development at the moment, but we wanted to go public with it as soon as possible, to include the community and receive feedback so we can make that distro community-centric from the beginning. Most of the infrastructure is currently in progress too.
So, if you want to get started with Tanglu,
subscribe to our mailinglist tanglu-devel and write a mail to it, intruducing yourself. We can then include you in the loop. Generally, if you want to get access to our machines, a trusted GPG-signature will help a lot.
If you want to talk to us, join #tanglu-devel or Freenode! Most discussions are currently happening there.
And that s it! Tanglu will be awesome!
Some other projects of mine will develop a bit slower because I am now involved in Tanglu. But nothing will stop, and there is some pretty cool stuff coming for both GNOME and KDE (and I still have to implement DEP-11 for Debian).
The following is what I usually do when I want to debianize a Haskell stuff from Hackage. This is a personal recipe, by no means official procedure or such. I may be wrong, badly at that.
As part of the 
* So, we got new laptop last week.
The entire plan was to introduce my wife into tech world or atleast in Debian and/or OpenSouce world. I visited home for one of this and other personal reason(s) [Expect next post on this!]. My wife reported 
I ll report Part 2 when things will be enough to report the progress.
For some time, 
So, since recently bugs.debian.org has started using libravatar avatars. Not yet the federated service, but that s supposedly in the works. But for that, one of course need to run each own service. Which I wanted to do. In a simple way.
So I did it.
You can find a 
Dear users and supporters of the backports service!
The Backports Team is pleased to announce the next important step on getting backports more integrated. People who are reading 
After one week of campaign on -vote@, many subjects have been mentioned already. I m trying here to list the concrete, actionable ideas I found interesting (does not necessarily mean that I agree with all of them) and that may be worth further discussion at a less busy time. There s obviously some amount of subjectivity in such a list, and I m also slightly biased ;) . Feel free to point to missing ideas or references (when an idea appeared in several emails, I ve generally tried to use the first reference).
On the campaign itself, and having general discussions inside Debian:
I've a collection of about 500 bookmarks which I've barely touched for a few years. I started organizing them late the other night, because I'd been off work sick for two days and that was about the most I felt up for doing with a computer.
The intention was to "tidy" them, and then setup some way of syncing them across browsers/computers. In the end I didn't like any of the syncing plugins I could find - xmarks, etc - so I decided to take a step backwards.
I'd exported my bookmarks to HTML page, via firefox, before I started, and then later in a fit of pique I deleted the whole damn lot of them.
So now a few years worth of bookmarks are stored in a single HTML file. But wait, we can use revision control can't we? We can host that file on github/similar. We can rely upon merges to deal with conflicts - simple if we just add lines to the end, or delete lines.
Maybe that's the best way to store bookmarks? I updated the bookmark file to read:
The XDG standard says user-specific data files should be written [in] $XDG_DATA_HOME which defaults to $HOME/.local/share.
This is basically a link-post to 
While working on fixing a few encoding problems that I managed to
introduce to the BTS almost half a year ago, I took a side bit of
coding, and introduced 
More importantly, but much less fun, the double encoding problems
(where mails would get double-encoded if any of the headers contained
non-us-ascii text), and mojibake wontfix icon ( ) should be fixed now.
If you see any additional cases of this, please report them to
owner@bugs.debian.org.