On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair, I sort of did a double-take as I realized what I had received.
Using Chrome OS
My Cr-48 and a Kindle
(This is part of a series of posts on Why Linux?)
I find Linux more flexible. Maybe that's the familiarity showing, maybe
it's about the package management, but it's a powerful reason for me to
use it.
For example, a couple of years ago I wanted to try out some iSCSI stuff
against a SAN. Of course I have test boxes available I can do this on,
but this was just to try out a few bits and pieces rather than anything
more concrete. So I installed open-iscsi on my desktop and was able to merrily do the tests I wanted with very little additional work.
Or I wanted to try out some BitKeeper to git conversion work recently. I
wasn't sure how much resource it would take on a build server, and
didn't want to tie things up there. So I ran it on my desktop overnight,
where I could easily setup the appropriate environment and wouldn't
impact on anyone else's resources.
Problems talking to dodgy hardware? Linux is much better about giving
you some idea what's going on, without needing to install extra
software. I had a workmate grappling with an old USB music player
recently; hooking it up to her Windows laptop wasn't providing a lot of
joy so I attached it to my Linux box and was able to see that it did
identify ok, but was disconnecting randomly at times too.
Want to script querying an AD server for the current employee list and
displaying who's joined and who's left since the last time you did so?
I found that easy enough with the common Linux LDAP tools. I'm sure it's
doable under Windows too, but I'm not sure it would be quite so simple.
For bonus points add graphviz into the mix for automatic organisation
charts (modulo accuracy of the AD data).
This flexibility is something that helps me do my job. Sure, as I
mentioned above I do have access to test boxes that I can use for
this, but being able to do it on my desktop can be useful - for example
if I'm offline, or on a slow network connection, or just geographically
distant from my test machines so network latency is higher than I'd
like.
(Also, it's something that makes a Linux box a really great test box.
I'm lucky in that I have a mix of OSes available to me for testing, but
the one that I use most often is the Debian box. Much easier to get and
install decent diagnosis tools for it that can give me packet level
dumps, or do really odd stuff that turns out to be really useful.)
Picture of Mehdi taken by Antoine Madet
I ve been mostly active in the OCaml team where we designed a tool to compute automatically the dependencies between OCaml packages, called dh-ocaml. This was a joint work with St phane Glondu, Sylvain Le Gall and Stefano Zacchiroli. I really appreciated the time spent with them while developing dh-ocaml. Some of the bits included in dh-ocaml have been included upstream in their latest release.
I ve also tried to give a second life to the Buildd Status Pages because they were (kind of) abandoned. I intend to keep them alive and add new features to them.
If you had a wand and could change one thing in Debian, what would that be?
Make OCaml part of a default Debian installation 
But, since I m not a magician yet, I d stick to more realistic plans:
During our last meeting in Paris last October, the Release Team agreed to organize a meeting after Squeeze s release to discuss (among other questions) Wheezy s cycle. But the details of the meeting are not fixed yet (we still have plenty of time to organize it and other more important tasks to care about). We would like to be able to announce a clear roadmap for Wheezy and enhance our communication with the rest of the project. We certainly want to avoid what happened for Squeeze. Making things a bit more predictable for developers is one of our goals.
Do you think the Constantly Usable Testing project will help?
The original idea by Joey Hess is great because it allows d-i developers to work with a stable version of the archive. It allows them to focus on the new features they want to implement or the parts they want to fix (AIUI). It also allows to have constantly available and working installation images.
Then, there is the idea of having a constantly usable Testing for users. The idea seems nice. People tend to like the idea behind CUT because they miss some software disappearing from Testing and because of the long delays for security fixes to reach Testing.
If the Release Team has decided to remove a package from Testing, I think that there must be a reason for that. It either means that the software is broken, has unfixed security holes or was asked for the removal by its maintainer. I think that we should better try to spend some time to fix those packages, instead of throwing a broken version in a new suite. It could be argued that one could add experimental s version in CUT (or sid s) but every user is free to cherry-pick packages from the relevant suite when needed while still following Testing as a default branch.
Besides, it s quite easy to see what was removed recently by checking the archive of debian-testing-changes or by querying UDD. IMO, It would be more useful to provide a better interface of that archive for our users. We could even imagine a program that alerts the user about installed software that got recently removed from Testing, to keep the user constantly aware any issue that could affect his machine. About the security or important updates, one has to recall the existence of Testing-security and testing-proposed-updates that are used specifically to let fixes reach Testing as soon as possible when it s not possible to go through Unstable. I m sure that the security team would appreciate some help to deal with security updates for Testing. We also have ways to speed migrate packages from Unstable to Testing.
I have to admit that I m not convinced yet by the benefits brought by CUT for our users.
2 comments Liked this article? Click here. My blog is Flattr-enabled.
Debian unstable is not conceived as a product for end-users, and for very good reasons. There seems to be some misunderstanding and people trying to push end-users to use unstable. This blog post tries to address the claims raised and put them into proper light.
1. It contains mainly stable versions of the software
The critical part here is the term mainly. Yes, developers are advised to only upload packages to unstable that they deem to be suitable for the next stable release. This is no hard requirement though and no one actually playing a gate-keeper enforcing this recommendation. Also, there is a fine amount of packages that follow either VCS snapshots or development branches, and only time can tell how stable those releases actually are. That's actually why there is a delay of several days before a package can transition over to testing. 2. It doesn't break badly every other day That's right but if you look at it, it also means that it does break badly eventually. And if you don't know how to move on from there, including knowing the location of maintainer scripts and how to edit them in those cases, or even resort to a rescue system, you are in troubles. 3. It's the basis of other distributions That's right in itself too, but it doesn't address the fact that those other distributions do put a lot of effort into quality assurance to work around the most nasty and annoying bugs that do affect unstable every other day. 4. It's not inherently less secure than Stable or Testing It's not inherently more secure than stable or testing either. And this is also ignoring the fact that some security bugs don't even get into stable or testing, they only affect unstable and have to get addressed just there. 5. I use it on my main computer This is the reason that you should ignore as most. People using unstable are often enough deeply involved into Debian maintenance, know how to write maintainer scripts, know where they are located in case of troubles, know how to use a rescue system in case of bootloader or kernel troubles. Just think about whether you would consider yourself to be at the same knowledge level than the person who wrote the blog article you read that used this as a convincing argument. Conclusion: Stories always have several truths attached to them. If you feel adventurous, like to understand what's going on and have a tendency for digging into things that go wrong, you most probably are using unstable already anyway and are reporting bugs that you find along your way. If you on the other hand rather
justwant to use your computer and don't want to work around (smaller) bugs every other day, you rather should stick with the release that is actually provided as purpose to suit the needs of end-users: stable.
This guy is very known by people who use to walk around the Paulista Avenue at night. This week Gilberto Kassab mayor of S o Paulo authorized the local police to arrest him and all other artists in order to replace them by one more crap christmas tree playing those well known depressed songs. SAD :_(
street artist treated like shit in S o Paulo - Brazil
(This is part of a series of posts on Why Linux?)
My first PC was an Amstrad PPC640D; an 8088 with twin 720k 3.5" disk
drives. It never ran Windows (3.0 was current at that point in time and
I don't think it would manage to run off a single floppy), so ran DOS. I
moved on to an 8086 desktop machine, complete with 10M full height 5.25"
HDD and CGA graphics. It still runs DOS. From there I moved to an
80386DX-40 desktop, with 4M RAM and SVGA graphics. A massive leap
forward, and something actually capable of running more than DOS.
Except I didn't. I had a Windows for Workgroups 3.11 install, but mostly
I still did what I needed to from DOS. The machine was never networked;
it had a modem attached but that was used to connect to Fidonet which
was well serviced by DOS tools. I put Linux on the box at one point
but it was C and TCP/IP and I was Pascal and Fido in those days, so I
didn't really know what to make of it.
Fast forward a few years and I'm still mostly using DOS, but I'm on a
486 and am running a separate machine as a BBS. It's using RemoteAccess under DOS and it feels like with 486 hardware I should be able to do some of this multitasking lark. I try OS/2 and Windows 95, but both end up dropping modem data when doing other things (I've moved on to ISDN at this point). Maybe I just needed to tweak things more, but I deem multitasking with BBS software a failure and go back to DOS and 2 machines.
When I went to university one of my new course mates had brought a
machine running Linux, and various of the older students are already
running it. There was a wealth of information and interest available to
me. So I try again. I've learnt C and TCP/IP networking since last
time, and suddenly it all makes more sense and I'm able to do more with
it (I'm sure a summer using HP/UX on my desktop at Nortel helped).
And, as I finally get to the point, it's efficient. It makes use of the
extra memory in the machine that DOS can only touch with kludges. It
allows me to multitask in a usable fashion. I don't feel the need for a
GUI so I don't have to run one, which no doubt helps, but everything
that's running is easily visible and tunable. I start running it as my
desktop at university and convert the BBS over to it at some point soon
after. It doesn't drop modem data. I rejoice, and don't look back.
In those days I was running hardware that was probably at the low end of
what the popular multitasking OSes wanted (I remember seeing Win95 on a
4M machine when it first came out, and it crawled). These days my main
machines are (I would hope) more than capable of running Windows well.
The efficiency angle is still an appeal of Linux though; for example in
the server space I don't understand why you'd want to run something with
the overhead of an always on GUI (people who leave Linux servers running
GDM confuse me). I want to be able to do everything I need on a server
remotely, be that via SSH or, in a pinch, a serial console. I don't want
to sit at the box and use a GUI. Linux lets me run only what I actually
need on the machine.
Mockup of mobile UI
<fb:share-button href="http://blog.jhr-online.de/169" type="button"></fb:share-button>Countless times already have I used Google s amazing feature called maps. Admittedly, if you know me, you might wonder how I can be advertising Google. At least as often as I used google maps, I have told people about google s evilness. They re making their users transparent in ways most people can t even imagine transparent to other users (just like Facebook does) but, more importantly, transparent to themselves and their advertising customers. Technically skilled people reading my blog probably just nod and scoll down now :) Well, there still is something about Google that makes me use their developments: they are good. I don t know any other online service to create own maps, get directions etc. with as much detail and huge amount of data as google delivers. Thus, Google maps became my main source for locations and directions world wide. As such, I wanted to use it to get directions between places in Berlin, Germany. Apparently, Google s software had some kind of hick up or whatever, though. They got the directions right but somehow I doubt the map is anyhow related to what I requested. See for yourself 
Yes, yes, no software is perfect but still :)
<iframe allowtransparency="true" frameborder="0" scrolling="no" src="http://www.facebook.com/plugins/like.php?href=http://blog.jhr-online.de/169&layout=standard&show_faces=true&width=450&action=like&colorscheme=light" style="border:none; overflow:hidden; width:450px; height:65px"></iframe>
For my birthday back in October, my wonderful wife gave me a Kindle 3 from Amazon. I d been considering other e-book readers for quite some time, but I had mostly ignored the Kindle due to the lack of EPUB support and a general dislike of Amazon s DRM enforcement. In the end, the superior hardware and ecosystem of the Kindle overpowered those concerns and overall I m very pleased with the purchase. The screen is amazing, literally just like reading off a piece of paper and the selection of books is OK. I ve been buying almost all my books from Amazon to date since it s so easy (the Whispernet is amazingly quick!) but it s not terribly difficult to get EPUBs from elsewhere onto the device after a quick run through Calibre to turn them into a MOBI file, so I keep telling myself I ve still got some flexibility.
Almost as much fun as reading on the device has been learning about how it works. The Mobile Read forums have lots of step by step posts on how to do specific tasks like replacing the screensaver image, but they don t give much background detail on how the Kindle is actually operating which is what really interests me. Luckily among all the step by step posts I also found a usbnetwork package which also adds an SSH server to the Kindle, so after installing that and then SSHing in to my Kindle I ve been poking around.
Under the cover the Kindle reveals a fairly standard Linux installation. While the hardware and IO devices are obviously unique, compared to something like an Android phone, the Kindle is refreshingly normal .
Hardware
/proc rather than as a device. With a bit of digging I found some simple constants that when written to the proc files cause the screen to display the standard boot/progress/upgrading images. I haven t deciphered how to make more complex updates to the display yet./opt/amazon/ebook and consists of lots of Java classes. The system uses the cvm Java environment from Sun/Oracle which is specialised for embedded low-memory devices like this. The framework appears to take over most of the co-ordination, management and interaction tasks once it has started up.sendlogs scripts I d noticed and a few syslog lines containing GPS co-ordinates that had been pasted on the Mobile Read forums. I can t find any trace of GPS co-ordinates in any syslog messages I ve seen on my device, but there is definitely information about the cell sites that my Kindle can see, the books that I m opening and where I m up to in them:
101206:235431 wand[2515]: I dtp:diag: t=4cfd77b7,MCC MNC=272 01,Channel=10762,Band=WCDMA I IMT 2000,Cell ID=1362209,LAC=3021,RAC=1
,Network Time=0000/00/00 00.00.00,Local Time Offset=Not provided,Selection Mode=Automatic,Test Mode=0,Bars=4,Roaming=1,RSSI=-88,Tx
Power=6,System Mode=WCDMA,Data Service Mode=HSDPA,Service Status=Service,Reg Status=Success,Call Status=Conversation,MM Attach St
ate=Attach accept,MM LU State=LU update,GMM Attach State=Attach accept,GMM State=Registered,GMM RAU State=Not available,PDP State=
Active,Network Mode=CS PS separate attach mode,PMM Mode=Connected,SIM Status=Valid; PIN okay; R3,MM Attach Error=No error,MM LU Er
ror=No error,GMM Attach Error=No error,GMM RAU Error=Not available,PDP Rej Reason=No error,Active/Monitored Sets=0;39;-11 1;180;-1
5,RSCP=-111,DRX=64,HSDPA Status=Active,HSDPA Indication=HSDPA HSUPA unsupp,Neighbor Cells=,Best 6 Cells=,Pathloss=,MFRM=,EGPRS Ind
ication=,HPLMN=,RPLMN=272;01 ,FPLMN=234;33 234;30 234;20 272;05 ,n=1:
101206:235758 cvm[3426]: I Reader:BOOK INFO:book asin=B003IWZZ3Y,file size=233168,file last mod date=2010-11-27 19.18.22 +0000,con
tent type=ebook,length=MobiPosition_ 465747,access=2010-12-06 09.44.32 +0000,last read position=MobiPosition_ 464387,isEncrypted=f
alse,isSample=false,isNew=false,isTTSMetdataPresent=false,isTTSMetadataAllowed=true,fileExtn=azw:
101206:233416 udhcpc[5639]: Offer from server xxx.xxx.2.254 received
101206:233416 udhcpc[5639]: Sending select for xxx.xxx.2.10...
Interestingly you can see from the last two lines, that Amazon has taken some care to preserve privacy by not including the full IP address given to the device by my local Wifi network, so in light of that I find it interesting that they decided not to obfuscate the Cell and Book IDs in those respective log messages too. Seems rather inconsistent.
As to how and when these logs are sent to Amazon, the picture is a little bit murky. Every 15 minutes tinyrot runs out of cron and rotates /var/log/messages if it is greater than 256k in size. Rotated logs are stored into /var/local/log under filenames like messages_00000044_20101207000006.gz and alongside the log files are a set of state files named nexttosendfile, messages_oldest, messages_youngest. Something regularly sweeps through this directory to update the state and remove the old logs (after sending them up to Amazon I assume). I suspect that something is buried in the Java application code mentioned above.
On the whole the Kindle is a fascinating piece of technology. It delivers a wonderful reading experience on top of a familiar Linux system and is going to provide me with many more hours of entertainment as I unpack all the tricks and techniques that have gone into this device. I would recommended it as a present for geeks everywhere.
The relationship between Debian and Ubuntu has been the subject of many
vigorous debates over the years, ever since Ubuntu s launch in 2004.
Six years later, the situation has improved and both projects
are communicating better. The Natty Narwhal Ubuntu Developer
Summit (UDS) featured like all UDS for more than 2 years a Debian
Health Check session where current cooperation issues and projects are
discussed. A few days after that session, Lucas Nussbaum gave a talk
during the mini-Debconf
Paris detailing the relationship between both projects, both at the
technical and social level. He also shared some concerns for Debian s
future and gave his point of view on how Debian should address them.
Both events give valuable insights on the current state of
the relationship.
Lucas Nussbaum s Debian-Ubuntu talk
Lucas started by introducing himself. He s an Ubuntu developer since 2006
and a Debian developer since 2007. He has worked to improve the collaboration
between both projects, notably by extending the Debian infrastructure to show
Ubuntu-related information. He attended conferences for both projects
(Debconf, UDS) and has friends in both communities. For all of these reasons,
he believes himself to be qualified to speak on this topic.
Collaboration at the technical level
He then quickly explained the task of a distribution: taking upstream
software, integrating it in standardized ways, doing quality assurance on
the whole, delivering the result to users, and assuring some support
afterward. He pointed out that in the case of Ubuntu, the distribution
has one special upstream: Debian.
Indeed Ubuntu gets most of its software from Debian (89%), and
only 7% are new packages coming from other upstream projects (the
remaining 4% are unknown, they are newer upstream releases of software
available in Debian but he was not able to find out whether the Debian
packaging had been reused or not). From all the packages imported from
Debian, 17% have Ubuntu-specific changes. The reasons for those changes
are varied: bugfixes, integration with Launchpad/Ubuntu One/etc., or
toolchain changes. The above figures are based on Ubuntu Lucid (10.04) while
excluding many Ubuntu-specific packages (language-pack-*, language-support-*,
kde-l10n-*, *ubuntu*, *launchpad*).
The different agendas and the differences in philosophy (Debian
often seeking perfect solutions to problems; Ubuntu accepting
temporary suboptimal workarounds) also explain why so many packages are
modified on the Ubuntu side. It s simply not possible to always do the
work in Debian first. But keeping changes in Ubuntu requires a lot of work
since they merge with Debian unstable every 6 months. That s why they have
a strong incentive to push changes to upstream and/or to Debian.
There are 3 channels that Ubuntu uses to push changes to Debian: they
file bug reports (between 250 to 400 during each Ubuntu release cycle),
they interact directly with Debian maintainers (often the case when
there s a maintenance team), or they do nothing and hope that the Debian
maintainer will pick up the patch directly from the Debian
Package Tracking System (it relays information provided by patches.ubuntu.com).
Lucas pointed out that those changes are not the only thing that
Debian should take back. Ubuntu has a huge user base resulting in lots of
bug reports sitting in Launchpad, often without anyone taking care of
them. Debian maintainers who already have enough bugs on their
packages are obviously not interested in even more bugs, but those who are
maintaining niche packages, with few reports, might be interested by the
user feedback available in Launchpad. Even if some of the reports are
Ubuntu-specific, many of them are advance warnings of problems
that will affect Debian later on, when the toolchain catches up with
Ubuntu s aggressive updates. To make this easier for Debian maintainers,
Lucas improved the Debian Package Tracking System so that they can easily
get Ubuntu bug reports for their packages even without interacting with
Launchpad.
Human feelings on both sides
Lucas witnessed a big evolution in the perception of Ubuntu on the Debian
side. The initial climate was rather negative: there were feelings of its work
being stolen, claims of giving back that did not match the observations of
the Debian maintainers, and problems with specific Canonical employees
that reflected badly on Ubuntu as a whole. These days most Debian developers find
something positive in Ubuntu: it brings a lot of new users to Linux, it
provides something that works for their friends and family, it brings new
developers to Debian, and it serves as a technological playground for
Debian.
On the Ubuntu side, the culture has changed as well. Debian is no
longer so scary for Ubuntu contributors and contributing to Debian is The
Right Thing to do. More and more Ubuntu developers are getting involved in Debian
as well. But at the package level there s not always much to contribute, as
many bugfixes are only temporary workarounds. And while Ubuntu s
community follows this philosophy, Canonical is a for-profit company that
contributes back mainly when it has compelling reasons to do so.
Consequences for Debian
In Lucas s eyes, the success of Ubuntu creates new problems. For many
new users Linux is a synonym for Ubuntu, and since much innovation happens
in Ubuntu first, Debian is overshadowed by its most popular derivative.
He goes as far as saying that because of that Debian becomes less
relevant .
He went on to say that Debian needs to be relevant because the
project defends important values that Ubuntu does not. And it needs to
stay as an independent partner that filters what comes out of Ubuntu,
ensuring that quality prevails in the long term.
Fixing this problem is difficult, and the answer should not be
to undermine Ubuntu. On the contrary, more cooperation is needed. If
Debian developers are involved sooner in Ubuntu s projects, Debian will
automatically get more credit. And if Ubuntu does more work in
Debian, their work can be showcased sooner in the Debian context as
well.
The other solution that Lucas proposed is that Debian needs to
communicate on why it s better than Ubuntu. Debian might not be better for
everybody but there are many reasons why one could prefer Debian over
Ubuntu. He listed some of them: Debian has better values
since it s a volunteer-based project where decisions are made publicly
and it has advocated the free software philosophy since 1993. On the other hand,
Ubuntu is under control of Canonical where some decisions are imposed, it
advocates some proprietary web services (Ubuntu One), the installer
recommends adding proprietary software, and copyright assignments are
required to contribute to Canonical projects.
Debian is also better in terms of quality because every package has a
maintainer who is often an expert in the field of the package. As a
derivative, Ubuntu does not have the resources to do the same and instead
most packages are maintained on a best effort basis by a limited set of
developers who can t know everything about all packages.
In conclusion, Lucas explained that Debian can neither ignore Ubuntu
nor fight it. Instead it should consider Ubuntu as a
chance and should leverage it to get back in the center
of the FLOSS ecosystem .
The Debian health check UDS session
While this session has existed for some time, it s only the second
time that a Debian Project Leader was present at UDS to discuss collaboration
issues. During UDS-M (the previous summit), this increased involvement
from Debian was a nice surprise to many. Stefano
Zacchiroli the Debian leader collected and shared the
feedback of Debian developers and the session ended up being very
productive. Six months later is a good time to look back and verify
if decisions made during UDS-M (see blueprint)
have been followed through.
Progress has been made
On the Debian side, Stefano set up a Derivatives
Front Desk so that derivative distributions (not just Ubuntu)
have a clear point of
contact when they are trying to cooperate but don t know where to start.
It s also a good place to share experiences among the various
derivatives. In parallel, a #debian-ubuntu channel has been started on OFTC (the
IRC network used by Debian). With more than 50 regulars coming from both
distributions, it s a good place for quick queries when you need advice
on how to interact with the distribution that you re not familiar
with.
Ubuntu has updated its documentation to prominently feature how to
cooperate with Debian. For example, the sponsorship process
documentation explains how to forward patches both to the upstream
developers and to Debian. It also recommends ensuring that the patch
is not Ubuntu-specific and gives some explanation on how to do it (which
includes checking against a list of common packaging
changes made by Ubuntu). The Debian Derivative Front Desk is
mentioned as a fallback when the Debian maintainer is unresponsive.
While organizing Ubuntu Developer
Week, Ubuntu now reaches out to Debian developers and tries to have
sessions on working with Debian . Launchpad has also been extended to provide a list of bugs with
attached patches and that information has been integrated in the Debian
Package Tracking system by Lucas Nussbaum.
Still some work to do
Some of the work items have not been completed yet: many
Debian maintainers would like a simpler way to issue a sync request (a
process used to inject a package from Debian into Ubuntu).
There s a requestsync command line tool provided by the ubuntu-dev-tools package (which is available in Debian) but it s not yet usable because
Launchpad doesn t know the GPG keys of Debian maintainers.
Another issue concerns packages which are first introduced in Ubuntu.
Most of them have no reason to be Ubuntu-specific and should also end up
in Debian. It has thus been suggested that people packaging new software
for Ubuntu also upload them to Debian. They could however
immediately file a request
for adoption (RFA) to find another Debian maintainer if they
don t plan to maintain it in the long term. If Ubuntu doesn t make
this effort, it can take a long time until someone decides to reintegrate
the Ubuntu package into Debian just because nobody knows about it.
This represents an important shift in the Ubuntu process and it s not
certain that it s going to work out. As with any important policy change,
it can take several years until people are used to it.
Both issues have been rescheduled for this release cycle, so they re still on the agenda.
This time the UDS session was probably less interesting than the
previous one. Stefano explained
once more what Debian considers good collaboration practices: teams
with members from both distributions, and forwarding of bugs
if they have been well triaged and are known to apply to Debian. He also
invited Ubuntu to discuss big changes with Debian before implementing
them.
An interesting suggestion that came up was that some Ubuntu developers could
participate in Debcamp (one week hack-together before Debconf) to work
with some Debian developers, go through Ubuntu patches, and merge the
interesting bits. This would nicely complement Ubuntu s increased presence
at Debconf: for the first time, community management team member Jorge Castro was at DebConf 10 giving a talk on
collaboration between Debian and Ubuntu.
There was also some brainstorming on how to identify packages where the
collaboration is failing. A growing number of Ubuntu revisions (identified
for example by a version like 1.0-1ubuntu62) could indicate that no
synchronization was made with Debian, but it would also identify packages
which are badly maintained on the Debian side. If Ubuntu consistently has
a newer upstream version compared to Debian, it can also indicate a
problem: maybe the person maintaining the package for Ubuntu would be better
off doing the same work in Debian directly since the maintainer is lagging or not
doing their work. Unfortunately this doesn t hold true for all packages
since many Gnome packages are newer in Ubuntu but are actively maintained
on both sides.
Few of those discussions led to concrete decisions. It seems most
proponents are reasonably satisfied with the current situation. Of course,
one can always do better and Jono Bacon is going to ensure that all
Canonical teams working on Ubuntu are aware of how to properly cooperate
with Debian. The goal is to avoid heavy package modifications without
coordination.
Conclusion
The Debian-Ubuntu relationships used to be a hot topic, but that s no
longer the case thanks to regular efforts made on both sides. Conflicts
between individuals still happen, but there are multiple places where they
can be reported and discussed (#debian-ubuntu channel, Derivatives
Front Desk at derivatives@debian.org on the
Debian side or debian@ubuntu.com on
the Ubuntu side). Documentation and infrastructure are in place to
make it easier for volunteers to do the right thing.
Despite all those process improvements, the best results still come out
when people build personal relationships by discussing what they
are doing. It often leads to tight cooperation, up to commit rights to the
source repositories. Regular contacts help build a real sense of
cooperation that no automated process can ever hope to achieve.
This article was first published in Linux Weekly News. You can get my monthly summary of the Debian/Ubuntu news, all you have to do is to click here to subscribe to my free newsletter.
5 comments Liked this article? Click here. My blog is Flattr-enabled.
How much would you pay to participate in a social network and what would you expect for that?
On the web, I m used to some social networks being available for free. Usefulness and size varies massively, but there s quite a choice of them. There s a price to access them (computer, internet access, time) but once you ve paid that, there are free-to-use networks.
Offline, a lot of networking opportunities cost money and not just access costs (travel, time). Especially business networks. OK, there are paid business networks online too, but some of the biggest ones have some long-term free access level, to try to entice people to upgrade. Offline, it seems like the reverse: there are some free networks and some that have short-term free access, but the norm seems to be pay-to-play. Often you get nothing except entry for the basic subscription, but at least our co-op usually prefers networks where we re proper members with some say in how things are run.
Not that democracy always works. One networking organisations made a mistake in posting out ballot papers that means we can t vote in its leadership election. This isn t the first administrative problem we ve suffered and their last decent event was at least a year ago, too. At what point should we quit? I think I ll try to address this through the membership democracy first.
In this recession, some of our offline networks are reviewing their prices. In one case, a network which was free is going to become one of our more expensive annual subscriptions if we renew. If I look at it as a simple does this bring in enough work to pay for itself? decision then probably it won t. How much value do you attach to being there and to being visible, though?
Surprisingly, my Monday blog post has received much more attention than I did expect and was source for at least one article full of speculations (in Czech). Hey, there was no new information in the post, nor some secret information leak (not that I know something what is not known publicly).
Anyway meanwhile public announcement about UNIX copyrights has been made. I don't think it changes much, but it seems to be one if things people wanted to know.
What I find more interesting (and hard to read and understand) is explanation of the currently publicly available bits from a transactional lawyer at The Standards Blog. At least it gave me basic idea why some things are so complex in this deal and just confirmed that I want to avoid need for contact with lawyers language as much as possible :-).
Filed under: Suse 0 comments Flattr this!
For the Freaky Wall I have installed a Debian GNU/kFreeBSD system
using the installer with ZFS support announced on:
http://robertmh.wordpress.com/2010/09/06/debian-installer-with-zfs/
I used the mini.iso found on:
http://people.debian.org/~rmh/zfs/kfreebsd-amd64/monolithic/mini.iso
the 12th of October of 2010; as I had some problems and reported them to
Robert is possible that the current image solves part of them.
Installation plan
I did a standard installation on a machine with two hard disks, but only used
the first one from the installer.
The plan was to use ZFS with RAID-1, but current versions of grub do not
support booting from a ZFS + RAID file system, so I had to use the same
technique used for Linux for a long time; three partitions: a swap partition,
a small /boot partition and a big partition for /; / and /boot were
formated to use ZFS.
First reboot
After the installation the system failed to boot because of a bug when
building the /boot/grub/grub.cfg (some routes were missing a //@ prefix);
to be able to boot Iwe edited the config on the grub prompt and later fixed
the file:
--- grub.cfg.orig 2010-10-13 16:40:39.000000000 +0200
+++ grub.cfg 2010-10-13 18:38:47.535436766 +0200
@@ -64,7 +64,7 @@
set root='(hd0,1)'
search --no-floppy --fs-uuid --set a371979bb836d1fe
echo 'Loading kernel of FreeBSD 8.1-1-amd64 ...'
- kfreebsd /kfreebsd-8.1-1-amd64.gz
+ kfreebsd //@/kfreebsd-8.1-1-amd64.gz
insmod part_msdos
insmod zfs
set root='(hd0,3)'
@@ -75,7 +75,7 @@
insmod zfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set a371979bb836d1fe
- kfreebsd_module /zfs/zpool.cache type=/boot/zfs/zpool.cache
+ kfreebsd_module //@/zfs/zpool.cache type=/boot/zfs/zpool.cache
set kFreeBSD.vfs.root.mountfrom=zfs:dkfbf1-ad4s3
set kFreeBSD.vfs.root.mountfrom.options=rw
dpkg-reconfigure kbdcontrol
/boot partition was mounted on /target/boot, as that was what was
recorded on the ZFS file system; to fix it I executed the following commands:
# zfs set mountpoint=/ dkfbf1-ad4s3
# zfs set mountpoint=/boot dkfbf1-ad4s1
dkfbf1-ad4s3 is the root file system and dkfbf1-ad4s1 is the
original /boot.
I reported that to Robert also and I believe it is fixed on the ZFS
installer now.parted; the final result was:
# parted -l
Model: ST3250620NS/3BKS (ide)
Disk /dev/ad6: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 256MB 255MB primary
2 256MB 4256MB 4000MB primary
3 4256MB 250GB 246GB primary
Model: ST3250620NS/3BKS (ide)
Disk /dev/ad4: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 256MB 255MB primary
2 256MB 4256MB 4000MB primary linux-swap(v1)
3 4256MB 250GB 246GB primary
/etc/fstab:
/dev/ad4s2 none swap sw 0 0
/dev/ad6s2 none swap sw 0 0
zpool attach dkfbf1-ad4s3 ad4s3 ad6s3
/boot can't work as a replica I adjusted it to make two copies of
every file:
zfs set copies=2 dkfbf1-ad4s1
/boot partition synchronized with rsync each night.
After all those changes the system didn't boot, as the grub-pc generates a
buggy /boot/grub/grub.cfg; the problem is on the /etc/grub.d/10_kfreebsd
section:
### BEGIN /etc/grub.d/10_kfreebsd ###
menuentry 'Debian GNU/kFreeBSD, with kFreeBSD 8.1-1-amd64' --class debian \
--class gnu-kfreebsd --class gnu --class os
insmod part_msdos
insmod zfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set a371979bb836d1fe
echo 'Loading kernel of FreeBSD 8.1-1-amd64 ...'
kfreebsd /kfreebsd-8.1-1-amd64.gz
set kFreeBSD.vfs.root.mountfrom=unknown:/dev/ad4s3
set kFreeBSD.vfs.root.mountfrom.options=rw
### END /etc/grub.d/10_kfreebsd ###
/lib/modules directory to /boot and created a
link on the root partition to the new directory):
cd /boot
mkdir lib
mv /lib/modules lib
cd /lib
ln -s ../boot/lib/modules
/etc/grub.d/10_kfreebsd code I wrote a new
script (/etc/grub.d/09_zfs_kfreebsd) that creates the right config for my
current configuration on the grub.cfg file:
#!/bin/sh
prefix=/usr
exec_prefix=$ prefix
bindir=$ exec_prefix /bin
libdir=$ exec_prefix /lib
. $ libdir /grub/grub-mkconfig_lib
prepare_boot_cache="$(prepare_grub_to_access_device $ GRUB_DEVICE_BOOT sed -e "s/^/\t/")"
kfreebsd_versions="$(ls /lib/modules/)"
zfs_root_device="$(zfs list awk '/\/$/ print $1 ' head -1)"
for kversion in $kfreebsd_versions; do
cat << EOF
# Entry when using ZFS (we have issues with /etc/grub.d/10_kfreebsd)
menuentry 'Debian GNU/kFreeBSD, with kFreeBSD $kversion and ZFS' --class debian --class gnu-kfreebsd --class gnu --class os
$ prepare_boot_cache
echo 'Loading kernel of FreeBSD $kversion ...'
kfreebsd //@/kfreebsd-$kversion.gz
kfreebsd_module_elf //@/lib/modules/$kversion/opensolaris.ko
kfreebsd_module_elf //@/lib/modules/$kversion/zfs.ko
kfreebsd_module //@/zfs/zpool.cache type=/boot/zfs/zpool.cache
set kFreeBSD.vfs.root.mountfrom=zfs:$zfs_root_device
set kFreeBSD.vfs.root.mountfrom.options=rw
EOF
done
grub-pc package will deal well
with my config and I'll be able to remove this script, but I guess I'll have
to install it from backports.
The entry generated by the script when called from update-grub will be
similar to:
### BEGIN /etc/grub.d/09_zfs-kfreebsd ###
# Entry when using ZFS (we have issues with /etc/grub.d/10_kfreebsd)
menuentry 'Debian GNU/kFreeBSD, with kFreeBSD 8.1-1-amd64 @ ITI' --class debian --class gnu-kfreebsd --class gnu --class os
insmod part_msdos
insmod zfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set a371979bb836d1fe
echo 'Loading kernel of FreeBSD 8.1-1-amd64 ...'
kfreebsd //@/kfreebsd-8.1-1-amd64.gz
kfreebsd_module_elf //@/lib/modules/8.1-1-amd64/opensolaris.ko
kfreebsd_module_elf //@/lib/modules/8.1-1-amd64/zfs.ko
kfreebsd_module //@/zfs/zpool.cache type=/boot/zfs/zpool.cache
set kFreeBSD.vfs.root.mountfrom=zfs:dkfbf1-ad4s3
set kFreeBSD.vfs.root.mountfrom.options=rw
### END /etc/grub.d/10_iti-kfreebsd ###
/conf/As a bonus, this file system would provide a unified access to all system configuration data available through Config::Model. In any case, people would still be able to tinker configuration with their favorite text editor on a file in /etc. The modification will be propagated to the corresponding entry in the /conf virtual file system. The reverse will also be done. Anyone interested ? All the best PS: Further technical discussion will be held on Config::Model mailing list: config-model-users at lists.sourceforge.net 2010.11.25 edit: specified that config data can still be written in usual config file.
system/
sshd/
PermitRootLogin # contain 0 or 1
ssh/
popcon/
Next.