The recent work by MWR Labs does a reasonable job showing Debian s poor pro-active security and why I am so frustrated about it: we have not been able to move very quickly at getting it enabled. While my hardening-includes package is available to maintainers that want to turn on protections for their builds, it s still a far cry from having it be distro-wide, and it doesn t protect people that build stuff by hand. We were able to solve this in Ubuntu very directly a while ago by improving the compiler itself.
Since SSP and FORTIFY_SOURCE can only be confirmed (it s not possible without source analysis to see if it should have been enabled), it would be nice to see what binaries differed between distros on this. Most of the SSP disabled stuff are binaries that lack character arrays on the stack to begin with, and the FORTIFY_SOURCE stuff may have done all compile-time protections. The comments about other distributions could potentially enable it for a few more binaries is a bit misleading since, for all but Debian, both SSP and FORTIFY_SOURCE are enabled for all builds.
I did appreciate the nod to Ubuntu for being the only distro without by-default PIE that built Firefox with PIE. Given that Firefox is the #2 most vulnerable piece of software in a desktop distro, it was important to do it. (The #1 most vulnerable is the kernel itself I m counting number of fixed CVEs for this stat.)
The kernel analysis by MWR seems rather incomplete. Also, it s not clear to me which distros were running a PAE kernel, which would change some of the results. I didn t see any mention of several other userspace protections that the kernel can provide, for example:
Since the introduction of the 3.0 (quilt) source format, it is now possible to integrate multiple upstream tarballs in Debian source packages. This article will show you how to do the same with your own package shall you need it. It s quite useful to easily integrate supplementary plugins, translations, or documentation that the upstream developers are providing in separate tarballs.
Step by step explanation
We ll take the spamassassin source package as an example. The upstream version is 3.3.1. The main upstream tarball is named as usual (spamassassin_3.3.1.orig.tar.gz) and contains the top directory of our source package. We already have a debian directory because the package is not new.
Upstream provides spamassassin rules in a separate tarball named Mail-SpamAssassin-rules-3.3.1.r901671.tgz. We grab it, rename it to spamassassin_3.3.1.orig-pkgrules.tar.gz and put it next to the main tarball. The pkgrules part is the component name that we choose to identify the tarball, it s also the name of the directory in which it will be extracted inside the source package. For now that directory doesn t exist yet so we must create it.
$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz $ cd spamassassin-3.3.1 $ mkdir pkgrules $ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gzThis is already enough, the next time that you will build the source package, the supplementary tarball will be automatically integrated in the generated source package.
$ dpkg-buildpackage -S [...] dpkg-source -b spamassassin-3.3.1 dpkg-source: info: using source format 3.0 (quilt)' dpkg-source: info: building spamassassin using existing ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.debian.tar.gz dpkg-source: info: building spamassassin in spamassassin_3.3.1-1.dscThe supplementary tarball is now part of the source package but we re not making anything useful out of it. We have to modify debian/rules (or debian/spamassin.install) to install the new files in the binary package. A special case: bundling related software In very rare cases, you might want to create a bundle of several software (small perl modules for example) and you don t have any main tarball, you only have several small tarballs. Rename all the tarballs following the same logic as above and when building the source package you can ask dpkg-source to create an empty (and fake) main archive for you with the option
--create-empty-orig:
$ dpkg-buildpackage -S --source-option=--create-empty-origUse with care as the version number you give to the bundle is what users will see and it s likely unrelated to the version number of each individual software. Common mistakes Forgetting to extract the supplementary tarball If you forget to extract the content of the supplementary tarball in the pkgrules directory, dpkg-source will emit lots of warnings about those files being deleted. In fact, you did not delete them but you only forgot to create them in the first place.
dpkg-source: warning: ignoring deletion of directory pkgrules dpkg-source: warning: ignoring deletion of file pkgrules/20_fake_helo_tests.cf dpkg-source: warning: ignoring deletion of file pkgrules/60_shortcircuit.cf [...]Using a bad version number for the supplementary tarball Sometimes the supplementary tarball has a version of its own that does not match the upstream version. You must still name the file in a way that matches the upstream version of the main tarball otherwise it will not be picked up by dpkg-source and it will generate a new patch in debian/patches/ containing the whole new directory. It s possible to encode the version number of the supplementary tarball in the component name (in our example above we could have picked pkgrules-r901671 as component name) but this means that the name of the associated directory will regularly change and you must adapt your packaging rules to cope with this. However this last trick has the benefit of being able to update the additional tarball without bumping the upstream version. A sourceful upload of a new revision of the package will be accepted by the archive: the main tarball is ignored since it s unchanged but the supplementary tarball is taken since it s a new file for the archive (it has a different filename). Be sure to move away old versions of the additional tarball when you do that if you don t want to upload several versions of the same tarball by mistake! Misextracting the supplementary tarball dpkg-source is very smart when it extracts the supplementary tarball and you should be as well when you manually extract it. If the tarball contains only a single top-level directory, that directory is extracted, renamed to match the component name and moved in the source package directory.
$ mkdir pkgrules # Archive contains a single top-level directory $ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz # Archive contains many top-level entries $ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
After a semi-recent thread on debian-devel, I poked around and
realized that I'd never actually gotten around to formally announcing
the release of source code for Selectricity, a piece of web-based
election software designed to allow for preferential decision-making and
to provide "election machinery for the masses." Selectricity is useful
for a range of decisions but it targets all those quick little decisions
that we might want to decide preferentially but where running a vote
would be overkill.
Things were delayed through a drawn out set of negotiations with the MIT
Technology Licensing Office over how to release the code under a free
software license of my choosing. I was swamped when things finally came
through. Over time, I managed to forget that I never did a formal
announcement, never setup a mailing list, and never did all those things
that I have tried to teach other people in the Free Software Project
Management HOWTO. Code just sort of appeared on my website under the
GNU Affero General Public License. It was until the debian-devel
thread that I remembered I'd never made a formal announcement. Sorry
about that!
The git repository has been online and accessible through searches for
more than a year now. Most folks who wanted the code seem to have been
able to find it there. Indeed, a number of people have set up their own
instances and a few have submitted patches to the code! But more
visibility for the source means more empowered users, more visibility
for free software, and more developers.
So I've shipped all the code into a project in Gitorious (its like
GitHub, except free), announced things on the Selectricity Blog,
changed the Selectricity footer of to include a prominent link to the
source. I've also created a mailing list. The Gitorious project
page includes a wiki.
I also want to mention this all here because the attention of the
current development team seems mostly to have moved on to other
projects. The current team seems able to keep the hosted version up and
running, and even gets around to little improvements now and then, but
there's definitely room for new life and new leadership.
There are some nearly-complete and "complete minus further testing"
features in the development tree that might provide low hanging fruit
for folks interested in elections and decision-making who might want to
get involved in Selectricity development. If you're interested and know
(or want to learn) Rails, feel free to check out the code, introduce
yourself on the list or contact team@selectricity.org to coordinate.
Image via Wikipedia

deb http://backports.debian.org/debian-backports lenny-backports main contrib non-free
Really, I should have known better than to buy myself a rather 'bleeding-edge' laptop. I suppose I've been lucky with my last couple of laptops and was thinking that pretty much everything works on Linux. Or maybe I'm being picky, because in fact pretty much everything does work on my new Dell Studio.
I bought this laptop mainly because it has a 1920x1080 screen, without being a 17" monster. I had such a monster about four laptops ago (an enormous Sony Vaio weighing in at around 5kg and with a 1hr battery life) and it was an disaster: lots of weird proprietary stuff that never worked, like the external speakers in the docking station. But I loved that screen right up until the day Fraser threw a pair of scissors into it.
With the advent of mass-market 1920x1080 screens I've been waiting for them to arrive in laptops at a reasonable price, and the availability of this screen in a few possible laptops seemed to me to be that point.
It's a Dell Studio 15, and as well as the nice screen, it comes with a new Intel i7 Quad Core CPU, 6G RAM, 640G hard drive and a Blu-ray drive. While there are a few similar models around this one seemed to have the best mix of features-for-weight-and-price, so I bought my first Dell.
I built a USB key with the latest Debian Installer from Squeeze and installed that and everything came up pretty well. I had to use the broadcom-sta driver for the wireless, since the BCM 43224 is not (yet) supported by the free b43 driver (though from looking the mailing list people seem to be working on it, and it looks like it might not be too far away).
Everything seemed good. X came up on the (georgeous) screen. I don't care too much about 3D performance, but it was nice to note that the ATI 5000 series is expected to have full support as soon as it's integrated into the right places - it seems the code is written, and public, it just isn't incorporated into the 'radeon' driver quite yet. The fact that ATI is nowadays a free-software friendly company was one of the reasons for choosing this, in preference to an NVidia-based laptop.
But it seems that it isn't all roses. The fan in the laptop seems permanently on, and not on, in a quiet-just-barely-audible way, but ON, in an 'IN UR LAPTOPZ KOOLIN UR P0RCESSAZ' kind of a way. Too damn noisy for me to concentrate in a quiet room.
I've investigated what's going on, and it seems likely there are some ACPI misunderstandings happening. Some googling and some pecking around in /sys makes me wonder if the laptop expects some kind of configuration choice between favouring Active cooling and Passive cooling, and it's defaulted to the first one. Perhaps you get better benchmarks that way.
Linux ACPI also seems to only half understand it, it has two thermal zones, and one of them always appears with 0 temperature. I can see set points for the fans, but have no control over them. In particular this got me out reading the ACPI 4.0 specification, and it explicitly mentions this choice of favouring 'Active' vs 'Passive' as being done by configuring the passive trip point setting to a higher value than the low & high active trip points.
In the ACPI 4 spec (page 409) it says:
To implement a preference towards performance or energy conservation, OSPM can request that the platform change the priority of active cooling (performance) versus passive cooling (energy conservation/silence) by evaluating the _SCP (Set Cooling Policy) object for the thermal zone or a corresponding OS-specific interface to individual devices within a thermal zone.This laptop is showing 'passive' at 95000 millidegrees celsius, and 'active' at 55000 / 75000 so right in line with the suggestion. However I don't see any way in Linux to change these trip point values, and in any case I'm not convinced the laptop is actually obeying them at all. It should be that if I do nothing on the laptop for a while the temperature would surely drop below 55 degrees celsius. Surely a modern laptop will sit at under 40 degrees when it's quiescent, and the temperature sensor that does show me something sits at around 30 degrees in this too, 26.8, to be overprecise. That one doesn't budge either. Looking in /sys/ I can't for the life of me find a way to set that cooling policy, and when I disassemble the DSDT it looks like a noop... Thinking that perhaps there was a newer BIOS, I looked at the Dell site and found there was one. Great! Investigating even further, it seems Dell hardware has some interesting capability via libsmbios and some utilities which will let me install my BIOS from a Linux system... even better! Linux is a second-class citizen though, and when I look for the Dell BIOS Hdr file I need there is no version of the file for this laptop - let alone the current BIOS version. And when I download the BIOS from Dell's website and unzip the first layer of packaging I find that both of the files inside will only run on Windows. I added a FreeDOS boot stanza to Grub 2 in order to discover this, also discovering in the process that this is not well explained, and I could not find how to do it on the FreeDOS or Grub2 websites, so in passing, here is what I added into
/etc/grub/40_custom :
menuentry 'BIOS Flash 1558 A09' --class os
set root='(hd0,msdos1)'
linux16 /boot/memdisk
initrd16 /boot/1558_A09.img
Which certainly does boot FreeDOS from Grub2, into the image built from the 8M FreeDOS base image, and which I called '1558_A09.img' because that seems to be one of Dell's reference numbers for this model / BIOS version.
So still no BIOS update for Andrew, it seems, and the laptop is probably going to continue to be noisy for some time. Possibly forever.
Suspend/Resume works though. Kernel mode-setting for the ATI Radeon Mobility HD 5450 (or whatever it is) seems to work. Building kernels seems to work. The Blu-ray drive seems to work, at least as far as reading CDs - just because I got a laptop with a "Full HD" screen doesn't mean I watch movies on it: those pixels are for programming on! In any case, after reading the literature of pain about playing Blu-ray disks on Linux I'm convinced that we won't be shelling out to buy one any any time soon.
After a bit more frustration I did manage to get the BIOS installed, using the hack I found here of running the Windows BIOS update under Wine and copying the BIOS file out of the temp directory while the error message is displayed. I could then download a random DOS-installable Phoenix BIOS to get copy of phlash16.exe and put those two files on the FreeDOS image I created earlier. Finally I was able to put that learning about how to boot FreeDOS from Grub2 to good use!
Unfortunately, having jumped through all of those hoops (including the frustration of trying to build and use Dell's firmware-extract tools on a Debian system), the fan continues to grind away at annoying volume, with no way that I have been able to find to control it, and the temperature sensors also seem wrong, since one doesn't budge from 0 and the other doesn't budge from 26800.
During boot I get a bunch of error messages, like:
[ 1.049936] \_SB_.PCI0:_OSC invalid UUID
[ 1.052202] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 1.052210] pci 0000:00:1c.0: PME# disabled
[ 1.065228] pci 0000:07:00.2: PME# supported from D0 D1 D2 D3hot D3cold
[ 1.065237] pci 0000:07:00.2: PME# disabled
[ 1.079086] Unable to assume PCIe control: Disabling ASPM
[ 1.086412] HEST: Table is not found!
[ 1.249906] ACPI: Fan [FAN0] (off)
[ 1.249959] ACPI: Fan [FAN1] (off)
[ 1.250093] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
[ 1.259118] acpi device:02: registered as cooling_device2
[ 1.262132] thermal LNXTHERM:01: registered as thermal_zone0
[ 1.262139] ACPI: Thermal Zone [TZ00] (27 C)
[ 1.262561] thermal LNXTHERM:02: registered as thermal_zone1
[ 1.262571] ACPI: Thermal Zone [TZ01] (0 C)
[ 1.262598] ERST: Table is not found!
[ 2.769664] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 2.769670] ACPI: resource 0000:00:1f.3 [io 0x1840-0x185f] conflicts with ACPI
region SMBI [bus 1840-184f pref window disabled]
[ 2.769672] ACPI: If an ACPI driver is available for this device, you should use it
instead of the native driver
I don't yet know what this all means, so I guess I'll be signing up for the linux-acpi mailing list to see if there's anything I can do to get things working better. Any pointers will be gratefully received :-)
Right about now I wonder if maybe I should have gone for the HP or the Asus, even if they were a little heavier and a bit more expensive and next time I get a new laptop I must remember not to spend more than $900 (USD$600) on it.
[Updated: 2010-09-08... Noise Problems Solved
The unofficial rc bug tracker
currently knows about the following bugs:
| In Total: | 379 |
|---|---|
| Affecting Squeeze: | 291 |
| Squeeze only: | 65 |
| Remaining to be fixed in Squeeze: | 226 |
| Pending in Squeeze: | 14 |
|---|---|
| Patched in Squeeze: | 43 |
| Duplicates in Squeeze: | 21 |
| Contrib or non-free in Squeeze: | 13 |
| Claimed in Squeeze: | 2 |
| Delayed in Squeeze: | 8 |
| Can fixed in a security Update: | 14 |
| Otherwise fixed in Squeeze: | 16 |
Squeezereleased. However, with the view of the Release Managers, 244 need to be dealt with for the release to happen. Please see my older post for an explanation of the different numbers.
The next 4th of September, the Portuguese Debian community will gather at the University of Aveiro for the third edition of the DebianDayPT
There will be several talks about about Debian/Free Software in Portuguese and as special guest, Martin Michlmayr will deliver a couple of talks titled Contributing to Debian and Project Management in Free Software . Like last year, there will be DVDs with Debian Live so people can discover, try and install upcoming Debian stable Squeeze .
You can find more information of the event and information of how to arrive at: http://debiandaypt.debianpt.org/.
I have been wanting to post for several days already, at least since this last Sunday. I have repeatedly bragged about taking part in the Ciclot n: The last Sunday every month, the city's government closes to automotive transit a ~33Km circuit, for cyclists to enjoy. And by cyclists, I mean people from all expertise ranges Well, the very elite bikers will not take part of such a massive thing, but there are people pedalling a couple of blocks, people taking their small kids to drive a bit, and I recognized an amazingly large proportion of people doing the whole route.
Well, this last Sunday one lap was not enough for me I did two laps, ~65Km.
For some reason, the distance numbers in that map were made... in miles :-P Anyway, the planned route will be:
Two weeks ago, Maria and I completed
one of our dreams
when we arrived in Cap de Creus, where the Pyrenean range sinks in the
Mediterranean. To get there, we walked hundreds of kilometres during a month,
crossed dozens of steep valleys and enjoyed one of the richest experiences
of our lives.
We managed to complete this challenge without facing major problems or
pains, and after the first five our six days, our legs seemed to have
gotten used to the daily effort and it started to be easier and easier.
Our morale kept growing as days passed and we advanced east. When I
started walking on a cold and rainy morning in Hondarribia, after barely
no rest in the night bus to Ir n, I thought for myself that it was
improbable that we'd manage to get anywhere near Catalunya, that one of
us would get injuried way before, or we'd just give up and go for the easy
beach vacation in the Basque Country.

Biad s refuge, under Posets
But we didn't, and after a somewhat painful start, with our boots soaking
wet during the stages that crossed the enchanting Selva de Irati
which ended up with me getting the biggest blister I've ever seen, we
started to walk farther every day, extending the stages when we
felt strong after reaching their official end. When we crossed from
Nafarroa to Aragonese territory, the mental wall that I had built over the
toughest stages in our quest started to fall apart. Days later, we found
ourselves climbing down to Pineta, leaving Ordesa behind and enjoying a
feeling that our adventure could not go better. The weather had been
perfect for over a week and our legs and back were strong to go all over
the way to the sea.

Ca n de A isclo, on our way to Pineta
When we finally saw that huge blue stain on the horizon, the day before
getting to the last mark, we got really excited. We had made it, but as we
walked towards the cape, happiness slowly got mixed with melancholy. An
unforgettable adventure was about to end, and we didn't want to face our
return to the city and our routines. It had been many days surrounded only by
awesome landscapes, and living without watches, with only sunlight and
weariness marking the time to get in our sleeping bags.

At the very last red and white mark of our journey
We've had plenty of time to meet great people. Starting with
the Navarrian brothers we met in the early stage, which provided us with a
good pace to follow while our leg muscles were still building up; or Kike
and Ana, who drove from Pamplona to visit us during the first Aragonese
stages (thanks for the supplies!). Tom s and Roger, young hikers from
Matar , surprised us with their maturity and experience as mountaineers;
we had the pleasure to join forces during four days, walking a really cool
variant through the Infiernos and Collado del Letrero
which avoided going through the ghost city of Panticosa. Roger and Tom s,
we really hope to meet you soon! Andreu, Manel, Ghandi and Ga la visited us
at the Vall de N ria and were unlucky to suffer a frightening
hail and thunder storm when they left our shelter on their way back to
their car. Thanks! All of you have been a very special part of our
experience!
This adventure through GR 11 has been incredibly positive for us for
several reasons. We've learned a lot about ourselves and strengthened our
relation, and now I know how powerful drive can be; to get somewhere, no
matter how far, it's really easy if you just believe you can do it and
desire to get there.
Maria and I are proud of what we've done, and no wonder we're looking
for new challenges. An obvious one would be repeating this experience,
going through the French side of the Pyrenees, but for now, the Corsican
GR 20 seems the most appealing. We'll see, next summer!
Debian and Ubuntu have a set of official membership roles that can be granted to regular contributors. Those roles come with rights that enable the contributors to do their work and to participate in the project governance (elections and other official decision-making processes). It s also a way for the distributions to acknowledge the work done: most contributors are proud of the status they reached.
The membership structure plays an important role in the development of a distribution: it defines the kind of contributors that are welcome in the project, it sets expectations of the project towards its contributors and defines their rights. In the end, this shapes the project s ability to recruit new contributors to keep the project alive and kicking. This article introduces the existing statuses in Debian and Ubuntu, and defines the sometimes confusing jargon associated with them.
The Debian Case
Debian only has two types of official members: Debian Developers (DD) and Debian Maintainers (DM). The rights of the developers are codified in the Debian Constitution while those of the maintainers have been defined in a general resolution of 2007. The Debian Maintainer status is still mostly documented in a wiki page. The integration of this new status in Debian s official processes has been slow to come largely because it was introduced at that time without enough negotiation with the involved parties. Nowadays, it is preferred that people get the DM status before applying for DD.
DM is a very limited role: maintainers can only upload packages that already have their name on them (either in the Maintainer or Uploaders field) and a specific flag (DM-Upload-Allowed: yes) that only Debian Developers can add. They have no other rights and limited access to Debian s resources.
Besides those official roles, there are also maintainers of packages that have no official status within Debian except that they are listed in the Maintainer field of the package. They are doing the maintenance work but all uploads are done by a Debian Developer after verification of the work done (this is called sponsorship and is the only way to start with official packaging work). Once the DD trusts the maintainer, the developer will typically ask the maintainer to apply for DM status in order to be relieved from the sponsorship work.
In the end, that makes three different kind of package maintainers and a lot of confusion when you discuss membership issues in particular when the New Maintainer process is the path that you follow to become a Debian Developer. Don t be fooled by the names when reading Debian s documentation!
The Ubuntu Case
Ubuntu had, from the start, an official Ubuntu Member status that includes all contributors: developers of course, but also documentation writers, artists, translators, etc. This status notably grants the right to vote in elections of the Community
Council, the right to participate on Planet Ubuntu, and the @ubuntu.com email alias.
For developers, the situation is more complicated: the wiki page lists no less than five different statuses. Initially, developers were split between Ubuntu Core Developers and the MOTU (Masters Of The Universe). The latter were responsible of the universe/multiverse sections of the archive while the former also had upload rights for the main/restricted sections. But, inspired by the Debian Maintainers concept and facing concrete problems in terms of archive management, they changed their infrastructure to offer more fine-grained control on package uploads.
Ubuntu can now grant upload permissions on a package-per-package basis, but it can also delegate the right to grant upload permissions with the same granularity. This lead to the new Per-Package Uploader status which is simply an Ubuntu Member with upload rights on a limited set of packages where they have a specific expertise. The more generic Ubuntu Developers status now encompasses members of various development teams that have been delegated the right to manage upload permissions on a (usually large) package set (the current teams are Ubuntu Desktop, Mythubuntu, Kubuntu, and Edubuntu). Those teams can define their own policy to add new members provided they follow the basic rules defined by the Developer Membership Board (see this wiki page).
Ubuntu Contributing Developer is an intermediate status for someone who is not yet ready for one of the other developer statuses but who has still shown enough commitment to be an Ubuntu Member.
All those statuses can be obtained in a similar way: you prepare a wiki page listing your past contributions, you collect testimonials from existing members that you have worked with, you add yourself in the agenda of the next meeting of the board (or council) that grants the status that you seek, and you attend the meeting. The members of the board will decide whether you are ready for the status (or not) based on what you provided in the wiki, based on your answers during the meeting (and on a mailing-list for developers), and based on what others have to say about you.
The most important boards are usually elected by the community while others are commonly appointed by the community council. Those governance bodies include Canonical employees but not as many as one would expect: two out of eight in the Developer Membership Board, two out of eight in the Community Council, but all six members of the Technical Board. The last figure, while not intended, is not surprising given the high expectations set on potential members of the technical board. Mark, as the founder, is the only person to have a permanent seat on both the Community Council and the Technical Board.
Comparison of the Statuses Between Debian and Ubuntu
The following table summarizes the rights given to each developer role in the two projects (Put the mouse over the abbreviations to know what they are referring to).
| Rights | Debian | Ubuntu | ||||
|---|---|---|---|---|---|---|
| DM | DD | UM | PPU/UD | MOTU | UCD | |
| Package maintenance via sponsorship | Y | N/A | Y | Y | Y | N/A |
| Official email alias | - | Y | Y | Y | Y | Y |
| Participate in votes for members | - | Y | Y | Y | Y | Y |
| Participate in votes for developers | - | Y | - | Y | Y | Y |
| Upload rights restricted to pre-approved packages | Y | - | - | Y | - | - |
| Upload rights restricted to a section of the archive | - | - | - | - | Y | - |
| Unlimited upload rights | - | Y | - | - | - | Y |
| Number of contributors (as of 2010-07-27) | 117 | 904 | 462 | 27 | 85 | 63 |
This article was first published in Linux Weekly News. In a comment, Mark Shuttleworth tried to explain how the Ubuntu community is being setup.
For me, the most enjoyable part of traveling is the inspiration that I derive from visiting different places, talking to people, and generally being outside of my normal environment. This bank holiday weekend, when so many Londoners visit faraway lands, my partner and I stayed in London instead, and my sought inspiration closer to home. The city has been delightfully quiet, and in contrast to the preceding week, the weather was mostly pleasant, apart from the sudden downpours the BBC described as squally showers .
I ve been wondering if the following kind of testing management software exists (preferably free software, of course).
It would allow one to specify a number of test cases. For each, one should be able to describe preconditions, testing instructions and expected outcome. Also, file attachments should be supported in case a test case needs a particular data set.
It would publish a web site describing each test case.
A tester (who in the free software world could be anyone) would take a test case, follow the instructions given and observe whatever outcome occurs. The tester would then file a test report with this software, either a terse success report or a more verbose failure report.
The software should maintain testing statistics so that testers could easily choose test cases that have a dearth of reports.
As a bonus, it would be nice if the software could submit a failure report as a bug report .
(Note that this would be useful for handling the sort of tests that cannot be automated. There are many good ways already to run automated test suites.)
If you find that running Windows makes a GRUB 2-based system unbootable (Debian bug, Ubuntu bug), then I'd like to hear from you. This is a bug in which some proprietary Windows-based software overwrites particular sectors in the gap between the master boot record and the first partition, sometimes called the "embedding area". GRUB Legacy and GRUB 2 both normally use this part of the disk to store one of their key components: GRUB Legacy calls this component Stage 1.5, while GRUB 2 calls it the core image (comparison). However, Stage 1.5 is less useful than the core image (for example, the latter provides a rescue shell which can be used to recover from some problems), and is therefore rather smaller: somewhere around 10KB vs. 24KB for the common case of ext[234] on plain block devices. It seems that the Windows-based software writes to a sector which is after the end of Stage 1.5, but before the end of the core image. This is why the problem appears to be new with GRUB 2.
At least some occurrences of this are with software which writes a signature to the embedding area which hangs around even after uninstallation (even with one of those tools that tracks everything the installation process did and reverses it, I gather), so that you cannot uninstall and reinstall the application to defeat a trial period. This seems like a fine example of an antifeature, especially given its destructive consequences for free software, and is in general a poor piece of engineering; what happens if multiple such programs want to use the same sector, I wonder? They clearly aren't doing much checking that the sector is unused, not that that's really possible anyway. While I do not normally think that GRUB should go to any great lengths to accommodate proprietary software, this is a case where we need to defend ourselves against the predatory practices of some companies making us look bad: a relatively small number of people do enough detective work to realise that it's the fault of a particular Windows application, but many more simply blame our operating system because it won't start any more.
I believe that it may be possible to assemble a collection of signatures of such software, and arrange to avoid the disk sectors they have stolen. Indeed, I have a first draft of the necessary code. This is not a particularly pleasant solution, but it seems to be the most practical way around the problem; I'm hoping that several of the programs at fault are using common "licence manager" code or something like that, so that we can address most of the problems with a relatively small number of signatures. In order to do this, I need to hear from as many people as possible who are affected by this problem.
If you suffer from this problem, then please do the following:
fdisk -lu to a file. In this output, take note of the start sector of the first partition (usually 63, but might also be 2048 on recent installations, or occasionally something else). If this is something other than 63, then replace 63 in the following items with your number./dev/sda with your disk device if it's something else): dd if=/dev/sda of=sda.1 count=63dd if=/dev/sda of=sda.2 count=63fdisk -lu, and the embedding area before and after making GRUB unbootable.Next.