This site is now 100% read-only, and retired.

XML Logo

Posted by glanz on Mon 5 Feb 2007 at 21:21
Tags: none.
The "stagnation" of ReiserFS may have something to do with the arrest in California of Hans Reiser as the principal suspect in the disappearance of his wife.

This all brings up a good point: It is never good to depend on a system or distribution,for that matter, that depends on the well-being of one person, or even a small circle of friends. If the head of Debian disappeared, this would have little effect on Debian other than the usual wailing and moaning on mailing lists. Take Mepis, for example. It depends nearly entirely on one person. If he gives up, Mepis will most likely go down the drain. This happened to Lycoris. This happened to Libranet. And there are many other distributions that depend too much on the whims, psychological well-being, and material circumstances of one or of a very few persons.

Another "probable" example is Ulteo. Either Gael Duval just gave up on it, or worse, he issued a press release for vaporware, mounted a fancy, a forum, etc.., and sold the idea to investors to make some quick money before fucking off to a warm climate, or he is simply discouraged by statements like the one I just made.

This is one reason why new users should not only beware of small Linux start-ups that are there to make money off of providing free software for a price, and cutting access to usability by crippling default content and holding it up for ransom as Xandros does for CD burning, but also small efforts with with very little going for them other than good intentions.

But this phenomenon is not only restricted to small distributions, but also to badly managed distributions that stretch their clientèle thin by weeding them out with requests for money and special services where they are not needed. Mandrake went out because of this, and now it looks like Mandriva will follow the same road to oblivion according to


Posted by glanz on Sun 4 Feb 2007 at 12:04
Tags: none.
This interview is revealing. Now I don't know how true or false the statements Hans Reiser makes here, but if they are more or less true, then that's not promising:

Jeremy Andrews: How much effort does Namesys have to put into the support of Reiser3?

Hans Reiser: We didn't start V4 until V3 was stable. After we started V4 we hired one guy to do most of the V3 bug fixes, which were mostly in the newer journaling code, and then after a year the bug reports mostly stopped coming in. The bugs that do get reported now are always in the new features added by the SuSE guys. I am a big believer in the let there be a stable branch of the code with no new features model of software development. This makes me a bit of a heretic in the lkml community, but oh well.

From "slh" @ Sidux

While technically correct, this perception doesn't represent the actual state of affairs. True is that Namesys put reiserfs 3.6 into a strict feature freeze/ deep maintenance mode in favour of the upcoming (still not ready for prime time and not backwards compatible) reiser4 a few years ago - at that stage it dealt better with lots of small files than concurrent filesystem at that time, at least regarding speed that statement isn't true anymore with other filesystems improving and reiserfs stagnating. SuSE delayed that stagnation to actually meet the needs of contemporary use cases with its own developers (until the end of 2006 up to 3 developers almost exclusively for reiserfs 3.6 development), ACLs, xattrs, proper quota support, online resizing are still missing from reiserfs 3.6 completely. These changes (basically leading to a compatible reiserfs 3.6.1 or something like that) introduced regressions like any other developments and SuSE tried to fix them as they got noticed.

Right now with harddisks getting larger, xattrs and quotas becoming more important, clustering becoming a serious need, the old reiserfs 3.6 code isn't easy to keep on par any longer while concurrent file systems handle these issues easily while keeping up-/ and backwards compatibility, performance and journalling stability isn't an advantage for reiserfs any more because other filesystems were able to catch up and even overtake reiserfs 3.6 in the mean time (reiser4 is a complete new and incompatible filesystem, not a natural successor that could be upgraded - fragmentation and stability issues are also quite nasty). For these reasons Novell/ SuSE decided to follow Namesys' lead and cease all efforts regarding future development of reiserfs 3.6 and to switch to ext3/ ext4 while promising to provide further (deep) maintenance, as they're required to do for their existing (enterprise) user base anyways.

In my opinion it is sad that all further development of reiserfs 3.6 has been halted, because the b-tree approach and leaf packing had undeniable advantages for performance and overhead regarding lots of small files - but it also limited further development of the on-disk format as well. What is to be expected for reiserfs 3.6 in the future, SuSE will most likely look after serious bugs in reiserfs for the foreseable future, but personally I won't trust my data to a file system without active (!= deep) maintenance and that neglection is already showing in some rather serious bugs in reiserfs still present kernel 2.6.19 and 2.6.20, besides that alternative filesystems are also getting better than the current state of affairs for reiserfs 3.6 regarding stability and performance because those are still actively developed and not static targets without any improvements. This means that I don't consider reiserfs 3.6 a decent choice for "newly created" filesystems, but transitioning existing filesystems might not be a prime priority either - reiserfs is still there and won't go away in the next 5+ years<fullstop>.

If you want to transition away from reiserfs, "cp -a", "rsync -a", "tar -cjf" and subsequent "mkfs -t <insert_your_filesystem_of_choice_here>" (rather easy with external USB/ firewire/ eS-ATA disks or free space on different partitions) are the weapons of choice.

Post scriptum:
- please read and subsequent clarifications regarding SuSE's point of view.
- reiser4 is a completely different filesystem and incompatible to reiserfs 3.6; up- or downgrades are not possible at all, therefore its development is as unrelated to these issues/ discussions as ext4, xfs, jfx, ufs2, zfs, ntfs/ hpfs, vfat would be.
- I'd recommend ext3 for new general purpose filesystems.


Posted by glanz on Thu 1 Feb 2007 at 22:16
Tags: none.

From: James Bottomley <james.bottomley <at>;
Subject: GPLv3 Position Statement
Newsgroups: gmane.linux.kernel
Date: 2006-09-22 16:15:50 GMT (18 weeks, 6 days, 1 hour and 39 minutes ago)

Although this white paper was discussed amongst the full group of kernel
developers who participated in the informal poll, as you can expect from
Linux Kernel Developers, there was a wide crossection of opinion. This
document is really only for discussion, and represents only the views of
the people listed as authors (not the full voting pool).



The Dangers and Problems with GPLv3

James E.J. Bottomley Mauro Carvalho Chehab
Thomas Gleixner Christoph Hellwig Dave Jones
Greg Kroah-Hartman Tony Luck Andrew Morton
Trond Myklebust David Woodhouse

15 September 2006

This document is a position statement on the GNU General Public
License version 3 (in its current Draft 2 form) and its surrounding
process issued by some of the Maintainers of the Linux Kernel
speaking purely in their role as kernel maintainers. In no regard
should any opinion expressed herein be construed to represent the
views of any entities employing or being associated with any of the

1 Linux and GPLv2

Over the past decade, the Linux Operating System has shown itself to be far
and away the most successful Open Source operating system in history.
However, it certainly wasn't the first such open source operating system
and neither is it currently the only such operating system. We believe that
the pre-eminent success of Linux owes a great part to the dynamism and
diversity of its community of contributors, and that one of the catalysts
for creating and maintaining this community is the development contract as
expressed by GPLv2.

Since GPLv2 has served us so well for so long, and since it is the
foundation of our developer contract which has helped propel Linux to the
successes it enjoys today, we are extremely reluctant to contemplate
tampering with that licence except as bug fixes to correct exposed problems
or updates counter imminent dangers. So far, in the whole history of GPLv2,
including notable successes both injunctively and at trial, we have not
found any bugs significant enough to warrant such corrections.

2 Linux, the Kernel and the Open Source Universe

Linux Distributions, as the Free Software Foundation (FSF) has often
observed, don't only contain the kernel; they are composed of a
distribution of disparate open source components of which the kernel is
only a part (albeit a significant and indispensable part) which
collectively make up a useful and usable system. Thus, Linux as installed
by the end user, is critically dependent on entities, known as
distributions, who collect all of the necessary components together and
deliver them in a tested, stable form. The vast proliferation of Open
Source Licences complicates the job of these distributions and forces them
to spend time checking and assessing the ramifications of combining
software packages distributed under different (and often mutually
incompatible) licences--indeed, sometimes licensing consideration will be
sufficient to exclude a potential package from a distribution altogether.

In deference to the critical role of distributions, we regard reducing
the Open Source licensing profusion as a primary objective. GPLv2 has
played an important role in moving towards this objective by becoming the
dominant Licence in the space today, making it possible to put together a
Linux Distribution from entirely GPLv2 components and thus simplify the
life of a distributor. Therefore, we believe that any update to GPLv2 must
be so compelling as to cause all projects currently licensed under it to
switch as expediently as possible and thus not fragment the currently
unified GPLv2 licensed ecosystem.

3 Linux and Freedom

Another of the planks of Linux's success rests squarely on the breadth and
diversity of its community of contributors and users, without whom we
wouldn't have the steady stream of innovation which drives our movement
forward. However, an essential element of this is the fact that individuals
with disparate (and sometimes even competing) objectives can still march
together a considerable distance to their mutual benefit. This synergy of
effort, while not compromising dissimilar aims, is one of the reasons Linux
manages to harness the efforts of not only motivated developers but also
corporate and commercial interests. This in turn is brought about by a
peculiar freedom enshrined in the developer contract as represented by
GPLv2, namely the freedom from binding the end use of the project. Without
this freedom, it would be much more difficult to satisfy the objectives of
the contributors, since those objectives often have expression in terms of
the end use to which they wish to put the particular project. Therefore, in
order to maintain the essential development synergy and consequent
innovation stream it provides to Linux, we could not countenance any change
to the GPL which would jeopardise this fundamental freedom.

4 Pivotal Role of the Free Software Foundation

We have acknowledged before, projects controlled by the FSF (especially
gcc, binutils and glibc) are essential components of every shipping Linux
distribution. However, we also take note of the fact that the FSF operates
very differently from Linux in that it requires assignment of copyright
from each and every one of the thousands of contributors to its code
base. These contributions have been given to the FSF not as a tribute to do
with as it will but under a solemn trust, as stated in article 9 of GPLv2,
only to licence the code under versions of the GPL that "... will be
similar in spirit to the present version". We, like all the individual
contributors to GNU projects, have taken that trust at face value and
accorded the FSF a special role in the Open Source Universe because of
it. It goes without saying that any updates to GPLv2 must be completely in
accord with the execution of that trust.

5 GPLv3 and the Process to Date

The current version (Discussion Draft 2) of GPLv3 on first reading fails
the necessity test of section 1 on the grounds that there's no substantial
and identified problem with GPLv2 that it is trying to solve.

However, a deeper reading reveals several other problems with the
current FSF draft:

5.1 DRM Clauses

Also referred to as the "Tivoisation" clauses.

While we find the use of DRM by media companies in their attempts to
reach into user owned devices to control content deeply disturbing, our
belief in the essential freedoms of section 3 forbids us from ever
accepting any licence which contains end use restrictions. The existence of
DRM abuse is no excuse for curtailing freedoms.

Further, the FSF's attempts at drafting and re-drafting these
provisions have shown them to be a nasty minefield which keeps ensnaring
innocent and beneficial uses of encryption and DRM technologies so, on such
demonstrated pragmatic ground, these clauses are likewise dangerous and
difficult to get right and should have no place in a well drafted update to

Finally, we recognise that defining what constitutes DRM abuse is
essentially political in nature and as such, while we may argue forcefully
for our political opinions, we may not suborn or coerce others to go along
with them. Therefore, attempting to write these type of restrictions into
GPLv3 and then relicense all FSF code under it is tantamount to co-opting
the work of all prior contributions into the service of the FSF's political
ends, and thus represents a fundamental violation of the trust outlined in
section 4.

5.2 Additional Restrictions Clause

As we stated in section 2 one of the serious issues in Open Source is too
many licences. The additional restrictions section in the current draft
makes GPLv3 a pick and choose soup of possible restrictions which is going
to be a nightmare for our distributions to sort out legally and get
right. Thus, it represents a significant and unacceptable retrograde step
over GPLv2 and its no additional restrictions clause.

Further, the additional restrictions create the possibility of
fragmentation of the licensing universes among particular chosen
restrictions, which then become difficult to combine and distribute
(because of the need for keeping track of the separate restrictions). Thus,
we think this potential for fragmentation will completely eliminate the
needed compulsion to move quickly to a new licence as outlined in section 2

5.3 Patents Provisions

As drafted, this currently looks like it would potentially jeopardise the
entire patent portfolio of a company simply by the act of placing a GPLv3
licensed programme on their website. Since the Linux software ecosystem
relies on these type of contributions from companies who have lawyers who
will take the broadest possible interpretation when assessing liability, we
find this clause unacceptable because of the chilling effect it will have
on the necessary corporate input to our innovation stream.

Further, some companies who also act as current distributors of Linux
have significant patent portfolios; thus this clause represents another
barrier to their distributing Linux and as such is unacceptable under
section 2 because of the critical reliance our ecosystem has on these

6 Conclusions

The three key objections noted in section 5 are individually and
collectively sufficient reason for us to reject the current licence
proposal. However, we also note that the current draft with each of the
unacceptable provisions stripped out completely represents at best marginal
value over the tested and proven GPLv2. Therefore, as far as we are
concerned (and insofar as we control subsystems of the kernel) we cannot
foresee any drafts of GPLv3 coming out of the current drafting process that
would prove acceptable to us as a licence to move the current Linux Kernel

Further, since the FSF is proposing to shift all of its projects to
GPLv3 and apply pressure to every other GPL licensed project to move, we
foresee the release of GPLv3 portends the Balkanisation of the entire Open
Source Universe upon which we rely. This Balkanisation, which will be
manifested by distributions being forced to fork various packages in order
to get consistent licences, has the potential to inflict massive collateral
damage upon our entire ecosystem and jeopardise the very utility and
survival of Open Source. Since we can see nothing of sufficient value in
the current drafts of the GPLv3 to justify this terrible cost, we can only
assume the FSF is unaware of the current potential for disaster of the
course on which is has embarked. Therefore, we implore the FSF to
re-examine the consequences of its actions and to abandon the current GPLv3
process before it becomes too late.


Posted by glanz on Wed 31 Jan 2007 at 14:59
Tags: none.
This is a fully functional Debian Sid system that starts with a minimal KDE 3.55. A good way to get one's "foot in the Debian door" without having to use Debian's b0rked and screwed installer.

This release mostly is a proof of concept for the sidux building environment, the co-operation of our teams and to discuss the final packages list with our users - now is the time to discuss and lobby for meta tasks to install additional software for the final release. It's completely based on Debian Sid and enriched & stabilized with sidux own packages and scripts. It comes with kernel, which is based on the most recent vanilla kernel together with several patches for improved hardware support. Other special purpose kernels are available from the sidux servers and will be accompanied by experimental 2.6.20-rc variants for testing soon.

# amd64 (AMD64, Intel Core2, newer 64 bit capable Pentium 4 CPUs (watch for the "lm" flag in /proc/cpuinfo or use infobash -v 3) and i686 (pentium pro/ pentium II or newer).
# debian sid, up to date as of 2007-01-24 19:00 UTC.
# kernel (smp, voluntary preemption).
# minimal, but fully functional KDE 3.5.5 (en + de).
# completely overhauled live mode.
# largely adapted installer.
# new graphical installer frontend.
# netcardconfig can cope with wpa/ wpa2 again.
# offline manual for en + de directly on the disc, online manuals for more languages online at; a big thank you goes to the documentation and translation teams!
# a completely new ISO creation process written from scratch in a clean room environment.
# amd64 (AMD64, Intel Core2, newer 64 bit capable Pentium 4 CPUs (watch for the "lm" flag in /proc/cpuinfo or use infobash -v 3) and i686 (pentium pro/ pentium II or newer).
# debian sid, up to date as of 2007-01-24 19:00 UTC.
# kernel (smp, voluntary preemption).
# minimal, but fully functional KDE 3.5.5 (en + de).
# completely overhauled live mode.
# largely adapted installer.
# new graphical installer frontend.
# netcardconfig can cope with wpa/ wpa2 again.
# offline manual for en + de directly on the disc, online manuals for more languages online at; a big thank you goes to the documentation and translation teams!
# a completely new ISO creation process written from scratch in a clean room environment.

Hints for hardware with non-free needs:
(after adding contrib/ non-free to /etc/apt/sources.list and ensuring internet access)

* ATi Radeon graphics: 3d acceleration for older cards up to r35x should work, newer Radeon X1xxx cards need non-free drivers for accelerated performance, please use get-sidux-binary-gfx to fetch install scripts for these cards.
* Atheros/ "madwifi" wlan: m-a a-i madwifi.
* Atmel AT76c50x 11 MBit/s wlan: apt-get install atmel-firmware
* AVM ISDN/ ADSL PCI/ USB Karten: AVM's closed source driver are not compatible with kernel 2.6.19.x yet, please download kernel 2.6.18.x ( for now and use m-a a-i avm.
* Broadcom/ bcm43xx wlan: apt-get install bcm43xx-fwcutter.
* Eagle USB ADSL modem: fetch the firmware from and place it under /lib/firmware/.
* DVB firmwares for various full featured DVB TV cards (most budget cards won't need this): fetch the needed firmeware (check dmesg) from and place it under /lib/firmware/.
* hostap based 11 MBit/s wlan with loadable firmware (e.g. D-Link DWL-520 rev. E1 and others):
* Intel ipw2100, 11 MBit/s wlan: fetch the firmware from and place it under /lib/firmware/.
* Intel ipw2200, 54 MBit/s wlan: fetch the firmware from and place it under /lib/firmware/.
* Intel ipw3945, 54 Mbit/s wlan: apt-get install ipw3945d firmware-ipw3945
* Intersil prism54, 54 MBit/s wlan: fetch the firmware from and place it under /lib/firmware/.
* nVidia graphics: 3d acceleration isn't possible with free drivers yet, please use get-sidux-binary-gfx to fetch install scripts for these cards.
* Texas Instruments ACX100 (22 Mbit/s)/ ACX111 (54 MBit/s) wlan, fetch the firmware from and place it under /lib/firmware/.
* ZyDAS zd1202 11 MBit/s wlan: apt-get install zd1201-firmware
* ZyDAS zd1211 54 MBit/s wlan: fetch the firmware from and place it under /lib/firmware/.
* We will check if we can provide packages for at least some of these devices, but the legal status isn't necessarily easy.