Ihr Browser versucht gerade eine Seite aus dem sogenannten Internet auszudrucken. Das Internet ist ein weltweites Netzwerk von Computern, das den Menschen ganz neue Möglichkeiten der Kommunikation bietet.

Da Politiker im Regelfall von neuen Dingen nichts verstehen, halten wir es für notwendig, sie davor zu schützen. Dies ist im beidseitigen Interesse, da unnötige Angstzustände bei Ihnen verhindert werden, ebenso wie es uns vor profilierungs- und machtsüchtigen Politikern schützt.

Sollten Sie der Meinung sein, dass Sie diese Internetseite dennoch sehen sollten, so können Sie jederzeit durch normalen Gebrauch eines Internetbrowsers darauf zugreifen. Dazu sind aber minimale Computerkenntnisse erforderlich. Sollten Sie diese nicht haben, vergessen Sie einfach dieses Internet und lassen uns in Ruhe.

Die Umgehung dieser Ausdrucksperre ist nach §95a UrhG verboten.

Mehr Informationen unter www.politiker-stopp.de.

Menu verstecken/anzeigen [Jens Benecke: ]
 Menü [JB] Computer / Debian → SuSE

Switching from Debian GNU/Linux to SuSE Linux 9.1

As detailed in this document, I have been an avid Debian supporter for quite some time now. I originally started with SuSE 5.1 Basic, but soon after switched to Debian and stayed there for a long time.

But this has changed. I deserted the Debian Camp in April 2004, and went elsewhere. Only our main server (where this web site is running) is now still running Debian GNU/Linux, my home machines have all been converted to SuSE.

Why?

Three main reasons.

  • More desktop related stuff included and configured by default. After moving out of student life, my focus shifted onto more user oriented things, I do not run three servers at home any more, just one machine.
  • More 'stable' system (stable meaning not constantly changing, see below).
  • SuSE has gone a long way since I seriously used it last time and has become friendly even towards experiments and YaST haters.

Debian vs. SuSE

Installation and default setup

No need to talk about that. Debian's current stable version puts a system on your harddisk that boots, period. If anything, it configures your network, but only if it is not USB or WLAN based. It does not care about X11 (graphical user interface), mouse, RAID, volume management, Firewire, Bluetooth, DSL, power management (ACPI/APM), CD and DVD burners, TV/DVB cards, sound cards and whatever other stuff you might have plugged into your computer. All of that stuff needs to be installed and configured manually with Debian, comparable to Windows (although Windows at least produces a GUI for the installation).

The default SuSE installation is desktop oriented: KDE desktop with SuSE specific welcome and support icons, OpenOffice, RealPlayer 10, Macromedia Flash plugins, audio and video players, CD/DVD burning, and not much more. The whole system is about 1.5GB including all applications. (There is the option of installing a "minimal" system which would only be about 400MB, without GUI.) The default KDE menu is clean with few but relevant choices of software, not cluttered with hundreds of applications, like the default Debian desktop was (but this might have changed).

For me, using SuSE meant that I did not have to compile my own kernel because SuSE already contains the half dozen patches that I needed for regular use, e.g. ReiserFS updates. It meant that I did not have to compile my own KDE because SuSE provides updated KDE packages for all of their distributions. It meant that I did not have to manually configure my system to automatically recognize and display USB and/or Firewire harddisks when I plugged them in, or manually compile and configure ALSA to work with my soundcard. That saved me quite a bit of work, but also fun - fun tinkering for which I do not have the time any more..

Installation - nifty little things

For special setups, SuSE also offers things like headless installation which you can perform without monitor - and, optionally, keyboard (using a boot installation floppy with pre-defined settings). Enter something like

hostip=192.168.2.1/24 vnc=1 vncpassword=xyz
and Linux will boot, autodetect the network, start a virtual VNC server to which you can connect using the given password and start YaST from within this VNC session. This means that you don't have to sit in the server room all the time, while Linux installs. :-)

Also, a boot command line like

hostip=192.168.2.1/24 ssh=1 sshpassword=xyz
will do the same thing using SSH. You can connect with any SSH client and - if you have a local X11 server running - the graphical YaST2 installation program will appear on your local desktop (if not, the text based YaST2 will start) and you can install remotely.

Adding

install=ftp://192.168.2.5/pub/wherever/
will fetch all the files from a remote location. It supports, FTP, HTTP, NFS, Samba (Windows share), and SLP (auto discovery). Also, installation over a serial console is possible. See Remote Installation at SuSE's portal page for more information.

Versions

I have lived with and supported Debian for about six years and also lived with its shortcomings. The main things that people complain about constantly with Debian is that it is not divded into three versions called stable, testing and unstable, but rather in stale, untested and broken. The stable tree is something for people who do not care about software younger than two to three years. It is very well tested and Debian developers are really, really fussy about bugs and errors in the stable tree. It is good for production machines where the newest version is not needed, but critical services require as much stability as possible. See here for a discussion.

Testing and unstable are for power users who know what they are doing and want reasonably tested software that does not wreak havoc on your system but might require manual intervention such as configuration, or which has obscure bugs that are very hard to reproduce but do happen. I ran Debian unstable for almost three years and never had a system that was unuseable to the extent that I had to reinstall everything. However, I had dozens of cases where a "normal user" would have simply given up and reinstalled from scratch, because I had to leave the graphical interface and fix things using the text console, or a rescue system.

I do have to admit however, that many of these cases were self induced by installing known unstable software. But Linux is like that - if you know how, you can install broken stuff and still be able to manually fix things because the system is totally open. Nothing is purposedly hidden like in most commercial operating systems where even the most professional people have no chance after a certain point.

Returning to Debian: My primary point was that for the software I wanted, most of the time I needed manual work to get it running "properly", because the versions that Debian shipped were too old or not there at all. With SuSE, I can install one version and update it with external packages that are also available (e.g. new KDE releases), but there is always a fairly up to date released version available.

Package configuration

Debian is constantly praised for its clean innards and (as I have done as well) good pre-configuration of software. If you install, say, a DNS server, it comes pre-configured with a default setup that works after asking you a couple questions abou your network setup. But this only goes so far: There is no central configuration tool that knows about all the cross-dependancies of software.

For example, if I enable routing on my SuSE machine via YaST, it automatically installs a DHCP server that knows that I have a dynamic IP address, and thus potentially changing DNS servers, and configures the DHCP server in a way that it updates its own configuration according to what my provider tells me via PPPoE. For Debian, there is no button that says "Share this internet connection", it has do be done manually, for example with a shell script.

Standards compliance

Debian has a very well documented /etc directory where all the system configuration goes. SuSE, just like just about every major distributor except Debian and (maybe?) Gentoo, has put a layer on top of /etc, according to the Linux Standard Base which dictates a common base among different Linux distributions for application developers to be able to depen upon. The LSB definition is followed quite strictly by SuSE, and (as far as I could see) not at all by Debian, which is why many commercial applications just don't work (properly) on Debian, or at least aren't officially supported. My impression is that Debian is too much a 'moving target' for the software industry.

For example: Debian provides several startup mechanisms: the BSD init system, SysV init, file-rc, and several others. It is up to the user which one they want, they all have advantages and disadvantages e.g. regarding maintenance. SuSE provides only one, the "standard" init system, but it is integrated with the rest of the system, works and has a lot more features like startup dependancies specified inside the respective files (so that they can be started in the correct order). For example in /etc/init.d/ssh there is this text:

### BEGIN INIT INFO
# Provides: sshd
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the sshd daemon
### END INIT INFO
which tells the init system what this application is all about, what it requires and when it is supposed to be started and stopped.

Development and package management

This was one of the reasons why it took me so long to move to SuSE. In the past, SuSE users had little choice when it came to installing an application that was not compiled for SuSE. They could compile it themselves using the traditional ./configure && make && make install commands, but would have to figure out all dependancies by themselves, and with this method, the application would install $DEITY knows where and not easily be uninstalled any more.

Debian provides a way of reconfiguring source code packages in that they install in a temporary directory and a Debian package (.deb) can be built from the application. This works really well, and automatically figures out dependancies and installation locations. Reconfiguring applications to build a RPM package for SuSE (and other distributors) is a little harder, but more flexible in the end. You need to build a so called SPEC file which contains bascially the same information that Debian needs to build the package. Then you have several possibilities, my favorite is the SuSE build tool.

'build' uses the SuSE installation DVD to create a new build system inside a chroot environment, completely independant from your running system, compiles the package there, and returns the RPM file. This requires (of course) that you know which SuSE packages are needed for building the package, and list them in the SPEC file. But the advantages are quite interesting:

  • Your build environment does not change your running system. You do not need to install dozens of -devel packages into you running system to compile something.
  • The RPM you are building fits 100% into a "standard installation" and only depends on packages that SuSE ships by default. I have upgraded to KDE 3.3.2 on my home machine, but the RPMs I build link against the official 3.3.0 libraries that SuSE 9.2 ships with.

Of course, you can do all that with Debian as well - I hear that many Debian developers use the chroot feature to compile their packages for each Debian release - but it requires more manual work.

Package maintenance and updates

In the past, I complained about maintaining and updating a SuSE system. This is still partially true. SuSE system updates are done via YaST and only care about the packages that SuSE can update on its own. If you install third party products that can neither be upgraded nor kept (because they depend on some old version of a library that would get replaced with a current version), they will - probably - be removed and you will have to find newer versions to re-install after the upgrade.

But serisously: I have found these are rather theoretical disadvantages. The package management system works well, APT for RPM exists and you can even include external repositories into YaST, like Links 2 Linux which provide many additions like audio/video players and codecs (see also my recommendations). This includes almost everything you might need for several SuSE versions, including distribution upgrades, available via APT. You can forget about SuSE's online update and keep your system up to date via APT alone, if you want.

Plus, there are some features that Debian does not yet offer. How about patch RPMs and delta RPMs? If you installed, say, OpenOffice.org, which sizes about 60MB, and there is an upgrade to one part of OpenOffice.org that only changes three files, you usually had to download the upgraded package, which would mean another 60MB. With patch RPMs, you download a RPM package that only contains the changed file(s), and with delta RPMs, you download a RPM package that contains a binary diff of all the changes. The net result on your harddisk is the same, and the RPM package database is updated accordingly. This really saves on download time, at the price of a bit more local work for the update application to apply the patches instead of just overwriting files. YaST and its online update feature use all these features by default.

The packages themselves

SuSE ships with fewer packages than Debian. A lot fewer. This is mostly due to the fact that they concentrate on one mail server (Postfix), one web server (Apache) and so on, and don't split packages up as much as Debian. SuSE 9.2 includes 206 perl packages, most of which are modules depending on additional software that would make no sense installing by default. Of these, I have installed thirteen on my desktop, and none manually (most are needed by YaST and the system, I guess).

Debian includes over 800 perl packages (of which about 20 are installed on this server) and I guess at least some of these 800 are duplicates, due to the fact that Debian does not have an "official Perl version". SuSE 9.2 has Perl-5.8 and every perl package is adopted to this version. Debian (Sarge) includes 5.004, 5.005, 5.6, and 5.8 and not all Perl module packages actually depend on the newest version of Perl yet.

But that's just speculation. Maybe Debian actually does include more Perl modules. Or maybe Debian will eventually adopt Perl 5.8 (or 6.0 or 6.005 or whatever comes next) as the 'official' version and then wait another year until all the maintainers have adopted all the Perl dependant packages, until releasing Sarge. Who knows.

Bugs

SuSE packages still display "http://www.suse.de/feedback" as the "package maintainer". On this web page you will find a feedback form where you can report bugs. This works pretty well, although you do not get any default feedback from SuSE. I have reported about 30-40 bugs since SuSE 9.1 came out and I have received replies for only about ten of them (mostly questions), but most of them were fixed in later upgrades. This is an area where Debian developers are still a little bit better in terms of responsiveness (although I have never had all of my reported bugs fixed in Debian either). If you just want to "fire and forget" (tell them something is going wrong and forget about it, instead of entering into a dialog with the developers to track down the problem) this is OK.

SuSE 9.1 shipped with a few bugs that were corrected in subsequent online updates, for example regarding hotplugging support. Also, I had to configure XFree86 (or, as of 9.2, X.Org) manually because I have two TFT displays and wanted a big single desktop, which YaST could not do automatically then). But all of the bugs that I encountered were either application bugs (and would therefore also have been in Debian, because the apps are the same), or they were in features that Debian did not have at all, e.g. automatic mounting and display of removable media on the current user's desktop.

Conclusion

SuSE is not for the hardcore geek whose goal is to recompile his system twice a day, and who wants to keep patch his own kernel and maybe run multiple kernels alternatively (support for keeping the old kernel after an upgrade is only officially in YaST since SuSE 9.2). SuSE has working, up to date packages, a sensible default configuration, it is quite easy to keep updated and to get running, and it is easier to get additional packages (by including new repositories in YaST, or by using APT plus an appropriate graphical frontend). The installation could not be easier, except maybe for more exotic configuratios like dual-screens (in my case).

SuSE needs more work regarding updates of external packages. Most problems would be solved by allowing additional package sources from within the system update application, even when booting from the new CD or DVD. You'd need the location where the new applications reside but anybody who did install external apps would know where to find their upgraded version as well.

But for the average somebody and also for some server things, I would now prefer SuSE. I mainly installed Debian on the server running this website because I have known it for far longer and the maintenance and customer management application (SysCP) requires Debian.


Zuletzt geändert am: 28.02.2005 15:03
(c) 2003 Jens Benecke. Verlinkung dieser Seiten generell erlaubt, ich übernehme KEINE Verantwortung für externe Links (z.B. zu Google-Suche).
Details hierzu und zur Verantwortung über den Inhalt der Seiten hier.
Alle Artikel auf dieser Seite sind lediglich MEINUNGSÄUSSERNGEN.
[Apache Logo] [Debian Logo] [PHP Logo] [Perl Logo] [MySQL Logo] [Postfix Logo]