Interview with Grzegorz Dąbrowski - english version
1. Welcome. First, write a few things about yourself if you will.
My name is Grzegorz Dąbrowski, I'm 29 years old. I graduated computer
2. Were you interested in BeOS? When did you start getting interested
in Haiku and for what reasons?
I had my first experience with BeOS when it has been released for free
in the form of BeOS 5 Personal Edition. I installed it, played with it
and eventually dropped it after a while. It didn't become my main
Later I heard about the appearance of Haiku. In 2003 I started a
bigger project - the creation of a linux distribution - Pingwinek. It
didn't gain popularity, the distribution didn't stand the competition.
Even back then there was over 300 linux distributions already
available. That is why I decided to drop the development of "Pingwinek
GNU/Linux". During work on the project over 2500 package descriptions
have been made along with the "box" packaging system. I thought that
he work that has been done should not be wasted. That is why then I
decided to change the base system to a different one, but which one?
At first I put my interest on other big popular systems, *BSD,
OpenSolaris. But I decided to give less popular systems a chance like
Haiku, Hurd, Minix and Syllable. After a few months of observation of
those projects, I chose Haiku - it was the second half of the year
2006. Even though Haiku back then was far from stable, couldn't
properly free allocated memory, the native compiler cold not compile
"Hello World", I chose Haiku because I saw future in it. It was a hard
choice because other systems were more stable in that moment, e.g. the
compiler on Syllable worked with no problems. Looking from the time's
perspective, I think the choice of Haiku was a good choice, although
lately other systems also started developing more rapidly. I'm talking
here about Minix and Hurd. In March 2007, I released "Pingwinek
GNU/Haiku". Later, because of licensing reasons, I changed the name to
TiltOS and moved on in the direction of package creation.
3. You're the creator of the Haiku gcc4 TiltOS 'distribution' -
although in the gcc4 license context we cannot really use the word
Haiku - I'm writing this in quotes, because it's a distribution (how
linux-like it sounds ;)) of a system that did not yet release an
official full-fledged version. More precisely, it is more a package
system for Haiku gcc4/gcc4h. Do you think that Haiku in version gcc4
hybrid is the better path, despite dropping compatibility with some
parts of BeOS software - the requirements of media server gcc2 etc. If
yes, write more about this topic.
Compatibility with older applications is very important. We also need
to look into the future. Newer applications require newer compilers.
Many applications dropped GCC2 support (the C89 standard) long ago. I
don't know anything about applications that work on gcc2 and do not on
gcc4h. If such exist, the problem is probably resolved in a more or
less complicated manner. For instance, problems with translators in
version gcc2 on a gcc4h system have been resolved by putting them in a
gcc2 subdirectory and special handling.
While we're at the compiler topic, I would like to mention that in the
last weeks I have been working on compiling Haiku using the clang
compiler. The goal, in a minimal, has been realised, i.e. the whole
Haiku system has been compiled and working. In the process I have
filled in a few bugs to the compiler and the Haiku operating system,
along with respective patches. A few problems still need resolving,
e.g. dropping code bypasses that I had to do to compile Haiku. Some
fragments need to be rewritten etc., some applications also behave
differently. The reason for this might be the bypasses in code I made
or Haiku bugs which revealed themselves when using the clang compiler.
4. You also help in Qt development. Do you think that beside of many
pros the easier porting of known applications such as VLC Media
Player, which in the newest versions use Qt, will lead to Haiku
getting flooded by sloppy and unfinished application ports?
That's correct, there was a time during which I was working on Qt as
well as compiled Qt applications on Haiku, e.g. KOffice, KDE. The word
'port' is very ambiguous. For example an application using Qt can get
compiled on the Haiku system and just work, since Qt is more or less
ported. The level of a port can vary. Let's take for example Qt. The
most trivial port can be such that Qt will get compiled to use the X
server for Haiku. This will work but slower, because of an additional
layer required and because of displaying the window in the X server.
The next level of a Qt port would be using the application and
multimedia servers from Haiku. This is more or less the current state.
The highest level of porting would be rewriting the application to
directly use the Haiku API. No one will do such a thing, since it
takes too much time and doesn't make much sense - maybe only if
someone from ideological reasons wants to have a fully native
I don't think that Haiku will be flooded with underdone ports. Even
if, then this is not really a problem. The users are the ones that
decide which applications they want to use. If a port is of low
quality then one of two things can happen: either someone fixes it or
it will die of natural death. Many people still think that the
appearance of popular applications from other systems on Haiku is
something bad. I think that this positively affects the popularity of
the system and confirms its stability and maturity.
5. Before, VLC was created so that it could be multiplatform - or that
ports to other systems could be easy - and was available on different
systems: BeOS, Syllable, QNX and of course all different Linux and
*nix. Today authors of the application use Qt to "ease themselves
multiplatformability". Is this, in your opinion, cutting the corners
by the VLC creators or only the lack of motivation for someone to do a
port of the newest VLC not using Qt on a system that doesn't have that
VLC programmers did cut the corners in some sense, but I can
understand them. Keeping different code for different platforms can
slow down the development of the whole project. Incompatible changes
in the core of the application appear and suddenly it is necessary to
update all existing ports. Sadly, not always the developers are
willing to swiftly update code for a given platform. Then programmers
have problems during releases, because either they wait for someone to
fix the code or disable the support for a given platform. Keeping
uniform code for many platforms is simply easier. If a given community
wants native code, it can always write an independent VLC client,
since I suspect that VLC exports the necessary API.
6. You are also responsible for the port of the KOffice office package
- which first required KDE Applications and the KDE Development
Platform - the currently most advanced and enabling easy import of
files in popular formats office package for Haiku. Analogously the
next step should be a port of OpenOffice. You wrote that no one will
try doing a native port because it makes no sense, though the OO.org
port on MacOSX, while at first being based on X server, at the end
became a native port. Besides, an application of this class written
natively would be a good trade-card for the operating system. Don't
you think that in some situations we should use some time for a port
being full rewritten for the destination operating system?
Additionally taking into consideration that Haiku in this moment does
not have even one native office package up to today's standards. Even
with the AbiWord text processor port there are still great problems,
such as Polish font glitches etc. What is the reason for this, in your
As it is probably visible by now, I like challenges. I started work on
OpenOffice for Haiku many months ago, but dropped it after a few
weeks. Before I mention the details, I would like to note that porting
applications for Haiku not always has to make no sense as I mentioned
before. In overall, applications can be divided into two groups. The
first group includes applications that have been designed in a way
that allows using alternative components, for instance for the GUI.
The second group includes monolithic applications which do not provide
such possibilities. To the first group we can include applications
such as OpenOffice (gtk+, qt, win, os2, aqua), Firefox, Abiword
(cocoa, gtk+, win, beos), Transmission (gtk+, gt, beos). Porting
applications from the first group makes sense, from the second - not
As for the problem with porting Abiword. The difficulty probably lies
in the fact that there is much code to be written. But there's still
less of it than in porting e.g. Gtk+ or Qt. Sadly, the code written is
very specific for Abiword in contrast to for example Gtk+, so the
costs are very large.
But returning to OpenOffice, I have divided porting of this enormous
application into few phases. The first phase includes compiling and
running using Gtk+ (using the X server). The second phase consists of
compiling and running using Qt (without the X server). The third and
last phase is the native port, analogical to what happens to Abiword.
After a long fight the first phase has been reached, so we have
OpenOffice available on Haiku in a X server window.
After finishing with clang I plan on returning to the OpenOffice topic
and starting the second phase. I will not even try approaching the
third phase, since in my opinion it's about a few months of work
full-time, not really for one person only.
7. Do you think the package manager that is being prepared for Haiku,
that will fulfil the requirements given here:
will finally allow installing software regardless whether it is for
gcc2 or gcc4 on Haiku gcc4h without the threat of making a mess in
system libraries? And with the certainty that everything will be on
its right place after installation of any application, even if we
would want to install some package from TiltOS?
In the given document a few ideas regarding package handling have been
presented. Sadly, the choice here is not easy, because two main
conflicting concepts meet. From one perspective, it would be good if
applications could be self-sufficient and installed in apps, but on
the other hand a central repository with package dependencies would be
also helpful. Such a repository partially forces installing packages
into one place, e.g. to /boot/common. What is more interesting, in the
document you linked no one brought up the problem you mentioned -
gcc2/gcc4, which even more complicates package handling. The current
hybrid solution is not really good, I think that the developers will
come up with a better idea before releasing Haiku R1. I personally
would see a solution in the form of different namespaces for gcc2 and
gcc4. Let's assume that we have a gcc2h system - running a gcc4
application should be performed in such a way, that it would see the
base system and gcc4 libraries. This could be done by using "UnionFS"
and "chroot". Physically, gcc4 files would be separated from the main
file structure and could be located in e.g. /boot/abi/gcc4.
But referring to your last question - TiltOS packages are located in a
central repository. This concept is in conflict with other sources of
files, such as manually installed applications in the same place on
disk or other package systems. An analogous situation exists in the
world of linux distributions. For instance on a Ubuntu system (deb
packages) we shouldn't install packages from Fedora (rpm). Although it
is possible, it can result in file overwriting, incoherent information
and potential incompatibilities.
8. You wrote in a few places that the need of native application by
users comes from ideological reasons. But don't you think that the
very creation of Haiku or even BeOS was an ideological move caused by
the need of creating an alternative for commercial systems like
Windows or MacOS, in the same time not being based on existing
solutions with the luggage of old solutions such as Linux? Creating a
system from scratch based on new technologies, prepared for certain
usages in which existing solutions had problems. Maybe that is the
reason why programmers and testers work on Haiku - because it tries to
create its own solutions instead of taking existing elements from
other systems. Otherwise they might not have been interested in the
system at all.
I don't know what goal the creators of BeOS had in mind, but I can
suspect that it was more a commercial than ideological decision.
Whereas Haiku was created because of ideological reasons and I think
that this is the main force behind the constant system development
despite the high competition of other systems.
In my opinion, one of the main advantages of Haiku is the system
coherence and well designed API. We have one API for network support,
multimedia, GUI etc. It's completely different in the world of linux.
There is chaos there. For multimedia we have e.g. GStreamer, Phonon,
ffmpeg - it's not even worth mentioning sound handling. For GUI, we
have e.g. Gtk+, Qt, fltk, and the graphical subsystem changes
9. How do you see the future of TiltOS? Will it be parting from Haiku
in solutions sense or will they be moving along the same path? Or
maybe in some time will we see TiltOS as a system based on Haiku but
heavily integrated with the Qt environment?
In its current state, TiltOS differs from Haiku mainly with that most
of the code that resides in the Haiku repository that originally comes
from other sources has been replaced with box binary packages. So, for
example, elements such as bash, coreutils, libpng and libjpeg are
installed from packages, and there's over 30 of them. Thanks to such a
move the system can be updated. Ultimately, I would like to modularize
the Haiku code so that one could update the kernel and respective kits
through the network instead of needing to install a newer version of
the system. I didn't think about integrating with Qt. I would like see
TiltOS more of like a modular system, binary compatible with BeOS and
Haiku (after the stabilization of gcc4 ABI) with access to a wide
package repository. Probably as a hybrid gcc4/gcc2 or clang/gcc2
10. Is there something you would like to tell our readers?
Dear readers, promote the Haiku operating system as much as you can,
it's worth it :). If you are an user you can always write about Haiku,
translate it into the Polish language, report bugs or support it
financially. If you are a programmer, you can always help developing
the system, Gallium3d, java, wine, OpenOffice and others wait for you.
So, off to work :)
Interview translation done by sil2100